Re: correctly handling EPROTO

[Thinh Nguyen <Thinh.Nguyen@synopsys.com>]

On Fri, Mar 20, 2026, Alan Stern wrote:
> On Thu, Mar 19, 2026 at 11:16:22PM +0000, Thinh Nguyen wrote:
> > On Wed, Mar 18, 2026, Alan Stern wrote:
> > > On Wed, Mar 18, 2026 at 11:59:21PM +0000, Thinh Nguyen wrote:
> > > > I've seen Windows drivers handling UAS transaction error recovery
> > > > through clear-halt and retry SCSI command, and it works well. I hope to
> > > > see this type of recovery implemented for usb storage and uas devices in
> > > > the future.
> > > 
> > > I don't know about uas, but usb-storage handles transaction error 
> > > recovery in approximately the same way.  A clear-halt is issued only if 
> > > the device sent a halt token -- but that's not considered a transaction 
> > 
> > That's -EPIPE right? With this, the storage driver knows that it needs to
> > perform clear-halt because the bulk endpoint is STALL, not -EPROTO.
> 
> Correct.  As for Michal's caveats regarding TTs, they don't really apply 
> to USB mass-storage devices because almost all of them can connect at 
> high speed or even at SuperSpeed.  Besides, even if there was a device 
> behind a TT and the TT messed up recovery from a -EPIPE, usb-storage 
> would simply proceed with a port reset.
> 
> (There may be a few oddball devices out there which can only run at full 
> speed.  For instance, at one time when Linus reported that his wife was 
> having a problem with some low-end mass-storage device she used for 
> knitting or crochet.  It turned out not to be any sort of protocol 
> error; the problem was caused by the userspace utilities that probe each 
> newly added disk looking for partition and LVM information -- this 
> device was extremely slow and had a total storage capacity something 
> like a mere 100 KB (not MB!), and the utilities were trying to read all 
> of it repeatedly, which took a long time.)

Yikes, with that device, -EPROTO probably is the least of the concern.
It better serve in certain tech museum.

> 
> > > error.  Otherwise, for things like -EPROTO, usb-storage does a device 
> > > reset and the SCSI command is retried.  Possibly skipping some initial 
> > 
> > The recovery I'm thinking of doesn't involve a port reset. A port reset
> > is very disruptive and will impact performance greatly. I'm referring to
> > an intermediate recovery step at the usb storage driver without
> > delegating to the SCSI layer.
> 
> I don't know what other sort of intermediate reset could be carried out.  
> The Bulk-Only-Transport protocol _does_ include a class-specific reset 
> request, but usb-storage doesn't use it because experience has shown 
> that practically no USB mass-storage devices implement it properly 
> (which was probably a consequence of the fact that Windows did not use 
> it).
> 
> In fact, the error recovery sequence used by usb-storage is as similar 
> to what Windows does -- or did, since this goes back quite a few years 
> -- as I could make it.

Just to be clear, I'm not suggesting to replace the current recovery
mechanism, but potentially we can introduce more.

> 
> Naturally, UAS may be a totally different situation.

Windows has a clever way to handle this for UAS. It sends a command/task
with the same tag as the failing transfer on the command endpoint,
triggering an overlap tag response and causing the device side to cancel
the command along with the pending data transfer. This puts the host and
device in sync again.

All compliant UAS devices must support overlap tag detection.

(We can go into more detail should we want to pursue this)

> 
> > Currently we _have_ to do a port reset because the bulk sequence can be
> > out of sync and the xhci doesn't synchronize against the device for the
> > storage driver to retry the command directly.
> 
> The same is true for EHCI.
> 
> > What I'd like to see is that the endpoint can be put in a state where
> > the class driver can submit a new URB without unbind/reset/power cycle.
> > With the current implementation of the xhci driver, we cannot do that
> > for bulk endpoints with -EPROTO error.
> 
> Which means unlinking queued URBs (either automatically by the core or 
> else by hand in the class driver), waiting for them to complete, and 
> issuing a clear-halt.  Once that is done, submission of new URBs should 

The clear-halt doesn't have to be done after the unlinking of URBs. The
xhci endpoint is in stopped state after a reset ep command. As
long as the class driver doesn't submit a new URB to trigger a doorbell
ring, the xhci driver can send a clear-halt after a reset ep command and
no transfer will start.

> work, if the cause of the error was transient and has gone away.
> 
> I don't make any distinction here between resubmitting the URB that 
> failed (a retry) or submitting a new, completely different URB.  But 
> Michal is right that under some circumstances, when communicating with a 
> low- or full-speed device (which is common with HID), data may get lost 
> or duplicated.  I don't see anything we can do about that.
> 

Of course, as I mentioned, there needs to be synchronization mechanism
at the class driver or higher layer.

The xhci spec actually suggests to perform clear-halt after a reset for
this type of scenario. Whether there will be any class driver to take
advantage of retrying without port reset is a different matter.

I can see that this kind of recovery can be done, and it seems to be an
improvement. So I just want to put it out there.

BR,
Thinh