Re: xhci: hard lockup on ASM2142 when Address Device command times out

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

On Wed, 19 Aug 2026 11:35:40 +0100, Pedro Fonseca wrote:
> I am hitting a reproducible hard lockup in xhci_hcd on an ASMedia
> ASM2142/ASM3142 controller. It happened twice in three days on the
> same kernel, and both times the machine lost all USB input and had
> to be power-cycled.

Is this a regression or just using new hardware for the first time?

> The two occurrences produced different backtraces, and I think
> together they show both ends of the same deadlock: one caught the CPU
> holding xhci->lock, the other caught a CPU spinning for it from hard
> IRQ context.

Yes, a known bug when command abort fails and in some other cases.
The lock ought to be dropped while waiting, but this opens new race
conditions which will need to be analyzed and solved.

Not a deadlock, lock holder times out.

> Affected controller:
> 
>    26:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM2142/ASM3142
>            USB 3.1 Host Controller [1b21:2142]
>            Subsystem: Micro-Star International Co., Ltd. [MSI] [1462:7a32]
>            Kernel driver in use: xhci_hcd
> 
> Topology below it: a Genesys Logic hub (05e3:0610 USB2 / 05e3:0626
> USB3) with a Ducky keyboard (04d9:0356) and a OnePlus 6T phone
> (18d1:4ee7, ADB/charging mode) attached.
> 
>    /:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
>        |__ Port 002: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
>            |__ Port 002: Dev 003, If 0, Class=Vendor Specific Class,
>                                         Driver=[none], 480M
>            |__ Port 003: Dev 004, If 0, Class=HID, Driver=usbhid, 12M
>            |__ Port 003: Dev 004, If 1, Class=HID, Driver=usbhid, 12M
>            |__ Port 003: Dev 004, If 2, Class=HID, Driver=usbhid, 12M
> 
> 
> Trigger
> =======
> 
> In both occurrences the lockup happens exactly 19 seconds after a fast
> connect/disconnect cycle of the OnePlus 6T on port 3-2.2, behind the
> Genesys hub. The phone re-enumerates repeatedly as ADB switches modes,
> and the controller dies in the middle of a setup device command.
> 
> It is not fully deterministic - it happened twice in roughly two days
> of normal use, not on every plug event.
> 
> 
> Occurrence 2 - 2026-08-19 10:45:05 (waiter side)
> ================================================
> 
> Aug 19 10:44:45 usb 3-2.2: new high-speed USB device number 13 using 
> xhci_hcd
> Aug 19 10:44:45 usb 3-2.2: New USB device found, idVendor=18d1, 
> idProduct=4ee7, bcdDevice= 4.09
> Aug 19 10:44:45 usb 3-2.2: Product: OnePlus 6T
> Aug 19 10:44:45 usb 3-2.2: USB disconnect, device number 13
> Aug 19 10:44:46 usb 3-2.2: new high-speed USB device number 14 using 
> xhci_hcd
> Aug 19 10:45:05 watchdog: CPU11: Watchdog detected hard LOCKUP on cpu 11
> [...]
> Aug 19 10:45:05 xhci_hcd 0000:26:00.0: Abort failed to stop command 
> ring: -110
> Aug 19 10:45:05 xhci_hcd 0000:26:00.0: xHCI host controller not 
> responding, assume dead
> Aug 19 10:45:05 xhci_hcd 0000:26:00.0: HC died; cleaning up
> Aug 19 10:45:05 xhci_hcd 0000:26:00.0: Timeout while waiting for setup 
> device command
> Aug 19 10:45:05 usb 3-1: USB disconnect, device number 2
> Aug 19 10:45:05 usb 4-2: USB disconnect, device number 2
> Aug 19 10:45:05 usb 3-2: USB disconnect, device number 3
> Aug 19 10:45:06 usb 3-2.2: device not accepting address 14, error -108
> Aug 19 10:45:06 usb 3-2-port2: couldn't allocate usb_device
> Aug 19 10:45:06 usb 3-2.3: USB disconnect, device number 12

Looks like a firmware bug, because ASMedia should internally time
out an Address Device command after 3 seconds. The only exception
I know is the old ASM1042 (waits forever and can't be aborted). 

An interesting experiment would be to unplug the offending device
before abort timeout. This recovers even ASM1042, at least so long
as it's alive. You should see "error -71" and continued operation:

usb 3-2.2: device not accepting address 14, error -71

> After the controller died, the second xHCI on this board (03:00.0, the
> AMD X370 chipset one) also started failing while I was trying to plug
> in a spare keyboard to reboot cleanly:
> 
> Aug 19 10:45:52 usb 1-12: new full-speed USB device number 26 using xhci_hcd
> Aug 19 10:45:57 usb 1-12: Device not responding to setup address.
> Aug 19 10:45:58 usb 1-12: device not accepting address 26, error -71
> Aug 19 10:45:58 usb 1-12: WARN: invalid context state for evaluate context command.
> Aug 19 10:46:01 usb usb1-port12: attempt power cycle
> Aug 19 10:49:32 usb 1-12: device not accepting address 29, error -71
> Aug 19 10:49:59 xhci_hcd 0000:03:00.0: xHC error in resume, USBSTS 0x401, Reinit
> Aug 19 10:49:59 usb usb1: root hub lost power or was reset
> Aug 19 10:49:59 usb usb2: root hub lost power or was reset

Are you sure it's not a pre-existing, independent issue?

> I power-cycled the machine at 10:50.

Probably SSH would work over some PCI NIC.

Regards,
Michal