You are not logged in.

#1 2018-12-15 16:36:55

dasBook
Member
Registered: 2015-10-27
Posts: 12

Suspend started to fail with update to 4.19.8

My MBP (2015, 15") started to fail to sleep after last update with the following relevant dmesg output:

[13508.802033] PM: suspend entry (deep)
[13508.802035] PM: Syncing filesystems ... done.
...
[13508.819782] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
[13508.819784] PM: Device usb2 failed to suspend async: error -16
...
[13509.836594] PM: Some devices failed to suspend, or early wake event detected

AFAICT, the error is -EBUSY and there's like a bajillion places in the kernel that report EBUSY in the USB code.  Anybody else seeing this? If so, any suggestions on how to fix it, or track the issue? Or maybe points to a more relevant other forum?

Update: it looks like the issue appeared in 4.19.6, see here. There is a workaround, to build your own after reverting commit 2f31a67f01a8beb22cae754c53522cb61a005750.

Last edited by dasBook (2018-12-15 17:01:54)

Offline

#2 2018-12-19 11:30:30

jaylittle
Member
Registered: 2013-01-16
Posts: 47

Re: Suspend started to fail with update to 4.19.8

Yeah I've been seeing this as well on a Purism Librem15 rev3 with no USB devices plugged into it at the time of suspend.  Thanks for posting about it as that assures me that I'm not going crazy.  Hopefully they will fix this soon.

Offline

#3 2018-12-19 18:47:50

revberaldo
Member
From: Campinas, Brazil
Registered: 2009-09-18
Posts: 49
Website

Re: Suspend started to fail with update to 4.19.8

I'm having exactly the same issue. Turns out that if I stop NetworkManager, suspend works fine again.

Running on a Macbook Air 2017 13" btw.

Offline

#4 2018-12-24 00:17:59

soren121
Member
From: USA
Registered: 2011-11-20
Posts: 9

Re: Suspend started to fail with update to 4.19.8

The patch for this will be in 4.20-rc8 [source]. And probably the next 4.19 patch release as well.

Offline

#5 2019-01-08 01:05:44

revberaldo
Member
From: Campinas, Brazil
Registered: 2009-09-18
Posts: 49
Website

Re: Suspend started to fail with update to 4.19.8

Still having the same problem on kernel 4.20. I think these are the relevant dmesg lines:

[jan 7 20:40] PM: suspend entry (deep)
[  +0,000002] PM: Syncing filesystems ... done.
[  +0,018885] Freezing user space processes ... (elapsed 0.002 seconds) done.
[  +0,002113] OOM killer disabled.
[  +0,000001] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  +0,001323] printk: Suspending console(s) (use no_console_suspend to debug)
[  +0,000798] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16
[  +0,000004] PM: Device usb2 failed to suspend async: error -16
[  +0,015435] pcieport 0000:06:04.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
[  +0,000035] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  +0,000040] pcieport 0000:06:05.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
[  +0,000006] pcieport 0000:06:06.0: quirk: waiting for Thunderbolt to reestablish PCI tunnels...
[  +0,000761] sd 0:0:0:0: [sda] Stopping disk
[  +0,093041] PM: Some devices failed to suspend, or early wake event detected
[  +0,000424] sd 0:0:0:0: [sda] Starting disk
[  +0,110119] OOM killer enabled.
[  +0,000003] Restarting tasks ... done.
[  +0,055958] video LNXVIDEO:00: Restoring backlight state
[  +0,000129] PM: suspend exit
[  +0,000057] PM: suspend entry (s2idle)
[  +0,000001] PM: Syncing filesystems ... done.

Offline

#6 2019-01-29 12:04:55

dasBook
Member
Registered: 2015-10-27
Posts: 12

Re: Suspend started to fail with update to 4.19.8

Still failing for me, too. Absolutely bonkers.

Offline

#7 2019-01-30 11:04:47

mod24
Member
Registered: 2006-11-25
Posts: 20

Re: Suspend started to fail with update to 4.19.8

Hi there,

I do have the exact same Problems since 4.19.8 an still newest kernel 4.20.5-arch1-1-ARCH on my mbp. Tried everything I can imagine, but no look. Would be extremly grateful if someone would have an Idea on how to solve this.

Kind Regards
Michael

Offline

#8 2019-01-30 12:40:43

Tom B
Member
Registered: 2014-01-15
Posts: 187
Website

Re: Suspend started to fail with update to 4.19.8

Unfortunately I still have the same problem. It's odd because I can suspend once after boot and it's fine but trying to suspend a second time causes the "usb2 failed to suspend" error.

Offline

#9 2019-01-30 14:03:00

mod24
Member
Registered: 2006-11-25
Posts: 20

Re: Suspend started to fail with update to 4.19.8

Forgot to mention: The exact same symptoms apply to me: The first suspend after reboot works, after that I get the "usb2 failed to suspend".

Offline

#10 2019-02-02 10:46:18

hnra
Member
Registered: 2019-02-02
Posts: 3

Re: Suspend started to fail with update to 4.19.8

Had the same issue, first suspend works but subsequent ones fail. Just updated the kernel and the issue seems fixed, tried a couple of consecutive suspends and all worked.

Kernel version: 4.20.6-arch1-1

EDIT: Worked for like a week with multiple restarts, now its back.

Last edited by hnra (2019-02-22 15:49:55)

Offline

#11 2019-02-02 17:02:59

canavar
Member
Registered: 2019-02-02
Posts: 1

Re: Suspend started to fail with update to 4.19.8

I have 4.20.6-arch1-1-ARCH and still getting the same error;

[   87.281315] dpm_run_callback(): usb_dev_suspend+0x0/0x10 returns -16                                                                                                                                                                                                                         
[   87.281318] PM: Device usb2 failed to suspend async: error -16                                                                                                                                                                                                                               [   87.316409] sd 0:0:0:0: [sda] Synchronizing SCSI cache                                                                                                                                                                                                                                       [   87.318809] sd 0:0:0:0: [sda] Stopping disk                                                                                                                                                                                                                                                  
[   87.650193] PM: Some devices failed to suspend, or early wake event detected   

works at first suspend but fails for the subsequent ones.

Last edited by canavar (2019-02-02 17:03:55)

Offline

#12 2019-02-03 13:28:07

Tom B
Member
Registered: 2014-01-15
Posts: 187
Website

Re: Suspend started to fail with update to 4.19.8

4.20.6-arch1-1 makes no difference for me either.

There is obviously some kind of  state change that isn't reset after the first suspend. I've tried reloading the following modules between suspends

usbhid, xhci_hcd, xhci_pci

but it doesn't seem to help.

Last edited by Tom B (2019-02-03 13:42:12)

Offline

#13 2019-02-04 00:41:09

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: Suspend started to fail with update to 4.19.8

@Tom B is you build 4.20.6 with 2f31a67f01a8beb22cae754c53522cb61a005750 reverted is the issue still present?

Offline

#14 2019-02-04 13:07:19

Tom B
Member
Registered: 2014-01-15
Posts: 187
Website

Re: Suspend started to fail with update to 4.19.8

I haven't done a custom build, I'm using the latest version of the arch kernel from the repositories. If 2f31a67f01a8beb22cae754c53522cb61a005750 is reverted in the repo build then yes, otherwise I'll need to a custom build.

Offline

#15 2019-02-04 13:15:31

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: Suspend started to fail with update to 4.19.8

That commit has not been reverted upstream.

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 01b5818a4be5..da98a11244e2 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1474,18 +1474,15 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
 	unsigned long flags;
 	struct xhci_hub *rhub;
 	struct xhci_port **ports;
-	u32 portsc_buf[USB_MAXCHILDREN];
-	bool wake_enabled;
 
 	rhub = xhci_get_rhub(hcd);
 	ports = rhub->ports;
 	max_ports = rhub->num_ports;
 	bus_state = &xhci->bus_state[hcd_index(hcd)];
-	wake_enabled = hcd->self.root_hub->do_remote_wakeup;
 
 	spin_lock_irqsave(&xhci->lock, flags);
 
