[igt-dev] [Intel-gfx] [PATCH i-g-t] lib: Require working GEM (!wedged) to allow hang injection

[Chris Wilson]

Quoting Mika Kuoppala (2018-07-10 14:30:15)
> Chris Wilson <chris at chris-wilson.co.uk> writes:
> 
> > As we ordinarily use a spinning batch to trigger a hang, we cannot do so
> > without execbuf. On the other hand, if we do a manual reset of the
> > wedged driver, we expect it to remain wedged and for the reset to fail;
> > failing the test. Even if we remove the igt_assert(!wedged), the test is
> > suspect as we don't know if the reset took place and so do not know if
> > the conditions the test is trying to setup apply.
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > ---
> >  lib/igt_gt.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> > index 4569fd36b..89b318ae6 100644
> > --- a/lib/igt_gt.c
> > +++ b/lib/igt_gt.c
> > @@ -162,6 +162,13 @@ igt_hang_t igt_allow_hang(int fd, unsigned ctx, unsigned flags)
> >       };
> >       unsigned ban;
> >  
> > +     /*
> > +      * If the driver is already wedged, we don't expect it to be able
> > +      * to recover from reset and for it to remain wedged. It's hard to
> > +      * say even if we do hang/reset making the test suspect.
> > +      */
> > +     igt_require_gem(fd);
> 
> This will do a manual reset for a wedged driver, trying to rectify the
> situation. But we are on a more solid ground after it.

Hmm, true. Need to wait to make sure it doesn't interfere with gem_eio
and its ilk. I think it remains sensible to verify that we have a
working GEM driver before testing, but there will be a time when we need
something not quite so heavy handed.
-Chris