On Tue, 20 Sep 2011 13:35:56 +0200, Daniel Vetter dan...@ffwll.ch 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
On Tue, 11 Oct 2011 21:20:21 +0200, Daniel Vetter daniel.vet...@ffwll.ch
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
On Sun, 30 Oct 2011 18:39:03 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, 11 Oct 2011 21:20:21 +0200, Daniel Vetter daniel.vet...@ffwll.ch
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
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
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
... 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
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 daniel.vet...@ffwll.ch
---
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
On Sun, 30 Oct 2011 20:12:11 +0100, Daniel Vetter daniel.vet...@ffwll.ch
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
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, 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
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
On Sun, 30 Oct 2011 20:12:08 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Sun, 30 Oct 2011 20:12:09 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Sun, 30 Oct 2011 18:20:54 -0700, Ben Widawsky b...@bwidawsk.net 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
On Sun, 30 Oct 2011 20:12:11 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Sun, 30 Oct 2011 20:12:10 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Sun, 30 Oct 2011 18:47:50 -0700
Ben Widawsky b...@bwidawsk.net wrote:
On Sun, 30 Oct 2011 20:12:11 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Sun, 30 Oct 2011 20:12:12 +0100
Daniel Vetter daniel.vet...@ffwll.ch 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
On Sun, 30 Oct 2011 18:52:10 -0700, Ben Widawsky b...@bwidawsk.net 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
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
21 matches
Mail list logo
