Some additional information that might be useful is that the system seems unable to determine CPU frequencies. For example
root@up:~# cpupower frequency-info
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
CPUs which run at the same hardware frequency: Not Available
CPUs which need to have their frequency coordinated by software: Not Available
maximum transition latency: Cannot determine or is not supported.
Not Available
available cpufreq governors: Not Available
Unable to determine current policy
current CPU frequency: Unable to call hardware
current CPU frequency: Unable to call to kernel
root@up:~# ls /sys/devices/system/cpu/cpu0/
cpu_capacity crash_notes_size node0/ power/
subsystem/ uevent
crash_notes hotplug/ of_node/ regs/
topology/
root@up:~# ls -l /sys/devices/system/cpu/cpu0/
total 0
-r--r--r-- 1 root root 4096 Mar 15 12:22 cpu_capacity
-r-------- 1 root root 4096 Mar 15 12:22 crash_notes
-r-------- 1 root root 4096 Mar 15 12:22 crash_notes_size
drwxr-xr-x 2 root root 0 Mar 15 12:22 hotplug
lrwxrwxrwx 1 root root 0 Mar 15 12:22 node0 -> ../../node/node0
lrwxrwxrwx 1 root root 0 Mar 15 12:22 of_node -> ../../../../firmware/devicetree/base/cpus/cpu@0
drwxr-xr-x 2 root root 0 Mar 15 12:22 power
drwxr-xr-x 3 root root 0 Mar 15 12:22 regs
lrwxrwxrwx 1 root root 0 Jan 1 1970 subsystem -> ../../../../bus/cpu drwxr-xr-x 2 root root 0 Mar 15 12:16 topology
-rw-r--r-- 1 root root 4096 Jan 1 1970 uevent
root@up:~#
Whereas on a Pi 4B running Bullseye without this issue
hbarta@kweli:~$ cpupower frequency-info
analyzing CPU 0:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: Cannot determine or is not supported.
hardware limits: 600 MHz - 2.00 GHz
available frequency steps: 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30 GHz, 1.40 GHz, 1.50 GHz, 1.60 GHz, 1.70 GHz, 1.80
GHz, 1.90 GHz, 2.00 GHz
available cpufreq governors: performance schedutil
current policy: frequency should be within 600 MHz and 2.00 GHz.
The governor "schedutil" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 600 MHz (asserted by call to kernel)
hbarta@kweli:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 2000000
hbarta@kweli:~$
The second example shows a Pi that has been overclocked and in fact, I discovered this issue when I tried to overclock a Pi 4B running Bookworm. I also discovered that the system did not respond to the settings in /boot/firmware/config.txt that are used to overclock. The following
settings seem to have no effect
arm_freq=2000
over_voltage=6
gpu_freq=750
best,
On Tue, Mar 15, 2022 at 6:13 AM Diederik de Haas <
didi.debian@cknow.org>
wrote:
On Tuesday, 15 March 2022 05:20:02 CET Gunnar Wolf wrote:
Given you have already pursued the situation to this detail, could you share... between which versions do you see the regression?
raspi-firmware/testing 1.20220120+ds-1 arm64 [upgradable from: 1.20210805+ds-1]
--
Beautiful Sunny Winfield
<div dir="ltr">Some additional information that might be useful is that the system seems unable to determine CPU frequencies. For example<div><br></div><div><font face="monospace">root@up:~# cpupower frequency-info<br>analyzing CPU 0:<br> no or
unknown cpufreq driver is active on this CPU<br> CPUs which run at the same hardware frequency: Not Available<br> CPUs which need to have their frequency coordinated by software: Not Available<br> maximum transition latency: Cannot determine or
is not supported.<br>Not Available<br> available cpufreq governors: Not Available<br> Unable to determine current policy<br> current CPU frequency: Unable to call hardware<br> current CPU frequency: Unable to call to kernel<br>root@up:~# ls /
sys/devices/system/cpu/cpu0/ <br>cpu_capacity crash_notes_size node0/ power/ subsystem/ uevent <br>crash_notes hotplug/ of_node/ regs/
topology/ <br>root@up:~# ls -l /sys/devices/system/cpu/cpu0/<br>total 0<br>-r--r--r-- 1 root root 4096 Mar 15 12:22 cpu_capacity<br>-r-------- 1 root root 4096 Mar 15 12:22 crash_notes<br>-r-------- 1 root root 4096 Mar 15 12:
22 crash_notes_size<br>drwxr-xr-x 2 root root 0 Mar 15 12:22 hotplug<br>lrwxrwxrwx 1 root root 0 Mar 15 12:22 node0 -> ../../node/node0<br>lrwxrwxrwx 1 root root 0 Mar 15 12:22 of_node -> ../../../../firmware/devicetree/base/cpus/cpu@
0<br>drwxr-xr-x 2 root root 0 Mar 15 12:22 power<br>drwxr-xr-x 3 root root 0 Mar 15 12:22 regs<br>lrwxrwxrwx 1 root root 0 Jan 1 1970 subsystem -> ../../../../bus/cpu<br>drwxr-xr-x 2 root root 0 Mar 15 12:16 topology<br>-rw-r--
r-- 1 root root 4096 Jan 1 1970 uevent<br>root@up:~#</font></div><div><br></div><div>Whereas on a Pi 4B running Bullseye without this issue</div><div><br></div><div><font face="monospace">hbarta@kweli:~$ cpupower frequency-info<br>analyzing CPU 0:<br>
driver: cpufreq-dt<br> CPUs which run at the same hardware frequency: 0 1 2 3<br> CPUs which need to have their frequency coordinated by software: 0 1 2 3<br> maximum transition latency: Cannot determine or is not supported.<br> hardware
limits: 600 MHz - 2.00 GHz<br> available frequency steps: 600 MHz, 700 MHz, 800 MHz, 900 MHz, 1000 MHz, 1.10 GHz, 1.20 GHz, 1.30 GHz, 1.40 GHz, 1.50 GHz, 1.60 GHz, 1.70 GHz, 1.80 GHz, 1.90 GHz, 2.00 GHz<br> available cpufreq governors: performance
schedutil<br> current policy: frequency should be within 600 MHz and 2.00 GHz.<br> The governor "schedutil" may decide which speed to use<br> within this range.<br> current CPU frequency:
Unable to call hardware<br> current CPU frequency: 600 MHz (asserted by call to kernel)<br>hbarta@kweli:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq<br>2000000<br>hbarta@kweli:~$</font> <br></div><div><br></div><div>The second example
shows a Pi that has been overclocked and in fact, I discovered this issue when I tried to overclock a Pi 4B running Bookworm. I also discovered that the system did not respond to the settings in /boot/firmware/config.txt that are used to overclock. The
following settings seem to have no effect</div><div><br></div><div><font face="monospace">arm_freq=2000<br>over_voltage=6<br>gpu_freq=750</font><br></div><div><br></div><div> best,<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_
attr">On Tue, Mar 15, 2022 at 6:13 AM Diederik de Haas <<a href="mailto:
didi.debian@cknow.org">
didi.debian@cknow.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-
left:1ex">On Tuesday, 15 March 2022 05:20:02 CET Gunnar Wolf wrote:<br>
> Given you have already pursued the situation to this detail, could you<br> > share... between which versions do you see the regression?<br>
raspi-firmware/testing 1.20220120+ds-1 arm64 [upgradable from: 1.20210805+ds-1]</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Beautiful Sunny Winfield</div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)