Governor problem with generic 6.1 arm64 kernel on Raspberry
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
Reply to: