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
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]
Created attachment 24251 [details]
Created attachment 24252 [details]
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 184.108.40.206. 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]
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
Author: Alexey Starikovskiy <firstname.lastname@example.org>
Date: Thu Dec 24 11:34:16 2009 +0300
ACPI: EC: Accelerate query execution
shipped in Linux-2.6.33-rc5
Is this patch being considered for -stable?
*** Bug 10932 has been marked as a duplicate of this bug. ***