linux-kernel - Re: [PATCH] mm: Work around Intel SNB GTT bug with some physical pages.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120508072109.GA4802@phenom.ffwll.local>
Date:	Tue, 8 May 2012 09:21:09 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Dave Airlie <airlied@...il.com>
Cc:	Stéphane Marchesin <marcheu@...omium.org>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
	olofj@...omium.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] mm: Work around Intel SNB GTT bug with some physical
 pages.

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@...omium.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@...ll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/