Bug 6558

Summary:	Cpufreq reports nominal CPU speed instead of actual
Product:	Power Management	Reporter:	Markus Strobl (mstrobl2)
Component:	cpufreq	Assignee:	cpufreq (cpufreq)
Status:	REJECTED INVALID
Severity:	normal	CC:	akpm, davej, esigra, kernel, trenn, venki
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.16	Subsystem:
Regression:	---	Bisected commit-id:

Description Markus Strobl 2006-05-15 08:14:48 UTC

Most recent kernel where this bug did not occur: 2.6.15
Distribution: Gentoo-AMD64
Hardware Environment: 
Software Environment:
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
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq"
================== 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.

Comment 1 Andrew Morton 2007-01-31 01:25:37 UTC

Dave, I think this was deliberate, wan't it?

Comment 2 Dave Jones 2007-01-31 14:13:36 UTC

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.