Bug 11994
Summary: | Computer doesn't power down after commit ACPI: EC: do transaction from interrupt context | ||
---|---|---|---|
Product: | ACPI | Reporter: | François Valenduc (francoisvalenduc) |
Component: | EC | Assignee: | Alexey Starikovskiy (astarikovskiy) |
Status: | CLOSED CODE_FIX | ||
Severity: | high | CC: | acpi-bugzilla, astarikovskiy, rjw |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.27.5 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 11808 | ||
Attachments: |
dmesg output
output of acpidump Output of lspci -vxxx revert msleep() wait for last gpe restart failed transaction Rejects obtained with the patch "restart failed tranaction" restart transaction patch against yesterday's linus tree |
Description
François Valenduc
2008-11-09 02:02:42 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? Created attachment 18743 [details] dmesg output Output of dmesg with kernel 2.6.27.5 and patch mentionned in bug bug #11841 applied (from http://marc.info/?l=linux-acpi&m=122603281922125&w=4) 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. Hi, Francois Will you please attach the output of acpidump, lspci -vxxx? Thanks. Created attachment 18745 [details]
output of acpidump
Created attachment 18746 [details]
Output of lspci -vxxx
So here are the files you asked.
Handled-By : ykzhao <yakui.zhao@intel.com> First-Bad-Commit : 5ceb40417bca2045350e77f740e0c4c94875fff2 First-Bad-Commit : 7c6db4e050601f359081fde418ca6dc4fc2d0011 Created attachment 18757 [details]
revert msleep()
please check if any of these 3 patches (applied on top of each other) helps.
Created attachment 18758 [details]
wait for last gpe
patch #2
Created attachment 18759 [details]
restart failed transaction
patch #3
The problem is already solved if I apply the first patch. Should I apply the two others ? yes, it would be great if they don't break your machine again... Check both at once. :) Thanks! I have applied the second patch and it still works OK. However, the third one can't be applied and give rejects. 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.
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.
please check if patches from 12004 work any better. several EC patches shipped in 2.6.28-rc4-git3 so that would be a good baseline to test. 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. |