Bug 11623
| Summary: | scaling_available_frequencies reports too high frequencies | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Márton Németh (nm127) |
| Component: | cpufreq | Assignee: | ykzhao (yakui.zhao) |
| Status: | CLOSED DUPLICATE | ||
| Severity: | normal | CC: | lenb, yakui.zhao |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.25 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
dmesg 2.6.26.5
.config of 2.6.26-5 minimal .config (2.6.25) git bisect log |
||
|
Description
Márton Németh
2008-09-22 12:51:24 UTC
Created attachment 17956 [details]
dmesg 2.6.26.5
Sorry, there is a typo in comment #0: the wrong kernel version is 2.6.26-5. Created attachment 17957 [details]
.config of 2.6.26-5
Created attachment 18262 [details]
minimal .config (2.6.25)
I did some tests with different stable kernel versions. I used the attached minimalistic kernel configuration.
2.6.22: OK (*)
2.6.24: OK (*)
2.6.25: bad
2.6.27: bad
(*): I used gcc 4.3.2, so I had to add "CFLAGS_KERNEL= -fno-tree-scev-cprop" into the kernel Makefile in order the kernel to be linked.
Created attachment 18264 [details] git bisect log I also found that the 2.6.25-rc1 is bad. I bisected the problem and found that: ed9cbcd40004904dbe61ccc16d6106a7de38c998 is first bad commit commit ed9cbcd40004904dbe61ccc16d6106a7de38c998 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Tue Nov 20 14:20:21 2007 -0500 Revert "speedstep-lib.c: fix frequency multiplier for Pentium4 models 0&1" For P4 model < 2, The MSR_FBC_REGISTER_ID ratio is undefined. Revert the commit that was added to handle that case, as it results in random MHz displayed. Something else will have to be done to properly handle model < 2. //commit 3e4159ab35c88aef5e063ba78796b277b762a30a //Author: matthias.christian <matthias.christian> //Date: Sat Feb 5 23:09:38 2005 +0000 // // [PATCH] speedstep-lib.c: fix frequency multiplier for Pentium4 models 0&1 // // The Pentium4 models 0&1 have a longer MSR_EBC_FREQUENCY_ID register as the // models 2&3, so the bit shift must be bigger. // // Signed-off-by: Matthias-Christian Ott <matthias.christian@tiscali.de> // Signed-off-by: Dominik Brodowski <linux@brodo.de> // Signed-off-by: Andrew Morton <akpm@osdl.org> // Signed-off-by: Linus Torvalds <torvalds@osdl.org> // // BKrev: 42055232eWM-NgjhZVir44mp5GXktQ http://bugzilla.kernel.org/show_bug.cgi?id=7186 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> :040000 040000 d2f684cee8d8802839210fe8ea85957373011f29 fb90c8ce0bcb025156d33673 d16a841140d19f9c M arch Hi, Marton
Sorry for the late response.
From the /proc/cpuinfo we can know that the model id is 1 and 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.
In fact the p4-clockmod cpufreq driver is bogus. It is realized by processor throttling. On most box it is replaced by the acpi-cpufreq driver.
Of course if you think that it is necessary on your box, please try the patch in
http://bugzilla.kernel.org/show_bug.cgi?id=10968#c3.
Thanks.
Hi, Marton
As the multiplier is not defined in the MSR_EBC_FREQUENCY_ID when model id is less than 2, it is incorrect that the max cpufreq is calculated based on the MSR value.
Maybe it should be obtained from the result of calibrate_cpu_khz.
In the patch of comment #6 the max cpufreq is obtained by using calibrate_cpu_khz if the model id is less than 2.
Thanks.
|