From: Matt Mackall <mpm@selenic.com>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
cl@linux-foundation.org, penberg@cs.helsinki.fi,
linux-mm@kvack.org
Subject: Re: PROBLEM: kernel BUG at mm/slab.c:3002!
Date: Tue, 10 Mar 2009 12:18:52 -0500 [thread overview]
Message-ID: <1236705532.3205.14.camel@calx> (raw)
In-Reply-To: <49B68450.9000505@hp.com>
On Tue, 2009-03-10 at 11:16 -0400, Alan D. Brunelle wrote:
> Running blktrace & I/O loads cause a kernel BUG at mm/slab.c:3002!.
Pid: 11346, comm: blktrace Tainted: G B 2.6.29-rc7 #3 ProLiant
DL585 G5
That 'B' there indicates you've hit 'bad page' before this. That bug
seems to be strongly correlated with some form of hardware trouble.
Unfortunately, that makes everything after that point a little suspect.
Both this slab BUG and the bad page issue are "shouldn't happen"
situations that are generally caused by memory changing out from under
the subsystem, either by some other code scribbling on the relevant
memory or DRAM trouble or the like. If you want to pursue this further,
please gather up a collection of any bad page reports you can find on
your system and change the BUG code at slab.c:3002 to read something
like:
if (slabp->inuse < 0 || slabp->inuse >= cachep->num) {
printk("SLAB: slabp %p inuse %d max %d\n",
slabp, slabp->inuse, cachep->num);
BUG();
}
We might find that the slab and the bad page are the same page or
nearby. We might find that inuse has a single bit flipped (hardware
error). Or we might find that it has a revealing value scribbled over it
that points to the culprit. From your trace, it appears to contain 0x70,
which is a rather large number of objects to have on a slab but as we
don't know what slab it is, it's hard to say what happened.
--
http://selenic.com : development and support for Mercurial and Linux
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-03-10 17:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-10 15:16 Alan D. Brunelle
2009-03-10 17:14 ` Alan D. Brunelle
2009-03-10 17:18 ` Matt Mackall [this message]
2009-03-10 17:29 ` Alan D. Brunelle
2009-03-10 17:43 ` Matt Mackall
2009-03-10 18:53 ` Alan D. Brunelle
2009-03-10 22:05 ` Hugh Dickins
2009-03-10 17:40 ` Christoph Lameter
2009-03-11 2:21 ` Nick Piggin
2009-03-11 14:28 ` Alan D. Brunelle
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=1236705532.3205.14.camel@calx \
--to=mpm@selenic.com \
--cc=Alan.Brunelle@hp.com \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@cs.helsinki.fi \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox