openSUSE 16.0/1 uses kernel 6.12, broken scaling_cur_freq (at least on Ryzen)

English Install/Boot/Login
1

So, noticed that 16.0 and 16.1 use kernel 6.12. The /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq doesn’t not adjust dynamically to CPU frequency. As a not so great work around out of sysfs, you can use cpuinfo_avg_freq instead (which does update).

I use Level1tech’s siomon, and did a code change to use that workaround for now. Otherwise, at least on my Ryzen 9900X platform, the values stay such at 613954 (614Mhz) even when the cores are all clocking well above 5Ghz.

So, since 6.1 seems to use this kernel as well, not sure what it would take to backport patches to properly handle the CPU freq. Was sort of hoping for a upgrade to fix this.

2

@cjcox what frequency scaler module was it using before for AMD?

On older intel I add intel_pstate=passive I suspect there is an AMD equivalent.

3

Another thought is the power-profiles-daemon is it installed and service running?

I have an older AMD E2-7110 APU with AMD Radeon R2 Graphics, it was scaling fine and using “acpi-cpufreq” I installed the daemon here on GNOME and can now select balanced etc.

4

More data (showing the problem), below run while a stress-ng --cpu 24 was run. So, all clocks on all cores were well above 5Ghz. (see the current frequency below listed at 614Mhz)

> sudo cpupower frequency-info
analyzing CPU 4:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 4
  CPUs which need to have their frequency coordinated by software: 4
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 614 MHz - 5.66 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 614 MHz and 5.66 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 614 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    AMD PSTATE Highest Performance: 166. Maximum Frequency: 5.66 GHz.
    AMD PSTATE Nominal Performance: 129. Nominal Frequency: 4.40 GHz.
    AMD PSTATE Lowest Non-linear Performance: 18. Lowest Non-linear Frequency: 614 MHz.
    AMD PSTATE Lowest Performance: 18. Lowest Frequency: 600 MHz.

Looking at actual frequency:

> cat /proc/cpuinfo | grep "MHz"
cpu MHz         : 5297.471
cpu MHz         : 5297.519
cpu MHz         : 5297.513
cpu MHz         : 5297.456
cpu MHz         : 5297.446
cpu MHz         : 5297.485
cpu MHz         : 5142.102
cpu MHz         : 5142.105
cpu MHz         : 5142.131
cpu MHz         : 5142.102
cpu MHz         : 5142.031
cpu MHz         : 5142.074
cpu MHz         : 5297.455
cpu MHz         : 5297.437
cpu MHz         : 5297.504
cpu MHz         : 5297.487
cpu MHz         : 5297.427
cpu MHz         : 5297.482
cpu MHz         : 5142.057
cpu MHz         : 5142.101
cpu MHz         : 5142.105
cpu MHz         : 5142.065
cpu MHz         : 5142.049
cpu MHz         : 5142.117
5

https://docs.kernel.org/admin-guide/pm/amd-pstate.html so the epp is;

Energy Performance Preference (EPP) (RW)
This attribute provides a hint to the hardware if software wants to bias toward performance (0x0) or energy efficiency (0xff).

See if the following makes a difference;

update-bootloader --add-option amd_pstate=passive
update-bootlader --config

To remove just use --del-option <flag> and update the config.

6

It seems the amd_pstate=active flag enables the epp version. You don’t have that added cat /proc/cmdline?

7

I think there’s some confusion. It’s only the value of current CPU frequency that is a constant and incorrect. Frequencies are changing as I’ve shown.

8

Use the -c N or -c all will show other cpu’s, but cpupower frequency-info will pick a random core.

9

The way I understand the kernel doc is with the epp part is new and if the software wants performance, then it will use. If you want the previous operation (pre 6.12 kernel) then you need to add the option with passive, not active (which I think is default).

10

We are still not communicating. The CPU goes to way over 5Ghz on all cores.

However the value in the kernel for sysfs under any CPU load condition stays at a fixed value for /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq of 613954 (614Mhz) which is wrong. So, anything that looks to that kernel value to be representative of the current running frequency always gets 614Mhz no matter what. And that is wrong. The only post I saw close to this was someone on a RPi forum saying there might be a problem in kernel 6.12.

11

No, I understand what your saying, but my theory is the reporting and the module may be bypassing that setting. Can you confirm if adding that option (passive) does change the scaling_cur_freq?

If not, then a bug report is likely needed…

12

Well, switching to OS controlled does make it work, so I guess that “active” has no control over the sysfs value… which, maybe makes sense (?), but there are plenty of tools that only measure the active frequency that way, so, IMHO, all those software programs, including siomon from Level1Tech are doing it wrong. Frustrating.

13

So it would seem the new default “epp” (active) is working as designed… :wink: