On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote: > On Sun, Feb 26, 2012 at 18:07, Greg KH <greg@xxxxxxxxx> wrote: > > On Sun, Feb 26, 2012 at 05:38:46PM +0100, Maik Zumstrull wrote: > > > I don't see any long delay in your kernel log messages. > > The problem isn't visible in dmesg AFAIK. I was asked to include this > output in the report just in case. It's visible in strace (attached to > Bugzilla, can take a fresh trace if you'd like), and to the user > because the whole system ignores user input during the freeze. > > > What exactly is stalling so long? > > When someone previously looked at the issue with me, the delay seemed > to be in acquiring the big TTY lock. There is no more "big" tty lock in the 3.2 kernel. Well, there's a small one, but this all should be fixed now. > > 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? What could be causing the lock to hold things up here? > > If you enable debugging for usb and/or the driver, what does the kernel > > log show? > > I don't think we've done that yet. Quick pointer on how to do this? > I'm reasonably experienced, but not a kernel developer. Just pass > debug=1 to certain modules? That can work if it's the option module. > > What driver is bound to this device, the option one? > > Yes. The drivers symlink points to bus/usb/drivers/option, anyway, I > hope that's what you meant. Yes. Please try loading the module with: modprobe option debug=1 and seeing what happens in the kernel log when you open the device. thanks, greg k-h -- 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
