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 16 2006 - 08:35:38 EST
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.
Note that I've now put an older kernel on the system (22.214.171.124) and it
seems to be surviving longer than before, with 126.96.36.199. It would be
nice if it survived a day, as it's a backup server for a couple of
(See also my messages to the xfs list, subject "cache_purge: shake on
cache 0x5880a0 left 8 nodes!?" and "XFS internal error
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/