On Wed, Jul 19, 2017 at 4:05 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: > On Wed, Jul 19, 2017 at 3:42 PM, Chris Wilson <ch...@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?
Obviously, because that's what we're doing already. But I don't have the DRM_ERROR from i915_gem_wait_for_error anywhere in my logs either, so not clear what exactly is going on ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
