Re: [PATCH 0/2] xhci: handshake timeout overrun and configure endpoint hang on device disconnect

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

On Fri, 30 Oct 2026 18:15:17 +0800, Henry Tseng wrote:
> I got a 10 Gbps hub (05e3:0625) and tried it on v7.3-rc5. Unplugging
> the enclosure from the hub still doesn't hang, but disconnecting the
> hub together with the enclosure from the root port does. The stuck
> command is again the one dropping ep 0x83 of a 1c04:0018 hub inside
> the enclosure, 2-1.2.3 (slot 6) here.
> 
>   [   59.162027] usb 2-1.2.3: new SuperSpeed Plus Gen 2x1 USB device number 4 using xhci_hcd
>   [   59.174788] usb 2-1.2.3: New USB device found, idVendor=1c04, idProduct=0018, bcdDevice=94.01
>   ...
>   [   99.662478] xhci_hcd 0000:0c:00.3: Port change event, 2-1, id 5, portsc: 0x202a0
>   [   99.662702] usb 2-1: USB disconnect, device number 2
>   [   99.662721] usb 2-1.2.3: USB disconnect, device number 4
>   [   99.662937] xhci_hcd 0000:0c:00.3: Cancel URB 000000002114d18f, dev 1.2.3, ep 0x83, starting at offset 0xfe68d000
>   [   99.675129] xhci_hcd 0000:0c:00.3: drop ep 0x83, slot id 6, new drop flags = 0x80, new add flags = 0x0
>   [  105.027976] xhci_hcd 0000:0c:00.3: Command timeout, USBSTS: 0x00000010 PCD
> 
> So the hang seems tied to the root port going away rather than to
> where the enclosure sits. The NOTATTACHED check handles this case
> as well, since usb_disconnect() marks the whole subtree.

Great, we can confidently deal with this bug internally in xhci-hcd,
without worrying about external hubs that we have no visibility into.

As for actually fixing this, we are now in panic mode because the 7.3
changes in the logic for avoiding HW bugs on disconnection have caused
regressions. We may need to wait till the dust settles there.

Using udev->state instead of xhci-hcd infrastructure might work too
while avoiding the aforementioned drama, but I'm not familiar enough
with USB core to tell off the top of my head if it's 100% reliable.

Regards,
Michal