Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: kernel BUG at kernel/power/snapshot.c:464! | Date | Mon, 18 Feb 2008 13:07:44 +0100 |
| |
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
| |