[BUG] xhci: ASM2142 command-abort timeout (-110) kills the host instead of resetting it

[BUG] xhci: ASM2142 command-abort timeout (-110) kills the host instead of resetting it

[metaphaze]

Hello,

xhci_abort_cmd_ring() treats a command-abort handshake timeout as a dead
host. On an ASMedia ASM2142 that timeout happens while a USB 2.0 device
is failing enumeration, and the whole controller is marked dead. The
comment above the handshake already says a timeout should be recovered
with a host controller reset rather than treated as -ENODEV.

Hardware
  ASUS PRIME Z270-AR, BIOS 1301 (2018-03-14)
  0000:06:00.0 ASMedia ASM2142/ASM3142 [1b21:2142]
  Subsystem ASUSTeK [1043:8732]
  Onboard rear USB-C (port EC1) and the teal USB 3.1 Type-A share it
  Intel xHCI on the same board enumerates the same phones normally

Software
  Linux maynard 6.18.38-gentoo-MetaPhaze-MAYNARD #11 SMP PREEMPT_DYNAMIC
  xhci_hcd, in tree. Last bind logged:
    hcc params 0x0200ef80 hci version 0x110 quirks 0x0000000000800010
  Boot also logs:
    DMAR: [Firmware Bug]: RMRR entry for device 06:00.0 is broken - applying workaround

What happens
  A USB 2.0-only device (phone) is plugged into the rear USB-C port.
  The driver correctly starts high-speed enumeration on the companion
  bus (usb 3-1, 480 Mbps). The SuperSpeed bus stays empty.
  The device-descriptor read fails:

    usb 3-1: new high-speed USB device number N using xhci_hcd
    usb 3-1: device descriptor read/64, error -71

  That repeats. The address assignment reaches address 4 and fails
  with -108. About 18 seconds after the first failed read the command
  ring cannot be aborted and the whole host is declared dead:

    xhci_hcd 0000:06:00.0: Abort failed to stop command ring: -110
    xhci_hcd 0000:06:00.0: xHCI host controller not responding, assume dead
    xhci_hcd 0000:06:00.0: HC died; cleaning up
    xhci_hcd 0000:06:00.0: Timeout while waiting for setup device command
    usb 3-1: device not accepting address 4, error -108
    usb usb3-port1: couldn't allocate usb_device

  -110 is -ETIMEDOUT from xhci_handshake() in xhci_abort_cmd_ring()
  (drivers/usb/host/xhci-ring.c, 5 second CRR wait). The function then
  calls xhci_halt() and xhci_hc_died(). The comment there says:

    If CRR is not negated in 5 seconds then driver handles it as if
    host died (-ENODEV). In the future we should distinguish between
    -ENODEV and -ETIMEDOUT and try to recover a -ETIMEDOUT with a
    host controller reset.

  A PCI function reset brings the controller back until the next
  high-speed attach:

    echo 0000:06:00.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
    echo 1 > /sys/bus/pci/devices/0000:06:00.0/reset
    echo 0000:06:00.0 > /sys/bus/pci/drivers/xhci_hcd/bind

  The cable with nothing attached does not trip this. Plugging the
  device into the cable does, every time we tried (three attaches
  after a clean reset: 15:11, 15:26, and 16:55 CDT on 2026-10-24).
  No idVendor is ever read, so the device never enumerates. The same
  phones enumerate on the Intel controller.

  During unbind/reset the kernel also logged a correctable PCIe Data
  Link Layer timeout on 06:00.0. That was not present on the original
  death, only around the manual reset.

The USB 2.0 fallback itself is selected correctly. The descriptor
failure may be this port's D+/D- path, but the controller-wide death
is the driver giving up on -ETIMEDOUT. A host reset, which is what
the comment proposes and what the manual PCI reset already does,
would bring the other port on this chip back instead of leaving both
ports dead until the next unbind.

I can retest a patch. The machine is available.

Thanks

Re: [BUG] xhci: ASM2142 command-abort timeout (-110) kills the host instead of resetting it

[Michal Pecio]

On Sat, 24 Oct 2026 17:31:34 -0500, metaphaze wrote:
> Hello,
> 
> xhci_abort_cmd_ring() treats a command-abort handshake timeout as a dead
> host. On an ASMedia ASM2142 that timeout happens while a USB 2.0 device
> is failing enumeration, and the whole controller is marked dead.

Yes, this happens sometimes, also on my ASM3142 (same PCI ID, not sure
what the differences are), but I have never had a reproducible case.

Could you record a trace of what happens there?

# disconnect other devices from this controller
cd /sys/kernel/tracing/
echo 1 >events/xhci-hcd/xhci_queue_trb/enable
echo 1 >events/xhci-hcd/xhci_handle_event/enable
echo 1 >events/xhci-hcd/xhci_get_port_status/enable
echo 1 >events/xhci-hcd/xhci_portsc_writel/enable
echo 1 >tracing_on
# connect the device, wait for failure
cp trace /tmp/xhci-trace
# send the trace and dmesg

> The comment above the handshake already says a timeout should be
> recovered with a host controller reset rather than treated as -ENODEV.

Theoretically possible, but resetting the HC would still be somewhat
disruptive and it may be better to just prevent triggering HW bugs.
Usually this happens and then there is little urgency to implement
automatic recovery by reset.

>   A PCI function reset brings the controller back until the next
>   high-speed attach:
> 
>     echo 0000:06:00.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
>     echo 1 > /sys/bus/pci/devices/0000:06:00.0/reset
>     echo 0000:06:00.0 > /sys/bus/pci/drivers/xhci_hcd/bind

Is this PCI reset necessary?

An unbind/bind cycle issues xHCI reset which normally suffices.

Regards,
Michal