ebin-dev

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.

Did you check that the recommended bootloader is flashed to emmc ? And that the rtl_nic firmware is updated ? Did you start from the Armbian Image with kernel 6.1.36 ?

The old files can of course be deleted in / , /boot , /usr/src , and in /lib/modules .

Depending on your use case try kernel 6.6.8, 6.1.71, and 5.15.93 (download links are provided here). Armbian built kernels 6.6.x (x>8) are all unstable.

The uuids containing 'a6be' refer to the 'to device', the ones containing '91ac' refer to the 'from device'.

I am using the following script to transfer a system to another volume (in this case the running system to emmc) (UUIDs to be adapted to your case (sed -e 's/UUID=<from device>/UUID=<to device>/g' -i /mnt/emmc/etc/fstab) #!/bin/bash # Check if user is root if [ $(id -u) != "0" ]; then echo "Error: You must be root to run this script." exit 1 fi cat > install-exclude <<EOF /dev/* /proc/* /sys/* /run/* # /tmp/* # /root/* EOF exec 2>/dev/null umount /mnt/emmc exec 2>&1 mount --uuid 7268e76f-3e1b-4e01-a6be-987654321098 /mnt/emmc rsync -avxSE --delete --exclude-from="install-exclude" / /mnt/emmc # change fstab sed -e 's/UUID=b790c4d7-5709-4000-91ac-123456789012/UUID=7268e76f-3e1b-4e01-a6be-987654321098/g' -i /mnt/emmc/etc/fstab sed -e 's/UUID=b790c4d7-5709-4000-91ac-123456789012/UUID=7268e76f-3e1b-4e01-a6be-987654321098/g' -i /mnt/emmc/boot/armbianEnv.txt umount /mnt/emmc rm install-exclude echo "All done." On top of that you may wish to manually rsync /var/log and /var/log.hdd to the other device. The segmentation fault is probably caused by the wrong bootloader on emmc. Armbian tools might overwrite it. So install again the recommended bootloader to emmc. Good luck.

I observed the same issues you describe (freezing shortly after the first script is manually started) and I would like to understand why it seems to be stable after your third attempt. Could you post the messages output during boot ? Does it start with 'DDR Version 1.25 20210517' ?

Did you test that image ? None of the Armbian built 6.6.x (x >8) kernels (downloadable on beta.armbian.com) are stable on my system. They all seem to have the same issue.

NFS is known to cause problems with kernel 6.6.8. It would probably be wise to switch to 6.1.71 or 5.15.93 in your case.

You can try to upgrade from buster to bullseye. Unfortunately your mileage may vary. It may or may not work depending on circumstances. This is why Armbian moderators always post messages like "user space upgrades are not supported" ...

Why don't you flash linux-u-boot-edge-helios64_22.02.1_arm64 to both devices mmcblk0 and mmcblk1 and perform the python3 check after a cold start ? # messages output to the terminal while booting DDR Version 1.25 20210517 In soft reset SRX channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 ...

Are you sure that you have flashed linux-u-boot-edge-helios64_22.02.1_arm64 (it contains the rockchip ddr blob) to emmc and not accidentally to sd ? emmc may be accessed as either /dev/mmcblk1p1 or as /dev/mmcblk0p1. If you started your system from emmc 'df -h' is your friend. So obviously the path has to be adapted accordingly for flashing u-boot to that device: either 'of=/dev/mmcblk1' or 'of=/dev/mmcblk0'.

Armbian bullseye images can be downloaded from the archive. And if you are having issues with OMV7 you should open another thread.

OMV 7 is not finished yet - there is just a release candidate available. You could switch to kernel 5.15.93 again but it will not resolve OMV application issues.

I did not test the procedure with more recent images. It would be very helpful if you could start from the 6.1.63 image and test it as it is (with rtl_nic firmware updated). In case of stability issues, change u-boot to the version recommended. If you are still having issues with linux 6.1.63 try linux 6.6.8, 6.1.71, or 5.15.93 instead and follow the procedure described - and please post your observations here in this thread.

I tried armbian built 6.7.4 without any modifications but it crashes almost immediately on my system. Even without hs400. The netdev watchdog message looks like the timeout caused by the mainline r8152 driver. Have never seen those events occurring before 'cut here'.

May be it is not a fault but an upstream change that leads to issues with hs400 again ? Good to hear that 6.7.x is quite stable. The remaining issue (short timeout) with the mainline r8152 driver can be reduced (eliminated) if other huge tasks do not have to compete with it. You could use taskset to assign other huge tasks to cpu5 and leave cpu4 to handle i/o.