[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Governor problem with generic 6.1 arm64 kernel on Raspberry



Sorry for mixing things up. Chimaera is oldstable and thus corresponds
to Bullseye...

On Tue, 2024-03-12 at 11:14 +0100, Alex wrote:
> 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: