Latest working kernel version: - Earliest failing kernel version: 2.6.10, no older kernel tested Distribution: Ubuntu Hardware Environment: Acer Travelmate 4001 LMI - M11 Software Environment: Ubuntu 5.04 - 7.10 Problem Description: On my Notebook (Acer travelmate 4001 LMI-M11) with ubuntu 7.10, my processor gets identified incorrectly by acpi_cpufreq, this is due a buggy DSDT and presend since i got the notebook in every kernel version i testet (Starting with 2.6.10) i alwlays need to manually patch speedstep_centrino to include special tables for my Dothan cpu. as referenced here (http://lkml.org/lkml/2007/9/4/58) well, i report it, as it justified linux-phc for me ATM. if theres any additional info i should provide, please tell me uname -a Linux plasmafire 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/Linux reported by acpi_cpufreq: /cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 1600000 1400000 1200000 800000 600000 unloading acpi_cpufreq, manually loading speedstep_centrino with patched Tables: 600000 800000 1000000 1200000 1500000 root@plasmafire:/sys/devices/system/cpu/cpu0/cpufreq # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.50GHz stepping : 6 cpu MHz : 1500.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe up est tm2 bogomips : 3199.46 clflush size : 64
addendum: i'm running distro kernel ATM, but it happend with vanilla, too (verified that with several versions during the last years)
please verify that the system is running the latest available BIOS please attach the output from dmidecode please attach the output from acpidump with the latest stable kernel, 2.6.24.y, not using any out-of-tree drivers or modifications, please paste the output from: # grep . /sys/devices/system/cpu/cpu0/cpufreq/* and attach the complete output from dmesg -s64000
Created attachment 14860 [details] acpidump output on vanilla 2.6.24.2
Created attachment 14861 [details] dmesg output on vanilla 2.6.24.2
Created attachment 14862 [details] dmidecode output on vanilla 2.6.24.2
bios is 3A10 (latest from Acer FTP haven't found any newer version/beta anywhere) uname -a Linux plasmafire 2.6.24.2-vanilla #1 SMP Sat Feb 16 12:15:51 CET 2008 i686 GNU/Linux grep . /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1600000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:600000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:1600000 1400000 1200000 800000 600000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:powersave ondemand userspace conservative performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:600000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufreq /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:conservative /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1600000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:600000 other requested outputs in attachments
Created attachment 14873 [details] DSDT patch after some messing around with a custom DSDT, i was able to create a DSDT patch that fixes the odd behavior, but its certainly just a workaround, and nor a true fix.
hm, clearly no solution, the custom DSDT breaks other things: - powertop doesn't recognize any C-States anymore - wakeups go up from about 100 to about 500 /second, power drainincreases by about 2-3W :-/
Hi, Dieter The bug is caused by buggy DSDT. The cpufreq in acpi-driver is extracted from _PSS package, which is incorrect. It is appropriate to fix this bug by upgrading bios. (Maybe you can report this issue to Acer OEM). Will you please boot the system with the option of "acpi.debug_layer=0x01000000 acpi.debug_level=0x1f cpufreq.debug=7" and attach the output of dmesg? Of course the custom DSDT is required. Thanks.
i'll check if i can find a contact to acer, but i doubt that they even care about their customers, as the latest bios version is nearly 3 years old, so i guess, that i need to fix it with a custom DSDT, but i'll try anyways. the dmesg log will be attacked asap, need to recompile the kernel
Created attachment 14882 [details] dmesg with debug options enabled and custom DSDT
Hi, Dieter Thanks for the info. After using the custom DSDT your laptop can work in correct cpufreq. The remaining problems are listed in the following: > powertop doesn't recognize any C-States anymore > - wakeups go up from about 100 to about 500 /second, power drainincreases by about 2-3W :-/ That powertop can't recognize any C-states is caused by the NULL pblk address. From the debug dmesg it seems that Processor block address is NULL . But from the DSDT it seems that the PBLK address is 0x00001010. > Processor (CPU0, 0x00, 0x00001010, 0x06) Will you please confirm the difference between the oringal dsdt and custom dsdt? Please only modify the cpufreq definition in _PSS package and see whether the problem still exists. Thanks.
the line is the same in the original DSDT, and it works there :S i'll attack original and fixed source if it helps
Created attachment 14894 [details] original DSDT source
Created attachment 14895 [details] fixed DSDT source
Created attachment 14911 [details] try the custom DSDT Will you please try the custom DSDT and see whether remaing problems still exists?
Hi, Dieter Will you please try the attached custom DSDT and see whether the remaing problems still exists? It will be great if you can "acpi.debug_layer=0x01000000 acpi.debug_level=0x1f cpufreq.debug=7" and attach the output of dmesg. > powertop doesn't recognize any C-States anymore > - wakeups go up from about 100 to about 500 /second, power drainincreases by about 2-3W :-/ The attached custom DSDT only modifies the cpufreq definition in _PSS package.
Created attachment 14914 [details] dmesg with ykzhao 's DSDT and debug options
Powertop still shows no C-states, in console mode, it stays @ 60-120 wakeups, but sometimes spikes to 300-700, where <interrupt>: acpi creates the biggest load, maybe a result from the debug statements? i'll retry with a non debug kernel later today
also got a reply mail from acer, it roughly translates to: "we got no newer bios then you got installed, please send us your notebook" (sorry, i won't do that, i'm out of warranty and i'm for sure not gonna pay more for a fix then the notebook is worth). you think it would help to write a mail directly to Acer in Taiwan? (i wrote to european customer support)
on default kernel now, with custom DSDT loaded looked fine first, but now: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7317 root 20 0 3944 1656 980 R 79.8 0.1 3:43.71 powertop Aufwachen pro Sekunde : 7180,6 Intervall: 10,0s Stromverbrauch (nach ACPI): 29,2W (1,4 Std.) Häufigste Ursachen für das Aufwachen: 85,4% (6132,3) <interrupt> : acpi 12,8% (919,8) <interrupt> : extra timer interrupt 1,6% (113,6) <interrupt> : uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, 0,2% ( 11,6) <interrupt> : libata sorry text is in german i'm also missing keystrokes
is there any further i can do?