The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Dave Airlie <airlied@gmail.com>
Cc: "Stéphane Marchesin" <marcheu@chromium.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	olofj@chromium.org, torvalds@linux-foundation.org
Subject: Re: [PATCH] mm: Work around Intel SNB GTT bug with some physical pages.
Date: Tue, 8 May 2012 09:21:09 +0200	[thread overview]
Message-ID: <20120508072109.GA4802@phenom.ffwll.local> (raw)
In-Reply-To: <CAPM=9txbqEsejvtQJ9XfRcuU-vwJUkASTW6cxEhbwf0tUTSTow@mail.gmail.com>

On Tue, May 08, 2012 at 07:53:36AM +0100, Dave Airlie wrote:
> On Tue, May 8, 2012 at 12:13 AM, Stéphane Marchesin
> <marcheu@chromium.org> wrote:
> > While investing some Sandy Bridge rendering corruption, I found out
> > that all physical memory pages below 1MiB were returning garbage when
> > read through the GTT. This has been causing graphics corruption (when
> > it's used for textures, render targets and pixmaps) and GPU hangups
> > (when it's used for GPU batch buffers).
> >
> > I talked with some people at Intel and they confirmed my findings,
> > and said that a couple of other random pages were also affected.
> >
> > We could fix this problem by adding an e820 region preventing the
> > memory below 1 MiB to be used, but that prevents at least my machine
> > from booting. One could think that we should be able to fix it in
> > i915, but since the allocation is done by the backing shmem this is
> > not possible.
> >
> > In the end, I came up with the ugly workaround of just leaking the
> > offending pages in shmem.c. I do realize it's truly ugly, but I'm
> > looking for a fix to the existing code, and am wondering if people on
> > this list have a better idea, short of rewriting i915_gem.c to
> > allocate its own pages directly.
> 
> Ouch, can Intel get some details on why these pages are "special" and
> if they are special across chipsets, Ironlake? Ivybridge?
> 
> Like I can handle the < 1MB but the other selected pages look pretty
> random or misc, (2005, 2011, 2013? years?, 40004000, some shout out to
> the 4004?

I've discussed this with Stéphane, and that enumeration of 5 pages is
exhaustive. And both these 4 pages and the low 1mb block only cause
problems on snb (ivb and later is fixed). For the special pages the
official workaround is that the bios marks the two 2M blocks of memory at
512M and 1024M as reserved. And for the low 1M I guess Windows doesn't
hand out any of these to device drivers.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-05-08  7:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-07 23:13 [PATCH] mm: Work around Intel SNB GTT bug with some physical pages Stéphane Marchesin
2012-05-07 23:57 ` Andi Kleen
2012-05-08  6:53 ` Dave Airlie
2012-05-08  7:21   ` Daniel Vetter [this message]
2012-05-08 15:25 ` Linus Torvalds
2012-05-08 17:23   ` Daniel Vetter
2012-05-08 18:03     ` Rob Clark
2012-05-08 21:57 ` Hugh Dickins
2012-05-09  8:56   ` 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=20120508072109.GA4802@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcheu@chromium.org \
    --cc=olofj@chromium.org \
    --cc=torvalds@linux-foundation.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