From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
DRI Development <dri-devel@lists.freedesktop.org>,
Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock
Date: Wed, 19 Jul 2017 16:05:30 +0200 [thread overview]
Message-ID: <CAKMK7uHpHa2kgBD8oMGf27=hz0pr7z_BSQP6nB65VFbUoiJY1g@mail.gmail.com> (raw)
In-Reply-To: <150047174146.30670.1909725264954551895@mail.alporthouse.com>
On Wed, Jul 19, 2017 at 3:42 PM, Chris Wilson <chris@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-07-19 14:05 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-19 12:54 [PATCH 0/9] gpu reset vs modeset fix, plus page_flip removal Daniel Vetter
2017-07-19 12:54 ` [PATCH 1/9] drm/i915: Nuke legacy flip queueing code Daniel Vetter
2017-07-19 12:54 ` [PATCH 2/9] drm/i915: Unbreak gpu reset vs. modeset locking Daniel Vetter
2017-07-19 12:54 ` [PATCH 3/9] drm/i915: Avoid the gpu reset vs. modeset deadlock Daniel Vetter
2017-07-19 13:32 ` Chris Wilson
2017-07-19 13:44 ` Daniel Vetter
2017-07-19 18:44 ` Daniel Vetter
2017-07-19 12:54 ` [PATCH 4/9] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit Daniel Vetter
2017-07-19 13:04 ` Chris Wilson
2017-07-19 13:14 ` Daniel Vetter
2017-07-19 12:54 ` [PATCH 5/9] drm/i915: More surgically unbreak the modeset vs reset deadlock Daniel Vetter
2017-07-19 13:42 ` Chris Wilson
2017-07-19 14:05 ` Daniel Vetter [this message]
2017-07-19 14:11 ` Daniel Vetter
2017-07-19 12:54 ` [PATCH 6/9] drm/i915: Rip out legacy page_flip completion/irq handling Daniel Vetter
2017-07-19 12:55 ` [PATCH 7/9] drm/i915: adjust has_pending_fb_unpin to atomic Daniel Vetter
2017-07-19 13:06 ` Chris Wilson
2017-07-19 13:15 ` Daniel Vetter
2017-07-19 14:08 ` [Intel-gfx] " Chris Wilson
2017-07-19 12:55 ` [PATCH 8/9] drm/i915: Remove intel_flip_work infrastructure Daniel Vetter
2017-07-19 13:07 ` Chris Wilson
2017-07-19 13:24 ` [Intel-gfx] " Daniel Vetter
2017-07-19 14:16 ` Chris Wilson
2017-07-19 12:55 ` [PATCH 9/9] drm/i915: Drop unpin stall in atomic_prepare_commit Daniel Vetter
2017-07-19 13:09 ` Chris Wilson
2017-07-19 13:20 ` Daniel Vetter
2017-07-19 14:01 ` Maarten Lankhorst
2017-07-20 8:46 ` Daniel Vetter
2017-07-19 14:15 ` ✓ Fi.CI.BAT: success for gpu reset vs modeset fix, plus page_flip removal Patchwork
2017-07-19 14:46 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKMK7uHpHa2kgBD8oMGf27=hz0pr7z_BSQP6nB65VFbUoiJY1g@mail.gmail.com' \
--to=daniel.vetter@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=mika.kuoppala@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.