All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bin Liu <b-liu@ti.com>
To: "Måns Rullgård" <mans@mansr.com>
Cc: Johan Hovold <johan@kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>, Greg KH <greg@kroah.com>,
	linux-usb@vger.kernel.org
Subject: MUSB interrupt storm on device removal
Date: Fri, 25 Jan 2019 09:43:15 -0600	[thread overview]
Message-ID: <20190125154315.GH18982@uda0271908> (raw)

On Thu, Jan 24, 2019 at 04:31:19PM +0000, Måns Rullgård wrote:
> Bin Liu <b-liu@ti.com> writes:
> 
> > On Thu, Jan 24, 2019 at 12:56:33PM +0000, Måns Rullgård wrote:
> >> Johan Hovold <johan@kernel.org> writes:
> >> 
> >> > On Wed, Jan 23, 2019 at 08:50:38PM +0000, Måns Rullgård wrote:
> >> >> Bin Liu <b-liu@ti.com> 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.

             reply	other threads:[~2019-01-25 15:43 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-25 15:43 Bin Liu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-03-07 16:16 MUSB interrupt storm on device removal Bin Liu
2019-03-05 11:30 Måns Rullgård
2019-01-24 16:31 Måns Rullgård
2019-01-24 15:54 Bin Liu
2019-01-24 15:49 Alan Stern
2019-01-24 15:43 Bin Liu
2019-01-24 15:40 Bin Liu
2019-01-24 15:22 Alan Stern
2019-01-24 12:56 Måns Rullgård
2019-01-24  9:25 Johan Hovold
2019-01-24  9:22 Johan Hovold
2019-01-24  8:11 Greg Kroah-Hartman
2019-01-23 20:50 Måns Rullgård
2019-01-23 20:44 Alan Stern
2019-01-23 20:12 Bin Liu
2019-01-23 17:42 Alan Stern
2019-01-23 16:53 Bin Liu
2019-01-23 16:05 Alan Stern
2019-01-23 15:21 Bin Liu
2019-01-23 14:55 Johan Hovold
2019-01-23 14:09 Bin Liu
2019-01-23  8:55 Johan Hovold
2019-01-23  6:52 Greg KH
2019-01-22 20:52 Bin Liu
2019-01-22 20:16 Bin Liu
2019-01-22 17:19 Måns Rullgård
2019-01-22 14:57 Bin Liu
2019-01-21 21:20 Måns Rullgård
2019-01-21 16:31 Bin Liu
2019-01-18 20:15 Måns Rullgård
2019-01-10  3:07 Bin Liu
2019-01-09 13:19 Måns Rullgård
2018-12-17 21:36 Måns Rullgård
2018-12-17 20:56 Bin Liu
2018-12-17 19:16 Måns Rullgård
2018-12-17 18:44 Bin Liu
2018-12-17 15:13 Måns Rullgård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190125154315.GH18982@uda0271908 \
    --to=b-liu@ti.com \
    --cc=greg@kroah.com \
    --cc=johan@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.