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