Re: MUSB interrupt storm on device removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bin Liu <b-liu@xxxxxx> writes:

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

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.

-- 
Måns Rullgård



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux