Thread (4 messages) 4 messages, 2 authors, 2008-01-21

Re: evdev soft lockup 2.6.24-rc5-mm1

From: Jiri Slaby <hidden>
Date: 2008-01-09 10:30:26
Also in: lkml

On 01/09/2008 11:11 AM, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Jiri Slaby wrote:
quoted
BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
quoted
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? 
not 100%, it happens occasionally.
Running with lockdep would be really helpful, so that we possibly know who 
is holding the other instance of dev->mutex.
I'll try my best.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help