Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > Provide some serialisation between user operations by waiting for the > reset initiated by setting i915_wedged to complete. > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxx> > --- > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > index 5fdf8c137235..ada823815b8a 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -4129,6 +4129,10 @@ i915_wedged_set(void *data, u64 val) > i915_handle_error(dev_priv, val, > "Manually setting wedged to %llu", val); > > + wait_on_bit(&dev_priv->gpu_error.flags, > + I915_RESET_HANDOFF, > + TASK_UNINTERRUPTIBLE); > + But what happens here if we have already prevented the reset and the handoff never clears? Seems like it is a stuck task as the handoff is not cleared on error path in i915_reset. -Mika > return 0; > } > > -- > 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
