Re: i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

[Keith Packard <keithp@keithp.com>]

<#part sign=pgpmime>
On Fri, 16 Mar 2012 09:11:54 -0700, Linus Torvalds <torvalds@linux-foundation.org> 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@intel.com