Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078
From: Paul Slootman
Date: Wed Aug 23 2006 - 04:39:52 EST
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@xxxxxxx> 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 126.96.36.199 (after 188.8.131.52 had buggered it with the endian
> bug, but after numerous xfs_repairs). Interestingly I rebooted into an
> old 184.108.40.206 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 220.127.116.11 yesterday with gcc 4.1 (the previous kernel that
showed problems was 18.104.22.168 compiled with gcc 3.3.5), and the same
problem showed itself again, after 22.214.171.124 had run with no problems
whatsoever for 5 days.
I'll now give 126.96.36.199 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).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/