BipBip1981

Hi, Kernel 6.6.29 with: git clone --depth=1 --branch=main https://github.com/armbian/build cd build ./compile.sh kernel BOARD=helios64 BRANCH=current Same for me like with 6.6.26/27/28, pass my pattern test and also rsync over network of 3TO with -c option to do checksum during RAID10 Scrubbing pass I think Governor on this Kernel is less agressive like before... Keep in touch

Hi, To my side, it's too complex and risky for me to change hardware components on Helios64. I prefer for my case of uses change CPU Freq and Governor for less performance but stable inside take risk of damage my board by change components. Have a good day

Hi, Today: KERNEL 6.6.28 No voltage modification root@helios64:~/tmp# diff cpufreq-switching-2.c cpufreq-switching-2-TRANSITION_DELAY_0.c 19c19 < #define TRANSITION_DELAY 5000 --- > #define TRANSITION_DELAY 0 root@helios64:~/tmp# gcc -o cpufreq-switching-2-TRANSITION_DELAY_0.b cpufreq-switching-2-TRANSITION_DELAY_0.c root@helios64:~/tmp# time for i in $(seq 1 100); do ./cpufreq-switching-2-TRANSITION_DELAY_0.b ; done Few minutes... less than 5min... and crash in "full reboot" seem like short off/on with same sound like push reset button Second try, uptime 19min and same crash like push reset buttom First conclusion: Time delay 5000 seem Okok / Time delay 0 crash Keep in touch

Result with for i in $(seq 1 100); do ./cpufreq-switching-2-b ; done TRANSITION_DELAY 5000 16h47 uptime Kernel 6.6.28 NO CRASH ! Tomorrow try with TRANSITION_DELAY 0 Have a good night 9/10, 99/100 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 cpub_freq 1416000 cpub_freq 1200000 cpub_freq 1008000 cpub_freq 816000 cpub_freq 600000 cpub_freq 408000 cpub_freq 600000 cpub_freq 816000 cpub_freq 1008000 cpub_freq 1200000 cpub_freq 1416000 cpub_freq 1608000 cpub_freq 1800000 cpub_freq 1608000 root@helios64:~/tmp#

Hello, I crash this night (between 3hours uptime and 6hours uptime, i was sleeping) with 6.6.16 and without voltage correction. (red led flashing) (I crash with version "TRANSITION_DELAY 5000" that i copy/paste upper) Do you know which kernel was running when your box crashed? -> 6.6.28 but maybe with your TRANSITION_DELAY 0 version because i copy/paste from forum and then until now i use github version copy/paste upper I install 6.6.28 without voltage correction and look result List of packages i installed: base-files_24.5.0-trunk-12.4+deb12u5-bookworm_arm64__1-bookworm-1armbian1-Ba4f9-U12.4--deb12u5-R55fa.deb armbian-config_24.5.0-trunk_all__1-SA8477-B0293-R448a.deb linux-dtb-current-rockchip64_24.5.0-trunk_arm64__6.6.28-Sba15-D440d-P9dc2-Ca832H66b1-HK01ba-Vc222-Bf15a-R448a.deb armbian-plymouth-theme_24.5.0-trunk_all__1-Bfcdb-R448a.deb linux-image-current-rockchip64_24.5.0-trunk_arm64__6.6.28-Sba15-D440d-P9dc2-Ca832H66b1-HK01ba-Vc222-Bf15a-R448a.deb armbian-zsh_24.5.0-trunk_all__1-SAbfee-Baafd-R448a.deb linux-u-boot-helios64-current_24.5.0-trunk_arm64__2022.07-Se092-Pe990-H8c72-V65aa-Bf5f6-R448a.deb root@helios64:~/tmp# uname -a Linux helios64 6.6.28-current-rockchip64 #3 SMP PREEMPT Wed Apr 17 09:19:38 UTC 2024 aarch64 GNU/Linux root@helios64:~/tmp# for i in $(seq 1 100); do ./cpufreq-switching-2-b ; done If not crash, i try TRANSITION_DELAY 0 version if not crash TRANSITION_DELAY 0 version, i stay with this setting If crash i try voltage correction Keep in touch

Actually, i did this below and run your command, result at the end. For information, view freq change with htop command but not load up more than few % root@helios64:~/tmp# cat cpufreq-switching-2.c #include <stdio.h> #include <stdint.h> #include <stdlib.h> #include <string.h> #include <fcntl.h> #include <malloc.h> #include <unistd.h> #include <sys/mman.h> #define MAIN_LOOPS (100) #define TRIALS_PER_TOGGLE (10) #define MAX_MEGS (64) #define CPUL 0 #define CPUB 1 #define TRANSITION_DELAY 5000 const char *cpul_freqs[] = { "408000", "600000", "816000", "1008000", "1200000", "1416000" }; const char *cpub_freqs[] = { "408000", "600000", "816000", "1008000", "1200000", "1416000", "1608000", "1800000" }; uint32_t *megs[MAX_MEGS]; int checked_open(char *name) { int fd = open(name, O_RDWR); char err[128]; if (fd < 0) { snprintf(err, 128, "cannot open %s", name); perror(err); exit(1); } return fd; } #define SCALING_PATHL "/sys/devices/system/cpu/cpu0/cpufreq/" #define SCALING_PATHB "/sys/devices/system/cpu/cpu4/cpufreq/" void browse_freq(int *cpul_index, int *cpub_index, int *cpul_step, int *cpub_step) { static int inited = 0; int freql_target_len; int freqb_target_len; int freqfd; int cpul_freqs_count = 0; int cpub_freqs_count = 0; cpul_freqs_count = sizeof(cpul_freqs)/sizeof(cpul_freqs[0]); cpub_freqs_count = sizeof(cpub_freqs)/sizeof(cpub_freqs[0]); if (!inited) { #if CPUL freqfd = checked_open(SCALING_PATHL "scaling_governor"); write(freqfd, "userspace", 9); close(freqfd); #endif #if CPUB freqfd = checked_open(SCALING_PATHB "scaling_governor"); write(freqfd, "userspace", 9); close(freqfd); #endif inited = 1; } if (*cpul_index >= cpul_freqs_count - 1) *cpul_step = -1; if (*cpul_index <= 0) *cpul_step = 1; if (*cpub_index >= cpub_freqs_count - 1) *cpub_step = -1; if (*cpub_index <= 0) *cpub_step = 1; *cpul_index += *cpul_step; *cpub_index += *cpub_step; #if CPUL printf("cpul_freq %s\n", cpul_freqs[*cpul_index]); freql_target_len = strlen(cpul_freqs[*cpul_index]); freqfd = checked_open(SCALING_PATHL "scaling_setspeed"); write(freqfd, cpul_freqs[*cpul_index], freql_target_len); close(freqfd); #endif #if CPUB printf("cpub_freq %s\n", cpub_freqs[*cpub_index]); freqb_target_len = strlen(cpub_freqs[*cpub_index]); freqfd = checked_open(SCALING_PATHB "scaling_setspeed"); write(freqfd, cpub_freqs[*cpub_index], freqb_target_len); close(freqfd); #endif usleep(TRANSITION_DELAY); } void write_test_data(int nmegs, int toggle) { int cpul_index = 0; int cpub_index = 0; int cpul_step = 1; int cpub_step = 1; while (nmegs--) { browse_freq(&cpul_index, &cpub_index, &cpul_step, &cpub_step); } } void check_test_data(int nmegs, int toggle) { int cpul_index = 0; int cpub_index = 0; int cpul_step = 1; int cpub_step = 1; while (nmegs--) { browse_freq(&cpul_index, &cpub_index, &cpul_step, &cpub_step); } } int main(int argc, char **argv) { int nmegs = MAX_MEGS; printf("allocated %dMB\n", nmegs); int nloop, ntoggle, ntrial; printf("test: toggle freq before write\n"); for (nloop = 0; nloop < MAIN_LOOPS; nloop++) { printf("\r%d/%d ", nloop, MAIN_LOOPS); fflush(stdout); write_test_data(nmegs, 1); check_test_data(nmegs, 0); } printf("\n"); printf("test: toggle freq before read\n"); for (nloop = 0; nloop < MAIN_LOOPS; nloop++) { write_test_data(nmegs, 0); for (ntrial=0; ntrial < TRIALS_PER_TOGGLE; ntrial++) { printf("\r%d/%d, %d/%d ", ntrial, TRIALS_PER_TOGGLE, nloop, MAIN_LOOPS); fflush(stdout); check_test_data(nmegs, 1); } } printf("\n"); return 0; } ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# gcc -o cpufreq-switching-2-b cpufreq-switching-2.c ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# uname -a Linux helios64 6.6.16-current-rockchip64 #1 SMP PREEMPT Fri Feb 23 08:25:28 UTC 2024 aarch64 GNU/Linux ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=schedutil ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# uptime 19:39:19 up 5 min, 2 users, load average: 0.27, 0.54, 0.31 ————————————————————————————————————————————————————————————————————————————————————— root@helios64:~/tmp# for i in $(seq 1 100); do ./cpufreq-switching-2-b ; done

you mean you have no crash running cpufreq-switching-2-b five times with 6.6.16 and 6.6.28? Yes not crash today. I post soon full test pattern and result with 6.6.16 and then 6.6.28 with source of cpufreq-switching-2-b from https://gist.github.com/prahal/8fab73325eb0d7091ad7c4627bf8e25a compil with gcc -o cpufreq-switching-2-b cpufreq-switching-2.c So it crashed with which kernel? Did you rebuild cpufreq-switching-2-b between the test that crashed and the ones that did not? Yes i rebuild because i build in /tmp directory that what a ramdisk... and lost binary with crash Now i store binary on emmc 😉 I do next test with my armbian 24.2.1 build my self with official framework without any another tune then i do exact same with packages kernel armbian 24.5 build my self with official framework upgrade on my 24.2.1

