public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Ben Widawsky <benjamin.widawsky@intel.com>
Subject: Re: [PATCH 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend
Date: Fri, 18 Oct 2013 15:45:43 +0200	[thread overview]
Message-ID: <20131018134543.GY4830@phenom.ffwll.local> (raw)
In-Reply-To: <20131016170627.GA2947@bwidawsk.net>

On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote:
> 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

Fixed and merged with cc: stable.
-Daniel

> 
> > > 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
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

  parent reply	other threads:[~2013-10-18 13:45 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
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 [this message]
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=20131018134543.GY4830@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ben@bwidawsk.net \
    --cc=benjamin.widawsky@intel.com \
    --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