On Tue, May 8, 2012 at 12:13 AM, Stéphane Marchesin <marcheu@xxxxxxxxxxxx> 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? Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
