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.
To add more:
kernel 4.2.0 on AM3703 musb in DMA mode with Quectel U15 modem plugged:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 3, If 1, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 3, If 2, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 3, If 3, Class=Vendor Specific Class, Driver=option, 480M
|__ Port 4: Dev 3, If 4, Class=Vendor Specific Class, Driver=option, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-omap/3p, 480M
musb_ep_program 931: broken !rx_reinit, ep2 csr a203
musb_host_rx 1973: Rx interrupt with no errors or packet!
musb_ep_program 931: broken !rx_reinit, ep5 csr a203
musb_host_rx 1973: Rx interrupt with no errors or packet!
and in both PIO and DMA mode write to device ends this way:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 146 at drivers/usb/musb/musb_host.c:128 musb_h_tx_flush_fifo+0x84/0xb8()
Could not flush host TX2 fifo: csr: 2003
Modules linked in: option usb_wwan usbserial snd_soc_omap_twl4030 cpufreq_dt snd_soc_omap_mcbsp snd_soc_omap snd_soc_twl4030 snd_pcm_dmaengine omap_aes snd_soc_core omap_sham omap_mailbox s
CPU: 0 PID: 146 Comm: ModemManager Not tainted 4.2.0 #3
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[<c0013ad4>] (unwind_backtrace) from [<c0011be8>] (show_stack+0x10/0x14)
[<c0011be8>] (show_stack) from [<c003181c>] (warn_slowpath_common+0x84/0xac)
[<c003181c>] (warn_slowpath_common) from [<c0031870>] (warn_slowpath_fmt+0x2c/0x3c)
[<c0031870>] (warn_slowpath_fmt) from [<c02e6a64>] (musb_h_tx_flush_fifo+0x84/0xb8)
[<c02e6a64>] (musb_h_tx_flush_fifo) from [<c02e7ee0>] (musb_cleanup_urb.isra.13+0xa0/0x12c)
[<c02e7ee0>] (musb_cleanup_urb.isra.13) from [<c02e8060>] (musb_urb_dequeue+0xf4/0x114)
[<c02e8060>] (musb_urb_dequeue) from [<c02cdda0>] (usb_hcd_unlink_urb+0x60/0x7c)
[<c02cdda0>] (usb_hcd_unlink_urb) from [<c02ceb9c>] (usb_kill_urb+0x4c/0xc4)
[<c02ceb9c>] (usb_kill_urb) from [<bf1638d8>] (usb_wwan_close+0x94/0xb0 [usb_wwan])
[<bf1638d8>] (usb_wwan_close [usb_wwan]) from [<c025d0cc>] (tty_port_shutdown+0x7c/0x88)
[<c025d0cc>] (tty_port_shutdown) from [<c025d9a0>] (tty_port_close+0x24/0x58)
[<c025d9a0>] (tty_port_close) from [<c0256494>] (tty_release+0x128/0x40c)
[<c0256494>] (tty_release) from [<c00c9aa0>] (__fput+0xd4/0x1a4)
[<c00c9aa0>] (__fput) from [<c004937c>] (task_work_run+0x9c/0xb0)
[<c004937c>] (task_work_run) from [<c0011688>] (do_work_pending+0xa0/0xb8)
[<c0011688>] (do_work_pending) from [<c000e904>] (work_pending+0xc/0x20)
---[ end trace b14c1d9333664980 ]---
and device (U15) does not work. Also any other device pluged into that hub
after warning is printed does not work any more (udlfb worked before).
Just for completeness, here's a patch used:
--- linux-4.2/drivers/usb/serial/option.c.orig 2015-10-13 02:43:23.363254239 +0200
+++ linux-4.2/drivers/usb/serial/option.c 2015-10-13 02:44:24.663254239 +0200
@@ -1097,6 +1097,7 @@
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
+ { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9090)}, /* QUECTEL UC15 */
{ USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x68c0, 0xff),
.driver_info = (kernel_ulong_t)&sierra_mc73xx_blacklist }, /* MC73xx */
{ USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x9041, 0xff),
> 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 :-(
That probably depends on transfer size...
Best regards,
ladis
--
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
