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