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 16:47:46 +0000, Dave Airlie <airlied@gmail.com> wrote:

> The hibernate issue is known and I've been hoping someone from Intel
> would run with debugging it, they have a big enough team that I don't
> feel I can expend the personal time to look into it.

Yeah, I've been chatting with a couple of intel folks; we should have a
test patch ready shortly, but we haven't been able to reproduce anything
like this...

> Maybe Keith can push someone or maybe I just refuse pull requests
> until one with a fix appears.

>From what I've seen, this is a problem only on Ironlake machines, which
makes me afraid of some weird GTT flushing issue, given the adventures
we had with VT-d on that hardware where we idle the gpu before any GTT
updates. I wonder what would happen if we idled the GPU before any GTT
updates even when VT-d wasn't running...

> The latest thinking on the hibernate issues is kernel one sets up an
> fbcon, hibernate restores the old memory and the GTT still points at
> the pages,
> then something writes to the console and overwrites real memory., just
> a working theory, nobody has proven it yet.

Presumably the resumed kernel will not be able to write to the console
until the i915 driver is running again, at which point it will have
updated all of the GTT entries. And, presumably the booted kernel won't
be writing to the console after it has loaded the resumed kernel memory?

-- 
keith.packard@intel.com