Skip to contentSkip to conversation

MUSB interrupt storm on device removal

DISCUSSION Bin Liu 1 participant 1 message Jan 23, 2019 USB

lore
Share & tools
lore

Bin Liu

author
#0 lore raw
Quoted 6 lines · Alan Stern
Quoted 4 lines · Bin Liu
Quoted 3 lines

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.

Quoted 8 lines
Quoted 5 lines

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.

(sigh...)

Quoted 12 lines
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines

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.

Quoted 6 lines

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.

the musb driver doesn't use SOF interrupts, so SOF interrupt is disabled. Another way to add delay for -EPROTO would be moving such URBs into a new linked list and using a timer to reschedule the list. The musb driver already has enough mess, I really don't want to add this logic if there is other simpler option...

Quoted 10 lines
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

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.

Is it possible to test the use case on ehci?

- connect a multi-ports usb serial device to a hub;
- open multiple ports with cat command;
- remove the usb serial device from the hub;
- console lockup happens?

Quoted 5 lines
Quoted 3 lines

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.

Regards,
-Bin.