Bug 202509

Summary: MacBookPro11,5 power management fails to suspend usb-2 SD card reader
Product: Drivers Reporter: nikkoara (lnicoara)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Status: NEW ---    
Severity: normal CC: a3at.mail, adrian.allen, gaul, jakob.gruber, kouakitaki, lenb, lnicoara, murielfperez, rheluani, rui.zhang, xakraz
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.20.5 Subsystem:
Regression: No Bisected commit-id:
Attachments: lsusb -vv before removing SD card reader

Description nikkoara 2019-02-05 15:12:02 UTC
Created attachment 281005 [details]
lsusb -vv before removing SD card reader

The Apple SD card reader in my MacbookPro11,5 (running Arch) interferes with the suspend/resume operations. I started noticing this after the fix for https://bugzilla.kernel.org/show_bug.cgi?id=201997

If I remove the SD card reader device before the first suspend via:

`$ echo 1 >/sys/bus/usb/devices/2-4/remove`

all subsequent suspend/resume works ok.

If I don't do that, only the first suspend is successful and no errors are showing in the dmesg output. The second suspend and the ones after that show the following errors:

```
...
[  112.457348] PM: suspend entry (deep)
[  112.457350] PM: Syncing filesystems ... done.
[  112.470680] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  112.472007] OOM killer disabled.
[  112.472008] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  112.473238] printk: Suspending console(s) (use no_console_suspend to debug)
[  112.474235] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
[  112.474238] PM: Device usb2 failed to suspend async: error -16
[  112.507792] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  112.509497] sd 0:0:0:0: [sda] Stopping disk
[  112.581584] PM: Some devices failed to suspend, or early wake event detected
[  112.581723] sd 0:0:0:0: [sda] Starting disk
[  112.784248] apple_gmux: Timeout waiting for gmux switch to complete
[  112.785837] OOM killer enabled.
[  112.785839] Restarting tasks ... done.
[  112.848478] PM: suspend exit
[  112.848517] PM: suspend entry (s2idle)
[  112.848518] PM: Syncing filesystems ... done.
[  112.862322] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  112.863453] OOM killer disabled.
[  112.863453] Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done.
[  112.864176] printk: Suspending console(s) (use no_console_suspend to debug)
[  112.864769] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
[  112.864772] PM: Device usb2 failed to suspend async: error -16
[  112.897661] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  112.901344] sd 0:0:0:0: [sda] Stopping disk
[  112.938469] PM: Some devices failed to suspend, or early wake event detected
[  112.938531] sd 0:0:0:0: [sda] Starting disk
[  113.048934] OOM killer enabled.
[  113.048935] Restarting tasks ... done.
[  113.049317] PM: suspend exit
[  113.052243] audit: type=1130 audit(1549376273.646:44): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=?
terminal=? res=failed'
...
```

After the first resume I cannot use the same removal of the USB device to correct the suspends because the device does not show up anymore in the sys mount.
Comment 1 taki 2019-02-06 02:11:21 UTC
This bug is also present on MacBookPro 12,1 with kernel version 4.20.3. First time the suspend works, but after that the laptop don't suspend at all (immediate wake).

dmesg message:

> [  387.569396] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
> [  387.569398] PM: Device usb2 failed to suspend async: error -16
> [  387.591987] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [  387.592431] sd 0:0:0:0: [sda] Stopping disk
> [  388.586059] PM: Some devices failed to suspend, or early wake event
> detected
Comment 2 Adrian Allen 2019-02-12 18:07:41 UTC
I'm also affected by this issue, 2015 Macbook Pro with Intel I7-4870HQ. 

Running Fedora 29 on Weyland with 4.20.6-200.fc29.x86_64. 

As others have noted, I can work around the problem once by "echo 1 >/sys/bus/usb/devices/2-4/remove", but this only works for one suspend cycle as the node is removed.

I am willing to provide whatever verbosity of logs might be helpful and am capable of applying patches and rebuilding locally if necessary for troubleshooting purposes. My existing logs aren't notably different from what others have posted so for the sake of brevity I am omitting them for now.
Comment 3 Xavier Krantz 2019-02-14 09:49:49 UTC
Hello,

