Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > Check that we do not submit two contexts into ELSP with the same CCID > [upper portion of the descriptor]. > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/1793 > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > index d68a04f2a9d5..f8a8cd72f227 100644 > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > @@ -1621,6 +1621,7 @@ assert_pending_valid(const struct intel_engine_execlists *execlists, > struct i915_request * const *port, *rq; > struct intel_context *ce = NULL; > bool sentinel = false; > + u32 ccid = -1; > > trace_ports(execlists, msg, execlists->pending); > > @@ -1654,6 +1655,14 @@ assert_pending_valid(const struct intel_engine_execlists *execlists, > } > ce = rq->context; > > + if (ccid == upper_32_bits(ce->lrc_desc)) { > + GEM_TRACE_ERR("Dup ccid:%x context:%llx in pending[%zd]\n", > + ccid, ce->timeline->fence_context, > + port - execlists->pending); The trace was lost, atleast from me, on the previous logs I looked and thus the value. trace buffer overflowed? But if it was reader error, then perhaps putting this explicitly in dmesg is not necessary. Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > + return false; > + } > + ccid = upper_32_bits(ce->lrc_desc); > + > /* > * Sentinels are supposed to be lonely so they flush the > * current exection off the HW. Check that they are the > -- > 2.20.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
