Most recent kernel where this bug did *NOT* occur: none. Distribution: Ubuntu & OpenSuSE Hardware Environment: see link Software Environment: see link Problem Description: CPU Scaling isn't working. I have opened a bugreport at launchpad (bugreporting system of ubuntu) and one of them told me to file the bug here and give you a link: https://launchpad.net/bugs/93331 Steps to reproduce: root@loopy2:~# /etc/init.d/powernowd restart * Stopping powernowd: [ OK ] * Starting powernowd... /etc/init.d/powernowd: 156: cannot create /sys/devices/system/cpu/cpu0//cpufreq/scaling_governor: Directory nonexistent * CPU frequency scaling not supported
Do you have either the acpi-cpufreq or speedstep-centrino module loaded ? Can you attach the dmesg output ?
Created attachment 10839 [details] dmesg output :) If you need any more information please contact me. :)
I have loaded the following modules: uwe@loopy2:~$ lsmod | grep cpufreq cpufreq_stats 7360 0 cpufreq_ondemand 9228 0 cpufreq_userspace 5408 0 cpufreq_conservative 8200 0 freq_table 5792 2 cpufreq_stats,cpufreq_ondemand cpufreq_powersave 2688 0 uwe@loopy2:~$ lsmod | grep acpi sony_acpi 6284 0 pcc_acpi 13184 0 dev_acpi 12292 0 asus_acpi 17308 0 backlight 7040 1 asus_acpi There are no modules matching "centrino" loaded.
please attach /proc/cpuinfo
Created attachment 10930 [details] cat /proc/cpuinfo output Someone of the Ubuntu Team has commited a patch but I don't want to recompile my kernel so I need to wait until the patch gets merged into the standard kernel. I'll report back as soon as this happens.
modprobe acpi-cpufreq should DTRT
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.20-12-generic/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device I don't know what DTRT means. :)
DTRT = "do the right thing" :-) Please attach your /proc/acpi/dsdt It appears your BIOS either lacks tables, or has broken ones. Maybe the Intel folks can spot something that can be worked around, or failing that, maybe there's a BIOS update available for your system.
The Ubuntu Kernel Team provided a fix. It was something about linux-phc tables.
merging linux-phc is not the right way to fix this. I truly hope that Ubuntu haven't merged that stuff in their kernel. Forking whole subsystems (especially ones that are unlikely to ever get merged back) isn't the way to get stuff fixed in the upstream kernel.
rather than just the DSDT, please attach the complete output from acpidump. If the distro doesn't have it, you can get a copy of the acpidump utility in the latest pmtools there: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
Created attachment 10944 [details] dsdt.log
Created attachment 10945 [details] acpidump log i've attached the 2 output files.
DSDT shows no _PCT, _PSS, _PPC for P-state control, but does show that an SSDT is supposed to be loaded based on results of _PDC -- but dynamic SSDT is not mentioned in the dmesg. Processor (CPU1, 0x01, 0x00000810, 0x06) { OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF) Name (NCPU, 0x00) Name (TYPE, 0x80000000) Name (HNDL, 0x80000000) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, DAT0) Store (DAT0, TYPE) OperationRegion (PMRG, SystemIO, \PMBS, 0x50) Field (PMRG, ByteAcc, NoLock, Preserve) { Offset (0x41), DEV4, 1, DEV5, 1, DEV6, 1, DEV7, 1, STS4, 1, STS5, 1, STS6, 1, STS7, 1 } If (LAnd (LEqual (NCPU, 0x02), LEqual (And (TYPE, 0x0A), 0x0A))) { Store (0x01, STS7) Store (0x01, DEV7) Load (SSDT, HNDL) } If (LAnd (LEqual (NCPU, 0x01), LEqual (And (TYPE, 0x01), 0x01))) { If (LNot (And (TYPE, 0x10))) { Load (SSDT, HNDL) } } } }
*** Bug 8245 has been marked as a duplicate of this bug. ***
I'm unsure if Bug 8245 really is a duplicate as I'm was also using 6.10 Edgy and 6.06 Dapper and this bug was always present. In Bug 8245 Daniel Swarbrick said: > Under 2.6.17 (Ubuntu 6.10), speedstep-centrino loads successfully, and the > frequency scales from 600MHz to 1.6GHz as it should. acpi-cpufreq fails to > > load > with ENODEV. For me it was the same problem as no - no scaling at all. If there's any information needed please tell me. I don't have anything to do with kernels and stuff I'm just a normal Linux user. ;)
Created attachment 10951 [details] dmesg log with current kernel with linux-phc Oh I forgot to mention - the Kernel I'm using now is another one than the one I was using when I first reported this Bug. The one I'm using now is the one with Ubuntu's fix (about the linux-phc tables). The one I'm using now is: 2.6.20-13-generic #2 SMP and I was using 2.6.20-12. What I want to say is, the dmesg.log and cpuinfo.log where from another kernel without the phc stuff. I've attached the new dmesg output as dmesg2.log - maybe that explains the differences. But as you know I absolutely don't know anything about kernel stuff and how all that stuff works.
Created attachment 10955 [details] dmesg output from 2.6.21rc5 Len, hope this is sufficient info for you. Kernel compiled with cpufreq debug enabled, and booted with cpufreq.debug=7 You can see towards the end that speedstep-centrino and acpi-cpufreq still fail to load, as they did pre-linux-phc patches.
Created attachment 10956 [details] FULL dmesg output from 2.6.21rc5 Sorry, previous attachment seemed to chop first few lines. Guess it's bigger than 64000 bytes!
>Len, hope this is sufficient info for you. Kernel compiled with cpufreq debug >enabled, and booted with cpufreq.debug=7 Please #echo 0x1f >/sys/module/acpi/parameter/debug_level and modprobe the cpufreq driver again. Hope we can get more information from the _dmesg_ output.
speedstep_lib was still loaded as module for me and a module for pentium 4 processors, guess that was the issue. adding acpi-cpufreq to the modules array in rc.conf fixed the issue and the faulty speedstep_lib didn't got loaded anymore (i have a amilo m1439g which is pretty much equal to the m1437g, but i think it's a general centrino issue)
Created attachment 11339 [details] Dmesg when wrong modules are loaded
Created attachment 11340 [details] cpufreq-info with the wrong modules loaded
Created attachment 11341 [details] lsmod when wrong modules are loaded
Created attachment 11342 [details] dmesg with the right modules loaded
Created attachment 11343 [details] cpufreq-info with the right modules loaded
Created attachment 11344 [details] lsmod with the right modules loaded
Uh, how embarrassing, this was supposed to end up on the archlinux bugtracker. Well now I can at least give you some more infos as I am not sure if this is archlinux specific. System is a Amilo M1439g which is equal to the M1437g except it has an Nvidia card instead of an ATI card Telling the kernel to load acpi-cpufreq right at the start fixes the issue and no wrong module gets loaded I've attached the output of dmesg, cpufreq-info and lsmod in the good and bad state This is all on the fresh released 2.6.21 Kernel. If there are any other infos you need I can upload them too,
>>> OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF) ^^^^^^^^^^^^^^^^^^ This means cpu freq changing is disabled in BIOS settings. Please look there.
(In reply to comment #20) > >Len, hope this is sufficient info for you. Kernel compiled with cpufreq > debug > >enabled, and booted with cpufreq.debug=7 > Please > #echo 0x1f >/sys/module/acpi/parameter/debug_level > and modprobe the cpufreq driver again. > Hope we can get more information from the _dmesg_ output. With 2.6.22-rc3, I'm unable to modprobe acpi or acpi-cpufreq ("No such device") and thus unable to echo the 0x1f debug flag. lsmod shows asus-acpi already loaded however. Attaching an updated dmesg output.
Created attachment 11790 [details] dmesg output from 2.6.22-rc3
Daniel, Did you look at comment #29 or ignored it? And yes, you can not "modprobe acpi", as it is compiled statically into kernel. modprobe acpi-cpufreq will fail until you enable frequency scaling in BIOS, as per #29. Regards, Alex.
(In reply to comment #32) > Daniel, > Did you look at comment #29 or ignored it? > And yes, you can not "modprobe acpi", as it is compiled statically into > kernel. > modprobe acpi-cpufreq will fail until you enable frequency scaling in BIOS, > as > per #29. > Regards, > Alex. > I did not ignore comment #29, but there is no option in the BIOS of these laptops to enable frequency scaling. In the past it has always just worked, until speedstep-centrino was gutted sometime around 2.6.19. I guess I may just have to resort to linux-phc patches again.
Then your issue is different from the one reported here. Open new bug and attach output of acpidump there. It is not possible to help you otherwise.
You mean this bug? http://bugzilla.kernel.org/show_bug.cgi?id=8245#c9
yes. and you have same string in your DSDT: "OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)" So, the only chance for you to get frequency control is to enable it in BIOS.
(In reply to comment #36) > yes. > and you have same string in your DSDT: > "OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)" > > So, the only chance for you to get frequency control is to enable it in BIOS. > ...which as I've said, is not possible. There is no option whatsoever to enable/disable frequency scaling in these BIOSes. It's a pity that this is now broken, because up until 2.6.18, it worked fine. <sigh> back to linux-phc... that's progress for ya.
Please post dmesg from 2.6.18, showing either acpi-cpufreq or speedstep-centrino working.
It does not work in 2.6.18. I said that it worked _up until_ 2.6.18 (ie, 2.6.17 and earlier). I've never seen acpi-cpufreq work on this hardware regardless, but speedstep-centrino used to work until it had its entrails ripped out in 2.6.18. I will try to boot up a 2.6.17 livecd distro and get the evidence you ask for.
(In reply to comment #38) > Please post dmesg from 2.6.18, showing either acpi-cpufreq or > speedstep-centrino working. > The dmesg output I'm about to attach does not show the speedstep_centrino driver loading (not verbose enough), but I will also attach an 'lsmod' output, and the output of the various cpufreq sysfs files. I used Ubuntu 6.10 Desktop (livecd), which is a 2.6.17 kernel.
Created attachment 11803 [details] dmesg output from 2.6.17
Created attachment 11804 [details] lsmod output from 2.6.17
Created attachment 11805 [details] sysfs entries for cpufreq on 2.6.17
ok, this looks promising, but Ubuntu kernel is known to be highly modified. I think you still need to _compile_ 2.6.17 with cpufreq debug and acpi debug info. Could you also attach /proc/acpi/processor/* ?
(In reply to comment #44) > ok, this looks promising, but Ubuntu kernel is known to be highly modified. > I think you still need to _compile_ 2.6.17 with cpufreq debug and acpi debug > info. Could you also attach /proc/acpi/processor/* ? > Ok, I think the mystery is solved. Rather than compiling 2.6.17, I compared speedstep-centrino.c from Ubuntu's 2.6.17 kernel package, against the upstream source. Ubuntu have obviously patched it, adding freq/voltage tables for Pentium M Dothan cores (upstream only supports Banias). They've also done this in their 2.6.20 package for Feisty. So I guess my notebook has broken ACPI BIOS, and the frequency scaling has only ever worked because of the linux-phc patches that Ubuntu were applying :( Hopefully they'll at least keep doing that, to save me from having to patch it myself each time. I still don't understand why these patches for the Dothan cores have never made it into mainline...
There is a later BIOS for my notebook, released about two weeks after the version I was previously running (dated December 2004). There is nothing in the release notes about ACPI, but I thought I'd give it a crack anyway. Wouldn't you know it... acpi-cpufreq loads fine, detects the frequencies available, and scales the clock speed. Even Windows no longer needs the Notebook Hardware Control app to scale the clock speed. Well done Fujitsu-Siemens.... >:(
ok, thanks for information. Closing it now.
Thanks for following-up Daniel. Curious that speedstep-centrino tables for Dothan was what made this work for you in Ubuntu-2.6.17 and that upgrading the BIOS make acpi-cpufreq start working. It makes one wonder what Windows would do with the old BIOS on that machine. As we haven't heard from Uwe, the original poster, in months, we'll assume he's somehow magically happy with the upstream kernel and we'll file this one into the broken BIOS bucket.