Re: [PATCH] usb: xhci: Tear down host on Reset Endpoint and Set TR Dequeue timeout

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

On Wed,  4 Nov 2026 01:27:25 +0000, Ambareesh Balaji wrote:
> When a command times out, xhci_handle_command_timeout() aborts the
> command ring. The aborted command is turned into a No-Op TRB, so its
> completion is handled as a No-Op and the command's own handler never
> runs.
> 
> A timed out Stop Endpoint command already halts the host and tears it
> down. Reset Endpoint and Set TR Dequeue Pointer timeouts are not
> handled, so the endpoint stays halted (EP_HALTED or SET_DEQ_PENDING)
> and its cancelled TDs are never given back. A driver waiting for those
> URBs, such as usb_kill_urb() during unbind, then waits forever.
> 
> Reset Endpoint and Set TR Dequeue Pointer change endpoint state in the
> host controller only and never talk to the device, so a timeout means
> the host controller is not responding, as with Stop Endpoint. Handle
> them the same way: halt the host and give back all URBs with
> xhci_hc_died(). The endpoint state flags are not cleared here, because
> the endpoint handlers and URB dequeue check XHCI_STATE_DYING first.
> 
> The timeout was reproduced on an AMD xHCI controller passed through to a
> QEMU/KVM guest. An endpoint halt was set on a usbhid interrupt IN endpoint
> and the doorbell of the Set TR Dequeue Pointer command queued by the
> usbhid unbind was suppressed with a kprobe, to emulate a host that does
> not answer the command. Without this change the unbind blocks forever in
> usb_kill_urb(). With it the command times out, the host is torn down and
> the unbind completes. Normal unbind and rebind of the same device is
> unaffected.
> 
> Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
> Signed-off-by: Ambareesh Balaji <ambareeshbalaji@gmail.com>

If timeout of those commands is handled as poorly as you say it is
then it looks like nobody is actually running into those cases (or they
would have been reported), so it's not very urgent. But regression risk
is also low then.

I have long wondered if we shouldn't simply halt the HC on every
command timeout other than Address Device. Commands shouldn't be taking
5 seconds to complete. When they do, something unexpected must be going
on and it's unclear if the HC is still usable or capable of recovering
cleanly when we abort the command. (I recall that aborting Stop EP on
one old and dodgy HC leaves the endpoint in a bogus state).

I have been running with a local patch which turns command timeouts
into xhci_halt/xhci_hc_died and so far the only functional difference
I noticed is that the driver takes less time to "kill" hanged HCs.

Note that in practical workloads, there are usually many endpoints and
sooner or later somebody unlinks a URB and causes Stop EP timeout, so
we "kill" the HC anyway. I haven't seen cases when Reset EP or Set TR
Dequeue hang but other commands still work.

I could submit this patch for 7.5. It doesn't seem urgent and probably
doesn't deserve "Fixes" or "Cc:stable".

Regards,
Michal