Re: Governor problem with generic 6.1 arm64 kernel on Raspberry
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 <sokoloff@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 <sokoloff@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
Reply to: