BipBip1981

Hi, For feedback, i disconnect from SATA connector by unrack/rack harddisk and i disconnect and reconnect plug on mainboard side. Have a good day.

Hi, few days ago, i disconnect and reconnect all connectors on ATA1 line, it's seem to become Okok 😉

Hi, I swap ata1 and ata5, problem stay on ata1, i look cable and socket on ata1 Keep in touch

Hi everybody, For information Prahal dtb patch file is not for me the problem because my problem is only on ata1 after cold boot, never after reboot command. I think hardware problem like harddisk, cables or mainboard... i continu to search. Have good day

Hi, Same with 28.11-trunk build myself and 6.6.56 kernel Below grep SATA and grep ata: root@helios64:~# dmesg | grep SATA [ 3.137429] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode [ 3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) root@helios64:~# dmesg | grep ata [ 0.000000] Memory: 3787452K/4061184K available (16960K kernel code, 2318K rwdata, 5248K rodata, 4736K init, 604K bss, 142660K reserved, 131072K cma-reserved) [ 0.018184] CPU features: detected: ARM errata 1165522, 1319367, or 1530923 [ 0.719520] libata version 3.00 loaded. [ 3.151033] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.151704] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.152392] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.153059] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.153722] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 3.163337] dwmmc_rockchip fe320000.mmc: DW MMC controller at irq 82,32 bit host data width,256 deep fifo [ 8.508139] ata1: link is slow to respond, please be patient (ready=-19) [ 10.588155] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 10.610022] ata1.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133 [ 10.620898] ata1.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 10.624658] ata1.00: Features: NCQ-sndrcv NCQ-prio [ 10.639786] ata1.00: configured for UDMA/133 [ 11.116112] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.117876] ata2.00: ATA-9: WDC WD80EFAX-68KNBN0, 81.00A81, max UDMA/133 [ 11.128615] ata2.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 11.132356] ata2.00: Features: NCQ-sndrcv NCQ-prio [ 11.148021] ata2.00: configured for UDMA/133 [ 11.628156] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.630146] ata3.00: ATA-9: TS256GSSD370S, O1225G, max UDMA/133 [ 11.630849] ata3.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 32), AA [ 11.632376] ata3.00: Features: Dev-Sleep [ 11.635170] ata3.00: configured for UDMA/133 [ 12.116158] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.118227] ata4.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133 [ 12.128937] ata4.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 12.132823] ata4.00: Features: NCQ-sndrcv NCQ-prio [ 12.148357] ata4.00: configured for UDMA/133 [ 12.624185] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.626073] ata5.00: ATA-9: WDC WD80EFBX-68AZZN0, 85.00A85, max UDMA/133 [ 12.636772] ata5.00: 15628053168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 12.640617] ata5.00: Features: NCQ-sndrcv NCQ-prio [ 12.656091] ata5.00: configured for UDMA/133 [ 52.828386] EXT4-fs (dm-1): mounted filesystem 58534626-3f89-40db-9b0e-9519a2805962 ro with writeback data mode. Quota mode: none. [ 56.637970] EXT4-fs (mmcblk0p1): mounted filesystem ba516afd-4114-4179-8bcf-3d0f63b058fe r/w with ordered data mode. Quota mode: none. [ 64.262140] EXT4-fs (dm-2): mounted filesystem cc702057-ff5f-4b6f-ad29-4f5d5d96216e r/w with ordered data mode. Quota mode: none. [ 64.341677] systemd[1]: Starting plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data... [ 64.358217] systemd[1]: Finished plymouth-read-write.service - Tell Plymouth To Write Out Runtime Data. [ 66.316142] systemd-journald[1673]: Data hash table of /var/log/journal/21a29cba476e44048a808d9a655190f3/system.journal has a fill level at 88.2 (4015 of 4551 items, 2621440 file size, 652 bytes per hash table item), suggesting rotation.

Hi evevrybody, Since few days i note a problem with SATA on my Helios64. Only on a cold boot, SATA speed isn't to 6.0Gbps randomly on SATA disk, after reboot command, all it's good at 6.0Gbps root@helios64:~# dmesg | grep SATA [ 3.169958] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode [ 3.183007] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.183681] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.184378] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.185046] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.185710] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 10.440028] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 10.976033] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.480029] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.963976] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.472056] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) After reboot command: root@helios64:~# dmesg | grep SATA [ 3.151099] ahci 0000:01:00.0: AHCI 0001.0301 32 slots 5 ports 6 Gbps 0x1f impl SATA mode [ 3.164109] ata1: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010100 irq 74 [ 3.164781] ata2: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010180 irq 75 [ 3.165448] ata3: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010200 irq 76 [ 3.166114] ata4: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010280 irq 77 [ 3.166778] ata5: SATA max UDMA/133 abar m8192@0xfa010000 port 0xfa010300 irq 78 [ 10.000101] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 10.524107] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.036103] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 11.520039] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 12.024104] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300) I upgrade to 24.11 trunk build myself with framework and tune with Prahal dtb file and 6.6.56 kernel. Keep in touch. Bye

