Commit 68ad3612 authored by Chris Wilson's avatar Chris Wilson

drm/i915: Only call tasklet_kill() on the first prepare_reset

tasklet_kill() will spin waiting for the current tasklet to be executed.
However, if tasklet_disable() has been called, then the tasklet is never
executed but permanently put back onto the runlist until
tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
disable/enable pair. This is the case when we call set-wedge from inside
i915_reset(), and another request was submitted to us concurrent to the
reset.

Fixes: 963ddd63 ("drm/i915: Suspend submission tasklets around wedging")
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180307134226.25492-6-chris@chris-wilson.co.uk
parent 47650db0
......@@ -2948,8 +2948,16 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs *engine)
* calling engine->init_hw() and also writing the ELSP.
* Turning off the execlists->tasklet until the reset is over
* prevents the race.
*
* Note that this needs to be a single atomic operation on the
* tasklet (flush existing tasks, prevent new tasks) to prevent
* a race between reset and set-wedged. It is not, so we do the best
* we can atm and make sure we don't lock the machine up in the more
* common case of recursively being called from set-wedged from inside
* i915_reset.
*/
tasklet_kill(&engine->execlists.tasklet);
if (!atomic_read(&engine->execlists.tasklet.count))
tasklet_kill(&engine->execlists.tasklet);
tasklet_disable(&engine->execlists.tasklet);
/*
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment