Most recent kernel where this bug did *NOT* occur: 2.6.17 Distribution: Ubuntu (Feisty) Hardware Environment: Averatec E1200 - 1.6GHz Pentium M Software Environment: Problem Description: The 1.6GHz Pentium M (see cpuinfo below) now acts like a 600MHz generic x86. pufreq scaling does not load, speedstep centrino claims no such device, etc. Everything worked fine in 2.6.17 (would scale from 600MHz to 1.6GHz quite smoothly using speedstep-centrino). Will provide any/all info requested and am happy to experiment with my machine to figure this out (not an expert but certainly not a newbie either, just not a C coder). cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.60GHz stepping : 6 cpu MHz : 599.981 cache size : 2048 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 mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2 bogomips : 1200.82 Steps to reproduce: Use 2.6.19 kernel.
Does the "acpi-cpufreq" driver work?
No. Says no such device. Also, resume from suspend is now somewhat broken... hangs about one in five times on wake (was fine in 2.6.17).
Can you attach the output of acpidump. You can find acpidump in latest pmtools pkg here. http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
Created attachment 9716 [details] output of acpidump
Note: acpidump output is identical under 2.6.17 and 2.6.19.
Created attachment 9720 [details] Debug patch
Looks like a BIOS issue from first looks. Please try the attached debug patch and let me know whether it helps. That will tell us more about the BIOS behavior. Thanks, Venki
No dice. The patch does not appear to change anything. Also, the est flag appears in cpuinfo (without the patch and with it, of course) so I am not surprised this is not the issue. I have enabled CPU Frequency Debugging in kernel, will attempt to get some output from that now.
With cpu frequency debugging enabled, I have the following in dmesg. Maybe it will help? cpufreq-core: trying to register driver centrino cpufreq-core: adding CPU 0 speedstep-centrino: speedstep-centrino: obtaining ACPI data failed speedstep-centrino: no table support for CPU model "Intel(R) Pentium(R) M processor 1.60GHz" cpufreq-core: initialization failed cpufreq-core: no CPU initialized for driver centrino cpufreq-core: unregistering CPU 0
Hmm.... Let me find some more time in acpidump and try to figure out why this particular SSDT table which has the P-state information is not getting loaded.
There was a recent patch from Mattia that went into latest 2.6.20-rc. Can you please check with that kernel and let me know if you still have this issue. Thanks, Venki
Still an issue, now using 2.6.20-rc3 Anything else I can do to help you out?
Apologies in advance if this is a pointless question (I haven't spent much time with the kernel source)... but.... 2.6.17 worked fine. Since then failed. Seems that the "DOTHAN" cpus were removed from the speedstep-centrino code between 2.6.17 and 2.6.18. file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c line 290-296 Now, my CPU reports its model name as "Intel(R) Pentium(R) M processor 1.60GHz Seems that the speedstep-centrino code compares reported model name to hardcoded model name (makes sense). But the hardcoded name is now only able to deal with ending in MHz (no GHz). Is this possibly related? Again, if this is spurious I apologize, I am just trying to help. Thanks for taking the time.
Hello again, So I am now well aware of all sorts of issues that led to the switch from speedstep-centrino to acpi-cpufreq. The laptop in question has a badly broken BIOS I think. I installed WinXP on it (which previously did freq scaling) to see what would happen. Windows cannot do freq scaling anymore either. If the maintainers want to keep this bug open, that's fine and my offer to provide info/test things holds. But I will not object if this is closed due to my computer being a piece of *pick-a-word*. Thanks for all the time so far.
Venki, what's your verdict? Do you need this bug open for tracking purposes, further blacklisting work or should it be closed? Thanks, --Natalie
I experienced approximately the same problem when switching from kernel 2.6.20 (which worked really fine) to 2.6.22.5. My intel CPU is now stuck at 800Mhz, which is really annoying. I enabled ACPI and CPUFREQ debug in kernel and I'll post some output.
Created attachment 12530 [details] output of acpidump
Created attachment 12531 [details] content of cpuinfo
Created attachment 12532 [details] output of dmesg
Christophe, Can you attach the config file from under /boot for your kernel version and also the output of cat /sys/devices/system/cpu/cpu*/cpufreq/* (if it exists). sardion, Looks like BIOS for some reason does not want to support speedstep. Kepp updating the BIOS and you may get lucky sometime ;).
Other people are reporting the problem here: https://bugs.launchpad.net/bugs/132271 I'll provide the infos you requested. (sorry for the delay, I forgot to add me to the CC...)
Created attachment 12871 [details] Ubuntu kernel config
cat: /sys/devices/system/cpu/cpu*/cpufreq/*: No such file or directory
I have just compiled and tried 2.6.23rc6 kernel using my 2.6.20 kernel (because 2.6.20 is working). However, there is no change, cpufreq is still broken and my cpu is stuck at 800MHz
Venki, I'm marking it a regression, do you agree?
Agreed. This looks like a regression. I need to dig more into acpidump to see why 2.6.20 works and later ones does not.
Created attachment 12960 [details] output of acpidump of kernel 2.6.20 output of acpidump of kernel 2.6.20
I don't know if this should be the case but there is no diff in acpidump output of 2.6.20 kernel and 2.6.22 one.
I think I may have an explanation to this problem. My CMOS battery is dying. Could this break cpufreq ? It it is a possible reason, then it might be interesting to know why kernel 2.6.20 still manages cpu scaling althought 2.6.22 can't. Apparently 2.6.20 is more "robust" on this point, it would be good if recent kernels were too.
Created attachment 13145 [details] Patch to restore cpufreq on my cpu Since I didn't have any news. I decided to have a look at the kernel code. I compared arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c in 2.6.20 and 2.6.22 and I saw that my cpu's code ("CPU_DOTHAN_C0 / SONOMA") was removed. I wrote a patch to add it back and now cpu frequency scaling is working again. I tested my patch on a 2.6.23.1 kernel. Could someone have a look and see why this code was removed?
Christophe, Thanks for the finding. I tried looking at the difference you mentioned above. But looks like this "SONOMA" support never made it to any base kernel. I do not see this particular code included in 2.6.20 at all. Are you sure speedstep works for you with 2.6.20 kernel from kernel.org. Or is it some 2.6.20+patches kernel from some distribution.
Oh I see. My 2.6.20 kernel is indeed a kernel from Ubuntu Feisty v7.04. It is likely that it was their patch then. I'm posting the file from my 2.6.20 kernel.
Created attachment 13171 [details] speedstep-centrino.c from Kernel 2.6.20 (Ubuntu Feisty)
Here is the page to the kernel: http://packages.ubuntu.com/feisty/base/linux-image-2.6.20-15-generic
Unmarking regression as mainline kernel never had hardcoded tables for Sonoma. Two ways to go about this: 1) Check with you BIOS provider for any updates and BIOS options to see anything related to speedstep. The reason acpi-cpufreq does not work here is that the BIOS is not giving proper ACPI tables. It will be interesting to see whether P-states works on Windows on the same platform. My guess is no. But, if you can check, may be you will be able to influence BIOS provider more. One thing not yet clear for me is that the BIOS is trying to load an SSDT table, but I don't see any reference to where that table is in acpidump output. I will check with others on any way to track this SSDT table and look at its contents. 2) Second option is to try and get a minimal patch that supports only this platform in speedstep-centrino tables. But, as Matthew mentioned in the email, it is not good to hardcode tables as it may not be proper one for all platforms.
Indeed, Cpu step is not working on Windows either. My BIOS is already the last one on Fujitsu's website. I already contacted Futjitsu-Siemens and they weren't cooperative because my laptop is no longer under warranty (although I insisted and spent a lot of time on the phone)... For information, my cpu is this one: /* Intel Pentium M processor 750 / 1.86 GHz (Sonoma) */ static struct cpufreq_frequency_table sonoma_1862[] = { OPEX( 798, 133, 988, 988, 988, 988), OPEX(1064, 133, 1084, 1080, 1068, 1056), OPEX(1330, 133, 1180, 1172, 1132, 1124), OPEX(1596, 133, 1276, 1264, 1196, 1192), OPEX(1862, 133, 1356, 1356, 1260, 1260), { .frequency = CPUFREQ_TABLE_END } }; My laptop is a fujitsu-siemens amilo M 6453G, Bios version is 1.01C. On 10/15/07, bugme-daemon@bugzilla.kernel.org < bugme-daemon@bugzilla.kernel.org> wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=7607 > > > venkatesh.pallipadi@intel.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Regression|1 |0 > > > > > ------- Comment #35 from venkatesh.pallipadi@intel.com 2007-10-15 13:30 > ------- > > Unmarking regression as mainline kernel never had hardcoded tables for > Sonoma. > > Two ways to go about this: > 1) Check with you BIOS provider for any updates and BIOS options to see > anything related to speedstep. The reason acpi-cpufreq does not work here > is > that the BIOS is not giving proper ACPI tables. It will be interesting to > see > whether P-states works on Windows on the same platform. My guess is no. > But, if > you can check, may be you will be able to influence BIOS provider more. > > One thing not yet clear for me is that the BIOS is trying to load an SSDT > table, but I don't see any reference to where that table is in acpidump > output. > I will check with others on any way to track this SSDT table and look at > its > contents. > > 2) Second option is to try and get a minimal patch that supports only this > platform in speedstep-centrino tables. But, as Matthew mentioned in the > email, > it is not good to hardcode tables as it may not be proper one for all > platforms. > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > Indeed, Cpu step is not working on Windows either. My BIOS is already the last one on Fujitsu's website. I already contacted Futjitsu-Siemens and they weren't cooperative because my laptop is no longer under warranty (although I insisted and spent a lot of time on the phone)... <br><br>For information, my cpu is this one:<br>/* Intel Pentium M processor 750 / 1.86 GHz (Sonoma) */<br>static struct cpufreq_frequency_table sonoma_1862[] =<br>{<br> OPEX( 798, 133, 988, 988, 988, 988),<br> OPEX(1064, 133, 1084, 1080, 1068, 1056), <br> OPEX(1330, 133, 1180, 1172, 1132, 1124),<br> OPEX(1596, 133, 1276, 1264, 1196, 1192),<br> OPEX(1862, 133, 1356, 1356, 1260, 1260),<br> { .frequency = CPUFREQ_TABLE_END }<br>};<br><br>My laptop is a fujitsu-siemens amilo M 6453G, Bios version is 1.01C.<br><br><div><span class="gmail_quote">On 10/15/07, <b class="gmail_sendername"><a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a></b> <<a href="mailto:bugme-daemon@bugzilla.kernel.org"> bugme-daemon@bugzilla.kernel.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="http://bugzilla.kernel.org/show_bug.cgi?id=7607"> http://bugzilla.kernel.org/show_bug.cgi?id=7607</a><br><br><br><a href="mailto:venkatesh.pallipadi@intel.com">venkatesh.pallipadi@intel.com</a> changed:<br><br> What |Removed |Added<br>---------------------------------------------------------------------------- <br> Regression|1 |0<br><br><br><br><br>------- Comment #35 from <a href="mailto:venkatesh.pallipadi@intel.com">venkatesh.pallipadi@intel.com</a> 2007-10-15 13:30 -------<br><br>Unmarking regression as mainline kernel never had hardcoded tables for Sonoma. <br><br>Two ways to go about this:<br>1) Check with you BIOS provider for any updates and BIOS options to see<br>anything related to speedstep. The reason acpi-cpufreq does not work here is<br>that the BIOS is not giving proper ACPI tables. It will be interesting to see <br>whether P-states works on Windows on the same platform. My guess is no. But, if<br>you can check, may be you will be able to influence BIOS provider more.<br><br>One thing not yet clear for me is that the BIOS is trying to load an SSDT <br>table, but I don't see any reference to where that table is in acpidump output.<br>I will check with others on any way to track this SSDT table and look at its<br>contents.<br><br>2) Second option is to try and get a minimal patch that supports only this <br>platform in speedstep-centrino tables. But, as Matthew mentioned in the email,<br>it is not good to hardcode tables as it may not be proper one for all<br>platforms.<br><br><br>--<br>Configure bugmail: <a href="http://bugzilla.kernel.org/userprefs.cgi?tab=email"> http://bugzilla.kernel.org/userprefs.cgi?tab=email</a><br>------- You are receiving this mail because: -------<br>You are on the CC list for the bug, or are watching someone who is.<br></blockquote></div><br>
This same issue seems to be common across multiple platforms. The only resolution we have got right now is to get BIOS to support P-states. *** This bug has been marked as a duplicate of bug 7463 ***
Wouldn't it be possible to set the CPU the max speed when frequency scaling won't work instead of min speed? At least, this would be usable on broken systems like mine. On 10/18/07, bugme-daemon@bugzilla.kernel.org < bugme-daemon@bugzilla.kernel.org> wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=7607 > > > venkatesh.pallipadi@intel.com changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|ASSIGNED |RESOLVED > Resolution| |DUPLICATE > > > > > ------- Comment #37 from venkatesh.pallipadi@intel.com 2007-10-18 14:08 > ------- > This same issue seems to be common across multiple platforms. The only > resolution we have got right now is to get BIOS to support P-states. > > *** This bug has been marked as a duplicate of bug 7463 *** > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > Wouldn't it be possible to set the CPU the max speed when frequency scaling won't work instead of min speed? At least, this would be usable on broken systems like mine.<br><br><div><span class="gmail_quote">On 10/18/07, <b class="gmail_sendername"><a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a></b> <<a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a>> wrote:</span> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="http://bugzilla.kernel.org/show_bug.cgi?id=7607">http://bugzilla.kernel.org/show_bug.cgi?id=7607 </a><br><br><br><a href="mailto:venkatesh.pallipadi@intel.com">venkatesh.pallipadi@intel.com</a> changed:<br><br> What |Removed |Added<br>---------------------------------------------------------------------------- <br> Status|ASSIGNED |RESOLVED<br> Resolution| |DUPLICATE<br><br><br><br><br>------- Comment #37 from <a href="mailto:venkatesh.pallipadi@intel.com">venkatesh.pallipadi@intel.com </a> 2007-10-18 14:08 -------<br>This same issue seems to be common across multiple platforms. The only<br>resolution we have got right now is to get BIOS to support P-states.<br><br>*** This bug has been marked as a duplicate of bug 7463 *** <br><br><br>--<br>Configure bugmail: <a href="http://bugzilla.kernel.org/userprefs.cgi?tab=email">http://bugzilla.kernel.org/userprefs.cgi?tab=email</a><br>------- You are receiving this mail because: -------<br>You are on the CC list for the bug, or are watching someone who is. <br></blockquote></div><br>