[Intel-gfx] [PATCH 5/6] drm/i915: Implement GPU reset

Ben Gamari bgamari.foss at gmail.com
Sun Sep 13 22:56:16 CEST 2009


On Sun, Sep 13, 2009 at 09:40:11PM +0100, Owain Ainsworth wrote:
> 
> my version of the code doesn't actually do this and it managed fine.
> 
> where we'll be locked (and blocking) is essentially whenever we hit
> i915_wait_request. now, that fucntion in it's sleeping loop does check
> whether wedged is set, if so it EIO's out of there. So we set wedged (we
> MUST do that first), then we wakeup all sleepers. Now, anyone sleeping
> (and since they always sleep with the lock) will check the condition and
> return EIO, where they're release the lock and dump that return back to
> userland. Anything else means that something else is buggy.
> 
> such contention problems on openbsd i've not seen. The only other option
> I can see is in wait_ring, where we should really also check for wedged
> and if so cede the lock and try again, but that's a different problem,
> really and has been a problem for $LONG_TIME

Certainly. This code should be redundant in almost all cases. While
debugging the patch I saw contention issues but these were probably
triggered by bugs in my code. I kept the code, however, for cases such
as the one you mention (and because I didn't think to remove it). While
theoretically the locking semantics should preclude these cases, one
never knows. If we can agree to clean up all of the locking paths to
honor .wedged, then I agree that this code serves no purpose.

- Ben




More information about the Intel-gfx mailing list