Re: MUSB interrupt storm on device removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 23 Jan 2019, Bin Liu wrote:

> > One possibility is to giveback URBs with certain errors (such as
> > -EPROTO) only at a frame boundary, or at 1-ms intervals.  This feels 
> > like a very artificial solution, though.
> 
> My plan is to add an error counter in musb driver endpoint struct, if
> -EPROTO has happened consequentially for a certain times, for example 3,
> giveback URBs with -EPIPE instead -EPROTO. This is the simplest solution
> I can think of, though I hate expending struct unnecessarily, this is
> one of the cases.

But -EPIPE is documented to mean that the device replied with a STALL.  
You would be violating the documentation.

> > > > I do see now that of all USB drivers we have two drivers that handles
> > > > -EPROTO by resubmitting after a delay, while a handful explicitly deals
> > > > with -EPROTO by simply stopping to resubmit (some probably bail out on
> > > > all errors, but the majority appear to resubmit on -EPROTO).
> > 
> > Any driver which immediately retries an URB after getting -EPROTO or
> > -EILSEQ or -ETIME, and has no mechanism for backing off or limiting the
> > retries, is buggy.  As far as I can see, that's all there is to it.
> 
> Agreed, but given that majority appear to resubmit on -EPROTO as Johan
> said, I think better to handle it in HCD.

Do all those other drivers handle -EPIPE correctly?  A logical way to 
respond to -EPIPE is to issue a Clear-Halt request; what will happen 
when that also fails?

I think it makes more sense to continue using -EPROTO but slow down the 
exchange of packets so that there is no interrupt storm.

> > > Thanks for the info.
> > > I will handle this case in musb driver.
> > 
> > Why doesn't the same problem occur with other types of host controller?
> 
> Not sure, I am on musb for most of the times. Maybe other HCD doesn't
> giveback URBs with -EPROTO in such error case.

ehci-hcd also uses -EPROTO.

> musb controller has a register bit telling the controller has tried the
> transaction 3 times but didn't receive any response, then the musb
> driver just giveback this URB with -EPROTO.

Same with EHCI.

Alan Stern




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux