On Tue, 2025-07-22 at 11:31 -0500, Aaron Rainbolt wrote:
> 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?
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
