Latest working kernel version: 2.6.18 Earliest failing kernel version: Distribution: Debian Hardware Environment: Software Environment: Problem Description: In case of Linux kernel 2.6.25.5 with p4_clockmod loaded the available frequencies are the following: $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 1725000 3450000 5175000 6900000 8625000 10350000 12075000 13800000 However, the 13.8GHz is too high as the upper limit: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 1 model name : Intel(R) Celeron(R) CPU 1.70GHz stepping : 3 cpu MHz : 6900.000 cache size : 128 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 pebs bts bogomips : 3388.22 clflush size : 64 power management: In case of 2.6.18 the following frequencies are reported: $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 212500 425000 637500 850000 1062500 1275000 1487500 1700000 Steps to reproduce: Boot and watch the scaling_available_frequencies.
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.
This will be marked as the dup of bug 10968 *** This bug has been marked as a duplicate of bug 10968 ***