[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
> On 10/24/2012 01:14 PM, Arend van Spriel wrote:
>> On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
>>> I have this lockdep warning on wireless-testing tree based
>>> on 3.7-rc1 (no other patches except wireless bits).
>>>
>>> =
>>> Restarting tasks ... done.
>>> [ INFO: possible recursive locking detected ]
>>> 3.7.0-rc1-wl+ #2 Not tainted
>>> -
>>> Xorg/2269 is trying to acquire lock:
>>> (>mutex){+.+.+.}, at: []
>>> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
>>>
>>> but task is already holding lock:
>>> (>mutex){+.+.+.}, at: []
>>> nouveau_abi16_get+0x34/0x100 [nouveau]
>>>
>>
>> I have observed the same bug so I built and tested v3.7-rc2 tag with
>> lockdep enabled. It has the same problem and it results in a failure to
>> resume after suspend. See below.
>>
>> Gr. AvS
>
> digging into the trace:
>
>
> nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the
> mutex. Assume this should protect the chan variable passed to
> nouveau_gem_pushbuf_validate(), which does a bit more that validate as
> it ends up in nouveau_bo_move_m2mf() which uses the drm->chan. However,
> it deadlocks before that.
>
> Gr. AvS
I reverted the two drm merges:
ceb736c Merge branch 'drm-nouveau-fixes' of
git://anongit.freedesktop.org/git/no
612a9aa Merge branch 'drm-next' of
git://people.freedesktop.org/~airlied/linux
It is not surprising that it solved the deadlock (doing pm_test).
Unfortunately, suspend/resume still does not work. System goes to sleep
just fine, but when trying to resume the BIOS kicks in and system boots
instead of waking up.
Gr. AvS
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
> On 10/24/2012 01:14 PM, Arend van Spriel wrote:
>> On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
>>> I have this lockdep warning on wireless-testing tree based
>>> on 3.7-rc1 (no other patches except wireless bits).
>>>
>>> =
>>> Restarting tasks ... done.
>>> [ INFO: possible recursive locking detected ]
>>> 3.7.0-rc1-wl+ #2 Not tainted
>>> -
>>> Xorg/2269 is trying to acquire lock:
>>> (>mutex){+.+.+.}, at: []
>>> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
>>>
>>> but task is already holding lock:
>>> (>mutex){+.+.+.}, at: []
>>> nouveau_abi16_get+0x34/0x100 [nouveau]
>>>
>>
>> I have observed the same bug so I built and tested v3.7-rc2 tag with
>> lockdep enabled. It has the same problem and it results in a failure to
>> resume after suspend. See below.
>>
>> Gr. AvS
>
> digging into the trace:
>
>
> nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the
> mutex. Assume this should protect the chan variable passed to
> nouveau_gem_pushbuf_validate(), which does a bit more that validate as
> it ends up in nouveau_bo_move_m2mf() which uses the drm->chan. However,
> it deadlocks before that.
>
> Gr. AvS
Maybe this helps. The two locations where the lock is grabbed are from
the same commit (see below).
Gr. AvS
commit ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69
Author: Ben Skeggs
Date: Fri Jul 20 08:17:34 2012 +1000
drm/nouveau: port all engines to new engine module format
This is a HUGE commit, but it's not nearly as bad as it looks - any
problems
can be isolated to a particular chipset and engine combination. It was
simply too difficult to port each one at a time, the compat layers are
*already* ridiculous.
Most of the changes here are simply to the glue, the process for
each of the
engine modules was to start with a standard skeleton and copy+paste
the old
code into the appropriate places, fixing up variable names etc as
needed.
v2: Marcin Slusarz
- fix find/replace bug in license header
v3: Ben Skeggs
- bump indirect pushbuf size to 8KiB, 4KiB barely enough for
userspace and
left no space for kernel's requirements during GEM pushbuf
submission.
- fix duplicate assignments noticed by clang
v4: Marcin Slusarz
- add sparse annotations to nv04_fifo_pause/nv04_fifo_start
- use ioread32_native/iowrite32_native for fifo control registers
v5: Ben Skeggs
- rebase on v3.6-rc4, modified to keep copy engine fix intact
- nv10/fence: unmap fence bo before destroying
- fixed fermi regression when using nvidia gr fuc
- fixed typo in supported dma_mask checking
Signed-off-by: Ben Skeggs
Re: [BUG 3.7-rc1] nouveau cli-mutex possible recursive locking detected
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
(cli-mutex){+.+.+.}, at: [a012a27f]
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
but task is already holding lock:
(cli-mutex){+.+.+.}, at: [a012f3c4] nouveau_abi16_get+0x34/0x100
[nouveau]
I have observed the same bug so I built and tested v3.7-rc2 tag with
lockdep enabled. It has the same problem and it results in a failure to
resume after suspend. See below.
Gr. AvS
[ 76.272795] PM: suspend of devices complete after 2149.188 msecs
[ 76.273110] PM: suspend devices took 2.152 seconds
[ 76.273354] suspend debug: Waiting for 5 seconds.
[ 81.233082] ehci_hcd :00:1a.0: setting latency timer to 64
[ 81.233369] ehci_hcd :00:1d.0: setting latency timer to 64
[ 81.233422] pci :00:1e.0: setting latency timer to 64
[ 81.248934] e1000e :00:19.0: wake-up capability disabled by ACPI
[ 81.249398] e1000e :00:19.0: irq 41 for MSI/MSI-X
[ 81.249903] ahci :00:1f.2: setting latency timer to 64
[ 81.249982] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X
[ 81.250515] nouveau [ DRM] re-enabling device...
[ 81.250548] nouveau [ DRM] resuming client object trees...
[ 81.250557] nouveau [ VBIOS][:01:00.0] running init tables
[ 81.701998] nouveau [ DRM] resuming display...
[ 81.803923] firewire_core :04:00.4: rediscovered device fw0
[ 81.823913] dell_wmi: Received unknown WMI event (0x11)
[ 81.824521] serial 00:08: activated
[ 82.135333] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 82.187115] ata6: SATA link down (SStatus 0 SControl 300)
[ 82.232290] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 82.284002] ata5: SATA link down (SStatus 0 SControl 300)
[ 82.330629] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by
device (Stat=0x51 Err=0x04)
[ 82.408079] ata2.00: configured for UDMA/133
[ 84.073571] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 84.127965] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by
device (Stat=0x51 Err=0x04)
[ 84.202292] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 84.254039] ata1.00: configured for UDMA/133
[ 84.303718] sd 0:0:0:0: [sda] Starting disk
[ 84.360186] PM: resume of devices complete after 3132.774 msecs
[ 84.410322] PM: resume devices took 3.180 seconds
[ 84.449642] PM: Finishing wakeup.
[ 84.505964]
[ 84.506716] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx
[ 84.477326] Restarting tasks ... done.
[ 84.575294] video LNXVIDEO:00: Restoring backlight state
[ 84.623825] =
[ 84.623825] [ INFO: possible recursive locking detected ]
[ 84.623826] 3.7.0-rc2-testing-lockdep #1 Not tainted
[ 84.623827] -
[ 84.623827] Xorg/1369 is trying to acquire lock:
[ 84.623828] (cli-mutex){+.+.+.}, at: [f8974ca8]
nouveau_bo_move_m2mf.isra.13+0x38/0x120 [nouveau]
[ 84.623856]
[ 84.623856] but task is already holding lock:
[ 84.623856] (cli-mutex){+.+.+.}, at: [f8979346]
nouveau_abi16_get+0x26/0x110 [nouveau]
[ 84.623871]
[ 84.623871] other info that might help us debug this:
[ 84.623872] Possible unsafe locking scenario:
[ 84.623872]
[ 84.623872]CPU0
[ 84.623872]
[ 84.623873] lock(cli-mutex);
[ 84.623874] lock(cli-mutex);
[ 84.623874]
[ 84.623874] *** DEADLOCK ***
[ 84.623874]
[ 84.623874] May be due to missing lock nesting notation
[ 84.623874]
[ 84.623875] 1 lock held by Xorg/1369:
[ 84.623889] #0: (cli-mutex){+.+.+.}, at: [f8979346]
nouveau_abi16_get+0x26/0x110 [nouveau]
[ 84.623890]
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG 3.7-rc1] nouveau cli-mutex possible recursive locking detected
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
(cli-mutex){+.+.+.}, at: [a012a27f]
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
but task is already holding lock:
(cli-mutex){+.+.+.}, at: [a012f3c4]
nouveau_abi16_get+0x34/0x100 [nouveau]
I have observed the same bug so I built and tested v3.7-rc2 tag with
lockdep enabled. It has the same problem and it results in a failure to
resume after suspend. See below.
Gr. AvS
digging into the trace:
nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the
mutex. Assume this should protect the chan variable passed to
nouveau_gem_pushbuf_validate(), which does a bit more that validate as
it ends up in nouveau_bo_move_m2mf() which uses the drm-chan. However,
it deadlocks before that.
Gr. AvS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG 3.7-rc1] nouveau cli-mutex possible recursive locking detected
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
(cli-mutex){+.+.+.}, at: [a012a27f]
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
but task is already holding lock:
(cli-mutex){+.+.+.}, at: [a012f3c4]
nouveau_abi16_get+0x34/0x100 [nouveau]
I have observed the same bug so I built and tested v3.7-rc2 tag with
lockdep enabled. It has the same problem and it results in a failure to
resume after suspend. See below.
Gr. AvS
digging into the trace:
nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the
mutex. Assume this should protect the chan variable passed to
nouveau_gem_pushbuf_validate(), which does a bit more that validate as
it ends up in nouveau_bo_move_m2mf() which uses the drm-chan. However,
it deadlocks before that.
Gr. AvS
Maybe this helps. The two locations where the lock is grabbed are from
the same commit (see below).
Gr. AvS
commit ebb945a94bba2ce8dff7b0942ff2b3f2a52a0a69
Author: Ben Skeggs bske...@redhat.com
Date: Fri Jul 20 08:17:34 2012 +1000
drm/nouveau: port all engines to new engine module format
This is a HUGE commit, but it's not nearly as bad as it looks - any
problems
can be isolated to a particular chipset and engine combination. It was
simply too difficult to port each one at a time, the compat layers are
*already* ridiculous.
Most of the changes here are simply to the glue, the process for
each of the
engine modules was to start with a standard skeleton and copy+paste
the old
code into the appropriate places, fixing up variable names etc as
needed.
v2: Marcin Slusarz marcin.slus...@gmail.com
- fix find/replace bug in license header
v3: Ben Skeggs bske...@redhat.com
- bump indirect pushbuf size to 8KiB, 4KiB barely enough for
userspace and
left no space for kernel's requirements during GEM pushbuf
submission.
- fix duplicate assignments noticed by clang
v4: Marcin Slusarz marcin.slus...@gmail.com
- add sparse annotations to nv04_fifo_pause/nv04_fifo_start
- use ioread32_native/iowrite32_native for fifo control registers
v5: Ben Skeggs bske...@redhat.com
- rebase on v3.6-rc4, modified to keep copy engine fix intact
- nv10/fence: unmap fence bo before destroying
- fixed fermi regression when using nvidia gr fuc
- fixed typo in supported dma_mask checking
Signed-off-by: Ben Skeggs bske...@redhat.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG 3.7-rc1] nouveau cli-mutex possible recursive locking detected
On 10/24/2012 02:45 PM, Arend van Spriel wrote:
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
(cli-mutex){+.+.+.}, at: [a012a27f]
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
but task is already holding lock:
(cli-mutex){+.+.+.}, at: [a012f3c4]
nouveau_abi16_get+0x34/0x100 [nouveau]
I have observed the same bug so I built and tested v3.7-rc2 tag with
lockdep enabled. It has the same problem and it results in a failure to
resume after suspend. See below.
Gr. AvS
digging into the trace:
nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the
mutex. Assume this should protect the chan variable passed to
nouveau_gem_pushbuf_validate(), which does a bit more that validate as
it ends up in nouveau_bo_move_m2mf() which uses the drm-chan. However,
it deadlocks before that.
Gr. AvS
I reverted the two drm merges:
ceb736c Merge branch 'drm-nouveau-fixes' of
git://anongit.freedesktop.org/git/no
612a9aa Merge branch 'drm-next' of
git://people.freedesktop.org/~airlied/linux
It is not surprising that it solved the deadlock (doing pm_test).
Unfortunately, suspend/resume still does not work. System goes to sleep
just fine, but when trying to resume the BIOS kicks in and system boots
instead of waking up.
Gr. AvS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
> On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
>> I have this lockdep warning on wireless-testing tree based
>> on 3.7-rc1 (no other patches except wireless bits).
>>
>> =
>> Restarting tasks ... done.
>> [ INFO: possible recursive locking detected ]
>> 3.7.0-rc1-wl+ #2 Not tainted
>> -
>> Xorg/2269 is trying to acquire lock:
>> (>mutex){+.+.+.}, at: []
>> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
>>
>> but task is already holding lock:
>> (>mutex){+.+.+.}, at: []
>> nouveau_abi16_get+0x34/0x100 [nouveau]
>>
>
> I have observed the same bug so I built and tested v3.7-rc2 tag with
> lockdep enabled. It has the same problem and it results in a failure to
> resume after suspend. See below.
>
> Gr. AvS
digging into the trace:
nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the
mutex. Assume this should protect the chan variable passed to
nouveau_gem_pushbuf_validate(), which does a bit more that validate as
it ends up in nouveau_bo_move_m2mf() which uses the drm->chan. However,
it deadlocks before that.
Gr. AvS
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
> I have this lockdep warning on wireless-testing tree based
> on 3.7-rc1 (no other patches except wireless bits).
>
> =
> Restarting tasks ... done.
> [ INFO: possible recursive locking detected ]
> 3.7.0-rc1-wl+ #2 Not tainted
> -
> Xorg/2269 is trying to acquire lock:
> (>mutex){+.+.+.}, at: []
> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
>
> but task is already holding lock:
> (>mutex){+.+.+.}, at: []
> nouveau_abi16_get+0x34/0x100 [nouveau]
>
I have observed the same bug so I built and tested v3.7-rc2 tag with
lockdep enabled. It has the same problem and it results in a failure to
resume after suspend. See below.
Gr. AvS
[ 76.272795] PM: suspend of devices complete after 2149.188 msecs
[ 76.273110] PM: suspend devices took 2.152 seconds
[ 76.273354] suspend debug: Waiting for 5 seconds.
[ 81.233082] ehci_hcd :00:1a.0: setting latency timer to 64
[ 81.233369] ehci_hcd :00:1d.0: setting latency timer to 64
[ 81.233422] pci :00:1e.0: setting latency timer to 64
[ 81.248934] e1000e :00:19.0: wake-up capability disabled by ACPI
[ 81.249398] e1000e :00:19.0: irq 41 for MSI/MSI-X
[ 81.249903] ahci :00:1f.2: setting latency timer to 64
[ 81.249982] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X
[ 81.250515] nouveau [ DRM] re-enabling device...
[ 81.250548] nouveau [ DRM] resuming client object trees...
[ 81.250557] nouveau [ VBIOS][:01:00.0] running init tables
[ 81.701998] nouveau [ DRM] resuming display...
[ 81.803923] firewire_core :04:00.4: rediscovered device fw0
[ 81.823913] dell_wmi: Received unknown WMI event (0x11)
[ 81.824521] serial 00:08: activated
[ 82.135333] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 82.187115] ata6: SATA link down (SStatus 0 SControl 300)
[ 82.232290] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 82.284002] ata5: SATA link down (SStatus 0 SControl 300)
[ 82.330629] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by
device (Stat=0x51 Err=0x04)
[ 82.408079] ata2.00: configured for UDMA/133
[ 84.073571] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 84.127965] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by
device (Stat=0x51 Err=0x04)
[ 84.202292] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 84.254039] ata1.00: configured for UDMA/133
[ 84.303718] sd 0:0:0:0: [sda] Starting disk
[ 84.360186] PM: resume of devices complete after 3132.774 msecs
[ 84.410322] PM: resume devices took 3.180 seconds
[ 84.449642] PM: Finishing wakeup.
[ 84.505964]
[ 84.506716] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx
[ 84.477326] Restarting tasks ... done.
[ 84.575294] video LNXVIDEO:00: Restoring backlight state
[ 84.623825] =
[ 84.623825] [ INFO: possible recursive locking detected ]
[ 84.623826] 3.7.0-rc2-testing-lockdep #1 Not tainted
[ 84.623827] -
[ 84.623827] Xorg/1369 is trying to acquire lock:
[ 84.623828] (>mutex){+.+.+.}, at: []
nouveau_bo_move_m2mf.isra.13+0x38/0x120 [nouveau]
[ 84.623856]
[ 84.623856] but task is already holding lock:
[ 84.623856] (>mutex){+.+.+.}, at: []
nouveau_abi16_get+0x26/0x110 [nouveau]
[ 84.623871]
[ 84.623871] other info that might help us debug this:
[ 84.623872] Possible unsafe locking scenario:
[ 84.623872]
[ 84.623872]CPU0
[ 84.623872]
[ 84.623873] lock(>mutex);
[ 84.623874] lock(>mutex);
[ 84.623874]
[ 84.623874] *** DEADLOCK ***
[ 84.623874]
[ 84.623874] May be due to missing lock nesting notation
[ 84.623874]
[ 84.623875] 1 lock held by Xorg/1369:
[ 84.623889] #0: (>mutex){+.+.+.}, at: []
nouveau_abi16_get+0x26/0x110 [nouveau]
[ 84.623890]
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
(>mutex){+.+.+.}, at: []
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
but task is already holding lock:
(>mutex){+.+.+.}, at: [] nouveau_abi16_get+0x34/0x100
[nouveau]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>mutex);
lock(>mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by Xorg/2269:
#0: (>mutex){+.+.+.}, at: []
nouveau_abi16_get+0x34/0x100 [nouveau]
stack backtrace:
Pid: 2269, comm: Xorg Not tainted 3.7.0-rc1-wl+ #2
Call Trace:
[] print_deadlock_bug+0xf4/0x100
[] validate_chain+0x549/0x7e0
[] __lock_acquire+0x367/0x580
[] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[] lock_acquire+0xa4/0x120
[] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[] ? _raw_spin_unlock_irqrestore+0x40/0x80
[] __mutex_lock_common+0x47/0x3f0
[] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[] ? nv84_graph_tlb_flush+0x291/0x2b0 [nouveau]
[] ? _nouveau_gpuobj_wr32+0x26/0x30 [nouveau]
[] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[] mutex_lock_nested+0x37/0x50
[] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[] nouveau_bo_move+0xe3/0x330 [nouveau]
[] ttm_bo_handle_move_mem+0x2bd/0x670 [ttm]
[] ttm_bo_move_buffer+0x12e/0x150 [ttm]
[] ttm_bo_validate+0x99/0x130 [ttm]
[] nouveau_bo_validate+0x23/0x30 [nouveau]
[] validate_list+0xae/0x2c0 [nouveau]
[] nouveau_gem_pushbuf_validate+0xa2/0x1e0 [nouveau]
[] nouveau_gem_ioctl_pushbuf+0x22c/0x8a0 [nouveau]
[] drm_ioctl+0x355/0x570 [drm]
[] ? do_sync_read+0xaa/0xf0
[] ? nouveau_gem_pushbuf_validate+0x1e0/0x1e0 [nouveau]
[] do_vfs_ioctl+0x8c/0x350
[] ? sysret_check+0x22/0x5d
[] sys_ioctl+0xa1/0xb0
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] system_call_fastpath+0x16/0x1b
[BUG 3.7-rc1] nouveau cli-mutex possible recursive locking detected
I have this lockdep warning on wireless-testing tree based
on 3.7-rc1 (no other patches except wireless bits).
=
Restarting tasks ... done.
[ INFO: possible recursive locking detected ]
3.7.0-rc1-wl+ #2 Not tainted
-
Xorg/2269 is trying to acquire lock:
(cli-mutex){+.+.+.}, at: [a012a27f]
nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
but task is already holding lock:
(cli-mutex){+.+.+.}, at: [a012f3c4] nouveau_abi16_get+0x34/0x100
[nouveau]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(cli-mutex);
lock(cli-mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by Xorg/2269:
#0: (cli-mutex){+.+.+.}, at: [a012f3c4]
nouveau_abi16_get+0x34/0x100 [nouveau]
stack backtrace:
Pid: 2269, comm: Xorg Not tainted 3.7.0-rc1-wl+ #2
Call Trace:
[810bbc24] print_deadlock_bug+0xf4/0x100
[810bdba9] validate_chain+0x549/0x7e0
[810be1a7] __lock_acquire+0x367/0x580
[a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[810be464] lock_acquire+0xa4/0x120
[a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[8156c860] ? _raw_spin_unlock_irqrestore+0x40/0x80
[81569217] __mutex_lock_common+0x47/0x3f0
[a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[a011dd61] ? nv84_graph_tlb_flush+0x291/0x2b0 [nouveau]
[a00b4be6] ? _nouveau_gpuobj_wr32+0x26/0x30 [nouveau]
[a012a27f] ? nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[815696e7] mutex_lock_nested+0x37/0x50
[a012a27f] nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
[a012a783] nouveau_bo_move+0xe3/0x330 [nouveau]
[a009619d] ttm_bo_handle_move_mem+0x2bd/0x670 [ttm]
[a0098a1e] ttm_bo_move_buffer+0x12e/0x150 [ttm]
[a0098ad9] ttm_bo_validate+0x99/0x130 [ttm]
[a012add3] nouveau_bo_validate+0x23/0x30 [nouveau]
[a012cd8e] validate_list+0xae/0x2c0 [nouveau]
[a012dec2] nouveau_gem_pushbuf_validate+0xa2/0x1e0 [nouveau]
[a012e22c] nouveau_gem_ioctl_pushbuf+0x22c/0x8a0 [nouveau]
[a002c465] drm_ioctl+0x355/0x570 [drm]
[8119349a] ? do_sync_read+0xaa/0xf0
[a012e000] ? nouveau_gem_pushbuf_validate+0x1e0/0x1e0 [nouveau]
[811a579c] do_vfs_ioctl+0x8c/0x350
[81575745] ? sysret_check+0x22/0x5d
[811a5b01] sys_ioctl+0xa1/0xb0
[81291eee] ? trace_hardirqs_on_thunk+0x3a/0x3f
[81575719] system_call_fastpath+0x16/0x1b
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
