mmotm 2010-07-27 - nouveau lockdep issues.
On Wed, Jul 28, 2010 at 01:42:03AM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Tue, 27 Jul 2010 14:56:50 PDT, akpm at linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
> >
> >http://userweb.kernel.org/~akpm/mmotm/
>
> Hit this while the X server was on its way down during a 'shutdown -r now'.
> Worked fine
> in -rc5-mmotm0719. 'e16' is the Enlightenment window manager, if that matters.
>
> [ 93.181787] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 99.802836] [drm] nouveau :01:00.0: Allocating FIFO number 4
> [ 99.808875] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised
> FIFO 4
> [ 103.262226] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 113.341948] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 123.421836] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 123.550520] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo
> 4
> [ 123.551253]
> [ 123.551253] ==
> [ 123.551253] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> [ 123.551253] 2.6.35-rc6-mmotm0727 #1
> [ 123.551253] --
> [ 123.551253] e16/3822 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> [ 123.551253] (&(&mm->unused_lock)->rlock){+.+...}, at:
> [] drm_mm_put_block+0x10e/0x142
> [ 123.551253]
> [ 123.551253] and this task is already holding:
> [ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.}, at:
> [] nouveau_channel_free+0x10f/0x233
> [ 123.551253] which would create a new lock dependency:
> [ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.} ->
> (&(&mm->unused_lock)->rlock){+.+...}
> [ 123.551253]
It's only theoritcal issue. If you want to quiet it down until it will be
"fixed" properly, you can
apply patch from
http://lists.freedesktop.org/archives/nouveau/2010-July/005994.html
Marcin
mmotm 2010-07-27 - nouveau lockdep issues.
On Tue, 27 Jul 2010 14:56:50 PDT, akpm at linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
>
>http://userweb.kernel.org/~akpm/mmotm/
Hit this while the X server was on its way down during a 'shutdown -r now'.
Worked fine
in -rc5-mmotm0719. 'e16' is the Enlightenment window manager, if that matters.
[ 93.181787] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 99.802836] [drm] nouveau :01:00.0: Allocating FIFO number 4
[ 99.808875] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised
FIFO 4
[ 103.262226] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 113.341948] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 123.421836] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 123.550520] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 4
[ 123.551253]
[ 123.551253] ==
[ 123.551253] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 123.551253] 2.6.35-rc6-mmotm0727 #1
[ 123.551253] --
[ 123.551253] e16/3822 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 123.551253] (&(&mm->unused_lock)->rlock){+.+...}, at: []
drm_mm_put_block+0x10e/0x142
[ 123.551253]
[ 123.551253] and this task is already holding:
[ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.}, at:
[] nouveau_channel_free+0x10f/0x233
[ 123.551253] which would create a new lock dependency:
[ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.} ->
(&(&mm->unused_lock)->rlock){+.+...}
[ 123.551253]
[ 123.551253] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.}
[ 123.551253] ... which became HARDIRQ-irq-safe at:
[ 123.551253] [] __lock_acquire+0x301/0xd6a
[ 123.551253] [] lock_acquire+0x10a/0x130
[ 123.551253] [] _raw_spin_lock_irqsave+0x44/0x57
[ 123.551253] [] nouveau_irq_handler+0x63/0x1920
[ 123.551253] [] handle_IRQ_event+0xad/0x213
[ 123.551253] [] handle_fasteoi_irq+0xd1/0x115
[ 123.551253] [] handle_irq+0x122/0x133
[ 123.551253] [] do_IRQ+0x57/0xaf
[ 123.551253]
[ 123.604031] [drm] nouveau :01:00.0: GPU lockup - switching to software
fbcon
[ 123.604031] [] ret_from_intr+0x0/0xf
[ 123.604031] [] cpu_idle+0x85/0x169
[ 123.604031] [] start_secondary+0x1b1/0x1b5
[ 123.604031]
[ 123.604031] to a HARDIRQ-irq-unsafe lock:
[ 123.604031] (&(&mm->unused_lock)->rlock){+.+...}
[ 123.604031] ... which became HARDIRQ-irq-unsafe at:
[ 123.604031] ... [] __lock_acquire+0x382/0xd6a
[ 123.604031] [] lock_acquire+0x10a/0x130
[ 123.604031] [] _raw_spin_lock+0x36/0x45
[ 123.604031] [] drm_mm_pre_get+0x24/0xb2
[ 123.604031] [] ttm_bo_init+0x1fe/0x3c0
[ 123.604031] [] nouveau_bo_new+0x3ae/0x423
[ 123.604031] [] nouveau_mem_init+0x293/0x487
[ 123.604031] [] nouveau_card_init+0xa5e/0xd52
[ 123.604031] [] nouveau_load+0x519/0x528
[ 123.604031] [] drm_get_pci_dev+0x174/0x26a
[ 123.604031] [] nouveau_pci_probe+0x10/0x12
[ 123.604031] [] local_pci_probe+0x3f/0x70
[ 123.604031] [] pci_device_probe+0x65/0x96
[ 123.604031] [] driver_probe_device+0xe8/0x182
[ 123.604031] [] __driver_attach+0x4a/0x6b
[ 123.604031] [] bus_for_each_dev+0x57/0x83
[ 123.604031] [] driver_attach+0x19/0x1b
[ 123.604031] [] bus_add_driver+0xae/0x205
[ 123.604031] [] driver_register+0xb5/0x122
[ 123.604031] [] __pci_register_driver+0x61/0xcd
[ 123.604031] [] drm_pci_init+0x31/0x98
[ 123.604031] [] drm_init+0x5d/0x61
[ 123.604031] [] nouveau_init+0x48/0x4a
[ 123.604031] [] do_one_initcall+0x7a/0x12f
[ 123.604031] [] kernel_init+0x138/0x1c2
[ 123.604031] [] kernel_thread_helper+0x4/0x10
[ 123.604031]
[ 123.604031] other info that might help us debug this:
[ 123.604031]
[ 123.604031] 1 lock held by e16/3822:
[ 123.604031] #0: (&(&dev_priv->context_switch_lock)->rlock){-.}, at:
[] nouveau_channel_free+0x10f/0x233
[ 123.604031]
[ 123.604031] the dependencies between HARDIRQ-irq-safe lock and the holding
lock:
[ 123.604031] -> (&(&dev_priv->context_switch_lock)->rlock){-.} ops: 15 {
[ 123.604031]IN-HARDIRQ-W at:
[ 123.604031][]
__lock_acquire+0x301/0xd6a
[ 123.604031][]
lock_acquire+0x10a/0x130
[ 123.604031][]
_raw_spin_lock_irqsave+0x44/0x57
[ 123.604031][]
nouveau_irq_handler+0x63/0x1920
[ 123.604031][]
handle_IRQ_event+0xad/0x213
[ 123.604031][]
handle_fasteoi_irq+0xd1/0x115
[ 123.604031][]
handle_irq+0x122/0x133
[ 123.604031][]
do_IRQ+0x57/0xaf
[ 123.604031
mmotm 2010-07-27 - nouveau lockdep issues.
On Tue, 27 Jul 2010 14:56:50 PDT, a...@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
>
>http://userweb.kernel.org/~akpm/mmotm/
Hit this while the X server was on its way down during a 'shutdown -r now'.
Worked fine
in -rc5-mmotm0719. 'e16' is the Enlightenment window manager, if that matters.
[ 93.181787] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 99.802836] [drm] nouveau :01:00.0: Allocating FIFO number 4
[ 99.808875] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised
FIFO 4
[ 103.262226] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 113.341948] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 123.421836] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
[ 123.550520] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 4
[ 123.551253]
[ 123.551253] ==
[ 123.551253] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 123.551253] 2.6.35-rc6-mmotm0727 #1
[ 123.551253] --
[ 123.551253] e16/3822 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 123.551253] (&(&mm->unused_lock)->rlock){+.+...}, at: []
drm_mm_put_block+0x10e/0x142
[ 123.551253]
[ 123.551253] and this task is already holding:
[ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.}, at:
[] nouveau_channel_free+0x10f/0x233
[ 123.551253] which would create a new lock dependency:
[ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.} ->
(&(&mm->unused_lock)->rlock){+.+...}
[ 123.551253]
[ 123.551253] but this new dependency connects a HARDIRQ-irq-safe lock:
[ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.}
[ 123.551253] ... which became HARDIRQ-irq-safe at:
[ 123.551253] [] __lock_acquire+0x301/0xd6a
[ 123.551253] [] lock_acquire+0x10a/0x130
[ 123.551253] [] _raw_spin_lock_irqsave+0x44/0x57
[ 123.551253] [] nouveau_irq_handler+0x63/0x1920
[ 123.551253] [] handle_IRQ_event+0xad/0x213
[ 123.551253] [] handle_fasteoi_irq+0xd1/0x115
[ 123.551253] [] handle_irq+0x122/0x133
[ 123.551253] [] do_IRQ+0x57/0xaf
[ 123.551253]
[ 123.604031] [drm] nouveau :01:00.0: GPU lockup - switching to software
fbcon
[ 123.604031] [] ret_from_intr+0x0/0xf
[ 123.604031] [] cpu_idle+0x85/0x169
[ 123.604031] [] start_secondary+0x1b1/0x1b5
[ 123.604031]
[ 123.604031] to a HARDIRQ-irq-unsafe lock:
[ 123.604031] (&(&mm->unused_lock)->rlock){+.+...}
[ 123.604031] ... which became HARDIRQ-irq-unsafe at:
[ 123.604031] ... [] __lock_acquire+0x382/0xd6a
[ 123.604031] [] lock_acquire+0x10a/0x130
[ 123.604031] [] _raw_spin_lock+0x36/0x45
[ 123.604031] [] drm_mm_pre_get+0x24/0xb2
[ 123.604031] [] ttm_bo_init+0x1fe/0x3c0
[ 123.604031] [] nouveau_bo_new+0x3ae/0x423
[ 123.604031] [] nouveau_mem_init+0x293/0x487
[ 123.604031] [] nouveau_card_init+0xa5e/0xd52
[ 123.604031] [] nouveau_load+0x519/0x528
[ 123.604031] [] drm_get_pci_dev+0x174/0x26a
[ 123.604031] [] nouveau_pci_probe+0x10/0x12
[ 123.604031] [] local_pci_probe+0x3f/0x70
[ 123.604031] [] pci_device_probe+0x65/0x96
[ 123.604031] [] driver_probe_device+0xe8/0x182
[ 123.604031] [] __driver_attach+0x4a/0x6b
[ 123.604031] [] bus_for_each_dev+0x57/0x83
[ 123.604031] [] driver_attach+0x19/0x1b
[ 123.604031] [] bus_add_driver+0xae/0x205
[ 123.604031] [] driver_register+0xb5/0x122
[ 123.604031] [] __pci_register_driver+0x61/0xcd
[ 123.604031] [] drm_pci_init+0x31/0x98
[ 123.604031] [] drm_init+0x5d/0x61
[ 123.604031] [] nouveau_init+0x48/0x4a
[ 123.604031] [] do_one_initcall+0x7a/0x12f
[ 123.604031] [] kernel_init+0x138/0x1c2
[ 123.604031] [] kernel_thread_helper+0x4/0x10
[ 123.604031]
[ 123.604031] other info that might help us debug this:
[ 123.604031]
[ 123.604031] 1 lock held by e16/3822:
[ 123.604031] #0: (&(&dev_priv->context_switch_lock)->rlock){-.}, at:
[] nouveau_channel_free+0x10f/0x233
[ 123.604031]
[ 123.604031] the dependencies between HARDIRQ-irq-safe lock and the holding
lock:
[ 123.604031] -> (&(&dev_priv->context_switch_lock)->rlock){-.} ops: 15 {
[ 123.604031]IN-HARDIRQ-W at:
[ 123.604031][]
__lock_acquire+0x301/0xd6a
[ 123.604031][]
lock_acquire+0x10a/0x130
[ 123.604031][]
_raw_spin_lock_irqsave+0x44/0x57
[ 123.604031][]
nouveau_irq_handler+0x63/0x1920
[ 123.604031][]
handle_IRQ_event+0xad/0x213
[ 123.604031][]
handle_fasteoi_irq+0xd1/0x115
[ 123.604031][]
handle_irq+0x122/0x133
[ 123.604031][]
do_IRQ+0x57/0xaf
[ 123.604031]
Re: mmotm 2010-07-27 - nouveau lockdep issues.
On Wed, Jul 28, 2010 at 01:42:03AM -0400, valdis.kletni...@vt.edu wrote:
> On Tue, 27 Jul 2010 14:56:50 PDT, a...@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-07-27-14-56 has been uploaded to
> >
> >http://userweb.kernel.org/~akpm/mmotm/
>
> Hit this while the X server was on its way down during a 'shutdown -r now'.
> Worked fine
> in -rc5-mmotm0719. 'e16' is the Enlightenment window manager, if that matters.
>
> [ 93.181787] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 99.802836] [drm] nouveau :01:00.0: Allocating FIFO number 4
> [ 99.808875] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised
> FIFO 4
> [ 103.262226] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 113.341948] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 123.421836] [drm:output_poll_execute] *ERROR* delayed enqueue failed 1
> [ 123.550520] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo
> 4
> [ 123.551253]
> [ 123.551253] ==
> [ 123.551253] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> [ 123.551253] 2.6.35-rc6-mmotm0727 #1
> [ 123.551253] --
> [ 123.551253] e16/3822 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> [ 123.551253] (&(&mm->unused_lock)->rlock){+.+...}, at:
> [] drm_mm_put_block+0x10e/0x142
> [ 123.551253]
> [ 123.551253] and this task is already holding:
> [ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.}, at:
> [] nouveau_channel_free+0x10f/0x233
> [ 123.551253] which would create a new lock dependency:
> [ 123.551253] (&(&dev_priv->context_switch_lock)->rlock){-.} ->
> (&(&mm->unused_lock)->rlock){+.+...}
> [ 123.551253]
It's only theoritcal issue. If you want to quiet it down until it will be
"fixed" properly, you can
apply patch from
http://lists.freedesktop.org/archives/nouveau/2010-July/005994.html
Marcin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
