Hi, Is there really no one who could and would just do that one test for me? I reproduced the problem with the actual 6.1.69 kernel from the Debian repository.
1. Boot a Rasyberry Pi 4 without X or other graphics running. Check if scaling_cur_freq and cpuinfo_cur_freq are in line. You also could query by Raspberry userland (vcgencmd measure_clock arm), which is in my case always identical to cpuinfo_cur_freq. alex@aws:~:(6)> cd /sys/devices/system/cpu/cpufreq/policy0/ 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 3. Start Xorg server. I just found the latest generic kernel build from the debian repository supports kms and accelerated X, which is a great achievement, by the way. Repeat the tests. In my use case the cpuinfo_cur_freq is now always identical to cpuinfo_max_freq, no matter what scaling_cur_freq gives back. vcgencmd via /dev/vcio also reports the max speed. 4. Shut that X server down again and re-check. In my setup the governor (no matter which one you choose) will not go back working again. Thanks, Alex On Wed, 2024-03-13 at 22:39 +0100, Alex wrote: > I have to admit that I drew the wrong conclusions. Some of my > frequency readings were conducted within an x-terminal, some on a > console screen, without X running. That, in fact, seemed to make the > difference. > > Booting in any of the 6.1 upstream generic kernels works fine, > including the governor, as long as I remained in text mode. Also > switching between different governors immediately brought the > intended result. > > Once starting the X Server (X.Org 1.20.11 with either fbdev or > fbturbo driver) causes the CPU frequency not following the scaling > frequency any more but stick to the maximum speed defined as per > firmware or config.txt. Shutting down the X server does not revert > this. > > For me this seems to be a gpu related issue ... ? > > Regards, > Alex > > > On Wed, 2024-03-13 at 14:27 +0100, Alex wrote: > > > > > > > There was a typo in my last statement... > > > > > oldstable 5.10 --> governor *is* working > > > oldstable 6.1 backport --> governor not working > > > oldstable 6.1 RT backport --> governor is working > > > stable 6.1 --> governor is working > > > > > > On Wed, 2024-03-13 at 13:41 +0100, Alex wrote: > > > Hi Andy, > > > > > > I see your point... however the governor working or not seems to > > > be a > > > pure kernel issue, and Devuan does not support any arm platform > > > and > > > not build the generic kernels in the apt repository. Their > > > repository > > > is mainly fed from Debian one, with some changes when it comes to > > > systemd vs. init. > > > > > > There are prebuilt images for arm64 with custom compiled kernels > > > without any method to do regular updates (they do not feed these > > > kernels to the apt repository). This is why I ended in compiling > > > the > > > kernel by myself in the first place. > > > > > > However, to be sure it really is a kernel issue I gave > > > 20231109_raspi_4_bookworm.img an try today and the governor > > > worked. > > > So I installed the 6.1 kernel from the stable repository on my > > > oldstable Devuan userland and still, the governor works. > > > > > > So, there seems to be a difference between the 6.1 oldstable > > > backport > > > kernels vs. the ones in the stable repository. > > > > > > My first posts primary intention was not to get support (as I do > > > have > > > a running system), but to point out a possible bug which is > > > present > > > in some Debian arm64 kernels, while others are working fine. > > > > > > oldstable 5.10 --> governor not working > > > oldstable 6.1 backport --> governor not working > > > oldstable 6.1 RT backport --> governor working > > > stable 6.1 --> governor working > > > > > > So after all, this does not seem to be a Devuan issue. I'd be > > > glad to > > > help tracking down this issue. > > > > > > Alex > > > > > > On Tue, 2024-03-12 at 22:26 +0000, Andrew M.A. Cater wrote: > > > > On Tue, Mar 12, 2024 at 11:14:10AM +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... > > > > > > > > > > > > > Can I respectfully suggest that you ask Devuan for help? > > > > > > > > if you use the images at raspi.debian.net, we may be able to > > > > help > > > > you. > > > > If you want to try booting using UEFI and a stock Debian image, > > > > we > > > > can also offer advice. > > > > > > > > For Devuan - we cannot be entirely sure that the advice we give > > > > will > > > > be correct. > > > > > > > > With every good wish, as ever, > > > > > > > > Andy > > > > > > > > > Alex > > > > > > > > > > > > > > >
