Now I am a step further. Hank has proved that on his system the governor works fine, also with X. As he uses the 1.21.1.7 from bookworm (stable), I cloned my oldstable card and dist-upgraded it to stable.
The good news - the governor is working now. The bad news - when I try to play a video using Gnome's Video tool it gets stuck and flickering and the Xorg server log file complains: [ 822.310] (EE) modeset(0): Failed to make 1280x913x32bpp GBM bo Any idea where that might come from? Best -Alex On Wed, 2024-03-20 at 10:03 -0500, Hank Barta wrote: > Boy, bash really did not like the line terminations in that file but > I finally identified the issue with the help of shellcheck > > In test-gov.sh line 1: > #!/bin/sh > ^-- SC1017 (error): Literal carriage return. Run script > through tr -d '\r' . > > First test, booting to a console: > > hbarta@cm4iob:~/bin$ sudo ./test1.gov.sh > > Scaling driver is cpufreq-dt, current governor is schedutil > Max CPU Frequency as per hardware is 1800000, min freq is 600000 > Max CPU Frequency as per governor is 1800000, min freq is 600000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > > Starting monitoring every 2 seconds > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > hbarta@cm4iob:~/bin$ > > Start gdm and login to Plasma/X11 > > hbarta@cm4iob:~/bin$ sudo ./test1.gov.sh > > Scaling driver is cpufreq-dt, current governor is schedutil > Max CPU Frequency as per hardware is 1800000, min freq is 600000 > Max CPU Frequency as per governor is 1800000, min freq is 600000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > > Starting monitoring every 2 seconds > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1800000, the hardware reports > 1800000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > hbarta@cm4iob:~/bin$ > > Stop gdm (which results in blank screen except for blinking cursor, > upper left .) > > hbarta@cm4iob:~/bin$ sudo ./test1.gov.sh > > Scaling driver is cpufreq-dt, current governor is schedutil > Max CPU Frequency as per hardware is 1800000, min freq is 600000 > Max CPU Frequency as per governor is 1800000, min freq is 600000 > Current Frequency as per governor is 1000000, the hardware reports > 1000000 > > Starting monitoring every 2 seconds > Current Frequency as per governor is 1200000, the hardware reports > 1500000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > Current Frequency as per governor is 1200000, the hardware reports > 1200000 > hbarta@cm4iob:~/bin$ > > Does this provide the information you are looking for? > > best, > > On Wed, Mar 20, 2024 at 9:26 AM Alex <sokol...@e-mail.de> wrote: > > Sure I can write it in a script.. as you're using bash, there you > > go.... > > > > https://pastebin.com/4BtgHfjW > > > > As some of the /sys files are readable only by root, start it with > > sudo. When the governor works correct, the CPU freq should follow > > the scaling_freq, it may vary due to timing and other things. > > > > -Alex > > > > > > On Wed, 2024-03-20 at 08:43 -0500, Hank Barta wrote: > > > I'll give it a try. > > > > > > hbarta@cm4iob:~/bin$ cd /sys/devices/system/cpu/cpufreq/policy0/ > > > hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ cat > > > scaling_driver scaling_governor > > > cpufreq-dt > > > schedutil > > > hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ cpufreq-dt > > > -bash: cpufreq-dt: command not found > > > hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ schedutil > > > -bash: schedutil: command not found > > > hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ foreach i > > > ( `seq 1 1 10` ) > > > -bash: syntax error near unexpected token `(' > > > hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ > > > > > > Can I suggest you provide a script to report the readings that > > > works with Debian? It would be great if you could put it > > > somewhere like Github or Pastebin? > > > > > > This is Debian Bookworm (not updated recently as I don't normally > > > run this.) I can run your tests before and after an upgrade. At > > > present this host is running > > > > > > Linux cm4iob 6.1.0-18-arm64 #1 SMP Debian 6.1.76-1 (2024-02-01) > > > aarch64 GNU/Linux > > > > > > > > > > > > On Wed, Mar 20, 2024 at 5:53 AM Alex <sokol...@e-mail.de> wrote: > > > > > That latest kernel I referred to is .76, 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Beautiful Sunny Winfield > > > > > > > -- > Beautiful Sunny Winfield
