INFO: possible recursive locking detected ps2_command - Kernel

This is a discussion on INFO: possible recursive locking detected ps2_command - Kernel ; Hi During mouse unplugging from psaux connector from the laptops' docking station I've got attached INFO trace. (laptops still has synaptics device) Also for unknown reason to me psaux mouse & synaptic device do not work somehow together - is ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: INFO: possible recursive locking detected ps2_command

  1. INFO: possible recursive locking detected ps2_command

    Hi

    During mouse unplugging from psaux connector from the laptops' docking
    station I've got attached INFO trace.
    (laptops still has synaptics device)

    Also for unknown reason to me psaux mouse & synaptic device do not
    work somehow together - is it hw limitation
    of /dev/input/mice interface?
    (USB mouse and synaptics do work quite well together)

    [ INFO: possible recursive locking detected ]
    2.6.27-rc1 #48
    ---------------------------------------------
    kseriod/166 is trying to acquire lock:
    (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460

    but task is already holding lock:
    (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460

    other info that might help us debug this:
    4 locks held by kseriod/166:
    #0: (serio_mutex){--..}, at: [] serio_thread+0x3e/0x410
    #1: (&serio->drv_mutex){--..}, at: []
    serio_connect_driver+0x2b/0x50
    #2: (psmouse_mutex){--..}, at: []
    psmouse_connect+0x30/0x2c0 [psmouse]
    #3: (&ps2dev->cmd_mutex){--..}, at: []
    ps2_command+0x5e/0x460

    stack backtrace:
    Pid: 166, comm: kseriod Not tainted 2.6.27-rc1 #48

    Call Trace:
    [] __lock_acquire+0xcea/0x13b0
    [] ? trace_hardirqs_off_caller+0x21/0xc0
    [] ? trace_hardirqs_off+0xd/0x10
    [] ? ps2_command+0x5e/0x460
    [] lock_acquire+0x96/0xe0
    [] ? ps2_command+0x5e/0x460
    [] mutex_lock_nested+0xc1/0x340
    [] ? ps2_command+0x5e/0x460
    [] ? native_sched_clock+0x90/0xb0
    [] ps2_command+0x5e/0x460
    [] ? trace_hardirqs_off_caller+0x21/0xc0
    [] ? get_lock_stats+0x34/0x70
    [] psmouse_sliced_command+0x2d/0x90 [psmouse]
    [] ? ps2_sendbyte+0x48/0x130
    [] synaptics_pt_write+0x27/0x60 [psmouse]
    [] ? _spin_unlock_irq+0x3d/0x80
    [] ps2_sendbyte+0x5d/0x130
    [] ? sub_preempt_count+0x80/0x120
    [] ps2_command+0xfd/0x460
    [] ? sub_preempt_count+0x80/0x120
    [] ? _spin_unlock_irq+0x3d/0x80
    [] psmouse_probe+0x27/0xa0 [psmouse]
    [] ? serio_open+0x11/0x50
    [] psmouse_connect+0x178/0x2c0 [psmouse]
    [] serio_connect_driver+0x36/0x50
    [] serio_driver_probe+0x1b/0x20
    [] driver_probe_device+0xa2/0x1e0
    [] ? __device_attach+0x0/0x10
    [] __device_attach+0x9/0x10
    [] bus_for_each_drv+0x6b/0xa0
    [] device_attach+0x88/0x90
    [] bus_attach_device+0x55/0x80
    [] device_add+0x4f9/0x610
    [] ? sub_preempt_count+0x80/0x120
    [] serio_thread+0x23c/0x410
    [] ? autoremove_wake_function+0x0/0x40
    [] ? serio_thread+0x0/0x410
    [] kthread+0x49/0x90
    [] child_rip+0xa/0x11
    [] ? finish_task_switch+0x57/0x110
    [] ? _spin_unlock_irq+0x3d/0x80
    [] ? restore_args+0x0/0x30
    [] ? trace_hardirqs_off+0xd/0x10
    [] ? kthread+0x0/0x90
    [] ? child_rip+0x0/0x11
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: INFO: possible recursive locking detected ps2_command


    (cc linux-input)

    On Thu, 31 Jul 2008 11:41:25 +0200
    "Zdenek Kabelac" wrote:

    > Hi
    >
    > During mouse unplugging from psaux connector from the laptops' docking
    > station I've got attached INFO trace.
    > (laptops still has synaptics device)
    >
    > Also for unknown reason to me psaux mouse & synaptic device do not
    > work somehow together - is it hw limitation
    > of /dev/input/mice interface?
    > (USB mouse and synaptics do work quite well together)
    >
    > [ INFO: possible recursive locking detected ]
    > 2.6.27-rc1 #48


    (it's 2.6.27-rc1)

    > ---------------------------------------------
    > kseriod/166 is trying to acquire lock:
    > (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460
    >
    > but task is already holding lock:
    > (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460
    >
    > other info that might help us debug this:
    > 4 locks held by kseriod/166:
    > #0: (serio_mutex){--..}, at: [] serio_thread+0x3e/0x410
    > #1: (&serio->drv_mutex){--..}, at: []
    > serio_connect_driver+0x2b/0x50
    > #2: (psmouse_mutex){--..}, at: []
    > psmouse_connect+0x30/0x2c0 [psmouse]
    > #3: (&ps2dev->cmd_mutex){--..}, at: []
    > ps2_command+0x5e/0x460
    >
    > stack backtrace:
    > Pid: 166, comm: kseriod Not tainted 2.6.27-rc1 #48
    >
    > Call Trace:
    > [] __lock_acquire+0xcea/0x13b0
    > [] ? trace_hardirqs_off_caller+0x21/0xc0
    > [] ? trace_hardirqs_off+0xd/0x10
    > [] ? ps2_command+0x5e/0x460
    > [] lock_acquire+0x96/0xe0
    > [] ? ps2_command+0x5e/0x460
    > [] mutex_lock_nested+0xc1/0x340
    > [] ? ps2_command+0x5e/0x460
    > [] ? native_sched_clock+0x90/0xb0
    > [] ps2_command+0x5e/0x460
    > [] ? trace_hardirqs_off_caller+0x21/0xc0
    > [] ? get_lock_stats+0x34/0x70
    > [] psmouse_sliced_command+0x2d/0x90 [psmouse]
    > [] ? ps2_sendbyte+0x48/0x130
    > [] synaptics_pt_write+0x27/0x60 [psmouse]
    > [] ? _spin_unlock_irq+0x3d/0x80
    > [] ps2_sendbyte+0x5d/0x130
    > [] ? sub_preempt_count+0x80/0x120
    > [] ps2_command+0xfd/0x460
    > [] ? sub_preempt_count+0x80/0x120
    > [] ? _spin_unlock_irq+0x3d/0x80
    > [] psmouse_probe+0x27/0xa0 [psmouse]
    > [] ? serio_open+0x11/0x50
    > [] psmouse_connect+0x178/0x2c0 [psmouse]
    > [] serio_connect_driver+0x36/0x50
    > [] serio_driver_probe+0x1b/0x20
    > [] driver_probe_device+0xa2/0x1e0
    > [] ? __device_attach+0x0/0x10
    > [] __device_attach+0x9/0x10
    > [] bus_for_each_drv+0x6b/0xa0
    > [] device_attach+0x88/0x90
    > [] bus_attach_device+0x55/0x80
    > [] device_add+0x4f9/0x610
    > [] ? sub_preempt_count+0x80/0x120
    > [] serio_thread+0x23c/0x410
    > [] ? autoremove_wake_function+0x0/0x40
    > [] ? serio_thread+0x0/0x410
    > [] kthread+0x49/0x90
    > [] child_rip+0xa/0x11
    > [] ? finish_task_switch+0x57/0x110
    > [] ? _spin_unlock_irq+0x3d/0x80
    > [] ? restore_args+0x0/0x30
    > [] ? trace_hardirqs_off+0xd/0x10
    > [] ? kthread+0x0/0x90
    > [] ? child_rip+0x0/0x11


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: INFO: possible recursive locking detected ps2_command

    On Thu, Jul 31, 2008 at 02:57:39PM -0700, Andrew Morton wrote:
    >
    > (cc linux-input)
    >
    > On Thu, 31 Jul 2008 11:41:25 +0200
    > "Zdenek Kabelac" wrote:
    >
    > > Hi
    > >
    > > During mouse unplugging from psaux connector from the laptops' docking
    > > station I've got attached INFO trace.
    > > (laptops still has synaptics device)
    > >


    Dell?

    > > Also for unknown reason to me psaux mouse & synaptic device do not
    > > work somehow together - is it hw limitation
    > > of /dev/input/mice interface?
    > > (USB mouse and synaptics do work quite well together)
    > >
    > > [ INFO: possible recursive locking detected ]
    > > 2.6.27-rc1 #48

    >
    > (it's 2.6.27-rc1)
    >


    Peter, here is the trace we talked about long time ago. For some reason
    lockdep annotation only works once. If reconnect is forced or psmouse
    module is reloaded lockdep starts complaining about passthrough port.

    > > ---------------------------------------------
    > > kseriod/166 is trying to acquire lock:
    > > (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460
    > >
    > > but task is already holding lock:
    > > (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460
    > >
    > > other info that might help us debug this:
    > > 4 locks held by kseriod/166:
    > > #0: (serio_mutex){--..}, at: [] serio_thread+0x3e/0x410
    > > #1: (&serio->drv_mutex){--..}, at: []
    > > serio_connect_driver+0x2b/0x50
    > > #2: (psmouse_mutex){--..}, at: []
    > > psmouse_connect+0x30/0x2c0 [psmouse]
    > > #3: (&ps2dev->cmd_mutex){--..}, at: []
    > > ps2_command+0x5e/0x460
    > >
    > > stack backtrace:
    > > Pid: 166, comm: kseriod Not tainted 2.6.27-rc1 #48
    > >
    > > Call Trace:
    > > [] __lock_acquire+0xcea/0x13b0
    > > [] ? trace_hardirqs_off_caller+0x21/0xc0
    > > [] ? trace_hardirqs_off+0xd/0x10
    > > [] ? ps2_command+0x5e/0x460
    > > [] lock_acquire+0x96/0xe0
    > > [] ? ps2_command+0x5e/0x460
    > > [] mutex_lock_nested+0xc1/0x340
    > > [] ? ps2_command+0x5e/0x460
    > > [] ? native_sched_clock+0x90/0xb0
    > > [] ps2_command+0x5e/0x460
    > > [] ? trace_hardirqs_off_caller+0x21/0xc0
    > > [] ? get_lock_stats+0x34/0x70
    > > [] psmouse_sliced_command+0x2d/0x90 [psmouse]
    > > [] ? ps2_sendbyte+0x48/0x130
    > > [] synaptics_pt_write+0x27/0x60 [psmouse]
    > > [] ? _spin_unlock_irq+0x3d/0x80
    > > [] ps2_sendbyte+0x5d/0x130
    > > [] ? sub_preempt_count+0x80/0x120
    > > [] ps2_command+0xfd/0x460
    > > [] ? sub_preempt_count+0x80/0x120
    > > [] ? _spin_unlock_irq+0x3d/0x80
    > > [] psmouse_probe+0x27/0xa0 [psmouse]
    > > [] ? serio_open+0x11/0x50
    > > [] psmouse_connect+0x178/0x2c0 [psmouse]
    > > [] serio_connect_driver+0x36/0x50
    > > [] serio_driver_probe+0x1b/0x20
    > > [] driver_probe_device+0xa2/0x1e0
    > > [] ? __device_attach+0x0/0x10
    > > [] __device_attach+0x9/0x10
    > > [] bus_for_each_drv+0x6b/0xa0
    > > [] device_attach+0x88/0x90
    > > [] bus_attach_device+0x55/0x80
    > > [] device_add+0x4f9/0x610
    > > [] ? sub_preempt_count+0x80/0x120
    > > [] serio_thread+0x23c/0x410
    > > [] ? autoremove_wake_function+0x0/0x40
    > > [] ? serio_thread+0x0/0x410
    > > [] kthread+0x49/0x90
    > > [] child_rip+0xa/0x11
    > > [] ? finish_task_switch+0x57/0x110
    > > [] ? _spin_unlock_irq+0x3d/0x80
    > > [] ? restore_args+0x0/0x30
    > > [] ? trace_hardirqs_off+0xd/0x10
    > > [] ? kthread+0x0/0x90
    > > [] ? child_rip+0x0/0x11

    >
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-input" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html


    --
    Dmitry
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: INFO: possible recursive locking detected ps2_command

    On Thu, 2008-07-31 at 23:04 -0400, Dmitry Torokhov wrote:
    > On Thu, Jul 31, 2008 at 02:57:39PM -0700, Andrew Morton wrote:
    > >
    > > (cc linux-input)
    > >
    > > On Thu, 31 Jul 2008 11:41:25 +0200
    > > "Zdenek Kabelac" wrote:
    > >
    > > > Hi
    > > >
    > > > During mouse unplugging from psaux connector from the laptops' docking
    > > > station I've got attached INFO trace.
    > > > (laptops still has synaptics device)
    > > >

    >
    > Dell?
    >
    > > > Also for unknown reason to me psaux mouse & synaptic device do not
    > > > work somehow together - is it hw limitation
    > > > of /dev/input/mice interface?
    > > > (USB mouse and synaptics do work quite well together)
    > > >
    > > > [ INFO: possible recursive locking detected ]
    > > > 2.6.27-rc1 #48

    > >
    > > (it's 2.6.27-rc1)
    > >

    >
    > Peter, here is the trace we talked about long time ago. For some reason
    > lockdep annotation only works once. If reconnect is forced or psmouse
    > module is reloaded lockdep starts complaining about passthrough port.


    Bit puzzling - and I don't have any ps2 hardware around to test with
    (nor do I normally use modules - but that is fixable of course).

    Does Rabin's patch help?

    http://lkml.org/lkml/2008/8/7/329

    > > > ---------------------------------------------
    > > > kseriod/166 is trying to acquire lock:
    > > > (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460
    > > >
    > > > but task is already holding lock:
    > > > (&ps2dev->cmd_mutex){--..}, at: [] ps2_command+0x5e/0x460
    > > >
    > > > other info that might help us debug this:
    > > > 4 locks held by kseriod/166:
    > > > #0: (serio_mutex){--..}, at: [] serio_thread+0x3e/0x410
    > > > #1: (&serio->drv_mutex){--..}, at: []
    > > > serio_connect_driver+0x2b/0x50
    > > > #2: (psmouse_mutex){--..}, at: []
    > > > psmouse_connect+0x30/0x2c0 [psmouse]
    > > > #3: (&ps2dev->cmd_mutex){--..}, at: []
    > > > ps2_command+0x5e/0x460
    > > >
    > > > stack backtrace:
    > > > Pid: 166, comm: kseriod Not tainted 2.6.27-rc1 #48
    > > >
    > > > Call Trace:
    > > > [] __lock_acquire+0xcea/0x13b0
    > > > [] ? trace_hardirqs_off_caller+0x21/0xc0
    > > > [] ? trace_hardirqs_off+0xd/0x10
    > > > [] ? ps2_command+0x5e/0x460
    > > > [] lock_acquire+0x96/0xe0
    > > > [] ? ps2_command+0x5e/0x460
    > > > [] mutex_lock_nested+0xc1/0x340
    > > > [] ? ps2_command+0x5e/0x460
    > > > [] ? native_sched_clock+0x90/0xb0
    > > > [] ps2_command+0x5e/0x460
    > > > [] ? trace_hardirqs_off_caller+0x21/0xc0
    > > > [] ? get_lock_stats+0x34/0x70
    > > > [] psmouse_sliced_command+0x2d/0x90 [psmouse]
    > > > [] ? ps2_sendbyte+0x48/0x130
    > > > [] synaptics_pt_write+0x27/0x60 [psmouse]
    > > > [] ? _spin_unlock_irq+0x3d/0x80
    > > > [] ps2_sendbyte+0x5d/0x130
    > > > [] ? sub_preempt_count+0x80/0x120
    > > > [] ps2_command+0xfd/0x460
    > > > [] ? sub_preempt_count+0x80/0x120
    > > > [] ? _spin_unlock_irq+0x3d/0x80
    > > > [] psmouse_probe+0x27/0xa0 [psmouse]
    > > > [] ? serio_open+0x11/0x50
    > > > [] psmouse_connect+0x178/0x2c0 [psmouse]
    > > > [] serio_connect_driver+0x36/0x50
    > > > [] serio_driver_probe+0x1b/0x20
    > > > [] driver_probe_device+0xa2/0x1e0
    > > > [] ? __device_attach+0x0/0x10
    > > > [] __device_attach+0x9/0x10
    > > > [] bus_for_each_drv+0x6b/0xa0
    > > > [] device_attach+0x88/0x90
    > > > [] bus_attach_device+0x55/0x80
    > > > [] device_add+0x4f9/0x610
    > > > [] ? sub_preempt_count+0x80/0x120
    > > > [] serio_thread+0x23c/0x410
    > > > [] ? autoremove_wake_function+0x0/0x40
    > > > [] ? serio_thread+0x0/0x410
    > > > [] kthread+0x49/0x90
    > > > [] child_rip+0xa/0x11
    > > > [] ? finish_task_switch+0x57/0x110
    > > > [] ? _spin_unlock_irq+0x3d/0x80
    > > > [] ? restore_args+0x0/0x30
    > > > [] ? trace_hardirqs_off+0xd/0x10
    > > > [] ? kthread+0x0/0x90
    > > > [] ? child_rip+0x0/0x11


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: INFO: possible recursive locking detected ps2_command

    On Fri, Aug 08, 2008 at 12:49:49PM +0200, Peter Zijlstra wrote:
    > On Thu, 2008-07-31 at 23:04 -0400, Dmitry Torokhov wrote:
    > > On Thu, Jul 31, 2008 at 02:57:39PM -0700, Andrew Morton wrote:
    > > >
    > > > (cc linux-input)
    > > >
    > > > On Thu, 31 Jul 2008 11:41:25 +0200
    > > > "Zdenek Kabelac" wrote:
    > > >
    > > > > Hi
    > > > >
    > > > > During mouse unplugging from psaux connector from the laptops' docking
    > > > > station I've got attached INFO trace.
    > > > > (laptops still has synaptics device)
    > > > >

    > >
    > > Dell?
    > >
    > > > > Also for unknown reason to me psaux mouse & synaptic device do not
    > > > > work somehow together - is it hw limitation
    > > > > of /dev/input/mice interface?
    > > > > (USB mouse and synaptics do work quite well together)
    > > > >
    > > > > [ INFO: possible recursive locking detected ]
    > > > > 2.6.27-rc1 #48
    > > >
    > > > (it's 2.6.27-rc1)
    > > >

    > >
    > > Peter, here is the trace we talked about long time ago. For some reason
    > > lockdep annotation only works once. If reconnect is forced or psmouse
    > > module is reloaded lockdep starts complaining about passthrough port.

    >
    > Bit puzzling - and I don't have any ps2 hardware around to test with
    > (nor do I normally use modules - but that is fixable of course).
    >
    > Does Rabin's patch help?
    >
    > http://lkml.org/lkml/2008/8/7/329
    >


    I doubt it resolves problem fully because it only takes care of module
    unload. I can easily trip lockdep by reconnecting the device. Just to
    give some more details about the problem:

    - synaptics touchpads have a pass-through port that allows to connect
    either external mouse or maybe a trackpoint device. Both devices
    are represented by 'serio' structures and are handled by the same
    driver (psmouse).

    - as far as I know we have proper locking there and lockdep
    annotatinos were added to lockdep to reflect the nesting of the
    serio ports.

    - if child port (pass-through port) is destroyed and recreated (due
    to module unload, or because user requested reconnect through sysfs
    or system-initiated reconnect) lockdep starts complaining although
    the new child port should still have the same "depth" as the old
    one.

    Thanks!

    --
    Dmitry
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread