On Tuesday, 15 March 2022 13:32:37 CET Hank Barta wrote: > 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 I lack the knowledge to properly/fully understand the issue Gunnar linked to, but it looks applicable ... still (despite the last msg indicating the issue was fixed). I don't know exactly the role that clocks play, but they seem quite important. And when the value of a/multiple clock(s) return 0, it doesn't surprise me that it would cause other things to fail, like the ones you reported above, which in turn cause the CPU (f.e.) to be way slower then it can be. Personally I think it's more useful if Hank reported the issue himself to https://github.com/raspberrypi/firmware/ then let Gunnar do it on his behalf. Having a bug in Debian's BTS (against raspi-firmware) regarding this issue seems useful as well and with the 'forwarded' keyword it can be linked to the upstream issue. Cheers, Diederik
Attachment:
signature.asc
Description: This is a digitally signed message part.