Hi there, I am running a Raspberry Pi 4 with an oldstable release for a few years now. In fact, it is Devuan Chimaera, corresponding to Debian 11 Bookworm without systemd. As the kernel images comes straight from Debian, I am reporting it here...
I was and am running with a self-compiled kernel using the Raspberry Pi source on github. Everything fine so far. No I figured there is a 6.1 gerenic kernel in the apt repository with bcm/vc4 video framebuffer support, so wanted to give it a try. While it is booting quite smoothly and the video including X and Desktop is working, for some reason, the kernel scheduler is not. The CPU speed stays fixed at the maximum of 1800MHz, spouriously, every nth boot, it springs to other values, but not really following the governor. I will provide some data here. 1st try, my custom compiled kernel, 2nd try, the 6.1.69 from the repository. alex@aws:~:(1)> uname -a Linux aws 6.1.77-v8+ #17 SMP PREEMPT Mon Mar 11 15:51:14 CET 2024 aarch64 GNU/Linux alex@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0 alex@aws:cpu/cpufreq/policy0:(3)> ll total 0 -r--r--r-- 1 root root 4096 Mar 12 10:06 affected_cpus -r-------- 1 root root 4096 Mar 12 10:06 cpuinfo_cur_freq -r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_max_freq -r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_min_freq -r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 Mar 12 10:06 related_cpus -r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_available_frequencies -r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_available_governors -r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_cur_freq -r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_driver -rw-r--r-- 1 root root 4096 Mar 12 10:02 scaling_governor -rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_max_freq -rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_min_freq -rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_setspeed drwxr-xr-x 2 root root 0 Mar 12 10:40 stats alex@aws:cpu/cpufreq/policy0:(4)> cat scaling_driver scaling_governor cpufreq-dt schedutil alex@aws:cpu/cpufreq/policy0:(5)> foreach i ( `seq 1 1 10` ) foreach? date +%H:%M:%S foreach? sudo cat scaling_cur_freq cpuinfo_cur_freq foreach? echo --- ; sleep 2 foreach? end 10:41:31 1300000 1300000 --- 10:41:33 900000 1500000 --- 10:41:35 1800000 1800000 --- 10:41:37 1800000 1300000 --- 10:41:39 1300000 1300000 --- 10:41:42 1300000 1800000 --- 10:41:44 1400000 1200000 --- 10:41:46 1800000 1800000 --- 10:41:48 1800000 1800000 --- 10:41:50 1200000 1200000 --- alex@aws:cpu/cpufreq/policy0:(10)> Reboot the same system with generic kernel... alex@aws:~:(1)> uname -a Linux aws 6.1.0-0.deb11.17-arm64 #1 SMP Debian 6.1.69-1~bpo11+1 (2024- 01-05) aarch64 GNU/Linux alex@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0 alex@aws:cpu/cpufreq/policy0:(3)> cat scaling_driver scaling_governor cpufreq-dt schedutil alex@aws:cpu/cpufreq/policy0:(4)> foreach i ( `seq 1 1 10` ) foreach? date +%H:%M:%S foreach? sudo cat scaling_cur_freq cpuinfo_cur_freq foreach? echo --- ; sleep 2 foreach? end 10:47:49 1300000 1800000 --- 10:47:51 1300000 1800000 --- 10:47:53 1300000 1800000 --- 10:47:55 1300000 1800000 --- 10:47:57 1300000 1800000 --- 10:47:59 1300000 1800000 --- 10:48:01 1300000 1800000 --- 10:48:03 1300000 1800000 --- 10:48:05 1300000 1800000 --- 10:48:07 1300000 1800000 --- alex@aws:cpu/cpufreq/policy0:(9)> The cpuinfo_cur_freq should follow the scaling_cur_freq, which it does on the first place, but not with the generic kernel. Some more experiments: Same issue with 6.1.0-0.deb11.13-arm64 (6.1.55). But, the governor works fine with the generic linux-image-5.10.0-28- arm64 (5.10.209), however that version had no video support for the Raspberry vc4. Also, a short try showed that the Realtime kernel linux-image-6.1.0- 0.deb11.17-rt-arm64-unsigned indeed has a working governor, but no video support for the Raspberry as well. However, I did not check that kernel in detail and over more than one boot. First question - anyone else having the same problem and maybe a solution? Perhaps I am overlooking something here? Any idea where the root cause might be, and/or how to address it? Thanks for any inputs, Alex
