Forum: >>> Magnum BBS <<<

Re: Governor problem with generic 6.1 arm64 kernel on Raspberry

From Alex@21:1/5 to Alex on Tue Mar 12 12:00:01 2024

Sorry for mixing things up. Chimaera is oldstable and thus corresponds
to Bullseye...

On Tue, 2024-03-12 at 11:14 +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...

I was and am running with a self-compiled kernel using the Raspberry
Pi
source on github. Everything fine so far. No I figured there is a 6.1
gerenic kernel in the apt repository with bcm/vc4 video framebuffer
support, so wanted to give it a try.

While it is booting quite smoothly and the video including X and
Desktop is working, for some reason, the kernel scheduler is not.

The CPU speed stays fixed at the maximum of 1800MHz, spouriously,
every
nth boot, it springs to other values, but not really following the
governor. I will provide some data here. 1st try, my custom compiled
kernel, 2nd try, the 6.1.69 from the repository.

alex@aws:~:(1)> uname -a
Linux aws 6.1.77-v8+ #17 SMP PREEMPT Mon Mar 11 15:51:14 CET 2024
aarch64 GNU/Linux
alex@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0 alex@aws:cpu/cpufreq/policy0:(3)> ll
total 0
-r--r--r-- 1 root root 4096 Mar 12 10:06 affected_cpus
-r-------- 1 root root 4096 Mar 12 10:06 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_transition_latency -r--r--r-- 1 root root 4096 Mar 12 10:06 related_cpus
-r--r--r-- 1 root root 4096 Mar 12 10:06
scaling_available_frequencies
-r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_available_governors -r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_cur_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_driver
-rw-r--r-- 1 root root 4096 Mar 12 10:02 scaling_governor
-rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_max_freq
-rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_min_freq
-rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_setspeed
drwxr-xr-x 2 root root 0 Mar 12 10:40 stats 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
---
10:41:42
1300000
1800000
---
10:41:44
1400000
1200000
---
10:41:46
1800000
1800000
---
10:41:48
1800000
1800000
---
10:41:50
1200000
1200000
---
alex@aws:cpu/cpufreq/policy0:(10)>

Reboot the same system with generic kernel...

alex@aws:~:(1)> uname -a
Linux aws 6.1.0-0.deb11.17-arm64 #1 SMP Debian 6.1.69-1~bpo11+1
(2024-
01-05) aarch64 GNU/Linux
alex@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0 alex@aws:cpu/cpufreq/policy0:(3)> cat scaling_driver
scaling_governor
cpufreq-dt
schedutil
alex@aws:cpu/cpufreq/policy0:(4)> 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:47:49
1300000
1800000
---
10:47:51
1300000
1800000
---
10:47:53
1300000
1800000
---
10:47:55
1300000
1800000
---
10:47:57
1300000
1800000
---
10:47:59
1300000
1800000
---
10:48:01
1300000
1800000
---
10:48:03
1300000
1800000
---
10:48:05
1300000
1800000
---
10:48:07
1300000
1800000
---
alex@aws:cpu/cpufreq/policy0:(9)>

The cpuinfo_cur_freq should follow the scaling_cur_freq, which it
does
on the first place, but not with the generic kernel. Some more
experiments: Same issue with 6.1.0-0.deb11.13-arm64 (6.1.55).

But, the governor works fine with the generic linux-image-5.10.0-28-
arm64 (5.10.209), however that version had no video support for the
Raspberry vc4.

Also, a short try showed that the Realtime kernel linux-image-6.1.0- 0.deb11.17-rt-arm64-unsigned indeed has a working governor, but no
video support for the Raspberry as well. However, I did not check
that
kernel in detail and over more than one boot.

First question - anyone else having the same problem and maybe a
solution? Perhaps I am overlooking something here? Any idea where the
root cause might be, and/or how to address it?

Thanks for any inputs,
Alex

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to All on Tue Mar 12 11:20:02 2024

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...

I was and am running with a self-compiled kernel using the Raspberry Pi
source on github. Everything fine so far. No I figured there is a 6.1
gerenic kernel in the apt repository with bcm/vc4 video framebuffer
support, so wanted to give it a try.

While it is booting quite smoothly and the video including X and
Desktop is working, for some reason, the kernel scheduler is not.

The CPU speed stays fixed at the maximum of 1800MHz, spouriously, every
nth boot, it springs to other values, but not really following the
governor. I will provide some data here. 1st try, my custom compiled
kernel, 2nd try, the 6.1.69 from the repository.

alex@aws:~:(1)> uname -a
Linux aws 6.1.77-v8+ #17 SMP PREEMPT Mon Mar 11 15:51:14 CET 2024
aarch64 GNU/Linux
alex@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0 alex@aws:cpu/cpufreq/policy0:(3)> ll
total 0
-r--r--r-- 1 root root 4096 Mar 12 10:06 affected_cpus
-r-------- 1 root root 4096 Mar 12 10:06 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_min_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 cpuinfo_transition_latency
-r--r--r-- 1 root root 4096 Mar 12 10:06 related_cpus
-r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_available_frequencies -r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_available_governors
-r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_cur_freq
-r--r--r-- 1 root root 4096 Mar 12 10:06 scaling_driver
-rw-r--r-- 1 root root 4096 Mar 12 10:02 scaling_governor
-rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_max_freq
-rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_min_freq
-rw-r--r-- 1 root root 4096 Mar 12 10:06 scaling_setspeed
drwxr-xr-x 2 root root 0 Mar 12 10:40 stats 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
---
10:41:42
1300000
1800000
---
10:41:44
1400000
1200000
---
10:41:46
1800000
1800000
---
10:41:48
1800000
1800000
---
10:41:50
1200000
1200000
---
alex@aws:cpu/cpufreq/policy0:(10)>

Reboot the same system with generic kernel...

alex@aws:~:(1)> uname -a
Linux aws 6.1.0-0.deb11.17-arm64 #1 SMP Debian 6.1.69-1~bpo11+1 (2024-
01-05) aarch64 GNU/Linux
alex@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0 alex@aws:cpu/cpufreq/policy0:(3)> cat scaling_driver scaling_governor cpufreq-dt
schedutil
alex@aws:cpu/cpufreq/policy0:(4)> 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:47:49
1300000
1800000
---
10:47:51
1300000
1800000
---
10:47:53
1300000
1800000
---
10:47:55
1300000
1800000
---
10:47:57
1300000
1800000
---
10:47:59

From Andrew M.A. Cater@21:1/5 to Alex on Tue Mar 12 23:30:01 2024

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to Andrew M.A. Cater on Wed Mar 13 13:50:02 2024

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

<html><head></head><body><div>Hi Andy,</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>So, there seems to be a difference between the 6.1 oldstable backport kernels vs. the ones
in the stable repository.</div><div><br></div><div>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.</div>
<div><br></div><div>oldstable 5.10 --> governor not working</div><div>oldstable 6.1 backport --> governor not working</div><div>oldstable 6.1 RT backport --> governor working</div><div>stable 6.1 --> governor working</div><div><br></div><div>
So after all, this does not seem to be a Devuan issue. I'd be glad to help tracking down this issue.</div><div><br></div><div>Alex</div><div><br></div><div>On Tue, 2024-03-12 at 22:26 +0000, Andrew M.A. Cater wrote:</div><blockquote type="cite" style="
margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Tue, Mar 12, 2024 at 11:14:10AM +0100, Alex wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi there,<br></

<div><br></div><div>I am running a Raspberry Pi 4 with an oldstable release for a few years<br></div><div>now. In fact, it is Devuan Chimaera, corresponding to Debian 11<br></div><div>Bookworm without systemd. As the kernel images comes straight from<

</div><div>Debian, I am reporting it here...<br></div><div><br></div></blockquote><div><br></div><div>Can I respectfully suggest that you ask Devuan for help?<br></div><div><br></div><div>if you use the images at raspi.debian.net, we may be able to

