MUSB interrupt storm on device removal

Quoted 16 lines · Johan Hovold

Quoted 4 lines

At least when -EPROTO errors are caused by device disconnect, we know that they will eventually go away when the upstream hub reports the port disconnect event. But until then, an interrupt storm is certainly possible.

Indeed, and this isn't the first time we've had this discussion either I realised.

In fact, I've been hit by this myself on BBB and musb when disconnecting a device connected through an external hub.

At the time, the immediate causes that were making the completion handler take longer than usual (unaligned copy of a large buffer and a printk respectively) could be fixed. The problem went away, but of course not the underlying issue.

Quoted 7 lines

Note that the problem I was seeing also went away both when switching to a different single-core SoC using ehci-omap, or when replacing the external hub. IIRC it wasn't the hub workqueue that was starved as a I first had thought, but the hub interrupt was never even received (or processed at least).

Unfortunately, I never got around to investigating this further.

I guess now we have some motivation to look into this more closely. :-)

Quoted 20 lines

Quoted 11 lines

Quoted 6 lines

Quoted 3 lines

My point was that unless you fix this at the HCD level, you will need to add complex recovery handling to every USB driver and completion handler (~500 of those). But perhaps that is what it needed.

okay, it probably make sense to handle the case in HCD because the number of HCD is much less.

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 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.

Quoted 7 lines

I tend to agree with you on that, but adding complex back-off handling of intermittent errors to every USB driver and completion handler will be quite a bit of work. Unless the HCD drivers can assist, we'd at least want have some part of the implementation provided by shared code.

Also note that simply starting to bail out on any error now would risk introducing regressions for setups where intermittent errors do occur.

Agreed.

Quoted 2 lines

Quoted 1 line

Why doesn't the same problem occur with other types of host controller?

Quoted 3 lines

I think we should get to the bottom of that. BBB is single core which may be part of the reason why it's affected, but it's definitely related to the controller as well.

Perhaps it has something to do with the timing of the completion interrupts. I don't know anything about how musb works, though. Some low-level timing information would be good to see.