Created attachment 206271 [details] Debug info [1.] Suspend only works once per boot on 2015 Macbook Air (MacBookAir7,2) [2.] When booting a 2015 Macbook Air (MacBookAir7,2), suspend (either via lid close or running "systemctl suspend" from a terminal) will work the first time only. A second attempt to suspend will seem to suspend, but immediately wake back up. Rebooting the system and trying to suspend will work, again for the first attempt only. Very consistent and easy to reproduce. Moving the hard disk to a 2014 Macbook Air (MacBookAir6,2) results in a system that suspends correctly on every attempt. Related Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1483054 [3.] kernel, suspend, apple, macbook air [4.] Linux version 4.5.0-040500rc4-generic (kernel@gomeisa) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) ) #201602141731 SMP Sun Feb 14 22:33:37 UTC 2016 [6.] systemctl suspend [7.] Ubuntu 15.10. Native 4.2.0-27-generic kernel as well as Ubuntu "mainline" kernel 4.5-rc4 (from http://kernel.ubuntu.com/~kernel-ppa/mainline/). Many previous versions tested with the same result, although I never took note of each version. [7.1.] Attached as ver_linux_output [7.2.] Attached as proc-cpuinfo [7.3.] Attached as proc-modules [7.4.] Attached as proc-ioports and proc-iomem [7.5.] Attached as lspci-vvv [7.6.] Attached as proc-scsi-scsi [7.7.] Attachment dmidecode [X.] Attachment syslog-first-suspend and syslog-second-suspend
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.