help you.<br></div><div>If you want to try booting using UEFI and a stock Debian image, we<br></div><div>can also offer advice.<br></div><div><br></div><div>For Devuan - we cannot be entirely sure that the advice we give will<br></div><div>be correct.<br>
</div><div><br></div><div>With every good wish, as ever,<br></div><div><br></div><div>Andy<br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Alex<br></div><div><br></div></
blockquote><div><br></div></blockquote><div><br></div><div><span></span></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to Alex on Wed Mar 13 14:30:03 2024

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to Alex on Wed Mar 13 22:40:01 2024

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

<html><head></head><body><div>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.</div><div><br></

<div>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. </div><div><br></div><div>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.</div><div><br></div><div>For me this seems to be a gpu related issue ... ?</div><div><br></div><div>Regards,</div><div>Alex</div><div><br></div><div><br></div><div>On Wed, 2024-03-13 at 14:27 +0100, Alex wrote:</div><blockquote type="cite"
style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div></blockquote><div><br></div><div>There was a typo in my last
statement...<br></div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>oldstable 5.10 --> governor *is* working<br></div><div>oldstable 6.1 backport --> governor not working<

</div><div>oldstable 6.1 RT backport --> governor is working<br></div><div>stable 6.1 --> governor is working<br></div></blockquote><div><br></div><div><br></div><div>On Wed, 2024-03-13 at 13:41 +0100, Alex wrote:<br></div><blockquote type="cite"

style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hi Andy,<br></div><div><br></div><div>I see your point... however the governor working or not seems to be a<br></div><div>pure kernel issue, and Devuan does not support any
arm platform and<br></div><div>not build the generic kernels in the apt repository. Their repository<br></div><div>is mainly fed from Debian one, with some changes when it comes to<br></div><div>systemd vs. init.<br></div><div><br></div><div>There are
prebuilt images for arm64 with custom compiled kernels<br></div><div>without any method to do regular updates (they do not feed these<br></div><div>kernels to the apt repository). This is why I ended in compiling the<br></div><div>kernel by myself in the
first place. <br></div><div><br></div><div>However, to be sure it really is a kernel issue I gave<br></div><div>20231109_raspi_4_bookworm.img an try today and the governor worked.<br></div><div>So I installed the 6.1 kernel from the stable
repository on my<br></div><div>oldstable Devuan userland and still, the governor works.<br></div><div><br></div><div>So, there seems to be a difference between the 6.1 oldstable backport<br></div><div>kernels vs. the ones in the stable repository.<br></

<div><br></div><div>My first posts primary intention was not to get support (as I do have<br></div><div>a running system), but to point out a possible bug which is present<br></div><div>in some Debian arm64 kernels, while others are working fine.<br><

/div><div><br></div><div>oldstable 5.10 --> governor not working<br></div><div>oldstable 6.1 backport --> governor not working<br></div><div>oldstable 6.1 RT backport --> governor working<br></div><div>stable 6.1 --> governor working<br></div>
<div><br></div><div>So after all, this does not seem to be a Devuan issue. I'd be glad to<br></div><div>help tracking down this issue.<br></div><div><br></div><div>Alex<br></div><div><br></div><div>On Tue, 2024-03-12 at 22:26 +0000, Andrew M.A. Cater
wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On Tue, Mar 12, 2024 at 11:14:10AM +0100, Alex wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #
729fcf solid;padding-left:1ex"><div>Hi there,<br></div><div><br></div><div>I am running a Raspberry Pi 4 with an oldstable release for a few<br></div><div>years<br></div><div>now. In fact, it is Devuan Chimaera, corresponding to Debian 11<br></div><div>
Bookworm without systemd. As the kernel images comes straight<br></div><div>from<br></div><div>Debian, I am reporting it here...<br></div><div><br></div></blockquote><div><br></div><div>Can I respectfully suggest that you ask Devuan for help?<br></div><

<br></div><div>if you use the images at raspi.debian.net, we may be able to help<br></div><div>you.<br></div><div>If you want to try booting using UEFI and a stock Debian image, we<br></div><div>can also offer advice.<br></div><div><br></div><div>For

