Bug 9353

Summary: acpi-cpufreq doesn't work M31EI dual-core Centrino notebook
Product: ACPI Reporter: Mathias Hasselmann (mathias.hasselmann)
Component: Power-ProcessorAssignee: ykzhao (yakui.zhao)
Status: REJECTED INVALID    
Severity: normal CC: acpi-bugzilla, davej
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.22-14-generic Subsystem:
Regression: Yes Bisected commit-id:
Attachments: The DSTD of that notebook
Output of dmesg
Output of acpidump
Output of dmesg without custom DSDT
don't load table with invalid address/length
don't load table with invalid address/length
/proc/cpuinfo after the system is booted

Description Mathias Hasselmann 2007-11-11 13:39:25 UTC
Most recent kernel where this bug did not occur: 2.6.17? (Edgy and early Feistys)
Distribution: Ubuntu
Hardware Environment: Uniwill M31EI (Intel T2400)
Software Environment:
Problem Description:

The M31EI is a dual-core Centrino notebook designed by Uniwill, no Elitegroup [1]. CPU scaling worked on Ubuntu 6.06 (and early 6.10) kernels (2.6.17?), which appearently used the old speedstep-centrino module.

Now with 7.10 neither speedstep-centrino nor acpi-cpufreq work. Both modules complain "No such device". Problem seems to be - like usual - in the ACPI tables:

[   20.938328] ACPI Warning (tbutils-0217): Incorrect checksum in table [   �] -  00, should be 05 [20070126]
[   20.938369] ACPI Error (tbinstal-0134): Table has invalid signature [   �], must be SSDT, PSDT or OEMx [20070126]
[   20.938405] ACPI Error (psparse-0551): Method parse/execution failed [\_PR_.CPU1._PDC] (Node df802180), AE_BAD_SIGNATURE
[   21.142856] ACPI Warning (tbutils-0217): Incorrect checksum in table [   �] -  00, should be 05 [20070126]
[   21.142895] ACPI Error (tbinstal-0134): Table has invalid signature [   �], must be SSDT, PSDT or OEMx [20070126]
[   21.142929] ACPI Error (psparse-0551): Method parse/execution failed [\_PR_.CPU2._PDC] (Node df802240), AE_BAD_SIGNATURE

[1] http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=774&DetailName=Bios&MenuID=57&LanID=0

Steps to reproduce:

modprobe acpi-cpufreq
modprobe speedstep-centrino
Comment 1 Mathias Hasselmann 2007-11-11 13:41:04 UTC
Created attachment 13498 [details]
The DSTD of that notebook
Comment 2 ykzhao 2007-11-11 16:59:32 UTC
In the processor block of DSDT.dsl(comment #1)
    OperationRegion (STBL, SystemMemory, 0xFFFF0000, 0xFFFF)
    Method (_PDC, 1, NotSerialized)
            {
                 Load (STBL, HNDL)
                 Store (0x01, TBLD)
            }

The region of 0xffff0000-0xffffffff is reserved by BIOS.But the OS will load table dynamically from the address of 0xffff0000. It is uncorrect. 

It is appropriate to fix this problem by Uniwill.

Anyway please upload the following info:
a. acpidump
b. dmesg
Comment 3 Zhang Rui 2007-11-11 22:05:35 UTC
You probably disable the cpu P-state feature in the BIOS.
Can you check if there are any BIOS options for CPU performance control please?
Comment 4 Mathias Hasselmann 2007-11-11 23:32:09 UTC
Created attachment 13502 [details]
Output of dmesg
Comment 5 Mathias Hasselmann 2007-11-11 23:33:17 UTC
Created attachment 13503 [details]
Output of acpidump

acpidump also writes this message to stderr:
Wrong checksum for generic table!
Comment 6 Mathias Hasselmann 2007-11-12 00:05:43 UTC
Created attachment 13504 [details]
Output of dmesg without custom DSDT

Duh, forgot to disable the custom DSDT I build yesterday before calling dmesg. I had the naïve hope the checksum problems would go away by recompling the DSDT with iasl.

Regarding BIOS options: No changes after enabling "Long Battery Life Mode".
No other option available.
Comment 7 Zhang Rui 2007-11-12 18:44:14 UTC
please set CONFIG_CPU_FREQ_DEBUG and load speedstep driver after 
"echo 7 > /sys/modules/cpufreq/parameters/debug".
And please attach the content of /proc/cpuinfo as well.
Comment 8 Zhang Rui 2007-11-12 18:49:50 UTC
It would be great if you can attach the dmesg output of a older kernel which the old speedstep-centrino module works well on your laptop, better with CONFIG_CPU_FREQ_DEBUG set.
Comment 9 ykzhao 2007-11-12 19:02:21 UTC
Will you please attach the info of /proc/cpuinfo after the system is booted ?
Thanks.
Comment 10 Zhang Rui 2007-11-12 19:52:03 UTC
Created attachment 13519 [details]
don't load table with invalid address/length

There are two problems here.
One is the error messages printed by ACPI. This patch should remove these debug messages.
The other problem is probably the incompatibility between the new cpufreq driver and your hardware. But it's just a suspect unless you can send the dmesg with the old cpufreq driver successfully loaded. :)
Comment 11 Zhang Rui 2007-11-12 19:56:06 UTC
Created attachment 13520 [details]
don't load table with invalid address/length

Oops, fix a typo in the last patch.
Comment 12 Mathias Hasselmann 2007-11-12 23:56:10 UTC
Created attachment 13522 [details]
/proc/cpuinfo after the system is booted

Fetching and building kernel sources now.
Thanks for help, btw.
Comment 13 ykzhao 2007-11-13 19:22:08 UTC
I agree with what Rui said in comment #10 .
It would be great if you can attach the dmesg and .config with the old cpufreq driver successfully loaded. Of course the files of dmesg and .config for the 2.6.22-14 are also needed.
Thanks.
Comment 14 Mathias Hasselmann 2007-11-14 23:49:22 UTC
Still have to figure out what source code the Ubuntu guys used to build the kernel I use: Just building the code they ship in their kernel-source package leads to a kernel not finding the root file system. Strange. Will try the "apt-get source" variant on the weekend.

Will keep you informed.
Comment 15 Fu Michael 2007-12-23 17:34:40 UTC
Mathias, any update?
Comment 16 Len Brown 2008-01-01 11:08:18 UTC
Mathias, if you've got the working ubuntu kernel binary available,
just boot it and grab the dmesg -s64000 and contents of
/sys/devices/system/cpu/cpu*/cpufreq/*  no need to build from source.
Comment 17 Mathias Hasselmann 2008-01-06 14:16:52 UTC
Duh, sorry for wasting your time. 

After trying each Ubuntu kernel back to 2.6.15-20 without success, I went into the BIOS setup again and tried each option available. "Long Battery Life" mode was guilty for messing up ACPI information.