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

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

[Aaron Rainbolt]

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).

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

[srinivas pandruvada]

On Sat, 2025-05-17 at 22:33 -0500, Aaron Rainbolt 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. 
> 

I think this is similar to
https://lkml.indiana.edu/2504.3/04971.html

The issue is the BIOS didn't program frequencies correctly in ACPI
CPPC. So frequency limits will be wrong.

You can dump the following values and also the details about the system
under test (OEM, model etc).

grep -r . /sys/devices/system/cpu/cpu*/acpi_cppc/*


Thanks,
Srinivas

> 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).

Re: [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@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?

Re: [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@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