Bug 7186
| Summary: | p4-clockmod reports wrong MHz in /proc/cpuinfo desktop P4 | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Timothy Stotts (kernel_bugs) |
| Component: | cpufreq | Assignee: | 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 |
||
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? 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 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 Gents, where do we stand with this bug now? ping for fix... 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. 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. Created attachment 13334 [details]
Obtain FSB ration from model string when model id is less than 2
(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. 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. 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.
Hi, Timothy, are you able to test the patch in comment# 11? thanks. 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" shipped in Linux-2.6.24-git22 closed This breaks frequency scaling on my CPU. See #10968 for details. |
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