anonymoustemp

5.1.0-1111-ayufan tag. Kernel crash when PCIE card is installed (thus pcie host root complex initialize). Will try previous tags soon, BTW, if anyone successfully run the "mainline" kernel with PCIE cards? [ 161.895780] io scheduler mq-deadline registered [ 161.897340] io scheduler kyber registered [ 161.911264] io scheduler bfq registered [ 162.136905] vcc5v0_host: supplied by vcc5v0_usb [ 162.740884] rockchip-pcie f8000000.pcie: no vpcie12v regulator found [ 162.746764] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found [ 162.750391] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found [ 163.280713] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 163.284059] rockchip-pcie f8000000.pcie: MEM 0xfa000000..0xfbdfffff -> 0xf0 [ 163.286820] rockchip-pcie f8000000.pcie: IO 0xfbe00000..0xfbefffff -> 0xf0 [ 163.302884] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00 [ 163.305119] pci_bus 0000:00: root bus resource [bus 00-1f] [ 163.306968] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff] [ 163.310027] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff] (bus add) [ 163.542130] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reg [ 163.560746] SError Interrupt on CPU5, code 0xbf000002 -- SError [ 163.560932] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G L 5.1.0-3 [ 163.561051] Hardware name: Pine64 RockPro64 (DT) [ 163.561157] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 163.561258] pc : rockchip_pcie_rd_conf+0x1e8/0x280 [ 163.561356] lr : rockchip_pcie_rd_conf+0x214/0x280 [ 163.561440] sp : ffff00001004b7f0 [ 163.561527] x29: ffff00001004b7f0 x28: 0000000000000000 [ 163.561800] x27: 0000000000000000 x26: 0000000000000000 [ 163.562047] x25: 0000000000000004 x24: ffff800004de13c0 [ 163.562275] x23: 0000000000000000 x22: ffff8000f61d6800 [ 163.562499] x21: ffff00001004b894 x20: 0000000000100000 [ 163.562718] x19: 0000000000000000 x18: 0000000000000000 [ 163.562936] x17: 00000000250ca3fe x16: 000000009ae7c865 [ 163.563154] x15: ffffffffffffffff x14: ffff00001153d6c8 [ 163.563374] x13: ffff8000ec3df91c x12: ffff8000ec3df190 [ 163.563592] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f [ 163.563811] x9 : ff72646268756463 x8 : 00000000000003bd [ 163.564030] x7 : 0000000000000000 x6 : 0000000000000001 [ 163.564248] x5 : ffff00001060f630 x4 : 0000000000000000 [ 163.564466] x3 : 0000000000000000 x2 : 0000000000c00008 [ 163.564686] x1 : ffff000017c00008 x0 : 0000000000000000 [ 163.564961] Kernel panic - not syncing: Asynchronous SError Interrupt [ 163.565098] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G L 5.1.0-3 [ 163.565196] Hardware name: Pine64 RockPro64 (DT) [ 163.565276] Call trace: [ 163.565367] dump_backtrace+0x0/0x168 [ 163.565452] show_stack+0x24/0x30 [ 163.565535] dump_stack+0xac/0xd4 [ 163.565617] panic+0x150/0x2e8 [ 163.565705] __stack_chk_fail+0x0/0x28 [ 163.565798] arm64_serror_panic+0x80/0x8c [ 163.565884] do_serror+0x11c/0x120 [ 163.565968] el1_error+0x84/0xf8 [ 163.566064] rockchip_pcie_rd_conf+0x1e8/0x280 [ 163.566164] pci_bus_read_config_dword+0xb8/0x108 [ 163.566271] pci_bus_generic_read_dev_vendor_id+0x40/0x1b8 [ 163.566368] pci_bus_read_dev_vendor_id+0x58/0x88 [ 163.566464] pci_scan_single_device+0x84/0xf8 [ 163.566556] pci_scan_slot+0x44/0x108 [ 163.566653] pci_scan_child_bus_extend+0x5c/0x350 [ 163.566749] pci_scan_bridge_extend+0x37c/0x518 [ 163.566849] pci_scan_child_bus_extend+0x204/0x350 [ 163.566945] pci_scan_root_bus_bridge+0x60/0xd0 [ 163.567042] rockchip_pcie_probe+0x5ec/0x718 [ 163.567135] platform_drv_probe+0x58/0xa8 [ 163.567223] really_probe+0x1f0/0x3d8

