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
