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 :-( Regards, 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
