BipBip1981

Hi, to my side same: root@helios64:~# cat /var/log/syslog | grep mdadm root@helios64:~# and, for moment not crash/freeze to my helios64...

Hi, This morning, i do cold boot and crash after few minutes (less than 10min...) Boot is okok but lose ssh connection and to same with usb wire console, i have login and password ask but then i am block... (i can't find if problem hardware... systemd... software...) I use reset bottom and after 15min uptime, i try the same and not lose connection, (i don't understand why not lose connection, i do nothing and Helios64 seem Okok...) i do: (3 times) root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# ./cpufreq-switching allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 root@helios64:/tmp# Not crash/freeze and during this test, i have samba Time Machine backup work and lot of I/O Network and 1GO of data pass from my mac to helios. I don't tune voltage, juste use 6.6.28 Kernel and my standard configuaration.... I run again you program and, i have again Time Machine Backup (samba share in background): | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian-unofficial 24.5.0-trunk Bookworm with Linux 6.6.28-current-rockchip64 No end-user support: built from trunk System load: 86% Up time: 27 min Local users: 2 Memory usage: 11% of 3.77G IP: 10.0.0.155 CPU temp: 41°C Usage of /: 47% of 14G RX today: 1.5 GiB [ General system configuration (beta): armbian-config ] Web console: https://helios64:9090/ You have no mail. helios64@helios64:~$ su - Mot de passe : root@helios64:~# cd /tmp/ root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:34:39 up 28 min, 3 users, load average: 5.87, 4.75, 3.61 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:36:12 up 29 min, 3 users, load average: 4.99, 4.71, 3.70 root@helios64:/tmp# No Problem, To conclude for moment, to my side; 6.6.28 stable but not at cold boot... stable after. Something (hardware or software) when cold boot crash or do bug in linux software... and after reset buttom is Okok... It's crazy i know ! (Possible problem in cold ramlog boot is /var/log full... i view is full just now... i will investigate next week...) If you want next week, i build a Vanilla armbian from source with official framework and run your cpufreq-switching on it, i think i will have same this day with my standard configuration but maybe not with crash at cold boot If you read my history message about Helios64 since about 3 years... it never stable with standard parameter. I do many tests and to change Kernel and this day the Best Kernel i never use is 6.6.27 and upper because not crash at standard frequency Schedutil Governor The very bad Kernel was 6.X branch, with thing kernel, Helios crash often just when i unlock my raid10 with LUKS cryptosetup And le 5.15.(something)69 or just before was the best stable Kernel with 400-1400Mhz schelutil (i speak about this in very old post) I try again you program, Time Machine Backup is finish... root@helios64:/tmp# uptime ; ./cpufreq-switching ; uptime 06:51:25 up 44 min, 3 users, load average: 3.98, 4.58, 4.24 allocated 64MB test: toggle freq before write 99/100 test: toggle freq before read 9/10, 99/100 06:53:01 up 46 min, 3 users, load average: 3.03, 4.09, 4.10 root@helios64:/tmp# Not crash, now i go to work office and then pass a weekend with my familly, keep in touch next week During this weekend, i run on my helios64 a script do in loop: echo check > /sys/block/md0/md/sync_action and: btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-XXXXXXXXXXXXXX If Monday morning when i back my Helios64 not crash/freeze, for me 6.6.28 is good Kernel. Have a good day

Hi, Not change millivolt value because i afraid to do a mistake I just setting differentes values of freq For moment i am at 400-1200Mhz and not lose connection... Can you explain me command to change milivolt setting if i have futur courage or crazy spirit to try this idea? And i have question, i install my 6.6.27 Kernel .deb build my self with official framework, then i reboot and do my pattern 3 times without crash... Today i reboot and lose connection approximately 10min after boot when i set upper than 1400mhz... milivolt value work before reboot why not after, setting not change? Now i do: git clone --depth=1 --branch=main https://github.com/armbian/build ; cd build/ ./compile.sh kernel BOARD=helios64 BRANCH=current dpkg -i *.deb to install Kernel 6.6.28 4 packages reboot and... uptime 18min... not loose connection ! i become crazy !

....Grrrr I reboot... and now i lose network connection random time (approximately 6-10min) after full boot... and i lose access by USB wire to console... return in unstable world... I become CRAZY ! Back to 400-1200Mhz max schedutil, if lose connection... back to 1200 1200 Performance (equal to fix freq 1200)

Hi, My command: To scrub RAID10: echo check > /sys/block/md0/md/sync_action At same time i check BTRFS with: btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-XXXXXXXXXXXXX At at same time i do copy/delete/copy random from personnal computer to helios64 samba share one pass finished after about 36h... i run pass 3 times For information, i use LUKS overs my raid10 My fancontrol file is: root@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 and i install: Full Firmware deb package to remove error with 2,5G ethernet driver I do extend swap by swapfile to 6Go and i run 2 containers with podman, Plex and SFTPGO

Hi, My test parttern run and i do: helios64@helios64:~$ for i in $(seq 1 100);do python3 -c "import pkg_resources" || break;done helios64@helios64:~$ No crash to my side 😉 I never had until today my helios64 stable with 400-1800MHZ stable with my pattern test and podman container run. I think i am dreaming.... yes? not? Helios64 stable is AMAZING !!!!!

Hi everybody, I test 24.05 trunk build myself armbian bookworm with 6.6.27 Kernel and... For moment, i have a stable Helios64 with 400-1800Mhz schedutil and just my tuned fancontrol file. Running for more than 1 days without crash with my test pattern... and not crash/freeze until now !!!!!! I hope not crash during next few days... If not crash, i advise everybody to swith to this kernel Keep in touch

