[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen11: Add Wa_1604278689:icl,ehl

[Chris Wilson]

Quoting Matt Roper (2019-08-16 17:29:09)
> On Fri, Aug 16, 2019 at 08:07:18AM +0100, Chris Wilson wrote:
> > Quoting Patchwork (2019-08-16 00:52:20)
> > > #### Possible regressions ####
> > > 
> > >   * igt at i915_selftest@live_hangcheck:
> > >     - fi-icl-u3:          [PASS][1] -> [DMESG-FAIL][2]
> > >    [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
> > >    [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
> > >     - {fi-icl-dsi}:       [PASS][3] -> [DMESG-FAIL][4]
> > >    [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
> > >    [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html
> > >     - {fi-icl-u4}:        [PASS][5] -> [DMESG-FAIL][6]
> > >    [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6714/fi-icl-u4/igt@i915_selftest@live_hangcheck.html
> > >    [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14040/fi-icl-u4/igt@i915_selftest@live_hangcheck.html
> > 
> > All icl machines suffering a similar failure to reset an engine (not
> > rcs!). We haven't seen that before, so it does look very suspicious.
> > -Chris
> 
> Hmm.  So for a render engine register that's saved/restored as part of
> the context, is there somewhere else I should be setting this value?  My
> understanding was that the items added in *_ctx_workarounds_init only
> applied to the render engine (since __intel_engine_init_ctx_wa bails out
> for other engine classes), yet it seems it's the BCS engine that's
> failing to reset with this patch?.  If I just I915_WRITE to this
> register, won't the value only apply to whichever context is currently
> executing on the RCS engine and be lost when other contexts switch in?

The magic is in the ordering. If you put it in the gt_workarounds, it
gets applied before we record the default context image -- and so it
gets copied into all subsequent contexts.

The only reason why we still have ctx_workarounds is that some registers
had to be written via CS, and it's easy for us to apply the rule "if the
spec says it is a context register, put it in the ctx_workarounds". We
also use that to determine whether to use a SRM or mmio verification.

At the end of the day, whatever works :)
-Chris