Re: [PATCH] drm/i915: Allow userspace to request no-error-capture upon GPU hangs

From: Dave Gordon <david.s.gordon@intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Allow userspace to request no-error-capture upon GPU hangs
Date: Wed, 16 Dec 2015 17:30:18 +0000	[thread overview]
Message-ID: <56719FAA.1080209@intel.com> (raw)
In-Reply-To: <20151216100914.GT30437@phenom.ffwll.local>

On 16/12/15 10:09, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 10:00:44AM +0000, Chris Wilson wrote:
>> On Wed, Dec 16, 2015 at 09:54:47AM +0100, Daniel Vetter wrote:
>>> On Fri, Dec 11, 2015 at 10:18:35PM +0000, Chris Wilson wrote:
>>>> igt likes to inject GPU hangs into its command streams. However, as we
>>>> expect these hangs, we don't actually want them recorded in the dmesg
>>>> output or stored in the i915_error_state (usually). To accomodate this
>>>> allow userspace to set a flag on the context that any hang emanating
>>>> from that context will not be recorded. We still do the error capture
>>>> (otherwise how do we find the guilty context and know its intent?) as
>>>> part of the reason for random GPU hang injection is to exercise the race
>>>> conditions between the error capture and normal execution.
>>>>
>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>
>>> Hm, I do like that we exercise the full paths all the time, increasing
>>> chances for fireworks. What's the motivation here? Is there some
>>> substantial speed-up?
>>
>> No, since we keep doing the error-capture (we have to, we haven't fixed
>> the bugs in it yet!), the only benefits are:
>>
>> (a) Reduce dmesg spam during igt
>> (b) simulating hangs doesn't leave an error-state around, or rather, we
>> don't leave the simulated error state and igt doesn't eat a *genuine* hang
>> that occurred during or before the test.
>
> Oh, should better wait for coffee to kick in - I didn't realize that all
> that code still runs, and the only thing that changes is whether we'll
> store the capture error state in the global slot used by debugfs.
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Note this is the first version, obsoleted by the one Chris posted 41 
minutes later, and which I already gave an R-B, with qualifications:

http://www.spinics.net/lists/intel-gfx/msg83235.html

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx