Quoting Mika Kuoppala (2018-07-10 14:30:15)
> Chris Wilson 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;
> >
Chris Wilson 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
Quoting Mika Kuoppala (2018-07-10 14:13:39)
> Chris Wilson 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;
>
Chris Wilson 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
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
