I have done some more testing now. It seems there is no problem on newer kernels. The problem seems to disappear somewhere around version 3.5. And also, I was only seeing this problem on a computer with Intel QM77 chipset. With another older computer there was no problem even with kernel version 3.2. /Martin 2014-03-24 14:55 GMT+01:00 Martin Åkerberg <martin.aakerberg@xxxxxxxxx>: > thanks for the response, > > I will try to reproduce the problem on the latest mainline kernel. > > Regards, > > Martin > > 2014-03-22 13:21 GMT+01:00 Johan Hovold <jhovold@xxxxxxxxx>: >> 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 0000: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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