-	if (wake_enabled) {
+	if (hcd->self.root_hub->do_remote_wakeup) {
 		if (bus_state->resuming_ports ||	/* USB2 */
 		    bus_state->port_remote_wakeup) {	/* USB3 */
 			spin_unlock_irqrestore(&xhci->lock, flags);
@@ -1493,37 +1490,26 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
 			return -EBUSY;
 		}
 	}
-	/*
-	 * Prepare ports for suspend, but don't write anything before all ports
-	 * are checked and we know bus suspend can proceed
-	 */
-	bus_state->bus_suspended = 0;
+
 	port_index = max_ports;
+	bus_state->bus_suspended = 0;
 	while (port_index--) {
+		/* suspend the port if the port is not suspended */
 		u32 t1, t2;
+		int slot_id;
 
 		t1 = readl(ports[port_index]->addr);
 		t2 = xhci_port_state_to_neutral(t1);
-		portsc_buf[port_index] = 0;
-
-		/* Bail out if a USB3 port has a new device in link training */
-		if ((hcd->speed >= HCD_USB3) &&
-		    (t1 & PORT_PLS_MASK) == XDEV_POLLING) {
-			bus_state->bus_suspended = 0;
-			spin_unlock_irqrestore(&xhci->lock, flags);
-			xhci_dbg(xhci, "Bus suspend bailout, port in polling\n");
-			return -EBUSY;
-		}
 
-		/* suspend ports in U0, or bail out for new connect changes */
-		if ((t1 & PORT_PE) && (t1 & PORT_PLS_MASK) == XDEV_U0) {
-			if ((t1 & PORT_CSC) && wake_enabled) {
-				bus_state->bus_suspended = 0;
+		if ((t1 & PORT_PE) && !(t1 & PORT_PLS_MASK)) {
+			xhci_dbg(xhci, "port %d not suspended\n", port_index);
+			slot_id = xhci_find_slot_id_by_port(hcd, xhci,
+					port_index + 1);
+			if (slot_id) {
 				spin_unlock_irqrestore(&xhci->lock, flags);
-				xhci_dbg(xhci, "Bus suspend bailout, port connect change\n");
-				return -EBUSY;
+				xhci_stop_device(xhci, slot_id, 1);
+				spin_lock_irqsave(&xhci->lock, flags);
 			}
-			xhci_dbg(xhci, "port %d not suspended\n", port_index);
 			t2 &= ~PORT_PLS_MASK;
 			t2 |= PORT_LINK_STROBE | XDEV_U3;
 			set_bit(port_index, &bus_state->bus_suspended);
@@ -1532,7 +1518,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
 		 * including the USB 3.0 roothub, but only if CONFIG_PM
 		 * is enabled, so also enable remote wake here.
 		 */
-		if (wake_enabled) {
+		if (hcd->self.root_hub->do_remote_wakeup) {
 			if (t1 & PORT_CONNECT) {
 				t2 |= PORT_WKOC_E | PORT_WKDISC_E;
 				t2 &= ~PORT_WKCONN_E;
@@ -1552,26 +1538,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
 
 		t1 = xhci_port_state_to_neutral(t1);
 		if (t1 != t2)
-			portsc_buf[port_index] = t2;
-	}
-
-	/* write port settings, stopping and suspending ports if needed */
-	port_index = max_ports;
-	while (port_index--) {
-		if (!portsc_buf[port_index])
-			continue;
-		if (test_bit(port_index, &bus_state->bus_suspended)) {
-			int slot_id;
-
-			slot_id = xhci_find_slot_id_by_port(hcd, xhci,
-							    port_index + 1);
-			if (slot_id) {
-				spin_unlock_irqrestore(&xhci->lock, flags);
-				xhci_stop_device(xhci, slot_id, 1);
-				spin_lock_irqsave(&xhci->lock, flags);
-			}
-		}
-		writel(portsc_buf[port_index], ports[port_index]->addr);
+			writel(t2, ports[port_index]->addr);
 	}
 	hcd->state = HC_STATE_SUSPENDED;
 	bus_state->next_statechange = jiffies + msecs_to_jiffies(10);

Manually adjusted revert for 4.20.6 (build tested only)

Offline

#16 2019-02-19 13:24:26

dasBook
Member
Registered: 2015-10-27
Posts: 12

Re: Suspend started to fail with update to 4.19.8

Following the resolution for 201997 I filed 202509 because the suspend is still broken in 4.20.10 the cause still related to USB power management. As I detailed there the symptom for the second bug is the same (the EBUSY error). FWIW, the workaround for me is to remove the SD card reader before the first suspend:

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

and then all subsequent suspends work. It is far from ideal but HTH.

Offline

#17 2019-03-10 11:51:24

droptable
Member
Registered: 2019-03-10
Posts: 1

Re: Suspend started to fail with update to 4.19.8

I have the same problem on a Thinkpad T430s running kernel 5.0.0 and finally found a workaround that seems to fix it, but I don't know how universal this approach is.

First execute lsusb.py to find the device that causes the problem.
For me it was a xhci host controller with no devices attached:

usb2             1d6b:0003 09  3.00 5000MBit/s 0mA 1IF  (Linux 5.0.0-arch1-1-ARCH xhci-hcd xHCI Host Controller 0000:00:14.0) hub

Remember the PCI ID (here 0000:00:14.0).

Create a file under /usr/lib/systemd/system-sleep/ e.g. 10-usb_suspend_workaround.sh and change PCI_DEV to match yours.

#!/bin/bash

PCI_DEV="0000:00:14.0"

case $1/$2 in
  pre/*)
    # echo "Going to $2..."
    echo "$PCI_DEV" > /sys/bus/pci/drivers/xhci_hcd/unbind
    ;;
  post/*)
    # echo "Waking up from $2..."
    echo "$PCI_DEV" > /sys/bus/pci/drivers/xhci_hcd/bind
    ;;
esac

Don't forget to chmod +x the file.

Offline

#18 2019-03-27 15:28:40

yubo56
Member
Registered: 2016-01-07
Posts: 4

Re: Suspend started to fail with update to 4.19.8

+1 for xhci_hcd unbind! On a Macbook pro 15.6" from 2016.

Offline

#19 2019-03-27 19:07:39

hnra
Member
Registered: 2019-02-02
Posts: 3

Re: Suspend started to fail with update to 4.19.8

Unfortunately the bind/unbind script crashes X11 and leaves the keyboard unresponsive on resume.

Offline

#20 2019-04-06 12:11:10

hnra
Member
Registered: 2019-02-02
Posts: 3

Re: Suspend started to fail with update to 4.19.8

A fix for this issue seems to be included in the mainline kernel. Built and tested the mainline kernel from the AUR and it seems to be fixed.

"Don't let USB3 ports stuck in polling state prevent suspend"

https://git.kernel.org/pub/scm/linux/ke … 39be98c913

Offline

#21 2022-11-23 20:03:07

NickTouik
Member
Registered: 2014-01-15
Posts: 19

Re: Suspend started to fail with update to 4.19.8

I want to report that droptable's 10-usb_suspend_workaround.sh also fixed a broken suspend on my Dell Lattitude 7390 laptop that had similar symptoms.

I run Manjaro btw.

Offline

Board footer

Powered by FluxBB