Re: correctly handling EPROTO

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

On Fri, Mar 13, 2026, Alan Stern wrote:
> On Fri, Mar 13, 2026 at 11:33:48AM +0100, Oliver Neukum wrote:
> > On 13.03.26 08:53, Michal Pecio wrote:
> > 
> > There are also these pesky software systems where a perpetual immediate
> > retry causes a livelock.
> 
> Yes, we need to avoid this.
> 

This can be handled by the class driver (e.g. fall back to port reset
after 3 retry failures in a row).

> > We have to ask ourselves to which extent we want to deal with failing
> > hardware. I would prefer to deal with true hardware failure separately,
> > but if you think that we need to include the possibility on a driver level,
> > please say so.
> 
> I tend to group transaction-level errors like EPROTO into three 
> categories:
> 
> 	1. Device has been unplugged, hub will notify us soon;
> 
> 	2. Unrecoverable device problem, needs reset or power cycle;
> 
> 	3. Short term problem (cable issue, EMI, system load).
> 
> Retrying makes sense for 3 but not for 1 or 2.  Unfortunately we can't 
> tell which category a particular fault lies in.

There's no need to distinquish them if we have a proper fallback
recovery (such as reset/power cycle) should retry failed as noted above. 

>

<snip>

> 
> > [..]
> > > Summary:
> > > 
> > > Retrying may or may not be productive - see 1.
> > 
> > Does it hurt? Furthermore is it likelier to succeed if we clear
> > a halt before we do so?
> > 
> > > In certain cases retries are impossible anyway - see 2b and 4b.
> > > Extra work by class specific means is inevitable. See "USB philosophy".
> > 
> > We are handling errors. That is, conditions that should not happen
> > in the first place. Perfection will not serve us. Can we come to
> > something reasonable that will mostly work and not preclude going
> > to more drastic methods if it fails?
> 
> And also bearing in mind that retrying will help only for problems of 
> type 3 above.  (Also bearing in mind that the most drastic methods 
> involve manual intervention; they can't be done in software.)
> 

Just want to give my 2-cent here: I experimented and have seen Windows
drivers do retry for MSC (particularly for UASP devices), and it works
well.

The retry is not specifically at the failed URB. It's a retry of the
UASP command where the data block offset is specified, and the entire
transfer is resent.

This will probably not work for application with isoc endpoints where
timing is critical or application without certain synchronization
protocol in its transfer header.

BR,
Thinh