Bug 201997

Summary: With kernel 4.19.6 and above, suspend to S3 is broken
Product: Power Management Reporter: devsk (funtoos)
Component: Hibernation/SuspendAssignee: Rafael J. Wysocki (rjw)
Status: RESOLVED CODE_FIX    
Severity: blocking CC: a3at.mail, abdulkadiryaman, gaul, kouakitaki, lnicoara, psterner, rheluani, sascha, xakraz
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 4.19.6 Tree: Mainline
Regression: Yes

Description devsk 2018-12-15 14:09:58 UTC
This is on Dell XPS 9570.

Suspend to S3 works till 4.19.5. With 4.19.6, the system refuses to suspend and wakes right up. I get this:
....
Dec 13 14:18:12 localhost kernel: [   71.815375] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
Dec 13 14:18:12 localhost kernel: [   71.815376] PM: Device usb1 failed to suspend async: error -16
Dec 13 14:18:12 localhost kernel: [   72.281834] PM: Some devices failed to suspend, or early wake event detected
...
Dec 13 14:18:12 localhost kernel: [   72.394977] OOM killer enabled.
Dec 13 14:18:12 localhost kernel: [   72.394977] Restarting tasks ... done.

There is nothing connected to the USB root hub at usb1.

I tried 4.19.9 and its broken as well.
Comment 1 devsk 2018-12-15 14:13:30 UTC
I have tried blacklisting uvcvideo (one of the internal devices on the usb1 hub is the webcam), removing it, but that does not help.

With no internal devices attached on usb1, its only the hub itself left. I obviously can not remove (removable is marked as unknown in sysfs and 'echo' results in write failures for /sys/bus/usb/devices/usb1/remove) the hub before suspend.
Comment 2 devsk 2018-12-15 15:48:18 UTC
I checked out v4.19.9 and reverted 

usb: xhci: Prevent bus suspend if a port connect change or polling state is detected

commit 2f31a67f01a8beb22cae754c53522cb61a005750 upstream.

USB3 roothub might autosuspend before a plugged USB3 device is detected,
causing USB3 device enumeration failure.

suspend works like before. I am not sure what the side effect of reverting that commit is.
Comment 3 devsk 2018-12-16 10:04:50 UTC
Looks like some discussion of this patch at: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1877754.html
Comment 4 Sascha Lüdecke 2018-12-18 10:33:27 UTC
> Looks like some discussion of this patch at:
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1877754.html

On a Gigabyte Aero 14K (i7-7700HQ, GTX 1050 Ti, QHD) I have the same problem using a Qualcomm Atheros QCA6174 based WLAN card. I run ArchLinux.

The patch linked above works fine for me and restores my ability to suspend and hibernate.
Comment 5 devsk 2018-12-24 16:18:58 UTC
No fix in 4.19.x so far.
Comment 6 Sascha Lüdecke 2018-12-29 14:48:14 UTC
The fix appears to be applied in 4.20:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/host/xhci-hub.c?h=v4.20#n1510
Comment 7 devsk 2018-12-30 07:21:09 UTC
Looks like it made it in: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.13
Comment 8 devsk 2018-12-31 07:58:56 UTC
Fixed in 4.19.13
Comment 9 Azat Khuzhin 2019-01-20 22:07:03 UTC
I'm running 5.0 in between of rc1 and rc2 (e1706720408e), so it is contain the referenced patch (2f31a67f01a8beb22cae754c53522cb61a005750), but my macbookpro 11,4 do not want to suspend due to the same reason:

