xfs
[Top] [All Lists]

Re: hitting the BUG() in filemap.c:843 (in unlock_page())

To: Luben Tuikov <luben@xxxxxxxxxxxx>
Subject: Re: hitting the BUG() in filemap.c:843 (in unlock_page())
From: Matteo Centonza <matteo@xxxxxx>
Date: Wed, 16 Oct 2002 09:43:03 +0200 (CEST)
Cc: linux-xfs <linux-xfs@xxxxxxxxxxx>
In-reply-to: <3DACEDFD.B96BB72C@splentec.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
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


<Prev in Thread] Current Thread [Next in Thread>