Quoting Tvrtko Ursulin (2020-04-23 15:47:58) > > On 23/04/2020 09:59, Chris Wilson wrote: > > When recording the default context state, we submit an ordinary context > > and then steal the context image for our defaults. To be able to steal > > the state, we must have total ownership of the context. During CI we > > want to make this error extremely obvious, as otherwise we will fail the > > user's module load. > > > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/1763 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/gt/intel_gt.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c > > index 1c99cc72305a..379eb39e7979 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > > @@ -472,6 +472,7 @@ static int __engines_record_defaults(struct intel_gt *gt) > > > > /* We want to be able to unbind the state from the GGTT */ > > GEM_BUG_ON(intel_context_is_pinned(rq->context)); > > + GEM_BUG_ON(i915_vma_is_pinned(state)); > > Not sure - context->state ownership is in the context pinned status and > then there is the unbind below which will fail if vma is pinned. Which > sounds better than a bug on. Is it difficult to figure out what is > failing in practice? A debug message on the unbind failure path might be > more friendly in that case. I was able to recognise the failure :) I thought this might be more explicit. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx