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