I have here a T20 thinkpad with a T22 BIOS and a 2.6.32 kernel. After boot, acpi_listen shows me all the events that are being generated by the lid switch, hotkeys, batteries, ac, and maybe more. However, when I disconnect and reconnect ac power a few times in rapid succession, that leads to all of these events not being reported anymore. Suspend to RAM and to disk both don't fix it, only a reboot does. The BIOS and EC firmware are the newest versions available (1.12 and 1.06, respectively). "Commit 2a84cb removed delay needed by some slow controllers (Acer TM4001)" did not solve it. Whether this is a regression is unknown, which I cannot select in the interface. However, Debian's 2.6.25-2-686 kernel is affected, too.
Please uncomment #define DEBUG in drivers/acpi/ec.c and attach dmesg output.
please attach the acpidump output, and the output of "grep . /sys/firmware/acpi/interrupts/*".
Created attachment 24250 [details] acpidump
Created attachment 24251 [details] /sys/firmware/acpi/interrupts/*
Created attachment 24252 [details] kern.log kern.log of one boot. I hope you don't need any information before the beginning of the file? The ringbuffer seems to have been just a few kB too short ... Up to second 47, everything worked fine. Then, in second 252 I started unplugging and replugging the power supply until it stopped working. The debug output stopped, too.
FYI: The problem still exists in 2.6.32.2. I'll continue any further debugging on that version unless you object.
Created attachment 24260 [details] Protect Query execution Just a one more wild guess. Please check if it helps.
That deadlocks on boot at "ACPI: Using PIC for interrupt routing"
Created attachment 24262 [details] Protect Query execution #2 Typo fixed, sorry. Please check with this one.
Unless I misunderstand this interface somehow, there is still a typo in there. I changed the "guery" to "query" and got the same deadlock as before.
Created attachment 24270 [details] Protect Query execution #3 Ok, order of locks was wrong... Please check if this one makes any difference. I've checked it on my Thinkpad, at least it does not lock up.
Created attachment 24273 [details] kern.log #2 Boots again, but problem persists. If you think that I should increase the log buffer size, let me know ...
Created attachment 24274 [details] Accelerate query propogation Well, it was ugly anyway... Let's try to touch from other side... From the log it looks like EC is working, it is just too busy with traffic and has no time to reply to query in time. With this patch we split acknowledge of the query and query method execution, and this allows us to execute acknowledge on fast work queue. Please check if it helps...
That looks very much like a fix. I have generated probably a few hundred events now, and it's still alive. FYI: I have reverted all your other patches before applying this one. Let me know if I should test any other combinations (well, only the first one has chances of not conflicting, I guess ;-). Thanks a lot so far!
marked as RESOLVED as the patch in comment #13 is in acpi-test
commit a62e8f1978f49e52f87a711ff6711b323d4b12ff Author: Alexey Starikovskiy <astarikovskiy@suse.de> Date: Thu Dec 24 11:34:16 2009 +0300 ACPI: EC: Accelerate query execution shipped in Linux-2.6.33-rc5 closed.
Is this patch being considered for -stable?
*** Bug 10932 has been marked as a duplicate of this bug. ***