ebin-dev

Thanks for the initiative with the PR. Here is what happens: The cpufreqpolicy sets a generic value for the sampling_rate of 200000 (this is how often the governor’s worker routine should run, in microseconds). The sampling_rate should be set to a nominal value close to the cpuinfo_transition_latency (49000 and 40000 nanoseconds for the clusters of rk3399) such that it is effectively about 1000 times as large. For rk3399 boards the cluster sampling_rates of 49000 (big) and 40000 (little) are very responsive and not too demanding for the cpus. In that case no problems occur if io_is_busy is set to 1 ! I added a comment to PR6507 and requested that the sampling_rate should be a parameter (per cpu cluster) and be set to the value of the cpuinfo_transition_latency of that cpu. The fine tuned values for Helios64 are those (io_is_busy set to 1 again, sampling_rate set to more responsive values): for cpufreqpolicy in 0 4 ; do echo 1 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/cpuinfo_transition_latency) > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done Edit: With these changes the timeout issues of the 2.5G interface are resolved for 6.6.29 and 6.6.30 too. Helios64 is one of the best arm based NAS systems I have seen so far. I am not going to replace it anytime soon.

@SteeMan I tested the latest changes in armbian-hardware-optimize with linux 6.6.8, 6.6.29 and 6.6.30 on a Helios64. The above cpufreqpolicy does not work if 'io_is_busy' is set to 1 on Helios64 at least if the 2.5G interface is used (transmit queue timeouts). In armbian-hardware-optimize (a-h-o) it is set to 1. It must be set to 0 (kernel default). If the sampling_rate is set to a more responsive value of 50000 the issues vanish with io_is_busy set to 1. The optimizations for the 1G interface (eth0/end0) in the armbian script (see below) have the effect that those tasks are not performed in the NIC anymore (hardware) but on the CPUs in software. The effect is a huge additional load on the CPUs. Anyway such settings are not necessary with the new EEVDF scheduler anymore. The reason why I am disabling armbian-hardware-optimize is that I need a stable system and I want to avoid any random and untested changes on my system. echo 8 > /proc/irq/$(awk -F":" "/eth0/ {print \$1}" < /proc/interrupts | sed 's/\ //g')/smp_affinity echo 7 > /sys/class/net/eth0/queues/rx-0/rps_cpus echo 32768 > /proc/sys/net/core/rps_sock_flow_entries echo 32768 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

TLDR; The dtb contains a 75 mV bump for all fast cores as suggested by @prahal. You can find the opp-table-1 in this thread above (posted April 19). Use device tree compiler 'dtc' to apply your own changes (link). The dtb further contains a fix that enables hs400 speed on emmc also proposed by prahal. There is also a change for providing L2 cache information (this is all explained in this post) - and there is also a note that 6.6.29 is stable with those modifications. However, 6.6.29 and 6.6.30 bugs me with frequent transmit queue timeouts while using the 2.5G interface (NETDEV WATCHDOG: end1 (r8152): transmit queue 0 timed out 8584 ms). I could not find any combination of settings to get rid of this. Therefore I switched back to 6.6.8 - it works perfectly fine - absolutely no issues. I am on linux 6.6.30 with the following configuration were armbian-hardware-optimize.service is disabled and NAS performance is restored: (The transfer rate from Helios64 to a MacBook Pro is 280MByte/s using a 2.5G switch in between and a 2.5G USB-C Dongle (StarTech US2GC30 (rtl8156bg)) attached to the Mac) root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1800000 GOVERNOR=ondemand root@helios64:~# cat /etc/rc.local #!/bin/sh -e # # rc.local # # This script is executed at the end of each multiuser runlevel. # Make sure that the script will "exit 0" on success or any other # value on error. # # In order to enable or disable this script just change the execution # bits. # # By default this script does nothing. for cpufreqpolicy in 0 4 ; do echo 1 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/io_is_busy echo 25 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/up_threshold echo 10 > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_down_factor echo $(cat /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/cpuinfo_transition_latency) > /sys/devices/system/cpu/cpufreq/policy${cpufreqpolicy}/ondemand/sampling_rate done for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 30 > /proc/irq/$i/smp_affinity done exit 0 root@helios64:~# systemctl disable armbian-hardware-optimize.service root@helios64:~# reboot Edit: 'sampling_rate' reduced, it was not responsive enough - now 49000 (big cores) and 40000 (little cores) in microseconds. The nominal value is the same as 'cpuinfo_transition_latency'. If you are happy with 6.6.29 or 6.6.30 go ahead. For your convenience I attach the modified dtbs. rk3399-kobol-helios64.dtb-6.6.8-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.29-L2-hs400-opp rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp

