Bug 9997
Summary: | acpi_cpufreq detects wrong frequencies for Pentium M 715 - Dothan on Acer Travelmate 4001 LMI | ||
---|---|---|---|
Product: | ACPI | Reporter: | Dieter Steiner (spoilerhead) |
Component: | Power-Processor | Assignee: | Venkatesh Pallipadi (venki) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | acpi-bugzilla |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.22-14-generic | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump output on vanilla 2.6.24.2
dmesg output on vanilla 2.6.24.2 dmidecode output on vanilla 2.6.24.2 DSDT patch dmesg with debug options enabled and custom DSDT original DSDT source fixed DSDT source try the custom DSDT dmesg with ykzhao 's DSDT and debug options |
Description
Dieter Steiner
2008-02-15 14:03:52 UTC
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? |