Could you guys try this patch, it should detect some stack overflows, in
case that's what you're hitting... Meanwhile, perhaps we can set up a
similar test here.
-Eric
On Wed, 2002-10-16 at 02:43, Matteo Centonza wrote:
> Hi,
>
> > We have this scenario:
> >
> > xfs -> vg (simplest setup, LVM) -> md (raid5) -> SCSI LLDD.
> >
>
> our setup here differs only in having an IDE subsystem. In our case
> xfs has internal log.
>
> > When md is set up with 3 (odd #) devices, then
> > a mount sleeps indefinitely on down(), and when
> > md is set up with 4 devices, then the kernel
> > oopses at filemap.c:843 in unlock_page() the BUG()
> > statement.
> >
> > The stack (of an SMP system) just prior to the
> > oops is attached below.
> >
>
> Our has 4 disks and hits the same kernel BUG with 2.4.19 (CVS as of
> 20020806). Although i've lost the oops trace, i remember it was very
> similar to this.
>
> > Now I've only been looking briefly at the code
> > but have already noticed that _end_pagebuf_page_io_multi()
> > does a unlock_page(), I'd guess for a good reason.
> > It nevertheless breaks when set up with the above scenario.
> > My guess would be that there's a wrong assumption somewhere.
> >
> > ((The same scenario, but with ext2 fs, doesn't oops.))
>
>
> We are currently stick to 2.4.18 (Release 1.1) and it works very well.
>
> Thanks,
>
> -m
>
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc. 651-683-3102
stackcheck.patch
Description: Text document
|