Jump to content

ebin-dev

Members
  • Posts

    374
  • Joined

  • Last visited

Everything posted by ebin-dev

  1. 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 ?
  2. The old files can of course be deleted in / , /boot , /usr/src , and in /lib/modules .
  3. 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.
  4. The uuids containing 'a6be' refer to the 'to device', the ones containing '91ac' refer to the 'from device'.
  5. 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.
  6. 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' ?
  7. 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.
  8. 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.
  9. 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" ...
  10. 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 ...
  11. 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'.
  12. Armbian bullseye images can be downloaded from the archive. And if you are having issues with OMV7 you should open another thread.
  13. 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.
  14. 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.
  15. 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'.
  16. 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.
  17. I copied the 6.7.2 deb files yesterday (trunk-480) and will test them once I am back home next week. 6.1.71 or 5.15.93 should be fine. You could also try 6.7.2 🙂
  18. The 6.6.8 debs were downloaded from an Armbian mirror and are not modified. Everything you need is explained here: in particular that NFS causes trouble with 6.6.x kernels and that 6.1.71 should be used instead or 5.15.93. To implement hs400 and L2 cache information you can use 'dtc'. For your convenience I attached the dtb for 6.6.8 and 5.15.93 (just copy the matching one to /boot/dtb/rockchip/rk3399-kobol-helios64.dtb). It is essential to flash the bootloader to emmc after you have installed the kernel debs, to perform a cold boot and to run 'sbc-bench -r' at least once. rk3399-kobol-helios64.dtb-5.15.93-L2-hs400 rk3399-kobol-helios64.dtb-6.6.8-L2-hs400
  19. Newer kernel versions of the 6.6 branch (6.6.9 to 6.6.12) would not appear to run stable anymore on helios64 (6.6.8 is stable - using the ondemand governor in my use case). In kernel versions 6.6.9 to 6.6.12 energy aware scheduling (EAS) is disabled automatically - it can now only be used combination with the schedutil governor. But using schedutil is currently not a good option.
  20. Bumping rockchip64 current to linux 6.6 (and edge to 6.7) is actually good news. But I do not think that this explains why the entire beta/pool/main folder disappeared from a mirror (but it does not matter). If nothing else is changed (keep fingers crossed), then the new Armbian built rockchip64 6.6.x and 6.7.y kernels should appear i.e. on imola.armbian.com/beta/pool/main/l/ and reappear on the mirrors.
  21. Just to let you know: the directory 'beta/pool/main/l/linux-6.6.8/' has vanished over night (actually the entire folder fi.mirror.armbian.de/beta/pool/main). This was the location we used for downloading linux 6.6.x (6.1.y etc.) (kernel, dtb and headers). My link to the linux 6.6.8 files in this forum (as downloaded on 23.12.2023) remains active - also added links to linux 6.1.71 and 5.15.93 (dropbox).
  22. @prahal So I used the opportunity to fix the settings for the 1G interface in armbian-hardware-optimization: My /etc/armbian-release states BOARDFAMILY=rk3399, Branch=current and I therefore edited the lines starting at line 251 - and that was successful. But I do not know if there is any positive effect on the 1G interface, since I am using 2.5G only. (I will go through the settings in /sys/class/net/end1 and see if something can be tuned for the 2.5G interface.) # cat /etc/armbian-release BOARD=helios64 BOARD_NAME="Helios64" BOARDFAMILY=rk3399 ... BRANCH=current #cat /usr/lib/armbian/armbian-hardware-optimization lines 251 ff: echo 8 > /proc/irq/$(awk -F":" "/end0/ {print \$1}" < /proc/interrupts | sed 's/\ //g')/smp_affinity echo 7 > /sys/class/net/end0/queues/rx-0/rps_cpus echo 32768 > /proc/sys/net/core/rps_sock_flow_entries echo 32768 > /sys/class/net/end0/queues/rx-0/rps_flow_cnt # systemctl status armbian-hardware-optimize.service ● armbian-hardware-optimize.service - Armbian hardware optimization Loaded: loaded (/lib/systemd/system/armbian-hardware-optimize.service; enabled; preset: enabled) Active: active (exited) since Fri 2024-01-12 15:49:01 CET; 33min ago Process: 700 ExecStart=/usr/lib/armbian/armbian-hardware-optimization start (code=exited, status=0/SUCCESS) Main PID: 700 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4374) Memory: 2.1M CPU: 795ms CGroup: /system.slice/armbian-hardware-optimize.service I do not know if the following information is correct: # dpkg -l armbian-bsp-cli-helios64-* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-================================-=========================================-============-===================================================== hi armbian-bsp-cli-helios64-current 23.08.0-trunk--1-PCc73b-Vccab-H1d04-B9c45 arm64 Armbian CLI BSP for board 'helios64' branch 'current'
  23. That is true - in that script eth0 should be replaced by end0 if you wish to apply the Armbian optimisation to the 1G interface. The interrupt for xhci-hcd:usb1 devices is 46 and smb affinity is set to 10 (cpu4) on my system (used by the 2.5G interface): # cat /proc/irq/46/smp_affinity 10 # cat /proc/interrupts | grep xhci 46: 1481 0 261 0 998993 0 GICv3 142 Level xhci-hcd:usb1 93: 0 0 0 0 0 0 GICv3 137 Level dwc3-otg, xhci-hcd:usb5 CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
  24. @prahal There are many values to choose from between 1000 and 40000 (regulator-ramp-delay). Why don't you try 2000, 4000, 10000, 20000 ? (It might solve your problem)
  25. The purpose of the 'armbian-hardware-optimization' is to bind the heavy tasks to one or both big core(s), since the little ones would not be capable of dealing with them. For some heavy tasks the kernel may need more than one big core. So I think this would make sense. Cryptosetup on a raid 5 with 5 spinning disks is definitely a huge load. Dealing with the ethernet traffic on the 2.5G interface is also a heavy load: 280Mbyts/s have to be handled in pieces of 1500bytes (MTU) - simultaneously in both directions. So it might make some sense if you modify the optimization settings depending on your use case.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines