New: xhci_hcd: USB device on onboard port fails to enumerate (error -110/-71), delays boot around 70s on ASUS ROG Strix X870-F

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

Bug ID: 222049
Summary: xhci_hcd: USB device on onboard port fails to
enumerate (error -110/-71), delays boot around 70s on ASUS ROG Strix X870-F
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

System: ASUS ROG Strix X870-F Gaming WiFi, BIOS 2402 (also reproduced on 2301)
Kernel: 7.2.5-200.fc44.x86_64 i'm using Fedora 44

An internal/onboard USB device consistently fails to enumerate on port 1-11 during every boot, causing dracut-initqueue.service to block for approximately 60-70 seconds before boot can continue.

The device produces repeated "device descriptor read/64, error -110" failures, followed by a port power cycle attempt, then repeated "Device not responding to setup address" / "error -71" failures, before the kernel gives up with "unable to enumerate USB device" at around 70 seconds.

This is fully reproducible across multiple boots and persists after I've tried Updating BIOS from 2301 to the latest 2402
Disabling AURA/RGB in BIOS (an onboard ASUS AURA LED Controller
0b05:19af is present at a different port, 1-7, and is unaffected)
Physically disconnecting all external USB peripherals
(only mouse, keyboard, fingerprint reader remain connected)
Disconnecting the internal front-panel USB 2.0 header

Since it persists with no external devices connected and no front-panel header connected, the failing device appears to be an internal/onboard USB endpoint on the motherboard itself.

❯ journalctl -b 0 -o short-monotonic --no-pager | grep -B3 -A3 "1-11"

[    5.171308] fedora-main kernel: usb 1-7: Manufacturer: AsusTek Computer Inc.
[    5.171359] fedora-main kernel: usb 1-7: SerialNumber: 9876543210
[    5.193023] fedora-main kernel: hid-generic 0003:0B05:19AF.000A:
hiddev100,hidraw9: USB HID v1.11 Device [AsusTek Computer Inc. AURA LED
Controller] on usb-0000:09:00.0-7/input2
[    5.366352] fedora-main kernel: usb 1-11: new high-speed USB device number
10 using xhci_hcd
[   10.970441] fedora-main kernel: usb 1-11: device descriptor read/64, error
-110
[   26.843437] fedora-main kernel: usb 1-11: device descriptor read/64, error
-110
[   27.129393] fedora-main kernel: usb 1-11: new high-speed USB device number
11 using xhci_hcd
[   32.474430] fedora-main kernel: usb 1-11: device descriptor read/64, error
-110
[   48.346395] fedora-main kernel: usb 1-11: device descriptor read/64, error
-110
[   48.460043] fedora-main kernel: usb usb1-port11: attempt power cycle
[   48.904403] fedora-main kernel: usb 1-11: new high-speed USB device number
12 using xhci_hcd
[   53.704061] fedora-main kernel: usb 1-11: Device not responding to setup
address.
[   58.717053] fedora-main kernel: usb 1-11: Device not responding to setup
address.
[   58.933398] fedora-main kernel: usb 1-11: device not accepting address 12,
error -71
[   59.113460] fedora-main kernel: usb 1-11: new high-speed USB device number
13 using xhci_hcd
[   62.202367] fedora-main systemd-udevd[404]: usb1: Worker [444] processing
SEQNUM=2850 is taking a long time.
[   63.914407] fedora-main kernel: usb 1-11: Device not responding to setup
address.
[   68.926397] fedora-main kernel: usb 1-11: Device not responding to setup
address.
[   69.141050] fedora-main kernel: usb 1-11: device not accepting address 13,
error -71
[   69.148028] fedora-main kernel: usb usb1-port11: unable to enumerate USB
device
[   69.237128] fedora-main systemd[1]: Finished dracut-initqueue.service -
dracut initqueue hook.
[   69.237364] fedora-main systemd[1]: Reached target remote-fs-pre.target -

Preparation for Remote File Systems.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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

Michał Pecio ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Michał Pecio ([email protected]) --- Did this device ever work in the past?

It's probably Mediatek Bluetooth, they get stuck in such state and need a standby power cycle to recover (disconnect the PC from power for a minute). I recall some discussion about this on linux-bluetooth, but not sure how far it went. IIRC some users had luck blacklisting btusb (which implies that the driver puts the device in the bad state), or maybe it was with Realtek chips, not sure. Others found that some BIOS settings like "ErP ready" cut power to BT during standby and thus "fix" this device automatically.

IIRC the delay itself is not the kernel's fault - userspace started quickly, but then it chooses to wait long time for enumeration to complete (or fail).

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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

--- Comment #2 from Todd ([email protected]) ---
Thank you for the explanation Michał. I’ll go through all those Bluetooth troubleshooting steps.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

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

Todd ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |ANSWERED

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.