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@xxxxxxxxxxxxxxxxxx>
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@xxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
