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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
