Bug 113261
| Summary: | Suspend only works once per boot , caused by bogus XHCI/Lid wakeup event - 2015 Macbook Air (MacBookAir7,2) | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Nick Bartos (kmod32) |
| Component: | USB | Assignee: | Chen Yu (yu.c.chen) |
| Status: | NEEDINFO --- | ||
| Severity: | normal | CC: | h1909476, kernel, rui.zhang, yu.c.chen |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 4.5-rc4 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
Debug info
/proc/acpi/wakeup before and after suspend acpidump of macbook air 2015 lspci -vvx before and after first suspend |
||
|
Description
Nick Bartos
2016-02-26 19:24:51 UTC
It seems that we got a wakeup event after suspend. Please attach the output of "cat /proc/acpi/wakeup" both before and after the first suspend/resume. Created attachment 207651 [details]
/proc/acpi/wakeup before and after suspend
Contents per request. At every stage, /proc/acpi/wakeup is the same.
I see that this is still marked as NEEDINFO, please let me know if there is more info I need to provide. what if you run "echo XHC1 > /proc/acpi/wakeup" before the first resume, can the problem be reproduced? When disabling wakeup for XHC1, the problem cannot be reproduced. Of interesting note is that the lid open event does not work (with or without XHC1 enabled) in 4.5 (I also tried the latest 4.5.0-040500-generic_4.5.0-040500.201603140130). Using Ubuntu's own 4.2.0-16-generic, the lid open event does work. However, when using Ubuntu's 4.2.0-16-generic kernel, both the XHC1 and LID0 wakeup events need to be disabled for suspend to work more than once. It seems that for some reason, suspend only works consistently if ALL wakeup events are disabled (then the power button must be pressed to wake up from sleep, nothing else does it). (In reply to Nick Bartos from comment #5) > When disabling wakeup for XHC1, the problem cannot be reproduced. > It seems that we get redundant xhci wakeup event upon suspend. > Of interesting note is that the lid open event does not work (with or > without XHC1 enabled) in 4.5 (I also tried the latest > 4.5.0-040500-generic_4.5.0-040500.201603140130). Using Ubuntu's own > 4.2.0-16-generic, the lid open event does work. However, when using > Ubuntu's 4.2.0-16-generic kernel, both the XHC1 and LID0 wakeup events need > to be disabled for suspend to work more than once. This seems to be a different problem. please attach the acpidump of the laptop. Created attachment 218431 [details]
acpidump of macbook air 2015
For the XHCI wakeup event issue, let's see if we can get some help from the USB expert. Please attach the output of lspci -vvx both before and after the first suspend, in both 4.2 and 4.5 kernel. (In reply to Nick Bartos from comment #5) > > Of interesting note is that the lid open event does not work (with or > without XHC1 enabled) in 4.5 (I also tried the latest > 4.5.0-040500-generic_4.5.0-040500.201603140130). Using Ubuntu's own > 4.2.0-16-generic, the lid open event does work. what about a vanilla 4.2 kernel? I don't recall any commit that would bring this difference, please run git bisect to find out which commit introduces this problem. ping... Created attachment 220691 [details]
lspci -vvx before and after first suspend
Hi, I get the same problem on an ASUS UX303LA. Is this bug being worked on ? Here is the problem 1. XHCI in /proc/acpi/wakeup always needs to be disabled for the system to suspend/resume properly. 2. LID not work in 4.5 kernel, but when it works in 4.2 kernel, it must be disabled in /proc/acpi/wakeup as well. right? (In reply to Nick Bartos from comment #5) > Of interesting note is that the lid open event does not work (with or > without XHC1 enabled) in 4.5 What do you mean? you can never receive the Lid open event via input layer? (In reply to Zhang Rui from comment #13) > > What do you mean? you can never receive the Lid open event via input layer? I'm afraid I don't remember exactly. I've just been dealing with: echo 'LID0' > /proc/acpi/wakeup echo 'XHC1' > /proc/acpi/wakeup And using the power button to resume from suspend, which has been working flawless for months. Well, this bug sounds either like a kernel issue, OR a firmware issue. If you're happy with current situation and don't have time to continue debugging, I will close this bug report. Or else, please provide the information required in comment #13. I'm still affected and I'm not very happy with it, so while I don't know much about this, I could give the information you want. Just know that the problem seems to happen randomly, so I can't test it arbitrarily. @Nick Bartos @ h1909476@mvrht.com I think the bogus wakeup event issued by XHC1 is a common problem, as I also met this issue on my MacBookPro 2015. I'd prefer to send the issue to usb-maillist directly, as Greg requested before. I'll prepare a mail to involve the usb developers in. |