Bug 7186

Summary: p4-clockmod reports wrong MHz in /proc/cpuinfo desktop P4
Product: Power Management Reporter: Timothy Stotts (kernel_bugs)
Component: cpufreqAssignee: ykzhao (yakui.zhao)
Status: CLOSED CODE_FIX    
Severity: low CC: akpm, davej, kernel, linux, matthias.christian
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.18 Subsystem:
Regression: --- Bisected commit-id:
Attachments: Obtain FSB ration from model string when model id is less than 2
Restore the previous calc of FSB ration for model <2

Description Timothy Stotts 2006-09-22 11:19:11 UTC
Most recent kernel where this bug did not occur:
This always occurs since 2.6.16. No idea about earlier versions.

Distribution:
    Gentoo.  Verified bug with vanilla kernel.
Bug was originally filed at:
    http://bugs.gentoo.org/show_bug.cgi?id=141234
Possibly related:
    Bug 6367

Hardware Environment:
    Dell Dimension 8100
    Pentium 4 1300 MHz w/ RDRAM from mid-2001

Software Environment:
    N/A

Problem Description:
    p4-clockmod produces wrong MHz statistics in /proc/cpuinfo
    Simple benchmark with Perl script adding 1000s of integers shows that the 
frequency scaling works correctly and that the CPU is not being over-clocked.

Steps to reproduce:

#### (1) without p4-clockmod loaded:
# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 0
model name	: Intel(R) Pentium(R) 4 CPU 1300MHz
stepping	: 7
cpu MHz		: 1285.413
cache size	: 256 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips	: 2573.13

#### (2) with p4-clockmod loaded:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
525000 787500 1050000 1312500 1575000 1837500 2100000
# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 0
model name	: Intel(R) Pentium(R) 4 CPU 1300MHz
stepping	: 7
cpu MHz		: 2100.000
cache size	: 256 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 2
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips	: 2573.13
Comment 1 Dave Jones 2006-09-22 13:24:50 UTC
We've changed so little in this driver that I'm almost convinced this has to be
an ACPI regression.  Either that, or we've started taking interest in some
different ACPI tables that we didn't used to, and your BIOS happens to contain
nonsense values.

Acpi folks, what say you?
Comment 2 Venkatesh Pallipadi 2006-09-22 14:36:07 UTC
This looks like a bug in speedstep-lib. 

Similar issue was posted on cpufreq some time back

-----
>A Gentoo user at http://bugs.gentoo.org/141234 reports that the 
>p4-clockmod cpufreq driver reports bad frequencies for his 1300mhz 
>Pentium 4 processor:
>
># cat sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
>525000 787500 1050000 1312500 1575000 1837500 2100000
-----

I responded to it at that time as below..

-----
The root of the problem seems to be this line at
arch/i386/kernel/cpu/cpufreq/speedstep-lib.c:pentium4_get_frequency()

if (c->x86_model < 2)
	mult = msr_lo >> 27;

The CPU model on this system here is 0. As I see in the documentation,
multiplier is not defined in MSR_EBC_FREQUENCY_ID for model 0. So, we
are getting the wrong estimate of the processor frequency.

Dominik may have more history about this.
Dominik: did this >> 27 work on any P4 with model 0 and 1 at all?

Note that this is only a reporting issue. Even with this bug, top speed
of the CPU will always be 1.3 and with P4_clock mod, CPU speed will vary
according to scale by (1/8th) for every lower P-state.

-----

Is Dominik the maintainer of speedstep-lib? I didn't hear anything back from 
him on this one...

Thanks,
Venki
Comment 3 Anonymous Emailer 2006-10-01 18:23:51 UTC
Reply-To: linux@dominikbrodowski.net

Hi,

On Fri, Sep 22, 2006 at 02:46:08PM -0700, bugme-daemon@bugzilla.kernel.org wrote:
> The root of the problem seems to be this line at
> arch/i386/kernel/cpu/cpufreq/speedstep-lib.c:pentium4_get_frequency()
> 
> if (c->x86_model < 2)
> 	mult = msr_lo >> 27;
> 
> The CPU model on this system here is 0. As I see in the documentation,
> multiplier is not defined in MSR_EBC_FREQUENCY_ID for model 0. So, we
> are getting the wrong estimate of the processor frequency.
> 
> Dominik may have more history about this.
> Dominik: did this >> 27 work on any P4 with model 0 and 1 at all?

