Hi Johan, On Tue, Jan 22, 2019 at 02:16:30PM -0600, Bin Liu wrote: > On Tue, Jan 22, 2019 at 05:19:39PM +0000, Måns Rullgård wrote: > > Bin Liu <b-liu@xxxxxx> writes: > > > > > On Mon, Jan 21, 2019 at 09:20:52PM +0000, Måns Rullgård wrote: > > >> Bin Liu <b-liu@xxxxxx> writes: > > >> > > >> > On Fri, Jan 18, 2019 at 08:15:02PM +0000, Måns Rullgård wrote: > > >> >> Bin Liu <b-liu@xxxxxx> writes: > > >> >> > > >> >> > On Mon, Dec 17, 2018 at 09:36:17PM +0000, Måns Rullgård wrote: > > >> >> >> 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 > > >> > > > >> > Is 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.html > > > > > > Okay, 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? 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; Regards, -Bin.
