From: William Lee Irwin III <wli@holomorphy.com>
To: linux-ia64@vger.kernel.org
Subject: [1/1] make bad_page() print all of page->flags
Date: Wed, 01 Sep 2004 06:14:43 +0000 [thread overview]
Message-ID: <20040901061443.GW5492@holomorphy.com> (raw)
On Wed, Sep 01, 2004 at 03:59:33PM +1000, Ian Wienand wrote:
> 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 at free_hot_cold_page (in process 'swapper', page e0000000049bcd08)
> flags:0x00000000 mapping:0000000000000000 mapcount:1 count:0
> Backtrace:
> [-- 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 :
> Virtual mem_map starts at 0xe000000004928000
> 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");
next reply other threads:[~2004-09-01 6:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-01 6:14 William Lee Irwin III [this message]
2004-09-01 7:28 ` [1/1] make bad_page() print all of page->flags Ian Wienand
2004-09-01 7:39 ` William Lee Irwin III
2004-09-01 15:24 ` Bjorn Helgaas
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=20040901061443.GW5492@holomorphy.com \
--to=wli@holomorphy.com \
--cc=linux-ia64@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.