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

[srinivas pandruvada]

On Tue, 2025-07-22 at 11:31 -0500, Aaron Rainbolt wrote:
> 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?
I asked for some dumps before. We can try to inform the OEM of the
system as this is a BIOS tables issue. What is the make and model of
your system?

Thanks,
Srinivas