[Intel-gfx] [PATCH] drm/i915: Add a strong mb to resetting the has-CS-interrupt bit

Chris Wilson chris at chris-wilson.co.uk
Tue Dec 19 12:48:00 UTC 2017


Quoting Tvrtko Ursulin (2017-12-19 12:26:38)
> 
> On 19/12/2017 09:01, Chris Wilson wrote:
> > After a reset, the state of the CSB registers are scrubbed and not valid
> > until a powercontext is reloaded. We only know when a powercontext has
> > been reloaded once we see a CS-interrupt, before then we must ignore the
> > CSB registers within the execlists_submission_tasklet. However, glk is
> > sporadically dying with an illegal CSB pointer value (both in the HSWP
> > and mmio) suggesting that it is running with the CS-interrupt bit set
> > before the powercontext has been reloaded. Make sure the clearing of
> > that bit is serialised on reset with the re-enabling of the tasklet.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104262
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > Cc: MichaƂ Winiarski <michal.winiarski at intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > ---
> >   drivers/gpu/drm/i915/i915_gem.c | 6 +++++-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index 5b4cfb20de97..a68fc1240c95 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3089,7 +3089,11 @@ i915_gem_reset_request(struct intel_engine_cs *engine,
> >   void i915_gem_reset_engine(struct intel_engine_cs *engine,
> >                          struct drm_i915_gem_request *request)
> >   {
> > -     engine->irq_posted = 0;
> > +     /*
> > +      * Make sure this write is visible before we re-enable the interrupt
> > +      * handlers on another CPU.
> > +      */
> 
> After IRC discussion you could add "because tasklet_enable is only a 
> compiler barrier, so not enough", or something.

Thanks, mentioned that tasklet_enable() resolves to just a compiler
barrier which should help us recheck this in future if we stumble over
it again.
-Chris


More information about the Intel-gfx mailing list