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

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

On Fri, 16 Oct 2026 18:11:39 +0800, Henry Tseng wrote:
> Yes. I repeated it on v7.3-rc5 with 2-1.3 deconfigured first, so 2-1.3
> had nothing left to drop on disconnect and no command was issued for
> it. After the USB3 root port reported the disconnect, the configure
> endpoint command for 2-1.4.4 (slot 8) completed, and then the one for
> 2-1.4 (slot 6) got stuck.

So there is something special about those hubs, but we have no idea
what it is and whether any workaround is possible. Using the DC flag
isn't helping either, and basically

> I agree the kernel isn't doing anything wrong here. The idea of patch
> 2 is that when disable slot follows anyway, this configure endpoint
> command doesn't seem to be needed

This may be the only option and I haven't noticed bad side-effects on
any of my HCs when Configure Endpoint is omitted before Disable Slot.

However,

> > Maybe it helps to re-connect the device before abort begins?
> > This worked with Renesas :)
> 
> The timing is a bit tricky to hit, but I gave it a few tries and the
> host was still declared dead every time.

Should be quite easy, you have 5 seconds before the abort begins. But
this result isn't good, it suggests that your patch is prone to a race
condition: if the link disappears for a moment and comes back before
USB core calls xhci_check_bandwidth(), rhub_port->connected may already
be true again, the workaround won't fire and the HC will hang.

We really need something that permanently "sticks" to all disconnected
udevs until they are reset or deleted, like the former VDEV_PORT_ERROR
flag which has been removed in v7.3.

I have already suggested before that the previous solution was better,
but Mathias didn't seem interested in reworking this. But I think this
cannot be avoided in the long term, due to issue like here. Per-device
flags really are the right thing to do.

> The only hub I have at hand is a 5 Gbps one (05e3:0612), so I tested
> with it between the root port and the enclosure. On v7.3-rc5,
> unplugging the enclosure from that hub doesn't hang, and all
> configure endpoint commands complete

What happens if you disconnect the 5gbps hub with its children from
the root hub? If this fails, we obviously have a problem. If not, we
still won't know. If you think your customers are likely to use these
devices behind hubs, you may want to get a 10gbps one and try.

I don't understand this bug so I can't tell what result to expect.

Regards,
Michal