How to find out why my CPUs' frequencies are limited

This document is intended to track down this nasty problem on Linux.
It is mainly focused on ACPI driven X86 machines with AMD and Intel's
CPU frequency technologies PowerNow! and SpeedStep.

There are generally two possibilities how BIOS can tell OS to limit freq:
  1) Via _PPC call, directly telling the OS which frequencies it must not use
  2) Via a thermal zone's passive trip point. If the temperature of the trip
     point exceeds the passive trip point, OS has to reduce the frequency
     following a specific algorithm. Immediate frequency drops from 3G (max) to
     800M (min) are not typical (possible?).

There is a broken possibility:
  3) BIOS/HW just limits maximum frequency behind the OS back.

Both only exists on ACPI driven platforms

1) Via _PPC call

On latest kernels you can check on ACPI driven machines (not copy and pasted):
/sys/devices/system/cpu/cpu0/cpufreq/bios_limit

If this is not max, BIOS limited your freq.
This can be ignored by passing processor.ignore_ppc=1 boot param

2) Via passive cooling

Hm, I don't have a laptop here, /sys is more relevant as this info will vanish,
TBD: Extend with sys info...

grep -r . /proc/acpi/thermal_zone
will show you the current temperature and passive trip point values of your thermal zones (and a bit more...).
If passive trip point is higher than the temperature value of the corresponding thermal zone, the thermal driver will cause the cpufreq subsystem to lower the maximum frequency.

3) BIOS/HW just limits maximum frequency behind the OS back.

In that case you could see "out of sync" (or similar) message if CPU_FREQ_DEBUG is compiled in and debug mode is turned on via:
echo 7 >/sys/module/cpufreq/parameters/debug
or cpufreq.debug=7 boot param.

Or check:
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
which should make the cpufreq driver read the current frequency directly from HW, instead assuming the last set frequency is still the current one  as done in scaling_cur_freq.

But scaling_max_freq should not be affected by 3.