drm/i915: don't return a spurious -EIO from intel_ring_begin
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Wed, 4 Jul 2012 20:52:50 +0000 (22:52 +0200)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Thu, 5 Jul 2012 08:03:45 +0000 (10:03 +0200)
commitde2b998552c1534e87bfbc51ec5734b02bc89020
tree06385a5a5f55fd7dc072073fddbd22e678d5e5ba
parenta9340ccab547f24e3b398b7e3ebd792827ff1be1
drm/i915: don't return a spurious -EIO from intel_ring_begin

The issue with this check is that it results in userspace receiving an
-EIO while the gpu reset hasn't completed, resulting in fallback to sw
rendering or worse.

Now there's also a stern comment in intel_ring_wait_seqno saying that
intel_ring_begin should not return -EAGAIN, ever, because some callers
can't handle that. But after an audit of the callsites I don't see any
issues. I guess the last problematic spot disappeared with the removal
of the pipelined fencing code.

So do the right thing and call check_wedge, which should properly
decide whether an -EAGAIN or -EIO is appropriate if wedged is set.

Note that the early check for a wedged gpu before touching the ring is
rather important (and it took me quite some time of acting like the
densest doofus to figure that out): If we don't do that and the gpu
died for good, not having been resurrect by the reset code, userspace
can merrily fill up the entire ring until it notices that something is
amiss.

Allowing userspace to emit more render, despite that we know that it
will fail can't lead to anything good (and by experience can lead to
all sorts of havoc, including angering the OOM gods and hard-hanging
the hw for good).

v2: Fix EAGAIN mispell, noticed by Chris Wilson.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/intel_ringbuffer.c