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 >
