lkml.org 
[lkml]   [2008]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: kernel BUG at kernel/power/snapshot.c:464!
    Date
    On Saturday, 9 of February 2008, Rafael J. Wysocki wrote:
    > On Friday, 8 of February 2008, Jeff Mahoney wrote:
    > > Rafael J. Wysocki wrote:
    > > > On Friday, 8 of February 2008, Pavel Machek wrote:
    > > >> Hi!
    > > >>
    > > >>> Our old friend kernel BUG at kernel/power/snapshot.c:464! is back, this
    > > >>> time from mainline. I can't reproduce with 2.6.24-final, but I can with
    > > >>> a git snapshot from a few days ago. I'm doing a git bisect run now, but
    > > >>> it's rather time consuming, so I thought I'd pass this on in the interim.
    > > >>>
    > > >>> I can reproduce this just by doing "cat /dev/snapshot".
    > > >>>
    > > >>> Working output looks like:
    > > >>> swsusp: Marking nosave pages: 000000000009f000 - 0000000000100000
    > > >>> swsusp: Marking nosave pages: 00000000f7ff0000 - 0000000100000000
    > > >>> swsusp: Basic memory bitmaps created
    > > >>> swsusp: Basic memory bitmaps freed
    > > >> root@amd:~# cat /dev/snapshot
    > > >> cat: /dev/snapshot: No data available
    > > >> root@amd:~#
    > > >>
    > > >> ...on less than two days old 2.6.25-rc0-git. Rafael, do you have any
    > > >> ideas what may break?
    > > >
    > > > No idea and I can't reproduce it.
    > > >
    > > > Plus the trace looks bogus, as there are no "swsusp: ..." messages in the
    > > > mainline any more.
    > >
    > > The git version from two days ago did. :)
    > >
    > > I just git pulled and built and got the same BUG.
    > >
    > > Here are the nosave registration messages:
    > > PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
    > > PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
    > > PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
    > > PM: Registered nosave memory: 00000000f7ff0000 - 00000000f7fff000
    > > PM: Registered nosave memory: 00000000f7fff000 - 00000000f8000000
    > > PM: Registered nosave memory: 00000000f8000000 - 00000000ff780000
    > > PM: Registered nosave memory: 00000000ff780000 - 0000000100000000
    > >
    > > And the old swsusp messages match those ranges, just coalesced into two
    > > ranges.
    > >
    > > Reassembling the zones from /proc/zoneinfo yields:
    > > Node 0, zone DMA start_pfn: 0, spanned 4096
    > > (0x0-0x1000)
    > > Node 0, zone DMA32 start_pfn: 4096, spanned 1011696
    > > (0x1000-0xf7ff0)
    > > Node 1, zone Normal start_pfn: 1048576, spanned 1048576
    > > (0x100000-200000)
    >
    > Ah, NUMA.
    >
    > > The pfn it's searching for is 0xf7ff0, which will end up hitting this in
    > > memory_bm_find_bit:
    > > while (pfn < zone_bm->start_pfn || pfn >= zone_bm->end_pfn) {
    > > zone_bm = zone_bm->next;
    > > BUG_ON(!zone_bm)
    > > }
    > >
    > > Should that be pfn > zone_bm->end_pfn, or is end_pfn non-inclusive?
    >
    > It used to be non-inclusive and I think it is, as 0xf7ff0 seems to be the start
    > of a reserved region.
    >
    > Well, the assumption is that if the PFN doesn't belong to any zone, then
    > pfn_valid() in mark_nosave_pages() should filter it out. Apparently, it has
    > stopped doing this at one point.

    Andi, Thomas, Ingo,
    the source of the bug is that on a K8 NUMA system there is a PFN for which
    pfn_valid() returns 'true' and yet it doesn't belong to any zone. Is there a
    valid scenarion in which something like this is possible? It didn't happen
    with 2.6.24.

    [Please see http://bugzilla.kernel.org/show_bug.cgi?id=9966 for the reference
    to the entire thread.]

    Thanks,
    Rafael


    \
     
     \ /
      Last update: 2008-02-18 13:11    [W:0.026 / U:1.528 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site