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

Hi Michal,

Thank you for taking the time to look into my email, it's very much 
appreciated.
My replies below.


Once again, thank you.

KR,

PF

On 19/08/2026 16:17, Michal Pecio wrote:
> 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?
Neither the kernel nor the controller is new, but the workload is: the 
OnePlus 6T (the trigger device) first appears in my logs on 2026-08-15, 
one day after I first booted 7.1.8-200.fc44 (Fedora). The earlier 
kernels here (7.1.4, 7.1.5) were never exposed to this plug/unplug 
pattern, so I can't call it a regression either way.
>
>> 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.

Thanks, that matches what I see. It happened a third time today, and 
this time the watchdog caught the holder side directly:

   Workqueue: events xhci_handle_command_timeout
   RIP: 0010:delay_halt_mwaitx+0x39/0x40
   Call Trace:
    delay_halt.part.0+0x36/0x60
    xhci_handshake+0x92/0x110
    xhci_abort_cmd_ring.isra.0+0xda/0x1d0
    xhci_handle_command_timeout+0x1b3/0x280
    process_one_work+0x19e/0x390
   xhci_hcd 0000:26:00.0: Abort failed to stop command ring: -110
   xhci_hcd 0000:26:00.0: xHCI host controller not responding, assume dead
   xhci_hcd 0000:26:00.0: HC died; cleaning up

Again exactly 19 seconds after a connect/disconnect cycle on 3-2.2.

>
>> 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
I'll try that on the next occurrence and report back, it reproduces 
every day or two, so it shouldn't take long.

One data point in favour of your firmware-bug theory: on 08-15 the same 
phone was plugged into the other xHCI on this board (AMD X370, 
0000:03:00.0) and produced repeated "Device not responding to setup 
address" + "device not accepting address, error -71" with no further 
harm. The ASMedia is the only controller that wedges on it.
>
>> 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?
You're right, it is. Checking older logs, port 1-12 was already throwing 
those -71 errors on 08-15 with the same phone, days before the first 
ASMedia lockup. So the 03:00.0 trouble is most likely the flaky 
device/cable itself, independent of this bug. Sorry for the noise there.
>
>> I power-cycled the machine at 10:50.
> Probably SSH would work over some PCI NIC.
Yes. Even better: after today's occurrence I confirmed that a PCI remove 
+ rescan of 0000:26:00.0 brings the controller back fully (all devices 
re-enumerate) with no reboot needed, so I have a way to recover and keep 
experimenting without power cycling.

>
> Regards,
> Michal