Bug 8245
| Summary: | acpi-cpufreq does not load - Pentium M processor 1.60GHz - Fujitsu Siemens Amilo M 1425 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Daniel Swarbrick (daniel) |
| Component: | Power-Processor | Assignee: | Venkatesh Pallipadi (venki) |
| Status: | REJECTED DUPLICATE | ||
| Severity: | normal | CC: | acpi-bugzilla |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.20.3 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
acpidump output
/proc/acpi/processor/CPUn/throttling /proc/cpuinfo |
||
|
Description
Daniel Swarbrick
2007-03-21 02:59:30 UTC
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. |