On Sun, 2012-02-26 at 19:48 +0100, Maik Zumstrull wrote: > On Sun, Feb 26, 2012 at 18:57, Greg KH <g...@kroah.com> wrote: > > On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote: > > >> > Is the device stuck doing something? > >> > >> Not as far as I know. > > > > Are two userspace programs trying to access the device at the same time? > > The device exports three virtual serial ports. ModemManager accesses > more than one. On the other hand, we were able to reproduce the freeze > accessing only one port from one process, see Bugzilla. > > I've attached a fresh strace of opening the device on 3.2.6. The > open() takes 10s, the close takes 5s. Nothing else was accessing any > ttyUSB*; I killed ModemManager and double checked with lsof. > > > Yes. Please try loading the module with: > > modprobe option debug=1 > > and seeing what happens in the kernel log when you open the device. > > Output attached. I think it's three "option_send_setup" for one > open()/close(). At least, that's what happens with the C snippet.
There's a few issues going on here that I've seen before. First is the SENDSETUP quirk in option.ko that is required for some devices where the interface is claimed by option but really isn't supposed to be, because it's not actually speaking USB serial. Thus it doesn't respond to the sendsetup command and the option driver just blocks for a bit. Second is "closing_wait", which ModemManager sets to ASYNC_CLOSING_WAIT_NONE to prevent a 5 or 10 second freeze on close() where if the port has not responded to any request, the buffer is still full, and close() blocks (even if O_NONBLOCK) until the buffer is flushed. Setting ASYNC_CLOSING_WAIT_NONE appeared to fix that. What device is this? Dan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1330355725.1941.7.ca...@dcbw.foobar.com