Re: [ISSUE REPORT] xHCI infinite endpoint reset loop on full-speed after transfer error

["Michał Pecio" <michal.pecio@gmail.com>]

On Mon, 12 May 2025 10:19:13 +0200, Michał Pecio wrote:
> On Mon, 12 May 2025 14:39:13 +0800, Guan Wang wrote:
> > Using Linux version 6.15.0-rc5-00032, I encountered an issue where
> > the xHCI controller enters an infinite loop while attempting to
> > recover a USB endpoint. This causes the xHCI driver to get stuck,
> > and no USB transfers can proceed.
> > 
> > This issue appears to only occur with full-speed bulk devices such
> > as USB serial adapters(e.g., USB-Serial or CDC-ACM class). I've
> > reproduced it using CH340 and CP2102 USB serial devices.
> > 
> > **Steps to reproduce:**
> > 1. Attach the device.
> > 2. Start continuous data transfer (e.g., `cat /dev/ttyUSB0`).
> > 3. Induce transfer errors via:
> >    - EMI interference
> >    - Sudden temperature changes
> >    - Long USB cables
> >    - Briefly shorting DP/DM lines to simulate a transaction error
> > 
> > After this, the xHCI controller enters an infinite reset loop on the
> > affected endpoint. "Transfer error" messages continuously appear in
> > the logs, creating a log storm. The issue seems to improve or
> > disappear when an external high-speed USB hub is inserted between
> > the host and device.  
> 
> Greg may be asking the right question.
> 
> I tried this on 3ce9925823c7, which is linus/master from a few days
> ago, with uPD720202 and PL2303HX or CH341A in TX-RX loopback. I
> temporarily disconnect D- to get transaction errors without detaching
> the device.
> 
> All characters sent during disconnection are lost, and sometimes one
> or two after reconnection too (bug?), but things are back to normal
> then.

This has all the signs of toggle mismatch: the OUT transfer succeeds,
but no corresponding IN transfer occurs, even though URBs are clearly
pending because the next character sent does generate an IN transfer
without new IN URB submission in between.

I wonder if your issue may simply be a matter of overly pedantic host
controller refusing to accept DATA1 PID right after Reset Endpoint, on
the grounds that it must be a software bug (which it is).

> OTOH, it stops working if I insert a high-speed hub upstream of the D-
> switch (tried with two hubs). But still no transaction error storm.

This appears to be usb-serial not resubmitting URBs failed with -EPIPE.
Simply reopening the port restores operation.