MUSB interrupt storm on device removal

From: Alan Stern <stern@rowland.harvard.edu>
To: Bin Liu <b-liu@ti.com>
Cc: "Johan Hovold" <johan@kernel.org>, "Greg KH" <greg@kroah.com>,
	"Måns Rullgård" <mans@mansr.com>,
	linux-usb@vger.kernel.org
Subject: MUSB interrupt storm on device removal
Date: Wed, 23 Jan 2019 12:42:36 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1901231236550.1564-100000@iolanthe.rowland.org> (raw)

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