Re: CDC ACM problem
On Thu, Mar 20, 2014 at 02:31:30PM +0100, Martin Åkerberg wrote: > Hi Johan, > > You seem to be last contributor to cdc-acm driver in linux. I don't know if > you are the correct person to ask, or if you have the time to answer, but > if not, could you point me to the correct forum? The linux-usb list (added as CC) would be that forum. > Anyway, I am implementing a CDC-ACM device in a Atmel XMEGA processor. I am > interfacing this from a c-program on a Linux machine. Everything is working > as expected when it comes to opening the /dev/ttyACM0, configuring the > terminal, reading and sending data and closing the device. The problem > occurs when I try to open and close the device repeatedly many times. > > As a test: With a simple c-program I open and close the device in an > endless loop. Before every open and close I have a 100ms delay. I can see > on my device that setup messages with control line signals is sent on every > open and close, as expected. > > After about 50-500 cycles the open call fails. The message I can read in > dmesg is: > > [xxx] xhci_hcd :00:14.0 ERROR no room on ep ring > [xxx] cdc_acm 3-3:1.1: acm_submit_read_urb - usb_submit_urb failed: -12 > > I read this as memory overflow regarding read urbs. I see in the kernel > code that 16 read urbs are allocated everytime the port is opened. But > these read urbs should be killed in the acm_port_shutdown function, which > might get called via > > tty_port_close >tty_port_shutdown > port->ops->shutdown > > I say "might" since it seems it doesn't happen in my case. > > Do you have any idea why this might be? Well, this appears to be a problem in the xhci-driver, and not directly related to cdc-acm. Specifically, the -ENOMEM (-12) above originates in the xhci-driver when it fails to enqueue the urb. [ The cdc-acm driver allocates its urbs on probe and releases them when the device is unbound. ] > I don't see any of the kernel warnings from tty_port_close_start, > > The "uname -r" output is: 3.2.0.23-generic That is a fairly old kernel (and also a distro-kernel?). I'd suggest you try to reproduce this on a more recent mainline kernel such as v3.13.6 (or v3.14-rc7). Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression cause by commit f1125f81 (from Deng-Cheng Zhu)
Messages like this should always be sent to the linux-usb mailing list. On Sat, 22 Mar 2014, Dâniel Fraga wrote: > Hi! I posted this bug and it seems your commit caused the > regression: > > https://bugzilla.kernel.org/show_bug.cgi?id=72611 > > Can you take a look? > > Thank you! > > Ps: I put James and Alan on CC just in case. I don't see how that particular commit could cause your problem. The code changed by the commit is used only in debugging. Are you certain you found the correct commit? To track the bug further, you should turn on CONFIG_USB_DEBUG and post the dmesg log showing what happens when the mouse gets stuck. You also should post a usbmon trace (see Documentation/usb/usbmon.txt). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: questions about give back urb in tasklet
On Wed, Mar 19, 2014 at 11:05 PM, vichy wrote: > hi Ming: One approach I like to use is trace event. >>> Would you please let us how to to use trace event for calculate >>> max/average usb irq time? >> >> You can enable irq_handler_entry and irq_handler_exit event, then >> write a script easily to figure out the time consumed in ehci irq handler, >> see Documentation/trace/events.txt of linux kernel for detailed steps. > I find it ^^ > But actually the local interrupt is still disabled during completion because we need to convert spin_lock in all current usb drivers to spin_lock_irqsave() first. >>> Would you please let me know the function or source you mentioned? >> >> The local interrupt is disabled during completion handler in >> __usb_hcd_giveback_urb(). >> >>> >>> BTW, why I cannot see xhci add HCD_BH? >> >> There might be some reasons: >> >> - in previous following up discussion, Alan thought it should >> be easier to just split the hcd interrupt handler into two parts >> >> - as I said, spin_lock() isn't converted to spin_lock_irqsave() >> in drivers' completion handler yet > Do you mean , > take uvc/uac for example, > if we put completion what they register previously in BH, > the spin_lock() in their completions should be changed to spin_lock_irqsave()? > > Is it due to original completion is called in irq context? Some drivers may assume that the completion handler is called from hardirq handler, so call spin_lock(), and they should have called spin_lock_irqsave() if there are shared resources between its completion handler and other irq handler. So the simplest approach for the conversion is to replace all spin_lock() inside urb completion path into spin_lock_irqsave(). > >> >> - maybe no one really care the time in which local interrupt is >> disabled by USB completion handler.(That might be true >> because USB devices are commonly used in personal >> computer, not in big server product) >> >>> is there some reason xhci cannot put completion in BH? >> >> IMO, the completion handler should be put into tasklet, and >> can be done. If you like, you can take time to do that. > Below is so far kernel implementation. > Isn't it put completion handler into tasklet? Yes, it is run in tasklet context with local irq disabled. As you know we need to enable irq during URB completion. >... >.. > spin_lock(&bh->lock); > list_add_tail(&urb->urb_list, &bh->head); > running = bh->running; > spin_unlock(&bh->lock); > > if (running) > ; > else if (high_prio_bh) > tasklet_hi_schedule(&bh->bh); > else > tasklet_schedule(&bh->bh); > > > Thanks for your help, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REGRESSION with bisect] 3.13 and above kernels freeze mouse pointer when entering KDE 4.12
Ok. Greg Kroah-Hartman asked me to post this bug in this list and CC some developers. The bug report is here: https://bugzilla.kernel.org/show_bug.cgi?id=72611 I attached what Alan Stern asked (USB debug log and usbmon trace) in the bug report. I hope it helps. Thanks. -- Linux 3.12.14: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com?r=danielfragabr Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to recognize device for 45 minutes and Device Disconnects
On Sat, 22 Mar 2014, Mike Mitchell wrote: > On Wed, Mar 19, 2014 at 12:51 PM, Alan Stern wrote: > > > > This trace doesn't show a 45-minute delay. It also doesn't show a > > > disconnect. Everything appears to be working normally. > > > > > The 3.5 kernel is getting old. Can you try something more recent, such > > > as 3.13? > > > > > Alan Stern > > > > I upgraded the kernel to : Linux enc006 3.13.6-031306-generic > #201403070154 SMP Okay, good. > I was optimistic that the device was detected at boot after the restart. > But then it disconnected again: > > Mar 21 21:28:44 enc006 kernel: [23321.382950] usb 2-1.1: USB disconnect, > device number 3 > Mar 21 21:28:44 enc006 kernel: [23321.631377] usb 2-1.1: new full-speed USB > device number 4 using ehci-pci > Mar 21 21:28:45 enc006 kernel: [23321.724156] usb 2-1.1: New USB device > found, idVendor=0d8c, idProduct=0008 > Mar 21 21:28:45 enc006 kernel: [23321.724164] usb 2-1.1: New USB device > strings: Mfr=0, Product=1, SerialNumber=0 > Mar 21 21:28:45 enc006 kernel: [23321.724169] usb 2-1.1: Product: C-Media > USB Audio Device > Mar 21 21:28:45 enc006 kernel: [23321.738614] input: C-Media USB Audio > Deviceas > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.3/input/input6 > Mar 21 21:28:45 enc006 kernel: [23321.738876] hid-generic > 0003:0D8C:0008.0002: input,hidraw0: USB HID v1.00 Device [C-Media USB Audio > Device ] on usb-:00:1d.0-1.1/input3 > Mar 22 00:20:22 enc006 kernel: [33618.155946] usb 2-1.1: USB disconnect, > device number 4 > > Then after the reboot, it was not detected right away again. Attached file > shows whole kern.log and delay in recognizing device after reboot. But > hese is the 42 minute part: > > Mar 22 10:52:40 enc006 kernel: [ 2564.269338] usb 2-1.1: new full-speed USB > device number 3 using ehci-pci > Mar 22 10:52:41 enc006 kernel: [ 2564.363243] usb 2-1.1: New USB device > found, idVendor=0d8c, idProduct=0008 > Mar 22 10:52:41 enc006 kernel: [ 2564.363252] usb 2-1.1: New USB device > strings: Mfr=0, Product=1, SerialNumber=0 > Mar 22 10:52:41 enc006 kernel: [ 2564.363256] usb 2-1.1: Product: C-Media > USB Audio Device > Mar 22 10:52:41 enc006 kernel: [ 2564.401169] hidraw: raw HID events driver > (C) Jiri Kosina > Mar 22 10:52:41 enc006 kernel: [ 2564.431416] usbcore: registered new > interface driver snd-usb-audio > Mar 22 10:52:41 enc006 kernel: [ 2564.431879] usbcore: registered new > interface driver usbhid > Mar 22 10:52:41 enc006 kernel: [ 2564.431884] usbhid: USB HID core driver > Mar 22 10:52:41 enc006 kernel: [ 2564.458741] input: C-Media USB Audio > Deviceas > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.3/input/input5 > Mar 22 10:52:41 enc006 kernel: [ 2564.459103] hid-generic > 0003:0D8C:0008.0001: input,hidraw0: USB HID v1.00 Device [C-Media USB Audio > Device ] on usb-:00:1d.0-1.1/input3 > > The 42 minute delay to recognition is remarkably consistent for this to be > a hardware problem. And I can;t help but think the disconnects are related. > I'm not sure if this is power, usbcore, or usbhid related. Where should I > be looking to get more detailed information? What happens if you run "lsusb -v" shortly after booting? Does that cause the mouse to be recognized? Anyway, here's something you can do: Collect a usbmon trace for bus 2. Detailed instructions are in the kernel source file Documentation/usb/usbmon.txt. Start the trace shortly after booting, while the mouse still hasn't been detected. Then while the trace is running, do the following: echo 0 >/sys/bus/usb/devices/2-1/bConfigurationValue and a few seconds later, echo 1 >/sys/bus/usb/devices/2-1/bConfigurationValue It's possible that this will cause the mouse to be detected, but if it doesn't, wait the 45 minutes (or however long it takes) before stopping the usbmon trace. Then post the output from the trace, and we'll see what it reveals. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION with bisect] 3.13 and above kernels freeze mouse pointer when entering KDE 4.12
On Sat, 22 Mar 2014, Dâniel Fraga wrote: > Ok. Greg Kroah-Hartman asked me to post this bug in this list > and CC some developers. The bug report is here: > > https://bugzilla.kernel.org/show_bug.cgi?id=72611 > > I attached what Alan Stern asked (USB debug log and usbmon > trace) in the bug report. I hope it helps. Which device is the troublesome mouse? You have so many USB devices attached, it's hard to tell what's going on. Can you run the same test again, but this time with all the USB devices unplugged (or as many as possible) except for the mouse? Also, don't attach the kernel log file; instead attach the output from the dmesg command. And turn on CONFIG_PRINTK_TIME in your kernel's configuration. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION with bisect] 3.13 and above kernels freeze mouse pointer when entering KDE 4.12
On Sat, 22 Mar 2014 17:18:07 -0400 (EDT) Alan Stern wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=72611 > > > > I attached what Alan Stern asked (USB debug log and usbmon > > trace) in the bug report. I hope it helps. > > Which device is the troublesome mouse? You have so many USB devices > attached, it's hard to tell what's going on. The device is the following: Bus 002 Device 007: ID 1532:0016 Razer USA, Ltd > Can you run the same test again, but this time with all the USB devices > unplugged (or as many as possible) except for the mouse? Yes. Here it's a bit complicated to remove the other usb devices here, but I attached the full dmesg with printk as requested: https://bugzilla.kernel.org/show_bug.cgi?id=72611 1) full dmesg here with printk: https://bugzilla.kernel.org/attachment.cgi?id=130321 Extract with the mouse part: [4.428482] usb 2-1.6: new full-speed USB device number 7 using ehci-pci [4.513395] usb 2-1.6: ep0 maxpacket = 8 [4.516331] usb 2-1.6: skipped 1 descriptor after interface [4.516702] usb 2-1.6: default language 0x0409 [4.517954] usb 2-1.6: udev 7, busnum 2, minor = 134 [4.517960] usb 2-1.6: New USB device found, idVendor=1532, idProduct=0016 [4.517963] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [4.517965] usb 2-1.6: Product: Razer DeathAdder [4.517968] usb 2-1.6: Manufacturer: Razer [4.518225] usb 2-1.6: usb_probe_device [4.518228] usb 2-1.6: configuration #1 chosen from 1 choice [4.518448] usb 2-1.6: adding 2-1.6:1.0 (config #1, interface 0) [4.518613] usbhid 2-1.6:1.0: usb_probe_interface [4.518615] usbhid 2-1.6:1.0: usb_probe_interface - got id [6.118210] input: Razer Razer DeathAdder as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input9 [ 26.738592] usb 2-1.6: ep 81: reserve intr @ 0+8 (0.0+1) [1/3 us] mask 1c01 [ 26.738597] usb 2-1.6: link qh1-1c01/8802153fb480 start 0 [1/3 us] [ 26.759691] usb 2-1.6: unlink qh1-1c01/8802153fb480 start 0 [1/3 us] [ 27.546452] usb 2-1.6: link qh1-1c01/8802153fb480 start 0 [1/3 us] [ 28.336116] usbhid 2-1.6:1.0: disconnect by usbfs [ 28.336133] usb 2-1.6: unlink qh1-1c01/8802153fb480 start 0 [1/3 us] [ 28.353165] usb 2-1.6: manual set_interface for iface 0, alt 0 [ 28.353168] usb 2-1.6: ep 81: release intr @ 0+8 (0.0+1) [1/3 us] mask 1c01 [ 28.354041] usbhid 2-1.6:1.0: usb_probe_interface [ 28.354044] usbhid 2-1.6:1.0: usb_probe_interface - got id [ 28.356155] input: Razer Razer DeathAdder as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input10 [ 28.356226] usb 2-1.6: ep 81: reserve intr @ 0+8 (0.0+1) [1/3 us] mask 1c01 [ 28.356237] usb 2-1.6: link qh1-1c01/8800d55d6300 start 0 [1/3 us] [ 28.356347] usbhid 2-1.6:1.0: disconnect by usbfs [ 28.356358] usb 2-1.6: unlink qh1-1c01/8800d55d6300 start 0 [1/3 us] [ 28.381307] usb 2-1.6: manual set_interface for iface 0, alt 0 [ 28.381311] usb 2-1.6: ep 81: release intr @ 0+8 (0.0+1) [1/3 us] mask 1c01 [ 29.356447] usbhid 2-1.6:1.0: usb_probe_interface [ 29.356452] usbhid 2-1.6:1.0: usb_probe_interface - got id [ 29.358654] input: Razer Razer DeathAdder as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input11 [ 29.358725] usb 2-1.6: ep 81: reserve intr @ 0+8 (0.0+1) [1/3 us] mask 1c01 [ 29.358729] usb 2-1.6: link qh1-1c01/8800d59ea900 start 0 [1/3 us] [ 29.358999] usbhid 2-1.6:1.0: disconnect by usbfs [ 29.359010] usb 2-1.6: unlink qh1-1c01/8800d59ea900 start 0 [1/3 us] [ 29.389647] usb 2-1.6: manual set_interface for iface 0, alt 0 [ 29.389651] usb 2-1.6: ep 81: release intr @ 0+8 (0.0+1) [1/3 us] mask 1c01 [ 30.358728] usbhid 2-1.6:1.0: usb_probe_interface [ 30.358734] usbhid 2-1.6:1.0: usb_probe_interface - got id [ 30.361130] input: Razer Razer DeathAdder as /devices/pci:00/:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.0/input/input12 [ 30.361228] usb 2-1.6: ep 81: reserve intr @ 0+8 (0.0+1) [1/3 us] mask 1c01 [ 30.361232] usb 2-1.6: link qh1-1c01/8802153c3600 start 0 [1/3 us] 2) usbmon trace: https://bugzilla.kernel.org/attachment.cgi?id=130331 The device is the "2:007". I think you can grep it. I had to move the mouse a lot to trigger the bug. It happens only when entering KDE and with intensive hard disk usage, high load. -- Linux 3.12.14: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com?r=danielfragabr Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
