On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote:
> On Sun, Feb 26, 2012 at 18:07, Greg KH <g...@kroah.com> 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, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120226175748.ga3...@kroah.com
