Re: MUSB interrupt storm on device removal

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

 



On Thu, Jan 24, 2019 at 04:31:19PM +0000, Måns Rullgård wrote:
> Bin Liu <b-liu@xxxxxx> writes:
> 
> > On Thu, Jan 24, 2019 at 12:56:33PM +0000, Måns Rullgård wrote:
> >> Johan Hovold <johan@xxxxxxxxxx> writes:
> >> 
> >> > On Wed, Jan 23, 2019 at 08:50:38PM +0000, Måns Rullgård wrote:
> >> >> Bin Liu <b-liu@xxxxxx> writes:
> >> >> 
> >> >> >> > > 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?
> >> >> 
> >> >> It doesn't seem to happen using ehci or even musb on Allwinner A20.
> >> >> I have only seen the problem with musb on AM3358.
> >> >
> >> > The A20 being dual core may possible explain the difference.
> >> 
> >> Booting the A20 with nosmp it still works correctly.
> >
> > Can you please debug it to see how the hub disconnect event got a chance
> > to be processed?
> 
> Could you be a little more specific?  I'm happy to run some tests, but I
> need to know what information you're looking for.

Never mind.

We have already understood the root cause on Beaglbone - in device
disconnect musb generates interrupt storm which prevents the hub
disconnect event being processed.

The issue doesn't show up on A20, either because musb on A20 doesn't
generates the interrupts fast enough, or 'nosmp' parameter doesn't make
kernel running in non-SMP mode. In either way the issue on Beaglebone has
to be fixed.

error-code.txt says

-ESHUTDOWN              The device or host controller has been disabled due
                        to some problem that could not be worked around,
			such as a physical disconnect.

So instead -EPIPE as in the solution I proposed previously, I am going
to use -ESHUTDOWN when -EPROTO happens consequentially multiple times.

Regards,
-Bin.



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

  Powered by Linux