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

Reply via email to