kernel BUG at kernel/power/snapshot.c:464!

kernel BUG at kernel/power/snapshot.c:464!

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi Pavel -

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

Here's the trace:

swsusp: Marking nosave pages: 000000000009f000 - 0000000000100000
swsusp: Marking nosave pages: 00000000f7ff0000 - 0000000100000000
- ------------[ cut here ]------------
kernel BUG at kernel/power/snapshot.c:464!
invalid opcode: 0000 [1] SMP
CPU 1
Modules linked in: ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs
autofs4 sunrpc iptable_filter ip_tables ip6table_filter ip6_tables
x_tables ipv6 af_packet loop dm_mod sbp2 ohci1394 ieee1394 parport_pc
parport tg3 sr_mod i2c_amd8111 shpchp button pci_hotplug amd_rng
rtc_cmos rtc_core rtc_lib i2c_amd756 i2c_core k8temp serio_raw cdrom
hwmon sg floppy ohci_hcd sd_mod usbcore edd ext3 mbcache jbd fan
sata_sil pata_amd libata scsi_mod thermal processor
Pid: 3131, comm: cat Not tainted 2.6.24-vanilla #14
RIP: 0010:[<ffffffff8025a254>]  [<ffffffff8025a254>]
memory_bm_find_bit+0x20/0x78
RSP: 0018:ffff8100f602bd78  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff810000003480 RCX: ffff8100f602bd8c
RDX: ffff8100f602bd80 RSI: 00000000000f7ff0 RDI: ffff8100f65eadc0
RBP: 00000000000f7ff0 R08: ffff8100f602bd80 R09: 0000000100000000
R10: ffff8100f602bae8 R11: ffffffff80322454 R12: ffff8100f65eadc0
R13: ffff8100f67f6d58 R14: ffff8100f67f6d58 R15: ffff8100f6138ec0
FS:  00002b24042806f0(0000) GS:ffff8100f7688ac0(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00002b2403fe1c30 CR3: 00000000f69bd000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Process cat (pid: 3131, threadinfo ffff8100f602a000, task
ffff8100379ff040)
Stack:  ffffffff8025a2bd ffff8100379ce018 0000003ff6138ec0 ffffffff8025ba68
 ffff8100f6138ec0 0000000000000000 ffff8100f67f6d58 ffffffff8025c65f
 ffff8100f77341c0 ffffffff80412b6a ffffffff80445610 0000000000000000
Call Trace:
 [<ffffffff8025a2bd>] memory_bm_set_bit+0x11/0x20
 [<ffffffff8025ba68>] create_basic_memory_bitmaps+0x162/0x166
 [<ffffffff8025c65f>] snapshot_open+0x58/0x102
 [<ffffffff80412b6a>] mutex_lock+0xd/0x1e
 [<ffffffff80361d8a>] misc_open+0x13e/0x1b2
 [<ffffffff802990bf>] chrdev_open+0x158/0x17c
 [<ffffffff802a12b1>] open_namei+0x2d0/0x653

 [<ffffffff80298f67>] chrdev_open+0x0/0x17c
 [<ffffffff8029527a>] __dentry_open+0xeb/0x1be
 [<ffffffff80295404>] do_filp_open+0x2d/0x3d
 [<ffffffff802950f0>] get_unused_fd_flags+0x80/0x118
 [<ffffffff8029545a>] do_sys_open+0x46/0xc3
 [<ffffffff8020bfde>] system_call+0x7e/0x83


Code: 0f 0b eb fe 48 3b 70 08 72 ee 48 3b 70 10 73 e8 48 89 47 10
RIP  [<ffffffff8025a254>] memory_bm_find_bit+0x20/0x78
 RSP <ffff8100f602bd78>
- ---[ end trace c6de0b8a8d80da39 ]---


- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHrKd+LPWxlyuTD7IRArWBAJ9+wGj8l2g/NU3B09YTwtM3+8dYIACdGeAt
3F2Cs30J2dCqRXFYe95StO8=
=j1bj
-----END PGP SIGNATURE-----

Re: kernel BUG at kernel/power/snapshot.c:464!

[Pavel Machek]

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?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: kernel BUG at kernel/power/snapshot.c:464!

[Rafael J. Wysocki]

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.

Thanks,
Rafael

Re: kernel BUG at kernel/power/snapshot.c:464!

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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)

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?

