Comment 10 for bug 2051733

The way it is currently done, I don't think valid CPU frequency listing via "scaling_cur_freq", or /proc/cpuinfo, is expected to work. Why not? Because the required code is never executed, on purpose. Here is an excerpt from a commit (see the bit about NOHZ full)

commit f3eca381bd49d708073ba1a9af4fa6ea5d5810a6
Author: Thomas Gleixner <email address hidden>
Date: Fri Apr 15 21:20:04 2022 +0200

    x86/aperfmperf: Replace arch_freq_get_on_cpu()

    Reading the current CPU frequency from /sys/..../scaling_cur_freq involves
    in the worst case two IPIs due to the ad hoc sampling.

    The frequency invariance infrastructure provides the APERF/MPERF samples
    already. Utilize them and consolidate this with the /proc/cpuinfo readout.

    The sample is considered valid for 20ms. So for idle or isolated NOHZ full
    CPUs the function returns 0, which is matching the previous behaviour.

There was couple of later commits and now it prints out the minimum CPU frequency when it thinks the number are stale. With NOHz full it always thinks the numbers are stale.

The intel_cpufreq driver seems to display CPU frequencies okay, but only the pstate that was requested, not the actual frequency granted.