[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,01/12] drm/i915: Correctly handle error path in i915_gem_init_hw

[Chris Wilson]

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