make bad_page() print all of page->flags
PATCH 1/1 make bad_page() print all of page->flags
Quoted 5 lines · Ian Wienand
With 2.6.9-rc1 on IA64 I have this problem when I boot on an rx2600 (with both SMP and uniprocessor builds) :
Bad page state atfree_hot_cold_page(in process 'swapper', pagee0000000049bcd08) flags:0x00000000 mapping:0000000000000000 mapcount:1 count:0Backtrace:
Quoted 8 lines
[-- no backtrace is printed, unfortunately, and the machine stops dead --] But I also noticed that virtual mem map was right at around the same place :
Virtualmem_mapstarts at0xe000000004928000
So I turned that off in the config, and it appears to work OK. I noticed there were a lot of rmap changes with respect to locking just recently put in, and I suspect they are the culprit. I'm afraid this is a little over my head, but I'm willing to try any suggestions.
(1) is this struct page actually in your virtual mem_map?
(2) page->flags looks 32-bit, but ia64 doesn't define ARCH_HAS_ATOMIC_UNSIGNED that I can tell; what's going on there? Let's see if those flags are really all zero.
(3) "stops dead" isn't a very good description; deadlock? livelock? interrupts on or off?
-- wli
bad_page() only prints out 8 hexadecimal digits of page->flags regardless of sizeof(page_flags_t). This leads to confusing and/or incomplete bug reports. The following patch uses a field width argument to replace the hardcoded %08lx so that bad_page() may print the whole of page->flags.
Index: mm2-2.6.9-rc1/mm/page_alloc.c
=================================--- mm2-2.6.9-rc1.orig/mm/page_alloc.c 2004-08-31 01:06:55.000000000 -0700
+++ mm2-2.6.9-rc1/mm/page_alloc.c 2004-08-31 23:06:23.558598368 -0700
@@ -79,9 +79,9 @@
{
printk(KERN_EMERG "Bad page state at %s (in process '%s', page %p)\n",
function, current->comm, page);
- printk(KERN_EMERG "flags:0x%08lx mapping:%p mapcount:%d count:%d\n",
- (unsigned long)page->flags, page->mapping,
- page_mapcount(page), page_count(page));
+ printk(KERN_EMERG "flags:0x%0*lx mapping:%p mapcount:%d count:%d\n",
+ (int)(2*sizeof(page_flags_t)), (unsigned long)page->flags,
+ page->mapping, page_mapcount(page), page_count(page));
printk(KERN_EMERG "Backtrace:\n");
dump_stack();
printk(KERN_EMERG "Trying to fix it up, but a reboot is needed\n");
Quoted 1 line · William Lee Irwin III
(1) is this struct page actually in your virtual
mem_map?
I'm assuming so, since when it's turned off it works?
Quoted 3 lines
(2)
page->flagslooks 32-bit, but ia64 doesn't defineARCH_HAS_ATOMIC_UNSIGNEDthat I can tell; what's going on there? Let's see if those flags are really all zero.
Thanks, I applied the patch and it seems to be all zeros
Bad page state at free_hot_cold_page (in process 'swapper', page e000000004940c98) flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0
Backtrace:
[-- stops again --]
Quoted 2 lines
(3) "stops dead" isn't a very good description; deadlock? livelock? interrupts on or off?
It doesn't respond to magic-sysrq and I guess it takes an MCA because it spontaneously reboots after about 10 seconds, though doesn't print anything useful before it does that.
Thanks for you help,
-i
Quoted 1 line · William Lee Irwin III
Quoted 1 line
(1) is this struct page actually in your virtual
mem_map?
Quoted 1 line · Ian Wienand
I'm assuming so, since when it's turned off it works?
That's not quite enough to tell. Generally some kind of dump of the index of the sparse array (probably the ptes mapping it) so that the virtual addresses falling within it can be detected is needed to tell.
Quoted 3 lines · William Lee Irwin III
Quoted 3 lines
(2)
page->flagslooks 32-bit, but ia64 doesn't defineARCH_HAS_ATOMIC_UNSIGNEDthat I can tell; what's going on there? Let's see if those flags are really all zero.
Quoted 5 lines · Ian Wienand
Thanks, I applied the patch and it seems to be all zeros
Bad page state atfree_hot_cold_page(in process 'swapper', pagee000000004940c98) flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0Backtrace:[-- stops again --]
My bet is that this is not a real page, or otherwise that it's uninitialized and some kind of boundary conditions in free_area_init_core() or surrounding functions have been flubbed.
Quoted 2 lines · William Lee Irwin III
Quoted 2 lines
(3) "stops dead" isn't a very good description; deadlock? livelock? interrupts on or off?
Quoted 3 lines · Ian Wienand
It doesn't respond to magic-sysrq and I guess it takes an MCA because it spontaneously reboots after about 10 seconds, though doesn't print anything useful before it does that.
"Fatal machine check" sounds like a good description of this.
-- wli
Quoted 7 lines · Ian Wienand
Quoted 2 lines · William Lee Irwin III
(3) "stops dead" isn't a very good description; deadlock? livelock? interrupts on or off?
It doesn't respond to magic-sysrq and I guess it takes an MCA because it spontaneously reboots after about 10 seconds, though doesn't print anything useful before it does that.
You mentioned this was an HP rx2600. You can tell for sure whether it was an MCA (and get useful information about it) by doing "errdump clear" at the EFI shell prompt before reproducing the problem, stopping at the EFI shell prompt again during the subsequent reboot, and doing "errdump mca".
There's also a "salinfo" package that automatically retrieves and logs this information. It's part of Debian, there are sources here:
ftp://ftp.kernel.org/pub/linux/kernel/people/helgaas
or I can send you an RPM for RHEL3 if you need it.