LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Jeff Mahoney <jeffm@suse.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@suse.de>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: kernel BUG at kernel/power/snapshot.c:464!
Date: Mon, 18 Feb 2008 13:07:44 +0100	[thread overview]
Message-ID: <200802181307.45429.rjw@sisk.pl> (raw)
In-Reply-To: <200802090040.01479.rjw@sisk.pl>

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

      reply	other threads:[~2008-02-18 12:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08 19:03 Jeff Mahoney
2008-02-08 20:20 ` Pavel Machek
2008-02-08 20:55   ` Rafael J. Wysocki
2008-02-08 22:37     ` Jeff Mahoney
2008-02-08 23:40       ` Rafael J. Wysocki
2008-02-18 12:07         ` Rafael J. Wysocki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802181307.45429.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=tglx@linutronix.de \
    --subject='Re: kernel BUG at kernel/power/snapshot.c:464'\!'' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).