Quoting Mika Kuoppala (2019-11-28 11:27:30) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > We have a case of a mysteriously absent pulse, so dump the engine > > details to see if we can find out what happened to it. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=112405 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++ > > drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 5 +++++ > > 2 files changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c > > index 8f6e353caa66..df3369c3f330 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c > > @@ -1479,6 +1479,8 @@ void intel_engine_dump(struct intel_engine_cs *engine, > > drm_printf(m, "*** WEDGED ***\n"); > > > > drm_printf(m, "\tAwake? %d\n", atomic_read(&engine->wakeref.count)); > > + drm_printf(m, "\tBarriers?: %s\n", > > + yesno(!llist_empty(&engine->barrier_tasks))); > > A random thought arise when reading this and it was that > should we do a memory barrier before dump. But there > would be no pairing and it could actually hide something > more sinister. Yeah, exactly who do we want to serialise with -- and we will always need a snapshot just in case we screw that up :) It's debug; as async as we can without oopsing, and keep on staring until it starts to make sense. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
