That latest kernel I referred to is .67, not 69, sorry for the confusion.
On Wed, 2024-03-20 at 11:48 +0100, Alex wrote: > 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 > > > > > > > > > > > > > > > > > > > > > >