Hi, Fisrt, i restore my backup with 6.6.16 and run cpufreq-switching-2-b 5 times and cpufreq-switching-b 2 times root@helios64:~# uname -a Linux helios64 6.6.16-current-rockchip64 #1 SMP PREEMPT Fri Feb 23 08:25:28 UTC 2024 aarch64 GNU/Linux root@helios64:~# cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=408000 MAX_SPEED=1800000 GOVERNOR=schedutil root@helios64:~/tmp# ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b root@helios64:~/tmp# ./cpufreq-switching-b ; ./cpufreq-switching-b No crash with your program Second, I installed build my self this over my 24.2.1 build with 6.6.28: linux-dtb-current-rockchip64_24.5.0-trunk_arm64__6.6.28-Sba15-D440d-P9dc2-Ca832H66b1-HK01ba-Vc222-Bf15a-R448a.deb linux-image-current-rockchip64_24.5.0-trunk_arm64__6.6.28-Sba15-D440d-P9dc2-Ca832H66b1-HK01ba-Vc222-Bf15a-R448a.deb reboot and do: root@helios64:~/tmp# uname -a Linux helios64 6.6.28-current-rockchip64 #3 SMP PREEMPT Wed Apr 17 09:19:38 UTC 2024 aarch64 GNU/Linux root@helios64:~/tmp# ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b ; ./cpufreq-switching-2-b ; ./cpufreq-switching.b ; ./cpufreq-switching.b Not crash… freq seem change in htop program monitor but load isn’t at 100% on cpu… load seem idle… it’s normal, same with 6.6.16 or 6.6.28? if it’s normal: not crash with your cpufreq-switching-2-b & cpufreq-switching.b program on my helios crash with my pattern test on 6.6.16 and not with 6.6.27 and 6.6.28 What do you think about my results ?

hi, i build 2 version from your site: root@helios64:~/tmp# ls cpufreq-switching-2-b cpufreq-switching-2.c cpufreq-switching.b cpufreq-switching.c I run this version cpufreq-switching-2-b ? and after running your program, i think automatic freq change don't change but stay a last freq fixe, i all right?

Hi, i use cpufreq-switching-2-b and... Full Crash and reboot automatic after less than 15s... After reboot not crash second try just after reboot... for moment, my test pattern not crash, cpufreq-switching-2-b continu to do crash with cpufreq-switching-2-b. I test 2 version here soon: https://gist.github.com/prahal

Hi, i use cpufreq-switching-2-b and... Full Crash and reboot automatic after less than 15s... After reboot not crash second try just after reboot... for moment, my test pattern not crash, cpufreq-switching-2-b continu to do crash with cpufreq-switching-2-b. I test 2 version here soon: https://gist.github.com/prahal

Hi, For moment not crash with my pattern test. Tthis evening i run cpufreq-switching-2-b and post result Keep in touch root@helios64:~# btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-14d5a7aa1c4d Opening filesystem to check... Checking filesystem on /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-14d5a7aa1c4d UUID: 1d4e2c84-1c43-4d73-8acb-14d5a7aa1c4d [1/7] checking root items (0:04:20 elapsed, 6258640 items checked) [2/7] checking extents (0:22:26 elapsed, 613032 items checked) [3/7] checking free space cache (0:08:50 elapsed, 5519 items checked) [4/7] checking fs roots (8:40:20 elapsed, 169002 items checked) [5/7] checking csums against data (35:54:03 elapsed, 2619191 items checked) helios64@helios64:~$ cat /proc/mdstat Personalities : [raid10] [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] md0 : active raid10 sdd1[0] sdc1[5] sde1[4] sda1[2] 15627581440 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU] [=>...................] check = 5.2% (821480320/15627581440) finish=1681.3min speed=146770K/sec bitmap: 0/117 pages [0KB], 65536KB chunk unused devices: <none> helios64@helios64:~$ uptime 11:05:34 up 1 day, 22:02, 3 users, load average: 2,98, 2,82, 2,78

Hi, For moment not crash with my pattern test. Tthis evening i run cpufreq-switching-2-b and post result Keep in touch root@helios64:~# btrfs check --readonly --check-data-csum --progress /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-14d5a7aa1c4d Opening filesystem to check... Checking filesystem on /dev/disk/by-uuid/1d4e2c84-1c43-4d73-8acb-14d5a7aa1c4d UUID: 1d4e2c84-1c43-4d73-8acb-14d5a7aa1c4d [1/7] checking root items (0:04:20 elapsed, 6258640 items checked) [2/7] checking extents (0:22:26 elapsed, 613032 items checked) [3/7] checking free space cache (0:08:50 elapsed, 5519 items checked) [4/7] checking fs roots (8:40:20 elapsed, 169002 items checked) [5/7] checking csums against data (35:54:03 elapsed, 2619191 items checked) helios64@helios64:~$ cat /proc/mdstat Personalities : [raid10] [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] md0 : active raid10 sdd1[0] sdc1[5] sde1[4] sda1[2] 15627581440 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU] [=>...................] check = 5.2% (821480320/15627581440) finish=1681.3min speed=146770K/sec bitmap: 0/117 pages [0KB], 65536KB chunk unused devices: <none> helios64@helios64:~$ uptime 11:05:34 up 1 day, 22:02, 3 users, load average: 2,98, 2,82, 2,78

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