Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078

[Paul Slootman <paul+nospam@wurtel.net>]

On Thu 17 Aug 2006, Nathan Scott wrote:
> On Wed, Aug 16, 2006 at 12:38:10PM +0000, Paul Slootman wrote:
> > Nathan Scott  <nathans@sgi.com> wrote:
> > >On Fri, Aug 11, 2006 at 12:25:03PM +0200, Jesper Juhl wrote:
> > >> I didn't capture all of the xfs_repair output, but I did get this :
> > >> ...
> > >> Phase 4 - check for duplicate blocks...
> > >>         - setting up duplicate extent list...
> > >>         - clear lost+found (if it exists) ...
> > >>         - clearing existing "lost+found" inode
> > >>         - deleting existing "lost+found" entry
> > >>         - check for inodes claiming duplicate blocks...
> > >>         - agno = 0
> > >>         - agno = 1
> > >>         - agno = 2
> > >>         - agno = 3
> > >>         - agno = 4
> > >>         - agno = 5
> > >>         - agno = 6
> > >> LEAFN node level is 1 inode 412035424 bno = 8388608
> > >
> > >Ooh.  Can you describe this test case you're using?  Something with
> > >a bunch of renames in it, obviously, but I'd also like to be able to
> > >reproduce locally with the exact data set (file names in particular),
> > >if at all possible.
> > 
> > >From your reaction above I gather that "LEAFN node level is 1 inode ..."
> > is a bad thing?
> > 
> > My filesystem (that crashes under heavy load, while rsyncing to and from
> > it) has a lot of these messages when xfs_repair is run.
> 
> Do you have a reproducible test case?  Please send a go-to-woe recipe
> so I can see the problem first hand... and preferably one that is, er,
> slightly simpler than Jesper's case.

Unfortunately no, this is a 1.1TB filesystem with 54% usage, and dozens
of large rsyncs to and from it. However during this XFS panicks.

That was with 2.6.17.7 (after 2.6.17.4 had buggered it with the endian
bug, but after numerous xfs_repairs).  Interestingly I rebooted into an
old 2.6.15.6 kernel yesterday after the last XFS crash, and it survived
last night's activities perfectly well. After a couple of days I'm
willing to give the latest 2.6.18-rc or whatever a try (once I've a
complete set of backups again, and they've been passed on to the
long-term backup system).


Paul Slootman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/