After the ILK vt-d workaround patches it became clear that we had
introduced a bug. Chris tracked down the issue to recursive calls to
unmap. This happens because we try to optimize waiting on requests by
calling retire requests after the wait, which may drop the last
reference on an object and en
On Sun, 30 Oct 2011 18:52:10 -0700, Ben Widawsky wrote:
> Well, I had to pick one, and looking at the call chain, it seemed there wasn't
> much to gain by doing retiring at this point.
The point is that you're mixing the stuff the commit message talks about
with other changes *which are not ment
On Sun, 30 Oct 2011 18:36:23 -0700
Keith Packard wrote:
> On Sun, 30 Oct 2011 18:20:54 -0700, Ben Widawsky wrote:
> >
> > The solution here is to add a new flag to the call chain which gives the
> > routines the information they need to possibly defer actions which may
> > cause us to recurse.
On Sun, 30 Oct 2011 20:12:12 +0100
Daniel Vetter wrote:
> Based on a patch by Ben Widawsky, but with different colors
> for the bikeshed.
>
> In contrast to Ben's patch this one doesn't add the fault regs.
> Afaics they're for the optional page fault support which
> - we're not enabling
> - and
On Sun, 30 Oct 2011 18:47:50 -0700
Ben Widawsky wrote:
> On Sun, 30 Oct 2011 20:12:11 +0100
> Daniel Vetter wrote:
>
> > The code already got unwindy and we want to dump more per-ring
> > registers.
> >
> > Only functional change is that we now also capture the video
> > ring registers on ilk.
On Sun, 30 Oct 2011 20:12:10 +0100
Daniel Vetter wrote:
> ... and add a helpr function for the places where we want a flag.
>
> This way we can use ring->id to index into arrays.
>
> v2: Resurrect the missing beautification-space Chris Wilson noted.
> I'm moving this space around because I'll r
On Sun, 30 Oct 2011 20:12:11 +0100
Daniel Vetter wrote:
> The code already got unwindy and we want to dump more per-ring
> registers.
>
> Only functional change is that we now also capture the video
> ring registers on ilk.
>
> v2: fixup a refactor fumble spotted by Chris Wilson.
>
> Signed-of
On Sun, 30 Oct 2011 18:20:54 -0700, Ben Widawsky wrote:
>
> The solution here is to add a new flag to the call chain which gives the
> routines the information they need to possibly defer actions which may
> cause us to recurse.
This looks a lot nicer; it's shorter than I feared too.
> @@ -2051
On Sun, 30 Oct 2011 20:12:09 +0100
Daniel Vetter wrote:
> In the pre-gem days with non-existing hangcheck and gpu reset code,
> this timeout of 3 seconds was pretty important to avoid stuck
> processes.
>
> But now we have the hangcheck code in gem that goes to great length
> to ensure that the
On Sun, 30 Oct 2011 20:12:08 +0100
Daniel Vetter wrote:
> If our semaphore logic gets confused and we have a ring stuck waiting
> for one, there's a decent chance it'll just execute garbage when being
> kicked. Also, kicking the ring obscures the place where the error
> first occured, making erro
After the ILK vt-d workaround patches it became clear that we had
introduced a bug. Chris tracked down the issue to recursive calls to
unmap. This happens because we try to optimize waiting on requests by
calling retire requests after the wait, which may drop the last
reference on an object and en
On Sun, 2011-10-30 at 16:57 +, Chris Wilson wrote:
> Bugs fixed in this snapshot (compared to 2.16.0)
No hibernation memory corruption fix. Sniff, sniff... :-(
--
Bojan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freede
I had to disable sna in 2.16.0 when running compiz or I'd get some
graphics corruption, and the problem seems to still exist in 2.16.901 as
well. Here's a screenshot I just took on the RC with sna enabled:
http://i.imgur.com/UtQpv.png
I'm on a ThinkPad X220 (i5-2540M) running Gentoo with the
On Sun, 30 Oct 2011 20:12:11 +0100, Daniel Vetter
wrote:
> The code already got unwindy and we want to dump more per-ring
> registers.
So this patch is to cook the spaghetti then? Not sure if unwindy
conjures the right imagery, I still think you mean unwieldly. ;)
> Only functional change is t
Based on a patch by Ben Widawsky, but with different colors
for the bikeshed.
In contrast to Ben's patch this one doesn't add the fault regs.
Afaics they're for the optional page fault support which
- we're not enabling
- and which seems to be unsupported by the hw team. Recent bspec
lacks tons
The code already got unwindy and we want to dump more per-ring
registers.
Only functional change is that we now also capture the video
ring registers on ilk.
v2: fixup a refactor fumble spotted by Chris Wilson.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 55 +++
... and add a helpr function for the places where we want a flag.
This way we can use ring->id to index into arrays.
v2: Resurrect the missing beautification-space Chris Wilson noted.
I'm moving this space around because I'll reuse ring_str in the next
patch.
Signed-off-by: Daniel Vetter
Review
In the pre-gem days with non-existing hangcheck and gpu reset code,
this timeout of 3 seconds was pretty important to avoid stuck
processes.
But now we have the hangcheck code in gem that goes to great length
to ensure that the gpu is really dead before declaring it wedged.
So there's no need for
If our semaphore logic gets confused and we have a ring stuck waiting
for one, there's a decent chance it'll just execute garbage when being
kicked. Also, kicking the ring obscures the place where the error
first occured, making error_state decoding much harder.
So drop this an let gpu reset handl
On Sun, 30 Oct 2011 18:39:03 +, Chris Wilson
wrote:
> On Tue, 11 Oct 2011 21:20:21 +0200, Daniel Vetter
> wrote:
> > Based on a patch by Ben Widawsky, but with different colors
> > for the bikeshed.
> >
> > In contrast to Ben's patch this one doesn't add the fault regs.
> > Afaics they're
On Tue, 11 Oct 2011 21:20:21 +0200, Daniel Vetter
wrote:
> Based on a patch by Ben Widawsky, but with different colors
> for the bikeshed.
>
> In contrast to Ben's patch this one doesn't add the fault regs.
> Afaics they're for the optional page fault support which
> - we're not enabling
> - and
This is the first release candidate in preparation for the upcoming
2.17.0 release. We will appreciate any feedback we can get from
testing of this snapshot.
The basis of this release are to push out a couple of critical stability
fixes for SandyBridge and IvyBridge. There is very little else to s
On Tue, 20 Sep 2011 13:35:56 +0200, Daniel Vetter wrote:
> On Sat, Sep 17, 2011 at 09:57:05PM +0100, Chris Wilson wrote:
> > And whilst you are here, can you incorporate this patch?
> > else if (obj->gtt_space &&
> > +obj->map_and_fenceable &&
> > obj->base
23 matches
Mail list logo