| Message ID | CAGm1_kuxCK16351uf0SiKz750hbc0955hz3k=y_tF0sHx76fXQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: > On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: > > Hi Yegor, > > > > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: > >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: > >> > > >> > Hi Yegor, > >> > > >> >> Hi Bin, > >> >> > >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> >> > Any chance it will actually happen? MUSB is still unusable for me and > >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have > >> >> > tried)... > >> >> > >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. > >> >> Just activating SImCOM SIM7100E produces following error: > >> >> > >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc > >> >> usbcore: registered new interface driver option > >> >> usbserial: USB Serial support registered for GSM modem (1-port) > >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected > >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 > >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected > >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 > >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected > >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 > >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected > >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 > >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected > >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 > >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device > >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at > >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 > >> >> usbcore: registered new interface driver qmi_wwan > >> >> ------------[ cut here ]------------ > >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 > >> >> musb_h_tx_flush_fifo+0xc4/0xe4() > >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial > >> >> musb_dsps musb_am335x > >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 > >> >> Hardware name: Generic AM33XX (Flattened Device Tree) > >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) > >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) > >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) > >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] > >> >> (warn_slowpath_fmt+0x30/0x40) > >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] > >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) > >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] > >> >> (musb_cleanup_urb+0xbc/0x130) > >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) > >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) > >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) > >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] > >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] > >> >> (tty_port_shutdown+0x90/0x9c) > >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) > >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) > >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) > >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) > >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) > >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > >> >> ---[ end trace fb2fc0420e2c4594 ]--- > >> >> > >> >> Could you please take a look at this? > >> >> > >> >> Yegor > >> > > >> > I cannot reproduce it anymore, as commits > >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 > >> > bba40e6948b94cba71965285fbac31bd078c024a > >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part > >> > of 4.5.0-rc6 ... > >> > >> You are lucky! I've tried 4.5.0 and I still have this issue, though > >> I'm on am335x and not on DM3730: > > > > How do you trigger the issue? Plug the modem then unplug it? > > Can you please try the way in [1] to increase the loops to see if the > > fifo could be flushed in a longer time? > > > > Regards, > > -Bin. > > > > [1] http://www.spinics.net/lists/linux-usb/msg137242.html > > Do you mean something like this? > > diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > index 58487a4..f6d6822 100644 > --- a/drivers/usb/musb/musb_host.c > +++ b/drivers/usb/musb/musb_host.c > @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) > struct musb *musb = ep->musb; > void __iomem *epio = ep->regs; > u16 csr; > - int retries = 1000; > + int retries = 10000; Yes. > > csr = musb_readw(epio, MUSB_TXCSR); > while (csr & MUSB_TXCSR_FIFONOTEMPTY) { > > No, it doesn't help. I'm triggering this issue via enabling it, i.e. > our hardware can power on/off mPCIe slot via GPIO pin. When the system > starts mPCI slot is disabled. The I enable it after booting into user > space and the produces the error. It also happens if I insert USB Ok. I can imagine the device is no longer functional due to the fifo flush issue. > modem as a dongle, where usb_modeswitch first has to switch it from > CD-ROM mode into modem mode. Any detail of the usb modem dongle? I will try to find one to take a look. I have a few usb modems but none of them triggers this problem. Regards, -Bin. -- 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
On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: > Hi, > > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: >> > Hi Yegor, >> > >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: >> >> > >> >> > Hi Yegor, >> >> > >> >> >> Hi Bin, >> >> >> >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have >> >> >> > tried)... >> >> >> >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. >> >> >> Just activating SImCOM SIM7100E produces following error: >> >> >> >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc >> >> >> usbcore: registered new interface driver option >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 >> >> >> usbcore: registered new interface driver qmi_wwan >> >> >> ------------[ cut here ]------------ >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial >> >> >> musb_dsps musb_am335x >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] >> >> >> (warn_slowpath_fmt+0x30/0x40) >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] >> >> >> (musb_cleanup_urb+0xbc/0x130) >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] >> >> >> (tty_port_shutdown+0x90/0x9c) >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- >> >> >> >> >> >> Could you please take a look at this? >> >> >> >> >> >> Yegor >> >> > >> >> > I cannot reproduce it anymore, as commits >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 >> >> > bba40e6948b94cba71965285fbac31bd078c024a >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part >> >> > of 4.5.0-rc6 ... >> >> >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though >> >> I'm on am335x and not on DM3730: >> > >> > How do you trigger the issue? Plug the modem then unplug it? >> > Can you please try the way in [1] to increase the loops to see if the >> > fifo could be flushed in a longer time? >> > >> > Regards, >> > -Bin. >> > >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html >> >> Do you mean something like this? >> >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c >> index 58487a4..f6d6822 100644 >> --- a/drivers/usb/musb/musb_host.c >> +++ b/drivers/usb/musb/musb_host.c >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) >> struct musb *musb = ep->musb; >> void __iomem *epio = ep->regs; >> u16 csr; >> - int retries = 1000; >> + int retries = 10000; > > Yes. > >> >> csr = musb_readw(epio, MUSB_TXCSR); >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { >> >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. >> our hardware can power on/off mPCIe slot via GPIO pin. When the system >> starts mPCI slot is disabled. The I enable it after booting into user >> space and the produces the error. It also happens if I insert USB > > Ok. I can imagine the device is no longer functional due to the fifo > flush issue. I've inserted the mPCIe modem into the system, where mPCIe is alsways on and the issue is still there. Some modems like Huawei MU609 are working, but when using with the latest usb_modeswitch and compiling all those drivers as modules (option, qmi_wwan etc.) I can also provoke the FIFO flush issue. >> modem as a dongle, where usb_modeswitch first has to switch it from >> CD-ROM mode into modem mode. > > Any detail of the usb modem dongle? I will try to find one to take a > look. I have a few usb modems but none of them triggers this problem. TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) When connected to the host I get following infos: Bus 001 Device 004: ID 2357:9000 user@debian9:~$ mmcli -m 0 /org/freedesktop/ModemManager1/Modem/0 (device id 'bce4a4be2de9ef14e5f9faebf495b6a3c3278972') ------------------------- Hardware | manufacturer: 'QUALCOMM INCORPORATED' | model: '8' | revision: '8200C-FACPASZQ-30350 1 [Dec 15 2011 15:00:00]' | supported: 'gsm-umts' | current: 'gsm-umts' | equipment id: '863745011099716' ------------------------- System | device: '/sys/devices/pci0000:00/0000:00:06.0/usb1/1-2' | drivers: 'qmi_wwan, option1' | plugin: 'Generic' | primary port: 'cdc-wdm0' | ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), cdc-wdm0 (qmi), wwan0 (net)' ------------------------- Numbers | own : 'unknown' ------------------------- Status | lock: 'unknown' | unlock retries: 'unknown' | state: 'failed' | failed reason: 'sim-missing' | power state: 'unknown' | access tech: 'unknown' | signal quality: '0' (cached) ------------------------- Modes | supported: 'allowed: 2g; preferred: none | allowed: 3g; preferred: none | allowed: 2g, 3g; preferred: none | allowed: 2g, 3g; preferred: 2g | allowed: 2g, 3g; preferred: 3g' | current: 'allowed: any; preferred: none' ------------------------- Bands | supported: 'unknown' | current: 'unknown' ------------------------- IP | supported: 'ipv4, ipv6, ipv4v6' ------------------------- SIM | path: 'none' ------------------------- Bearers | paths: 'none' Yegor -- 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
On Mon, Mar 14, 2016 at 3:54 PM, Yegor Yefremov <yegorslists@googlemail.com> wrote: > On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: >> Hi, >> >> On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: >>> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: >>> > Hi Yegor, >>> > >>> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: >>> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: >>> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: >>> >> > >>> >> > Hi Yegor, >>> >> > >>> >> >> Hi Bin, >>> >> >> >>> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: >>> >> >> > Any chance it will actually happen? MUSB is still unusable for me and >>> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have >>> >> >> > tried)... >>> >> >> >>> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. >>> >> >> Just activating SImCOM SIM7100E produces following error: >>> >> >> >>> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc >>> >> >> usbcore: registered new interface driver option >>> >> >> usbserial: USB Serial support registered for GSM modem (1-port) >>> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected >>> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 >>> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected >>> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 >>> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected >>> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 >>> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected >>> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 >>> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected >>> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 >>> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device >>> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at >>> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 >>> >> >> usbcore: registered new interface driver qmi_wwan >>> >> >> ------------[ cut here ]------------ >>> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 >>> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() >>> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >>> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial >>> >> >> musb_dsps musb_am335x >>> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 >>> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) >>> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) >>> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) >>> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) >>> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] >>> >> >> (warn_slowpath_fmt+0x30/0x40) >>> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] >>> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) >>> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] >>> >> >> (musb_cleanup_urb+0xbc/0x130) >>> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) >>> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) >>> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) >>> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] >>> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >>> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] >>> >> >> (tty_port_shutdown+0x90/0x9c) >>> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) >>> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) >>> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) >>> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) >>> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) >>> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >>> >> >> ---[ end trace fb2fc0420e2c4594 ]--- >>> >> >> >>> >> >> Could you please take a look at this? >>> >> >> >>> >> >> Yegor >>> >> > >>> >> > I cannot reproduce it anymore, as commits >>> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 >>> >> > bba40e6948b94cba71965285fbac31bd078c024a >>> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part >>> >> > of 4.5.0-rc6 ... >>> >> >>> >> You are lucky! I've tried 4.5.0 and I still have this issue, though >>> >> I'm on am335x and not on DM3730: >>> > >>> > How do you trigger the issue? Plug the modem then unplug it? >>> > Can you please try the way in [1] to increase the loops to see if the >>> > fifo could be flushed in a longer time? >>> > >>> > Regards, >>> > -Bin. >>> > >>> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html >>> >>> Do you mean something like this? >>> >>> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c >>> index 58487a4..f6d6822 100644 >>> --- a/drivers/usb/musb/musb_host.c >>> +++ b/drivers/usb/musb/musb_host.c >>> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) >>> struct musb *musb = ep->musb; >>> void __iomem *epio = ep->regs; >>> u16 csr; >>> - int retries = 1000; >>> + int retries = 10000; >> >> Yes. >> >>> >>> csr = musb_readw(epio, MUSB_TXCSR); >>> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { >>> >>> No, it doesn't help. I'm triggering this issue via enabling it, i.e. >>> our hardware can power on/off mPCIe slot via GPIO pin. When the system >>> starts mPCI slot is disabled. The I enable it after booting into user >>> space and the produces the error. It also happens if I insert USB >> >> Ok. I can imagine the device is no longer functional due to the fifo >> flush issue. > > I've inserted the mPCIe modem into the system, where mPCIe is alsways > on and the issue is still there. Some modems like Huawei MU609 are > working, but when using with the latest usb_modeswitch and compiling > all those drivers as modules (option, qmi_wwan etc.) I can also > provoke the FIFO flush issue. > >>> modem as a dongle, where usb_modeswitch first has to switch it from >>> CD-ROM mode into modem mode. >> >> Any detail of the usb modem dongle? I will try to find one to take a >> look. I have a few usb modems but none of them triggers this problem. > > TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) > > When connected to the host I get following infos: > > Bus 001 Device 004: ID 2357:9000 > > user@debian9:~$ mmcli -m 0 > > /org/freedesktop/ModemManager1/Modem/0 (device id > 'bce4a4be2de9ef14e5f9faebf495b6a3c3278972') > ------------------------- > Hardware | manufacturer: 'QUALCOMM INCORPORATED' > | model: '8' > | revision: '8200C-FACPASZQ-30350 1 [Dec 15 2011 15:00:00]' > | supported: 'gsm-umts' > | current: 'gsm-umts' > | equipment id: '863745011099716' > ------------------------- > System | device: '/sys/devices/pci0000:00/0000:00:06.0/usb1/1-2' > | drivers: 'qmi_wwan, option1' > | plugin: 'Generic' > | primary port: 'cdc-wdm0' > | ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), cdc-wdm0 > (qmi), wwan0 (net)' > ------------------------- > Numbers | own : 'unknown' > ------------------------- > Status | lock: 'unknown' > | unlock retries: 'unknown' > | state: 'failed' > | failed reason: 'sim-missing' > | power state: 'unknown' > | access tech: 'unknown' > | signal quality: '0' (cached) > ------------------------- > Modes | supported: 'allowed: 2g; preferred: none > | allowed: 3g; preferred: none > | allowed: 2g, 3g; preferred: none > | allowed: 2g, 3g; preferred: 2g > | allowed: 2g, 3g; preferred: 3g' > | current: 'allowed: any; preferred: none' > ------------------------- > Bands | supported: 'unknown' > | current: 'unknown' > ------------------------- > IP | supported: 'ipv4, ipv6, ipv4v6' > ------------------------- > SIM | path: 'none' > > ------------------------- > Bearers | paths: 'none' Have also tried to connect the mPCIe modem via this adapter (https://techship.se/products/pci-express-mini-card-to-usb-adapter/). Still the same behavior. -- 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
Hi, On Mon, Mar 14, 2016 at 03:54:36PM +0100, Yegor Yefremov wrote: > On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: > > Hi, > > > > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: > >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: > >> > Hi Yegor, > >> > > >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: > >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: > >> >> > > >> >> > Hi Yegor, > >> >> > > >> >> >> Hi Bin, > >> >> >> > >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and > >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have > >> >> >> > tried)... > >> >> >> > >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. > >> >> >> Just activating SImCOM SIM7100E produces following error: > >> >> >> > >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc > >> >> >> usbcore: registered new interface driver option > >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) > >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 > >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 > >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 > >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 > >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 > >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device > >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at > >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 > >> >> >> usbcore: registered new interface driver qmi_wwan > >> >> >> ------------[ cut here ]------------ > >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 > >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() > >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial > >> >> >> musb_dsps musb_am335x > >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 > >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) > >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) > >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) > >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) > >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] > >> >> >> (warn_slowpath_fmt+0x30/0x40) > >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] > >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) > >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] > >> >> >> (musb_cleanup_urb+0xbc/0x130) > >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) > >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) > >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) > >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] > >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] > >> >> >> (tty_port_shutdown+0x90/0x9c) > >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) > >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) > >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) > >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) > >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) > >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- > >> >> >> > >> >> >> Could you please take a look at this? > >> >> >> > >> >> >> Yegor > >> >> > > >> >> > I cannot reproduce it anymore, as commits > >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 > >> >> > bba40e6948b94cba71965285fbac31bd078c024a > >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part > >> >> > of 4.5.0-rc6 ... > >> >> > >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though > >> >> I'm on am335x and not on DM3730: > >> > > >> > How do you trigger the issue? Plug the modem then unplug it? > >> > Can you please try the way in [1] to increase the loops to see if the > >> > fifo could be flushed in a longer time? > >> > > >> > Regards, > >> > -Bin. > >> > > >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html > >> > >> Do you mean something like this? > >> > >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > >> index 58487a4..f6d6822 100644 > >> --- a/drivers/usb/musb/musb_host.c > >> +++ b/drivers/usb/musb/musb_host.c > >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) > >> struct musb *musb = ep->musb; > >> void __iomem *epio = ep->regs; > >> u16 csr; > >> - int retries = 1000; > >> + int retries = 10000; > > > > Yes. > > > >> > >> csr = musb_readw(epio, MUSB_TXCSR); > >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { > >> > >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. > >> our hardware can power on/off mPCIe slot via GPIO pin. When the system > >> starts mPCI slot is disabled. The I enable it after booting into user > >> space and the produces the error. It also happens if I insert USB > > > > Ok. I can imagine the device is no longer functional due to the fifo > > flush issue. > > I've inserted the mPCIe modem into the system, where mPCIe is alsways > on and the issue is still there. Some modems like Huawei MU609 are > working, but when using with the latest usb_modeswitch and compiling > all those drivers as modules (option, qmi_wwan etc.) I can also > provoke the FIFO flush issue. What are the version number of old and new musb_modeswitch? Mine is 2.0.1 but I didn't see such issue on my modems. > > >> modem as a dongle, where usb_modeswitch first has to switch it from > >> CD-ROM mode into modem mode. > > > > Any detail of the usb modem dongle? I will try to find one to take a > > look. I have a few usb modems but none of them triggers this problem. > > TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) It seems no where in US selling it. Regards, -Bin. -- 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
On Mon, Mar 14, 2016 at 6:08 PM, Bin Liu <b-liu@ti.com> wrote: > Hi, > > On Mon, Mar 14, 2016 at 03:54:36PM +0100, Yegor Yefremov wrote: >> On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: >> > Hi, >> > >> > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: >> >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: >> >> > Hi Yegor, >> >> > >> >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: >> >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: >> >> >> > >> >> >> > Hi Yegor, >> >> >> > >> >> >> >> Hi Bin, >> >> >> >> >> >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and >> >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have >> >> >> >> > tried)... >> >> >> >> >> >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. >> >> >> >> Just activating SImCOM SIM7100E produces following error: >> >> >> >> >> >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc >> >> >> >> usbcore: registered new interface driver option >> >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) >> >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 >> >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 >> >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 >> >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 >> >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 >> >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device >> >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at >> >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 >> >> >> >> usbcore: registered new interface driver qmi_wwan >> >> >> >> ------------[ cut here ]------------ >> >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 >> >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() >> >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >> >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial >> >> >> >> musb_dsps musb_am335x >> >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 >> >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) >> >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) >> >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) >> >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) >> >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] >> >> >> >> (warn_slowpath_fmt+0x30/0x40) >> >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] >> >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) >> >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] >> >> >> >> (musb_cleanup_urb+0xbc/0x130) >> >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) >> >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) >> >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) >> >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] >> >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >> >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] >> >> >> >> (tty_port_shutdown+0x90/0x9c) >> >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) >> >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) >> >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) >> >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) >> >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) >> >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >> >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- >> >> >> >> >> >> >> >> Could you please take a look at this? >> >> >> >> >> >> >> >> Yegor >> >> >> > >> >> >> > I cannot reproduce it anymore, as commits >> >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 >> >> >> > bba40e6948b94cba71965285fbac31bd078c024a >> >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part >> >> >> > of 4.5.0-rc6 ... >> >> >> >> >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though >> >> >> I'm on am335x and not on DM3730: >> >> > >> >> > How do you trigger the issue? Plug the modem then unplug it? >> >> > Can you please try the way in [1] to increase the loops to see if the >> >> > fifo could be flushed in a longer time? >> >> > >> >> > Regards, >> >> > -Bin. >> >> > >> >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html >> >> >> >> Do you mean something like this? >> >> >> >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c >> >> index 58487a4..f6d6822 100644 >> >> --- a/drivers/usb/musb/musb_host.c >> >> +++ b/drivers/usb/musb/musb_host.c >> >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) >> >> struct musb *musb = ep->musb; >> >> void __iomem *epio = ep->regs; >> >> u16 csr; >> >> - int retries = 1000; >> >> + int retries = 10000; >> > >> > Yes. >> > >> >> >> >> csr = musb_readw(epio, MUSB_TXCSR); >> >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { >> >> >> >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. >> >> our hardware can power on/off mPCIe slot via GPIO pin. When the system >> >> starts mPCI slot is disabled. The I enable it after booting into user >> >> space and the produces the error. It also happens if I insert USB >> > >> > Ok. I can imagine the device is no longer functional due to the fifo >> > flush issue. >> >> I've inserted the mPCIe modem into the system, where mPCIe is alsways >> on and the issue is still there. Some modems like Huawei MU609 are >> working, but when using with the latest usb_modeswitch and compiling >> all those drivers as modules (option, qmi_wwan etc.) I can also >> provoke the FIFO flush issue. > > What are the version number of old and new musb_modeswitch? Mine is > 2.0.1 but I didn't see such issue on my modems. This is not the usb_modeswitch, that makes trouble, but the fact, that the latest usb_modeswitch_data (it requires usb_modeswitch 2.3.0) has an entry for Huawei MU609/909 and tries to switch the modem in Configuration 1 instead of the default one. For usb_modeswitch to function properly all those drivers must be compiled as modules (at least this is the experience I've made with it). I'll try to find a kernel configuration, that would trigger this behavior. What modems do you have? >> >> >> modem as a dongle, where usb_modeswitch first has to switch it from >> >> CD-ROM mode into modem mode. >> > >> > Any detail of the usb modem dongle? I will try to find one to take a >> > look. I have a few usb modems but none of them triggers this problem. >> >> TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) > > It seems no where in US selling it. Can you get SIMcom 7100E and mPCIe adapter? Yegor -- 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
Hi, On Mon, Mar 14, 2016 at 06:17:26PM +0100, Yegor Yefremov wrote: > On Mon, Mar 14, 2016 at 6:08 PM, Bin Liu <b-liu@ti.com> wrote: > > Hi, > > > > On Mon, Mar 14, 2016 at 03:54:36PM +0100, Yegor Yefremov wrote: > >> On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: > >> > Hi, > >> > > >> > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: > >> >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: > >> >> > Hi Yegor, > >> >> > > >> >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: > >> >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: > >> >> >> > > >> >> >> > Hi Yegor, > >> >> >> > > >> >> >> >> Hi Bin, > >> >> >> >> > >> >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and > >> >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have > >> >> >> >> > tried)... > >> >> >> >> > >> >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. > >> >> >> >> Just activating SImCOM SIM7100E produces following error: > >> >> >> >> > >> >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc > >> >> >> >> usbcore: registered new interface driver option > >> >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) > >> >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected > >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 > >> >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected > >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 > >> >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected > >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 > >> >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected > >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 > >> >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected > >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 > >> >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device > >> >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at > >> >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 > >> >> >> >> usbcore: registered new interface driver qmi_wwan > >> >> >> >> ------------[ cut here ]------------ > >> >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 > >> >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() > >> >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > >> >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial > >> >> >> >> musb_dsps musb_am335x > >> >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 > >> >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) > >> >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) > >> >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) > >> >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) > >> >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] > >> >> >> >> (warn_slowpath_fmt+0x30/0x40) > >> >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] > >> >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) > >> >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] > >> >> >> >> (musb_cleanup_urb+0xbc/0x130) > >> >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) > >> >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) > >> >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) > >> >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] > >> >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > >> >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] > >> >> >> >> (tty_port_shutdown+0x90/0x9c) > >> >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) > >> >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) > >> >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) > >> >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) > >> >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) > >> >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > >> >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- > >> >> >> >> > >> >> >> >> Could you please take a look at this? > >> >> >> >> > >> >> >> >> Yegor > >> >> >> > > >> >> >> > I cannot reproduce it anymore, as commits > >> >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 > >> >> >> > bba40e6948b94cba71965285fbac31bd078c024a > >> >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part > >> >> >> > of 4.5.0-rc6 ... > >> >> >> > >> >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though > >> >> >> I'm on am335x and not on DM3730: > >> >> > > >> >> > How do you trigger the issue? Plug the modem then unplug it? > >> >> > Can you please try the way in [1] to increase the loops to see if the > >> >> > fifo could be flushed in a longer time? > >> >> > > >> >> > Regards, > >> >> > -Bin. > >> >> > > >> >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html > >> >> > >> >> Do you mean something like this? > >> >> > >> >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > >> >> index 58487a4..f6d6822 100644 > >> >> --- a/drivers/usb/musb/musb_host.c > >> >> +++ b/drivers/usb/musb/musb_host.c > >> >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) > >> >> struct musb *musb = ep->musb; > >> >> void __iomem *epio = ep->regs; > >> >> u16 csr; > >> >> - int retries = 1000; > >> >> + int retries = 10000; > >> > > >> > Yes. > >> > > >> >> > >> >> csr = musb_readw(epio, MUSB_TXCSR); > >> >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { > >> >> > >> >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. > >> >> our hardware can power on/off mPCIe slot via GPIO pin. When the system > >> >> starts mPCI slot is disabled. The I enable it after booting into user > >> >> space and the produces the error. It also happens if I insert USB > >> > > >> > Ok. I can imagine the device is no longer functional due to the fifo > >> > flush issue. > >> > >> I've inserted the mPCIe modem into the system, where mPCIe is alsways > >> on and the issue is still there. Some modems like Huawei MU609 are > >> working, but when using with the latest usb_modeswitch and compiling > >> all those drivers as modules (option, qmi_wwan etc.) I can also > >> provoke the FIFO flush issue. > > > > What are the version number of old and new musb_modeswitch? Mine is > > 2.0.1 but I didn't see such issue on my modems. > > This is not the usb_modeswitch, that makes trouble, but the fact, that > the latest usb_modeswitch_data (it requires usb_modeswitch 2.3.0) has > an entry for Huawei MU609/909 and tries to switch the modem in Oh, I see. > Configuration 1 instead of the default one. For usb_modeswitch to > function properly all those drivers must be compiled as modules (at > least this is the experience I've made with it). I'll try to find a I use modules in most of the times. > kernel configuration, that would trigger this behavior. > > What modems do you have? Alcatel HSPA Data Card, X230L I cannot find others at the moment. I just moved recently. Regards, -Bin. > > >> > >> >> modem as a dongle, where usb_modeswitch first has to switch it from > >> >> CD-ROM mode into modem mode. > >> > > >> > Any detail of the usb modem dongle? I will try to find one to take a > >> > look. I have a few usb modems but none of them triggers this problem. > >> > >> TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) > > > > It seems no where in US selling it. > > Can you get SIMcom 7100E and mPCIe adapter? I will do a search for it later. Regards, -Bin. -- 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
On Mon, Mar 14, 2016 at 6:59 PM, Bin Liu <b-liu@ti.com> wrote: > Hi, > > On Mon, Mar 14, 2016 at 06:17:26PM +0100, Yegor Yefremov wrote: >> On Mon, Mar 14, 2016 at 6:08 PM, Bin Liu <b-liu@ti.com> wrote: >> > Hi, >> > >> > On Mon, Mar 14, 2016 at 03:54:36PM +0100, Yegor Yefremov wrote: >> >> On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: >> >> > Hi, >> >> > >> >> > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: >> >> >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: >> >> >> > Hi Yegor, >> >> >> > >> >> >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: >> >> >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: >> >> >> >> > >> >> >> >> > Hi Yegor, >> >> >> >> > >> >> >> >> >> Hi Bin, >> >> >> >> >> >> >> >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and >> >> >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have >> >> >> >> >> > tried)... >> >> >> >> >> >> >> >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. >> >> >> >> >> Just activating SImCOM SIM7100E produces following error: >> >> >> >> >> >> >> >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc >> >> >> >> >> usbcore: registered new interface driver option >> >> >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) >> >> >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected >> >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 >> >> >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected >> >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 >> >> >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected >> >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 >> >> >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected >> >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 >> >> >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected >> >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 >> >> >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device >> >> >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at >> >> >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 >> >> >> >> >> usbcore: registered new interface driver qmi_wwan >> >> >> >> >> ------------[ cut here ]------------ >> >> >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 >> >> >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() >> >> >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >> >> >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial >> >> >> >> >> musb_dsps musb_am335x >> >> >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 >> >> >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) >> >> >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) >> >> >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) >> >> >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) >> >> >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] >> >> >> >> >> (warn_slowpath_fmt+0x30/0x40) >> >> >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] >> >> >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) >> >> >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] >> >> >> >> >> (musb_cleanup_urb+0xbc/0x130) >> >> >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) >> >> >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) >> >> >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) >> >> >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] >> >> >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >> >> >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] >> >> >> >> >> (tty_port_shutdown+0x90/0x9c) >> >> >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) >> >> >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) >> >> >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) >> >> >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) >> >> >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) >> >> >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >> >> >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- >> >> >> >> >> >> >> >> >> >> Could you please take a look at this? >> >> >> >> >> >> >> >> >> >> Yegor >> >> >> >> > >> >> >> >> > I cannot reproduce it anymore, as commits >> >> >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 >> >> >> >> > bba40e6948b94cba71965285fbac31bd078c024a >> >> >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part >> >> >> >> > of 4.5.0-rc6 ... >> >> >> >> >> >> >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though >> >> >> >> I'm on am335x and not on DM3730: >> >> >> > >> >> >> > How do you trigger the issue? Plug the modem then unplug it? >> >> >> > Can you please try the way in [1] to increase the loops to see if the >> >> >> > fifo could be flushed in a longer time? >> >> >> > >> >> >> > Regards, >> >> >> > -Bin. >> >> >> > >> >> >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html >> >> >> >> >> >> Do you mean something like this? >> >> >> >> >> >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c >> >> >> index 58487a4..f6d6822 100644 >> >> >> --- a/drivers/usb/musb/musb_host.c >> >> >> +++ b/drivers/usb/musb/musb_host.c >> >> >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) >> >> >> struct musb *musb = ep->musb; >> >> >> void __iomem *epio = ep->regs; >> >> >> u16 csr; >> >> >> - int retries = 1000; >> >> >> + int retries = 10000; >> >> > >> >> > Yes. >> >> > >> >> >> >> >> >> csr = musb_readw(epio, MUSB_TXCSR); >> >> >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { >> >> >> >> >> >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. >> >> >> our hardware can power on/off mPCIe slot via GPIO pin. When the system >> >> >> starts mPCI slot is disabled. The I enable it after booting into user >> >> >> space and the produces the error. It also happens if I insert USB >> >> > >> >> > Ok. I can imagine the device is no longer functional due to the fifo >> >> > flush issue. >> >> >> >> I've inserted the mPCIe modem into the system, where mPCIe is alsways >> >> on and the issue is still there. Some modems like Huawei MU609 are >> >> working, but when using with the latest usb_modeswitch and compiling >> >> all those drivers as modules (option, qmi_wwan etc.) I can also >> >> provoke the FIFO flush issue. >> > >> > What are the version number of old and new musb_modeswitch? Mine is >> > 2.0.1 but I didn't see such issue on my modems. >> >> This is not the usb_modeswitch, that makes trouble, but the fact, that >> the latest usb_modeswitch_data (it requires usb_modeswitch 2.3.0) has >> an entry for Huawei MU609/909 and tries to switch the modem in > > Oh, I see. > >> Configuration 1 instead of the default one. For usb_modeswitch to >> function properly all those drivers must be compiled as modules (at >> least this is the experience I've made with it). I'll try to find a > > I use modules in most of the times. > >> kernel configuration, that would trigger this behavior. >> >> What modems do you have? > > Alcatel HSPA Data Card, X230L > > I cannot find others at the moment. I just moved recently. OK :-) >> >> >> modem as a dongle, where usb_modeswitch first has to switch it from >> >> >> CD-ROM mode into modem mode. >> >> > >> >> > Any detail of the usb modem dongle? I will try to find one to take a >> >> > look. I have a few usb modems but none of them triggers this problem. >> >> >> >> TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) >> > >> > It seems no where in US selling it. >> >> Can you get SIMcom 7100E and mPCIe adapter? > > I will do a search for it later. Btw if you do get hold of a mPCIe modem, you can have our Baltos iR5221 for testing. Ask Felipe Balbi. He knows, where you can find one sample. Yegor -- 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
Hi, On Mon, Mar 14, 2016 at 03:54:36PM +0100, Yegor Yefremov wrote: > On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: > > Hi, > > > > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: > >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: > >> > Hi Yegor, > >> > > >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: > >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: > >> >> > > >> >> > Hi Yegor, > >> >> > > >> >> >> Hi Bin, > >> >> >> > >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: > >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and > >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have > >> >> >> > tried)... > >> >> >> > >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. > >> >> >> Just activating SImCOM SIM7100E produces following error: > >> >> >> > >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc > >> >> >> usbcore: registered new interface driver option > >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) > >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 > >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 > >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 > >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 > >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected > >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 > >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device > >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at > >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 > >> >> >> usbcore: registered new interface driver qmi_wwan > >> >> >> ------------[ cut here ]------------ > >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 > >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() > >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial > >> >> >> musb_dsps musb_am335x > >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 > >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) > >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) > >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) > >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) > >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] > >> >> >> (warn_slowpath_fmt+0x30/0x40) > >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] > >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) > >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] > >> >> >> (musb_cleanup_urb+0xbc/0x130) > >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) > >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) > >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) > >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] > >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] > >> >> >> (tty_port_shutdown+0x90/0x9c) > >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) > >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) > >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) > >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) > >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) > >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- > >> >> >> > >> >> >> Could you please take a look at this? > >> >> >> > >> >> >> Yegor > >> >> > > >> >> > I cannot reproduce it anymore, as commits > >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 > >> >> > bba40e6948b94cba71965285fbac31bd078c024a > >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part > >> >> > of 4.5.0-rc6 ... > >> >> > >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though > >> >> I'm on am335x and not on DM3730: > >> > > >> > How do you trigger the issue? Plug the modem then unplug it? > >> > Can you please try the way in [1] to increase the loops to see if the > >> > fifo could be flushed in a longer time? > >> > > >> > Regards, > >> > -Bin. > >> > > >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html > >> > >> Do you mean something like this? > >> > >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c > >> index 58487a4..f6d6822 100644 > >> --- a/drivers/usb/musb/musb_host.c > >> +++ b/drivers/usb/musb/musb_host.c > >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) > >> struct musb *musb = ep->musb; > >> void __iomem *epio = ep->regs; > >> u16 csr; > >> - int retries = 1000; > >> + int retries = 10000; > > > > Yes. > > > >> > >> csr = musb_readw(epio, MUSB_TXCSR); > >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { > >> > >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. > >> our hardware can power on/off mPCIe slot via GPIO pin. When the system > >> starts mPCI slot is disabled. The I enable it after booting into user > >> space and the produces the error. It also happens if I insert USB > > > > Ok. I can imagine the device is no longer functional due to the fifo > > flush issue. > > I've inserted the mPCIe modem into the system, where mPCIe is alsways > on and the issue is still there. Some modems like Huawei MU609 are > working, but when using with the latest usb_modeswitch and compiling > all those drivers as modules (option, qmi_wwan etc.) I can also > provoke the FIFO flush issue. > > >> modem as a dongle, where usb_modeswitch first has to switch it from > >> CD-ROM mode into modem mode. > > > > Any detail of the usb modem dongle? I will try to find one to take a > > look. I have a few usb modems but none of them triggers this problem. > > TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) > What exactly do you do to trigger the fifo flush problem on MA260? I got a MA260 dongle, but usb_modeswitch does not trigger it. Regards, -Bin. -- 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
On Thu, Mar 31, 2016 at 10:13 PM, Bin Liu <b-liu@ti.com> wrote: > Hi, > > On Mon, Mar 14, 2016 at 03:54:36PM +0100, Yegor Yefremov wrote: >> On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: >> > Hi, >> > >> > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: >> >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: >> >> > Hi Yegor, >> >> > >> >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: >> >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: >> >> >> > >> >> >> > Hi Yegor, >> >> >> > >> >> >> >> Hi Bin, >> >> >> >> >> >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: >> >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and >> >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have >> >> >> >> > tried)... >> >> >> >> >> >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. >> >> >> >> Just activating SImCOM SIM7100E produces following error: >> >> >> >> >> >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc >> >> >> >> usbcore: registered new interface driver option >> >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) >> >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 >> >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 >> >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 >> >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 >> >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected >> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 >> >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device >> >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at >> >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 >> >> >> >> usbcore: registered new interface driver qmi_wwan >> >> >> >> ------------[ cut here ]------------ >> >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 >> >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() >> >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >> >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial >> >> >> >> musb_dsps musb_am335x >> >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 >> >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) >> >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) >> >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) >> >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) >> >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] >> >> >> >> (warn_slowpath_fmt+0x30/0x40) >> >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] >> >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) >> >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] >> >> >> >> (musb_cleanup_urb+0xbc/0x130) >> >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) >> >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) >> >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) >> >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] >> >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >> >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] >> >> >> >> (tty_port_shutdown+0x90/0x9c) >> >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) >> >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) >> >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) >> >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) >> >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) >> >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >> >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- >> >> >> >> >> >> >> >> Could you please take a look at this? >> >> >> >> >> >> >> >> Yegor >> >> >> > >> >> >> > I cannot reproduce it anymore, as commits >> >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 >> >> >> > bba40e6948b94cba71965285fbac31bd078c024a >> >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part >> >> >> > of 4.5.0-rc6 ... >> >> >> >> >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though >> >> >> I'm on am335x and not on DM3730: >> >> > >> >> > How do you trigger the issue? Plug the modem then unplug it? >> >> > Can you please try the way in [1] to increase the loops to see if the >> >> > fifo could be flushed in a longer time? >> >> > >> >> > Regards, >> >> > -Bin. >> >> > >> >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html >> >> >> >> Do you mean something like this? >> >> >> >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c >> >> index 58487a4..f6d6822 100644 >> >> --- a/drivers/usb/musb/musb_host.c >> >> +++ b/drivers/usb/musb/musb_host.c >> >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) >> >> struct musb *musb = ep->musb; >> >> void __iomem *epio = ep->regs; >> >> u16 csr; >> >> - int retries = 1000; >> >> + int retries = 10000; >> > >> > Yes. >> > >> >> >> >> csr = musb_readw(epio, MUSB_TXCSR); >> >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { >> >> >> >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. >> >> our hardware can power on/off mPCIe slot via GPIO pin. When the system >> >> starts mPCI slot is disabled. The I enable it after booting into user >> >> space and the produces the error. It also happens if I insert USB >> > >> > Ok. I can imagine the device is no longer functional due to the fifo >> > flush issue. >> >> I've inserted the mPCIe modem into the system, where mPCIe is alsways >> on and the issue is still there. Some modems like Huawei MU609 are >> working, but when using with the latest usb_modeswitch and compiling >> all those drivers as modules (option, qmi_wwan etc.) I can also >> provoke the FIFO flush issue. >> >> >> modem as a dongle, where usb_modeswitch first has to switch it from >> >> CD-ROM mode into modem mode. >> > >> > Any detail of the usb modem dongle? I will try to find one to take a >> > look. I have a few usb modems but none of them triggers this problem. >> >> TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) >> > > What exactly do you do to trigger the fifo flush problem on MA260? I got > a MA260 dongle, but usb_modeswitch does not trigger it. I'm using Debian 8 image with following usb_modeswitch: root@baltos:~# usb_modeswitch -e * usb_modeswitch: handle USB devices with multiple modes * Version 2.2.0 (C) Josua Dietze 2014 * Based on libusb1/libusbx ! PLEASE REPORT NEW CONFIGURATIONS ! Both 3.18.21 and 4.5.0 report following error after MA260 insertion: usb 1-1.2: new high-speed USB device number 3 using musb-hdrc usb 1-1.2: New USB device found, idVendor=2357, idProduct=f000 usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 usb 1-1.2: Product: TP-LINK HSPA+ Modem usb 1-1.2: Manufacturer: TP-LINK, Incorporated usb 1-1.2: SerialNumber: 863745011099716 usb-storage 1-1.2:1.0: USB Mass Storage device detected scsi host0: usb-storage 1-1.2:1.0 scsi 0:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 scsi 0:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 sd 0:0:0:1: [sda] Attached SCSI removable disk usb 1-1.2: USB disconnect, device number 3 usb 1-1.2: new high-speed USB device number 4 using musb-hdrc usb 1-1.2: New USB device found, idVendor=2357, idProduct=9000 usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 usb 1-1.2: Product: TP-LINK HSPA+ Modem usb 1-1.2: Manufacturer: TP-LINK, Incorporated usb 1-1.2: SerialNumber: 863745011099716 usb-storage 1-1.2:1.2: USB Mass Storage device detected scsi host1: usb-storage 1-1.2:1.2 qmi_wwan 1-1.2:1.4: cdc-wdm0: USB WDM device qmi_wwan 1-1.2:1.4 wwan0: register 'qmi_wwan' at usb-musb-hdrc.0.auto-1.2, WWAN/QMI device, de:ea:e8:d0:61:6c usbcore: registered new interface driver option usbserial: USB Serial support registered for GSM modem (1-port) option 1-1.2:1.0: GSM modem (1-port) converter detected usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 option 1-1.2:1.1: GSM modem (1-port) converter detected usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 option 1-1.2:1.3: GSM modem (1-port) converter detected usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 scsi 1:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 scsi 1:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 sd 1:0:0:1: [sda] Attached SCSI removable disk ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1740 at drivers/usb/musb/musb_host.c:139 musb_h_tx_flush_fifo+0xc4/0xe4() musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 Modules linked in: option usb_wwan musb_dsps musb_am335x CPU: 0 PID: 1740 Comm: ModemManager Not tainted 4.5.0 #1 Hardware name: Generic AM33XX (Flattened Device Tree) [<c0017ecc>] (unwind_backtrace) from [<c0014100>] (show_stack+0x10/0x14) [<c0014100>] (show_stack) from [<c03cf384>] (dump_stack+0xb0/0xe4) [<c03cf384>] (dump_stack) from [<c003bf68>] (warn_slowpath_common+0x7c/0xb8) [<c003bf68>] (warn_slowpath_common) from [<c003bfd4>] (warn_slowpath_fmt+0x30/0x40) [<c003bfd4>] (warn_slowpath_fmt) from [<c0534c30>] (musb_h_tx_flush_fifo+0xc4/0xe4) [<c0534c30>] (musb_h_tx_flush_fifo) from [<c0535d74>] (musb_cleanup_urb+0xbc/0x130) [<c0535d74>] (musb_cleanup_urb) from [<c0536424>] (musb_urb_dequeue+0xf0/0x128) [<c0536424>] (musb_urb_dequeue) from [<c050b98c>] (usb_hcd_unlink_urb+0x50/0x84) [<c050b98c>] (usb_hcd_unlink_urb) from [<c050cbd0>] (usb_kill_urb+0x4c/0xc4) [<c050cbd0>] (usb_kill_urb) from [<bf00e85c>] (usb_wwan_close+0xbc/0xf0 [usb_wwan]) [<bf00e85c>] (usb_wwan_close [usb_wwan]) from [<c042d8e0>] (tty_port_shutdown+0x90/0x9c) [<c042d8e0>] (tty_port_shutdown) from [<c042dfd0>] (tty_port_close+0x24/0x4c) [<c042dfd0>] (tty_port_close) from [<c0425f30>] (tty_release+0xec/0x474) [<c0425f30>] (tty_release) from [<c0168b60>] (__fput+0x80/0x1d0) [<c0168b60>] (__fput) from [<c005b944>] (task_work_run+0x90/0xc4) [<c005b944>] (task_work_run) from [<c0013ac4>] (do_work_pending+0x8c/0xb4) [<c0013ac4>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) ---[ end trace cbf0ee35fffa18d3 ]--- Debian image was created with these scripts: https://github.com/visionsystemsgmbh/vsdebootstrap Kernel config: https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/linux-3.15-config I've tried both usb1 channel and USB hub and usb2 channel directly. In both cases I get this crash. Yegor -- 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
Hi Bin, On Fri, Apr 1, 2016 at 8:56 AM, Yegor Yefremov <yegorslists@googlemail.com> wrote: > On Thu, Mar 31, 2016 at 10:13 PM, Bin Liu <b-liu@ti.com> wrote: >> Hi, >> >> On Mon, Mar 14, 2016 at 03:54:36PM +0100, Yegor Yefremov wrote: >>> On Mon, Mar 14, 2016 at 3:42 PM, Bin Liu <b-liu@ti.com> wrote: >>> > Hi, >>> > >>> > On Mon, Mar 14, 2016 at 03:33:51PM +0100, Yegor Yefremov wrote: >>> >> On Mon, Mar 14, 2016 at 3:01 PM, Bin Liu <b-liu@ti.com> wrote: >>> >> > Hi Yegor, >>> >> > >>> >> > On Mon, Mar 14, 2016 at 02:40:34PM +0100, Yegor Yefremov wrote: >>> >> >> On Mon, Mar 14, 2016 at 1:11 PM, Ladislav Michl <ladis@linux-mips.org> wrote: >>> >> >> > On Mon, Mar 14, 2016 at 11:25:59AM +0100, Yegor Yefremov wrote: >>> >> >> > >>> >> >> > Hi Yegor, >>> >> >> > >>> >> >> >> Hi Bin, >>> >> >> >> >>> >> >> >> On Wed, Jan 27, 2016 at 11:01 AM, Ladislav Michl <ladis@linux-mips.org> wrote: >>> >> >> >> > Any chance it will actually happen? MUSB is still unusable for me and >>> >> >> >> > doesn't work properly since TI's 2.6.37 kernel (oldest one I have >>> >> >> >> > tried)... >>> >> >> >> >>> >> >> >> The issue with musb_h_tx_flush_fifo still persists. Kernel 4.5.0-rc6. >>> >> >> >> Just activating SImCOM SIM7100E produces following error: >>> >> >> >> >>> >> >> >> # usb 1-1.3: new high-speed USB device number 6 using musb-hdrc >>> >> >> >> usbcore: registered new interface driver option >>> >> >> >> usbserial: USB Serial support registered for GSM modem (1-port) >>> >> >> >> option 1-1.3:1.0: GSM modem (1-port) converter detected >>> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB4 >>> >> >> >> option 1-1.3:1.1: GSM modem (1-port) converter detected >>> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB5 >>> >> >> >> option 1-1.3:1.2: GSM modem (1-port) converter detected >>> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB6 >>> >> >> >> option 1-1.3:1.3: GSM modem (1-port) converter detected >>> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB7 >>> >> >> >> option 1-1.3:1.4: GSM modem (1-port) converter detected >>> >> >> >> usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB8 >>> >> >> >> qmi_wwan 1-1.3:1.5: cdc-wdm0: USB WDM device >>> >> >> >> qmi_wwan 1-1.3:1.5 wwan0: register 'qmi_wwan' at >>> >> >> >> usb-musb-hdrc.0.auto-1.3, WWAN/QMI device, b2:67:d8:31:8f:b6 >>> >> >> >> usbcore: registered new interface driver qmi_wwan >>> >> >> >> ------------[ cut here ]------------ >>> >> >> >> WARNING: CPU: 0 PID: 868 at drivers/usb/musb/musb_host.c:139 >>> >> >> >> musb_h_tx_flush_fifo+0xc4/0xe4() >>> >> >> >> musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >>> >> >> >> Modules linked in: qmi_wwan option usb_wwan ftdi_sio usbserial >>> >> >> >> musb_dsps musb_am335x >>> >> >> >> CPU: 0 PID: 868 Comm: ModemManager Not tainted 4.5.0-rc6 #47 >>> >> >> >> Hardware name: Generic AM33XX (Flattened Device Tree) >>> >> >> >> [<c0017e34>] (unwind_backtrace) from [<c0014088>] (show_stack+0x10/0x14) >>> >> >> >> [<c0014088>] (show_stack) from [<c02c5b24>] (dump_stack+0xb0/0xe4) >>> >> >> >> [<c02c5b24>] (dump_stack) from [<c003bca4>] (warn_slowpath_common+0x7c/0xb8) >>> >> >> >> [<c003bca4>] (warn_slowpath_common) from [<c003bd10>] >>> >> >> >> (warn_slowpath_fmt+0x30/0x40) >>> >> >> >> [<c003bd10>] (warn_slowpath_fmt) from [<c041ec10>] >>> >> >> >> (musb_h_tx_flush_fifo+0xc4/0xe4) >>> >> >> >> [<c041ec10>] (musb_h_tx_flush_fifo) from [<c041fd54>] >>> >> >> >> (musb_cleanup_urb+0xbc/0x130) >>> >> >> >> [<c041fd54>] (musb_cleanup_urb) from [<c0420404>] (musb_urb_dequeue+0xf0/0x128) >>> >> >> >> [<c0420404>] (musb_urb_dequeue) from [<c03fa82c>] (usb_hcd_unlink_urb+0x50/0x84) >>> >> >> >> [<c03fa82c>] (usb_hcd_unlink_urb) from [<c03fba70>] (usb_kill_urb+0x4c/0xc4) >>> >> >> >> [<c03fba70>] (usb_kill_urb) from [<bf02f85c>] >>> >> >> >> (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >>> >> >> >> [<bf02f85c>] (usb_wwan_close [usb_wwan]) from [<c0322ce8>] >>> >> >> >> (tty_port_shutdown+0x90/0x9c) >>> >> >> >> [<c0322ce8>] (tty_port_shutdown) from [<c03233cc>] (tty_port_close+0x24/0x4c) >>> >> >> >> [<c03233cc>] (tty_port_close) from [<c031a258>] (tty_release+0xec/0x478) >>> >> >> >> [<c031a258>] (tty_release) from [<c014ef38>] (__fput+0x80/0x1d0) >>> >> >> >> [<c014ef38>] (__fput) from [<c005a8d8>] (task_work_run+0x90/0xc4) >>> >> >> >> [<c005a8d8>] (task_work_run) from [<c0013a4c>] (do_work_pending+0x8c/0xb4) >>> >> >> >> [<c0013a4c>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >>> >> >> >> ---[ end trace fb2fc0420e2c4594 ]--- >>> >> >> >> >>> >> >> >> Could you please take a look at this? >>> >> >> >> >>> >> >> >> Yegor >>> >> >> > >>> >> >> > I cannot reproduce it anymore, as commits >>> >> >> > 4c2ba0c67394514f3f75c660c9f5d02e66a7efd4 >>> >> >> > bba40e6948b94cba71965285fbac31bd078c024a >>> >> >> > fixed issue for me (using Inventra DMA on DM3730) - but those two are part >>> >> >> > of 4.5.0-rc6 ... >>> >> >> >>> >> >> You are lucky! I've tried 4.5.0 and I still have this issue, though >>> >> >> I'm on am335x and not on DM3730: >>> >> > >>> >> > How do you trigger the issue? Plug the modem then unplug it? >>> >> > Can you please try the way in [1] to increase the loops to see if the >>> >> > fifo could be flushed in a longer time? >>> >> > >>> >> > Regards, >>> >> > -Bin. >>> >> > >>> >> > [1] http://www.spinics.net/lists/linux-usb/msg137242.html >>> >> >>> >> Do you mean something like this? >>> >> >>> >> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c >>> >> index 58487a4..f6d6822 100644 >>> >> --- a/drivers/usb/musb/musb_host.c >>> >> +++ b/drivers/usb/musb/musb_host.c >>> >> @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) >>> >> struct musb *musb = ep->musb; >>> >> void __iomem *epio = ep->regs; >>> >> u16 csr; >>> >> - int retries = 1000; >>> >> + int retries = 10000; >>> > >>> > Yes. >>> > >>> >> >>> >> csr = musb_readw(epio, MUSB_TXCSR); >>> >> while (csr & MUSB_TXCSR_FIFONOTEMPTY) { >>> >> >>> >> No, it doesn't help. I'm triggering this issue via enabling it, i.e. >>> >> our hardware can power on/off mPCIe slot via GPIO pin. When the system >>> >> starts mPCI slot is disabled. The I enable it after booting into user >>> >> space and the produces the error. It also happens if I insert USB >>> > >>> > Ok. I can imagine the device is no longer functional due to the fifo >>> > flush issue. >>> >>> I've inserted the mPCIe modem into the system, where mPCIe is alsways >>> on and the issue is still there. Some modems like Huawei MU609 are >>> working, but when using with the latest usb_modeswitch and compiling >>> all those drivers as modules (option, qmi_wwan etc.) I can also >>> provoke the FIFO flush issue. >>> >>> >> modem as a dongle, where usb_modeswitch first has to switch it from >>> >> CD-ROM mode into modem mode. >>> > >>> > Any detail of the usb modem dongle? I will try to find one to take a >>> > look. I have a few usb modems but none of them triggers this problem. >>> >>> TP-LINK MA260 (http://www.tp-link.com/en/products/details/cat-5090_MA260.html) >>> >> >> What exactly do you do to trigger the fifo flush problem on MA260? I got >> a MA260 dongle, but usb_modeswitch does not trigger it. > > I'm using Debian 8 image with following usb_modeswitch: > > root@baltos:~# usb_modeswitch -e > > * usb_modeswitch: handle USB devices with multiple modes > * Version 2.2.0 (C) Josua Dietze 2014 > * Based on libusb1/libusbx > > ! PLEASE REPORT NEW CONFIGURATIONS ! > > Both 3.18.21 and 4.5.0 report following error after MA260 insertion: > > usb 1-1.2: new high-speed USB device number 3 using musb-hdrc > usb 1-1.2: New USB device found, idVendor=2357, idProduct=f000 > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > usb 1-1.2: Product: TP-LINK HSPA+ Modem > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > usb 1-1.2: SerialNumber: 863745011099716 > usb-storage 1-1.2:1.0: USB Mass Storage device detected > scsi host0: usb-storage 1-1.2:1.0 > scsi 0:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > scsi 0:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > sd 0:0:0:1: [sda] Attached SCSI removable disk > usb 1-1.2: USB disconnect, device number 3 > usb 1-1.2: new high-speed USB device number 4 using musb-hdrc > usb 1-1.2: New USB device found, idVendor=2357, idProduct=9000 > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > usb 1-1.2: Product: TP-LINK HSPA+ Modem > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > usb 1-1.2: SerialNumber: 863745011099716 > usb-storage 1-1.2:1.2: USB Mass Storage device detected > scsi host1: usb-storage 1-1.2:1.2 > qmi_wwan 1-1.2:1.4: cdc-wdm0: USB WDM device > qmi_wwan 1-1.2:1.4 wwan0: register 'qmi_wwan' at > usb-musb-hdrc.0.auto-1.2, WWAN/QMI device, de:ea:e8:d0:61:6c > usbcore: registered new interface driver option > usbserial: USB Serial support registered for GSM modem (1-port) > option 1-1.2:1.0: GSM modem (1-port) converter detected > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 > option 1-1.2:1.1: GSM modem (1-port) converter detected > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 > option 1-1.2:1.3: GSM modem (1-port) converter detected > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 > scsi 1:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > scsi 1:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > sd 1:0:0:1: [sda] Attached SCSI removable disk > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 1740 at drivers/usb/musb/musb_host.c:139 > musb_h_tx_flush_fifo+0xc4/0xe4() > musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > Modules linked in: option usb_wwan musb_dsps musb_am335x > CPU: 0 PID: 1740 Comm: ModemManager Not tainted 4.5.0 #1 > Hardware name: Generic AM33XX (Flattened Device Tree) > [<c0017ecc>] (unwind_backtrace) from [<c0014100>] (show_stack+0x10/0x14) > [<c0014100>] (show_stack) from [<c03cf384>] (dump_stack+0xb0/0xe4) > [<c03cf384>] (dump_stack) from [<c003bf68>] (warn_slowpath_common+0x7c/0xb8) > [<c003bf68>] (warn_slowpath_common) from [<c003bfd4>] > (warn_slowpath_fmt+0x30/0x40) > [<c003bfd4>] (warn_slowpath_fmt) from [<c0534c30>] > (musb_h_tx_flush_fifo+0xc4/0xe4) > [<c0534c30>] (musb_h_tx_flush_fifo) from [<c0535d74>] > (musb_cleanup_urb+0xbc/0x130) > [<c0535d74>] (musb_cleanup_urb) from [<c0536424>] (musb_urb_dequeue+0xf0/0x128) > [<c0536424>] (musb_urb_dequeue) from [<c050b98c>] (usb_hcd_unlink_urb+0x50/0x84) > [<c050b98c>] (usb_hcd_unlink_urb) from [<c050cbd0>] (usb_kill_urb+0x4c/0xc4) > [<c050cbd0>] (usb_kill_urb) from [<bf00e85c>] > (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > [<bf00e85c>] (usb_wwan_close [usb_wwan]) from [<c042d8e0>] > (tty_port_shutdown+0x90/0x9c) > [<c042d8e0>] (tty_port_shutdown) from [<c042dfd0>] (tty_port_close+0x24/0x4c) > [<c042dfd0>] (tty_port_close) from [<c0425f30>] (tty_release+0xec/0x474) > [<c0425f30>] (tty_release) from [<c0168b60>] (__fput+0x80/0x1d0) > [<c0168b60>] (__fput) from [<c005b944>] (task_work_run+0x90/0xc4) > [<c005b944>] (task_work_run) from [<c0013ac4>] (do_work_pending+0x8c/0xb4) > [<c0013ac4>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > ---[ end trace cbf0ee35fffa18d3 ]--- > > Debian image was created with these scripts: > https://github.com/visionsystemsgmbh/vsdebootstrap > Kernel config: https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/linux-3.15-config > > I've tried both usb1 channel and USB hub and usb2 channel directly. In > both cases I get this crash. I've made some more test and could at least find a software constellation, that produces this error. You'll need ModemManager and libqmi. As soon as ModemManager sees the modem it opens and closes its interfaces in oder to get modem's configuration. And wwan closing seems to produce this error. I could reproduce this behavior with am335x-evmsk, Linux 4.5 (omap2plus_defconfig, CONFIG_USB_NET_CDC_MBIM, CONFIG_USB_NET_QMI_WWAN and CONFIG_USB_SERIAL_OPTION) and Buildroot with enabled ModemManager and libqmi support. Yegor -- 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
Yegor, On Mon, Apr 04, 2016 at 09:03:46AM +0200, Yegor Yefremov wrote: > > > > I'm using Debian 8 image with following usb_modeswitch: > > > > root@baltos:~# usb_modeswitch -e > > > > * usb_modeswitch: handle USB devices with multiple modes > > * Version 2.2.0 (C) Josua Dietze 2014 > > * Based on libusb1/libusbx > > > > ! PLEASE REPORT NEW CONFIGURATIONS ! > > > > Both 3.18.21 and 4.5.0 report following error after MA260 insertion: > > > > usb 1-1.2: new high-speed USB device number 3 using musb-hdrc > > usb 1-1.2: New USB device found, idVendor=2357, idProduct=f000 > > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > usb 1-1.2: Product: TP-LINK HSPA+ Modem > > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > > usb 1-1.2: SerialNumber: 863745011099716 > > usb-storage 1-1.2:1.0: USB Mass Storage device detected > > scsi host0: usb-storage 1-1.2:1.0 > > scsi 0:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > scsi 0:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > sd 0:0:0:1: [sda] Attached SCSI removable disk > > usb 1-1.2: USB disconnect, device number 3 > > usb 1-1.2: new high-speed USB device number 4 using musb-hdrc > > usb 1-1.2: New USB device found, idVendor=2357, idProduct=9000 > > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > usb 1-1.2: Product: TP-LINK HSPA+ Modem > > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > > usb 1-1.2: SerialNumber: 863745011099716 > > usb-storage 1-1.2:1.2: USB Mass Storage device detected > > scsi host1: usb-storage 1-1.2:1.2 > > qmi_wwan 1-1.2:1.4: cdc-wdm0: USB WDM device > > qmi_wwan 1-1.2:1.4 wwan0: register 'qmi_wwan' at > > usb-musb-hdrc.0.auto-1.2, WWAN/QMI device, de:ea:e8:d0:61:6c > > usbcore: registered new interface driver option > > usbserial: USB Serial support registered for GSM modem (1-port) > > option 1-1.2:1.0: GSM modem (1-port) converter detected > > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 > > option 1-1.2:1.1: GSM modem (1-port) converter detected > > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 > > option 1-1.2:1.3: GSM modem (1-port) converter detected > > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 > > scsi 1:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > scsi 1:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > sd 1:0:0:1: [sda] Attached SCSI removable disk > > ------------[ cut here ]------------ > > WARNING: CPU: 0 PID: 1740 at drivers/usb/musb/musb_host.c:139 > > musb_h_tx_flush_fifo+0xc4/0xe4() > > musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > > Modules linked in: option usb_wwan musb_dsps musb_am335x > > CPU: 0 PID: 1740 Comm: ModemManager Not tainted 4.5.0 #1 > > Hardware name: Generic AM33XX (Flattened Device Tree) > > [<c0017ecc>] (unwind_backtrace) from [<c0014100>] (show_stack+0x10/0x14) > > [<c0014100>] (show_stack) from [<c03cf384>] (dump_stack+0xb0/0xe4) > > [<c03cf384>] (dump_stack) from [<c003bf68>] (warn_slowpath_common+0x7c/0xb8) > > [<c003bf68>] (warn_slowpath_common) from [<c003bfd4>] > > (warn_slowpath_fmt+0x30/0x40) > > [<c003bfd4>] (warn_slowpath_fmt) from [<c0534c30>] > > (musb_h_tx_flush_fifo+0xc4/0xe4) > > [<c0534c30>] (musb_h_tx_flush_fifo) from [<c0535d74>] > > (musb_cleanup_urb+0xbc/0x130) > > [<c0535d74>] (musb_cleanup_urb) from [<c0536424>] (musb_urb_dequeue+0xf0/0x128) > > [<c0536424>] (musb_urb_dequeue) from [<c050b98c>] (usb_hcd_unlink_urb+0x50/0x84) > > [<c050b98c>] (usb_hcd_unlink_urb) from [<c050cbd0>] (usb_kill_urb+0x4c/0xc4) > > [<c050cbd0>] (usb_kill_urb) from [<bf00e85c>] > > (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > > [<bf00e85c>] (usb_wwan_close [usb_wwan]) from [<c042d8e0>] > > (tty_port_shutdown+0x90/0x9c) > > [<c042d8e0>] (tty_port_shutdown) from [<c042dfd0>] (tty_port_close+0x24/0x4c) > > [<c042dfd0>] (tty_port_close) from [<c0425f30>] (tty_release+0xec/0x474) > > [<c0425f30>] (tty_release) from [<c0168b60>] (__fput+0x80/0x1d0) > > [<c0168b60>] (__fput) from [<c005b944>] (task_work_run+0x90/0xc4) > > [<c005b944>] (task_work_run) from [<c0013ac4>] (do_work_pending+0x8c/0xb4) > > [<c0013ac4>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > > ---[ end trace cbf0ee35fffa18d3 ]--- > > > > Debian image was created with these scripts: > > https://github.com/visionsystemsgmbh/vsdebootstrap > > Kernel config: https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/linux-3.15-config > > > > I've tried both usb1 channel and USB hub and usb2 channel directly. In > > both cases I get this crash. > > I've made some more test and could at least find a software > constellation, that produces this error. You'll need ModemManager and > libqmi. As soon as ModemManager sees the modem it opens and closes its Are you sure it is ModemManager open/close the port? Or other app? In my debian rootfs, I did # apt-get install modemmanager libqmi-utils but it seems there is not open/close to the modem uart port. tx fifo flush problem still does not happen to me. here is the enum log. 1 [ 663.745927] usb 2-1: new high-speed USB device number 14 using musb-hdrc 2 [ 663.890525] usb 2-1: New USB device found, idVendor=2357, idProduct=f000 3 [ 663.897857] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 4 [ 663.905462] usb 2-1: Product: TP-LINK HSPA+ Modem 5 [ 663.910666] usb 2-1: Manufacturer: TP-LINK, Incorporated 6 [ 663.916451] usb 2-1: SerialNumber: 863745011324437 7 [ 663.961261] usb-storage 2-1:1.0: USB Mass Storage device detected 8 [ 663.996977] scsi host12: usb-storage 2-1:1.0 9 [ 664.999261] scsi 12:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 10 [ 665.010298] scsi 12:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 11 [ 665.059673] sd 12:0:0:1: [sda] Attached SCSI removable disk 12 [ 665.699173] usb 2-1: USB disconnect, device number 14 13 [ 666.195929] usb 2-1: new high-speed USB device number 15 using musb-hdrc 14 [ 666.340925] usb 2-1: New USB device found, idVendor=2357, idProduct=9000 15 [ 666.348258] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 16 [ 666.356057] usb 2-1: Product: TP-LINK HSPA+ Modem 17 [ 666.361086] usb 2-1: Manufacturer: TP-LINK, Incorporated 18 [ 666.366857] usb 2-1: SerialNumber: 863745011324437 19 [ 666.422189] option 2-1:1.0: GSM modem (1-port) converter detected 20 [ 666.448184] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0 21 [ 666.461670] option 2-1:1.1: GSM modem (1-port) converter detected 22 [ 666.488928] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1 23 [ 666.501318] usb-storage 2-1:1.2: USB Mass Storage device detected 24 [ 666.528750] scsi host13: usb-storage 2-1:1.2 25 [ 666.543441] option 2-1:1.3: GSM modem (1-port) converter detected 26 [ 666.573614] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2 27 [ 666.613559] qmi_wwan 2-1:1.4: cdc-wdm0: USB WDM device 28 [ 666.627262] qmi_wwan 2-1:1.4 wwan0: register 'qmi_wwan' at usb-musb-hdrc.1.auto-1, WWAN/QMI device, 22:2f:9a:72:2e:40 29 [ 667.542287] scsi 13:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 30 [ 667.588101] scsi 13:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 31 [ 667.653600] sd 13:0:0:1: [sda] Attached SCSI removable disk > interfaces in oder to get modem's configuration. And wwan closing > seems to produce this error. I could reproduce this behavior with > am335x-evmsk, Linux 4.5 (omap2plus_defconfig, CONFIG_USB_NET_CDC_MBIM, > CONFIG_USB_NET_QMI_WWAN and CONFIG_USB_SERIAL_OPTION) and Buildroot > with enabled ModemManager and libqmi support. > > Yegor -- 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
On Mon, Apr 4, 2016 at 8:45 PM, Bin Liu <b-liu@ti.com> wrote: > Yegor, > > On Mon, Apr 04, 2016 at 09:03:46AM +0200, Yegor Yefremov wrote: >> > >> > I'm using Debian 8 image with following usb_modeswitch: >> > >> > root@baltos:~# usb_modeswitch -e >> > >> > * usb_modeswitch: handle USB devices with multiple modes >> > * Version 2.2.0 (C) Josua Dietze 2014 >> > * Based on libusb1/libusbx >> > >> > ! PLEASE REPORT NEW CONFIGURATIONS ! >> > >> > Both 3.18.21 and 4.5.0 report following error after MA260 insertion: >> > >> > usb 1-1.2: new high-speed USB device number 3 using musb-hdrc >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=f000 >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated >> > usb 1-1.2: SerialNumber: 863745011099716 >> > usb-storage 1-1.2:1.0: USB Mass Storage device detected >> > scsi host0: usb-storage 1-1.2:1.0 >> > scsi 0:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > scsi 0:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > sd 0:0:0:1: [sda] Attached SCSI removable disk >> > usb 1-1.2: USB disconnect, device number 3 >> > usb 1-1.2: new high-speed USB device number 4 using musb-hdrc >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=9000 >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated >> > usb 1-1.2: SerialNumber: 863745011099716 >> > usb-storage 1-1.2:1.2: USB Mass Storage device detected >> > scsi host1: usb-storage 1-1.2:1.2 >> > qmi_wwan 1-1.2:1.4: cdc-wdm0: USB WDM device >> > qmi_wwan 1-1.2:1.4 wwan0: register 'qmi_wwan' at >> > usb-musb-hdrc.0.auto-1.2, WWAN/QMI device, de:ea:e8:d0:61:6c >> > usbcore: registered new interface driver option >> > usbserial: USB Serial support registered for GSM modem (1-port) >> > option 1-1.2:1.0: GSM modem (1-port) converter detected >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 >> > option 1-1.2:1.1: GSM modem (1-port) converter detected >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 >> > option 1-1.2:1.3: GSM modem (1-port) converter detected >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 >> > scsi 1:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > scsi 1:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > sd 1:0:0:1: [sda] Attached SCSI removable disk >> > ------------[ cut here ]------------ >> > WARNING: CPU: 0 PID: 1740 at drivers/usb/musb/musb_host.c:139 >> > musb_h_tx_flush_fifo+0xc4/0xe4() >> > musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >> > Modules linked in: option usb_wwan musb_dsps musb_am335x >> > CPU: 0 PID: 1740 Comm: ModemManager Not tainted 4.5.0 #1 >> > Hardware name: Generic AM33XX (Flattened Device Tree) >> > [<c0017ecc>] (unwind_backtrace) from [<c0014100>] (show_stack+0x10/0x14) >> > [<c0014100>] (show_stack) from [<c03cf384>] (dump_stack+0xb0/0xe4) >> > [<c03cf384>] (dump_stack) from [<c003bf68>] (warn_slowpath_common+0x7c/0xb8) >> > [<c003bf68>] (warn_slowpath_common) from [<c003bfd4>] >> > (warn_slowpath_fmt+0x30/0x40) >> > [<c003bfd4>] (warn_slowpath_fmt) from [<c0534c30>] >> > (musb_h_tx_flush_fifo+0xc4/0xe4) >> > [<c0534c30>] (musb_h_tx_flush_fifo) from [<c0535d74>] >> > (musb_cleanup_urb+0xbc/0x130) >> > [<c0535d74>] (musb_cleanup_urb) from [<c0536424>] (musb_urb_dequeue+0xf0/0x128) >> > [<c0536424>] (musb_urb_dequeue) from [<c050b98c>] (usb_hcd_unlink_urb+0x50/0x84) >> > [<c050b98c>] (usb_hcd_unlink_urb) from [<c050cbd0>] (usb_kill_urb+0x4c/0xc4) >> > [<c050cbd0>] (usb_kill_urb) from [<bf00e85c>] >> > (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >> > [<bf00e85c>] (usb_wwan_close [usb_wwan]) from [<c042d8e0>] >> > (tty_port_shutdown+0x90/0x9c) >> > [<c042d8e0>] (tty_port_shutdown) from [<c042dfd0>] (tty_port_close+0x24/0x4c) >> > [<c042dfd0>] (tty_port_close) from [<c0425f30>] (tty_release+0xec/0x474) >> > [<c0425f30>] (tty_release) from [<c0168b60>] (__fput+0x80/0x1d0) >> > [<c0168b60>] (__fput) from [<c005b944>] (task_work_run+0x90/0xc4) >> > [<c005b944>] (task_work_run) from [<c0013ac4>] (do_work_pending+0x8c/0xb4) >> > [<c0013ac4>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >> > ---[ end trace cbf0ee35fffa18d3 ]--- >> > >> > Debian image was created with these scripts: >> > https://github.com/visionsystemsgmbh/vsdebootstrap >> > Kernel config: https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/linux-3.15-config >> > >> > I've tried both usb1 channel and USB hub and usb2 channel directly. In >> > both cases I get this crash. >> >> I've made some more test and could at least find a software >> constellation, that produces this error. You'll need ModemManager and >> libqmi. As soon as ModemManager sees the modem it opens and closes its > > Are you sure it is ModemManager open/close the port? Or other app? Good question. At first I had a rootfs without ModemManager and libqmi and I had no tx errors, but as soon as I added ModemManager I got this issue. Will look more into it tomorrow. > In my debian rootfs, I did > > # apt-get install modemmanager libqmi-utils > > but it seems there is not open/close to the modem uart port. tx fifo > flush problem still does not happen to me. here is the enum log. > > 1 [ 663.745927] usb 2-1: new high-speed USB device number 14 using musb-hdrc > 2 [ 663.890525] usb 2-1: New USB device found, idVendor=2357, idProduct=f000 > 3 [ 663.897857] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > 4 [ 663.905462] usb 2-1: Product: TP-LINK HSPA+ Modem > 5 [ 663.910666] usb 2-1: Manufacturer: TP-LINK, Incorporated > 6 [ 663.916451] usb 2-1: SerialNumber: 863745011324437 > 7 [ 663.961261] usb-storage 2-1:1.0: USB Mass Storage device detected > 8 [ 663.996977] scsi host12: usb-storage 2-1:1.0 > 9 [ 664.999261] scsi 12:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > 10 [ 665.010298] scsi 12:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > 11 [ 665.059673] sd 12:0:0:1: [sda] Attached SCSI removable disk > 12 [ 665.699173] usb 2-1: USB disconnect, device number 14 > 13 [ 666.195929] usb 2-1: new high-speed USB device number 15 using musb-hdrc > 14 [ 666.340925] usb 2-1: New USB device found, idVendor=2357, idProduct=9000 > 15 [ 666.348258] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > 16 [ 666.356057] usb 2-1: Product: TP-LINK HSPA+ Modem > 17 [ 666.361086] usb 2-1: Manufacturer: TP-LINK, Incorporated > 18 [ 666.366857] usb 2-1: SerialNumber: 863745011324437 > 19 [ 666.422189] option 2-1:1.0: GSM modem (1-port) converter detected > 20 [ 666.448184] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0 > 21 [ 666.461670] option 2-1:1.1: GSM modem (1-port) converter detected > 22 [ 666.488928] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1 > 23 [ 666.501318] usb-storage 2-1:1.2: USB Mass Storage device detected > 24 [ 666.528750] scsi host13: usb-storage 2-1:1.2 > 25 [ 666.543441] option 2-1:1.3: GSM modem (1-port) converter detected > 26 [ 666.573614] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2 > 27 [ 666.613559] qmi_wwan 2-1:1.4: cdc-wdm0: USB WDM device > 28 [ 666.627262] qmi_wwan 2-1:1.4 wwan0: register 'qmi_wwan' at usb-musb-hdrc.1.auto-1, WWAN/QMI device, 22:2f:9a:72:2e:40 > 29 [ 667.542287] scsi 13:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > 30 [ 667.588101] scsi 13:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > 31 [ 667.653600] sd 13:0:0:1: [sda] Attached SCSI removable disk Could you post output from: mmcli -m 0 >> interfaces in oder to get modem's configuration. And wwan closing >> seems to produce this error. I could reproduce this behavior with >> am335x-evmsk, Linux 4.5 (omap2plus_defconfig, CONFIG_USB_NET_CDC_MBIM, >> CONFIG_USB_NET_QMI_WWAN and CONFIG_USB_SERIAL_OPTION) and Buildroot >> with enabled ModemManager and libqmi support. >> >> Yegor -- 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
On Mon, Apr 04, 2016 at 09:02:07PM +0200, Yegor Yefremov wrote: > On Mon, Apr 4, 2016 at 8:45 PM, Bin Liu <b-liu@ti.com> wrote: > > Yegor, > > > > On Mon, Apr 04, 2016 at 09:03:46AM +0200, Yegor Yefremov wrote: > >> > > >> > I'm using Debian 8 image with following usb_modeswitch: > >> > > >> > root@baltos:~# usb_modeswitch -e > >> > > >> > * usb_modeswitch: handle USB devices with multiple modes > >> > * Version 2.2.0 (C) Josua Dietze 2014 > >> > * Based on libusb1/libusbx > >> > > >> > ! PLEASE REPORT NEW CONFIGURATIONS ! > >> > > >> > Both 3.18.21 and 4.5.0 report following error after MA260 insertion: > >> > > >> > usb 1-1.2: new high-speed USB device number 3 using musb-hdrc > >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=f000 > >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem > >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > >> > usb 1-1.2: SerialNumber: 863745011099716 > >> > usb-storage 1-1.2:1.0: USB Mass Storage device detected > >> > scsi host0: usb-storage 1-1.2:1.0 > >> > scsi 0:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > >> > scsi 0:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > >> > sd 0:0:0:1: [sda] Attached SCSI removable disk > >> > usb 1-1.2: USB disconnect, device number 3 > >> > usb 1-1.2: new high-speed USB device number 4 using musb-hdrc > >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=9000 > >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem > >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > >> > usb 1-1.2: SerialNumber: 863745011099716 > >> > usb-storage 1-1.2:1.2: USB Mass Storage device detected > >> > scsi host1: usb-storage 1-1.2:1.2 > >> > qmi_wwan 1-1.2:1.4: cdc-wdm0: USB WDM device > >> > qmi_wwan 1-1.2:1.4 wwan0: register 'qmi_wwan' at > >> > usb-musb-hdrc.0.auto-1.2, WWAN/QMI device, de:ea:e8:d0:61:6c > >> > usbcore: registered new interface driver option > >> > usbserial: USB Serial support registered for GSM modem (1-port) > >> > option 1-1.2:1.0: GSM modem (1-port) converter detected > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 > >> > option 1-1.2:1.1: GSM modem (1-port) converter detected > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 > >> > option 1-1.2:1.3: GSM modem (1-port) converter detected > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 > >> > scsi 1:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > >> > scsi 1:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > >> > sd 1:0:0:1: [sda] Attached SCSI removable disk > >> > ------------[ cut here ]------------ > >> > WARNING: CPU: 0 PID: 1740 at drivers/usb/musb/musb_host.c:139 > >> > musb_h_tx_flush_fifo+0xc4/0xe4() > >> > musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > >> > Modules linked in: option usb_wwan musb_dsps musb_am335x > >> > CPU: 0 PID: 1740 Comm: ModemManager Not tainted 4.5.0 #1 > >> > Hardware name: Generic AM33XX (Flattened Device Tree) > >> > [<c0017ecc>] (unwind_backtrace) from [<c0014100>] (show_stack+0x10/0x14) > >> > [<c0014100>] (show_stack) from [<c03cf384>] (dump_stack+0xb0/0xe4) > >> > [<c03cf384>] (dump_stack) from [<c003bf68>] (warn_slowpath_common+0x7c/0xb8) > >> > [<c003bf68>] (warn_slowpath_common) from [<c003bfd4>] > >> > (warn_slowpath_fmt+0x30/0x40) > >> > [<c003bfd4>] (warn_slowpath_fmt) from [<c0534c30>] > >> > (musb_h_tx_flush_fifo+0xc4/0xe4) > >> > [<c0534c30>] (musb_h_tx_flush_fifo) from [<c0535d74>] > >> > (musb_cleanup_urb+0xbc/0x130) > >> > [<c0535d74>] (musb_cleanup_urb) from [<c0536424>] (musb_urb_dequeue+0xf0/0x128) > >> > [<c0536424>] (musb_urb_dequeue) from [<c050b98c>] (usb_hcd_unlink_urb+0x50/0x84) > >> > [<c050b98c>] (usb_hcd_unlink_urb) from [<c050cbd0>] (usb_kill_urb+0x4c/0xc4) > >> > [<c050cbd0>] (usb_kill_urb) from [<bf00e85c>] > >> > (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > >> > [<bf00e85c>] (usb_wwan_close [usb_wwan]) from [<c042d8e0>] > >> > (tty_port_shutdown+0x90/0x9c) > >> > [<c042d8e0>] (tty_port_shutdown) from [<c042dfd0>] (tty_port_close+0x24/0x4c) > >> > [<c042dfd0>] (tty_port_close) from [<c0425f30>] (tty_release+0xec/0x474) > >> > [<c0425f30>] (tty_release) from [<c0168b60>] (__fput+0x80/0x1d0) > >> > [<c0168b60>] (__fput) from [<c005b944>] (task_work_run+0x90/0xc4) > >> > [<c005b944>] (task_work_run) from [<c0013ac4>] (do_work_pending+0x8c/0xb4) > >> > [<c0013ac4>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > >> > ---[ end trace cbf0ee35fffa18d3 ]--- > >> > > >> > Debian image was created with these scripts: > >> > https://github.com/visionsystemsgmbh/vsdebootstrap > >> > Kernel config: https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/linux-3.15-config > >> > > >> > I've tried both usb1 channel and USB hub and usb2 channel directly. In > >> > both cases I get this crash. > >> > >> I've made some more test and could at least find a software > >> constellation, that produces this error. You'll need ModemManager and > >> libqmi. As soon as ModemManager sees the modem it opens and closes its > > > > Are you sure it is ModemManager open/close the port? Or other app? > > Good question. At first I had a rootfs without ModemManager and libqmi > and I had no tx errors, but as soon as I added ModemManager I got this > issue. Will look more into it tomorrow. > > > In my debian rootfs, I did > > > > # apt-get install modemmanager libqmi-utils > > > > but it seems there is not open/close to the modem uart port. tx fifo > > flush problem still does not happen to me. here is the enum log. > > > > 1 [ 663.745927] usb 2-1: new high-speed USB device number 14 using musb-hdrc > > 2 [ 663.890525] usb 2-1: New USB device found, idVendor=2357, idProduct=f000 > > 3 [ 663.897857] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > 4 [ 663.905462] usb 2-1: Product: TP-LINK HSPA+ Modem > > 5 [ 663.910666] usb 2-1: Manufacturer: TP-LINK, Incorporated > > 6 [ 663.916451] usb 2-1: SerialNumber: 863745011324437 > > 7 [ 663.961261] usb-storage 2-1:1.0: USB Mass Storage device detected > > 8 [ 663.996977] scsi host12: usb-storage 2-1:1.0 > > 9 [ 664.999261] scsi 12:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > 10 [ 665.010298] scsi 12:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > 11 [ 665.059673] sd 12:0:0:1: [sda] Attached SCSI removable disk > > 12 [ 665.699173] usb 2-1: USB disconnect, device number 14 > > 13 [ 666.195929] usb 2-1: new high-speed USB device number 15 using musb-hdrc > > 14 [ 666.340925] usb 2-1: New USB device found, idVendor=2357, idProduct=9000 > > 15 [ 666.348258] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > 16 [ 666.356057] usb 2-1: Product: TP-LINK HSPA+ Modem > > 17 [ 666.361086] usb 2-1: Manufacturer: TP-LINK, Incorporated > > 18 [ 666.366857] usb 2-1: SerialNumber: 863745011324437 > > 19 [ 666.422189] option 2-1:1.0: GSM modem (1-port) converter detected > > 20 [ 666.448184] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0 > > 21 [ 666.461670] option 2-1:1.1: GSM modem (1-port) converter detected > > 22 [ 666.488928] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1 > > 23 [ 666.501318] usb-storage 2-1:1.2: USB Mass Storage device detected > > 24 [ 666.528750] scsi host13: usb-storage 2-1:1.2 > > 25 [ 666.543441] option 2-1:1.3: GSM modem (1-port) converter detected > > 26 [ 666.573614] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2 > > 27 [ 666.613559] qmi_wwan 2-1:1.4: cdc-wdm0: USB WDM device > > 28 [ 666.627262] qmi_wwan 2-1:1.4 wwan0: register 'qmi_wwan' at usb-musb-hdrc.1.auto-1, WWAN/QMI device, 22:2f:9a:72:2e:40 > > 29 [ 667.542287] scsi 13:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > 30 [ 667.588101] scsi 13:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > 31 [ 667.653600] sd 13:0:0:1: [sda] Attached SCSI removable disk > > Could you post output from: > > mmcli -m 0 root@debian:~# mmcli -m 0 error: couldn't get bus: Could not connect: No such file or directory root@debian:~# mmcli -L error: couldn't get bus: Could not connect: No such file or directory Seems like I miss something in my rootfs? -- 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
On Mon, Apr 04, 2016 at 02:12:32PM -0500, Bin Liu wrote: > On Mon, Apr 04, 2016 at 09:02:07PM +0200, Yegor Yefremov wrote: > > On Mon, Apr 4, 2016 at 8:45 PM, Bin Liu <b-liu@ti.com> wrote: > > > Yegor, > > > > > > On Mon, Apr 04, 2016 at 09:03:46AM +0200, Yegor Yefremov wrote: > > >> > > > >> > I'm using Debian 8 image with following usb_modeswitch: > > >> > > > >> > root@baltos:~# usb_modeswitch -e > > >> > > > >> > * usb_modeswitch: handle USB devices with multiple modes > > >> > * Version 2.2.0 (C) Josua Dietze 2014 > > >> > * Based on libusb1/libusbx > > >> > > > >> > ! PLEASE REPORT NEW CONFIGURATIONS ! > > >> > > > >> > Both 3.18.21 and 4.5.0 report following error after MA260 insertion: > > >> > > > >> > usb 1-1.2: new high-speed USB device number 3 using musb-hdrc > > >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=f000 > > >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem > > >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > > >> > usb 1-1.2: SerialNumber: 863745011099716 > > >> > usb-storage 1-1.2:1.0: USB Mass Storage device detected > > >> > scsi host0: usb-storage 1-1.2:1.0 > > >> > scsi 0:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > >> > scsi 0:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > >> > sd 0:0:0:1: [sda] Attached SCSI removable disk > > >> > usb 1-1.2: USB disconnect, device number 3 > > >> > usb 1-1.2: new high-speed USB device number 4 using musb-hdrc > > >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=9000 > > >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem > > >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated > > >> > usb 1-1.2: SerialNumber: 863745011099716 > > >> > usb-storage 1-1.2:1.2: USB Mass Storage device detected > > >> > scsi host1: usb-storage 1-1.2:1.2 > > >> > qmi_wwan 1-1.2:1.4: cdc-wdm0: USB WDM device > > >> > qmi_wwan 1-1.2:1.4 wwan0: register 'qmi_wwan' at > > >> > usb-musb-hdrc.0.auto-1.2, WWAN/QMI device, de:ea:e8:d0:61:6c > > >> > usbcore: registered new interface driver option > > >> > usbserial: USB Serial support registered for GSM modem (1-port) > > >> > option 1-1.2:1.0: GSM modem (1-port) converter detected > > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 > > >> > option 1-1.2:1.1: GSM modem (1-port) converter detected > > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 > > >> > option 1-1.2:1.3: GSM modem (1-port) converter detected > > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 > > >> > scsi 1:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > >> > scsi 1:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > >> > sd 1:0:0:1: [sda] Attached SCSI removable disk > > >> > ------------[ cut here ]------------ > > >> > WARNING: CPU: 0 PID: 1740 at drivers/usb/musb/musb_host.c:139 > > >> > musb_h_tx_flush_fifo+0xc4/0xe4() > > >> > musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 > > >> > Modules linked in: option usb_wwan musb_dsps musb_am335x > > >> > CPU: 0 PID: 1740 Comm: ModemManager Not tainted 4.5.0 #1 > > >> > Hardware name: Generic AM33XX (Flattened Device Tree) > > >> > [<c0017ecc>] (unwind_backtrace) from [<c0014100>] (show_stack+0x10/0x14) > > >> > [<c0014100>] (show_stack) from [<c03cf384>] (dump_stack+0xb0/0xe4) > > >> > [<c03cf384>] (dump_stack) from [<c003bf68>] (warn_slowpath_common+0x7c/0xb8) > > >> > [<c003bf68>] (warn_slowpath_common) from [<c003bfd4>] > > >> > (warn_slowpath_fmt+0x30/0x40) > > >> > [<c003bfd4>] (warn_slowpath_fmt) from [<c0534c30>] > > >> > (musb_h_tx_flush_fifo+0xc4/0xe4) > > >> > [<c0534c30>] (musb_h_tx_flush_fifo) from [<c0535d74>] > > >> > (musb_cleanup_urb+0xbc/0x130) > > >> > [<c0535d74>] (musb_cleanup_urb) from [<c0536424>] (musb_urb_dequeue+0xf0/0x128) > > >> > [<c0536424>] (musb_urb_dequeue) from [<c050b98c>] (usb_hcd_unlink_urb+0x50/0x84) > > >> > [<c050b98c>] (usb_hcd_unlink_urb) from [<c050cbd0>] (usb_kill_urb+0x4c/0xc4) > > >> > [<c050cbd0>] (usb_kill_urb) from [<bf00e85c>] > > >> > (usb_wwan_close+0xbc/0xf0 [usb_wwan]) > > >> > [<bf00e85c>] (usb_wwan_close [usb_wwan]) from [<c042d8e0>] > > >> > (tty_port_shutdown+0x90/0x9c) > > >> > [<c042d8e0>] (tty_port_shutdown) from [<c042dfd0>] (tty_port_close+0x24/0x4c) > > >> > [<c042dfd0>] (tty_port_close) from [<c0425f30>] (tty_release+0xec/0x474) > > >> > [<c0425f30>] (tty_release) from [<c0168b60>] (__fput+0x80/0x1d0) > > >> > [<c0168b60>] (__fput) from [<c005b944>] (task_work_run+0x90/0xc4) > > >> > [<c005b944>] (task_work_run) from [<c0013ac4>] (do_work_pending+0x8c/0xb4) > > >> > [<c0013ac4>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) > > >> > ---[ end trace cbf0ee35fffa18d3 ]--- > > >> > > > >> > Debian image was created with these scripts: > > >> > https://github.com/visionsystemsgmbh/vsdebootstrap > > >> > Kernel config: https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/linux-3.15-config > > >> > > > >> > I've tried both usb1 channel and USB hub and usb2 channel directly. In > > >> > both cases I get this crash. > > >> > > >> I've made some more test and could at least find a software > > >> constellation, that produces this error. You'll need ModemManager and > > >> libqmi. As soon as ModemManager sees the modem it opens and closes its > > > > > > Are you sure it is ModemManager open/close the port? Or other app? > > > > Good question. At first I had a rootfs without ModemManager and libqmi > > and I had no tx errors, but as soon as I added ModemManager I got this > > issue. Will look more into it tomorrow. > > > > > In my debian rootfs, I did > > > > > > # apt-get install modemmanager libqmi-utils > > > > > > but it seems there is not open/close to the modem uart port. tx fifo > > > flush problem still does not happen to me. here is the enum log. > > > > > > 1 [ 663.745927] usb 2-1: new high-speed USB device number 14 using musb-hdrc > > > 2 [ 663.890525] usb 2-1: New USB device found, idVendor=2357, idProduct=f000 > > > 3 [ 663.897857] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > > 4 [ 663.905462] usb 2-1: Product: TP-LINK HSPA+ Modem > > > 5 [ 663.910666] usb 2-1: Manufacturer: TP-LINK, Incorporated > > > 6 [ 663.916451] usb 2-1: SerialNumber: 863745011324437 > > > 7 [ 663.961261] usb-storage 2-1:1.0: USB Mass Storage device detected > > > 8 [ 663.996977] scsi host12: usb-storage 2-1:1.0 > > > 9 [ 664.999261] scsi 12:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > > 10 [ 665.010298] scsi 12:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > > 11 [ 665.059673] sd 12:0:0:1: [sda] Attached SCSI removable disk > > > 12 [ 665.699173] usb 2-1: USB disconnect, device number 14 > > > 13 [ 666.195929] usb 2-1: new high-speed USB device number 15 using musb-hdrc > > > 14 [ 666.340925] usb 2-1: New USB device found, idVendor=2357, idProduct=9000 > > > 15 [ 666.348258] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 > > > 16 [ 666.356057] usb 2-1: Product: TP-LINK HSPA+ Modem > > > 17 [ 666.361086] usb 2-1: Manufacturer: TP-LINK, Incorporated > > > 18 [ 666.366857] usb 2-1: SerialNumber: 863745011324437 > > > 19 [ 666.422189] option 2-1:1.0: GSM modem (1-port) converter detected > > > 20 [ 666.448184] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0 > > > 21 [ 666.461670] option 2-1:1.1: GSM modem (1-port) converter detected > > > 22 [ 666.488928] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1 > > > 23 [ 666.501318] usb-storage 2-1:1.2: USB Mass Storage device detected > > > 24 [ 666.528750] scsi host13: usb-storage 2-1:1.2 > > > 25 [ 666.543441] option 2-1:1.3: GSM modem (1-port) converter detected > > > 26 [ 666.573614] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2 > > > 27 [ 666.613559] qmi_wwan 2-1:1.4: cdc-wdm0: USB WDM device > > > 28 [ 666.627262] qmi_wwan 2-1:1.4 wwan0: register 'qmi_wwan' at usb-musb-hdrc.1.auto-1, WWAN/QMI device, 22:2f:9a:72:2e:40 > > > 29 [ 667.542287] scsi 13:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > > 30 [ 667.588101] scsi 13:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 > > > 31 [ 667.653600] sd 13:0:0:1: [sda] Attached SCSI removable disk > > > > Could you post output from: > > > > mmcli -m 0 > > root@debian:~# mmcli -m 0 > error: couldn't get bus: Could not connect: No such file or directory > > root@debian:~# mmcli -L > error: couldn't get bus: Could not connect: No such file or directory > > Seems like I miss something in my rootfs? > Ok, missing 'dbus' package. I am able to see the issue now. Does your modem still functional after the fifo flush issue? I am not familiar with modem. Regards, -Bin. -- 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
On Mon, Apr 4, 2016 at 9:36 PM, Bin Liu <b-liu@ti.com> wrote: > On Mon, Apr 04, 2016 at 02:12:32PM -0500, Bin Liu wrote: >> On Mon, Apr 04, 2016 at 09:02:07PM +0200, Yegor Yefremov wrote: >> > On Mon, Apr 4, 2016 at 8:45 PM, Bin Liu <b-liu@ti.com> wrote: >> > > Yegor, >> > > >> > > On Mon, Apr 04, 2016 at 09:03:46AM +0200, Yegor Yefremov wrote: >> > >> > >> > >> > I'm using Debian 8 image with following usb_modeswitch: >> > >> > >> > >> > root@baltos:~# usb_modeswitch -e >> > >> > >> > >> > * usb_modeswitch: handle USB devices with multiple modes >> > >> > * Version 2.2.0 (C) Josua Dietze 2014 >> > >> > * Based on libusb1/libusbx >> > >> > >> > >> > ! PLEASE REPORT NEW CONFIGURATIONS ! >> > >> > >> > >> > Both 3.18.21 and 4.5.0 report following error after MA260 insertion: >> > >> > >> > >> > usb 1-1.2: new high-speed USB device number 3 using musb-hdrc >> > >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=f000 >> > >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 >> > >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem >> > >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated >> > >> > usb 1-1.2: SerialNumber: 863745011099716 >> > >> > usb-storage 1-1.2:1.0: USB Mass Storage device detected >> > >> > scsi host0: usb-storage 1-1.2:1.0 >> > >> > scsi 0:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > >> > scsi 0:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > >> > sd 0:0:0:1: [sda] Attached SCSI removable disk >> > >> > usb 1-1.2: USB disconnect, device number 3 >> > >> > usb 1-1.2: new high-speed USB device number 4 using musb-hdrc >> > >> > usb 1-1.2: New USB device found, idVendor=2357, idProduct=9000 >> > >> > usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4 >> > >> > usb 1-1.2: Product: TP-LINK HSPA+ Modem >> > >> > usb 1-1.2: Manufacturer: TP-LINK, Incorporated >> > >> > usb 1-1.2: SerialNumber: 863745011099716 >> > >> > usb-storage 1-1.2:1.2: USB Mass Storage device detected >> > >> > scsi host1: usb-storage 1-1.2:1.2 >> > >> > qmi_wwan 1-1.2:1.4: cdc-wdm0: USB WDM device >> > >> > qmi_wwan 1-1.2:1.4 wwan0: register 'qmi_wwan' at >> > >> > usb-musb-hdrc.0.auto-1.2, WWAN/QMI device, de:ea:e8:d0:61:6c >> > >> > usbcore: registered new interface driver option >> > >> > usbserial: USB Serial support registered for GSM modem (1-port) >> > >> > option 1-1.2:1.0: GSM modem (1-port) converter detected >> > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB0 >> > >> > option 1-1.2:1.1: GSM modem (1-port) converter detected >> > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB1 >> > >> > option 1-1.2:1.3: GSM modem (1-port) converter detected >> > >> > usb 1-1.2: GSM modem (1-port) converter now attached to ttyUSB2 >> > >> > scsi 1:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > >> > scsi 1:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > >> > sd 1:0:0:1: [sda] Attached SCSI removable disk >> > >> > ------------[ cut here ]------------ >> > >> > WARNING: CPU: 0 PID: 1740 at drivers/usb/musb/musb_host.c:139 >> > >> > musb_h_tx_flush_fifo+0xc4/0xe4() >> > >> > musb-hdrc musb-hdrc.0.auto: Could not flush host TX2 fifo: csr: 2403 >> > >> > Modules linked in: option usb_wwan musb_dsps musb_am335x >> > >> > CPU: 0 PID: 1740 Comm: ModemManager Not tainted 4.5.0 #1 >> > >> > Hardware name: Generic AM33XX (Flattened Device Tree) >> > >> > [<c0017ecc>] (unwind_backtrace) from [<c0014100>] (show_stack+0x10/0x14) >> > >> > [<c0014100>] (show_stack) from [<c03cf384>] (dump_stack+0xb0/0xe4) >> > >> > [<c03cf384>] (dump_stack) from [<c003bf68>] (warn_slowpath_common+0x7c/0xb8) >> > >> > [<c003bf68>] (warn_slowpath_common) from [<c003bfd4>] >> > >> > (warn_slowpath_fmt+0x30/0x40) >> > >> > [<c003bfd4>] (warn_slowpath_fmt) from [<c0534c30>] >> > >> > (musb_h_tx_flush_fifo+0xc4/0xe4) >> > >> > [<c0534c30>] (musb_h_tx_flush_fifo) from [<c0535d74>] >> > >> > (musb_cleanup_urb+0xbc/0x130) >> > >> > [<c0535d74>] (musb_cleanup_urb) from [<c0536424>] (musb_urb_dequeue+0xf0/0x128) >> > >> > [<c0536424>] (musb_urb_dequeue) from [<c050b98c>] (usb_hcd_unlink_urb+0x50/0x84) >> > >> > [<c050b98c>] (usb_hcd_unlink_urb) from [<c050cbd0>] (usb_kill_urb+0x4c/0xc4) >> > >> > [<c050cbd0>] (usb_kill_urb) from [<bf00e85c>] >> > >> > (usb_wwan_close+0xbc/0xf0 [usb_wwan]) >> > >> > [<bf00e85c>] (usb_wwan_close [usb_wwan]) from [<c042d8e0>] >> > >> > (tty_port_shutdown+0x90/0x9c) >> > >> > [<c042d8e0>] (tty_port_shutdown) from [<c042dfd0>] (tty_port_close+0x24/0x4c) >> > >> > [<c042dfd0>] (tty_port_close) from [<c0425f30>] (tty_release+0xec/0x474) >> > >> > [<c0425f30>] (tty_release) from [<c0168b60>] (__fput+0x80/0x1d0) >> > >> > [<c0168b60>] (__fput) from [<c005b944>] (task_work_run+0x90/0xc4) >> > >> > [<c005b944>] (task_work_run) from [<c0013ac4>] (do_work_pending+0x8c/0xb4) >> > >> > [<c0013ac4>] (do_work_pending) from [<c000f8e8>] (slow_work_pending+0xc/0x20) >> > >> > ---[ end trace cbf0ee35fffa18d3 ]--- >> > >> > >> > >> > Debian image was created with these scripts: >> > >> > https://github.com/visionsystemsgmbh/vsdebootstrap >> > >> > Kernel config: https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/linux-3.15-config >> > >> > >> > >> > I've tried both usb1 channel and USB hub and usb2 channel directly. In >> > >> > both cases I get this crash. >> > >> >> > >> I've made some more test and could at least find a software >> > >> constellation, that produces this error. You'll need ModemManager and >> > >> libqmi. As soon as ModemManager sees the modem it opens and closes its >> > > >> > > Are you sure it is ModemManager open/close the port? Or other app? >> > >> > Good question. At first I had a rootfs without ModemManager and libqmi >> > and I had no tx errors, but as soon as I added ModemManager I got this >> > issue. Will look more into it tomorrow. >> > >> > > In my debian rootfs, I did >> > > >> > > # apt-get install modemmanager libqmi-utils >> > > >> > > but it seems there is not open/close to the modem uart port. tx fifo >> > > flush problem still does not happen to me. here is the enum log. >> > > >> > > 1 [ 663.745927] usb 2-1: new high-speed USB device number 14 using musb-hdrc >> > > 2 [ 663.890525] usb 2-1: New USB device found, idVendor=2357, idProduct=f000 >> > > 3 [ 663.897857] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 >> > > 4 [ 663.905462] usb 2-1: Product: TP-LINK HSPA+ Modem >> > > 5 [ 663.910666] usb 2-1: Manufacturer: TP-LINK, Incorporated >> > > 6 [ 663.916451] usb 2-1: SerialNumber: 863745011324437 >> > > 7 [ 663.961261] usb-storage 2-1:1.0: USB Mass Storage device detected >> > > 8 [ 663.996977] scsi host12: usb-storage 2-1:1.0 >> > > 9 [ 664.999261] scsi 12:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > > 10 [ 665.010298] scsi 12:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > > 11 [ 665.059673] sd 12:0:0:1: [sda] Attached SCSI removable disk >> > > 12 [ 665.699173] usb 2-1: USB disconnect, device number 14 >> > > 13 [ 666.195929] usb 2-1: new high-speed USB device number 15 using musb-hdrc >> > > 14 [ 666.340925] usb 2-1: New USB device found, idVendor=2357, idProduct=9000 >> > > 15 [ 666.348258] usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4 >> > > 16 [ 666.356057] usb 2-1: Product: TP-LINK HSPA+ Modem >> > > 17 [ 666.361086] usb 2-1: Manufacturer: TP-LINK, Incorporated >> > > 18 [ 666.366857] usb 2-1: SerialNumber: 863745011324437 >> > > 19 [ 666.422189] option 2-1:1.0: GSM modem (1-port) converter detected >> > > 20 [ 666.448184] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0 >> > > 21 [ 666.461670] option 2-1:1.1: GSM modem (1-port) converter detected >> > > 22 [ 666.488928] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1 >> > > 23 [ 666.501318] usb-storage 2-1:1.2: USB Mass Storage device detected >> > > 24 [ 666.528750] scsi host13: usb-storage 2-1:1.2 >> > > 25 [ 666.543441] option 2-1:1.3: GSM modem (1-port) converter detected >> > > 26 [ 666.573614] usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2 >> > > 27 [ 666.613559] qmi_wwan 2-1:1.4: cdc-wdm0: USB WDM device >> > > 28 [ 666.627262] qmi_wwan 2-1:1.4 wwan0: register 'qmi_wwan' at usb-musb-hdrc.1.auto-1, WWAN/QMI device, 22:2f:9a:72:2e:40 >> > > 29 [ 667.542287] scsi 13:0:0:0: CD-ROM TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > > 30 [ 667.588101] scsi 13:0:0:1: Direct-Access TP-LINK MMC Storage 2.31 PQ: 0 ANSI: 2 >> > > 31 [ 667.653600] sd 13:0:0:1: [sda] Attached SCSI removable disk >> > >> > Could you post output from: >> > >> > mmcli -m 0 >> >> root@debian:~# mmcli -m 0 >> error: couldn't get bus: Could not connect: No such file or directory >> >> root@debian:~# mmcli -L >> error: couldn't get bus: Could not connect: No such file or directory >> >> Seems like I miss something in my rootfs? >> > > Ok, missing 'dbus' package. I am able to see the issue now. Does your > modem still functional after the fifo flush issue? I am not familiar > with modem. Can Modemmanager find your SIM card? mmcli -m 0 | grep SIM SIM | path: '/org/freedesktop/ModemManager1/SIM/0' My Huawei E353 has no problems with finding it, but MA260. So I cannot really try it. AT interface is still functioning, but I can't check, if qmi one is working. -- 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
Yegor, On Tue, Apr 05, 2016 at 08:16:27AM +0200, Yegor Yefremov wrote: > >> > > >> > Could you post output from: > >> > > >> > mmcli -m 0 > >> > >> root@debian:~# mmcli -m 0 > >> error: couldn't get bus: Could not connect: No such file or directory > >> > >> root@debian:~# mmcli -L > >> error: couldn't get bus: Could not connect: No such file or directory > >> > >> Seems like I miss something in my rootfs? > >> > > > > Ok, missing 'dbus' package. I am able to see the issue now. Does your > > modem still functional after the fifo flush issue? I am not familiar > > with modem. > > Can Modemmanager find your SIM card? mmcli -m 0 | grep SIM > > SIM | path: '/org/freedesktop/ModemManager1/SIM/0' > > My Huawei E353 has no problems with finding it, but MA260. So I cannot > really try it. AT interface is still functioning, but I can't check, > if qmi one is working. Here is what I found with two modems including MA260. Right after booted the board and connected the modem, tx fifo flush problem happens, but 'mmcli -m 0' _can_ find the SIM card. Now remove the modem then plug it again, fifo flush problem does not happen at this time, but 'mmcli -m 0' is unable to find the SIM card anymore, with the following error. error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0' I also tried the same procedure with a xHCI controller, the behavoir is the same - in very first enumeration mmcli can find SIM, but does not since the second time. So I would think the finding SIM card problem since second enumeration is not related to musb tx fifo flush issue. Regards, -Bin. -- 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
On Tue, Apr 5, 2016 at 4:09 PM, Bin Liu <b-liu@ti.com> wrote: > Yegor, > > On Tue, Apr 05, 2016 at 08:16:27AM +0200, Yegor Yefremov wrote: >> >> > >> >> > Could you post output from: >> >> > >> >> > mmcli -m 0 >> >> >> >> root@debian:~# mmcli -m 0 >> >> error: couldn't get bus: Could not connect: No such file or directory >> >> >> >> root@debian:~# mmcli -L >> >> error: couldn't get bus: Could not connect: No such file or directory >> >> >> >> Seems like I miss something in my rootfs? >> >> >> > >> > Ok, missing 'dbus' package. I am able to see the issue now. Does your >> > modem still functional after the fifo flush issue? I am not familiar >> > with modem. >> >> Can Modemmanager find your SIM card? mmcli -m 0 | grep SIM >> >> SIM | path: '/org/freedesktop/ModemManager1/SIM/0' >> >> My Huawei E353 has no problems with finding it, but MA260. So I cannot >> really try it. AT interface is still functioning, but I can't check, >> if qmi one is working. > > Here is what I found with two modems including MA260. Right after booted > the board and connected the modem, tx fifo flush problem happens, but > 'mmcli -m 0' _can_ find the SIM card. I think I have physical problem with my SIM card. It is a micro SIM in a plastic adapter. I think it is a little bit higher, than in the original adapter, that is now broken. E353 seems to have better contacts. > Now remove the modem then plug it again, fifo flush problem does not > happen at this time, but 'mmcli -m 0' is unable to find the SIM card > anymore, with the following error. > > error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0' ModemManager counts modem high, so that after you replug it you'll have it at 1 mmcli -m 1 You can check the number via mmcli -L > I also tried the same procedure with a xHCI controller, the behavoir is > the same - in very first enumeration mmcli can find SIM, but does not > since the second time. > > So I would think the finding SIM card problem since second enumeration > is not related to musb tx fifo flush issue. Yegor -- 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
On Tue, Apr 05, 2016 at 06:35:36PM +0200, Yegor Yefremov wrote: > On Tue, Apr 5, 2016 at 4:09 PM, Bin Liu <b-liu@ti.com> wrote: > > Yegor, > > > > On Tue, Apr 05, 2016 at 08:16:27AM +0200, Yegor Yefremov wrote: > >> >> > > >> >> > Could you post output from: > >> >> > > >> >> > mmcli -m 0 > >> >> > >> >> root@debian:~# mmcli -m 0 > >> >> error: couldn't get bus: Could not connect: No such file or directory > >> >> > >> >> root@debian:~# mmcli -L > >> >> error: couldn't get bus: Could not connect: No such file or directory > >> >> > >> >> Seems like I miss something in my rootfs? > >> >> > >> > > >> > Ok, missing 'dbus' package. I am able to see the issue now. Does your > >> > modem still functional after the fifo flush issue? I am not familiar > >> > with modem. > >> > >> Can Modemmanager find your SIM card? mmcli -m 0 | grep SIM > >> > >> SIM | path: '/org/freedesktop/ModemManager1/SIM/0' > >> > >> My Huawei E353 has no problems with finding it, but MA260. So I cannot > >> really try it. AT interface is still functioning, but I can't check, > >> if qmi one is working. > > > > Here is what I found with two modems including MA260. Right after booted > > the board and connected the modem, tx fifo flush problem happens, but > > 'mmcli -m 0' _can_ find the SIM card. > > I think I have physical problem with my SIM card. It is a micro SIM in > a plastic adapter. I think it is a little bit higher, than in the > original adapter, that is now broken. E353 seems to have better > contacts. > > > Now remove the modem then plug it again, fifo flush problem does not > > happen at this time, but 'mmcli -m 0' is unable to find the SIM card > > anymore, with the following error. > > > > error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0' > > ModemManager counts modem high, so that after you replug it you'll have it at 1 > > mmcli -m 1 > > You can check the number via > > mmcli -L Thanks for the tip. Yes, mmcli can aleays find the SIM card. -- 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
On Tue, Apr 5, 2016 at 7:58 PM, Bin Liu <b-liu@ti.com> wrote: > On Tue, Apr 05, 2016 at 06:35:36PM +0200, Yegor Yefremov wrote: >> On Tue, Apr 5, 2016 at 4:09 PM, Bin Liu <b-liu@ti.com> wrote: >> > Yegor, >> > >> > On Tue, Apr 05, 2016 at 08:16:27AM +0200, Yegor Yefremov wrote: >> >> >> > >> >> >> > Could you post output from: >> >> >> > >> >> >> > mmcli -m 0 >> >> >> >> >> >> root@debian:~# mmcli -m 0 >> >> >> error: couldn't get bus: Could not connect: No such file or directory >> >> >> >> >> >> root@debian:~# mmcli -L >> >> >> error: couldn't get bus: Could not connect: No such file or directory >> >> >> >> >> >> Seems like I miss something in my rootfs? >> >> >> >> >> > >> >> > Ok, missing 'dbus' package. I am able to see the issue now. Does your >> >> > modem still functional after the fifo flush issue? I am not familiar >> >> > with modem. >> >> >> >> Can Modemmanager find your SIM card? mmcli -m 0 | grep SIM >> >> >> >> SIM | path: '/org/freedesktop/ModemManager1/SIM/0' >> >> >> >> My Huawei E353 has no problems with finding it, but MA260. So I cannot >> >> really try it. AT interface is still functioning, but I can't check, >> >> if qmi one is working. >> > >> > Here is what I found with two modems including MA260. Right after booted >> > the board and connected the modem, tx fifo flush problem happens, but >> > 'mmcli -m 0' _can_ find the SIM card. >> >> I think I have physical problem with my SIM card. It is a micro SIM in >> a plastic adapter. I think it is a little bit higher, than in the >> original adapter, that is now broken. E353 seems to have better >> contacts. >> >> > Now remove the modem then plug it again, fifo flush problem does not >> > happen at this time, but 'mmcli -m 0' is unable to find the SIM card >> > anymore, with the following error. >> > >> > error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0' >> >> ModemManager counts modem high, so that after you replug it you'll have it at 1 >> >> mmcli -m 1 >> >> You can check the number via >> >> mmcli -L > > Thanks for the tip. Yes, mmcli can aleays find the SIM card. I've got SIM7100E card working with ModemManager. It also provokes the same tx fifo error, but wwan0 is working afterwards. At least I could make a connection, get IP address over DHCP and ping an URL. mmcli -m 0 --simple-connect="apn=internet.eplus.de" -- 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
On Wed, Apr 06, 2016 at 11:53:26AM +0200, Yegor Yefremov wrote: > > Thanks for the tip. Yes, mmcli can aleays find the SIM card. > > I've got SIM7100E card working with ModemManager. It also provokes the > same tx fifo error, but wwan0 is working afterwards. At least I could > make a connection, get IP address over DHCP and ping an URL. > > mmcli -m 0 --simple-connect="apn=internet.eplus.de" So this tx fifo flush warning can be ignored, right? -- 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
On Wed, Apr 6, 2016 at 3:09 PM, Bin Liu <b-liu@ti.com> wrote: > On Wed, Apr 06, 2016 at 11:53:26AM +0200, Yegor Yefremov wrote: >> > Thanks for the tip. Yes, mmcli can aleays find the SIM card. >> >> I've got SIM7100E card working with ModemManager. It also provokes the >> same tx fifo error, but wwan0 is working afterwards. At least I could >> make a connection, get IP address over DHCP and ping an URL. >> >> mmcli -m 0 --simple-connect="apn=internet.eplus.de" > > So this tx fifo flush warning can be ignored, right? This is difficult to say. Could you make a connection with MA260? And I must also make a test with HackRF hardware. I'll let you know, as soon as I've tested it. Do you have an idea, how one can fix this nevertheless? -- 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
On Wed, Apr 06, 2016 at 03:17:48PM +0200, Yegor Yefremov wrote: > On Wed, Apr 6, 2016 at 3:09 PM, Bin Liu <b-liu@ti.com> wrote: > > On Wed, Apr 06, 2016 at 11:53:26AM +0200, Yegor Yefremov wrote: > >> > Thanks for the tip. Yes, mmcli can aleays find the SIM card. > >> > >> I've got SIM7100E card working with ModemManager. It also provokes the > >> same tx fifo error, but wwan0 is working afterwards. At least I could > >> make a connection, get IP address over DHCP and ping an URL. > >> > >> mmcli -m 0 --simple-connect="apn=internet.eplus.de" > > > > So this tx fifo flush warning can be ignored, right? > > This is difficult to say. Could you make a connection with MA260? And > I must also make a test with HackRF hardware. I'll let you know, as > soon as I've tested it. > > Do you have an idea, how one can fix this nevertheless? No. As Felipe mentioned in this thread earlier, we don't get much help from the MUSB document. Unless this issue caused any functional problem, I wouldn't spend more time on it. Regards, -Bin. -- 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
On Wed, Apr 6, 2016 at 3:26 PM, Bin Liu <b-liu@ti.com> wrote: > On Wed, Apr 06, 2016 at 03:17:48PM +0200, Yegor Yefremov wrote: >> On Wed, Apr 6, 2016 at 3:09 PM, Bin Liu <b-liu@ti.com> wrote: >> > On Wed, Apr 06, 2016 at 11:53:26AM +0200, Yegor Yefremov wrote: >> >> > Thanks for the tip. Yes, mmcli can aleays find the SIM card. >> >> >> >> I've got SIM7100E card working with ModemManager. It also provokes the >> >> same tx fifo error, but wwan0 is working afterwards. At least I could >> >> make a connection, get IP address over DHCP and ping an URL. >> >> >> >> mmcli -m 0 --simple-connect="apn=internet.eplus.de" >> > >> > So this tx fifo flush warning can be ignored, right? >> >> This is difficult to say. Could you make a connection with MA260? And >> I must also make a test with HackRF hardware. I'll let you know, as >> soon as I've tested it. >> >> Do you have an idea, how one can fix this nevertheless? > > No. As Felipe mentioned in this thread earlier, we don't get much help > from the MUSB document. Unless this issue caused any functional problem, > I wouldn't spend more time on it. What should we do with the warning message? It will make users worry about the system. Could you then look at the freeze issue with removing FTDI device during it is working? -- 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
On Wed, Apr 06, 2016 at 03:35:41PM +0200, Yegor Yefremov wrote: > On Wed, Apr 6, 2016 at 3:26 PM, Bin Liu <b-liu@ti.com> wrote: > > On Wed, Apr 06, 2016 at 03:17:48PM +0200, Yegor Yefremov wrote: > >> On Wed, Apr 6, 2016 at 3:09 PM, Bin Liu <b-liu@ti.com> wrote: > >> > On Wed, Apr 06, 2016 at 11:53:26AM +0200, Yegor Yefremov wrote: > >> >> > Thanks for the tip. Yes, mmcli can aleays find the SIM card. > >> >> > >> >> I've got SIM7100E card working with ModemManager. It also provokes the > >> >> same tx fifo error, but wwan0 is working afterwards. At least I could > >> >> make a connection, get IP address over DHCP and ping an URL. > >> >> > >> >> mmcli -m 0 --simple-connect="apn=internet.eplus.de" > >> > > >> > So this tx fifo flush warning can be ignored, right? > >> > >> This is difficult to say. Could you make a connection with MA260? And > >> I must also make a test with HackRF hardware. I'll let you know, as > >> soon as I've tested it. > >> > >> Do you have an idea, how one can fix this nevertheless? > > > > No. As Felipe mentioned in this thread earlier, we don't get much help > > from the MUSB document. Unless this issue caused any functional problem, > > I wouldn't spend more time on it. > > What should we do with the warning message? It will make users worry > about the system. We decided to use WARN() until we have enuogh data to conclude the flush error does not break any function. But we are not there yet. > > Could you then look at the freeze issue with removing FTDI device > during it is working? I can. I will have to first locate a FT4243H device. -- 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
On Wed, Apr 6, 2016 at 5:02 PM, Bin Liu <b-liu@ti.com> wrote: > On Wed, Apr 06, 2016 at 03:35:41PM +0200, Yegor Yefremov wrote: >> On Wed, Apr 6, 2016 at 3:26 PM, Bin Liu <b-liu@ti.com> wrote: >> > On Wed, Apr 06, 2016 at 03:17:48PM +0200, Yegor Yefremov wrote: >> >> On Wed, Apr 6, 2016 at 3:09 PM, Bin Liu <b-liu@ti.com> wrote: >> >> > On Wed, Apr 06, 2016 at 11:53:26AM +0200, Yegor Yefremov wrote: >> >> >> > Thanks for the tip. Yes, mmcli can aleays find the SIM card. >> >> >> >> >> >> I've got SIM7100E card working with ModemManager. It also provokes the >> >> >> same tx fifo error, but wwan0 is working afterwards. At least I could >> >> >> make a connection, get IP address over DHCP and ping an URL. >> >> >> >> >> >> mmcli -m 0 --simple-connect="apn=internet.eplus.de" >> >> > >> >> > So this tx fifo flush warning can be ignored, right? >> >> >> >> This is difficult to say. Could you make a connection with MA260? And >> >> I must also make a test with HackRF hardware. I'll let you know, as >> >> soon as I've tested it. >> >> >> >> Do you have an idea, how one can fix this nevertheless? >> > >> > No. As Felipe mentioned in this thread earlier, we don't get much help >> > from the MUSB document. Unless this issue caused any functional problem, >> > I wouldn't spend more time on it. >> >> What should we do with the warning message? It will make users worry >> about the system. > > We decided to use WARN() until we have enuogh data to conclude the flush > error does not break any function. But we are not there yet. > >> >> Could you then look at the freeze issue with removing FTDI device >> during it is working? > > I can. I will have to first locate a FT4243H device. Insert MA260 and execute following command: cat /dev/zero > /dev/ttyUSB2 then remove MA260 - system freezes. -- 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
On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: > Insert MA260 and execute following command: > > cat /dev/zero > /dev/ttyUSB2 > > then remove MA260 - system freezes. It does not freeze on my setup. I don't have radio service though. Does it freeze if you take out the SIM card? -- 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
On Thu, Apr 7, 2016 at 4:30 PM, Bin Liu <b-liu@ti.com> wrote: > On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: >> Insert MA260 and execute following command: >> >> cat /dev/zero > /dev/ttyUSB2 >> >> then remove MA260 - system freezes. > > It does not freeze on my setup. I don't have radio service though. > Does it freeze if you take out the SIM card? My SIM card won't be detected anyway, so I just used the dongle without a SIM card. Producing traffic on AT command port and removing the modem during this traffic was enough to bring the system to a freeze state. Have performed the same test with PandaBoard and it survived. -- 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
Hi, On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: > >> Could you then look at the freeze issue with removing FTDI device > >> during it is working? > > > > I can. I will have to first locate a FT4243H device. > > Insert MA260 and execute following command: > > cat /dev/zero > /dev/ttyUSB2 > > then remove MA260 - system freezes. Can you please try the patch [1] to see if it fixes the system freezing issue? Thanks, -Bin. [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 -- 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
On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: > Hi, > > On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: >> >> Could you then look at the freeze issue with removing FTDI device >> >> during it is working? >> > >> > I can. I will have to first locate a FT4243H device. >> >> Insert MA260 and execute following command: >> >> cat /dev/zero > /dev/ttyUSB2 >> >> then remove MA260 - system freezes. > > Can you please try the patch [1] to see if it fixes the system freezing > issue? > > [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 I've tested this patch with both FTDI FT4232HS as also Huawei ME909u-521. I can produce a freeze with both devices. Yegor -- 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
Hi, On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: > On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: > > Hi, > > > > On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: > >> >> Could you then look at the freeze issue with removing FTDI device > >> >> during it is working? > >> > > >> > I can. I will have to first locate a FT4243H device. > >> > >> Insert MA260 and execute following command: > >> > >> cat /dev/zero > /dev/ttyUSB2 > >> > >> then remove MA260 - system freezes. > > > > Can you please try the patch [1] to see if it fixes the system freezing > > issue? > > > > [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 > > I've tested this patch with both FTDI FT4232HS as also Huawei > ME909u-521. I can produce a freeze with both devices. Please remind me, is the dongle directly connected to MUSB or behind a hub? Thanks, -Bin. -- 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
On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: > Hi, > > On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: >> On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: >> > Hi, >> > >> > On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: >> >> >> Could you then look at the freeze issue with removing FTDI device >> >> >> during it is working? >> >> > >> >> > I can. I will have to first locate a FT4243H device. >> >> >> >> Insert MA260 and execute following command: >> >> >> >> cat /dev/zero > /dev/ttyUSB2 >> >> >> >> then remove MA260 - system freezes. >> > >> > Can you please try the patch [1] to see if it fixes the system freezing >> > issue? >> > >> > [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 >> >> I've tested this patch with both FTDI FT4232HS as also Huawei >> ME909u-521. I can produce a freeze with both devices. > > Please remind me, is the dongle directly connected to MUSB or behind a > hub? Behind a hub. Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. Yegor -- 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
Hi, On Tue, May 03, 2016 at 03:19:10PM +0200, Yegor Yefremov wrote: > On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: > > Hi, > > > > On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: > >> On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: > >> > Hi, > >> > > >> > On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: > >> >> >> Could you then look at the freeze issue with removing FTDI device > >> >> >> during it is working? > >> >> > > >> >> > I can. I will have to first locate a FT4243H device. > >> >> > >> >> Insert MA260 and execute following command: > >> >> > >> >> cat /dev/zero > /dev/ttyUSB2 > >> >> > >> >> then remove MA260 - system freezes. > >> > > >> > Can you please try the patch [1] to see if it fixes the system freezing > >> > issue? > >> > > >> > [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 > >> > >> I've tested this patch with both FTDI FT4232HS as also Huawei > >> ME909u-521. I can produce a freeze with both devices. > > > > Please remind me, is the dongle directly connected to MUSB or behind a > > hub? > > Behind a hub. > > Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. Thanks for the update. Can you please test the patch [1] instead? I'd like to use it as the fix. Regards, -Bin. [1] http://marc.info/?l=linux-usb&m=146222355213935&w=2 -- 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
Hi, On 03.05.2016 15:37, Bin Liu wrote: > Hi, > > On Tue, May 03, 2016 at 03:19:10PM +0200, Yegor Yefremov wrote: >> On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: >>> Hi, >>> >>> On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: >>>> On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: >>>>> Hi, >>>>> >>>>> On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: >>>>>>>> Could you then look at the freeze issue with removing FTDI device >>>>>>>> during it is working? >>>>>>> >>>>>>> I can. I will have to first locate a FT4243H device. >>>>>> >>>>>> Insert MA260 and execute following command: >>>>>> >>>>>> cat /dev/zero > /dev/ttyUSB2 >>>>>> >>>>>> then remove MA260 - system freezes. >>>>> >>>>> Can you please try the patch [1] to see if it fixes the system freezing >>>>> issue? >>>>> >>>>> [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 >>>> >>>> I've tested this patch with both FTDI FT4232HS as also Huawei >>>> ME909u-521. I can produce a freeze with both devices. >>> >>> Please remind me, is the dongle directly connected to MUSB or behind a >>> hub? >> >> Behind a hub. >> >> Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. > > Thanks for the update. > > Can you please test the patch [1] instead? I'd like to use it as the > fix. We are running a system on ChiliBoard (am335x) and we have also noticed freezes caused by usb driver. After applying this patch, we are not able to reproduce the issue anymore. Our setup: We have Telit LE910 modem connected to USB hub, which is connected to am335x. We use AT commands (usb option driver) to control modem. Freezing happens when we poweroff the modem (issue poweroff to modem, not simply remove the power). Before freeze, we have active connection to some modem's virtual serial ports (GPS, modem connection). We also noticed, that when we remove 5V power from the board, system unfreezes and works ok from that time. In our case 5V is used to power Telit modem. > > Regards, > -Bin. > > [1] http://marc.info/?l=linux-usb&m=146222355213935&w=2 > > -- > 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 >
Hi, On Wed, May 04, 2016 at 03:44:41PM +0200, Marcin Niestroj wrote: > Hi, > > On 03.05.2016 15:37, Bin Liu wrote: > >Hi, > > > >On Tue, May 03, 2016 at 03:19:10PM +0200, Yegor Yefremov wrote: > >>On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: > >>>Hi, > >>> > >>>On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: > >>>>On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: > >>>>>Hi, > >>>>> > >>>>>On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: > >>>>>>>>Could you then look at the freeze issue with removing FTDI device > >>>>>>>>during it is working? > >>>>>>> > >>>>>>>I can. I will have to first locate a FT4243H device. > >>>>>> > >>>>>>Insert MA260 and execute following command: > >>>>>> > >>>>>>cat /dev/zero > /dev/ttyUSB2 > >>>>>> > >>>>>>then remove MA260 - system freezes. > >>>>> > >>>>>Can you please try the patch [1] to see if it fixes the system freezing > >>>>>issue? > >>>>> > >>>>>[1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 > >>>> > >>>>I've tested this patch with both FTDI FT4232HS as also Huawei > >>>>ME909u-521. I can produce a freeze with both devices. > >>> > >>>Please remind me, is the dongle directly connected to MUSB or behind a > >>>hub? > >> > >>Behind a hub. > >> > >>Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. > > > >Thanks for the update. > > > >Can you please test the patch [1] instead? I'd like to use it as the > >fix. > > We are running a system on ChiliBoard (am335x) and we have also noticed > freezes caused by usb driver. After applying this patch, we are not able > to reproduce the issue anymore. Thanks for the report. > > Our setup: We have Telit LE910 modem connected to USB hub, which is > connected to am335x. We use AT commands (usb option driver) to control > modem. Freezing happens when we poweroff the modem (issue poweroff to > modem, not simply remove the power). Before freeze, we have active > connection to some modem's virtual serial ports (GPS, modem connection). It seems to be the same problem which the patch fixes. > > We also noticed, that when we remove 5V power from the board, system From which board? the ChiliBoard or Telit? > unfreezes and works ok from that time. In our case 5V is used to power > Telit modem. > > > > >Regards, > >-Bin. > > > >[1] http://marc.info/?l=linux-usb&m=146222355213935&w=2 > > > >-- > >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 > > > > -- > Regards, > Marcin Regards, -Bin. -- 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
On 04.05.2016 15:53, Bin Liu wrote: > Hi, > > On Wed, May 04, 2016 at 03:44:41PM +0200, Marcin Niestroj wrote: >> Hi, >> >> On 03.05.2016 15:37, Bin Liu wrote: >>> Hi, >>> >>> On Tue, May 03, 2016 at 03:19:10PM +0200, Yegor Yefremov wrote: >>>> On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: >>>>> Hi, >>>>> >>>>> On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: >>>>>> On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: >>>>>>>>>> Could you then look at the freeze issue with removing FTDI device >>>>>>>>>> during it is working? >>>>>>>>> >>>>>>>>> I can. I will have to first locate a FT4243H device. >>>>>>>> >>>>>>>> Insert MA260 and execute following command: >>>>>>>> >>>>>>>> cat /dev/zero > /dev/ttyUSB2 >>>>>>>> >>>>>>>> then remove MA260 - system freezes. >>>>>>> >>>>>>> Can you please try the patch [1] to see if it fixes the system freezing >>>>>>> issue? >>>>>>> >>>>>>> [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 >>>>>> >>>>>> I've tested this patch with both FTDI FT4232HS as also Huawei >>>>>> ME909u-521. I can produce a freeze with both devices. >>>>> >>>>> Please remind me, is the dongle directly connected to MUSB or behind a >>>>> hub? >>>> >>>> Behind a hub. >>>> >>>> Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. >>> >>> Thanks for the update. >>> >>> Can you please test the patch [1] instead? I'd like to use it as the >>> fix. >> >> We are running a system on ChiliBoard (am335x) and we have also noticed >> freezes caused by usb driver. After applying this patch, we are not able >> to reproduce the issue anymore. > > Thanks for the report. > >> >> Our setup: We have Telit LE910 modem connected to USB hub, which is >> connected to am335x. We use AT commands (usb option driver) to control >> modem. Freezing happens when we poweroff the modem (issue poweroff to >> modem, not simply remove the power). Before freeze, we have active >> connection to some modem's virtual serial ports (GPS, modem connection). > > It seems to be the same problem which the patch fixes. > >> >> We also noticed, that when we remove 5V power from the board, system > > From which board? the ChiliBoard or Telit? From ChiliBoard. But ChiliBoard is suppied by both, 5V (AC) and USB. ChiliBoard stays active, because PMIC switches automatically to USB. Telit however goes down, because it is supplied directly from 5V (AC). > >> unfreezes and works ok from that time. In our case 5V is used to power >> Telit modem. >> >>> >>> Regards, >>> -Bin. >>> >>> [1] http://marc.info/?l=linux-usb&m=146222355213935&w=2 >>> >>> -- >>> 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 >>> >> >> -- >> Regards, >> Marcin > > Regards, > -Bin. > -- > 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 >
Hi, On Wed, May 04, 2016 at 04:00:59PM +0200, Marcin Niestroj wrote: > On 04.05.2016 15:53, Bin Liu wrote: > >Hi, > > > >On Wed, May 04, 2016 at 03:44:41PM +0200, Marcin Niestroj wrote: > >>Hi, > >> > >>On 03.05.2016 15:37, Bin Liu wrote: > >>>Hi, > >>> > >>>On Tue, May 03, 2016 at 03:19:10PM +0200, Yegor Yefremov wrote: > >>>>On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: > >>>>>Hi, > >>>>> > >>>>>On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: > >>>>>>On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: > >>>>>>>Hi, > >>>>>>> > >>>>>>>On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: > >>>>>>>>>>Could you then look at the freeze issue with removing FTDI device > >>>>>>>>>>during it is working? > >>>>>>>>> > >>>>>>>>>I can. I will have to first locate a FT4243H device. > >>>>>>>> > >>>>>>>>Insert MA260 and execute following command: > >>>>>>>> > >>>>>>>>cat /dev/zero > /dev/ttyUSB2 > >>>>>>>> > >>>>>>>>then remove MA260 - system freezes. > >>>>>>> > >>>>>>>Can you please try the patch [1] to see if it fixes the system freezing > >>>>>>>issue? > >>>>>>> > >>>>>>>[1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 > >>>>>> > >>>>>>I've tested this patch with both FTDI FT4232HS as also Huawei > >>>>>>ME909u-521. I can produce a freeze with both devices. > >>>>> > >>>>>Please remind me, is the dongle directly connected to MUSB or behind a > >>>>>hub? > >>>> > >>>>Behind a hub. > >>>> > >>>>Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. > >>> > >>>Thanks for the update. > >>> > >>>Can you please test the patch [1] instead? I'd like to use it as the > >>>fix. > >> > >>We are running a system on ChiliBoard (am335x) and we have also noticed > >>freezes caused by usb driver. After applying this patch, we are not able > >>to reproduce the issue anymore. > > > >Thanks for the report. > > > >> > >>Our setup: We have Telit LE910 modem connected to USB hub, which is > >>connected to am335x. We use AT commands (usb option driver) to control > >>modem. Freezing happens when we poweroff the modem (issue poweroff to > >>modem, not simply remove the power). Before freeze, we have active > >>connection to some modem's virtual serial ports (GPS, modem connection). > > > >It seems to be the same problem which the patch fixes. > > > >> > >>We also noticed, that when we remove 5V power from the board, system > > > >From which board? the ChiliBoard or Telit? > > From ChiliBoard. But ChiliBoard is suppied by both, 5V (AC) and USB. > ChiliBoard stays active, because PMIC switches automatically to USB. > Telit however goes down, because it is supplied directly from 5V (AC). I am not sure I understand what happens. When you remove 5V from the board, it not only powers off the modem, but also the ChiliBoard, so nothing is running then, what do you mean by 'system unfreezes'? Putting back the 5V system works fine? Of cause, this is reboot. The freezing only happens when disconnecting the device. Regards, -Bin. > > > > >>unfreezes and works ok from that time. In our case 5V is used to power > >>Telit modem. > >> > >>> > >>>Regards, > >>>-Bin. > >>> > >>>[1] http://marc.info/?l=linux-usb&m=146222355213935&w=2 > >>> > >>>-- > >>>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 > >>> > >> > >>-- > >>Regards, > >>Marcin > > > >Regards, > >-Bin. > >-- > >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 > > > > -- > Regards, > Marcin -- 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
On 04.05.2016 16:14, Bin Liu wrote: > Hi, > > On Wed, May 04, 2016 at 04:00:59PM +0200, Marcin Niestroj wrote: >> On 04.05.2016 15:53, Bin Liu wrote: >>> Hi, >>> >>> On Wed, May 04, 2016 at 03:44:41PM +0200, Marcin Niestroj wrote: >>>> Hi, >>>> >>>> On 03.05.2016 15:37, Bin Liu wrote: >>>>> Hi, >>>>> >>>>> On Tue, May 03, 2016 at 03:19:10PM +0200, Yegor Yefremov wrote: >>>>>> On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: >>>>>>>> On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: >>>>>>>>>>>> Could you then look at the freeze issue with removing FTDI device >>>>>>>>>>>> during it is working? >>>>>>>>>>> >>>>>>>>>>> I can. I will have to first locate a FT4243H device. >>>>>>>>>> >>>>>>>>>> Insert MA260 and execute following command: >>>>>>>>>> >>>>>>>>>> cat /dev/zero > /dev/ttyUSB2 >>>>>>>>>> >>>>>>>>>> then remove MA260 - system freezes. >>>>>>>>> >>>>>>>>> Can you please try the patch [1] to see if it fixes the system freezing >>>>>>>>> issue? >>>>>>>>> >>>>>>>>> [1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 >>>>>>>> >>>>>>>> I've tested this patch with both FTDI FT4232HS as also Huawei >>>>>>>> ME909u-521. I can produce a freeze with both devices. >>>>>>> >>>>>>> Please remind me, is the dongle directly connected to MUSB or behind a >>>>>>> hub? >>>>>> >>>>>> Behind a hub. >>>>>> >>>>>> Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. >>>>> >>>>> Thanks for the update. >>>>> >>>>> Can you please test the patch [1] instead? I'd like to use it as the >>>>> fix. >>>> >>>> We are running a system on ChiliBoard (am335x) and we have also noticed >>>> freezes caused by usb driver. After applying this patch, we are not able >>>> to reproduce the issue anymore. >>> >>> Thanks for the report. >>> >>>> >>>> Our setup: We have Telit LE910 modem connected to USB hub, which is >>>> connected to am335x. We use AT commands (usb option driver) to control >>>> modem. Freezing happens when we poweroff the modem (issue poweroff to >>>> modem, not simply remove the power). Before freeze, we have active >>>> connection to some modem's virtual serial ports (GPS, modem connection). >>> >>> It seems to be the same problem which the patch fixes. >>> >>>> >>>> We also noticed, that when we remove 5V power from the board, system >>> >> >From which board? the ChiliBoard or Telit? >> >> From ChiliBoard. But ChiliBoard is suppied by both, 5V (AC) and USB. >> ChiliBoard stays active, because PMIC switches automatically to USB. >> Telit however goes down, because it is supplied directly from 5V (AC). > > I am not sure I understand what happens. When you remove 5V from the > board, it not only powers off the modem, but also the ChiliBoard, so > nothing is running then, what do you mean by 'system unfreezes'? Putting > back the 5V system works fine? Of cause, this is reboot. The freezing > only happens when disconnecting the device. When we remove AC (refered as 5V in my previous comments) from the ChiliBoard it is still active, because it starts to use USB power from PC (in fact also 5V). Only Telit powers down, because it uses AC 5V directly. In summary: after unplugging AC cable ChiliBoard is still powered, but with USB power from PC. Telit is powered down, because it is connected to AC 5V directly, with no option to use USB power from PC. > > Regards, > -Bin. > >> >>> >>>> unfreezes and works ok from that time. In our case 5V is used to power >>>> Telit modem. >>>> >>>>> >>>>> Regards, >>>>> -Bin. >>>>> >>>>> [1] http://marc.info/?l=linux-usb&m=146222355213935&w=2 >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> -- >>>> Regards, >>>> Marcin >>> >>> Regards, >>> -Bin. >>> -- >>> 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 >>> >> >> -- >> Regards, >> Marcin
Hi, On Wed, May 04, 2016 at 04:33:14PM +0200, Marcin Niestroj wrote: > On 04.05.2016 16:14, Bin Liu wrote: > >Hi, > > > >On Wed, May 04, 2016 at 04:00:59PM +0200, Marcin Niestroj wrote: > >>On 04.05.2016 15:53, Bin Liu wrote: > >>>Hi, > >>> > >>>On Wed, May 04, 2016 at 03:44:41PM +0200, Marcin Niestroj wrote: > >>>>Hi, > >>>> > >>>>On 03.05.2016 15:37, Bin Liu wrote: > >>>>>Hi, > >>>>> > >>>>>On Tue, May 03, 2016 at 03:19:10PM +0200, Yegor Yefremov wrote: > >>>>>>On Tue, May 3, 2016 at 3:16 PM, Bin Liu <b-liu@ti.com> wrote: > >>>>>>>Hi, > >>>>>>> > >>>>>>>On Tue, May 03, 2016 at 11:03:23AM +0200, Yegor Yefremov wrote: > >>>>>>>>On Thu, Apr 14, 2016 at 6:50 PM, Bin Liu <b-liu@ti.com> wrote: > >>>>>>>>>Hi, > >>>>>>>>> > >>>>>>>>>On Thu, Apr 07, 2016 at 09:09:50AM +0200, Yegor Yefremov wrote: > >>>>>>>>>>>>Could you then look at the freeze issue with removing FTDI device > >>>>>>>>>>>>during it is working? > >>>>>>>>>>> > >>>>>>>>>>>I can. I will have to first locate a FT4243H device. > >>>>>>>>>> > >>>>>>>>>>Insert MA260 and execute following command: > >>>>>>>>>> > >>>>>>>>>>cat /dev/zero > /dev/ttyUSB2 > >>>>>>>>>> > >>>>>>>>>>then remove MA260 - system freezes. > >>>>>>>>> > >>>>>>>>>Can you please try the patch [1] to see if it fixes the system freezing > >>>>>>>>>issue? > >>>>>>>>> > >>>>>>>>>[1] http://marc.info/?l=linux-usb&m=144683124825113&w=2 > >>>>>>>> > >>>>>>>>I've tested this patch with both FTDI FT4232HS as also Huawei > >>>>>>>>ME909u-521. I can produce a freeze with both devices. > >>>>>>> > >>>>>>>Please remind me, is the dongle directly connected to MUSB or behind a > >>>>>>>hub? > >>>>>> > >>>>>>Behind a hub. > >>>>>> > >>>>>>Btw your other patch "musb_host: fix lockup on rxcsr_h_error" is working. > >>>>> > >>>>>Thanks for the update. > >>>>> > >>>>>Can you please test the patch [1] instead? I'd like to use it as the > >>>>>fix. > >>>> > >>>>We are running a system on ChiliBoard (am335x) and we have also noticed > >>>>freezes caused by usb driver. After applying this patch, we are not able > >>>>to reproduce the issue anymore. > >>> > >>>Thanks for the report. > >>> > >>>> > >>>>Our setup: We have Telit LE910 modem connected to USB hub, which is > >>>>connected to am335x. We use AT commands (usb option driver) to control > >>>>modem. Freezing happens when we poweroff the modem (issue poweroff to > >>>>modem, not simply remove the power). Before freeze, we have active > >>>>connection to some modem's virtual serial ports (GPS, modem connection). > >>> > >>>It seems to be the same problem which the patch fixes. > >>> > >>>> > >>>>We also noticed, that when we remove 5V power from the board, system > >>> > >>>From which board? the ChiliBoard or Telit? > >> > >>From ChiliBoard. But ChiliBoard is suppied by both, 5V (AC) and USB. > >>ChiliBoard stays active, because PMIC switches automatically to USB. > >>Telit however goes down, because it is supplied directly from 5V (AC). > > > >I am not sure I understand what happens. When you remove 5V from the > >board, it not only powers off the modem, but also the ChiliBoard, so > >nothing is running then, what do you mean by 'system unfreezes'? Putting > >back the 5V system works fine? Of cause, this is reboot. The freezing > >only happens when disconnecting the device. > > When we remove AC (refered as 5V in my previous comments) from the > ChiliBoard it is still active, because it starts to use USB power from > PC (in fact also 5V). Only Telit powers down, because it uses AC 5V > directly. Ok, clear now. > > In summary: after unplugging AC cable ChiliBoard is still powered, but > with USB power from PC. Telit is powered down, because it is connected > to AC 5V directly, with no option to use USB power from PC. It will be interesting to see what is happening when removing AC from ChiliBoard. You could first try to turn on dynamic debug log in musb_host.c. A bus trace between MUSB and hub also could help. Regards, -Bin. > > > > >Regards, > >-Bin. > > > >> > >>> > >>>>unfreezes and works ok from that time. In our case 5V is used to power > >>>>Telit modem. > >>>> > >>>>> > >>>>>Regards, > >>>>>-Bin. > >>>>> > >>>>>[1] http://marc.info/?l=linux-usb&m=146222355213935&w=2 > >>>>> > >>>>>-- > >>>>>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 > >>>>> > >>>> > >>>>-- > >>>>Regards, > >>>>Marcin > >>> > >>>Regards, > >>>-Bin. > >>>-- > >>>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 > >>> > >> > >>-- > >>Regards, > >>Marcin > > -- > Regards, > Marcin -- 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
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index 58487a4..f6d6822 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -112,7 +112,7 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) struct musb *musb = ep->musb; void __iomem *epio = ep->regs; u16 csr; - int retries = 1000; + int retries = 10000; csr = musb_readw(epio, MUSB_TXCSR); while (csr & MUSB_TXCSR_FIFONOTEMPTY) {