Most recent kernel where this bug did *NOT* occur: 2.6.17 Distribution: Ubuntu 7.04 Hardware Environment: Fujitsu Siemens Amilo M 1425, Pentium M 1.60GHz Centrino (Dothan) Software Environment: Problem Description: speedstep-centrino no longer works, and acpi-cpufreq does not appear to work either. AFAIK, speedstep-centrino has never officially supported Dothan cores, yet the module used to support frequency scaling. I can only think that speedstep-centrino used to obtain freq/voltage pairs via ACPI successfully, since these are not hardcoded in speedstep-centrino.c, as they are for Banias. With cpufreq debugging enabled, a modprobe speedstep-centrino produces: [ 3733.100000] cpufreq-core: trying to register driver centrino [ 3733.100000] cpufreq-core: adding CPU 0 [ 3733.100000] speedstep-centrino: speedstep-centrino: obtaining ACPI data failed [ 3733.100000] speedstep-centrino: no table support for CPU model "Intel(R) Pentium(R) M processor 1.60GHz" [ 3733.100000] cpufreq-core: initialization failed [ 3733.100000] cpufreq-core: no CPU initialized for driver centrino [ 3733.100000] cpufreq-core: unregistering CPU 0 and a modprobe acpi-cpufreq produces: [ 3782.216000] acpi-cpufreq: acpi_cpufreq_init [ 3782.216000] acpi-cpufreq: acpi_cpufreq_early_init [ 3782.216000] cpufreq-core: trying to register driver acpi-cpufreq [ 3782.216000] cpufreq-core: adding CPU 0 [ 3782.216000] acpi-cpufreq: acpi_cpufreq_cpu_init [ 3782.216000] cpufreq-core: initialization failed [ 3782.216000] cpufreq-core: no CPU initialized for driver acpi-cpufreq [ 3782.216000] cpufreq-core: unregistering CPU 0
Created attachment 10883 [details] acpidump output
Created attachment 10884 [details] /proc/acpi/processor/CPUn/throttling
What happens when you try each driver in 2.6.17, they both work or just speedstep-centrino works? yes, as of 2.6.20, acpi-cpufreq is supposed to work everyplace and speedstep-centrino is supposed to be depricated.
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. In the meantime I've also confirmed that BackTrack 2 livecd (2.6.20) and KNOPPIX 5.1.0 (2.6.19) also fail to load either speedstep-centrino or acpi-cpufreq.
Created attachment 10907 [details] /proc/cpuinfo
After having read up on ACPI at http://acpi.sourceforge.net/documentation/processor.html, I thought it was worth mentioning that my system does not /proc/acpi/processor/CPU./performance at all - ie, ACPI is not discovering P-states at all. Could this indicate a buggy BIOS? I don't know enough about kernel innards to say whether this is _because_ acpi-cpufreq is not loading, or _causing_ acpi-cpufreq to not load.
The ACPI DSDT does not contain P-state information (no _PCT, _PSS, _PPC) but it does load an SSDT at run-time based on the _PDC bits: Processor (CPU1, 0x01, 0x00000410, 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) If (LEqual (NCPU, 0x02)) { If (LEqual (And (TYPE, 0x0A), 0x0A)) { 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 } Store (0x01, STS7) Store (0x01, DEV7) Load (SSDT, HNDL) } } } } The code in linux-2.6.21-rc5 should print out the header of each table, including a dynamically loaded SSDT. Can you attach the complete output from dmesg -s 64000 fro 2.6.21-rc5 or later? We can also probably peek at the SSDT with acpidump on the physical addresses to confirm that it includes the needed P-state objects. But I suspect the real problem here is that the _PDC bits are not causing the needed SSDT to get loaded in the first place.
Len, you may already be aware of this, as I see you're subscribed on #8228, this appears to a be a dupe bug report. I hope to get time to try 2.6.21rc5 in the next couple of days, probably in a Debian environment - they're a little closer to vanilla sources than Ubuntu.
yes, lets work this in bug 8228, which was filed against the Fujitsu Siemens Amilo M1437G (the older bug report wins:-) *** This bug has been marked as a duplicate of 8228 ***