Unfortunately, that's from myself and the you can see the original author mentioned that it's just a basic setup. In fact, upstream Uboot, even just using evb board config, can boot on that RockPro64. While USB doesn't work in that case and no sdcard support, only eMMC and ethernet, and I haven't tested eMMC. With that commit, I ran into the ram issue.

The armbian idbloader/uboot/trust combo survives at least one loop. While my bad upstream uboot build can not even survive 10 tests of a single loop. Armbian community/build rocks! And here is my feedback to Armbian: Upstream kernel works relatively well with armbian uboot. What I have tested: boot (WORKING) SDcard (WORKING) git checkout for mesa (WORKING) memtester, still running at least one loop passed (WORKING) base system upgrade (WORKING) ethernet (WORKING) USB2.0 and 3.0 port (WORKING) PCIE slot, no root complex, although PCIE power is on (NOT WORKING) What I haven't tested yet but will test soon: Memory performance (upstream alarm vs armbian, armbian uboot) LLVMpipe wayland/X11 Maybe some basic audio test on that 3.5mm jack eMMC (will take some time for that purchase) What I won't test: Blob X11/wayland, I just hate blob, especially when I just want a NAS build BT/Wireless, Just don't want to spend extra money on a NAS. GPIO headers, the same reason. Now it's my turn to "steal" some juice from the armbian/ayumi uboot branch for alarm. But AFAIK for nas build, I still need to use armbian legacy kernel for a while.

Not in rc5 nor rc6 yet. Just saw the rockchip wiki mentioning it's *UBoot* initialize the memory controller, so bad Uboot build and bad that upstream patch. I'm just taking the shortcut to use the armbian idbloader/uboot combo and running Archlinux Arm kernel to test if the v5.0.8 works. Will report back soon.

Hopes this will be the last question. What's the armbian recommended test suit for SBCs? As I have only focused on fs so far, the main suits are fstests, LTP and bcc (for error injection and performance analyse). It would be a good idea to have a simple suit to test stability (maybe just LTP?) Thanks.

Thank you very much for such information. As I'm completely new to SBC community, and the huge different from my previous kernel experience indeed surprises me. Now it totally makes sense. Makes sense for the situation. I'll check the branch to see if I can find something related and test. And explore the armbian repo to find some clue with the Uboot/firmware (which is my current assumption of the strange crash). Thank you again for the detailed explanation on the workflow.

That's what I didn't expect at all. Shouldn't upstream get more review and tests? Or it's a completely different case for ARM world? That branch looks pretty promising, although some commits don't meet upstream standard just by a quick glance. But still it provides a pretty good clue for me to look into the random hang. It pretty much limits the modification to a reviewable size, which is a huge leap compared to legacy kernel. Thank you very much for the info.

Hi, I got my RockPro64 board several days ago, and got *UPSTREAM* kernel (v5.1-rc5) and uboot (v2019.04) running on it using Archlinux ARM. (Sorry guys, I like upstream and Alarm more) The pull request for uboot-rockpro64 can be found here: https://github.com/archlinuxarm/PKGBUILDs/pull/1691 The upstream kernel is in the official core repor of Archlinuxarm (and that's why I like Alarm so much). It boots and runs mostly OK on full upstream kernel/u-boot setup. On rc-kernel it even has HDMI output working, but no hardware acceleration. I'm waiting panfrost as the open-source driver, so far it doesn't matter much as I don't plan to use it with X11/wayland anyway. But it's awesome that you can just run GNOME3 on wayland, using llvmpipe. And I even compiled mesa with panfrost natively on that board, so the future looks super bright. However the biggest problem I hit is, upstream (5.0.8 and 5.1-rc5) kernel has random panic. The panic itself is Async SError, and mostly happens for memory heavy operations (memtester and heavy file operations like checking out the whole kernel code). The last panic I hit has no meaningful kernel calltrace, just el0_error_naked (user space triggered, and memtester is running) At first I thought it's faulty ram, but when using the rockchip kernel from Armbian, it no longer crashes any more. I have no clue what's going wrong, device tree? idbloader? trust.img? Uboot? Or just upstream kernel sucks? (I really hate to admit the last one) Is there any upstream kernel precompiled in armbian for me to test so I could rule out one more problem? Thanks.