[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v8,01/12] drm/i915: Park before resetting the submission backend

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-04-10 06:32:29)
> 
> 
> On 4/9/2018 9:02 PM, Michal Wajdeczko wrote:
> > On Mon, 09 Apr 2018 17:09:18 +0200, Patchwork 
> > <patchwork at emeril.freedesktop.org> wrote:
> >
> >> == Series Details ==
> >>
> >> Series: series starting with [v8,01/12] drm/i915: Park before 
> >> resetting the submission backend
> >> URL   : https://patchwork.freedesktop.org/series/41365/
> >> State : failure
> >>
> >> == Summary ==
> >>
> >> ---- Possible new issues:
> >
> > two variants:
> >
> >>
> >> Test drm_mm:
> >>         Subgroup sanitycheck:
> >>                 pass       -> INCOMPLETE (shard-apl)
> >
> > #1
> >
> > <0>[  400.245461] drv_self-5775    1.... 400208508us : 
> > intel_guc_submission_disable: intel_guc_submission_disable:1255 
> > GEM_BUG_ON(dev_priv->gt.awake)
> >
> > <4>[  400.245871] Call Trace:
> > <4>[  400.245959]  intel_uc_fini_hw+0x4b/0xe0 [i915]
> > <4>[  400.246047]  i915_gem_fini_hw+0x16/0x30 [i915]
> > <4>[  400.246129]  i915_reset+0x1e8/0x2b0 [i915]
> > <4>[  400.246222]  igt_global_reset+0x38/0xe0 [i915]
> >
> Without gem_set_wedged if i915_reset path is invoked we can face this issue.
> igt_global_reset and gem_eio resets are directly invoking 
> i915_handle_error/i915_reset so I think we should fix the IGTs.

No, wrong answer.

> >> Test drv_hangman:
> >>         Subgroup error-state-capture-blt:
> >>                 pass       -> INCOMPLETE (shard-apl)
> >>         Subgroup error-state-capture-bsd:
> >>                 pass       -> INCOMPLETE (shard-apl)
> >>         Subgroup error-state-capture-render:
> >>                 pass       -> INCOMPLETE (shard-apl)
> >>         Subgroup error-state-capture-vebox:
> >>                 pass       -> INCOMPLETE (shard-apl)
> >> Test drv_selftest:
> >>         Subgroup live_guc:
> >>                 pass       -> SKIP       (shard-apl)
> >>         Subgroup live_hangcheck:
> >>                 pass       -> DMESG-FAIL (shard-apl)
> >> Test gem_eio:
> >>         Subgroup execbuf:
> >>                 pass       -> INCOMPLETE (shard-apl)
> >
> > #2:
> >
> > <3>[  227.833798] intel_engine_unpin_breadcrumbs_irq:219 
> > GEM_BUG_ON(!b->irq_enabled)
> >
> > <4>[  227.834607] Call Trace:
> > <4>[  227.834691]  intel_engines_park+0xef/0x180 [i915]
> > <4>[  227.834709]  ? synchronize_irq+0x3e/0xb0
> > <4>[  227.834781]  __i915_gem_park+0x3e/0x160 [i915]
> > <4>[  227.834850]  i915_gem_idle_work_handler+0x1cd/0x220 [i915]
> > <4>[  227.834868]  process_one_work+0x21a/0x640
> >
> >
> irq disabling with GuC submission is not taking into consideration if it 
> was enabled by waiter.

irqs cannot be disabled while in guc mode. It is still the same problem
of being unbalanced across enabling. (i.e. we switch to another mode to
submit the request and then enable the guc, ergo the guc never pins the
irq for itself.)
-Chris