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 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 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 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 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
[ 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: []
> evo_wait+0x43/0xf0
> [0.625562]
> [0.625562] but task is already holding lock:
> [0.625564] (&dmac->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(&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:
> [] __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: (&fb_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: (&dev->mode_config.mutex){+.+.+.}, at:
> [] drm_modeset_lock_all+0x2a/0x70
> [0.625589] #8: (&crtc->mutex){+.+.+.}, at: []
> drm_modeset_lock_all+0x54/0x70
> [0.625591] #9: (&dmac->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
> [
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: []
evo_wait+0x43/0xf0
[0.625562]
[0.625562] but task is already holding lock:
[0.625564] (&dmac->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(&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:
[] __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: (&fb_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: (&dev->mode_config.mutex){+.+.+.}, at:
[] drm_modeset_lock_all+0x2a/0x70
[0.625589] #8: (&crtc->mutex){+.+.+.}, at: []
drm_modeset_lock_all+0x54/0x70
[0.625591] #9: (&dmac->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]
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
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 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 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. -- ___ 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 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 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 ___ 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: []
> evo_wait+0x43/0xf0
> [0.633624]
> [0.633624] but task is already holding lock:
> [0.633626] (&dmac->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(&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:
> [] __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: (&fb_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: (&dev->mode_config.mutex){+.+.+.}, at:
> [] drm_modeset_lock_all+0x2a/0x70
> [0.633650] #8: (&crtc->mutex){+.+.+.}, at: []
> drm_modeset_lock_all+0x54/0x70
> [0.633652] #9: (&dmac->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
[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: []
nouveau_instobj_create_+0x43/0x90 [nouveau]
[ 40.864179]
[ 40.864179] but task is already holding lock:
[ 40.864179] (&subdev->mutex){+.+.+.}, at: []
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:
[] __driver_attach+0x53/0xb0
[ 40.864179] #1: (&__lockdep_no_validate__){..}, at:
[] __driver_attach+0x61/0xb0
[ 40.864179] #2: (drm_global_mutex){+.+.+.}, at: []
drm_get_pci_dev+0xb7/0x2a0 [drm]
[ 40.864179] #3: (&subdev->mutex){+.+.+.}, at: []
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] [] __lock_acquire+0x783/0x1d90
[ 40.864179] [] ? __lock_acquire+0x3ef/0x1d90
[ 40.864179] [] ? mark_held_locks+0x82/0x130
[ 40.864179] [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 40.864179] [] lock_acquire+0x96/0xc0
[ 40.864179] [] ? nouveau_instobj_create_+0x43/0x90
[nouveau]
[ 40.864179] [] ? nouveau_object_create_+0x9c/0xf0
[nouveau]
[ 40.864179] [] ? nouveau_instobj_create_+0x43/0x90
[nouveau]
[ 40.864179] [] mutex_lock_nested+0x5e/0x390
[ 40.864179] [] ? nouveau_instobj_create_+0x43/0x90
[nouveau]
[ 40.864179] [] ? _raw_spin_unlock+0x30/0x60
[ 40.864179] [] ? nouveau_object_create_+0xce/0xf0
[nouveau]
[ 40.864179] [] ? _raw_spin_unlock_irq+0x2b/0x60
[ 40.864179] [] nouveau_instobj_create_+0x43/0x90 [nouveau]
[ 40.864179] [] nv50_instobj_ctor+0xa1/0x1b0 [nouveau]
[ 40.864179] [] ? finish_task_switch+0x3a/0x110
[ 40.864179] [] nouveau_object_ctor+0x33/0xe0 [nouveau]
[ 40.864179] [] nv50_instmem_alloc+0x2f/0x40 [nouveau]
[ 40.864179] [] nouveau_gpuobj_create_+0x38d/0x4c0
[nouveau]
[ 40.864179] [] nouveau_engctx_create_+0x17c/0x3d0
[nouveau]
[ 40.864179] [] nv50_disp_data_ctor+0x131/0x160 [nouveau]
[ 40.864179] [] ? nouveau_subdev_reset+0x72/0xb0 [nouveau]
[ 40.864179] [] nouveau_object_ctor+0x33/0xe0 [nouveau]
[ 40.864179] [] nouveau_object_new+0x14a/0x2b0 [nouveau]
[ 40.864179] [] nv50_display_create+0x1ea/0x9a0 [nouveau]
[ 40.864179] [] ? __cancel_work_timer+0x72/0xc0
[ 40.864179] [] nouveau_display_create+0x4c4/0x900
[nouveau]
[ 40.864179] [] nouveau_drm_load+0x3b2/0x960 [nouveau]
[ 40.864179] [] ? device_register+0x19/0x20
[ 40.864179] [] ? drm_sysfs_device_add+0x81/0xb0 [drm]
[ 40.864179] [] drm_get_pci_dev+0x179/0x2a0 [drm]
[ 40.864179] [] ? __pci_set_master+0x4d/0x80
[ 40.864179] [] nouveau_drm_probe+0x25a/0x290 [nouveau]
[ 40.864179] [] ? _raw_spin_unlock_irqrestore+0x3d/0x80
[ 40.864179] [] local_pci_probe+0x46/0x80
[ 40.864179] [] pci_device_probe+0xf9/0x120
[ 40.864179] [] driver_probe_device+0x76/0x240
[ 40.864179] [] __driver_attach+0xa3/0xb0
[ 40.864179] [] ? driver_probe_device+0x240/0x240
[ 40.864179] [] bus_for_each_dev+0x56/0x90
[ 40.864179] [] driver_attach+0x19/0x20
[ 40.864179] [] bus_add_driver+0x188/0x270
[ 40.864179] [] driver_register+0x75/0x150
[ 40.864179] [] __pci_register_driver+0x5f/0x70
[ 40.864179] [] drm_pci_init+0x11a/0x130 [drm]
[ 40.864179] [] ? vga_switcheroo_register_handler+0x40/0x90
[ 40.864179] [] ? 0xa04a2fff
[ 40.864179] [] nouveau_drm_init+0x4d/0x1000 [nouveau]
[ 40.864179] [] do_one_initcall+0x3a/0x170
[ 40.864179] [] load_module+0x1a52/0x2020
[ 40.864179] [] ? get_modinfo.isra.30+0xc0/0xc0
[ 40.864179] [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 40.864179] [] sys_init_module+0xd1/0x100
[ 40.864179] [] system_call_fastpath+0x16/0x1b
I don't understand the need for the mutex_lock in that code though, wouldn't it
be better for the caller to ensure that this code is only called once?
~Maarten
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
