Re: Linux 4.2.0-rc5: am335x: musb warnings
Hi, Yegor Yefremov writes: > Hi Felipe, hi Ladislav, > > On Wed, Oct 14, 2015 at 1:47 AM, Ladislav Michl 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 >>> wrote: >>> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov >>> > wrote: >>> >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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) >> [] (unwind_backtrace) from [] (show_stack+0x10/0x14) >> [] (show_stack) from [] (warn_slowpath_common+0x84/0xac) >> [] (warn_slowpath_common) from [] >> (warn_slowpath_fmt+0x2c/0x3c) >> [] (warn_slowpath_fmt) from [] >>
Re: Linux 4.2.0-rc5: am335x: musb warnings
Hi Felipe, hi Ladislav, On Wed, Oct 14, 2015 at 1:47 AM, Ladislav Michl 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 >> wrote: >> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov >> > wrote: >> >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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) > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (warn_slowpath_common+0x84/0xac) > [] (warn_slowpath_common) from [] > (warn_slowpath_fmt+0x2c/0x3c) > [] (warn_slowpath_fmt) from [] > (musb_h_tx_flush_fifo+0x84/0xb8) > [] (musb_h_tx_flush_fifo) from [] > (musb_cleanup_urb.isra.13+0xa0/0x12c) > [] (musb_cleanup_urb.
Re: Linux 4.2.0-rc5: am335x: musb warnings
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 > wrote: > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov > > wrote: > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (warn_slowpath_common+0x84/0xac) [] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x2c/0x3c) [] (warn_slowpath_fmt) from [] (musb_h_tx_flush_fifo+0x84/0xb8) [] (musb_h_tx_flush_fifo) from [] (musb_cleanup_urb.isra.13+0xa0/0x12c) [] (musb_cleanup_urb.isra.13) from [] (musb_urb_dequeue+0xf4/0x114) [] (musb_urb_dequeue) from [] (usb_hcd_unlink_urb+0x60/0x7c) [] (usb_hcd_unlink_urb) from [] (usb_kill_urb+0x4c/0xc4) [] (usb_kill_urb) from [] (usb_wwan_close+0x94/0xb0
Re: Linux 4.2.0-rc5: am335x: musb warnings
Hi Felipe, On Tue, Sep 8, 2015 at 5:45 PM, Felipe Balbi 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 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 >> >> > wrote: >> >> > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov >> >> > > wrote: >> >> > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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. >> >>
Re: Linux 4.2.0-rc5: am335x: musb warnings
On Mon, Sep 07, 2015 at 12:32:10PM +0200, Yegor Yefremov wrote: > On Mon, Aug 31, 2015 at 7:41 PM, Felipe Balbi 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 > >> > wrote: > >> > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov > >> > > wrote: > >> > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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 a
Re: Linux 4.2.0-rc5: am335x: musb warnings
On Mon, Aug 31, 2015 at 7:41 PM, Felipe Balbi 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 >> > wrote: >> > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov >> > > wrote: >> > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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,
Re: Linux 4.2.0-rc5: am335x: musb warnings
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 > > wrote: > > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov > > > wrote: > > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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. -- balbi signature.asc Description: Digital signature
Re: Linux 4.2.0-rc5: am335x: musb warnings
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 > wrote: > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov > > wrote: > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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. -- balbi signature.asc Description: Digital signature
Re: Linux 4.2.0-rc5: am335x: musb warnings
Hi Felipe, On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov wrote: > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov > wrote: >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.2.0-rc5: am335x: musb warnings
On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov wrote: > On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.2.0-rc5: am335x: musb warnings
On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 4.2.0-rc5: am335x: musb warnings
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 ? > 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 signature.asc Description: Digital signature
