[Intel-gfx] [PATCH 1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock

Daniel Vetter daniel.vetter at ffwll.ch
Thu Jul 20 20:18:19 UTC 2017


On Thu, Jul 20, 2017 at 10:16 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Quoting Daniel Vetter (2017-07-20 21:04:50)
>> On Thu, Jul 20, 2017 at 9:47 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> >> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> >> index 02b1f4966049..995522e40ec1 100644
>> >> --- a/drivers/gpu/drm/i915/intel_display.c
>> >> +++ b/drivers/gpu/drm/i915/intel_display.c
>> >> @@ -3471,6 +3471,12 @@ 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);
>> >> +       DRM_DEBUG_DRIVER("Wedging GPU to avoid deadlocks with pending modeset updates\n");
>> >
>> > I meant this a dev_err(). It has user visible impact and user data loss.
>>
>> stop_rings is gone so I can't differentiate, and DRM_ERROR breaks CI.
>> Which after your timeout is the only point of this patch really.
>
> So drop this patch. If the only reason is to sweep the bug under the
> carpet, don't. I thought this patch was to move the wedge to where you
> planned to replace it with the refined approach to abort the modeset.

It fixes a regression we have in CI, because the dmesg-warn can hide
other stuff. If you want, resurrect some better way to handle that,
meanwhile this here gets the job done. Since the latter patches don't
work I'm proposing just this one here for merging.
-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