Kernel Bug Tracker – Bug 6558
Cpufreq reports nominal CPU speed instead of actual
Last modified: 2007-02-11 00:53:13 UTC
Most recent kernel where this bug did not occur: 2.6.15
Problem Description: As of 2.6.16 the current CPU speed is reported as the
nominal speed instead of actual speed. On over or under clocked systems this
means that the true CPU speed is not shown. The problem is new as of 2.6.16.
/proc/cpuinfo is where the incorrect speed is included and this file is then
used by various utilities to display current CPU speed. This means the wrong CPU
speed is displayed in utilities such as KDE's KSysguard etc.
From GENTOO bug #131348, posted by Daniel Drake:
================= Start included text =================
What has happened is that as of 2.6.16, /proc/cpuinfo asks cpufreq for the
current frequency, and if that fails, it falls back on the old way (cpu_khz).
So your bug is that cpufreq does not show the real frequency -- you should be
able to confirm this by reading
================== End included text =================
Also see Gentoo bug 131348: http://bugs.gentoo.org/show_bug.cgi?id=131348
Steps to reproduce:
Change CPU speed by setting front side bus speed to any value except standard.
/proc/cpuinfo will show correct speed under 2.6.15 or earlier. Under 2.6.16 it
shows the incorrect nominal speed.
Dave, I think this was deliberate, wan't it?
If the FSB has been overclocked, we have no chance to report the correct speed.
The CPU can only report FSB values back to cpufreq that it knows about (Which
are typically the common 100/133/266 etc multiples. Go outside these, and all
bets are off).
If the CPU has a x10 multiplier and thinks its at 266FSB but the user has it
clocked up to 300, cpufreq will report 266*10, whilst it's actually running at
400MHz faster than we report.
Additionally, any BIOS tables detailing the frequencies the chip can run at are
determined using fixed FSB values. If that has an entry for "2.6GHz", that's
what cpufreq exports, since it's not based on what the FSB is actually running
at, but the FSB speed the platform supports.
There's really no good way to deal with this. There are good reasons not to
under/overclock, and this is one of them.