[BUG] intel_pstate: CPU frequencies miscalculated/incorrectly detected on Arrow Lake hardware

[Aaron Rainbolt]

On Sat, 17 May 2025 22:33:23 -0500
Aaron Rainbolt <arainbolt at kfocus.org> wrote:

> We have tested three systems with Arrow Lake CPUs, and all of them
> report incorrect max and base frequencies. Two systems have Ultra 9
> 275 HX CPUs, and one has an Ultra 5 225 H. The problem occurs with
> both the Ubuntu 6.11 kernel and the 6.14.6 mainline kernel.
> 
> How these values are misreported appears to depend on the CPU. On the
> Ultra 9 275HX systems when running Ubuntu’s 6.11.0-1015-oem kernel,
> the max reported frequency on a golden core is 5000000; however, the
> CPU spec says it should be 5400000. In contrast, on an Ultra 5 225H
> system, the max reported frequency on a golden core is 6200000;
> however, the spec says it should be 4900000. 
> 
> This bug is troublesome to end users because many CPU monitoring apps
> will report the CPU is running quite a bit slower or faster than the
> spec. Tools such as cpupower-gui, cpufreq-info, and cpufreq-set all
> show incorrect values because they read cpuinfo_max_freq and
> base_frequency, and write scaling_max_freq values in
> /sys/devices/system/cpu/cpufreq/policy* directories. 
> 
> The following bash script shows the incorrect values read from the
> cpuinfo_max_freq and base_frequency files. It also shows how the
> actual max frequencies attained are as expected. The example values
> shown come from an Ultra 9 275 HX CPU.
> 
>     echo; echo '== BEGIN ==';
>     echo 'Ensure turbo is on';
>     cd /sys/devices/system/cpu;
>     echo '0' |sudo tee intel_pstate/no_turbo > /dev/null;
>     if grep -q '0' intel_pstate/no_turbo; then echo 'Turbo is on'; fi
> 
>     echo; echo 'Find top 2 golden cores';
>     cd /sys/devices/system/cpu/cpufreq/;
>     grep . policy*/cpuinfo_max_freq \
>       | awk -F: '{print $2" "$1}' |sort -rn | head -n2;
>     #> 5000000 policy2/cpuinfo_max_freq
>     #> 5000000 policy3/cpuinfo_max_freq  
> 
>     echo; echo 'Confirm misreporting: per spec, this should be
> 5400000!'; grep . policy2/cpuinfo_max_freq; # 500000
> 
>     echo; echo 'Confirm misreporting: per spec, this should be
> 2700000!' grep . policy2/base_frequency; # 2500000
> 
>     echo; echo '# Run a CPU benchmark now, then press [ Enter ] to
> see top 3 freqs.'; echo 'This will take 6 seconds to complete.';
>     read -r -p '# You should see that the freqs match the CPU specs.
> ';\ for i in {0..5}; do
>       grep . policy*/scaling_cur_freq | awk -F: '{print $2" "$1}';
>       sleep 1;
>     done |sort -rn |head -n3 
>     #> 5400000 policy2/scaling_cur_freq
>     #> 5320159 policy2/scaling_cur_freq
>     #> 5241886 policy3/scaling_cur_freq  
> 
>     echo; echo '== END   =='; echo;
> 
> The actual results, when running the above script, shows the
> cpuinfo_max_freq and base_frequencies values do not match those
> specified by Intel. With the 6.11.0-1021-oem Ubuntu Kernel, we see the
> following:
> 
> | Turbo? | Core | Freq (spec) | Freq (report) | Freq (actual) |
> | Yes    | P    | 5.4 GHz     | 5.0 GHz       | 5.4 GHz       |
> | No     | P    | 2.7 GHz     | 2.5 GHz       | 2.7 GHz       |
> | Yes    | E    | 4.6 GHz     | 4.6 GHz       | 4.6 GHz       |
> | No     | E    | 2.1 GHz     | 2.1 GHz       | 2.1 GHz       |
> 
> We have verified the cores are operating at their specified
> frequencies by running a demanding CPU benchmark while graphing
> frequencies with KDE System Monitor, on all 3 systems. This tool
> appeared to graph scaling_cur_freq values. Notice E-cores appear to
> be correctly reported. Also, all systems misinterpret values written
> to scaling_max_req with the apparent same error deltas: on the Ultra
> 9 275 HX, setting this value to 5000000 results in actual max
> frequencies of 5400000. Setting it to 2500000 results in max 2700000.
> Setting it to 1650000 results in max 2100000.
> 
> The behavior with the 6.14.6 kernel is worse than with 6.11, with all
> values under-reported. Actual frequencies were not tested on 6.14.6:
> 
> | Turbo? | Core | Freq (spec) | Freq (report) |
> | Yes    | P    | 5.4 GHz     | 3.9 GHz       |
> | No     | P    | 2.7 GHz     | 2.0 GHz       |
> | Yes    | E    | 4.6 GHz     | 3.3 GHz       |
> | No     | E    | 2.1 GHz     | 1.5 GHz       |
> 
> Is it possible the math currently used for calculating CPU frequencies
> is no longer correct for Arrow Lake CPUs? This seems similar to the
> issue that was fixed by commit f5c8cf2 (cpufreq: intel_pstate: hybrid:
> Use known scaling factor for P-cores).

Following up on this, is there any update or possible fix we could
test?