From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Hurley Subject: Re: 3.8-rc2: lockdep warning in nouveau driver Date: Tue, 29 Jan 2013 09:56:40 -0500 Message-ID: <1359471400.4985.5.camel@thor.lan> References: <50ED5874.5010209@broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50ED5874.5010209@broadcom.com> Sender: linux-kernel-owner@vger.kernel.org To: Ben Skeggs Cc: dri-devel@lists.freedesktop.org, "linux-kernel@vger.kernel.org" , Arend van Spriel List-Id: dri-devel@lists.freedesktop.org On Wed, 2013-01-09 at 12:45 +0100, Arend van Spriel wrote: > Maybe this one is already known, but I did not find a post about it. So > here it is. > > Regards, > Arend [snip] > [ 9.589986] ============================================= > [ 9.595365] [ INFO: possible recursive locking detected ] > [ 9.600745] 3.8.0-rc2-wl-testing-lockdep-00002-ga524cf0 #1 Not tainted > [ 9.607248] --------------------------------------------- > [ 9.612626] modprobe/163 is trying to acquire lock: > [ 9.617486] (&subdev->mutex){+.+.+.}, at: [] > nv50_fb_vram_new+0x92/0x230 [nouveau] > [ 9.626052] > [ 9.626052] but task is already holding lock: > [ 9.631865] (&subdev->mutex){+.+.+.}, at: [] > nv50_disp_data_ctor+0x55/0xc0 [nouveau] > [ 9.640593] > [ 9.640593] other info that might help us debug this: > [ 9.647096] Possible unsafe locking scenario: > [ 9.647096] > [ 9.652995] CPU0 > [ 9.655430] ---- > [ 9.657867] lock(&subdev->mutex); > [ 9.661365] lock(&subdev->mutex); > [ 9.664863] > [ 9.664863] *** DEADLOCK *** > [ 9.664863] > [ 9.670762] May be due to missing lock nesting notation Same. [ 5.995881] ============================================= [ 5.995886] [ INFO: possible recursive locking detected ] [ 5.995892] 3.8.0-next-20130125+ttypatch-xeon+lockdep #20130125+ttypatch Not tainted [ 5.995898] --------------------------------------------- [ 5.995904] modprobe/275 is trying to acquire lock: [ 5.995909] (&subdev->mutex){+.+.+.}, at: [] nouveau_instobj_create_+0x48/0x90 [nouveau] [ 5.995955] [ 5.995955] but task is already holding lock: [ 5.995961] (&subdev->mutex){+.+.+.}, at: [] nv50_disp_data_ctor+0x65/0xd0 [nouveau] [ 5.995989] [ 5.995989] other info that might help us debug this: [ 5.995995] Possible unsafe locking scenario: [ 5.995995] [ 5.996001] CPU0 [ 5.996004] ---- [ 5.996005] lock(&subdev->mutex); [ 5.996005] lock(&subdev->mutex); [ 5.996005] [ 5.996005] *** DEADLOCK *** Regards, Peter Hurley