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 Sat, 17 Mar 2012 18:44:18 -0700 (PDT), Hugh Dickins <hughd@google.com> wrote:

> __GFP_MOVABLE is a hint to page allocation that there's a good likelihood
> that this logical page can be migrated elsewhere in physical memory later
> on if mm wants, so it's a good idea to allocate it from a physical area of
> similarly MOVABLE pages;

So, allocating things with __GFP_MOVABLE may just change where in memory
the graphics pages get allocated, moving whatever GPU-inspired damage to
less sensitive bits of the kernel data. Sounds fabulous!

> I keep worrying about the sequence when the machine is powered on again
> after hibernation: can i915 get up to anything before it is resumed from
> the hibernation image?

Well, the frame buffer is presumably still using whatever mapping it had
before suspend occurred; is there any way it could be writing through
that before the graphics driver was resumed?

What I don't understand is the relationship between the boot kernel and
the resumed kernel; when does the boot kernel stop writing to the
console, and how does it hand off control of the frame buffer at that
time.

It would be great if we could separate out the boot kernel access to the
graphics system from the resumed system -- if the boot kernel was run
without the i915 driver loaded at all, and just used VGA text mode, then
any damage as a result of resume wouldn't be caused by the boot kernel
GTT mappings getting used at the wrong time.

-- 
keith.packard@intel.com