Bug 202509

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

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.

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 
```

> 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

(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.

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
```

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.

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.

> * 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

(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 -.-

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

Doh, please ignore my comment, this is with 4.20rc4-1, i.e. without 45f750c16cae3625014c14c77bd9005eda975d35

(In reply to nikkoara from comment #0)
> ...

FWIW, at 5.0.0 I see the same.

It seems that this issue is discussed on the linux-usb mailing list, here: https://marc.info/?l=linux-usb&m=154816680816246&w=2

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.

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.

(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.