[Intel-gfx] [PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock
Daniel Vetter
daniel.vetter at ffwll.ch
Wed Jul 19 14:05:30 UTC 2017
On Wed, Jul 19, 2017 at 3:42 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Quoting Daniel Vetter (2017-07-19 13:54:58)
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index 5aa7ca1ab592..4762f158032d 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -3471,10 +3471,9 @@ void intel_prepare_reset(struct drm_i915_private *dev_priv)
>> !gpu_reset_clobbers_display(dev_priv))
>> return;
>>
>> - /* We have a modeset vs reset deadlock, defensively unbreak it.
>> - *
>> - * FIXME: We can do a _lot_ better, this is just a first iteration.*/
>> - i915_gem_set_wedged(dev_priv);
>> + /* We have a modeset vs reset deadlock, defensively unbreak it. */
>> + set_bit(I915_RESET_MODESET, &dev_priv->gpu_error.flags);
>> + wake_up_all(&dev_priv->gpu_error.wait_queue);
>
> How are we breaking the
>
> modeset_lock -> struct_mutex -> wait_on_reset ?
>
> We wait the modeset_lock next which stops the reset from
> proceeding, and so the deadlock persists until the wedge-me timeout?
Hm indeed, I didn't check my logs carefully enough and there's still
"i915_reset_device timed out" in it. But I also thought the only real
wait we have left for the gpu is the one under i915_sw_fence. I think
we could simply switch i915_mutex_lock_interruptible calls in atomic
modeset over mutex_lock_interruptible? Or is there another can of
worms I'm missing?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list