USB device fails to connect when waking up from suspend

Hi all,

I’ve been trying for a couple weeks or so to debug an issue I’m having and I’m not sure how to proceed.

I have a Bluetooth dongle connected to my computer’s USB and everything works fine while the computer is on. When I suspend and resume, though, the dongle doesn’t turn back on. I currently have to re-plug it in to get it to pick up.

I’ve checked out dmesg, but I’m not sure what I’m looking at to be honest.

[198494.861971] ACPI: PM: Waking up from system sleep state S3
[198494.864779] xhci_hcd 0000:02:00.0: xHC error in resume, USBSTS 0x401, Reinit
[198494.864784] usb usb1: root hub lost power or was reset
[198494.864785] usb usb2: root hub lost power or was reset
[198494.864810] sd 1:0:0:0: [sdb] Starting disk
[198494.864820] sd 5:0:0:0: [sdd] Starting disk
[198494.864867] sd 4:0:0:0: [sdc] Starting disk
[198494.864874] sd 0:0:0:0: [sda] Starting disk
[198494.865475] serial 00:04: activated
[198494.923998] nvme nvme0: 15/0/0 default/read/poll queues
[198495.056795] usb 3-4.1.4: reset high-speed USB device number 6 using xhci_hcd
[198495.175736] ata9: SATA link down (SStatus 0 SControl 300)
[198495.175740] ata10: SATA link down (SStatus 0 SControl 300)
[198495.193081] usb 1-3: reset full-speed USB device number 5 using xhci_hcd
[198495.332942] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[198495.332961] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[198495.332980] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[198495.333226] ata5.00: configured for UDMA/133
[198495.334077] ata1.00: configured for UDMA/133
[198495.336659] ata2.00: configured for UDMA/133
[198497.714047] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[198500.216754] ata6: found unknown device (class 0)
[198502.643458] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[198502.683637] ata6.00: configured for UDMA/133
[198502.688583] OOM killer enabled.
[198502.688584] Restarting tasks ... done.
[198502.699954] random: crng reseeded on system resumption
[198502.709799] PM: suspend exit
[198504.721242] Bluetooth: hci0: command 0x1001 tx timeout
[198506.364417] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[198506.578722] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[198512.768696] Bluetooth: hci0: RTL: HCI_OP_READ_LOCAL_VERSION failed (-110)

Happy to provide any other logs or anything. Thanks for looking!

Seems to be a lot of issues similar to this where it times out when trying to load the firmware not sure? :man_shrugging:

To me it’s like a power issue when it goes to sleep it lacks the power to be able to power it on when it’s loading and then bypasses it because it’s not ready so it times out. But this is just my guess thinking what is happening. I could be totally out to lunch. :wink:

Okay, interesting. Do you know of any way to get it to programmatically try again? I’ve tried a few scripts and usbreset to no avail.

Have you set usb to not autosuspend by using a kernel parameter?

usbcore autosuspend=1



It seems the xhci_hcd kernel module may misbehave on suspend.

  • Check if the module is loaded.
lsmod | grep xhci

Unload and reload (or just load) the module and see what changes.

  • You may try a different kernel (i.e. linux-lts) and see if it still happens.
  • The next thing I would do is look for (possible) relevant module options and test different settings (in kernel command line, or in a file in /etc/modules-load.d/*.conf and rebuild kernels).
  • Test if a workaround can temporarily fix it, unloading the module before suspend/sleep. Here is an example service unit (2. Power management).
1 Like

Thank you, I’ve added this parameter now so I’ll see if it fixes things!

That command currently returns:

❯ lsmod | grep xhci
xhci_pci               24576  0
xhci_pci_renesas       24576  1 xhci_pci

I don’t see xhci_hcd in there, so that could be part of the issue. The mouse is working currently (re-plugged after most recent resume).

I switched to linux-lts a couple days ago to try addressing this issue. I’ll look into unloading it before suspend as well.

Thank you!

This is the same output as on my hardware. But I’m not using this usb device. Have you tried it in other ports?


[ricklinux@asus-tuff ~]$ lsmod | grep xhci
xhci_pci               28672  0
xhci_pci_renesas       24576  1 xhci_pci

That’s interesting! It seems like xhci_hcd deals with USB 3.0. I’ve been trying the device in a few different ports, but only the ones on my front panel (which I believe is all 3.0 ports)

I’m gonna test first with the kernel parameters you suggested, but if that doesn’t work I will try a 2.0 port.

I seem to have jacked up my bluetooth a bit. I’m no longer able to connect my mouse or any other bt devices. I can see the adapter and use bluetoothctl to scan and do other things, but the scan never returns anything.

Sadly, I’m not even sure what I changed to get here. I thought I only added a couple kernel parameters x.x

I even booted the EndeavourOS live usb and it had the same bluetooth issues.

This may mean it is HW blocked. Check with rfkill list.
Also, you may need to reset your BIOS. Read your User Manual for instructions.

Thanks for your response! It doesn’t seem to be hardware blocked. I’ll check the BIOS and see what I can turn up.

❯ rfkill list
1: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1 Like

I checked out the BIOS and didn’t see anything unusual. I also tried booting into Windows (haven’t been in there in a couple months) and the mouse connected to Bluetooth right away, so it seems like the hardware is fine.

This topic has shifted away from USB issues into a new Bluetooth problem, so I’m gonna make a new post for that issue.

This doesn’t work for you? It just worked for someone else.

Thanks for the suggestion, I just gave it a shot. It actually disabled my other, wired mouse. The Bluetooth adapter is in the same state it was prior, it shows up as a BT device but fails to properly scan.