[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected

Arend van Spriel arend at broadcom.com
Thu Oct 25 03:14:46 PDT 2012

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: [<ffffffffa012a27f>]
>>> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
>>> but task is already holding lock:
>>>   (&cli->mutex){+.+.+.}, at: [<ffffffffa012f3c4>]
>>> 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 
612a9aa Merge branch 'drm-next' of 

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

More information about the dri-devel mailing list