Quoting Mika Kuoppala (2017-07-10 15:14:19) > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > > > Since we make call i915_gem_context_mark_guilty() concurrently when > > resetting different engines in parallel, we need to make sure that our > > updates are safe for the unlocked access. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Michel Thierry <michel.thierry@xxxxxxxxx> > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > And we dont ever clear the context bannable flag so > this should be fine. > > One improvement would be that only the triggering > ban would spew the message. But now thinking about it, > the dual message would reveal the concurrent ban and > is more informative. It only tells you that we encountered a race condition in handling a reset on two engines. A double ban message is going to be more confusing than anything. Did I send the patch to add the user message for the per-engine reset? I was having withdrawal symptoms from not seeing it before mesa died. Otoh, we clearly do propagate the error to userspace, but on the other hand I'm used to seeing it. It's akin to the kernel reporting when it sends a terminal signal to a process. I've been trying to find that to see if they discuss the same issue and in particular why its hidden behind kconfig and sysctl. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
