On Mon, Dec 17, 2018 at 07:16:08PM +0000, Måns Rullgård wrote: > Bin Liu <b-liu@xxxxxx> writes: > > > Hi, > > > > On Mon, Dec 17, 2018 at 03:13:12PM +0000, Måns Rullgård wrote: > >> 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 > >> > >> 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. > > > > 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. > > > 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. Regards, -Bin.
