[Intel-gfx] [PATCH 3/5] drm/i915: don't return a spurious -EIO from intel_ring_begin

[Daniel Vetter]

On Mon, Jun 25, 2012 at 11:06 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Mon, 25 Jun 2012 22:49:03 +0200, Daniel Vetter <daniel at ffwll.ch> wrote:
>> On Mon, Jun 25, 2012 at 09:32:23PM +0100, Chris Wilson wrote:
>> > It looks like the patch to reuse check_wedge() should be first as it is
>> > the common theme in the series.
>>
>> Hm, actually I think I'll smash the check_wedge into the last patch. With
>> that change, this patch would solely be about not returning spurious -EIO,
>> whereas the last patch would be solely about not returning -EAGAIN in
>> cases we can't handle. Does that make some sense?
>
> The split sounds reasonable, grouping the patch in that manner should
> give a better story. My only holdout is that I don't want to lose the
> papering in i915_reset().

Hm, I'm not yet convinced on the quality of that ductape. I've went
with the unconditional mutex_lock, deadlocks be damned, approach
because:
- QA has a machine that seemingly _always_ hits this problem. Here it
depends upon the machine and ranges from "fails after a few hundred
reset cycles" to "fails after 5 runs at most".
- Eric complained that when developing new userspace driver code the
gpu gets wedged every once in a while resetting his gpu pretty much
after every compile&run cycle.
So to make life easier for QA and userspace driver devs I've opted to
make it succed (or deadlock), and presuming the kernel code actually
works. Now kernel devs obviously prefer to blows things up with an
OOPS or two, so I see that we should have some balance. But even there
my thinking is that waiting for the stuck process backtrace is better
than trying to paper over severe issues when the systems has clearly
lost its mind already.

So essentially I still fail to see the upside of your proposed ductape
... In either case I guess a walk to the reset button is inevitable
every once in a while ;-)

Yours, Daniel
-- 
Daniel Vetter
daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch