Re: xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.

[Alan Stern]

On Sun, Apr 06, 2025 at 12:23:11AM +0200, Michał Pecio wrote:
> Looks like some URB stalled and usb_storage reset the device without
> usb_clear_halt(). Then the core didn't usb_hcd_reset_endpoint() either.
> And apparently EP_STALLED is still set in xhci_hcd after all that time.
> 
> Then usb_storage submits one URB which never executes because the EP
> is in Running-Idle state and the doorbell is inhibited by EP_STALLED.
> 30s later it times out, unlinks the URB and resets again. Set TR Deq
> fails because the endpoint is Running.

> Not sure if it's a USB core bug or something that xHCI should take
> care of on its own. For now, reverting those two "stall" patches ought
> to clean up the noise.

The core believes that resetting a device should erase the endpoint 
information in the HCD.  There is a callback in hub_port_reset() to that 
effect:

		if (hcd->driver->reset_device)
			hcd->driver->reset_device(hcd, udev);

So after this the EP should not be in the Running-Idle state; in fact it 
should not exist at all (unless it is ep0, but in this case I think it 
isn't).

Is the implementation of the reset_device callback in xhci-hcd missing 
something?

Alan Stern