MUSB interrupt storm on device removal
From: Bin Liu <b-liu@ti.com>
Date: 2019-01-22 20:52:44
Subsystem:
the rest, usb serial subsystem, usb subsystem · Maintainers:
Linus Torvalds, Johan Hovold, Greg Kroah-Hartman
Hi Johan, On Tue, Jan 22, 2019 at 02:16:30PM -0600, Bin Liu wrote:
quoted hunk
On Tue, Jan 22, 2019 at 05:19:39PM +0000, Måns Rullgård wrote:quoted
Bin Liu [off-list ref] writes:quoted
On Mon, Jan 21, 2019 at 09:20:52PM +0000, Måns Rullgård wrote:quoted
Bin Liu [off-list ref] writes:quoted
On Fri, Jan 18, 2019 at 08:15:02PM +0000, Måns Rullgård wrote:quoted
Bin Liu [off-list ref] writes:quoted
On Mon, Dec 17, 2018 at 09:36:17PM +0000, Måns Rullgård wrote:quoted
Bin Liu [off-list ref] writes:quoted
On Mon, Dec 17, 2018 at 07:16:08PM +0000, Måns Rullgård wrote:quoted
Bin Liu [off-list ref] writes:quoted
Hi, On Mon, Dec 17, 2018 at 03:13:12PM +0000, Måns Rullgård wrote:quoted
I have a strange problem with the musb driver in host mode on AM3358 (beaglebone) hardware. If I connect a multi-port serial adapter andIs this on beaglebone or beagleboneblack?We've seen it with Beaglebone Enhanced [1] and BeagleCore [2] based devices. Both are based on the AM3358 and mostly compatible with the Beaglebone Black. [1] https://elinux.org/SanCloud_BeagleBoneEnhanced [2] http://beaglecore.com/products/bcm1str.htmlOkay, now I see you have a hub on the board. I just reproduced the console lockup after added a hub in my setup. I will find some time to debug this. FYI, there was a similar issue in a few years ago, which was that the hub routine never got called during the storm then the device disconnect event never got populated from the hub driver. I am wondering if this is the same issue pops up again...Now that you mentioned the hub, I tried connecting the serial adapter to the OTG port (in host mode) on the Beaglebone Enhanced (it's not normally used in this product). When connected directly, the disconnect indeed works properly. With a hub in between, it breaks.Please use the following hack as a workaround for now. I will think more about it. Regards, -Bin. --------8<---------- diff git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index b59ce9ad14ce..3719f6d9b26c 100644--- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c@@ -1811,7 +1811,7 @@ void musb_host_rx(struct musb *musb, u8 epnum) } else if (rx_csr & MUSB_RXCSR_H_ERROR) { musb_dbg(musb, "end %d RX proto error", epnum); - status = -EPROTO; + status = -EPIPE; musb_writeb(epio, MUSB_RXINTERVAL, 0); rx_csr &= ~MUSB_RXCSR_H_ERROR;
When a usb serial device is detached, the musb controller driver returns -EPROTO in urb giveback, then usb_serial_generic_read_bulk_callback() re-submit the urb, this circle causes interrupt storm, and the hub driver workqueue never got a chance to run to populate the device disconnect event, the whole console locks up. Do you think usb_serial_generic_read_bulk_callback() should handle -EPROTO as well? Regards, -Bin.
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 2274d9625f63..8c2a6e55de3a 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c@@ -397,6 +397,7 @@ void usb_serial_generic_read_bulk_callback(struct urb *urb) __func__, status); return; case -EPIPE: + case -EPROTO: dev_err(&port->dev, "%s - urb stopped: %d\n", __func__, status); return;