I gave up on 6.6.29/30: in general they are stable but the 2.5G interface causes trouble again (NETDEV WATCHDOG: end1 (r8152): transmit queue 0 timed out 8584 ms) although the code for the r8152 driver did not change since the release of 6.6.8. Therefore I am back again on 6.6.8. It runs fine with the kernel defaults, irq smp_affinity set for ahci and xhci (see above) (armbian-hardware-optimize.service disabled) and it also benefits from the 75 mV opp increase (dtb attached). rk3399-kobol-helios64.dtb-6.6.8-L2-hs400-opp

You are running out of stack space during rsync.

It is not only about setting default cpufreq governors - there are also other settings essential for the network performance (see here). And for Helios64 it is essential to set the irq smp_affinity: for i in $(awk -F":" "/xhci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 20 > /proc/irq/$i/smp_affinity done for i in $(awk -F":" "/ahci/ {print \$1}" < /proc/interrupts | sed 's/\ //g'); do echo 30 > /proc/irq/$i/smp_affinity done If armbian-hardware-optimization is disabled or has vanished at least the irq smp_affinity should be set for sata (ahci) and for the 2.5G LAN interface (xhci) (i.e. in /etc/rc.local)

I am using the default values (after various tests). # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand Edit: I would love to use schedutil but low priority tasks take three times as long with it to complete compared to ondemand (!!) (I tested that with a complete file scan of my nextcloud installation). There was a lot discussion going on in armbian/build on github. Finally the Armbian default governor was set to schedutil again instead to ondemand. But schedutil parameters need to be fine-tuned such that EAS works correctly and from my own observations I can confirm that this is clearly not (yet) the case at least for the rk3399-kobol-helios64.dtb. Anyway - you can set min_speed to 600000 for all cores (ondemand): it does not affect power consumption at all, but it renders your Helios64 more responsive. And disable armbian-hardware-optimize - it degrades performance.

I am using the ondemand governor. # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

Just download the file "rk3399-kobol-helios64.dtb-6.6.29-L2-hs400-opp" and copy it to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb and reboot. It replaces the original rk3399-kobol-helios64.dtb which you may rename to rk3399-kobol-helios64.dtb-orig beforehand. It clearly enhances the stability of the system - but it cannot resolve any application errors.

Did you increase opp voltages by 75mV for the fast cores in this test ? (dtb attached) rk3399-kobol-helios64.dtb-6.6.29-L2-hs400-opp

Current kernel 6.6.29 uses the lowest frequencies 400 and 600 MHz also for the big cores, contrary to linux 6.6.8, where the lowest frequency used by the big cores is 800 MHz. So I would assume from what you say that linux 6.6.29 should be more stable. However, I was puzzled why this is not the case with my system: actually none of the kernels 6.6.x (x>8) was stable on my system until I tried 6.6.29 with the 75mV bump for all states of the big cores ! The explanation I have for that is that the jump from the lowest state 408 to 1.8 GHz is somewhat larger than from 800 MHz and that the correct voltage feeded to the cores becomes more critical in those cases. So with the 75 mV bump for all states of the big cores, that source of instability seems to have vanished now: 6.6.29 is stable so far (at least on my system). # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand # transition tables, linux 6.6.29 # cat /sys/devices/system/cpu/cpufreq/policy4/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 408000: 0 1705 141 1 5 1 1 394 600000: 1695 0 7 2 0 3 0 120 816000: 137 8 0 2 3 3 2 21 1008000: 2 1 5 0 0 0 0 1 1200000: 5 1 2 0 0 2 3 4 1416000: 2 0 3 0 3 0 3 4 1608000: 1 0 0 1 1 3 0 5 1800000: 407 111 18 3 5 3 2 0 # cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 408000: 0 2951 7 3 2 1547 600000: 2865 0 2 2 2 139 816000: 8 2 0 1 1 7 1008000: 4 0 1 0 4 4 1200000: 1 1 1 1 0 21 1416000: 1633 55 8 6 16 0

Linux 6.6.29 is stable on my system so far when used with the modified dtb (in particular applying the 75mV bump for the big cores, dtb attached below). Could you give it a try ? rk3399-kobol-helios64.dtb-6.6.29-L2-hs400-opp

There are only a few frequencies involved - at least on my board (see the transition tables in my other message in the parallel thread). Upping the voltage by 75mV - as you suggested - helped my board to get rid of remaining few occasional issues during the boot process ! I am measuring the combined power consumption of Helios64 and two 2.5G switches (together 12.66W idle) - it does not seem to be affected at all by that small change. Temperature reported by the Armbian welcome screen is 44 °C (ambient temp 19°C in the basement). Is the remaining crash - once a day on your Helios64 - positively affected by upping the voltage to 1.2V for all states ? If not it may be caused by something else. Edit: I am currently testing 6.6.29 using a modified dtb (L2, hs400, opp up by 75mV)

When looking at the cpu frequency transition tables it would appear there are essentially only a few frequencies involved (little cores: 600 <-> 408 <-> 1416 MHz, big cores 816 <-> 1800 MHz) # transition tables, linux 6.6.8 # cat /sys/devices/system/cpu/cpufreq/policy4/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 408000: 0 0 0 0 0 0 0 0 600000: 0 0 0 0 0 0 0 1 816000: 0 0 0 9 12 7 2 262 1008000: 0 0 17 0 1 1 3 1 1200000: 0 0 9 2 0 5 5 4 1416000: 0 0 5 3 6 0 13 12 1608000: 0 0 4 4 2 13 0 12 1800000: 0 0 258 5 4 13 12 0 # cat /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table From : To : 408000 600000 816000 1008000 1200000 1416000 408000: 0 2859 4 8 6 1572 600000: 2780 0 5 4 3 104 816000: 14 4 0 7 3 1 1008000: 3 2 5 0 11 14 1200000: 2 2 3 6 0 40 1416000: 1651 28 12 10 30 0 Edit: That behavior is specific for kernel 6.6.8. Testing 6.6.29 atm: I have noticed that it uses different frequencies: preferably switching between the lowest and the highest frequency available for each core.

But isn't that quite an improvement for your box ? Your latest suggestion (voltage increase of 75mV for the big cores) had a very positive effect ! It seems that also my helios benefits from that (but too early to be sure about it).

I am using 6.6.8 with the modified dtb (cache awareness, emmc with hs400, 75 mV bump for the big cores). It works perfectly fine. For your convenience I attach the dtb. Since Helios64 is used throughout the day by several people - time for tests is very limited. Everybody is invited to test kernels and provide feedback here. rk3399-kobol-helios64.dtb-6.6.8-L2-hs400-opp

can't confirm (my system is now based on Armbian 23.5.4): # cat /var/log/syslog | grep mdadm #

OK - I am currently testing your opp-table-1 values (added the missing ones): opp-table-1 { compatible = "operating-points-v2"; opp-shared; phandle = <0x0d>; opp00 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; clock-latency-ns = <0x9c40>; }; opp01 { opp-hz = <0x00 0x23c34600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp02 { opp-hz = <0x00 0x30a32c00>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp03 { opp-hz = <0x00 0x3c14dc00>; opp-microvolt = <0xe7ef0 0xe7ef0 0x1312d0>; }; opp04 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0xfa3e8 0xfa3e8 0x1312d0>; }; opp05 { opp-hz = <0x00 0x54667200>; opp-microvolt = <0x10c8e0 0x10c8e0 0x1312d0>; }; opp06 { opp-hz = <0x00 0x5fd82200>; opp-microvolt = <0x11edd8 0x11edd8 0x1312d0>; }; opp07 { opp-hz = <0x00 0x6b49d200>; opp-microvolt = <0x1312d0 0x1312d0 0x1312d0>; }; };

Do I understand you correctly that you suggest to increase all opp-microvolt values in opp-table-1 by 75 millivolt ? This would i.e. change opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; to opp-microvolt = <0xdbba0 0xdbba0 0x1437c8>; # here are my current values opp-table-1 { compatible = "operating-points-v2"; opp-shared; phandle = <0x0d>; opp00 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; clock-latency-ns = <0x9c40>; }; opp01 { opp-hz = <0x00 0x23c34600>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; }; opp02 { opp-hz = <0x00 0x30a32c00>; opp-microvolt = <0xc96a8 0xc96a8 0x1312d0>; }; opp03 { opp-hz = <0x00 0x3c14dc00>; opp-microvolt = <0xd59f8 0xd59f8 0x1312d0>; }; opp04 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0xe7ef0 0xe7ef0 0x1312d0>; }; opp05 { opp-hz = <0x00 0x54667200>; opp-microvolt = <0xfa3e8 0xfa3e8 0x1312d0>; }; opp06 { opp-hz = <0x00 0x5fd82200>; opp-microvolt = <0x10c8e0 0x10c8e0 0x1312d0>; }; opp07 { opp-hz = <0x00 0x6b49d200>; opp-microvolt = <0x124f80 0x124f80 0x1312d0>; }; };

Linux 6.6.27 is not stable on my system - with or without the modifications (hs400 speed and cache awareness). I will switch back to 6.6.8 now. # kernel oops 2024-04-17T20:45:02.182350+02:00 helios64 kernel: [20582.266022] Unable to handle kernel paging request at virtual address ffff800481075118 2024-04-17T20:45:02.182405+02:00 helios64 kernel: [20582.266042] Mem abort info: 2024-04-17T20:45:02.182409+02:00 helios64 kernel: [20582.266047] ESR = 0x0000000086000005 2024-04-17T20:45:02.182413+02:00 helios64 kernel: [20582.266053] EC = 0x21: IABT (current EL), IL = 32 bits 2024-04-17T20:45:02.182416+02:00 helios64 kernel: [20582.266062] SET = 0, FnV = 0 2024-04-17T20:45:02.182421+02:00 helios64 kernel: [20582.266068] EA = 0, S1PTW = 0 2024-04-17T20:45:02.182424+02:00 helios64 kernel: [20582.266073] FSC = 0x05: level 1 translation fault 2024-04-17T20:45:02.182428+02:00 helios64 kernel: [20582.266080] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000037b7000 2024-04-17T20:45:02.182432+02:00 helios64 kernel: [20582.266088] [ffff800481075118] pgd=10000000f7fff003, p4d=10000000f7fff003, pud=0000000000000000 2024-04-17T20:45:02.182436+02:00 helios64 kernel: [20582.266111] Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP 2024-04-17T20:45:02.182440+02:00 helios64 kernel: [20582.266686] Modules linked in: xt_comment xt_tcpudp nft_compat nf_tables nfnetlink eq3_char_loop(O) rpi_rf_mod_led(O) dummy_rx8130(O) hb_rf_eth(O) generic_raw_uart(O) sunrpc lz4hc lz4 zram binfmt_misc cp210x us> 2024-04-17T20:45:02.182445+02:00 helios64 kernel: [20582.273976] CPU: 5 PID: 13764 Comm: kworker/5:2 Tainted: G C O 6.6.27-current-rockchip64 #2 2024-04-17T20:45:02.182450+02:00 helios64 kernel: [20582.274829] Hardware name: Helios64 (DT) 2024-04-17T20:45:02.182453+02:00 helios64 kernel: [20582.275191] Workqueue: events dbs_work_handler 2024-04-17T20:45:02.182457+02:00 helios64 kernel: [20582.275626] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) 2024-04-17T20:45:02.182461+02:00 helios64 kernel: [20582.276247] pc : 0xffff800481075118 2024-04-17T20:45:02.182464+02:00 helios64 kernel: [20582.276567] lr : 0xffff800481075118 2024-04-17T20:45:02.182467+02:00 helios64 kernel: [20582.276882] sp : ffff800088b23530 2024-04-17T20:45:02.182472+02:00 helios64 kernel: [20582.277182] x29: ffff800088b23530 x28: ffff800081c4d090 x27: ffff0000040a8080 2024-04-17T20:45:02.182499+02:00 helios64 kernel: [20582.277830] x26: 000000003b9aca00 x25: ffff0000040a84f8 x24: 0000000000000000 2024-04-17T20:45:02.182503+02:00 helios64 kernel: [20582.278474] x23: ffff800081a47000 x22: ffff8000816f8008 x21: ffff800088b23578 2024-04-17T20:45:02.182507+02:00 helios64 kernel: [20582.279118] x20: 00000000000000fa x19: 00000001004d6073 x18: 0000000000000000 2024-04-17T20:45:02.182510+02:00 helios64 kernel: [20582.279762] x17: 000000040044ffff x16: 00100074b5503510 x15: 0000000000000000 2024-04-17T20:45:02.182513+02:00 helios64 kernel: [20582.280404] x14: 00000000000000c9 x13: 0000000000000002 x12: 0000000000000000 2024-04-17T20:45:02.182516+02:00 helios64 kernel: [20582.281048] x11: 0000000000000400 x10: 0000000000000a90 x9 : ffff800088b23450 2024-04-17T20:45:02.182520+02:00 helios64 kernel: [20582.281691] x8 : ffff000006da46f0 x7 : 0000000000000000 x6 : 0000000000000070 2024-04-17T20:45:02.182523+02:00 helios64 kernel: [20582.282333] x5 : 00000000410fd080 x4 : 0000000000f0000f x3 : 0000000000000002 2024-04-17T20:45:02.182527+02:00 helios64 kernel: [20582.282976] x2 : 0000000000000000 x1 : ffff000006da3c00 x0 : 00000000124a8be7 2024-04-17T20:45:02.182530+02:00 helios64 kernel: [20582.283621] Call trace: 2024-04-17T20:45:02.182533+02:00 helios64 kernel: [20582.283846] 0xffff800481075118 2024-04-17T20:45:02.182536+02:00 helios64 kernel: [20582.284136] rk3x_i2c_xfer_common.isra.0+0x32c/0x438 2024-04-17T20:45:02.182539+02:00 helios64 kernel: [20582.284589] rk3x_i2c_xfer+0x18/0x24 2024-04-17T20:45:02.182543+02:00 helios64 kernel: [20582.284917] __i2c_transfer+0x1ec/0x80c 2024-04-17T20:45:02.182546+02:00 helios64 kernel: [20582.285269] i2c_transfer+0x60/0x128 2024-04-17T20:45:02.182549+02:00 helios64 kernel: [20582.285598] i2c_transfer_buffer_flags+0x5c/0x90 2024-04-17T20:45:02.182552+02:00 helios64 kernel: [20582.286017] regmap_i2c_write+0x20/0x58 2024-04-17T20:45:02.182556+02:00 helios64 kernel: [20582.286370] _regmap_raw_write_impl+0x7ac/0x8f8 2024-04-17T20:45:02.182559+02:00 helios64 kernel: [20582.286778] _regmap_bus_raw_write+0x60/0x7c 2024-04-17T20:45:02.182563+02:00 helios64 kernel: [20582.287163] _regmap_write+0x60/0x188 2024-04-17T20:45:02.182567+02:00 helios64 kernel: [20582.287496] _regmap_update_bits+0x114/0x134 2024-04-17T20:45:02.182570+02:00 helios64 kernel: [20582.287881] regmap_update_bits_base+0x64/0x98 2024-04-17T20:45:02.182573+02:00 helios64 kernel: [20582.288282] regulator_set_voltage_sel_regmap+0x50/0x9c 2024-04-17T20:45:02.182577+02:00 helios64 kernel: [20582.288759] _regulator_call_set_voltage_sel+0x74/0xc8 2024-04-17T20:45:02.182580+02:00 helios64 kernel: [20582.289224] _regulator_do_set_voltage+0x47c/0x58c 2024-04-17T20:45:02.182584+02:00 helios64 kernel: [20582.289660] regulator_set_voltage_rdev+0x64/0x258 2024-04-17T20:45:02.182586+02:00 helios64 kernel: [20582.290096] regulator_do_balance_voltage+0x1f4/0x428 2024-04-17T20:45:02.182590+02:00 helios64 kernel: [20582.290553] regulator_balance_voltage+0x50/0x9c 2024-04-17T20:45:02.182593+02:00 helios64 kernel: [20582.290974] regulator_set_voltage_unlocked+0xa8/0x12c 2024-04-17T20:45:02.182597+02:00 helios64 kernel: [20582.291438] regulator_set_voltage+0x50/0x98 2024-04-17T20:45:02.182600+02:00 helios64 kernel: [20582.291828] _opp_config_regulator_single+0x50/0x19c 2024-04-17T20:45:02.182603+02:00 helios64 kernel: [20582.292281] _set_opp+0xd8/0x4bc 2024-04-17T20:45:02.182607+02:00 helios64 kernel: [20582.292577] dev_pm_opp_set_rate+0x18c/0x280 2024-04-17T20:45:02.182610+02:00 helios64 kernel: [20582.292963] set_target+0x30/0x3c [cpufreq_dt] 2024-04-17T20:45:02.182613+02:00 helios64 kernel: [20582.293377] __cpufreq_driver_target+0x1d0/0x344 2024-04-17T20:45:02.182616+02:00 helios64 kernel: [20582.293797] od_dbs_update+0xbc/0x1ac 2024-04-17T20:45:02.182620+02:00 helios64 kernel: [20582.294133] dbs_work_handler+0x40/0x7c 2024-04-17T20:45:02.182623+02:00 helios64 kernel: [20582.294486] process_one_work+0x160/0x3a8 2024-04-17T20:45:02.182626+02:00 helios64 kernel: [20582.294854] worker_thread+0x32c/0x438 2024-04-17T20:45:02.182630+02:00 helios64 kernel: [20582.295197] kthread+0x114/0x118 2024-04-17T20:45:02.182633+02:00 helios64 kernel: [20582.295494] ret_from_fork+0x10/0x20 2024-04-17T20:45:02.182636+02:00 helios64 kernel: [20582.295835] Code: ???????? ???????? ???????? ???????? (????????) 2024-04-17T20:45:02.182640+02:00 helios64 kernel: [20582.296383] ---[ end trace 0000000000000000 ]---

A first test with linux 6.6.27 (downloaded from beta.armbian.com) was successful on my system too - even with the modifications (hs400 speed and cache awareness). (here is a link to the linux-6.6.27 debs downloaded today; I also attached modified dtbs for some kernel versions) dtbs.zip

I am using the standard settings - no need to reduce the frequency of the fast cores. Anything related to OMV should go to another thread ! # cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

This is all explained in detail in the message linked next to the recommended u-boot version.

Just flash the bootloader again to emmc. Double check that the UUIDs in /etc/fstab and in /boot/armbianEnv are correct. And double check that all your log files are present on emmc (otherwise rsync them manually): some apps do not recreate them once installed. If you helios64 is still not running smoothly, reinstall 6.6.8 on emmc, or alternatively 6.1.71, or 5.15.93.

I replaced the link to linux-u-boot-edge and to the rtl_nic firmware.