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 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
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. -- ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
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 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
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 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
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. -- ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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] 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;
}
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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. -- ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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. -- ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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. -- ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] 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]
[Nouveau] nouveau lockdep splat on init
Testing airlied's current drm-fixes branch gives me this, with lockdep enabled:
[ 40.864179] =
[ 40.864179] [ INFO: possible recursive locking detected ]
[ 40.864179] 3.8.0-rc3-patser+ #915 Tainted: GW
[ 40.864179] -
[ 40.864179] modprobe/524 is trying to acquire lock:
[ 40.864179] (subdev-mutex){+.+.+.}, at: [a0333ba3]
nouveau_instobj_create_+0x43/0x90 [nouveau]
[ 40.864179]
[ 40.864179] but task is already holding lock:
[ 40.864179] (subdev-mutex){+.+.+.}, at: [a03467f4]
nv50_disp_data_ctor+0x94/0x160 [nouveau]
[ 40.864179]
[ 40.864179] other info that might help us debug this:
[ 40.864179] Possible unsafe locking scenario:
[ 40.864179]
[ 40.864179]CPU0
[ 40.864179]
[ 40.864179] lock(subdev-mutex);
[ 40.864179] lock(subdev-mutex);
[ 40.864179]
[ 40.864179] *** DEADLOCK ***
[ 40.864179]
[ 40.864179] May be due to missing lock nesting notation
[ 40.864179]
[ 40.864179] 4 locks held by modprobe/524:
[ 40.864179] #0: (__lockdep_no_validate__){..}, at:
[81410ea3] __driver_attach+0x53/0xb0
[ 40.864179] #1: (__lockdep_no_validate__){..}, at:
[81410eb1] __driver_attach+0x61/0xb0
[ 40.864179] #2: (drm_global_mutex){+.+.+.}, at: [a0094437]
drm_get_pci_dev+0xb7/0x2a0 [drm]
[ 40.864179] #3: (subdev-mutex){+.+.+.}, at: [a03467f4]
nv50_disp_data_ctor+0x94/0x160 [nouveau]
[ 40.864179]
[ 40.864179] stack backtrace:
[ 40.864179] Pid: 524, comm: modprobe Tainted: GW
3.8.0-rc3-patser+ #915
[ 40.864179] Call Trace:
[ 40.864179] [8109cd63] __lock_acquire+0x783/0x1d90
[ 40.864179] [8109c9cf] ? __lock_acquire+0x3ef/0x1d90
[ 40.864179] [8109b4d2] ? mark_held_locks+0x82/0x130
[ 40.864179] [8135160e] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 40.864179] [8109e8e6] lock_acquire+0x96/0xc0
[ 40.864179] [a0333ba3] ? nouveau_instobj_create_+0x43/0x90
[nouveau]
[ 40.864179] [a02fc3fc] ? nouveau_object_create_+0x9c/0xf0
[nouveau]
[ 40.864179] [a0333ba3] ? nouveau_instobj_create_+0x43/0x90
[nouveau]
[ 40.864179] [816f5abe] mutex_lock_nested+0x5e/0x390
[ 40.864179] [a0333ba3] ? nouveau_instobj_create_+0x43/0x90
[nouveau]
[ 40.864179] [816fa790] ? _raw_spin_unlock+0x30/0x60
[ 40.864179] [a02fc42e] ? nouveau_object_create_+0xce/0xf0
[nouveau]
[ 40.864179] [816fa6ab] ? _raw_spin_unlock_irq+0x2b/0x60
[ 40.864179] [a0333ba3] nouveau_instobj_create_+0x43/0x90 [nouveau]
[ 40.864179] [a0334e91] nv50_instobj_ctor+0xa1/0x1b0 [nouveau]
[ 40.864179] [8107126a] ? finish_task_switch+0x3a/0x110
[ 40.864179] [a02fc103] nouveau_object_ctor+0x33/0xe0 [nouveau]
[ 40.864179] [a0334cbf] nv50_instmem_alloc+0x2f/0x40 [nouveau]
[ 40.864179] [a02fa34d] nouveau_gpuobj_create_+0x38d/0x4c0
[nouveau]
[ 40.864179] [a02f74ac] nouveau_engctx_create_+0x17c/0x3d0
[nouveau]
[ 40.864179] [a0346891] nv50_disp_data_ctor+0x131/0x160 [nouveau]
[ 40.864179] [a02fe3f2] ? nouveau_subdev_reset+0x72/0xb0 [nouveau]
[ 40.864179] [a02fc103] nouveau_object_ctor+0x33/0xe0 [nouveau]
[ 40.864179] [a02fce6a] nouveau_object_new+0x14a/0x2b0 [nouveau]
[ 40.864179] [a043171a] nv50_display_create+0x1ea/0x9a0 [nouveau]
[ 40.864179] [81060582] ? __cancel_work_timer+0x72/0xc0
[ 40.864179] [a03fe7b4] nouveau_display_create+0x4c4/0x900
[nouveau]
[ 40.864179] [a03e6da2] nouveau_drm_load+0x3b2/0x960 [nouveau]
[ 40.864179] [8140e599] ? device_register+0x19/0x20
[ 40.864179] [a0095d11] ? drm_sysfs_device_add+0x81/0xb0 [drm]
[ 40.864179] [a00944f9] drm_get_pci_dev+0x179/0x2a0 [drm]
[ 40.864179] [8137042d] ? __pci_set_master+0x4d/0x80
[ 40.864179] [a03e646a] nouveau_drm_probe+0x25a/0x290 [nouveau]
[ 40.864179] [816fa71d] ? _raw_spin_unlock_irqrestore+0x3d/0x80
[ 40.864179] [81374566] local_pci_probe+0x46/0x80
[ 40.864179] [81375db9] pci_device_probe+0xf9/0x120
[ 40.864179] [81410c86] driver_probe_device+0x76/0x240
[ 40.864179] [81410ef3] __driver_attach+0xa3/0xb0
[ 40.864179] [81410e50] ? driver_probe_device+0x240/0x240
[ 40.864179] [8140f0e6] bus_for_each_dev+0x56/0x90
[ 40.864179] [814107e9] driver_attach+0x19/0x20
[ 40.864179] [81410388] bus_add_driver+0x188/0x270
[ 40.864179] [81411425] driver_register+0x75/0x150
[ 40.864179] [81374dcf] __pci_register_driver+0x5f/0x70
[ 40.864179] [a009473a] drm_pci_init+0x11a/0x130 [drm]
[ 40.864179] [8140b2c0] ? vga_switcheroo_register_handler+0x40/0x90
[ 40.864179] [a04a3000] ?