<pre>
Jan 21 00:51:25 PM: suspend entry (deep)
Jan 21 00:51:27 PM: Syncing filesystems ... done.
Jan 21 00:51:27 Freezing user space processes ... (elapsed 0.001 seconds) done.
Jan 21 00:51:27 OOM killer disabled.
Jan 21 00:51:27 Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Jan 21 00:51:27 printk: Suspending console(s) (use no_console_suspend to debug)
Jan 21 00:51:27 pcieport 0000:06:06.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
Jan 21 00:51:27 pcieport 0000:06:05.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
Jan 21 00:51:27 pcieport 0000:06:04.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
Jan 21 00:51:27 pcieport 0000:06:03.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
Jan 21 00:51:27 sd 0:0:0:0: [sda] Synchronizing SCSI cache
Jan 21 00:51:27 sd 0:0:0:0: [sda] Stopping disk
Jan 21 00:51:27 dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
Jan 21 00:51:27 PM: Device usb2 failed to suspend async: error -16
Jan 21 00:51:27 PM: Some devices failed to suspend, or early wake event detected
Jan 21 00:51:27 sd 0:0:0:0: [sda] Starting disk
Jan 21 00:51:27 ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jan 21 00:51:27 ata1.00: unexpected _GTF length (8)
Jan 21 00:51:27 ata1.00: unexpected _GTF length (8)
Jan 21 00:51:27 ata1.00: configured for UDMA/133
Jan 21 00:51:27 OOM killer enabled.
Jan 21 00:51:27 Restarting tasks ... done.
Jan 21 00:51:27 brcmfmac: brcmf_inetaddr_changed: fail to get arp ip table err:-52
Jan 21 00:51:27 video LNXVIDEO:00: Restoring backlight state
Jan 21 00:51:27 PM: suspend exit
Jan 21 00:51:27 PM: suspend entry (s2idle)
Jan 21 00:51:27 PM: Syncing filesystems ... done.
Jan 21 00:51:30 Freezing user space processes ... (elapsed 0.001 seconds) done.
Jan 21 00:51:30 OOM killer disabled.
Jan 21 00:51:30 Freezing remaining freezable tasks ... (elapsed 0.055 seconds) done.
Jan 21 00:51:30 printk: Suspending console(s) (use no_console_suspend to debug)
Jan 21 00:51:30 sd 0:0:0:0: [sda] Synchronizing SCSI cache
Jan 21 00:51:30 sd 0:0:0:0: [sda] Stopping disk
Jan 21 00:51:30 dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
Jan 21 00:51:30 PM: Device usb2 failed to suspend async: error -16
Jan 21 00:51:30 PM: Some devices failed to suspend, or early wake event detected
Jan 21 00:51:30 sd 0:0:0:0: [sda] Starting disk
Jan 21 00:51:30 ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Jan 21 00:51:30 ata1.00: unexpected _GTF length (8)
Jan 21 00:51:30 ata1.00: unexpected _GTF length (8)
Jan 21 00:51:30 ata1.00: configured for UDMA/133
Jan 21 00:51:30 OOM killer enabled.
Jan 21 00:51:30 Restarting tasks ... done.
Jan 21 00:51:30 video LNXVIDEO:00: Restoring backlight state
Jan 21 00:51:30 PM: suspend exit
Jan 21 00:51:30 Process accounting resumed
Jan 21 00:51:42 brcmfmac: brcmf_inetaddr_changed: fail to get arp ip table err:-52
</pre>

<pre>
lsusb.py
 WARNING: Failure to read usb.ids
usb1             1d6b:0002 09  2.00  480MBit/s 0mA 1IF  (Linux 5.0.0-rc2-custom-00217-ge1706720408e 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)
 1-8             05ac:8290 ef  2.01   12MBit/s 0mA 6IFs (Broadcom Corp. Bluetooth USB Host Controller)
usb2             1d6b:0003 09  3.00 5000MBit/s 0mA 1IF  (Linux 5.0.0-rc2-custom-00217-ge1706720408e xhci-hcd xHCI Host Controller 0000:00:14.0) hub
</pre>

Nothing attached to the USB ports
Comment 10 Azat Khuzhin 2019-01-20 22:19:43 UTC
> I'm running 5.0 in between of rc1 and rc2 (e1706720408e), so it is contain
> the referenced patch (2f31a67f01a8beb22cae754c53522cb61a005750), but my
> macbookpro 11,4 do not want to suspend due to the same reason:

