<#part sign=pgpmime> On Fri, 16 Mar 2012 09:11:54 -0700, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > I don't know if these kinds of things have been forwarded to you, but > there's apparently been several things like this going on - with the > finger pointing to the i915 driver apparently clearing random memory. > Often the end result seems to be list corruption or a NULL pointer > dereference in the filesystem layer. Yikes! I've been participating in the hibernation thread, but I hadn't heard about this other random memory corruption. We had a theory about hibernation -- unflushed FB writes that go astray when the pages underneath the GTT get reassigned when switching from the boot kernel to the resumed kernel. Something similar could be happening at other times though? A graphics page is freed with writes outstanding, the GTT entry is cleared and the page allocated to something in the filesystem, but before the GTT entry update is recognized by the GPU, and before pending writes are flushed, the data gets written through the GTT to the middle of the file system structure. That stretches the bounds of credibility though; you'd have to have unflushed data *and* an unflushed GTT write, neither of which is supposed to happen. > So it might be the culprit. As the reason of the corruption is not yet > understood, it might be that suspend/resume cycle is not necessary > pre-requisite for this to trigger, it might just make it more likely. That opens up a much broader scope of code that might contain problems... -- keith.packard@xxxxxxxxx _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
