Bug 11994 - Computer doesn't power down after commit ACPI: EC: do transaction from interrupt context
Summary: Computer doesn't power down after commit ACPI: EC: do transaction from interr...
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: All Linux
: P1 high
Assignee: Alexey Starikovskiy
Depends on:
Blocks: 11808
  Show dependency tree
Reported: 2008-11-09 02:02 UTC by François Valenduc
Modified: 2008-11-15 05:37 UTC (History)
3 users (show)

See Also:
Kernel Version:
Regression: Yes
Bisected commit-id:

dmesg output (24.01 KB, text/plain)
2008-11-09 02:16 UTC, François Valenduc
output of acpidump (109.35 KB, text/plain)
2008-11-09 05:45 UTC, François Valenduc
Output of lspci -vxxx (23.15 KB, text/plain)
2008-11-09 05:46 UTC, François Valenduc
revert msleep() (977 bytes, patch)
2008-11-09 12:50 UTC, Alexey Starikovskiy
Details | Diff
wait for last gpe (2.22 KB, patch)
2008-11-09 12:51 UTC, Alexey Starikovskiy
Details | Diff
restart failed transaction (4.18 KB, patch)
2008-11-09 12:52 UTC, Alexey Starikovskiy
Details | Diff
Rejects obtained with the patch "restart failed tranaction" (2.91 KB, text/plain)
2008-11-09 23:22 UTC, François Valenduc
restart transaction patch against yesterday's linus tree (4.07 KB, patch)
2008-11-12 04:04 UTC, Tiago Batista
Details | Diff

Description François Valenduc 2008-11-09 02:02:42 UTC
Latest working kernel version:
Earliest failing kernel version:
Distribution: Gentoo
Hardware Environment: ACER Travelmate 4001 Lmi
Software Environment:
Problem Description:

Steps to reproduce: try to power down the computer

I can't more power down my computer correctly since commit 5ceb40417bca2045350e77f740e0c4c94875fff2 (ACPI: EC: do transaction from interrupt context) has been merged in the stable kernel. I did a bisection run between and and it show up as the first bad commit.
If I revert all EC related commit between these 2 kernels, the problem doesn't occur.
This commit also flood dmesg with lines like "ACPI: EC: non-query interrupt received, switching to interrupt mode" (see bug #11841) but it is solved by the patched proposed in this bug report.
Comment 1 Alan Jenkins 2008-11-09 02:16:17 UTC
As I said before, I don't really know how to investigate this.

But more details might help.  Here are some dumb questions about possible details.

Do you get a black display but power LED still on?
Or does the display seem to freeze?
Does the keyboard respond?  E.g. the emergency Sysrq keys (see Documentation/sysrq.txt)?  If you have keyboard LEDs, are they flashing?  Do the keyboard LEDs change if you press numlock or capslock?
Comment 2 François Valenduc 2008-11-09 02:16:41 UTC
Created attachment 18743 [details]
dmesg output

Output of dmesg with kernel and patch mentionned in bug  bug #11841 applied (from  http://marc.info/?l=linux-acpi&m=122603281922125&w=4)
Comment 3 François Valenduc 2008-11-09 02:21:20 UTC
In fact, the shutdown stops after the last step (remounting filesystems read-only). The screen is not black and the sysrq keys don't respond but LEDs change if I press CAPS Lock.
Comment 4 ykzhao 2008-11-09 05:36:33 UTC
Hi, Francois
    Will you please attach the output of acpidump, lspci -vxxx?
Comment 5 François Valenduc 2008-11-09 05:45:32 UTC
Created attachment 18745 [details]
output of acpidump
Comment 6 François Valenduc 2008-11-09 05:46:12 UTC
Created attachment 18746 [details]
Output of lspci -vxxx

So here are the files you asked.
Comment 7 Rafael J. Wysocki 2008-11-09 11:02:30 UTC
Handled-By : ykzhao <yakui.zhao@intel.com>
Comment 8 Rafael J. Wysocki 2008-11-09 11:21:35 UTC
First-Bad-Commit : 5ceb40417bca2045350e77f740e0c4c94875fff2
Comment 9 Rafael J. Wysocki 2008-11-09 11:58:41 UTC
First-Bad-Commit : 7c6db4e050601f359081fde418ca6dc4fc2d0011
Comment 10 Alexey Starikovskiy 2008-11-09 12:50:59 UTC
Created attachment 18757 [details]
revert msleep()

please check if any of these 3 patches (applied on top of each other) helps.
Comment 11 Alexey Starikovskiy 2008-11-09 12:51:41 UTC
Created attachment 18758 [details]
wait for last gpe

patch #2
Comment 12 Alexey Starikovskiy 2008-11-09 12:52:10 UTC
Created attachment 18759 [details]
restart failed transaction

patch #3
Comment 13 François Valenduc 2008-11-09 13:11:21 UTC
The problem is already solved if I apply the first patch. Should I apply the two others ?
Comment 14 Alexey Starikovskiy 2008-11-09 14:17:57 UTC
yes, it would be great if they don't break your machine again... Check both at once. :)
Comment 15 François Valenduc 2008-11-09 23:19:49 UTC
I have applied the second patch and it still works OK. However, the third one can't be applied and give rejects.
Comment 16 François Valenduc 2008-11-09 23:22:28 UTC
Created attachment 18769 [details]
Rejects obtained with the patch "restart failed tranaction"

I applied this patch on the current git tree of 2.6.28 and after the two other patches but it doesn't work.
Comment 17 Tiago Batista 2008-11-12 04:04:22 UTC
Created attachment 18821 [details]
restart transaction patch against yesterday's linus tree

Please take a look at this before applying as I am not a skilled developer.

Also, after applying, the output of dmesg |grep EC reads:
[    0.022518] ACPI: EC: Look up EC in DSDT
[    0.077080] ACPI: EC: non-query interrupt received, switching to interrupt mode
[    0.130278] ACPI: EC: GPE storm detected, transactions will use polling mode
[    0.507079] ACPI: EC: GPE = 0x1d, I/O: command/status = 0x66, data = 0x62
[    0.507135] ACPI: EC: driver started in interrupt mode
[    0.819611] ACPI: SBS HC: EC = 0xdf158780, offset = 0x18, query_bit = 0x20
[   35.559049] ACPI: EC: missing confirmations, switch off interrupt mode.
[   72.284252] ACPI: EC: missing confirmations, switch off interrupt mode.
[   94.298039] ACPI: EC: missing confirmations, switch off interrupt mode.
[   96.291040] ACPI: EC: missing confirmations, switch off interrupt mode.

is this the expected output? I have not shutdown the computer yet, if it fails I will report the problem.
Comment 18 Alexey Starikovskiy 2008-11-12 06:16:35 UTC
please check if patches from 12004 work any better.
Comment 19 Len Brown 2008-11-12 21:40:07 UTC
several EC patches shipped in 2.6.28-rc4-git3
so that would be a good baseline to test.
Comment 20 François Valenduc 2008-11-14 11:23:34 UTC
The problem doesn't occur anymore with the revert-mspleep patch and the other ec patches solves all the other problem related to this one (see #12004 and #11841). So for me, the problem is fixed.

Note You need to log in before you can comment on or make changes to this bug.