Quoting Sagar Arun Kamble (2018-04-05 11:02:33) > > > On 4/5/2018 6:03 AM, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [v6,01/12] drm/i915: Correctly handle error > > path in i915_gem_init_hw > > URL : https://patchwork.freedesktop.org/series/41159/ > > State : failure > > > > == Summary == > > > > ---- Possible new issues: > > > > Test gem_eio: > > Subgroup execbuf: > > pass -> INCOMPLETE (shard-apl) > I am seeing this failure w/o this patch series too. > Working fix that I have tried is to unpark from reset path explicitly > if GT is awake: > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > b/drivers/gpu/drm/i915/i915_drv.c > index d354627..2fc9d0e 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1960,6 +1960,9 @@ void i915_reset(struct drm_i915_private *i915) > goto error; > } > > + if (i915->gt.awake) > + intel_engines_unpark(i915); > + > i915_queue_hangcheck(i915); > > finish: > > This way we will balance the irq refcounts.
Only for them to be unbalanced on resume... Just we don't currently warn about that. But that's the kind of plan I have, before we call reset_default_submission in unwedge, to bludgeon through the full idle sequence. Just means playing about with the idle worker to extract what we need from under the mutex, probably calling it i915_gem_park in the process. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
