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, Paul Slootman wrote:
> 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).

I compiled 2.6.17.9 yesterday with gcc 4.1 (the previous kernel that
showed problems was 2.6.17.7 compiled with gcc 3.3.5), and the same
problem showed itself again, after 2.6.15.6 had run with no problems
whatsoever for 5 days.

I'll now give 2.6.16.1 a go (we have that kernel lying around :-)


BTW, what's the significance of the xfs_repair message
LEAFN node level is 1 inode 827198 bno = 8388608
(I see a lot more of these this time round).


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/