This is a little scary, the xfs and ext2 filesystems are on different devices,
otherwise I would question the raid driver, or are they? Your device numbers
are a little different, where are the partitions you used for the tests?
I have not seen anything like this before, it smells a little of a buffer
head getting stamped on. Would it be possible to add disassemblies of the
ext2 functions you have hit corruption in? i.e. just run gdb on vmlinux
and disassemble them, otherwise it is hard to figure out which memory
reference was at fault.
Thanks
Steve
> Hi,
>
> I'm running the XFS stress tests on a Dell Poweredge 4400 running. The
> kernel is the current CVS one (as at today) but the problem persists over
> several weeks of compilations. Local modifications to the kernel are the
> addition of the module for the AACRAID Perc 3/Di RAID controller and the
> e1000 driver from Intel for the ethernet card. Highmem support is enabled
> (the machine has 1GB of RAM). The kernels are compiled with the kgcc
> package from Redhat 7.0 (egcs
> 2.91.66) or the RH7.1 gcc (2.96-81) - it makes no difference.
>
> hinv, dmesg, and backtraces from kdb at crash time are available at
> http://www.csee.uq.edu.au/~chrisp/xfs/. I don't know what other information
> to gather. Any pointers?
>
> So far I have seen deaths (caused by NULL pointer exceptions) in (at least)
> ext2_get_block, ext2_update_inode, ext2_alloc_branch, etc, while running
> 'check' from the xfstests directory. I haven't been able to trigger any
> crashes during any other activity on the system, using 2.2.19 and the
> standard RH7.1 kernel (I can't run xfs test on those though, obviously).
>
> I may be able to provide remote access + console access to the server if
> it's of any use (it is a development/test box) if it is of any use.
>
> Chris
|