[lkml]   [2012]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: inode->i_wb_list corruption.
    <#part sign=pgpmime>
    On Mon, 12 Mar 2012 19:26:30 -0400, Dave Jones <> 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.


     \ /
      Last update: 2012-03-13 01:09    [W:0.020 / U:2.344 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site