Re: [PATCH 1/5] drm/i915: Suppress EIO during set-to-gtt

[Daniel Vetter <daniel@ffwll.ch>]

On Sat, Apr 14, 2012 at 09:55:47AM +0100, Chris Wilson wrote:
> If we fail to flush the rendering to an object already bound to the GTT
> because the hardware is edge, all is good!
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

As already quickly discussed on irc, I'm not too happy about -EIO special
casing in set_to_gtt_domain, set_to_cpu_domain and flush_fence. Imo,
assuming that our hangcheck and wedging code works correctly, we should
bail out of this, the reset code should reset all the gem tracking state
and as long as we dont emit any new requests on the gpu, we should never
need to wait for one and get a -EIO in return.

Reconsidering the -EIO special case in unbind, I'm also not sure any more
that this one's right. In normal operations we should never try to unbind
an active object, which leaves us with the ilk vt-d workaround. That one
should eat the -EIO itself, imo.

Now given how well-tested that code is, I expect bugs. But imo the right
course of action is to make that code testable first before we sprinkle
-EIO handling all over the place. I've planned to resurrect my gpu hangman
this week, and I'm thinking of ways to extend that to test our -EIO/gpu
wedging code.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48