Quoting Tvrtko Ursulin (2019-10-14 10:25:04) > > On 13/10/2019 20:31, Chris Wilson wrote: > > We rely on only the tasklet being allowed to call into process_csb(), so > > assert that is locked when we do. As the tasklet uses a simple bitlock, > > there is no strong lockdep checking so we must make do with a plain > > assertion that the tasklet is running and assume that we are the > > tasklet! > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > --- > > drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + > > drivers/gpu/drm/i915/i915_gem.h | 5 +++++ > > 2 files changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > > index 8be9e69d5718..ab20433182d1 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > > @@ -1984,6 +1984,7 @@ static void process_csb(struct intel_engine_cs *engine) > > u8 head, tail; > > > > GEM_BUG_ON(USES_GUC_SUBMISSION(engine->i915)); > > + GEM_BUG_ON(!tasklet_is_locked(&execlists->tasklet)); > > I see some reset paths calling process_csb which looks like a problem > for this assert. Oh, no it's not :) execlists_reset() is surrounded by reset_prepare and reset_finish who are responsible for disabling the tasklet and serialising with direct submission around the reset. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
