| Message ID | 20180710113105.17868-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Chris Wilson <chris@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; by 'manual' you are referring to '-1' on i915_wedged debugfs entry? -Mika > 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@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); > + > igt_assert(igt_sysfs_set_parameter > (fd, "reset", "%d", INT_MAX /* any reset method */)); > > -- > 2.18.0 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Mika Kuoppala (2018-07-10 14:13:39) > Chris Wilson <chris@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; > > by 'manual' you are referring to '-1' on i915_wedged debugfs entry? Yes, igt_force_gpu_reset() as opposed to igt_hang_ring(). -Chris
Chris Wilson <chris@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@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. Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> > + > igt_assert(igt_sysfs_set_parameter > (fd, "reset", "%d", INT_MAX /* any reset method */)); > > -- > 2.18.0 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Mika Kuoppala (2018-07-10 14:30:15) > Chris Wilson <chris@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@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
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); + igt_assert(igt_sysfs_set_parameter (fd, "reset", "%d", INT_MAX /* any reset method */));
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@chris-wilson.co.uk> --- lib/igt_gt.c | 7 +++++++ 1 file changed, 7 insertions(+)