"scaling_cur_freq" or vcgencmd showing inplausible values since upgrading to kernel 4.19.97-v7l+

[bcutter]

Pi 4 4 GB was running absolutely smooth and stable for more than 80 days until 2020-02-07 when I manually rebooted the system to make the newest kernel update active. System is overclocked with

arm_freq=1950
over_voltage=4

Since that kernel update cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq (which is used to check the current clock speed) gives values of 2000000 (= 2.0 GHz).

vcgencmd get_config int confirms the above noted overclocking settings (1.95 GHz) of /boot/confg.txt.

Why can clock speed using "scaling_cur_freq" now show 2.00 GHz?

By the way:

1. "sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq" gives maximum of 1950000 (1.95 GHz), matching the overclocking settings.
2. Whole system behaviour (quite unstable in terms of USB interrupt handling, resulting in unmounting of USB flash drives and sudden reboots) is like when testing overclocking with "arm_freq=2000" some weeks ago. 1950 was found and proven to be a very stable value.

So what can I believe: is system overclocked to 1950 or 2000 MHz? Is "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq" showing rubbish?

Either "scaling_cur_freq" file shows rubbish or "vcgencmd get_config int" does.

[JamesH65]

The code that deal with voltages and frequencies has changed considerably to reduce thermal loads. It may be that 1950 is no longer a valid value and it has used the closest one. That level of over voltage and that sort of ARM speed is a very large ask of the silicon, as I suspect you are right on the edge of failing. I'd be inclined to start again to find a reliable set of overclock values, although note that we do no guarantee that any overclocks will work, and we cannot guarantee that changes to firmware will not affect existing overclocks in the future.

[pelwell]

The clock speed value you can trust most is the output of "vcgencmd measure_clock arm" (or "... core" for the VPU clock). This uses a hardware clock pulse counter to measure the real frequency. Because the counter is started and stopped from software and measured against the 1MHz system timer there is a small amount of jitter in the measurement, but running this a few times should give an accurate reading,

[bcutter]

Alright thank you James for the explanation. In fact there are strange numbers shown, in the past there was never ever a value "1333" (which is now).

So my summary is:

1. The actual clock is the one shown by vcgencmd get_config int | grep arm_freq
2. Using sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq or vcgencmd measure_clock arm should now be the most reliable way of getting the actual current clock speed, where cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq is likely to be unreliable because it is maybe rounded or sth. like that.
3. It is likely the max. overclocking setting 1950 MHz might be a bit too much now because of changed kernel settings.

Correct?

Update @pelwell: Thanks for that, wasn´t aware of this command. Will take a look at it and maybe implement this for my clocking and fan control monitoring scripts.

[pelwell]

It is likely the max. overclocking setting 1950 MHz might be a bit too much now because of changed kernel settings.

Every kernel build will slightly alter the sequence of instructions. Also, every physical instance of an SoC (i.e. every Pi) will have slightly different characteristics with respect to silicon "speed" - not just between chips but within them (they aren't completely uniform across the dies). As a result, there's a chance that changing kernel builds will give different maximum "safe" clock speeds on any given Pi, not because of improvements or regressions, but just because they are different.

[kosmosgit]

Before this update everything was stable at 2147 MHz, the ondemand governator even switched up to 2294 MHz (display with the start tool CPUfreq Frontend) despite arm_freq = 2147. But now the Raspberry crashes when you start the browser. So had to go back down to 2000 MHz. And the temperature has even risen slightly, you should readjust here.

Now i test the pre-release Kernel 4.19.102 and the error is still there.

Perhaps all valid clock values could be named. Then you could adjust the governor appropriately.

[bcutter]

For me stability (long-term) tests are still running, but switching from arm_freq = 1950 to 1800 MHz seems a quite stable one currently. So a theoretical loss of 150 MHz. Well, performance is nice but I prefer a stable system. Finger´s crossed.

[JamesH65]

Before this update everything was stable at 2147 MHz, the ondemand governator even switched up to 2294 MHz (display with the start tool CPUfreq Frontend) despite arm_freq = 2147. But now the Raspberry crashes when you start the browser. So had to go back down to 2000 MHz. And the temperature has even risen slightly, you should readjust here.

Now i test the pre-release Kernel 4.19.102 and the error is still there.

Perhaps all valid clock values could be named. Then you could adjust the governor appropriately.

All of our work in this area is designed to improve things for normal users - ie those that run the Pi at standard settings - there's a reason they are standard, and that is that we ensure they always work. Whilst overclocking is allowed, we do not guarantee that it will continue to work in the same way between firmware released (unlike standard settings), and we don't put anywhere near the same amount of testing in to these unsupported areas. Your overclock of 2147 is huge, over 30% above standard. You should have no expectation the device will continue to run at that speed over different firmware releases. As for valid clock values, these are in flux at the moment as various changes are made to the firmware to improve temperature control at standard settings. Once they have settled down, I will fix up the documentation.

[JamesH65]

I believe overclocking issues are fixed in the latest firmware. So this issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[bcutter]

I believe overclocking issues are fixed in the latest firmware. So this issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

Sounds promising 👍🏼 Does it mean the former overclocking settings are safe to be restored (or at least worth a try)?

And what exact firmware?

[JamesH65]

AIUI they should work similarly to previously. Perhaps faster in some cases.

apt update && apt full-upgrade should get everything you need.

[JamesH65]

Please close this issue if all is now working.

[bcutter]

Couldn’t find an update yet.

uname -a gives

4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Therefore could not test higher ich values.

As soon as update appears I’ll test and close the issue after few days.

[popcornmix]

4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

You have the latest apt version. It contains all the fixes.

[bcutter]

I tested the overclocking setup by reverting back to the values used before the kernel firmware update.
2.000 MHz: rebooted immediately after 2 min. system update
1.950 MHz: same issues as before (USB problems unmounting flash drives and killing services depending on it etc. - happened within a few minutes)

Therefore there´s no positive change at all (overclocking issues are NOT fixed) - in my case. I simply reverted back to the "post kernel update" stable value of 1.800 MHz for my hardware. And I´ve not enough time to tweak & test more on this, I´ll never get back that time by improved cpu performance. So I´ll just live with that and crossing fingers for the next kernel updates.

As this issue was originally adressing another topic I´m closing this issue now.