- -Jeff

Here's the updated oops, which doesn't look any different:

- ------------[ cut here ]------------
kernel BUG at kernel/power/snapshot.c:464!
invalid opcode: 0000 [1] SMP
CPU 1
Modules linked in: ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs
autofs4 sunrpc iptable_filter ip_tables ip6table_filter ip6_tables
x_tables ipv6 af_packet loop dm_mod sbp2 ohci1394 ieee1394 k8temp
amd_rng tg3 i2c_amd8111 hwmon i2c_amd756 floppy shpchp rtc_cmos rtc_core
rtc_lib sr_mod i2c_core cdrom parport_pc parport pci_hotplug serio_raw
button sg ohci_hcd sd_mod usbcore edd ext3 mbcache jbd fan sata_sil
pata_amd libata scsi_mod thermal processor
Pid: 3165, comm: cat Not tainted 2.6.24-vanilla #20
RIP: 0010:[<ffffffff80254c4c>]  [<ffffffff80254c4c>]
memory_bm_find_bit+0x20/0x78
RSP: 0018:ffff8100379bfd78  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff810000003480 RCX: ffff8100379bfd8c
RDX: ffff8100379bfd80 RSI: 00000000000f7ff0 RDI: ffff81003793e5c0
RBP: 00000000000f7ff0 R08: ffff8100379bfd80 R09: 0000000000000000
R10: 0000000000000028 R11: 0000000000000001 R12: ffff81003793e5c0
R13: ffff81003783f118 R14: ffff81003783f118 R15: ffff8100f603e380
FS:  00007f753cff06f0(0000) GS:ffff8100f767ec40(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f753cb47c30 CR3: 00000000f61fc000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process cat (pid: 3165, threadinfo ffff8100379be000, task ffff8100378f0640)
Stack:  ffffffff80254cb5 ffff810037837018 0000003ff603e380 ffffffff8025641f
 ffff8100f603e380 0000000000000000 ffff81003783f118 ffffffff80257016
 ffff8100f777fe40 ffffffff8040dbca ffffffff80451aa0 0000000000000000
Call Trace:
 [<ffffffff80254cb5>] ? memory_bm_set_bit+0x11/0x20
 [<ffffffff8025641f>] ? create_basic_memory_bitmaps+0x134/0x139
 [<ffffffff80257016>] ? snapshot_open+0x58/0x13f
 [<ffffffff8040dbca>] ? mutex_lock+0xd/0x1e
 [<ffffffff8035fb76>] ? misc_open+0x13e/0x1b2
 [<ffffffff80294459>] ? chrdev_open+0x150/0x174
 [<ffffffff8029c495>] ? open_namei+0x2d0/0x653
 [<ffffffff80294309>] ? chrdev_open+0x0/0x174
 [<ffffffff802906dc>] ? __dentry_open+0xeb/0x1be
 [<ffffffff80290866>] ? do_filp_open+0x2d/0x3d
 [<ffffffff8029055b>] ? get_unused_fd_flags+0x7f/0x10e
 [<ffffffff802908bc>] ? do_sys_open+0x46/0xc3
 [<ffffffff8020befb>] ? system_call_after_swapgs+0x7b/0x80


Code: 00 3d 4f 80 e9 74 8f 1b 00 90 90 48 8b 47 10 49 89 d0 48 3b 70 08
72 06 48 3b 70 10 72 21 48 8b 07 eb 0c 48 8b 00 48 85 c0 75 04 <0f> 0b
eb fe 48 3b 70 08 72 ee 48 3b 70 10 73 e8 48 89 47 10 48
RIP  [<ffffffff80254c4c>] memory_bm_find_bit+0x20/0x78
 RSP <ffff8100379bfd78>
- ---[ end trace 5aadb6f82638eb8d ]---


- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFHrNm6LPWxlyuTD7IRAtL5AJ4hiKgxkwc8mlrGxIKfyIebTit5LwCcDDeF
f7iGfoSBqyY7FgmnC3f0898=
=X6Jq
-----END PGP SIGNATURE-----

Re: kernel BUG at kernel/power/snapshot.c:464!

[Rafael J. Wysocki]

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.

Andrew, have we had any changes to the way in which pfn_valid() works recently?

Rafael


> Here's the updated oops, which doesn't look any different:
> 
> ------------[ cut here ]------------
> kernel BUG at kernel/power/snapshot.c:464!
> invalid opcode: 0000 [1] SMP
> CPU 1
> Modules linked in: ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs
> autofs4 sunrpc iptable_filter ip_tables ip6table_filter ip6_tables
> x_tables ipv6 af_packet loop dm_mod sbp2 ohci1394 ieee1394 k8temp
> amd_rng tg3 i2c_amd8111 hwmon i2c_amd756 floppy shpchp rtc_cmos rtc_core
> rtc_lib sr_mod i2c_core cdrom parport_pc parport pci_hotplug serio_raw
> button sg ohci_hcd sd_mod usbcore edd ext3 mbcache jbd fan sata_sil
> pata_amd libata scsi_mod thermal processor
> Pid: 3165, comm: cat Not tainted 2.6.24-vanilla #20
> RIP: 0010:[<ffffffff80254c4c>]  [<ffffffff80254c4c>]
> memory_bm_find_bit+0x20/0x78
> RSP: 0018:ffff8100379bfd78  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff810000003480 RCX: ffff8100379bfd8c
> RDX: ffff8100379bfd80 RSI: 00000000000f7ff0 RDI: ffff81003793e5c0
> RBP: 00000000000f7ff0 R08: ffff8100379bfd80 R09: 0000000000000000
> R10: 0000000000000028 R11: 0000000000000001 R12: ffff81003793e5c0
> R13: ffff81003783f118 R14: ffff81003783f118 R15: ffff8100f603e380
> FS:  00007f753cff06f0(0000) GS:ffff8100f767ec40(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007f753cb47c30 CR3: 00000000f61fc000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process cat (pid: 3165, threadinfo ffff8100379be000, task ffff8100378f0640)
> Stack:  ffffffff80254cb5 ffff810037837018 0000003ff603e380 ffffffff8025641f
>  ffff8100f603e380 0000000000000000 ffff81003783f118 ffffffff80257016
>  ffff8100f777fe40 ffffffff8040dbca ffffffff80451aa0 0000000000000000
> Call Trace:
>  [<ffffffff80254cb5>] ? memory_bm_set_bit+0x11/0x20
>  [<ffffffff8025641f>] ? create_basic_memory_bitmaps+0x134/0x139
>  [<ffffffff80257016>] ? snapshot_open+0x58/0x13f
>  [<ffffffff8040dbca>] ? mutex_lock+0xd/0x1e
>  [<ffffffff8035fb76>] ? misc_open+0x13e/0x1b2
>  [<ffffffff80294459>] ? chrdev_open+0x150/0x174
>  [<ffffffff8029c495>] ? open_namei+0x2d0/0x653
>  [<ffffffff80294309>] ? chrdev_open+0x0/0x174
>  [<ffffffff802906dc>] ? __dentry_open+0xeb/0x1be
>  [<ffffffff80290866>] ? do_filp_open+0x2d/0x3d
>  [<ffffffff8029055b>] ? get_unused_fd_flags+0x7f/0x10e
>  [<ffffffff802908bc>] ? do_sys_open+0x46/0xc3
>  [<ffffffff8020befb>] ? system_call_after_swapgs+0x7b/0x80
> 
> 
> Code: 00 3d 4f 80 e9 74 8f 1b 00 90 90 48 8b 47 10 49 89 d0 48 3b 70 08
> 72 06 48 3b 70 10 72 21 48 8b 07 eb 0c 48 8b 00 48 85 c0 75 04 <0f> 0b
> eb fe 48 3b 70 08 72 ee 48 3b 70 10 73 e8 48 89 47 10 48
> RIP  [<ffffffff80254c4c>] memory_bm_find_bit+0x20/0x78
>  RSP <ffff8100379bfd78>
> ---[ end trace 5aadb6f82638eb8d ]---
> 
> 

Re: kernel BUG at kernel/power/snapshot.c:464!

[Rafael J. Wysocki]

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