MUSB interrupt storm on device removal

Quoted 43 lines · Bin Liu

Quoted 42 lines · Måns Rullgård

Quoted 28 lines · Bin Liu

Hi,

Quoted 20 lines · Måns Rullgård

I have a strange problem with the musb driver in host mode on AM3358 (beaglebone) hardware. If I connect a multi-port serial adapter and open two or more of the ttys, then unplug the device, an interrupt storm ensues that makes the system completely unresponsive until the watchdog resets it. Enabling some debug messages, I get this repeated endlessly:

musb-hdrc musb-hdrc.1: usbintr (0) epintr(1c0000)
musb-hdrc musb-hdrc.1: end 2 RX proto error
musb-hdrc musb-hdrc.1: ... next ep2 RX urb 72aabc13
musb-hdrc musb-hdrc.1: <-- hw2 urb 72aabc13 spd3 dev4 ep3in h_addr02 h_port00 bytes 4096 musb-hdrc musb-hdrc.1: RXCSR2 := 2020
musb-hdrc musb-hdrc.1: end 3 RX proto error
musb-hdrc musb-hdrc.1: ... next ep3 RX urb 94c2cc43
musb-hdrc musb-hdrc.1: <-- hw3 urb 94c2cc43 spd3 dev4 ep2in h_addr02 h_port00 bytes 4096 musb-hdrc musb-hdrc.1: RXCSR3 := 2020
musb-hdrc musb-hdrc.1: end 4 RX proto error
musb-hdrc musb-hdrc.1: ... next ep4 RX urb cbdc39c6
musb-hdrc musb-hdrc.1: <-- hw4 urb cbdc39c6 spd3 dev4 ep5in h_addr02 h_port00 bytes 4096 musb-hdrc musb-hdrc.1: RXCSR4 := 2020

Quoted 4 lines

This happens with both a two-port FTDI serial adapter and a Simcom GSM modem (Qualcomm based) using the "option" driver. In both cases, the problem occurs only if two or more of the ttys are opened when the device is unplugged.

Quoted 4 lines

Please help me to understand the test case so that I can try to replicate the issue - if I connect a multi-port FTDI adapter, use cat command to open more than one port then unplug the adapter, I should see the flooding debug messages?

Yes, that's what I'm seeing. Obviously, you have to first enable those debug messages. Otherwise it just stops dead in its tracks.

I forgot to mention, I also tried making the interrupt handler threaded. This allows the system to remain slightly responsive, but it never recovers.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

On which kernel version do you see the problem?

This was on 4.19.9. I don't see any later commits that look related, but I can try some other tree if you suggest one.

This should be fine. The driver was barely touched recently. I have only a few days left for 2018, let me try to reproduce it first after I am back in Jan.

No problem. I suspect most of us will have some time off during the holidays.

If it helps, we first noticed this with a 4.9 (stable) kernel, so it's not a recent regression.