xfs
[Top] [All Lists]

RE: Linux 2.4.18 freeze running dbench 1.3

To: Christian Røsnes <christian@xxxxxxxxx>
Subject: RE: Linux 2.4.18 freeze running dbench 1.3
From: Steve Lord <lord@xxxxxxx>
Date: 04 Mar 2002 09:54:45 -0600
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <LKEBKIBHKNEKEKPHFNCCMEGHCOAA.christian@xxxxxxxxx>
References: <LKEBKIBHKNEKEKPHFNCCMEGHCOAA.christian@xxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Mon, 2002-03-04 at 09:24, Christian Røsnes wrote:
> 
> To follow up:
> 
> I tested dbench on an ext2 partition (/home) on the same server,
> and it worked. dbench on the XFS /usr partition still crashes the server.
> This kernel was made with gcc 2.96.


Let me confirm something here - you originally reported a complete
hang when running with xfs. Keith asked you to run with the nmi
oopser enabled - is this oops coming out after your turned on the
oopser enabled (nmi_watchdog=1 on the kernel boot line)?

If this is the case I think I can deduce the lock xfs has got hung
up on - and safely say I have never seen this before. I may try and
come up with some tracing code for this one, it looks like a spinlock
leak on the superblock counters.

Could you possibly try this:

Edit fs/xfs/Makefile and fs/xfs/linux/Makefile, look for the line like
this:

        EXTRA_CFLAGS +=  -I. -funsigned-char

(It is a little different in the xfs/linux/Makefile) Remove the
   -funsigned-char

Also remove all the .o files in the xfs directories after doing this.
Now in the config tool, turn on spinlock debugging in the kernel and
try running xfs again.

You have to remove the -funsigned-char to make xfs function with
spinlock debugging. We know it mostly works this way, but it has not
had much exposure.

Hopefully this will report some misuse of the lock somewhere.

Thanks

   Steve


-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


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