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 at 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 at ffwll.ch Mobile: +41 (0)79 365 57 48