Devuan - we cannot be entirely sure that the advice we give<br></div><div>will<br></div><div>be correct.<br></div><div><br></div><div>With every good wish, as ever,<br></div><div><br></div><div>Andy<br></div><div><br></div><blockquote type="cite" style="
margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Alex<br></div><div><br></div></blockquote><div><br></div></blockquote><div><br></div></blockquote><div><br></div></blockquote><div><br></div><div><span></span></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to Alex on Wed Mar 20 11:50:02 2024

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 gove

From Alex@21:1/5 to All on Wed Mar 20 12:00:01 2024

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to Alex on Wed Mar 20 12:00:01 2024

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to Hank Barta on Wed Mar 20 15:30:01 2024

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

<html><head></head><body><div>Sure I can write it in a script.. as you're using bash, there you go....</div><div><br></div><div><a href="https://pastebin.com/4BtgHfjW">https://pastebin.com/4BtgHfjW</a></div><div><br></div><div>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.</div><div><br></div><div>-Alex</div><div><br></div><div><br></div><div>On Wed, 2024-
03-20 at 08:43 -0500, Hank Barta wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div>I'll give it a try.</div><div><br><span style="font-family:monospace">hbarta@cm4iob:~/bin$
cd /sys/devices/system/cpu/cpufreq/policy0/<br>hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_driver scaling_governor<br>cpufreq-dt<br>schedutil<br>hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ cpufreq-dt<br>-bash: cpufreq-dt:
command not found<br>hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ schedutil<br>-bash: schedutil: command not found<br>hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ foreach i ( `seq 1 1 10` )<br>-bash: syntax error near unexpected
token `('<br>hbarta@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ </span><br></div><div><br></div><div>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?<br></div><div><br></div><div>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</div><div><br></div><div><span style="font-family:
monospace"><span style="color:rgb(0,0,0);background-color:rgb(255,255,255)">Linux cm4iob 6.1.0-18-arm64 #1 SMP Debian 6.1.76-1 (2024-02-01) aarch64 GNU/Linux</span><br><br><br></span></div></div><div><br></div><div class="gmail_quote"><div dir="ltr"
class="gmail_attr">On Wed, Mar 20, 2024 at 5:53 AM Alex <<a href="mailto:sokoloff@e-mail.de">sokoloff@e-mail.de</a>> wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>> That
latest kernel I referred to is .76, not 69, sorry for the<br>> confusion.<br>> <br>> On Wed, 2024-03-20 at 11:48 +0100, Alex wrote:<br>> > Hi,<br>> > <br>> > Is there really no one who could and would just do that one test<br>&
gt; > for<br>> > me? I reproduced the problem with the actual 6.1.69 kernel from the<br>> > Debian repository.<br>> > <br>> > 1. Boot a Rasyberry Pi 4 without X or other graphics running. Check<br>> > if<br>> >
scaling_cur_freq and cpuinfo_cur_freq are in line. You also could<br>> > query<br>> > by Raspberry userland (vcgencmd measure_clock arm), which is in my<br>> > case<br>> > always identical to cpuinfo_cur_freq.<br>> > <

> > <br>> > alex@aws:~:(6)> cd /sys/devices/system/cpu/cpufreq/policy0/<br>> > alex@aws:cpu/cpufreq/policy0:(4)> cat scaling_driver<br>> > scaling_governor<br>> > cpufreq-dt<br>> > schedutil<br>> > alex@

aws:cpu/cpufreq/policy0:(5)> foreach i ( `seq 1 1 10` )<br>> > foreach? date +%H:%M:%S<br>> > foreach? sudo cat scaling_cur_freq cpuinfo_cur_freq<br>> > foreach? echo --- ; sleep 2<br>> > foreach? end<br>> > 10:41:31<br>&
gt; > 1300000<br>> > 1300000<br>> > ---<br>> > 10:41:33<br>> > 900000<br>> > 1500000<br>> > ---<br>> > 10:41:35<br>> > 1800000<br>> > 1800000<br>> > ---<br>> > 10:41:37<br>> >
1800000<br>> > 1300000<br>> > ---<br>> > 10:41:39<br>> > 1300000<br>> > 1300000<br>> > <br>> > 3. Start Xorg server. I just found the latest generic kernel build<br>> > from<br>> > the debian
repository supports kms and accelerated X, which is a<br>> > great<br>> > achievement, by the way.<br>> > <br>> > Repeat the tests. In my use case the cpuinfo_cur_freq is now always<br>> > identical to cpuinfo_max_freq, no
matter what scaling_cur_freq<br>> > gives<br>> > back. vcgencmd via /dev/vcio also reports the max speed.<br>> > <br>> > 4. Shut that X server down again and re-check. In my setup the<br>> > governor<br>> > (no
matter which one you choose) will not go back working again. <br>> > <br>> > Thanks,<br>> > Alex<br>> > <br>> > On Wed, 2024-03-13 at 22:39 +0100, Alex wrote:<br>> > > I have to admit that I drew the wrong
conclusions. Some of my<br>> > > frequency readings were conducted within an x-terminal, some on a<br>> > > console screen, without X running. That, in fact, seemed to make<br>> > > the<br>> > > difference.<br>> >
> <br>> > > Booting in any of the 6.1 upstream generic kernels works fine,<br>> > > including the governor, as long as I remained in text mode. Also<br>> > > switching between different governors immediately brought the<br>&
gt; > > intended result. <br>> > > <br>> > > Once starting the X Server (X.Org 1.20.11 with either fbdev or<br>> > > fbturbo driver) causes the CPU frequency not following the<br>> > > scaling<br>> > &
gt; frequency any more but stick to the maximum speed defined as per<br>> > > firmware or config.txt. Shutting down the X server does not<br>> > > revert<br>> > > this.<br>> > > <br>> > > For me this seems to
be a gpu related issue ... ?<br>> > > <br>> > > Regards,<br>> > > Alex<br>> > > <br>> > > <br>> > > On Wed, 2024-03-13 at 14:27 +0100, Alex wrote:<br>> > > > > <br>> > > > <

> > > > There was a typo in my last statement...<br>> > > > <br>> > > > > oldstable 5.10 --> governor *is* working<br>> > > > > oldstable 6.1 backport --> governor not working<br>> &

gt; > > > oldstable 6.1 RT backport --> governor is working<br>> > > > > stable 6.1 --> governor is working<br>> > > > <br>> > > > <br>> > > > On Wed, 2024-03-13 at 13:41 +0100, Alex wrote:
<br>> > > > > Hi Andy,<br>> > > > > <br>> > > > > I see your point... however the governor working or not seems<br>> > > > > to<br>> > > > > be a<br>> > > > > pure
kernel issue, and Devuan does not support any arm<br>> > > > > platform<br>> > > > > and<br>> > > > > not build the generic kernels in the apt repository. Their<br>> > > > > repository<br>> &
gt; > > > is mainly fed from Debian one, with some changes when it<br>> > > > > comes<br>> > > > > to<br>> > > > > systemd vs. init.<br>> > > > > <br>> > > > > There are
prebuilt images for arm64 with custom compiled<br>> > > > > kernels<br>> > > > > without any method to do regular updates (they do not feed<br>> > > > > these<br>> > > > > kernels to the apt
repository). This is why I ended in<br>> > > > > compiling<br>> > > > > the<br>> > > > > kernel by myself in the first place. <br>> > > > > <br>> > > > > However, to be sure
it really is a kernel issue I gave<br>> > > > > 20231109_raspi_4_bookworm.img an try today and the governor<br>> > > > > worked.<br>> > > > > So I installed the 6.1 kernel from the stable repository on<br>>
> > > > my<br>> > > > > oldstable Devuan userland and still, the governor works.<br>> > > > > <br>> > > > > So, there seems to be a difference between the 6.1 oldstable<br>> > > > >
backport<br>> > > > > kernels vs. the ones in the stable repository.<br>> > > > > <br>> > > > > My first posts primary intention was not to get support (as I<br>> > > > > do<br>> > > &
gt; > have<br>> > > > > a running system), but to point out a possible bug which is<br>> > > > > present<br>> > > > > in some Debian arm64 kernels, while others are working fine.<br>> > > > >
<br>> > > > > oldstable 5.10 --> governor not working<br>> > > > > oldstable 6.1 backport --> governor not working<br>> > > > > oldstable 6.1 RT backport --> governor working<br>> > > > &
gt; stable 6.1 --> governor working<br>> > > > > <br>> > > > > So after all, this does not seem to be a Devuan issue. I'd be<br>> > > > > glad to<br>> > > > > help tracking down this issue.<

> > > > > <br>> > > > > Alex<br>> > > > > <br>> > > > > On Tue, 2024-03-12 at 22:26 +0000, Andrew M.A. Cater wrote:<br>> > > > > > On Tue, Mar 12, 2024 at 11:14:10AM +0100,

Alex wrote:<br>> > > > > > > Hi there,<br>> > > > > > > <br>> > > > > > > I am running a Raspberry Pi 4 with an oldstable release<br>> > > > > > > for<br>> > > &
gt; > > > a<br>> > > > > > > few<br>> > > > > > > years<br>> > > > > > > now. In fact, it is Devuan Chimaera, corresponding to<br>> > > > > > > Debian<br>> &
gt; > > > > > 11<br>> > > > > > > Bookworm without systemd. As the kernel images comes<br>> > > > > > > straight<br>> > > > > > > from<br>> > > > > > >
Debian, I am reporting it here...<br>> > > > > > > <br>> > > > > > <br>> > > > > > Can I respectfully suggest that you ask Devuan for help?<br>> > > > > > <br>> > > > &
gt; > if you use the images at <a href="http://raspi.debian.net" rel="noreferrer" target="_blank">raspi.debian.net</a>, we may be able<br>> > > > > > to<br>> > > > > > help<br>> > > > > > you.<br>&
gt; > > > > > If you want to try booting using UEFI and a stock Debian<br>> > > > > > image,<br>> > > > > > we<br>> > > > > > can also offer advice.<br>> > > > > > <br>
> > > > > > For Devuan - we cannot be entirely sure that the advice we<br>> > > > > > give<br>> > > > > > will<br>> > > > > > be correct.<br>> > > > > > <br>> &
gt; > > > > With every good wish, as ever,<br>> > > > > > <br>> > > > > > Andy<br>> > > > > > <br>> > > > > > > Alex<br>> > > > > > > <br>> >
> > > > <br>> > > > > <br>> > > > <br>> > > <br>> > <br>> > <br>> <br>> <br></div><div><br></div><div><br></div></blockquote></div><div><br clear="all"><br><span class="gmail_signature_
prefix">-- </span><br></div><div dir="ltr" class="gmail_signature"><div dir="ltr">Beautiful Sunny Winfield</div></div></blockquote><div><br></div><div><span></span></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From Alex@21:1/5 to Hank Barta on Thu Mar 21 12:10:01 2024

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Who's Online
Recent Visitors
- Thlc
  Sat Sep 13 17:11:34 2025
  from Rognac, France via Telnet
- Thlc
  Sat Sep 13 17:04:03 2025
  from Rognac, France via Telnet
- Thlc
  Sat Sep 13 16:32:19 2025
  from Rognac, France via SSH
- Thlc
  Sat Sep 13 15:41:11 2025
  from Rognac, France via SSH
- Thlc
  Sat Sep 13 07:56:03 2025
  from Rognac, France via SSH
- Gretchiie
  Sat Sep 13 07:22:10 2025
  from Derry, Nh via Telnet
- Thlc
  Sat Sep 13 06:57:56 2025
  from Rognac, France via SSH
- Thlc
  Sat Sep 13 06:47:28 2025
  from Rognac, France via SSH

System Info

Sysop:	Keyop
Location:	Huddersfield, West Yorkshire, UK
Users:	546
Nodes:	16 (2 / 14)
Uptime:	148:28:23
Calls:	10,383
Calls today:	8
Files:	14,054
D/L today:	2 files (1,861K bytes)
Messages:	6,417,747

Re: Governor problem with generic 6.1 arm64 kernel on Raspberry

Who's Online

Recent Visitors

System Info