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
Created attachment 13498 [details] The DSTD of that notebook
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
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?
Created attachment 13502 [details] Output of dmesg
Created attachment 13503 [details] Output of acpidump acpidump also writes this message to stderr: Wrong checksum for generic table!
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.
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.
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.
Will you please attach the info of /proc/cpuinfo after the system is booted ? Thanks.
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. :)
Created attachment 13520 [details] don't load table with invalid address/length Oops, fix a typo in the last patch.
Created attachment 13522 [details] /proc/cpuinfo after the system is booted Fetching and building kernel sources now. Thanks for help, btw.
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.
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.
Mathias, any update?
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.
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.