Re: evdev soft lockup 2.6.24-rc5-mm1

[Jiri Slaby]

On 01/09/2008 11:11 AM, Jiri Kosina wrote:
> On Wed, 9 Jan 2008, Jiri Slaby wrote:
>
> > BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
> [ ... ]
> > Call Trace:
> >  [<ffffffff804e7648>] __mutex_lock_slowpath+0x38/0xd0
> >  [<ffffffff804e747e>] mutex_lock+0x1e/0x30
> >  [<ffffffff8040c497>] input_release_device+0x27/0x50
> >  [<ffffffff804102aa>] evdev_ungrab+0x3a/0x50
> >  [<ffffffff804103eb>] evdev_release+0xcb/0xd0
> >  [<ffffffff80293460>] __fput+0xc0/0x230
> >  [<ffffffff802938a6>] fput+0x16/0x20
> >  [<ffffffff80290296>] filp_close+0x56/0x90
> >  [<ffffffff80291afa>] sys_close+0x9a/0xf0
> >  [<ffffffff8020ba4e>] system_call+0x7e/0x83
> > I was not able to use sysrq keys, the keyboard is obviously defunct. If 
> > this is not known, I'll try to turn lockdep on and maybe connect through 
> > ssh next time it happens.
>
> Is this reproducible on your side? 
>
> Running with lockdep would be really helpful, so that we possibly know who 
> is holding the other instance of dev->mutex.

Seems not to be an issue any longer, but I'll keep an eye on it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/