From: Ben Widawsky <ben@bwidawsk.net>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Ben Widawsky <benjamin.widawsky@intel.com>,
Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend
Date: Wed, 16 Oct 2013 10:06:27 -0700 [thread overview]
Message-ID: <20131016170627.GA2947@bwidawsk.net> (raw)
In-Reply-To: <20131016165831.GB32493@nuc-i3427.alporthouse.com>
On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
> On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote:
> > Once the machine gets to a certain point in the suspend process, we
> > expect the GPU to be idle. If it is not, we might corrupt memory.
> > Empirically (with an early version of this patch) we have seen this is
> > not the case. We cannot currently explain why the latent GPU writes
> > occur.
> >
> > In the technical sense, this patch is a workaround in that we have an
> > issue we can't explain, and the patch indirectly solves the issue.
> > However, it's really better than a workaround because we understand why
> > it works, and it really should be a safe thing to do in all cases.
> >
> > The noticeable effect other than the debug messages would be an increase
> > in the suspend time. I have not measure how expensive it actually is.
> >
> > I think it would be good to spend further time to root cause why we're
> > seeing these latent writes, but it shouldn't preclude preventing the
> > fallout.
> >
> > NOTE: It should be safe (and makes some sense IMO) to also keep the
> > VALID bit unset on resume when we clear_range(). I've opted not to do
> > this as properly clearing those bits at some later point would be extra
> > work.
> >
> > v2: Fix bugzilla link
>
> And the other one?
>
I'm really amazing. If we move ahead with this patch, Daniel, can you just erase
the extra bugs.freedesktop.org/6549://
> > Bugzilla: http://bugs.freedesktop.org/6549://bugs.freedesktop.org/show_bug.cgi?id=65496
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321
> > Tested-by: Takashi Iwai <tiwai@suse.de>
> > Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
>
> So clearing the valid bit should result in the GPU reporting errors for
> delayed accesses, but none were reported?
> -Chris
>
So I can't actually reproduce the problem for some reason. Paulo will
need to answer. One theory is the fault information is lost on suspend.
The original patch put faults both in suspend, and resume. After this, I
asked Paulo to wedge the GPU, and there I saw faults.
--
Ben Widawsky, Intel Open Source Technology Center
next prev parent reply other threads:[~2013-10-16 17:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 16:18 [PATCH 1/2] drm/i915: Make PTE valid encoding optional Ben Widawsky
2013-10-16 16:18 ` [PATCH 2/2] drm/i915: Disable GGTT PTEs on GEN6+ suspend Ben Widawsky
2013-10-16 16:21 ` [PATCH 2/2] [v2] " Ben Widawsky
2013-10-16 16:58 ` Chris Wilson
2013-10-16 17:06 ` Ben Widawsky [this message]
2013-10-16 17:27 ` Chris Wilson
2013-10-17 7:41 ` Takashi Iwai
2013-10-17 9:24 ` Chris Wilson
2013-10-17 10:06 ` Takashi Iwai
2013-10-18 13:45 ` Daniel Vetter
2013-10-18 0:20 ` Todd Previte
2013-10-18 13:40 ` [PATCH 1/2] drm/i915: Make PTE valid encoding optional 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=20131016170627.GA2947@bwidawsk.net \
--to=ben@bwidawsk.net \
--cc=benjamin.widawsky@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox