On Fri, Aug 11, 2017 at 11:36:15AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-08-11 09:04:18) > > On Fri, Aug 11, 2017 at 09:23:27AM +0200, Daniel Vetter wrote: > > > In our snb farm in CI we have plenty of underruns, but not enough > > > stolen memory to enable fbc. Which means every time there's an > > > underrun the no_fbc_reason swichtes to something that makes > > > kms_frontbuffer_tracking fail instead of skip, adding massive amounts > > > of additional noise to igt test runs. > > > > > > Make sure we don't try to disable fbc when it's off already. > > > > > > Cc: Paulo Zanoni <paulo.r.zan...@intel.com> > > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > > > > Note this seems to be the real bug that's causing all the spurious noise > > on snb CI in the full run. So pretty important to land this fast. > > Yup, this is more than just silencing CI, this looks to be a > precondition for intel_fbc_deactivate() -- all other callers check for > fbc->enabled before calling deactivate. I would even suggest we add a > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c > b/drivers/gpu/drm/i915/intel_fbc.c > index 122d6372f58d..0c6e66f8a0f1 100644 > --- a/drivers/gpu/drm/i915/intel_fbc.c > +++ b/drivers/gpu/drm/i915/intel_fbc.c > @@ -485,6 +485,9 @@ static void intel_fbc_deactivate(struct drm_i915_private > *dev_priv) > > WARN_ON(!mutex_is_locked(&fbc->lock)); > > + if (WARN_ON(!fbc->enabled)) > + return; > +
Good idea, squashed in and applied. -Daniel > > Either way, > Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk> > -Chris -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