I hope all fixes and hacks will be include soon because the result is amazing to my side 😉 Welcome to Armbian-unofficial 24.5.3 Bookworm with Linux 6.6.32-current-rockchip64 System load: 16% Up time: 91 days 5:31

Hi, Today i upgrade to 24.5.3 when apt full-upgrade proposed me to upgrade and return of crash 😞 Tuned rk3399-kobol-helios64.dtb L2 hs400 file seen to be update... i copy paste file used with 6.6.32... I replace rk3399-kobol-helios64.dtb.org (with 24.5.3) with my rk3399-kobol-helios64.dtb post in this forum sha256sum: e90ebceb4b2f213818f320dfc61c90e556e0470702afa4117b0302bffc3d2cce rk3399-kobol-helios64.dtb sha256sum: 0eb03b645ab8125a4460d4509df32050188a8bdf2b5065f4321748b4eb6f6b4d rk3399-kobol-helios64.dtb.org It's seem to be not crash now... Keep in touch. UPDATE: i confirm, after update to 24.5.3, copy rk3399-kobol-helios64.dtb with L2 and hs400 in place of rk3399-kobol-helios64.dtb original is mandatory UPDATE 2: Same if you build with framwork last 24.8 version, you need to remplace: sha256sum: 0eb03b645ab8125a4460d4509df32050188a8bdf2b5065f4321748b4eb6f6b4d rk3399-kobol-helios64.dtb with sha256sum: e90ebceb4b2f213818f320dfc61c90e556e0470702afa4117b0302bffc3d2cce rk3399-kobol-helios64.dtb-6.6.30-L2-hs400-opp rename to rk3399-kobol-helios64.dtb

Hi, I had this problem in past, you may try to unrack and rack hardisk or move it if you not use all rack. Problem to my side was bad contact in SATA connector. Bye

Hi, i use on my own build from scratch with framework official Armbian 24.05 with kernel 6.6.30 and DTB file send by ebin-dev here with 408-1800mhz ondemand governor and for the first time since I have it, it is stable and usable with my case of uses and it pass my pattern stability test ! Many thanks to ebin-dev for the great work.

Hi, Thank for your files and informations. To my side i don't use 2.5G interface because i don't have router 2.5G (and i don't do this tune: https://blog.kobol.io/2020/11/13/helios64-2-5g-ethernet-issue/ ). For moment, no problem with armbian-hardware-monitor.service enable, i stay with this setting, if one day armbian version will be change to use your workaround upper, i use it. I keep my 6.6.29 build and i build 6.6.30 for futur Keep in touch

Hi, On post below i report i have a stable helios64 with ebin-dev's file dtb for 6.6.29 with ondemand 408-1800mhz Whereis a post explain how dtb file change for understand how that work? You speak about end of cpufreq, armbian-hardware-optimize.service, irq smp_affinity, xhci and ahci... anyone have enough knowlege to explain this change ? It's specific for helios64 support or that will be include on futur armbian for every boards/versions ?

Hi, uptime more 5 days with my pattern test and ebin-dev's file for voltage change, not crash. now i use helios64 on normal condition to see if better than before for information my pattern test never pass before today on my helios64 with ondemand gov and 408-1800 freqs since i have it Keep in touch root@helios64:~# uptime 10:06:08 up 5 days, 40 min, 2 users, load average: 1.94, 2.49, 2.65 root@helios64:~# uname -a Linux helios64 6.6.29-current-rockchip64 #1 SMP PREEMPT Sat Apr 27 15:11:44 UTC 2024 aarch64 GNU/Linux helios64@helios64:~$ cat /etc/fancontrol # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu #INTERVAL=10 INTERVAL=30 FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 #MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MAXTEMP=/dev/fan-p6/pwm1=50 /dev/fan-p7/pwm1=50 #MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTART=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 #MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINSTOP=/dev/fan-p6/pwm1=20 /dev/fan-p7/pwm1=20 MINPWM=20 root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=ondemand

Hi, we speak same problem to link below. Read last 2-3 pages . Keep in touch

Hi, Not crash for moment with my patern test after 2days in 400-1800 schedutil. I pass on fly to 400-1800 ondemand and restart cpufrequtils.service, no crash. I program 2 anothers pattern test after the end of this first that start 2 days ago with schedutil gov and finish with ondemand gov. Result for GOVERNOR=ondemand 408-1800 Monday Keep in touch