From: Daniel Vetter <daniel@ffwll.ch>
To: ville.syrjala@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset
Date: Tue, 29 Jan 2013 17:39:46 +0100 [thread overview]
Message-ID: <20130129163946.GS14766@phenom.ffwll.local> (raw)
In-Reply-To: <1359476018-31274-1-git-send-email-ville.syrjala@linux.intel.com>
On Tue, Jan 29, 2013 at 06:13:32PM +0200, ville.syrjala@linux.intel.com wrote:
> Someone mentioned on irc that intel_crtc_wait_for_pending_flips() was
> getting stuck in some cases. This rang a bell since I was poking around
> that stuff last year.
>
> The issue that I'm trying to fix here is processes getting stuck in D
> state when a GPU reset happens while page flips have been scheduled.
>
> Testing is easy 1) fire up 'glxgears -fullscreen', run 'gem_hang 0',
> try to VT switch. Without this series X and some kworker soon get stuck
> in D state and you're left with a useless box. With the patch set, you
> wait a while, the GPU hangcheck kicks in, and you get your console back.
Broken record maintainer request: Can you please bake that into an i-g-t?
I think (hope) that running one of the delayed flip tests vs. the hangman
(gem_hang is a bit evil since it can kill boxes for real) should do the
trick. Then maybe also run one of the wf-vblank tests vs. hangman to check
that we cancel those correctly, too.
> The irc discussion was apparently about [1], but since the dmesg there
> doesn't show a GPU hang, I don't see this patch set fixing it. Frankly,
> I have no idea what's happening there.
>
> Additional work after this would involve sending out pending page flip
> events. Currently if you don't do the VT switch after a hang, glxgears
> remains stuck because the X server didn't get the page flip event from
> the kernel. Also we should probably do an explicit intel_pipe_set_base()
> with the current fb, to make sure we show the correct fb after the hang.
> But I'm not going to touch these right now. Actually I'm hoping someone
> else will volunteer for these tasks ;)
Hm ... I guess we need to walk the file_priv event list somewhere an fire
them all off, indicating somehow that things went kaboom. I think we
should aim for a drm generic way to singal those even.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2013-01-29 16:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 16:13 [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset ville.syrjala
2013-01-29 16:13 ` [PATCH 1/6] drm/i915: Kill obj->pending_flip ville.syrjala
2013-02-13 10:16 ` Damien Lespiau
2013-02-13 16:13 ` Daniel Vetter
2013-01-29 16:13 ` [PATCH 2/6] drm/i915: Don't wait for page flips if there was GPU reset ville.syrjala
2013-02-13 10:23 ` Damien Lespiau
2013-02-13 10:51 ` Ville Syrjälä
2013-02-13 11:49 ` Daniel Vetter
2013-02-13 15:23 ` Daniel Vetter
2013-02-13 16:52 ` Ville Syrjälä
2013-02-13 17:09 ` Daniel Vetter
2013-01-29 16:13 ` [PATCH 3/6] drm/i915: Wake up pending_flip_queue as part of reset handling ville.syrjala
2013-02-13 10:24 ` Damien Lespiau
2013-02-13 15:31 ` Daniel Vetter
2013-01-29 16:13 ` [PATCH 4/6] drm/i915: Move intel_crtc_has_pending_flip() earlier ville.syrjala
2013-02-13 10:27 ` Damien Lespiau
2013-01-29 16:13 ` [PATCH 5/6] drm/i915: Add intel_crtc_wait_for_pending_flips_locked() ville.syrjala
2013-02-13 10:37 ` Damien Lespiau
2013-01-29 16:13 ` [PATCH 6/6] drm/i915: Really wait for pending flips in intel_pipe_set_base() ville.syrjala
2013-02-13 10:40 ` Damien Lespiau
2013-02-13 15:49 ` Daniel Vetter
2013-02-13 17:06 ` Ville Syrjälä
2013-02-13 17:11 ` Daniel Vetter
2013-02-13 17:26 ` Ville Syrjälä
2013-02-13 17:31 ` Daniel Vetter
2013-02-13 17:39 ` Chris Wilson
2013-01-29 16:39 ` Daniel Vetter [this message]
2013-01-29 16:40 ` [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset Daniel Vetter
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=20130129163946.GS14766@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.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.