ACPI event causes system freeze for LID ac_power or battery. IE if the lid button is pressed, the ac_adapter is connected or removed, or the battery is inserted or removed the system freezes hard. Does not matter if X is running, or not. Note: also system will not power down properly, hangs on acpi_power_off Notebook: Sharp PCAV18 (athlon 1800) Distro: Mandriva 2006 Kernel: 2.6.13.4 (problem exists with stock kernel also)
Created attachment 6299 [details] dmesg output
Created attachment 6300 [details] lspci -vv output
Created attachment 6301 [details] biosdecode output
Created attachment 6302 [details] dmidecode output
I tested different variations of compiled kernels, with ACPI built in, aCPI as modules, preemptive kernel. I disassembled the DSDT, fixed 4 warnings and recompiled and built that into the kernel. No change, still locks hard at event. It previously worked fine on a 2.6.3 kernel. If there is any other information that would be helpful, let me know.
two problems here, likely unrelated 1. poweroff fails 2. events hang the system lets categorize this one as poweroff, since that is the most basic ACPI feature. what is the latest kernel that worked? Has this been broken ever since 2.6.4, or did something recent, such as 2.6.12 work?
I have 3 kernels available on the unit right now. 2.6.13.4 (compiled, tested different options) 2.6.12-12mdk (which is the stock drake kernel) 2.6.12-12mdk1 (which is custom that I have compiled, testing options again) I will dl the linux 2.6.12.12 kernel and report the findings. I have tried earlier kernels, but have not had much success compiling them from within mandrakiva2006. The kernel included with Knoppix 3.9 (2.6.11) works fine booted from CD. If there are any reccomended .config settins let me know, I will be more than happy to test them.
I downloaded the 2.6.12 (not 12.12 as stated above) and compiled (without custom DSDT). Same problem(s) persist.
Created attachment 6398 [details] iasl compiler warnings Attached are the compile warnings from iasl.
Created attachment 6399 [details] current dsdt - disassembled here is the current dsdt - disassembled
I also just got finished testing the latest kernel release 2.6.14, and the exact same problems exist.
Is there anything I can do? Any other information needed to help squash this bug? I have tried lots of stuff, nothing does an good. Greg
could you attach dmesg output from 2.6.14 kernel? your dmesg from 2.6.13.4 reports that you don't have any batteries installed. Is it a mistake from ACPI? Also "System is already in ACPI mode" looks strange...
Created attachment 6611 [details] dmesg output Here is the dmesg output from 2.6.14 I have been running with the battery out because when it is installed, I have random lockup. This attachment is with the battery installed (running on battery power).
Warning is gone, good. Could you please try commenting out Acquire/Release of the Mutex in PHS/PHS2 methods in the very end of DSDT, just to rule out locking problems?
I commented out the aquire and release of both of those (and recompiled dsdt into kernel). No difference. Same problems exist.
Could you compile ACPI with debug info and echo "0xffff" > /proc/acpi/debug_level to see if ACPI prints any additional informarion about your lockups?
Created attachment 6765 [details] messages output compiled ACPI with debug info followed instructions: echo "0xffff" > /proc/acpi/debug_level nothing I can see gets written to messages that appears to be related.
I also tested the 2.6.14.3 release, same problems exist.
Did the system hang just after last line of output from ACPI?
This was the last line: Dec 4 10:33:35 localhost kernel: acpi_utils-0287 [05] evaluate_integer : Return value [1] I am assuming the next line is the system restart, I have to physically power it down and up again.
Tested with 2.6.14.4 kernel release, same problem(s) exist.
Greg, what is the compiler you are using? Could it be "too advanced" for kernel compiles?
gcc version 4.0.1 What ver do you reccomend?
Compiled latest kernel release (2.6.14.5), same problem(s) exist.
I found that excluding the laptop extras (for IBM, Toshiba, Asuc etc) from the kernel (2.6.14), it no longer freezes when the power is connected, on battery insertion/removal, or LID switch (which is good!). Battery status also works. But acpi_poweroff will not power down the unit. I also compiled the latest 2.6.15 kernel with the same config, and it does not freeze on event, but now the battery status no longer works. acpi_poweroff still does not power the unit down.
Correction: battery status does not work properly with 2.6.14 or 2.6.15, The ac-adapter status does work. The battery status only reports what the battery level was at boot time, after that it does not change....
I tried compileing 2.6.15 with the ACPI modules built in, and as modules. It will now recogize the battery charge state (as long as it was booted with the battery insertd). The unit will still not power down by itself. I also added the acpi debug option and found when shutting the laptop down with this, I get another message right after "acpi_power_off called" hwsleep-0204 [05] enter_sleep_state : Entering sleep state [S5] I am not sure if this means anything.
I have been playing around with kernel compile options, and found that enabling generic x86 support and setting the preemption model to preemptable low latency desktop solves a lot of the problems. The laptop will power off now, but will not power up again when powered off with the ac plugged in. The ac plug needs to be removed (and battery removed) in order for the power button to work again. So it appears that it is not quite powering off fully. doing more testing....
Created attachment 7024 [details] .config After multiple kernel compiles with different .configs, I finally got things working well! attached my current .config
And what was the last change to .config? I mean what was wrong in previous one?
The last changes to the .config was to build ACPI and its options into the kernel (as opposed to modules). That appeared to fix the problem with the unit not shutting off completely at power down. Why it would matter whether they were built in, or as modules I do not know. I must have tried 15 or more different configurations of kernel 2.6.15 with varying levels of success, problems. I tried different compilers (gcc-4.0.1 and gcc-2.95) Sometimes USB devices would have problems with power managment, sometimes cpufreqd would fail, the pcmcia interface would not work etc. I do not remember all the different combinations of options I tried. I can post my original .config if you like.