Hello, Yes i set fixed frequency to 1200. For power consumption, i my case off use it's not a problem because i start when use it and stop helios64 when i don't use. My big problem isn't unstability during long time but during intense use. For example: 400Mhz - 1400mhz is okok if helios do nothing... but when fast i/O network or Disk I/O, Helios64 crash or freeze. With 5.1X Kernel, Helios is stable at 400-1400MHZ Schedutil With first 6.X Kernel, Helios is stable at 400-14000MHZ Schedutil With 6.6 Kernel and upper my pattern to test stabilty crash when i use setting above and not crash with 1200 Fixed frequency. At 1400 or more with my pattern to test Helios crash. My configuration is: 8To x 4 Raid 10 -> LVM -> Lucks -> LVM -> BTRFS. To test stabilty i do: - Scrubbing RAID and at same time i do a BTRFS with Checksum check, that do a lot of I/O and Frequency change... Since i pass to Kernel 6.6.X, this pattern to test fail always. With 5.1X Kernel 400-1400MHZ Schedutil and 6.X Kernel 400-14000MHZ Schedutil and at 1200 Fixed, always pass and always crash at 400-1200MHZ. I advise you if you want stable online setting to Keep a 5.1X Kernel with 400-1400MHz. That not my choice because i prefer to follow most update Kernel and i believe (or dreaming) adevelloper find problem with Helios RockChip and correct it one day.

Hello, Try: 1200MHZ 1200MHZ Performance The only stable settings for me since passed to 6.6.X Kernel with Armbian Bookworm

hi, okok, from my side kernel 6.6.12 1200MHz Performance, i do podman run hello-world, no problem and my helios run from 2 days with my freeze test pattern and not freeze for moment. good night or day

okok keep in touch, i am interesting by your feedback.

Hi, try: 1200mhz min freq 1200mhz max freq governor performance in armbian-config program. The best stable configuration in my helios64

Hi, My return, best result and best stabilty is this setting: 1200Mhz max performance with upper frequency random crash... some time just when reconnect to network (ex: restart my router, many samba access) or launch docker container... or just unlock drive with cryptosetup... or during "btrfs check" Have a good day

Hi, It's running with Armbian Brookworm build by me with official script. Two different crash arrive, one with fault led red system flashing, second with all blue led are fix, lost network and lost console access with usb-c cable. In log, they are nothing important, crash append but i not found information in log (My log isn't in ramlog, i disable this shit feature...). I have 4 8TO raid 10 with BTRFS over Luks, i reproduce crash by run btrfs check file system with checksum and mdadm check raid at same time. My brother have helios64 and he crash his Helios simply crash on waiting with docker container active and do nothing and without any HD drive with all last official Kobol Armbian build or with my own build. I will test next week with this image system (https://dl.slarm64.org/slackware/images/helios64/) simply to know if armbian specific problem or hardware problem. Have a good day.

Hi, Game Over for me... again... crash with CPU @400-1200MHz with "on demand" Governor Kernel... in less than 24h... I retry same test with "schedutil" and the last main build by me... I not hope many thing... Return next week Bye

Hi, not crash again 😞 i try step by step "configuration crash" (btrfs check my file system and mdadm check raid at same time, 2 days by pass) with my custom fancontrol file and step by step up cpu frequency with performance governor to not use auto scale frequency. For moment, it stable at 1000mhz, i start a minimum 7 days ago Keep in touch result Bye.

Hi, I use Helios64 from the begin and this board is very unstable according to my experience and many posts here... After many dialogue here and settings shared about Frequency and Governor Kernel... maybe i find the problem and i ask anyone return of experiences about the procedure and setting belong: - Connect USB Wireless Dongle or USB(-c) Ethernet Plug - Configure it - Disconnect all ethernet cable to the board - Use with last time crash configuration and do a endurance test your helios64 board Have a good day

Hi, Today i make upgrade to 23.11 armbian on my Helios64. It's in bookworm version (apt source list is good, no change since 23.08) but now it display this: Welcome to Armbian 23.11.1 Buster with Linux 6.1.63-current-rockchip64 No end-user support: community creations & unsupported (buster) userspace! it's a bug? thank have a nice day

I have a helios64, but i'm not dev and i can't make a patch. I only can test on Helios64 if all work good after à full compile with a patch.

Hi, @balbes150: explain how you can fix it and i test to build with your fix then i test on my helios64

Hi, To my side, i have a stable system: bulleye trunk build from source with armbian-dev-tools with 5.15.26 Kernel and 400MHZ-1400MHZ schedutil. Have a good day.

Hi, Thks for your patch, i think it's more "clean" than my "Kiss workaround" Have a good day

Hello, yes, -> Welcome to Armbian 21.08.6 Hirsute with bleeding edge Linux 5.15.5-rockchip64

Hello, My workaround or patch, maybe it bad, sad or unclear but it's KISS and seem to work ! Bye root@helios64:~# cat /etc/fancontrol # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 #FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input FCTEMPS=/dev/fan-p6/pwm1=/sys/class/thermal/thermal_zone0/temp /dev/fan-p7/pwm1=/sys/class/thermal/thermal_zone0/temp MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=20

Hello, My workaround or patch, maybe it bad, sad or unclear but it's KISS and seem to work ! Bye root@helios64:~# cat /etc/fancontrol # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu INTERVAL=10 #FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input FCTEMPS=/dev/fan-p6/pwm1=/sys/class/thermal/thermal_zone0/temp /dev/fan-p7/pwm1=/sys/class/thermal/thermal_zone0/temp MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=20