Non-fatal (box is still alive and apparently well) on boot,
FC5-uptodate on a Dell Latitude C640. From the dmesg ring:
[ 8.680000] =============================================
[ 8.680000] [ INFO: possible recursive locking detected ]
[ 8.680000] 2.6.18-git21 #1
[ 8.680000] ---------------------------------------------
[ 8.680000] kseriod/163 is trying to acquire lock:
[ 8.680000] (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
ps2_command+0x89/0x358
[ 8.680000]
[ 8.680000] but task is already holding lock:
[ 8.680000] (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
ps2_command+0x89/0x358
[ 8.680000]
[ 8.680000] other info that might help us debug this:
[ 8.680000] 4 locks held by kseriod/163:
[ 8.680000] #0: (serio_mutex){--..}, at: [<c0317a5f>]
serio_thread+0x11/0x2ca
[ 8.680000] #1: (&serio->drv_mutex){--..}, at: [<c0316f2c>]
serio_connect_driver+0x17/0x32
[ 8.680000] #2: (psmouse_mutex){--..}, at: [<c0320a90>]
psmouse_connect+0x11/0x24a
[ 8.680000] #3: (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
ps2_command+0x89/0x358
[ 8.680000]
[ 8.680000] stack backtrace:
[ 8.680000] [<c010339c>] show_trace_log_lvl+0x24/0x39
[ 8.680000] [<c0103b54>] dump_stack+0x24/0x28
[ 8.680000] [<c0129c8f>] __lock_acquire+0x128/0xa1c
[ 8.680000] [<c012a897>] lock_acquire+0x6a/0x84
[ 8.680000] [<c03d14f5>] mutex_lock_nested+0xd8/0x25b
[ 8.680000] [<c03198c3>] ps2_command+0x89/0x358
[ 8.680000] [<c031fed9>] psmouse_sliced_command+0x2c/0x74
[ 8.680000] [<c0323be0>] synaptics_pt_write+0x2a/0x5a
[ 8.680000] [<c031978e>] ps2_sendbyte+0x51/0xfd
[ 8.680000] [<c031994f>] ps2_command+0x115/0x358
[ 8.680000] [<c031fa59>] psmouse_probe+0x24/0x7d
[ 8.680000] [<c0320b8d>] psmouse_connect+0x10e/0x24a
[ 8.680000] [<c0316f36>] serio_connect_driver+0x21/0x32
[ 8.680000] [<c02e0615>] really_probe+0x3c/0xc3
[ 8.680000] [<c02dfaea>] bus_for_each_drv+0x52/0x84
[ 8.680000] [<c02e07a9>] device_attach+0x5e/0x72
[ 8.680000] [<c02dfa6c>] bus_attach_device+0x24/0x50
[ 8.680000] [<c02ded5c>] device_add+0x37d/0x4bf
[ 8.680000] [<c0317b29>] serio_thread+0xdb/0x2ca
[ 8.680000] [<c0123d19>] kthread+0xc5/0xf4
[ 8.680000] [<c0102edb>] kernel_thread_helper+0x7/0x10
[ 8.680000] DWARF2 unwinder stuck at kernel_thread_helper+0x7/0x10
[ 8.680000]
[ 8.680000] Leftover inexact backtrace:
[ 8.680000]
[ 8.680000] =======================
--alessandro
"Well a man has two reasons for things that he does
the first one is pride and the second one is love
all understandings must come by this way"
(Husker Du, 'She Floated Away')
On Wed, 4 Oct 2006, Alessandro Suardi wrote:
> Non-fatal (box is still alive and apparently well) on boot,
> FC5-uptodate on a Dell Latitude C640. From the dmesg ring:
> [ 8.680000] =============================================
> [ 8.680000] [ INFO: possible recursive locking detected ]
> [ 8.680000] 2.6.18-git21 #1
> [ 8.680000] ---------------------------------------------
> [ 8.680000] kseriod/163 is trying to acquire lock:
> [ 8.680000] (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
> ps2_command+0x89/0x358
Me and Peter Zijlstra have already submitted patches to fix this - read
the thread at
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-09/msg07416.html
I don't know the reason why these have not yet been merged into the input
tree. Dmitry?
Thanks,
--
Jiri Kosina
On 10/4/06, Jiri Kosina <[email protected]> wrote:
> On Wed, 4 Oct 2006, Alessandro Suardi wrote:
>
> > Non-fatal (box is still alive and apparently well) on boot,
> > FC5-uptodate on a Dell Latitude C640. From the dmesg ring:
>
> > [ 8.680000] =============================================
> > [ 8.680000] [ INFO: possible recursive locking detected ]
> > [ 8.680000] 2.6.18-git21 #1
> > [ 8.680000] ---------------------------------------------
> > [ 8.680000] kseriod/163 is trying to acquire lock:
> > [ 8.680000] (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
> > ps2_command+0x89/0x358
>
> Me and Peter Zijlstra have already submitted patches to fix this - read
> the thread at
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-09/msg07416.html
>
> I don't know the reason why these have not yet been merged into the input
> tree. Dmitry?
>
Sorry, was a little busy.
I tested the patches and they work. Couple of comments:
- register_lock_class is marked as inline but now has 2 call sites and
is relatively big - might want to remove "inline"
- how about adding lockdep_set_subclass() to avoid littering source
with struct lock_class_key when we only want to tweak subclass? For
that we might want export register_lock_class and hide it behind a
#define...
--
Dmitry
On Thu, 5 Oct 2006, Dmitry Torokhov wrote:
> I tested the patches and they work. Couple of comments:
> - register_lock_class is marked as inline but now has 2 call sites and
> is relatively big - might want to remove "inline"
I agree.
> - how about adding lockdep_set_subclass() to avoid littering source
> with struct lock_class_key when we only want to tweak subclass? For
> that we might want export register_lock_class and hide it behind a
> #define...
I added Ingo to CC so that he could comment.
However I would not be able to submit patches which will be tested, as the
only machine I had with passthrough synpatics port broke horribly and is
currently in the warranty repair.
--
Jiri Kosina
On Thu, 2006-10-05 at 16:34 -0400, Dmitry Torokhov wrote:
> On 10/4/06, Jiri Kosina <[email protected]> wrote:
> > On Wed, 4 Oct 2006, Alessandro Suardi wrote:
> >
> > > Non-fatal (box is still alive and apparently well) on boot,
> > > FC5-uptodate on a Dell Latitude C640. From the dmesg ring:
> >
> > > [ 8.680000] =============================================
> > > [ 8.680000] [ INFO: possible recursive locking detected ]
> > > [ 8.680000] 2.6.18-git21 #1
> > > [ 8.680000] ---------------------------------------------
> > > [ 8.680000] kseriod/163 is trying to acquire lock:
> > > [ 8.680000] (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
> > > ps2_command+0x89/0x358
> >
> > Me and Peter Zijlstra have already submitted patches to fix this - read
> > the thread at
> > http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-09/msg07416.html
> >
> > I don't know the reason why these have not yet been merged into the input
> > tree. Dmitry?
> >
>
> Sorry, was a little busy.
>
> I tested the patches and they work. Couple of comments:
>
> - register_lock_class is marked as inline but now has 2 call sites and
> is relatively big - might want to remove "inline"
> - how about adding lockdep_set_subclass() to avoid littering source
> with struct lock_class_key when we only want to tweak subclass? For
> that we might want export register_lock_class and hide it behind a
> #define...
>
or something like this:
#define concat_i(a) #a
#define concat(a,b) concat_i(a ## b)
#define lockdep_set_subclass(lock, subclass) \
({ static struct lock_key_class __key; \
lockdep_init_map(&(lock)->dep_map, concat(lock, subclass), \
&__key, subclass); })
On 10/6/06, Peter Zijlstra <[email protected]> wrote:
> > - how about adding lockdep_set_subclass() to avoid littering source
> > with struct lock_class_key when we only want to tweak subclass? For
> > that we might want export register_lock_class and hide it behind a
> > #define...
> >
>
> or something like this:
>
> #define concat_i(a) #a
> #define concat(a,b) concat_i(a ## b)
>
> #define lockdep_set_subclass(lock, subclass) \
> ({ static struct lock_key_class __key; \
> lockdep_init_map(&(lock)->dep_map, concat(lock, subclass), \
> &__key, subclass); })
>
That leaves unneeded __key (another one was already created by
mutex_init...) but it tucked away nicely in the define so it is fune
by me.
Ingo, do you want to send these changes on or you want me to push them
through my tree?
--
Dmitry
* Dmitry Torokhov <[email protected]> wrote:
> >#define lockdep_set_subclass(lock, subclass) \
> > ({ static struct lock_key_class __key; \
> > lockdep_init_map(&(lock)->dep_map, concat(lock, subclass), \
> > &__key, subclass); })
>
> That leaves unneeded __key (another one was already created by
> mutex_init...) but it tucked away nicely in the define so it is fine
> by me.
>
> Ingo, do you want to send these changes on or you want me to push them
> through my tree?
could you send that commit to Andrew? It looks good to me, and the
unavailability of the lockdep_set_subclass() API upstream is hindering
Jiri now.
Ingo