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