I meant this patch of course 45f750c16cae3625014c14c77bd9005eda975d35 (not the one that introduces the problem 2f31a67f01a8beb22cae754c53522cb61a005750)
Comment 11 Azat Khuzhin 2019-01-20 22:22:33 UTC
Also what is curious is that the first time (just after boot) suspend works like a charm, but after first resume it breaks, I guess I need to dig into this

P.S. this is like the card reader in MBP, it also stop working after first suspend-resume
Comment 12 Azat Khuzhin 2019-01-20 22:28:58 UTC
So I guess that the problem is the card reader, connected to usb2, which fails after first suspend-resume:

Jan 21 01:26:53 Process accounting resumed
Jan 21 01:26:57 usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
Jan 21 01:26:57 usb 2-4: USB disconnect, device number 2
Jan 21 01:27:01 usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
Jan 21 01:27:03 brcmfmac: brcmf_inetaddr_changed: fail to get arp ip table err:-52
Jan 21 01:27:05 usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
Jan 21 01:27:09 usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
Jan 21 01:27:13 usb usb2-port4: Cannot enable. Maybe the USB cable is bad?
...
Comment 13 Azat Khuzhin 2019-01-21 06:09:30 UTC
So I tried to unbind/bind the USB hub and suspend works one more time after resume:

> echo 0000:00:14.0 | tee /sys/bus/pci/drivers/xhci_hcd/unbind
> /sys/bus/pci/drivers/xhci_hcd/bind

but third time it reports the same error:

> Jan 21 09:06:52 dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
> Jan 21 09:06:52 PM: Device usb2 failed to suspend async: error -16
> Jan 21 09:06:52 PM: Some devices failed to suspend, or early wake event
> detected
Comment 14 Azat Khuzhin 2019-01-23 21:18:39 UTC
And removing the sd apple card reader indeed fixes the issue:

> echo 1 >| /sys/bus/usb/devices/2-4/remove
Comment 15 Azat Khuzhin 2019-01-23 21:20:23 UTC
Also I tried with/without 0x80 (XHCI_RESET_ON_RESUME) for xhci_hcd.quirks, nothing changes though
Comment 16 taki 2019-01-26 04:04:16 UTC
I can confirm this bug is present on MacBookPro 12,1, too, running kernel 4.20.3. First time the suspend works, but after waking up once, it resume immediately after suspend. dmesg shows the following:

> [  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 17 nikkoara 2019-01-29 12:16:42 UTC
I confirm this issue on both my MacBookAir6,2 and MacBookPro11,4 running Arch with kernel 4.20.4.
Comment 18 petey 2019-01-29 15:52:37 UTC
I confirm this issue on my MacBook Air 6.2.
Comment 19 canavar 2019-02-02 19:59:16 UTC
I confirm this issue on my MacbookPro14 running kernel 4.20.6 with archlinux
Comment 20 Xavier Krantz 2019-02-04 15:50:14 UTC
I confirm this issue on my MacBookPro12,1 running kernel 4.20.6 with archlinux
Comment 21 Xavier Krantz 2019-02-04 15:52:01 UTC
(In reply to Azat Khuzhin from comment #11)
> Also what is curious is that the first time (just after boot) suspend works
> like a charm, but after first resume it breaks, I guess I need to dig into
> this
> 
> P.S. this is like the card reader in MBP, it also stop working after first
> suspend-resume

I confirm  that the first time (just after boot) suspend works

MacBookPro12,1 running kernel 4.20.6 with archlinux
Comment 22 devsk 2019-02-04 22:27:50 UTC
Folks: I think the original problem (seen on XPS 15, with no peripherals attached) reported in this bug is fixed. And hence the status of the bug. Nobody is going to fix a resolved bug...;-)

Please open a new issue and start a new discussion
Comment 23 Andrew Gaul 2019-02-07 22:50:46 UTC
nikkora filed a MacBook-specific issue:

https://bugzilla.kernel.org/show_bug.cgi?id=202509

He also suggests a workaround there.