Hi Felipe, On Tue, Sep 8, 2015 at 5:45 PM, Felipe Balbi <balbi@xxxxxx> wrote: > On Mon, Sep 07, 2015 at 12:32:10PM +0200, Yegor Yefremov wrote: >> On Mon, Aug 31, 2015 at 7:41 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> > Hi, >> > >> > On Mon, Aug 31, 2015 at 11:41:59AM -0500, Felipe Balbi wrote: >> >> On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote: >> >> > Hi Felipe, >> >> > >> >> > On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov >> >> > <yegorslists@xxxxxxxxxxxxxx> wrote: >> >> > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov >> >> > > <yegorslists@xxxxxxxxxxxxxx> wrote: >> >> > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> >> > >>> HI, >> >> > >>> >> >> > >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote: >> >> > >>>> I performed a stress test with several FT4232H chips connected to a >> >> > >>> >> >> > >>> how many ? >> >> > >> >> >> > >> # lsusb -t >> >> > >> /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >> >> > >> /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >> >> > >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M >> >> > >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M >> >> > >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M >> >> > >> >> >> > >> 3 chips a 4-ports are attached. >> >> > > >> >> > > Warnings appear on another device (without internal hub) with only one >> >> > > FT4232H too: >> >> > > >> >> > > # lsusb -t >> >> > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M >> >> > > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M >> >> > > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M >> >> > > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M >> >> > > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M >> >> > > >> >> > >>>> hub, that is attached to one of the musb ports. So far the test was >> >> > >>>> successful for several hours. But I've seen following warnings: >> >> > >>>> >> >> > >>>> musb_host_rx 1973: Rx interrupt with no errors or packet! >> >> > >>>> musb_ep_program 931: broken !rx_reinit, ep5 csr 0203 >> >> > >>>> musb_host_rx 1973: Rx interrupt with no errors or packet! >> >> > >>>> musb_host_rx 1973: Rx interrupt with no errors or packet! >> >> > >>>> musb_host_rx 1973: Rx interrupt with no errors or packet! >> >> > >>>> musb_host_rx 1973: Rx interrupt with no errors or packet! >> >> > >>>> musb_ep_program 931: broken !rx_reinit, ep5 csr 0003 >> >> > >>>> musb_host_rx 1973: Rx interrupt with no errors or packet! >> >> > >>>> musb_ep_program 931: broken !rx_reinit, ep7 csr 0003 >> >> > >>>> >> >> > >>>> Is this expected behavior? >> >> > >>> >> >> > >>> no, that shouldn't happen, but it does and, apparently, in more than one >> >> > >>> implementation. Wondering if you're running into endpoint limitation due >> >> > >>> to MUSB's poor transfer scheduling for non-bulk endpoints. >> >> > >>> >> >> > >>> -- >> >> > >>> balbi >> >> > >> >> > Now I have another trouble with msub and FTDI FT4232H chip. If I start >> >> > something like this on all 4 ports at 115200b/s, then pull USB cable >> >> > and the system freezes: >> >> > >> >> > cat /dev/urandom > /dev/ttyUSB0 >> >> > ... >> >> > cat /dev/urandom > /dev/ttyUSB3 >> >> > >> >> > I see these messages: >> >> > >> >> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb >> >> > status: -110 >> >> > >> >> > After them system reboots as my watchdog time expires. >> >> > >> >> > Kernel 4.2.0-rc5 >> >> > >> >> > Older FTDI chips like FT2232 have no problems. Somehow is musb really >> >> > allergic to FTDI and vice versa :-( >> >> >> >> those are just messages of URB time out. They should be expected. No >> >> idea why you're getting a reboot though. I'll see if I can reproduce. >> > >> > okay, reproduced. Seems to be a race somewhere. some printks() made it >> > go away :-) >> > >> > I'll have a look. >> >> Thanks for testing. I can imagine, that sorting these things out would >> fix my 3G modem removal issue. > > cool :-) I'll let you know once I have something. Where have you placed these printks? I need at least a workaround for some hardware tests. Yegor -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
