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

[Michal Pecio <michal.pecio@gmail.com>]

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