i8042 lockdep false positive.

i8042 lockdep false positive.

[Dave Jones]

I just had a user file the report below, which iirc, was deemed a false
positive.  Didn't we add something to the code so that lockdep would
ignore what this was doing ?  Did we regress?

(This was .21-rc5, during resume)

	Dave

 > =============================================
 > [ INFO: possible recursive locking detected ]
 > 2.6.20-1.3062.fc7 #1
 > ---------------------------------------------
 > kseriod/216 is trying to acquire lock:
 >  (&ps2dev->cmd_mutex){--..}, at: [<c0614fa2>] mutex_lock+0x21/0x24
 > 
 > but task is already holding lock:
 >  (&ps2dev->cmd_mutex){--..}, at: [<c0614fa2>] mutex_lock+0x21/0x24
 > 
 > other info that might help us debug this:
 > 5 locks held by kseriod/216:
 >  #0:  (serio_mutex){--..}, at: [<c0614fa2>] mutex_lock+0x21/0x24
 >  #1:  (&s->rwsem){----}, at: [<c05882de>] serio_find_driver+0x13/0x50
 >  #2:  (&serio->drv_mutex){--..}, at: [<c0614fa2>] mutex_lock+0x21/0x24
 >  #3:  (psmouse_mutex){--..}, at: [<c0614fa2>] mutex_lock+0x21/0x24
 >  #4:  (&ps2dev->cmd_mutex){--..}, at: [<c0614fa2>] mutex_lock+0x21/0x24
 > 
 > stack backtrace:
 >  [<c04061e9>] show_trace_log_lvl+0x1a/0x2f
 >  [<c04067ad>] show_trace+0x12/0x14
 >  [<c0406831>] dump_stack+0x16/0x18
 >  [<c0442089>] __lock_acquire+0x11f/0xba4
 >  [<c0442f00>] lock_acquire+0x56/0x6f
 >  [<c0614e0a>] __mutex_lock_slowpath+0xf7/0x26e
 >  [<c0614fa2>] mutex_lock+0x21/0x24
 >  [<c058ad30>] ps2_command+0x92/0x319
 >  [<c05912d8>] psmouse_sliced_command+0x1c/0x5a
 >  [<c0594861>] synaptics_pt_write+0x1e/0x41
 >  [<c058ac0c>] ps2_sendbyte+0x39/0xcb
 >  [<c058adaa>] ps2_command+0x10c/0x319
 >  [<c0590f13>] psmouse_probe+0x1d/0x6c
 >  [<c0591f90>] psmouse_connect+0xed/0x205
 >  [<c05882a3>] serio_connect_driver+0x1e/0x2e
 >  [<c05882c9>] serio_driver_probe+0x16/0x18
 >  [<c0562b45>] really_probe+0xc7/0x150
 >  [<c0562c63>] driver_probe_device+0x95/0xa1
 >  [<c0562c77>] __device_attach+0x8/0xa
 >  [<c0562035>] bus_for_each_drv+0x3a/0x65
 >  [<c0562d00>] device_attach+0x68/0x7d
 >  [<c05882e9>] serio_find_driver+0x1e/0x50
 >  [<c0588f39>] serio_thread+0x153/0x2a6
 >  [<c043830f>] kthread+0xb3/0xdc
 >  [<c0405cd3>] kernel_thread_helper+0x7/0x10
 >  =======================


-- 
http://www.codemonkey.org.uk

Re: i8042 lockdep false positive.

[Dmitry Torokhov]

Hi Dave,

On 4/13/07, Dave Jones <davej@redhat.com> wrote:
> I just had a user file the report below, which iirc, was deemed a false
> positive.  Didn't we add something to the code so that lockdep would
> ignore what this was doing ?  Did we regress?
>

For some reasn lockdep annotations cease to work when you reload
psmouse module. I did not have time to look further.

-- 
Dmitry

Re: i8042 lockdep false positive.

[Dave Jones]

On Fri, Apr 13, 2007 at 03:18:32PM -0400, Dmitry Torokhov wrote:
 > Hi Dave,
 > 
 > On 4/13/07, Dave Jones <davej@redhat.com> wrote:
 > > I just had a user file the report below, which iirc, was deemed a false
 > > positive.  Didn't we add something to the code so that lockdep would
 > > ignore what this was doing ?  Did we regress?
 > >
 > 
 > For some reasn lockdep annotations cease to work when you reload
 > psmouse module. I did not have time to look further.

In the case reported, psmouse was non-modular.

	Dave

-- 
http://www.codemonkey.org.uk

Re: i8042 lockdep false positive.

[Dmitry Torokhov]

On 4/13/07, Dave Jones <davej@redhat.com> wrote:
> On Fri, Apr 13, 2007 at 03:18:32PM -0400, Dmitry Torokhov wrote:
>  > Hi Dave,
>  >
>  > On 4/13/07, Dave Jones <davej@redhat.com> wrote:
>  > > I just had a user file the report below, which iirc, was deemed a false
>  > > positive.  Didn't we add something to the code so that lockdep would
>  > > ignore what this was doing ?  Did we regress?
>  > >
>  >
>  > For some reasn lockdep annotations cease to work when you reload
>  > psmouse module. I did not have time to look further.
>
> In the case reported, psmouse was non-modular.
>

OK, I was not precise. Every time we destroy and re-create passthrough
port lockdep starts bitching. For some reason annotation works only
once.

I am more quirious why synaptics could not simply reconnect upon
resume and went into full-blown cleanup/find driver/connect cycle...

-- 
Dmitry