Quoting Mika Kuoppala (2020-04-27 18:31:37) > 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. The trick is to look at the pstores. Or to reproduce it locally where you can remotely capture the full trace. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
