From patchwork Tue Oct 13 23:47:12 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ladislav Michl X-Patchwork-Id: 7389591 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 254179F302 for ; Tue, 13 Oct 2015 23:47:22 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D15E4207F1 for ; Tue, 13 Oct 2015 23:47:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8D0FD20719 for ; Tue, 13 Oct 2015 23:47:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751881AbbJMXrR (ORCPT ); Tue, 13 Oct 2015 19:47:17 -0400 Received: from eddie.linux-mips.org ([148.251.95.138]:57492 "EHLO cvs.linux-mips.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751851AbbJMXrQ (ORCPT ); Tue, 13 Oct 2015 19:47:16 -0400 Received: (from localhost user: 'ladis' uid#1021 fake: STDIN (ladis@eddie.linux-mips.org)) by eddie.linux-mips.org id S27009448AbbJMXrOEjIJm (ORCPT ); Wed, 14 Oct 2015 01:47:14 +0200 Date: Wed, 14 Oct 2015 01:47:12 +0200 From: Ladislav Michl To: Yegor Yefremov Cc: Felipe Balbi , "linux-omap@vger.kernel.org" Subject: Re: Linux 4.2.0-rc5: am335x: musb warnings Message-ID: <20151013234712.GA23406@localhost.localdomain> References: <20150806142135.GB19110@saruman.tx.rr.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 [usb_wwan]) [] (usb_wwan_close [usb_wwan]) from [] (tty_port_shutdown+0x7c/0x88) [] (tty_port_shutdown) from [] (tty_port_close+0x24/0x58) [] (tty_port_close) from [] (tty_release+0x128/0x40c) [] (tty_release) from [] (__fput+0xd4/0x1a4) [] (__fput) from [] (task_work_run+0x9c/0xb0) [] (task_work_run) from [] (do_work_pending+0xa0/0xb8) [] (do_work_pending) from [] (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: > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- 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),