The original code (2003 or earlier) didn't have it -- it's undocumented (at
least until the revision of the documentation I looked at) anyway as far as
I know. This specific check for "model < 2" got included only in 2005 in
this patch:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=3e4159ab35c88aef5e063ba78796b277b762a30a

So CC'ing Matthias-Christian Ott <matthias.christian@tiscali.de> now.

> Is Dominik the maintainer of speedstep-lib? I didn't hear anything back from 
> him on this one...

I don't know, I hope not :) Sorry for not replying earlier; I had to get all
sorts of things to do at university first.

Thanks,
	Dominik

Comment 4 Andrew Morton 2007-01-31 01:28:40 UTC
Gents, where do we stand with this bug now?
Comment 5 Fu Michael 2007-10-10 00:55:46 UTC
ping for fix...
Comment 6 ykzhao 2007-10-10 22:50:02 UTC
What Venki said is very right . 
The root of the problem seems to be this line at
arch/i386/kernel/cpu/cpufreq/speedstep-lib.c:pentium4_get_frequency()
if (c->x86_model < 2)
	mult = msr_lo >> 27; 
In this system the family id is 15 and the model id is 0. As it is described in the document of 253669 , multiplier is not defined in the MSR_EBC_FREQUENCY_ID when model id is less than 2. So after P4 clock module is loaded, the cpuinfo reports the wrong cpu frequency.
There are two ways to solve this problem when model is is less than 2
1. p4-get-frequency return 0 
   It means that this cpu doesn't support speedstep.
2. The cpufrequency is obtained from the model_name string. For example , the cpufreq for this system is 1300MHz.

Welcome the comments.
Thanks.
Comment 7 Len Brown 2007-10-17 00:47:48 UTC
okay, per comment #3, this regression was caused by commit 
3e4159ab35c88aef5e063ba78796b277b762a30a
which was apparently wrong.

Why not just revert that commit until the proper
patch in its place has been developed?

In any case, this is unrelated to ACPI -- so booting
back to the cpufreq category.
Comment 8 ykzhao 2007-10-30 01:36:33 UTC
Created attachment 13334 [details]
Obtain FSB ration from model string when model id is less than 2
Comment 9 Timothy Stotts 2007-10-31 05:23:58 UTC
(In reply to comment #8)
> Created an attachment (id=13334) [details]
> Obtain FSB ration from model string when model id is less than 2
> 

As bug reporter, I volunteer to test.
Please tell me if this patch is for `p4-clockmod' or a different kernel module.
Comment 10 Len Brown 2007-10-31 20:37:05 UTC
re: patch in comment #8
No, please do not parse the brand string, just don't go there.

I recommend:
1. revert http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commit;h=3e4159ab35c88aef5e063ba78796b277b762a30a
it is simply wrong.

2. otherwise deal with model < 2

2a. I recommend that you simply fail to load p4-clockmod on such systems.
(yes, I know this may appear Draconian, as this bug report is about
a cosmetic defect, and now I'm proposing taking something away
that has perceived value > 0)  but...

2b. I recommend that p4-clockmod not load on ANY system, indeed...

2c. I recommend that p4-clockmod be deleted from the upstream tree,
    and all instances of it on the planet Earth be hunted down
    and deleted.  Because it has NO VALUE except to confuse users
    into thinking that it has value.
Comment 11 ykzhao 2007-11-01 02:58:57 UTC
Created attachment 13364 [details]
Restore the previous calc of FSB ration for model <2

Will you please upload the info of /proc/cpuinfo after applying the attached patch? (P4-clockmod should be loaded).
Thanks.
Comment 12 Fu Michael 2007-11-28 23:39:13 UTC
Hi, Timothy, are you able to test the patch in comment# 11? thanks.
Comment 13 Len Brown 2007-12-05 18:44:12 UTC
the patch in comment #11 has been applied to the acpi test tree

ed9cbcd40004904dbe61ccc16d6106a7de38c998
Revert "speedstep-lib.c: fix frequency multiplier for Pentium4 models 0&1"
Comment 14 Len Brown 2008-02-10 14:20:57 UTC
shipped in Linux-2.6.24-git22
closed
Comment 15 Matthias-Christian Ott 2008-07-05 04:42:09 UTC
This breaks frequency scaling on my CPU. See #10968 for details.