[ +to Scot Doyle ]
Scot, please take a look at this soft lockup.
Regards,
Peter Hurley
Hi Ming,
On 05/17/2016 02:12 AM, Ming Lei wrote:
> Hi,
>
> On Tue, May 17, 2016 at 4:07 AM, Dann Frazier
> wrote:
>> Hi,
>> I'm observing a soft lockup issue w/ the ASP
On 02/01/2016 09:20 PM, Archit Taneja wrote:
> Hi Peter,
>
> On 02/02/2016 02:07 AM, Peter Hurley wrote:
>> Hi Archit,
>>
>> Just booting 4.4-rc5+, I got this splat [1]
>> At first glance, this appears to be a simple fix.
>
> Thanks for sharing this.
>
so I'm not
sure why this hasn't triggered many times before, but it hasn't.
Regards,
Peter Hurley
[1] BUG splat
[ 37.438494] BUG: sleeping function called from invalid context at
/home/peter/src/kernels/mainline/mm/slub.c:1287
[ 37.438495] in_atomic(): 1, irqs_disabled
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
> On 30 July 2015 at 16:02, Ilia Mirkin wrote:
>> On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
>> wrote:
>>> On 30/07/15 15:52, Bryan O'Donoghue wrote:
>>>>
>>>>
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.
What's the freedesktop bugzilla # for reference?
Regards,
Peter Hurley
> On Thu, Jul 30,
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
> Is this happening with libdrm 2.4.60? If so, that's a known
> (user-side) issue and should be fixed by using any version but that
> one.
What's the freedesktop bugzilla # for reference?
Regards,
Peter Hurley
> On Thu, Jul 30,
On 05/07/2015 04:49 AM, Denys Vlasenko wrote:
> Function compiles to 89 bytes of machine code.
> 466 callsites with this .config:
> http://busybox.net/~vda/kernel_config
> Size reduction:
Much of the cruft is related to calling iowriteX.
Ben,
Isn't subdev io always mmio? (iow, never to the 64k i
On 05/06/2015 04:56 AM, Daniel Vetter wrote:
> On Tue, May 05, 2015 at 11:57:42AM -0400, Peter Hurley wrote:
>> On 05/05/2015 11:42 AM, Daniel Vetter wrote:
>>> On Tue, May 05, 2015 at 10:36:24AM -0400, Peter Hurley wrote:
>>>> On 05/04/2015 12:52 AM, Mario Kleiner wr
On 05/05/2015 11:57 AM, Peter Hurley wrote:
> On 05/05/2015 11:42 AM, Daniel Vetter wrote:
>> I'm also somewhat confused about how you to a line across both cpus for
>> barriers because barriers only have cpu-local effects (which is why we
>> always need a barrier on
On 05/05/2015 11:42 AM, Daniel Vetter wrote:
> On Tue, May 05, 2015 at 10:36:24AM -0400, Peter Hurley wrote:
>> On 05/04/2015 12:52 AM, Mario Kleiner wrote:
>>> On 04/16/2015 03:03 PM, Daniel Vetter wrote:
>>>> On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wr
On 05/04/2015 12:52 AM, Mario Kleiner wrote:
> On 04/16/2015 03:03 PM, Daniel Vetter wrote:
>> On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wrote:
>>> On 04/15/2015 01:31 PM, Daniel Vetter wrote:
>>>> On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter
On 04/16/2015 02:39 AM, Mario Kleiner wrote:
> On 04/16/2015 03:29 AM, Peter Hurley wrote:
>> On 04/15/2015 05:26 PM, Mario Kleiner wrote:
>> Because the time scales for these events don't require that level of
>> resolution; consider how much code has to get executed be
On 04/15/2015 01:31 PM, Daniel Vetter wrote:
> On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
>> Hi Daniel,
>>
>> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
>>> This was a bit too much cargo-culted, so lets make it solid:
>>> - vblank->
On 04/16/2015 02:39 AM, Mario Kleiner wrote:
> On 04/16/2015 03:29 AM, Peter Hurley wrote:
>> On 04/15/2015 05:26 PM, Mario Kleiner wrote:
>>> A couple of questions to educate me and one review comment.
>>>
>>> On 04/15/2015 07:34 PM, Daniel Vetter wrote:
>&
t;> auditing all callers and my point in extracting this little helper was
>> to localize all the locking into just one place. Hence I think that
>> additional optimization is too risky.
>>
>> Cc: Chris Wilson
>> Cc: Mario Kleiner
>> Cc: Ville Syrjälä
>>
elf-contradictory.
If vblank->count writes are always protected by vblank_time_lock (something I
did not verify but that the comment above asserts), then the trailing write
barrier is not required (and the assertion that it is in the comment is
incorrect).
A spin unlock operation is always a
On 01/28/2015 11:11 PM, Dave Airlie wrote:
> These two copy to/from VGA memory, however on the Silicon
> Motion SMI750 VGA card on a 64-bit system cause console corruption.
>
> This is due to the hw being buggy and not handling a 64-bit transaction
> correctly.
>
> We could try and create a 32-bi
modeset->num_connectors must be 0 to reach the BUG_ON() which tests
for non-zero modeset->num_connectors; remove BUG_ON().
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_fb_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/g
akenly set to
connector_status_disconnected, and the connector will not be mode set.
Fix the connector->status when connector->force is DRM_FORCE_ON_DIGITAL.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_probe_helper.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/dr
lds, regardless of the specified type or actual field width.
The enlarged write overwrites adjacent fields.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Regards,
Peter Hurley
On 09/26/2014 11:12 AM, Leann Ogasawara wrote:
> On Fri, Sep 26, 2014 at 7:10 AM, Peter Hurley
> wrote:
>> [ +cc Leann Ogasawara, Marek Szyprowski, Kyungmin Park, Arnd Bergmann ]
>>
>> On 09/26/2014 08:40 AM, Rik van Riel wrote:
>>> On 09/26/2014 08:28 AM, Rob
>>>> On Fri, 26 Sep 2014 09:15:57 +0200 Thomas Hellstrom
>>>> wrote:
>>>>
>>>>> On 09/26/2014 01:52 AM, Peter Hurley wrote:
>>>>>> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
>>>>>>> There are six ttm patc
allocation doing CMA dma allocation,
which is the root problem.
Regards,
Peter Hurley
On 09/25/2014 04:33 PM, Alex Deucher wrote:
> On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley
> wrote:
>> After several days uptime with a 3.16 kernel (generally running
>> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
>> desktop workspaces) I&#x
On 09/25/2014 02:55 PM, Peter Hurley wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
>
> Mostly the slowdowns are
TLB
Specifically, this statement:
It could cause incorrect page aging and the (mistaken) reclaim of
hot pages, but the chance of that should be relatively low.
I'm wondering if this could cause worse-case behavior with TTM? I'm
testing a revert of this on mainline 3.16-final now,
On 09/12/2014 01:25 PM, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 01:03:51PM -0400, Peter Hurley wrote:
>> On 09/12/2014 12:04 PM, Chris Wilson wrote:
>>> On Fri, Sep 12, 2014 at 05:34:56PM +0200, Daniel Vetter wrote:
>>>> On Fri, Sep 12, 2014 at 04:23:29PM +0100
;>>> already.
>>>
>>> Replace the rogue WARN_ON_SMP(!spin_is_locked(&dev->event_lock)) in
>>> send_vblank_event() as well then.
>>
>> Meh, I've missed that one, that's actually better I think. I'll drop my
>> patch here.
>
> I thought assert_spin_lock was the preferred form?
Actually, lockdep_assert_held() is the preferred form.
See https://lkml.org/lkml/2014/9/3/171
Regards,
Peter Hurley
On 09/30/2013 01:27 PM, Peter Hurley wrote:
On 09/03/2013 09:45 PM, Ben Skeggs wrote:
Well, we can't just go around breaking stuff deliberately for the
people still using them!
I've blacklisted them myself and merged the patch.
Ben,
This patch causes my dual-head Quadro FX570 (G8
570] [10de:040e] (rev a1) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation Device [10de:0474]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TA
On 09/17/2013 04:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there&#
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunate
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
"get_scanout_position()" ca
On 08/28/2013 03:15 AM, Ben Skeggs wrote:
> On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley
> wrote:
>> This series was originally motivated by a deadlock, introduced in
>> commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
>> 'drm/nouveau/disp: port vblank handling t
On 08/28/2013 03:15 AM, Ben Skeggs wrote:
On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley wrote:
This series was originally motivated by a deadlock, introduced in
commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
'drm/nouveau/disp: port vblank handling to event interface',
due to inv
Remove index parameter; access index via handler->index instead.
Dissociate handler from related container; use handler->priv to
access container.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 6 +++---
drivers/gpu/drm/nouveau/core/engine/software/
Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 36 +-
.../gpu/drm/nouveau/core/engine/software/nv50.c| 11
nouveau_event_put_locked() only has 1 call site; fold into caller.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm
asteoi_irq+0x1e/0x100
[] handle_fasteoi_irq+0x5a/0x100
[] handle_irq+0x22/0x40
[] do_IRQ+0x5a/0xd0
[] common_interrupt+0x6f/0x6f
[] ? default_idle+0x1d/0x290
[] ? default_idle+0x1b/0x290
[] arch_cpu_idle+0x26/0x30
[] cpu_startup_entry+0xce/0x410
[] ? clockevents_register_device+
lifetime, and distinguishes "one-of" event handlers
(such as gpio) from "many temporary" event handlers (such as uevent).
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 63 +++---
.../gpu/drm/nouveau/core/engine/sof
st will be corrupted.
Migrate nouveau_event_get/_put from add/remove semantics to
enable/disable semantics.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 20
drivers/gpu/drm/nouveau/core/include/core/event.h | 4
drivers/gpu/d
-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 24 +++
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 ++
drivers/gpu/drm/nouveau/nouveau_fence.c | 15 +++---
3 files changed, 38 insertions(+), 7 deletions(-)
diff
The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core
Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau
tale,
as is the case with nouveau_connector_hotplug, which only schedules a work
item, and nouveau_drm_vblank_handler, which the drm core expects may be stale.
Peter Hurley (9):
drm/nouveau: Add priv field for event handlers
drm/nouveau: Move event index check from critical section
drm/nouveau: Allocate l
Remove index parameter; access index via handler->index instead.
Dissociate handler from related container; use handler->priv to
access container.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 6 +++---
drivers/gpu/drm/nouveau/core/engine/software/
Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 36 +-
.../gpu/drm/nouveau/core/engine/software/nv50.c| 11
nouveau_event_put_locked() only has 1 call site; fold into caller.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm
asteoi_irq+0x1e/0x100
[] handle_fasteoi_irq+0x5a/0x100
[] handle_irq+0x22/0x40
[] do_IRQ+0x5a/0xd0
[] common_interrupt+0x6f/0x6f
[] ? default_idle+0x1d/0x290
[] ? default_idle+0x1b/0x290
[] arch_cpu_idle+0x26/0x30
[] cpu_startup_entry+0xce/0x410
[] ? clockevents_register_device+
lifetime, and distinguishes "one-of" event handlers
(such as gpio) from "many temporary" event handlers (such as uevent).
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 63 +++---
.../gpu/drm/nouveau/core/engine/sof
st will be corrupted.
Migrate nouveau_event_get/_put from add/remove semantics to
enable/disable semantics.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 20
drivers/gpu/drm/nouveau/core/include/core/event.h | 4
drivers/gpu/d
-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 24 +++
drivers/gpu/drm/nouveau/core/include/core/event.h | 6 ++
drivers/gpu/drm/nouveau/nouveau_fence.c | 15 +++---
3 files changed, 38 insertions(+), 7 deletions(-)
diff
tale,
as is the case with nouveau_connector_hotplug, which only schedules a work
item, and nouveau_drm_vblank_handler, which the drm core expects may be stale.
Peter Hurley (9):
drm/nouveau: Add priv field for event handlers
drm/nouveau: Move event index check from critical section
drm/nouveau: Allocate l
The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/core
Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/nouveau/core/include/core/event.h | 1 +
drivers/gpu/drm/nouveau
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
The irq flags state is already established by the outer
spin_lock_irqsave(); re-disabling irqs is redundant.
Signed-off-by: Peter Hurley
---
drivers/gpu/drm/drm_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
etween the event handler and the event. Untangling object lifetimes in
nouveau is a non-trivial exercise.
Regards,
Peter Hurley
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 7eb81c1..78bff7c 100644
-
enforces non-overlapping lifetimes
between the event handler and the event. Untangling object lifetimes in
nouveau is a non-trivial exercise.
Regards,
Peter Hurley
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
> b/drivers/gpu/drm/n
On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> Oops, fixed to apply this time..
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 4610c3a..020542e 100644
> --- a/drivers/gpu/drm
On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> Oops, fixed to apply this time..
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 4610c3a..020542e 100644
> --- a/drivers/gpu/drm
On Sun, 2013-03-24 at 12:56 +0100, Maarten Lankhorst wrote:
> Op 23-03-13 12:47, Peter Hurley schreef:
> > On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
> >> On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
> >> the user X session is comi
On Sun, 2013-03-24 at 12:56 +0100, Maarten Lankhorst wrote:
> Op 23-03-13 12:47, Peter Hurley schreef:
> > On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
> >> On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
> >> the user X session is comi
On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
> On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
> the user X session is coming up:
Perhaps I wasn't clear that this happens on every boot and is a
regression from 3.8
I'd be happy to help resolve thi
On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
> On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
> the user X session is coming up:
Perhaps I wasn't clear that this happens on every boot and is a
regression from 3.8
I'd be happy to help resolve thi
[ 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+Nouv
On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
the user X session is coming up:
BUG: unable to handle kernel NULL pointer dereference at 0001
IP: [<0001>] 0x0
PGD 0
Oops: 0010 [#1] PREEMPT SMP
Modules linked in: ip6table_filter ip6_tables ebtable_
[ 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+Nouv
On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
the user X session is coming up:
BUG: unable to handle kernel NULL pointer dereference at 0001
IP: [<0001>] 0x0
PGD 0
Oops: 0010 [#1] PREEMPT SMP
Modules linked in: ip6table_filter ip6_tables ebtable_
OOM -- which made no sense. Completely out of page blocks
larger than 32k on a 10gb machine with a bunch of emacs and terminal
windows open for 3 days, just doing code, build, code, build, code,
build?
Regards,
Peter Hurley
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
report has a cross reference :(
The original report is here:
https://bugzilla.kernel.org/show_bug.cgi?id=51291
Pekka,
Can you please re-assign the bugzilla #51291 above to DRI? Thanks.
Regards,
Peter Hurley
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
OOM -- which made no sense. Completely out of page blocks
larger than 32k on a 10gb machine with a bunch of emacs and terminal
windows open for 3 days, just doing code, build, code, build, code,
build?
Regards,
Peter Hurley
report has a cross reference :(
The original report is here:
https://bugzilla.kernel.org/show_bug.cgi?id=51291
Pekka,
Can you please re-assign the bugzilla #51291 above to DRI? Thanks.
Regards,
Peter Hurley
xf0 [nouveau]
[7.436148] [] ? mutex_lock_nested+0x29e/0x3a0
[7.436168] [] ? evo_wait+0x43/0xf0 [nouveau]
[7.436170] [] ? mark_held_locks+0xaf/0x110
[7.436190] [] evo_wait+0x43/0xf0 [nouveau]
[7.436212] [] evo_sync+0x5c/0xf0 [nouveau]
[7.436233] [] nv50_display_flip_next+0x5ad/0x5c0
[nouveau]
Regards,
Peter Hurley
xf0 [nouveau]
[7.436148] [] ? mutex_lock_nested+0x29e/0x3a0
[7.436168] [] ? evo_wait+0x43/0xf0 [nouveau]
[7.436170] [] ? mark_held_locks+0xaf/0x110
[7.436190] [] evo_wait+0x43/0xf0 [nouveau]
[7.436212] [] evo_sync+0x5c/0xf0 [nouveau]
[7.436233] [] nv50_
Hi Maarten
On Mon, 2013-02-04 at 22:59 +0100, Maarten Lankhorst wrote:
> Op 04-02-13 22:30, Marcin Slusarz schreef:
> > 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> > locked in arbitrary order, which is not true (at least in general case).
> > Tell it to distinguish
Hi Maarten
On Mon, 2013-02-04 at 22:59 +0100, Maarten Lankhorst wrote:
> Op 04-02-13 22:30, Marcin Slusarz schreef:
> > 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> > locked in arbitrary order, which is not true (at least in general case).
> > Tell it to distinguish
&subdev->mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x65/0xd0 [nouveau]
[5.995989]
[5.995989] other info that might help us debug this:
[5.995995] Possible unsafe locking scenario:
[5.995995]
[5.996001]CPU0
[5.996004]
[5.996005] lock(&
&subdev->mutex){+.+.+.}, at: []
nv50_disp_data_ctor+0x65/0xd0 [nouveau]
[5.995989]
[5.995989] other info that might help us debug this:
[5.995995] Possible unsafe locking scenario:
[5.995995]
[5.996001]CPU0
[5.996004]
[5.996005] lock(&subdev->mutex);
[5.996005] lock(&subdev->mutex);
[5.996005]
[5.996005] *** DEADLOCK ***
Regards,
Peter Hurley
79 matches
Mail list logo
