Quoting Chris Wilson (2019-10-14 10:27:59) > 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. Same being true for cancel_requests, on wedging we have to disable the tasklet before taking control of the state. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