I was also affected by this issue that prevented my Macbook to suspend at lid close.

However, after an update the issue seems to fixed for me.
I did not checked the logs but the laptop goes into suspend mode without any issue now.

```
OS: Arch Linux x86_64 
Host: MacBookPro12,1 1.0 
Kernel: 4.20.7-arch1-1-ARCH 
Resolution: 1680x1050 
DE: KDE 
CPU: Intel i5-5257U (4) @ 3.100GHz 
GPU: Intel Iris Graphics 6100 
Memory: 3149MiB / 7878MiB 
```
Comment 4 Azat Khuzhin 2019-02-14 10:06:11 UTC
> 4.20.7-arch1-1-ARCH

Hm, interesting, I don't see any nearly related changes in between 4.20.6 and 4.20.7, IOW are you sure that you had exactly the same issue?

Also can you confirm that SD card reader works after suspend (and only the first one), correct?

P.S. I see that you hardware differs a little, since I had i7 in my laptop, although this should not be related I guess
Comment 5 nikkoara 2019-02-14 13:40:39 UTC
(In reply to Xavier Krantz from comment #3)
> ...
> However, after an update the issue seems to fixed for me.
> I did not checked the logs but the laptop goes into suspend mode without any
> issue now.


I went back to re-verify. Although I am at 4.20.7 myself, the issue remains unchanged.
Comment 6 Xavier Krantz 2019-02-20 17:02:44 UTC
In the end I don't know if it is exactly the same issue...

However:
* I had the same behavior with the 1st suspend working and the remaining not
* When the issue occurred, I had the same error messages than taki in my logs


Today I have noticed something else:
* Upgrading from kernel 4.20.8 to 4.20.10 brought a new issue with the laptop lid close / suspend not working as expected.
* Downgrading back to 4.20.8 fixed the issue and I don't have the errors imly logs...


```
> [  387.569396] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
> [  387.569398] PM: Device usb2 failed to suspend async: error -16
> [  387.591987] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [  387.592431] sd 0:0:0:0: [sda] Stopping disk
> [  388.586059] PM: Some devices failed to suspend, or early wake event
> detected
```
Comment 7 Adrian Allen 2019-02-20 18:53:50 UTC
This mysteriously stopped happening for me almost immediately after I posted that I had the issue. I've been having this problem for a month or two and finally got around to reporting it, and now I don't have the issue anymore. 

I'm now on 4.20.8-200.fc29.x86_64, but suspend was working normally before I upgraded. 

I wish I knew what fixed it, this was maddening.
Comment 8 Azat Khuzhin 2019-02-21 10:32:01 UTC
Xavier Krantz
> * I had the same behavior with the 1st suspend working and the remaining not

And does SD Card Reader works after suspend?

I remember that for me it never worked after suspend, the only thing that raised up after upgrading to 4.x.x was that suspend didn't work anymore because of it.
Comment 9 Azat Khuzhin 2019-02-21 10:41:31 UTC
> * Upgrading from kernel 4.20.8 to 4.20.10 brought a new issue with the laptop
> lid close / suspend not working as expected.
> * Downgrading back to 4.20.8 fixed the issue and I don't have the errors imly
> logs...

So I still don't see any relevant bit in the changelog that can change suspend/usb behavior
Comment 10 Adrian Allen 2019-02-22 17:15:52 UTC
(In reply to Adrian Allen from comment #7)
> This mysteriously stopped happening for me almost immediately after I posted
> that I had the issue. I've been having this problem for a month or two and
> finally got around to reporting it, and now I don't have the issue anymore. 
> 
> I'm now on 4.20.8-200.fc29.x86_64, but suspend was working normally before I
> upgraded. 
> 
> I wish I knew what fixed it, this was maddening.

I withdraw my withdrawal. For no readily apparent reason, the issue has returned.  I will try to get more information about what's actually happening when the bug happens, but unfortunately 90% of the time when this occurs, I'm trying to leave the office at the end of the day and am not particularly inclined to sit back down and mess with things -.-
Comment 11 Azat Khuzhin 2019-03-02 17:24:41 UTC
And apparently the issue is not only in SD Card Reader (usb2), since suspend just failed due to usb3.0 hub (usb1):

# lsusb.py
 WARNING: Failure to read usb.ids
usb1             1d6b:0002 09  2.00  480MBit/s 0mA 1IF  (Linux 4.20.0-rc4-mainline xhci-hcd xHCI Host Controller 0000:00:14.0) hub
 1-12            05ac:0274 00  2.00   12MBit/s 500mA 5IFs (Apple Inc. Apple Internal Keyboard / Trackpad D3H631636U1GHMFAY4PS)
usb2             1d6b:0003 09  3.00 5000MBit/s 0mA 1IF  (Linux 4.20.0-rc4-mainline xhci-hcd xHCI Host Controller 0000:00:14.0) hub

[  296.849665] PM: suspend entry (deep)
[  296.849669] PM: Syncing filesystems ... done.
[  296.955978] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  296.957607] OOM killer disabled.
[  296.957608] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  296.958856] printk: Suspending console(s) (use no_console_suspend to debug)
[  296.976305] pcieport 0000:06:04.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
[  296.976308] pcieport 0000:06:06.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
[  296.976313] pcieport 0000:06:03.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
[  296.976316] pcieport 0000:06:05.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
[  296.992614] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  296.993263] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
[  296.993270] PM: Device usb1 failed to suspend async: error -16
[  296.998456] sd 0:0:0:0: [sda] Stopping disk
[  298.236647] PM: Some devices failed to suspend, or early wake event detected
[  298.237142] sd 0:0:0:0: [sda] Starting disk
[  298.237366] ACPI: button: The lid device is not compliant to SW_LID.
[  299.286956] OOM killer enabled.
[  299.286958] Restarting tasks ... done.
[  299.290271] brcmfmac: brcmf_inetaddr_changed: fail to get arp ip table err:-52
[  299.403579] video LNXVIDEO:00: Restoring backlight state
[  299.403765] PM: suspend exit
[  299.403861] PM: suspend entry (s2idle)

