Messages in this thread | | | From | Keith Packard <> | Subject | Re: inode->i_wb_list corruption. | Date | Mon, 12 Mar 2012 17:06:52 -0700 |
| |
<#part sign=pgpmime> On Mon, 12 Mar 2012 19:26:30 -0400, Dave Jones <davej@redhat.com> wrote:
> Thinking about how the GTT could contain stale pointers, I came up with this scenario: > > Before we begin the thaw, the initramfs sets up a framebuffer. > This causes the GTT to be setup.
Yes. The frame buffer is allocated as regular kernel pages, of course.
> - Thaw begins, hardware state still points to the GTT setup by the modesetting code. > At this point, any graphics operations are going to cause writes through > those translations. Bad news if we just wrote a bunch of thawed data > there.
The question is what data could still be pending there; we're running just fbcon at that point, which uses only write-through access. Presumably, any fbdev writes will have been long-since finished once we start the new kernel.
> - Thaw begins, and data is written over the GTT setup by the initramfs, but > the hardware registers still points at it, until thaw is complete, when we > reprogram the GTT registers to their pre-hibernate values.
I'm not sure how the new kernel could manage to do any writes through this though -- it shouldn't touch the frame buffer until it has thawed the video driver, right?
> If we could somehow set modeset=0 automatically if we detect a hibernate > partition it would probably 'solve' it, but I suspect the real answer > would be to do GTT teardown before we do a thaw.
We've got a ton of memory available in the 'stolen' area which the BIOS used as a frame buffer; we should be able to switch to that before the switch, if we decide that this is necessary.
-- keith.packard@intel.com
| |