On Sat, 17 May 2025 22:33:23 -0500
Aaron Rainbolt <arainbolt@xxxxxxxxxx> 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?
