Re: [Nouveau] nouveau lockdep splat
On Sun, Mar 24, 2013 at 10:00:55PM +0400, Lijo Antony wrote: > Looks like this has been fixed in -rc4. Yep, it seems so here too. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 07:29 PM, Borislav Petkov wrote: On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote: # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb This is a merge commit which means something went wrong along the way of the bisection. Looks like this has been fixed in -rc4. -lijo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 07:29 PM, Borislav Petkov wrote: On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote: # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb This is a merge commit which means something went wrong along the way of the bisection. Looks like this has been fixed in -rc4. -lijo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On Sun, Mar 24, 2013 at 10:00:55PM +0400, Lijo Antony wrote: Looks like this has been fixed in -rc4. Yep, it seems so here too. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote: > # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch > 'drm-next' of git://people.freedesktop.org/~airlied/linux > git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb This is a merge commit which means something went wrong along the way of the bisection. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 10:35 AM, Lijo Antony wrote: I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git bisect in that mail is incorrect). While investigating, I found this issue was introduced during 3.9 merge window. For me this comes when I connect my TV via HDMI. FWIW, git bisect gave this log, git bisect start 'drivers/gpu/' # good: [e450fcc6669705ef49784080ac6dd8513df37763] drm/tegra: Add list of framebuffers to debugfs git bisect good e450fcc6669705ef49784080ac6dd8513df37763 # bad: [6dbe51c251a327e012439c4772097a13df43c5b8] Linux 3.9-rc1 git bisect bad 6dbe51c251a327e012439c4772097a13df43c5b8 # good: [bab588fcfb6335c767d811a8955979f5440328e0] Merge tag 'soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good bab588fcfb6335c767d811a8955979f5440328e0 # good: [be88298b0a3f771a4802f20c5e66af74bfd1dff1] drm/tilcdc: only build on arm git bisect good be88298b0a3f771a4802f20c5e66af74bfd1dff1 # bad: [4d53233a36fdda567cd4d080e27e1ee4b669ddd1] drm: don't use idr_remove_all() git bisect bad 4d53233a36fdda567cd4d080e27e1ee4b669ddd1 # good: [9afa3195b96da7d2320ec44d19fbfbded7a15571] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial git bisect good 9afa3195b96da7d2320ec44d19fbfbded7a15571 # good: [496ad9aa8ef448058e36ca7a787c61f2e63f0f54] new helper: file_inode(file) git bisect good 496ad9aa8ef448058e36ca7a787c61f2e63f0f54 # bad: [d895cb1af15c04c522a25c79cc429076987c089b] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad d895cb1af15c04c522a25c79cc429076987c089b # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb -lijo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 12:40 AM, Peter Hurley wrote: with the hope of having the right people on CC now (finally, thanks Lucas :-)), here's the same splat on -rc3. Someone better take a look soonish, please: Also happens in next (on nv50 hardware). I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git bisect in that mail is incorrect). While investigating, I found this issue was introduced during 3.9 merge window. For me this comes when I connect my TV via HDMI. But for a couple of tags during bisecting, I have seen the same during boot also. -lijo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 12:40 AM, Peter Hurley wrote: with the hope of having the right people on CC now (finally, thanks Lucas :-)), here's the same splat on -rc3. Someone better take a look soonish, please: Also happens in next (on nv50 hardware). I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git bisect in that mail is incorrect). While investigating, I found this issue was introduced during 3.9 merge window. For me this comes when I connect my TV via HDMI. But for a couple of tags during bisecting, I have seen the same during boot also. -lijo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On 03/20/2013 10:35 AM, Lijo Antony wrote: I think this is same as https://lkml.org/lkml/2013/3/16/143 (btw, git bisect in that mail is incorrect). While investigating, I found this issue was introduced during 3.9 merge window. For me this comes when I connect my TV via HDMI. FWIW, git bisect gave this log, git bisect start 'drivers/gpu/' # good: [e450fcc6669705ef49784080ac6dd8513df37763] drm/tegra: Add list of framebuffers to debugfs git bisect good e450fcc6669705ef49784080ac6dd8513df37763 # bad: [6dbe51c251a327e012439c4772097a13df43c5b8] Linux 3.9-rc1 git bisect bad 6dbe51c251a327e012439c4772097a13df43c5b8 # good: [bab588fcfb6335c767d811a8955979f5440328e0] Merge tag 'soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good bab588fcfb6335c767d811a8955979f5440328e0 # good: [be88298b0a3f771a4802f20c5e66af74bfd1dff1] drm/tilcdc: only build on arm git bisect good be88298b0a3f771a4802f20c5e66af74bfd1dff1 # bad: [4d53233a36fdda567cd4d080e27e1ee4b669ddd1] drm: don't use idr_remove_all() git bisect bad 4d53233a36fdda567cd4d080e27e1ee4b669ddd1 # good: [9afa3195b96da7d2320ec44d19fbfbded7a15571] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial git bisect good 9afa3195b96da7d2320ec44d19fbfbded7a15571 # good: [496ad9aa8ef448058e36ca7a787c61f2e63f0f54] new helper: file_inode(file) git bisect good 496ad9aa8ef448058e36ca7a787c61f2e63f0f54 # bad: [d895cb1af15c04c522a25c79cc429076987c089b] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect bad d895cb1af15c04c522a25c79cc429076987c089b # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb -lijo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
On Wed, Mar 20, 2013 at 07:23:19PM +0400, Lijo Antony wrote: # bad: [fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad fffddfd6c8e0c10c42c6e2cc54ba880fcc36ebbb This is a merge commit which means something went wrong along the way of the bisection. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] nouveau lockdep splat
[ adding Ben Skeggs and Dave Airlie ]
On Tue, 2013-03-19 at 21:24 +0100, Borislav Petkov wrote:
> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> > Dropping Tegra ML, it's not the place where Nouveau mails should go.
> > Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
>
> Ok,
>
> with the hope of having the right people on CC now (finally, thanks
> Lucas :-)), here's the same splat on -rc3. Someone better take a look
> soonish, please:
Also happens in next (on nv50 hardware).
> [0.541078] [drm] No driver support for vblank timestamp query.
> [0.541272] nouveau [ DRM] 3 available performance level(s)
> [0.541276] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz
> voltage 900mV
> [0.541280] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz
> voltage 900mV
> [0.541284] nouveau [ DRM] 3: core 520MHz shader 1230MHz memory
> 790MHz voltage 900mV
> [0.541287] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz
> voltage 900mV
> [0.559846] nouveau [ DRM] MM: using COPY for buffer copies
> [0.625371] nouveau [ DRM] allocated 1920x1080 fb: 0x7, bo
> 88043b54f000
> [0.625441] fbcon: nouveaufb (fb0) is primary device
> [0.62]
> [0.625556] =
> [0.625556] [ INFO: possible recursive locking detected ]
> [0.625557] 3.9.0-rc3+ #25 Not tainted
> [0.625557] -
> [0.625558] swapper/0/1 is trying to acquire lock:
> [0.625562] (>lock){+.+...}, at: []
> evo_wait+0x43/0xf0
> [0.625562]
> [0.625562] but task is already holding lock:
> [0.625564] (>lock){+.+...}, at: []
> evo_wait+0x43/0xf0
> [0.625565]
> [0.625565] other info that might help us debug this:
> [0.625565] Possible unsafe locking scenario:
> [0.625565]
> [0.625565]CPU0
> [0.625565]
> [0.625566] lock(>lock);
> [0.625567] lock(>lock);
> [0.625567]
> [0.625567] *** DEADLOCK ***
> [0.625567]
> [0.625567] May be due to missing lock nesting notation
> [0.625567]
> [0.625568] 10 locks held by swapper/0/1:
> [0.625570] #0: (&__lockdep_no_validate__){..}, at:
> [] __driver_attach+0x5b/0xb0
> [0.625572] #1: (&__lockdep_no_validate__){..}, at:
> [] __driver_attach+0x69/0xb0
> [0.625575] #2: (drm_global_mutex){+.+.+.}, at: []
> drm_get_pci_dev+0xc6/0x2d0
> [0.625578] #3: (registration_lock){+.+.+.}, at: []
> register_framebuffer+0x25/0x310
> [0.625581] #4: (_info->lock){+.+.+.}, at: []
> lock_fb_info+0x26/0x60
> [0.625583] #5: (console_lock){+.+.+.}, at: []
> register_framebuffer+0x1ba/0x310
> [0.625585] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
> [] __blocking_notifier_call_chain+0x42/0x80
> [0.625587] #7: (>mode_config.mutex){+.+.+.}, at:
> [] drm_modeset_lock_all+0x2a/0x70
> [0.625589] #8: (>mutex){+.+.+.}, at: []
> drm_modeset_lock_all+0x54/0x70
> [0.625591] #9: (>lock){+.+...}, at: []
> evo_wait+0x43/0xf0
> [0.625591]
> [0.625591] stack backtrace:
> [0.625592] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc3+ #25
> [0.625593] Call Trace:
> [0.625595] [] __lock_acquire+0x76b/0x1c20
> [0.625597] [] ? dcb_table+0x1ac/0x2a0
> [0.625599] [] lock_acquire+0x8a/0x120
> [0.625600] [] ? evo_wait+0x43/0xf0
> [0.625602] [] ? mutex_lock_nested+0x292/0x330
> [0.625603] [] mutex_lock_nested+0x6e/0x330
> [0.625605] [] ? evo_wait+0x43/0xf0
> [0.625606] [] ? mark_held_locks+0x9b/0x100
> [0.625607] [] evo_wait+0x43/0xf0
> [0.625609] [] nv50_display_flip_next+0x713/0x7a0
> [0.625611] [] ? mutex_unlock+0xe/0x10
> [0.625612] [] ? evo_kick+0x37/0x40
> [0.625613] [] nv50_crtc_commit+0x10e/0x230
> [0.625615] [] drm_crtc_helper_set_mode+0x365/0x510
> [0.625617] [] drm_crtc_helper_set_config+0xa4e/0xb70
> [0.625618] [] drm_mode_set_config_internal+0x31/0x70
> [0.625619] [] drm_fb_helper_set_par+0x71/0xf0
> [0.625621] [] fbcon_init+0x514/0x5a0
> [0.625623] [] visual_init+0xbc/0x120
> [0.625624] [] do_bind_con_driver+0x163/0x320
> [0.625625] [] do_take_over_console+0x61/0x70
> [0.625627] [] do_fbcon_takeover+0x63/0xc0
> [0.625628] [] fbcon_event_notify+0x5fd/0x700
> [0.625629] [] notifier_call_chain+0x4d/0x70
> [0.625630] [] __blocking_notifier_call_chain+0x58/0x80
> [0.625631] [] blocking_notifier_call_chain+0x16/0x20
> [0.625633] [] fb_notifier_call_chain+0x1b/0x20
> [0.625634] [] register_framebuffer+0x1c8/0x310
> [0.625635] [] drm_fb_helper_initial_config+0x371/0x520
> [0.625637] [] ?
> drm_fb_helper_single_add_all_connectors+0x47/0xf0
> [0.625639] [] ? kmem_cache_alloc_trace+0xee/0x150
> [0.625641] [] nouveau_fbcon_init+0x10e/0x160
> [0.625643] []
Re: nouveau lockdep splat
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's the same splat on -rc3. Someone better take a look
soonish, please:
[0.541078] [drm] No driver support for vblank timestamp query.
[0.541272] nouveau [ DRM] 3 available performance level(s)
[0.541276] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz
voltage 900mV
[0.541280] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.541284] nouveau [ DRM] 3: core 520MHz shader 1230MHz memory 790MHz
voltage 900mV
[0.541287] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.559846] nouveau [ DRM] MM: using COPY for buffer copies
[0.625371] nouveau [ DRM] allocated 1920x1080 fb: 0x7, bo
88043b54f000
[0.625441] fbcon: nouveaufb (fb0) is primary device
[0.62]
[0.625556] =
[0.625556] [ INFO: possible recursive locking detected ]
[0.625557] 3.9.0-rc3+ #25 Not tainted
[0.625557] -
[0.625558] swapper/0/1 is trying to acquire lock:
[0.625562] (>lock){+.+...}, at: []
evo_wait+0x43/0xf0
[0.625562]
[0.625562] but task is already holding lock:
[0.625564] (>lock){+.+...}, at: []
evo_wait+0x43/0xf0
[0.625565]
[0.625565] other info that might help us debug this:
[0.625565] Possible unsafe locking scenario:
[0.625565]
[0.625565]CPU0
[0.625565]
[0.625566] lock(>lock);
[0.625567] lock(>lock);
[0.625567]
[0.625567] *** DEADLOCK ***
[0.625567]
[0.625567] May be due to missing lock nesting notation
[0.625567]
[0.625568] 10 locks held by swapper/0/1:
[0.625570] #0: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x5b/0xb0
[0.625572] #1: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x69/0xb0
[0.625575] #2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xc6/0x2d0
[0.625578] #3: (registration_lock){+.+.+.}, at: []
register_framebuffer+0x25/0x310
[0.625581] #4: (_info->lock){+.+.+.}, at: []
lock_fb_info+0x26/0x60
[0.625583] #5: (console_lock){+.+.+.}, at: []
register_framebuffer+0x1ba/0x310
[0.625585] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[] __blocking_notifier_call_chain+0x42/0x80
[0.625587] #7: (>mode_config.mutex){+.+.+.}, at:
[] drm_modeset_lock_all+0x2a/0x70
[0.625589] #8: (>mutex){+.+.+.}, at: []
drm_modeset_lock_all+0x54/0x70
[0.625591] #9: (>lock){+.+...}, at: []
evo_wait+0x43/0xf0
[0.625591]
[0.625591] stack backtrace:
[0.625592] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc3+ #25
[0.625593] Call Trace:
[0.625595] [] __lock_acquire+0x76b/0x1c20
[0.625597] [] ? dcb_table+0x1ac/0x2a0
[0.625599] [] lock_acquire+0x8a/0x120
[0.625600] [] ? evo_wait+0x43/0xf0
[0.625602] [] ? mutex_lock_nested+0x292/0x330
[0.625603] [] mutex_lock_nested+0x6e/0x330
[0.625605] [] ? evo_wait+0x43/0xf0
[0.625606] [] ? mark_held_locks+0x9b/0x100
[0.625607] [] evo_wait+0x43/0xf0
[0.625609] [] nv50_display_flip_next+0x713/0x7a0
[0.625611] [] ? mutex_unlock+0xe/0x10
[0.625612] [] ? evo_kick+0x37/0x40
[0.625613] [] nv50_crtc_commit+0x10e/0x230
[0.625615] [] drm_crtc_helper_set_mode+0x365/0x510
[0.625617] [] drm_crtc_helper_set_config+0xa4e/0xb70
[0.625618] [] drm_mode_set_config_internal+0x31/0x70
[0.625619] [] drm_fb_helper_set_par+0x71/0xf0
[0.625621] [] fbcon_init+0x514/0x5a0
[0.625623] [] visual_init+0xbc/0x120
[0.625624] [] do_bind_con_driver+0x163/0x320
[0.625625] [] do_take_over_console+0x61/0x70
[0.625627] [] do_fbcon_takeover+0x63/0xc0
[0.625628] [] fbcon_event_notify+0x5fd/0x700
[0.625629] [] notifier_call_chain+0x4d/0x70
[0.625630] [] __blocking_notifier_call_chain+0x58/0x80
[0.625631] [] blocking_notifier_call_chain+0x16/0x20
[0.625633] [] fb_notifier_call_chain+0x1b/0x20
[0.625634] [] register_framebuffer+0x1c8/0x310
[0.625635] [] drm_fb_helper_initial_config+0x371/0x520
[0.625637] [] ?
drm_fb_helper_single_add_all_connectors+0x47/0xf0
[0.625639] [] ? kmem_cache_alloc_trace+0xee/0x150
[0.625641] [] nouveau_fbcon_init+0x10e/0x160
[0.625643] [] nouveau_drm_load+0x40a/0x5d0
[0.625644] [] ? device_register+0x1e/0x30
[0.625645] [] ? drm_sysfs_device_add+0x86/0xb0
[0.625647] [] drm_get_pci_dev+0x186/0x2d0
[0.625649] [] ? __pci_set_master+0x2b/0x90
[0.625650] [] nouveau_drm_probe+0x26a/0x2c0
[0.625652] [] ? pci_match_device+0xd5/0xe0
[0.625654] [] pci_device_probe+0x136/0x150
[
Re: nouveau lockdep splat
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's the same splat on -rc3. Someone better take a look
soonish, please:
[0.541078] [drm] No driver support for vblank timestamp query.
[0.541272] nouveau [ DRM] 3 available performance level(s)
[0.541276] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz
voltage 900mV
[0.541280] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.541284] nouveau [ DRM] 3: core 520MHz shader 1230MHz memory 790MHz
voltage 900mV
[0.541287] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.559846] nouveau [ DRM] MM: using COPY for buffer copies
[0.625371] nouveau [ DRM] allocated 1920x1080 fb: 0x7, bo
88043b54f000
[0.625441] fbcon: nouveaufb (fb0) is primary device
[0.62]
[0.625556] =
[0.625556] [ INFO: possible recursive locking detected ]
[0.625557] 3.9.0-rc3+ #25 Not tainted
[0.625557] -
[0.625558] swapper/0/1 is trying to acquire lock:
[0.625562] (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625562]
[0.625562] but task is already holding lock:
[0.625564] (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625565]
[0.625565] other info that might help us debug this:
[0.625565] Possible unsafe locking scenario:
[0.625565]
[0.625565]CPU0
[0.625565]
[0.625566] lock(dmac-lock);
[0.625567] lock(dmac-lock);
[0.625567]
[0.625567] *** DEADLOCK ***
[0.625567]
[0.625567] May be due to missing lock nesting notation
[0.625567]
[0.625568] 10 locks held by swapper/0/1:
[0.625570] #0: (__lockdep_no_validate__){..}, at:
[814337cb] __driver_attach+0x5b/0xb0
[0.625572] #1: (__lockdep_no_validate__){..}, at:
[814337d9] __driver_attach+0x69/0xb0
[0.625575] #2: (drm_global_mutex){+.+.+.}, at: [8135a8e6]
drm_get_pci_dev+0xc6/0x2d0
[0.625578] #3: (registration_lock){+.+.+.}, at: [812c8fc5]
register_framebuffer+0x25/0x310
[0.625581] #4: (fb_info-lock){+.+.+.}, at: [812c7ed6]
lock_fb_info+0x26/0x60
[0.625583] #5: (console_lock){+.+.+.}, at: [812c915a]
register_framebuffer+0x1ba/0x310
[0.625585] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[810695c2] __blocking_notifier_call_chain+0x42/0x80
[0.625587] #7: (dev-mode_config.mutex){+.+.+.}, at:
[8135e61a] drm_modeset_lock_all+0x2a/0x70
[0.625589] #8: (crtc-mutex){+.+.+.}, at: [8135e644]
drm_modeset_lock_all+0x54/0x70
[0.625591] #9: (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625591]
[0.625591] stack backtrace:
[0.625592] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc3+ #25
[0.625593] Call Trace:
[0.625595] [810953fb] __lock_acquire+0x76b/0x1c20
[0.625597] [8137f4ec] ? dcb_table+0x1ac/0x2a0
[0.625599] [81096e1a] lock_acquire+0x8a/0x120
[0.625600] [8141bb63] ? evo_wait+0x43/0xf0
[0.625602] [81615432] ? mutex_lock_nested+0x292/0x330
[0.625603] [8161520e] mutex_lock_nested+0x6e/0x330
[0.625605] [8141bb63] ? evo_wait+0x43/0xf0
[0.625606] [810976eb] ? mark_held_locks+0x9b/0x100
[0.625607] [8141bb63] evo_wait+0x43/0xf0
[0.625609] [8141e603] nv50_display_flip_next+0x713/0x7a0
[0.625611] [8161562e] ? mutex_unlock+0xe/0x10
[0.625612] [8141bc47] ? evo_kick+0x37/0x40
[0.625613] [8141e88e] nv50_crtc_commit+0x10e/0x230
[0.625615] [8134c295] drm_crtc_helper_set_mode+0x365/0x510
[0.625617] [8134d68e] drm_crtc_helper_set_config+0xa4e/0xb70
[0.625618] [8135f731] drm_mode_set_config_internal+0x31/0x70
[0.625619] [8134b791] drm_fb_helper_set_par+0x71/0xf0
[0.625621] [812d4234] fbcon_init+0x514/0x5a0
[0.625623] [8132cbfc] visual_init+0xbc/0x120
[0.625624] [8132f2b3] do_bind_con_driver+0x163/0x320
[0.625625] [8132f541] do_take_over_console+0x61/0x70
[0.625627] [812d2853] do_fbcon_takeover+0x63/0xc0
[0.625628] [812d652d] fbcon_event_notify+0x5fd/0x700
[0.625629] [8161c91d] notifier_call_chain+0x4d/0x70
[0.625630] [810695d8] __blocking_notifier_call_chain+0x58/0x80
[0.625631] [81069616] blocking_notifier_call_chain+0x16/0x20
[0.625633] [812c79cb] fb_notifier_call_chain+0x1b/0x20
[0.625634] [812c9168]
Re: [Nouveau] nouveau lockdep splat
[ adding Ben Skeggs and Dave Airlie ]
On Tue, 2013-03-19 at 21:24 +0100, Borislav Petkov wrote:
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Ok,
with the hope of having the right people on CC now (finally, thanks
Lucas :-)), here's the same splat on -rc3. Someone better take a look
soonish, please:
Also happens in next (on nv50 hardware).
[0.541078] [drm] No driver support for vblank timestamp query.
[0.541272] nouveau [ DRM] 3 available performance level(s)
[0.541276] nouveau [ DRM] 0: core 135MHz shader 270MHz memory 135MHz
voltage 900mV
[0.541280] nouveau [ DRM] 1: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.541284] nouveau [ DRM] 3: core 520MHz shader 1230MHz memory
790MHz voltage 900mV
[0.541287] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz
voltage 900mV
[0.559846] nouveau [ DRM] MM: using COPY for buffer copies
[0.625371] nouveau [ DRM] allocated 1920x1080 fb: 0x7, bo
88043b54f000
[0.625441] fbcon: nouveaufb (fb0) is primary device
[0.62]
[0.625556] =
[0.625556] [ INFO: possible recursive locking detected ]
[0.625557] 3.9.0-rc3+ #25 Not tainted
[0.625557] -
[0.625558] swapper/0/1 is trying to acquire lock:
[0.625562] (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625562]
[0.625562] but task is already holding lock:
[0.625564] (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625565]
[0.625565] other info that might help us debug this:
[0.625565] Possible unsafe locking scenario:
[0.625565]
[0.625565]CPU0
[0.625565]
[0.625566] lock(dmac-lock);
[0.625567] lock(dmac-lock);
[0.625567]
[0.625567] *** DEADLOCK ***
[0.625567]
[0.625567] May be due to missing lock nesting notation
[0.625567]
[0.625568] 10 locks held by swapper/0/1:
[0.625570] #0: (__lockdep_no_validate__){..}, at:
[814337cb] __driver_attach+0x5b/0xb0
[0.625572] #1: (__lockdep_no_validate__){..}, at:
[814337d9] __driver_attach+0x69/0xb0
[0.625575] #2: (drm_global_mutex){+.+.+.}, at: [8135a8e6]
drm_get_pci_dev+0xc6/0x2d0
[0.625578] #3: (registration_lock){+.+.+.}, at: [812c8fc5]
register_framebuffer+0x25/0x310
[0.625581] #4: (fb_info-lock){+.+.+.}, at: [812c7ed6]
lock_fb_info+0x26/0x60
[0.625583] #5: (console_lock){+.+.+.}, at: [812c915a]
register_framebuffer+0x1ba/0x310
[0.625585] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[810695c2] __blocking_notifier_call_chain+0x42/0x80
[0.625587] #7: (dev-mode_config.mutex){+.+.+.}, at:
[8135e61a] drm_modeset_lock_all+0x2a/0x70
[0.625589] #8: (crtc-mutex){+.+.+.}, at: [8135e644]
drm_modeset_lock_all+0x54/0x70
[0.625591] #9: (dmac-lock){+.+...}, at: [8141bb63]
evo_wait+0x43/0xf0
[0.625591]
[0.625591] stack backtrace:
[0.625592] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc3+ #25
[0.625593] Call Trace:
[0.625595] [810953fb] __lock_acquire+0x76b/0x1c20
[0.625597] [8137f4ec] ? dcb_table+0x1ac/0x2a0
[0.625599] [81096e1a] lock_acquire+0x8a/0x120
[0.625600] [8141bb63] ? evo_wait+0x43/0xf0
[0.625602] [81615432] ? mutex_lock_nested+0x292/0x330
[0.625603] [8161520e] mutex_lock_nested+0x6e/0x330
[0.625605] [8141bb63] ? evo_wait+0x43/0xf0
[0.625606] [810976eb] ? mark_held_locks+0x9b/0x100
[0.625607] [8141bb63] evo_wait+0x43/0xf0
[0.625609] [8141e603] nv50_display_flip_next+0x713/0x7a0
[0.625611] [8161562e] ? mutex_unlock+0xe/0x10
[0.625612] [8141bc47] ? evo_kick+0x37/0x40
[0.625613] [8141e88e] nv50_crtc_commit+0x10e/0x230
[0.625615] [8134c295] drm_crtc_helper_set_mode+0x365/0x510
[0.625617] [8134d68e] drm_crtc_helper_set_config+0xa4e/0xb70
[0.625618] [8135f731] drm_mode_set_config_internal+0x31/0x70
[0.625619] [8134b791] drm_fb_helper_set_par+0x71/0xf0
[0.625621] [812d4234] fbcon_init+0x514/0x5a0
[0.625623] [8132cbfc] visual_init+0xbc/0x120
[0.625624] [8132f2b3] do_bind_con_driver+0x163/0x320
[0.625625] [8132f541] do_take_over_console+0x61/0x70
[0.625627] [812d2853] do_fbcon_takeover+0x63/0xc0
[0.625628] [812d652d] fbcon_event_notify+0x5fd/0x700
[0.625629] [8161c91d] notifier_call_chain+0x4d/0x70
[0.625630]
Re: nouveau lockdep splat
On Wed, 2013-03-06 at 12:31 -0700, Stephen Warren wrote:
> On 03/06/2013 12:14 PM, Marcin Slusarz wrote:
> > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
> >> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
> >>> Dropping Tegra ML, it's not the place where Nouveau mails should go.
> >>
> >> $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
> >> ...
> >> linux-te...@vger.kernel.org (open list:TEGRA SUPPORT)
> >>
> >> Maybe get_maintainer.pl patterns need correction...
> >
> > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer:
> > allow
> > keywords to match filenames") of get_maintainer.pl which now can look at
> > file
> > contents...
>
> get_maintainer.pl could always look at file contents IIRC. The change
> was that I added keyword "tegra" to the Tegra section that now matches
> this file's contents.
>
> ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau
>
> ... might be a better invocation, although perhaps I should add an
> explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS.
Another option might be avoid overloading the "K:"
entry and use a different letter for the file name
pattern match (maybe "N") and avoid looking for
tegra in the file or patch without another specific
"K:" keyword match.
Maybe:
---
MAINTAINERS | 10 +++---
scripts/get_maintainer.pl | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..76e0223 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -96,10 +96,14 @@ Descriptions of section entries:
F: net/
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
+ N: Filename wildcard pattern match, for instance:
+ N: (?i)[^a-z]tegra
+ matches any filename with case insensitive "tegra" but not
+ any other word like integrate
K: Keyword perl extended regex pattern to match content in a
- patch or file, or an affected filename. For instance:
+ patch or file. For instance:
K: of_get_profile
- matches patch or file content, or filenames, that contain
+ matches patch or file content, that contain
"of_get_profile"
K: \b(printk|pr_(info|err))\b
matches patch or file content, or filenames, that contain one or
@@ -7866,7 +7870,7 @@ L:linux-te...@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
-K: (?i)[^a-z]tegra
+N: (?i)[^a-z]tegra
TEHUTI ETHERNET DRIVER
M: Andy Gospodarek
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 12:31:49PM -0700, Stephen Warren wrote: > get_maintainer.pl could always look at file contents IIRC. The change > was that I added keyword "tegra" to the Tegra section that now matches > this file's contents. > > ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau > > ... might be a better invocation, although perhaps I should add an > explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS. No, you should add a pattern which matches only tegra. If there's no such pattern, you should simply drop the "K:" thing. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 08:14:18PM +0100, Marcin Slusarz wrote: > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > > ... > > linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) > > > > Maybe get_maintainer.pl patterns need correction... > > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow > keywords to match filenames") of get_maintainer.pl which now can look at file > contents... > > TEGRA SUPPORT > M:Stephen Warren > L:linux-te...@vger.kernel.org > Q:http://patchwork.ozlabs.org/project/linux-tegra/list/ > T:git > git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git > S:Supported > K:(?i)[^a-z]tegra > > Note the last line and this: > > $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c > u32 rekey = 56; /* binary driver, and tegra constant */ > max_ac_packet -= 18; /* constant from tegra */ > > Fun. Yeah, and a lot of it, thanks for digging this out. So obviously this regex is a bit... unfortunate. Although the idea of grepping the files for unique patterns is not bad, I have to admit. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On 03/06/2013 12:14 PM, Marcin Slusarz wrote: > On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: >> On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: >>> Dropping Tegra ML, it's not the place where Nouveau mails should go. >> >> $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c >> ... >> linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) >> >> Maybe get_maintainer.pl patterns need correction... > > That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow > keywords to match filenames") of get_maintainer.pl which now can look at file > contents... get_maintainer.pl could always look at file contents IIRC. The change was that I added keyword "tegra" to the Tegra section that now matches this file's contents. ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau ... might be a better invocation, although perhaps I should add an explicit exclusion for "nouveau" to the Tegra section in MAINTAINERS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: > On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > > Dropping Tegra ML, it's not the place where Nouveau mails should go. > > $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c > ... > linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) > > Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 "get_maintainer: allow keywords to match filenames") of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M: Stephen Warren L: linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported K: (?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Marcin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 get_maintainer: allow keywords to match filenames) of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M: Stephen Warren swar...@wwwdotorg.org L: linux-te...@vger.kernel.org Q: http://patchwork.ozlabs.org/project/linux-tegra/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S: Supported K: (?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Marcin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On 03/06/2013 12:14 PM, Marcin Slusarz wrote: On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 get_maintainer: allow keywords to match filenames) of get_maintainer.pl which now can look at file contents... get_maintainer.pl could always look at file contents IIRC. The change was that I added keyword tegra to the Tegra section that now matches this file's contents. ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau ... might be a better invocation, although perhaps I should add an explicit exclusion for nouveau to the Tegra section in MAINTAINERS. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 08:14:18PM +0100, Marcin Slusarz wrote: On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote: On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... That's new feature (introduced in commit eb90d0855b75f8 get_maintainer: allow keywords to match filenames) of get_maintainer.pl which now can look at file contents... TEGRA SUPPORT M:Stephen Warren swar...@wwwdotorg.org L:linux-te...@vger.kernel.org Q:http://patchwork.ozlabs.org/project/linux-tegra/list/ T:git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git S:Supported K:(?i)[^a-z]tegra Note the last line and this: $ grep tegra drivers/gpu/drm/nouveau/nv50_display.c u32 rekey = 56; /* binary driver, and tegra constant */ max_ac_packet -= 18; /* constant from tegra */ Fun. Yeah, and a lot of it, thanks for digging this out. So obviously this regex is a bit... unfortunate. Although the idea of grepping the files for unique patterns is not bad, I have to admit. :-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, Mar 06, 2013 at 12:31:49PM -0700, Stephen Warren wrote: get_maintainer.pl could always look at file contents IIRC. The change was that I added keyword tegra to the Tegra section that now matches this file's contents. ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau ... might be a better invocation, although perhaps I should add an explicit exclusion for nouveau to the Tegra section in MAINTAINERS. No, you should add a pattern which matches only tegra. If there's no such pattern, you should simply drop the K: thing. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Wed, 2013-03-06 at 12:31 -0700, Stephen Warren wrote:
On 03/06/2013 12:14 PM, Marcin Slusarz wrote:
On Wed, Mar 06, 2013 at 01:04:29AM +0100, Borislav Petkov wrote:
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote:
Dropping Tegra ML, it's not the place where Nouveau mails should go.
$ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c
...
linux-te...@vger.kernel.org (open list:TEGRA SUPPORT)
Maybe get_maintainer.pl patterns need correction...
That's new feature (introduced in commit eb90d0855b75f8 get_maintainer:
allow
keywords to match filenames) of get_maintainer.pl which now can look at
file
contents...
get_maintainer.pl could always look at file contents IIRC. The change
was that I added keyword tegra to the Tegra section that now matches
this file's contents.
./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau
... might be a better invocation, although perhaps I should add an
explicit exclusion for nouveau to the Tegra section in MAINTAINERS.
Another option might be avoid overloading the K:
entry and use a different letter for the file name
pattern match (maybe N) and avoid looking for
tegra in the file or patch without another specific
K: keyword match.
Maybe:
---
MAINTAINERS | 10 +++---
scripts/get_maintainer.pl | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e95b1e9..76e0223 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -96,10 +96,14 @@ Descriptions of section entries:
F: net/
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
+ N: Filename wildcard pattern match, for instance:
+ N: (?i)[^a-z]tegra
+ matches any filename with case insensitive tegra but not
+ any other word like integrate
K: Keyword perl extended regex pattern to match content in a
- patch or file, or an affected filename. For instance:
+ patch or file. For instance:
K: of_get_profile
- matches patch or file content, or filenames, that contain
+ matches patch or file content, that contain
of_get_profile
K: \b(printk|pr_(info|err))\b
matches patch or file content, or filenames, that contain one or
@@ -7866,7 +7870,7 @@ L:linux-te...@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
-K: (?i)[^a-z]tegra
+N: (?i)[^a-z]tegra
TEHUTI ETHERNET DRIVER
M: Andy Gospodarek a...@greyhouse.net
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: > Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nouveau lockdep splat
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov:
> New -rc1, so let the stabilization games begin.
>
> I see the following on rc1, let me know if you need more info.
>
>
> [0.633617] =
> [0.633618] [ INFO: possible recursive locking detected ]
> [0.633618] 3.9.0-rc1 #2 Not tainted
> [0.633619] -
> [0.633619] swapper/0/1 is trying to acquire lock:
> [0.633623] (>lock){+.+...}, at: []
> evo_wait+0x43/0xf0
> [0.633624]
> [0.633624] but task is already holding lock:
> [0.633626] (>lock){+.+...}, at: []
> evo_wait+0x43/0xf0
> [0.633626]
> [0.633626] other info that might help us debug this:
> [0.633626] Possible unsafe locking scenario:
> [0.633626]
> [0.633626]CPU0
> [0.633627]
> [0.633627] lock(>lock);
> [0.633628] lock(>lock);
> [0.633628]
> [0.633628] *** DEADLOCK ***
> [0.633628]
> [0.633628] May be due to missing lock nesting notation
> [0.633628]
> [0.633629] 10 locks held by swapper/0/1:
> [0.633632] #0: (&__lockdep_no_validate__){..}, at:
> [] __driver_attach+0x5b/0xb0
> [0.633633] #1: (&__lockdep_no_validate__){..}, at:
> [] __driver_attach+0x69/0xb0
> [0.633636] #2: (drm_global_mutex){+.+.+.}, at: []
> drm_get_pci_dev+0xc6/0x2d0
> [0.633640] #3: (registration_lock){+.+.+.}, at: []
> register_framebuffer+0x25/0x310
> [0.633642] #4: (_info->lock){+.+.+.}, at: []
> lock_fb_info+0x26/0x60
> [0.633644] #5: (console_lock){+.+.+.}, at: []
> register_framebuffer+0x1ba/0x310
> [0.633646] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
> [] __blocking_notifier_call_chain+0x42/0x80
> [0.633648] #7: (>mode_config.mutex){+.+.+.}, at:
> [] drm_modeset_lock_all+0x2a/0x70
> [0.633650] #8: (>mutex){+.+.+.}, at: []
> drm_modeset_lock_all+0x54/0x70
> [0.633652] #9: (>lock){+.+...}, at: []
> evo_wait+0x43/0xf0
> [0.633652]
> [0.633652] stack backtrace:
> [0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
> [0.633654] Call Trace:
> [0.633656] [] __lock_acquire+0x76b/0x1c20
> [0.633658] [] ? dcb_table+0x1ac/0x2a0
> [0.633659] [] ? evo_wait+0x43/0xf0
> [0.633660] [] lock_acquire+0x8a/0x120
> [0.633662] [] ? evo_wait+0x43/0xf0
> [0.633664] [] ? mutex_lock_nested+0x292/0x330
> [0.633665] [] mutex_lock_nested+0x6e/0x330
> [0.633667] [] ? evo_wait+0x43/0xf0
> [0.633668] [] ? __mutex_unlock_slowpath+0xc7/0x150
> [0.633669] [] evo_wait+0x43/0xf0
> [0.633671] [] nv50_display_flip_next+0x749/0x7d0
> [0.633672] [] ? evo_kick+0x37/0x40
> [0.633674] [] nv50_crtc_commit+0x10e/0x230
> [0.633676] [] drm_crtc_helper_set_mode+0x365/0x510
> [0.633677] [] drm_crtc_helper_set_config+0xa4e/0xb70
> [0.633679] [] drm_mode_set_config_internal+0x31/0x70
> [0.633680] [] drm_fb_helper_set_par+0x71/0xf0
> [0.633682] [] fbcon_init+0x514/0x5a0
> [0.633683] [] visual_init+0xbc/0x120
> [0.633685] [] do_bind_con_driver+0x163/0x320
> [0.633686] [] do_take_over_console+0x61/0x70
> [0.633687] [] do_fbcon_takeover+0x63/0xc0
> [0.633689] [] fbcon_event_notify+0x5fd/0x700
> [0.633690] [] notifier_call_chain+0x4d/0x70
> [0.633691] [] __blocking_notifier_call_chain+0x58/0x80
> [0.633692] [] blocking_notifier_call_chain+0x16/0x20
> [0.633694] [] fb_notifier_call_chain+0x1b/0x20
> [0.633695] [] register_framebuffer+0x1c8/0x310
> [0.633696] [] drm_fb_helper_initial_config+0x371/0x520
> [0.633697] [] ?
> drm_fb_helper_single_add_all_connectors+0x47/0xf0
> [0.633700] [] ? kmem_cache_alloc_trace+0xee/0x150
> [0.633701] [] nouveau_fbcon_init+0x10e/0x160
> [0.633703] [] nouveau_drm_load+0x40a/0x5d0
> [0.633705] [] ? device_register+0x1e/0x30
> [0.633706] [] ? drm_sysfs_device_add+0x86/0xb0
> [0.633708] [] drm_get_pci_dev+0x186/0x2d0
> [0.633710] [] ? __pci_set_master+0x2b/0x90
> [0.633711] [] nouveau_drm_probe+0x26a/0x2c0
> [0.633713] [] ? pci_match_device+0xd5/0xe0
> [0.633714] [] pci_device_probe+0x136/0x150
> [0.633715] [] driver_probe_device+0x76/0x210
> [0.633716] [] __driver_attach+0xab/0xb0
> [0.633717] [] ? driver_probe_device+0x210/0x210
> [0.633718] [] bus_for_each_dev+0x5d/0xa0
> [0.633719] [] driver_attach+0x1e/0x20
> [0.633720] [] bus_add_driver+0x111/0x280
> [0.633722] [] ? ttm_init+0x62/0x62
> [0.633724] [] driver_register+0x77/0x170
> [0.633725] [] ? ttm_init+0x62/0x62
> [0.633726] [] __pci_register_driver+0x64/0x70
> [0.633728] [] drm_pci_init+0x115/0x130
> [0.633729] [] ? ttm_init+0x62/0x62
> [0.633730] [] ?
Re: nouveau lockdep splat
Dropping Tegra ML, it's not the place where Nouveau mails should go.
Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best.
Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov:
New -rc1, so let the stabilization games begin.
I see the following on rc1, let me know if you need more info.
[0.633617] =
[0.633618] [ INFO: possible recursive locking detected ]
[0.633618] 3.9.0-rc1 #2 Not tainted
[0.633619] -
[0.633619] swapper/0/1 is trying to acquire lock:
[0.633623] (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633624]
[0.633624] but task is already holding lock:
[0.633626] (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633626]
[0.633626] other info that might help us debug this:
[0.633626] Possible unsafe locking scenario:
[0.633626]
[0.633626]CPU0
[0.633627]
[0.633627] lock(dmac-lock);
[0.633628] lock(dmac-lock);
[0.633628]
[0.633628] *** DEADLOCK ***
[0.633628]
[0.633628] May be due to missing lock nesting notation
[0.633628]
[0.633629] 10 locks held by swapper/0/1:
[0.633632] #0: (__lockdep_no_validate__){..}, at:
[8143375b] __driver_attach+0x5b/0xb0
[0.633633] #1: (__lockdep_no_validate__){..}, at:
[81433769] __driver_attach+0x69/0xb0
[0.633636] #2: (drm_global_mutex){+.+.+.}, at: [8135a8f6]
drm_get_pci_dev+0xc6/0x2d0
[0.633640] #3: (registration_lock){+.+.+.}, at: [812c8e75]
register_framebuffer+0x25/0x310
[0.633642] #4: (fb_info-lock){+.+.+.}, at: [812c7d86]
lock_fb_info+0x26/0x60
[0.633644] #5: (console_lock){+.+.+.}, at: [812c900a]
register_framebuffer+0x1ba/0x310
[0.633646] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[810694d2] __blocking_notifier_call_chain+0x42/0x80
[0.633648] #7: (dev-mode_config.mutex){+.+.+.}, at:
[8135e63a] drm_modeset_lock_all+0x2a/0x70
[0.633650] #8: (crtc-mutex){+.+.+.}, at: [8135e664]
drm_modeset_lock_all+0x54/0x70
[0.633652] #9: (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633652]
[0.633652] stack backtrace:
[0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
[0.633654] Call Trace:
[0.633656] [8109524b] __lock_acquire+0x76b/0x1c20
[0.633658] [8137f50c] ? dcb_table+0x1ac/0x2a0
[0.633659] [8141bb53] ? evo_wait+0x43/0xf0
[0.633660] [81096c6a] lock_acquire+0x8a/0x120
[0.633662] [8141bb53] ? evo_wait+0x43/0xf0
[0.633664] [815eaf52] ? mutex_lock_nested+0x292/0x330
[0.633665] [815ead2e] mutex_lock_nested+0x6e/0x330
[0.633667] [8141bb53] ? evo_wait+0x43/0xf0
[0.633668] [815eb0b7] ? __mutex_unlock_slowpath+0xc7/0x150
[0.633669] [8141bb53] evo_wait+0x43/0xf0
[0.633671] [8141e569] nv50_display_flip_next+0x749/0x7d0
[0.633672] [8141bc37] ? evo_kick+0x37/0x40
[0.633674] [8141e7ee] nv50_crtc_commit+0x10e/0x230
[0.633676] [8134c2a5] drm_crtc_helper_set_mode+0x365/0x510
[0.633677] [8134d69e] drm_crtc_helper_set_config+0xa4e/0xb70
[0.633679] [8135f751] drm_mode_set_config_internal+0x31/0x70
[0.633680] [8134b7a1] drm_fb_helper_set_par+0x71/0xf0
[0.633682] [812d40e4] fbcon_init+0x514/0x5a0
[0.633683] [8132cbdc] visual_init+0xbc/0x120
[0.633685] [8132f293] do_bind_con_driver+0x163/0x320
[0.633686] [8132f521] do_take_over_console+0x61/0x70
[0.633687] [812d2703] do_fbcon_takeover+0x63/0xc0
[0.633689] [812d63dd] fbcon_event_notify+0x5fd/0x700
[0.633690] [815f23fd] notifier_call_chain+0x4d/0x70
[0.633691] [810694e8] __blocking_notifier_call_chain+0x58/0x80
[0.633692] [81069526] blocking_notifier_call_chain+0x16/0x20
[0.633694] [812c787b] fb_notifier_call_chain+0x1b/0x20
[0.633695] [812c9018] register_framebuffer+0x1c8/0x310
[0.633696] [8134b4d1] drm_fb_helper_initial_config+0x371/0x520
[0.633697] [8134a607] ?
drm_fb_helper_single_add_all_connectors+0x47/0xf0
[0.633700] [81140a5e] ? kmem_cache_alloc_trace+0xee/0x150
[0.633701] [8140578e] nouveau_fbcon_init+0x10e/0x160
[0.633703] [813f5f8a] nouveau_drm_load+0x40a/0x5d0
[0.633705] [81430cee] ? device_register+0x1e/0x30
[0.633706] [8135c086] ? drm_sysfs_device_add+0x86/0xb0
[0.633708] [8135a9b6] drm_get_pci_dev+0x186/0x2d0
[0.633710] [812b0eab] ? __pci_set_master+0x2b/0x90
[0.633711] [813f63ba]
Re: nouveau lockdep splat
On Tue, Mar 05, 2013 at 05:30:52PM +0100, Lucas Stach wrote: Dropping Tegra ML, it's not the place where Nouveau mails should go. $ ./scripts/get_maintainer.pl -f drivers/gpu/drm/nouveau/nv50_display.c ... linux-te...@vger.kernel.org (open list:TEGRA SUPPORT) Maybe get_maintainer.pl patterns need correction... Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
nouveau lockdep splat
New -rc1, so let the stabilization games begin.
I see the following on rc1, let me know if you need more info.
[0.633617] =
[0.633618] [ INFO: possible recursive locking detected ]
[0.633618] 3.9.0-rc1 #2 Not tainted
[0.633619] -
[0.633619] swapper/0/1 is trying to acquire lock:
[0.633623] (>lock){+.+...}, at: []
evo_wait+0x43/0xf0
[0.633624]
[0.633624] but task is already holding lock:
[0.633626] (>lock){+.+...}, at: []
evo_wait+0x43/0xf0
[0.633626]
[0.633626] other info that might help us debug this:
[0.633626] Possible unsafe locking scenario:
[0.633626]
[0.633626]CPU0
[0.633627]
[0.633627] lock(>lock);
[0.633628] lock(>lock);
[0.633628]
[0.633628] *** DEADLOCK ***
[0.633628]
[0.633628] May be due to missing lock nesting notation
[0.633628]
[0.633629] 10 locks held by swapper/0/1:
[0.633632] #0: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x5b/0xb0
[0.633633] #1: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x69/0xb0
[0.633636] #2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xc6/0x2d0
[0.633640] #3: (registration_lock){+.+.+.}, at: []
register_framebuffer+0x25/0x310
[0.633642] #4: (_info->lock){+.+.+.}, at: []
lock_fb_info+0x26/0x60
[0.633644] #5: (console_lock){+.+.+.}, at: []
register_framebuffer+0x1ba/0x310
[0.633646] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[] __blocking_notifier_call_chain+0x42/0x80
[0.633648] #7: (>mode_config.mutex){+.+.+.}, at:
[] drm_modeset_lock_all+0x2a/0x70
[0.633650] #8: (>mutex){+.+.+.}, at: []
drm_modeset_lock_all+0x54/0x70
[0.633652] #9: (>lock){+.+...}, at: []
evo_wait+0x43/0xf0
[0.633652]
[0.633652] stack backtrace:
[0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
[0.633654] Call Trace:
[0.633656] [] __lock_acquire+0x76b/0x1c20
[0.633658] [] ? dcb_table+0x1ac/0x2a0
[0.633659] [] ? evo_wait+0x43/0xf0
[0.633660] [] lock_acquire+0x8a/0x120
[0.633662] [] ? evo_wait+0x43/0xf0
[0.633664] [] ? mutex_lock_nested+0x292/0x330
[0.633665] [] mutex_lock_nested+0x6e/0x330
[0.633667] [] ? evo_wait+0x43/0xf0
[0.633668] [] ? __mutex_unlock_slowpath+0xc7/0x150
[0.633669] [] evo_wait+0x43/0xf0
[0.633671] [] nv50_display_flip_next+0x749/0x7d0
[0.633672] [] ? evo_kick+0x37/0x40
[0.633674] [] nv50_crtc_commit+0x10e/0x230
[0.633676] [] drm_crtc_helper_set_mode+0x365/0x510
[0.633677] [] drm_crtc_helper_set_config+0xa4e/0xb70
[0.633679] [] drm_mode_set_config_internal+0x31/0x70
[0.633680] [] drm_fb_helper_set_par+0x71/0xf0
[0.633682] [] fbcon_init+0x514/0x5a0
[0.633683] [] visual_init+0xbc/0x120
[0.633685] [] do_bind_con_driver+0x163/0x320
[0.633686] [] do_take_over_console+0x61/0x70
[0.633687] [] do_fbcon_takeover+0x63/0xc0
[0.633689] [] fbcon_event_notify+0x5fd/0x700
[0.633690] [] notifier_call_chain+0x4d/0x70
[0.633691] [] __blocking_notifier_call_chain+0x58/0x80
[0.633692] [] blocking_notifier_call_chain+0x16/0x20
[0.633694] [] fb_notifier_call_chain+0x1b/0x20
[0.633695] [] register_framebuffer+0x1c8/0x310
[0.633696] [] drm_fb_helper_initial_config+0x371/0x520
[0.633697] [] ?
drm_fb_helper_single_add_all_connectors+0x47/0xf0
[0.633700] [] ? kmem_cache_alloc_trace+0xee/0x150
[0.633701] [] nouveau_fbcon_init+0x10e/0x160
[0.633703] [] nouveau_drm_load+0x40a/0x5d0
[0.633705] [] ? device_register+0x1e/0x30
[0.633706] [] ? drm_sysfs_device_add+0x86/0xb0
[0.633708] [] drm_get_pci_dev+0x186/0x2d0
[0.633710] [] ? __pci_set_master+0x2b/0x90
[0.633711] [] nouveau_drm_probe+0x26a/0x2c0
[0.633713] [] ? pci_match_device+0xd5/0xe0
[0.633714] [] pci_device_probe+0x136/0x150
[0.633715] [] driver_probe_device+0x76/0x210
[0.633716] [] __driver_attach+0xab/0xb0
[0.633717] [] ? driver_probe_device+0x210/0x210
[0.633718] [] bus_for_each_dev+0x5d/0xa0
[0.633719] [] driver_attach+0x1e/0x20
[0.633720] [] bus_add_driver+0x111/0x280
[0.633722] [] ? ttm_init+0x62/0x62
[0.633724] [] driver_register+0x77/0x170
[0.633725] [] ? ttm_init+0x62/0x62
[0.633726] [] __pci_register_driver+0x64/0x70
[0.633728] [] drm_pci_init+0x115/0x130
[0.633729] [] ? ttm_init+0x62/0x62
[0.633730] [] ? ttm_init+0x62/0x62
[0.633731] [] nouveau_drm_init+0x4d/0x4f
[0.633732] [] do_one_initcall+0x122/0x170
[0.633734] [] kernel_init_freeable+0x108/0x197
[0.633735] [] ? do_early_param+0x8c/0x8c
[0.633737] [] ? rest_init+0xe0/0xe0
[0.633738] [] kernel_init+0xe/0xf0
[0.633740] [] ret_from_fork+0x7c/0xb0
[0.633741] [] ? rest_init+0xe0/0xe0
--
Regards/Gruss,
Boris.
Sent from a fat crate under
nouveau lockdep splat
New -rc1, so let the stabilization games begin.
I see the following on rc1, let me know if you need more info.
[0.633617] =
[0.633618] [ INFO: possible recursive locking detected ]
[0.633618] 3.9.0-rc1 #2 Not tainted
[0.633619] -
[0.633619] swapper/0/1 is trying to acquire lock:
[0.633623] (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633624]
[0.633624] but task is already holding lock:
[0.633626] (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633626]
[0.633626] other info that might help us debug this:
[0.633626] Possible unsafe locking scenario:
[0.633626]
[0.633626]CPU0
[0.633627]
[0.633627] lock(dmac-lock);
[0.633628] lock(dmac-lock);
[0.633628]
[0.633628] *** DEADLOCK ***
[0.633628]
[0.633628] May be due to missing lock nesting notation
[0.633628]
[0.633629] 10 locks held by swapper/0/1:
[0.633632] #0: (__lockdep_no_validate__){..}, at:
[8143375b] __driver_attach+0x5b/0xb0
[0.633633] #1: (__lockdep_no_validate__){..}, at:
[81433769] __driver_attach+0x69/0xb0
[0.633636] #2: (drm_global_mutex){+.+.+.}, at: [8135a8f6]
drm_get_pci_dev+0xc6/0x2d0
[0.633640] #3: (registration_lock){+.+.+.}, at: [812c8e75]
register_framebuffer+0x25/0x310
[0.633642] #4: (fb_info-lock){+.+.+.}, at: [812c7d86]
lock_fb_info+0x26/0x60
[0.633644] #5: (console_lock){+.+.+.}, at: [812c900a]
register_framebuffer+0x1ba/0x310
[0.633646] #6: ((fb_notifier_list).rwsem){.+.+.+}, at:
[810694d2] __blocking_notifier_call_chain+0x42/0x80
[0.633648] #7: (dev-mode_config.mutex){+.+.+.}, at:
[8135e63a] drm_modeset_lock_all+0x2a/0x70
[0.633650] #8: (crtc-mutex){+.+.+.}, at: [8135e664]
drm_modeset_lock_all+0x54/0x70
[0.633652] #9: (dmac-lock){+.+...}, at: [8141bb53]
evo_wait+0x43/0xf0
[0.633652]
[0.633652] stack backtrace:
[0.633653] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc1 #2
[0.633654] Call Trace:
[0.633656] [8109524b] __lock_acquire+0x76b/0x1c20
[0.633658] [8137f50c] ? dcb_table+0x1ac/0x2a0
[0.633659] [8141bb53] ? evo_wait+0x43/0xf0
[0.633660] [81096c6a] lock_acquire+0x8a/0x120
[0.633662] [8141bb53] ? evo_wait+0x43/0xf0
[0.633664] [815eaf52] ? mutex_lock_nested+0x292/0x330
[0.633665] [815ead2e] mutex_lock_nested+0x6e/0x330
[0.633667] [8141bb53] ? evo_wait+0x43/0xf0
[0.633668] [815eb0b7] ? __mutex_unlock_slowpath+0xc7/0x150
[0.633669] [8141bb53] evo_wait+0x43/0xf0
[0.633671] [8141e569] nv50_display_flip_next+0x749/0x7d0
[0.633672] [8141bc37] ? evo_kick+0x37/0x40
[0.633674] [8141e7ee] nv50_crtc_commit+0x10e/0x230
[0.633676] [8134c2a5] drm_crtc_helper_set_mode+0x365/0x510
[0.633677] [8134d69e] drm_crtc_helper_set_config+0xa4e/0xb70
[0.633679] [8135f751] drm_mode_set_config_internal+0x31/0x70
[0.633680] [8134b7a1] drm_fb_helper_set_par+0x71/0xf0
[0.633682] [812d40e4] fbcon_init+0x514/0x5a0
[0.633683] [8132cbdc] visual_init+0xbc/0x120
[0.633685] [8132f293] do_bind_con_driver+0x163/0x320
[0.633686] [8132f521] do_take_over_console+0x61/0x70
[0.633687] [812d2703] do_fbcon_takeover+0x63/0xc0
[0.633689] [812d63dd] fbcon_event_notify+0x5fd/0x700
[0.633690] [815f23fd] notifier_call_chain+0x4d/0x70
[0.633691] [810694e8] __blocking_notifier_call_chain+0x58/0x80
[0.633692] [81069526] blocking_notifier_call_chain+0x16/0x20
[0.633694] [812c787b] fb_notifier_call_chain+0x1b/0x20
[0.633695] [812c9018] register_framebuffer+0x1c8/0x310
[0.633696] [8134b4d1] drm_fb_helper_initial_config+0x371/0x520
[0.633697] [8134a607] ?
drm_fb_helper_single_add_all_connectors+0x47/0xf0
[0.633700] [81140a5e] ? kmem_cache_alloc_trace+0xee/0x150
[0.633701] [8140578e] nouveau_fbcon_init+0x10e/0x160
[0.633703] [813f5f8a] nouveau_drm_load+0x40a/0x5d0
[0.633705] [81430cee] ? device_register+0x1e/0x30
[0.633706] [8135c086] ? drm_sysfs_device_add+0x86/0xb0
[0.633708] [8135a9b6] drm_get_pci_dev+0x186/0x2d0
[0.633710] [812b0eab] ? __pci_set_master+0x2b/0x90
[0.633711] [813f63ba] nouveau_drm_probe+0x26a/0x2c0
[0.633713] [812b4f15] ? pci_match_device+0xd5/0xe0
[0.633714] [812b5096] pci_device_probe+0x136/0x150
[0.633715] [81433566] driver_probe_device+0x76/0x210
[0.633716] [814337ab] __driver_attach+0xab/0xb0
[0.633717]