P.S. and just to note I'm removing usb2 via udev
Comment 12 Azat Khuzhin 2019-03-02 17:28:48 UTC
Doh, please ignore my comment, this is with 4.20rc4-1, i.e. without 45f750c16cae3625014c14c77bd9005eda975d35
Comment 13 nikkoara 2019-03-12 21:29:15 UTC
(In reply to nikkoara from comment #0)
> ...

FWIW, at 5.0.0 I see the same.
Comment 14 nikkoara 2019-03-15 17:58:54 UTC
It seems that this issue is discussed on the linux-usb mailing list, here: https://marc.info/?l=linux-usb&m=154816680816246&w=2
Comment 15 Zhang Rui 2019-07-01 08:39:44 UTC
I believe I see this problem for some time, but then it is gone.
can you please confirm if the problem still exists in the latest upstream kernel?
BTW, reassign to the USB expert.
Comment 16 Greg Kroah-Hartman 2019-07-01 08:53:19 UTC
On Mon, Jul 01, 2019 at 08:41:21AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=202509
> 
> Zhang Rui (rui.zhang@intel.com) changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Component|Hibernation/Suspend         |USB
>            Assignee|rjw@rjwysocki.net           |greg@kroah.com
>             Product|Power Management            |Drivers

All USB bugs should be sent to the linux-usb@vger.kernel.org mailing
list, and not entered into bugzilla.  Please bring this issue up there,
if it is still a problem in the latest kernel release.
Comment 17 nikkoara 2019-07-01 15:07:23 UTC
(In reply to Zhang Rui from comment #15)
> I believe I see this problem for some time, but then it is gone.
> can you please confirm if the problem still exists in the latest upstream
> kernel?
> BTW, reassign to the USB expert.

I do not see it anymore. Sleeping continues to fail but I see no more USB related messages in the dmesg output.