crosser

@prahal I am running this now: crosser@kobol:~$ cat /etc/os-release PRETTY_NAME="Armbian 24.11.3 noble" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.armbian.com" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" PRIVACY_POLICY_URL="https://www.armbian.com" UBUNTU_CODENAME=noble LOGO="armbian-logo" ARMBIAN_PRETTY_NAME="Armbian 24.11.3 noble" crosser@kobol:~$ uname -a Linux kobol 6.12.1-edge-rockchip64 #1 SMP PREEMPT Fri Nov 22 14:30:26 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux crosser@kobol:~$ dpkg --list|grep dtb ii linux-dtb-edge-rockchip64 24.11.1 arm64 Armbian Linux edge DTBs in /boot/dtb-6.12.1-edge-rockchip64 crosser@kobol:~$ without any kernel-level alterations (A few minor userspace config modifications are needed to make LED work, and nfs services start in the right order, but that is all)

@prahal sorry for dropping off. I was too lazy to build the needed version of the kernel, and before long, a new edge release came out, and the device was rock solid since then. Knock on wood. (As a side note, I _do_ have a real problem with the hardware: after some research I figured that one of the two disk power circuits has gone bad, so now I have two disks (and SSD) working, and three slots empty.) crosser@kobol:~$ uname -a Linux kobol 6.12.1-edge-rockchip64 #1 SMP PREEMPT Fri Nov 22 14:30:26 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux crosser@kobol:~$ uptime 20:32:31 up 56 days, 12 min, 1 user, load average: 0.04, 0.05, 0.00 (last reboot to upgrade the kernel, no crashes for quite a while)

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.