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-ProcessorAssignee: 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
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
Comment 1 Daniel Swarbrick 2007-03-21 03:00:53 UTC
Created attachment 10883 [details]
acpidump output
Comment 2 Daniel Swarbrick 2007-03-21 03:02:46 UTC
Created attachment 10884 [details]
/proc/acpi/processor/CPUn/throttling
Comment 3 Len Brown 2007-03-21 18:42:25 UTC
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.

Comment 4 Daniel Swarbrick 2007-03-21 19:32:13 UTC
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.
Comment 5 Daniel Swarbrick 2007-03-22 01:28:37 UTC
Created attachment 10907 [details]
/proc/cpuinfo
Comment 6 Daniel Swarbrick 2007-03-22 02:18:33 UTC
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.
Comment 7 Len Brown 2007-03-25 20:30:23 UTC
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.
Comment 8 Daniel Swarbrick 2007-03-26 04:28:13 UTC
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.
Comment 9 Len Brown 2007-03-26 09:49:33 UTC
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 ***