From: Dave Chinner <david@fromorbit.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: xfs@oss.sgi.com
Subject: Re: 2.6.31.6: XFS DEBUG: Assertions cause kernel OOPS.
Date: Tue, 1 Dec 2009 10:38:18 +1100 [thread overview]
Message-ID: <20091130233818.GE30608@discord.disaster> (raw)
In-Reply-To: <alpine.DEB.2.00.0911300819010.20343@p34.internal.lan>
On Mon, Nov 30, 2009 at 08:22:03AM -0500, Justin Piszcz wrote:
> Hi,
>
> I wanted to compile my kernel with DEBUG for XFS and also kernel frame pointers
> to catch any issues.
>
> However, DEBUG for XFS does more harm than good?
DEBUG is there for developers, not end users. Often the debug code
will assert fail or panic where the situation is not fatal but
indicative of some problem that should be looked into further.
> I tried to install bonnie++:
> # apt-get install -y bonnie++
>
> And then this happened:
>
> [ 1578.768558] Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
....
> [ 1578.769252] [<ffffffff811eb916>] xfs_bmapi+0x66/0x1940
> [ 1578.769252] [<ffffffff81260c51>] ? __up_read+0x91/0xb0
> [ 1578.769252] [<ffffffff8123a0a7>] ? xfs_buf_free+0xc7/0x110
> [ 1578.769252] [<ffffffff8123a1e6>] ? xfs_buf_rele+0xf6/0x130
> [ 1578.769252] [<ffffffff8122e70a>] ? xfs_trans_brelse+0x19a/0x2a0
> [ 1578.769252] [<ffffffff811f7ac7>] ? xfs_da_brelse+0x77/0x120
> [ 1578.769252] [<ffffffff810bf63d>] ? filldir+0x9d/0xe0
> [ 1578.769252] [<ffffffff8120225a>] xfs_dir2_leaf_getdents+0x61a/0x780
> [ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
> [ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
> [ 1578.769252] [<ffffffff811fc6ec>] xfs_readdir+0x10c/0x110
> [ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
> [ 1578.769252] [<ffffffff8123b4f4>] xfs_file_readdir+0x34/0x50
> [ 1578.769252] [<ffffffff810bf7f8>] vfs_readdir+0xa8/0xc0
> [ 1578.769252] [<ffffffff810bf963>] sys_getdents+0x83/0xe0
> [ 1578.769252] [<ffffffff8102d1ab>] system_call_fastpath+0x16/0x1b
That is indicative of trying to map more blocks that we can fit
in the block map array during directory leaf readahead. That is
definitely not a problem for production systems, but definitely
indicates that the readahead loop termination has a bug in it
somewhere.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-11-30 23:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-30 13:22 2.6.31.6: XFS DEBUG: Assertions cause kernel OOPS Justin Piszcz
2009-11-30 13:59 ` Alex Elder
2009-11-30 14:15 ` Justin Piszcz
2009-11-30 23:38 ` Dave Chinner [this message]
2009-12-01 18:39 ` Justin Piszcz
2009-12-01 23:58 ` Dave Chinner
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=20091130233818.GE30608@discord.disaster \
--to=david@fromorbit.com \
--cc=jpiszcz@lucidpixels.com \
--cc=xfs@oss.sgi.com \
/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