Governor problem with generic 6.1 arm64 kernel on Raspberry

[Alex]

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.

***@aws:~:(1)> uname -a
Linux aws 6.1.77-v8+ #17 SMP PREEMPT Mon Mar 11 15:51:14 CET 2024
aarch64 GNU/Linux
***@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0
***@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
***@aws:cpu/cpufreq/policy0:(4)> cat scaling_driver scaling_governor
cpufreq-dt
schedutil
***@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
---
***@aws:cpu/cpufreq/policy0:(10)>

Reboot the same system with generic kernel...

***@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
***@aws:~:(2)> cd /sys/devices/system/cpu/cpufreq/policy0
***@aws:cpu/cpufreq/policy0:(3)> cat scaling_driver scaling_governor
cpufreq-dt
schedutil
***@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
---
***@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

[Alex]

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

Post by Alex
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.
Linux aws 6.1.77-v8+ #17 SMP PREEMPT Mon Mar 11 15:51:14 CET 2024
aarch64 GNU/Linux
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
cpufreq-dt
schedutil
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
---
Reboot the same system with generic kernel...
Linux aws 6.1.0-0.deb11.17-arm64 #1 SMP Debian 6.1.69-1~bpo11+1 (2024-
01-05) aarch64 GNU/Linux
scaling_governor
cpufreq-dt
schedutil
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
---
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

[Andrew M.A. Cater]

Post by Alex
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

Post by Alex
Alex

[Alex]

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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex

[Alex]

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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex

[Alex]

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

Post by Alex
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
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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex

[Alex]

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.


***@aws:~:(6)> cd /sys/devices/system/cpu/cpufreq/policy0/
***@aws:cpu/cpufreq/policy0:(4)> cat scaling_driver scaling_governor
cpufreq-dt
schedutil
***@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

Post by Alex
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

Post by Alex
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
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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex

[Alex]

That latest kernel I referred to is .76, not 69, sorry for the
confusion.

Post by Alex
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.
scaling_governor
cpufreq-dt
schedutil
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

Post by Alex
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

Post by Alex
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
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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex

[Hank Barta]

I'll give it a try.

***@cm4iob:~/bin$ cd /sys/devices/system/cpu/cpufreq/policy0/
***@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_driver
scaling_governor
cpufreq-dt
schedutil
***@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ cpufreq-dt
-bash: cpufreq-dt: command not found
***@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ schedutil
-bash: schedutil: command not found
***@cm4iob:/sys/devices/system/cpu/cpufreq/policy0$ foreach i ( `seq 1 1
10` )
-bash: syntax error near unexpected token `('
***@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

That latest kernel I referred to is .76, not 69, sorry for the
confusion.

Post by Alex
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.
scaling_governor
cpufreq-dt
schedutil
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

Post by Alex
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

Post by Alex
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
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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex

[Alex]

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

Post by Hank Barta
I'll give it a try.
scaling_driver scaling_governor
cpufreq-dt
schedutil
-bash: cpufreq-dt: command not found
-bash: schedutil: command not found
`seq 1 1 10` )
-bash: syntax error near unexpected token `('
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

Post by Alex

That latest kernel I referred to is .76, not 69, sorry for the
confusion.

Post by Alex
Hi,
Is there really no one who could and would just do that one

test

Post by Alex
for
me? I reproduced the problem with the actual 6.1.69 kernel from

the

Post by Alex
Debian repository.
1. Boot a Rasyberry Pi 4 without X or other graphics running.

Check

Post by Alex
if
scaling_cur_freq and cpuinfo_cur_freq are in line. You also

could

Post by Alex
query
by Raspberry userland (vcgencmd measure_clock arm), which is in

my

Post by Alex
case
always identical to cpuinfo_cur_freq.
scaling_governor
cpufreq-dt
schedutil
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

Post by Alex
from
the debian repository supports kms and accelerated X, which is

a

Post by Alex
great
achievement, by the way.
Repeat the tests. In my use case the cpuinfo_cur_freq is now

always

Post by Alex
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. 

Post by Alex
Thanks,
Alex

Post by Alex
I have to admit that I drew the wrong conclusions. Some of my
frequency readings were conducted within an x-terminal, some

on a

Post by Alex

Post by Alex
console screen, without X running. That, in fact, seemed to

make

Post by Alex

Post by Alex
the
difference.
Booting in any of the 6.1 upstream generic kernels works

fine,

Post by Alex

Post by Alex
including the governor, as long as I remained in text mode.

Also

Post by Alex

Post by Alex
switching between different governors immediately brought the
intended result. 
Once starting the X Server (X.Org 1.20.11 with either fbdev

or

Post by Alex

Post by Alex
fbturbo driver) causes the CPU frequency not following the scaling
frequency any more but stick to the maximum speed defined as

per

Post by Alex

Post by Alex
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

Post by Alex
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
Hi Andy,
I see your point... however the governor working or not

seems

Post by Alex

Post by Alex

Post by Alex

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

Post by Alex

Post by Alex

Post by Alex

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

Post by Alex

Post by Alex

Post by Alex

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

Post by Alex

Post by Alex

Post by Alex

worked.
So I installed the 6.1 kernel from the stable repository

on

Post by Alex

Post by Alex

Post by Alex

my
oldstable Devuan userland and still, the governor works.
So, there seems to be a difference between the 6.1

oldstable

Post by Alex

Post by Alex

Post by Alex

backport
kernels vs. the ones in the stable repository.
My first posts primary intention was not to get support

(as I

Post by Alex

Post by Alex

Post by Alex

do
have
a running system), but to point out a possible bug which

is

Post by Alex

Post by Alex

Post by Alex

present
in some Debian arm64 kernels, while others are working

fine.

Post by Alex

Post by Alex

Post by Alex

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

Post by Alex

Post by Alex

Post by Alex

glad to
help tracking down this issue.
Alex
On Tue, 2024-03-12 at 22:26 +0000, Andrew M.A. Cater

Post by Andrew M.A. Cater

Post by Alex
Hi there,
I am running a Raspberry Pi 4 with an oldstable

release

Post by Alex

Post by Alex

Post by Alex

Post by Andrew M.A. Cater

Post by Alex
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?

Post by Alex

Post by Alex

Post by Alex

Post by Andrew M.A. Cater
if you use the images at raspi.debian.net, we may be

able

Post by Alex

Post by Alex

Post by Alex

Post by Andrew M.A. Cater
to
help
you.
If you want to try booting using UEFI and a stock

Debian

Post by Alex

Post by Alex

Post by Alex

Post by Andrew M.A. Cater
image,
we
can also offer advice.
For Devuan - we cannot be entirely sure that the advice

we

Post by Alex

Post by Alex

Post by Alex

Post by Andrew M.A. Cater
give
will
be correct.
With every good wish, as ever,
Andy

Post by Alex
Alex

--
Beautiful Sunny Winfield

[Alex]

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

Boy, bash really did not like the line terminations in that file but
I finally identified the issue with the help of shellcheck
#!/bin/sh
         ^-- SC1017 (error): Literal carriage return. Run script
through tr -d '\r' .
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
Start gdm and login to Plasma/X11
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
Stop gdm (which results in blank screen except for blinking cursor,
upper left .)
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
Does this provide the information you are looking for?
best,

Post by Alex
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

Post by Hank Barta
I'll give it a try.
scaling_driver scaling_governor
cpufreq-dt
schedutil
-bash: cpufreq-dt: command not found
-bash: schedutil: command not found
( `seq 1 1 10` )
-bash: syntax error near unexpected token `('
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

That latest kernel I referred to is .76, not 69, sorry for the
confusion.

Post by Alex
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.
scaling_governor
cpufreq-dt
schedutil
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

Post by Alex
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

Post by Alex
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
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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex

--
Beautiful Sunny Winfield

--
Beautiful Sunny Winfield

[Alex]

That latest kernel I referred to is .67, not 69, sorry for the
confusion.

Post by Alex
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.
cpufreq-dt
schedutil
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

Post by Alex
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

Post by Alex
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
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

Post by Andrew M.A. Cater

Post by Alex
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

Post by Alex
Alex