crosser

Edge from the deb package (6.8.11-edge-rockchip64). It was the first time; this Saturday I got a similar situation, _but_ I was able to ssh (after minutes of waiting) and save syslog. The first anomaly in the log was (this time): Sep 14 22:11:52 kobol kernel: BUG: Bad page state in process kcompactd0 pfn:1e320 Sep 14 22:11:52 kobol kernel: page:000000001709b832 refcount:0 mapcount:0 mapping:000000004953ae39 index:0x4c1a1c30 pfn:0x1e320 Sep 14 22:11:52 kobol kernel: aops:0xffff800081149ed8 ino:1 Sep 14 22:11:52 kobol kernel: flags: 0xffff1800000020c(referenced|uptodate|workingset|node=0|zone=0|lastcpupid=0xffff) Sep 14 22:11:52 kobol kernel: page_type: 0xffffffff() Sep 14 22:11:52 kobol kernel: raw: 0ffff1800000020c dead000000000100 dead000000000122 ffff0000009e8338 Sep 14 22:11:52 kobol kernel: raw: 000000004c1a1c30 0000000000000000 00000000ffffffff 0000000000000000 Sep 14 22:11:52 kobol kernel: page dumped because: non-NULL mapping and later there are repeated "rcu: INFO: rcu_preempt detected stalls on CPUs/tasks ..." (see attached file). I will try that other dtb, thanks! rcu-stall.txt

I found my Helis64 unresponsive after about a week or so. Even heartbeat LED is not blinking (permanently on). I see this repeating on the serial console [495778.879711] rcu: rcu_preempt kthread timer wakeup didn't happen for 5324533 jiffies! g9706925 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 [495778.880747] rcu: Possible timer handling issue on cpu=3 timer-softirq=2513452 [495778.881383] rcu: rcu_preempt kthread starved for 5324534 jiffies! g9706925 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x200 ->cpu=3 [495778.882336] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. [495778.883137] rcu: RCU grace-period kthread stack dump: [495778.883584] task:rcu_preempt state:R stack:0 pid:16 tgid:16 ppid:2 flags:0x00000008 [495778.884404] Call trace: [495778.884627] __switch_to+0xe0/0x124 [495778.884946] __schedule+0x308/0xa8c [495778.885263] schedule+0x34/0xf8 [495778.885549] schedule_timeout+0x98/0x1bc [495778.885902] rcu_gp_fqs_loop+0x150/0x670 [495778.886256] rcu_gp_kthread+0x234/0x274 [495778.886603] kthread+0x114/0x118 [495778.886896] ret_from_fork+0x10/0x20 [495778.887219] rcu: Stack dump where RCU GP kthread last ran: [495778.887705] Sending NMI from CPU 4 to CPUs 3: Aside from usual NFS server (unused at the time) and syncthing, it was running duplicity backup at the time. I cannot rule out that it ran out of memory. Though it did run full backup successfully a couple of days ago. helios64-rcu-stall.txt

Thanks @prahal. I think that possibly interface renaming issue was triggered by the change of the MAC, as in, there was a preexisting renaming udev rule that bound the name to the mac address, and it stopped matching. My system was upgraded across multiple ubuntu versions, it's difficult to figure what's the new thing, and what's a leftover (booting the same userspace with 6.6 kernel returns the old naming). Yes, static dhcp lease is what bit me. And big thanks for your effort! It's awesome to be able to continue to use this very decent hardware so long after it was abandoned!

Thanks @ebin-dev! (I need to figure out what to watch to keep up with the new developments. Not easy when it comes to armbian...)

With the recent update of the kernel "edge" package (6.8.11-edge-rockchip64) when the system boots. interfaces get different names (they used to be "end0" and "eth1" before, and now they are "eth0" and "eth1"), but more importantly, they both show different MAC address (the old address returns when previous kernel is booted). It took some time to figure why it did not appear on its prescribed address... Anyone notice this, or has a clue why? Armbian 24.5.5 noble Linux kobol 6.8.11-edge-rockchip64 #1 SMP PREEMPT Sat May 25 14:28:41 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

FWIW: I had similar problem, and it was fixed by adding a dependency with an override file that I think should have been a default dependency in the first place: $ cat /etc/systemd/system/proc-fs-nfsd.mount.d/override.conf [Unit] After=local-fs.target That simple!

There's been a problem when 5.15 was first rolled out (mmc access, fan control, ...) and I pinned 5.10 for a while. A couple of months ago I tried Lunar with edge kernel (6.1) and it worked fine. So I switched and run it now, without any problems(*). I tried 5.15 as well, and it worked fine too. Things look quite good now, great thanks to the unsung heroes who are keeping the distro for this hardware alive! (*) I use NFS server, and due to a problem not specific to the kernel, it fails to start at boot. That is because `nfsd` module is not included in initramfs, and `proc-fs-nfsd.mount` unit tries to load before the "real" root fs is mounted. And fails, and prevents all other nfs services from starting. That is solved by adding `After=local-fs.target` to the unit.

I remember _one_ version of the kernel (released as a package in the focal channel) about a year ago was broken, but I don't remember details. I do remember that I booted from the (stock) SD, ran dist-upgrade, and things returned to norm. It is possible that 5.10.60 was the one that was broken for me too. I am attaching a log from reset to "Welcome" when the system is booted, with kernel 5.15.35. At this point, internal mmc is not visible in the system (and obviously not mountable). Eugene kobolboot-5.15.35-fail-to-mount

Kernel 5.15 is unusable for me (helios64), 5.15.25 and 5.15.35 do not see internal mmc: [ 2.404726] mmc1: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA [ 2.474955] mmc1: mmc_select_hs200 failed, error -110 [ 2.475458] mmc1: error -110 whilst initialising MMC card [ 2.592202] mmc1: mmc_select_hs200 failed, error -110 [ 2.592665] mmc1: error -110 whilst initialising MMC card [ 2.724392] mmc1: mmc_select_hs200 failed, error -110 [ 2.724853] mmc1: error -110 whilst initialising MMC card It works with all previous kernels (up to 5.10.63), u-boot boots from it just fine. Is it a known problem?