From owner-linux-xfs@oss.sgi.com Fri Dec  1 00:05:48 2000
Received:  by oss.sgi.com id <S553953AbQLAIFh>;
	Fri, 1 Dec 2000 00:05:37 -0800
Received: from hermes.mixx.net ([212.84.196.2]:52492 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553950AbQLAIFR>;
	Fri, 1 Dec 2000 00:05:17 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 21DD5F814
	for <linux-xfs@oss.sgi.com>; Fri,  1 Dec 2000 09:05:16 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id F27472CAA2; Fri,  1 Dec 2000 09:05:15 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: sys_attrctl not working on ppc
Date:   1 Dec 2000 08:05:15 GMT
Organization: innominate AG, Berlin, Germany
Lines:  48
Distribution: local
Message-ID: <news2mail-907m3r$27r$3@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> <news-innominate.list.sgi.xfs@innominate.de> <10011101103.ZM113097@wobbly.melbourne.sgi.com> <20001110094151.C333@ysabell> <10011110006.ZM127189@wobbly.melbourne.sgi.com> <news2mail-8uo7od$4lt$1@mate.bln.innominate.de> <10011141059.ZM128320@wobbly.melbourne.sgi.com> <news2mail-8utlfv$8iu$1@mate.bln.innominate.de> <20001201122045.G32822@fudge.melbourne.sgi.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975657915 2299 10.0.0.31 (1 Dec 2000 08:05:15 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

[also changed the subject to something more useful here]

Andrew Gildfind <ajag@fudge.melbourne.sgi.com> wrote:

> Hi Thomas,

> Could you put a printk at the start of the sys_attrctl function defined
> in linux/fs/stat.c, and rerun the QA test 020, or drive the attribute code
> directly using xfs_attr, and check whether the printk actually gets called.

> If it doesn't then we know for sure it's the syscall that isn't hooked up
> correctly. unistd.h and entry.S looked like the only places which needed
> to be changed but I may have missed something. If it does hit the the attribute
> syscall, then there's a more serious problem somewhere else in the code.

looks like this is the case:

...
Start mounting filesystem: ide0(3,8)
Ending clean XFS mount for filesystem: ide0(3,8)
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
here is sys_attrctl
Start mounting filesystem: ide0(3,8)
Ending clean XFS mount for filesystem: ide0(3,8)
ppc:/usr/src/xfs/cmd/xfs/stress #

this is the dmesg of check 020 - it gets called - so the problem is
somethere deeper ... maybe anykind of endian stuff of the parameters?
(just an idea) ... do you have any other idea?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Dec  1 00:09:57 2000
Received:  by oss.sgi.com id <S553955AbQLAIJs>;
	Fri, 1 Dec 2000 00:09:48 -0800
Received: from hermes.mixx.net ([212.84.196.2]:64268 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553952AbQLAIJ2>;
	Fri, 1 Dec 2000 00:09:28 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 31112F814
	for <linux-xfs@oss.sgi.com>; Fri,  1 Dec 2000 09:09:26 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 09E432CAA2; Fri,  1 Dec 2000 09:09:26 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: kernelcrash during root filesystem recovery
Date:   1 Dec 2000 08:09:25 GMT
Organization: innominate AG, Berlin, Germany
Lines:  77
Distribution: local
Message-ID: <news2mail-907mbl$27r$4@mate.bln.innominate.de>
References: <20001130202247.A24118@s2y4n2c.de> <3A26F641.45226EF7@thebarn.com>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975658165 2299 10.0.0.31 (1 Dec 2000 08:09:25 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

just a very trivial idea (maybe wrong): i think i have seen this then
i did not change the lilo entry for the xfs root from read-only to
read-write ... but i might be wrong ... but if that should be the
case the xfs code should maybe change it to read-write itself
(if that is possible)

just an idea

t

Russell Cattelan <cattelan@thebarn.com> wrote:
> utz lehmann wrote:

> Hmm not good.
> We are going to need a bit more go to on.

> Can you get a backtrace from kdb?

> If you could hook up to a serial console that would
> help in capturing the output.


>> hi
>>
>> i found a bug in yesterdays (2000-11-29) kernel (the test11 one).
>>
>> i had powered off my computer without a clean shutdown. i do this very
>> often, no problems since month with xfs.
>>
>> the kernel traped into kdb while recovering the xfs root filesystem. i write
>> the messages down from the screen, maybe there are typos:
>>
>> XFS: WARNING: recovery required on readonly filesystem.
>>
>> XFS: write access will be enabled recovery.
>>
>> Staring XFS recovery on filesystem: ide0 (3,6) (dev:3/6)
>> Unable to handle kernel NULL pointer dereference at virtual address 00000008
>>  printing eip:
>> c016482b
>> *pde = 00000000
>>
>> Entering kdb (currect=0xc125c000, pid1) Panic: Oops
>> due to panic @ 0xc016482b
>> eax = 0x00000000 ebx = 0xc12c3460 ecx = 0xc12c3460 edx = 0x00000000
>> esi = 0xc12c0e60 edi = 0x00000000 esp = 0xc125d940 eip = 0xc016482b
>> ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246
>> xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d90c
>>
>> i rebooted the machine with the same result.
>> rebooting with a kernel from 2000-11-14 works with no problems.
>>
>> i made some tests with the buggy kernel:
>>
>> clean shutdown works.
>> hardreset after "sync" works.
>> hardreset after booting without sync works.
>> hardreset during booting works.
>> hardreset during writing (cp -av /usr/src/linux /tmp) triggers the bug.
>> 4 times it traped into kdb, 1 time the kernel hangs.
>>
>> booting with the older kernel always works.
>>
>> my system:
>> K6-500, 128MB
>> xfs root filesystem on a ide disk.
>>
>> hope that helps.
>>
>> utz


-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Dec  1 00:38:48 2000
Received:  by oss.sgi.com id <S553957AbQLAIi2>;
	Fri, 1 Dec 2000 00:38:28 -0800
Received: from alsa.jcu.cz ([160.217.1.49]:5650 "EHLO alsa.alsa-project.org")
	by oss.sgi.com with ESMTP id <S553954AbQLAIiN>;
	Fri, 1 Dec 2000 00:38:13 -0800
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA20391;
	Fri, 1 Dec 2000 09:37:49 +0100
Date:   Fri, 1 Dec 2000 09:37:49 +0100 (CET)
From:   Andy Lo A Foe <andy@alsa-project.org>
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: latest CVS hangs on boot
In-Reply-To: <3A26EE4B.13B84B9@thebarn.com>
Message-ID: <Pine.LNX.4.21.0012010926540.19662-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, 30 Nov 2000, Russell Cattelan wrote:

> > but before IDE device probing (I think). Is this a known bug? Plain test11
> > works fine, and so does an earlier -XFS-test10 tree. I can provide
> > debugging output, if needed..
> 
> Not as of yet.
> 
> What else can you tell us.

Sorry, was late yesterday:
- gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
- K7V with VT82C686 controller + QUANTUM FIREBALLP KX13.6
- 128MB RAM
- Debian Woody (glibc 2.2)
- 10Gig XFS partition

Did a fresh checkout of current CVS last night, same results. 
XFS-beta tree (test5 based) works fine. I tested the kernel on 2 different
K7V boxes and both hang at the same point (it seems).

> Can you break into kdb?

Tried compiling kdb in just now, getting some weird errors on some
perfectly legal looking defines ie

	....
        unsigned int    bp_free:1;      /* This entry is available */
	....

/usr/src/XFS/linux-2.4-xfs/linux/include/linux/kdbprivate.h:91: parse
error before `:'
...etc...etc...
/usr/src/XFS/linux-2.4-xfs/linux/include/linux/kdbprivate.h:112: warning: array
`kdb_breakpoints' assumed to have one element
/usr/src/XFS/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage size
of `display_endian' isn't known

> if so a back trace would be a good starting point.

Unfortunately I don't have time to fix the kdb compile today. Perhaps this
weekend. Any help appreciated..

Thanks,
-andy

--
AlsaPlayer, http://www.alsaplayer.org/


From owner-linux-xfs@oss.sgi.com Fri Dec  1 01:12:37 2000
Received:  by oss.sgi.com id <S553960AbQLAJMS>;
	Fri, 1 Dec 2000 01:12:18 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:6966 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553956AbQLAJL6>;
	Fri, 1 Dec 2000 01:11:58 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id BAA01422
	for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 01:11:57 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id UAA06364; Fri, 1 Dec 2000 20:10:36 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Andy Lo A Foe <andy@alsa-project.org>
cc:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: latest CVS hangs on boot 
In-reply-to: Your message of "Fri, 01 Dec 2000 09:37:49 BST."
             <Pine.LNX.4.21.0012010926540.19662-100000@alsa.alsa-project.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 01 Dec 2000 20:10:36 +1100
Message-ID: <5753.975661836@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, 1 Dec 2000 09:37:49 +0100 (CET), 
Andy Lo A Foe <andy@alsa-project.org> wrote:
>/usr/src/XFS/linux-2.4-xfs/linux/include/linux/dis-asm.h:148: storage size
>of `display_endian' isn't known

display_endian is enum bfd_endian which is defined in
/usr/include/bfd.h.  You need a recent version of binutils to compile
with kdb, I run with binutils-2.9.5.0.22-6.


From owner-linux-xfs@oss.sgi.com Fri Dec  1 09:23:30 2000
Received:  by oss.sgi.com id <S553985AbQLARXV>;
	Fri, 1 Dec 2000 09:23:21 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55378 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553769AbQLARXG>; Fri, 1 Dec 2000 09:23:06 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA05616
	for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 09:31:10 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA7789623; Fri, 1 Dec 2000 11:21:48 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA52357; Fri, 1 Dec 2000 11:21:48 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB1HLmj30003;
	Fri, 1 Dec 2000 11:21:48 -0600
Message-ID: <3A27DE2C.31A62DAF@thebarn.com>
Date:   Fri, 01 Dec 2000 11:21:48 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: agf corruption on the alpha
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com> <news2mail-9061lo$dc3$3@mate.bln.innominate.de> <3A26C307.5FCCC673@thebarn.com> <news2mail-907le1$27r$1@mate.bln.innominate.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thomas Graichen wrote:

>
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 2 size 512
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 48 size 8192  °c4
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 1 size 512
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 3 size 512
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 32 size 8192  VÓ#
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 16 size 8192
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 265154 size 3072      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 2 size 512    XAGI
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 48 size 8192  IABT
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7dc0 block 1 size 512    XAGF
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7d20 block 32 size 8192  ABTC
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7f00 block 16 size 8192  ABTB
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7e60 block 0 size 1024   XFSB
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7460 block 128 size 8192 INAí
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 0 size 1024   XFSB

Ok here it is. The superblock write has the wrong size (1024)
The really odd thing the AGF and AGI are the correct size, I has half expecting them to
be 1024 also.

I will probably have to stare at the code a bit before I have any more suggestions.


>
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265160 size 1024      þíº¾
>
> i hope it is complete - because there are problems with the prink's not
> getting out all - klogd and syslogd seem to eat them up somehow - the
> above is what i got using "cat /proc/kmsg" which should be fine i
> think
>
> please let me know if you need also output from some more fs activity
> than just that simple echo to file (but i thought this might be
> simpler for you to find somthing in)
>
> good luck
>
> t
>
> p.s.: is there any trick to get the printk stuff out in a more prefect
>       way (i.e. complete and in perfect sync via klogd/syslogd)?

Not that I know of... mostly I just capture stuff with kermit logging.


>
>
> --
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77             http://www.innominate.com


From owner-linux-xfs@oss.sgi.com Fri Dec  1 09:52:50 2000
Received:  by oss.sgi.com id <S553989AbQLARwk>;
	Fri, 1 Dec 2000 09:52:40 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:23848 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553986AbQLARwg>;
	Fri, 1 Dec 2000 09:52:36 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA27928
	for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 09:52:35 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA7768939; Fri, 1 Dec 2000 11:51:18 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA96998; Fri, 1 Dec 2000 11:51:18 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB1HpIj30209;
	Fri, 1 Dec 2000 11:51:18 -0600
Message-ID: <3A27E514.CFC404EC@thebarn.com>
Date:   Fri, 01 Dec 2000 11:51:17 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     jd@davida.com
CC:     linux-xfs@oss.sgi.com
Subject: Re: 64 bit device sizes
References: <3A27721E.B03F10EE@davida.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Joseph I. Davida" wrote:

> If SGI does not push the Linux community
> into modifying the block IO layer to use
> 64 bit ints for representing the number of
> blocks in a device, we will be stuck with
> the 2 TB limit for a long time. One way to
> make this push is for SGI to go ahead and
> make the mods and let the rest catch up.
> The LARGEFILE support is already in place
> and it uses 64 bit ints for inodes, file
> sizes...etc. The only bit remaining is
> the LVM and block layer which still use
> 32 bit ints for device number of blocks.

That's not entirely true... inode number are still 32 bit.
the LARGEFILE support fixes the size fields for things
like stat and lseek but not inode numbers.

As far as the block layer stuff goes, the latest thinking from the 2.5
plans is to eliminate buffer_heads and implement a kiobuf based
io sub system.  The 32 bit limitations should go away at that time.

I suspect that we will end up back porting much of this to 2.4.whatever
since
we will need large FS support long before 2.5 becomes 2.6.

For the moment we are a ways from having 2TB file systems available for
ia32,
so we have waiting on rest  of the linux developers to solve this
problem
while we concentrate on stabilizing the file system itself.


>
> Cheers,
>
> Joe


From owner-linux-xfs@oss.sgi.com Fri Dec  1 10:08:21 2000
Received:  by oss.sgi.com id <S553997AbQLASIL>;
	Fri, 1 Dec 2000 10:08:11 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:65068 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553994AbQLASIA>;
	Fri, 1 Dec 2000 10:08:00 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA00277
	for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 10:08:00 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA7762307 for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 12:05:28 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA31263 for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 12:05:28 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eB1I5Sn30366
	for linux-xfs@oss.sgi.com; Fri, 1 Dec 2000 12:05:28 -0600
Date:   Fri, 1 Dec 2000 12:05:28 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200012011805.eB1I5Sn30366@gibble.americas.sgi.com>
Subject: TAKE - Simple code cleanup.
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Date:  Fri Dec  1 10:04:38 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:79622a
linux/drivers/block/ll_rw_blk.c - 1.53
	- Simple formating changes; clean up formating to match orginal file.



From owner-linux-xfs@oss.sgi.com Fri Dec  1 10:11:51 2000
Received:  by oss.sgi.com id <S553993AbQLASLb>;
	Fri, 1 Dec 2000 10:11:31 -0800
Received: from pC19F0385.dip.t-dialin.net ([193.159.3.133]:12421 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S553988AbQLASLP>; Fri, 1 Dec 2000 10:11:15 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB1IQm101620;
	Fri, 1 Dec 2000 19:26:48 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Fri, 1 Dec 2000 19:26:48 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
Message-ID: <20001201192648.A1611@s2y4n2c.de>
References: <20001130202247.A24118@s2y4n2c.de> <3A26F641.45226EF7@thebarn.com> <news2mail-907mbl$27r$4@mate.bln.innominate.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <news2mail-907mbl$27r$4@mate.bln.innominate.de>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi

same error with read-write.

utz

Thomas Graichen [news-innominate.list.sgi.xfs@innominate.de] wrote:
> just a very trivial idea (maybe wrong): i think i have seen this then
> i did not change the lilo entry for the xfs root from read-only to
> read-write ... but i might be wrong ... but if that should be the
> case the xfs code should maybe change it to read-write itself
> (if that is possible)
> 
> just an idea
> 
> t
> 
> Russell Cattelan <cattelan@thebarn.com> wrote:
> > utz lehmann wrote:
> 
> > Hmm not good.
> > We are going to need a bit more go to on.
> 
> > Can you get a backtrace from kdb?
> 
> > If you could hook up to a serial console that would
> > help in capturing the output.
> 
> 
> >> hi
> >>
> >> i found a bug in yesterdays (2000-11-29) kernel (the test11 one).
> >>
> >> i had powered off my computer without a clean shutdown. i do this very
> >> often, no problems since month with xfs.
> >>
> >> the kernel traped into kdb while recovering the xfs root filesystem. i write
> >> the messages down from the screen, maybe there are typos:
> >>
> >> XFS: WARNING: recovery required on readonly filesystem.
> >>
> >> XFS: write access will be enabled recovery.
> >>
> >> Staring XFS recovery on filesystem: ide0 (3,6) (dev:3/6)
> >> Unable to handle kernel NULL pointer dereference at virtual address 00000008
> >>  printing eip:
> >> c016482b
> >> *pde = 00000000
> >>
> >> Entering kdb (currect=0xc125c000, pid1) Panic: Oops
> >> due to panic @ 0xc016482b
> >> eax = 0x00000000 ebx = 0xc12c3460 ecx = 0xc12c3460 edx = 0x00000000
> >> esi = 0xc12c0e60 edi = 0x00000000 esp = 0xc125d940 eip = 0xc016482b
> >> ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246
> >> xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d90c
> >>
> >> i rebooted the machine with the same result.
> >> rebooting with a kernel from 2000-11-14 works with no problems.
> >>
> >> i made some tests with the buggy kernel:
> >>
> >> clean shutdown works.
> >> hardreset after "sync" works.
> >> hardreset after booting without sync works.
> >> hardreset during booting works.
> >> hardreset during writing (cp -av /usr/src/linux /tmp) triggers the bug.
> >> 4 times it traped into kdb, 1 time the kernel hangs.
> >>
> >> booting with the older kernel always works.
> >>
> >> my system:
> >> K6-500, 128MB
> >> xfs root filesystem on a ide disk.
> >>
> >> hope that helps.
> >>
> >> utz
> 
> 
> -- 
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Fri Dec  1 10:21:31 2000
Received:  by oss.sgi.com id <S554000AbQLASVV>;
	Fri, 1 Dec 2000 10:21:21 -0800
Received: from pC19F0385.dip.t-dialin.net ([193.159.3.133]:13701 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S553998AbQLASVE>; Fri, 1 Dec 2000 10:21:04 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB1Ib4g01696;
	Fri, 1 Dec 2000 19:37:04 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Fri, 1 Dec 2000 19:37:03 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     utz lehmann <xfs@s2y4n2c.de>, linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
Message-ID: <20001201193703.A1636@s2y4n2c.de>
References: <20001130202247.A24118@s2y4n2c.de> <3A26F641.45226EF7@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A26F641.45226EF7@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi

for serial console i need to solder a cable first.

i dont know to use kdb. can you help me.

thanks.

utz

Russell Cattelan [cattelan@thebarn.com] wrote:
> utz lehmann wrote:
> 
> Hmm not good.
> We are going to need a bit more go to on.
> 
> Can you get a backtrace from kdb?
> 
> If you could hook up to a serial console that would
> help in capturing the output.
> 
> 
> > hi
> >
> > i found a bug in yesterdays (2000-11-29) kernel (the test11 one).
> >
> > i had powered off my computer without a clean shutdown. i do this very
> > often, no problems since month with xfs.
> >
> > the kernel traped into kdb while recovering the xfs root filesystem. i write
> > the messages down from the screen, maybe there are typos:
> >
> > XFS: WARNING: recovery required on readonly filesystem.
> >
> > XFS: write access will be enabled recovery.
> >
> > Staring XFS recovery on filesystem: ide0 (3,6) (dev:3/6)
> > Unable to handle kernel NULL pointer dereference at virtual address 00000008
> >  printing eip:
> > c016482b
> > *pde = 00000000
> >
> > Entering kdb (currect=0xc125c000, pid1) Panic: Oops
> > due to panic @ 0xc016482b
> > eax = 0x00000000 ebx = 0xc12c3460 ecx = 0xc12c3460 edx = 0x00000000
> > esi = 0xc12c0e60 edi = 0x00000000 esp = 0xc125d940 eip = 0xc016482b
> > ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010246
> > xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d90c
> >
> > i rebooted the machine with the same result.
> > rebooting with a kernel from 2000-11-14 works with no problems.
> >
> > i made some tests with the buggy kernel:
> >
> > clean shutdown works.
> > hardreset after "sync" works.
> > hardreset after booting without sync works.
> > hardreset during booting works.
> > hardreset during writing (cp -av /usr/src/linux /tmp) triggers the bug.
> > 4 times it traped into kdb, 1 time the kernel hangs.
> >
> > booting with the older kernel always works.
> >
> > my system:
> > K6-500, 128MB
> > xfs root filesystem on a ide disk.
> >
> > hope that helps.
> >
> > utz

From owner-linux-xfs@oss.sgi.com Fri Dec  1 11:52:52 2000
Received:  by oss.sgi.com id <S554003AbQLATwl>;
	Fri, 1 Dec 2000 11:52:41 -0800
Received: from alsa.jcu.cz ([160.217.1.49]:47885 "EHLO alsa.alsa-project.org")
	by oss.sgi.com with ESMTP id <S553996AbQLATwb>;
	Fri, 1 Dec 2000 11:52:31 -0800
Received: from localhost (andy@localhost)
	by alsa.alsa-project.org (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA23115;
	Fri, 1 Dec 2000 20:51:54 +0100
Date:   Fri, 1 Dec 2000 20:51:53 +0100 (CET)
From:   Andy Lo A Foe <andy@alsa-project.org>
To:     Keith Owens <kaos@melbourne.sgi.com>
cc:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: latest CVS hangs on boot 
In-Reply-To: <5753.975661836@kao2.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0012011022220.22547-100000@alsa.alsa-project.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, 1 Dec 2000, Keith Owens wrote:

> display_endian is enum bfd_endian which is defined in
> /usr/include/bfd.h.  You need a recent version of binutils to compile
> with kdb, I run with binutils-2.9.5.0.22-6.

Whoops, didn't know there was a binutils-dev package, I'm using
binutils-2.10.1.0.2-1 (packaged with Debian/Woody). Right, after
installing the headers the kernel build successfully! Now, I started the
debugger with kdb=early and did some exploring. Trying to figure out how
to set breakpoints inside the init functions (C is my comfort layer). Help
appreciated :)

-andy

--
AlsaPlayer, http://www.alsaplayer.org/



From owner-linux-xfs@oss.sgi.com Fri Dec  1 13:52:12 2000
Received:  by oss.sgi.com id <S554008AbQLAVwC>;
	Fri, 1 Dec 2000 13:52:02 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:1550 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S554002AbQLAVvx>;
	Fri, 1 Dec 2000 13:51:53 -0800
Received: (qmail 24496 invoked from network); 1 Dec 2000 21:51:47 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 1 Dec 2000 21:51:46 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     utz lehmann <xfs@s2y4n2c.de>
cc:     linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery 
In-reply-to: Your message of "Fri, 01 Dec 2000 19:37:03 BST."
             <20001201193703.A1636@s2y4n2c.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Sat, 02 Dec 2000 08:51:46 +1100
Message-ID: <20516.975707506@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, 1 Dec 2000 19:37:03 +0100, 
utz lehmann <xfs@s2y4n2c.de> wrote:
>i dont know to use kdb. can you help me.

There are manual pages for kdb, "man Documentation/kdb/kdb.mm" for an
overview, then read the other man pages.  Little known Linux fact, if
the 'man' command is given a name that contains '/' then it goes direct
to that file instead of searching the man paths.

  cd linux/Documentation/kdb
  man ./kdb.mm
  man ./kdb_bt.man
  etc.

man kdb.mm will search the man paths, man ./kdb.mm will look at the
specified file.

For this problem, the starting point is a backtrace on the failing
process, the kdb command is 'bt'.  To capture the output there are two
options :-

(1) Run a null modem cable to a second machine, compile the kernel with
    serial console enabled (CONFIG_SERIAL=y, CONFIG_SERIAL_CONSOLE=y),
    boot with the serial console active.  My lilo.conf contains

      append="console=tty0 console=ttyS1,38400"

    This is all covered in Documentation/serial-console.txt.  Run any
    comms program on the second machine to capture the output.  You can
    enter kdb commands on either the main keyboard or the serial
    console.

(2) If the syslog has started before the panic and the machine is
    usable after the panic and the amount of output is small (less than
    8K of text) then you can save the kdb output via syslog.  When you
    enter kdb, type

      set LOGGING=1

    kdb output will be stored in the syslog buffer.  When you type 'go'
    in kdb, that data will be written to disk by syslog.  Of course
    that requires that syslog is working after the panic.  In a lot of
    cases the panic kills the machine and syslog is never written so
    this option is not reliable.

You can enter preset commands via kdb/kdb_cmds then compile.  Any
commands added to that file are issued during kdb initialization.  It
is a useful place to store your standard settings for kdb environment
variables.


From owner-linux-xfs@oss.sgi.com Fri Dec  1 18:46:14 2000
Received:  by oss.sgi.com id <S554031AbQLBCqE>;
	Fri, 1 Dec 2000 18:46:04 -0800
Received: from p3E9D19CB.dip.t-dialin.net ([62.157.25.203]:45701 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S554025AbQLBCpq>; Fri, 1 Dec 2000 18:45:46 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB231pL05632;
	Sat, 2 Dec 2000 04:01:51 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Sat, 2 Dec 2000 04:01:51 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Keith Owens <kaos@melbourne.sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
Message-ID: <20001202040151.A5499@s2y4n2c.de>
References: <20001201193703.A1636@s2y4n2c.de> <20516.975707506@ocs3.ocs-net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20516.975707506@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

ok, here is the backtrace (via serial console):

[...]
fatfs: bogus cluster size
fatfs: bogus cluster size
Start mounting filesystem: ide0(3,6)
XFS: WARNING: recovery required on readonly filesystem.

XFS: write access will be enabled during recovery.

Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
kernel BUG at slab.c:1542!

Entering kdb (current=0xc125c000, pid 1) Panic: invalid operand
due to panic @ 0xc0127d97
eax = 0x0000001b ebx = 0x00000000 ecx = 0x00000001 edx = 0x00000001 
esi = 0x003fc680 edi = 0x00000007 esp = 0xc125d7ec eip = 0xc0127d97 
ebp = 0xc12c0be0 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286 
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d7b8
kdb> bt
    EBP       EIP         Function(args)
0xc12c0be0 0x00000000c0127d97 kmalloc+0x97 (0x3fc680, 0x7)
                               kernel .text 0xc0100000 0xc0127d00 0xc0127da8
           0x00000000c01428ba expand_kiobuf+0x2e (0xc12c0be0, 0xff1a0)
                               kernel .text 0xc0100000 0xc014288c 0xc01429cc
           0x00000000c0163011 _pagebuf_get_kiovec+0x39 (0xc12be960, 0xff1a0)
                               kernel .text 0xc0100000 0xc0162fd8 0xc0163060
           0x00000000c01632e8 _pagebuf_lookup_pages+0x12c (0xc12be960, 0xdc8ab000, 0xcad2e4e8, 0xff1a0000, 0x202201)
                               kernel .text 0xc0100000 0xc01631bc 0xc0163730
           0x00000000c01638e1 pagebuf_get+0x159 (0xc1249940, 0xdc8ab000, 0xcad2e4e8, 0xff1a0000, 0x2201)
                               kernel .text 0xc0100000 0xc0163788 0xc016399c
           0x00000000c01ad570 xlog_recover_do_inode_trans+0xe0 (0xc125bb60, 0xc12a85c0, 0x2)
                               kernel .text 0xc0100000 0xc01ad490 0xc01adb6c
           0x00000000c01adf2a xlog_recover_do_trans+0x6e (0xc125bb60, 0xc7f86260, 0x2)
                               kernel .text 0xc0100000 0xc01adebc 0xc01adfc8
           0x00000000c01ae05b xlog_recover_commit_trans+0x27 (0xc125bb60, 0xc125da98, 0xc7f86260, 0x2)
                               kernel .text 0xc0100000 0xc01ae034 0xc01ae070
           0x00000000c01ae1a8 xlog_recover_process_data+0x124 (0xc125bb60, 0xc125da60, 0xc7f8ec00, 0xc7f30238, 0x2)
                               kernel .text 0xc0100000 0xc01ae084 0xc01ae230
           0x00000000c01aed45 xlog_do_recovery_pass+0x42d (0xc125bb60, 0x9a6, 0x0, 0x1b88, 0x0)
                               kernel .text 0xc0100000 0xc01ae918 0xc01aeed0
           0x00000000c01aef45 xlog_do_log_recovery+0x75 (0xc125bb60, 0x9a6, 0x0, 0x1b88, 0x0)
more>  
                               kernel .text 0xc0100000 0xc01aeed0 0xc01aef6c
           0x00000000c01aef8e xlog_do_recover+0x22 (0xc125bb60, 0x9a6, 0x0, 0x1b88, 0x0)
                               kernel .text 0xc0100000 0xc01aef6c 0xc01af064
           0x00000000c01af100 xlog_recover+0x9c (0xc125bb60, 0x1)
                               kernel .text 0xc0100000 0xc01af064 0xc01af128
           0x00000000c01a9045 xfs_log_mount+0x75 (0xc7f87400, 0x306, 0x24c520, 0x0, 0x2580)
                               kernel .text 0xc0100000 0xc01a8fd0 0xc01a907c
           0x00000000c01b07e8 xfs_mountfs+0xcf4 (0xc7f86160, 0xc7f87400, 0x306, 0x0)
                               kernel .text 0xc0100000 0xc01afaf4 0xc01b0c64
           0x00000000c01b8bd9 xfs_cmountfs+0x51d (0xc7f86160, 0x306, 0x306, 0x0, 0x2)
                               kernel .text 0xc0100000 0xc01b86bc 0xc01b8c44
           0x00000000c01b8dde xfs_mount+0xd2 (0xc7f86160, 0xc7f8e6ec, 0xc125df20, 0xc0388fe0, 0xc7f86160)
                               kernel .text 0xc0100000 0xc01b8d0c 0xc01b8de8
           0x00000000c01b8e0b xfs_vfsmount+0x23 (0xc7f86160, 0xc7f8e6ec, 0xc125df20, 0x0, 0xc0388fe0)
                               kernel .text 0xc0100000 0xc01b8de8 0xc01b8e20
           0x00000000c01c9bc1 linvfs_read_super+0x225 (0xc7f8e400, 0x0, 0x1)
                               kernel .text 0xc0100000 0xc01c999c 0xc01c9ca4
           0x00000000c01337bc read_super+0x100 (0x306, 0xc7f85120, 0xc0326270, 0x1, 0x0)
                               kernel .text 0xc0100000 0xc01336bc 0xc013382c
           0x00000000c033c834 mount_root+0x164
                               kernel .text.init 0xc0336000 0xc033c6d0 0xc033ca40
           0x00000000c033692e do_basic_setup+0x3a
                               kernel .text.init 0xc0336000 0xc03368f4 0xc0336930
more> 
           0x00000000c0107007 init+0x7
                               kernel .text 0xc0100000 0xc0107000 0xc0107150
           0x00000000c0108da7 kernel_thread+0x23
                               kernel .text 0xc0100000 0xc0108d84 0xc0108db4
kdb> 




what should i do next?


utz

From owner-linux-xfs@oss.sgi.com Fri Dec  1 19:16:34 2000
Received:  by oss.sgi.com id <S554033AbQLBDQO>;
	Fri, 1 Dec 2000 19:16:14 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:55873 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554030AbQLBDPv>;
	Fri, 1 Dec 2000 19:15:51 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA15903
	for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 19:15:50 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA44285; Fri, 1 Dec 2000 19:09:06 -0800 (PST)
Message-ID: <3A286883.D90E004A@sgi.com>
Date:   Fri, 01 Dec 2000 19:12:03 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     utz lehmann <xfs@s2y4n2c.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
References: <20001201193703.A1636@s2y4n2c.de> <20516.975707506@ocs3.ocs-net> <20001202040151.A5499@s2y4n2c.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

utz lehmann wrote:
> 
> ok, here is the backtrace (via serial console):
	[ ... ]
> 
> Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
> kernel BUG at slab.c:1542!
> 
	[ ... ]
> 
> what should i do next?

First, the immediate BUG() is due to a bogus sized
kmalloc being requested.

Second, I've been seeing problems here with recovery;
so far I thought it was a bug in code that I've been
working on. But looking at your backtrace may be something
else is broken.

Looking through some recent changes, I think a bcopy
was accidentally deleted. In file fs/xfs/xfs_log_recover.c,
AFTER the kmem_realloc( ... ) at line 1218, can you ADD:

         bcopy(dp , &ptr[old_len], len);                 /* s, d, l */

Can you please recompile & retry recovery?

Thanks for your efforts in providing debug information!

ananth.

PS: Daniel, revision 1.195 is where the bcopy was taken out.
    It appears to be an error. Can you please check?

-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Fri Dec  1 19:20:14 2000
Received:  by oss.sgi.com id <S554035AbQLBDUE>;
	Fri, 1 Dec 2000 19:20:04 -0800
Received: from p3EE05020.dip.t-dialin.net ([62.224.80.32]:51589 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S554032AbQLBDTx>; Fri, 1 Dec 2000 19:19:53 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB23a1o06132;
	Sat, 2 Dec 2000 04:36:01 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Sat, 2 Dec 2000 04:36:01 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Keith Owens <kaos@melbourne.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
Message-ID: <20001202043601.A6078@s2y4n2c.de>
References: <20001201193703.A1636@s2y4n2c.de> <20516.975707506@ocs3.ocs-net> <20001202040151.A5499@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001202040151.A5499@s2y4n2c.de>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


interesting.
i repeated the test:
- booting with the good kernel to recover the filesytem.
- cp -av /usr/src/linux/ /tmp/
- hardreset
- booting the bad kernel


[...]
fatfs: bogus cluster size
fatfs: bogus cluster size
Start mounting filesystem: ide0(3,6)
XFS: WARNING: recovery required on readonly filesystem.

XFS: write access will be enabled during recovery.

Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
cmn_err level 1 Filesystem "ide0(3,6)": xfs_inode_recover: Bad inode log record, rec ptr 0xc12a2ce0, dino ptr 0xc12b9b00, dino bp 0xc7f45d00, ino 13752315, total extents = -2, nblocks = 0
XFS: log mount/recovery failed
XFS: log mount failed
Kernel panic: VFS: Unable to mount root fs on 03:06

the kernel hangs, no kdb!



same procedure above:

[...]
fatfs: bogus cluster size
fatfs: bogus cluster size
Start mounting filesystem: ide0(3,6)
XFS: WARNING: recovery required on readonly filesystem.

XFS: write access will be enabled during recovery.

Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
Unable to handle kernel NULL pointer dereference at virtual address 0000003c
 printing eip:
c0163d04
*pde = 00000000

Entering kdb (current=0xc125c000, pid 1) Panic: Oops
due to panic @ 0xc0163d04
eax = 0x00000000 ebx = 0xc7f87400 ecx = 0x00000000 edx = 0x00000200 
esi = 0xc1281d20 edi = 0x00000001 esp = 0xc125d944 eip = 0xc0163d04 
ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010282 
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d910
kdb> bt
    EBP       EIP         Function(args)
           0x00000000c0163d04 pagebuf_geterror+0x4 (0x0)
                               kernel .text 0xc0100000 0xc0163d00 0xc0163d08
           0x00000000c01ad329 xlog_recover_do_buffer_trans+0x155 (0xc125bb60, 0xc12811e0, 0x2)
                               kernel .text 0xc0100000 0xc01ad1d4 0xc01ad490
           0x00000000c01adfb5 xlog_recover_do_trans+0xf9 (0xc125bb60, 0xc7f861a0, 0x2)
                               kernel .text 0xc0100000 0xc01adebc 0xc01adfc8
           0x00000000c01ae05b xlog_recover_commit_trans+0x27 (0xc125bb60, 0xc125da78, 0xc7f861a0, 0x2)
                               kernel .text 0xc0100000 0xc01ae034 0xc01ae070
           0x00000000c01ae1a8 xlog_recover_process_data+0x124 (0xc125bb60, 0xc125da60, 0xc7f8ec00, 0xc7f30d9c, 0x2)
                               kernel .text 0xc0100000 0xc01ae084 0xc01ae230
           0x00000000c01aed45 xlog_do_recovery_pass+0x42d (0xc125bb60, 0x6d9, 0x0, 0x123d, 0x0)
                               kernel .text 0xc0100000 0xc01ae918 0xc01aeed0
           0x00000000c01aef45 xlog_do_log_recovery+0x75 (0xc125bb60, 0x6d9, 0x0, 0x123d, 0x0)
                               kernel .text 0xc0100000 0xc01aeed0 0xc01aef6c
           0x00000000c01aef8e xlog_do_recover+0x22 (0xc125bb60, 0x6d9, 0x0, 0x123d, 0x0)
                               kernel .text 0xc0100000 0xc01aef6c 0xc01af064
           0x00000000c01af100 xlog_recover+0x9c (0xc125bb60, 0x1)
                               kernel .text 0xc0100000 0xc01af064 0xc01af128
           0x00000000c01a9045 xfs_log_mount+0x75 (0xc7f87400, 0x306, 0x24c520, 0x0, 0x2580)
                               kernel .text 0xc0100000 0xc01a8fd0 0xc01a907c
           0x00000000c01b07e8 xfs_mountfs+0xcf4 (0xc7f86160, 0xc7f87400, 0x306, 0x0)
more> 
                               kernel .text 0xc0100000 0xc01afaf4 0xc01b0c64
           0x00000000c01b8bd9 xfs_cmountfs+0x51d (0xc7f86160, 0x306, 0x306, 0x0, 0x2)
                               kernel .text 0xc0100000 0xc01b86bc 0xc01b8c44
           0x00000000c01b8dde xfs_mount+0xd2 (0xc7f86160, 0xc7f8e6ec, 0xc125df20, 0xc0388fe0, 0xc7f86160)
                               kernel .text 0xc0100000 0xc01b8d0c 0xc01b8de8
           0x00000000c01b8e0b xfs_vfsmount+0x23 (0xc7f86160, 0xc7f8e6ec, 0xc125df20, 0x0, 0xc0388fe0)
                               kernel .text 0xc0100000 0xc01b8de8 0xc01b8e20
           0x00000000c01c9bc1 linvfs_read_super+0x225 (0xc7f8e400, 0x0, 0x1)
                               kernel .text 0xc0100000 0xc01c999c 0xc01c9ca4
           0x00000000c01337bc read_super+0x100 (0x306, 0xc7f85120, 0xc0326270, 0x1, 0x0)
                               kernel .text 0xc0100000 0xc01336bc 0xc013382c
           0x00000000c033c834 mount_root+0x164
                               kernel .text.init 0xc0336000 0xc033c6d0 0xc033ca40
           0x00000000c033692e do_basic_setup+0x3a
                               kernel .text.init 0xc0336000 0xc03368f4 0xc0336930
           0x00000000c0107007 init+0x7
                               kernel .text 0xc0100000 0xc0107000 0xc0107150
           0x00000000c0108da7 kernel_thread+0x23
                               kernel .text 0xc0100000 0xc0108d84 0xc0108db4
kdb> 

From owner-linux-xfs@oss.sgi.com Fri Dec  1 19:39:34 2000
Received:  by oss.sgi.com id <S554037AbQLBDjO>;
	Fri, 1 Dec 2000 19:39:14 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14615 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554034AbQLBDiw>; Fri, 1 Dec 2000 19:38:52 -0800
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA00784; Fri, 1 Dec 2000 19:46:56 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id TAA22174;
	Fri, 1 Dec 2000 19:38:51 -0800 (PST)
Date:   Fri, 1 Dec 2000 19:38:51 -0800 (PST)
Message-Id: <200012020338.TAA22174@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  dhcp-163-154-5-223.engr.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (srn@engr.sgi.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com,
        tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570

 Status : open                         Priority : 3                         
 Assigned Engineer : nb                Submitter : coreym                   
*Modified User : srn                  *Modified User Domain : engr          
*Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: srn@engr (BugWorks)
Date: Dec 01 2000 07:38:50PM
==========================

QA has identified this as one of their top IA32 bugs.
I've asked Chris Brady in FTS to triage and take 
a look to see if we can help; here's his comments:

#804570 - The elevator bug
This is is a system hang problem that sounds fairly serious.
However, it looks like it is only related to the xfs filesystem.
I sent e-mail to the case owner (nb@sgi whoever that is) and 
offered help.  If we can help with this I will try to get 
Sean on it.

From owner-linux-xfs@oss.sgi.com Fri Dec  1 20:09:44 2000
Received:  by oss.sgi.com id <S554039AbQLBEJe>;
	Fri, 1 Dec 2000 20:09:34 -0800
Received: from pC19F7517.dip.t-dialin.net ([193.159.117.23]:53637 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S553779AbQLBEJT>; Fri, 1 Dec 2000 20:09:19 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB24POP06535;
	Sat, 2 Dec 2000 05:25:24 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Sat, 2 Dec 2000 05:25:24 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
Message-ID: <20001202052524.A6500@s2y4n2c.de>
References: <20001201193703.A1636@s2y4n2c.de> <20516.975707506@ocs3.ocs-net> <20001202040151.A5499@s2y4n2c.de> <3A286883.D90E004A@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A286883.D90E004A@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

it works!

i made 2 tests with it: it works.

then i made 3 tests with following procedure:
- cp -av 
- boot the bad kernel. it hangs or crashend.
- boot with the patched kernel. recovery works.


thanks!

utz

Rajagopal Ananthanarayanan [ananth@sgi.com] wrote:
> utz lehmann wrote:
> > 
> > ok, here is the backtrace (via serial console):
> 	[ ... ]
> > 
> > Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
> > kernel BUG at slab.c:1542!
> > 
> 	[ ... ]
> > 
> > what should i do next?
> 
> First, the immediate BUG() is due to a bogus sized
> kmalloc being requested.
> 
> Second, I've been seeing problems here with recovery;
> so far I thought it was a bug in code that I've been
> working on. But looking at your backtrace may be something
> else is broken.
> 
> Looking through some recent changes, I think a bcopy
> was accidentally deleted. In file fs/xfs/xfs_log_recover.c,
> AFTER the kmem_realloc( ... ) at line 1218, can you ADD:
> 
>          bcopy(dp , &ptr[old_len], len);                 /* s, d, l */
> 
> Can you please recompile & retry recovery?
> 
> Thanks for your efforts in providing debug information!
> 
> ananth.
> 
> PS: Daniel, revision 1.195 is where the bcopy was taken out.
>     It appears to be an error. Can you please check?
> 
> -- 
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Fri Dec  1 21:05:54 2000
Received:  by oss.sgi.com id <S554041AbQLBFFp>;
	Fri, 1 Dec 2000 21:05:45 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57113 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554038AbQLBFFS>; Fri, 1 Dec 2000 21:05:18 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA03477
	for <linux-xfs@oss.sgi.com>; Fri, 1 Dec 2000 21:13:22 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA46108; Fri, 1 Dec 2000 20:59:43 -0800 (PST)
Message-ID: <3A28828E.7C0D4FBA@sgi.com>
Date:   Fri, 01 Dec 2000 21:03:10 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     utz lehmann <xfs@s2y4n2c.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
References: <20001201193703.A1636@s2y4n2c.de> <20516.975707506@ocs3.ocs-net> <20001202040151.A5499@s2y4n2c.de> <3A286883.D90E004A@sgi.com> <20001202052524.A6500@s2y4n2c.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

utz lehmann wrote:
> 
> it works!
> 
> i made 2 tests with it: it works.
> 
> then i made 3 tests with following procedure:
> - cp -av
> - boot the bad kernel. it hangs or crashend.
> - boot with the patched kernel. recovery works.
> 

Cool ... I'll try similar experiments here as well.
Good to see that recovery works inspite of a fairly
serious bug!

regards,


--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Fri Dec  1 21:14:04 2000
Received:  by oss.sgi.com id <S554043AbQLBFNz>;
	Fri, 1 Dec 2000 21:13:55 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2586 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554040AbQLBFNm>; Fri, 1 Dec 2000 21:13:42 -0800
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA07582; Fri, 1 Dec 2000 21:21:46 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id VAA09127;
	Fri, 1 Dec 2000 21:13:38 -0800 (PST)
Date:   Fri, 1 Dec 2000 21:13:38 -0800 (PST)
Message-Id: <200012020513.VAA09127@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  sgigate.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (ananth@engr.sgi.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com,
        tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570

 Status : open                         Priority : 3                         
 Assigned Engineer : nb                Submitter : coreym                   
*Modified User : ananth               *Modified User Domain : engr          
*Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: ananth@engr (BugWorks)
Date: Dec 01 2000 09:13:37PM
==========================


Just so there is no confusion, this is only
in Linux 2.4 ... here it has been observed
only with XFS but elsewhere there also reports
with ext2. Jens Axboe has some fixes for it.
For XFS we are hoping the changes make it into
the next 2.4 patch, test12.

Steve, are you seeing this in 2.4 kernels?

ananth.

From owner-linux-xfs@oss.sgi.com Fri Dec  1 23:18:45 2000
Received:  by oss.sgi.com id <S554045AbQLBHSg>;
	Fri, 1 Dec 2000 23:18:36 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:40708 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S554042AbQLBHSK>;
	Fri, 1 Dec 2000 23:18:10 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eB27HrQ44014;
	Sat, 2 Dec 2000 01:17:53 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A28A221.37A42167@thebarn.com>
Date:   Sat, 02 Dec 2000 01:17:53 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     sgi.bugs.xfs@fido.engr.sgi.com
CC:     nb@sgi.com, raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com,
        mann@sgi.com, tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com,
        linux-xfs@oss.sgi.com
Subject: Re: ADD 804570 - The elevator bug
References: <200012020513.VAA09127@info.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"ananth@engr.sgi.com" wrote:

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570
>
>  Status : open                         Priority : 3
>  Assigned Engineer : nb                Submitter : coreym
> *Modified User : ananth               *Modified User Domain : engr
> *Description :
> I ran rwtest on a xfs-linux filesystem on the machine permit:
>
> rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &
>
> This caused df, ls -l, fdisk, and top all to hang.
>
> Permit is running Redhat 6.2 with a 2.4.0-test5 kernel
>
> ==========================
> ADDITIONAL INFORMATION (ADD)
>
> .....
>
> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: ananth@engr (BugWorks)
> Date: Dec 01 2000 09:13:37PM
> ==========================
>
> Just so there is no confusion, this is only
> in Linux 2.4 ... here it has been observed
> only with XFS but elsewhere there also reports
> with ext2. Jens Axboe has some fixes for it.
> For XFS we are hoping the changes make it into
> the next 2.4 patch, test12.

Yes this is a know problem in the latest 2.4 kernels.
It has been observed on other file  systems as well not just XFS.

I have do have a kernel with Jens elevator patch, that does
appear to fix the starvation problem. Unfortunately it appears to either
have problems itself or is exposing  problems in the XFS code.

Currently XFS kiobuf based io causes a lockup that eventually cause the
kernel to through an NMI.

Non kiobuf io causes pagebuf to panic under heavy load.

I got this running late friday and haven't had much
of a chance to investigate.

Since this is a linux bug we are  waiting for the official
fix to show up in the linux tree.

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri Dec  1 23:21:55 2000
Received:  by oss.sgi.com id <S554047AbQLBHVp>;
	Fri, 1 Dec 2000 23:21:45 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:5993 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554044AbQLBHVX>;
	Fri, 1 Dec 2000 23:21:23 -0800
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA06701; Fri, 1 Dec 2000 23:21:22 -0800 (PST)
	mail_from (pv@feature.engr.sgi.com)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id XAA19932; Fri, 1 Dec 2000 23:20:03 -0800 (PST)
Date:   Fri, 1 Dec 2000 23:20:03 -0800 (PST)
Message-Id: <200012020720.XAA19932@feature.engr.sgi.com>
X-Pv-Incident: 804570 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (cattelan@thebarn.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com,
        tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : coreym                    Status : open                        
 Assigned Engineer : nb                Priority : 3                         
*Modified Date : 12/01/00             *Modified User : cattelan             
*Modified User Domain : thebarn.com   *Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: russell cattelan <cattelan@thebarn.com>
Date: Dec 01 2000 11:20:03PM
[pvnews version: 1.71]
==========================
"ananth@engr.sgi.com" wrote:

> View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570
>
>  Status : open                         Priority : 3
>  Assigned Engineer : nb                Submitter : coreym
> *Modified User : ananth               *Modified User Domain : engr
> *Description :
> I ran rwtest on a xfs-linux filesystem on the machine permit:
>
> rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &
>
> This caused df, ls -l, fdisk, and top all to hang.
>
> Permit is running Redhat 6.2 with a 2.4.0-test5 kernel
>
> ==========================
> ADDITIONAL INFORMATION (ADD)
>
> .....
>
> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: ananth@engr (BugWorks)
> Date: Dec 01 2000 09:13:37PM
> ==========================
>
> Just so there is no confusion, this is only
> in Linux 2.4 ... here it has been observed
> only with XFS but elsewhere there also reports
> with ext2. Jens Axboe has some fixes for it.
> For XFS we are hoping the changes make it into
> the next 2.4 patch, test12.

Yes this is a know problem in the latest 2.4 kernels.
It has been observed on other file  systems as well not just XFS.

I have do have a kernel with Jens elevator patch, that does
appear to fix the starvation problem. Unfortunately it appears to either
have problems itself or is exposing  problems in the XFS code.

Currently XFS kiobuf based io causes a lockup that eventually cause the
kernel to through an NMI.

Non kiobuf io causes pagebuf to panic under heavy load.

I got this running late friday and haven't had much
of a chance to investigate.

Since this is a linux bug we are  waiting for the official
fix to show up in the linux tree.

--
Russell Cattelan
cattelan@thebarn.com

From owner-linux-xfs@oss.sgi.com Fri Dec  1 23:25:46 2000
Received:  by oss.sgi.com id <S554049AbQLBHZ0>;
	Fri, 1 Dec 2000 23:25:26 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:46084 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S554046AbQLBHZO>;
	Fri, 1 Dec 2000 23:25:14 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eB27P3Q44031;
	Sat, 2 Dec 2000 01:25:04 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A28A3CF.1621C40D@thebarn.com>
Date:   Sat, 02 Dec 2000 01:25:03 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     utz lehmann <xfs@s2y4n2c.de>
CC:     Keith Owens <kaos@melbourne.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery
References: <20001201193703.A1636@s2y4n2c.de> <20516.975707506@ocs3.ocs-net> <20001202040151.A5499@s2y4n2c.de> <20001202043601.A6078@s2y4n2c.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

utz lehmann wrote:

I've actually recently hit the same bug.

But it looks like Ananth hit the nail on the head
and found the problem.


Keep the cable handy :-)


> interesting.
> i repeated the test:
> - booting with the good kernel to recover the filesytem.
> - cp -av /usr/src/linux/ /tmp/
> - hardreset
> - booting the bad kernel
>
> [...]
> fatfs: bogus cluster size
> fatfs: bogus cluster size
> Start mounting filesystem: ide0(3,6)
> XFS: WARNING: recovery required on readonly filesystem.
>
> XFS: write access will be enabled during recovery.
>
> Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
> cmn_err level 1 Filesystem "ide0(3,6)": xfs_inode_recover: Bad inode log record, rec ptr 0xc12a2ce0, dino ptr 0xc12b9b00, dino bp 0xc7f45d00, ino 13752315, total extents = -2, nblocks = 0
> XFS: log mount/recovery failed
> XFS: log mount failed
> Kernel panic: VFS: Unable to mount root fs on 03:06
>
> the kernel hangs, no kdb!
>
> same procedure above:
>
> [...]
> fatfs: bogus cluster size
> fatfs: bogus cluster size
> Start mounting filesystem: ide0(3,6)
> XFS: WARNING: recovery required on readonly filesystem.
>
> XFS: write access will be enabled during recovery.
>
> Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
> Unable to handle kernel NULL pointer dereference at virtual address 0000003c
>  printing eip:
> c0163d04
> *pde = 00000000
>
> Entering kdb (current=0xc125c000, pid 1) Panic: Oops
> due to panic @ 0xc0163d04
> eax = 0x00000000 ebx = 0xc7f87400 ecx = 0x00000000 edx = 0x00000200
> esi = 0xc1281d20 edi = 0x00000001 esp = 0xc125d944 eip = 0xc0163d04
> ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010282
> xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc125d910
> kdb> bt
>     EBP       EIP         Function(args)
>            0x00000000c0163d04 pagebuf_geterror+0x4 (0x0)
>                                kernel .text 0xc0100000 0xc0163d00 0xc0163d08
>            0x00000000c01ad329 xlog_recover_do_buffer_trans+0x155 (0xc125bb60, 0xc12811e0, 0x2)
>                                kernel .text 0xc0100000 0xc01ad1d4 0xc01ad490
>            0x00000000c01adfb5 xlog_recover_do_trans+0xf9 (0xc125bb60, 0xc7f861a0, 0x2)
>                                kernel .text 0xc0100000 0xc01adebc 0xc01adfc8
>            0x00000000c01ae05b xlog_recover_commit_trans+0x27 (0xc125bb60, 0xc125da78, 0xc7f861a0, 0x2)
>                                kernel .text 0xc0100000 0xc01ae034 0xc01ae070
>            0x00000000c01ae1a8 xlog_recover_process_data+0x124 (0xc125bb60, 0xc125da60, 0xc7f8ec00, 0xc7f30d9c, 0x2)
>                                kernel .text 0xc0100000 0xc01ae084 0xc01ae230
>            0x00000000c01aed45 xlog_do_recovery_pass+0x42d (0xc125bb60, 0x6d9, 0x0, 0x123d, 0x0)
>                                kernel .text 0xc0100000 0xc01ae918 0xc01aeed0
>            0x00000000c01aef45 xlog_do_log_recovery+0x75 (0xc125bb60, 0x6d9, 0x0, 0x123d, 0x0)
>                                kernel .text 0xc0100000 0xc01aeed0 0xc01aef6c
>            0x00000000c01aef8e xlog_do_recover+0x22 (0xc125bb60, 0x6d9, 0x0, 0x123d, 0x0)
>                                kernel .text 0xc0100000 0xc01aef6c 0xc01af064
>            0x00000000c01af100 xlog_recover+0x9c (0xc125bb60, 0x1)
>                                kernel .text 0xc0100000 0xc01af064 0xc01af128
>            0x00000000c01a9045 xfs_log_mount+0x75 (0xc7f87400, 0x306, 0x24c520, 0x0, 0x2580)
>                                kernel .text 0xc0100000 0xc01a8fd0 0xc01a907c
>            0x00000000c01b07e8 xfs_mountfs+0xcf4 (0xc7f86160, 0xc7f87400, 0x306, 0x0)
> more>
>                                kernel .text 0xc0100000 0xc01afaf4 0xc01b0c64
>            0x00000000c01b8bd9 xfs_cmountfs+0x51d (0xc7f86160, 0x306, 0x306, 0x0, 0x2)
>                                kernel .text 0xc0100000 0xc01b86bc 0xc01b8c44
>            0x00000000c01b8dde xfs_mount+0xd2 (0xc7f86160, 0xc7f8e6ec, 0xc125df20, 0xc0388fe0, 0xc7f86160)
>                                kernel .text 0xc0100000 0xc01b8d0c 0xc01b8de8
>            0x00000000c01b8e0b xfs_vfsmount+0x23 (0xc7f86160, 0xc7f8e6ec, 0xc125df20, 0x0, 0xc0388fe0)
>                                kernel .text 0xc0100000 0xc01b8de8 0xc01b8e20
>            0x00000000c01c9bc1 linvfs_read_super+0x225 (0xc7f8e400, 0x0, 0x1)
>                                kernel .text 0xc0100000 0xc01c999c 0xc01c9ca4
>            0x00000000c01337bc read_super+0x100 (0x306, 0xc7f85120, 0xc0326270, 0x1, 0x0)
>                                kernel .text 0xc0100000 0xc01336bc 0xc013382c
>            0x00000000c033c834 mount_root+0x164
>                                kernel .text.init 0xc0336000 0xc033c6d0 0xc033ca40
>            0x00000000c033692e do_basic_setup+0x3a
>                                kernel .text.init 0xc0336000 0xc03368f4 0xc0336930
>            0x00000000c0107007 init+0x7
>                                kernel .text 0xc0100000 0xc0107000 0xc0107150
>            0x00000000c0108da7 kernel_thread+0x23
>                                kernel .text 0xc0100000 0xc0108d84 0xc0108db4
> kdb>

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun Dec  3 14:10:39 2000
Received:  by oss.sgi.com id <S553855AbQLCWKa>;
	Sun, 3 Dec 2000 14:10:30 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:3629 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553852AbQLCWKX>;
	Sun, 3 Dec 2000 14:10:23 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA25839
	for <linux-xfs@oss.sgi.com>; Sun, 3 Dec 2000 14:10:21 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA01516
	for linux-xfs@oss.sgi.com; Mon, 4 Dec 2000 09:09:04 +1100 (EST)
Date:   Mon, 4 Dec 2000 09:09:04 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200012032209.JAA01516@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - Recovery bugfix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ouch - put back in accidently removed line.

Modid:  2.4.x-xfs:slinx:79810a
Date:  Sun Dec  3 14:08:19 PST 2000
Workarea:  snort:/diska/build1/people/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_log_recover.c - 1.198
	- OUCH - put back in accidently removed line


From owner-linux-xfs@oss.sgi.com Mon Dec  4 06:08:48 2000
Received:  by oss.sgi.com id <S553845AbQLDOIi>;
	Mon, 4 Dec 2000 06:08:38 -0800
Received: from relay.dera.gov.uk ([192.5.29.49]:26408 "HELO relay.dera.gov.uk")
	by oss.sgi.com with SMTP id <S553752AbQLDOIR>;
	Mon, 4 Dec 2000 06:08:17 -0800
Received: (qmail 10837 invoked from network); 4 Dec 2000 14:08:14 +0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by relay.dera.gov.uk with SMTP; 4 Dec 2000 14:08:14 +0000
Content-Length: 1787
Message-ID: <XFMail.20001204140814.gale@syntax.dera.gov.uk>
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3A28A221.37A42167@thebarn.com>
Date:   Mon, 04 Dec 2000 14:08:14 -0000 (GMT)
From:   Tony Gale <gale@syntax.dera.gov.uk>
To:     Russell Cattelan <cattelan@thebarn.com>
Subject: Re: ADD 804570 - The elevator bug
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


This may account for my test xfs news server not surviving for more
than a week. But, the filesystem pretty much goes unrecoverable after
I am forced to reset the box:

kmem_alloc doing a vmalloc 241488 size & PAGE_SIZE 0 rval=0xf8829000
Start mounting filesystem: sd(8,17)
Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17)
cmn_err level 1 Filesystem "sd(8,17)": xfs_inode_recover: Bad inode
log record, rec ptr 0xf5165fc0, dino ptr 0xf5091d00, dino bp
0xe2cb73c0, ino 121654813, total extents = -4746, nblocks = 16
XFS: log mount/recovery failed
XFS: log mount failed
Size 241488 doing a vfree 0xf8829000

Now xfs_check is spewing countless (with the block number increasing):

block 2/195770000 out of range

-tony




On 02-Dec-2000 Russell Cattelan wrote:
> 
> Yes this is a know problem in the latest 2.4 kernels.
> It has been observed on other file  systems as well not just XFS.
> 
> I have do have a kernel with Jens elevator patch, that does
> appear to fix the starvation problem. Unfortunately it appears to
> either
> have problems itself or is exposing  problems in the XFS code.
> 
> Currently XFS kiobuf based io causes a lockup that eventually cause
> the
> kernel to through an NMI.
> 
> Non kiobuf io causes pagebuf to panic under heavy load.
> 
> I got this running late friday and haven't had much
> of a chance to investigate.
> 
> Since this is a linux bug we are  waiting for the official
> fix to show up in the linux tree.
> 
> --
> Russell Cattelan
> cattelan@thebarn.com

---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
I cannot draw a cart, nor eat dried oats; If it be man's work I will do it.

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.

From owner-linux-xfs@oss.sgi.com Mon Dec  4 10:08:49 2000
Received:  by oss.sgi.com id <S554018AbQLDSIj>;
	Mon, 4 Dec 2000 10:08:39 -0800
Received: from pC19F75C0.dip.t-dialin.net ([193.159.117.192]:16275 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S554015AbQLDSI1>; Mon, 4 Dec 2000 10:08:27 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB4IMqq09779;
	Mon, 4 Dec 2000 19:22:52 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Mon, 4 Dec 2000 19:22:52 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Tony Gale <gale@syntax.dera.gov.uk>
Cc:     Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: ADD 804570 - The elevator bug
Message-ID: <20001204192252.A9697@s2y4n2c.de>
References: <3A28A221.37A42167@thebarn.com> <XFMail.20001204140814.gale@syntax.dera.gov.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <XFMail.20001204140814.gale@syntax.dera.gov.uk>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hello

sounds like the recovery bug i found last week.

try a older kernel version. from november, 14th should work.
the beta kernel (test5 based) should work too.
or try following patch.
the latest cvs version still have the bug, i just checkt it.


utz

-----------------------------------------------------------------------

Date: Fri, 01 Dec 2000 19:12:03 -0800
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
To: utz lehmann <xfs@s2y4n2c.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: kernelcrash during root filesystem recovery

utz lehmann wrote:
> 
> ok, here is the backtrace (via serial console):
	[ ... ]
> 
> Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
> kernel BUG at slab.c:1542!
> 
	[ ... ]
> 
> what should i do next?

First, the immediate BUG() is due to a bogus sized
kmalloc being requested.

Second, I've been seeing problems here with recovery;
so far I thought it was a bug in code that I've been
working on. But looking at your backtrace may be something
else is broken.

Looking through some recent changes, I think a bcopy
was accidentally deleted. In file fs/xfs/xfs_log_recover.c,
AFTER the kmem_realloc( ... ) at line 1218, can you ADD:

         bcopy(dp , &ptr[old_len], len);                 /* s, d, l */

Can you please recompile & retry recovery?

Thanks for your efforts in providing debug information!

ananth.

PS: Daniel, revision 1.195 is where the bcopy was taken out.
    It appears to be an error. Can you please check?

-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------



Tony Gale [gale@syntax.dera.gov.uk] wrote:
> 
> This may account for my test xfs news server not surviving for more
> than a week. But, the filesystem pretty much goes unrecoverable after
> I am forced to reset the box:
> 
> kmem_alloc doing a vmalloc 241488 size & PAGE_SIZE 0 rval=0xf8829000
> Start mounting filesystem: sd(8,17)
> Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17)
> cmn_err level 1 Filesystem "sd(8,17)": xfs_inode_recover: Bad inode
> log record, rec ptr 0xf5165fc0, dino ptr 0xf5091d00, dino bp
> 0xe2cb73c0, ino 121654813, total extents = -4746, nblocks = 16
> XFS: log mount/recovery failed
> XFS: log mount failed
> Size 241488 doing a vfree 0xf8829000
> 
> Now xfs_check is spewing countless (with the block number increasing):
> 
> block 2/195770000 out of range
> 
> -tony
> 
> 
> 
> 
> On 02-Dec-2000 Russell Cattelan wrote:
> > 
> > Yes this is a know problem in the latest 2.4 kernels.
> > It has been observed on other file  systems as well not just XFS.
> > 
> > I have do have a kernel with Jens elevator patch, that does
> > appear to fix the starvation problem. Unfortunately it appears to
> > either
> > have problems itself or is exposing  problems in the XFS code.
> > 
> > Currently XFS kiobuf based io causes a lockup that eventually cause
> > the
> > kernel to through an NMI.
> > 
> > Non kiobuf io causes pagebuf to panic under heavy load.
> > 
> > I got this running late friday and haven't had much
> > of a chance to investigate.
> > 
> > Since this is a linux bug we are  waiting for the official
> > fix to show up in the linux tree.
> > 
> > --
> > Russell Cattelan
> > cattelan@thebarn.com
> 
> ---
> E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
> I cannot draw a cart, nor eat dried oats; If it be man's work I will do it.
> 
> The views expressed above are entirely those of the writer
> and do not represent the views, policy or understanding of
> any other person or official body.

From owner-linux-xfs@oss.sgi.com Mon Dec  4 10:10:09 2000
Received:  by oss.sgi.com id <S554020AbQLDSJ7>;
	Mon, 4 Dec 2000 10:09:59 -0800
Received: from pC19F75C0.dip.t-dialin.net ([193.159.117.192]:16531 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S554017AbQLDSJn>; Mon, 4 Dec 2000 10:09:43 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB4IPq809812
	for linux-xfs@oss.sgi.com; Mon, 4 Dec 2000 19:25:52 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Mon, 4 Dec 2000 19:25:52 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     linux-xfs@oss.sgi.com
Subject: recovery bug still exist!!!
Message-ID: <20001204192552.B9697@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hello

i just checked the lastest cvs source (non beta tree).
the recovery bug still exist.


utz

From owner-linux-xfs@oss.sgi.com Mon Dec  4 12:27:53 2000
Received:  by oss.sgi.com id <S553744AbQLDU1n>;
	Mon, 4 Dec 2000 12:27:43 -0800
Received: from hermes.mixx.net ([212.84.196.2]:22796 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553691AbQLDU1W>;
	Mon, 4 Dec 2000 12:27:22 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 1185AF812
	for <linux-xfs@oss.sgi.com>; Mon,  4 Dec 2000 21:27:20 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 93C012CAA3; Mon,  4 Dec 2000 21:27:19 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: immutable etc.
Date:   4 Dec 2000 20:27:19 GMT
Organization: innominate AG, Berlin, Germany
Lines:  14
Distribution: local
Message-ID: <news2mail-90gun7$srf$2@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.de
X-Trace: mate.bln.innominate.de 975961639 29551 10.0.0.31 (4 Dec 2000 20:27:19 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

just a little question: is there anything like the immutable and
append only flags of ext2 (and for instance FFS in BSD) in XFS
too - maybe somehow realized via extended attributes or in
any other way?

a lot of thanks in advance

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Dec  4 12:31:33 2000
Received:  by oss.sgi.com id <S553800AbQLDUbX>;
	Mon, 4 Dec 2000 12:31:23 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:5216 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553720AbQLDUbM>;
	Mon, 4 Dec 2000 12:31:12 -0800
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA05850
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 12:31:12 -0800 (PST)
	mail_from (raa@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA29856 for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 14:29:56 -0600 (CST)
Received: from ioperf.americas.sgi.com (ioperf.americas.sgi.com [128.162.184.23]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA11996; Mon, 4 Dec 2000 14:28:37 -0600 (CST)
From:   "Bob Albers Jr." <raa@sgi.com>
Received: by ioperf.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id OAA53861; Mon, 4 Dec 2000 14:28:39 -0600 (CST)
Message-Id: <200012042028.OAA53861@ioperf.americas.sgi.com>
Date:   Mon, 4 Dec 2000 14:28:39 -0600 (CST)
To:     nb@sgi.com, sgi.bugs.xfs@fido.engr.sgi.com
Subject: Re:  ADD 804570 - The elevator bug
Cc:     linux-xfs@oss.sgi.com, alaffin@sgi.com, rrl@sgi.com, tbd@sgi.com,
        mann@sgi.com, cattelan@sgi.com, huovinen@sgi.com, raa@sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


> This is is a system hang problem that sounds fairly serious.
> However, it looks like it is only related to the xfs filesystem.
> I sent e-mail to the case owner (nb@sgi whoever that is) and 
> offered help.  If we can help with this I will try to get 
> Sean on it.

Actually, I own it now since Neil passed XFS Linux management on to me.
There's been a potential fix generated for this problem.  There also may be
some code tweaking that can be done to avoid this.

I've attached Steve Lord's e-mail on the subject.

Bob


From owner-slinx-xfs@cthulhu.engr.sgi.com  Tue Nov 21 04:14:08 2000
To: slinx-xfs@engr.sgi.com
Subject: I wonder if this is the elevator bug we have seen?
Date: Tue, 21 Nov 2000 04:06:51 -0600
From: Steve Lord <lord@sgi.com>


Anyone want to give Corey a kernel with this in it?

Steve


------- Forwarded Message

Date:    Tue, 21 Nov 2000 17:38:44 +0900
From:    kumon@flab.fujitsu.co.jp
To:      linux-kernel@vger.kernel.org
cc:      Dave Jones <davej@suse.de>, Andrea Arcangeli <andrea@suse.de>,
	 Jens Axboe <axboe@suse.de>,
	 kumon@flab.fujitsu.co.jp
Subject: [PATCH] livelock in elevator scheduling

The current elevator_linus() doesn't obey the true elevator
scheduling, and causes I/O livelock during frequent random write
traffics. In such environment I/O (read/write) transactions may be
delayed almost infinitely (more than 1 hour).

Problem:
 Current elevator_linus() traverses the I/O requesting queue from the
tail to top. And when the current request has smaller sector number
than the request on the top of queue, it is always placed just after
the top.
 This means, if requests in some sector range are continuously
generated, a request with larger sector number is always places at the
last and has no chance to go to the front.  e.g. it is not scheduled.

 This is not hypothetical but actually observed.  Running a random
disk write benchmark can completely supress other disk I/O by this
reason.


 The following patch fixes this problem. It still doesn't follow a
strict elevator scheduling, but it does much better.  Additionally, it
may be better to add extra priority to reads than writes to obtain
better response, but this patch doesn't.

diff -ru linux-2.4.0-test11-pre2/drivers/block/elevator.c linux-2.4.0-test11-pr
e2-test5/drivers/block/elevator.c
- --- linux-2.4.0-test11-pre2/drivers/block/elevator.c	Wed Aug 23 14:33:46 200
0
+++ linux-2.4.0-test11-pre2-test5/drivers/block/elevator.c	Tue Nov 21 15:3
2:01 2000
@@ -47,6 +47,11 @@
 			break;
 		tmp->elevator_sequence--;
 	}
+	if (entry == head) {
+		tmp = blkdev_entry_to_request(entry);
+		if (IN_ORDER(req, tmp))
+			entry = real_head->prev;
+	}
 	list_add(&req->queue, entry);
 }
 

To implement a complete elevator scheduling, preparing an alternate
waiting queue is better, I think.

- --
Computer Systems Laboratory, Fujitsu Labs.
kumon@flab.fujitsu.co.jp
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/


------- End of Forwarded Message


From owner-linux-xfs@oss.sgi.com Mon Dec  4 12:34:53 2000
Received:  by oss.sgi.com id <S553813AbQLDUed>;
	Mon, 4 Dec 2000 12:34:33 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:865 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553799AbQLDUe2>;
	Mon, 4 Dec 2000 12:34:28 -0800
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA06313; Mon, 4 Dec 2000 12:34:28 -0800 (PST)
	mail_from (pv@feature.engr.sgi.com)
Received: from feature.engr.sgi.com (gate-feature.engr.sgi.com [130.62.42.134]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA88243; Mon, 4 Dec 2000 12:32:42 -0800 (PST)
Received: (from pv@localhost) by feature.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA07647; Mon, 4 Dec 2000 12:30:05 -0800 (PST)
Date:   Mon, 4 Dec 2000 12:30:05 -0800 (PST)
Message-Id: <200012042030.MAA07647@feature.engr.sgi.com>
X-Pv-Incident: 804570 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@fddi-odin.corp.sgi.com (raa@sgi.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com,
        tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

 Submitter : coreym                    Status : open                        
 Assigned Engineer : nb                Priority : 3                         
*Modified Date : 12/04/00             *Modified User : raa                  
*Modified User Domain : sgi.com       *Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: "bob albers jr." <raa@sgi.com>
Date: Dec 04 2000 12:30:04PM
[pvnews version: 1.71]
==========================

> This is is a system hang problem that sounds fairly serious.
> However, it looks like it is only related to the xfs filesystem.
> I sent e-mail to the case owner (nb@sgi whoever that is) and 
> offered help.  If we can help with this I will try to get 
> Sean on it.

Actually, I own it now since Neil passed XFS Linux management on to me.
There's been a potential fix generated for this problem.  There also may be
some code tweaking that can be done to avoid this.

I've attached Steve Lord's e-mail on the subject.

Bob


>From owner-slinx-xfs@cthulhu.engr.sgi.com  Tue Nov 21 04:14:08 2000
To: slinx-xfs@engr.sgi.com
Subject: I wonder if this is the elevator bug we have seen?
Date: Tue, 21 Nov 2000 04:06:51 -0600
From: Steve Lord <lord@sgi.com>


Anyone want to give Corey a kernel with this in it?

Steve


------- Forwarded Message

Date:    Tue, 21 Nov 2000 17:38:44 +0900
From:    kumon@flab.fujitsu.co.jp
To:      linux-kernel@vger.kernel.org
cc:      Dave Jones <davej@suse.de>, Andrea Arcangeli <andrea@suse.de>,
	 Jens Axboe <axboe@suse.de>,
	 kumon@flab.fujitsu.co.jp
Subject: [PATCH] livelock in elevator scheduling

The current elevator_linus() doesn't obey the true elevator
scheduling, and causes I/O livelock during frequent random write
traffics. In such environment I/O (read/write) transactions may be
delayed almost infinitely (more than 1 hour).

Problem:
 Current elevator_linus() traverses the I/O requesting queue from the
tail to top. And when the current request has smaller sector number
than the request on the top of queue, it is always placed just after
the top.
 This means, if requests in some sector range are continuously
generated, a request with larger sector number is always places at the
last and has no chance to go to the front.  e.g. it is not scheduled.

 This is not hypothetical but actually observed.  Running a random
disk write benchmark can completely supress other disk I/O by this
reason.


 The following patch fixes this problem. It still doesn't follow a
strict elevator scheduling, but it does much better.  Additionally, it
may be better to add extra priority to reads than writes to obtain
better response, but this patch doesn't.

diff -ru linux-2.4.0-test11-pre2/drivers/block/elevator.c linux-2.4.0-test11-pr
e2-test5/drivers/block/elevator.c
- --- linux-2.4.0-test11-pre2/drivers/block/elevator.c	Wed Aug 23 14:33:46 200
0
+++ linux-2.4.0-test11-pre2-test5/drivers/block/elevator.c	Tue Nov 21 15:3
2:01 2000
@@ -47,6 +47,11 @@
 			break;
 		tmp->elevator_sequence--;
 	}
+	if (entry == head) {
+		tmp = blkdev_entry_to_request(entry);
+		if (IN_ORDER(req, tmp))
+			entry = real_head->prev;
+	}
 	list_add(&req->queue, entry);
 }
 

To implement a complete elevator scheduling, preparing an alternate
waiting queue is better, I think.

- --
Computer Systems Laboratory, Fujitsu Labs.
kumon@flab.fujitsu.co.jp
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/


------- End of Forwarded Message

From owner-linux-xfs@oss.sgi.com Mon Dec  4 12:39:22 2000
Received:  by oss.sgi.com id <S553817AbQLDUjD>;
	Mon, 4 Dec 2000 12:39:03 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:33378 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553809AbQLDUiw>;
	Mon, 4 Dec 2000 12:38:52 -0800
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA07099
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 12:38:50 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA36040; Mon, 4 Dec 2000 14:37:33 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA80032; Mon, 4 Dec 2000 14:36:17 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB4KaHj17646;
	Mon, 4 Dec 2000 14:36:17 -0600
Message-ID: <3A2C003F.B40D640B@thebarn.com>
Date:   Mon, 04 Dec 2000 14:36:16 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tony Gale <gale@syntax.dera.gov.uk>
CC:     linux-xfs@oss.sgi.com
Subject: Re: ADD 804570 - The elevator bug
References: <XFMail.20001204140814.gale@syntax.dera.gov.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Tony Gale wrote:

> This may account for my test xfs news server not surviving for more
> than a week.

hmm I doubt it... the problem in the elevator right now is a starvation
issue. I hasn't linked to crashes or corruption (yet), just very very long
waits to service
some disk requests.


> But, the filesystem pretty much goes unrecoverable after
> I am forced to reset the box:

This could be related to other issues.
First exactly what version of the XFS tree are you running?
If you are running anything less than current (as of today)
or the XFS_BETA_4 image, please upgrade immediately.

There was a corruption problem in all previous version.
Symptoms of the corruption does sound similar to what
you are describing.

At this point you will need to run xfs_repair to get your
file system back, if repair fails let us know hopefully we
can fix whatever went wrong.



>
> kmem_alloc doing a vmalloc 241488 size & PAGE_SIZE 0 rval=0xf8829000
> Start mounting filesystem: sd(8,17)
> Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17)
> cmn_err level 1 Filesystem "sd(8,17)": xfs_inode_recover: Bad inode
> log record, rec ptr 0xf5165fc0, dino ptr 0xf5091d00, dino bp
> 0xe2cb73c0, ino 121654813, total extents = -4746, nblocks = 16
> XFS: log mount/recovery failed
> XFS: log mount failed
> Size 241488 doing a vfree 0xf8829000
>
> Now xfs_check is spewing countless (with the block number increasing):
>
> block 2/195770000 out of range
>
> -tony
>
> On 02-Dec-2000 Russell Cattelan wrote:
> >
> > Yes this is a know problem in the latest 2.4 kernels.
> > It has been observed on other file  systems as well not just XFS.
> >
> > I have do have a kernel with Jens elevator patch, that does
> > appear to fix the starvation problem. Unfortunately it appears to
> > either
> > have problems itself or is exposing  problems in the XFS code.
> >
> > Currently XFS kiobuf based io causes a lockup that eventually cause
> > the
> > kernel to through an NMI.
> >
> > Non kiobuf io causes pagebuf to panic under heavy load.
> >
> > I got this running late friday and haven't had much
> > of a chance to investigate.
> >
> > Since this is a linux bug we are  waiting for the official
> > fix to show up in the linux tree.
> >
> > --
> > Russell Cattelan
> > cattelan@thebarn.com
>
> ---
> E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
> I cannot draw a cart, nor eat dried oats; If it be man's work I will do it.
>
> The views expressed above are entirely those of the writer
> and do not represent the views, policy or understanding of
> any other person or official body.


From owner-linux-xfs@oss.sgi.com Mon Dec  4 13:02:12 2000
Received:  by oss.sgi.com id <S553823AbQLDVBx>;
	Mon, 4 Dec 2000 13:01:53 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:38250 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553814AbQLDVBj>;
	Mon, 4 Dec 2000 13:01:39 -0800
Received: from hops.chicago.sgi.com (hops.chicago.sgi.com [169.238.235.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA11391
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 13:01:38 -0800 (PST)
	mail_from (gquinn@guinness.chicago.sgi.com)
Received: from guinness.chicago.sgi.com (guinness.chicago.sgi.com [169.238.235.131]) by hops.chicago.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA56654 for <@hops.chicago.sgi.com:linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 15:00:22 -0600 (CST)
Received: from localhost (gquinn@localhost) by guinness.chicago.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA25871 for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 15:00:21 -0600 (CST)
Date:   Mon, 4 Dec 2000 15:00:21 -0600
From:   Gerry Quinn <gquinn@guinness.chicago.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: problem with beta checkout
Message-ID: <Pine.SGI.4.05.10012041455510.807097-100000@guinness.chicago.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Anybody have an idea what is causing this...or am I doing it wrong?

cvs -z3 checkout linux-2.4-xfs-beta
		.
		.
		.
cvs server: Updating linux-2.4-xfs-beta/cmd/xfs/copy
U linux-2.4-xfs-beta/cmd/xfs/copy/Makefile
U linux-2.4-xfs-beta/cmd/xfs/copy/locks.c
U linux-2.4-xfs-beta/cmd/xfs/copy/locks.h
cvs [server aborted]: EOF in value in RCS file /cvs/linux-2.4-xfs-beta/cmd/xfs/copy/xfs_copy.c,v

Thanks.

................................................
. Gerry Quinn                                  .
. sgi                                          .
. Chicago Branch Office - Schaumburg, Illinois .
. 847-925-2941; vnet 625-2941; pag 888-398-9044.
. gquinn@chicago.sgi.com                       .
................................................

"I'll put up with all the bulls%$&, but as 
soon as they stop paying me, I'm out-a-here!"


From owner-linux-xfs@oss.sgi.com Mon Dec  4 13:53:43 2000
Received:  by oss.sgi.com id <S553829AbQLDVxX>;
	Mon, 4 Dec 2000 13:53:23 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:33918 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553825AbQLDVxR>;
	Mon, 4 Dec 2000 13:53:17 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id NAA21536
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 13:53:15 -0800 (PST)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA11253 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 08:50:43 +1100
Received: from localhost (dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id IAA02300 for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 08:50:41 +1100 (EST)
Message-Id: <200012042150.IAA02300@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To:     linux-xfs@oss.sgi.com
Subject: Heads Up: recovery bug (fixed)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 05 Dec 2000 08:50:41 +1100
From:   Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


utz lehmann writes:
 => hello
 => 
 => i just checked the lastest cvs source (non beta tree).
 => the recovery bug still exist.

For the record, I fixed the reported bug in xfs_log_recover.c
yesterday. The new version is 1.198, 2000/12/03 22:08:19.

If you're using an XFS development kernel please make sure you
rebuild with this change in your kernel.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Mon Dec  4 14:34:13 2000
Received:  by oss.sgi.com id <S553687AbQLDWdy>;
	Mon, 4 Dec 2000 14:33:54 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29553 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553650AbQLDWdf>; Mon, 4 Dec 2000 14:33:35 -0800
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA04167
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 14:41:42 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA50685; Mon, 4 Dec 2000 16:32:18 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA72015; Mon, 4 Dec 2000 16:31:01 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB4MV1j19581;
	Mon, 4 Dec 2000 16:31:01 -0600
Message-ID: <3A2C1B24.64ACB386@thebarn.com>
Date:   Mon, 04 Dec 2000 16:31:00 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Gerry Quinn <gquinn@guinness.chicago.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: problem with beta checkout
References: <Pine.SGI.4.05.10012041455510.807097-100000@guinness.chicago.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Gerry Quinn wrote:

> Anybody have an idea what is causing this...or am I doing it wrong?

I deleted everything and let the process  refresh the tree from scratch.

Should be good to go now.

>
>
> cvs -z3 checkout linux-2.4-xfs-beta
>                 .
>                 .
>                 .
> cvs server: Updating linux-2.4-xfs-beta/cmd/xfs/copy
> U linux-2.4-xfs-beta/cmd/xfs/copy/Makefile
> U linux-2.4-xfs-beta/cmd/xfs/copy/locks.c
> U linux-2.4-xfs-beta/cmd/xfs/copy/locks.h
> cvs [server aborted]: EOF in value in RCS file /cvs/linux-2.4-xfs-beta/cmd/xfs/copy/xfs_copy.c,v
>
> Thanks.
>
> ................................................
> . Gerry Quinn                                  .
> . sgi                                          .
> . Chicago Branch Office - Schaumburg, Illinois .
> . 847-925-2941; vnet 625-2941; pag 888-398-9044.
> . gquinn@chicago.sgi.com                       .
> ................................................
>
> "I'll put up with all the bulls%$&, but as
> soon as they stop paying me, I'm out-a-here!"


From owner-linux-xfs@oss.sgi.com Mon Dec  4 14:58:33 2000
Received:  by oss.sgi.com id <S553832AbQLDW6X>;
	Mon, 4 Dec 2000 14:58:23 -0800
Received: from mcomail02.maxtor.com ([134.6.76.16]:37893 "HELO
        mcomail02.maxtor.com") by oss.sgi.com with SMTP id <S553733AbQLDW5z>;
	Mon, 4 Dec 2000 14:57:55 -0800
Received: from 134.6.67.21 by mcomail02.maxtor.com (InterScan E-Mail VirusWall NT); Mon, 04 Dec 2000 15:56:14 -0700 (Mountain Standard Time)
Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21)
	id <XC6W8S9K>; Mon, 4 Dec 2000 15:58:31 -0700
Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C0253704F@mcaexc01.msj.maxtor.com>
From:   "Davida, Joe" <Joe_Davida@Maxtor.com>
To:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: kioclusters
Date:   Mon, 4 Dec 2000 15:58:05 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

You say you have seen performance problems with non-sequential
localized writes using the kiocluster option on mounts.
Is the performance problem bad enough so that it is worse
than ext2fs?

Joe

From owner-linux-xfs@oss.sgi.com Mon Dec  4 16:11:22 2000
Received:  by oss.sgi.com id <S553847AbQLEALM>;
	Mon, 4 Dec 2000 16:11:12 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3194 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553844AbQLEAFx>; Mon, 4 Dec 2000 16:05:53 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00716
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 16:13:58 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA03956
	for linux-xfs@oss.sgi.com; Tue, 5 Dec 2000 11:03:15 +1100 (EST)
Date:   Tue, 5 Dec 2000 11:03:15 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012050003.LAA03956@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - logprint
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:79904a
Date:  Mon Dec  4 16:03:02 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/logprint/log_misc.c - 1.75
	- correctly display dquot structure when processing a log buffer.

cmd/xfs/logprint/log_print_all.c - 1.6
	- minor tidyups.


From owner-linux-xfs@oss.sgi.com Mon Dec  4 16:31:53 2000
Received:  by oss.sgi.com id <S553850AbQLEAbn>;
	Mon, 4 Dec 2000 16:31:43 -0800
Received: from p3EE0567F.dip.t-dialin.net ([62.224.86.127]:54165 "EHLO
        kernelpanix.aura.of.mankind") by oss.sgi.com with ESMTP
	id <S553846AbQLEAbQ>; Mon, 4 Dec 2000 16:31:16 -0800
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id eB50lRR12920;
	Tue, 5 Dec 2000 01:47:27 +0100
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date:   Tue, 5 Dec 2000 01:47:27 +0100
From:   utz lehmann <xfs@s2y4n2c.de>
To:     Daniel Moore <dxm@clouds.melbourne.sgi.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Heads Up: recovery bug (fixed)
Message-ID: <20001205014727.A12899@s2y4n2c.de>
References: <200012042150.IAA02300@clouds.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200012042150.IAA02300@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi

for your information.
i compiled a new kernel. now recovery works again.

thanks.

utz

Daniel Moore [dxm@clouds.melbourne.sgi.com] wrote:
> 
> utz lehmann writes:
>  => hello
>  => 
>  => i just checked the lastest cvs source (non beta tree).
>  => the recovery bug still exist.
> 
> For the record, I fixed the reported bug in xfs_log_recover.c
> yesterday. The new version is 1.198, 2000/12/03 22:08:19.
> 
> If you're using an XFS development kernel please make sure you
> rebuild with this change in your kernel.
> 
> -----------------------------------------------------
>  Daniel Moore                  dxm@sgi.com
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon Dec  4 16:32:54 2000
Received:  by oss.sgi.com id <S553902AbQLEAcd>;
	Mon, 4 Dec 2000 16:32:33 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:42502 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553849AbQLEAc3>; Mon, 4 Dec 2000 16:32:29 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id WAA17989;
	Mon, 4 Dec 2000 22:32:16 -0200
Date:   Mon, 4 Dec 2000 20:37:24 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     "Davida, Joe" <Joe_Davida@Maxtor.com>
cc:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: kioclusters
In-Reply-To: <09D1E9BD9C30D311919200A0C9DD5C2C0253704F@mcaexc01.msj.maxtor.com>
Message-ID: <Pine.LNX.4.21.0012042030140.15821-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Mon, 4 Dec 2000, Davida, Joe wrote:

> You say you have seen performance problems with non-sequential
> localized writes using the kiocluster option on mounts.
> Is the performance problem bad enough so that it is worse
> than ext2fs?

Its probably worse than ext2.

The reason for that is because the prototype kiobuf IO layer which we are
using does not try aggregate any requests to avoid seek times while the
buffer_head IO does that.

We definately need merging of kiobuf IO in Linux 2.5. 


From owner-linux-xfs@oss.sgi.com Mon Dec  4 16:57:04 2000
Received:  by oss.sgi.com id <S553924AbQLEA4z>;
	Mon, 4 Dec 2000 16:56:55 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:42053 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553853AbQLEA4m>;
	Mon, 4 Dec 2000 16:56:42 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA26928
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 16:56:41 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA03275; Mon, 4 Dec 2000 16:49:58 -0800 (PST)
Message-ID: <3A2C3C84.1A142B30@sgi.com>
Date:   Mon, 04 Dec 2000 16:53:24 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Davida, Joe" <Joe_Davida@Maxtor.com>
CC:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: kioclusters
References: <09D1E9BD9C30D311919200A0C9DD5C2C0253704F@mcaexc01.msj.maxtor.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Davida, Joe" wrote:
> 
> You say you have seen performance problems with non-sequential
> localized writes using the kiocluster option on mounts.
> Is the performance problem bad enough so that it is worse
> than ext2fs?
> 
> Joe


Performance difference really depends on what is being run.
We have noticed that for dbench with small number of clients,
xfs+kiocluter does worse than ext2 ... but for dbench with
larger number of clients xfs+kiocluster does better than ext2.

I've been working on a patch which in my tests with dbench
has improved xfs+kiocluster significantly. If you are working
with a test system, can you please try the following patch
(in conjuction with the kiocluster option)? The patch is against
the latest development xfs tree ...


----------------- patch begins -------------------------------
diff -Naur ../../xfs-tot/linux/fs/pagebuf/page_buf.c ./fs/pagebuf/page_buf.c
--- ../../xfs-tot/linux/fs/pagebuf/page_buf.c   Tue Nov 28 16:34:17 2000
+++ ./fs/pagebuf/page_buf.c     Thu Nov 30 10:29:39 2000
@@ -186,7 +186,7 @@
 unsigned long pagebuf_min[P_PARAM] = { HZ/2, 1*HZ, HZ/2, 1, 0, 0 };
 unsigned long pagebuf_max[P_PARAM] = { HZ*30, HZ*300, HZ*30, 1024, 4096, 1 };
 
-pagebuf_param_t pb_params = {{ HZ, 15 * HZ, HZ, 512, 1024, 0 }};
+pagebuf_param_t pb_params = {{ HZ, 15 * HZ, 2*HZ, 512, 1024, 0 }};
 
 /*
  * Pagebuf statistics variables
@@ -595,7 +595,11 @@
                        kp->maplist[pi] = cp;
                } else {
                        cp = kp->maplist[pi];
-                       set_bit(PG_referenced, &cp->flags);
+                       /*
+                        * Don't set referenced bit;
+                        * we may consider age_page_up.
+                       //set_bit(PG_referenced, &cp->flags);
+                        */
                        while (TryLockPage(cp)) {
                                wait_on_page(cp);
                        }
@@ -1345,7 +1349,7 @@
        struct buffer_head *bh;
        off_t blk_offset;
        size_t blk_length;
-       int err=0;
+       int err=0, need_balance_dirty = 0;
        int force_io = (rw != READ) || (pb->pb_flags & PBF_FORCEIO);
        int concat_ok = ((MAJOR(dev) != LVM_BLK_MAJOR) || (MAJOR(dev) != MD_MAJOR));
 
@@ -1425,7 +1429,9 @@
 
                        if (rw == WRITE ) {
                                set_bit(BH_Uptodate, &bh->b_state);
-                               set_bit(BH_Dirty, &bh->b_state);
+                               if (!buffer_dirty(bh))
+                                       need_balance_dirty = 1;
+                               __mark_buffer_dirty(bh);
                        }
                        psync->bh[cnt++] = bh;
                        atomic_inc(&psync->remain);
@@ -1444,7 +1450,8 @@
                if (locking)
                        UnlockPage(page);
        }
-
+       if (need_balance_dirty)
+               balance_dirty(dev);
        return err;
 error:
        /* If we ever do get here then clean up what we already did */
diff -Naur ../../xfs-tot/linux/fs/pagebuf/page_buf_io.c ./fs/pagebuf/page_buf_io.c
--- ../../xfs-tot/linux/fs/pagebuf/page_buf_io.c        Tue Nov 28 16:34:17 2000
+++ ./fs/pagebuf/page_buf_io.c  Fri Dec  1 10:31:28 2000
@@ -93,11 +93,11 @@
 /*
  * Forward declarations.
  */
-STATIC void __pb_block_commit_write_async(struct inode *,
+STATIC int __pb_block_commit_write_async(struct inode *,
                struct page *, page_buf_bmap_t *);
 STATIC int __pb_block_prepare_write_async(struct inode *, struct page *,
                unsigned, unsigned, int, page_buf_bmap_t *, int);
-STATIC int pagebuf_delalloc_convert(struct page *, u_long, struct page **);
+STATIC int pagebuf_delalloc_convert(struct page *, u_long, struct page **, int, int);
 STATIC void hook_buffers_to_page(struct inode *, struct page *,
                page_buf_bmap_t *, ulong);
 
@@ -114,6 +114,20 @@
 int MAX_CLUSTER = 512;
 int CLUSTER_PAGE_LIST_SIZE = ((2*512)+1);
 
+/*
+ * stats
+ */
+struct pb_io_stat_s {
+       int pcd_normal_scan;
+       int pcd_normal_converted;
+
+       int pcd_skip_locked;
+       int pcd_skip_referenced;
+
+       int pcd_ilock_failed;
+} pb_io_stat = {0, 0, 0, 0, 0};
+
+EXPORT_SYMBOL(pb_io_stat);
 
 /*
  * The minimum size where we will start using pagebuf structures instead
@@ -210,10 +224,12 @@
 
        if (IS_KIOCLUSTER(ip)){
                /*
-                * If kmalloc, no big deal; the lower layers won't cluster.
+                * If kmalloc fails, no big deal; the lower layers won't
+                * cluster. Also, this allocation has to be non-sleeping
+                * since this can be in kswapd's path ...
                 */
                cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *),
-                                          GFP_KERNEL);
+                                          GFP_ATOMIC);
        } else {
                cpages = (struct page **)1; /* a boolean */
        }
@@ -235,7 +251,7 @@
 
                        lock_page(page);
                        if (test_and_clear_bit(PG_delalloc, &page->flags)) {
-                               pagebuf_delalloc_convert(page, 0, cpages);
+                               pagebuf_delalloc_convert(page, 0, cpages, 0, 0);
                        } else {
                                UnlockPage(page);
                        }
@@ -511,7 +527,8 @@
 int pagebuf_iozero(            /* zero contents of buffer      */
     page_buf_t * pb,           /* buffer to zero               */
     off_t boff,                        /* offset in buffer             */
-    size_t bsize)              /* size of data to zero           */
+    size_t bsize,              /* size of data to zero           */
+    int  *dirty)
 {
        loff_t cboff;
        size_t cpoff;
@@ -541,6 +558,7 @@
                if (pb->pb_bn == PAGE_BUF_DADDR_NULL) {
                        if (test_and_set_bit(PG_delalloc, &pm->flags) == 0) {
                                atomic_inc(&pb_delalloc_pages);
+                               (*dirty)++;
                        }
                }
        }
@@ -548,16 +566,6 @@
        pb->pb_flags &= ~(PBF_READ | PBF_WRITE);
        pb->pb_flags &= ~(_PBF_SOME_INVALID_PAGES | PBF_PARTIAL | PBF_NONE);
 
-       if (!pcd_active && (pb->pb_bn == PAGE_BUF_DADDR_NULL)) {
-               unsigned int    np = atomic_read(&pb_delalloc_pages);
-
-               if (np > 2 * pb_params.p_un.max_dirty_pages)
-                       wake_up_interruptible_sync(&pcd_waitq);
-               else if (np > pb_params.p_un.max_dirty_pages)
-                       wake_up_interruptible(&pcd_waitq);
-       }
-
-
        return (0);
 }
 
@@ -1174,62 +1182,6 @@
                        page, page->index, bh->b_blocknr));
 }
 
-
-void
-set_buffer_dirty_uptodate(struct buffer_head *bh)
-{
-       int need_balance_dirty = 0;
-
-       if (bh->b_blocknr <= 0) {
-               printk("Warning: buffer 0x%p with weird blockno (%ld)\n",
-                       bh, bh->b_blocknr);
-       }
-       set_bit(BH_Uptodate, &bh->b_state);
-       if (!buffer_dirty(bh)) {
-               bh->b_end_io = end_pb_buffer_io_async;
-               need_balance_dirty = 1;
-       }
-       __mark_buffer_dirty(bh);
-
-       if (need_balance_dirty)
-               balance_dirty(bh->b_dev);
-}
-
-int pbwcm_debug = 0;
-
-int
-__pb_write_or_convert_bmap(
-       struct inode *inode,
-       struct page *page)
-{
-       loff_t  offset = page->index << PAGE_CACHE_SHIFT;
-       int error, nmaps;
-       page_buf_bmap_t map;
-
-       error = inode->i_op->pagebuf_bmap(inode, offset, PAGE_CACHE_SIZE,
-                       &map, 1, &nmaps, PBF_WRITE);
-       if (error == 0 && (map.pbm_flags & PBMF_DELAY)) {
-               error = inode->i_op->pagebuf_bmap(inode, offset,
-                               map.pbm_bsize, &map, 1,
-                               &nmaps, PBF_WRITE|PBF_FILE_ALLOCATE);
-               if (error) {
-                       printk("pbwcm: bmap error %d ro 0x%Lx size 0x%x\n",
-                                  error, offset, map.pbm_bsize);
-               } else {
-                       dprintk(pbwcm_debug,
-                        ("converted bn:%Ld off:%Ld size:%d flags:%d\n",
-                            map.pbm_bn, map.pbm_offset,
-                            map.pbm_bsize, map.pbm_flags));
-               }
-       }
-       if (!error) {
-               hook_buffers_to_page(inode, page, &map, PAGE_CACHE_SHIFT);
-               set_buffer_dirty_uptodate(page->buffers);
-       }
-       return error;
-}
-
-
 STATIC int
 __pb_block_prepare_write_async(struct inode *inode, struct page *page,
                unsigned from, unsigned to, int at_eof,
@@ -1390,15 +1342,34 @@
 }
 
 int pbcw_debug = 0;
+
+int
+set_buffer_dirty_uptodate(struct buffer_head *bh)
+{
+       int need_balance_dirty = 0;
+
+       if (bh->b_blocknr <= 0) {
+               printk("Warning: buffer 0x%p with weird blockno (%ld)\n",
+                       bh, bh->b_blocknr);
+       }
+       set_bit(BH_Uptodate, &bh->b_state);
+       if (!buffer_dirty(bh)) {
+               bh->b_end_io = end_pb_buffer_io_async;
+               need_balance_dirty = 1;
+       }
+       __mark_buffer_dirty(bh);
+       return (need_balance_dirty);
+}
+
 int pbcw_debug2 = 0;
 
-STATIC void
+STATIC int
 __pb_block_commit_write_async(struct inode     *inode,
                                struct page     *page,
                                page_buf_bmap_t *mp)
 {
        struct buffer_head      *bh;
-       unsigned int            np;
+       int                     dirty = 0;
 
        /*
         * Prepare write took care of reading/zero-out
@@ -1412,32 +1383,20 @@
                if (test_bit(PG_delalloc, &page->flags)) {
                        dprintk(pbcw_debug2, ("mapped buffer 0x%p page 0x%p is delalloc\n", bh,
page));
                }
-               set_buffer_dirty_uptodate(page->buffers);
+               dirty = set_buffer_dirty_uptodate(page->buffers);
                dprintk(pbcw_debug, ("pbcw: refiled valid buffer 0x%p\n",
                        page->buffers));
        } else if (test_and_set_bit(PG_delalloc, &page->flags) == 0) {
                dprintk(pbcw_debug, ("Marking page 0x%p delalloc\n", page));
-               np = atomic_read(&pb_delalloc_pages);
-               if (np > PB_MAX_DIRTY_FACTOR * pb_params.p_un.max_dirty_pages) {
-                       clear_bit(PG_delalloc, &page->flags);
-                       if (__pb_write_or_convert_bmap(inode, page)) {
-                               BUG();
-                       }
-               } else {
-                       atomic_inc(&pb_delalloc_pages);
-                       if (!pcd_active) {
-                               if (np > 2 * pb_params.p_un.max_dirty_pages)
-                                       wake_up_interruptible_sync(&pcd_waitq);
-                               else if (np > pb_params.p_un.max_dirty_pages)
-                                       wake_up_interruptible(&pcd_waitq);
-                       }
-                       balance_dirty(inode->i_rdev);
-               }
+
+               atomic_inc(&pb_delalloc_pages);
+               dirty = 1;
        }
 
        /* Advance though extent no matter what */
        if (mp)
                mp->pbm_delta += PAGE_CACHE_SIZE;
+       return dirty;
 }
 
 int
@@ -1448,7 +1407,8 @@
        char            *user_addr,
        size_t          len,
        loff_t          *lp,
-       page_buf_bmap_t *mp)            /* bmap for page                     */
+       page_buf_bmap_t *mp,            /* bmap for page                     */
+       int             *dirty)
 {
        struct page *page;
        unsigned long done;
@@ -1507,7 +1467,7 @@
                        goto unlock;
                }
 
-               __pb_block_commit_write_async(inode, page, mp);
+               *dirty += __pb_block_commit_write_async(inode, page, mp);
 
                foff += bytes_in_page;
                len -= bytes_in_page;
@@ -1533,7 +1493,8 @@
        char *buf,              /* buffer address               */
        size_t len,             /* size of buffer               */
        loff_t * lp,            /* file offset to use and update */
-       int pb_flags)           /* flags to pass to bmap calls  */
+       int pb_flags,           /* flags to pass to bmap calls  */
+       int *dirty)
 {
        struct inode *inode = filp->f_dentry->d_inode;
        page_buf_bmap_t map;
@@ -1628,7 +1589,7 @@
                 */
                status = __pagebuf_do_delwri(inode,
                                rounded_offset, size, buf,
-                               len, &foff, &map);
+                               len, &foff, &map, dirty);
                if (status <= 0)
                        break;
                written += status;
@@ -1646,7 +1607,8 @@
     struct file * filp,                /* file to write                */
     char *buf,                 /* buffer address               */
     size_t len,                        /* size of buffer               */
-    loff_t * lp)               /* file offset to use and update */
+    loff_t * lp,               /* file offset to use and update */
+    int        *dirty)
 {
        struct inode *inode = filp->f_dentry->d_inode;
        unsigned long limit = current->rlim[RLIMIT_FSIZE].rlim_cur;
@@ -1711,7 +1673,7 @@
 
                if (!page) {
                        status = _pagebuf_file_write(filp,
-                                       buf, len, &foff, pb_flags);
+                                       buf, len, &foff, pb_flags, dirty);
                        if (status > 0)
                                written += status;
 
@@ -1748,7 +1710,7 @@
                        goto unlock;
                }
 
-               __pb_block_commit_write_async(inode, page, &map);
+               *dirty += __pb_block_commit_write_async(inode, page, &map);
 
                len -= bytes;
                buf += bytes;
@@ -1773,8 +1735,6 @@
 }
 
 int pcd_debug = 0;
-int pcd_skip_locked = 0;
-int pcd_ilock_failed = 0;
 static int page_cleaner_daemon_started = 0;
 static int daemon_terminate = 0;
 
@@ -1783,12 +1743,12 @@
  * Returns page locked and with an extra reference count.
  */
 STATIC struct page *
-probe_page(struct inode *inode, unsigned long index)
+probe_page(struct inode *inode, unsigned long index, int check)
 {
        struct page *page;
 
        page = __find_lock_page_nowait(inode->i_mapping, index,
-                               page_hash(inode->i_mapping, index));
+                               page_hash(inode->i_mapping, index), check);
        if (!page)
                return NULL;
        if (!test_and_clear_bit(PG_delalloc, &(page)->flags)) {
@@ -1820,26 +1780,33 @@
 kio_cluster_write(struct inode *inode,
              struct page  *startpage,
              page_buf_bmap_t *mp,
-             struct page **cpages)
+             struct page **cpages,
+             int np,
+             int check)
 {
        unsigned long   tindex, tlast;
        struct page     **pcp, **pcstart;
        loff_t          cstart_offset;
        page_buf_t      *pb;
        size_t          csize;
-       int             count = pb_params.p_un.max_cluster;
+       int             m, count = pb_params.p_un.max_cluster;
 
-       pcp = &cpages[MAX_CLUSTER]; /* start from the middle */
        dprintk(cluster_debug,
                ("cluster_write: inode 0x%p page 0x%p index 0x%lx\n",
                        inode, startpage, startpage->index));
+
+       if (np && count > np) /* obey limit if supplied */
+               count = np;
+       m = count >> 1;         /* start from middle */ 
+       pcp = &cpages[m];
        *pcp-- = startpage;
+       count--;
        if (startpage->index != 0) {
                tlast = mp->pbm_offset >> PAGE_CACHE_SHIFT;
                for (tindex = startpage->index-1; tindex >= tlast &&
                      pcp >= &cpages[0] && count; tindex--, pcp--, count--)
                {
-                       if (!(*pcp = probe_page(inode, tindex)))
+                       if (!(*pcp = probe_page(inode, tindex, check)))
                                break;
                        dprintk(cluster_debug,
                            ("cluster_write(L): inode 0x%p page 0x%p idx 0x%lx\n",
@@ -1849,11 +1816,11 @@
        pcstart = pcp+1;
        tlast = PAGE_CACHE_ALIGN_LL(mp->pbm_offset + mp->pbm_bsize) >>
                                                        PAGE_CACHE_SHIFT;
-       for (tindex = startpage->index + 1, pcp = &cpages[MAX_CLUSTER+1];
-               tindex < tlast && pcp < &cpages[CLUSTER_PAGE_LIST_SIZE] && count;
+       for (tindex = startpage->index + 1, pcp = &cpages[m+1];
+               tindex < tlast && pcp < &cpages[2*m] && count;
                tindex++, pcp++, count--)
        {
-               if (!(*pcp = probe_page(inode, tindex)))
+               if (!(*pcp = probe_page(inode, tindex, check)))
                        break;
                dprintk(cluster_debug,
                        ("cluster_write(R): inode 0x%p page 0x%p index 0x%lx\n",
@@ -1920,7 +1887,8 @@
 STATIC void
 cluster_write(struct inode *inode,
              unsigned long index,
-             page_buf_bmap_t *mp)
+             page_buf_bmap_t *mp,
+             int check)
 {
        unsigned long tindex;
        unsigned long tlast;
@@ -1930,7 +1898,7 @@
        if (index != 0) {
                tlast = mp->pbm_offset >> PAGE_CACHE_SHIFT;
                for (tindex = index-1; tindex >= tlast; tindex--) {
-                       if (!(page = probe_page(inode, tindex)))
+                       if (!(page = probe_page(inode, tindex, check)))
                                break;
                        convert_page(inode, page, mp);
                }
@@ -1938,13 +1906,12 @@
        tlast = PAGE_CACHE_ALIGN_LL(mp->pbm_offset + mp->pbm_bsize) >>
                                                        PAGE_CACHE_SHIFT;
        for (tindex = index + 1; tindex < tlast; tindex++) {
-               if (!(page = probe_page(inode, tindex)))
+               if (!(page = probe_page(inode, tindex, check)))
                        break;
                convert_page(inode, page, mp);
        }
 }
 
-
 int
 pagebuf_convert_page(struct page *page, int toss, int wait)
 {
@@ -1972,7 +1939,9 @@
 pagebuf_delalloc_convert(
        struct page *mm,        /* delalloc page to convert - locked */
        u_long  flags,          /* flags to pass to bmap call */
-       struct page **cpages)   /* can we cluster conversion? */ 
+       struct page **cpages,   /* can we cluster conversion? */ 
+       int np,                 /* n pages in cpages          */
+       int check)              /* check flush times          */
 {
        page_buf_bmap_t maps[PBF_MAX_MAPS];
        struct inode *inode;
@@ -1996,7 +1965,7 @@
 
        if (error) {
                if (error == -EAGAIN) {
-                       pcd_ilock_failed++;
+                       pb_io_stat.pcd_ilock_failed++;
                        set_bit(PG_delalloc, &mm->flags);
                 } else {
                        printk("PCD: pagebuf_bmap error %d pb_flags 0x%lx\n",
@@ -2020,13 +1989,13 @@
        if (cpages) {
                if (IS_KIOCLUSTER(inode)) {
                        get_page(mm);
-                       count = kio_cluster_write(inode, mm, &maps[0], cpages);
+                       count = kio_cluster_write(inode, mm, &maps[0], cpages, np, check);
                } else {
                        hook_buffers_to_page(inode, mm, &maps[0],
                                                        PAGE_CACHE_SHIFT);
                        set_buffer_dirty_uptodate(mm->buffers);
                        UnlockPage(mm);
-                       cluster_write(inode, mm->index, &maps[0]);
+                       cluster_write(inode, mm->index, &maps[0], check);
                        count = 1;
                }
 
@@ -2042,6 +2011,8 @@
 }
 
 int pcd_debug2 = 0;
+int sum_min = 0;
+EXPORT_SYMBOL(sum_min);
 
 STATIC int
 page_cleaner_daemon(void *data)
@@ -2049,9 +2020,8 @@
        mem_map_t *mm = &mem_map[0], *mmlast = &mem_map[max_mapnr];
        u_long flags;
        struct buffer_head *bh;
-       int     pb_min_save = PB_MIN_DIRTY_PAGES;
        struct page **cpages;
-       int     looped, sum;
+       int     looped, tsum, sum;
 
        /*  Set up the thread  */
        exit_files(current);
@@ -2074,7 +2044,6 @@
        cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * sizeof(struct page *),
                                GFP_KERNEL);
 
-       mm = &mem_map[0] - 1;
        while (1) {
                /*
                 * If we actually get into a low-memory situation,
@@ -2082,10 +2051,11 @@
                 * up on a more timely basis.
                 */
 
-               pcd_skip_locked = 0;
-               pcd_ilock_failed = 0;
+               pb_io_stat.pcd_skip_locked = pb_io_stat.pcd_skip_referenced = 0;
+               pb_io_stat.pcd_ilock_failed = 0;
                sum = looped = 0;
-               while (atomic_read(&pb_delalloc_pages) > PB_MIN_DIRTY_PAGES) {
+               mm = &mem_map[0] - 1;
+               while (1) {
                        if (current->need_resched)
                                schedule();
 
@@ -2101,8 +2071,12 @@
                        }
                        if (!test_bit(PG_delalloc, &(mm)->flags))
                                continue;
+                       if (mm->age >= PAGE_AGE_START && !looped) {
+                               pb_io_stat.pcd_skip_referenced++;
+                               continue;
+                       }
                        if (TryLockPage(mm)) {
-                               pcd_skip_locked++;
+                               pb_io_stat.pcd_skip_locked++;
                                continue;
                        }
                        if (!test_and_clear_bit(PG_delalloc, &(mm)->flags)) {
@@ -2129,16 +2103,20 @@
 /* since bmap can block, this should be in a different daemon       */
 /*---------------- DELALLOC CONVERT --------------------------------*/
 
-                       sum += pagebuf_delalloc_convert(mm,
-                               PBF_BMAP_TRY_ILOCK, cpages);
+                       tsum = pagebuf_delalloc_convert(mm,
+                               PBF_BMAP_TRY_ILOCK, cpages, 0, 0);
+
+                       pb_io_stat.pcd_normal_converted += tsum;
+                       sum += tsum;
 
                        /* Do not let too many pages get locked up
                         * waiting for the queue to open in here
                         */
-                       if (sum > 256) {
+                       if (tsum > 256) {
                                run_task_queue(&tq_disk);
-                               sum = 0;
                        }
+                       if (sum > sum_min)
+                               break;
 
                }
                run_task_queue(&tq_disk);
@@ -2149,18 +2127,9 @@
                        wake_up_interruptible(&pcd_waitq);
                        break;
                }
-
-               /*
-                * if woken up periodically (nothing else to do)
-                * convert all the pages, else convert only
-                * to keep watermarks happy.
-                */
-               if (interruptible_sleep_on_timeout(&pcd_waitq,
-                               pb_params.p_un.cluster_interval) == 0)
-               {
-                       PB_MIN_DIRTY_PAGES = 0;
-               } else
-                       PB_MIN_DIRTY_PAGES = pb_min_save;
+               interruptible_sleep_on_timeout(&pcd_waitq,
+                               pb_params.p_un.cluster_interval);
+               pb_io_stat.pcd_normal_scan++;
                pcd_active = 1;
        }
        kfree(cpages);
diff -Naur ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.c ./fs/xfs/linux/xfs_lrw.c
--- ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.c  Mon Dec  4 13:28:38 2000
+++ ./fs/xfs/linux/xfs_lrw.c    Fri Dec  1 10:30:10 2000
@@ -77,7 +77,8 @@
        char            *buf,
        size_t          size,
        loff_t          *offsetp,
-       int             read)   /* set if read, otherwise this is write */
+       int             read,   /* set if read, otherwise this is write */
+       int             *dirty)
 {
        ssize_t         ret;
        struct xfs_inode *xip;
@@ -98,7 +99,7 @@
                if (!(filp->f_flags & O_INVISIBLE))
                        xfs_ichgtime(xip, XFS_ICHGTIME_ACC);
        } else {
-               ret = pagebuf_generic_file_write(filp, buf, size, offsetp);
+               ret = pagebuf_generic_file_write(filp, buf, size, offsetp, dirty);
        }
 out:
        return(ret);
@@ -118,6 +119,7 @@
        vnode_t         *vp;
        xfs_inode_t     *ip;
 #endif
+       int dirty = 0;
 
        n = XFS_MAX_FILE_OFFSET - *offsetp;
        if (n <= 0)
@@ -145,7 +147,8 @@
        }
 #endif /* CONFIG_XFS_DMAPI */
 
-       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 1);
+       /* dirty doesn't matter */
+       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 1, &dirty);
        return(ret);
 }
 
@@ -168,7 +171,8 @@
        xfs_iocore_t    *io,
        xfs_off_t       offset,
        xfs_fsize_t     isize,
-       struct pm       *pmp)
+       struct pm       *pmp,
+       int             *dirty)
 {
        xfs_fileoff_t   last_fsb;
        xfs_fileoff_t   next_fsb;
@@ -342,7 +346,7 @@
                        printk("xfs_zero_last_block: unwritten?\n");
                }
        } else {
-               error = pagebuf_iozero(pb, zero_offset, zero_len);
+               error = pagebuf_iozero(pb, zero_offset, zero_len, dirty);
                pagebuf_rele(pb);
                goto out_lock;
        }
@@ -358,7 +362,7 @@
              ("zlb: pb_iozero pb 0x%p zf 0x%x zl 0x%x\n",
                pb, zero_offset, zero_len));
 
-       if (error = pagebuf_iozero(pb, zero_offset, zero_len)) {
+       if (error = pagebuf_iozero(pb, zero_offset, zero_len, dirty)) {
                pagebuf_rele(pb);
                goto out_lock;
        }
@@ -409,7 +413,8 @@
        xfs_iocore_t    *io,
        xfs_off_t       offset,
        xfs_fsize_t     isize,
-       struct pm       *pmp)
+       struct pm       *pmp,
+       int             *dirty)
 {
        struct inode    *ip = vp->v_inode;
        xfs_fileoff_t   start_zero_fsb;
@@ -440,7 +445,7 @@
         * First handle zeroing the block on which isize resides.
         * We only zero a part of that block so it is handled specially.
         */
-       error = xfs_zero_last_block(ip, io, offset, isize, pmp);
+       error = xfs_zero_last_block(ip, io, offset, isize, pmp, dirty);
        if (error) {
                ASSERT(ismrlocked(io->io_lock, MR_UPDATE));
                ASSERT(ismrlocked(io->io_iolock, MR_UPDATE));
@@ -555,7 +560,7 @@
                }
 
                if (imap.br_startblock == DELAYSTARTBLOCK) {
-                       error = pagebuf_iozero(pb, 0, lsize);
+                       error = pagebuf_iozero(pb, 0, lsize, dirty);
                        pagebuf_rele(pb);
                } else {
                        pb->pb_bn = XFS_FSB_TO_DB_IO(io, imap.br_startblock);
@@ -568,7 +573,7 @@
                                        ("xfs_zero_eof: real time device? use diff inode\n"));
                        }
 
-                       if (error = pagebuf_iozero(pb, 0, lsize)) {
+                       if (error = pagebuf_iozero(pb, 0, lsize, dirty)) {
                                pagebuf_rele(pb);
                                goto out_lock;
                        }
@@ -629,6 +634,7 @@
        int             eventsent = 0;
        loff_t          savedsize = *offsetp;
 #endif
+       int             dirty = 0;
 
        vp = BHV_TO_VNODE(bdp);
        xip = XFS_BHVTOI(bdp);
@@ -704,7 +710,7 @@
        if (*offsetp > isize && isize) {
                io->io_writeio_blocks = mp->m_writeio_blocks;
                ret = xfs_zero_eof(BHV_TO_VNODE(bdp), io, *offsetp,
-                       isize, NULL);
+                       isize, NULL, &dirty);
                if (ret) {
                        xfs_iunlock(xip, XFS_ILOCK_EXCL|XFS_IOLOCK_EXCL);
                        return(ret); /* JIMJIM should this be negative? */
@@ -713,7 +719,7 @@
        xfs_iunlock(xip, XFS_ILOCK_EXCL);
 
 retry:
-       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 0);
+       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 0, &dirty);
 
 #ifdef CONFIG_XFS_DMAPI
        if ((ret == -ENOSPC) &&
@@ -754,6 +760,8 @@
                }
        }
        xfs_iunlock(xip, XFS_IOLOCK_EXCL);
+       if (dirty)
+               balance_dirty(ip->i_dev);
        return(ret);
 }
 
diff -Naur ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.h ./fs/xfs/linux/xfs_lrw.h
--- ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.h  Tue Nov 28 16:34:23 2000
+++ ./fs/xfs/linux/xfs_lrw.h    Wed Oct 25 12:37:18 2000
@@ -48,7 +48,7 @@
 extern int xfs_bdstrat_cb (struct xfs_buf *);
 
 extern int xfs_zero_eof (vnode_t *, struct xfs_iocore *, xfs_off_t,
-                               xfs_fsize_t, struct pm *);
+                               xfs_fsize_t, struct pm *, int *dirty);
 extern ssize_t xfs_read (bhv_desc_t *, struct file *, char *,
                                size_t, loff_t *);
 extern ssize_t xfs_write (bhv_desc_t *, struct file *, char *,
diff -Naur ../../xfs-tot/linux/fs/xfs/xfs_inode.c ./fs/xfs/xfs_inode.c
--- ../../xfs-tot/linux/fs/xfs/xfs_inode.c      Tue Nov 28 16:34:30 2000
+++ ./fs/xfs/xfs_inode.c        Thu Nov 30 10:29:40 2000
@@ -1707,7 +1707,7 @@
        cred_t          *credp)
 {
        xfs_fsize_t     isize;
-       int             error;
+       int             error, dirty;
 
        ASSERT(ismrlocked(&(ip->i_lock), MR_UPDATE) != 0);
        ASSERT(ismrlocked(&(ip->i_iolock), MR_UPDATE) != 0);
@@ -1720,7 +1720,8 @@
         * xfs_write_file() beyond the end of the file
         * and any blocks between the old and new file sizes.
         */
-       error = xfs_zero_eof(XFS_ITOV(ip), &ip->i_iocore, new_size, isize, NULL);
+       error = xfs_zero_eof(XFS_ITOV(ip), &ip->i_iocore, new_size, isize,
+                                                       NULL, &dirty);
        return error;
 }
 
diff -Naur ../../xfs-tot/linux/fs/xfs/xfs_rw.c ./fs/xfs/xfs_rw.c
--- ../../xfs-tot/linux/fs/xfs/xfs_rw.c Tue Nov 28 16:34:31 2000
+++ ./fs/xfs/xfs_rw.c   Wed Oct 25 12:11:52 2000
@@ -690,7 +690,7 @@
        void            *dio)               
 {
        xfs_dio_t       *diop = (xfs_dio_t *)dio;
-       int             relock;
+       int             relock, dirty;
        __uint64_t      flush_end;
        xfs_mount_t     *mp;
 
@@ -717,7 +717,8 @@
                XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD);
                isize = XFS_SIZE(mp, io);
                if (offset > isize) {
-                       xfs_zero_eof(vp, io, offset, isize, diop->xd_pmp);
+                       xfs_zero_eof(vp, io, offset, isize,
+                                       diop->xd_pmp, &dirty);
                }
                XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD);
        }
diff -Naur ../../xfs-tot/linux/include/linux/page_buf.h ./include/linux/page_buf.h
--- ../../xfs-tot/linux/include/linux/page_buf.h        Tue Nov 28 16:34:57 2000
+++ ./include/linux/page_buf.h  Fri Dec  1 16:38:38 2000
@@ -570,7 +570,8 @@
 extern int pagebuf_iozero(             /* zero contents of buffer      */
                page_buf_t *,           /* buffer to zero               */
                off_t,                  /* offset in buffer             */
-               size_t);                /* size of data to zero         */
+               size_t,                 /* size of data to zero         */
+               int *);                 /* generated new dirty data?    */
 
 extern int pagebuf_mapin(              /* make buffer addressable      */
                page_buf_t *);          /* buffer to make addressable   */
@@ -635,7 +636,8 @@
                struct file *,          /* file to write                */
                char *,                 /* buffer address               */
                size_t,                 /* size of buffer               */
-               loff_t *);              /* file offset to use and update */
+               loff_t *,               /* file offset to use and update */
+               int *);                 /* dirty indicator              */
 
        /*
         * pagebuf_generic_file_write writes data from the specified file
diff -Naur ../../xfs-tot/linux/include/linux/pagemap.h ./include/linux/pagemap.h
--- ../../xfs-tot/linux/include/linux/pagemap.h Tue Nov 28 16:34:57 2000
+++ ./include/linux/pagemap.h   Fri Dec  1 16:38:39 2000
@@ -70,7 +70,7 @@
 extern struct page * __find_lock_page (struct address_space * mapping,
                                unsigned long index, struct page **hash);
 extern struct page * __find_lock_page_nowait (struct address_space * mapping,
-                               unsigned long index, struct page **hash);
+                               unsigned long index, struct page **hash, int);
 extern void lock_page(struct page *page);
 #define find_lock_page(mapping, index) \
                __find_lock_page(mapping, index, page_hash(mapping, index))
diff -Naur ../../xfs-tot/linux/include/linux/swap.h ./include/linux/swap.h
--- ../../xfs-tot/linux/include/linux/swap.h    Tue Nov 28 16:34:59 2000
+++ ./include/linux/swap.h      Fri Dec  1 16:36:29 2000
@@ -208,6 +208,9 @@
 #define ZERO_PAGE_BUG \
        if (page_count(page) == 0) BUG();
 
+#define DELALLOC_DEBUG_PAGE \
+       if (test_bit(PG_delalloc, &(page)->flags)) BUG();
+
 #define add_page_to_active_list(page) { \
        DEBUG_ADD_PAGE \
        ZERO_PAGE_BUG \
@@ -228,6 +231,7 @@
 #define add_page_to_inactive_clean_list(page) { \
        DEBUG_ADD_PAGE \
        ZERO_PAGE_BUG \
+       DELALLOC_DEBUG_PAGE \
        SetPageInactiveClean(page); \
        list_add(&(page)->lru, &page->zone->inactive_clean_list); \
        page->zone->inactive_clean_pages++; \
diff -Naur ../../xfs-tot/linux/mm/filemap.c ./mm/filemap.c
--- ../../xfs-tot/linux/mm/filemap.c    Tue Nov 28 16:35:03 2000
+++ ./mm/filemap.c      Thu Nov 30 10:29:41 2000
@@ -252,6 +252,24 @@
        spin_unlock(&pagecache_lock);
 }
 
+static inline struct page * __find_page_nolock_noref(struct address_space *mapping, unsigned
long offset, struct page *page)
+{
+       goto inside;
+
+       for (;;) {
+               page = page->next_hash;
+inside:
+               if (!page)
+                       goto not_found;
+               if (page->mapping != mapping)
+                       continue;
+               if (page->index == offset)
+                       break;
+       }
+not_found:
+       return page;
+}
+
 static inline struct page * __find_page_nolock(struct address_space *mapping, unsigned long
offset, struct page *page)
 {
        goto inside;
@@ -580,17 +598,19 @@
 }
 
 struct page * __find_lock_page_nowait(struct address_space *mapping,
-                               unsigned long offset, struct page **hash)
+                       unsigned long offset, struct page **hash, int check)
 {
        struct page *page;
 
        spin_lock(&pagecache_lock);
-       page = __find_page_nolock(mapping, offset, *hash);
+       page = __find_page_nolock_noref(mapping, offset, *hash);
        if (page)
                page_cache_get(page);
        spin_unlock(&pagecache_lock);
 
-       if (page && TryLockPage(page)) {
+       if (page &&
+               ((check && page->age >= PAGE_AGE_START) || TryLockPage(page)))
+       {
                /* don't wait for page */
                put_page(page);
                return NULL;
diff -Naur ../../xfs-tot/linux/mm/swap.c ./mm/swap.c
--- ../../xfs-tot/linux/mm/swap.c       Tue Nov 28 16:35:03 2000
+++ ./mm/swap.c Wed Nov  1 14:03:55 2000
@@ -173,7 +173,8 @@
         * inactive_clean list it doesn't need to be perfect...
         */
        int maxcount = (page->buffers ? 3 : 2);
-       page->age = 0;
+       if (page->age)
+               return;
        ClearPageReferenced(page);
 
        /*
@@ -181,8 +182,7 @@
         * (some pages aren't on any list at all)
         */
        if (PageActive(page) && page_count(page) <= maxcount &&
-                       !page_ramdisk(page) && 
-                       !test_bit(PG_delalloc, &page->flags))
+                       !page_ramdisk(page)) 
        {
 
                /*
@@ -194,7 +194,9 @@
                 * need to be cleared away) and/or the function calling
                 * us has an extra reference count on the page.
                 */
-               if (page->buffers || page_count(page) == 2) {
+               if (page->buffers || page_count(page) == 2 
+                       || test_bit(PG_delalloc, &page->flags))
+               {
                        del_page_from_active_list(page);
                        add_page_to_inactive_dirty_list(page);
                /*
-------------------------------- patch ends ------------------------------

-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon Dec  4 19:42:14 2000
Received:  by oss.sgi.com id <S553694AbQLEDly>;
	Mon, 4 Dec 2000 19:41:54 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:62079 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553673AbQLEDlY>;
	Mon, 4 Dec 2000 19:41:24 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA27831
	for <linux-xfs@oss.sgi.com>; Mon, 4 Dec 2000 19:41:21 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14191 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 14:40:04 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id OAA89327 for linux-xfs@oss.sgi.com; Tue, 5 Dec 2000 14:40:03 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10012051440.ZM179409@wobbly.melbourne.sgi.com>
Date:   Tue, 5 Dec 2000 14:40:01 -0400
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     linux-xfs@oss.sgi.com
Subject: util-linux-2.10r
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi,

(FYI) - Andries has made util-linux-2.10r available
- http://www.kernel.org/pub/linux/utils/util-linux/

This allows mount-by-label and by-UUID for XFS, and
also fixes the ppc/minix mount problem which Thomas
picked up on using the XFS stress tests.  Of course,
it also has Martin's original code to autodetect XFS
(so that the "-t xfs" option to mount is not needed).

I have (only) tested the mount binary which this
package generates, and it seems to work very nicely.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Tue Dec  5 00:03:15 2000
Received:  by oss.sgi.com id <S553708AbQLEIDG>;
	Tue, 5 Dec 2000 00:03:06 -0800
Received: from TYO202.gate.nec.co.jp ([202.247.6.41]:22035 "EHLO
        TYO202.gate.nec.co.jp") by oss.sgi.com with ESMTP
	id <S553657AbQLEICq>; Tue, 5 Dec 2000 00:02:46 -0800
Received: from mailsv.nec.co.jp ([10.7.68.90])
	by TYO202.gate.nec.co.jp (8.9.3/3.7W00120420) with ESMTP id RAA29742
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 17:02:38 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP
	id RAA22871 for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 17:01:42 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp. (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48])
	by mahler.hpc.bs1.fc.nec.co.jp (8.9.3/3.7W-HPC5.1E(common)) with ESMTP id QAA29026
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 16:56:27 +0900
Date:   Tue, 05 Dec 2000 16:56:27 +0900
Message-ID: <geelzn47ys.wl@hpc.bs1.fc.nec.co.jp>
From:   Hiroshi Aono <h-aono@ap.jp.nec.com>
To:     linux-xfs@oss.sgi.com
Subject: panic occurs on IA64
User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada)
 CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch
 9) (Canyonlands) (i386-pc-linux)
MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

I tried to run XFS on IA64, but kernel panic occurs.
I got 11202000XFSdevel.patch.gz and compiled.
Then I run the kernel on IA64 machine which is provided by Intel. (2cpu, 1Gmem, xfs on SCSI disk)

Mkfs works fine.

[root@luna aono]# mkfs -t xfs -b size=16384 -f /dev/sdc1
meta-data=/dev/sdc1              isize=256    agcount=8, agsize=8033 blks
data     =                       bsize=16384  blocks=64258, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=16384 
log      =internal log           bsize=16384  blocks=1000
realtime =none                   extsz=65536  blocks=0, rtextents=0

However the kernel crashed at xlog_bread when I mounted the filesystem.
First, I trapped at xlog_bread and xfsbdstrat.

[root@luna aono]# mount -t xfs /dev/sdc1 /mnt/xfs

Instruction breakpoint #1 at 0xe0000000007db470
e0000000007db470 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db471 <xfsbdstrat+0x1>:             addl r14=1055048,r1
e0000000007db472 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x31e88000) on processor 0 [0]kdb> go

Start mounting filesystem: sd(8,33)
Instruction breakpoint #0 at 0xe0000000007804a0
e0000000007804a0 <xlog_bread>: [MII]       alloc r43=ar.pfs,16,12,0
e0000000007804a1 <xlog_bread+0x1>:             addl r14=1055048,r1
e0000000007804a2 <xlog_bread+0x2>:             mov r42=b0
Entering kdb (0x31e88000) on processor 0 [0]kdb> go

Instruction breakpoint #1 at 0xe0000000007db470
e0000000007db470 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db471 <xfsbdstrat+0x1>:             addl r14=1055048,r1
e0000000007db472 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x31e88000) on processor 0 [0]kdb> go

Instruction breakpoint #0 at 0xe0000000007804a0
e0000000007804a0 <xlog_bread>: [MII]       alloc r43=ar.pfs,16,12,0
e0000000007804a1 <xlog_bread+0x1>:             addl r14=1055048,r1
e0000000007804a2 <xlog_bread+0x2>:             mov r42=b0
Entering kdb (0x31e88000) on processor 0 [0]kdb> go

Unable to handle kernel paging request at virtual address 00000000000001d0
mount[300]: Oops 8813272891392
Entering kdb (0x31e88000) on processor 0 Panic: <NULL>
due to panic @ 0x7806d0
 psr: 0x0000101008026030   ifs: 0x8000000000000610    ip: 0xe0000000007806d0  
unat: 0x0000000000000000   pfs: 0x0000000000000590   rsc: 0x0000000000000003  
rnat: 0x0000000000000590  bsps: 0x0000000000000003    pr: 0x000000000002e553  
ldrs: 0x0000000000000000   ccv: 0x0000000000000000  fpsr: 0x0009804c8a70033f  
  b0: 0xe000000000782c30    b6: 0xe000000000502f70    b7: 0xe000000000521270  
  r1: 0xe000000000ce1e40    r2: 0xe000000031e8f970    r3: 0x000000000002e513  
  r8: 0x0000000000000000    r9: 0x0000000000000000   r10: 0x0000000000000000  
 r11: 0x600000000000c140   r12: 0xe000000031e8f9b0   r13: 0xe000000031e88000  
 r14: 0x00000000000001d0   r15: 0xe000000031d13840   r16: 0xe000000031d13810  
 r17: 0x0000000008000001   r18: 0xe000000031d13818   r19: 0x0000000000000200  
 r20: 0xe000000031e897b8   r21: 0x000000000002e593   r22: 0x000000003fe36dc0  
 r23: 0x80000000ffdf5f30   r24: 0x80000000ffdf5ee0   r25: 0x80000000ffdf5f40  
 r26: 0x000000003ff48010   r27: 0xe000000000de22d8   r28: 0xe000000000521270  
 r29: 0x0000000000000001   r30: 0xe000000000c94080   r31: 0x600000000000c110  
&regs = 0xe000000031e8f820
[0]kdb> bt
Ret Address (ip)    Mem Stack (sp) Reg Stack (bsp) Name

0xe0000000007806d0:  v+0x2000000000000000   v+0x3be60eb0   xlog_bread

bt command on IA64 seems not to work.
I disassembled the crashed point.
It seems the kernel crashed at before calling xfsbdstrat.

                        292: PCREL21B   assfail
     296:       d0 02 3c 30 20 00                   ld8 r45=[r15]
     29c:       08 00 00 50                         br.call.sptk.many b0=290 <xlog_bread+0x180>;;
     2a0:       10 00 00 00 01 00       [MIB]       nop.m 0x0
     2a6:       00 00 00 02 00 00                   nop.i 0x0
     2ac:       20 00 00 40                         br 2c0 <xlog_bread+0x1b0>
     2b0:       00 00 00 00 01 00       [MII]       nop.m 0x0
     2b6:       40 22 d9 ac 29 00                   dep.z r36=r36,9,23
     2bc:       00 00 04 00                         nop.i 0x0
     2c0:       01 78 00 50 01 21       [MII]       adds r15=128,r40
     2c6:       70 42 95 00 42 00                   adds r39=40,r37
     2cc:       02 29 01 84                         adds r16=16,r37;;
     2d0:       04 70 00 1e 18 10       [MLX]       ld8 r14=[r15]
     2d6:       08 00 00 00 00 20                   movl r17=0x8000001
     2dc:       12 00 00 60 
     2e0:       02 00 00 00 01 00       [MII]       nop.m 0x0
     2e6:       30 01 90 2c 00 c0                   sxt4 r19=r36;;
     2ec:       e1 48 01 80                         add r14=r14,r41
     2f0:       02 78 00 4b 00 21       [MII]       adds r15=64,r37
     2f6:       40 42 a3 00 42 00                   adds r36=104,r40;;
     2fc:       00 00 04 00                         nop.i 0x0
     300:       00 00 38 4e 98 11       [MII]       st8 [r39]=r14
     306:       20 c1 94 00 42 a0                   adds r18=24,r37
     30c:       05 28 01 84                         mov r45=r37
     310:       0b 70 00 20 10 10       [MMI]       ld4 r14=[r16];;
     316:       e0 88 38 1c 40 00                   or r14=r17,r14
     31c:       00 00 04 00                         nop.i 0x0;;
     320:       08 00 38 20 90 11       [MMI]       st4 [r16]=r14
     326:       00 98 3c 30 23 00                   st8 [r15]=r19
     32c:       00 00 04 00                         nop.i 0x0
     330:       0b 70 00 48 18 10       [MMI]       ld8 r14=[r36];;
     336:       e0 80 3a 06 42 00                   adds r14=464,r14
     33c:       00 00 04 00                         nop.i 0x0;;
     340:       0a 78 00 1c 18 10       [MMI]       ld8 r15=[r14];; <- crashed
     346:       00 78 48 30 23 00                   st8 [r18]=r15
     34c:       00 00 04 00                         nop.i 0x0
     350:       11 60 01 48 18 10       [MIB]       ld8 r44=[r36]
                        352: PCREL21B   xfsbdstrat
     356:       00 00 00 02 00 00                   nop.i 0x0
     35c:       08 00 00 50                         br.call.sptk.many b0=350 <xlog_bread+0x240>;;
     360:       11 60 01 4a 00 21       [MIB]       mov r44=r37


/*
 * nbblks should be uint, but oh well.  Just want to catch that 32-bit length.
 */
int
xlog_bread(xlog_t       *log,
           xfs_daddr_t  blk_no,
           int          nbblks,
           xfs_buf_t    *bp)
{
        int error;

        ASSERT(log);
        ASSERT(nbblks > 0);
        ASSERT(BBTOB(nbblks) <= XFS_BUF_SIZE(bp));
        ASSERT(bp);

        XFS_BUF_SET_ADDR(bp, log->l_logBBstart + blk_no);
        XFS_BUF_READ(bp);
        XFS_BUF_BUSY(bp);
        XFS_BUF_SET_COUNT(bp, BBTOB(nbblks));
        XFS_BUF_SET_TARGET(bp, &log->l_mp->m_logdev_targ);

        xfsbdstrat(log->l_mp, bp);
        if (error = xfs_iowait(bp)) {
                xfs_ioerror_alert("xlog_bread", log->l_mp,
                                  XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp));
                return (error);
        }
        return error;
}       /* xlog_bread */

What is wrong? can you help me?

Hiroshi Aono, NEC Solutions
(h-aono@ap.jp.nec.com)

From owner-linux-xfs@oss.sgi.com Tue Dec  5 02:15:15 2000
Received:  by oss.sgi.com id <S553975AbQLEKPF>;
	Tue, 5 Dec 2000 02:15:05 -0800
Received: from relay.dera.gov.uk ([192.5.29.49]:44097 "HELO relay.dera.gov.uk")
	by oss.sgi.com with SMTP id <S553971AbQLEKOz>;
	Tue, 5 Dec 2000 02:14:55 -0800
Received: (qmail 3908 invoked from network); 5 Dec 2000 10:14:53 +0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by relay.dera.gov.uk with SMTP; 5 Dec 2000 10:14:53 +0000
Content-Length: 1487
Message-ID: <XFMail.20001205101452.gale@syntax.dera.gov.uk>
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3A2C003F.B40D640B@thebarn.com>
Date:   Tue, 05 Dec 2000 10:14:52 -0000 (GMT)
From:   Tony Gale <gale@syntax.dera.gov.uk>
To:     Russell Cattelan <cattelan@thebarn.com>
Subject: Re: ADD 804570 - The elevator bug
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 04-Dec-2000 Russell Cattelan wrote:
> Tony Gale wrote:
> 
>> But, the filesystem pretty much goes unrecoverable after
>> I am forced to reset the box:
> 
> This could be related to other issues.
> First exactly what version of the XFS tree are you running?
> If you are running anything less than current (as of today)
> or the XFS_BETA_4 image, please upgrade immediately.

I was running linux-2.4-xfs cvs from Nov 27. I can't gauge the
stability of xfs if I keep updating it.

I've upgraded to the current cvs + elevator patch now.

> 
> There was a corruption problem in all previous version.
> Symptoms of the corruption does sound similar to what
> you are describing.
> 
> At this point you will need to run xfs_repair to get your
> file system back, if repair fails let us know hopefully we
> can fix whatever went wrong.
>

xfs_repair seems to sort out the (numerous) problems, although innd
still won't work with the resulting spool. Will have to speak to innd
people about that.

But, xfs_repair does have an annoyance. I like to run fs repair 
programs until it reports no problems, but the way xfs_repair
unlinks lost+found, if there are any files in there you always get
disconnected inodes in phase 6.

Thanks

-tony


---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
grep me no patterns and I'll tell you no lines.

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.

From owner-linux-xfs@oss.sgi.com Tue Dec  5 05:03:56 2000
Received:  by oss.sgi.com id <S553655AbQLENDq>;
	Tue, 5 Dec 2000 05:03:46 -0800
Received: from [64.240.27.5] ([64.240.27.5]:39948 "EHLO dns.tricord.com")
	by oss.sgi.com with ESMTP id <S553647AbQLENDb>;
	Tue, 5 Dec 2000 05:03:31 -0800
Received: by dns.tricord with Internet Mail Service (5.5.2448.0)
	id <VRSJY5T0>; Tue, 5 Dec 2000 07:04:12 -0600
Message-ID: <6DEE94132593D41182D200508BDCA59014E594@mail.tricord.com>
From:   "Lord, Steve" <SLord@tricord.com>
To:     'Tony Gale' <gale@syntax.dera.gov.uk>,
        Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: RE: ADD 804570 - The elevator bug
Date:   Tue, 5 Dec 2000 07:05:53 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


I should comment here - since it was an old message of mine which
was sent around again. The code I suggested people try is buggy,
there was followup in linux kernel about this. Basically the
elevator 'bug' is a starvation problem which is due to it using
very large constants for how many times a request can be scanned
over before it has to be processed. It never caused a crash,
it just caused some test programs to hang for about a day before
they worked through the elevator.

Fixing the elevator should be as simple as either getting hold of
elvtune which can tweak these parameters or changing them in the
code (probably elevator.c) I am in a hotel room in Denver and I
don't have direct access to source at the moment, or I would point
you at the right places.

[ Side note on repair and the lost+found directory - the first thing
repair does is remove this directory without removing its contents,
which means that if you run repair with a lost+found with contents
you will always get unlinked files. If you want to keep the files
then move them somewhere else (renaming lost+found would work) or
just delete them between repair runs. I do not know the reasoning
behind this logic, the authors or repair left SGI a long time
ago.

You state that your news server hangs after about a week - this is
the thing which needs digging into I think. Have you tried dropping
into kdb when this happens - a dump of all stack traces might be a
good starting point.

Steve
 
> -----Original Message-----
> From: Tony Gale [mailto:gale@syntax.dera.gov.uk]
> Sent: Tuesday, December 05, 2000 4:15 AM
> To: Russell Cattelan
> Cc: linux-xfs@oss.sgi.com
> Subject: Re: ADD 804570 - The elevator bug
> 
> 
> 
> On 04-Dec-2000 Russell Cattelan wrote:
> > Tony Gale wrote:
> > 
> >> But, the filesystem pretty much goes unrecoverable after
> >> I am forced to reset the box:
> > 
> > This could be related to other issues.
> > First exactly what version of the XFS tree are you running?
> > If you are running anything less than current (as of today)
> > or the XFS_BETA_4 image, please upgrade immediately.
> 
> I was running linux-2.4-xfs cvs from Nov 27. I can't gauge the
> stability of xfs if I keep updating it.
> 
> I've upgraded to the current cvs + elevator patch now.
> 
> > 
> > There was a corruption problem in all previous version.
> > Symptoms of the corruption does sound similar to what
> > you are describing.
> > 
> > At this point you will need to run xfs_repair to get your
> > file system back, if repair fails let us know hopefully we
> > can fix whatever went wrong.
> >
> 
> xfs_repair seems to sort out the (numerous) problems, although innd
> still won't work with the resulting spool. Will have to speak to innd
> people about that.
> 
> But, xfs_repair does have an annoyance. I like to run fs repair 
> programs until it reports no problems, but the way xfs_repair
> unlinks lost+found, if there are any files in there you always get
> disconnected inodes in phase 6.
> 
> Thanks
> 
> -tony
> 
> 
> ---
> E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
> grep me no patterns and I'll tell you no lines.
> 
> The views expressed above are entirely those of the writer
> and do not represent the views, policy or understanding of
> any other person or official body.
> 

From owner-linux-xfs@oss.sgi.com Tue Dec  5 05:28:55 2000
Received:  by oss.sgi.com id <S553714AbQLEN2g>;
	Tue, 5 Dec 2000 05:28:36 -0800
Received: from relay.dera.gov.uk ([192.5.29.49]:24632 "HELO relay.dera.gov.uk")
	by oss.sgi.com with SMTP id <S553652AbQLEN2Q>;
	Tue, 5 Dec 2000 05:28:16 -0800
Received: (qmail 32018 invoked from network); 5 Dec 2000 13:28:14 +0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by relay.dera.gov.uk with SMTP; 5 Dec 2000 13:28:14 +0000
Content-Length: 1715
Message-ID: <XFMail.20001205132813.gale@syntax.dera.gov.uk>
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <6DEE94132593D41182D200508BDCA59014E594@mail.tricord.com>
Date:   Tue, 05 Dec 2000 13:28:13 -0000 (GMT)
From:   Tony Gale <gale@syntax.dera.gov.uk>
To:     "Lord, Steve" <SLord@tricord.com>
Subject: RE: ADD 804570 - The elevator bug
Cc:     linux-xfs@oss.sgi.com, Russell Cattelan <cattelan@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 05-Dec-2000 Lord, Steve wrote:
> 
> Fixing the elevator should be as simple as either getting hold of
> elvtune which can tweak these parameters or changing them in the
> code (probably elevator.c) I am in a hotel room in Denver and I
> don't have direct access to source at the moment, or I would point
> you at the right places.

Ok, will back it out for now.

> 
> [ Side note on repair and the lost+found directory - the first
> thing
> repair does is remove this directory without removing its contents,
> which means that if you run repair with a lost+found with contents
> you will always get unlinked files. If you want to keep the files
> then move them somewhere else (renaming lost+found would work) or
> just delete them between repair runs. I do not know the reasoning
> behind this logic, the authors or repair left SGI a long time
> ago.

Yes, it's just slightly annoying, and I can't see a reason for it
either.

> 
> You state that your news server hangs after about a week - this is
> the thing which needs digging into I think. Have you tried dropping
> into kdb when this happens - a dump of all stack traces might be a
> good starting point.
> 

I'll put my hands up and admit to being less than proactive on
tracking down the actual problem than I should have been. Was more
concerned with not being able to get innd to work after resetting.
Will do a more thorough job next time (hoping there won't be a next
time :-) )

Thanks

-tony


---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
The cost of feathers has risen, even down is up!

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.

From owner-linux-xfs@oss.sgi.com Tue Dec  5 08:56:16 2000
Received:  by oss.sgi.com id <S553981AbQLEQ4I>;
	Tue, 5 Dec 2000 08:56:08 -0800
Received: from mcomail02.maxtor.com ([134.6.76.16]:39945 "HELO
        mcomail02.maxtor.com") by oss.sgi.com with SMTP id <S553978AbQLEQ4A>;
	Tue, 5 Dec 2000 08:56:00 -0800
Received: from 134.6.67.21 by mcomail02.maxtor.com (InterScan E-Mail VirusWall NT); Tue, 05 Dec 2000 09:52:39 -0700 (Mountain Standard Time)
Received: by mcoexc03.mlm.maxtor.com with Internet Mail Service (5.5.2650.21)
	id <XC6W9CKY>; Tue, 5 Dec 2000 09:54:11 -0700
Message-ID: <09D1E9BD9C30D311919200A0C9DD5C2C02537051@mcaexc01.msj.maxtor.com>
From:   "Davida, Joe" <Joe_Davida@Maxtor.com>
To:     'Rajagopal Ananthanarayanan' <ananth@sgi.com>
Cc:     "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: RE: kioclusters
Date:   Tue, 5 Dec 2000 09:54:32 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

	Thank you RajaGopal,
	Will try the patch. By latest you mean as of what date?
	My current tree is as of last Friday 12/1.
	Cheers,

	Joe

>-----Original Message-----
>From: Rajagopal Ananthanarayanan [mailto:ananth@sgi.com]
>Sent: Monday, December 04, 2000 4:53 PM
>To: Davida, Joe
>Cc: 'linux-xfs@oss.sgi.com'
>Subject: Re: kioclusters
>
>
>"Davida, Joe" wrote:
>> 
>> You say you have seen performance problems with non-sequential
>> localized writes using the kiocluster option on mounts.
>> Is the performance problem bad enough so that it is worse
>> than ext2fs?
>> 
>> Joe
>
>
>Performance difference really depends on what is being run.
>We have noticed that for dbench with small number of clients,
>xfs+kiocluter does worse than ext2 ... but for dbench with
>larger number of clients xfs+kiocluster does better than ext2.
>
>I've been working on a patch which in my tests with dbench
>has improved xfs+kiocluster significantly. If you are working
>with a test system, can you please try the following patch
>(in conjuction with the kiocluster option)? The patch is against
>the latest development xfs tree ...
>
>
>----------------- patch begins -------------------------------
>diff -Naur ../../xfs-tot/linux/fs/pagebuf/page_buf.c 
>./fs/pagebuf/page_buf.c
>--- ../../xfs-tot/linux/fs/pagebuf/page_buf.c   Tue Nov 28 
>16:34:17 2000
>+++ ./fs/pagebuf/page_buf.c     Thu Nov 30 10:29:39 2000
>@@ -186,7 +186,7 @@
> unsigned long pagebuf_min[P_PARAM] = { HZ/2, 1*HZ, HZ/2, 1, 0, 0 };
> unsigned long pagebuf_max[P_PARAM] = { HZ*30, HZ*300, HZ*30, 
>1024, 4096, 1 };
> 
>-pagebuf_param_t pb_params = {{ HZ, 15 * HZ, HZ, 512, 1024, 0 }};
>+pagebuf_param_t pb_params = {{ HZ, 15 * HZ, 2*HZ, 512, 1024, 0 }};
> 
> /*
>  * Pagebuf statistics variables
>@@ -595,7 +595,11 @@
>                        kp->maplist[pi] = cp;
>                } else {
>                        cp = kp->maplist[pi];
>-                       set_bit(PG_referenced, &cp->flags);
>+                       /*
>+                        * Don't set referenced bit;
>+                        * we may consider age_page_up.
>+                       //set_bit(PG_referenced, &cp->flags);
>+                        */
>                        while (TryLockPage(cp)) {
>                                wait_on_page(cp);
>                        }
>@@ -1345,7 +1349,7 @@
>        struct buffer_head *bh;
>        off_t blk_offset;
>        size_t blk_length;
>-       int err=0;
>+       int err=0, need_balance_dirty = 0;
>        int force_io = (rw != READ) || (pb->pb_flags & PBF_FORCEIO);
>        int concat_ok = ((MAJOR(dev) != LVM_BLK_MAJOR) || 
>(MAJOR(dev) != MD_MAJOR));
> 
>@@ -1425,7 +1429,9 @@
> 
>                        if (rw == WRITE ) {
>                                set_bit(BH_Uptodate, &bh->b_state);
>-                               set_bit(BH_Dirty, &bh->b_state);
>+                               if (!buffer_dirty(bh))
>+                                       need_balance_dirty = 1;
>+                               __mark_buffer_dirty(bh);
>                        }
>                        psync->bh[cnt++] = bh;
>                        atomic_inc(&psync->remain);
>@@ -1444,7 +1450,8 @@
>                if (locking)
>                        UnlockPage(page);
>        }
>-
>+       if (need_balance_dirty)
>+               balance_dirty(dev);
>        return err;
> error:
>        /* If we ever do get here then clean up what we already did */
>diff -Naur ../../xfs-tot/linux/fs/pagebuf/page_buf_io.c 
>./fs/pagebuf/page_buf_io.c
>--- ../../xfs-tot/linux/fs/pagebuf/page_buf_io.c        Tue 
>Nov 28 16:34:17 2000
>+++ ./fs/pagebuf/page_buf_io.c  Fri Dec  1 10:31:28 2000
>@@ -93,11 +93,11 @@
> /*
>  * Forward declarations.
>  */
>-STATIC void __pb_block_commit_write_async(struct inode *,
>+STATIC int __pb_block_commit_write_async(struct inode *,
>                struct page *, page_buf_bmap_t *);
> STATIC int __pb_block_prepare_write_async(struct inode *, 
>struct page *,
>                unsigned, unsigned, int, page_buf_bmap_t *, int);
>-STATIC int pagebuf_delalloc_convert(struct page *, u_long, 
>struct page **);
>+STATIC int pagebuf_delalloc_convert(struct page *, u_long, 
>struct page **, int, int);
> STATIC void hook_buffers_to_page(struct inode *, struct page *,
>                page_buf_bmap_t *, ulong);
> 
>@@ -114,6 +114,20 @@
> int MAX_CLUSTER = 512;
> int CLUSTER_PAGE_LIST_SIZE = ((2*512)+1);
> 
>+/*
>+ * stats
>+ */
>+struct pb_io_stat_s {
>+       int pcd_normal_scan;
>+       int pcd_normal_converted;
>+
>+       int pcd_skip_locked;
>+       int pcd_skip_referenced;
>+
>+       int pcd_ilock_failed;
>+} pb_io_stat = {0, 0, 0, 0, 0};
>+
>+EXPORT_SYMBOL(pb_io_stat);
> 
> /*
>  * The minimum size where we will start using pagebuf 
>structures instead
>@@ -210,10 +224,12 @@
> 
>        if (IS_KIOCLUSTER(ip)){
>                /*
>-                * If kmalloc, no big deal; the lower layers 
>won't cluster.
>+                * If kmalloc fails, no big deal; the lower 
>layers won't
>+                * cluster. Also, this allocation has to be 
>non-sleeping
>+                * since this can be in kswapd's path ...
>                 */
>                cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * 
>sizeof(struct page *),
>-                                          GFP_KERNEL);
>+                                          GFP_ATOMIC);
>        } else {
>                cpages = (struct page **)1; /* a boolean */
>        }
>@@ -235,7 +251,7 @@
> 
>                        lock_page(page);
>                        if (test_and_clear_bit(PG_delalloc, 
>&page->flags)) {
>-                               pagebuf_delalloc_convert(page, 
>0, cpages);
>+                               pagebuf_delalloc_convert(page, 
>0, cpages, 0, 0);
>                        } else {
>                                UnlockPage(page);
>                        }
>@@ -511,7 +527,8 @@
> int pagebuf_iozero(            /* zero contents of buffer      */
>     page_buf_t * pb,           /* buffer to zero               */
>     off_t boff,                        /* offset in buffer    
>         */
>-    size_t bsize)              /* size of data to zero           */
>+    size_t bsize,              /* size of data to zero           */
>+    int  *dirty)
> {
>        loff_t cboff;
>        size_t cpoff;
>@@ -541,6 +558,7 @@
>                if (pb->pb_bn == PAGE_BUF_DADDR_NULL) {
>                        if (test_and_set_bit(PG_delalloc, 
>&pm->flags) == 0) {
>                                atomic_inc(&pb_delalloc_pages);
>+                               (*dirty)++;
>                        }
>                }
>        }
>@@ -548,16 +566,6 @@
>        pb->pb_flags &= ~(PBF_READ | PBF_WRITE);
>        pb->pb_flags &= ~(_PBF_SOME_INVALID_PAGES | 
>PBF_PARTIAL | PBF_NONE);
> 
>-       if (!pcd_active && (pb->pb_bn == PAGE_BUF_DADDR_NULL)) {
>-               unsigned int    np = atomic_read(&pb_delalloc_pages);
>-
>-               if (np > 2 * pb_params.p_un.max_dirty_pages)
>-                       wake_up_interruptible_sync(&pcd_waitq);
>-               else if (np > pb_params.p_un.max_dirty_pages)
>-                       wake_up_interruptible(&pcd_waitq);
>-       }
>-
>-
>        return (0);
> }
> 
>@@ -1174,62 +1182,6 @@
>                        page, page->index, bh->b_blocknr));
> }
> 
>-
>-void
>-set_buffer_dirty_uptodate(struct buffer_head *bh)
>-{
>-       int need_balance_dirty = 0;
>-
>-       if (bh->b_blocknr <= 0) {
>-               printk("Warning: buffer 0x%p with weird 
>blockno (%ld)\n",
>-                       bh, bh->b_blocknr);
>-       }
>-       set_bit(BH_Uptodate, &bh->b_state);
>-       if (!buffer_dirty(bh)) {
>-               bh->b_end_io = end_pb_buffer_io_async;
>-               need_balance_dirty = 1;
>-       }
>-       __mark_buffer_dirty(bh);
>-
>-       if (need_balance_dirty)
>-               balance_dirty(bh->b_dev);
>-}
>-
>-int pbwcm_debug = 0;
>-
>-int
>-__pb_write_or_convert_bmap(
>-       struct inode *inode,
>-       struct page *page)
>-{
>-       loff_t  offset = page->index << PAGE_CACHE_SHIFT;
>-       int error, nmaps;
>-       page_buf_bmap_t map;
>-
>-       error = inode->i_op->pagebuf_bmap(inode, offset, 
>PAGE_CACHE_SIZE,
>-                       &map, 1, &nmaps, PBF_WRITE);
>-       if (error == 0 && (map.pbm_flags & PBMF_DELAY)) {
>-               error = inode->i_op->pagebuf_bmap(inode, offset,
>-                               map.pbm_bsize, &map, 1,
>-                               &nmaps, PBF_WRITE|PBF_FILE_ALLOCATE);
>-               if (error) {
>-                       printk("pbwcm: bmap error %d ro 0x%Lx 
>size 0x%x\n",
>-                                  error, offset, map.pbm_bsize);
>-               } else {
>-                       dprintk(pbwcm_debug,
>-                        ("converted bn:%Ld off:%Ld size:%d 
>flags:%d\n",
>-                            map.pbm_bn, map.pbm_offset,
>-                            map.pbm_bsize, map.pbm_flags));
>-               }
>-       }
>-       if (!error) {
>-               hook_buffers_to_page(inode, page, &map, 
>PAGE_CACHE_SHIFT);
>-               set_buffer_dirty_uptodate(page->buffers);
>-       }
>-       return error;
>-}
>-
>-
> STATIC int
> __pb_block_prepare_write_async(struct inode *inode, struct page *page,
>                unsigned from, unsigned to, int at_eof,
>@@ -1390,15 +1342,34 @@
> }
> 
> int pbcw_debug = 0;
>+
>+int
>+set_buffer_dirty_uptodate(struct buffer_head *bh)
>+{
>+       int need_balance_dirty = 0;
>+
>+       if (bh->b_blocknr <= 0) {
>+               printk("Warning: buffer 0x%p with weird 
>blockno (%ld)\n",
>+                       bh, bh->b_blocknr);
>+       }
>+       set_bit(BH_Uptodate, &bh->b_state);
>+       if (!buffer_dirty(bh)) {
>+               bh->b_end_io = end_pb_buffer_io_async;
>+               need_balance_dirty = 1;
>+       }
>+       __mark_buffer_dirty(bh);
>+       return (need_balance_dirty);
>+}
>+
> int pbcw_debug2 = 0;
> 
>-STATIC void
>+STATIC int
> __pb_block_commit_write_async(struct inode     *inode,
>                                struct page     *page,
>                                page_buf_bmap_t *mp)
> {
>        struct buffer_head      *bh;
>-       unsigned int            np;
>+       int                     dirty = 0;
> 
>        /*
>         * Prepare write took care of reading/zero-out
>@@ -1412,32 +1383,20 @@
>                if (test_bit(PG_delalloc, &page->flags)) {
>                        dprintk(pbcw_debug2, ("mapped buffer 
>0x%p page 0x%p is delalloc\n", bh,
>page));
>                }
>-               set_buffer_dirty_uptodate(page->buffers);
>+               dirty = set_buffer_dirty_uptodate(page->buffers);
>                dprintk(pbcw_debug, ("pbcw: refiled valid 
>buffer 0x%p\n",
>                        page->buffers));
>        } else if (test_and_set_bit(PG_delalloc, &page->flags) == 0) {
>                dprintk(pbcw_debug, ("Marking page 0x%p 
>delalloc\n", page));
>-               np = atomic_read(&pb_delalloc_pages);
>-               if (np > PB_MAX_DIRTY_FACTOR * 
>pb_params.p_un.max_dirty_pages) {
>-                       clear_bit(PG_delalloc, &page->flags);
>-                       if (__pb_write_or_convert_bmap(inode, page)) {
>-                               BUG();
>-                       }
>-               } else {
>-                       atomic_inc(&pb_delalloc_pages);
>-                       if (!pcd_active) {
>-                               if (np > 2 * 
>pb_params.p_un.max_dirty_pages)
>-                                       
>wake_up_interruptible_sync(&pcd_waitq);
>-                               else if (np > 
>pb_params.p_un.max_dirty_pages)
>-                                       
>wake_up_interruptible(&pcd_waitq);
>-                       }
>-                       balance_dirty(inode->i_rdev);
>-               }
>+
>+               atomic_inc(&pb_delalloc_pages);
>+               dirty = 1;
>        }
> 
>        /* Advance though extent no matter what */
>        if (mp)
>                mp->pbm_delta += PAGE_CACHE_SIZE;
>+       return dirty;
> }
> 
> int
>@@ -1448,7 +1407,8 @@
>        char            *user_addr,
>        size_t          len,
>        loff_t          *lp,
>-       page_buf_bmap_t *mp)            /* bmap for page       
>              */
>+       page_buf_bmap_t *mp,            /* bmap for page       
>              */
>+       int             *dirty)
> {
>        struct page *page;
>        unsigned long done;
>@@ -1507,7 +1467,7 @@
>                        goto unlock;
>                }
> 
>-               __pb_block_commit_write_async(inode, page, mp);
>+               *dirty += __pb_block_commit_write_async(inode, 
>page, mp);
> 
>                foff += bytes_in_page;
>                len -= bytes_in_page;
>@@ -1533,7 +1493,8 @@
>        char *buf,              /* buffer address               */
>        size_t len,             /* size of buffer               */
>        loff_t * lp,            /* file offset to use and update */
>-       int pb_flags)           /* flags to pass to bmap calls  */
>+       int pb_flags,           /* flags to pass to bmap calls  */
>+       int *dirty)
> {
>        struct inode *inode = filp->f_dentry->d_inode;
>        page_buf_bmap_t map;
>@@ -1628,7 +1589,7 @@
>                 */
>                status = __pagebuf_do_delwri(inode,
>                                rounded_offset, size, buf,
>-                               len, &foff, &map);
>+                               len, &foff, &map, dirty);
>                if (status <= 0)
>                        break;
>                written += status;
>@@ -1646,7 +1607,8 @@
>     struct file * filp,                /* file to write       
>         */
>     char *buf,                 /* buffer address               */
>     size_t len,                        /* size of buffer      
>         */
>-    loff_t * lp)               /* file offset to use and update */
>+    loff_t * lp,               /* file offset to use and update */
>+    int        *dirty)
> {
>        struct inode *inode = filp->f_dentry->d_inode;
>        unsigned long limit = current->rlim[RLIMIT_FSIZE].rlim_cur;
>@@ -1711,7 +1673,7 @@
> 
>                if (!page) {
>                        status = _pagebuf_file_write(filp,
>-                                       buf, len, &foff, pb_flags);
>+                                       buf, len, &foff, 
>pb_flags, dirty);
>                        if (status > 0)
>                                written += status;
> 
>@@ -1748,7 +1710,7 @@
>                        goto unlock;
>                }
> 
>-               __pb_block_commit_write_async(inode, page, &map);
>+               *dirty += __pb_block_commit_write_async(inode, 
>page, &map);
> 
>                len -= bytes;
>                buf += bytes;
>@@ -1773,8 +1735,6 @@
> }
> 
> int pcd_debug = 0;
>-int pcd_skip_locked = 0;
>-int pcd_ilock_failed = 0;
> static int page_cleaner_daemon_started = 0;
> static int daemon_terminate = 0;
> 
>@@ -1783,12 +1743,12 @@
>  * Returns page locked and with an extra reference count.
>  */
> STATIC struct page *
>-probe_page(struct inode *inode, unsigned long index)
>+probe_page(struct inode *inode, unsigned long index, int check)
> {
>        struct page *page;
> 
>        page = __find_lock_page_nowait(inode->i_mapping, index,
>-                               page_hash(inode->i_mapping, index));
>+                               page_hash(inode->i_mapping, 
>index), check);
>        if (!page)
>                return NULL;
>        if (!test_and_clear_bit(PG_delalloc, &(page)->flags)) {
>@@ -1820,26 +1780,33 @@
> kio_cluster_write(struct inode *inode,
>              struct page  *startpage,
>              page_buf_bmap_t *mp,
>-             struct page **cpages)
>+             struct page **cpages,
>+             int np,
>+             int check)
> {
>        unsigned long   tindex, tlast;
>        struct page     **pcp, **pcstart;
>        loff_t          cstart_offset;
>        page_buf_t      *pb;
>        size_t          csize;
>-       int             count = pb_params.p_un.max_cluster;
>+       int             m, count = pb_params.p_un.max_cluster;
> 
>-       pcp = &cpages[MAX_CLUSTER]; /* start from the middle */
>        dprintk(cluster_debug,
>                ("cluster_write: inode 0x%p page 0x%p index 0x%lx\n",
>                        inode, startpage, startpage->index));
>+
>+       if (np && count > np) /* obey limit if supplied */
>+               count = np;
>+       m = count >> 1;         /* start from middle */ 
>+       pcp = &cpages[m];
>        *pcp-- = startpage;
>+       count--;
>        if (startpage->index != 0) {
>                tlast = mp->pbm_offset >> PAGE_CACHE_SHIFT;
>                for (tindex = startpage->index-1; tindex >= tlast &&
>                      pcp >= &cpages[0] && count; tindex--, 
>pcp--, count--)
>                {
>-                       if (!(*pcp = probe_page(inode, tindex)))
>+                       if (!(*pcp = probe_page(inode, tindex, check)))
>                                break;
>                        dprintk(cluster_debug,
>                            ("cluster_write(L): inode 0x%p 
>page 0x%p idx 0x%lx\n",
>@@ -1849,11 +1816,11 @@
>        pcstart = pcp+1;
>        tlast = PAGE_CACHE_ALIGN_LL(mp->pbm_offset + mp->pbm_bsize) >>
>                                                        
>PAGE_CACHE_SHIFT;
>-       for (tindex = startpage->index + 1, pcp = 
>&cpages[MAX_CLUSTER+1];
>-               tindex < tlast && pcp < 
>&cpages[CLUSTER_PAGE_LIST_SIZE] && count;
>+       for (tindex = startpage->index + 1, pcp = &cpages[m+1];
>+               tindex < tlast && pcp < &cpages[2*m] && count;
>                tindex++, pcp++, count--)
>        {
>-               if (!(*pcp = probe_page(inode, tindex)))
>+               if (!(*pcp = probe_page(inode, tindex, check)))
>                        break;
>                dprintk(cluster_debug,
>                        ("cluster_write(R): inode 0x%p page 
>0x%p index 0x%lx\n",
>@@ -1920,7 +1887,8 @@
> STATIC void
> cluster_write(struct inode *inode,
>              unsigned long index,
>-             page_buf_bmap_t *mp)
>+             page_buf_bmap_t *mp,
>+             int check)
> {
>        unsigned long tindex;
>        unsigned long tlast;
>@@ -1930,7 +1898,7 @@
>        if (index != 0) {
>                tlast = mp->pbm_offset >> PAGE_CACHE_SHIFT;
>                for (tindex = index-1; tindex >= tlast; tindex--) {
>-                       if (!(page = probe_page(inode, tindex)))
>+                       if (!(page = probe_page(inode, tindex, check)))
>                                break;
>                        convert_page(inode, page, mp);
>                }
>@@ -1938,13 +1906,12 @@
>        tlast = PAGE_CACHE_ALIGN_LL(mp->pbm_offset + mp->pbm_bsize) >>
>                                                        
>PAGE_CACHE_SHIFT;
>        for (tindex = index + 1; tindex < tlast; tindex++) {
>-               if (!(page = probe_page(inode, tindex)))
>+               if (!(page = probe_page(inode, tindex, check)))
>                        break;
>                convert_page(inode, page, mp);
>        }
> }
> 
>-
> int
> pagebuf_convert_page(struct page *page, int toss, int wait)
> {
>@@ -1972,7 +1939,9 @@
> pagebuf_delalloc_convert(
>        struct page *mm,        /* delalloc page to convert - locked */
>        u_long  flags,          /* flags to pass to bmap call */
>-       struct page **cpages)   /* can we cluster conversion? */ 
>+       struct page **cpages,   /* can we cluster conversion? */ 
>+       int np,                 /* n pages in cpages          */
>+       int check)              /* check flush times          */
> {
>        page_buf_bmap_t maps[PBF_MAX_MAPS];
>        struct inode *inode;
>@@ -1996,7 +1965,7 @@
> 
>        if (error) {
>                if (error == -EAGAIN) {
>-                       pcd_ilock_failed++;
>+                       pb_io_stat.pcd_ilock_failed++;
>                        set_bit(PG_delalloc, &mm->flags);
>                 } else {
>                        printk("PCD: pagebuf_bmap error %d 
>pb_flags 0x%lx\n",
>@@ -2020,13 +1989,13 @@
>        if (cpages) {
>                if (IS_KIOCLUSTER(inode)) {
>                        get_page(mm);
>-                       count = kio_cluster_write(inode, mm, 
>&maps[0], cpages);
>+                       count = kio_cluster_write(inode, mm, 
>&maps[0], cpages, np, check);
>                } else {
>                        hook_buffers_to_page(inode, mm, &maps[0],
>                                                        
>PAGE_CACHE_SHIFT);
>                        set_buffer_dirty_uptodate(mm->buffers);
>                        UnlockPage(mm);
>-                       cluster_write(inode, mm->index, &maps[0]);
>+                       cluster_write(inode, mm->index, 
>&maps[0], check);
>                        count = 1;
>                }
> 
>@@ -2042,6 +2011,8 @@
> }
> 
> int pcd_debug2 = 0;
>+int sum_min = 0;
>+EXPORT_SYMBOL(sum_min);
> 
> STATIC int
> page_cleaner_daemon(void *data)
>@@ -2049,9 +2020,8 @@
>        mem_map_t *mm = &mem_map[0], *mmlast = &mem_map[max_mapnr];
>        u_long flags;
>        struct buffer_head *bh;
>-       int     pb_min_save = PB_MIN_DIRTY_PAGES;
>        struct page **cpages;
>-       int     looped, sum;
>+       int     looped, tsum, sum;
> 
>        /*  Set up the thread  */
>        exit_files(current);
>@@ -2074,7 +2044,6 @@
>        cpages = kmalloc(CLUSTER_PAGE_LIST_SIZE * 
>sizeof(struct page *),
>                                GFP_KERNEL);
> 
>-       mm = &mem_map[0] - 1;
>        while (1) {
>                /*
>                 * If we actually get into a low-memory situation,
>@@ -2082,10 +2051,11 @@
>                 * up on a more timely basis.
>                 */
> 
>-               pcd_skip_locked = 0;
>-               pcd_ilock_failed = 0;
>+               pb_io_stat.pcd_skip_locked = 
>pb_io_stat.pcd_skip_referenced = 0;
>+               pb_io_stat.pcd_ilock_failed = 0;
>                sum = looped = 0;
>-               while (atomic_read(&pb_delalloc_pages) > 
>PB_MIN_DIRTY_PAGES) {
>+               mm = &mem_map[0] - 1;
>+               while (1) {
>                        if (current->need_resched)
>                                schedule();
> 
>@@ -2101,8 +2071,12 @@
>                        }
>                        if (!test_bit(PG_delalloc, &(mm)->flags))
>                                continue;
>+                       if (mm->age >= PAGE_AGE_START && !looped) {
>+                               pb_io_stat.pcd_skip_referenced++;
>+                               continue;
>+                       }
>                        if (TryLockPage(mm)) {
>-                               pcd_skip_locked++;
>+                               pb_io_stat.pcd_skip_locked++;
>                                continue;
>                        }
>                        if (!test_and_clear_bit(PG_delalloc, 
>&(mm)->flags)) {
>@@ -2129,16 +2103,20 @@
> /* since bmap can block, this should be in a different daemon       */
> /*---------------- DELALLOC CONVERT --------------------------------*/
> 
>-                       sum += pagebuf_delalloc_convert(mm,
>-                               PBF_BMAP_TRY_ILOCK, cpages);
>+                       tsum = pagebuf_delalloc_convert(mm,
>+                               PBF_BMAP_TRY_ILOCK, cpages, 0, 0);
>+
>+                       pb_io_stat.pcd_normal_converted += tsum;
>+                       sum += tsum;
> 
>                        /* Do not let too many pages get locked up
>                         * waiting for the queue to open in here
>                         */
>-                       if (sum > 256) {
>+                       if (tsum > 256) {
>                                run_task_queue(&tq_disk);
>-                               sum = 0;
>                        }
>+                       if (sum > sum_min)
>+                               break;
> 
>                }
>                run_task_queue(&tq_disk);
>@@ -2149,18 +2127,9 @@
>                        wake_up_interruptible(&pcd_waitq);
>                        break;
>                }
>-
>-               /*
>-                * if woken up periodically (nothing else to do)
>-                * convert all the pages, else convert only
>-                * to keep watermarks happy.
>-                */
>-               if (interruptible_sleep_on_timeout(&pcd_waitq,
>-                               pb_params.p_un.cluster_interval) == 0)
>-               {
>-                       PB_MIN_DIRTY_PAGES = 0;
>-               } else
>-                       PB_MIN_DIRTY_PAGES = pb_min_save;
>+               interruptible_sleep_on_timeout(&pcd_waitq,
>+                               pb_params.p_un.cluster_interval);
>+               pb_io_stat.pcd_normal_scan++;
>                pcd_active = 1;
>        }
>        kfree(cpages);
>diff -Naur ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.c 
>./fs/xfs/linux/xfs_lrw.c
>--- ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.c  Mon Dec  4 
>13:28:38 2000
>+++ ./fs/xfs/linux/xfs_lrw.c    Fri Dec  1 10:30:10 2000
>@@ -77,7 +77,8 @@
>        char            *buf,
>        size_t          size,
>        loff_t          *offsetp,
>-       int             read)   /* set if read, otherwise this 
>is write */
>+       int             read,   /* set if read, otherwise this 
>is write */
>+       int             *dirty)
> {
>        ssize_t         ret;
>        struct xfs_inode *xip;
>@@ -98,7 +99,7 @@
>                if (!(filp->f_flags & O_INVISIBLE))
>                        xfs_ichgtime(xip, XFS_ICHGTIME_ACC);
>        } else {
>-               ret = pagebuf_generic_file_write(filp, buf, 
>size, offsetp);
>+               ret = pagebuf_generic_file_write(filp, buf, 
>size, offsetp, dirty);
>        }
> out:
>        return(ret);
>@@ -118,6 +119,7 @@
>        vnode_t         *vp;
>        xfs_inode_t     *ip;
> #endif
>+       int dirty = 0;
> 
>        n = XFS_MAX_FILE_OFFSET - *offsetp;
>        if (n <= 0)
>@@ -145,7 +147,8 @@
>        }
> #endif /* CONFIG_XFS_DMAPI */
> 
>-       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 1);
>+       /* dirty doesn't matter */
>+       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 1, &dirty);
>        return(ret);
> }
> 
>@@ -168,7 +171,8 @@
>        xfs_iocore_t    *io,
>        xfs_off_t       offset,
>        xfs_fsize_t     isize,
>-       struct pm       *pmp)
>+       struct pm       *pmp,
>+       int             *dirty)
> {
>        xfs_fileoff_t   last_fsb;
>        xfs_fileoff_t   next_fsb;
>@@ -342,7 +346,7 @@
>                        printk("xfs_zero_last_block: unwritten?\n");
>                }
>        } else {
>-               error = pagebuf_iozero(pb, zero_offset, zero_len);
>+               error = pagebuf_iozero(pb, zero_offset, 
>zero_len, dirty);
>                pagebuf_rele(pb);
>                goto out_lock;
>        }
>@@ -358,7 +362,7 @@
>              ("zlb: pb_iozero pb 0x%p zf 0x%x zl 0x%x\n",
>                pb, zero_offset, zero_len));
> 
>-       if (error = pagebuf_iozero(pb, zero_offset, zero_len)) {
>+       if (error = pagebuf_iozero(pb, zero_offset, zero_len, dirty)) {
>                pagebuf_rele(pb);
>                goto out_lock;
>        }
>@@ -409,7 +413,8 @@
>        xfs_iocore_t    *io,
>        xfs_off_t       offset,
>        xfs_fsize_t     isize,
>-       struct pm       *pmp)
>+       struct pm       *pmp,
>+       int             *dirty)
> {
>        struct inode    *ip = vp->v_inode;
>        xfs_fileoff_t   start_zero_fsb;
>@@ -440,7 +445,7 @@
>         * First handle zeroing the block on which isize resides.
>         * We only zero a part of that block so it is handled 
>specially.
>         */
>-       error = xfs_zero_last_block(ip, io, offset, isize, pmp);
>+       error = xfs_zero_last_block(ip, io, offset, isize, pmp, dirty);
>        if (error) {
>                ASSERT(ismrlocked(io->io_lock, MR_UPDATE));
>                ASSERT(ismrlocked(io->io_iolock, MR_UPDATE));
>@@ -555,7 +560,7 @@
>                }
> 
>                if (imap.br_startblock == DELAYSTARTBLOCK) {
>-                       error = pagebuf_iozero(pb, 0, lsize);
>+                       error = pagebuf_iozero(pb, 0, lsize, dirty);
>                        pagebuf_rele(pb);
>                } else {
>                        pb->pb_bn = XFS_FSB_TO_DB_IO(io, 
>imap.br_startblock);
>@@ -568,7 +573,7 @@
>                                        ("xfs_zero_eof: real 
>time device? use diff inode\n"));
>                        }
> 
>-                       if (error = pagebuf_iozero(pb, 0, lsize)) {
>+                       if (error = pagebuf_iozero(pb, 0, 
>lsize, dirty)) {
>                                pagebuf_rele(pb);
>                                goto out_lock;
>                        }
>@@ -629,6 +634,7 @@
>        int             eventsent = 0;
>        loff_t          savedsize = *offsetp;
> #endif
>+       int             dirty = 0;
> 
>        vp = BHV_TO_VNODE(bdp);
>        xip = XFS_BHVTOI(bdp);
>@@ -704,7 +710,7 @@
>        if (*offsetp > isize && isize) {
>                io->io_writeio_blocks = mp->m_writeio_blocks;
>                ret = xfs_zero_eof(BHV_TO_VNODE(bdp), io, *offsetp,
>-                       isize, NULL);
>+                       isize, NULL, &dirty);
>                if (ret) {
>                        xfs_iunlock(xip, 
>XFS_ILOCK_EXCL|XFS_IOLOCK_EXCL);
>                        return(ret); /* JIMJIM should this be 
>negative? */
>@@ -713,7 +719,7 @@
>        xfs_iunlock(xip, XFS_ILOCK_EXCL);
> 
> retry:
>-       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 0);
>+       ret = xfs_rdwr(bdp, filp, buf, size, offsetp, 0, &dirty);
> 
> #ifdef CONFIG_XFS_DMAPI
>        if ((ret == -ENOSPC) &&
>@@ -754,6 +760,8 @@
>                }
>        }
>        xfs_iunlock(xip, XFS_IOLOCK_EXCL);
>+       if (dirty)
>+               balance_dirty(ip->i_dev);
>        return(ret);
> }
> 
>diff -Naur ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.h 
>./fs/xfs/linux/xfs_lrw.h
>--- ../../xfs-tot/linux/fs/xfs/linux/xfs_lrw.h  Tue Nov 28 
>16:34:23 2000
>+++ ./fs/xfs/linux/xfs_lrw.h    Wed Oct 25 12:37:18 2000
>@@ -48,7 +48,7 @@
> extern int xfs_bdstrat_cb (struct xfs_buf *);
> 
> extern int xfs_zero_eof (vnode_t *, struct xfs_iocore *, xfs_off_t,
>-                               xfs_fsize_t, struct pm *);
>+                               xfs_fsize_t, struct pm *, int *dirty);
> extern ssize_t xfs_read (bhv_desc_t *, struct file *, char *,
>                                size_t, loff_t *);
> extern ssize_t xfs_write (bhv_desc_t *, struct file *, char *,
>diff -Naur ../../xfs-tot/linux/fs/xfs/xfs_inode.c ./fs/xfs/xfs_inode.c
>--- ../../xfs-tot/linux/fs/xfs/xfs_inode.c      Tue Nov 28 
>16:34:30 2000
>+++ ./fs/xfs/xfs_inode.c        Thu Nov 30 10:29:40 2000
>@@ -1707,7 +1707,7 @@
>        cred_t          *credp)
> {
>        xfs_fsize_t     isize;
>-       int             error;
>+       int             error, dirty;
> 
>        ASSERT(ismrlocked(&(ip->i_lock), MR_UPDATE) != 0);
>        ASSERT(ismrlocked(&(ip->i_iolock), MR_UPDATE) != 0);
>@@ -1720,7 +1720,8 @@
>         * xfs_write_file() beyond the end of the file
>         * and any blocks between the old and new file sizes.
>         */
>-       error = xfs_zero_eof(XFS_ITOV(ip), &ip->i_iocore, 
>new_size, isize, NULL);
>+       error = xfs_zero_eof(XFS_ITOV(ip), &ip->i_iocore, 
>new_size, isize,
>+                                                       NULL, &dirty);
>        return error;
> }
> 
>diff -Naur ../../xfs-tot/linux/fs/xfs/xfs_rw.c ./fs/xfs/xfs_rw.c
>--- ../../xfs-tot/linux/fs/xfs/xfs_rw.c Tue Nov 28 16:34:31 2000
>+++ ./fs/xfs/xfs_rw.c   Wed Oct 25 12:11:52 2000
>@@ -690,7 +690,7 @@
>        void            *dio)               
> {
>        xfs_dio_t       *diop = (xfs_dio_t *)dio;
>-       int             relock;
>+       int             relock, dirty;
>        __uint64_t      flush_end;
>        xfs_mount_t     *mp;
> 
>@@ -717,7 +717,8 @@
>                XFS_ILOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD);
>                isize = XFS_SIZE(mp, io);
>                if (offset > isize) {
>-                       xfs_zero_eof(vp, io, offset, isize, 
>diop->xd_pmp);
>+                       xfs_zero_eof(vp, io, offset, isize,
>+                                       diop->xd_pmp, &dirty);
>                }
>                XFS_IUNLOCK(mp, io, XFS_ILOCK_EXCL|XFS_EXTSIZE_RD);
>        }
>diff -Naur ../../xfs-tot/linux/include/linux/page_buf.h 
>./include/linux/page_buf.h
>--- ../../xfs-tot/linux/include/linux/page_buf.h        Tue 
>Nov 28 16:34:57 2000
>+++ ./include/linux/page_buf.h  Fri Dec  1 16:38:38 2000
>@@ -570,7 +570,8 @@
> extern int pagebuf_iozero(             /* zero contents of 
>buffer      */
>                page_buf_t *,           /* buffer to zero      
>         */
>                off_t,                  /* offset in buffer    
>         */
>-               size_t);                /* size of data to 
>zero         */
>+               size_t,                 /* size of data to 
>zero         */
>+               int *);                 /* generated new dirty 
>data?    */
> 
> extern int pagebuf_mapin(              /* make buffer 
>addressable      */
>                page_buf_t *);          /* buffer to make 
>addressable   */
>@@ -635,7 +636,8 @@
>                struct file *,          /* file to write       
>         */
>                char *,                 /* buffer address      
>         */
>                size_t,                 /* size of buffer      
>         */
>-               loff_t *);              /* file offset to use 
>and update */
>+               loff_t *,               /* file offset to use 
>and update */
>+               int *);                 /* dirty indicator     
>         */
> 
>        /*
>         * pagebuf_generic_file_write writes data from the 
>specified file
>diff -Naur ../../xfs-tot/linux/include/linux/pagemap.h 
>./include/linux/pagemap.h
>--- ../../xfs-tot/linux/include/linux/pagemap.h Tue Nov 28 
>16:34:57 2000
>+++ ./include/linux/pagemap.h   Fri Dec  1 16:38:39 2000
>@@ -70,7 +70,7 @@
> extern struct page * __find_lock_page (struct address_space * mapping,
>                                unsigned long index, struct 
>page **hash);
> extern struct page * __find_lock_page_nowait (struct 
>address_space * mapping,
>-                               unsigned long index, struct 
>page **hash);
>+                               unsigned long index, struct 
>page **hash, int);
> extern void lock_page(struct page *page);
> #define find_lock_page(mapping, index) \
>                __find_lock_page(mapping, index, 
>page_hash(mapping, index))
>diff -Naur ../../xfs-tot/linux/include/linux/swap.h 
>./include/linux/swap.h
>--- ../../xfs-tot/linux/include/linux/swap.h    Tue Nov 28 
>16:34:59 2000
>+++ ./include/linux/swap.h      Fri Dec  1 16:36:29 2000
>@@ -208,6 +208,9 @@
> #define ZERO_PAGE_BUG \
>        if (page_count(page) == 0) BUG();
> 
>+#define DELALLOC_DEBUG_PAGE \
>+       if (test_bit(PG_delalloc, &(page)->flags)) BUG();
>+
> #define add_page_to_active_list(page) { \
>        DEBUG_ADD_PAGE \
>        ZERO_PAGE_BUG \
>@@ -228,6 +231,7 @@
> #define add_page_to_inactive_clean_list(page) { \
>        DEBUG_ADD_PAGE \
>        ZERO_PAGE_BUG \
>+       DELALLOC_DEBUG_PAGE \
>        SetPageInactiveClean(page); \
>        list_add(&(page)->lru, &page->zone->inactive_clean_list); \
>        page->zone->inactive_clean_pages++; \
>diff -Naur ../../xfs-tot/linux/mm/filemap.c ./mm/filemap.c
>--- ../../xfs-tot/linux/mm/filemap.c    Tue Nov 28 16:35:03 2000
>+++ ./mm/filemap.c      Thu Nov 30 10:29:41 2000
>@@ -252,6 +252,24 @@
>        spin_unlock(&pagecache_lock);
> }
> 
>+static inline struct page * __find_page_nolock_noref(struct 
>address_space *mapping, unsigned
>long offset, struct page *page)
>+{
>+       goto inside;
>+
>+       for (;;) {
>+               page = page->next_hash;
>+inside:
>+               if (!page)
>+                       goto not_found;
>+               if (page->mapping != mapping)
>+                       continue;
>+               if (page->index == offset)
>+                       break;
>+       }
>+not_found:
>+       return page;
>+}
>+
> static inline struct page * __find_page_nolock(struct 
>address_space *mapping, unsigned long
>offset, struct page *page)
> {
>        goto inside;
>@@ -580,17 +598,19 @@
> }
> 
> struct page * __find_lock_page_nowait(struct address_space *mapping,
>-                               unsigned long offset, struct 
>page **hash)
>+                       unsigned long offset, struct page 
>**hash, int check)
> {
>        struct page *page;
> 
>        spin_lock(&pagecache_lock);
>-       page = __find_page_nolock(mapping, offset, *hash);
>+       page = __find_page_nolock_noref(mapping, offset, *hash);
>        if (page)
>                page_cache_get(page);
>        spin_unlock(&pagecache_lock);
> 
>-       if (page && TryLockPage(page)) {
>+       if (page &&
>+               ((check && page->age >= PAGE_AGE_START) || 
>TryLockPage(page)))
>+       {
>                /* don't wait for page */
>                put_page(page);
>                return NULL;
>diff -Naur ../../xfs-tot/linux/mm/swap.c ./mm/swap.c
>--- ../../xfs-tot/linux/mm/swap.c       Tue Nov 28 16:35:03 2000
>+++ ./mm/swap.c Wed Nov  1 14:03:55 2000
>@@ -173,7 +173,8 @@
>         * inactive_clean list it doesn't need to be perfect...
>         */
>        int maxcount = (page->buffers ? 3 : 2);
>-       page->age = 0;
>+       if (page->age)
>+               return;
>        ClearPageReferenced(page);
> 
>        /*
>@@ -181,8 +182,7 @@
>         * (some pages aren't on any list at all)
>         */
>        if (PageActive(page) && page_count(page) <= maxcount &&
>-                       !page_ramdisk(page) && 
>-                       !test_bit(PG_delalloc, &page->flags))
>+                       !page_ramdisk(page)) 
>        {
> 
>                /*
>@@ -194,7 +194,9 @@
>                 * need to be cleared away) and/or the function calling
>                 * us has an extra reference count on the page.
>                 */
>-               if (page->buffers || page_count(page) == 2) {
>+               if (page->buffers || page_count(page) == 2 
>+                       || test_bit(PG_delalloc, &page->flags))
>+               {
>                        del_page_from_active_list(page);
>                        add_page_to_inactive_dirty_list(page);
>                /*
>-------------------------------- patch ends 
>------------------------------
>
>-- 
>---------------------------------------------------------------
>-----------
>Rajagopal Ananthanarayanan ("ananth")
>Member Technical Staff, SGI.
>---------------------------------------------------------------
>-----------
>

From owner-linux-xfs@oss.sgi.com Tue Dec  5 09:06:06 2000
Received:  by oss.sgi.com id <S553984AbQLERF4>;
	Tue, 5 Dec 2000 09:05:56 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:39512 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553980AbQLERFh>;
	Tue, 5 Dec 2000 09:05:37 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA23204
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 09:05:37 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA10218; Tue, 5 Dec 2000 11:04:16 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA54521; Tue, 5 Dec 2000 11:04:16 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB5H4Fj22815;
	Tue, 5 Dec 2000 11:04:15 -0600
Message-ID: <3A2D200F.61AC777A@thebarn.com>
Date:   Tue, 05 Dec 2000 11:04:15 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Hiroshi Aono <h-aono@ap.jp.nec.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <geelzn47ys.wl@hpc.bs1.fc.nec.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hiroshi Aono wrote:

> Hi,
>
> I tried to run XFS on IA64, but kernel panic occurs.
> I got 11202000XFSdevel.patch.gz and compiled.
> Then I run the kernel on IA64 machine which is provided by Intel. (2cpu, 1Gmem, xfs on SCSI disk)
>
> Mkfs works fine.
>
> [root@luna aono]# mkfs -t xfs -b size=16384 -f /dev/sdc1
> meta-data=/dev/sdc1              isize=256    agcount=8, agsize=8033 blks
> data     =                       bsize=16384  blocks=64258, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=16384
> log      =internal log           bsize=16384  blocks=1000
> realtime =none                   extsz=65536  blocks=0, rtextents=0
>
> However the kernel crashed at xlog_bread when I mounted the filesystem.
> First, I trapped at xlog_bread and xfsbdstrat.
>
> [root@luna aono]# mount -t xfs /dev/sdc1 /mnt/xfs
>
> Instruction breakpoint #1 at 0xe0000000007db470
> e0000000007db470 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
> e0000000007db471 <xfsbdstrat+0x1>:             addl r14=1055048,r1
> e0000000007db472 <xfsbdstrat+0x2>:             mov r36=b0
> Entering kdb (0x31e88000) on processor 0 [0]kdb> go
>
> Start mounting filesystem: sd(8,33)
> Instruction breakpoint #0 at 0xe0000000007804a0
> e0000000007804a0 <xlog_bread>: [MII]       alloc r43=ar.pfs,16,12,0
> e0000000007804a1 <xlog_bread+0x1>:             addl r14=1055048,r1
> e0000000007804a2 <xlog_bread+0x2>:             mov r42=b0
> Entering kdb (0x31e88000) on processor 0 [0]kdb> go
>
> Instruction breakpoint #1 at 0xe0000000007db470
> e0000000007db470 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
> e0000000007db471 <xfsbdstrat+0x1>:             addl r14=1055048,r1
> e0000000007db472 <xfsbdstrat+0x2>:             mov r36=b0
> Entering kdb (0x31e88000) on processor 0 [0]kdb> go
>
> Instruction breakpoint #0 at 0xe0000000007804a0
> e0000000007804a0 <xlog_bread>: [MII]       alloc r43=ar.pfs,16,12,0
> e0000000007804a1 <xlog_bread+0x1>:             addl r14=1055048,r1
> e0000000007804a2 <xlog_bread+0x2>:             mov r42=b0
> Entering kdb (0x31e88000) on processor 0 [0]kdb> go
>
> Unable to handle kernel paging request at virtual address 00000000000001d0
> mount[300]: Oops 8813272891392
> Entering kdb (0x31e88000) on processor 0 Panic: <NULL>
> due to panic @ 0x7806d0
>  psr: 0x0000101008026030   ifs: 0x8000000000000610    ip: 0xe0000000007806d0
> unat: 0x0000000000000000   pfs: 0x0000000000000590   rsc: 0x0000000000000003
> rnat: 0x0000000000000590  bsps: 0x0000000000000003    pr: 0x000000000002e553
> ldrs: 0x0000000000000000   ccv: 0x0000000000000000  fpsr: 0x0009804c8a70033f
>   b0: 0xe000000000782c30    b6: 0xe000000000502f70    b7: 0xe000000000521270
>   r1: 0xe000000000ce1e40    r2: 0xe000000031e8f970    r3: 0x000000000002e513
>   r8: 0x0000000000000000    r9: 0x0000000000000000   r10: 0x0000000000000000
>  r11: 0x600000000000c140   r12: 0xe000000031e8f9b0   r13: 0xe000000031e88000
>  r14: 0x00000000000001d0   r15: 0xe000000031d13840   r16: 0xe000000031d13810
>  r17: 0x0000000008000001   r18: 0xe000000031d13818   r19: 0x0000000000000200
>  r20: 0xe000000031e897b8   r21: 0x000000000002e593   r22: 0x000000003fe36dc0
>  r23: 0x80000000ffdf5f30   r24: 0x80000000ffdf5ee0   r25: 0x80000000ffdf5f40
>  r26: 0x000000003ff48010   r27: 0xe000000000de22d8   r28: 0xe000000000521270
>  r29: 0x0000000000000001   r30: 0xe000000000c94080   r31: 0x600000000000c110
> &regs = 0xe000000031e8f820
> [0]kdb> bt
> Ret Address (ip)    Mem Stack (sp) Reg Stack (bsp) Name
>
> 0xe0000000007806d0:  v+0x2000000000000000   v+0x3be60eb0   xlog_bread
>
> bt command on IA64 seems not to work.
> I disassembled the crashed point.
> It seems the kernel crashed at before calling xfsbdstrat.
>
>                         292: PCREL21B   assfail
>      296:       d0 02 3c 30 20 00                   ld8 r45=[r15]
>      29c:       08 00 00 50                         br.call.sptk.many b0=290 <xlog_bread+0x180>;;
>      2a0:       10 00 00 00 01 00       [MIB]       nop.m 0x0
>      2a6:       00 00 00 02 00 00                   nop.i 0x0
>      2ac:       20 00 00 40                         br 2c0 <xlog_bread+0x1b0>
>      2b0:       00 00 00 00 01 00       [MII]       nop.m 0x0
>      2b6:       40 22 d9 ac 29 00                   dep.z r36=r36,9,23
>      2bc:       00 00 04 00                         nop.i 0x0
>      2c0:       01 78 00 50 01 21       [MII]       adds r15=128,r40
>      2c6:       70 42 95 00 42 00                   adds r39=40,r37
>      2cc:       02 29 01 84                         adds r16=16,r37;;
>      2d0:       04 70 00 1e 18 10       [MLX]       ld8 r14=[r15]
>      2d6:       08 00 00 00 00 20                   movl r17=0x8000001
>      2dc:       12 00 00 60
>      2e0:       02 00 00 00 01 00       [MII]       nop.m 0x0
>      2e6:       30 01 90 2c 00 c0                   sxt4 r19=r36;;
>      2ec:       e1 48 01 80                         add r14=r14,r41
>      2f0:       02 78 00 4b 00 21       [MII]       adds r15=64,r37
>      2f6:       40 42 a3 00 42 00                   adds r36=104,r40;;
>      2fc:       00 00 04 00                         nop.i 0x0
>      300:       00 00 38 4e 98 11       [MII]       st8 [r39]=r14
>      306:       20 c1 94 00 42 a0                   adds r18=24,r37
>      30c:       05 28 01 84                         mov r45=r37
>      310:       0b 70 00 20 10 10       [MMI]       ld4 r14=[r16];;
>      316:       e0 88 38 1c 40 00                   or r14=r17,r14
>      31c:       00 00 04 00                         nop.i 0x0;;
>      320:       08 00 38 20 90 11       [MMI]       st4 [r16]=r14
>      326:       00 98 3c 30 23 00                   st8 [r15]=r19
>      32c:       00 00 04 00                         nop.i 0x0
>      330:       0b 70 00 48 18 10       [MMI]       ld8 r14=[r36];;
>      336:       e0 80 3a 06 42 00                   adds r14=464,r14
>      33c:       00 00 04 00                         nop.i 0x0;;
>      340:       0a 78 00 1c 18 10       [MMI]       ld8 r15=[r14];; <- crashed
>      346:       00 78 48 30 23 00                   st8 [r18]=r15
>      34c:       00 00 04 00                         nop.i 0x0
>      350:       11 60 01 48 18 10       [MIB]       ld8 r44=[r36]
>                         352: PCREL21B   xfsbdstrat
>      356:       00 00 00 02 00 00                   nop.i 0x0
>      35c:       08 00 00 50                         br.call.sptk.many b0=350 <xlog_bread+0x240>;;
>      360:       11 60 01 4a 00 21       [MIB]       mov r44=r37
>
> /*
>  * nbblks should be uint, but oh well.  Just want to catch that 32-bit length.
>  */
> int
> xlog_bread(xlog_t       *log,
>            xfs_daddr_t  blk_no,
>            int          nbblks,
>            xfs_buf_t    *bp)
> {
>         int error;
>
>         ASSERT(log);
>         ASSERT(nbblks > 0);
>         ASSERT(BBTOB(nbblks) <= XFS_BUF_SIZE(bp));
>         ASSERT(bp);
>
>         XFS_BUF_SET_ADDR(bp, log->l_logBBstart + blk_no);
>         XFS_BUF_READ(bp);
>         XFS_BUF_BUSY(bp);
>         XFS_BUF_SET_COUNT(bp, BBTOB(nbblks));
>         XFS_BUF_SET_TARGET(bp, &log->l_mp->m_logdev_targ);
>
>         xfsbdstrat(log->l_mp, bp);
>         if (error = xfs_iowait(bp)) {
>                 xfs_ioerror_alert("xlog_bread", log->l_mp,
>                                   XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp));
>                 return (error);
>         }
>         return error;
> }       /* xlog_bread */
>
> What is wrong? can you help me?

Well these things are always difficult to just "look at" and figure out what is wrong.

But it looks like a bad pointer someplace.

Do you have XFS compiled with DEBUG turned on?
If not recompile the xfs module and try running again.
If the log structure or xfs_buf_t is NULL the ASSERTs at the
begging of the function should catch the fact.

If that doesn't work start printing out all the fields of the log structure that are
referenced.
log->l_mp->m_logdev_targ
and
log->l_mp


>
>
> Hiroshi Aono, NEC Solutions
> (h-aono@ap.jp.nec.com)


From owner-linux-xfs@oss.sgi.com Tue Dec  5 09:33:25 2000
Received:  by oss.sgi.com id <S553999AbQLERdG>;
	Tue, 5 Dec 2000 09:33:06 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:18026 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553983AbQLERdC>;
	Tue, 5 Dec 2000 09:33:02 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA01953
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 09:33:01 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA10557; Tue, 5 Dec 2000 11:30:28 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA62216; Tue, 5 Dec 2000 11:30:24 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB5HUOj23007;
	Tue, 5 Dec 2000 11:30:24 -0600
Message-ID: <3A2D262F.39DCCD4C@thebarn.com>
Date:   Tue, 05 Dec 2000 11:30:23 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tony Gale <gale@syntax.dera.gov.uk>
CC:     "Lord, Steve" <SLord@tricord.com>, linux-xfs@oss.sgi.com
Subject: Re: ADD 804570 - The elevator bug
References: <XFMail.20001205132813.gale@syntax.dera.gov.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Tony Gale wrote:

> On 05-Dec-2000 Lord, Steve wrote:
> >
> > Fixing the elevator should be as simple as either getting hold of
> > elvtune which can tweak these parameters or changing them in the
> > code (probably elevator.c) I am in a hotel room in Denver and I
> > don't have direct access to source at the moment, or I would point
> > you at the right places.
>
> Ok, will back it out for now.
>

the params that Steve as referring to is in the last structure defined
in
elevator.h
8192,                           /* read passovers */            \
 16384,                          /* write passovers */           \

Bumping these number down helps the problem, but doesn't fix it.
(they start out at 1 million and 2 million)


I'm working with a patch from Jens Axboe that clean up the
elevator quite a bit.  Unfortunately the system will panic
when kiobuf io is used. I'm working on tracking down the problem.

>
> >
> > [ Side note on repair and the lost+found directory - the first
> > thing
> > repair does is remove this directory without removing its contents,
> > which means that if you run repair with a lost+found with contents
> > you will always get unlinked files. If you want to keep the files
> > then move them somewhere else (renaming lost+found would work) or
> > just delete them between repair runs. I do not know the reasoning
> > behind this logic, the authors or repair left SGI a long time
> > ago.
>
> Yes, it's just slightly annoying, and I can't see a reason for it
> either.
>
> >
> > You state that your news server hangs after about a week - this is
> > the thing which needs digging into I think. Have you tried dropping
> > into kdb when this happens - a dump of all stack traces might be a
> > good starting point.
> >
>
> I'll put my hands up and admit to being less than proactive on
> tracking down the actual problem than I should have been. Was more
> concerned with not being able to get innd to work after resetting.
> Will do a more thorough job next time (hoping there won't be a next
> time :-) )

Please let us know if it does happen, we won't be able to track the
problem
down it if we don't know about it. We all want to see this thing
stabilize.




-Russell


From owner-linux-xfs@oss.sgi.com Tue Dec  5 11:24:26 2000
Received:  by oss.sgi.com id <S554069AbQLETYR>;
	Tue, 5 Dec 2000 11:24:17 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3422 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553722AbQLETYL>; Tue, 5 Dec 2000 11:24:11 -0800
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA09641
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 11:32:17 -0800 (PST)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from localhost (kenmcd@localhost)
	by rattle.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id GAA70722;
	Wed, 6 Dec 2000 06:22:48 +1100 (AEDT)
X-Authentication-Warning: rattle.melbourne.sgi.com: kenmcd owned process doing -bs
Date:   Wed, 6 Dec 2000 06:22:48 +1100
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
Reply-To: kenmcd@sgi.com
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
In-Reply-To: <3A2D200F.61AC777A@thebarn.com>
Message-ID: <Pine.SGI.4.21.0012060619000.2576811-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 5 Dec 2000, Russell Cattelan wrote:

> Hiroshi Aono wrote:
> 
> > Hi,
> >
> > I tried to run XFS on IA64, but kernel panic occurs.

The page size on IA64 is unlikely to be 4K bytes, so this already in
potentially dangerous territory.

We have an IA64 system locally, and now that Keith has kdb close to
working we may have some capacity to investigate XFS on IA64, but this
is not realistically expected to work without some changes relative to
the current CVS tree.


From owner-linux-xfs@oss.sgi.com Tue Dec  5 12:53:37 2000
Received:  by oss.sgi.com id <S554087AbQLEUxR>;
	Tue, 5 Dec 2000 12:53:17 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:10067 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554070AbQLEUxB>;
	Tue, 5 Dec 2000 12:53:01 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA20152
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 12:53:00 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA04119; Tue, 5 Dec 2000 12:45:30 -0800 (PST)
Message-ID: <3A2D54B6.8C24942@sgi.com>
Date:   Tue, 05 Dec 2000 12:48:54 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     kenmcd@sgi.com
CC:     Russell Cattelan <cattelan@thebarn.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <Pine.SGI.4.21.0012060619000.2576811-100000@rattle.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ken McDonell wrote:
> 
> On Tue, 5 Dec 2000, Russell Cattelan wrote:
> 
> > Hiroshi Aono wrote:
> >
> > > Hi,
> > >
> > > I tried to run XFS on IA64, but kernel panic occurs.
> 
> The page size on IA64 is unlikely to be 4K bytes, so this already in
> potentially dangerous territory.
> 

We don't really have any manifest constants in XFS tied to 4K, AFAICT.
The only restriction is that blocksize is tied to PAGE_SIZE &
PAGE_CACHE_SIZE ... both of which should be same for a given ARCH.

Internally we had tried XFS on IA64 about 3 months back.
At that time some things were functional and the instability
mostly came from the hardware ...


--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue Dec  5 13:42:57 2000
Received:  by oss.sgi.com id <S553717AbQLEVmh>;
	Tue, 5 Dec 2000 13:42:37 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:4720 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553651AbQLEVmL>;
	Tue, 5 Dec 2000 13:42:11 -0800
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA04192
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 13:42:09 -0800 (PST)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from localhost (kenmcd@localhost)
	by rattle.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id IAA29360;
	Wed, 6 Dec 2000 08:40:49 +1100 (AEDT)
X-Authentication-Warning: rattle.melbourne.sgi.com: kenmcd owned process doing -bs
Date:   Wed, 6 Dec 2000 08:40:49 +1100
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
Reply-To: kenmcd@sgi.com
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     Russell Cattelan <cattelan@thebarn.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
In-Reply-To: <3A2D54B6.8C24942@sgi.com>
Message-ID: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 5 Dec 2000, Rajagopal Ananthanarayanan wrote:

> Ken McDonell wrote:
> > 
> > On Tue, 5 Dec 2000, Russell Cattelan wrote:
> > 
> > > Hiroshi Aono wrote:
> > >
> > > > Hi,
> > > >
> > > > I tried to run XFS on IA64, but kernel panic occurs.
> > 
> > The page size on IA64 is unlikely to be 4K bytes, so this already in
> > potentially dangerous territory.
> > 
> 
> We don't really have any manifest constants in XFS tied to 4K, AFAICT.
> The only restriction is that blocksize is tied to PAGE_SIZE &
> PAGE_CACHE_SIZE ... both of which should be same for a given ARCH.

Good, that is better than I had understood the situation to be.

Warning: following question based on ignorance.

    Will mkfs by default choose a blocksize that satisifies the
    "restriction is that blocksize is tied to PAGE_SIZE &
    PAGE_CACHE_SIZE"?

And what _exactly_ does this restriction mean, given the semantic
imprecision of "tied to"?

> Internally we had tried XFS on IA64 about 3 months back.
> At that time some things were functional and the instability
> mostly came from the hardware ...


From owner-linux-xfs@oss.sgi.com Tue Dec  5 13:51:37 2000
Received:  by oss.sgi.com id <S554082AbQLEVv1>;
	Tue, 5 Dec 2000 13:51:27 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:17015 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554068AbQLEVvQ>; Tue, 5 Dec 2000 13:51:16 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id NAA06314
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 13:59:21 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA20991; Wed, 6 Dec 2000 08:49:53 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id IAA89163; Wed, 6 Dec 2000 08:49:51 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10012060849.ZM192744@wobbly.melbourne.sgi.com>
Date:   Wed, 6 Dec 2000 08:49:50 -0400
In-Reply-To: Ken McDonell <kenmcd@melbourne.sgi.com>
        "Re: panic occurs on IA64" (Dec  6,  8:40am)
References: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     kenmcd@sgi.com, Rajagopal Ananthanarayanan <ananth@sgi.com>
Subject: Re: panic occurs on IA64
Cc:     Russell Cattelan <cattelan@thebarn.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi,

On Dec 6,  8:40am, Ken McDonell wrote:
> Subject: Re: panic occurs on IA64
> ...
> 
>     Will mkfs by default choose a blocksize that satisifies the
>     "restriction is that blocksize is tied to PAGE_SIZE &
>     PAGE_CACHE_SIZE"?
> 

no - mkfs default blocksize is always 4K.

it would be fairly trivial to add a mkfs getpagesize(2) check
and print a warning if these don't match (we could remove it
later when the work has been done to fix this)... shall I?

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Tue Dec  5 14:03:38 2000
Received:  by oss.sgi.com id <S554091AbQLEWD2>;
	Tue, 5 Dec 2000 14:03:28 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:62072 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554088AbQLEWDG>; Tue, 5 Dec 2000 14:03:06 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07214
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 14:11:14 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA14223; Tue, 5 Dec 2000 16:01:41 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA89184; Tue, 5 Dec 2000 16:01:41 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB5M1fS02113;
	Tue, 5 Dec 2000 16:01:41 -0600
Message-ID: <3A2D65C4.64584227@thebarn.com>
Date:   Tue, 05 Dec 2000 16:01:40 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
CC:     kenmcd@sgi.com, Rajagopal Ananthanarayanan <ananth@sgi.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com> <10012060849.ZM192744@wobbly.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Nathan Scott wrote:

> hi,
>
> On Dec 6,  8:40am, Ken McDonell wrote:
> > Subject: Re: panic occurs on IA64
> > ...
> >
> >     Will mkfs by default choose a blocksize that satisifies the
> >     "restriction is that blocksize is tied to PAGE_SIZE &
> >     PAGE_CACHE_SIZE"?
> >
>
> no - mkfs default blocksize is always 4K.
>
> it would be fairly trivial to add a mkfs getpagesize(2) check
> and print a warning if these don't match (we could remove it
> later when the work has been done to fix this)... shall I?

Sounds like a good idea.

>
>
> cheers.
>
> --
> Nathan


From owner-linux-xfs@oss.sgi.com Tue Dec  5 14:06:38 2000
Received:  by oss.sgi.com id <S554093AbQLEWG2>;
	Tue, 5 Dec 2000 14:06:28 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30329 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554090AbQLEWGK>; Tue, 5 Dec 2000 14:06:10 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07247
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 14:14:18 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA14245; Tue, 5 Dec 2000 16:04:52 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA99822; Tue, 5 Dec 2000 16:04:51 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB5M4pS02122;
	Tue, 5 Dec 2000 16:04:51 -0600
Message-ID: <3A2D6683.A90A38E@thebarn.com>
Date:   Tue, 05 Dec 2000 16:04:51 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     kenmcd@sgi.com
CC:     Rajagopal Ananthanarayanan <ananth@sgi.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Ken McDonell wrote:

> On Tue, 5 Dec 2000, Rajagopal Ananthanarayanan wrote:
>
> > Ken McDonell wrote:
> > >
> > > On Tue, 5 Dec 2000, Russell Cattelan wrote:
> > >
> > > > Hiroshi Aono wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I tried to run XFS on IA64, but kernel panic occurs.
> > >
> > > The page size on IA64 is unlikely to be 4K bytes, so this already in
> > > potentially dangerous territory.
> > >
> >
> > We don't really have any manifest constants in XFS tied to 4K, AFAICT.
> > The only restriction is that blocksize is tied to PAGE_SIZE &
> > PAGE_CACHE_SIZE ... both of which should be same for a given ARCH.

Well since 8k pages have shown to be a problem; ie ye old 1024k sb
I'm guessing that the 16k pages will give a problem.
Actually I'm curious to see if the sb writes are 2048k?!

Does somebody have an alpha set up that I could log into and
try adding some printks.



>
>
> Good, that is better than I had understood the situation to be.
>
> Warning: following question based on ignorance.
>
>     Will mkfs by default choose a blocksize that satisifies the
>     "restriction is that blocksize is tied to PAGE_SIZE &
>     PAGE_CACHE_SIZE"?
>
> And what _exactly_ does this restriction mean, given the semantic
> imprecision of "tied to"?
>
> > Internally we had tried XFS on IA64 about 3 months back.
> > At that time some things were functional and the instability
> > mostly came from the hardware ...


From owner-linux-xfs@oss.sgi.com Tue Dec  5 14:07:58 2000
Received:  by oss.sgi.com id <S554095AbQLEWHj>;
	Tue, 5 Dec 2000 14:07:39 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:55302 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554092AbQLEWH3>;
	Tue, 5 Dec 2000 14:07:29 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA13762
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 14:07:29 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA04256; Tue, 5 Dec 2000 14:00:56 -0800 (PST)
Message-ID: <3A2D6663.9F9E53E@sgi.com>
Date:   Tue, 05 Dec 2000 14:04:19 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>
CC:     kenmcd@sgi.com, Russell Cattelan <cattelan@thebarn.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com> <10012060849.ZM192744@wobbly.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Nathan Scott wrote:
> 
> hi,
> 
> On Dec 6,  8:40am, Ken McDonell wrote:
> > Subject: Re: panic occurs on IA64
> > ...
> >
> >     Will mkfs by default choose a blocksize that satisifies the
> >     "restriction is that blocksize is tied to PAGE_SIZE &
> >     PAGE_CACHE_SIZE"?
> >
> 
> no - mkfs default blocksize is always 4K.
> 
> it would be fairly trivial to add a mkfs getpagesize(2) check
> and print a warning if these don't match (we could remove it
> later when the work has been done to fix this)... shall I?
> 

Indeed. You had the right question, Ken. Yes, we should
make the blocksize default to the pagesize ... regardless
of when we get non-page-sized blocks working, I can imagine
that page-sized blocks will be best performing ignoring
fragmentation issues.

BTW, by "tied to" I meant that the I/O routines only deal
with page-sized blocks ... it's probably not a huge change
to get less-than-page-sized blocks to work (we had 512-byte
blocks working about 6 months back). Large-than-page-sized
blocks is mostly an unknown quantity, implementation-wise.

Finally, a question for Hiroshi: can you please let us know
what block-size you used in mkfs? And, what was the
PAGE_SIZE in your kernel? If you let mkfs take the
defaults, can you please try again with whatever PAGE_SIZE
is for your machine?

thanks,

ananth.

From owner-linux-xfs@oss.sgi.com Tue Dec  5 15:20:19 2000
Received:  by oss.sgi.com id <S554007AbQLEXUJ>;
	Tue, 5 Dec 2000 15:20:09 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:64263 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553692AbQLEXUA>; Tue, 5 Dec 2000 15:20:00 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA03292
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 15:28:06 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id KAA21134; Wed, 6 Dec 2000 10:18:27 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>, kenmcd@sgi.com,
        Russell Cattelan <cattelan@thebarn.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64 
In-reply-to: Your message of "Tue, 05 Dec 2000 14:04:19 -0800."
             <3A2D6663.9F9E53E@sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 06 Dec 2000 10:18:26 +1100
Message-ID: <2380.976058306@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 05 Dec 2000 14:04:19 -0800, 
Rajagopal Ananthanarayanan <ananth@sgi.com> wrote:
>Finally, a question for Hiroshi: can you please let us know
>what block-size you used in mkfs? And, what was the
>PAGE_SIZE in your kernel? If you let mkfs take the
>defaults, can you please try again with whatever PAGE_SIZE
>is for your machine?

FYI, IA64 has different page sizes in different regions of the kernel.
The kernel code is a single page of 256M.  The vmalloc region has a
compile time selectable page size, default is 16K.  The getpagesize
syscall returns the compile time selected page size.  You can have a
file system created by a kernel with one page size being read by a
kernel with a different page size.


From owner-linux-xfs@oss.sgi.com Tue Dec  5 15:46:48 2000
Received:  by oss.sgi.com id <S553977AbQLEXqj>;
	Tue, 5 Dec 2000 15:46:39 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:7494 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553715AbQLEXqY>;
	Tue, 5 Dec 2000 15:46:24 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA16443
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 15:46:24 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA04411; Tue, 5 Dec 2000 15:38:46 -0800 (PST)
Message-ID: <3A2D7D52.F306DA65@sgi.com>
Date:   Tue, 05 Dec 2000 15:42:10 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Keith Owens <kaos@melbourne.sgi.com>
CC:     Nathan Scott <nathans@wobbly.melbourne.sgi.com>, kenmcd@sgi.com,
        Russell Cattelan <cattelan@thebarn.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <2380.976058306@kao2.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Keith Owens wrote:

> 
> FYI, IA64 has different page sizes in different regions of the kernel.
> The kernel code is a single page of 256M.  The vmalloc region has a
> compile time selectable page size, default is 16K.  The getpagesize
> syscall returns the compile time selected page size.  You can have a
> file system created by a kernel with one page size being read by a
> kernel with a different page size.

Kernel regions are not in question, so it shouldn't matter
if its pages are of different size than that used by the pagecache.

Also, re: booting kernels of different "user" pagesizes:
we currently have code that will refuse to mount a file-system
that is created with a non-page-sized blocks ...

-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue Dec  5 15:52:28 2000
Received:  by oss.sgi.com id <S554027AbQLEXwT>;
	Tue, 5 Dec 2000 15:52:19 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:12616 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553967AbQLEXv7>;
	Tue, 5 Dec 2000 15:51:59 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA17521
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 15:51:57 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22105; Wed, 6 Dec 2000 10:50:38 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id KAA32164; Wed, 6 Dec 2000 10:50:36 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10012061050.ZM185905@wobbly.melbourne.sgi.com>
Date:   Wed, 6 Dec 2000 10:50:35 -0400
In-Reply-To: Rajagopal Ananthanarayanan <ananth@sgi.com>
        "Re: panic occurs on IA64" (Dec  5,  2:04pm)
References: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com> 
	<10012060849.ZM192744@wobbly.melbourne.sgi.com> 
	<3A2D6663.9F9E53E@sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
Subject: Re: panic occurs on IA64
Cc:     kenmcd@sgi.com, Russell Cattelan <cattelan@thebarn.com>,
        Hiroshi Aono <h-aono@ap.jp.nec.com>, linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi Ananth,

On Dec 5,  2:04pm, Rajagopal Ananthanarayanan wrote:
> Subject: Re: panic occurs on IA64
> ...
> Finally, a question for Hiroshi: can you please let us know
> what block-size you used in mkfs? And, what was the

This was in the original post - I believe Hiroshi used 16K
pages, but I no longer have the original mail to check - oh
actually, here it is -
http://oss.sgi.com/projects/linux-xfs/indexed/msg02479.html

> PAGE_SIZE in your kernel? If you let mkfs take the
> defaults, can you please try again with whatever PAGE_SIZE
> is for your machine?

I'm not sure whether 16K is the PAGE_SIZE...

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Tue Dec  5 17:03:38 2000
Received:  by oss.sgi.com id <S554014AbQLFBDT>;
	Tue, 5 Dec 2000 17:03:19 -0800
Received: from TYO202.gate.nec.co.jp ([202.247.6.41]:62988 "EHLO
        TYO202.gate.nec.co.jp") by oss.sgi.com with ESMTP
	id <S553698AbQLFBDP>; Tue, 5 Dec 2000 17:03:15 -0800
Received: from mailsv.nec.co.jp ([10.7.68.90])
	by TYO202.gate.nec.co.jp (8.9.3/3.7W00120420) with ESMTP id KAA08062;
	Wed, 6 Dec 2000 10:03:08 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP
	id KAA05365; Wed, 6 Dec 2000 10:01:56 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp. (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48])
	by mahler.hpc.bs1.fc.nec.co.jp (8.9.3/3.7W-HPC5.1E(common)) with ESMTP id JAA30193;
	Wed, 6 Dec 2000 09:56:36 +0900
Date:   Wed, 06 Dec 2000 09:56:36 +0900
Message-ID: <gesno2pdtn.wl@hpc.bs1.fc.nec.co.jp>
From:   Hiroshi Aono <h-aono@ap.jp.nec.com>
To:     ananth@sgi.com
Cc:     nathans@wobbly.melbourne.sgi.com, kenmcd@sgi.com,
        cattelan@thebarn.com, h-aono@ap.jp.nec.com, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
In-Reply-To: In your message of "Tue, 05 Dec 2000 14:04:19 -0800"
	<3A2D6663.9F9E53E@sgi.com>
References: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com>
	<10012060849.ZM192744@wobbly.melbourne.sgi.com>
	<3A2D6663.9F9E53E@sgi.com>
User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada)
 CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch
 9) (Canyonlands) (i386-pc-linux)
MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Tue, 05 Dec 2000 14:04:19 -0800,
Rajagopal Ananthanarayanan <ananth@sgi.com> wrote:

Hi,

> Finally, a question for Hiroshi: can you please let us know
> what block-size you used in mkfs? And, what was the
> PAGE_SIZE in your kernel? If you let mkfs take the
> defaults, can you please try again with whatever PAGE_SIZE
> is for your machine?

I specified 16KB.

 #mkfs -t xfs -b size=16384 -f /dev/sdc1

IA64 default page size is 16KB. 
mkfs could not accept except 16KB.
PAGE_SIZE seems tuneable (4K,8K,16K,64K), so I will try to change the page size.
What is the most recommended size?

regards,

Hiroshi Aono, NEC Solutions
(h-aono@ap.jp.nec.com)

From owner-linux-xfs@oss.sgi.com Tue Dec  5 17:40:09 2000
Received:  by oss.sgi.com id <S554094AbQLFBj7>;
	Tue, 5 Dec 2000 17:39:59 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26138 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553698AbQLFBjf>; Tue, 5 Dec 2000 17:39:35 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA01929
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 17:47:42 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA18920
	for linux-xfs@oss.sgi.com; Wed, 6 Dec 2000 12:38:15 +1100 (EST)
Date:   Wed, 6 Dec 2000 12:38:15 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012060138.MAA18920@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - mkfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:80031a
Date:  Tue Dec  5 17:36:29 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/mkfs/mountinfo.c - 1.5
cmd/xfs/mkfs/mountinfo.h - 1.3
	- sync with Andries' 2.10r code fore autodetecting other filesystems -
	  adds cramfs, hpfs, hfs.

cmd/xfs/mkfs/xfs_mkfs.c - 1.180
	- take a guess at the optimal blocksize rather than just saying 4K all
	  the time.  if getpagesize gives us a valid xfs blocksize, use that;
	  otherwise fall back to 4K.


From owner-linux-xfs@oss.sgi.com Tue Dec  5 17:53:39 2000
Received:  by oss.sgi.com id <S554097AbQLFBx3>;
	Tue, 5 Dec 2000 17:53:29 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:4474 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553719AbQLFBxP>;
	Tue, 5 Dec 2000 17:53:15 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA12279
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 17:53:14 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA04569; Tue, 5 Dec 2000 17:47:41 -0800 (PST)
Message-ID: <3A2D9B88.45C73E02@sgi.com>
Date:   Tue, 05 Dec 2000 17:51:04 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Hiroshi Aono <h-aono@ap.jp.nec.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <Pine.SGI.4.21.0012060837260.2580968-100000@rattle.melbourne.sgi.com>
		<10012060849.ZM192744@wobbly.melbourne.sgi.com>
		<3A2D6663.9F9E53E@sgi.com> <gesno2pdtn.wl@hpc.bs1.fc.nec.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hiroshi Aono wrote:

> 
> I specified 16KB.
> 
>  #mkfs -t xfs -b size=16384 -f /dev/sdc1
> 

Ok, I looked back at your original mail ...

At the point of the fault you got:

-----------
Unable to handle kernel paging request at virtual address 00000000000001d0
----------

0x1d0 == 464, which matches with the assembly:

---------
     330:       0b 70 00 48 18 10       [MMI]       ld8 r14=[r36];;
     336:       e0 80 3a 06 42 00                   adds r14=464,r14
     33c:       00 00 04 00                         nop.i 0x0;;
     340:       0a 78 00 1c 18 10       [MMI]       ld8 r15=[r14];; <- crashed
     346:       00 78 48 30 23 00                   st8 [r18]=r15
     34c:       00 00 04 00                         nop.i 0x0
     350:       11 60 01 48 18 10       [MIB]       ld8 r44=[r36]
                        352: PCREL21B   xfsbdstrat
     356:       00 00 00 02 00 00                   nop.i 0x0
     35c:       08 00 00 50                         br.call.sptk.many b0=350
<xlog_bread+0x240>;;
---------------

Which rougly corresponds to this line in source:

	xfsbdstrat(log->l_mp, bp);

So, "log" seems to be zero at this point, which doesn't make
much sense.

Now, there was an important bug fix that went into this (fs/xfs/xfs_log_recover.c)
file recently (2000/12/03). The bug was introduced 2000/11/16.
>From your mail, again:

----------
I got 11202000XFSdevel.patch.gz and compiled.
------------

So, it's likely that you are getting affected by this bug.
Can you apply this patch and see if it helps?

-------------------- patch begin --------------------
--- /usr/tmp/TmpDir.31153-0/linux/fs/xfs/xfs_log_recover.c_1.197        Tue Dec  5 17:44:32 2000
+++ linux/fs/xfs/xfs_log_recover.c      Mon Dec  4 13:28:38 2000
@@ -1215,7 +1215,8 @@
        old_ptr = item->ri_buf[item->ri_cnt-1].i_addr;
        old_len = item->ri_buf[item->ri_cnt-1].i_len;
 
-       ptr = kmem_realloc(old_ptr, len+old_len, old_len, 0); /* s, d, l */
+       ptr = kmem_realloc(old_ptr, len+old_len, old_len, 0); 
+        bcopy(dp , &ptr[old_len], len); /* s, d, l */
        item->ri_buf[item->ri_cnt-1].i_len += len;
        item->ri_buf[item->ri_cnt-1].i_addr = ptr;
        return 0;
-------------------- patch end -----------------------



--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue Dec  5 18:17:09 2000
Received:  by oss.sgi.com id <S554101AbQLFCQs>;
	Tue, 5 Dec 2000 18:16:48 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:60956 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554098AbQLFCQ1>; Tue, 5 Dec 2000 18:16:27 -0800
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA02064
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 18:24:36 -0800 (PST)
	mail_from (ananth@waco.engr.sgi.com)
Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA75955 for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 18:15:56 -0800 (PST)
Received: (from ananth@localhost)
	by waco.engr.sgi.com (8.11.0/8.11.0) id eB62Eoa31267
	for linux-xfs@oss.sgi.com; Tue, 5 Dec 2000 18:14:50 -0800
Date:   Tue, 5 Dec 2000 18:14:50 -0800
From:   Ananth Ananthanarayanan <ananth@waco.engr.sgi.com>
Message-Id: <200012060214.eB62Eoa31267@waco.engr.sgi.com>
Subject: TAKE - Fix MIPS64 build
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Tue Dec  5 18:12:53 PST 2000
Workarea:  waco.engr.sgi.com:/build1/ananth/xfs-tot

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80033a
linux/fs/xfs/xfs_bit.c - 1.11
	- Use types.h from the kernel tree (support) ... fixes MIPS64 compilation.



From owner-linux-xfs@oss.sgi.com Tue Dec  5 20:52:19 2000
Received:  by oss.sgi.com id <S554100AbQLFEwJ>;
	Tue, 5 Dec 2000 20:52:09 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9508 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554098AbQLFEvs>; Tue, 5 Dec 2000 20:51:48 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA01265
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 20:59:54 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA51391
	for linux-xfs@oss.sgi.com; Wed, 6 Dec 2000 15:50:23 +1100 (EST)
Date:   Wed, 6 Dec 2000 15:50:23 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012060450.PAA51391@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - headers
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

a little more (minor) header file work prompted by Ananth's mips64
work.  nuked a dangling pseudo-inc/sys/attribute.h (unused).

Modid:  2.4.x-xfs:slinx:80039a
Date:  Tue Dec  5 20:48:11 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_bit.c - 1.12
	- remove ident, use xfs.h like everything else (aid portability).

linux/fs/xfs/xfs_bmap.c - 1.262
	- remove unused header.

linux/fs/xfs/xfs_da_btree.c - 1.115
	- replace kdb reference & include.

linux/fs/xfs/xfs_grio.h - 1.3
	- remove redundant includes.


From owner-linux-xfs@oss.sgi.com Tue Dec  5 21:48:20 2000
Received:  by oss.sgi.com id <S554099AbQLFFsK>;
	Tue, 5 Dec 2000 21:48:10 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:354 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553672AbQLFFrt>;
	Tue, 5 Dec 2000 21:47:49 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA05972
	for <linux-xfs@oss.sgi.com>; Tue, 5 Dec 2000 21:47:46 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA52844
	for linux-xfs@oss.sgi.com; Wed, 6 Dec 2000 16:45:12 +1100 (EST)
Date:   Wed, 6 Dec 2000 16:45:12 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012060545.QAA52844@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - logprint
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:80041a
Date:  Tue Dec  5 21:44:48 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/logprint/xfs_log_recover.c - 1.7
	- sync up with bcopy fix in the kernel code.


From owner-linux-xfs@oss.sgi.com Wed Dec  6 01:52:31 2000
Received:  by oss.sgi.com id <S553661AbQLFJwM>;
	Wed, 6 Dec 2000 01:52:12 -0800
Received: from relay.dera.gov.uk ([192.5.29.49]:21796 "HELO relay.dera.gov.uk")
	by oss.sgi.com with SMTP id <S553653AbQLFJvo>;
	Wed, 6 Dec 2000 01:51:44 -0800
Received: (qmail 30495 invoked from network); 6 Dec 2000 09:51:41 +0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by relay.dera.gov.uk with SMTP; 6 Dec 2000 09:51:41 +0000
Content-Length: 1460
Message-ID: <XFMail.20001206095141.gale@syntax.dera.gov.uk>
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <6DEE94132593D41182D200508BDCA59014E594@mail.tricord.com>
Date:   Wed, 06 Dec 2000 09:51:41 -0000 (GMT)
From:   Tony Gale <gale@syntax.dera.gov.uk>
To:     "Lord, Steve" <SLord@tricord.com>
Subject: xfs crash bt (was: RE: ADD 804570 - The elevator bug)
Cc:     linux-xfs@oss.sgi.com, Russell Cattelan <cattelan@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 05-Dec-2000 Lord, Steve wrote:
> 
> You state that your news server hangs after about a week - this is
> the thing which needs digging into I think. Have you tried dropping
> into kdb when this happens - a dump of all stack traces might be a
> good starting point.
> 

Well, I didn't have to wait too long. Here's my hand copied bt. If
you need any more debugging, let me know, I still have the machine in
kdb:

CPU1
----

find_inode+0x14 (0xf7676e00, 0x11028129, 0xf7e47568, 0x0, 0x0)
ihold4+0x58 (0xf7676e00, 0x11028129, 0x0, 0x0)
vn_get+0x28 (0xe9a9e5cc, 0xe07333db8, 0x0)
xfs_iget_core+0x1d2 (0x0, 0xf7b6d000, 0x0, 0x11028129, 0x0)
xfs_iget+0x2d (0xf7b6d000, 0x0, 0x11028129, 0x0, 0x0)
xfs_dir_lookup_int+0x137 (0x0, 0xd28169a8, 0x5, 0xdcad980, 0xe0755f00)
xfs_lookup+0x8a (0xd28169a8, 0xdacad980, 0xe0733efc, 0xe0733f00, 0x0)
linvfs_lookup+0x70 (0xd29034c0, 0xdacad920)
real_looup+0x7d
path_walk+0x64f
__user_walk+0x3c
sys_newlstat+0x17
system_call_0x33

CPU0
----

stext_lock+0x2180
permission+0x32 (0xf76807c0, 0x1)
path_walk+0x878 (0xe2857010, 0xf75fdfa0)
__user_walk+0x3c (0x940b718, 0x9, 0xf75ddfa0)
sys_access+0x86 (0x940b718, 0x4, 0xbffff0a4, 0xbffff036, 0xbffff006)

-tony


---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
Reappraisal, n.:
	An abrupt change of mind after being found out.

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.

From owner-linux-xfs@oss.sgi.com Wed Dec  6 02:33:11 2000
Received:  by oss.sgi.com id <S553725AbQLFKdC>;
	Wed, 6 Dec 2000 02:33:02 -0800
Received: from TYO201.gate.nec.co.jp ([202.32.8.214]:25352 "EHLO
        TYO201.gate.nec.co.jp") by oss.sgi.com with ESMTP
	id <S553699AbQLFKcm>; Wed, 6 Dec 2000 02:32:42 -0800
Received: from mailsv.nec.co.jp (mailsv [10.7.68.90])
	by TYO201.gate.nec.co.jp (8.9.3/3.7W00120617) with ESMTP id TAA19847;
	Wed, 6 Dec 2000 19:32:40 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP
	id TAA15126; Wed, 6 Dec 2000 19:31:42 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp. (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48])
	by mahler.hpc.bs1.fc.nec.co.jp (8.9.3/3.7W-HPC5.1E(common)) with ESMTP id TAA31005;
	Wed, 6 Dec 2000 19:26:19 +0900
Date:   Wed, 06 Dec 2000 19:26:19 +0900
Message-ID: <gelmttq20k.wl@hpc.bs1.fc.nec.co.jp>
From:   Hiroshi Aono <h-aono@ap.jp.nec.com>
To:     cattelan@thebarn.com
Cc:     h-aono@ap.jp.nec.com, linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
In-Reply-To: In your message of "Tue, 05 Dec 2000 11:04:15 -0600"
	<3A2D200F.61AC777A@thebarn.com>
References: <geelzn47ys.wl@hpc.bs1.fc.nec.co.jp>
	<3A2D200F.61AC777A@thebarn.com>
User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada)
 CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch
 9) (Canyonlands) (i386-pc-linux)
MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

> Do you have XFS compiled with DEBUG turned on?
> If not recompile the xfs module and try running again.
> If the log structure or xfs_buf_t is NULL the ASSERTs at the
> begging of the function should catch the fact.
>
> If that doesn't work start printing out all the fields of the log structure that are
> referenced.
> log->l_mp->m_logdev_targ
> and
> log->l_mp

DEBIG is on.
I specified .config for XFS as follows.

CONFIG_PAGE_BUF=y
CONFIG_XFS_FS=y
# CONFIG_XFS_DMAPI is not set
# CONFIG_XFS_QUOTA is not set 
CONFIG_XFS_DEBUG=y
CONFIG_XFS_VNODE_TRACING=y
CONFIG_XFS_SUPPORT=y

> So, it's likely that you are getting affected by this bug.
> Can you apply this patch and see if it helps?

Thanks.
I got latest xfs_log_recover.c and added printk debugging codes in xfs_bread.

--------------------8<--------------------
int
xlog_bread(xlog_t       *log,
           xfs_daddr_t  blk_no,
           int          nbblks,
           xfs_buf_t    *bp)
{
        int error;

        ASSERT(log);
        ASSERT(nbblks > 0);
        ASSERT(BBTOB(nbblks) <= XFS_BUF_SIZE(bp));
        ASSERT(bp);

printk("xlog_bread(1):bp=0x%lx\n",bp);
printk("xlog_bread(1):blk_no=0x%lx\n",blk_no);
printk("xlog_bread(1):log=0x%lx\n",log);
printk("xlog_bread(1):log->l_mp=0x%lx\n",log->l_mp);
printk("xlog_bread(1):log->l_mp->m_logdev_targ=0x%lx\n",log->l_mp->m_logdev_targ);
printk("xlog_bread(1):log->l_logBBstart=0x%lx\n",log->l_logBBstart);

        XFS_BUF_SET_ADDR(bp, log->l_logBBstart + blk_no);
        XFS_BUF_READ(bp);
        XFS_BUF_BUSY(bp);
        XFS_BUF_SET_COUNT(bp, BBTOB(nbblks));
        XFS_BUF_SET_TARGET(bp, &log->l_mp->m_logdev_targ);

printk("xlog_bread(2):bp=0x%lx\n",bp);
printk("xlog_bread(2):blk_no=0x%lx\n",blk_no);
printk("xlog_bread(2):log=0x%lx\n",log);
printk("xlog_bread(2):log->l_mp=0x%lx\n",log->l_mp);
printk("xlog_bread(2):log->l_mp->m_logdev_targ=0x%lx\n",log->l_mp->m_logdev_targ);
printk("xlog_bread(2):log->l_logBBstart=0x%lx\n",log->l_logBBstart);

        xfsbdstrat(log->l_mp, bp);
        if (error = xfs_iowait(bp)) {
                xfs_ioerror_alert("xlog_bread", log->l_mp,
                                  XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp));
                return (error);
        }
        return error;
}       /* xlog_bread */
--------------------8<--------------------

First, I booted PAGE_SIZE=16KB kernel.
But crashed.

--------------------8<--------------------
Instruction breakpoint #1 at 0xe0000000007db620
e0000000007db620 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db621 <xfsbdstrat+0x1>:             addl r14=1054664,r1
e0000000007db622 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
Start mounting filesystem: sd(8,33)
Instruction breakpoint #0 at 0xe0000000007804a0
e0000000007804a0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007804a1 <xlog_bread+0x1>:             addl r14=1054664,r1
e0000000007804a2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2df800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe00000003f080500
xlog_bread(1):log->l_mp=0xe00000003dd41000
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003dd41000
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2df800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe00000003f080500
xlog_bread(2):log->l_mp=0xe00000003dd41000
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003dd41000
xlog_bread(2):log->l_logBBstart=0xfb100
Instruction breakpoint #1 at 0xe0000000007db620
e0000000007db620 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db621 <xfsbdstrat+0x1>:             addl r14=1054664,r1
e0000000007db622 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe0000000007804a0
e0000000007804a0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007804a1 <xlog_bread+0x1>:             addl r14=1054664,r1
e0000000007804a2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2df800
xlog_bread(1):blk_no=0x7cff
xlog_bread(1):log=0xe00000003f080500
xlog_bread(1):log->l_mp=0x0
Unable to handle kernel paging request at virtual address 00000000000001d8
mount[298]: Oops 8813272891392
Entering kdb (0x3c370000) on processor 0 Panic: <NULL>
due to panic @ 0x780700
 psr: 0x0000101008026030   ifs: 0x8000000000000691    ip: 0xe000000000780700  
unat: 0x0000000000000000   pfs: 0x0000000000000691   rsc: 0x0000000000000003  
rnat: 0x0000000000000000  bsps: 0xe000000000d83578    pr: 0x000000000002a693  
ldrs: 0x0000000000000000   ccv: 0x0000000000000000  fpsr: 0x0009804c8a70033f  
  b0: 0xe0000000007806e0    b6: 0xe0000000008fd130    b7: 0xe000000000521270  
  r1: 0xe000000000ce1fc0    r2: 0xe00000003c377980    r3: 0x0000000000000000  
  r8: 0x000000000000001c    r9: 0x0000000000000896   r10: 0x0000000000000000  
 r11: 0x0000000000a5d993   r12: 0xe00000003c3779b0   r13: 0xe00000003c370000  
 r14: 0x00000000000001d0   r15: 0xe000000000de9d30   r16: 0x00000000000001d8  
 r17: 0xe000000000e2d84c   r18: 0xe000000000e2d840   r19: 0xe000000000d83558  
 r20: 0xe000000000e1e0b0   r21: 0x0000000000000000   r22: 0xe000000000de3210  
 r23: 0x80000000ffdf5f30   r24: 0x80000000ffdf5ee0   r25: 0x80000000ffdf5f40  
 r26: 0x000000003ff48010   r27: 0xe000000000de22d8   r28: 0xe000000000521270  
 r29: 0x0000000000000001   r30: 0xe000000000c94080   r31: 0xe00000003e826894  
&regs = 0xe00000003c377820
--------------------8<--------------------

Next, I booted PAGE_SIZE=8KB kernel. Panic occurred again.

--------------------8<--------------------
Instruction breakpoint #1 at 0xe0000000007cef10
e0000000007cef10 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007cef11 <xfsbdstrat+0x1>:             addl r14=1056448,r1
e0000000007cef12 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> go
XFS: bad magic number
XFS: SB validate failed
Instruction breakpoint #1 at 0xe0000000007cef10
e0000000007cef10 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007cef11 <xfsbdstrat+0x1>:             addl r14=1056448,r1
e0000000007cef12 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> gi o
Start mounting filesystem: sd(8,34)
Instruction breakpoint #0 at 0xe0000000007741f0
e0000000007741f0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007741f1 <xlog_bread+0x1>:             addl r14=1056448,r1
e0000000007741f2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> goo 
xlog_bread(1):bp=0xe0000000326f79c0
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033220540
xlog_bread(1):log->l_mp=0xe00000003274d800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003274d800
xlog_bread(1):log->l_logBBstart=0xfb080
xlog_bread(2):bp=0xe0000000326f79c0
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033220540
xlog_bread(2):log->l_mp=0xe00000003274d800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003274d800
xlog_bread(2):log->l_logBBstart=0xfb080
Instruction breakpoint #1 at 0xe0000000007cef10
e0000000007cef10 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007cef11 <xfsbdstrat+0x1>:             addl r14=1056448,r1
e0000000007cef12 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe0000000007741f0
e0000000007741f0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007741f1 <xlog_bread+0x1>:             addl r14=1056448,r1
e0000000007741f2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> go
eth0: card reports no resources.
xlog_bread(1):bp=0xe0000000326f79c0
xlog_bread(1):blk_no=0x3e7f
xlog_bread(1):log=0xe000000033220540
xlog_bread(1):log->l_mp=0x0
Unable to handle kernel paging request at virtual address 00000000000001d8
mount[301]: Oops 8813272891392
Entering kdb (0x32788000) on processor 0 Panic: <NULL>
due to panic @ 0x774450
 psr: 0x0000101008026030   ifs: 0x8000000000000691    ip: 0xe000000000774450  
unat: 0x0000000000000000   pfs: 0x0000000000000691   rsc: 0x0000000000000003  
rnat: 0x0000000000000000  bsps: 0xe000000000d77578    pr: 0x000000000002a693  
ldrs: 0x0000000000000000   ccv: 0x0000000000000000  fpsr: 0x0009804c8a70033f  
  b0: 0xe000000000774430    b6: 0xe0000000008f0a20    b7: 0xe000000000515270  
  r1: 0xe000000000cd58c0    r2: 0xe00000003278f980    r3: 0x0000000000000000  
  r8: 0x000000000000001c    r9: 0x0000000000000896   r10: 0x0000000000000000  
 r11: 0x0000000000a5d993   r12: 0xe00000003278f9b0   r13: 0xe000000032788000  
 r14: 0x00000000000001d0   r15: 0xe000000000ddf030   r16: 0x00000000000001d8  
 r17: 0xe000000000e1f84c   r18: 0xe000000000e1f840   r19: 0xe000000000d77558  
 r20: 0xe000000000e100b0   r21: 0x0000000000000000   r22: 0xe000000000dd7208  
 r23: 0x80000000ffdf5f30   r24: 0x80000000ffdf5ee0   r25: 0x80000000ffdf5f40  
 r26: 0x000000003ff48010   r27: 0xe000000000dd62d0   r28: 0xe000000000515270  
 r29: 0x0000000000000001   r30: 0xe000000000c88080   r31: 0x9ffffffffffebd34  
&regs = 0xe00000003278f820
--------------------8<--------------------

Then, I booted PAGE_SIZE=4KB kernel.

--------------------8<--------------------
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
Start mounting filesystem: sd(8,35)
Instruction breakpoint #0 at 0xe00000000076de40
e00000000076de40 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e00000000076de41 <xlog_bread+0x1>:             addl r14=1048856,r1
e00000000076de42 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe00000000076de40
e00000000076de40 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e00000000076de41 <xlog_bread+0x1>:             addl r14=1048856,r1
e00000000076de42 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x257f
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x257f
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe00000000076de40
e00000000076de40 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e00000000076de41 <xlog_bread+0x1>:             addl r14=1048856,r1
e00000000076de42 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x12bf
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x12bf
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> bc *
Breakpoint 0 at 0xe00000000076de40 in dr0 cleared
Breakpoint 1 at 0xe0000000007c8fa0 in dr0 cleared
[0]kdb> go
eth0: card reports no resources.
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x95f
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x95f
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x4af
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x4af
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x257
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x257
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x12b
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x12b
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x95
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x95
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x4a
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x4a
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x25
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x25
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x12
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x12
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x9
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x9
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x4
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x4
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x2
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x2
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Ending clean XFS mount for filesystem: sd(8,35)
--------------------8<--------------------

mount was successful!!!

When PAGE_SIZE is 4K, XFS seems to work. 
But 8K and 16K are NG. In this case, log->l_mp seems zero.

Is this a restriction?
If this is so, I hope it will be improved.
If needs more info, please let me know.

Regards,

Hiroshi Aono, NEC Solutions
(h-aono@ap.jp.nec.com)

From owner-linux-xfs@oss.sgi.com Wed Dec  6 03:02:21 2000
Received:  by oss.sgi.com id <S553721AbQLFLCB>;
	Wed, 6 Dec 2000 03:02:01 -0800
Received: from hermes.mixx.net ([212.84.196.2]:14608 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553699AbQLFLBk>;
	Wed, 6 Dec 2000 03:01:40 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 6F45CF80D
	for <linux-xfs@oss.sgi.com>; Wed,  6 Dec 2000 12:01:38 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id CAF052CAC2; Wed,  6 Dec 2000 12:01:01 +0100 (CET)
From:   gale@syntax.dera.gov.uk (Tony Gale)
X-Newsgroups: innominate.list.sgi.xfs
Subject: xfs crash bt (was: RE: ADD 804570 - The elevator bug)
Date:   6 Dec 2000 12:00:54 +0100
Organization: innominate AG, Berlin, Germany
Lines:  51
Distribution: local
Message-ID: <XFMail.20001206095141.gale@syntax.dera.gov.uk>
References: <6DEE94132593D41182D200508BDCA59014E594@mail.tricord.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Trace: mate.bln.innominate.de 976100454 7865 10.0.0.1 (6 Dec 2000 11:00:54 GMT)
X-Complaints-To: news@innominate.de
Content-Length: 1460
X-Delivered-To: news-innominate.list.sgi.xfs@localhost.bln.innominate.de
X-Received: from hermes.mixx.net (hermes.mixx.net [212.84.196.2]) 	by mate.bln.innominate.de (Postfix) with ESMTP id 348FB2CAE0 	for <news-innominate.list.sgi.xfs@innominate.de>; Wed,  6 Dec 2000 10:52:47 +0100 (CET)
X-Received: from oss.sgi.com (oss.sgi.com [216.32.174.190]) 	by hermes.mixx.net (Postfix) with ESMTP id 4AFE1F806 	for <news-innominate.list.sgi.xfs@innominate.de>; Wed,  6 Dec 2000 10:52:47 +0100 (CET)
X-Received:  by oss.sgi.com id <S553661AbQLFJwM>; 	Wed, 6 Dec 2000 01:52:12 -0800
X-Received: from relay.dera.gov.uk ([192.5.29.49]:21796 "HELO relay.dera.gov.uk") 	by oss.sgi.com with SMTP id <S553653AbQLFJvo>; 	Wed, 6 Dec 2000 01:51:44 -0800
X-Received: (qmail 30495 invoked from network); 6 Dec 2000 09:51:41 +0000
X-Received: from syntax.dera.gov.uk (146.80.9.50)   by relay.dera.gov.uk with SMTP; 6 Dec 2000 09:51:41 +0000
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
X-In-Reply-To: <6DEE94132593D41182D200508BDCA59014E594@mail.tricord.com>
X-To:   "Lord, Steve" <SLord@tricord.com>
X-Cc:   linux-xfs@oss.sgi.com, Russell Cattelan <cattelan@thebarn.com>
X-Precedence: bulk
To:     news-innominate.list.sgi.xfs@innominate.de
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 05-Dec-2000 Lord, Steve wrote:
> 
> You state that your news server hangs after about a week - this is
> the thing which needs digging into I think. Have you tried dropping
> into kdb when this happens - a dump of all stack traces might be a
> good starting point.
> 

Well, I didn't have to wait too long. Here's my hand copied bt. If
you need any more debugging, let me know, I still have the machine in
kdb:

CPU1
----

find_inode+0x14 (0xf7676e00, 0x11028129, 0xf7e47568, 0x0, 0x0)
ihold4+0x58 (0xf7676e00, 0x11028129, 0x0, 0x0)
vn_get+0x28 (0xe9a9e5cc, 0xe07333db8, 0x0)
xfs_iget_core+0x1d2 (0x0, 0xf7b6d000, 0x0, 0x11028129, 0x0)
xfs_iget+0x2d (0xf7b6d000, 0x0, 0x11028129, 0x0, 0x0)
xfs_dir_lookup_int+0x137 (0x0, 0xd28169a8, 0x5, 0xdcad980, 0xe0755f00)
xfs_lookup+0x8a (0xd28169a8, 0xdacad980, 0xe0733efc, 0xe0733f00, 0x0)
linvfs_lookup+0x70 (0xd29034c0, 0xdacad920)
real_looup+0x7d
path_walk+0x64f
__user_walk+0x3c
sys_newlstat+0x17
system_call_0x33

CPU0
----

stext_lock+0x2180
permission+0x32 (0xf76807c0, 0x1)
path_walk+0x878 (0xe2857010, 0xf75fdfa0)
__user_walk+0x3c (0x940b718, 0x9, 0xf75ddfa0)
sys_access+0x86 (0x940b718, 0x4, 0xbffff0a4, 0xbffff036, 0xbffff006)

-tony


---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
Reappraisal, n.:
	An abrupt change of mind after being found out.

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.


From owner-linux-xfs@oss.sgi.com Wed Dec  6 03:02:51 2000
Received:  by oss.sgi.com id <S554068AbQLFLCc>;
	Wed, 6 Dec 2000 03:02:32 -0800
Received: from hermes.mixx.net ([212.84.196.2]:28176 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553716AbQLFLCQ>;
	Wed, 6 Dec 2000 03:02:16 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 5CCFCF810
	for <linux-xfs@oss.sgi.com>; Wed,  6 Dec 2000 12:02:13 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 8C6B92CAB3; Wed,  6 Dec 2000 12:02:12 +0100 (CET)
From:   h-aono@ap.jp.nec.com (Hiroshi Aono)
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: panic occurs on IA64
Date:   6 Dec 2000 12:01:40 +0100
Organization: innominate AG, Berlin, Germany
Lines:  505
Distribution: local
Message-ID: <gelmttq20k.wl@hpc.bs1.fc.nec.co.jp>
References: <geelzn47ys.wl@hpc.bs1.fc.nec.co.jp> 	<3A2D200F.61AC777A@thebarn.com>
Mime-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada")
Content-Type: text/plain; charset=US-ASCII
X-Trace: mate.bln.innominate.de 976100500 8526 10.0.0.1 (6 Dec 2000 11:01:40 GMT)
X-Complaints-To: news@innominate.de
X-Delivered-To: news-innominate.list.sgi.xfs@localhost.bln.innominate.de
X-Received: from hermes.mixx.net (hermes.mixx.net [212.84.196.2]) 	by mate.bln.innominate.de (Postfix) with ESMTP id 09B982CB73 	for <news-innominate.list.sgi.xfs@innominate.de>; Wed,  6 Dec 2000 11:33:25 +0100 (CET)
X-Received: from oss.sgi.com (oss.sgi.com [216.32.174.190]) 	by hermes.mixx.net (Postfix) with ESMTP id 8A109F806 	for <news-innominate.list.sgi.xfs@innominate.de>; Wed,  6 Dec 2000 11:33:24 +0100 (CET)
X-Received:  by oss.sgi.com id <S553725AbQLFKdC>; 	Wed, 6 Dec 2000 02:33:02 -0800
X-Received: from TYO201.gate.nec.co.jp ([202.32.8.214]:25352 "EHLO         TYO201.gate.nec.co.jp") by oss.sgi.com with ESMTP 	id <S553699AbQLFKcm>; Wed, 6 Dec 2000 02:32:42 -0800
X-Received: from mailsv.nec.co.jp (mailsv [10.7.68.90]) 	by TYO201.gate.nec.co.jp (8.9.3/3.7W00120617) with ESMTP id TAA19847; 	Wed, 6 Dec 2000 19:32:40 +0900 (JST)
X-Received: from mahler.hpc.bs1.fc.nec.co.jp (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP 	id TAA15126; Wed, 6 Dec 2000 19:31:42 +0900 (JST)
X-Received: from mahler.hpc.bs1.fc.nec.co.jp. (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) 	by mahler.hpc.bs1.fc.nec.co.jp (8.9.3/3.7W-HPC5.1E(common)) with ESMTP id TAA31005; 	Wed, 6 Dec 2000 19:26:19 +0900
X-To:   cattelan@thebarn.com
X-Cc:   h-aono@ap.jp.nec.com, linux-xfs@oss.sgi.com
X-In-Reply-To: In your message of "Tue, 05 Dec 2000 11:04:15 -0600" 	<3A2D200F.61AC777A@thebarn.com>
X-User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada)  CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch  9) (Canyonlands) (i386-pc-linux)
X-Precedence: bulk
To:     news-innominate.list.sgi.xfs@innominate.de
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

> Do you have XFS compiled with DEBUG turned on?
> If not recompile the xfs module and try running again.
> If the log structure or xfs_buf_t is NULL the ASSERTs at the
> begging of the function should catch the fact.
>
> If that doesn't work start printing out all the fields of the log structure that are
> referenced.
> log->l_mp->m_logdev_targ
> and
> log->l_mp

DEBIG is on.
I specified .config for XFS as follows.

CONFIG_PAGE_BUF=y
CONFIG_XFS_FS=y
# CONFIG_XFS_DMAPI is not set
# CONFIG_XFS_QUOTA is not set 
CONFIG_XFS_DEBUG=y
CONFIG_XFS_VNODE_TRACING=y
CONFIG_XFS_SUPPORT=y

> So, it's likely that you are getting affected by this bug.
> Can you apply this patch and see if it helps?

Thanks.
I got latest xfs_log_recover.c and added printk debugging codes in xfs_bread.

--------------------8<--------------------
int
xlog_bread(xlog_t       *log,
           xfs_daddr_t  blk_no,
           int          nbblks,
           xfs_buf_t    *bp)
{
        int error;

        ASSERT(log);
        ASSERT(nbblks > 0);
        ASSERT(BBTOB(nbblks) <= XFS_BUF_SIZE(bp));
        ASSERT(bp);

printk("xlog_bread(1):bp=0x%lx\n",bp);
printk("xlog_bread(1):blk_no=0x%lx\n",blk_no);
printk("xlog_bread(1):log=0x%lx\n",log);
printk("xlog_bread(1):log->l_mp=0x%lx\n",log->l_mp);
printk("xlog_bread(1):log->l_mp->m_logdev_targ=0x%lx\n",log->l_mp->m_logdev_targ);
printk("xlog_bread(1):log->l_logBBstart=0x%lx\n",log->l_logBBstart);

        XFS_BUF_SET_ADDR(bp, log->l_logBBstart + blk_no);
        XFS_BUF_READ(bp);
        XFS_BUF_BUSY(bp);
        XFS_BUF_SET_COUNT(bp, BBTOB(nbblks));
        XFS_BUF_SET_TARGET(bp, &log->l_mp->m_logdev_targ);

printk("xlog_bread(2):bp=0x%lx\n",bp);
printk("xlog_bread(2):blk_no=0x%lx\n",blk_no);
printk("xlog_bread(2):log=0x%lx\n",log);
printk("xlog_bread(2):log->l_mp=0x%lx\n",log->l_mp);
printk("xlog_bread(2):log->l_mp->m_logdev_targ=0x%lx\n",log->l_mp->m_logdev_targ);
printk("xlog_bread(2):log->l_logBBstart=0x%lx\n",log->l_logBBstart);

        xfsbdstrat(log->l_mp, bp);
        if (error = xfs_iowait(bp)) {
                xfs_ioerror_alert("xlog_bread", log->l_mp,
                                  XFS_BUF_TARGET(bp), XFS_BUF_ADDR(bp));
                return (error);
        }
        return error;
}       /* xlog_bread */
--------------------8<--------------------

First, I booted PAGE_SIZE=16KB kernel.
But crashed.

--------------------8<--------------------
Instruction breakpoint #1 at 0xe0000000007db620
e0000000007db620 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db621 <xfsbdstrat+0x1>:             addl r14=1054664,r1
e0000000007db622 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
Start mounting filesystem: sd(8,33)
Instruction breakpoint #0 at 0xe0000000007804a0
e0000000007804a0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007804a1 <xlog_bread+0x1>:             addl r14=1054664,r1
e0000000007804a2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2df800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe00000003f080500
xlog_bread(1):log->l_mp=0xe00000003dd41000
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003dd41000
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2df800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe00000003f080500
xlog_bread(2):log->l_mp=0xe00000003dd41000
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003dd41000
xlog_bread(2):log->l_logBBstart=0xfb100
Instruction breakpoint #1 at 0xe0000000007db620
e0000000007db620 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db621 <xfsbdstrat+0x1>:             addl r14=1054664,r1
e0000000007db622 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe0000000007804a0
e0000000007804a0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007804a1 <xlog_bread+0x1>:             addl r14=1054664,r1
e0000000007804a2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c370000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2df800
xlog_bread(1):blk_no=0x7cff
xlog_bread(1):log=0xe00000003f080500
xlog_bread(1):log->l_mp=0x0
Unable to handle kernel paging request at virtual address 00000000000001d8
mount[298]: Oops 8813272891392
Entering kdb (0x3c370000) on processor 0 Panic: <NULL>
due to panic @ 0x780700
 psr: 0x0000101008026030   ifs: 0x8000000000000691    ip: 0xe000000000780700  
unat: 0x0000000000000000   pfs: 0x0000000000000691   rsc: 0x0000000000000003  
rnat: 0x0000000000000000  bsps: 0xe000000000d83578    pr: 0x000000000002a693  
ldrs: 0x0000000000000000   ccv: 0x0000000000000000  fpsr: 0x0009804c8a70033f  
  b0: 0xe0000000007806e0    b6: 0xe0000000008fd130    b7: 0xe000000000521270  
  r1: 0xe000000000ce1fc0    r2: 0xe00000003c377980    r3: 0x0000000000000000  
  r8: 0x000000000000001c    r9: 0x0000000000000896   r10: 0x0000000000000000  
 r11: 0x0000000000a5d993   r12: 0xe00000003c3779b0   r13: 0xe00000003c370000  
 r14: 0x00000000000001d0   r15: 0xe000000000de9d30   r16: 0x00000000000001d8  
 r17: 0xe000000000e2d84c   r18: 0xe000000000e2d840   r19: 0xe000000000d83558  
 r20: 0xe000000000e1e0b0   r21: 0x0000000000000000   r22: 0xe000000000de3210  
 r23: 0x80000000ffdf5f30   r24: 0x80000000ffdf5ee0   r25: 0x80000000ffdf5f40  
 r26: 0x000000003ff48010   r27: 0xe000000000de22d8   r28: 0xe000000000521270  
 r29: 0x0000000000000001   r30: 0xe000000000c94080   r31: 0xe00000003e826894  
&regs = 0xe00000003c377820
--------------------8<--------------------

Next, I booted PAGE_SIZE=8KB kernel. Panic occurred again.

--------------------8<--------------------
Instruction breakpoint #1 at 0xe0000000007cef10
e0000000007cef10 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007cef11 <xfsbdstrat+0x1>:             addl r14=1056448,r1
e0000000007cef12 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> go
XFS: bad magic number
XFS: SB validate failed
Instruction breakpoint #1 at 0xe0000000007cef10
e0000000007cef10 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007cef11 <xfsbdstrat+0x1>:             addl r14=1056448,r1
e0000000007cef12 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> gi o
Start mounting filesystem: sd(8,34)
Instruction breakpoint #0 at 0xe0000000007741f0
e0000000007741f0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007741f1 <xlog_bread+0x1>:             addl r14=1056448,r1
e0000000007741f2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> goo 
xlog_bread(1):bp=0xe0000000326f79c0
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033220540
xlog_bread(1):log->l_mp=0xe00000003274d800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003274d800
xlog_bread(1):log->l_logBBstart=0xfb080
xlog_bread(2):bp=0xe0000000326f79c0
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033220540
xlog_bread(2):log->l_mp=0xe00000003274d800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003274d800
xlog_bread(2):log->l_logBBstart=0xfb080
Instruction breakpoint #1 at 0xe0000000007cef10
e0000000007cef10 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007cef11 <xfsbdstrat+0x1>:             addl r14=1056448,r1
e0000000007cef12 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe0000000007741f0
e0000000007741f0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007741f1 <xlog_bread+0x1>:             addl r14=1056448,r1
e0000000007741f2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32788000) on processor 0 [0]kdb> go
eth0: card reports no resources.
xlog_bread(1):bp=0xe0000000326f79c0
xlog_bread(1):blk_no=0x3e7f
xlog_bread(1):log=0xe000000033220540
xlog_bread(1):log->l_mp=0x0
Unable to handle kernel paging request at virtual address 00000000000001d8
mount[301]: Oops 8813272891392
Entering kdb (0x32788000) on processor 0 Panic: <NULL>
due to panic @ 0x774450
 psr: 0x0000101008026030   ifs: 0x8000000000000691    ip: 0xe000000000774450  
unat: 0x0000000000000000   pfs: 0x0000000000000691   rsc: 0x0000000000000003  
rnat: 0x0000000000000000  bsps: 0xe000000000d77578    pr: 0x000000000002a693  
ldrs: 0x0000000000000000   ccv: 0x0000000000000000  fpsr: 0x0009804c8a70033f  
  b0: 0xe000000000774430    b6: 0xe0000000008f0a20    b7: 0xe000000000515270  
  r1: 0xe000000000cd58c0    r2: 0xe00000003278f980    r3: 0x0000000000000000  
  r8: 0x000000000000001c    r9: 0x0000000000000896   r10: 0x0000000000000000  
 r11: 0x0000000000a5d993   r12: 0xe00000003278f9b0   r13: 0xe000000032788000  
 r14: 0x00000000000001d0   r15: 0xe000000000ddf030   r16: 0x00000000000001d8  
 r17: 0xe000000000e1f84c   r18: 0xe000000000e1f840   r19: 0xe000000000d77558  
 r20: 0xe000000000e100b0   r21: 0x0000000000000000   r22: 0xe000000000dd7208  
 r23: 0x80000000ffdf5f30   r24: 0x80000000ffdf5ee0   r25: 0x80000000ffdf5f40  
 r26: 0x000000003ff48010   r27: 0xe000000000dd62d0   r28: 0xe000000000515270  
 r29: 0x0000000000000001   r30: 0xe000000000c88080   r31: 0x9ffffffffffebd34  
&regs = 0xe00000003278f820
--------------------8<--------------------

Then, I booted PAGE_SIZE=4KB kernel.

--------------------8<--------------------
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
Start mounting filesystem: sd(8,35)
Instruction breakpoint #0 at 0xe00000000076de40
e00000000076de40 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e00000000076de41 <xlog_bread+0x1>:             addl r14=1048856,r1
e00000000076de42 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe00000000076de40
e00000000076de40 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e00000000076de41 <xlog_bread+0x1>:             addl r14=1048856,r1
e00000000076de42 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x257f
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x257f
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe00000000076de40
e00000000076de40 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e00000000076de41 <xlog_bread+0x1>:             addl r14=1048856,r1
e00000000076de42 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x12bf
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x12bf
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Instruction breakpoint #1 at 0xe0000000007c8fa0
e0000000007c8fa0 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007c8fa1 <xfsbdstrat+0x1>:             addl r14=1048856,r1
e0000000007c8fa2 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x32a08000) on processor 0 [0]kdb> bc *
Breakpoint 0 at 0xe00000000076de40 in dr0 cleared
Breakpoint 1 at 0xe0000000007c8fa0 in dr0 cleared
[0]kdb> go
eth0: card reports no resources.
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x95f
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x95f
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x4af
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x4af
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x257
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x257
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x12b
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x12b
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x95
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x95
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x4a
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x4a
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x25
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x25
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x12
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x12
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x9
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x9
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x4
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x4
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x2
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x2
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
xlog_bread(1):bp=0xe0000000321c6940
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe000000033263000
xlog_bread(1):log->l_mp=0xe000000032a10800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(1):log->l_logBBstart=0xfb060
xlog_bread(2):bp=0xe0000000321c6940
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe000000033263000
xlog_bread(2):log->l_mp=0xe000000032a10800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe000000032a10800
xlog_bread(2):log->l_logBBstart=0xfb060
Ending clean XFS mount for filesystem: sd(8,35)
--------------------8<--------------------

mount was successful!!!

When PAGE_SIZE is 4K, XFS seems to work. 
But 8K and 16K are NG. In this case, log->l_mp seems zero.

Is this a restriction?
If this is so, I hope it will be improved.
If needs more info, please let me know.

Regards,

Hiroshi Aono, NEC Solutions
(h-aono@ap.jp.nec.com)


From owner-linux-xfs@oss.sgi.com Wed Dec  6 08:27:02 2000
Received:  by oss.sgi.com id <S553724AbQLFQ0x>;
	Wed, 6 Dec 2000 08:26:53 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:2060 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553685AbQLFQ0a>;
	Wed, 6 Dec 2000 08:26:30 -0800
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA00298; Wed, 6 Dec 2000 08:26:30 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id IAA63982;
	Wed, 6 Dec 2000 08:26:29 -0800 (PST)
Date:   Wed, 6 Dec 2000 08:26:29 -0800 (PST)
Message-Id: <200012061626.IAA63982@info.engr.sgi.com>
X-Pv-Incident: 804570 
webPV:  hobbes.denver.sgi.com 
webExec: webpvupdate,pvincident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cbrady@sgi.com)
Subject: ADD 804570 - The elevator bug
To:     nb@sgi.com
Cc:     raa@sgi.com, huovinen@sgi.com, cattelan@sgi.com, mann@sgi.com,
        tbd@sgi.com, rrl@sgi.com, alaffin@sgi.com, cbrady@sgi.com,
        linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=804570

*CC List : raa@sgi.com huovinen@sgi.com cattelan@sgi.com mann@sgi.com tbd@sgi.com rrl@sgi.com alaffin@sgi.com cbrady@sgi.com
 Status : open                        
 Priority : 3                          Assigned Engineer : nb               
 Submitter : coreym                   *Modified User : cbrady               
*Modified User Domain : sgi.com       *Description :
I ran rwtest on a xfs-linux filesystem on the machine permit:

rwtest 100000000:/mnt1/file_1 >/tmp/file_1.out 2>&1 &

This caused df, ls -l, fdisk, and top all to hang.

Permit is running Redhat 6.2 with a 2.4.0-test5 kernel

==========================
ADDITIONAL INFORMATION (ADD)

.....


==========================
ADDITIONAL INFORMATION (ADD)
From: cbrady@sgi.com (BugWorks)
Date: Dec 06 2000 08:26:28AM
==========================

From owner-linux-xfs@oss.sgi.com Wed Dec  6 09:15:22 2000
Received:  by oss.sgi.com id <S553695AbQLFRPM>;
	Wed, 6 Dec 2000 09:15:12 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:17189 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553663AbQLFRO7>;
	Wed, 6 Dec 2000 09:14:59 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA12504
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 09:14:58 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA23080; Wed, 6 Dec 2000 11:12:26 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA51009; Wed, 6 Dec 2000 11:12:25 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB6HCPS04929;
	Wed, 6 Dec 2000 11:12:25 -0600
Message-ID: <3A2E7379.BA137BEF@thebarn.com>
Date:   Wed, 06 Dec 2000 11:12:25 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Hiroshi Aono <h-aono@ap.jp.nec.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: panic occurs on IA64
References: <geelzn47ys.wl@hpc.bs1.fc.nec.co.jp>
		<3A2D200F.61AC777A@thebarn.com> <gelmttq20k.wl@hpc.bs1.fc.nec.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hiroshi Aono wrote:

>
>
> mount was successful!!!
>
> When PAGE_SIZE is 4K, XFS seems to work.

> But 8K and 16K are NG. In this case, log->l_mp seems zero.

Yes that does seem to be the problem.
Of course now the question is: why?

>
>
> Is this a restriction?

Up until this point almost all development/testing has been done on ia32/4k page
systems.
As such problems with 8k or 16k page system have not been identified.

>
> If this is so, I hope it will be improved.

Yes definitely, as resources permit.


>
> If needs more info, please let me know.
>
> Regards,
>
> Hiroshi Aono, NEC Solutions
> (h-aono@ap.jp.nec.com)


From owner-linux-xfs@oss.sgi.com Wed Dec  6 09:46:52 2000
Received:  by oss.sgi.com id <S553736AbQLFRqc>;
	Wed, 6 Dec 2000 09:46:32 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:32310 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553671AbQLFRqB>;
	Wed, 6 Dec 2000 09:46:01 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA20446
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 09:46:01 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA23333; Wed, 6 Dec 2000 11:44:43 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA04179; Wed, 6 Dec 2000 11:44:43 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB6HicS05008;
	Wed, 6 Dec 2000 11:44:38 -0600
Message-ID: <3A2E7B06.59B93BA4@thebarn.com>
Date:   Wed, 06 Dec 2000 11:44:38 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tony Gale <gale@syntax.dera.gov.uk>
CC:     "Lord, Steve" <SLord@tricord.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs crash bt (was: RE: ADD 804570 - The elevator bug)
References: <XFMail.20001206095141.gale@syntax.dera.gov.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Tony Gale wrote:

> On 05-Dec-2000 Lord, Steve wrote:
> >
> > You state that your news server hangs after about a week - this is
> > the thing which needs digging into I think. Have you tried dropping
> > into kdb when this happens - a dump of all stack traces might be a
> > good starting point.
> >
>
> Well, I didn't have to wait too long. Here's my hand copied bt. If
> you need any more debugging, let me know, I still have the machine in
> kdb:
>

Well nothing obvious jumps out at me here, other than a possible
deadlock problem.

Looking at the code related to the backtraces I don't see a common lock
that
might be tripping us up.

In the backtrace; find_inode is that  last  function listed?

We probably need to look at the process table and find out what is
running and what might be stuck.

continue the system "go"
break it again and do the cpu back traces.

Is is possible to get a serial console hooked up?
I would help a great deal in capturing  kdb output.


>
> CPU1
> ----
>
> find_inode+0x14 (0xf7676e00, 0x11028129, 0xf7e47568, 0x0, 0x0)
> ihold4+0x58 (0xf7676e00, 0x11028129, 0x0, 0x0)
> vn_get+0x28 (0xe9a9e5cc, 0xe07333db8, 0x0)
> xfs_iget_core+0x1d2 (0x0, 0xf7b6d000, 0x0, 0x11028129, 0x0)
> xfs_iget+0x2d (0xf7b6d000, 0x0, 0x11028129, 0x0, 0x0)
> xfs_dir_lookup_int+0x137 (0x0, 0xd28169a8, 0x5, 0xdcad980, 0xe0755f00)
> xfs_lookup+0x8a (0xd28169a8, 0xdacad980, 0xe0733efc, 0xe0733f00, 0x0)
> linvfs_lookup+0x70 (0xd29034c0, 0xdacad920)
> real_looup+0x7d
> path_walk+0x64f
> __user_walk+0x3c
> sys_newlstat+0x17
> system_call_0x33
>
> CPU0
> ----
>
> stext_lock+0x2180
> permission+0x32 (0xf76807c0, 0x1)
> path_walk+0x878 (0xe2857010, 0xf75fdfa0)
> __user_walk+0x3c (0x940b718, 0x9, 0xf75ddfa0)
> sys_access+0x86 (0x940b718, 0x4, 0xbffff0a4, 0xbffff036, 0xbffff006)
>
> -tony
>
> ---
> E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
> Reappraisal, n.:
>         An abrupt change of mind after being found out.
>
> The views expressed above are entirely those of the writer
> and do not represent the views, policy or understanding of
> any other person or official body.


From owner-linux-xfs@oss.sgi.com Wed Dec  6 10:03:22 2000
Received:  by oss.sgi.com id <S553740AbQLFSDM>;
	Wed, 6 Dec 2000 10:03:12 -0800
Received: from relay.dera.gov.uk ([192.5.29.49]:28712 "HELO relay.dera.gov.uk")
	by oss.sgi.com with SMTP id <S553735AbQLFSC5>;
	Wed, 6 Dec 2000 10:02:57 -0800
Received: (qmail 21333 invoked from network); 6 Dec 2000 18:02:55 +0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by relay.dera.gov.uk with SMTP; 6 Dec 2000 18:02:55 +0000
Content-Length: 1296
Message-ID: <XFMail.20001206180254.gale@syntax.dera.gov.uk>
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3A2E7B06.59B93BA4@thebarn.com>
Date:   Wed, 06 Dec 2000 18:02:54 -0000 (GMT)
From:   Tony Gale <gale@syntax.dera.gov.uk>
To:     Russell Cattelan <cattelan@thebarn.com>
Subject: Re: xfs crash bt (was: RE: ADD 804570 - The elevator bug)
Cc:     linux-xfs@oss.sgi.com, "Lord, Steve" <SLord@tricord.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On 06-Dec-2000 Russell Cattelan wrote:
> 
> Well nothing obvious jumps out at me here, other than a possible
> deadlock problem.
> 
> Looking at the code related to the backtraces I don't see a common
> lock
> that
> might be tripping us up.
> 
> In the backtrace; find_inode is that  last  function listed?

Well, it's first one listed, but yes.

> 
> We probably need to look at the process table and find out what is
> running and what might be stuck.

I believe the two process stuck are expire (from inn) and slocate.
Both of these would hit the fs pretty hard.

I don't know the code, but could it be a resource starvation problem,
such as out of inodes in the vfs?

> 
> continue the system "go"
> break it again and do the cpu back traces.

Still stuck in the same places (with minor find_inode offset diff).


> 
> Is is possible to get a serial console hooked up?
> I would help a great deal in capturing  kdb output.
> 
> 

Ok, will do so tomorrow, and then try and force a lockup (it's
getting late to be at work here).

Thanks

-tony

---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
Two wrongs are only the beginning.
		-- Kohn

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.

From owner-linux-xfs@oss.sgi.com Wed Dec  6 11:40:43 2000
Received:  by oss.sgi.com id <S553755AbQLFTkd>;
	Wed, 6 Dec 2000 11:40:33 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:3083 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553743AbQLFTkN>;
	Wed, 6 Dec 2000 11:40:13 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA28769
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 11:40:12 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA25046; Wed, 6 Dec 2000 13:38:54 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA86534; Wed, 6 Dec 2000 13:38:53 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eB6JcrS05338;
	Wed, 6 Dec 2000 13:38:53 -0600
Message-ID: <3A2E95CD.CB45802F@thebarn.com>
Date:   Wed, 06 Dec 2000 13:38:53 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tony Gale l <gale@syntax.dera.gov.uk>, linux-xfs@oss.sgi.com
Subject: Re: xfs crash bt (was: RE: ADD 804570 - The elevator bug)
References: <XFMail.20001206180254.gale@syntax.dera.gov.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Tony Gale wrote:

> On 06-Dec-2000 Russell Cattelan wrote:
> >
> > Well nothing obvious jumps out at me here, other than a possible
> > deadlock problem.
> >
> > Looking at the code related to the backtraces I don't see a common
> > lock
> > that
> > might be tripping us up.
> >
> > In the backtrace; find_inode is that  last  function listed?
>
> Well, it's first one listed, but yes.
>
> >
> > We probably need to look at the process table and find out what is
> > running and what might be stuck.
>
> I believe the two process stuck are expire (from inn) and slocate.
> Both of these would hit the fs pretty hard.
>
> I don't know the code, but could it be a resource starvation problem,
> such as out of inodes in the vfs?
>
> >
> > continue the system "go"
> > break it again and do the cpu back traces.
>
> Still stuck in the same places (with minor find_inode offset diff).

This may not be a lock contention problem then, it's possible we are
looping
on something? waiting for some resource?

Did you ever turn down the numbers in the elevator?

Try:
elvtune -r 1024 <dev>
elvtune -w 2048 <dev>

>
>
> >
> > Is is possible to get a serial console hooked up?
> > I would help a great deal in capturing  kdb output.
> >
> >
>
> Ok, will do so tomorrow, and then try and force a lockup (it's
> getting late to be at work here).
>
> Thanks
>
> -tony
>
> ---
> E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
> Two wrongs are only the beginning.
>                 -- Kohn
>
> The views expressed above are entirely those of the writer
> and do not represent the views, policy or understanding of
> any other person or official body.


From owner-linux-xfs@oss.sgi.com Wed Dec  6 17:27:15 2000
Received:  by oss.sgi.com id <S553706AbQLGB1F>;
	Wed, 6 Dec 2000 17:27:05 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:61489 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553678AbQLGB0o>;
	Wed, 6 Dec 2000 17:26:44 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA21196
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 17:26:42 -0800 (PST)
	mail_from (ajag@fudge.melbourne.sgi.com)
Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA02257; Thu, 7 Dec 2000 12:24:09 +1100
Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA02973; Thu, 7 Dec 2000 12:24:05 +1100 (EST)
Date:   Thu, 7 Dec 2000 12:24:05 +1100
From:   Andrew Gildfind <ajag@fudge.melbourne.sgi.com>
To:     thomas.graichen@innominate.de
Cc:     linux-xfs@oss.sgi.com
Subject: Re: sys_attrctl not working on ppc
Message-ID: <20001207122405.A2872@fudge.melbourne.sgi.com>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de> <news-innominate.list.sgi.xfs@innominate.de> <10011101103.ZM113097@wobbly.melbourne.sgi.com> <20001110094151.C333@ysabell> <10011110006.ZM127189@wobbly.melbourne.sgi.com> <news2mail-8uo7od$4lt$1@mate.bln.innominate.de> <10011141059.ZM128320@wobbly.melbourne.sgi.com> <news2mail-8utlfv$8iu$1@mate.bln.innominate.de> <20001201122045.G32822@fudge.melbourne.sgi.com> <news2mail-907m3r$27r$3@mate.bln.innominate.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <news2mail-907m3r$27r$3@mate.bln.innominate.de>; from news-innominate.list.sgi.xfs@innominate.de on Fri, Dec 01, 2000 at 08:05:15AM +0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, Dec 01, 2000 at 08:05:15AM +0000, Thomas Graichen wrote:
> [also changed the subject to something more useful here]
> 
> Andrew Gildfind <ajag@fudge.melbourne.sgi.com> wrote:
> 
> > Hi Thomas,
> 
> > Could you put a printk at the start of the sys_attrctl function defined
> > in linux/fs/stat.c, and rerun the QA test 020, or drive the attribute code
> > directly using xfs_attr, and check whether the printk actually gets called.
> 
> > If it doesn't then we know for sure it's the syscall that isn't hooked up
> > correctly. unistd.h and entry.S looked like the only places which needed
> > to be changed but I may have missed something. If it does hit the the attribute
> > syscall, then there's a more serious problem somewhere else in the code.
> 
> looks like this is the case:
> 
> ...
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> here is sys_attrctl
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> ppc:/usr/src/xfs/cmd/xfs/stress #
> 
> this is the dmesg of check 020 - it gets called - so the problem is
> somethere deeper ... maybe anykind of endian stuff of the parameters?
> (just an idea) ... do you have any other idea?
> 
> t
> 
> -- 
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77             http://www.innominate.com


Couple of observations first:

 - xfs_attr always calls the attr_* and therefore the system call with
   a path, rather than a file descriptor.
 - xfs_attr is always called with ATTR_DONT_FOLLOW - that is it never follows
   symlinks

The code looks like:

	asmlinkage long sys_attrctl(attr_obj_t obj, int type, 
					attr_op_t *ops, int count)
	{
		int		error = 0;
		struct inode	*inode;
		struct dentry	*dentry;
		struct file	*f = NULL;
		struct nameidata nd;

		if (count <= 0)
			return -EINVAL;

		lock_kernel();

		switch (type) {
		case ATTR_TYPE_FD:
			if (! (f = fget(obj.fd))) {
				error = -ENOENT;
				goto unlock;
			}
			dentry = f->f_dentry;
			break;

		case ATTR_TYPE_PATH:
			/* follow symlinks */
			error = user_path_walk(obj.path, &nd);
			if (error)
				goto unlock;
			dentry = nd.dentry;
			break;

		case ATTR_TYPE_LPATH:
			error = user_path_walk_link(obj.path, &nd);
			if (error)
				goto unlock;
			dentry = nd.dentry;
			break;

		case ATTR_TYPE_PID:
			error = -ENOSYS;
			goto unlock;

		default:
			error = -EINVAL;
			goto unlock;
		}


Which means that on the way in (and we know that at least its hitting the
syscall), it will always take the ATTR_TYPE_LPATH case. 

I've had another look at your QA results (ppc.15-11-2000) they give the
following:

	QA output created by 020
	*** list non-existant file
	   *** print attributes
	attr_list: Bad address
	Could not list attributes for <TESTFILE>
	      !!! error return
	*** list non-xfs file (in /proc)
	   *** print attributes
	attr_list: Bad address

	...


The first test checks the non-existent file case, which means that we
should come into the syscall, walk the path and die immediately with
an ENOENT, ie. we should never get into XFS code at all.

The fact that we are getting a bad address even in this case suggests to
me that there maybe something weird happening because the path comes
out of an attr_obj_t structure - are we sure that those structures are
the same size in userland/kernel on PPC?

So... can you whack in another printk just after the switch and check whether
the path lookup ever works - if it does I'm back in stumped-land, if not
we have our culprit..

Andrew

-- 
Andrew Gildfind - R&D Software Engineer - SGI PTG Melbourne Australia
email: ajag@melbourne.sgi.com - work: +61.3.9834.8200 home: +61.3.9421.5335

From owner-linux-xfs@oss.sgi.com Wed Dec  6 18:11:25 2000
Received:  by oss.sgi.com id <S553747AbQLGCLP>;
	Wed, 6 Dec 2000 18:11:15 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:58126 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553696AbQLGCK6>; Wed, 6 Dec 2000 18:10:58 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA03591
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 18:19:06 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA29729
	for linux-xfs@oss.sgi.com; Thu, 7 Dec 2000 13:09:31 +1100 (EST)
Date:   Thu, 7 Dec 2000 13:09:31 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012070209.NAA29729@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:80122a
Date:  Wed Dec  6 18:07:53 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/016 - 1.6
	- test requires finegrained control over log traffic - skip it when
	  run with quotas enabled cos dquots are logged.

cmd/xfs/stress/src/Makefile - 1.21
	- tidy up, add feature.c

cmd/xfs/tools/auto-qa - 1.37
	- add the quota user tools to the set of auto-qa managed
	  (built,installed,tested) code.

cmd/xfs/tools/srcdiff - 1.14
	- we now need xqm.h for qa, will need it for xfsdump too (later).

cmd/xfs/include/xqm.h - 1.1
	- userspace copy of shared kernel header.

cmd/xfs/stress/common.quota - 1.1
	- common quota qa shell routines.

cmd/xfs/stress/src/feature.c - 1.1
	- test whether a filesystem supports certain features.  currently
	  only tests for quota-related features.


From owner-linux-xfs@oss.sgi.com Wed Dec  6 18:26:14 2000
Received:  by oss.sgi.com id <S553770AbQLGC0F>;
	Wed, 6 Dec 2000 18:26:05 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:62022 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553764AbQLGCZy>;
	Wed, 6 Dec 2000 18:25:54 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA02414
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 18:25:53 -0800 (PST)
	mail_from (ananth@waco.engr.sgi.com)
Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA26232 for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 18:25:23 -0800 (PST)
Received: (from ananth@localhost)
	by waco.engr.sgi.com (8.11.0/8.11.0) id eB72OCB00525
	for linux-xfs@oss.sgi.com; Wed, 6 Dec 2000 18:24:12 -0800
Date:   Wed, 6 Dec 2000 18:24:12 -0800
From:   Ananth Ananthanarayanan <ananth@waco.engr.sgi.com>
Message-Id: <200012070224.eB72OCB00525@waco.engr.sgi.com>
Subject: TAKE - fix a merge problem in nfs
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

A previous bug fix now became redundant ...
Weird thing is patch didn't generate a reject.

Date:  Wed Dec  6 18:20:20 PST 2000
Workarea:  waco.engr.sgi.com:/build1/ananth/xfs-tot

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80123a
linux/fs/lockd/svclock.c - 1.11
	- Fix a dangling unlock_kernel() introduced in test11 upgrade.



From owner-linux-xfs@oss.sgi.com Wed Dec  6 19:10:36 2000
Received:  by oss.sgi.com id <S553760AbQLGDKQ>;
	Wed, 6 Dec 2000 19:10:16 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39953 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553734AbQLGDJq>; Wed, 6 Dec 2000 19:09:46 -0800
Received: from waco.engr.sgi.com (waco.engr.sgi.com [163.154.18.95]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA03246
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 19:17:56 -0800 (PST)
	mail_from (ananth@waco.engr.sgi.com)
Received: (from ananth@localhost)
	by waco.engr.sgi.com (8.11.0/8.11.0) id eB739Dh00791
	for linux-xfs@oss.sgi.com; Wed, 6 Dec 2000 19:09:13 -0800
Date:   Wed, 6 Dec 2000 19:09:13 -0800
From:   Ananth Ananthanarayanan <ananth@waco.engr.sgi.com>
Message-Id: <200012070309.eB739Dh00791@waco.engr.sgi.com>
Subject: TAKE - fix a merge problem in eepro100
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Wed Dec  6 19:08:41 PST 2000
Workarea:  waco.engr.sgi.com:/build1/ananth/xfs-tot

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80126a
linux/drivers/net/eepro100.c - 1.24
	- Fix merge problem introduced in test10 upgrade.



From owner-linux-xfs@oss.sgi.com Wed Dec  6 22:27:58 2000
Received:  by oss.sgi.com id <S553764AbQLGG1i>;
	Wed, 6 Dec 2000 22:27:38 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:37417 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553738AbQLGG1T>;
	Wed, 6 Dec 2000 22:27:19 -0800
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA20918
	for <linux-xfs@oss.sgi.com>; Wed, 6 Dec 2000 22:27:16 -0800 (PST)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA34103;
	Thu, 7 Dec 2000 17:25:58 +1100 (EDT)
From:   Timothy Shimmin <tes@boing.melbourne.sgi.com>
Message-Id: <200012070625.RAA34103@boing.melbourne.sgi.com>
Subject: Re: immutable etc.
To:     graichen@innominate.de
Date:   Thu, 7 Dec 2000 17:25:57 +1100 (EDT)
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <news2mail-90gun7$srf$2@mate.bln.innominate.de> from "Thomas Graichen" at Dec 04, 2000 08:27:19 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thomas writes:
> 
> just a little question: is there anything like the immutable and
> append only flags of ext2 (and for instance FFS in BSD) in XFS
> too - maybe somehow realized via extended attributes or in
> any other way?
> 
I didn't know what "immutable and append only flags" were :)
Looking in the ext2 CHANGES file:

    - New file attributes:
      - Immutable files cannot be modified.  Data cannot be written to
	these files.  They cannot be removed, renamed and new links cannot
	be created.  Even root cannot modify the files.  He has to remove
	the immutable attribute first.
      - Append-only files: can only be written in append-mode when writing.
	They cannot be removed, renamed and new links cannot be created.
	Note: files may only be added to an append-only directory.
      - No-dump files: the attribute is not used by the kernel.  My port
	of dump uses it to avoid backing up files which are not important.

No, I don't believe we have any equivalents.

Immutable sounds pretty much what one could achieve using the
standard access modes except for ROOT being disallowed to change
the file (without first setting the attribute).
OOI, how useful is this attribute ?

The No-Dump attribute (not that you asked ;-), I guess, could
be achieved rather easily by modifying xfsdump to use a particular 
Extended Attribute.

The extended attributes used in XFS in Linux are:
  1. DMAPI info
  2. ACL info (coming soon).

Other uses of EA in IRIX which _may_ be added to XFS in Linux are:
  3. MAC (Mandatory Access Controls) info
  4. File capability info

Cheers,
Tim.

From owner-linux-xfs@oss.sgi.com Thu Dec  7 00:36:18 2000
Received:  by oss.sgi.com id <S553767AbQLGIf7>;
	Thu, 7 Dec 2000 00:35:59 -0800
Received: from ns.caldera.de ([212.34.180.1]:47367 "EHLO ns.caldera.de")
	by oss.sgi.com with ESMTP id <S553762AbQLGIfb>;
	Thu, 7 Dec 2000 00:35:31 -0800
Received: (from hch@localhost)
	by ns.caldera.de (8.9.3/8.9.3) id JAA05626;
	Thu, 7 Dec 2000 09:35:17 +0100
Date:   Thu, 7 Dec 2000 09:35:17 +0100
From:   Christoph Hellwig <hch@caldera.de>
To:     Timothy Shimmin <tes@boing.melbourne.sgi.com>
Cc:     graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: immutable etc.
Message-ID: <20001207093517.A5515@caldera.de>
References: <news2mail-90gun7$srf$2@mate.bln.innominate.de> <200012070625.RAA34103@boing.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200012070625.RAA34103@boing.melbourne.sgi.com>; from tes@boing.melbourne.sgi.com on Thu, Dec 07, 2000 at 05:25:57PM +1100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 05:25:57PM +1100, Timothy Shimmin wrote:
> Immutable sounds pretty much what one could achieve using the
> standard access modes except for ROOT being disallowed to change
> the file (without first setting the attribute).
> OOI, how useful is this attribute ?

The basic idea of immutable files is that you drop
CAP_LINUX_IMMUTABLE for all processes, and attackers won't be able
to modifiy your binaries even if they have root access.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

From owner-linux-xfs@oss.sgi.com Thu Dec  7 00:42:28 2000
Received:  by oss.sgi.com id <S553771AbQLGImT>;
	Thu, 7 Dec 2000 00:42:19 -0800
Received: from hermes.mixx.net ([212.84.196.2]:29959 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553765AbQLGImF>;
	Thu, 7 Dec 2000 00:42:05 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 7E5C6F806
	for <linux-xfs@oss.sgi.com>; Thu,  7 Dec 2000 09:42:03 +0100 (CET)
Received: from orange.bln.innominate.de (orange.bln.innominate.de [10.0.0.31])
	by mate.bln.innominate.de (Postfix) with ESMTP id 10A4F2CAAC
	for <linux-xfs@oss.sgi.com>; Thu,  7 Dec 2000 09:41:40 +0100 (CET)
Received: by orange.bln.innominate.de (Postfix, from userid 502)
	id 8701325994; Thu,  7 Dec 2000 09:41:02 +0100 (CET)
From:   Thomas Graichen <graichen@innominate.de>
To:     linux-xfs@oss.sgi.com
Subject: (fwd) Re: sys_attrctl not working on ppc
Reply-To: thomas.graichen@innominate.de
Message-Id: <20001207084102.8701325994@orange.bln.innominate.de>
Date:   Thu,  7 Dec 2000 09:41:02 +0100 (CET)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Andrew Gildfind <ajag@fudge.melbourne.sgi.com> wrote:

> Couple of observations first:

>  - xfs_attr always calls the attr_* and therefore the system call with
>    a path, rather than a file descriptor.
>  - xfs_attr is always called with ATTR_DONT_FOLLOW - that is it never follows
>    symlinks

> The code looks like:

> 	asmlinkage long sys_attrctl(attr_obj_t obj, int type, 
> 					attr_op_t *ops, int count)
...

> Which means that on the way in (and we know that at least its hitting the
> syscall), it will always take the ATTR_TYPE_LPATH case. 

> I've had another look at your QA results (ppc.15-11-2000) they give the
> following:

> 	QA output created by 020
> 	*** list non-existant file
> 	   *** print attributes
> 	attr_list: Bad address
> 	Could not list attributes for <TESTFILE>
> 	      !!! error return
> 	*** list non-xfs file (in /proc)
> 	   *** print attributes
> 	attr_list: Bad address

> 	...


> The first test checks the non-existent file case, which means that we
> should come into the syscall, walk the path and die immediately with
> an ENOENT, ie. we should never get into XFS code at all.

> The fact that we are getting a bad address even in this case suggests to
> me that there maybe something weird happening because the path comes
> out of an attr_obj_t structure - are we sure that those structures are
> the same size in userland/kernel on PPC?

looks like (i hope this test is correct)

ppc:/usr/src/xfs/linux # gdb fs/xfs/xfs.o 
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ppc-suse-linux"...
(gdb) print sizeof(attr_obj_t)
$1 = 4
(gdb) quit
ppc:/usr/src/xfs/linux # gdb ../cmd/xfs/db/xfs_db 
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ppc-suse-linux"...
(gdb) print sizeof(attr_obj_t)
$1 = 4
(gdb)

> So... can you whack in another printk just after the switch and check whether
> the path lookup ever works - if it does I'm back in stumped-land, if not
> we have our culprit..

ok - here is the result:

Start mounting filesystem: ide0(3,8)
Ending clean XFS mount for filesystem: ide0(3,8)
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
ATTR_TYPE_PATH
Start mounting filesystem: ide0(3,8)
Ending clean XFS mount for filesystem: ide0(3,8)

so any new ideas?

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Dec  7 00:43:28 2000
Received:  by oss.sgi.com id <S553774AbQLGInS>;
	Thu, 7 Dec 2000 00:43:18 -0800
Received: from hermes.mixx.net ([212.84.196.2]:33031 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553768AbQLGIm7>;
	Thu, 7 Dec 2000 00:42:59 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 6E62DF806
	for <linux-xfs@oss.sgi.com>; Thu,  7 Dec 2000 09:42:57 +0100 (CET)
Received: from orange.bln.innominate.de (orange.bln.innominate.de [10.0.0.31])
	by mate.bln.innominate.de (Postfix) with ESMTP id 4832E2CAAC
	for <linux-xfs@oss.sgi.com>; Thu,  7 Dec 2000 09:42:57 +0100 (CET)
Received: by orange.bln.innominate.de (Postfix, from userid 502)
	id 25FA125994; Thu,  7 Dec 2000 09:42:20 +0100 (CET)
From:   Thomas Graichen <graichen@innominate.de>
To:     linux-xfs@oss.sgi.com
Subject: (fwd) Re: immutable etc.
Reply-To: thomas.graichen@innominate.de
Message-Id: <20001207084220.25FA125994@orange.bln.innominate.de>
Date:   Thu,  7 Dec 2000 09:42:20 +0100 (CET)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Timothy Shimmin <tes@boing.melbourne.sgi.com> wrote:
> Thomas writes:
>> 
>> just a little question: is there anything like the immutable and
>> append only flags of ext2 (and for instance FFS in BSD) in XFS
>> too - maybe somehow realized via extended attributes or in
>> any other way?
>> 
> I didn't know what "immutable and append only flags" were :)
> Looking in the ext2 CHANGES file:

>     - New file attributes:
>       - Immutable files cannot be modified.  Data cannot be written to
> 	these files.  They cannot be removed, renamed and new links cannot
> 	be created.  Even root cannot modify the files.  He has to remove
> 	the immutable attribute first.
>       - Append-only files: can only be written in append-mode when writing.
> 	They cannot be removed, renamed and new links cannot be created.
> 	Note: files may only be added to an append-only directory.
>       - No-dump files: the attribute is not used by the kernel.  My port
> 	of dump uses it to avoid backing up files which are not important.

> No, I don't believe we have any equivalents.

> Immutable sounds pretty much what one could achieve using the
> standard access modes except for ROOT being disallowed to change
> the file (without first setting the attribute).
> OOI, how useful is this attribute ?

i think it comes from 4.4BSD and the usefulness comes from the fact
that it is only possible to change those flags in the securelevel
which is normal in singleuser but not in multiuser - don't know
how it is handles by linux now but in general i think it might
be done via capabilities etc. ...

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Thu Dec  7 02:23:58 2000
Received:  by oss.sgi.com id <S553788AbQLGKXs>;
	Thu, 7 Dec 2000 02:23:48 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36900 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553785AbQLGKXk>; Thu, 7 Dec 2000 02:23:40 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id CAA07558
	for <linux-xfs@oss.sgi.com>; Thu, 7 Dec 2000 02:31:48 -0800 (PST)
	mail_from (ajag@fudge.melbourne.sgi.com)
Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA05129; Thu, 7 Dec 2000 21:22:20 +1100
Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id VAA06204; Thu, 7 Dec 2000 21:22:18 +1100 (EST)
Date:   Thu, 7 Dec 2000 21:22:18 +1100
From:   Andrew Gildfind <ajag@fudge.melbourne.sgi.com>
To:     thomas.graichen@innominate.de
Cc:     linux-xfs@oss.sgi.com
Subject: Re: (fwd) Re: sys_attrctl not working on ppc
Message-ID: <20001207212218.A7184@fudge.melbourne.sgi.com>
References: <20001207084102.8701325994@orange.bln.innominate.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <20001207084102.8701325994@orange.bln.innominate.de>; from graichen@innominate.de on Thu, Dec 07, 2000 at 09:41:02AM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 09:41:02AM +0100, Thomas Graichen wrote:
> Andrew Gildfind <ajag@fudge.melbourne.sgi.com> wrote:
> 
> > Couple of observations first:
> 
> >  - xfs_attr always calls the attr_* and therefore the system call with
> >    a path, rather than a file descriptor.
> >  - xfs_attr is always called with ATTR_DONT_FOLLOW - that is it never follows
> >    symlinks
> 
> > The code looks like:
> 
> > 	asmlinkage long sys_attrctl(attr_obj_t obj, int type, 
> > 					attr_op_t *ops, int count)
> ...
> 
> > Which means that on the way in (and we know that at least its hitting the
> > syscall), it will always take the ATTR_TYPE_LPATH case. 
> 
> > I've had another look at your QA results (ppc.15-11-2000) they give the
> > following:
> 
> > 	QA output created by 020
> > 	*** list non-existant file
> > 	   *** print attributes
> > 	attr_list: Bad address
> > 	Could not list attributes for <TESTFILE>
> > 	      !!! error return
> > 	*** list non-xfs file (in /proc)
> > 	   *** print attributes
> > 	attr_list: Bad address
> 
> > 	...
> 
> 
> > The first test checks the non-existent file case, which means that we
> > should come into the syscall, walk the path and die immediately with
> > an ENOENT, ie. we should never get into XFS code at all.
> 
> > The fact that we are getting a bad address even in this case suggests to
> > me that there maybe something weird happening because the path comes
> > out of an attr_obj_t structure - are we sure that those structures are
> > the same size in userland/kernel on PPC?
> 
> looks like (i hope this test is correct)
> 
> ppc:/usr/src/xfs/linux # gdb fs/xfs/xfs.o 
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "ppc-suse-linux"...
> (gdb) print sizeof(attr_obj_t)
> $1 = 4
> (gdb) quit
> ppc:/usr/src/xfs/linux # gdb ../cmd/xfs/db/xfs_db 
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "ppc-suse-linux"...
> (gdb) print sizeof(attr_obj_t)
> $1 = 4
> (gdb)
> 
> > So... can you whack in another printk just after the switch and check whether
> > the path lookup ever works - if it does I'm back in stumped-land, if not
> > we have our culprit..
> 
> ok - here is the result:
> 
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> ATTR_TYPE_PATH
> Start mounting filesystem: ide0(3,8)
> Ending clean XFS mount for filesystem: ide0(3,8)
> 

So to confirm the call made its way through the switch ok and went on to call
the vfs? Is ATTR_TYPE_PATH the type that came in with the call? If it was
then there's a bug in the library that maps the IRIXy flags to the attrctl
flags (that's a separate issue tho).

Do you have any more recent stress test outputs I could have a look at?

> so any new ideas?

One of the copy-ins later in the code is stuffed? Given that it already
passes on little-endian ia32 (all the on-disk stuff is big-endian) it's
probably not likely to be an endian issues in the core -> disk -> core 
conversion problem but I'm not really sure what's going on.

If you can let me have a current stress test output I'll have a look 
and see if I can think of anything else.

Andrew

-- 
Andrew Gildfind - R&D Software Engineer - SGI PTG Melbourne Australia
email: ajag@melbourne.sgi.com - work: +61.3.9834.8200 home: +61.3.9421.5335

From owner-linux-xfs@oss.sgi.com Thu Dec  7 07:37:39 2000
Received:  by oss.sgi.com id <S553664AbQLGPh3>;
	Thu, 7 Dec 2000 07:37:29 -0800
Received: from Cantor.suse.de ([194.112.123.193]:19204 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553646AbQLGPhR>;
	Thu, 7 Dec 2000 07:37:17 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id E7B0C1E307; Thu,  7 Dec 2000 16:37:14 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id F03EB3E452; Thu,  7 Dec 2000 16:37:12 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 7C85D2F300; Thu,  7 Dec 2000 16:37:11 +0100 (MET)
Date:   Thu, 7 Dec 2000 16:37:11 +0100
From:   Andi Kleen <ak@suse.de>
To:     Christoph Hellwig <hch@caldera.de>
Cc:     Timothy Shimmin <tes@boing.melbourne.sgi.com>,
        graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: immutable etc.
Message-ID: <20001207163711.A27514@gruyere.muc.suse.de>
References: <news2mail-90gun7$srf$2@mate.bln.innominate.de> <200012070625.RAA34103@boing.melbourne.sgi.com> <20001207093517.A5515@caldera.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001207093517.A5515@caldera.de>; from hch@caldera.de on Thu, Dec 07, 2000 at 09:35:17AM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 09:35:17AM +0100, Christoph Hellwig wrote:
> On Thu, Dec 07, 2000 at 05:25:57PM +1100, Timothy Shimmin wrote:
> > Immutable sounds pretty much what one could achieve using the
> > standard access modes except for ROOT being disallowed to change
> > the file (without first setting the attribute).
> > OOI, how useful is this attribute ?
> 
> The basic idea of immutable files is that you drop
> CAP_LINUX_IMMUTABLE for all processes, and attackers won't be able
> to modifiy your binaries even if they have root access.

So they just have to write to the block or raw device or directly to the
hardware (e.g. working IMMUTABLE normally implies non working x server).
Commonly accessed binaries like the ld.so can also be just modified in core. 




-Andi (who does not think immutable is very useful) 


From owner-linux-xfs@oss.sgi.com Thu Dec  7 09:29:29 2000
Received:  by oss.sgi.com id <S553683AbQLGR3T>;
	Thu, 7 Dec 2000 09:29:19 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:839 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553669AbQLGR3C>; Thu, 7 Dec 2000 09:29:02 -0800
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA09034; Thu, 7 Dec 2000 09:37:12 -0800 (PST)
	mail_from (nobody@info.engr.sgi.com)
Received: from info.engr.sgi.com (info.engr.sgi.com [192.26.80.216]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA52383; Thu, 7 Dec 2000 09:28:31 -0800 (PST)
Received: (from nobody@localhost)
	by info.engr.sgi.com (SGI-8.9.3/8.9.3) id JAA63625;
	Thu, 7 Dec 2000 09:27:14 -0800 (PST)
Date:   Thu, 7 Dec 2000 09:27:14 -0800 (PST)
Message-Id: <200012071727.JAA63625@info.engr.sgi.com>
X-Pv-Incident: 809716 
webPV:  gibble.americas.sgi.com 
webExec: webpvsubmit,PvProjectIncident 
Reply-To: sgi.bugs.xfs@fido.engr.sgi.com
From:   pv@relay.sgi.com (cattelan@engr.sgi.com)
Subject: BUG 809716 - XFS Linux and kiobuf io results in data corruption.
To:     nb@sgi.com
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=809716

Submitter : cattelan                  Submitter Domain : engr               
Assigned Engineer : nb                Assigned Domain : sgi.com             
Assigned Group : xfs-linux            Category : software                   
Customer Reported : F                 Priority : 3                          
Project : xfs-linux                   Status : open                         
Description :
Dual processor machine running linux XFS 2.4.0-test11
heavy doio tests, results in data corruption.

#!/bin/sh
export PATH=$PATH:/usr/tests/rts/bin


iogen -i 0 -T 128b 468973k:doio_1 | doio -akv -n 4 -m 1000 &
iogen -i 0 -T 128b 468973k:doio_2 | doio -akv -n 4 -m 1000 &
iogen -i 0 -T 128b 468973k:doio_3 | doio -akv -n 4 -m 1000 &
iogen -i 0 -T 128b 468973k:doio_4 | doio -akv -n 4 -m 1000 &


---------------------
*** DATA COMPARISON ERROR ***
check_file(/mnt1/doio_1, 359084382, 7237, S:953::doio*, 12, 0) failed

Comparison fd is 3, with open flags 0
Corrupt regions follow - unprintable chars are represented as '.'
-----------------------------------------------------------------
corrupt bytes starting at file offset 359084382
    1st 32 expected bytes:  S:953::doio*S:953::doio*S:953::d
    1st 32 actual bytes:    doio*M:956::doio*M:956::doio*M:9

Request number 24662
          fd 6 is file /mnt1/doio_1 - open flags are 010002 O_RDWR,O_SYNC,
          write done at file offset 359084382 - pattern is S (0123)
          number of requests is 1, strides per request is 1
          i/o byte count = 7237
          memory alignment is unaligned

syscall:  mmap-write(NULL, 480228352, PROT_WRITE, MAP_SHARED, 6, 0)
        file is mmaped to: 0x5cb09000
        file-mem=0x7217c15e, length=7237, buffer=0x8084309


doio (  951) 15:45:19
---------------------
Info:  25000 requests done (0 skipped) by this process

doio (  937) 15:45:27
---------------------
(parent) pid 953 exited because of data compare errors

From owner-linux-xfs@oss.sgi.com Thu Dec  7 10:13:49 2000
Received:  by oss.sgi.com id <S553681AbQLGSN3>;
	Thu, 7 Dec 2000 10:13:29 -0800
Received: from ns.caldera.de ([212.34.180.1]:8461 "EHLO ns.caldera.de")
	by oss.sgi.com with ESMTP id <S553645AbQLGSNL>;
	Thu, 7 Dec 2000 10:13:11 -0800
Received: (from hch@localhost)
	by ns.caldera.de (8.9.3/8.9.3) id TAA30513;
	Thu, 7 Dec 2000 19:12:34 +0100
Date:   Thu, 7 Dec 2000 19:12:34 +0100
From:   Christoph Hellwig <hch@caldera.de>
To:     Andi Kleen <ak@suse.de>
Cc:     Timothy Shimmin <tes@boing.melbourne.sgi.com>,
        graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: immutable etc.
Message-ID: <20001207191234.A30275@caldera.de>
References: <news2mail-90gun7$srf$2@mate.bln.innominate.de> <200012070625.RAA34103@boing.melbourne.sgi.com> <20001207093517.A5515@caldera.de> <20001207163711.A27514@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20001207163711.A27514@gruyere.muc.suse.de>; from ak@suse.de on Thu, Dec 07, 2000 at 04:37:11PM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 04:37:11PM +0100, Andi Kleen wrote:
> On Thu, Dec 07, 2000 at 09:35:17AM +0100, Christoph Hellwig wrote:
> > On Thu, Dec 07, 2000 at 05:25:57PM +1100, Timothy Shimmin wrote:
> > > Immutable sounds pretty much what one could achieve using the
> > > standard access modes except for ROOT being disallowed to change
> > > the file (without first setting the attribute).
> > > OOI, how useful is this attribute ?
> > 
> > The basic idea of immutable files is that you drop
> > CAP_LINUX_IMMUTABLE for all processes, and attackers won't be able
> > to modifiy your binaries even if they have root access.
> 
> So they just have to write to the block or raw device or directly to the
> hardware

Yes.  But

  a) it's at least harder for the attacker
  b) for a even more secure system you will just disable that too

> (e.g. working IMMUTABLE normally implies non working x server).

No.

> Commonly accessed binaries like the ld.so can also be just modified in core. 

Sure.  But you probably want to disable access to /dev/kmem, too
(that implies an unusable X-Server, unless you use a sane framebuffer device).

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

From owner-linux-xfs@oss.sgi.com Thu Dec  7 10:20:19 2000
Received:  by oss.sgi.com id <S553726AbQLGST7>;
	Thu, 7 Dec 2000 10:19:59 -0800
Received: from Cantor.suse.de ([194.112.123.193]:29958 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553648AbQLGSTu>;
	Thu, 7 Dec 2000 10:19:50 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 005821E33A; Thu,  7 Dec 2000 19:19:48 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 1D21E3E452; Thu,  7 Dec 2000 19:19:44 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id ED97E2F300; Thu,  7 Dec 2000 19:19:27 +0100 (MET)
Date:   Thu, 7 Dec 2000 19:19:27 +0100
From:   Andi Kleen <ak@suse.de>
To:     Christoph Hellwig <hch@caldera.de>
Cc:     Andi Kleen <ak@suse.de>,
        Timothy Shimmin <tes@boing.melbourne.sgi.com>,
        graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: immutable etc.
Message-ID: <20001207191927.A31785@gruyere.muc.suse.de>
References: <news2mail-90gun7$srf$2@mate.bln.innominate.de> <200012070625.RAA34103@boing.melbourne.sgi.com> <20001207093517.A5515@caldera.de> <20001207163711.A27514@gruyere.muc.suse.de> <20001207191234.A30275@caldera.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001207191234.A30275@caldera.de>; from hch@caldera.de on Thu, Dec 07, 2000 at 07:12:34PM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 07:12:34PM +0100, Christoph Hellwig wrote:
>   a) it's at least harder for the attacker
>   b) for a even more secure system you will just disable that too
> 
> > (e.g. working IMMUTABLE normally implies non working x server).
> 
> No.

It does.  I recently did a study for the changes required for a secure
(how to plug all holes that could be used to change kernel memory in a
controlled environment), and the X server was one of the most prominent 
(unless you go to unaccelerated X, which is not acceptable)  
There were lots of others too. 

> 
> > Commonly accessed binaries like the ld.so can also be just modified in core. 
> 
> Sure.  But you probably want to disable access to /dev/kmem, too

Disabling /dev/kmem and module loading is trivial. The problem when you 
want to do a full job is auditing every weird ioctl and /proc function hiding 
in some device driver if they do not allow to modify foreign memory for root. 
A lot of them do. 



-Andi

From owner-linux-xfs@oss.sgi.com Thu Dec  7 10:33:29 2000
Received:  by oss.sgi.com id <S553757AbQLGSdT>;
	Thu, 7 Dec 2000 10:33:19 -0800
Received: from ns.caldera.de ([212.34.180.1]:19469 "EHLO ns.caldera.de")
	by oss.sgi.com with ESMTP id <S553688AbQLGSc5>;
	Thu, 7 Dec 2000 10:32:57 -0800
Received: (from hch@localhost)
	by ns.caldera.de (8.9.3/8.9.3) id TAA32465;
	Thu, 7 Dec 2000 19:32:29 +0100
Date:   Thu, 7 Dec 2000 19:32:29 +0100
From:   Christoph Hellwig <hch@caldera.de>
To:     Andi Kleen <ak@suse.de>
Cc:     Timothy Shimmin <tes@boing.melbourne.sgi.com>,
        graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: immutable etc.
Message-ID: <20001207193229.A32292@caldera.de>
References: <news2mail-90gun7$srf$2@mate.bln.innominate.de> <200012070625.RAA34103@boing.melbourne.sgi.com> <20001207093517.A5515@caldera.de> <20001207163711.A27514@gruyere.muc.suse.de> <20001207191234.A30275@caldera.de> <20001207191927.A31785@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20001207191927.A31785@gruyere.muc.suse.de>; from ak@suse.de on Thu, Dec 07, 2000 at 07:19:27PM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 07:19:27PM +0100, Andi Kleen wrote:
> On Thu, Dec 07, 2000 at 07:12:34PM +0100, Christoph Hellwig wrote:
> >   a) it's at least harder for the attacker
> >   b) for a even more secure system you will just disable that too
> > 
> > > (e.g. working IMMUTABLE normally implies non working x server).
> > 
> > No.
> 
> It does.  I recently did a study for the changes required for a secure
> (how to plug all holes that could be used to change kernel memory in a
> controlled environment), and the X server was one of the most prominent 
> (unless you go to unaccelerated X, which is not acceptable)  
> There were lots of others too. 

Yes.  But IMMUTABLE doesn't even work on device files (yet).
X will get offended once you will disable it's access to kernel memory, but
IMMUTABLE is currently not usable to do so.

> 
> > 
> > > Commonly accessed binaries like the ld.so can also be just modified in core. 
> > 
> > Sure.  But you probably want to disable access to /dev/kmem, too
> 
> Disabling /dev/kmem and module loading is trivial. The problem when you 
> want to do a full job is auditing every weird ioctl and /proc function hiding 
> in some device driver if they do not allow to modify foreign memory for root. 
> A lot of them do. 

That's a really good idea.  Set up a mailinglist and I (and probably others) will
help you.

-- 
Whip me.  Beat me.  Make me maintain AIX.

From owner-linux-xfs@oss.sgi.com Thu Dec  7 10:42:49 2000
Received:  by oss.sgi.com id <S553753AbQLGSm3>;
	Thu, 7 Dec 2000 10:42:29 -0800
Received: from Cantor.suse.de ([194.112.123.193]:51208 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553648AbQLGSmT>;
	Thu, 7 Dec 2000 10:42:19 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 2CB0C1E346; Thu,  7 Dec 2000 19:42:17 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 4A3483E452; Thu,  7 Dec 2000 19:42:15 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id B2D182F300; Thu,  7 Dec 2000 19:42:10 +0100 (MET)
Date:   Thu, 7 Dec 2000 19:42:10 +0100
From:   Andi Kleen <ak@suse.de>
To:     Christoph Hellwig <hch@caldera.de>
Cc:     Andi Kleen <ak@suse.de>,
        Timothy Shimmin <tes@boing.melbourne.sgi.com>,
        graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: immutable etc.
Message-ID: <20001207194210.A32293@gruyere.muc.suse.de>
References: <news2mail-90gun7$srf$2@mate.bln.innominate.de> <200012070625.RAA34103@boing.melbourne.sgi.com> <20001207093517.A5515@caldera.de> <20001207163711.A27514@gruyere.muc.suse.de> <20001207191234.A30275@caldera.de> <20001207191927.A31785@gruyere.muc.suse.de> <20001207193229.A32292@caldera.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001207193229.A32292@caldera.de>; from hch@caldera.de on Thu, Dec 07, 2000 at 07:32:29PM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 07:32:29PM +0100, Christoph Hellwig wrote:
> On Thu, Dec 07, 2000 at 07:19:27PM +0100, Andi Kleen wrote:
> > On Thu, Dec 07, 2000 at 07:12:34PM +0100, Christoph Hellwig wrote:
> > >   a) it's at least harder for the attacker
> > >   b) for a even more secure system you will just disable that too
> > > 
> > > > (e.g. working IMMUTABLE normally implies non working x server).
> > > 
> > > No.
> > 
> > It does.  I recently did a study for the changes required for a secure
> > (how to plug all holes that could be used to change kernel memory in a
> > controlled environment), and the X server was one of the most prominent 
> > (unless you go to unaccelerated X, which is not acceptable)  
> > There were lots of others too. 
> 
> Yes.  But IMMUTABLE doesn't even work on device files (yet).
> X will get offended once you will disable it's access to kernel memory, but
> IMMUTABLE is currently not usable to do so.

I was not talking about immutable on device files, just on ways how 
"unbreakable for root" security features like immutable could be circumvented.
When an attacker gets access to DMA hardware or to kernel memory she wins,
because she can modify your immutable files.


> 
> > 
> > > 
> > > > Commonly accessed binaries like the ld.so can also be just modified in core. 
> > > 
> > > Sure.  But you probably want to disable access to /dev/kmem, too
> > 
> > Disabling /dev/kmem and module loading is trivial. The problem when you 
> > want to do a full job is auditing every weird ioctl and /proc function hiding 
> > in some device driver if they do not allow to modify foreign memory for root. 
> > A lot of them do. 
> 
> That's a really good idea.  Set up a mailinglist and I (and probably others) will
> help you.

I have no plans and no time to do that. The end result would probably
not be very usable as a desktop machine anyways. 


-Andi

From owner-linux-xfs@oss.sgi.com Thu Dec  7 10:52:48 2000
Received:  by oss.sgi.com id <S553782AbQLGSw3>;
	Thu, 7 Dec 2000 10:52:29 -0800
Received: from ns.caldera.de ([212.34.180.1]:30477 "EHLO ns.caldera.de")
	by oss.sgi.com with ESMTP id <S553748AbQLGSwA>;
	Thu, 7 Dec 2000 10:52:00 -0800
Received: (from hch@localhost)
	by ns.caldera.de (8.9.3/8.9.3) id TAA01684;
	Thu, 7 Dec 2000 19:51:43 +0100
Date:   Thu, 7 Dec 2000 19:51:43 +0100
From:   Christoph Hellwig <hch@caldera.de>
To:     Andi Kleen <ak@suse.de>
Cc:     Christoph Hellwig <hch@caldera.de>,
        Timothy Shimmin <tes@boing.melbourne.sgi.com>,
        graichen@innominate.de, linux-xfs@oss.sgi.com
Subject: Re: immutable etc.
Message-ID: <20001207195143.A1424@caldera.de>
References: <news2mail-90gun7$srf$2@mate.bln.innominate.de> <200012070625.RAA34103@boing.melbourne.sgi.com> <20001207093517.A5515@caldera.de> <20001207163711.A27514@gruyere.muc.suse.de> <20001207191234.A30275@caldera.de> <20001207191927.A31785@gruyere.muc <20001207193229.A32292@caldera.de> <20001207194210.A32293@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20001207194210.A32293@gruyere.muc.suse.de>; from ak@suse.de on Thu, Dec 07, 2000 at 07:42:10PM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 07, 2000 at 07:42:10PM +0100, Andi Kleen wrote:
> On Thu, Dec 07, 2000 at 07:32:29PM +0100, Christoph Hellwig wrote:
> > On Thu, Dec 07, 2000 at 07:19:27PM +0100, Andi Kleen wrote:
> > > On Thu, Dec 07, 2000 at 07:12:34PM +0100, Christoph Hellwig wrote:
> > > >   a) it's at least harder for the attacker
> > > >   b) for a even more secure system you will just disable that too
> > > > 
> > > > > (e.g. working IMMUTABLE normally implies non working x server).

	 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > > > 
> > > > No.
> > > 
> > > It does.  I recently did a study for the changes required for a secure
> > > (how to plug all holes that could be used to change kernel memory in a
> > > controlled environment), and the X server was one of the most prominent 
> > > (unless you go to unaccelerated X, which is not acceptable)  
> > > There were lots of others too. 
> > 
> > Yes.  But IMMUTABLE doesn't even work on device files (yet).
> > X will get offended once you will disable it's access to kernel memory, but
> > IMMUTABLE is currently not usable to do so.
> 
> I was not talking about immutable on device files, just on ways how 
> "unbreakable for root" security features like immutable could be circumvented.
> When an attacker gets access to DMA hardware or to kernel memory she wins,
> because she can modify your immutable files.

Your above statement looks different, but if that is your intention, your are right.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

From owner-linux-xfs@oss.sgi.com Thu Dec  7 15:59:51 2000
Received:  by oss.sgi.com id <S553791AbQLGX7l>;
	Thu, 7 Dec 2000 15:59:41 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3187 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553792AbQLGX72>; Thu, 7 Dec 2000 15:59:28 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA02578
	for <linux-xfs@oss.sgi.com>; Thu, 7 Dec 2000 16:07:39 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA41221 for <linux-xfs@oss.sgi.com>; Thu, 7 Dec 2000 17:58:12 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA99704 for <linux-xfs@oss.sgi.com>; Thu, 7 Dec 2000 17:58:11 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eB7NwBn10328
	for linux-xfs@oss.sgi.com; Thu, 7 Dec 2000 17:58:11 -0600
Date:   Thu, 7 Dec 2000 17:58:11 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200012072358.eB7NwBn10328@gibble.americas.sgi.com>
Subject: TAKE - Small fix.
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Thu Dec  7 15:57:44 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80230a
linux/fs/pagebuf/page_buf.c - 1.44
	- Small logic fix for MD and LVM devices.



From owner-linux-xfs@oss.sgi.com Thu Dec  7 22:25:34 2000
Received:  by oss.sgi.com id <S553794AbQLHGZP>;
	Thu, 7 Dec 2000 22:25:15 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:64780 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553790AbQLHGY5>;
	Thu, 7 Dec 2000 22:24:57 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eB86OgQ60154;
	Fri, 8 Dec 2000 00:24:42 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A307EA9.48EF2906@thebarn.com>
Date:   Fri, 08 Dec 2000 00:24:41 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Thomas Graichen <graichen@innominate.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: agf corruption on the alpha
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <10011281048.ZM165042@wobbly.melbourne.sgi.com>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com> <news2mail-9061lo$dc3$3@mate.bln.innominate.de> <3A26C307.5FCCC673@thebarn.com> <news2mail-907le1$27r$1@mate.bln.innominate.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Thomas Graichen wrote:

BTW just to let you know:
I found an alpha box and sent the day getting it up and running
RH 7.0 and the latest kernel.

Unfortunately I don't even get past mounting  the file system.
I'm running into the same problem reported with the ia64.
a null pointer mount point on the log structure.

If you can think of anything special you did with your
setup and/or creation of the file system?

-Russell


> [i changed the subject a bit ... this is no longer ppc :-]
>
> Russell Cattelan <cattelan@thebarn.com> wrote:
> > Thomas Graichen wrote:
>
> > Ok good...
> > So everything thing looks good right after mkfs and the mount.
>
> > The problem does appear to the first write to the super block.
> > as shown by
> > od -c -N 8 -j 512 /dev/sdb1
> > not reporting XAGF
>
> > My best guess that this point as to what it happening:
> > We have added valid bits to the page structure, with each
> > bit representing 1 512 byte block.
> > It appears that someplace in the pagebuf  math the basic unit
> > is now 1024, rather than 512.
> > Since the page size has doubled it does make sense the BB size has
> > doubled.
> > So now the trick is to find the problem.
>
> > Lets verify the problem first
> > just before the generic_make_request function in page_buf.c:
> > _pagebuf_page_io
> >                         printk ("_pagebuf page io calling gmk itr %d bh
> > 0x%p block %d size %ld\t",itr,
>
> > psync->bh[itr],psync->bh[itr]->b_blocknr,psync->bh[itr]->b_size);
> >                         { int i;
> >                         for(i=0; i < 4; i++){
> >                           printk("%c",psync->bh[itr]->b_data[i]);
> >                         }
> >                         printk("\n");
> >                         }
>
> > The numbers we will be interested in will be the b_ blocknr and the
> > b_bsize.
>
> ok - this is what i got for
>
> root@cyan:/var/log# mkfs -t xfs -f -b size=8192 /dev/sdb1
> meta-data=/dev/sdb1              isize=256    agcount=8, agsize=4142 blks
> data     =                       bsize=8192   blocks=33130, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=8192
> log      =internal log           bsize=8192   blocks=1000
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> root@cyan:/var/log# mount /dev/sdb1 /mnt
> root@cyan:/var/log# echo test > /mnt/testfile
> root@cyan:/var/log# umount /mnt
> root@cyan:/var/log#
>
> after a fresh reload of the modules
>
> <6>page_buf cache Copyright (c) 2000 Silicon Graphics, Inc.
> <6>XFS filesystem Copyright (c) 2000 Silicon Graphics, Inc.
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 0 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 530079 size 512
> <4>Start mounting filesystem: sd(8,17)
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 281151 size 1024      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 273151 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 269151 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 267151 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 266151 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265651 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265401 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265276 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265214 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265183 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265167 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265159 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265155 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265153 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265154 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265153 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265152 size 1024
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265153 size 1024      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265154 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 265170 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 265186 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7b40 block 265202 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7a00 block 265218 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7aa0 block 265234 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d6f60 block 265250 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7960 block 265266 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d69c0 block 265282 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d76e0 block 265298 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d6d80 block 265314 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7460 block 265330 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7e60 block 265346 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7f00 block 265362 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7d20 block 265378 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7dc0 block 265394 size 8192      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 128 size 8192
> <4>Ending clean XFS mount for filesystem: sd(8,17)
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 2 size 512
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 48 size 8192  °c4
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 1 size 512
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 3 size 512
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 32 size 8192  VÓ#
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f71e0 block 16 size 8192
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 265154 size 3072      þíº¾
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f7280 block 2 size 512    XAGI
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 48 size 8192  IABT
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7dc0 block 1 size 512    XAGF
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7d20 block 32 size 8192  ABTC
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7f00 block 16 size 8192  ABTB
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7e60 block 0 size 1024   XFSB
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00041d7460 block 128 size 8192 INAí
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 0 size 1024   XFSB
> <4>_pagebuf page io calling gmk itr 0 bh 0xfffffc00054f6600 block 265160 size 1024      þíº¾
>
> i hope it is complete - because there are problems with the prink's not
> getting out all - klogd and syslogd seem to eat them up somehow - the
> above is what i got using "cat /proc/kmsg" which should be fine i
> think
>
> please let me know if you need also output from some more fs activity
> than just that simple echo to file (but i thought this might be
> simpler for you to find somthing in)
>
> good luck
>
> t
>
> p.s.: is there any trick to get the printk stuff out in a more prefect
>       way (i.e. complete and in perfect sync via klogd/syslogd)?
>
> --
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77            http://www.innominate.com

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri Dec  8 01:11:45 2000
Received:  by oss.sgi.com id <S553793AbQLHJLZ>;
	Fri, 8 Dec 2000 01:11:25 -0800
Received: from hermes.mixx.net ([212.84.196.2]:2052 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553704AbQLHJK6>;
	Fri, 8 Dec 2000 01:10:58 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 37A76F810
	for <linux-xfs@oss.sgi.com>; Fri,  8 Dec 2000 10:10:56 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id C48002CA6F; Fri,  8 Dec 2000 10:10:55 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: agf corruption on the alpha
Date:   8 Dec 2000 09:10:55 GMT
Organization: innominate AG, Berlin, Germany
Lines:  26
Distribution: local
Message-ID: <news2mail-90q8iv$e5t$2@mate.bln.innominate.de>
References: <news2mail-8uecj0$i5e$1@mate.bln.innominate.de>   <news2mail-9001u3$n0b$2@mate.bln.innominate.de>   <10011290940.ZM169800@wobbly.melbourne.sgi.com>   <news2mail-902hr6$307$1@mate.bln.innominate.de> <10011301040.ZM164128@wobbly.melbourne.sgi.com> <news2mail-90550o$3u0$3@mate.bln.innominate.de> <3A267EBE.52E6CC95@thebarn.com> <news2mail-9061lo$dc3$3@mate.bln.innominate.de> <3A26C307.5FCCC673@thebarn.com> <news2mail-907le1$27r$1@mate.bln.innominate.de> <3A307EA9.48EF2906@thebarn.com>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 976266655 14525 10.0.0.31 (8 Dec 2000 09:10:55 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test10 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Russell Cattelan <cattelan@thebarn.com> wrote:
> Thomas Graichen wrote:

> BTW just to let you know:
> I found an alpha box and sent the day getting it up and running
> RH 7.0 and the latest kernel.

> Unfortunately I don't even get past mounting  the file system.
> I'm running into the same problem reported with the ia64.
> a null pointer mount point on the log structure.

> If you can think of anything special you did with your
> setup and/or creation of the file system?

nothing special: plain kernel, xfs as modules, gcc 2.95.2, and mkfs
                 with 8k blocksize

maybe i should sync my tree and retry ...

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Sun Dec 10 12:37:51 2000
Received:  by oss.sgi.com id <S553758AbQLJUhl>;
	Sun, 10 Dec 2000 12:37:41 -0800
Received: from Cantor.suse.de ([194.112.123.193]:45320 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553705AbQLJUhO>;
	Sun, 10 Dec 2000 12:37:14 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 191151E211
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 21:37:12 +0100 (MET)
Received: from D161.suse.de (D161.suse.de [10.10.100.161])
	by Hermes.suse.de (Postfix) with ESMTP id C128D3E452
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 21:37:11 +0100 (MET)
Received: (from axboe@localhost)
	by D161.suse.de (8.11.1/8.11.1/SuSE Linux 8.11.1-0.5) id eBAKbOA00773
	for linux-xfs@oss.sgi.com; Sun, 10 Dec 2000 21:37:24 +0100
Date:   Sun, 10 Dec 2000 21:37:24 +0100
From:   Jens Axboe <axboe@suse.de>
To:     linux-xfs@oss.sgi.com
Subject: patch: queue head reinit
Message-ID: <20001210213724.C294@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

Compiling latest linux-2.4-xfs, noticed that the patch test12-pre3 block
queue-head reinit fix is not included. I'd consider this critical and
would recommend that it be merged asap.

Index: drivers/block/ll_rw_blk.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/block/ll_rw_blk.c,v
retrieving revision 1.53
diff -u -r1.53 ll_rw_blk.c
--- drivers/block/ll_rw_blk.c	2000/12/01 18:04:38	1.53
+++ drivers/block/ll_rw_blk.c	2000/12/10 20:33:50
@@ -872,7 +872,7 @@
 	int max_segments = MAX_SEGMENTS;
 	struct request * req = NULL, *freereq = NULL;
 	int rw_ahead, max_sectors, el_ret;
-	struct list_head *head = &q->queue_head;
+	struct list_head *head;
 	int latency;
 	elevator_t *elevator = &q->elevator;
 
@@ -920,6 +920,7 @@
 	 * not to schedule or do something nonatomic
 	 */
 again:
+	head = &q->queue_head;
 	spin_lock_irq(&io_request_lock);
 
 	/*

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Sun Dec 10 12:56:51 2000
Received:  by oss.sgi.com id <S553796AbQLJU4l>;
	Sun, 10 Dec 2000 12:56:41 -0800
Received: from Cantor.suse.de ([194.112.123.193]:9226 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553728AbQLJU40>;
	Sun, 10 Dec 2000 12:56:26 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 03F721E243
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 21:56:24 +0100 (MET)
Received: from D161.suse.de (D161.suse.de [10.10.100.161])
	by Hermes.suse.de (Postfix) with ESMTP id EAFF33E452
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 21:56:23 +0100 (MET)
Received: (from axboe@localhost)
	by D161.suse.de (8.11.1/8.11.1/SuSE Linux 8.11.1-0.5) id eBAKuZ900952
	for linux-xfs@oss.sgi.com; Sun, 10 Dec 2000 21:56:35 +0100
Date:   Sun, 10 Dec 2000 21:56:35 +0100
From:   Jens Axboe <axboe@suse.de>
To:     linux-xfs@oss.sgi.com
Subject: patch: double freereq freeing
Message-ID: <20001210215635.E294@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi again,

This looks like a merge error. I sent this to Russell last week too,
when investigating the recent kio/elevator problems. It's not critical,
blkdev_release_request clears rq->q and thus it will not be freed
twice.

Index: drivers/block/ll_rw_blk.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/block/ll_rw_blk.c,v
retrieving revision 1.53
diff -u -r1.53 ll_rw_blk.c
--- drivers/block/ll_rw_blk.c	2000/12/01 18:04:38	1.53
+++ drivers/block/ll_rw_blk.c	2000/12/10 20:49:41
@@ -1013,8 +1014,6 @@
 	req_new_io(req, 0, count);
 	add_request(q, req, head, latency);
 out:
-	if (freereq)
-		blkdev_release_request(freereq);
 	if (!q->plugged)
 		(q->request_fn)(q);
 	if (freereq)

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Sun Dec 10 13:16:51 2000
Received:  by oss.sgi.com id <S553798AbQLJVQb>;
	Sun, 10 Dec 2000 13:16:31 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:38916 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S553795AbQLJVQF>;
	Sun, 10 Dec 2000 13:16:05 -0800
Received: from localhost.thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBALG2w37191;
	Sun, 10 Dec 2000 15:16:03 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by localhost.thebarn.com (8.11.1/8.11.1) with ESMTP id eBALF9405958;
	Sun, 10 Dec 2000 15:15:09 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A33F25C.5E9FAB1C@thebarn.com>
Date:   Sun, 10 Dec 2000 15:15:09 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jens Axboe <axboe@suse.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
References: <20001210215635.E294@suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jens Axboe wrote:

> Hi again,
>
> This looks like a merge error. I sent this to Russell last week too,
> when investigating the recent kio/elevator problems. It's not critical,
> blkdev_release_request clears rq->q and thus it will not be freed
> twice.

I have that one in the tree with the elevator patch.
I never got around to checking that particular fix in.

I'm building the tree now I'll check in both fixes once
I verify it builds.

BTW as far as your elevator patch goes do you know if
will be part of test12?


>
>
> Index: drivers/block/ll_rw_blk.c
> ===================================================================
> RCS file: /cvs/linux-2.4-xfs/linux/drivers/block/ll_rw_blk.c,v
> retrieving revision 1.53
> diff -u -r1.53 ll_rw_blk.c
> --- drivers/block/ll_rw_blk.c   2000/12/01 18:04:38     1.53
> +++ drivers/block/ll_rw_blk.c   2000/12/10 20:49:41
> @@ -1013,8 +1014,6 @@
>         req_new_io(req, 0, count);
>         add_request(q, req, head, latency);
>  out:
> -       if (freereq)
> -               blkdev_release_request(freereq);
>         if (!q->plugged)
>                 (q->request_fn)(q);
>         if (freereq)
>
> --
> * Jens Axboe <axboe@suse.de>
> * SuSE Labs


From owner-linux-xfs@oss.sgi.com Sun Dec 10 13:21:21 2000
Received:  by oss.sgi.com id <S553806AbQLJVVB>;
	Sun, 10 Dec 2000 13:21:01 -0800
Received: from Cantor.suse.de ([194.112.123.193]:14347 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553810AbQLJVUs>;
	Sun, 10 Dec 2000 13:20:48 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 2385D1E0AA; Sun, 10 Dec 2000 22:20:46 +0100 (MET)
Received: from D161.suse.de (D161.suse.de [10.10.100.161])
	by Hermes.suse.de (Postfix) with ESMTP
	id 121C73E452; Sun, 10 Dec 2000 22:20:46 +0100 (MET)
Received: (from axboe@localhost)
	by D161.suse.de (8.11.1/8.11.1/SuSE Linux 8.11.1-0.5) id eBALKvD01126;
	Sun, 10 Dec 2000 22:20:57 +0100
Date:   Sun, 10 Dec 2000 22:20:57 +0100
From:   Jens Axboe <axboe@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
Message-ID: <20001210222057.F294@suse.de>
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3A33F25C.5E9FAB1C@thebarn.com>; from cattelan@thebarn.com on Sun, Dec 10, 2000 at 03:15:09PM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Dec 10 2000, Russell Cattelan wrote:
> > This looks like a merge error. I sent this to Russell last week too,
> > when investigating the recent kio/elevator problems. It's not critical,
> > blkdev_release_request clears rq->q and thus it will not be freed
> > twice.
> 
> I have that one in the tree with the elevator patch.
> I never got around to checking that particular fix in.

Ah ok, so it didn't get completely lost :-)

> BTW as far as your elevator patch goes do you know if
> will be part of test12?

I haven't submitted it, so test12 is unlikely. Next version
perhaps, at least some parts of it. Depends on Linus and what
he thinks at this point.

In any way, I can merge it into the xfs tree if there's an interest.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Sun Dec 10 13:48:41 2000
Received:  by oss.sgi.com id <S553810AbQLJVsV>;
	Sun, 10 Dec 2000 13:48:21 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:44548 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S553802AbQLJVry>;
	Sun, 10 Dec 2000 13:47:54 -0800
Received: from localhost.thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBALlow37636;
	Sun, 10 Dec 2000 15:47:50 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by localhost.thebarn.com (8.11.1/8.11.1) with ESMTP id eBALkn406009;
	Sun, 10 Dec 2000 15:46:49 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A33F9C8.CD56A6CC@thebarn.com>
Date:   Sun, 10 Dec 2000 15:46:49 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jens Axboe <axboe@suse.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jens Axboe wrote:

> On Sun, Dec 10 2000, Russell Cattelan wrote:
> > > This looks like a merge error. I sent this to Russell last week too,
> > > when investigating the recent kio/elevator problems. It's not critical,
> > > blkdev_release_request clears rq->q and thus it will not be freed
> > > twice.
> >
> > I have that one in the tree with the elevator patch.
> > I never got around to checking that particular fix in.
>
> Ah ok, so it didn't get completely lost :-)
>
> > BTW as far as your elevator patch goes do you know if
> > will be part of test12?
>
> I haven't submitted it, so test12 is unlikely. Next version
> perhaps, at least some parts of it. Depends on Linus and what
> he thinks at this point.
>
> In any way, I can merge it into the xfs tree if there's an interest.

I have discovered a corruption problem when using kiobuf io.
I occurs both in the XFS-test11 tree and with your elevator patch.
So it does appear to be the fault of the patch,
although it does occur sooner with the elevator patch in.


Currently our doio test can completely starve out log requests,
thus by blocking out any new file system activity.
Your patch does a good job of clean up the starvation problem so
yes we do want to incorporate it.
We do need to figure out were the corruption is coming from
first.


>
>
> --
> * Jens Axboe <axboe@suse.de>
> * SuSE Labs


From owner-linux-xfs@oss.sgi.com Sun Dec 10 14:51:41 2000
Received:  by oss.sgi.com id <S553812AbQLJWvc>;
	Sun, 10 Dec 2000 14:51:32 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:27966 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553807AbQLJWvJ>; Sun, 10 Dec 2000 14:51:09 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA02615
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 14:59:21 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA07808
	for linux-xfs@oss.sgi.com; Mon, 11 Dec 2000 09:49:45 +1100 (EST)
Date:   Mon, 11 Dec 2000 09:49:45 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200012102249.JAA07808@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - drop unneeded include
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:80330a
Date:  Sun Dec 10 14:49:34 PST 2000
Workarea:  snort:/home/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/support/support.h - 1.2
	- drop unneeded include


From owner-linux-xfs@oss.sgi.com Sun Dec 10 15:23:31 2000
Received:  by oss.sgi.com id <S553816AbQLJXXW>;
	Sun, 10 Dec 2000 15:23:22 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:6207 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553811AbQLJXXC>; Sun, 10 Dec 2000 15:23:02 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09053
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 15:31:14 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA09597
	for linux-xfs@oss.sgi.com; Mon, 11 Dec 2000 10:21:40 +1100 (EST)
Date:   Mon, 11 Dec 2000 10:21:40 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200012102321.KAA09597@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - rename fs_* to xfs_fs_*
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:80332a
Date:  Sun Dec 10 15:21:19 PST 2000
Workarea:  snort:/home/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/linux/xfs_fs_subr.c - 1.23
	- rename fs_* to xfs_fs_*

linux/fs/xfs/linux/xfs_fs_subr.h - 1.2
linux/fs/xfs/linux/xfs_super.h - 1.5
linux/fs/xfs/xfs_iocore.c - 1.21
	- rename fs_* to xfs_fs_* 

linux/fs/xfs/xfs_mount.h - 1.119
	- add XFS_MFSI_RRINODES

linux/fs/xfs/xfs_vfsops.c - 1.302
linux/fs/xfs/xfs_vnodeops.c - 1.478
	- rename fs_* to xfs_fs_* 


From owner-linux-xfs@oss.sgi.com Sun Dec 10 15:32:12 2000
Received:  by oss.sgi.com id <S553821AbQLJXcB>;
	Sun, 10 Dec 2000 15:32:01 -0800
Received: from Cantor.suse.de ([194.112.123.193]:64529 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553818AbQLJXbp>;
	Sun, 10 Dec 2000 15:31:45 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 89B6D1E242; Mon, 11 Dec 2000 00:31:43 +0100 (MET)
Received: from D161.suse.de (D161.suse.de [10.10.100.161])
	by Hermes.suse.de (Postfix) with ESMTP
	id 6EEAC3E452; Mon, 11 Dec 2000 00:31:43 +0100 (MET)
Received: (from axboe@localhost)
	by D161.suse.de (8.11.1/8.11.1/SuSE Linux 8.11.1-0.5) id eBANVqn01961;
	Mon, 11 Dec 2000 00:31:52 +0100
Date:   Mon, 11 Dec 2000 00:31:52 +0100
From:   Jens Axboe <axboe@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
Message-ID: <20001211003152.O294@suse.de>
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3A33F9C8.CD56A6CC@thebarn.com>; from cattelan@thebarn.com on Sun, Dec 10, 2000 at 03:46:49PM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Dec 10 2000, Russell Cattelan wrote:
> > In any way, I can merge it into the xfs tree if there's an interest.
> 
> I have discovered a corruption problem when using kiobuf io.
> I occurs both in the XFS-test11 tree and with your elevator patch.
> So it does appear to be the fault of the patch,
> although it does occur sooner with the elevator patch in.

The most likely explanation is probably that blk-xx changes the
I/O generated and thus the pattern of how soon / when corruption
happens.

> Currently our doio test can completely starve out log requests,
> thus by blocking out any new file system activity.
> Your patch does a good job of clean up the starvation problem so
> yes we do want to incorporate it.

We can easily do a small patch that enables log writes to not be
rearranged by the elevator. That should completely fix such log
starvation issues.

> We do need to figure out were the corruption is coming from
> first.

Of course.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Sun Dec 10 17:11:22 2000
Received:  by oss.sgi.com id <S553834AbQLKBLN>;
	Sun, 10 Dec 2000 17:11:13 -0800
Received: from Cantor.suse.de ([194.112.123.193]:21767 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553819AbQLKBKx>;
	Sun, 10 Dec 2000 17:10:53 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 1B4141E296
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 02:10:52 +0100 (MET)
Received: from D161.suse.de (D161.suse.de [10.10.100.161])
	by Hermes.suse.de (Postfix) with ESMTP
	id AF9CA3E452; Mon, 11 Dec 2000 02:10:51 +0100 (MET)
Received: (from axboe@localhost)
	by D161.suse.de (8.11.1/8.11.1/SuSE Linux 8.11.1-0.5) id eBB1Ava02537;
	Mon, 11 Dec 2000 02:10:57 +0100
Date:   Mon, 11 Dec 2000 02:10:57 +0100
From:   Jens Axboe <axboe@suse.de>
To:     linux-xfs@oss.sgi.com
Subject: patch: ide kiobuf support
Message-ID: <20001211021057.B2304@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

Here's an updated patch for IDE kiobuf support, against current
tree (as of a couple of hours ago). DMA transfers should work (as
before), and so should pio. The only thing _not_ working at this
point is mult transfers so don't enable that. The main issue was
making sure that pio transfers do work, because even with DMA set
IDE may fall back to kio occasionally.

Beware that this patch may cause data corruption, system crashes,
and steal christmas. That being said, it Works Here. Testers
are of course appreciated.

Index: drivers/block/ll_rw_blk.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/block/ll_rw_blk.c,v
retrieving revision 1.53
diff -u -r1.53 ll_rw_blk.c
--- drivers/block/ll_rw_blk.c	2000/12/01 18:04:38	1.53
+++ drivers/block/ll_rw_blk.c	2000/12/11 01:03:43
@@ -835,7 +835,7 @@
         if (!(PAGE_SIZE - c_off > total_bytes))
                 nr_bytes = PAGE_SIZE - c_off;
  
-        rq->current_nr_sectors = nr_bytes >> 9; 
+        rq->hard_cur_sectors = rq->current_nr_sectors = nr_bytes >> 9; 
  
         /* Recalculate # segments; reuse "kioind" from above */
         for (; kioind < kiobuf->nr_pages && nr_bytes != total_bytes; kioind++){
@@ -872,7 +872,7 @@
 	int max_segments = MAX_SEGMENTS;
 	struct request * req = NULL, *freereq = NULL;
 	int rw_ahead, max_sectors, el_ret;
-	struct list_head *head = &q->queue_head;
+	struct list_head *head;
 	int latency;
 	elevator_t *elevator = &q->elevator;
 
@@ -920,6 +920,7 @@
 	 * not to schedule or do something nonatomic
 	 */
 again:
+	head = &q->queue_head;
 	spin_lock_irq(&io_request_lock);
 
 	/*
@@ -958,6 +959,7 @@
 			req->bh = bh;
 			req->buffer = bh->b_data;
 			req->current_nr_sectors = count;
+			req->hard_cur_sectors = count;
 			req->sector = req->hard_sector = sector;
 			req->nr_sectors = req->hard_nr_sectors += count;
 			req->e = elevator;
@@ -1002,7 +1004,7 @@
 	req->errors = 0;
 	req->hard_sector = req->sector = sector;
 	req->hard_nr_sectors = req->nr_sectors = count;
-	req->current_nr_sectors = count;
+	req->hard_cur_sectors = req->current_nr_sectors = count;
 	req->nr_segments = 1; /* Always 1 for a new request. */
 	req->nr_hw_segments = 1; /* Always 1 for a new request. */
 	blk_init_req(req, bh, kiobuf);
@@ -1013,8 +1015,6 @@
 	req_new_io(req, 0, count);
 	add_request(q, req, head, latency);
 out:
-	if (freereq)
-		blkdev_release_request(freereq);
 	if (!q->plugged)
 		(q->request_fn)(q);
 	if (freereq)
@@ -1233,7 +1233,7 @@
 	 * should try ll_rw_block()
 	 * for non-SCSI (e.g. IDE) disks.
 	 */
-        if (!SCSI_DISK_MAJOR(MAJOR(dev))) {
+	if (!SCSI_DISK_MAJOR(MAJOR(dev)) && !IDE_DISK_MAJOR(MAJOR(dev))) {
 		*error = -ENOSYS;
 		goto end_io;
 	}
@@ -1323,6 +1323,7 @@
 			req->nr_sectors = req->hard_nr_sectors;
 
 			req->current_nr_sectors = bh->b_size >> 9;
+			req->hard_cur_sectors = bh->b_size >> 9;
 			if (req->nr_sectors < req->current_nr_sectors) {
 				req->nr_sectors = req->current_nr_sectors;
 				printk("end_request: buffer-list destroyed\n");
Index: drivers/ide/ide-disk.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide-disk.c,v
retrieving revision 1.9
diff -u -r1.9 ide-disk.c
--- drivers/ide/ide-disk.c	2000/11/01 21:35:42	1.9
+++ drivers/ide/ide-disk.c	2000/12/11 01:03:43
@@ -131,6 +131,7 @@
 	return 0;	/* lba_capacity value may be bad */
 }
 
+
 /*
  * read_intr() is the handler for disk read/multread interrupts
  */
@@ -139,7 +140,7 @@
 	byte stat;
 	int i;
 	unsigned int msect, nsect;
-	struct request *rq;
+	struct request *rq = HWGROUP(drive)->rq;
 
 	/* new way for dealing with premature shared PCI interrupts */
 	if (!OK_STAT(stat=GET_STAT(),DATA_READY,BAD_R_STAT)) {
@@ -153,7 +154,6 @@
 	msect = drive->mult_count;
 	
 read_next:
-	rq = HWGROUP(drive)->rq;
 	if (msect) {
 		if ((nsect = rq->current_nr_sectors) > msect)
 			nsect = msect;
@@ -200,7 +200,7 @@
 			rq->nr_sectors-1);
 #endif
 		if ((rq->nr_sectors == 1) ^ ((stat & DRQ_STAT) != 0)) {
-			rq->sector++;
+			//rq->sector++;
 			rq->buffer += 512;
 			rq->errors = 0;
 			i = --rq->nr_sectors;
@@ -214,6 +214,7 @@
 			}
                         return ide_stopped;
 		}
+
 		return ide_stopped;	/* the original code did this here (?) */
 	}
 	return ide_error(drive, "write_intr", stat);
@@ -228,21 +229,9 @@
 int ide_multwrite (ide_drive_t *drive, unsigned int mcount)
 {
  	ide_hwgroup_t	*hwgroup= HWGROUP(drive);
+	struct request	*rq = hwgroup->rq;
 
-	/*
-	 *	This may look a bit odd, but remember wrq is a copy of the
-	 *	request not the original. The pointers are real however so the
-	 *	bh's are not copies. Remember that or bad stuff will happen
-	 *
-	 *	At the point we are called the drive has asked us for the
-	 *	data, and its our job to feed it, walking across bh boundaries
-	 *	if need be.
-	 */
-
- 	struct request	*rq = &hwgroup->wrq;
-
   	do {
- 		unsigned long flags;
   		unsigned int nsect = rq->current_nr_sectors;
 		if (nsect > mcount)
 			nsect = mcount;
@@ -254,7 +243,6 @@
 			drive->name, rq->sector, (unsigned long) rq->buffer,
 			nsect, rq->nr_sectors - nsect);
 #endif
-		spin_lock_irqsave(&io_request_lock, flags);	/* Is this really necessary? */
 #ifdef CONFIG_BLK_DEV_PDC4030
 		rq->sector += nsect;
 #endif
@@ -263,15 +251,15 @@
 			printk("%s: multwrite: count=%d, current=%ld\n",
 				drive->name, nsect, rq->nr_sectors);
 #endif
-			spin_unlock_irqrestore(&io_request_lock, flags);
 			break;
 		}
 		if ((rq->current_nr_sectors -= nsect) == 0) {
-			if ((rq->bh = rq->bh->b_reqnext) != NULL) {
+			if (rq->kiobuf)
+				ide_end_kio_request(rq, 1,rq->hard_cur_sectors);
+			else if ((rq->bh = rq->bh->b_reqnext) != NULL) {
 				rq->current_nr_sectors = rq->bh->b_size>>9;
 				rq->buffer             = rq->bh->b_data;
 			} else {
-				spin_unlock_irqrestore(&io_request_lock, flags);
 				printk("%s: buffer list corrupted (%ld, %ld, %d)\n",
 					drive->name, rq->current_nr_sectors,
 					rq->nr_sectors, nsect);
@@ -282,7 +270,6 @@
 			/* Fix the pointer.. we ate data */
 			rq->buffer += nsect << 9;
 		}
-                spin_unlock_irqrestore(&io_request_lock, flags);
 	} while (mcount);
         return 0;
 }
@@ -293,9 +280,8 @@
 static ide_startstop_t multwrite_intr (ide_drive_t *drive)
 {
 	byte stat;
-	int i;
 	ide_hwgroup_t *hwgroup = HWGROUP(drive);
-	struct request *rq = &hwgroup->wrq;
+	struct request *rq = hwgroup->rq;
 
 	if (OK_STAT(stat=GET_STAT(),DRIVE_READY,drive->bad_wstat)) {
 		if (stat & DRQ_STAT) {
@@ -309,21 +295,8 @@
 				ide_set_handler (drive, &multwrite_intr, WAIT_CMD, NULL);
 				return ide_started;
 			}
-		} else {
-			/*
-			 *	If the copy has all the blocks completed then
-			 *	we can end the original request.
-			 */
-			if (!rq->nr_sectors) {	/* all done? */
-				rq = hwgroup->rq;
-				for (i = rq->nr_sectors; i > 0;){
-					i -= rq->current_nr_sectors;
-					ide_end_request(1, hwgroup);
-				}
-				return ide_stopped;
-			}
 		}
-		return ide_stopped;	/* the original code did this here (?) */
+		return ide_stopped;
 	}
 	return ide_error(drive, "multwrite_intr", stat);
 }
@@ -383,7 +356,13 @@
 {
 	if (IDE_CONTROL_REG)
 		OUT_BYTE(drive->ctl,IDE_CONTROL_REG);
-	OUT_BYTE(rq->nr_sectors,IDE_NSECTOR_REG);
+
+	/*
+	 * for clustered kio requests, nr_sectors can be much bigger than
+	 * what ide hw can handle. do those in chunks of 256
+	 */
+	OUT_BYTE(rq->nr_sectors < 256 ? rq->nr_sectors : 0, IDE_NSECTOR_REG);
+
 #ifdef CONFIG_BLK_DEV_PDC4030
 	if (drive->select.b.lba || IS_PDC4030_DRIVE) {
 #else /* !CONFIG_BLK_DEV_PDC4030 */
@@ -454,7 +433,6 @@
 			 *
 			 * Except when you get an error it seems...
 			 */
-			hwgroup->wrq = *rq; /* scratchpad */
 			ide_set_handler (drive, &multwrite_intr, WAIT_CMD, NULL);
 			if (ide_multwrite(drive, drive->mult_count)) {
 				unsigned long flags;
Index: drivers/ide/ide-dma.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide-dma.c,v
retrieving revision 1.6
diff -u -r1.6 ide-dma.c
--- drivers/ide/ide-dma.c	2000/10/09 21:21:05	1.6
+++ drivers/ide/ide-dma.c	2000/12/11 01:03:43
@@ -197,9 +197,10 @@
 	if (OK_STAT(stat,DRIVE_READY,drive->bad_wstat|DRQ_STAT)) {
 		if (!dma_stat) {
 			struct request *rq = HWGROUP(drive)->rq;
-			rq = HWGROUP(drive)->rq;
-			for (i = rq->nr_sectors; i > 0;) {
-				i -= rq->current_nr_sectors;
+			if ((i = rq->nr_sectors) > 256)
+				i = 256;
+			while (i > 0) {
+				i -= rq->hard_cur_sectors;
 				ide_end_request(1, HWGROUP(drive));
 			}
 			return ide_stopped;
@@ -209,16 +210,81 @@
 	return ide_error(drive, "dma_intr", stat);
 }
 
-static int ide_build_sglist (ide_hwif_t *hwif, struct request *rq)
+/*
+ * Build kiobuf based scatter-gather list. Return number of segments.
+ */
+static int ide_kio_sgl(struct request *rq, struct scatterlist *sg)
+{
+	unsigned int total_bytes, nr_bytes, nr_seg, sg_size, segs;
+	struct kiobuf *kiobuf = rq->kiobuf;
+	unsigned int c_off, nr_pgs = 0, nr_sects = 0;
+	unsigned char *va;
+
+	/*
+	 * For leftover requests, only rq->nr_sectors gets adjusted.
+	 */
+	total_bytes = rq->nr_sectors << 9;
+
+	/*
+	 * find offset
+	 */
+	c_off = kiobuf->offset + (((kiobuf->length >> 9) - rq->nr_sectors) << 9);
+	if (c_off >= PAGE_SIZE) {
+		nr_pgs = (c_off >> PAGE_SHIFT);
+		c_off &= ~PAGE_MASK;
+	}
+
+	/*
+	 * limit to max ide hw size, if need be
+	 */
+	if ((segs = rq->nr_segments) > PRD_ENTRIES)
+		segs = PRD_ENTRIES;
+
+	/*
+	 * now build sg list
+	 */
+	for (sg_size = 0, nr_seg = 0, nr_bytes = 0; nr_seg < segs && nr_sects <= 256; nr_seg++, nr_sects += sg_size >> 9) {
+		va = c_off + (char *) page_address(kiobuf->maplist[nr_pgs]);
+		nr_pgs++;
+		if (c_off) {
+			if ((sg_size = PAGE_SIZE - c_off) > total_bytes)
+				sg_size = total_bytes;
+
+			c_off = 0;
+		} else if (nr_bytes + PAGE_SIZE > total_bytes) {
+			sg_size = total_bytes - nr_bytes;
+		} else {
+			sg_size = PAGE_SIZE;
+		}
+
+		nr_bytes += sg_size;
+		memset(&sg[nr_seg], 0, sizeof(struct scatterlist));
+		sg[nr_seg].address = va;
+		sg[nr_seg].length = sg_size;
+	}
+
+	/*
+	 * your plain paranoia
+	 */
+	if ((nr_bytes > total_bytes) || (nr_pgs > rq->kiobuf->nr_pages)) {
+		printk(KERN_ERR
+                       "ide_kio_sgl: sgl bytes[%d], request bytes[%d]\n"
+                       "ide_kio_sgl: pgcnt[%d], kiobuf->pgcnt[%d]!\n",
+			nr_bytes, total_bytes, nr_pgs, kiobuf->nr_pages);
+		BUG();
+	}
+
+	return nr_seg;
+}
+
+/*
+ * Build bh based scatter-gather list. Return number of segments.
+ */
+static int ide_bh_sgl(struct request *rq, struct scatterlist *sg)
 {
 	struct buffer_head *bh;
-	struct scatterlist *sg = hwif->sg_table;
 	int nents = 0;
 
-	if (rq->cmd == READ)
-		hwif->sg_dma_direction = PCI_DMA_FROMDEVICE;
-	else
-		hwif->sg_dma_direction = PCI_DMA_TODEVICE;
 	bh = rq->bh;
 	do {
 		unsigned char *virt_addr = bh->b_data;
@@ -229,12 +295,32 @@
 				break;
 			size += bh->b_size;
 		}
-		memset(&sg[nents], 0, sizeof(*sg));
+		memset(&sg[nents], 0, sizeof(struct scatterlist));
 		sg[nents].address = virt_addr;
 		sg[nents].length = size;
 		nents++;
 	} while (bh != NULL);
 
+	return nents;
+}
+
+static int ide_build_sglist (ide_hwif_t *hwif, struct request *rq)
+{
+	struct scatterlist *sg = hwif->sg_table;
+	int nents;
+
+	if (rq->cmd == READ)
+		hwif->sg_dma_direction = PCI_DMA_FROMDEVICE;
+	else
+		hwif->sg_dma_direction = PCI_DMA_TODEVICE;
+
+	if (rq->bh)
+		nents = ide_bh_sgl(rq, sg);
+	else if (rq->kiobuf)
+		nents = ide_kio_sgl(rq, sg);
+	else
+		panic("neither rq->bh nor rq->kiobuf in place\n");
+
 	return pci_map_sg(hwif->pci_dev, sg, nents, hwif->sg_dma_direction);
 }
 
@@ -257,6 +343,9 @@
 
 	HWIF(drive)->sg_nents = i = ide_build_sglist(HWIF(drive), HWGROUP(drive)->rq);
 
+	if (!i)
+		return 0;
+
 	sg = HWIF(drive)->sg_table;
 	while (i && sg_dma_len(sg)) {
 		u32 cur_addr;
@@ -266,7 +355,7 @@
 		cur_len = sg_dma_len(sg);
 
 		while (cur_len) {
-			if (++count >= PRD_ENTRIES) {
+			if (count++ >= PRD_ENTRIES) {
 				printk("%s: DMA table too small\n", drive->name);
 				pci_unmap_sg(HWIF(drive)->pci_dev,
 					     HWIF(drive)->sg_table,
@@ -292,8 +381,11 @@
 		i--;
 	}
 
-	if (!count)
+	if (!count) {
+		struct request *rq = HWGROUP(drive)->rq;
 		printk("%s: empty DMA table?\n", drive->name);
+		printk("sector %lu, hard sector %lu, nr_sectors %lu, hard nr_sectors %lu, cur nr_sectors %lu\n", rq->sector, rq->hard_sector, rq->nr_sectors, rq->hard_nr_sectors, rq->current_nr_sectors);
+	}
 	else if (!is_trm290_chipset)
 		*--table |= cpu_to_le32(0x80000000);
 
Index: drivers/ide/ide-probe.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide-probe.c,v
retrieving revision 1.10
diff -u -r1.10 ide-probe.c
--- drivers/ide/ide-probe.c	2000/10/09 21:21:05	1.10
+++ drivers/ide/ide-probe.c	2000/12/11 01:03:43
@@ -763,7 +763,7 @@
 #ifdef CONFIG_BLK_DEV_PDC4030
 		*max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : MAX_SECTORS);
 #else
-		*max_sect++ = MAX_SECTORS;
+		*max_sect++ = 256;
 #endif
 		*max_ra++ = MAX_READAHEAD;
 	}
Index: drivers/ide/ide.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide.c,v
retrieving revision 1.14
diff -u -r1.14 ide.c
--- drivers/ide/ide.c	2000/11/01 21:35:42	1.14
+++ drivers/ide/ide.c	2000/12/11 01:03:44
@@ -502,6 +502,90 @@
 	return 1;		/* drive ready: *might* be interrupting */
 }
 
+int ide_end_kio_request(struct request *rq, int uptodate, int sectors)
+{
+	int pgcnt = 0, nr_pages;
+	size_t curr_offset;
+	unsigned int nr_bytes, total_bytes, page_sectors, nr_sectors;
+	char *va = NULL;
+
+	if ((nr_sectors = rq->hard_nr_sectors) > 256)
+		nr_sectors = 256;
+
+	nr_pages = rq->kiobuf->nr_pages;
+	total_bytes = nr_sectors << 9;
+	curr_offset = rq->kiobuf->offset;
+
+	/*
+	 * In the case of leftover requests, the kiobuf->length
+	 * remains the same, but rq->nr_sectors would be smaller.
+	 * Adjust curr_offset in this case. If not a leftover,
+	 * the following makes no difference.
+	 */
+	curr_offset += (((rq->kiobuf->length >> 9) - nr_sectors) << 9);
+
+	/* How far into the kiobuf is the offset? */
+	if (curr_offset > PAGE_SIZE) {
+		pgcnt = curr_offset >> PAGE_SHIFT;
+		curr_offset &= ~PAGE_MASK;
+	}
+
+	/*		
+	 * Reusing the pgcnt and va value from above:
+	 * Harvest pages to account for number of sectors 
+	 * passed into function. 
+	 */
+	for (nr_bytes = 0; pgcnt < nr_pages && nr_bytes != total_bytes; pgcnt++) {
+		va = page_address(rq->kiobuf->maplist[pgcnt]) + curr_offset;
+		/* First page or final page? Partial page? */
+		if (curr_offset) {
+			if (PAGE_SIZE - curr_offset > total_bytes)
+				page_sectors = total_bytes >> 9;
+			else
+				page_sectors = (PAGE_SIZE - curr_offset) >> 9;
+			curr_offset = 0;
+		} else if (nr_bytes + PAGE_SIZE > total_bytes) {
+			page_sectors = (total_bytes - nr_bytes) >> 9;
+		} else {
+			page_sectors = PAGE_SIZE >> 9;
+		}
+		nr_bytes += (page_sectors << 9);
+		/* Leftover sectors in this page (onward)? */
+		if (sectors < page_sectors) {
+			rq->hard_nr_sectors -= sectors;
+			rq->sector += sectors;
+			rq->hard_cur_sectors = page_sectors - sectors;
+			va += (sectors << 9); /* Update for rq->buffer */
+			sectors = 0;
+			break;
+		}
+
+		/* Mark this page as done */
+		rq->nr_segments--;
+		rq->hard_nr_sectors -= page_sectors;
+		rq->sector += page_sectors;
+		if (!uptodate && rq->kiobuf->errno)
+			rq->kiobuf->errno = -EIO;
+		sectors -= page_sectors;
+	}
+
+	rq->current_nr_sectors = rq->hard_cur_sectors;
+	rq->nr_sectors = rq->hard_nr_sectors;
+
+	/* Check for leftovers */
+	if (rq->hard_nr_sectors) {
+		rq->buffer = va;
+		if (!rq->nr_segments)
+			rq->nr_segments = 1;
+		return 1;
+	}
+
+	if (rq->kiobuf->end_io)
+		rq->kiobuf->end_io(rq->kiobuf);
+
+	return 0;
+}
+
 /*
  * This is our end_request replacement function.
  */
@@ -509,11 +593,24 @@
 {
 	struct request *rq;
 	unsigned long flags;
+	int r;
 
 	spin_lock_irqsave(&io_request_lock, flags);
 	rq = hwgroup->rq;
+
+	/*
+	 * kiovec request
+	 */
+	if (rq->kiobuf)
+		r = ide_end_kio_request(rq, uptodate, rq->hard_cur_sectors);
+	else
+		r = end_that_request_first(rq, uptodate, hwgroup->drive->name);
 
-	if (!end_that_request_first(rq, uptodate, hwgroup->drive->name)) {
+	/*
+	 * finish request if either kiovec request or bh based request
+	 * is done
+	 */
+	if (!r) {
 		add_blkdev_randomness(MAJOR(rq->rq_dev));
 		blkdev_dequeue_request(rq);
         	hwgroup->rq = NULL;
Index: fs/pagebuf/page_buf_io.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/fs/pagebuf/page_buf_io.c,v
retrieving revision 1.36
diff -u -r1.36 page_buf_io.c
--- fs/pagebuf/page_buf_io.c	2000/11/21 10:24:08	1.36
+++ fs/pagebuf/page_buf_io.c	2000/12/11 01:03:45
@@ -1016,8 +1016,8 @@
 	/* arr is sized for worst case */
 	struct buffer_head *bh, *head, *arr[PAGE_CACHE_SIZE / 512];
 	int blocksize, bbits = inode->i_sb->s_blocksize_bits;
-	unsigned long kaddr = 0;
 	long nr, i, status = 0;
+	char *kaddr = NULL;
 
 	if (!PageLocked(page) || (inode->i_op->pagebuf_bmap == NULL))
 		PAGE_BUG(page);
Index: include/linux/blkdev.h
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/include/linux/blkdev.h,v
retrieving revision 1.26
diff -u -r1.26 blkdev.h
--- include/linux/blkdev.h	2000/10/11 20:41:07	1.26
+++ include/linux/blkdev.h	2000/12/11 01:03:47
@@ -39,7 +39,7 @@
 	unsigned long start_time;
 	unsigned long sector;
 	unsigned long nr_sectors;
-	unsigned long hard_sector, hard_nr_sectors;
+	unsigned long hard_sector, hard_nr_sectors, hard_cur_sectors;
 	unsigned int nr_segments;
 	unsigned int nr_hw_segments;
 	unsigned long current_nr_sectors;
Index: include/linux/ide.h
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/include/linux/ide.h,v
retrieving revision 1.25
diff -u -r1.25 ide.h
--- include/linux/ide.h	2000/11/01 21:35:42	1.25
+++ include/linux/ide.h	2000/12/11 01:03:48
@@ -657,6 +657,7 @@
 #include <linux/blk.h>
 
 void ide_end_request(byte uptodate, ide_hwgroup_t *hwgroup);
+int ide_end_kio_request(struct request *rq, int uptodate, int sectors);
 
 /*
  * This is used for (nearly) all data transfers from/to the IDE interface
Index: include/linux/major.h
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/include/linux/major.h,v
retrieving revision 1.22
diff -u -r1.22 major.h
--- include/linux/major.h	2000/10/23 18:56:35	1.22
+++ include/linux/major.h	2000/12/11 01:03:48
@@ -165,8 +165,23 @@
   (SCSI_DISK_MAJOR(M)	\
    || (M) == SCSI_CDROM_MAJOR)
 
-static __inline__ int scsi_blk_major(int m) {
+static inline int scsi_blk_major(int m)
+{
 	return SCSI_BLK_MAJOR(m);
+}
+
+/*
+ * Tests for IDE devices
+ */
+#define IDE_DISK_MAJOR(M)	((M) == IDE0_MAJOR || (M) == IDE1_MAJOR || \
+				(M) == IDE2_MAJOR || (M) == IDE3_MAJOR || \
+				(M) == IDE4_MAJOR || (M) == IDE5_MAJOR || \
+				(M) == IDE6_MAJOR || (M) == IDE7_MAJOR || \
+				(M) == IDE8_MAJOR || (M) == IDE9_MAJOR)
+
+static inline int ide_blk_major(int m)
+{
+	return IDE_DISK_MAJOR(m);
 }
 
 #endif

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Sun Dec 10 18:54:52 2000
Received:  by oss.sgi.com id <S553837AbQLKCym>;
	Sun, 10 Dec 2000 18:54:42 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:46660 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553827AbQLKCyV>; Sun, 10 Dec 2000 18:54:21 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA02518
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 19:02:34 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA34898
	for linux-xfs@oss.sgi.com; Mon, 11 Dec 2000 13:53:00 +1100 (EST)
Date:   Mon, 11 Dec 2000 13:53:00 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012110253.NAA34898@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:80336a
Date:  Sun Dec 10 18:48:07 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/quota/repquota.8 - 1.4
	- document -m option (use /etc/mtab in place of /etc/fstab).

cmd/quota/repquota.c - 1.7
	- add -m option (use /etc/mtab in place of /etc/fstab).

cmd/quota/setquota.c - 1.4
	- little bug in Marcos pre11 code - getopts doesn't allow -n through.

cmd/xfs/stress/016 - 1.8
cmd/xfs/stress/017 - 1.8
cmd/xfs/stress/018 - 1.6
cmd/xfs/stress/019 - 1.11
cmd/xfs/stress/021 - 1.4
	- get _fail from common.rc now (many tests use it, now in common).

cmd/xfs/stress/033 - 1.2
	- don't create an unused tmp file.

cmd/xfs/stress/049 - 1.2
	- get _fail from common.rc now (many tests use it, now in common).
	  also, add a check that loopback device support is available.

cmd/xfs/stress/common.filter - 1.9
	- allow sh -x test debugging to work.

cmd/xfs/stress/common.quota - 1.2
	- add some more routines for quota qa tests to share.

cmd/xfs/stress/common.rc - 1.40
	- add a common _fail routine since many tests use it.  add a routine to
	  check for loopback support.

cmd/xfs/stress/group - 1.54
	- add test 50, move 48 & 49 into auto qa group.

cmd/xfs/stress/src/feature.c - 1.2
	- allow checks for user/grp enforcement or accounting (separately).

cmd/xfs/stress/050 - 1.1
	- sanity test for XFS quota - set and verify some quota limits for
	  whatever form of quota is enabled.


From owner-linux-xfs@oss.sgi.com Sun Dec 10 19:19:43 2000
Received:  by oss.sgi.com id <S553842AbQLKDTX>;
	Sun, 10 Dec 2000 19:19:23 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:9988 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553835AbQLKDSu>;
	Sun, 10 Dec 2000 19:18:50 -0800
Received: from thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eBB3IaQ67890;
	Sun, 10 Dec 2000 21:18:36 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A34478B.BCCFB089@thebarn.com>
Date:   Sun, 10 Dec 2000 21:18:36 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
Reply-To: cattelan@thebarn.com
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jens Axboe <axboe@suse.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com> <20001211003152.O294@suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jens Axboe wrote:

> On Sun, Dec 10 2000, Russell Cattelan wrote:
> > > In any way, I can merge it into the xfs tree if there's an interest.
> >
> > I have discovered a corruption problem when using kiobuf io.
> > I occurs both in the XFS-test11 tree and with your elevator patch.
> > So it does appear to be the fault of the patch,
> > although it does occur sooner with the elevator patch in.

As I sure the above statement doesn't make much sense,
I meant to say "it does NOT appear" to be the fault of the patch.

>
>
> The most likely explanation is probably that blk-xx changes the
> I/O generated and thus the pattern of how soon / when corruption
> happens.

Just to expand on the problem a bit;
The corruption shows up under heavy load.
4 doio files each with 4 processes a piece doing
different types of io read/write readv/writev and mmap.
The  corruption always due to  mmap'ed io.

My best guess at this: Since IO path through uses
both bufer_head and kio bufs.
There is a sequence discrepancy, kio buf io may be initiated after a
buffer_head
io assuming the buffer head controlled data made it to disk but it may not.

Pagebuf issues a kio buf io write to the disk bypassing all the queues and
the disk elevator
etc. etc.. thus "sneaking" a write in before the buffer head io has a
chance to hit disk.

I really have no idea if this is what is happening but every story has to
have a begging :-)


>
>
> > Currently our doio test can completely starve out log requests,
> > thus by blocking out any new file system activity.
> > Your patch does a good job of clean up the starvation problem so
> > yes we do want to incorporate it.
>
> We can easily do a small patch that enables log writes to not be
> rearranged by the elevator. That should completely fix such log
> starvation issues.

If you patch proves to be stable enough, we can just pull it into the
tree.  I appears to clean up some other inefficiencies.

>
>
> > We do need to figure out were the corruption is coming from
> > first.
>
> Of course.
>
> --
> * Jens Axboe <axboe@suse.de>
> * SuSE Labs

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun Dec 10 20:40:12 2000
Received:  by oss.sgi.com id <S553841AbQLKEjx>;
	Sun, 10 Dec 2000 20:39:53 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:45895 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553820AbQLKEjl>; Sun, 10 Dec 2000 20:39:41 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA05054
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 20:47:54 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA65558 for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 22:38:24 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA14630 for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 22:38:24 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eBB4cO120901
	for linux-xfs@oss.sgi.com; Sun, 10 Dec 2000 22:38:24 -0600
Date:   Sun, 10 Dec 2000 22:38:24 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200012110438.eBB4cO120901@gibble.americas.sgi.com>
Subject: TAKE - 
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Sun Dec 10 20:38:00 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80339a
linux/drivers/block/ll_rw_blk.c - 1.54
	- Small merge error fix and
	  small "critical" fix from Jens.



From owner-linux-xfs@oss.sgi.com Sun Dec 10 22:53:34 2000
Received:  by oss.sgi.com id <S553851AbQLKGxO>;
	Sun, 10 Dec 2000 22:53:14 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:55871 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553831AbQLKGwq>;
	Sun, 10 Dec 2000 22:52:46 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA27400
	for <linux-xfs@oss.sgi.com>; Sun, 10 Dec 2000 22:52:45 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA61507
	for linux-xfs@oss.sgi.com; Mon, 11 Dec 2000 17:51:26 +1100 (EST)
Date:   Mon, 11 Dec 2000 17:51:26 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012110651.RAA61507@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - build
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This fixes a nasty little problem when building the user tools.
We use $GZIP to allow an alternate gzip path - unfortunately,
$GZIP is magic to gzip (default options), and is set by default
in some distros (to do max compression by default - Daniel came
across this doing testing on a recent version of Suse).

We now use $ZIP and I've audited the man pages of the other build
tools we use - I don't think we'll be bitten by this again.  Its
probably a good idea to do a "make realclean" before your next
recompile of the user tools.

cheers.


Modid:  2.4.x-xfs:slinx:80342a
Date:  Sun Dec 10 22:45:17 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/Makefile - 1.38
cmd/xfs/build/Makefile - 1.6
cmd/xfs/build/tar/Makefile - 1.3
	- rework handling of GZIP.

cmd/xfs/configure.in - 1.19
	- rework handling of GZIP.  add a better check for libuuid (not just the
	  header file).  add commented template for Martin & liblvm.

cmd/xfs/include/builddefs.in - 1.19
	- rework handling of GZIP.


From owner-linux-xfs@oss.sgi.com Mon Dec 11 02:01:14 2000
Received:  by oss.sgi.com id <S553854AbQLKKBF>;
	Mon, 11 Dec 2000 02:01:05 -0800
Received: from hermes.mixx.net ([212.84.196.2]:48914 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553831AbQLKKAm>;
	Mon, 11 Dec 2000 02:00:42 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 1E97EF80F
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 11:00:40 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mate.bln.innominate.de (Postfix) with ESMTP id 0C63B2CAA0
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 11:00:38 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 0C5F42CA9D; Mon, 11 Dec 2000 11:00:26 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: xfs mount rpm's
Date:   11 Dec 2000 10:00:25 GMT
Organization: innominate AG, Berlin, Germany
Lines:  12
Distribution: local
Message-ID: <news2mail-9128jp$p32$4@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 976528825 25698 10.0.0.31 (11 Dec 2000 10:00:25 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test11 (i686))
To:     linux-xfs@oss.sgi.com
X-Virus-Scanned: by AMaViS perl-10
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

just if anyone is interested - i have uploaded source and binary rpm's
for mount including the xfs mount by label patch at

  http://innominate.org/~graichen/projects/xfs/i386/

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Dec 11 02:05:15 2000
Received:  by oss.sgi.com id <S553856AbQLKKE4>;
	Mon, 11 Dec 2000 02:04:56 -0800
Received: from hermes.mixx.net ([212.84.196.2]:61458 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553848AbQLKKEi>;
	Mon, 11 Dec 2000 02:04:38 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id F2BB0F809
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 11:04:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mate.bln.innominate.de (Postfix) with ESMTP id C03842CA9D
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 11:04:35 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id 210B12CA71; Mon, 11 Dec 2000 11:04:32 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: new miniroot
Date:   11 Dec 2000 10:04:32 GMT
Organization: innominate AG, Berlin, Germany
Lines:  22
Distribution: local
Message-ID: <news2mail-9128rg$p32$5@mate.bln.innominate.de>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 976529072 25698 10.0.0.31 (11 Dec 2000 10:04:32 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test11 (i686))
To:     linux-xfs@oss.sgi.com
X-Virus-Scanned: by AMaViS perl-10
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

if anyone is interested: i have uploaded a new miniroot at

  http://innominate.org/~graichen/projects/miniroot/0.6/

the basic idea behind it is to have a standalone environment (ramdisk)
to do xfs things from (xfs_repair of the / fs, xfs_db of it, con-
version of an ext2 / to xfs and so on) ... it's very easy to use
and the docs are terrible so far :-) ... just give it a try


t

p.s.: 0.7 will follow sometime soon with some fixes to it i already
      have around - but 0.6 should work pretty well too (only
      xfs_admin does not work yet due to missing
      /usr/bin/expr)

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Mon Dec 11 06:04:58 2000
Received:  by oss.sgi.com id <S553855AbQLKOEr>;
	Mon, 11 Dec 2000 06:04:47 -0800
Received: from Cantor.suse.de ([194.112.123.193]:33801 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553815AbQLKOEa>;
	Mon, 11 Dec 2000 06:04:30 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 602351E13D; Mon, 11 Dec 2000 15:04:27 +0100 (MET)
Received: from D161.suse.de (D161.suse.de [10.10.100.161])
	by Hermes.suse.de (Postfix) with ESMTP
	id 495DD3E46E; Mon, 11 Dec 2000 15:04:27 +0100 (MET)
Received: (from axboe@localhost)
	by D161.suse.de (8.11.1/8.11.1/SuSE Linux 8.11.1-0.5) id eBBE4Xn02299;
	Mon, 11 Dec 2000 15:04:33 +0100
Date:   Mon, 11 Dec 2000 15:04:32 +0100
From:   Jens Axboe <axboe@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
Message-ID: <20001211150432.C294@suse.de>
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com> <20001211003152.O294@suse.de> <3A34478B.BCCFB089@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3A34478B.BCCFB089@thebarn.com>; from cattelan@thebarn.com on Sun, Dec 10, 2000 at 09:18:36PM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Dec 10 2000, Russell Cattelan wrote:
> Jens Axboe wrote:
> 
> > On Sun, Dec 10 2000, Russell Cattelan wrote:
> > > > In any way, I can merge it into the xfs tree if there's an interest.
> > >
> > > I have discovered a corruption problem when using kiobuf io.
> > > I occurs both in the XFS-test11 tree and with your elevator patch.
> > > So it does appear to be the fault of the patch,
> > > although it does occur sooner with the elevator patch in.
> 
> As I sure the above statement doesn't make much sense,
> I meant to say "it does NOT appear" to be the fault of the patch.

Ah, this is indeed how I read it too. Or I would have corrected
you :-)

> > The most likely explanation is probably that blk-xx changes the
> > I/O generated and thus the pattern of how soon / when corruption
> > happens.
> 
> Just to expand on the problem a bit;
> The corruption shows up under heavy load.
> 4 doio files each with 4 processes a piece doing
> different types of io read/write readv/writev and mmap.
> The  corruption always due to  mmap'ed io.
> 
> My best guess at this: Since IO path through uses
> both bufer_head and kio bufs.
> There is a sequence discrepancy, kio buf io may be initiated after a
> buffer_head
> io assuming the buffer head controlled data made it to disk but it may not.

You mean lack of ordering with bh vs kio? Assuming they all make it to
disk eventually, I don't see a specific problem that would cause
corruption there.

> Pagebuf issues a kio buf io write to the disk bypassing all the queues and
> the disk elevator
> etc. etc.. thus "sneaking" a write in before the buffer head io has a
> chance to hit disk.

The kiobuf request will be sequenced just like any other request, unless
it manipulates the queue directly itself (which, without having looked,
I'm assuming it does not. this would be ugly)

> I really have no idea if this is what is happening but every story has to
> have a begging :-)

Right, we'll track it down eventually.

> > rearranged by the elevator. That should completely fix such log
> > starvation issues.
> 
> If you patch proves to be stable enough, we can just pull it into the
> tree.  I appears to clean up some other inefficiencies.

It's stable.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Mon Dec 11 06:34:58 2000
Received:  by oss.sgi.com id <S553860AbQLKOet>;
	Mon, 11 Dec 2000 06:34:49 -0800
Received: from Cantor.suse.de ([194.112.123.193]:15885 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553857AbQLKOed>;
	Mon, 11 Dec 2000 06:34:33 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP id 9A84E1E1C2
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 15:34:30 +0100 (MET)
Received: from D161.suse.de (D161.suse.de [10.10.100.161])
	by Hermes.suse.de (Postfix) with ESMTP id 71CB13E452
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 15:34:30 +0100 (MET)
Received: (from axboe@localhost)
	by D161.suse.de (8.11.1/8.11.1/SuSE Linux 8.11.1-0.5) id eBBEYOa02604
	for linux-xfs@oss.sgi.com; Mon, 11 Dec 2000 15:34:24 +0100
Date:   Mon, 11 Dec 2000 15:34:24 +0100
From:   Jens Axboe <axboe@suse.de>
To:     linux-xfs@oss.sgi.com
Subject: patch: ide kio, part deux
Message-ID: <20001211153424.D294@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

I've fixed the last IDE kio problems, patch is included here. It now
works with any IDE mode, dma/pio, multwrite, etc. I've been banging
on it for the last couple of hours with dbench cp'ing etc, and it
appears solid. No hangs or data corruption.

So it should be safe to test, even on non-scratch xfs partitions.

Index: drivers/block/ll_rw_blk.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/block/ll_rw_blk.c,v
retrieving revision 1.53
diff -u -r1.53 ll_rw_blk.c
--- drivers/block/ll_rw_blk.c	2000/12/01 18:04:38	1.53
+++ drivers/block/ll_rw_blk.c	2000/12/11 14:30:00
@@ -835,7 +835,7 @@
         if (!(PAGE_SIZE - c_off > total_bytes))
                 nr_bytes = PAGE_SIZE - c_off;
  
-        rq->current_nr_sectors = nr_bytes >> 9; 
+        rq->hard_cur_sectors = rq->current_nr_sectors = nr_bytes >> 9; 
  
         /* Recalculate # segments; reuse "kioind" from above */
         for (; kioind < kiobuf->nr_pages && nr_bytes != total_bytes; kioind++){
@@ -872,7 +872,7 @@
 	int max_segments = MAX_SEGMENTS;
 	struct request * req = NULL, *freereq = NULL;
 	int rw_ahead, max_sectors, el_ret;
-	struct list_head *head = &q->queue_head;
+	struct list_head *head;
 	int latency;
 	elevator_t *elevator = &q->elevator;
 
@@ -920,6 +920,7 @@
 	 * not to schedule or do something nonatomic
 	 */
 again:
+	head = &q->queue_head;
 	spin_lock_irq(&io_request_lock);
 
 	/*
@@ -958,6 +959,7 @@
 			req->bh = bh;
 			req->buffer = bh->b_data;
 			req->current_nr_sectors = count;
+			req->hard_cur_sectors = count;
 			req->sector = req->hard_sector = sector;
 			req->nr_sectors = req->hard_nr_sectors += count;
 			req->e = elevator;
@@ -1002,7 +1004,7 @@
 	req->errors = 0;
 	req->hard_sector = req->sector = sector;
 	req->hard_nr_sectors = req->nr_sectors = count;
-	req->current_nr_sectors = count;
+	req->hard_cur_sectors = req->current_nr_sectors = count;
 	req->nr_segments = 1; /* Always 1 for a new request. */
 	req->nr_hw_segments = 1; /* Always 1 for a new request. */
 	blk_init_req(req, bh, kiobuf);
@@ -1013,8 +1015,6 @@
 	req_new_io(req, 0, count);
 	add_request(q, req, head, latency);
 out:
-	if (freereq)
-		blkdev_release_request(freereq);
 	if (!q->plugged)
 		(q->request_fn)(q);
 	if (freereq)
@@ -1233,7 +1233,7 @@
 	 * should try ll_rw_block()
 	 * for non-SCSI (e.g. IDE) disks.
 	 */
-        if (!SCSI_DISK_MAJOR(MAJOR(dev))) {
+	if (!SCSI_DISK_MAJOR(MAJOR(dev)) && !IDE_DISK_MAJOR(MAJOR(dev))) {
 		*error = -ENOSYS;
 		goto end_io;
 	}
@@ -1323,6 +1323,7 @@
 			req->nr_sectors = req->hard_nr_sectors;
 
 			req->current_nr_sectors = bh->b_size >> 9;
+			req->hard_cur_sectors = bh->b_size >> 9;
 			if (req->nr_sectors < req->current_nr_sectors) {
 				req->nr_sectors = req->current_nr_sectors;
 				printk("end_request: buffer-list destroyed\n");
Index: drivers/ide/ide-disk.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide-disk.c,v
retrieving revision 1.9
diff -u -r1.9 ide-disk.c
--- drivers/ide/ide-disk.c	2000/11/01 21:35:42	1.9
+++ drivers/ide/ide-disk.c	2000/12/11 14:30:01
@@ -131,6 +131,7 @@
 	return 0;	/* lba_capacity value may be bad */
 }
 
+
 /*
  * read_intr() is the handler for disk read/multread interrupts
  */
@@ -139,7 +140,7 @@
 	byte stat;
 	int i;
 	unsigned int msect, nsect;
-	struct request *rq;
+	struct request *rq = HWGROUP(drive)->rq;
 
 	/* new way for dealing with premature shared PCI interrupts */
 	if (!OK_STAT(stat=GET_STAT(),DATA_READY,BAD_R_STAT)) {
@@ -153,7 +154,6 @@
 	msect = drive->mult_count;
 	
 read_next:
-	rq = HWGROUP(drive)->rq;
 	if (msect) {
 		if ((nsect = rq->current_nr_sectors) > msect)
 			nsect = msect;
@@ -200,7 +200,7 @@
 			rq->nr_sectors-1);
 #endif
 		if ((rq->nr_sectors == 1) ^ ((stat & DRQ_STAT) != 0)) {
-			rq->sector++;
+			//rq->sector++;
 			rq->buffer += 512;
 			rq->errors = 0;
 			i = --rq->nr_sectors;
@@ -214,6 +214,7 @@
 			}
                         return ide_stopped;
 		}
+
 		return ide_stopped;	/* the original code did this here (?) */
 	}
 	return ide_error(drive, "write_intr", stat);
@@ -228,21 +229,9 @@
 int ide_multwrite (ide_drive_t *drive, unsigned int mcount)
 {
  	ide_hwgroup_t	*hwgroup= HWGROUP(drive);
-
-	/*
-	 *	This may look a bit odd, but remember wrq is a copy of the
-	 *	request not the original. The pointers are real however so the
-	 *	bh's are not copies. Remember that or bad stuff will happen
-	 *
-	 *	At the point we are called the drive has asked us for the
-	 *	data, and its our job to feed it, walking across bh boundaries
-	 *	if need be.
-	 */
-
- 	struct request	*rq = &hwgroup->wrq;
+	struct request	*rq = hwgroup->rq;
 
   	do {
- 		unsigned long flags;
   		unsigned int nsect = rq->current_nr_sectors;
 		if (nsect > mcount)
 			nsect = mcount;
@@ -254,7 +243,6 @@
 			drive->name, rq->sector, (unsigned long) rq->buffer,
 			nsect, rq->nr_sectors - nsect);
 #endif
-		spin_lock_irqsave(&io_request_lock, flags);	/* Is this really necessary? */
 #ifdef CONFIG_BLK_DEV_PDC4030
 		rq->sector += nsect;
 #endif
@@ -263,26 +251,12 @@
 			printk("%s: multwrite: count=%d, current=%ld\n",
 				drive->name, nsect, rq->nr_sectors);
 #endif
-			spin_unlock_irqrestore(&io_request_lock, flags);
 			break;
 		}
-		if ((rq->current_nr_sectors -= nsect) == 0) {
-			if ((rq->bh = rq->bh->b_reqnext) != NULL) {
-				rq->current_nr_sectors = rq->bh->b_size>>9;
-				rq->buffer             = rq->bh->b_data;
-			} else {
-				spin_unlock_irqrestore(&io_request_lock, flags);
-				printk("%s: buffer list corrupted (%ld, %ld, %d)\n",
-					drive->name, rq->current_nr_sectors,
-					rq->nr_sectors, nsect);
-				ide_end_request(0, hwgroup);
-				return 1;
-			}
-		} else {
-			/* Fix the pointer.. we ate data */
+		if ((rq->current_nr_sectors -= nsect) == 0)
+			ide_end_request(1, hwgroup);
+		else
 			rq->buffer += nsect << 9;
-		}
-                spin_unlock_irqrestore(&io_request_lock, flags);
 	} while (mcount);
         return 0;
 }
@@ -293,9 +267,8 @@
 static ide_startstop_t multwrite_intr (ide_drive_t *drive)
 {
 	byte stat;
-	int i;
 	ide_hwgroup_t *hwgroup = HWGROUP(drive);
-	struct request *rq = &hwgroup->wrq;
+	struct request *rq = hwgroup->rq;
 
 	if (OK_STAT(stat=GET_STAT(),DRIVE_READY,drive->bad_wstat)) {
 		if (stat & DRQ_STAT) {
@@ -310,20 +283,10 @@
 				return ide_started;
 			}
 		} else {
-			/*
-			 *	If the copy has all the blocks completed then
-			 *	we can end the original request.
-			 */
-			if (!rq->nr_sectors) {	/* all done? */
-				rq = hwgroup->rq;
-				for (i = rq->nr_sectors; i > 0;){
-					i -= rq->current_nr_sectors;
-					ide_end_request(1, hwgroup);
-				}
-				return ide_stopped;
-			}
+			if (!rq->nr_sectors)
+				ide_end_request(1, hwgroup);
 		}
-		return ide_stopped;	/* the original code did this here (?) */
+		return ide_stopped;
 	}
 	return ide_error(drive, "multwrite_intr", stat);
 }
@@ -383,7 +346,13 @@
 {
 	if (IDE_CONTROL_REG)
 		OUT_BYTE(drive->ctl,IDE_CONTROL_REG);
-	OUT_BYTE(rq->nr_sectors,IDE_NSECTOR_REG);
+
+	/*
+	 * for clustered kio requests, nr_sectors can be much bigger than
+	 * what ide hw can handle. do those in chunks of 256
+	 */
+	OUT_BYTE(rq->nr_sectors < 256 ? rq->nr_sectors : 0, IDE_NSECTOR_REG);
+
 #ifdef CONFIG_BLK_DEV_PDC4030
 	if (drive->select.b.lba || IS_PDC4030_DRIVE) {
 #else /* !CONFIG_BLK_DEV_PDC4030 */
@@ -454,7 +423,6 @@
 			 *
 			 * Except when you get an error it seems...
 			 */
-			hwgroup->wrq = *rq; /* scratchpad */
 			ide_set_handler (drive, &multwrite_intr, WAIT_CMD, NULL);
 			if (ide_multwrite(drive, drive->mult_count)) {
 				unsigned long flags;
Index: drivers/ide/ide-dma.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide-dma.c,v
retrieving revision 1.6
diff -u -r1.6 ide-dma.c
--- drivers/ide/ide-dma.c	2000/10/09 21:21:05	1.6
+++ drivers/ide/ide-dma.c	2000/12/11 14:30:01
@@ -197,9 +197,10 @@
 	if (OK_STAT(stat,DRIVE_READY,drive->bad_wstat|DRQ_STAT)) {
 		if (!dma_stat) {
 			struct request *rq = HWGROUP(drive)->rq;
-			rq = HWGROUP(drive)->rq;
-			for (i = rq->nr_sectors; i > 0;) {
-				i -= rq->current_nr_sectors;
+			if ((i = rq->nr_sectors) > 256)
+				i = 256;
+			while (i > 0) {
+				i -= rq->hard_cur_sectors;
 				ide_end_request(1, HWGROUP(drive));
 			}
 			return ide_stopped;
@@ -209,16 +210,81 @@
 	return ide_error(drive, "dma_intr", stat);
 }
 
-static int ide_build_sglist (ide_hwif_t *hwif, struct request *rq)
+/*
+ * Build kiobuf based scatter-gather list. Return number of segments.
+ */
+static int ide_kio_sgl(struct request *rq, struct scatterlist *sg)
+{
+	unsigned int total_bytes, nr_bytes, nr_seg, sg_size, segs;
+	struct kiobuf *kiobuf = rq->kiobuf;
+	unsigned int c_off, nr_pgs = 0, nr_sects = 0;
+	unsigned char *va;
+
+	/*
+	 * For leftover requests, only rq->nr_sectors gets adjusted.
+	 */
+	total_bytes = rq->nr_sectors << 9;
+
+	/*
+	 * find offset
+	 */
+	c_off = kiobuf->offset + (((kiobuf->length >> 9) - rq->nr_sectors) << 9);
+	if (c_off >= PAGE_SIZE) {
+		nr_pgs = (c_off >> PAGE_SHIFT);
+		c_off &= ~PAGE_MASK;
+	}
+
+	/*
+	 * limit to max ide hw size, if need be
+	 */
+	if ((segs = rq->nr_segments) > PRD_ENTRIES)
+		segs = PRD_ENTRIES;
+
+	/*
+	 * now build sg list
+	 */
+	for (sg_size = 0, nr_seg = 0, nr_bytes = 0; nr_seg < segs && nr_sects <= 256; nr_seg++, nr_sects += sg_size >> 9) {
+		va = c_off + (char *) page_address(kiobuf->maplist[nr_pgs]);
+		nr_pgs++;
+		if (c_off) {
+			if ((sg_size = PAGE_SIZE - c_off) > total_bytes)
+				sg_size = total_bytes;
+
+			c_off = 0;
+		} else if (nr_bytes + PAGE_SIZE > total_bytes) {
+			sg_size = total_bytes - nr_bytes;
+		} else {
+			sg_size = PAGE_SIZE;
+		}
+
+		nr_bytes += sg_size;
+		memset(&sg[nr_seg], 0, sizeof(struct scatterlist));
+		sg[nr_seg].address = va;
+		sg[nr_seg].length = sg_size;
+	}
+
+	/*
+	 * your plain paranoia
+	 */
+	if ((nr_bytes > total_bytes) || (nr_pgs > rq->kiobuf->nr_pages)) {
+		printk(KERN_ERR
+                       "ide_kio_sgl: sgl bytes[%d], request bytes[%d]\n"
+                       "ide_kio_sgl: pgcnt[%d], kiobuf->pgcnt[%d]!\n",
+			nr_bytes, total_bytes, nr_pgs, kiobuf->nr_pages);
+		BUG();
+	}
+
+	return nr_seg;
+}
+
+/*
+ * Build bh based scatter-gather list. Return number of segments.
+ */
+static int ide_bh_sgl(struct request *rq, struct scatterlist *sg)
 {
 	struct buffer_head *bh;
-	struct scatterlist *sg = hwif->sg_table;
 	int nents = 0;
 
-	if (rq->cmd == READ)
-		hwif->sg_dma_direction = PCI_DMA_FROMDEVICE;
-	else
-		hwif->sg_dma_direction = PCI_DMA_TODEVICE;
 	bh = rq->bh;
 	do {
 		unsigned char *virt_addr = bh->b_data;
@@ -229,12 +295,32 @@
 				break;
 			size += bh->b_size;
 		}
-		memset(&sg[nents], 0, sizeof(*sg));
+		memset(&sg[nents], 0, sizeof(struct scatterlist));
 		sg[nents].address = virt_addr;
 		sg[nents].length = size;
 		nents++;
 	} while (bh != NULL);
 
+	return nents;
+}
+
+static int ide_build_sglist (ide_hwif_t *hwif, struct request *rq)
+{
+	struct scatterlist *sg = hwif->sg_table;
+	int nents;
+
+	if (rq->cmd == READ)
+		hwif->sg_dma_direction = PCI_DMA_FROMDEVICE;
+	else
+		hwif->sg_dma_direction = PCI_DMA_TODEVICE;
+
+	if (rq->bh)
+		nents = ide_bh_sgl(rq, sg);
+	else if (rq->kiobuf)
+		nents = ide_kio_sgl(rq, sg);
+	else
+		panic("neither rq->bh nor rq->kiobuf in place\n");
+
 	return pci_map_sg(hwif->pci_dev, sg, nents, hwif->sg_dma_direction);
 }
 
@@ -257,6 +343,9 @@
 
 	HWIF(drive)->sg_nents = i = ide_build_sglist(HWIF(drive), HWGROUP(drive)->rq);
 
+	if (!i)
+		return 0;
+
 	sg = HWIF(drive)->sg_table;
 	while (i && sg_dma_len(sg)) {
 		u32 cur_addr;
@@ -266,7 +355,7 @@
 		cur_len = sg_dma_len(sg);
 
 		while (cur_len) {
-			if (++count >= PRD_ENTRIES) {
+			if (count++ >= PRD_ENTRIES) {
 				printk("%s: DMA table too small\n", drive->name);
 				pci_unmap_sg(HWIF(drive)->pci_dev,
 					     HWIF(drive)->sg_table,
@@ -292,8 +381,11 @@
 		i--;
 	}
 
-	if (!count)
+	if (!count) {
+		struct request *rq = HWGROUP(drive)->rq;
 		printk("%s: empty DMA table?\n", drive->name);
+		printk("sector %lu, hard sector %lu, nr_sectors %lu, hard nr_sectors %lu, cur nr_sectors %lu\n", rq->sector, rq->hard_sector, rq->nr_sectors, rq->hard_nr_sectors, rq->current_nr_sectors);
+	}
 	else if (!is_trm290_chipset)
 		*--table |= cpu_to_le32(0x80000000);
 
Index: drivers/ide/ide-probe.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide-probe.c,v
retrieving revision 1.10
diff -u -r1.10 ide-probe.c
--- drivers/ide/ide-probe.c	2000/10/09 21:21:05	1.10
+++ drivers/ide/ide-probe.c	2000/12/11 14:30:01
@@ -763,7 +763,7 @@
 #ifdef CONFIG_BLK_DEV_PDC4030
 		*max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : MAX_SECTORS);
 #else
-		*max_sect++ = MAX_SECTORS;
+		*max_sect++ = 256;
 #endif
 		*max_ra++ = MAX_READAHEAD;
 	}
Index: drivers/ide/ide.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/ide.c,v
retrieving revision 1.14
diff -u -r1.14 ide.c
--- drivers/ide/ide.c	2000/11/01 21:35:42	1.14
+++ drivers/ide/ide.c	2000/12/11 14:30:02
@@ -502,6 +502,90 @@
 	return 1;		/* drive ready: *might* be interrupting */
 }
 
+int ide_end_kio_request(struct request *rq, int uptodate, int sectors)
+{
+	int pgcnt = 0, nr_pages;
+	size_t curr_offset;
+	unsigned int nr_bytes, total_bytes, page_sectors, nr_sectors;
+	char *va = NULL;
+
+	if ((nr_sectors = rq->hard_nr_sectors) > 256)
+		nr_sectors = 256;
+
+	nr_pages = rq->kiobuf->nr_pages;
+	total_bytes = nr_sectors << 9;
+	curr_offset = rq->kiobuf->offset;
+
+	/*
+	 * In the case of leftover requests, the kiobuf->length
+	 * remains the same, but rq->nr_sectors would be smaller.
+	 * Adjust curr_offset in this case. If not a leftover,
+	 * the following makes no difference.
+	 */
+	curr_offset += (((rq->kiobuf->length >> 9) - nr_sectors) << 9);
+
+	/* How far into the kiobuf is the offset? */
+	if (curr_offset > PAGE_SIZE) {
+		pgcnt = curr_offset >> PAGE_SHIFT;
+		curr_offset &= ~PAGE_MASK;
+	}
+
+	/*		
+	 * Reusing the pgcnt and va value from above:
+	 * Harvest pages to account for number of sectors 
+	 * passed into function. 
+	 */
+	for (nr_bytes = 0; pgcnt < nr_pages && nr_bytes != total_bytes; pgcnt++) {
+		va = page_address(rq->kiobuf->maplist[pgcnt]) + curr_offset;
+		/* First page or final page? Partial page? */
+		if (curr_offset) {
+			if (PAGE_SIZE - curr_offset > total_bytes)
+				page_sectors = total_bytes >> 9;
+			else
+				page_sectors = (PAGE_SIZE - curr_offset) >> 9;
+			curr_offset = 0;
+		} else if (nr_bytes + PAGE_SIZE > total_bytes) {
+			page_sectors = (total_bytes - nr_bytes) >> 9;
+		} else {
+			page_sectors = PAGE_SIZE >> 9;
+		}
+		nr_bytes += (page_sectors << 9);
+		/* Leftover sectors in this page (onward)? */
+		if (sectors < page_sectors) {
+			rq->hard_nr_sectors -= sectors;
+			rq->sector += sectors;
+			rq->hard_cur_sectors = page_sectors - sectors;
+			va += (sectors << 9); /* Update for rq->buffer */
+			sectors = 0;
+			break;
+		}
+
+		/* Mark this page as done */
+		rq->nr_segments--;
+		rq->hard_nr_sectors -= page_sectors;
+		rq->sector += page_sectors;
+		if (!uptodate && rq->kiobuf->errno)
+			rq->kiobuf->errno = -EIO;
+		sectors -= page_sectors;
+	}
+
+	rq->current_nr_sectors = rq->hard_cur_sectors;
+	rq->nr_sectors = rq->hard_nr_sectors;
+
+	/* Check for leftovers */
+	if (rq->hard_nr_sectors) {
+		rq->buffer = va;
+		if (!rq->nr_segments)
+			rq->nr_segments = 1;
+		return 1;
+	}
+
+	if (rq->kiobuf->end_io)
+		rq->kiobuf->end_io(rq->kiobuf);
+
+	return 0;
+}
+
 /*
  * This is our end_request replacement function.
  */
@@ -509,11 +593,24 @@
 {
 	struct request *rq;
 	unsigned long flags;
+	int r;
 
 	spin_lock_irqsave(&io_request_lock, flags);
 	rq = hwgroup->rq;
+
+	/*
+	 * kiovec request
+	 */
+	if (rq->kiobuf)
+		r = ide_end_kio_request(rq, uptodate, rq->hard_cur_sectors);
+	else
+		r = end_that_request_first(rq, uptodate, hwgroup->drive->name);
 
-	if (!end_that_request_first(rq, uptodate, hwgroup->drive->name)) {
+	/*
+	 * finish request if either kiovec request or bh based request
+	 * is done
+	 */
+	if (!r) {
 		add_blkdev_randomness(MAJOR(rq->rq_dev));
 		blkdev_dequeue_request(rq);
         	hwgroup->rq = NULL;
Index: drivers/ide/pdc4030.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/drivers/ide/pdc4030.c,v
retrieving revision 1.2
diff -u -r1.2 pdc4030.c
--- drivers/ide/pdc4030.c	2000/05/02 21:36:51	1.2
+++ drivers/ide/pdc4030.c	2000/12/11 14:30:02
@@ -453,7 +453,7 @@
 static ide_startstop_t promise_write (ide_drive_t *drive)
 {
 	ide_hwgroup_t *hwgroup = HWGROUP(drive);
-	struct request *rq = &hwgroup->wrq;
+	struct request *rq = hwgroup->rq;
 
 #ifdef DEBUG_WRITE
 	printk(KERN_DEBUG "%s: promise_write: sectors(%ld-%ld), "
@@ -541,7 +541,6 @@
 	    	}
 		if (!drive->unmask)
 			__cli();	/* local CPU only */
-		HWGROUP(drive)->wrq = *rq; /* scratchpad */
 		return promise_write(drive);
 
 	} else {
Index: fs/pagebuf/page_buf_io.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/fs/pagebuf/page_buf_io.c,v
retrieving revision 1.36
diff -u -r1.36 page_buf_io.c
--- fs/pagebuf/page_buf_io.c	2000/11/21 10:24:08	1.36
+++ fs/pagebuf/page_buf_io.c	2000/12/11 14:30:04
@@ -1016,8 +1016,8 @@
 	/* arr is sized for worst case */
 	struct buffer_head *bh, *head, *arr[PAGE_CACHE_SIZE / 512];
 	int blocksize, bbits = inode->i_sb->s_blocksize_bits;
-	unsigned long kaddr = 0;
 	long nr, i, status = 0;
+	char *kaddr = NULL;
 
 	if (!PageLocked(page) || (inode->i_op->pagebuf_bmap == NULL))
 		PAGE_BUG(page);
Index: include/linux/blkdev.h
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/include/linux/blkdev.h,v
retrieving revision 1.26
diff -u -r1.26 blkdev.h
--- include/linux/blkdev.h	2000/10/11 20:41:07	1.26
+++ include/linux/blkdev.h	2000/12/11 14:30:06
@@ -39,7 +39,7 @@
 	unsigned long start_time;
 	unsigned long sector;
 	unsigned long nr_sectors;
-	unsigned long hard_sector, hard_nr_sectors;
+	unsigned long hard_sector, hard_nr_sectors, hard_cur_sectors;
 	unsigned int nr_segments;
 	unsigned int nr_hw_segments;
 	unsigned long current_nr_sectors;
Index: include/linux/ide.h
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/include/linux/ide.h,v
retrieving revision 1.25
diff -u -r1.25 ide.h
--- include/linux/ide.h	2000/11/01 21:35:42	1.25
+++ include/linux/ide.h	2000/12/11 14:30:08
@@ -497,7 +497,6 @@
 	ide_hwif_t		*hwif;	/* ptr to current hwif in linked-list */
 	struct request		*rq;	/* current request */
 	struct timer_list	timer;	/* failsafe timer */
-	struct request		wrq;	/* local copy of current write rq */
 	unsigned long		poll_timeout;	/* timeout value during long polls */
 	ide_expiry_t		*expiry;	/* queried upon timeouts */
 } ide_hwgroup_t;
@@ -657,6 +656,7 @@
 #include <linux/blk.h>
 
 void ide_end_request(byte uptodate, ide_hwgroup_t *hwgroup);
+int ide_end_kio_request(struct request *rq, int uptodate, int sectors);
 
 /*
  * This is used for (nearly) all data transfers from/to the IDE interface
Index: include/linux/major.h
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/include/linux/major.h,v
retrieving revision 1.22
diff -u -r1.22 major.h
--- include/linux/major.h	2000/10/23 18:56:35	1.22
+++ include/linux/major.h	2000/12/11 14:30:11
@@ -165,8 +165,23 @@
   (SCSI_DISK_MAJOR(M)	\
    || (M) == SCSI_CDROM_MAJOR)
 
-static __inline__ int scsi_blk_major(int m) {
+static inline int scsi_blk_major(int m)
+{
 	return SCSI_BLK_MAJOR(m);
+}
+
+/*
+ * Tests for IDE devices
+ */
+#define IDE_DISK_MAJOR(M)	((M) == IDE0_MAJOR || (M) == IDE1_MAJOR || \
+				(M) == IDE2_MAJOR || (M) == IDE3_MAJOR || \
+				(M) == IDE4_MAJOR || (M) == IDE5_MAJOR || \
+				(M) == IDE6_MAJOR || (M) == IDE7_MAJOR || \
+				(M) == IDE8_MAJOR || (M) == IDE9_MAJOR)
+
+static inline int ide_blk_major(int m)
+{
+	return IDE_DISK_MAJOR(m);
 }
 
 #endif

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Mon Dec 11 09:36:38 2000
Received:  by oss.sgi.com id <S553804AbQLKRg2>;
	Mon, 11 Dec 2000 09:36:28 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:55091 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553665AbQLKRgJ>;
	Mon, 11 Dec 2000 09:36:09 -0800
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA20251
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 09:36:09 -0800 (PST)
	mail_from (hawkes@engr.sgi.com)
Received: from pchawkes (sshgate.corp.sgi.com [169.238.216.146])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with SMTP id JAA70104
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 09:34:52 -0800 (PST)
Message-ID: <004f01c06398$7d56e740$6401a8c0@marin1.sfba.home.com>
From:   "John Hawkes" <hawkes@engr.sgi.com>
To:     <linux-xfs@oss.sgi.com>
Subject: CONFIG_FRAME_POINTER and arch/i386/kernel/semaphore.c
Date:   Mon, 11 Dec 2000 09:33:34 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Is there a reason why the xfs version of arch/i386/kernel/semaphore.c
has added:
  #if defined(CONFIG_FRAME_POINTER)
     ...
  #endif
for the asm routines __down_failed, __down_failed_interruptible, and
__down_failed_trylock, but *not* for __up_wakeup, __down_read_failed,
and __down_write_failed?

John Hawkes


From owner-linux-xfs@oss.sgi.com Mon Dec 11 09:52:07 2000
Received:  by oss.sgi.com id <S553859AbQLKRvs>;
	Mon, 11 Dec 2000 09:51:48 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:36979 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553752AbQLKRvd>; Mon, 11 Dec 2000 09:51:33 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA08682
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 09:59:47 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA71025; Mon, 11 Dec 2000 11:50:15 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA48962; Mon, 11 Dec 2000 11:50:15 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBBHoFd22968;
	Mon, 11 Dec 2000 11:50:15 -0600
Message-ID: <3A3513D6.2E4FC334@thebarn.com>
Date:   Mon, 11 Dec 2000 11:50:15 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     John Hawkes <hawkes@engr.sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: CONFIG_FRAME_POINTER and arch/i386/kernel/semaphore.c
References: <004f01c06398$7d56e740$6401a8c0@marin1.sfba.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

John Hawkes wrote:

That is part of the KDB patch.
It isn't specific to XFS.

> Is there a reason why the xfs version of arch/i386/kernel/semaphore.c
> has added:
>   #if defined(CONFIG_FRAME_POINTER)
>      ...
>   #endif
> for the asm routines __down_failed, __down_failed_interruptible, and
> __down_failed_trylock, but *not* for __up_wakeup, __down_read_failed,
> and __down_write_failed?
>
> John Hawkes


From owner-linux-xfs@oss.sgi.com Mon Dec 11 10:44:27 2000
Received:  by oss.sgi.com id <S553865AbQLKSoR>;
	Mon, 11 Dec 2000 10:44:17 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:21881 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553862AbQLKSoH>; Mon, 11 Dec 2000 10:44:07 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA09457
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 10:52:21 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA72240 for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 12:42:50 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA31947 for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 12:42:50 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBBIgod23248
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 12:42:50 -0600
Message-ID: <3A352029.19894EE5@thebarn.com>
Date:   Mon, 11 Dec 2000 12:42:49 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Initial fix for non 4k page =?ISO-8859-1?Q?systems.=0E?=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I need to rework this to make it a bit cleaner.
But I finally tracked down the problem with meta data corruption on
non 4k page systems.

Basically the problem is due to kmalloc returning memory that isn't disk
block aligned (512).
In the case of the super block; kmalloc was returning a pointer 768
bytes into a page.
Pagebuf keeps track of individual disk block via a bit array in the page
structure, but
this works under the assumption that the page is divided equally on 512
byte boundaries.
Obviously 768 is not on a 512 byte boundary, this was confusing the rest
of the pagebuf code
causing it incorrectly think it needed to write out 2 blocks (1024) for
the superblock.

I'm not sure if there is a way to force kmalloc to align memory, if
anybody has a suggest let me know
in the mean time this patch will realign things to the correct boundary.

I've only testing this on an alpha system, so I curious to see if this
fixes ppc and ia64.



*** /usr/tmp/TmpDir.23191-0/linux/fs/pagebuf/page_buf.c_1.44    Mon Dec
11 12:31:19 2000
--- linux/fs/pagebuf/page_buf.c Tue Nov  5 04:32:05 1912
***************
*** 862,867 ****
--- 862,868 ----
  {
        int rval;
        void *rmem;
+       size_t tlen = len;
        int flags = _PBF_LOCKABLE | PBF_FORCEIO;
        page_buf_t *pb;

***************
*** 870,879 ****
        if (0 != rval)
                return (NULL);

!       if ((rmem = kmalloc(len, GFP_KERNEL)) == 0) {
                pagebuf_free(pb);
                return (NULL);
        }
        if ((rval = pagebuf_associate_memory(pb, rmem, len)) != 0) {
                kfree(rmem);
                pagebuf_free(pb);
--- 871,897 ----
        if (0 != rval)
                return (NULL);

! alloc:
!       if ((rmem = kmalloc(tlen, GFP_KERNEL)) == 0) {
                pagebuf_free(pb);
                return (NULL);
        }
+ #define BLOCK_MASK (~(512-1))
+       if ((size_t)rmem != ((size_t)rmem & (size_t)BLOCK_MASK)){
+               if(tlen != len){
+                       rmem =  (size_t)rmem + (size_t)512 &
(size_t)BLOCK_MASK;
+                       printk("OK NEW 0x%p tlen %d\n",rmem,tlen);
+                       goto out;
+               }
+               printk("pb_get_no_daddr NOT block 0x%p mask 0x%p len
%d\n",
+                       rmem,
+                       ((size_t)rmem & (size_t)BLOCK_MASK),
+                       len);
+               kfree(rmem);
+               tlen = len << 1;
+               goto alloc;
+ }
+ out:
        if ((rval = pagebuf_associate_memory(pb, rmem, len)) != 0) {
                kfree(rmem);
                pagebuf_free(pb);


From owner-linux-xfs@oss.sgi.com Mon Dec 11 14:55:08 2000
Received:  by oss.sgi.com id <S553650AbQLKWyt>;
	Mon, 11 Dec 2000 14:54:49 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54298 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553667AbQLKWyV>; Mon, 11 Dec 2000 14:54:21 -0800
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA04759
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 15:02:36 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id OAA11254 for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 14:53:50 -0800 (PST)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id JAA02336; Tue, 12 Dec 2000 09:51:15 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     "John Hawkes" <hawkes@engr.sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: CONFIG_FRAME_POINTER and arch/i386/kernel/semaphore.c 
In-reply-to: Your message of "Mon, 11 Dec 2000 09:33:34 -0800."
             <004f01c06398$7d56e740$6401a8c0@marin1.sfba.home.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 12 Dec 2000 09:51:14 +1100
Message-ID: <1192.976575074@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 11 Dec 2000 09:33:34 -0800, 
"John Hawkes" <hawkes@engr.sgi.com> wrote:
>Is there a reason why the xfs version of arch/i386/kernel/semaphore.c
>has added:
>  #if defined(CONFIG_FRAME_POINTER)
>     ...
>  #endif
>for the asm routines __down_failed, __down_failed_interruptible, and
>__down_failed_trylock, but *not* for __up_wakeup, __down_read_failed,
>and __down_write_failed?

That is from the kdb patch, not from XFS.  Unfortunately the use of
CONFIG_FRAME_POINTER was added before I took over kdb so I am guessing
here.  Early versions of kdb required frame pointers to do backtrace.
__down_failedxxx routines can wait so they often appear in back traces.
__up_wakeup never waits so it was probably ignored for back trace
purposes.  __down_read_failed and __down_write_failed can wait, I have
no idea why they do not have frame pointers.

Current kdb does not need frame pointers to get a back trace on ix86 so
the lack of CONFIG_FRAME_POINTER on __up_wakeup, __down_read_failed and
__down_write_failed has not been a problem.  For consistency, I will
add frame pointers to these routines in my next but one kdb patch.


From owner-linux-xfs@oss.sgi.com Mon Dec 11 15:08:08 2000
Received:  by oss.sgi.com id <S553729AbQLKXHt>;
	Mon, 11 Dec 2000 15:07:49 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:18716 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553667AbQLKXHS>;
	Mon, 11 Dec 2000 15:07:18 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA09714
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 15:07:17 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA11245; Mon, 11 Dec 2000 15:01:41 -0800 (PST)
Message-ID: <3A355D96.9D50CA69@sgi.com>
Date:   Mon, 11 Dec 2000 15:04:54 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Keith Owens <kaos@melbourne.sgi.com>
CC:     John Hawkes <hawkes@engr.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: CONFIG_FRAME_POINTER and arch/i386/kernel/semaphore.c
References: <1192.976575074@kao2.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Keith Owens wrote:
> 
> On Mon, 11 Dec 2000 09:33:34 -0800,
> "John Hawkes" <hawkes@engr.sgi.com> wrote:
> >Is there a reason why the xfs version of arch/i386/kernel/semaphore.c
> >has added:
> >  #if defined(CONFIG_FRAME_POINTER)
> >     ...
> >  #endif
> >for the asm routines __down_failed, __down_failed_interruptible, and
> >__down_failed_trylock, but *not* for __up_wakeup, __down_read_failed,
> >and __down_write_failed?
> 
> That is from the kdb patch, not from XFS.  Unfortunately the use of
> CONFIG_FRAME_POINTER was added before I took over kdb so I am guessing
> here.  Early versions of kdb required frame pointers to do backtrace.
> __down_failedxxx routines can wait so they often appear in back traces.
> __up_wakeup never waits so it was probably ignored for back trace
> purposes.  __down_read_failed and __down_write_failed can wait, I have
> no idea why they do not have frame pointers.

Yes, it is for backtracing purposes. I'd guess the two omitted
routines were likely due to an oversight ... I know some of them
were added because I had pointed out missing frames; guess there
weren't any complaints about the omitted routines.

If you don't need FRAME_POINTER, why not remove it entirely?

BTW, John, the profiling tool also uses similar tricks to
record the callers of the down routines ... and _those_ you
might have to keep.

> 
> Current kdb does not need frame pointers to get a back trace on ix86 so
> the lack of CONFIG_FRAME_POINTER on __up_wakeup, __down_read_failed and
> __down_write_failed has not been a problem.  For consistency, I will
> add frame pointers to these routines in my next but one kdb patch.

From owner-linux-xfs@oss.sgi.com Mon Dec 11 15:17:39 2000
Received:  by oss.sgi.com id <S553814AbQLKXRT>;
	Mon, 11 Dec 2000 15:17:19 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:7967 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553799AbQLKXRS>;
	Mon, 11 Dec 2000 15:17:18 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA11183
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 15:17:17 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA75925; Mon, 11 Dec 2000 17:14:44 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA91140; Mon, 11 Dec 2000 17:14:44 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBBNEid23867;
	Mon, 11 Dec 2000 17:14:44 -0600
Message-ID: <3A355FE4.455ACC88@thebarn.com>
Date:   Mon, 11 Dec 2000 17:14:44 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jens Axboe <axboe@suse.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com> <20001211003152.O294@suse.de> <3A34478B.BCCFB089@thebarn.com> <20001211150432.C294@suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>
> > Just to expand on the problem a bit;
> > The corruption shows up under heavy load.
> > 4 doio files each with 4 processes a piece doing
> > different types of io read/write readv/writev and mmap.
> > The  corruption always due to  mmap'ed io.
> >
> > My best guess at this: Since IO path through uses
> > both bufer_head and kio bufs.
> > There is a sequence discrepancy, kio buf io may be initiated after a
> > buffer_head
> > io assuming the buffer head controlled data made it to disk but it may not.
>
> You mean lack of ordering with bh vs kio? Assuming they all make it to
> disk eventually, I don't see a specific problem that would cause
> corruption there.

If both io paths are referencing the same area on disk, and thus
the same page it is conceivable.
One ot the things that doio does to force corruption.
do normal read/write to a certain part of the file making sure
the boundary does not fall on a page and/or fs block boundary
then mmap the file right next the normal io area.

-----------------------------------
|                                       |
|         Page                       |
-----------------------------------
^R/W     ^    mmap       ^

This apparently has exposed a lot of corruption problems, in fact ext2
blows up rather quickly with doio.



>
> > Pagebuf issues a kio buf io write to the disk bypassing all the queues and
> > the disk elevator
> > etc. etc.. thus "sneaking" a write in before the buffer head io has a
> > chance to hit disk.
>
> The kiobuf request will be sequenced just like any other request, unless
> it manipulates the queue directly itself (which, without having looked,
> I'm assuming it does not. this would be ugly)

It is very possible the problem is in pagebuf itself, and not related to
the elevator.
I've let Chait deal with these thing until this point... guess I need to dig
into the code bit more.


I'm trying to convince one of our linux  testers to run the ide patch
through its paces.
Hopefully we'll have some results in a few days.

Thanks for your work in this area.


>
>
> > I really have no idea if this is what is happening but every story has to
> > have a begging :-)
>
> Right, we'll track it down eventually.
>
> > > rearranged by the elevator. That should completely fix such log
> > > starvation issues.
> >
> > If you patch proves to be stable enough, we can just pull it into the
> > tree.  I appears to clean up some other inefficiencies.
>
> It's stable.
>
> --
> * Jens Axboe <axboe@suse.de>
> * SuSE Labs


From owner-linux-xfs@oss.sgi.com Mon Dec 11 15:18:48 2000
Received:  by oss.sgi.com id <S553825AbQLKXSj>;
	Mon, 11 Dec 2000 15:18:39 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14110 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553813AbQLKXSa>; Mon, 11 Dec 2000 15:18:30 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA01703
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 15:26:43 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id KAA03185; Tue, 12 Dec 2000 10:17:07 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     John Hawkes <hawkes@engr.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: CONFIG_FRAME_POINTER and arch/i386/kernel/semaphore.c 
In-reply-to: Your message of "Mon, 11 Dec 2000 15:04:54 -0800."
             <3A355D96.9D50CA69@sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 12 Dec 2000 10:17:06 +1100
Message-ID: <1700.976576626@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 11 Dec 2000 15:04:54 -0800, 
Rajagopal Ananthanarayanan <ananth@sgi.com> wrote:
>Keith Owens wrote:
>If you don't need FRAME_POINTER, why not remove it entirely?

gdb against the kernel needs frame pointers.  kdb knows all about the
kernel special cases on the stack, gdb does not.  But since we have
made a start on gdb over serial line to kdb, even that argument
disappears.  For consistency I will add frame pointers to the routines
that do not have it but recommend that frame pointers not be used.


From owner-linux-xfs@oss.sgi.com Mon Dec 11 16:32:58 2000
Received:  by oss.sgi.com id <S553733AbQLLAcs>;
	Mon, 11 Dec 2000 16:32:48 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:64816 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553691AbQLLAcY>;
	Mon, 11 Dec 2000 16:32:24 -0800
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA19910
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 16:32:03 -0800 (PST)
	mail_from (ivanr@omen.melbourne.sgi.com)
Received: (from ivanr@localhost)
	by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA65598
	for linux-xfs@oss.sgi.com; Tue, 12 Dec 2000 11:29:31 +1100 (EST)
Date:   Tue, 12 Dec 2000 11:29:31 +1100 (EST)
From:   Ivan Rayner <ivanr@omen.melbourne.sgi.com>
Message-Id: <200012120029.LAA65598@omen.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - undo mods 80337a and 80332a
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Modid:  2.4.x-xfs:slinx:80392a
Date:  Mon Dec 11 15:55:22 PST 2000
Workarea:  omen.melbourne.sgi.com:/hosts/snort/diskb/build6/ivanr/isms/slinx-xfs-base
Undoes mod:  2.4.x-xfs:slinx:80337a
Author:  ivanr

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/xfs_mount.h - 1.121
Subject: TAKE - 

undo mod 80332a: we will solve the problem a different way

Modid:  2.4.x-xfs:slinx:80394a
Date:  Mon Dec 11 16:27:26 PST 2000
Workarea:  omen.melbourne.sgi.com:/hosts/snort/diskb/build6/ivanr/isms/slinx-xfs-base
Undoes mod:  2.4.x-xfs:slinx:80332a
Author:  ivanr

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/linux/xfs_fs_subr.c - 1.24
linux/fs/xfs/linux/xfs_fs_subr.h - 1.3
linux/fs/xfs/linux/xfs_super.h - 1.6
linux/fs/xfs/xfs_iocore.c - 1.22
linux/fs/xfs/xfs_mount.h - 1.122
linux/fs/xfs/xfs_vfsops.c - 1.303
linux/fs/xfs/xfs_vnodeops.c - 1.479

From owner-linux-xfs@oss.sgi.com Mon Dec 11 17:13:58 2000
Received:  by oss.sgi.com id <S553800AbQLLBNj>;
	Mon, 11 Dec 2000 17:13:39 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:25913 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553720AbQLLBNM>;
	Mon, 11 Dec 2000 17:13:12 -0800
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA23910
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 17:13:12 -0800 (PST)
	mail_from (hawkes@engr.sgi.com)
Received: from pchawkes (sshgate.corp.sgi.com [169.238.216.146])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with SMTP id RAA13589;
	Mon, 11 Dec 2000 17:11:48 -0800 (PST)
Message-ID: <012001c063d8$3c4ae180$6401a8c0@marin1.sfba.home.com>
From:   "John Hawkes" <hawkes@engr.sgi.com>
To:     "Keith Owens" <kaos@melbourne.sgi.com>,
        "Rajagopal Ananthanarayanan" <ananth@sgi.com>
Cc:     <linux-xfs@oss.sgi.com>
References: <1700.976576626@kao2.melbourne.sgi.com>
Subject: Re: CONFIG_FRAME_POINTER and arch/i386/kernel/semaphore.c 
Date:   Mon, 11 Dec 2000 17:09:53 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

From: "Keith Owens" <kaos@melbourne.sgi.com>
...
> For consistency I will add frame pointers to the routines
> that do not have it but recommend that frame pointers not be used.

As it turns out, kernprof's mcount functionality claims to need frame
pointers (to the point where the high-level kernel Makefile turns on
CONFIG_FRAME_POINTER if CONFIG_MCOUNT is set), yet the current version
0.9 of the kernprof patch doesn't mimic what the kdb patch does in
semaphore.c and insert the frame pointer instructions into the entry and
exit of those selected asm routines.  Unless someone tells me I'm wrong,
I'll add those CONFIG_FRAME_POINTER instructions into the kernprof
patch.

John Hawkes


From owner-linux-xfs@oss.sgi.com Mon Dec 11 17:23:59 2000
Received:  by oss.sgi.com id <S553823AbQLLBXt>;
	Mon, 11 Dec 2000 17:23:49 -0800
Received: from cndyland.com ([207.66.106.80]:50182 "EHLO ns2.iqintermedia.com")
	by oss.sgi.com with ESMTP id <S553744AbQLLBX1>;
	Mon, 11 Dec 2000 17:23:27 -0800
Received: from localhost (mpike@localhost)
	by ns2.iqintermedia.com (8.11.0/8.11.0) with ESMTP id eBC3JZY06112;
	Mon, 11 Dec 2000 20:19:35 -0700
Date:   Mon, 11 Dec 2000 20:19:34 -0700 (MST)
From:   Michael Pike <mpike@ns2.iqintermedia.com>
To:     Nathan Scott <nathans@snort.melbourne.sgi.com>
cc:     <linux-xfs@oss.sgi.com>
Subject: Re: TAKE - build
In-Reply-To: <200012110651.RAA61507@snort.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.30.0012112018590.6110-100000@ns2.iqintermedia.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 11 Dec 2000, Nathan Scott wrote:

> This fixes a nasty little problem when building the user tools.
> We use $GZIP to allow an alternate gzip path - unfortunately,
> $GZIP is magic to gzip (default options), and is set by default
> in some distros (to do max compression by default - Daniel came
> across this doing testing on a recent version of Suse).
>
> We now use $ZIP and I've audited the man pages of the other build
> tools we use - I don't think we'll be bitten by this again.  Its
> probably a good idea to do a "make realclean" before your next
> recompile of the user tools.
>
> cheers.
>
>
> Modid:  2.4.x-xfs:slinx:80342a
> Date:  Sun Dec 10 22:45:17 PST 2000
> Workarea:  snort:/diskb/build4/nathans/quota-xfs
> Author:  nathans
>
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
>
> cmd/xfs/Makefile - 1.38
> cmd/xfs/build/Makefile - 1.6
> cmd/xfs/build/tar/Makefile - 1.3
> 	- rework handling of GZIP.
>
> cmd/xfs/configure.in - 1.19
> 	- rework handling of GZIP.  add a better check for libuuid (not just the
> 	  header file).  add commented template for Martin & liblvm.
>
> cmd/xfs/include/builddefs.in - 1.19
> 	- rework handling of GZIP.
>


From owner-linux-xfs@oss.sgi.com Mon Dec 11 17:40:49 2000
Received:  by oss.sgi.com id <S553828AbQLLBk3>;
	Mon, 11 Dec 2000 17:40:29 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:14910 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553822AbQLLBkD>;
	Mon, 11 Dec 2000 17:40:03 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA26325
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 17:40:01 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id MAA06339; Tue, 12 Dec 2000 12:38:37 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     "John Hawkes" <hawkes@engr.sgi.com>
cc:     "Rajagopal Ananthanarayanan" <ananth@sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: CONFIG_FRAME_POINTER and arch/i386/kernel/semaphore.c 
In-reply-to: Your message of "Mon, 11 Dec 2000 17:09:53 -0800."
             <012001c063d8$3c4ae180$6401a8c0@marin1.sfba.home.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 12 Dec 2000 12:38:36 +1100
Message-ID: <3628.976585116@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, 11 Dec 2000 17:09:53 -0800, 
"John Hawkes" <hawkes@engr.sgi.com> wrote:
>From: "Keith Owens" <kaos@melbourne.sgi.com>
>...
>> For consistency I will add frame pointers to the routines
>> that do not have it but recommend that frame pointers not be used.
>
>As it turns out, kernprof's mcount functionality claims to need frame
>pointers (to the point where the high-level kernel Makefile turns on
>CONFIG_FRAME_POINTER if CONFIG_MCOUNT is set), yet the current version
>0.9 of the kernprof patch doesn't mimic what the kdb patch does in
>semaphore.c and insert the frame pointer instructions into the entry and
>exit of those selected asm routines.  Unless someone tells me I'm wrong,
>I'll add those CONFIG_FRAME_POINTER instructions into the kernprof
>patch.

There have been claims in the past that mcount() gets the wrong return
address on ix86 if frame pointers are not available.  I tend to trust
the people who made those claims but I could never reproduce it myself.


From owner-linux-xfs@oss.sgi.com Mon Dec 11 19:03:09 2000
Received:  by oss.sgi.com id <S553844AbQLLDCu>;
	Mon, 11 Dec 2000 19:02:50 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49713 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553829AbQLLDCf>; Mon, 11 Dec 2000 19:02:35 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA01976
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 19:10:47 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA91361
	for linux-xfs@oss.sgi.com; Tue, 12 Dec 2000 14:01:10 +1100 (EST)
Date:   Tue, 12 Dec 2000 14:01:10 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012120301.OAA91361@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - scripts
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Dec 11, 10:04am, Thomas Graichen wrote:
> Subject: new miniroot
> ...
> p.s.: 0.7 will follow sometime soon with some fixes to it i already
>       have around - but 0.6 should work pretty well too (only
>       xfs_admin does not work yet due to missing
>       /usr/bin/expr)

xfs_admin (and xfs_check) no longer have a dependency on
/usr/bin/expr - thanks to kenmcd for the suggested fix.

cheers.


Modid:  2.4.x-xfs:slinx:80405a
Date:  Mon Dec 11 18:59:33 PST 2000
Workarea:  snort:/diskb/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/db/xfs_admin.sh - 1.2
cmd/xfs/db/xfs_check.sh - 1.8
cmd/xfs/db/xfs_check64.sh - 1.6
cmd/xfs/db/xfs_ncheck.sh - 1.4
cmd/xfs/db/xfs_ncheck64.sh - 1.3
	- do not rely on external binaries other than sh and xfs_db (expr is no
	  longer needed).


From owner-linux-xfs@oss.sgi.com Mon Dec 11 20:23:19 2000
Received:  by oss.sgi.com id <S553847AbQLLEXJ>;
	Mon, 11 Dec 2000 20:23:09 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:23605 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553832AbQLLEWx>; Mon, 11 Dec 2000 20:22:53 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA08772; Mon, 11 Dec 2000 20:31:07 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id PAA10082; Tue, 12 Dec 2000 15:21:34 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     kdb@oss.sgi.com, linux-xfs@oss.sgi.com,
        linux-kernel@vger.kernel.org
Subject: [Announce] kdb v1.7 is available 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 12 Dec 2000 15:21:34 +1100
Message-ID: <6020.976594894@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

http://oss.sgi.com/projects/kdb/download/ix86/ contains patches for kdb
v1.7 against 2.4.0-test11 and 2.4.0-test12.

There is a large amount of internal reorganisation from kdb v1.6 to
v1.7 to make it easier to support multiple architectures.  Most of this
is feedback from the kdb for IA64 work in progress.

The patch against 2.4.0-test11 fixes the boot hang with NMI for UP.

kdb v1.7 contains a new "sections" command.  Primarily intended for
interfacing to external debuggers such as gdb, its output is not very
human readable.


From owner-linux-xfs@oss.sgi.com Mon Dec 11 20:47:09 2000
Received:  by oss.sgi.com id <S553849AbQLLEqu>;
	Mon, 11 Dec 2000 20:46:50 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:9270 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553673AbQLLEqX>; Mon, 11 Dec 2000 20:46:23 -0800
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA07759
	for <linux-xfs@oss.sgi.com>; Mon, 11 Dec 2000 20:54:34 -0800 (PST)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA07840;
	Tue, 12 Dec 2000 15:46:09 +1100
Date:   Tue, 12 Dec 2000 15:46:09 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200012120446.PAA07840@sherman.melbourne.sgi.com>
Subject: TAKE - Upgrade xfs to kdb v1.7
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Upgrade xfs to kdb v1.7

Date:  Mon Dec 11 20:44:55 PST 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80409a
linux/lib/string.c - 1.11
linux/include/linux/string.h - 1.7
linux/include/linux/elf.h - 1.10
linux/arch/i386/kernel/irq.c - 1.31
linux/arch/i386/kernel/io_apic.c - 1.23
linux/arch/i386/kernel/entry.S - 1.30
linux/Makefile - 1.74
linux/arch/i386/kernel/apic.c - 1.14
linux/kdb/kdb_bp.c - 1.7
linux/kdb/Makefile - 1.7
linux/include/linux/kdbprivate.h - 1.9
linux/include/linux/kdb.h - 1.13
linux/kdb/kdbmain.c - 1.16
linux/include/asm-i386/kdb.h - 1.7
linux/include/asm-i386/kdbprivate.h - 1.10
linux/arch/i386/kdb/kdba_id.c - 1.8
linux/Documentation/kdb/kdb.mm - 1.10
linux/kdb/kdb_id.c - 1.8
linux/arch/i386/kdb/kdbasupport.c - 1.11
linux/arch/i386/kdb/kdba_bp.c - 1.8
linux/kernel/kallsyms.c - 1.5
linux/include/linux/kallsyms.h - 1.5
linux/kdb/modules/kdbm_pg.c - 1.24


From owner-linux-xfs@oss.sgi.com Tue Dec 12 01:36:51 2000
Received:  by oss.sgi.com id <S553808AbQLLJgn>;
	Tue, 12 Dec 2000 01:36:43 -0800
Received: from TYO202.gate.nec.co.jp ([202.247.6.41]:54284 "EHLO
        TYO202.gate.nec.co.jp") by oss.sgi.com with ESMTP
	id <S553657AbQLLJgY>; Tue, 12 Dec 2000 01:36:24 -0800
Received: from mailsv.nec.co.jp (mailsv51 [10.7.69.90])
	by TYO202.gate.nec.co.jp (8.9.3/3.7W00120618) with ESMTP id SAA12400;
	Tue, 12 Dec 2000 18:36:20 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) by mailsv.nec.co.jp (8.9.3/3.7W-MAILSV-NEC) with ESMTP
	id SAA18066; Tue, 12 Dec 2000 18:35:08 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp. (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48])
	by mahler.hpc.bs1.fc.nec.co.jp (8.9.3/3.7W-HPC5.1E(common)) with ESMTP id SAA07764;
	Tue, 12 Dec 2000 18:29:05 +0900
Date:   Tue, 12 Dec 2000 18:29:05 +0900
Message-ID: <gek8967ztq.wl@hpc.bs1.fc.nec.co.jp>
From:   Hiroshi Aono <h-aono@ap.jp.nec.com>
To:     cattelan@thebarn.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Initial fix for non 4k page =?ISO-8859-1?Q?systems.=0E?=
In-Reply-To: In your message of "Mon, 11 Dec 2000 12:42:49 -0600"
	<3A352029.19894EE5@thebarn.com>
References: <3A352029.19894EE5@thebarn.com>
User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada)
 CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch
 9) (Canyonlands) (i386-pc-linux)
MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Mon, 11 Dec 2000 12:42:49 -0600,
Russell Cattelan <cattelan@thebarn.com> wrote:

Hi,

> But I finally tracked down the problem with meta data corruption on
> non 4k page systems.

Great!

> I've only testing this on an alpha system, so I curious to see if this
> fixes ppc and ia64.

I ran 16KB page size kernel on IA64 with your page_buf.c patch.

[root@luna /]# mkfs -t xfs -b size=16384 -f /dev/sdc1
meta-data=/dev/sdc1              isize=256    agcount=8, agsize=8033 blks
data     =                       bsize=16384  blocks=64258, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=16384 
log      =internal log           bsize=16384  blocks=1000
realtime =none                   extsz=65536  blocks=0, rtextents=0

When I type mount command, I trapped at xlog_brread and xfsbdstrat. 

[root@luna /]# mount -t xfs /dev/sdc1 /mnt/xfs

console messages:
(xfs_log_recover.c includes my debugging codes)
----------8<----------
pb_get_no_daddr NOT block 0xe00000003f080700 mask 0xe00000003f080600 len 512
OK NEW 0xe00000003d238800 tlen 1024
Instruction breakpoint #1 at 0xe0000000007db760
e0000000007db760 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db761 <xfsbdstrat+0x1>:             addl r14=1054344,r1
e0000000007db762 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
Start mounting filesystem: sd(8,33)
pb_get_no_daddr NOT block 0xe00000003f080500 mask 0xe00000003f080400 len 512
OK NEW 0xe00000003ab3bc00 tlen 1024
Instruction breakpoint #0 at 0xe0000000007805e0
e0000000007805e0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007805e1 <xlog_bread+0x1>:             addl r14=1054344,r1
e0000000007805e2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
Instruction breakpoint #1 at 0xe0000000007db760
e0000000007db760 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db761 <xfsbdstrat+0x1>:             addl r14=1054344,r1
e0000000007db762 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe0000000007805e0
e0000000007805e0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007805e1 <xlog_bread+0x1>:             addl r14=1054344,r1
e0000000007805e2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x7cff
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x7cff
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
Instruction breakpoint #1 at 0xe0000000007db760
e0000000007db760 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db761 <xfsbdstrat+0x1>:             addl r14=1054344,r1
e0000000007db762 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
Instruction breakpoint #0 at 0xe0000000007805e0
e0000000007805e0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007805e1 <xlog_bread+0x1>:             addl r14=1054344,r1
e0000000007805e2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x3e7f
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x3e7f
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
Instruction breakpoint #1 at 0xe0000000007db760
e0000000007db760 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db761 <xfsbdstrat+0x1>:             addl r14=1054344,r1
e0000000007db762 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
eth0: card reports no resources.
Instruction breakpoint #0 at 0xe0000000007805e0
e0000000007805e0 <xlog_bread>: [MII]       alloc r44=ar.pfs,17,13,0
e0000000007805e1 <xlog_bread+0x1>:             addl r14=1054344,r1
e0000000007805e2 <xlog_bread+0x2>:             mov r43=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> go
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x1f3f
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x1f3f
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
Instruction breakpoint #1 at 0xe0000000007db760
e0000000007db760 <xfsbdstrat>: [MII]       alloc r37=ar.pfs,9,6,0
e0000000007db761 <xfsbdstrat+0x1>:             addl r14=1054344,r1
e0000000007db762 <xfsbdstrat+0x2>:             mov r36=b0
Entering kdb (0x3c360000) on processor 0 [0]kdb> bc *
Breakpoint 0 at 0xe0000000007805e0 in dr0 cleared
Breakpoint 1 at 0xe0000000007db760 in dr0 cleared
[0]kdb> go
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0xf9f
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0xf9f
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x7cf
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x7cf
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x3e7
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x3e7
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x1f3
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x1f3
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0xf9
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0xf9
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x7c
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x7c
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x3e
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x3e
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x1f
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x1f
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0xf
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0xf
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x7
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x7
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x3
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x3
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x2
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x2
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
pb_get_no_daddr NOT block 0xe00000003ab3b6c0 mask 0xe00000003ab3b600 len 1024
xlog_bread(1):bp=0xe00000003c2c76c0
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c76c0
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
pb_get_no_daddr NOT block 0xe00000003ab3b6c0 mask 0xe00000003ab3b600 len 1024
xlog_bread(1):bp=0xe00000003c2c76c0
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c76c0
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
pb_get_no_daddr NOT block 0xe00000003f080500 mask 0xe00000003f080400 len 512
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x0
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x0
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
xlog_bread(1):bp=0xe00000003c2c7800
xlog_bread(1):blk_no=0x1
xlog_bread(1):log=0xe00000003f080700
xlog_bread(1):log->l_mp=0xe00000003c37c800
xlog_bread(1):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(1):log->l_logBBstart=0xfb100
xlog_bread(2):bp=0xe00000003c2c7800
xlog_bread(2):blk_no=0x1
xlog_bread(2):log=0xe00000003f080700
xlog_bread(2):log->l_mp=0xe00000003c37c800
xlog_bread(2):log->l_mp->m_logdev_targ=0xe00000003c37c800
xlog_bread(2):log->l_logBBstart=0xfb100
Ending clean XFS mount for filesystem: sd(8,33)
----------8<----------

mount succeeded!
Simple read and write seem to work.

Regards,

Hiroshi Aono, NEC Solutions
(h-aono@ap.jp.nec.com)

From owner-linux-xfs@oss.sgi.com Tue Dec 12 02:07:41 2000
Received:  by oss.sgi.com id <S553708AbQLLKHc>;
	Tue, 12 Dec 2000 02:07:32 -0800
Received: from plato.arts.usyd.edu.au ([129.78.16.1]:16138 "EHLO
        plato.arts.usyd.edu.au") by oss.sgi.com with ESMTP
	id <S553687AbQLLKHJ>; Tue, 12 Dec 2000 02:07:09 -0800
Received: from arts.usyd.edu.au (IDENT:matthew@holly.aitch.ucc.usyd.edu.au [129.78.226.234])
	by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id VAA25251
	for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 21:07:04 +1100 (EST)
Message-ID: <3A35F8C9.CD7ED8DC@arts.usyd.edu.au>
Date:   Tue, 12 Dec 2000 21:07:05 +1100
From:   Matthew Geier <matthew@arts.usyd.edu.au>
Organization: Arts IT Unit, Sydney University
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-XFS_BETA_4 i686)
X-Accept-Language: en, pdf
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Re: latest CVS hangs on boot
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At 00:58 1-12-2000 +0100, Andy Lo A Foe wrote:
>Hello,
>>
>Latest CVS tree from XFS hangs at boot right after IDE channel detection,
>but before IDE device probing (I think). Is this a known bug? Plain test11
>works fine, and so does an earlier -XFS-test10 tree.

 I just got into playing with XFS. I have the same 'lockup' at IDE init
time. The -test5 (?) based RPM works fine, a clean -test11 boots, but
the -test11xfs freezes solid.

 My system is an old ASUS P2B BX chipset board with an overclocked C566
in it. Ive got a Quantum FireBall, a ZIP drive and a pioneer DVD drive
on IDE. There is also an Adaptec
2940UW and Seagate barra drive as well, but at the lockup stage the SCSI
module for the
2940 hasnt been loaded.

 Its a Redhat-7 system, I used 'kgcc' (egcs-2.91.66 19990314)

From owner-linux-xfs@oss.sgi.com Tue Dec 12 02:44:12 2000
Received:  by oss.sgi.com id <S553801AbQLLKoD>;
	Tue, 12 Dec 2000 02:44:03 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:5641 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553700AbQLLKnt>;
	Tue, 12 Dec 2000 02:43:49 -0800
Received: (qmail 21937 invoked from network); 12 Dec 2000 10:43:37 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 12 Dec 2000 10:43:37 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Matthew Geier <matthew@arts.usyd.edu.au>
cc:     linux-xfs@oss.sgi.com
Subject: Re: latest CVS hangs on boot 
In-reply-to: Your message of "Tue, 12 Dec 2000 21:07:05 +1100."
             <3A35F8C9.CD7ED8DC@arts.usyd.edu.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 12 Dec 2000 21:43:37 +1100
Message-ID: <1479.976617817@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 12 Dec 2000 21:07:05 +1100, 
Matthew Geier <matthew@arts.usyd.edu.au> wrote:
>At 00:58 1-12-2000 +0100, Andy Lo A Foe wrote:
>>Latest CVS tree from XFS hangs at boot right after IDE channel detection,
>>but before IDE device probing (I think). Is this a known bug? Plain test11
>>works fine, and so does an earlier -XFS-test10 tree.
>
> I just got into playing with XFS. I have the same 'lockup' at IDE init
>time. The -test5 (?) based RPM works fine, a clean -test11 boots, but
>the -test11xfs freezes solid.

The APIC initialization code in standard 2.4.0-test11 kernels had some
problems and would hang machines during device probe.  The bug was
fixed in 2.4.0-test12-pre6.  I updated XFS-test11 to kdb v1.7 earlier
today which includes a backport of the APIC fix.  The fix may not be
in the CVS tree yet so I have attached the latest version of
arch/i386/kernel/apic.c, replace the 2.4.0-test11 version of apic.c.

begin 644 apic.c.tar.gz
M'XL(`-7_-3H``]1;:7/;1I/.5_E7C.VR1=H4#TFQ95M*5A85!_7J>B7YJ&2S
M*!`8DHA`@,$ABHF=W[Y/=P\.GK)W4[6UJK(LSM'3T]/'TSU#)W:'+7]G[T7K
M1L>A#EK.V'>;[G?_Y$^GW7ZQNZN^4SLO7W9V\+_JO-Q]2?_3S^Z+G1=MI5YN
M=[[?Z>QN[^R@>Z>S\_([U?Y'N5CQDR6I$ROUW8T3)>O&1>[:[O^O/ZUG#]2S
MC9/(=0)U>&$=J:$3>H$?#AHJ*!M3?Z3C!"-I<,VMJ\ZK5Z\::KO=;BLK'$3J
M-`I"B'%_A)G1?\3:&SIITXU&/Y@Y/_EWFN9OG#JNKW]7'YOJ,OISZM[X&Z\W
MWOIIHOI1K`8ZS/Q0J[WMW;U7W4^\=O*&IM%/"M9N$I5&ZCCV7?7.#T91K/->
ML`V205^]:ZIK/4GR=J*;ZB0%8RH=ZD0K?9?J,/%O=3!MKF+I@Q/[49:H;.PY
MF*V(>I_V0#-:#QX\]D,WR#RM]B&K[*[E1F'?'S2'/RST^*&?4OM"QVBT='C\
MQ[)F3P?.=%E'+XK2D5Y**AF-;9SAS7*N4AW'V3A=UCER.[LO]CI[<>HNZQ9'
M8<-NYC?F)"-:=782-8[2.%[2.D[&VEUL'P^<`(PS<3"JQG'4MT=9D/KCP-?Q
MKV>7]M'%^ZO?U('Z2W4:ZLN;<E@4>%\[U(TRDL*R,3QHH%-[Y-P%MVGM-O*]
M^H._'FQD4)Q!J#U%`VX;ZE;'#26#,&OC%C3(@=JQ=KP:J:]]\N&R_@8].D;?
MN^-KFUL_'%]>6>=GM5OJ:SW+-3Y17J3"*%6Q'D=QJAZKJ*]./EPK'::Q#^TC
MY=N0]4".25EGU\?O+@^OC[LU+%)7/Y:KG!Y^PF0LHEZK;2P4ZS2+PX+?+P\>
MT"'"EFA_R@VT$]ML]3R]W#5M-I]4BB"(8%*WM.V"H8K(ZM0![[*AGJDC)];]
M+'BM)AK^Y5:3#2>::"8PZ"@,IC"N.$FIW=-.DN@XY8E..%6!AJ5N8?N#@89C
M44F4Q2X9X@8+8ZG(KZ])KMP\B?U4VTZ,PZYTX^349Y5_A*"N_G7<Y7-:2JZ]
MGES[&\EUUI/KK"3G]U7-"/N'`[535SB<%6L<7[+>K5D&(U8N]&5^K=UU:UT<
MW;/4Q=&:E4HU@0*&$G!(+S7'A`A..U;G5\EK<^!K3W7)`FN/[9O&=Y:.GS^3
M^V5^+Y'=]41(FHLT($@V8]NFD*,0D4+MIG8O&<];,]8BVJ/(TW*J)'\Z@*XX
MGS3.R!:'N@H!>IHBJ!Z-TZER4D5Q)QLW>1X.96/!>;!&Y(2)`"W7@"-S>H%6
MR70TTBF%<>N<>^!0>47K].BR(9/\IF[FVU!OKRXVDQE($BEX/@[,9Z>60FAB
MGV#8&<?P63>U1^#JEOB>8X":%EAH_F?XB+F.LK17:]^]A'ZT[[:WJVWM#K?M
MB.;F(O?\Y'\B[HM,I-R+G-A3/<>]H;`2%<RJVM`AZ*%TOP_:,HF]910J%S[2
M@=`0\&`?3"*I-Y4ZBV`X@$HIB\E(,H_V24-)I"4!6!<6/D^B<#/%[_@&1SR-
M0D^FI$,_4>,(,Q\J=0TF>5U]Y^IQZF-Y>'3(W[IF*HMRAT16B9F.`.Q43^6K
M)-]>(7G2IZ51:RY0.4&F*28MT]3"!76%GJA8S1\1BD@D,A+#B,:Q'OA)2FB8
MQI.',K'[8;T(2;34HJ.\NK`^<$S@[J<'ZN]:9W]_;XW/H1D-X5P,G-$ZC@-G
MXS,21L3W^U,Y[XG>C,EDHQMB%0T.F(6YE$9#X%4=#3443:"P,X`*P=:GB*E&
M#:&NI)-`1`D=,BD'HCK!9YI,R5(*D=*^PP@['-,8PBM.$H4"C@DM&"<D[*T_
M'9^G#W"\^-VIG`5I'0@DI&ZYU&G;)-$M5D>HO]FC[$[$3\16XK!NKJ'O9%/*
M(+'7ZLD=M)"9F(OVQ7SI5/^5.]]+=KYU!E:#SO]JR4Y];N/I)*ILWO%P&+T(
MR"D91EG@*2;)!Y4X(\VSPFS4PP2X`$N.,-%P2AX,5Y/4/!].A,ZJ09TAM(5G
MC:,;+;H21N%658SDMWA?#P]$*+!%`R#;56S'ZF2T)N>8E#`Q2@%[FE:.IK,,
M!N="+]8\.%!D\NKS9U5^[O=G><C)S:+.DL@^T=A>3V-&Z%9W0=%:K`+?I&E6
M=^FI6]U[=<SJSJJ8U;U'P[YJJ<ZZI68$AI.N+5M_C<A"9-.LK!00?L\$PR=:
MDT;D:#]QH(+LQ02UT\0I^2HV8I(J_P>@[T"I>2+U0N8?_#C-(/2/?BSJZD:C
M,3*6GA_XP"$23GH(HZ,H(4QRI]EI4=Y`M8'[/(+@^@7Q4<?"6:TR<0'SRVAT
M%@W<"+&S@-:2:>C:AW$/(D]*'VGD_-'!"/*XOA<4>Y(#18_MN[%-/1+("DZN
M0'(81Z'_)_$#VE"+)(^T*P*.=93#T^[Q%6STY,0Z.\IQ.^"6?7+\X?CD^M)Z
M]X!J*Z:C>VH3%)`01=45;-%L#K`C`G>AS0NZ2O;V9F[SD,JX$B34VAB^F'0O
M#[?W)-XFJ(KVUZXNWE]:Y^^O\D%'U^>7ZBGYCWZ=S(+_P)X7=C2+'J(,X&'+
M99<XT9RY,)#B78E'$5T7)Z.]JK-]2&4JN^>GM8);JUM;M/AZ0ST=#Z>)[8XS
M>QPCCH?D_\9LIF_?OYMAR0+6"K`@#&>D0R_)4^_N3SCID^XE`^CKBTN`/VB8
M+N"Q2;_%W2EU!8O6S4%3/3J\V-K9VRM*=.^1JP.8GSHA[/21JO%Z/-F+W&Q$
MV$`"D]I^M=WIO""(>A4I2`8&#F@1P2<TC10*IG-@+&(C2-P/$*,\'?@X3K%[
M\22GY'%Z6CV"7"G2)8^`40':7#^EHD*)SIKKLT<6!T4'^:E*\`K2RL8F'1KX
MA*4\KB<Z#(2M[CVP#T*>17UY*_O6HN<S?"_@8(VJ=N,X<G62D)YYM?KS[=WZ
MNL2T>UEBQ!FNKYWD1EW$?A23LX04-QV7\+N"L#:;ZB-Y;S(/=^B$`\V:RG,A
M:[02G%N[L6NP?W%I+=D<],G*=[>":S-Y">=GT23'L^++<;()GT&1/>:Z\:UX
MNV+<.7MFT>.P@/TS1,VI[,V(-AIIE84W830)C7U9YRUQ7%`X^J.NX":<U"&;
MAT&3`\X2-?'3H40QD[N%.J7$B[I=RM^:!-V&_F"H^K'^(].A.ZWD;B0-GCX$
M[-8AYR,$2P#!4]_-`B<&'\S&V`\;:AQ@24ZII1'"3W/#IG+BE)BC"ISV6EDH
M?P@29`YB*L`@_9QHR)\18Q+!P*`7<45)#&W*O@F&)6HS23/W9K-!V0&%X#G^
MR1-I&+$GV5,<C9A%3]_ZKN;M]^$V$DH_!+1R.N8)`S225)6]ACBHB3-MJ&@H
M7+[>JE$K]_PJ65(O(]&&Y")B#;/R,A?4@$M]N`<Z#VQWKL#(TY6Z.++4F>8;
MCOEC8I]Y85DM_+-48:Q(ICTX03/_[2?8E3^&YC;5;Z)3C^'EVUSN->HF>RT(
MJ!ITY>"@7:\H8)XFOH(&/M9!HGE^GJ8N)]"I+VJPS`^1!<RXB&2<R46'=?EO
MQ%4WE=.MSEX6&K\V99UWHE)T8VQ4G%22^U=0&0RW&`9P(D+:34?^EBH_`"+7
M[6:1^H:1%(@3JBR0JP\UB8""`^P*FZJ4F+:*P@,AQ0362]=9HD`3TKU`#YQT
M1E/A*VGEO>WO7QWF7C`'O>?=\]=KF#8Z+>U6ZYQ;?U1;6R/'C:-[0@4A4L".
MN>*>@>@/%T.#>OJT+"Y1HO-0)&^*M6:5'*0=?[J&%-]4RC3B3SUU?)=2,0T"
MA^$]?N(Q:EU<CFLOBK1P#?W%,F]U1>-GOF7!^RKO\[K&684H3IXN4T)"+:1%
M':X7$JQT`OB.WBWI?YFBKI!T?<E^00?\B5$NZUPJ"::_[.*FOE&Y"))J6F&#
M!1G&WS8!\'?':ZS07"+,8-RE:ZJ_>-6',\NNN,[9F*E2JQUAN)OIW%PN$%;\
M;"2Q#__O'%[(A=7&0OIY?$5XBXFNL`6,J%<5!Y]E0_-(U;@M)%OMO4#RK7+C
M!?7CRTL$_:H+D]<'K98!%0F4).2Z*"/\Y"NN3LPJ94&7KC.1[4Y-Q=!04DZ?
M0N4<OV7-=$ZJ_[2XEJZ^3%K&M"M$SB)%=*HP6O+'N>R5?DD^A#0$X&.0K,K@
M>!`E+[E6DJ7U2;:V7*&+YRJ&8:-TB\V?'<^+9QU0(7?QQH[J.S<"&/_4,3`"
MH-%`+AO]44:`A=14IE1N$BB:.Z'<,U&QC%\,,&Z2>AB`LLQQV9=DB?@2K@;1
M.ENTB@07/T6H2IR^CBM5=&`4*FI0X"$\,IB"$+PU'Z\)-;YAE5,AHQ95&=1F
MI%A7?#]NF[M_FZ8FM8O#=\?VE?7+<7D79V;;&%$K&HQ/A<SLOG^'`[-#R`(Y
M:^TGZY-8R-O#J^.&FIG1+1TXP*=7W,&P&JD:_U=G=5I!H7#//^G4'9;IG=6E
MJCJ[ZZL+"MZN`P'GI2-'4DG==[*`[[2@(EDLF5?-G-/IA4H9#1'>BZ,;'=:K
MSIRDQ*DR]/7@0&UUWI.)S;2J>Q+N-_3(H0\NU-'YV4_6._O3W@O;.K<E72!-
MG-5R/RIVWE"^=X<52+9F!@O';K-#I7H7^RE2NIJ/@>TWRE?[*D3882H)/C]_
M+F:QQF+0%\U9C9G_J_];<S1VV3Z-"6U4C6A^YK?KVCP%UK=*DPSZ0K^6:!WD
MTU`+H^?US20:RS2..=BPB:Z=1O:M'Z=$M+Z$*IJ?/Z>_OI`-&#P\>Z]"V10Y
ME"1/^GG=G6W*X^#6([ZD(PA+$98SB)]_J4!'HC.&(Y'B.R?93I)D(W,G1P3A
M>`*,X+N]@!1M6L))<^5*5/(+FP>FTEH^Q#(`6.D[A[$O%0^%%2(@!3CX)AE+
M20@DD1(9L)]HKHO@3">4'26RI?Q94ZM8K9Q,J\WQB8W,;+JR8Z[L-(@*^4."
MUW*G;"H/AO]RYI3RHX^F%$RJ-C'0C4C@M"$,OT>YJ'!HWJO,7!Z9($1@!8!]
MU^8UY'5/&89,63)!=*(-V[`[#-[A!U(+CUKZ@3/@"#6S#E.D5B+"$VT__B.!
MFZH]+8DU9#9[/+JZM,?%Y>4N7UXR&5B)'TK?;KML_3S3K/;WU5ZQ8!;F2\8Z
M00A?N:HI,AMVYT(U5XQ93)/8&1M8L_Q2SLUB(\8&4DQ]*W\?_$V>B_J1.*4.
MWZ@6`PUF7#@&Y@N:\!>#BYP41I=3R2J_BM#&!B\\,WFK)#IS/P'5#?R1J9[+
M-*0"(RI%P)QC)Y[F<1M:'FZF#8[@DED&_F!(UB7W;FR:5"B@:,6X#G!#HOFI
MCL')M'4&!<]"<T\AJ7]N1@Z%-0"'HM#Y14V&/D)639C:5SOM]L(5;S\+78YT
M57<T_RJSD9<QZ!,4#OP1@4VQZTWS>",W]";P>BR%#+$K(D^%-I?N6;!;<DX/
M<N12,)!.?%?G^3B%`DK;D#R%:#7+]Z(!U9N$":)@BO7&+5`'GP+!IJ:\*&#$
M50M!)6>&X@W=/+.S<KCP5&7#O'UP=:-T=T2O4;H)3];-'>='=D!R@6KR!H.[
M<)8AP;(LE-(!ZP(<#M1.B5DP6*1J]/<B1(^K^S*?CCY_"@I<0.4O2?RL#];5
M^:7JO"C,3FXWBC=*M5D;XU-:M#TD`VG'-B),$<R+YPN5'IC`50Y<KJW3XTM&
M%K6YS\1377VF\%>DD=)[<7QIG7<MNN`Y.3\Z/#'-]Y5XY*55A8_9!Q2W/L`M
MQIW\2_6F)`B!8L4FEA22NT>7:PK<U-U0M8(`Q_NGZN^\]Y)V:'?R;#MON#ZE
MW7/B7MQ4%8-?,,^K%CRUCK!#.9M6]5PKJ4_E6-D.V8D25G529XDO95HSZ`K-
M=1[=(%]#.ITB2J2=5=%HUN="KQ!X;.ZKY;Z?6E._5B_KVA$B@Y2H"6YP"I*,
M".&XY9LK/S;NA``*5;7%`<(V'*[#3C`3(S>'0;H)CB;C:`*[E8J:PV9"-;G0
MI>M^4U:C!]V26XF?9>L=FYL(6'^D'!;7(EZ12ZO+?\MT,M+4/#T#"XFYTBRM
MGT<)*C,/&B`E*?/2[54!-%1RHR><"8Y)[Q0Y2O'-O(3<2Y>7VG)C!4_/)R.5
M>WX"L-GS!YL\DWL(&Q$>QP1*)I+GG=S!2_=!?O`MP>WE.#JC'.*B!?FXEVN<
M_,T$Z$\#<1=+4OEX,[9JA<6-,239II24B1E+7`H!ZD:IYIR5\4_4F2ZY0F=+
MJ3^KFHB\9V8&4A\>_/KTZ.A:[@9B'42.1Z^'J$;*<Y'P,D\&&Z1+KMB9P,(:
M!0BHD1W5P-P6;`>_>*O/EEVC=4S]<B;R_G`@=9667#Q-<L'1@R@YPS)H_9\R
MNL]\WG-&N4;!;)]X^]?MU]"DZP[][M*O*_IUA%\_Y'G3,JT2-]007U,XI\HJ
MMFT0Z)S[*="+%<X%[HDN(_0<(BF*[;D?8/1!IME4[T,('Y@*L^BZAHB$E$Q0
M">9WO]_WS3<STB)A`3J>3QRP`Y]P"CL_N;62QZOB`ST]YGMQ<%EYYT84Y4DZ
M*/ZHW@^&%40QH6<J]%0]RO.Y`DH5",4L.F$$D4_@DH8`N(+=A+T:G%I3WMR9
MAZ3:XQQJ6KSQ*L4F+^CEM=54^JBYN#+D5WZ'$,M$SZ[,JT7]/CV/F3A4FZ`G
M?*Z+@!VF9=))X\P-K#,U(*>29Q6"%17D0UQ5[N-?;"ND4]M<W@"$X592L33=
MSC]#I;(@-6'.YXR(7B;2IY/S\XLKS/WYEU:G757S"FZLIL=P*E*FG'E0,,&.
M^+J[P/ZJ1MB?5]<AW=?4"_RZD0-8>7XP&VH:)%E^ZY2+ET`CEQ:E2DA11\5`
MEL08^8^*BN2EJ44[[K3SGX7'@&4RSM3I:R*3D!:F^F-3G6BJ.Y+O*AZE.JIT
M[ASWZ.&F5`S4"($ZBS4]SN"8`&Q%:HQLBJ(M\NL;-:+D1[2FIP&4\P+`T`GZ
M6#S4]3S0K8XF>2S2S`H5<0P[+#K@C)QQYNUUI61'=3G@%3M-7'YZYN&/(*BE
M'#73U;ZWLFHI$J,^Q`,O7WR18+[DQN.DVH9%5^\K945>P<!:_K?G#W;6%1:J
M`]<I!2?Y<@R7;VA*Y520D\9]@+%0$MBP>/4-U23W*%8H-_50\(1>?694-B(_
M&SMTD4W//[1GWB#Q2&S14"65Z6G1EP8]`RA=;%4#WQ1J(.9+80[GLP41S0;"
ME@CWP5+YY.;<I!^&G"*.9*P))R?J2>`UG[1W`T^=_OQG,X]=M1H7*"'6+6B&
MK%!OY6;4^OF7^NIA3ZK#9D*G,#'D]X3%P:SG1/:^L+(T+ZYDZC.YPRN_A36;
M,90NP\Z'+GDU5_K@I/)LSD:3+]JZ2(=0Z3(?7DD;"`I5:I)R\`40,O:SD`&9
M%*B^N&2.7%(_=PT<M^7;E7QA(\4`PL9"&[B$"@!V#B%J\ZLUU.KE&O0UODX5
MD7`\+][4F`L'^A:@SY=B99D&2B_/H?+X2^DAOZ=7Y=<*JZ&A1?"I):1T^0!>
MV"U6,!*:.>&27O$E.[_Z9,()Z=D6/R9LJE]AV@'\=JJ^;[=-+)JZ?&TI5]P]
MB3X]G4[(8>=/YXJW-PD]8,Z`)WGS2'"XVL%IF.1-!`Y@^Y$GKY5^J_AC57M8
M89;>&=06A=ZJR&>?N*P^&]XZMLX^')Z8LR^>A*3\@GA2%2UIF7;<(?D!`XD\
M_HJ*1+`L,5_DE3?OF"L/BV$\2#<,P;N%0C-ECX#3<O$T)>1F4*\\(W+9J8%R
M4QVFIE+O<\U>4U4Z@:"\W\V7HHIT6;X3G<^/26[E,X+YX&*^9/I&/7_NB\^;
M_4ZK3U\_+3]7_$2;U?@Q^>;^3)$IU^V3*J`L-LS?XR80;:78+@34@XE55![=
M?%<A8N`OW/FP3S=IX3BA=%Y&PV;K:.5LB%,S_,S1+*&B%30>_'<[U]+;MA&$
M[_D5&P.%)$22HSA."J,QT`8.XAIY0`Z00V`(M$7;0D13%2G9.;2_O?/-S#XH
M48B!'GJ9.>1!<E?+Y;SGFPV0-6TBXH&=.%E\[0[/5$E^4*M^&)[P!RGA$2L/
M=D53@4VE=9NQGC0]NA:Q);EE')ND=PJ/2);T<]C8;E4O5^1$+6KB^QO25D#S
M5D&"R?8";XR_&)33Y;OJUI)ZHWO;,=>&5Q!W)@10]-;G'SYS:7F(E"G2$8)L
M*P(3BW/%J9$]=>;V^B$^BI.JEQ'QA**&=6A6EP79HG*1BW2CJ<RCKG(`'&;(
M$\NX"EV]/@'<]CT!G1ZEP!KL"]C_X==7DVFI^E$V:7"<SQ8!K3(8-'JT:><N
MW&^(U1N%?^Q6\FM%]D.\(\\1$H1QVARJDV6:'*2;4IOI0O$=C6ZJ(\5&JHG@
MSQF8JI113=X)T:XO7,.K8MT:5$;2BB=BVE08['YYL':"E?1.MV*F.'*KDP6G
M;7>;>_5FJVL>ESV(9_OYIV]:^^=Q3PO,+8F';1NP-;'477=-[9>9CI#R[$;!
MG9@?579F5"\\+)E5EUDJ@AN3?F)26C4`(?@"'3B!':<Z=9'5MT$T@"624'IU
M6?VHZKS@T3?+[%+\7@0.Y!["55%'2XY`X/_M<[B,?_6B(TU<(+YZ2!7D](J+
M>4.V/?B5E\9+ZO05=C_UN87$12EK+M`@#5E5>>&[JJ0)2\2=<6\LJC"8=5F2
M<)#)*Z\Y%UI5I/RZ)-=DFXI,2C=5WNO[%4.;\'XQ;A>G;3AR7<]4Q;-_D-1Y
M&7I,]^$(N\^':O?^;AJEM&8=3IR(_8N07CC:=QE]%7H<2!FNU)5J-O2GD_95
MB=A;#%[EK4$N4!^8`W;AEF4VO<HDE1#QG10U?_-@$\85W[.5A.>V6O#9"XF1
MOU`K^$V2XG!!YOD`@8KP"V)];M2%CE;>T"8[7\9*"OLNL=(*L,:>`"`>,EQJ
MBF+!#TR&P.2"357#C^1(5*T4/E(XT,('##`XZ4./-&6/L%98'X".4])3$('!
M-*\97P;%63$S-AHOXBI9U('%B#''IR\G3TEF._!E:X3!O[\]XU_`N\^*(I_.
M.!'85T>7*ZK*!O[4&L\$%06QX9>OOHO2HGG2(*=5F_30/T*O4`&P[Q-G4^ZA
M7/XUX<[EK@BZ^R.O9M,<")]K`3JPT&UR)7TG$2<R._/R4O'AD0,TH<2^J<K$
MUR4IA"]LX;MUT9-48X`TA670#BHH<+>S$KP/C'J8U7'01C=Q+)1(.#'AUI")
M=]S8QB,GCHW<!YMGRZO;&3[VBL_@V7^2505]@>^`L06N\_#R9$6[6KO:6TIC
MSQ10*!&NGD@0Z2(PBJ9(:!07\^EA03KFW`$[=.[/%>L`%GEM.7+G6_.%>`I2
M2(Q$4\<NK9;3+T[/Q^[9[@:R?YX_C*Y[[OC825(?QG=-U[LC@#MVMYW1(`Z?
M-GF7PR>@F:M[DK7U@/0X[?;<'?3A\RP@-:^'+X>C@^$AKUBS&F<GXX^3TX_O
M/KF]L(7-"#%"L?MA!SA;*@PPW%TP^#DOI1,]AI-:6<GWW?V,C_INK4WD[IV<
M*4,1A?8,W6;+Z3UY5OV`$;_S)^W<2^[L#ALQ=(.!&Y]\W?7-%6N[&Z2[;LE0
M^D&;RH@ET^-8O$)T[[D_KI)EA>RSX$XX+UCDV1T2F<X]/Z)0FH3@[;G<YXNC
M(S>63IOF]1?ZL,*QXHV#.&#KWDO<(R]+VG:<.]1)9G-T3LQCWXASK\(TK;=?
M'[E3O1H:K8%)Y!@F\JL3ACT9C]%O&%Y<6/27*<#++^8/7?Y3(8!.J:V@M79@
M"N'3__N\-2,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
.(Z/_2O\".KBJ$`!X````
`
end


From owner-linux-xfs@oss.sgi.com Tue Dec 12 08:59:54 2000
Received:  by oss.sgi.com id <S553694AbQLLQ7o>;
	Tue, 12 Dec 2000 08:59:44 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:26727 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553652AbQLLQ7f>;
	Tue, 12 Dec 2000 08:59:35 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA16621
	for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 08:59:34 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA82732; Tue, 12 Dec 2000 10:58:13 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA38252; Tue, 12 Dec 2000 10:58:13 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBCGwDd14187;
	Tue, 12 Dec 2000 10:58:13 -0600
Message-ID: <3A365925.29A0A644@thebarn.com>
Date:   Tue, 12 Dec 2000 10:58:13 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Keith Owens <kaos@melbourne.sgi.com>
CC:     Matthew Geier <matthew@arts.usyd.edu.au>, linux-xfs@oss.sgi.com
Subject: Re: latest CVS hangs on boot
References: <1479.976617817@ocs3.ocs-net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Keith Owens wrote:

> On Tue, 12 Dec 2000 21:07:05 +1100,
> Matthew Geier <matthew@arts.usyd.edu.au> wrote:
> >At 00:58 1-12-2000 +0100, Andy Lo A Foe wrote:
> >>Latest CVS tree from XFS hangs at boot right after IDE channel detection,
> >>but before IDE device probing (I think). Is this a known bug? Plain test11
> >>works fine, and so does an earlier -XFS-test10 tree.
> >
> > I just got into playing with XFS. I have the same 'lockup' at IDE init
> >time. The -test5 (?) based RPM works fine, a clean -test11 boots, but
> >the -test11xfs freezes solid.
>
> The APIC initialization code in standard 2.4.0-test11 kernels had some
> problems and would hang machines during device probe.  The bug was
> fixed in 2.4.0-test12-pre6.  I updated XFS-test11 to kdb v1.7 earlier
> today which includes a backport of the APIC fix.  The fix may not be
> in the CVS tree yet so I have attached the latest version of
> arch/i386/kernel/apic.c, replace the 2.4.0-test11 version of apic.c.
>
>

I've started merging the current tree up to test12... hopefully I will have it
finished
by late this afternoon.

-Russell




From owner-linux-xfs@oss.sgi.com Tue Dec 12 09:41:44 2000
Received:  by oss.sgi.com id <S553750AbQLLRle>;
	Tue, 12 Dec 2000 09:41:34 -0800
Received: from tux.mkp.net ([130.225.60.11]:47118 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553712AbQLLRlV>;
	Tue, 12 Dec 2000 09:41:21 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 145tQM-0002cO-00; Tue, 12 Dec 2000 18:41:10 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id MAA25102;
	Tue, 12 Dec 2000 12:40:02 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     linux-xfs@oss.sgi.com
Subject: TAKE - kdb 1.7 merge fix
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   12 Dec 2000 12:40:02 -0500
Message-ID: <yq1hf49iln1.fsf@jaguar.mkp.net>
Lines:  17
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Date:  Tue Dec 12 09:39:38 PST 2000
Workarea:  sshgate.corp.sgi.com:/export/d0/mkp/XFS/slinx-pristine

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80435a
linux/kernel/kallsyms.c - 1.6
        - Added missing function (kallsyms_sections)

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Tue Dec 12 13:36:56 2000
Received:  by oss.sgi.com id <S553717AbQLLVgq>;
	Tue, 12 Dec 2000 13:36:46 -0800
Received: from gw1.hcjbeng.org ([207.32.229.26]:23290 "EHLO
        mserver.hcjbeng.org") by oss.sgi.com with ESMTP id <S553651AbQLLVg1>;
	Tue, 12 Dec 2000 13:36:27 -0800
Received: from swilson-nt ([192.168.50.131])
	by mserver.hcjbeng.org (8.9.3/8.9.3) with SMTP id QAA12343
	for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 16:36:27 -0500
Reply-To: <swilson@hcjbeng.org>
From:   "Steven M Wilson" <swilson@hcjbeng.org>
To:     <linux-xfs@oss.sgi.com>
Subject: Installing XFS Beta on RedHat 7.0
Date:   Tue, 12 Dec 2000 16:35:29 -0500
Message-ID: <000001c06483$736a65e0$8332a8c0@swilson-nt.hcjbeng.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I'm attempting my first install of XFS and am getting the following error:
	depmod:  Unresolved symbols in /lib/modules/2.4.0-XFS_BETA_4/misc/ip2main.o
when installing the 2.4.0 kernel RPM:
	rpm -ivh kernel_2.4.0-XFS_BETA_4.i386.rpm

I am using RedHat distribution 7.0.

Thanks for any help!

Steve

========================================================
STEVEN M. WILSON   Systems Engineer, Satellite Group
HCJB World Radio Engineering Center
2830 S. 17th St.  Elkhart, IN 46517-4008
Phone: 1-219-293-4480, x526  Fax: 1-219-293-9910


From owner-linux-xfs@oss.sgi.com Tue Dec 12 14:02:45 2000
Received:  by oss.sgi.com id <S553832AbQLLWC0>;
	Tue, 12 Dec 2000 14:02:26 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:880 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553690AbQLLWB6>;
	Tue, 12 Dec 2000 14:01:58 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA20443
	for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 14:01:57 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA87015; Tue, 12 Dec 2000 16:00:39 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA40656; Tue, 12 Dec 2000 16:00:39 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBCM0dd24722;
	Tue, 12 Dec 2000 16:00:39 -0600
Message-ID: <3A36A006.B2B2E52C@thebarn.com>
Date:   Tue, 12 Dec 2000 16:00:38 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     swilson@hcjbeng.org
CC:     linux-xfs@oss.sgi.com
Subject: Re: Installing XFS Beta on RedHat 7.0
References: <000001c06483$736a65e0$8332a8c0@swilson-nt.hcjbeng.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Steven M Wilson wrote:

> I'm attempting my first install of XFS and am getting the following error:
>         depmod:  Unresolved symbols in /lib/modules/2.4.0-XFS_BETA_4/misc/ip2main.o
> when installing the 2.4.0 kernel RPM:
>         rpm -ivh kernel_2.4.0-XFS_BETA_4.i386.rpm
>
> I am using RedHat distribution 7.0.

Sorry the rpm are not compatible with RH 7.0 yet.
The best thing would be download the source tree and build from
scratch.



>
>
> Thanks for any help!
>
> Steve
>
> ========================================================
> STEVEN M. WILSON   Systems Engineer, Satellite Group
> HCJB World Radio Engineering Center
> 2830 S. 17th St.  Elkhart, IN 46517-4008
> Phone: 1-219-293-4480, x526  Fax: 1-219-293-9910


From owner-linux-xfs@oss.sgi.com Tue Dec 12 14:48:18 2000
Received:  by oss.sgi.com id <S553846AbQLLWr6>;
	Tue, 12 Dec 2000 14:47:58 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:17672 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553824AbQLLWrc>;
	Tue, 12 Dec 2000 14:47:32 -0800
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA28350
	for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 14:47:30 -0800 (PST)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id JAA23424;
	Wed, 13 Dec 2000 09:46:27 +1100
Date:   Wed, 13 Dec 2000 09:46:27 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200012122246.JAA23424@sherman.melbourne.sgi.com>
Subject: TAKE - kallsyms.c omitted from kdb v1.7 merge
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

kallsyms.c omitted from kdb v1.7 merge

Date:  Tue Dec 12 14:45:45 PST 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80482a
linux/kernel/kallsyms.c - 1.7


From owner-linux-xfs@oss.sgi.com Tue Dec 12 14:55:27 2000
Received:  by oss.sgi.com id <S553853AbQLLWzS>;
	Tue, 12 Dec 2000 14:55:18 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:14916 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553833AbQLLWzH>; Tue, 12 Dec 2000 14:55:07 -0800
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA01128
	for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 15:03:23 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via SMTP id OAA11482 for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 14:54:35 -0800 (PST)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id JAA25310; Wed, 13 Dec 2000 09:51:55 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     swilson@hcjbeng.org
cc:     linux-xfs@oss.sgi.com
Subject: Re: Installing XFS Beta on RedHat 7.0 
In-reply-to: Your message of "Tue, 12 Dec 2000 16:35:29 CDT."
             <000001c06483$736a65e0$8332a8c0@swilson-nt.hcjbeng.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Wed, 13 Dec 2000 09:51:55 +1100
Message-ID: <1130.976661515@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 12 Dec 2000 16:35:29 -0500, 
"Steven M Wilson" <swilson@hcjbeng.org> wrote:
>I'm attempting my first install of XFS and am getting the following error:
>	depmod:  Unresolved symbols in /lib/modules/2.4.0-XFS_BETA_4/misc/ip2main.o

2.4 kernels after about 2.4.0-test5 should not have a misc modules
directory, all modules should be under /lib/modules/<version>/kernel.
You probably have old data under /lib/modules.

  rm -rf /lib/modules/2.4.0-XFS_BETA_4
  make modules_install

to clean out any crud and create a clean modules tree.


From owner-linux-xfs@oss.sgi.com Tue Dec 12 18:59:59 2000
Received:  by oss.sgi.com id <S553675AbQLMC7t>;
	Tue, 12 Dec 2000 18:59:49 -0800
Received: from tux.mkp.net ([130.225.60.11]:43025 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553655AbQLMC7a>;
	Tue, 12 Dec 2000 18:59:30 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 14628X-0002yT-00; Wed, 13 Dec 2000 03:59:21 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id VAA25438;
	Tue, 12 Dec 2000 21:58:11 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     linux-xfs@oss.sgi.com
Subject: TAKE - mkfs.xfs vs. LVM
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   12 Dec 2000 21:58:11 -0500
Message-ID: <yq1u289gh8c.fsf@jaguar.mkp.net>
Lines:  17
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Date:  Tue Dec 12 18:57:13 PST 2000
Workarea:  sshgate.corp.sgi.com:/export/d0/mkp/XFS/slinx-pristine

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80534a
cmd/xfs/mkfs/xfs_mkfs.c - 1.182
        - Fix LVM stripe size/width calculation.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Tue Dec 12 22:06:38 2000
Received:  by oss.sgi.com id <S553692AbQLMGGT>;
	Tue, 12 Dec 2000 22:06:19 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47487 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553668AbQLMGGA>; Tue, 12 Dec 2000 22:06:00 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA09388
	for <linux-xfs@oss.sgi.com>; Tue, 12 Dec 2000 22:14:15 -0800 (PST)
	mail_from (ivanr@snort.melbourne.sgi.com)
Received: (from ivanr@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA95611
	for linux-xfs@oss.sgi.com; Wed, 13 Dec 2000 17:04:36 +1100 (EST)
Date:   Wed, 13 Dec 2000 17:04:36 +1100 (EST)
From:   Ivan Rayner <ivanr@snort.melbourne.sgi.com>
Message-Id: <200012130604.RAA95611@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - add parameter to some vop calls
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Add unused parameter to VOP_TOSS_PAGES VOP_FLUSH_PAGES and
VOP_FLUSHINVAL_PAGES for IRIX compatibility.  This is needed
for the cxfs port.

Ivan


Modid:  2.4.x-xfs:slinx:80550a
Date:  Tue Dec 12 22:02:07 PST 2000
Workarea:  snort:/diskb/build6/ivanr/isms/slinx-xfs-base
Author:  ivanr

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/linux/xfs_fs_subr.c - 1.25
linux/fs/xfs/linux/xfs_fs_subr.h - 1.4
linux/fs/xfs/linux/xfs_iops.c - 1.82
linux/fs/xfs/linux/xfs_lrw.c - 1.66
linux/fs/xfs/linux/xfs_vnode.h - 1.6
linux/fs/xfs/xfs_bmap.c - 1.263
linux/fs/xfs/xfs_dfrag.c - 1.25
linux/fs/xfs/xfs_inode.c - 1.308
linux/fs/xfs/xfs_rw.c - 1.329
linux/fs/xfs/xfs_vfsops.c - 1.304
linux/fs/xfs/xfs_vnodeops.c - 1.480

From owner-linux-xfs@oss.sgi.com Wed Dec 13 12:03:03 2000
Received:  by oss.sgi.com id <S553672AbQLMUCn>;
	Wed, 13 Dec 2000 12:02:43 -0800
Received: from gw1.hcjbeng.org ([207.32.229.26]:49141 "EHLO
        mserver.hcjbeng.org") by oss.sgi.com with ESMTP id <S553661AbQLMUCZ>;
	Wed, 13 Dec 2000 12:02:25 -0800
Received: from swilson-nt ([192.168.50.131])
	by mserver.hcjbeng.org (8.9.3/8.9.3) with SMTP id PAA15260
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 15:02:24 -0500
Reply-To: <swilson@hcjbeng.org>
From:   "Steven M Wilson" <swilson@hcjbeng.org>
To:     <linux-xfs@oss.sgi.com>
Subject: RE: Installing XFS Beta on RedHat 7.0
Date:   Wed, 13 Dec 2000 15:01:16 -0500
Message-ID: <000101c0653f$754bc9a0$8332a8c0@swilson-nt.hcjbeng.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
In-Reply-To: <3A36A006.B2B2E52C@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > I'm attempting my first install of XFS and am getting the
> > following error:
> > 	depmod:  Unresolved symbols in
> >		/lib/modules/2.4.0-XFS_BETA_4/misc/ip2main.o
> > when installing the 2.4.0 kernel RPM:
> > 	rpm -ivh kernel_2.4.0-XFS_BETA_4.i386.rpm
> >
> > I am using RedHat distribution 7.0.
>
> Sorry the rpm are not compatible with RH 7.0 yet.
> The best thing would be download the source tree and build from
> scratch.
>

Thanks for your response, Russell.  I am now trying to build from the
sources but have run into a few snags.  I've overcome most of the problems
but I'm stuck now with a failure to locate the file
"linux-2.4.0-test11-xfs-alpha.patch" under SOURCES.  This file is needed for
(at least) SCRIPTS/make-tarballs and the command "make i386kernel" at the
root of the source tree.

BTW, the CVS download instructions (/projects/xfs/cvs_download.html)
reference a non-existent (but potentially helpful?) file called README.build
in the top level directory.

Thanks for your help!

Steve

========================================================
STEVEN M. WILSON   Systems Engineer, Satellite Group
HCJB World Radio Engineering Center
2830 S. 17th St.  Elkhart, IN 46517-4008
Phone: 1-219-293-4480, x526  Fax: 1-219-293-9910



From owner-linux-xfs@oss.sgi.com Wed Dec 13 14:13:24 2000
Received:  by oss.sgi.com id <S553714AbQLMWNE>;
	Wed, 13 Dec 2000 14:13:04 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:50786 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553647AbQLMWMm>; Wed, 13 Dec 2000 14:12:42 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA07462
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 14:20:59 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA13769 for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 14:06:16 -0800 (PST)
Message-ID: <3A37F399.BAEC2952@sgi.com>
Date:   Wed, 13 Dec 2000 14:09:29 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: CVS problems?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


One of the users of XFS is having problems when
trying to obtain the latest CVS trees. Most of
us inside SGI do not use the CVS tree, since
we have a mirror of the tree on internal servers.
Can those of you who use CVS please comment on
this issue below?

----------
	It is exactly what I do whenever I run into these
        problems, yet your cvs sever does not send
        the changed files. I have had to literally
        cd into the dir of the offending file, delete it
        and do a cvs update in that dir to get latest rev.
------------

thanks,


--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Wed Dec 13 14:34:24 2000
Received:  by oss.sgi.com id <S553663AbQLMWeE>;
	Wed, 13 Dec 2000 14:34:04 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:31748 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553653AbQLMWdj>;
	Wed, 13 Dec 2000 14:33:39 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAB00997
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 14:32:52 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA98442; Wed, 13 Dec 2000 16:31:03 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA01125; Wed, 13 Dec 2000 16:31:02 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBDMV2t04442;
	Wed, 13 Dec 2000 16:31:02 -0600
Message-ID: <3A37F8A4.7F347007@thebarn.com>
Date:   Wed, 13 Dec 2000 16:31:00 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: CVS problems?
References: <3A37F399.BAEC2952@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Rajagopal Ananthanarayanan wrote:

> One of the users of XFS is having problems when
> trying to obtain the latest CVS trees. Most of
> us inside SGI do not use the CVS tree, since
> we have a mirror of the tree on internal servers.
> Can those of you who use CVS please comment on
> this issue below?
>
> ----------
>         It is exactly what I do whenever I run into these
>         problems, yet your cvs sever does not send
>         the changed files. I have had to literally
>         cd into the dir of the offending file, delete it
>         and do a cvs update in that dir to get latest rev.
> ------------
>

Hmmm this is a little schetchy.
One thing that is important when doing an update is the -d flag.
cvs update -d
That will tell it to update dirs.

I would be interesting to do a "cvs status" on the file before deletingit,
just to see what it thinks the state is.

>
>
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed Dec 13 14:45:54 2000
Received:  by oss.sgi.com id <S553698AbQLMWpo>;
	Wed, 13 Dec 2000 14:45:44 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:20489 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553660AbQLMWp1>;
	Wed, 13 Dec 2000 14:45:27 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA03581
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 14:44:39 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA43505
	for linux-xfs@oss.sgi.com; Thu, 14 Dec 2000 09:44:06 +1100 (EST)
Date:   Thu, 14 Dec 2000 09:44:06 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200012132244.JAA43505@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - mkfs bugfix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:80622a
Date:  Wed Dec 13 14:43:49 PST 2000
Workarea:  snort:/home/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/mkfs/xfs_mkfs.c - 1.183
	- don't try to get stripe info if we're creating a FS in a file


From owner-linux-xfs@oss.sgi.com Wed Dec 13 15:05:55 2000
Received:  by oss.sgi.com id <S553719AbQLMXFf>;
	Wed, 13 Dec 2000 15:05:35 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:40299 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553685AbQLMXFX>; Wed, 13 Dec 2000 15:05:23 -0800
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA01813
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 15:13:40 -0800 (PST)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA81568;
	Wed, 13 Dec 2000 15:04:01 -0800 (PST)
Date:   Wed, 13 Dec 2000 15:03:40 -0800 (PST)
From:   Tom Duffy <tduffy@engr.sgi.com>
To:     <swilson@hcjbeng.org>
cc:     <linux-xfs@oss.sgi.com>
Subject: Re: [Fwd: RE: Installing XFS Beta on RedHat 7.0]
In-Reply-To: <3A37FEAA.5B234468@sgi.com>
Message-ID: <Pine.LNX.4.30.0012131459150.1938-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> Thanks for your response, Russell.  I am now trying to build from the
> sources but have run into a few snags.  I've overcome most of the problems
> but I'm stuck now with a failure to locate the file
> "linux-2.4.0-test11-xfs-alpha.patch" under SOURCES.  This file is needed for
> (at least) SCRIPTS/make-tarballs and the command "make i386kernel" at the
> root of the source tree.

the patch is generated on the fly by the scripts.  it checks out a copy of
a clean linux 2.4.0-test11 tree and diffs the xfs tree to generate the
patch.

this is done because rpm wants a clean tarball plus patches...we will be
moving to a patch based system for distributing xfs at some point in the
future.

I am hesitant to check in the patch since it should be generated at any
given moment by looking at the current xfs tree and a stock linux tarball.
you will also need to grab a linux tarball and put that into SOURCES as
well as this is not checked into the tree (we did not want to have that
huge binary in the tree).

hope this helps,

-tduffy


From owner-linux-xfs@oss.sgi.com Wed Dec 13 15:16:55 2000
Received:  by oss.sgi.com id <S553735AbQLMXQe>;
	Wed, 13 Dec 2000 15:16:34 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:13089 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553716AbQLMXQd>;
	Wed, 13 Dec 2000 15:16:33 -0800
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA16409
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 15:15:46 -0800 (PST)
	mail_from (tduffy@engr.sgi.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA29046 for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 15:14:46 -0800 (PST)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA82316;
	Wed, 13 Dec 2000 15:12:13 -0800 (PST)
Date:   Wed, 13 Dec 2000 15:11:52 -0800 (PST)
From:   Tom Duffy <tduffy@engr.sgi.com>
To:     <linux-xfs@oss.sgi.com>
cc:     <kaos@melbourne.sgi.com>, <swilson@hcjbeng.org>
Subject: Re: Installing XFS Beta on RedHat 7.0
Message-ID: <Pine.LNX.4.30.0012131510100.1938-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Keith Owens said:
> 2.4 kernels after about 2.4.0-test5 should not have a misc modules
> directory, all modules should be under /lib/modules/<version>/kernel.
> You probably have old data under /lib/modules.

this is not entirely true.  alsa still sticks it's modules in misc.  the
rpms contain alsa modules.

-tduffy


From owner-linux-xfs@oss.sgi.com Wed Dec 13 15:25:25 2000
Received:  by oss.sgi.com id <S553725AbQLMXZF>;
	Wed, 13 Dec 2000 15:25:05 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:42766 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553716AbQLMXY6>; Wed, 13 Dec 2000 15:24:58 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id VAA24227;
	Wed, 13 Dec 2000 21:24:38 -0200
Date:   Wed, 13 Dec 2000 19:30:22 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: CVS problems?
In-Reply-To: <3A37F399.BAEC2952@sgi.com>
Message-ID: <Pine.LNX.4.21.0012131929550.25944-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On Wed, 13 Dec 2000, Rajagopal Ananthanarayanan wrote:

> 
> One of the users of XFS is having problems when
> trying to obtain the latest CVS trees. Most of
> us inside SGI do not use the CVS tree, since
> we have a mirror of the tree on internal servers.
> Can those of you who use CVS please comment on
> this issue below?
> 
> ----------
> 	It is exactly what I do whenever I run into these
>         problems, yet your cvs sever does not send
>         the changed files. I have had to literally
>         cd into the dir of the offending file, delete it
>         and do a cvs update in that dir to get latest rev.
> ------------

CVS update is working fine for me.


From owner-linux-xfs@oss.sgi.com Wed Dec 13 15:53:55 2000
Received:  by oss.sgi.com id <S553706AbQLMXxp>;
	Wed, 13 Dec 2000 15:53:45 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:42864 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553678AbQLMXxa>; Wed, 13 Dec 2000 15:53:30 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id QAA02974
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 16:01:46 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id KAA19697; Thu, 14 Dec 2000 10:52:10 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Tom Duffy <tduffy@engr.sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Installing XFS Beta on RedHat 7.0 
In-reply-to: Your message of "Wed, 13 Dec 2000 15:11:52 -0800."
             <Pine.LNX.4.30.0012131510100.1938-100000@dbear.engr.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 14 Dec 2000 10:52:10 +1100
Message-ID: <1469.976751530@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Wed, 13 Dec 2000 15:11:52 -0800 (PST), 
Tom Duffy <tduffy@engr.sgi.com> wrote:
>Keith Owens said:
>> 2.4 kernels after about 2.4.0-test5 should not have a misc modules
>> directory, all modules should be under /lib/modules/<version>/kernel.
>> You probably have old data under /lib/modules.
>
>this is not entirely true.  alsa still sticks it's modules in misc.  the
>rpms contain alsa modules.

I have logged a bug report with alsa.  They are still using the old
/lib/modules format with all the problems it causes.


From owner-linux-xfs@oss.sgi.com Wed Dec 13 16:36:46 2000
Received:  by oss.sgi.com id <S553734AbQLNAgZ>;
	Wed, 13 Dec 2000 16:36:25 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39286 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553696AbQLNAf5>; Wed, 13 Dec 2000 16:35:57 -0800
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01892
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 16:44:14 -0800 (PST)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id QAA08074
	for <linux-xfs@oss.sgi.com>; Wed, 13 Dec 2000 16:34:40 -0800 (PST)
Date:   Wed, 13 Dec 2000 16:34:19 -0800 (PST)
From:   Tom Duffy <tduffy@engr.sgi.com>
To:     <linux-xfs@oss.sgi.com>
Subject: Re: [Fwd: RE: Installing XFS Beta on RedHat 7.0] (fwd)
Message-ID: <Pine.LNX.4.30.0012131633460.1938-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

this did not seem to go through, so resending.

-tduffy

---------- Forwarded message ----------
Date: Wed, 13 Dec 2000 15:03:40 -0800 (PST)
From: Tom Duffy <tduffy@engr.sgi.com>
To: swilson@hcjbeng.org
Cc: linux-xfs@oss.sgi.com
Subject: Re: [Fwd: RE: Installing XFS Beta on RedHat 7.0]

> Thanks for your response, Russell.  I am now trying to build from the
> sources but have run into a few snags.  I've overcome most of the problems
> but I'm stuck now with a failure to locate the file
> "linux-2.4.0-test11-xfs-alpha.patch" under SOURCES.  This file is needed for
> (at least) SCRIPTS/make-tarballs and the command "make i386kernel" at the
> root of the source tree.

the patch is generated on the fly by the scripts.  it checks out a copy of
a clean linux 2.4.0-test11 tree and diffs the xfs tree to generate the
patch.

this is done because rpm wants a clean tarball plus patches...we will be
moving to a patch based system for distributing xfs at some point in the
future.

I am hesitant to check in the patch since it should be generated at any
given moment by looking at the current xfs tree and a stock linux tarball.
you will also need to grab a linux tarball and put that into SOURCES as
well as this is not checked into the tree (we did not want to have that
huge binary in the tree).

hope this helps,

-tduffy



From owner-linux-xfs@oss.sgi.com Thu Dec 14 09:16:00 2000
Received:  by oss.sgi.com id <S553669AbQLNRPk>;
	Thu, 14 Dec 2000 09:15:40 -0800
Received: from gw1.hcjbeng.org ([207.32.229.26]:4859 "EHLO mserver.hcjbeng.org")
	by oss.sgi.com with ESMTP id <S553646AbQLNRPh>;
	Thu, 14 Dec 2000 09:15:37 -0800
Received: from swilson-nt ([192.168.50.131])
	by mserver.hcjbeng.org (8.9.3/8.9.3) with SMTP id MAA18005;
	Thu, 14 Dec 2000 12:15:34 -0500
Reply-To: <swilson@hcjbeng.org>
From:   "Steven M Wilson" <swilson@hcjbeng.org>
To:     <linux-xfs@oss.sgi.com>
Cc:     <tduffy@engr.sgi.com>
Subject: RE: [Fwd: RE: Installing XFS Beta on RedHat 7.0]
Date:   Thu, 14 Dec 2000 12:14:33 -0500
Message-ID: <000001c065f1$54d039b0$8332a8c0@swilson-nt.hcjbeng.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <Pine.LNX.4.30.0012131459150.1938-100000@dbear.engr.sgi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> > I'm stuck now with a failure to locate the file
> > "linux-2.4.0-test11-xfs-alpha.patch" under SOURCES.
> > This file is needed for (at least) SCRIPTS/make-tarballs
> > and the command "make i386kernel" at the
> > root of the source tree.
>
> the patch is generated on the fly by the scripts.  it checks
> out a copy of
> a clean linux 2.4.0-test11 tree and diffs the xfs tree to generate the
> patch.
>
> this is done because rpm wants a clean tarball plus
> patches...we will be
> moving to a patch based system for distributing xfs at some
> point in the
> future.
>
> I am hesitant to check in the patch since it should be
> generated at any
> given moment by looking at the current xfs tree and a stock
> linux tarball.
> you will also need to grab a linux tarball and put that into
> SOURCES as
> well as this is not checked into the tree (we did not want to
> have that
> huge binary in the tree).
>
> hope this helps,
>
> -tduffy
>

The script "create_clean_kernel_tree" fails trying to locate and execute a
program called p_tupdate.  Where can I get this program?

Also, many scripts require the top directory to be /usr/src/redhat but the
rpmmacros file (cmd/xfs/build/rpm/rpmmacros) references
/usr/src/linux-2.4-xfs.  I created a symbolic link so that
/usr/src/linux-2.4-xfs points to /usr/src/redhat.  Was that the right thing
to do?

Thanks again for your help!

Steve


From owner-linux-xfs@oss.sgi.com Thu Dec 14 09:25:01 2000
Received:  by oss.sgi.com id <S553681AbQLNRYk>;
	Thu, 14 Dec 2000 09:24:40 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:31610 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553664AbQLNRYg>;
	Thu, 14 Dec 2000 09:24:36 -0800
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA02570
	for <linux-xfs@oss.sgi.com>; Thu, 14 Dec 2000 09:23:49 -0800 (PST)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA27349;
	Thu, 14 Dec 2000 09:23:19 -0800 (PST)
Date:   Thu, 14 Dec 2000 09:22:56 -0800 (PST)
From:   Tom Duffy <tduffy@engr.sgi.com>
To:     Steven M Wilson <swilson@hcjbeng.org>
cc:     <linux-xfs@oss.sgi.com>
Subject: RE: [Fwd: RE: Installing XFS Beta on RedHat 7.0]
In-Reply-To: <000001c065f1$54d039b0$8332a8c0@swilson-nt.hcjbeng.org>
Message-ID: <Pine.LNX.4.30.0012140918550.1938-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

> The script "create_clean_kernel_tree" fails trying to locate and execute a
> program called p_tupdate.  Where can I get this program?

p_tupdate is a program associated with sgi's internal source control
system called ptools.  first off, you don't want this program :)
secondly, it would not help you because this script is trying to checkout
code from a server inside the sgi firewall.

> Also, many scripts require the top directory to be /usr/src/redhat but the
> rpmmacros file (cmd/xfs/build/rpm/rpmmacros) references
> /usr/src/linux-2.4-xfs.  I created a symbolic link so that
> /usr/src/linux-2.4-xfs points to /usr/src/redhat.  Was that the right thing
> to do?

create a file ".rpmmacros" in your home directory and put the following
line it it:

%_topdir <path_to_directory>/linux-2.4-xfs

substituting <path_to_directory> with your path.

I am planning on restructuring the xfs rpm build to be less reliant on
sgi's internal source control once test12 goes in.  for the mean time, you
can simply grab a kenrel tarball, put that into SOURCES, and create the
xfs patch your self using diff -Nur on a clean test11 tree and the xfs
tree.

-tduffy


From owner-linux-xfs@oss.sgi.com Thu Dec 14 09:34:10 2000
Received:  by oss.sgi.com id <S553688AbQLNReA>;
	Thu, 14 Dec 2000 09:34:00 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:30539 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553671AbQLNRdm>; Thu, 14 Dec 2000 09:33:42 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA05531
	for <linux-xfs@oss.sgi.com>; Thu, 14 Dec 2000 09:41:59 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA107141; Thu, 14 Dec 2000 11:32:23 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA70594; Thu, 14 Dec 2000 11:32:23 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBEHWNi01356;
	Thu, 14 Dec 2000 11:32:23 -0600
Message-ID: <3A390426.14322A40@thebarn.com>
Date:   Thu, 14 Dec 2000 11:32:23 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     swilson@hcjbeng.org
CC:     linux-xfs@oss.sgi.com, tduffy@engr.sgi.com
Subject: Re: [Fwd: RE: Installing XFS Beta on RedHat 7.0]
References: <000001c065f1$54d039b0$8332a8c0@swilson-nt.hcjbeng.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Steven M Wilson wrote:

> > > I'm stuck now with a failure to locate the file
> > > "linux-2.4.0-test11-xfs-alpha.patch" under SOURCES.
> > > This file is needed for (at least) SCRIPTS/make-tarballs
> > > and the command "make i386kernel" at the
> > > root of the source tree.
> >
> > the patch is generated on the fly by the scripts.  it checks
> > out a copy of
> > a clean linux 2.4.0-test11 tree and diffs the xfs tree to generate the
> > patch.
> >
> > this is done because rpm wants a clean tarball plus
> > patches...we will be
> > moving to a patch based system for distributing xfs at some
> > point in the
> > future.
> >
> > I am hesitant to check in the patch since it should be
> > generated at any
> > given moment by looking at the current xfs tree and a stock
> > linux tarball.
> > you will also need to grab a linux tarball and put that into
> > SOURCES as
> > well as this is not checked into the tree (we did not want to
> > have that
> > huge binary in the tree).
> >
> > hope this helps,
> >
> > -tduffy
> >
>
> The script "create_clean_kernel_tree" fails trying to locate and execute a
> program called p_tupdate.  Where can I get this program?

hmm that's an SGI internal source code control program.

I'm not sure going through hassle of trying to build and rpm is really
going to gain you much.

I would recommend just copying the correct config file from the SOURCES
directory
(eg kernel-2.4.0-i686.config ) to linux/.config
cd linux
make oldconfig depend bzImage modules install modules_install
this will build and install everything.

Edit lilo.conf add another entry for
vmlinuz-2.4.0-XFS-test11
run  lilo
and reboot.
(selecting the new kernel at the LILO prompt)


Just for grins I will fire off an RPM build on a 7.0 box see if I can generate

7.0 images.


>
>
> Also, many scripts require the top directory to be /usr/src/redhat but the
> rpmmacros file (cmd/xfs/build/rpm/rpmmacros) references
> /usr/src/linux-2.4-xfs.  I created a symbolic link so that
> /usr/src/linux-2.4-xfs points to /usr/src/redhat.  Was that the right thing
> to do?
>
> Thanks again for your help!
>
> Steve


From owner-linux-xfs@oss.sgi.com Thu Dec 14 09:41:00 2000
Received:  by oss.sgi.com id <S553699AbQLNRkl>;
	Thu, 14 Dec 2000 09:40:41 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:10572 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553683AbQLNRk3>; Thu, 14 Dec 2000 09:40:29 -0800
Received: from hops.chicago.sgi.com (hops.chicago.sgi.com [169.238.235.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA06087
	for <linux-xfs@oss.sgi.com>; Thu, 14 Dec 2000 09:48:46 -0800 (PST)
	mail_from (gquinn@guinness.chicago.sgi.com)
Received: from guinness.chicago.sgi.com (guinness.chicago.sgi.com [169.238.235.131]) by hops.chicago.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA40021; Thu, 14 Dec 2000 11:39:11 -0600 (CST)
Received: from localhost (gquinn@localhost) by guinness.chicago.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA89427; Thu, 14 Dec 2000 11:39:10 -0600 (CST)
Date:   Thu, 14 Dec 2000 11:39:10 -0600
From:   Gerry Quinn <gquinn@guinness.chicago.sgi.com>
To:     Steven M Wilson <swilson@hcjbeng.org>
cc:     linux-xfs@oss.sgi.com, tduffy@engr.sgi.com
Subject: RE: [Fwd: RE: Installing XFS Beta on RedHat 7.0]
In-Reply-To: <000001c065f1$54d039b0$8332a8c0@swilson-nt.hcjbeng.org>
Message-ID: <Pine.SGI.4.05.10012141125050.1285890-100000@guinness.chicago.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi Steve,

I just finished successfully compiling linux-2.4-xfs-beta on redhat 7.0.
It booted up fine and I'm running a performance test on a scsi xfs
filesystem.

I found the following tip in the index of the mail list linix-xfs:

	I just installed the kgcc rpm from the distro and change the above line
	to:

	CC              = $(CROSS_COMPILE)kgcc -V egcs-2.91.66

	and the kernel is compiling now.  kgcc appears to, in fact, be
	egcs-2.91.66.

The compile worked after making this change.

Also, I linked /usr/lib/gcc-lib/egcs-2.91.66 to 
/usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66 however, I did this before 
making the change to the kernel top level Makefile so I don't know if it actually has any affect.

For what it's worth, The write performance on myscsi xfs filesystem is
14MB/sec.  I don't know whether this is good or not cause I know the bus 
is fast and wide but I don't know anything about the disk yet (ie it's a 
customers system and I don't know what is installed).

Hope this helps,

Gerry

................................................
. Gerry Quinn                                  .
. sgi                                          .
. Chicago Branch Office - Schaumburg, Illinois .
. 847-925-2941; vnet 625-2941; pag 888-398-9044.
. gquinn@chicago.sgi.com                       .
................................................

"I'll put up with all the bulls%$&, but as 
soon as they stop paying me, I'm out-a-here!"

On Thu, 14 Dec 2000, Steven M Wilson wrote:

> > > I'm stuck now with a failure to locate the file
> > > "linux-2.4.0-test11-xfs-alpha.patch" under SOURCES.
> > > This file is needed for (at least) SCRIPTS/make-tarballs
> > > and the command "make i386kernel" at the
> > > root of the source tree.
> >
> > the patch is generated on the fly by the scripts.  it checks
> > out a copy of
> > a clean linux 2.4.0-test11 tree and diffs the xfs tree to generate the
> > patch.
> >
> > this is done because rpm wants a clean tarball plus
> > patches...we will be
> > moving to a patch based system for distributing xfs at some
> > point in the
> > future.
> >
> > I am hesitant to check in the patch since it should be
> > generated at any
> > given moment by looking at the current xfs tree and a stock
> > linux tarball.
> > you will also need to grab a linux tarball and put that into
> > SOURCES as
> > well as this is not checked into the tree (we did not want to
> > have that
> > huge binary in the tree).
> >
> > hope this helps,
> >
> > -tduffy
> >
> 
> The script "create_clean_kernel_tree" fails trying to locate and execute a
> program called p_tupdate.  Where can I get this program?
> 
> Also, many scripts require the top directory to be /usr/src/redhat but the
> rpmmacros file (cmd/xfs/build/rpm/rpmmacros) references
> /usr/src/linux-2.4-xfs.  I created a symbolic link so that
> /usr/src/linux-2.4-xfs points to /usr/src/redhat.  Was that the right thing
> to do?
> 
> Thanks again for your help!
> 
> Steve
> 


From owner-linux-xfs@oss.sgi.com Thu Dec 14 16:01:06 2000
Received:  by oss.sgi.com id <S553782AbQLOAAr>;
	Thu, 14 Dec 2000 16:00:47 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:24326 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553686AbQLOAA2>;
	Thu, 14 Dec 2000 16:00:28 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA08703
	for <linux-xfs@oss.sgi.com>; Thu, 14 Dec 2000 15:59:40 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA02614
	for linux-xfs@oss.sgi.com; Fri, 15 Dec 2000 10:57:51 +1100 (EST)
Date:   Fri, 15 Dec 2000 10:57:51 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012142357.KAA02614@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - mountopts
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Came across this going thru the mount opt doco the other day...

Modid:  2.4.x-xfs:slinx:80759a
Date:  Thu Dec 14 15:56:45 PST 2000
Workarea:  snort:/diskb/build4/nathans/quota-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/fs/xfs/linux/xfs_mount_opt.c - 1.18
	- remove a useless if statement in the mount option parsing.


From owner-linux-xfs@oss.sgi.com Thu Dec 14 17:09:27 2000
Received:  by oss.sgi.com id <S553788AbQLOBJG>;
	Thu, 14 Dec 2000 17:09:06 -0800
Received: from morpheus.webprojkt.com ([209.61.155.148]:59918 "HELO
        morpheus.webprojkt.com") by oss.sgi.com with SMTP
	id <S553789AbQLOBIf>; Thu, 14 Dec 2000 17:08:35 -0800
Received: (qmail 31861 invoked by uid 604); 15 Dec 2000 01:08:33 -0000
Received: from unknown (HELO webprojkt.com) (216.126.153.42)
  by morpheus.webprojkt.com with SMTP; 15 Dec 2000 01:08:33 -0000
Message-ID: <3A396F0A.20508@webprojkt.com>
Date:   Thu, 14 Dec 2000 19:08:26 -0600
From:   Brice Ruth <brice@webprojkt.com>
User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20001211
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
CC:     netatalk-admins@umich.edu
Subject: Help ... missing directory
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Let me preface this message: I'm DESPERATE

OK, that being said, here goes:

My setup:
SMP i686 (PIII) running linux-2.4-xfs from CVS updated 12/11/2000 around 
9pm (CST).

I have a 20GB ide disk dedicated to XFS.  The main use of the disk is as 
a shared drive (via Appletalk) to our small group of designers.  Late 
this evening (about an hour ago) a designer noticed a directory missing 
from the share.  I logged into the server, did an ls of the share and 
sure enough, the directory was gone.  I have these entries from the log 
around that time:

Dec 14 18:00:24 construct afpd[2611]: refused connect from 10.0.0.16
Dec 14 18:00:24 construct afpd[2611]: dsi_getsess: Interrupted system call
Dec 14 18:00:33 construct afpd[5819]: session from 65339.5:247 on 3001.1:131
Dec 14 18:00:33 construct afpd[5819]: randnum/rand2num login: paulc
Dec 14 18:00:33 construct afpd[5819]: login paulc (uid 505, gid 250)
Dec 14 18:00:35 construct afpd[2611]: refused connect from 10.0.0.16
Dec 14 18:00:35 construct afpd[2611]: dsi_getsess: Interrupted system call
Dec 14 18:00:35 construct afpd[2611]: refused connect from 10.0.0.16
Dec 14 18:00:35 construct afpd[2611]: dsi_getsess: Interrupted system call
Dec 14 18:00:36 construct afpd[2611]: refused connect from 10.0.0.16
Dec 14 18:00:36 construct afpd[2611]: dsi_getsess: Interrupted system call

Obviously these aren't entries from XFS, they're from netatalk.  What I 
need to know is if there is ANY (I truly mean *ANY*) way to turn back 
the clock.  I'm not familiar enough with the XFS tools to play around 
with them without fear of trashing something else.  I tried to use 
xfs_logprint, but wasn't able to actually understand anything.

Please, please, please help.

Sincerest regards,

-- 
Brice Ruth
WebProjkt, Inc.
VP, Director of Internet Technology
http://www.webprojkt.com/


From owner-linux-xfs@oss.sgi.com Thu Dec 14 17:41:27 2000
Received:  by oss.sgi.com id <S553803AbQLOBlQ>;
	Thu, 14 Dec 2000 17:41:16 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:3614 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553789AbQLOBk5>;
	Thu, 14 Dec 2000 17:40:57 -0800
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA20672
	for <linux-xfs@oss.sgi.com>; Thu, 14 Dec 2000 17:40:09 -0800 (PST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22073; Fri, 15 Dec 2000 12:39:36 +1100
Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id MAA10958; Fri, 15 Dec 2000 12:39:35 +1100 (EDT)
From:   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10012151239.ZM210185@wobbly.melbourne.sgi.com>
Date:   Fri, 15 Dec 2000 12:39:34 -0400
In-Reply-To: Brice Ruth <brice@webprojkt.com>
        "Help ... missing directory" (Dec 14,  7:08pm)
References: <3A396F0A.20508@webprojkt.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To:     Brice Ruth <brice@webprojkt.com>, linux-xfs@oss.sgi.com
Subject: Re: Help ... missing directory
Cc:     netatalk-admins@umich.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

hi Brice,

On Dec 14,  7:08pm, Brice Ruth wrote:
> Subject: Help ... missing directory
> Let me preface this message: I'm DESPERATE
> 
> OK, that being said, here goes:
> 
> My setup:
> SMP i686 (PIII) running linux-2.4-xfs from CVS updated 12/11/2000 around 
> 9pm (CST).
> 
> I have a 20GB ide disk dedicated to XFS.  The main use of the disk is as 
> a shared drive (via Appletalk) to our small group of designers.  Late 
> this evening (about an hour ago) a designer noticed a directory missing 
> from the share.  I logged into the server, did an ls of the share and 
> sure enough, the directory was gone.
> ...
> Obviously these aren't entries from XFS, they're from netatalk.  What I 
> need to know is if there is ANY (I truly mean *ANY*) way to turn back 
> the clock.  I'm not familiar enough with the XFS tools to play around 
> with them without fear of trashing something else.  I tried to use 
> xfs_logprint, but wasn't able to actually understand anything.
> 

I think the best thing you can do is unmount the filesystem
and run xfs_repair(8) on the block device.  Use the -n option
(no writes) at first to see whether it is going to do anything.

If xfs_repair shows no fs corruption, I don't think there's much
else you can do.  If the directory was somehow corrupted, then
xfs_repair will move its disconnected children into the
/lost+found directory, and you could still have everything else
intact.

hope this helps.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu Dec 14 20:59:38 2000
Received:  by oss.sgi.com id <S553695AbQLOE71>;
	Thu, 14 Dec 2000 20:59:27 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:33812 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553645AbQLOE7K>; Thu, 14 Dec 2000 20:59:10 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA06762
	for <linux-xfs@oss.sgi.com>; Thu, 14 Dec 2000 21:07:27 -0800 (PST)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA61783
	for linux-xfs@oss.sgi.com; Fri, 15 Dec 2000 15:57:49 +1100 (EST)
Date:   Fri, 15 Dec 2000 15:57:49 +1100 (EST)
From:   Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200012150457.PAA61783@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - stress test 051
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Checkin of ACL tests. (ACL code not yet checked in).
If run check without ACL code then test won't be run. 

--Tim

Modid:  2.4.x-xfs:slinx:80812a
Date:  Thu Dec 14 20:54:06 PST 2000
Workarea:  snort:/diskb/build4/tes/slinx-xfs-acl
Author:  tes

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/stress/group - 1.55
	- Add test 051 of acl group.

cmd/xfs/stress/src/Makefile - 1.22
	- Add src/runas.

cmd/xfs/stress/051 - 1.1
	- Test out ACL code in kernel and libacl.

cmd/xfs/stress/051.out - 1.1
	- Success and failures for (g|s)etting acls and testing permissions.

cmd/xfs/stress/src/runas.c - 1.1
	- Run a command as particular euid, egid, suppl. groups
	  Written for use by stress/051 which tests ACLs.


From owner-linux-xfs@oss.sgi.com Thu Dec 14 22:28:10 2000
Received:  by oss.sgi.com id <S553765AbQLOG1u>;
	Thu, 14 Dec 2000 22:27:50 -0800
Received: from TYO201.gate.nec.co.jp ([202.32.8.214]:46097 "EHLO
        TYO201.gate.nec.co.jp") by oss.sgi.com with ESMTP
	id <S553704AbQLOG1b>; Thu, 14 Dec 2000 22:27:31 -0800
Received: from mailgate4.nec.co.jp ([10.7.69.193])
	by TYO201.gate.nec.co.jp (8.9.3/3.7W00121312) with ESMTP id PAA02775;
	Fri, 15 Dec 2000 15:27:20 +0900 (JST)
Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.9.3/3.7W-MAILGATE-NEC) with ESMTP
	id PAA06289; Fri, 15 Dec 2000 15:27:17 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP
	id PAA06115; Fri, 15 Dec 2000 15:26:56 +0900 (JST)
Received: from mahler.hpc.bs1.fc.nec.co.jp. (mahler.hpc.bs1.fc.nec.co.jp [133.203.2.48])
	by mahler.hpc.bs1.fc.nec.co.jp (8.9.3/3.7W-HPC5.1E(common)) with ESMTP id PAA12690;
	Fri, 15 Dec 2000 15:28:01 +0900
Date:   Fri, 15 Dec 2000 15:28:01 +0900
Message-ID: <geae9yfbbi.wl@hpc.bs1.fc.nec.co.jp>
From:   Hiroshi Aono <h-aono@ap.jp.nec.com>
To:     cattelan@thebarn.com
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Initial fix for non 4k page systems.
In-Reply-To: In your message of "Mon, 11 Dec 2000 12:42:49 -0600"
	<3A352029.19894EE5@thebarn.com>
References: <3A352029.19894EE5@thebarn.com>
User-Agent: Wanderlust/1.1.1 (Purple Rain) WEMI/1.13.7 (Shimada)
 CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.1 (patch
 9) (Canyonlands) (i386-pc-linux)
MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At Mon, 11 Dec 2000 12:42:49 -0600,
Russell Cattelan <cattelan@thebarn.com> wrote:

> I've only testing this on an alpha system, so I curious to see if this
> fixes ppc and ia64.

Hi,

I have been testing page_buf.c patch on ia64 system.
The XFS (2.4.0-test10 based) works well on the following machines, so far.
 - Intel Bigsur (2 CPU,1G memory)
 - NEC AzusA (16 CPU,4G memory)
I made a kernel on XFS and it booted.

Thanks,

Hiroshi Aono, NEC Solutions
(h-aono@ap.jp.nec.com)

From owner-linux-xfs@oss.sgi.com Thu Dec 14 23:26:30 2000
Received:  by oss.sgi.com id <S553768AbQLOH0U>;
	Thu, 14 Dec 2000 23:26:20 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:36623 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S553724AbQLOH0E>;
	Thu, 14 Dec 2000 23:26:04 -0800
Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBF7Pww99873;
	Fri, 15 Dec 2000 01:25:58 -0600 (CST)
Message-ID: <3A39C780.39AF7612@thebarn.com>
Date:   Fri, 15 Dec 2000 01:25:52 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Hiroshi Aono <h-aono@ap.jp.nec.com>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Initial fix for non 4k page systems.
References: <3A352029.19894EE5@thebarn.com> <geae9yfbbi.wl@hpc.bs1.fc.nec.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hiroshi Aono wrote:

> At Mon, 11 Dec 2000 12:42:49 -0600,
> Russell Cattelan <cattelan@thebarn.com> wrote:
>
> > I've only testing this on an alpha system, so I curious to see if this
> > fixes ppc and ia64.
>
> Hi,
>
> I have been testing page_buf.c patch on ia64 system.
> The XFS (2.4.0-test10 based) works well on the following machines, so far.
>  - Intel Bigsur (2 CPU,1G memory)
>  - NEC AzusA (16 CPU,4G memory)
> I made a kernel on XFS and it booted.

Good to know... Thanks


>
>
> Thanks,
>
> Hiroshi Aono, NEC Solutions
> (h-aono@ap.jp.nec.com)

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri Dec 15 04:43:30 2000
Received:  by oss.sgi.com id <S553755AbQLOMnL>;
	Fri, 15 Dec 2000 04:43:11 -0800
Received: from tux.mkp.net ([130.225.60.11]:10510 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553746AbQLOMnI>;
	Fri, 15 Dec 2000 04:43:08 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 146uCI-0004uQ-00; Fri, 15 Dec 2000 13:42:50 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id HAA26971;
	Fri, 15 Dec 2000 07:40:50 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Initial fix for non 4k page systems.
References: <3A352029.19894EE5@thebarn.com>
	<geae9yfbbi.wl@hpc.bs1.fc.nec.co.jp> <3A39C780.39AF7612@thebarn.com>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   15 Dec 2000 07:40:49 -0500
In-Reply-To: Russell Cattelan's message of "Fri, 15 Dec 2000 01:25:52 -0600"
Message-ID: <yq1zohxg8mm.fsf@jaguar.mkp.net>
Lines:  17
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>>>>> "Russell" == Russell Cattelan <cattelan@thebarn.com> writes:

>> I have been testing page_buf.c patch on ia64 system.  The XFS
>> (2.4.0-test10 based) works well on the following machines, so far.

Russell> Good to know... Thanks

FWIW, it also works on sparc64.

I'm still having issues with xfs-cmds, though (32-bit userland on
64-bit kernel).

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Fri Dec 15 18:53:58 2000
Received:  by oss.sgi.com id <S553794AbQLPCxs>;
	Fri, 15 Dec 2000 18:53:48 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:51724 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553787AbQLPCxe>; Fri, 15 Dec 2000 18:53:34 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA05728
	for <linux-xfs@oss.sgi.com>; Fri, 15 Dec 2000 19:01:53 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA124998 for <linux-xfs@oss.sgi.com>; Fri, 15 Dec 2000 20:52:17 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA09113 for <linux-xfs@oss.sgi.com>; Fri, 15 Dec 2000 20:52:17 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBG2qHx15554
	for <linux-xfs@oss.sgi.com>; Fri, 15 Dec 2000 20:52:17 -0600
Message-ID: <3A3AD8E0.F5F73A4B@thebarn.com>
Date:   Fri, 15 Dec 2000 20:52:16 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: XFS and test12
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Short update:
Test12 has proven more difficult than expected.

I've working around the fact that ll_rw_block is redefining the b_end_io
callback.
I now have the file system reading AND writing data again.

The final problem appears to be a page unlocking problem.
the responsibility of unlocking pages has shifted a bit, and it appears
we are not doing it correctly.

Hopefully I will be able to track this down in the next day or so.


-Russell Cattelan





From owner-linux-xfs@oss.sgi.com Sat Dec 16 00:16:13 2000
Received:  by oss.sgi.com id <S553826AbQLPIPx>;
	Sat, 16 Dec 2000 00:15:53 -0800
Received: from ns.caldera.de ([212.34.180.1]:7686 "EHLO ns.caldera.de")
	by oss.sgi.com with ESMTP id <S553793AbQLPIPV>;
	Sat, 16 Dec 2000 00:15:21 -0800
Received: (from hch@localhost)
	by ns.caldera.de (8.9.3/8.9.3) id JAA23933;
	Sat, 16 Dec 2000 09:15:01 +0100
Date:   Sat, 16 Dec 2000 09:15:01 +0100
From:   Christoph Hellwig <hch@caldera.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS and test12
Message-ID: <20001216091501.A23776@caldera.de>
References: <3A3AD8E0.F5F73A4B@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <3A3AD8E0.F5F73A4B@thebarn.com>; from cattelan@thebarn.com on Fri, Dec 15, 2000 at 08:52:16PM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, Dec 15, 2000 at 08:52:16PM -0600, Russell Cattelan wrote:
> Short update:
> Test12 has proven more difficult than expected.
> 
> I've working around the fact that ll_rw_block is redefining the b_end_io
> callback.
> I now have the file system reading AND writing data again.

You should use submit_bh() instead of ll_rw_block if you want to use
your own b_end_io.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

From owner-linux-xfs@oss.sgi.com Sat Dec 16 08:35:36 2000
Received:  by oss.sgi.com id <S553872AbQLPQf0>;
	Sat, 16 Dec 2000 08:35:26 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:49670 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553869AbQLPQe7>;
	Sat, 16 Dec 2000 08:34:59 -0800
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eBGGYdk88290;
	Sat, 16 Dec 2000 10:34:39 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A3B99AE.D00703F7@thebarn.com>
Date:   Sat, 16 Dec 2000 10:34:54 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Christoph Hellwig <hch@caldera.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: XFS and test12
References: <3A3AD8E0.F5F73A4B@thebarn.com> <20001216091501.A23776@caldera.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Christoph Hellwig wrote:

> On Fri, Dec 15, 2000 at 08:52:16PM -0600, Russell Cattelan wrote:
> > Short update:
> > Test12 has proven more difficult than expected.
> >
> > I've working around the fact that ll_rw_block is redefining the b_end_io
> > callback.
> > I now have the file system reading AND writing data again.
>
> You should use submit_bh() instead of ll_rw_block if you want to use
> your own b_end_io.

Yup... except sync_buffers calls ll_rw_block so all buffered writes were not
going out to disk.

>
>
>         Christoph
>
> --
> Whip me.  Beat me.  Make me maintain AIX.


From owner-linux-xfs@oss.sgi.com Sat Dec 16 17:03:58 2000
Received:  by oss.sgi.com id <S553890AbQLQBDj>;
	Sat, 16 Dec 2000 17:03:39 -0800
Received: from ns.virtualhost.dk ([195.184.98.160]:4613 "EHLO virtualhost.dk")
	by oss.sgi.com with ESMTP id <S553887AbQLQBDb>;
	Sat, 16 Dec 2000 17:03:31 -0800
Received: from burns.home.kernel.dk ([192.168.0.2] ident=root)
	by virtualhost.dk with esmtp (Exim 3.16 #1)
	id 147SEC-0008Mb-00; Sun, 17 Dec 2000 02:03:04 +0100
Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian))
	id 147SEA-0000ih-00; Sun, 17 Dec 2000 02:03:02 +0100
Date:   Sun, 17 Dec 2000 02:03:02 +0100
From:   Jens Axboe <axboe@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
Message-ID: <20001217020302.C2061@suse.de>
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com> <20001211003152.O294@suse.de> <3A34478B.BCCFB089@thebarn.com> <20001211150432.C294@suse.de> <3A355FE4.455ACC88@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3A355FE4.455ACC88@thebarn.com>; from cattelan@thebarn.com on Mon, Dec 11, 2000 at 05:14:44PM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Mon, Dec 11 2000, Russell Cattelan wrote:
> I'm trying to convince one of our linux  testers to run the ide patch
> through its paces. Hopefully we'll have some results in a few days.

Anything come of this? I haven't gotten any reports on how well it works.
I'm just assuming it's perfect, I know people will complain if it either
crashed or corrupts their data. Of course another option is that noone
has bothered trying it yet.

In any case, I of course want to know if there are any problems at all
so we can get these fixed.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Sat Dec 16 17:13:29 2000
Received:  by oss.sgi.com id <S553892AbQLQBNJ>;
	Sat, 16 Dec 2000 17:13:09 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:29203 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S553889AbQLQBNI>;
	Sat, 16 Dec 2000 17:13:08 -0800
Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBH1D3w22220;
	Sat, 16 Dec 2000 19:13:04 -0600 (CST)
Message-ID: <3A3C131A.1915BB39@thebarn.com>
Date:   Sat, 16 Dec 2000 19:12:58 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jens Axboe <axboe@suse.de>
CC:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com> <20001211003152.O294@suse.de> <3A34478B.BCCFB089@thebarn.com> <20001211150432.C294@suse.de> <3A355FE4.455ACC88@thebarn.com> <20001217020302.C2061@suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jens Axboe wrote:

> On Mon, Dec 11 2000, Russell Cattelan wrote:
> > I'm trying to convince one of our linux  testers to run the ide patch
> > through its paces. Hopefully we'll have some results in a few days.
>
> Anything come of this? I haven't gotten any reports on how well it works.
> I'm just assuming it's perfect, I know people will complain if it either
> crashed or corrupts their data. Of course another option is that noone
> has bothered trying it yet.
>
> In any case, I of course want to know if there are any problems at all
> so we can get these fixed.

Sorry nothing yet.
Martin said he was going to run some test but I haven't heard from him.

Our test team sometimes take a bit of time to get up to speed.
I'll push on them a bit more monday.


I've been a bit wrapped up with the merge up to test12.

XFS and test12 seem to running smoothly finally,  I plan on checking it in
either tonight or early tomorrow.


>
>
> --
> * Jens Axboe <axboe@suse.de>
> * SuSE Labs

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sat Dec 16 17:20:29 2000
Received:  by oss.sgi.com id <S553894AbQLQBUJ>;
	Sat, 16 Dec 2000 17:20:09 -0800
Received: from ns.virtualhost.dk ([195.184.98.160]:9989 "EHLO virtualhost.dk")
	by oss.sgi.com with ESMTP id <S553891AbQLQBUE>;
	Sat, 16 Dec 2000 17:20:04 -0800
Received: from burns.home.kernel.dk ([192.168.0.2] ident=root)
	by virtualhost.dk with esmtp (Exim 3.16 #1)
	id 147SUa-0008Pa-00; Sun, 17 Dec 2000 02:20:00 +0100
Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian))
	id 147SUY-0000lH-00; Sun, 17 Dec 2000 02:19:58 +0100
Date:   Sun, 17 Dec 2000 02:19:58 +0100
From:   Jens Axboe <axboe@suse.de>
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
Message-ID: <20001217021958.D2061@suse.de>
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com> <20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com> <20001211003152.O294@suse.de> <3A34478B.BCCFB089@thebarn.com> <20001211150432.C294@suse.de> <3A355FE4.455ACC88@thebarn.com> <20001217020302.C2061@suse.de> <3A3C131A.1915BB39@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3A3C131A.1915BB39@thebarn.com>; from cattelan@thebarn.com on Sat, Dec 16, 2000 at 07:12:58PM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sat, Dec 16 2000, Russell Cattelan wrote:
> > Anything come of this? I haven't gotten any reports on how well it works.
> > I'm just assuming it's perfect, I know people will complain if it either
> > crashed or corrupts their data. Of course another option is that noone
> > has bothered trying it yet.
> >
> > In any case, I of course want to know if there are any problems at all
> > so we can get these fixed.
> 
> Sorry nothing yet.
> Martin said he was going to run some test but I haven't heard from him.

Ok, this was also a message to the list saying 'if you've tried it, let
me know what happened'. I use the code myself too, not just for XFS but
as a test base for general kiobuf I/O.

> Our test team sometimes take a bit of time to get up to speed.
> I'll push on them a bit more monday.
> 
> 
> I've been a bit wrapped up with the merge up to test12.
> 
> XFS and test12 seem to running smoothly finally,  I plan on checking it in
> either tonight or early tomorrow.

Great, I will test once it's comitted. 

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs

From owner-linux-xfs@oss.sgi.com Sat Dec 16 22:28:31 2000
Received:  by oss.sgi.com id <S553904AbQLQG2V>;
	Sat, 16 Dec 2000 22:28:21 -0800
Received: from tux.mkp.net ([130.225.60.11]:56581 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553901AbQLQG1y>;
	Sat, 16 Dec 2000 22:27:54 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 147XHr-0006kb-00; Sun, 17 Dec 2000 07:27:12 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id BAA27527;
	Sun, 17 Dec 2000 01:25:00 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     Russell Cattelan <cattelan@thebarn.com>
Cc:     Jens Axboe <axboe@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: patch: double freereq freeing
References: <20001210215635.E294@suse.de> <3A33F25C.5E9FAB1C@thebarn.com>
	<20001210222057.F294@suse.de> <3A33F9C8.CD56A6CC@thebarn.com>
	<20001211003152.O294@suse.de> <3A34478B.BCCFB089@thebarn.com>
	<20001211150432.C294@suse.de> <3A355FE4.455ACC88@thebarn.com>
	<20001217020302.C2061@suse.de> <3A3C131A.1915BB39@thebarn.com>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   17 Dec 2000 01:24:58 -0500
In-Reply-To: Russell Cattelan's message of "Sat, 16 Dec 2000 19:12:58 -0600"
Message-ID: <yq166kjfttx.fsf@jaguar.mkp.net>
Lines:  15
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>>>>> "Russell" == Russell Cattelan <cattelan@thebarn.com> writes:

[kiobuf IDE support]

Russell> Sorry nothing yet.  Martin said he was going to run some test
Russell> but I haven't heard from him.

I've been pounding on it for several days now without any problems
whatsoever.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Sat Dec 16 23:28:20 2000
Received:  by oss.sgi.com id <S553910AbQLQH2L>;
	Sat, 16 Dec 2000 23:28:11 -0800
Received: from vitelus.com ([64.81.36.147]:10756 "EHLO vitelus.com")
	by oss.sgi.com with ESMTP id <S553907AbQLQH1u>;
	Sat, 16 Dec 2000 23:27:50 -0800
Received: from aaronl by vitelus.com with local (Exim 3.20 #1 (Debian))
	id 147YEX-0000AG-00
	for <linux-xfs@oss.sgi.com>; Sat, 16 Dec 2000 23:27:49 -0800
Date:   Sat, 16 Dec 2000 23:27:49 -0800
From:   Aaron Lehmann <aaronl@vitelus.com>
To:     linux-xfs@oss.sgi.com
Subject: NFS issues
Message-ID: <20001216232749.A571@vitelus.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


--wac7ysb48OaltWcw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment

Here is an issue I see on my Debian NFS server running the current XFS
devel tree and the userspace NFS server. The server is running
linux-2.4.0-test11-XFS and the client is running linux-2.4.0-test10.

server# cd /archive
client$ cd /archive
server# ls
backup  doc  media  nfs
client$ ls
backup  doc  media  nfs
server# mkdir test
client$ ls
backup  doc  media  nfs
client$ cd test
client$ cd ..
client$ ls
backup  doc  media  nfs
server# mkdir test2
client$ ls
backup  doc  media  nfs  test  test2
server# rm -rf test*
client$ ls
backup  doc  media  nfs  test  test2
client$ cd test
bash: cd: test: No such file or directory

The problem, of course, is that directory creations and deletions
don't immediately take effect on NFS clients that the filesystem has
been exported to.

--wac7ysb48OaltWcw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6PGr1dtqQf66JWJkRArhYAKDkz/F3K+QYODiGI0xeyPCQOetpqACggrLf
g6zqd/JF8lF+jcLm17Vrtw0=
=1ADz
-----END PGP SIGNATURE-----

--wac7ysb48OaltWcw--

From owner-linux-xfs@oss.sgi.com Sun Dec 17 19:28:34 2000
Received:  by oss.sgi.com id <S553806AbQLRD2N>;
	Sun, 17 Dec 2000 19:28:13 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:9732 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553758AbQLRD1n>; Sun, 17 Dec 2000 19:27:43 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id BAA27809
	for <linux-xfs@oss.sgi.com>; Mon, 18 Dec 2000 01:27:37 -0200
Date:   Sun, 17 Dec 2000 23:34:25 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     linux-xfs@oss.sgi.com
Subject: set_buffer_dirty_uptodate 
Message-ID: <Pine.LNX.4.21.0012172303250.856-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Hi, 

I was looking at the pagebuf code while I noted that
set_buffer_dirty_uptodate (pagebuf/page_buf_io.c:1188) may sleep waiting
for bdflush to clean some dirty buffers because it calls balance_dirty().

set_buffer_dirty_update is called by functions which are part of the XFS's
writepage codepath, which basically starts at linvfs_write_full_page
(xfs/linux/xfs_iops.c).

The issue is that linvfs_write_full_page() is taking a vnode lock before
going through this codepath, meaning that it can sleep waiting for bdflush
while holding this lock which seems to be unecessary.

If this "vnode lock" suffers from contention because processes sleep while
holding it, we can fix it by calling balance_dirty() _after_ we drop the
vnode lock.

In practice, this vnode lock is a being used concurrently by a lot of
users?

Thanks!


From owner-linux-xfs@oss.sgi.com Mon Dec 18 09:20:27 2000
Received:  by oss.sgi.com id <S553851AbQLRRUI>;
	Mon, 18 Dec 2000 09:20:08 -0800
Received: from sgi.SGI.COM ([192.48.153.1]:62471 "EHLO sgi.com")
	by oss.sgi.com with ESMTP id <S553752AbQLRRUD>;
	Mon, 18 Dec 2000 09:20:03 -0800
Received: from nodin.corp.sgi.com ([198.29.75.193]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA06047
	for <linux-xfs@oss.sgi.com>; Mon, 18 Dec 2000 09:19:49 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from zeus-fddi.americas.sgi.com ([128.162.8.103]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA04143 for <linux-xfs@oss.sgi.com>; Sun, 17 Dec 2000 13:41:48 -0800 (PST)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA136328 for <linux-xfs@oss.sgi.com>; Sun, 17 Dec 2000 15:36:47 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA18385 for <linux-xfs@oss.sgi.com>; Sun, 17 Dec 2000 15:36:47 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eBHLakV24736
	for linux-xfs@oss.sgi.com; Sun, 17 Dec 2000 15:36:46 -0600
Date:   Sun, 17 Dec 2000 15:36:46 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200012172136.eBHLakV24736@gibble.americas.sgi.com>
Subject: TAKE - 
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Sun Dec 17 13:36:36 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-test12

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80889a
linux/fs/xfs/linux/xfs_iops.c - 1.84
	- Ok one more missed line with the test12 merge.



From owner-linux-xfs@oss.sgi.com Mon Dec 18 09:21:58 2000
Received:  by oss.sgi.com id <S553854AbQLRRVi>;
	Mon, 18 Dec 2000 09:21:38 -0800
Received: from sgi.SGI.COM ([192.48.153.1]:62216 "EHLO sgi.com")
	by oss.sgi.com with ESMTP id <S553842AbQLRRVX>;
	Mon, 18 Dec 2000 09:21:23 -0800
Received: from nodin.corp.sgi.com ([198.29.75.193]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA05420
	for <linux-xfs@oss.sgi.com>; Mon, 18 Dec 2000 09:21:22 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from zeus-fddi.americas.sgi.com ([128.162.8.103]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA98958 for <linux-xfs@oss.sgi.com>; Sun, 17 Dec 2000 13:02:37 -0800 (PST)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA135877 for <linux-xfs@oss.sgi.com>; Sun, 17 Dec 2000 14:57:35 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA98078 for <linux-xfs@oss.sgi.com>; Sun, 17 Dec 2000 14:57:35 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eBHKvZc23305
	for linux-xfs@oss.sgi.com; Sun, 17 Dec 2000 14:57:35 -0600
Date:   Sun, 17 Dec 2000 14:57:35 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200012172057.eBHKvZc23305@gibble.americas.sgi.com>
Subject: TAKE - 
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Sun Dec 17 12:57:13 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-test12

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80888a
linux/fs/xfs/linux/xfs_iops.c - 1.83
linux/include/linux/page_buf.h - 1.68
	- Missed file in test12 update



From owner-linux-xfs@oss.sgi.com Mon Dec 18 21:31:53 2000
Received:  by oss.sgi.com id <S553800AbQLSFbd>;
	Mon, 18 Dec 2000 21:31:33 -0800
Received: from sgi.SGI.COM ([192.48.153.1]:32074 "EHLO sgi.com")
	by oss.sgi.com with ESMTP id <S553673AbQLSFbG>;
	Mon, 18 Dec 2000 21:31:06 -0800
Received: from sherman.melbourne.sgi.com ([134.14.55.175]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id VAA03221
	for <linux-xfs@oss.sgi.com>; Mon, 18 Dec 2000 21:30:59 -0800 (PST)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id QAA22949;
	Tue, 19 Dec 2000 16:30:10 +1100
Date:   Tue, 19 Dec 2000 16:30:10 +1100
From:   Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200012190530.QAA22949@sherman.melbourne.sgi.com>
Subject: TAKE - Change XFS Makefiles to 2.4.0-test13-prex format
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Change XFS Makefiles to 2.4.0-test13-prex format.

Linus decided to rewrite the Makefiles in 2.4.0-test13-pre1 onwards.
This completely messes up XFS, which does things that no other
filesystem does.  The Makefiles assume that a filesystem is either a
single module or is built into the kernel, XFS has both modules and
builin code.  The build system assumes that every module is to be
installed and that a module is built from a single directory, XFS has
module code in multiple directories, some of which is installed as part
of the xfs.o module, not as free standing modules.

This change changes the 2.4.0-test12 XFS Makefiles to use the new
2.4.0-test13-prex format.  Catch 22, cannot change the Makefiles
without upgrading to test13 Rules.make, cannot upgrade XFS to test13
without changing the XFS Makefiles.  As a workaround, I added
Rules.make.new which is the test13 Rule.make plus XFS specific changes.
The XFS Makefiles include Rules.make.new instead of Rules.make, the
rest of the kernel Makefiles are unchanged.

When XFS is updated to test13, rename Rules.make.new to Rules.make,
edit linux/fs/xfs/Makefile, linux/fs/xfs/linux/Makefile,
linux/fs/xfs/dmapi/Makefile, linux/fs/xfs/support/Makefile to point to
Rules.make instead of Rules.make.new.

Date:  Mon Dec 18 21:18:27 PST 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80970a
linux/Rules.make.new - 1.1
linux/fs/Makefile - 1.24

Change XFS Makefiles to 2.4.0-test13-prex format

Date:  Mon Dec 18 21:20:37 PST 2000
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:80971a
linux/fs/xfs/Makefile - 1.110
linux/fs/xfs/linux/Makefile - 1.32
linux/fs/xfs/dmapi/Makefile - 1.5
linux/fs/xfs/support/Makefile - 1.2


From owner-linux-xfs@oss.sgi.com Tue Dec 19 07:03:36 2000
Received:  by oss.sgi.com id <S553761AbQLSPD0>;
	Tue, 19 Dec 2000 07:03:26 -0800
Received: from relay.dera.gov.uk ([192.5.29.49]:7948 "HELO relay.dera.gov.uk")
	by oss.sgi.com with SMTP id <S553736AbQLSPDA>;
	Tue, 19 Dec 2000 07:03:00 -0800
Received: (qmail 31667 invoked from network); 19 Dec 2000 15:02:58 +0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by relay.dera.gov.uk with SMTP; 19 Dec 2000 15:02:58 +0000
Content-Length: 2191
Message-ID: <XFMail.20001219150257.gale@syntax.dera.gov.uk>
X-Mailer: XFMail 1.4.4 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3A2E95CD.CB45802F@thebarn.com>
Date:   Tue, 19 Dec 2000 15:02:57 -0000 (GMT)
From:   Tony Gale <gale@syntax.dera.gov.uk>
To:     Russell Cattelan <cattelan@thebarn.com>
Subject: Re: xfs crash bt (was: RE: ADD 804570 - The elevator bug)
Cc:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


Update...

After sorting out the elevator with elvtune, the system is yet to
deadlock with 11 days uptime.

-tony



On 06-Dec-2000 Russell Cattelan wrote:
> Tony Gale wrote:
> 
>> On 06-Dec-2000 Russell Cattelan wrote:
>> >
>> > Well nothing obvious jumps out at me here, other than a possible
>> > deadlock problem.
>> >
>> > Looking at the code related to the backtraces I don't see a
>> > common
>> > lock
>> > that
>> > might be tripping us up.
>> >
>> > In the backtrace; find_inode is that  last  function listed?
>>
>> Well, it's first one listed, but yes.
>>
>> >
>> > We probably need to look at the process table and find out what
>> > is
>> > running and what might be stuck.
>>
>> I believe the two process stuck are expire (from inn) and slocate.
>> Both of these would hit the fs pretty hard.
>>
>> I don't know the code, but could it be a resource starvation
>> problem,
>> such as out of inodes in the vfs?
>>
>> >
>> > continue the system "go"
>> > break it again and do the cpu back traces.
>>
>> Still stuck in the same places (with minor find_inode offset
>> diff).
> 
> This may not be a lock contention problem then, it's possible we
> are
> looping
> on something? waiting for some resource?
> 
> Did you ever turn down the numbers in the elevator?
> 
> Try:
> elvtune -r 1024 <dev>
> elvtune -w 2048 <dev>
> 
>>
>>
>> >
>> > Is is possible to get a serial console hooked up?
>> > I would help a great deal in capturing  kdb output.
>> >
>> >
>>
>> Ok, will do so tomorrow, and then try and force a lockup (it's
>> getting late to be at work here).
>>
>> Thanks
>>
>> -tony
>>
>> ---
>> E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
>> Two wrongs are only the beginning.
>>                 -- Kohn
>>
>> The views expressed above are entirely those of the writer
>> and do not represent the views, policy or understanding of
>> any other person or official body.

---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
Hmmm ... a PINHEAD, during an EARTHQUAKE, encounters an ALL-MIDGET
FIDDLE ORCHESTRA ... ha ... ha ...

The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.

From owner-linux-xfs@oss.sgi.com Tue Dec 19 09:04:36 2000
Received:  by oss.sgi.com id <S553750AbQLSREZ>;
	Tue, 19 Dec 2000 09:04:25 -0800
Received: from tbird.iworld.com ([63.236.72.237]:36881 "EHLO tbird.iworld.com")
	by oss.sgi.com with ESMTP id <S553694AbQLSREL>;
	Tue, 19 Dec 2000 09:04:11 -0800
Received: (from nobody@localhost)
	by tbird.iworld.com (8.10.2/8.10.2) id eBJEY0S00862;
	Tue, 19 Dec 2000 09:34:00 -0500
Date:   Tue, 19 Dec 2000 09:34:00 -0500
Message-Id: <200012191434.eBJEY0S00862@tbird.iworld.com>
X-Authentication-Warning: tbird.iworld.com: nobody set sender to alanc@linuxstart.com using -f
Content-Type: text/plain
Content-Disposition: inline
Mime-Version: 1.0
X-Mailer: MIME-tools 4.103 (Entity 4.115)
From:   alanc <alanc@linuxstart.com>
To:     linux-xfs@oss.sgi.com
Subject: XFS on Linux questions
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,
I was reading the latest XFS on Linux information and I am very interested in the XVM and real time capabilities of XFS. When will this be available in the Linux port?

Thanks,
Alan 

----------------------
Do you do Linux? :) 
Get your FREE @linuxstart.com email address at: http://www.linuxstart.com

From owner-linux-xfs@oss.sgi.com Tue Dec 19 11:25:26 2000
Received:  by oss.sgi.com id <S553816AbQLSTZQ>;
	Tue, 19 Dec 2000 11:25:16 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:51722 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553791AbQLSTZC>; Tue, 19 Dec 2000 11:25:02 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id RAA11112;
	Tue, 19 Dec 2000 17:24:42 -0200
Date:   Tue, 19 Dec 2000 15:31:40 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     Tony Gale l <gale@syntax.dera.gov.uk>, linux-xfs@oss.sgi.com
Subject: Re: xfs crash bt (was: RE: ADD 804570 - The elevator bug)
In-Reply-To: <3A2E95CD.CB45802F@thebarn.com>
Message-ID: <Pine.LNX.4.21.0012191524270.842-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Wed, 6 Dec 2000, Russell Cattelan wrote:

> Tony Gale wrote:
> 
> > On 06-Dec-2000 Russell Cattelan wrote:
> > >
> > > Well nothing obvious jumps out at me here, other than a possible
> > > deadlock problem.
> > >
> > > Looking at the code related to the backtraces I don't see a common
> > > lock
> > > that
> > > might be tripping us up.
> > >
> > > In the backtrace; find_inode is that  last  function listed?
> >
> > Well, it's first one listed, but yes.
> >
> > >
> > > We probably need to look at the process table and find out what is
> > > running and what might be stuck.
> >
> > I believe the two process stuck are expire (from inn) and slocate.
> > Both of these would hit the fs pretty hard.
> >
> > I don't know the code, but could it be a resource starvation problem,
> > such as out of inodes in the vfs?
> >
> > >
> > > continue the system "go"
> > > break it again and do the cpu back traces.
> >
> > Still stuck in the same places (with minor find_inode offset diff).
> 
> This may not be a lock contention problem then, it's possible we are
> looping on something?

It can well be looping at find_inode().

The patch at the end of this message may help us triggering the problem.

Tony, could you apply the attached patch and and see what happens? 

Thanks. 

--- fs/inode.c.orig     Tue Dec 19 17:20:29 2000
+++ fs/inode.c  Tue Dec 19 17:21:25 2000
@@ -556,6 +556,8 @@
        tmp = head;
        for (;;) {
                tmp = tmp->next;
+               if(tmp == tmp->next)
+                       BUG();
                inode = NULL;
                if (tmp == head)
                        break;



From owner-linux-xfs@oss.sgi.com Tue Dec 19 12:16:45 2000
Received:  by oss.sgi.com id <S553802AbQLSUQg>;
	Tue, 19 Dec 2000 12:16:36 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:55630 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553690AbQLSUQS>;
	Tue, 19 Dec 2000 12:16:18 -0800
Received: from rattle.melbourne.sgi.com (rattle.melbourne.sgi.com [134.14.55.145]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA17371
	for <linux-xfs@oss.sgi.com>; Tue, 19 Dec 2000 12:15:28 -0800 (PST)
	mail_from (kenmcd@melbourne.sgi.com)
Received: from localhost (kenmcd@localhost)
	by rattle.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id HAA26247;
	Wed, 20 Dec 2000 07:14:58 +1100 (AEDT)
X-Authentication-Warning: rattle.melbourne.sgi.com: kenmcd owned process doing -bs
Date:   Wed, 20 Dec 2000 07:14:58 +1100
From:   Ken McDonell <kenmcd@melbourne.sgi.com>
Reply-To: kenmcd@sgi.com
To:     alanc <alanc@linuxstart.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS on Linux questions
In-Reply-To: <200012191434.eBJEY0S00862@tbird.iworld.com>
Message-ID: <Pine.SGI.4.21.0012200708040.3416108-100000@rattle.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 19 Dec 2000, alanc wrote:

> Hi,
> I was reading the latest XFS on Linux information and I am very
> interested in the XVM and real time capabilities of XFS. When will this
> be available in the Linux port?

XVM porting to Linux is underway as part of the CXFS effort, but at
this stage there is no intention to open source either XVM or CXFS.

We have no immediate plans to add real time features (and more
importantly the guaranteed rate I/O, aka GRIO, capabilities) to the
open source version of XFS.  This is a matter of available resources
and priorities within SGI, so offers of external assistance may be
helpful.


From owner-linux-xfs@oss.sgi.com Tue Dec 19 12:50:36 2000
Received:  by oss.sgi.com id <S553822AbQLSUu0>;
	Tue, 19 Dec 2000 12:50:26 -0800
Received: from [212.247.11.130] ([212.247.11.130]:27121 "EHLO
        server.poldata.net") by oss.sgi.com with ESMTP id <S553807AbQLSUuB>;
	Tue, 19 Dec 2000 12:50:01 -0800
Received: from micke ([192.168.3.1])
	by server.poldata.net (8.11.0/8.11.0) with SMTP id eBJLu5916762
	for <linux-xfs@oss.sgi.com>; Tue, 19 Dec 2000 22:56:05 +0100
Message-ID: <001a01c069fd$e8a9ac10$4b00000a@micke>
From:   "Michael Jonsson" <micke@poldata.net>
To:     <linux-xfs@oss.sgi.com>
Subject: xfs patching ?????
Date:   Tue, 19 Dec 2000 21:54:40 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0017_01C06A06.49F3B3F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C06A06.49F3B3F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


then i try to patch the linux kernel i get this errer..... (the linux =
system I have is a RedHat 7.0)


*************************************************************************=
************************
[root@server linux]# patch -p1 < 11272000XFSBETA-4.patch
patching..................................................
patching file cmd/xfs/tools/README
patching file cmd/xfs/tools/auto-qa
patching file cmd/xfs/tools/fixcopyright
patching file cmd/xfs/tools/hunt-gpl
patching file cmd/xfs/tools/srcdiff
patching file cmd/xfs/tools/srctest
can't find file to patch at input line 288641
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rNu linux-2.4-test5/linux/Documentation/00-INDEX =
beta2.4/linux/Documentat
ion/00-INDEX
|--- linux-2.4-test5/linux/Documentation/00-INDEX       Tue Feb  8 =
13:28:31 2000
|+++ beta2.4/linux/Documentation/00-INDEX       Thu Jun  8 20:03:55 2000
--------------------------
File to patch:
*************************************************************************=
**************************

Best regard
Bichael Jonsson


------=_NextPart_000_0017_01C06A06.49F3B3F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>then i try to patch the linux kernel i =
get this=20
errer..... (the linux system I have is a RedHat 7.0)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2><BR>************************************************************=
*************************************<BR>[root@server=20
linux]# patch -p1 &lt; 11272000XFSBETA-4.patch</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>patching..................................................</FONT=
></DIV>
<DIV><FONT face=3DArial size=3D2>patching file =
cmd/xfs/tools/README<BR>patching file=20
cmd/xfs/tools/auto-qa<BR>patching file =
cmd/xfs/tools/fixcopyright<BR>patching=20
file cmd/xfs/tools/hunt-gpl<BR>patching file =
cmd/xfs/tools/srcdiff<BR>patching=20
file cmd/xfs/tools/srctest<BR>can't find file to patch at input line=20
288641<BR>Perhaps you used the wrong -p or --strip option?<BR>The text =
leading=20
up to this was:<BR>--------------------------<BR>|diff -rNu=20
linux-2.4-test5/linux/Documentation/00-INDEX=20
beta2.4/linux/Documentat<BR>ion/00-INDEX<BR>|---=20
linux-2.4-test5/linux/Documentation/00-INDEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
Tue Feb&nbsp; 8 13:28:31 2000<BR>|+++=20
beta2.4/linux/Documentation/00-INDEX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Thu=20
Jun&nbsp; 8 20:03:55 2000<BR>--------------------------<BR>File to=20
patch:</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>****************************************************************=
***********************************</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Best regard</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Bichael Jonsson</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0017_01C06A06.49F3B3F0--


From owner-linux-xfs@oss.sgi.com Tue Dec 19 15:03:36 2000
Received:  by oss.sgi.com id <S553824AbQLSXD0>;
	Tue, 19 Dec 2000 15:03:26 -0800
Received: from smtp6.xs4all.nl ([194.109.6.48]:59891 "EHLO smtp6.xs4all.nl")
	by oss.sgi.com with ESMTP id <S553821AbQLSXDF>;
	Tue, 19 Dec 2000 15:03:05 -0800
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp6.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA13330
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 00:03:03 +0100 (CET)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA28422
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 00:03:03 +0100 (CET)
Date:   Wed, 20 Dec 2000 00:03:03 +0100 (CET)
From:   Seth Mos <knuffie@xs4all.nl>
To:     linux-xfs@oss.sgi.com
Subject: XFS and root shell
Message-ID: <Pine.BSI.4.10.10012192358030.27919-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

If I have an ext2 filesystem that can not be mounted on boot time it will
bring up a root shell for system maintenance. How difficult is it to make
XFS do the same.

I booted and older kernel (older style log) did a dirty reboot and the
newer kernel could not mount /home because of the older log style.
Ofcourse xfs_repair nows what to do but i did not notice untill I tried to
log in.

Normally I would get a Emergency shell to check out what is wrong.
What needs to be changed if anyone can give pointers.

Bye
Seth


From owner-linux-xfs@oss.sgi.com Tue Dec 19 15:18:26 2000
Received:  by oss.sgi.com id <S553831AbQLSXSQ>;
	Tue, 19 Dec 2000 15:18:16 -0800
Received: from smtp6.xs4all.nl ([194.109.6.48]:60154 "EHLO smtp6.xs4all.nl")
	by oss.sgi.com with ESMTP id <S553823AbQLSXRz>;
	Tue, 19 Dec 2000 15:17:55 -0800
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp6.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA16609;
	Wed, 20 Dec 2000 00:17:53 +0100 (CET)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA29846;
	Wed, 20 Dec 2000 00:17:53 +0100 (CET)
Date:   Wed, 20 Dec 2000 00:17:52 +0100 (CET)
From:   Seth Mos <knuffie@xs4all.nl>
To:     Michael Jonsson <micke@poldata.net>
cc:     linux-xfs@oss.sgi.com
Subject: Re: xfs patching ?????
In-Reply-To: <001a01c069fd$e8a9ac10$4b00000a@micke>
Message-ID: <Pine.BSI.4.10.10012200012090.27919-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 19 Dec 2000, Michael Jonsson wrote:

> 
> then i try to patch the linux kernel i get this errer..... (the linux system I have is a RedHat 7.0)
> 
> 
> *************************************************************************************************
> [root@server linux]# patch -p1 < 11272000XFSBETA-4.patch
> patching..................................................
> patching file cmd/xfs/tools/README
> patching file cmd/xfs/tools/auto-qa
> patching file cmd/xfs/tools/fixcopyright
> patching file cmd/xfs/tools/hunt-gpl
> patching file cmd/xfs/tools/srcdiff
> patching file cmd/xfs/tools/srctest
> can't find file to patch at input line 288641
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |diff -rNu linux-2.4-test5/linux/Documentation/00-INDEX beta2.4/linux/Documentat
> ion/00-INDEX
> |--- linux-2.4-test5/linux/Documentation/00-INDEX       Tue Feb  8 13:28:31 2000
> |+++ beta2.4/linux/Documentation/00-INDEX       Thu Jun  8 20:03:55 2000
> --------------------------
> File to patch:
> ***************************************************************************************************

I have seen this error before, but have taken the easy way out.
The INDEX file should not be that important but I don't know if the tree
they compare against is fully clean.

I use the cvs update method. (costs more bandwith (about 25MB total)
You can check out the stable cvs tree with

export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs'
cvs login (password cvs)
cvs -z3 checkout linux-2.4-xfs-beta

Put it in a shellscript if you like to update often. (replace checkout
with update)

Bye
Seth


> 
> Best regard
> Bichael Jonsson
> 
> 


From owner-linux-xfs@oss.sgi.com Tue Dec 19 15:21:46 2000
Received:  by oss.sgi.com id <S553833AbQLSXVg>;
	Tue, 19 Dec 2000 15:21:36 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:5387 "EHLO lips.borg.umn.edu")
	by oss.sgi.com with ESMTP id <S553829AbQLSXV3>;
	Tue, 19 Dec 2000 15:21:29 -0800
Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBJNKVw55557;
	Tue, 19 Dec 2000 17:20:41 -0600 (CST)
Message-ID: <3A3FED39.1644E574@thebarn.com>
Date:   Tue, 19 Dec 2000 17:20:25 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Seth Mos <knuffie@xs4all.nl>
CC:     linux-xfs@oss.sgi.com
Subject: Re: XFS and root shell
References: <Pine.BSI.4.10.10012192358030.27919-100000@xs4.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Seth Mos wrote:

XFS either cleanly mounts or it doesn't, if it fails there is no
ok go what the hell go ahead and mount in a dirty state.
With ext2 you can tell it to go ahead and ignore the fact that
the file system isn't clean and mount it up.

The hope in doing that,  files like sh and fsck are probably
not part of what is wrong with the file system and therefore
able to bring up single user.

The best thing to do is grab Thomas Graichen XFS miniroot.
http://innominate.org/~graichen/projects/miniroot/0.6/
One caveat you the system needs to be up to install it.



> Hi,
>
> If I have an ext2 filesystem that can not be mounted on boot time it will
> bring up a root shell for system maintenance. How difficult is it to make
> XFS do the same.
>
> I booted and older kernel (older style log) did a dirty reboot and the
> newer kernel could not mount /home because of the older log style.
> Ofcourse xfs_repair nows what to do but i did not notice untill I tried to
> log in.
>
> Normally I would get a Emergency shell to check out what is wrong.
> What needs to be changed if anyone can give pointers.
>
> Bye
> Seth

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue Dec 19 15:34:56 2000
Received:  by oss.sgi.com id <S553832AbQLSXeq>;
	Tue, 19 Dec 2000 15:34:46 -0800
Received: from smtp6.xs4all.nl ([194.109.6.48]:15810 "EHLO smtp6.xs4all.nl")
	by oss.sgi.com with ESMTP id <S553712AbQLSXe0>;
	Tue, 19 Dec 2000 15:34:26 -0800
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp6.xs4all.nl (8.9.3/8.9.3) with ESMTP id AAA20045;
	Wed, 20 Dec 2000 00:34:25 +0100 (CET)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id AAA01479;
	Wed, 20 Dec 2000 00:34:24 +0100 (CET)
Date:   Wed, 20 Dec 2000 00:34:24 +0100 (CET)
From:   Seth Mos <knuffie@xs4all.nl>
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: XFS and root shell
In-Reply-To: <3A3FED39.1644E574@thebarn.com>
Message-ID: <Pine.BSI.4.10.10012200026330.27919-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Tue, 19 Dec 2000, Russell Cattelan wrote:

> Seth Mos wrote:
> 
> XFS either cleanly mounts or it doesn't, if it fails there is no
> ok go what the hell go ahead and mount in a dirty state.
> With ext2 you can tell it to go ahead and ignore the fact that
> the file system isn't clean and mount it up.

Sorry, that's not what I meant.
What I mean is that if a fs doesn't mount in general that it should go
single user. I DON'T want to _mount_ it dirty.
Just drop me to a shell.

If you make sure that the xfs* commands in /bin instead of /usr/bin.
If you can mount your root fs (al my machines have a 400 MB root fs) you
can repair your xfs partitions. e2fsck is in /bin for the same reason for 
a long time. This fs survives most of the horror that can happen (except
disk failure) because it is fairly static (some mount it ro).

> The hope in doing that,  files like sh and fsck are probably
> not part of what is wrong with the file system and therefore
> able to bring up single user.

You mean you can't effetively detect a not succesful mount except using a
dmesg check?
 
> The best thing to do is grab Thomas Graichen XFS miniroot.
> http://innominate.org/~graichen/projects/miniroot/0.6/
> One caveat you the system needs to be up to install it.
> 

No nothing is wrong for me. Just a question of wondering what can be
perfected.

> > Hi,
> >
> > If I have an ext2 filesystem that can not be mounted on boot time it will
> > bring up a root shell for system maintenance. How difficult is it to make
> > XFS do the same.
> >
> > I booted and older kernel (older style log) did a dirty reboot and the
> > newer kernel could not mount /home because of the older log style.
> > Ofcourse xfs_repair nows what to do but i did not notice untill I tried to
> > log in.
> >
> > Normally I would get a Emergency shell to check out what is wrong.
> > What needs to be changed if anyone can give pointers.
> >
> > Bye
> > Seth
> 
> --
> Russell Cattelan
> cattelan@thebarn.com
> 
> 
> 
> 


From owner-linux-xfs@oss.sgi.com Tue Dec 19 16:17:16 2000
Received:  by oss.sgi.com id <S553849AbQLTAQ4>;
	Tue, 19 Dec 2000 16:16:56 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:15371 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S553841AbQLTAQn>;
	Tue, 19 Dec 2000 16:16:43 -0800
Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBK0Gaw56235;
	Tue, 19 Dec 2000 18:16:37 -0600 (CST)
Message-ID: <3A3FFA5F.10AA0526@thebarn.com>
Date:   Tue, 19 Dec 2000 18:16:31 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
CC:     linux-xfs@oss.sgi.com
Subject: Re: set_buffer_dirty_uptodate
References: <Pine.LNX.4.21.0012172303250.856-100000@freak.distro.conectiva>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Marcelo Tosatti wrote:

> Hi,
>
> I was looking at the pagebuf code while I noted that
> set_buffer_dirty_uptodate (pagebuf/page_buf_io.c:1188) may sleep waiting
> for bdflush to clean some dirty buffers because it calls balance_dirty().
>
> set_buffer_dirty_update is called by functions which are part of the XFS's
> writepage codepath, which basically starts at linvfs_write_full_page
> (xfs/linux/xfs_iops.c).
>
> The issue is that linvfs_write_full_page() is taking a vnode lock before
> going through this codepath, meaning that it can sleep waiting for bdflush
> while holding this lock which seems to be unecessary.
>
> If this "vnode lock" suffers from contention because processes sleep while
> holding it, we can fix it by calling balance_dirty() _after_ we drop the
> vnode lock.
>
> In practice, this vnode lock is a being used concurrently by a lot of
> users?
>
> Thanks!

Sorry I haven't gotten back to you...

I haven't had a chance to look this over, but yes this might be a problem.

Have you been able to demonstrate this problem?


--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue Dec 19 16:21:06 2000
Received:  by oss.sgi.com id <S553862AbQLTAU4>;
	Tue, 19 Dec 2000 16:20:56 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:62986 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553848AbQLTAUs>; Tue, 19 Dec 2000 16:20:48 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id WAA12961;
	Tue, 19 Dec 2000 22:20:40 -0200
Date:   Tue, 19 Dec 2000 20:27:39 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: set_buffer_dirty_uptodate
In-Reply-To: <3A3FFA5F.10AA0526@thebarn.com>
Message-ID: <Pine.LNX.4.21.0012192025160.1324-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Tue, 19 Dec 2000, Russell Cattelan wrote:

> Marcelo Tosatti wrote:
> 
> > Hi,
> >
> > I was looking at the pagebuf code while I noted that
> > set_buffer_dirty_uptodate (pagebuf/page_buf_io.c:1188) may sleep waiting
> > for bdflush to clean some dirty buffers because it calls balance_dirty().
> >
> > set_buffer_dirty_update is called by functions which are part of the XFS's
> > writepage codepath, which basically starts at linvfs_write_full_page
> > (xfs/linux/xfs_iops.c).
> >
> > The issue is that linvfs_write_full_page() is taking a vnode lock before
> > going through this codepath, meaning that it can sleep waiting for bdflush
> > while holding this lock which seems to be unecessary.
> >
> > If this "vnode lock" suffers from contention because processes sleep while
> > holding it, we can fix it by calling balance_dirty() _after_ we drop the
> > vnode lock.
> >
> > In practice, this vnode lock is a being used concurrently by a lot of
> > users?
> >
> > Thanks!
> 
> Sorry I haven't gotten back to you...

No problem.

> I haven't had a chance to look this over, but yes this might be a problem.
> 
> Have you been able to demonstrate this problem?

Nope.

I was just reading XFS code and noticed the potential problem.

Dont you people have lockmeter output's of filesystem benchmarks on the
32p o2k?

That may give us a hint. 


From owner-linux-xfs@oss.sgi.com Tue Dec 19 19:27:28 2000
Received:  by oss.sgi.com id <S553882AbQLTD1S>;
	Tue, 19 Dec 2000 19:27:18 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:32791 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553868AbQLTD0x>;
	Tue, 19 Dec 2000 19:26:53 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA02862
	for <linux-xfs@oss.sgi.com>; Tue, 19 Dec 2000 19:26:03 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA67881
	for linux-xfs@oss.sgi.com; Wed, 20 Dec 2000 14:25:31 +1100 (EST)
Date:   Wed, 20 Dec 2000 14:25:31 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200012200325.OAA67881@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - vop changes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

vop_{read,write,remove,rmdir} are now back to being the
same as on irix. We need this for cxfs.

Modid:  2.4.x-xfs:slinx:81046a
Date:  Tue Dec 19 19:23:53 PST 2000
Workarea:  snort:/home/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/include/xfs_types.h - 1.4
	- add definition of flid_t (empty unless CELL_CAPABLE)

linux/fs/xfs/linux/xfs_behavior.h - 1.2
	- reincarnate some commented out CELL specific code

linux/fs/xfs/linux/xfs_file.c - 1.36
linux/fs/xfs/linux/xfs_iops.c - 1.85
linux/fs/xfs/linux/xfs_lrw.c - 1.68
linux/fs/xfs/linux/xfs_lrw.h - 1.13
linux/fs/xfs/linux/xfs_vnode.h - 1.8
linux/fs/xfs/xfs_vnodeops.c - 1.481
	- put vops back to the same as irix 

linux/fs/xfs/linux/xfs_vfs.h - 1.4
	- add more fields for CELL_CAPABLE

linux/fs/xfs/support/move.h - 1.4
	- extend uio_t

linux/fs/xfs/xfs_types.h - 1.49
	- add definition of flid_t (empty unless CELL_CAPABLE)



From owner-linux-xfs@oss.sgi.com Tue Dec 19 20:31:19 2000
Received:  by oss.sgi.com id <S553886AbQLTEa6>;
	Tue, 19 Dec 2000 20:30:58 -0800
Received: from [64.240.27.5] ([64.240.27.5]:32772 "EHLO dns.tricord.com")
	by oss.sgi.com with ESMTP id <S553883AbQLTEaz>;
	Tue, 19 Dec 2000 20:30:55 -0800
Received: by dns.tricord with Internet Mail Service (5.5.2448.0)
	id <ZFAXYXC5>; Tue, 19 Dec 2000 22:31:41 -0600
Message-ID: <6DEE94132593D41182D200508BDCA59014E5B6@MAIL>
From:   "Lord, Steve" <SLord@tricord.com>
To:     'Seth Mos' <knuffie@xs4all.nl>
Cc:     linux-xfs@oss.sgi.com
Subject: RE: XFS and root shell
Date:   Tue, 19 Dec 2000 22:33:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

If my memory serves me correctly, xfs_repair etc were all in
in the root filesystem on Irix.

If XFS fails to run log recovery at mount time then it is in a
pretty sorry state. There is a mount option not to run recovery,
which will give you a readonly filesystem for the really desperate,
it is quite possible that it will shut itself down if corrupted
metadata is detected during access in this case (and the shutdown
code in linux was not working too well).

If the mount system call is not returning an error code for a
failed XFS mount that sounds like a bug.

Also, ask Martin Peterson at LinuxCare about an xfs aware
version of the LinuxCare rescue disk, that would be a useful
thing to have.

Steve

> -----Original Message-----
> From: Seth Mos [mailto:knuffie@xs4all.nl]
> Sent: Tuesday, December 19, 2000 5:34 PM
> To: Russell Cattelan
> Cc: linux-xfs@oss.sgi.com
> Subject: Re: XFS and root shell
> 
> 
> On Tue, 19 Dec 2000, Russell Cattelan wrote:
> 
> > Seth Mos wrote:
> > 
> > XFS either cleanly mounts or it doesn't, if it fails there is no
> > ok go what the hell go ahead and mount in a dirty state.
> > With ext2 you can tell it to go ahead and ignore the fact that
> > the file system isn't clean and mount it up.
> 
> Sorry, that's not what I meant.
> What I mean is that if a fs doesn't mount in general that it should go
> single user. I DON'T want to _mount_ it dirty.
> Just drop me to a shell.
> 
> If you make sure that the xfs* commands in /bin instead of /usr/bin.
> If you can mount your root fs (al my machines have a 400 MB 
> root fs) you
> can repair your xfs partitions. e2fsck is in /bin for the 
> same reason for 
> a long time. This fs survives most of the horror that can 
> happen (except
> disk failure) because it is fairly static (some mount it ro).
> 
> > The hope in doing that,  files like sh and fsck are probably
> > not part of what is wrong with the file system and therefore
> > able to bring up single user.
> 
> You mean you can't effetively detect a not succesful mount 
> except using a
> dmesg check?
>  
> > The best thing to do is grab Thomas Graichen XFS miniroot.
> > http://innominate.org/~graichen/projects/miniroot/0.6/
> > One caveat you the system needs to be up to install it.
> > 
> 
> No nothing is wrong for me. Just a question of wondering what can be
> perfected.
> 
> > > Hi,
> > >
> > > If I have an ext2 filesystem that can not be mounted on 
> boot time it will
> > > bring up a root shell for system maintenance. How 
> difficult is it to make
> > > XFS do the same.
> > >
> > > I booted and older kernel (older style log) did a dirty 
> reboot and the
> > > newer kernel could not mount /home because of the older log style.
> > > Ofcourse xfs_repair nows what to do but i did not notice 
> untill I tried to
> > > log in.
> > >
> > > Normally I would get a Emergency shell to check out what is wrong.
> > > What needs to be changed if anyone can give pointers.
> > >
> > > Bye
> > > Seth
> > 
> > --
> > Russell Cattelan
> > cattelan@thebarn.com
> > 
> > 
> > 
> > 
> 

From owner-linux-xfs@oss.sgi.com Tue Dec 19 23:27:58 2000
Received:  by oss.sgi.com id <S553692AbQLTH1s>;
	Tue, 19 Dec 2000 23:27:48 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:524 "EHLO lips.borg.umn.edu")
	by oss.sgi.com with ESMTP id <S553651AbQLTH1V>;
	Tue, 19 Dec 2000 23:27:21 -0800
Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBK7RKw59789
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 01:27:20 -0600 (CST)
Message-ID: <3A405F53.8EDE92D3@thebarn.com>
Date:   Wed, 20 Dec 2000 01:27:15 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: None 4k page system fix
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

I cleaned up the fix for the 8k and 16k page systems and checked it into
the tree.

BUT it does not work on test12.

Actually I'm not sure if the fix is at fault or test12.
Since it works on test11 I'm assuming the problem is with test12 itself.

I'm going to leave this broken for the moment and start working on
updating the tree to test13preWHATEVER, to get up past this Makefile
change.

I'll get back to fixing the Alpha  after that.

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Wed Dec 20 01:51:19 2000
Received:  by oss.sgi.com id <S553885AbQLTJu6>;
	Wed, 20 Dec 2000 01:50:58 -0800
Received: from edge.coltex.nl ([194.151.97.115]:61200 "EHLO mail.coltex.nl")
	by oss.sgi.com with ESMTP id <S553668AbQLTJuz>;
	Wed, 20 Dec 2000 01:50:55 -0800
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.10.0/8.9.3) with ESMTP id eBK9olZ12261;
	Wed, 20 Dec 2000 10:50:48 +0100
Message-Id: <4.3.2.7.2.20001220103521.03754d38@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Wed, 20 Dec 2000 10:48:35 +0100
To:     "Lord, Steve" <SLord@tricord.com>
From:   Seth Mos <knuffie@xs4all.nl>
Subject: RE: XFS and root shell
Cc:     linux-xfs@oss.sgi.com
In-Reply-To: <6DEE94132593D41182D200508BDCA59014E5B6@MAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

At 22:33 19-12-2000 -0600, Lord, Steve wrote:
>If my memory serves me correctly, xfs_repair etc were all in
>in the root filesystem on Irix.

They are installed in /usr/bin under linux

from linux-2.4-xfs/cmd/xfs/configure

# Defaults:
ac_help=
ac_default_prefix=/usr/local
# Any additions from configure.in:
ac_default_prefix=/usr

./configure --help

Directory and file names:
   --prefix=PREFIX         install architecture-independent files in PREFIX
                           [/usr]

So does this need to be changed? Two ac_default_prefix is overdone anyways ;-)

>If XFS fails to run log recovery at mount time then it is in a
>pretty sorry state. There is a mount option not to run recovery,
>which will give you a readonly filesystem for the really desperate,
>it is quite possible that it will shut itself down if corrupted
>metadata is detected during access in this case (and the shutdown
>code in linux was not working too well).

I noticed that yes, but in this case there was an old xfs_log on disk fro a 
test-5 kernel and if you then hit the reset button the newer test-11 can 
not mount the older style xfs_log.

So this was not a case of a sorry state ;-)
I did have the luck that /usr was mounted so I could use xfs_repair to fix 
the xfs_log on disk (it seems to know about both types of xfs_log)

This is because my home machine has xfs* commands in /usr/bin
At work they live in /bin these days

>If the mount system call is not returning an error code for a
>failed XFS mount that sounds like a bug.

Yep, no errors to be seen anywhere.
I just didn't had /home/seth anymore !! (/home was not mounted during boot)

>Also, ask Martin Peterson at LinuxCare about an xfs aware
>version of the LinuxCare rescue disk, that would be a useful
>thing to have.

The root fs is ext2 so I always have access to the xfs* commands in general.
A redhat bootdisk with XFS kernel onboard is then probably enough to fix 
the system using the ext2 root fs.


>Steve

<snip>

Bye

--
Seth
Has anybody seen my lightbulb?
I _really_ need some light here.


From owner-linux-xfs@oss.sgi.com Wed Dec 20 13:26:22 2000
Received:  by oss.sgi.com id <S553919AbQLTV0M>;
	Wed, 20 Dec 2000 13:26:12 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:13060 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553661AbQLTV0A>;
	Wed, 20 Dec 2000 13:26:00 -0800
Received: (qmail 26374 invoked from network); 20 Dec 2000 21:25:55 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 20 Dec 2000 21:25:54 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Seth Mos <knuffie@xs4all.nl>
cc:     "Lord, Steve" <SLord@tricord.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS and root shell 
In-reply-to: Your message of "Wed, 20 Dec 2000 10:48:35 BST."
             <4.3.2.7.2.20001220103521.03754d38@pop.xs4all.nl> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 21 Dec 2000 08:25:54 +1100
Message-ID: <2972.977347554@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Wed, 20 Dec 2000 10:48:35 +0100, 
Seth Mos <knuffie@xs4all.nl> wrote:
>At 22:33 19-12-2000 -0600, Lord, Steve wrote:
>>If my memory serves me correctly, xfs_repair etc were all in
>>in the root filesystem on Irix.
>
>They are installed in /usr/bin under linux
>
>from linux-2.4-xfs/cmd/xfs/configure
>
># Defaults:
>ac_help=
>ac_default_prefix=/usr/local
># Any additions from configure.in:
>ac_default_prefix=/usr
>
>./configure --help
>
>Directory and file names:
>   --prefix=PREFIX         install architecture-independent files in PREFIX
>                           [/usr]

--prefix is for architecture-independent files, typically text files.
--exec-prefix is for binaries and run time libraries.  You need to set
--exec-prefix=/, that will move files to /bin, /sbin and /lib.


From owner-linux-xfs@oss.sgi.com Wed Dec 20 14:42:23 2000
Received:  by oss.sgi.com id <S553927AbQLTWmN>;
	Wed, 20 Dec 2000 14:42:13 -0800
Received: from [134.6.25.134] ([134.6.25.134]:4874 "EHLO mke.net")
	by oss.sgi.com with ESMTP id <S553908AbQLTWmC>;
	Wed, 20 Dec 2000 14:42:02 -0800
Received: from pacbell.net (IDENT:jd@localhost [127.0.0.1])
	by mke.net (8.11.1/8.9.3) with ESMTP id eBKEgmX27312
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 06:43:03 -0800
Message-ID: <3A40C567.CCD2666D@pacbell.net>
Date:   Wed, 20 Dec 2000 14:42:47 +0000
From:   "Joseph I. Davida" <jd108@pacbell.net>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: Building latest beta failure
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

	I had enabled dmapi option during configuration.
	If this feature is not ready, perhaps the config
	should grey it out completely?

	Joe

.
.
.
gmake[6]: Entering directory
`/usr/src/linux-2.4-xfs-beta/linux/fs/xfs/linux'
/usr/src/linux-2.4-xfs-beta/linux/scripts/mkdep  -I.. -I../pseudo-inc
-I. qsort.c xfs_aclstubs.c xfs_behavior.c xfs_cred.c xfs_cred.h
xfs_debug.c xfs_dmistubs.c xfs_file.c xfs_file.h xfs_fs_subr.c
xfs_globals.c xfs_griostubs.c xfs_ioctl.c xfs_iops.c xfs_iops.h
xfs_linux.h xfs_locks.c xfs_lrw.c xfs_lrw.h xfs_mount_opt.c xfs_move.c
xfs_random.c xfs_sema.h xfs_super.c xfs_super.h xfs_uaccess.c xfs_uuid.c
xfs_vfs.c xfs_vnode.c > .depend
/usr/src/linux-2.4-xfs-beta/linux/scripts/mkdep  -I.. -I../pseudo-inc
-I. `find .. -follow -name \*.h -print` > .hdepend
gmake[6]: Leaving directory
`/usr/src/linux-2.4-xfs-beta/linux/fs/xfs/linux'
gmake -C dmapi fastdep
gmake: Entering an unknown directory
gmake: *** dmapi: No such file or directory.  Stop.
gmake: Leaving an unknown directory
gmake[5]: *** [_sfdep_dmapi] Error 2
gmake[5]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs'
gmake[4]: *** [fastdep] Error 2
gmake[4]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs'
gmake[3]: *** [_sfdep_xfs] Error 2
gmake[3]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs'
gmake[2]: *** [fastdep] Error 2
gmake[2]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs'
gmake[1]: *** [_sfdep_fs] Error 2
gmake[1]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux'
gmake: *** [dep-files] Error 2

From owner-linux-xfs@oss.sgi.com Wed Dec 20 15:05:32 2000
Received:  by oss.sgi.com id <S553932AbQLTXFM>;
	Wed, 20 Dec 2000 15:05:12 -0800
Received: from Cantor.suse.de ([194.112.123.193]:14608 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553928AbQLTXE5>;
	Wed, 20 Dec 2000 15:04:57 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id C34FD1E367; Thu, 21 Dec 2000 00:04:55 +0100 (MET)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 7A2203E456; Thu, 21 Dec 2000 00:04:55 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id C14732F300; Thu, 21 Dec 2000 00:04:47 +0100 (MET)
Date:   Thu, 21 Dec 2000 00:04:47 +0100
From:   Andi Kleen <ak@suse.de>
To:     "Joseph I. Davida" <jd108@pacbell.net>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: Building latest beta failure
Message-ID: <20001221000447.A22526@gruyere.muc.suse.de>
References: <3A40C567.CCD2666D@pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A40C567.CCD2666D@pacbell.net>; from jd108@pacbell.net on Wed, Dec 20, 2000 at 02:42:47PM +0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Wed, Dec 20, 2000 at 02:42:47PM +0000, Joseph I. Davida wrote:
> 	I had enabled dmapi option during configuration.
> 	If this feature is not ready, perhaps the config
> 	should grey it out completely?

Or the user should use -d when doing a CVS update to grab new directories ? 

-Andi

From owner-linux-xfs@oss.sgi.com Wed Dec 20 15:16:02 2000
Received:  by oss.sgi.com id <S553934AbQLTXPm>;
	Wed, 20 Dec 2000 15:15:42 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:19027 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553930AbQLTXP0>;
	Wed, 20 Dec 2000 15:15:26 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA16348
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 15:14:37 -0800 (PST)
	mail_from (roehrich@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA176238; Wed, 20 Dec 2000 17:14:07 -0600 (CST)
Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.184.30]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA31919; Wed, 20 Dec 2000 17:14:07 -0600 (CST)
Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id RAA66159; Wed, 20 Dec 2000 17:14:48 -0600 (CST)
Message-Id: <200012202314.RAA66159@slobber.americas.sgi.com>
To:     "Joseph I. Davida" <jd108@pacbell.net>
cc:     linux-xfs@oss.sgi.com
Subject: Re: Building latest beta failure 
Date:   Wed, 20 Dec 2000 17:14:48 -0600
From:   Dean Roehrich <roehrich@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


>From:  "Joseph I. Davida" <jd108@pacbell.net>
>	I had enabled dmapi option during configuration.
>	If this feature is not ready, perhaps the config
>	should grey it out completely?

Do you have a DMAPI application?  I've been wondering if I'm the only one who
uses this particular implementation.

It sounds like you need some CVS advice to get the dmapi code into your
tree...  [okay, I see that Andi Kleen recommends using -d with cvs to get new
dirs.]

In the most recent version of our tree the DMAPI code might not build (as of
early this week).  I have a fix to bring it up to the latest VOP changes, but
there's also a new mount-time bug for DMAPI that I wasn't able to isolate
today.  Maybe I'll find it tomorrow.

Dean


>
>	Joe
>
>.
>.
>.
>gmake[6]: Entering directory
>`/usr/src/linux-2.4-xfs-beta/linux/fs/xfs/linux'
>/usr/src/linux-2.4-xfs-beta/linux/scripts/mkdep  -I.. -I../pseudo-inc
>-I. qsort.c xfs_aclstubs.c xfs_behavior.c xfs_cred.c xfs_cred.h
>xfs_debug.c xfs_dmistubs.c xfs_file.c xfs_file.h xfs_fs_subr.c
>xfs_globals.c xfs_griostubs.c xfs_ioctl.c xfs_iops.c xfs_iops.h
>xfs_linux.h xfs_locks.c xfs_lrw.c xfs_lrw.h xfs_mount_opt.c xfs_move.c
>xfs_random.c xfs_sema.h xfs_super.c xfs_super.h xfs_uaccess.c xfs_uuid.c
>xfs_vfs.c xfs_vnode.c > .depend
>/usr/src/linux-2.4-xfs-beta/linux/scripts/mkdep  -I.. -I../pseudo-inc
>-I. `find .. -follow -name \*.h -print` > .hdepend
>gmake[6]: Leaving directory
>`/usr/src/linux-2.4-xfs-beta/linux/fs/xfs/linux'
>gmake -C dmapi fastdep
>gmake: Entering an unknown directory
>gmake: *** dmapi: No such file or directory.  Stop.
>gmake: Leaving an unknown directory
>gmake[5]: *** [_sfdep_dmapi] Error 2
>gmake[5]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs'
>gmake[4]: *** [fastdep] Error 2
>gmake[4]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs'
>gmake[3]: *** [_sfdep_xfs] Error 2
>gmake[3]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs'
>gmake[2]: *** [fastdep] Error 2
>gmake[2]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs'
>gmake[1]: *** [_sfdep_fs] Error 2
>gmake[1]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux'
>gmake: *** [dep-files] Error 2
>

From owner-linux-xfs@oss.sgi.com Wed Dec 20 15:26:43 2000
Received:  by oss.sgi.com id <S553937AbQLTX0d>;
	Wed, 20 Dec 2000 15:26:33 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:57118 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553933AbQLTX0U>; Wed, 20 Dec 2000 15:26:20 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA00056
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 15:34:43 -0800 (PST)
	mail_from (cattelan@thebarn.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA176466; Wed, 20 Dec 2000 17:24:57 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA89705; Wed, 20 Dec 2000 17:24:57 -0600 (CST)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.0/8.10.1) with ESMTP id eBKNOvx21266;
	Wed, 20 Dec 2000 17:24:57 -0600
Message-ID: <3A413FC8.B0F3DABC@thebarn.com>
Date:   Wed, 20 Dec 2000 17:24:56 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-whipme11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Joseph I. Davida" <jd108@pacbell.net>
CC:     linux-xfs@oss.sgi.com
Subject: Re: Building latest beta failure
References: <3A40C567.CCD2666D@pacbell.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"Joseph I. Davida" wrote:

>         I had enabled dmapi option during configuration.
>         If this feature is not ready, perhaps the config
>         should grey it out completely?

Dmapi wasn't ready for the first beta release.
As such the files were not released.

If you want to play with dmapi use the current tree.

Yes the DMAPI option should be grayed out in the beta tree.


>
>
>         Joe
>
> .
> .
> .
> gmake[6]: Entering directory
> `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs/linux'
> /usr/src/linux-2.4-xfs-beta/linux/scripts/mkdep  -I.. -I../pseudo-inc
> -I. qsort.c xfs_aclstubs.c xfs_behavior.c xfs_cred.c xfs_cred.h
> xfs_debug.c xfs_dmistubs.c xfs_file.c xfs_file.h xfs_fs_subr.c
> xfs_globals.c xfs_griostubs.c xfs_ioctl.c xfs_iops.c xfs_iops.h
> xfs_linux.h xfs_locks.c xfs_lrw.c xfs_lrw.h xfs_mount_opt.c xfs_move.c
> xfs_random.c xfs_sema.h xfs_super.c xfs_super.h xfs_uaccess.c xfs_uuid.c
> xfs_vfs.c xfs_vnode.c > .depend
> /usr/src/linux-2.4-xfs-beta/linux/scripts/mkdep  -I.. -I../pseudo-inc
> -I. `find .. -follow -name \*.h -print` > .hdepend
> gmake[6]: Leaving directory
> `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs/linux'
> gmake -C dmapi fastdep
> gmake: Entering an unknown directory
> gmake: *** dmapi: No such file or directory.  Stop.
> gmake: Leaving an unknown directory
> gmake[5]: *** [_sfdep_dmapi] Error 2
> gmake[5]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs'
> gmake[4]: *** [fastdep] Error 2
> gmake[4]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs/xfs'
> gmake[3]: *** [_sfdep_xfs] Error 2
> gmake[3]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs'
> gmake[2]: *** [fastdep] Error 2
> gmake[2]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux/fs'
> gmake[1]: *** [_sfdep_fs] Error 2
> gmake[1]: Leaving directory `/usr/src/linux-2.4-xfs-beta/linux'
> gmake: *** [dep-files] Error 2


From owner-linux-xfs@oss.sgi.com Wed Dec 20 16:04:32 2000
Received:  by oss.sgi.com id <S553660AbQLUAEN>;
	Wed, 20 Dec 2000 16:04:13 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:13929 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553647AbQLUADp>;
	Wed, 20 Dec 2000 16:03:45 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA25260
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 16:02:55 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA176837 for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 18:02:27 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA98728 for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 18:02:27 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eBL02Rm25458
	for linux-xfs@oss.sgi.com; Wed, 20 Dec 2000 18:02:27 -0600
Date:   Wed, 20 Dec 2000 18:02:27 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200012210002.eBL02Rm25458@gibble.americas.sgi.com>
Subject: TAKE - Remove incorrectly places semi colons.
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Tue Dec 19 23:21:07 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-test12

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:81051a
linux/fs/pagebuf/page_buf.c - 1.46
	- Fix for none 4k page systems.


Subject: TAKE - 

Date:  Wed Dec 20 16:01:40 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-test12

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:81093a
linux/fs/xfs/support/sema.h - 1.3
	- Remove ";" from psema and vsema define's 
	  Causing compile errors on XVM



From owner-linux-xfs@oss.sgi.com Wed Dec 20 17:34:53 2000
Received:  by oss.sgi.com id <S553678AbQLUBen>;
	Wed, 20 Dec 2000 17:34:43 -0800
Received: from smtp6.xs4all.nl ([194.109.6.48]:13785 "EHLO smtp6.xs4all.nl")
	by oss.sgi.com with ESMTP id <S553653AbQLUBeU>;
	Wed, 20 Dec 2000 17:34:20 -0800
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp6.xs4all.nl (8.9.3/8.9.3) with ESMTP id CAA06165;
	Thu, 21 Dec 2000 02:34:18 +0100 (CET)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id CAA14956;
	Thu, 21 Dec 2000 02:34:17 +0100 (CET)
Date:   Thu, 21 Dec 2000 02:34:17 +0100 (CET)
From:   Seth Mos <knuffie@xs4all.nl>
To:     Michael Jonsson <micke@poldata.net>
cc:     linux-xfs@oss.sgi.com
Subject: Re: xfs patching ?????
In-Reply-To: <001801c06abd$5968fdb0$4b00000a@micke>
Message-ID: <Pine.BSI.4.10.10012210232110.14450-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Wed, 20 Dec 2000, Michael Jonsson wrote:

> It work's now, thanks...
> When are the xfs moving from the beta to the final edition ?
> /Mike

I don't work for SGI myself so I don't know the exact time table.
Maybe someone from SGI can comment on this?

It looks like most of the bigger errors are out, now the mysteries remain
ofcourse that are not straightforward.

Bye Seth


From owner-linux-xfs@oss.sgi.com Wed Dec 20 19:02:43 2000
Received:  by oss.sgi.com id <S553714AbQLUDCX>;
	Wed, 20 Dec 2000 19:02:23 -0800
Received: from sgi.SGI.COM ([192.48.153.1]:28721 "EHLO sgi.com")
	by oss.sgi.com with ESMTP id <S553698AbQLUDCO>;
	Wed, 20 Dec 2000 19:02:14 -0800
Received: from snort.melbourne.sgi.com ([134.14.55.149]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id TAA07748
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 19:02:12 -0800 (PST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: (from dxm@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA82474
	for linux-xfs@oss.sgi.com; Thu, 21 Dec 2000 14:00:51 +1100 (EST)
Date:   Thu, 21 Dec 2000 14:00:51 +1100 (EST)
From:   Daniel Moore <dxm@snort.melbourne.sgi.com>
Message-Id: <200012210300.OAA82474@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - remove broken m_*devp
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:81142a
Date:  Wed Dec 20 19:00:03 PST 2000
Workarea:  snort:/home/dxm/isms/slinx-xfs
Author:  dxm

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

cmd/xfs/include/xfs_mount.h - 1.5
linux/fs/xfs/xfs_mount.h - 1.123
	- remove broken definitions of m_ddev_targ, m_logdev_targ & m_rtdev_targ


From owner-linux-xfs@oss.sgi.com Wed Dec 20 21:52:04 2000
Received:  by oss.sgi.com id <S553719AbQLUFvp>;
	Wed, 20 Dec 2000 21:51:45 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:49471 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553706AbQLUFv1>; Wed, 20 Dec 2000 21:51:27 -0800
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA08406
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 21:59:50 -0800 (PST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id XAA178311 for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 23:50:10 -0600 (CST)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id XAA67829 for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 23:50:10 -0600 (CST)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.0/8.10.1) id eBL5oAA22812
	for linux-xfs@oss.sgi.com; Wed, 20 Dec 2000 23:50:10 -0600
Date:   Wed, 20 Dec 2000 23:50:10 -0600
From:   Russell Cattelan <cattelan@sgi.com>
Message-Id: <200012210550.eBL5oAA22812@gibble.americas.sgi.com>
Subject: TAKE - 
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Date:  Wed Dec 20 21:48:12 PST 2000
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-test13

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:81162a
linux/drivers/acpi/tables/tbconvrt.c - 1.1
linux/drivers/acpi/tables/tbxfroot.c - 1.1
linux/drivers/acpi/namespace/nsinit.c - 1.1
linux/drivers/acpi/ksyms.c - 1.1
linux/drivers/acpi/include/actbl71.h - 1.1
linux/drivers/video/matrox/matroxfb_g450.c - 1.1
linux/drivers/acpi/include/actbl2.h - 1.1
linux/drivers/acpi/include/actbl1.h - 1.1
linux/drivers/video/matrox/matroxfb_g450.h - 1.1
linux/drivers/acpi/include/aclinux.h - 1.1
linux/drivers/acpi/include/acgcc.h - 1.1
linux/include/asm-alpha/mmu.h - 1.1
linux/include/asm-arm/mmu.h - 1.1
linux/include/asm-i386/mmu.h - 1.1
linux/include/asm-ia64/mmu.h - 1.1
linux/include/asm-m68k/mmu.h - 1.1
linux/include/asm-mips/mmu.h - 1.1
linux/include/asm-mips64/mmu.h - 1.1
linux/include/asm-s390/mmu.h - 1.1
linux/include/asm-sh/mmu.h - 1.1
linux/include/asm-sparc/mmu.h - 1.1
linux/include/asm-sparc64/mmu.h - 1.1
linux/drivers/acpi/cmbatt.c - 1.1
linux/include/linux/shmem_fs.h - 1.1
linux/mm/shmem.c - 1.1
linux/net/x25/Makefile - 1.3
linux/net/wanrouter/Makefile - 1.3
linux/net/unix/Makefile - 1.3
linux/net/sunrpc/Makefile - 1.4
linux/net/sched/Makefile - 1.5
linux/net/rose/Makefile - 1.3
linux/net/packet/Makefile - 1.4
linux/net/netrom/Makefile - 1.3
linux/net/netlink/Makefile - 1.4
linux/net/lapb/Makefile - 1.3
linux/net/irda/irlan/Makefile - 1.4
linux/net/irda/ircomm/Makefile - 1.5
linux/net/irda/compressors/Makefile - 1.4
linux/net/irda/Makefile - 1.6
linux/net/ipx/Makefile - 1.3
linux/net/ipv6/Makefile - 1.4
linux/net/ipv4/Makefile - 1.6
linux/net/ethernet/Makefile - 1.3
linux/net/econet/Makefile - 1.5
linux/net/core/Makefile - 1.5
linux/net/bridge/Makefile - 1.4
linux/net/ax25/Makefile - 1.3
linux/net/appletalk/Makefile - 1.3
linux/net/Makefile - 1.14
linux/net/802/transit/Makefile - 1.3
linux/net/802/Makefile - 1.4
linux/mm/vmscan.c - 1.41
linux/mm/swapfile.c - 1.26
linux/mm/mmap.c - 1.30
linux/mm/filemap.c - 1.60
linux/mm/Makefile - 1.7
linux/lib/Makefile - 1.5
linux/kernel/sysctl.c - 1.35
linux/kernel/softirq.c - 1.7
linux/kernel/ksyms.c - 1.68
linux/kernel/fork.c - 1.25
linux/kernel/exit.c - 1.25
linux/kernel/Makefile - 1.22
linux/ipc/util.c - 1.17
linux/ipc/shm.c - 1.43
linux/ipc/Makefile - 1.3
linux/include/linux/tqueue.h - 1.8
linux/include/linux/swap.h - 1.23
linux/include/linux/sched.h - 1.34
linux/include/linux/pagemap.h - 1.20
linux/include/linux/mm.h - 1.42
linux/include/linux/fs.h - 1.72
linux/include/linux/cdrom.h - 1.16
linux/include/asm-sparc64/processor.h - 1.13
linux/include/asm-sparc/processor.h - 1.10
linux/include/asm-ppc/processor.h - 1.20
linux/include/asm-ppc/mmu.h - 1.6
linux/include/asm-mips/processor.h - 1.12
linux/include/asm-m68k/processor.h - 1.10
linux/include/asm-i386/uaccess.h - 1.8
linux/include/asm-i386/processor.h - 1.21
linux/include/asm-i386/pgtable.h - 1.24
linux/include/asm-i386/mmu_context.h - 1.11
linux/include/asm-i386/desc.h - 1.6
linux/include/asm-arm/processor.h - 1.14
linux/include/asm-alpha/system.h - 1.14
linux/include/asm-alpha/smp.h - 1.13
linux/include/asm-alpha/processor.h - 1.10
linux/include/asm-alpha/mmu_context.h - 1.11
linux/fs/vfat/Makefile - 1.3
linux/fs/umsdos/Makefile - 1.6
linux/fs/ufs/Makefile - 1.4
linux/fs/sysv/Makefile - 1.4
linux/fs/smbfs/Makefile - 1.5
linux/fs/romfs/Makefile - 1.3
linux/fs/qnx4/Makefile - 1.4
linux/fs/proc/Makefile - 1.9
linux/fs/ntfs/fs.c - 1.23
linux/fs/ntfs/Makefile - 1.6
linux/fs/nls/Makefile - 1.6
linux/fs/nfsd/Makefile - 1.4
linux/fs/nfs/Makefile - 1.6
linux/fs/ncpfs/Makefile - 1.3
linux/fs/msdos/Makefile - 1.3
linux/fs/minix/Makefile - 1.5
linux/fs/lockd/svc.c - 1.8
linux/fs/lockd/Makefile - 1.4
linux/fs/isofs/Makefile - 1.5
linux/fs/hpfs/Makefile - 1.4
linux/fs/hfs/Makefile - 1.3
linux/fs/fat/cache.c - 1.8
linux/fs/fat/Makefile - 1.4
linux/fs/ext2/Makefile - 1.4
linux/fs/exec.c - 1.35
linux/fs/devpts/Makefile - 1.3
linux/fs/coda/Makefile - 1.3
linux/fs/buffer.c - 1.48
linux/fs/autofs/Makefile - 1.3
linux/fs/affs/Makefile - 1.3
linux/fs/adfs/Makefile - 1.4
linux/fs/Makefile - 1.25
linux/drivers/video/Makefile - 1.29
linux/drivers/video/Config.in - 1.23
linux/drivers/usb/Makefile - 1.35
linux/drivers/sound/Makefile - 1.25
linux/drivers/scsi/sr_vendor.c - 1.8
linux/drivers/scsi/sr_ioctl.c - 1.14
linux/drivers/scsi/sr.h - 1.6
linux/drivers/scsi/sr.c - 1.22
linux/drivers/scsi/Makefile - 1.22
linux/drivers/sbus/char/Makefile - 1.7
linux/drivers/sbus/audio/dmy.c - 1.6
linux/drivers/sbus/audio/Makefile - 1.4
linux/drivers/sbus/Makefile - 1.4
linux/drivers/pnp/Makefile - 1.9
linux/drivers/pci/Makefile - 1.13
linux/drivers/nubus/Makefile - 1.4
linux/drivers/net/smc9194.c - 1.10
linux/drivers/net/irda/Makefile - 1.11
linux/drivers/net/hamradio/soundmodem/Makefile - 1.3
linux/drivers/net/hamradio/Makefile - 1.7
linux/drivers/net/Makefile - 1.36
linux/drivers/misc/Makefile - 1.10
linux/drivers/macintosh/Makefile - 1.8
linux/drivers/isdn/sc/Makefile - 1.3
linux/drivers/isdn/pcbit/drv.c - 1.9
linux/drivers/isdn/pcbit/Makefile - 1.3
linux/drivers/isdn/isdnloop/Makefile - 1.3
linux/drivers/isdn/isdn_net.c - 1.15
linux/drivers/isdn/icn/Makefile - 1.3
linux/drivers/isdn/hisax/netjet.c - 1.13
linux/drivers/isdn/hisax/isdnl1.c - 1.9
linux/drivers/isdn/hisax/hisax.h - 1.13
linux/drivers/isdn/hisax/foreign.h - 1.3
linux/drivers/isdn/hisax/foreign.c - 1.4
linux/drivers/isdn/hisax/config.c - 1.14
linux/drivers/isdn/hisax/Makefile - 1.7
linux/drivers/isdn/avmb1/capi.c - 1.17
linux/drivers/isdn/avmb1/b1lli.c - 1.3
linux/drivers/isdn/avmb1/b1capi.c - 1.4
linux/drivers/isdn/avmb1/Makefile - 1.10
linux/drivers/isdn/act2000/Makefile - 1.4
linux/drivers/isdn/Makefile - 1.6
linux/drivers/isdn/Config.in - 1.12
linux/drivers/fc4/Makefile - 1.5
linux/drivers/char/mem.c - 1.29
linux/drivers/char/joystick/Makefile - 1.6
linux/drivers/char/ftape/zftape/Makefile - 1.3
linux/drivers/char/ftape/lowlevel/Makefile - 1.3
linux/drivers/char/ftape/compressor/Makefile - 1.3
linux/drivers/char/ftape/Makefile - 1.3
linux/drivers/char/Makefile - 1.38
linux/drivers/cdrom/cdrom.c - 1.26
linux/drivers/cdrom/Makefile - 1.4
linux/drivers/block/paride/Makefile - 1.5
linux/drivers/block/ll_rw_blk.c - 1.56
linux/drivers/block/Makefile - 1.21
linux/drivers/Makefile - 1.20
linux/arch/sparc64/solaris/misc.c - 1.17
linux/arch/sparc64/solaris/Makefile - 1.4
linux/arch/sparc64/prom/Makefile - 1.7
linux/arch/sparc64/mm/Makefile - 1.6
linux/arch/sparc64/math-emu/Makefile - 1.5
linux/arch/sparc64/lib/Makefile - 1.9
linux/arch/sparc64/kernel/sys_sparc32.c - 1.31
linux/arch/sparc64/kernel/Makefile - 1.16
linux/arch/sparc64/Makefile - 1.10
linux/arch/sparc/prom/Makefile - 1.5
linux/arch/sparc/mm/Makefile - 1.8
linux/arch/sparc/math-emu/Makefile - 1.7
linux/arch/sparc/lib/Makefile - 1.10
linux/arch/sparc/kernel/Makefile - 1.13
linux/arch/sparc/Makefile - 1.8
linux/arch/ppc/mm/Makefile - 1.4
linux/arch/ppc/lib/Makefile - 1.5
linux/arch/ppc/kernel/Makefile - 1.17
linux/arch/ppc/amiga/Makefile - 1.5
linux/arch/ppc/Makefile - 1.16
linux/arch/ppc/8xx_io/Makefile - 1.4
linux/arch/i386/mm/Makefile - 1.5
linux/arch/i386/math-emu/Makefile - 1.5
linux/arch/i386/lib/Makefile - 1.13
linux/arch/i386/kernel/process.c - 1.28
linux/arch/i386/kernel/ldt.c - 1.6
linux/arch/i386/kernel/Makefile - 1.20
linux/arch/i386/config.in - 1.52
linux/arch/i386/Makefile - 1.20
linux/arch/alpha/mm/fault.c - 1.12
linux/arch/alpha/kernel/smp.c - 1.19
linux/arch/alpha/kernel/Makefile - 1.15
linux/Rules.make - 1.11
linux/Makefile - 1.76
linux/Documentation/parport.txt - 1.10
linux/Documentation/Configure.help - 1.67
linux/Documentation/Changes - 1.28
linux/net/decnet/Makefile - 1.6
linux/fs/efs/Makefile - 1.2
linux/drivers/isdn/eicon/Makefile - 1.3
linux/drivers/i2o/Makefile - 1.4
linux/arch/ppc/xmon/Makefile - 1.3
linux/drivers/parport/Makefile - 1.6
linux/net/khttpd/Makefile - 1.3
linux/fs/partitions/Makefile - 1.4
linux/drivers/isdn/hisax/hfc_pci.c - 1.13
linux/drivers/isdn/divert/Makefile - 1.2
linux/drivers/isdn/avmb1/kcapi.c - 1.10
linux/drivers/net/fc/Makefile - 1.3
linux/drivers/atm/Makefile - 1.10
linux/net/atm/Makefile - 1.6
linux/arch/ppc/math-emu/Makefile - 1.2
linux/arch/sparc64/kernel/pci.c - 1.15
linux/include/asm-sh/processor.h - 1.9
linux/drivers/pcmcia/Makefile - 1.7
linux/fs/udf/Makefile - 1.2
linux/drivers/net/pcmcia/Makefile - 1.13
linux/drivers/char/drm/Makefile - 1.6
linux/include/linux/acpi.h - 1.17
linux/drivers/net/wan/Makefile - 1.9
linux/drivers/net/tokenring/Makefile - 1.8
linux/arch/i386/kernel/smpboot.c - 1.19
linux/include/linux/pci_ids.h - 1.30
linux/fs/bfs/Makefile - 1.2
linux/drivers/char/pcmcia/Makefile - 1.3
linux/drivers/net/sk98lin/Makefile - 1.3
linux/include/asm-alpha/pgalloc.h - 1.8
linux/drivers/char/agp/Makefile - 1.4
linux/drivers/i2c/Makefile - 1.4
linux/arch/i386/kernel/acpi.c - 1.21
linux/fs/openpromfs/Makefile - 1.2
linux/fs/cramfs/inflate/Makefile - 1.3
linux/fs/cramfs/Makefile - 1.3
linux/drivers/telephony/Makefile - 1.3
linux/drivers/net/arcnet/Makefile - 1.2
linux/drivers/pnp/quirks.c - 1.6
linux/drivers/ieee1394/Makefile - 1.4
linux/fs/autofs4/Makefile - 1.3
linux/include/asm-ia64/processor.h - 1.7
linux/drivers/isdn/hysdn/Makefile - 1.3
linux/drivers/scsi/pcmcia/Makefile - 1.3
linux/fs/devfs/Makefile - 1.3
linux/drivers/isdn/hysdn/boardergo.c - 1.6
linux/drivers/net/skfp/Makefile - 1.3
linux/drivers/video/matrox/matroxfb_crtc2.c - 1.4
linux/drivers/video/matrox/matroxfb_base.h - 1.4
linux/drivers/video/matrox/matroxfb_base.c - 1.7
linux/drivers/video/matrox/matroxfb_DAC1064.h - 1.3
linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.4
linux/drivers/video/matrox/Makefile - 1.3
linux/drivers/net/tulip/Makefile - 1.2
linux/include/asm-mips64/processor.h - 1.7
linux/drivers/video/riva/Makefile - 1.2
linux/drivers/net/appletalk/Makefile - 1.3
linux/drivers/usb/serial/Makefile - 1.12
linux/drivers/ide/ide-cd.h - 1.5
linux/drivers/ide/ide-cd.c - 1.8
linux/drivers/ide/Makefile - 1.8
linux/net/ipv4/netfilter/Makefile - 1.5
linux/drivers/sound/dmasound/Makefile - 1.2
linux/fs/ramfs/Makefile - 1.2
linux/drivers/sound/emu10k1/Makefile - 1.3
linux/drivers/net/wan/lmc/Makefile - 1.3
linux/include/linux/nfs_page.h - 1.5
linux/drivers/char/rio/Makefile - 1.2
linux/arch/ppc/8260_io/Makefile - 1.3
linux/include/asm-s390/processor.h - 1.3
linux/net/ipv6/netfilter/Makefile - 1.3
linux/fs/xfs/Makefile - 1.112
linux/fs/xfs/linux/Makefile - 1.33
linux/kdb/Makefile - 1.8
linux/kdb/modules/Makefile - 1.9
linux/arch/i386/kdb/Makefile - 1.8
linux/fs/pagebuf/Makefile - 1.3
linux/fs/xfs/dmapi/Makefile - 1.7
linux/drivers/usb/storage/usb.c - 1.7
linux/drivers/usb/storage/scsiglue.c - 1.7
linux/drivers/usb/storage/Makefile - 1.4
linux/drivers/acpi/tables/tbxface.c - 1.3
linux/drivers/acpi/tables/tbutils.c - 1.3
linux/drivers/acpi/tables/tbtable.c - 1.3
linux/drivers/acpi/tables/tbinstal.c - 1.3
linux/drivers/acpi/tables/tbget.c - 1.3
linux/drivers/acpi/sys.c - 1.3
linux/drivers/acpi/resources/rsxface.c - 1.3
linux/drivers/acpi/resources/rsutils.c - 1.3
linux/drivers/acpi/resources/rsmisc.c - 1.3
linux/drivers/acpi/resources/rsmemory.c - 1.3
linux/drivers/acpi/resources/rslist.c - 1.3
linux/drivers/acpi/resources/rsirq.c - 1.3
linux/drivers/acpi/resources/rsio.c - 1.3
linux/drivers/acpi/resources/rsdump.c - 1.3
linux/drivers/acpi/resources/rscreate.c - 1.3
linux/drivers/acpi/resources/rscalc.c - 1.3
linux/drivers/acpi/resources/rsaddr.c - 1.3
linux/drivers/acpi/parser/psxface.c - 1.3
linux/drivers/acpi/parser/pswalk.c - 1.3
linux/drivers/acpi/parser/psutils.c - 1.3
linux/drivers/acpi/parser/pstree.c - 1.3
linux/drivers/acpi/parser/psscope.c - 1.3
linux/drivers/acpi/parser/psparse.c - 1.3
linux/drivers/acpi/parser/psopcode.c - 1.3
linux/drivers/acpi/parser/psargs.c - 1.3
linux/drivers/acpi/os.c - 1.3
linux/drivers/acpi/namespace/nsxfobj.c - 1.3
linux/drivers/acpi/namespace/nsxfname.c - 1.3
linux/drivers/acpi/namespace/nsutils.c - 1.3
linux/drivers/acpi/namespace/nssearch.c - 1.3
linux/drivers/acpi/namespace/nsobject.c - 1.3
linux/drivers/acpi/namespace/nsnames.c - 1.3
linux/drivers/acpi/namespace/nsload.c - 1.3
linux/fs/jffs/Makefile - 1.3
linux/drivers/acpi/namespace/nseval.c - 1.3
linux/drivers/acpi/namespace/nsalloc.c - 1.3
linux/drivers/acpi/namespace/nsaccess.c - 1.3
linux/drivers/acpi/interpreter/amutils.c - 1.3
linux/drivers/acpi/interpreter/amsystem.c - 1.3
linux/drivers/acpi/interpreter/amstorob.c - 1.3
linux/drivers/acpi/interpreter/amstoren.c - 1.3
linux/drivers/acpi/interpreter/amstore.c - 1.3
linux/drivers/acpi/interpreter/amresop.c - 1.3
linux/drivers/acpi/interpreter/amresolv.c - 1.3
linux/drivers/acpi/interpreter/amresnte.c - 1.3
linux/drivers/acpi/interpreter/amregion.c - 1.3
linux/drivers/acpi/interpreter/amprep.c - 1.3
linux/drivers/acpi/interpreter/amnames.c - 1.3
linux/drivers/acpi/interpreter/ammonad.c - 1.3
linux/drivers/acpi/interpreter/ammisc.c - 1.3
linux/drivers/acpi/interpreter/amfldio.c - 1.3
linux/drivers/acpi/interpreter/amfield.c - 1.3
linux/drivers/acpi/interpreter/amdyadic.c - 1.3
linux/drivers/acpi/interpreter/amcreate.c - 1.3
linux/drivers/acpi/interpreter/amconfig.c - 1.3
linux/drivers/acpi/include/amlcode.h - 1.3
linux/drivers/acpi/include/actypes.h - 1.3
linux/drivers/acpi/include/actbl64.h - 1.3
linux/drivers/acpi/include/actbl32.h - 1.3
linux/drivers/acpi/include/actables.h - 1.3
linux/drivers/acpi/include/acpixf.h - 1.3
linux/drivers/acpi/include/acpiosxf.h - 1.3
linux/drivers/acpi/include/acobject.h - 1.3
linux/drivers/acpi/include/acexcep.h - 1.3
linux/drivers/acpi/include/acenv.h - 1.3
linux/drivers/acpi/hardware/hwxface.c - 1.3
linux/drivers/acpi/hardware/hwregs.c - 1.3
linux/drivers/acpi/hardware/hwgpe.c - 1.3
linux/drivers/acpi/hardware/hwcpu32.c - 1.3
linux/drivers/acpi/hardware/hwacpi.c - 1.3
linux/drivers/acpi/events/evxfregn.c - 1.3
linux/drivers/acpi/events/evxfevnt.c - 1.3
linux/drivers/acpi/events/evxface.c - 1.3
linux/drivers/acpi/events/evsci.c - 1.3
linux/drivers/acpi/events/evrgnini.c - 1.3
linux/drivers/acpi/events/evregion.c - 1.3
linux/drivers/acpi/events/evmisc.c - 1.3
linux/drivers/acpi/events/evevent.c - 1.3
linux/drivers/acpi/ec.c - 1.3
linux/drivers/acpi/driver.h - 1.2
linux/drivers/acpi/driver.c - 1.5
linux/drivers/acpi/dispatcher/dswstate.c - 1.3
linux/drivers/acpi/dispatcher/dswscope.c - 1.3
linux/drivers/acpi/dispatcher/dswload.c - 1.3
linux/drivers/acpi/dispatcher/dswexec.c - 1.3
linux/drivers/acpi/dispatcher/dsutils.c - 1.3
linux/drivers/acpi/dispatcher/dsopcode.c - 1.3
linux/drivers/acpi/dispatcher/dsobject.c - 1.3
linux/drivers/acpi/dispatcher/dsmthdat.c - 1.3
linux/drivers/acpi/dispatcher/dsmethod.c - 1.3
linux/drivers/acpi/cpu.c - 1.3
linux/drivers/acpi/common/cmxface.c - 1.3
linux/drivers/acpi/common/cmutils.c - 1.3
linux/drivers/acpi/common/cmobject.c - 1.3
linux/drivers/acpi/common/cminit.c - 1.3
linux/drivers/acpi/common/cmglobal.c - 1.3
linux/drivers/acpi/common/cmeval.c - 1.3
linux/drivers/acpi/common/cmdelete.c - 1.3
linux/drivers/acpi/common/cmdebug.c - 1.3
linux/drivers/acpi/common/cmcopy.c - 1.3
linux/drivers/acpi/common/cmalloc.c - 1.3
linux/drivers/acpi/Makefile - 1.3
linux/drivers/mtd/Makefile - 1.5
linux/drivers/mtd/docprobe.c - 1.4
linux/drivers/mtd/mtdblock.c - 1.3
linux/drivers/mtd/mtdchar.c - 1.3
linux/include/linux/mtd/map.h - 1.4
linux/include/linux/mtd/mtd.h - 1.3
linux/drivers/media/video/Makefile - 1.3
linux/drivers/media/radio/Makefile - 1.3
linux/drivers/media/Makefile - 1.2
linux/drivers/isdn/hisax/l3ni1.c - 1.3
linux/drivers/input/Makefile - 1.2
linux/kdb/ChangeLog - 1.5
linux/drivers/md/raid5.c - 1.5
linux/arch/i386/kernel/bluesmoke.c - 1.5
linux/drivers/acpi/common/Makefile - 1.2
linux/drivers/acpi/common/cmclib.c - 1.2
linux/drivers/acpi/dispatcher/Makefile - 1.2
linux/drivers/acpi/events/Makefile - 1.2
linux/drivers/acpi/hardware/Makefile - 1.2
linux/drivers/acpi/include/accommon.h - 1.2
linux/drivers/acpi/include/acconfig.h - 1.2
linux/drivers/acpi/include/acdebug.h - 1.2
linux/drivers/acpi/include/acdispat.h - 1.2
linux/drivers/acpi/include/acevents.h - 1.2
linux/drivers/acpi/include/acglobal.h - 1.2
linux/drivers/acpi/include/achware.h - 1.2
linux/drivers/acpi/include/acinterp.h - 1.2
linux/drivers/acpi/include/aclocal.h - 1.2
linux/drivers/acpi/include/acmacros.h - 1.2
linux/drivers/acpi/include/acnamesp.h - 1.2
linux/drivers/acpi/include/acoutput.h - 1.2
linux/drivers/acpi/include/acparser.h - 1.2
linux/drivers/acpi/include/actbl.h - 1.2
linux/drivers/acpi/interpreter/Makefile - 1.2
linux/drivers/acpi/interpreter/amdump.c - 1.2
linux/drivers/acpi/namespace/Makefile - 1.2
linux/drivers/acpi/namespace/nsdump.c - 1.2
linux/drivers/acpi/parser/Makefile - 1.2
linux/drivers/acpi/parser/psfind.c - 1.2
linux/drivers/acpi/resources/Makefile - 1.2
linux/drivers/acpi/table.c - 1.2
linux/drivers/acpi/tables/Makefile - 1.2
linux/drivers/md/Makefile - 1.3
linux/fs/xfs/support/Makefile - 1.3
linux/drivers/video/sis/Makefile - 1.2
linux/net/irda/irnet/Makefile - 1.2
linux/drivers/parport/parport_gsc.c - 1.2
linux/include/asm-parisc/mmu.h - 1.2
linux/include/asm-parisc/processor.h - 1.2
linux/arch/i386/kernel/dmi_scan.c - 1.2
linux/drivers/mtd/nftlmount.c - 1.2
linux/Rules.make.new - 1.2
	- Update to test13-pre3, needed to move to new Makefile scheme.



From owner-linux-xfs@oss.sgi.com Wed Dec 20 22:27:54 2000
Received:  by oss.sgi.com id <S553725AbQLUG1e>;
	Wed, 20 Dec 2000 22:27:34 -0800
Received: from [192.117.188.36] ([192.117.188.36]:8196 "HELO mail.tapuz.co.il")
	by oss.sgi.com with SMTP id <S553716AbQLUG1L>;
	Wed, 20 Dec 2000 22:27:11 -0800
Received: from csdc094 ([203.69.58.15]) by mail.tapuz.co.il ; Thu, 21 Dec 2000 08:38:16 +0000
Message-ID: <002601c06b17$03f40f00$5ef1d092@chn.agilent.com>
From:   "kerler" <kerler@newmail.net>
To:     <linux-xfs@oss.sgi.com>
References: <200012210300.OAA82474@snort.melbourne.sgi.com>
Subject: Re: TAKE - remove broken m_*devp
Date:   Thu, 21 Dec 2000 14:25:58 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

The SPECS/kernel-2.4.spec does not include ppc support after
kernel24-2.4.0-XFS_BETA_4.src.rpm is installed using rpm.
how can i use xfs on ppc? and can xfs-cmds-1.0.5-1.src.rpm be used on ppc?

----- Original Message -----
From: Daniel Moore <dxm@snort.melbourne.sgi.com>
To: <linux-xfs@oss.sgi.com>
Sent: Thursday, December 21, 2000 11:00 AM
Subject: TAKE - remove broken m_*devp


> Modid:  2.4.x-xfs:slinx:81142a
> Date:  Wed Dec 20 19:00:03 PST 2000
> Workarea:  snort:/home/dxm/isms/slinx-xfs
> Author:  dxm
>
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
>
> cmd/xfs/include/xfs_mount.h - 1.5
> linux/fs/xfs/xfs_mount.h - 1.123
> - remove broken definitions of m_ddev_targ, m_logdev_targ & m_rtdev_targ
>


From owner-linux-xfs@oss.sgi.com Wed Dec 20 22:50:23 2000
Received:  by oss.sgi.com id <S553734AbQLUGuE>;
	Wed, 20 Dec 2000 22:50:04 -0800
Received: from hermes.mixx.net ([212.84.196.2]:4 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553721AbQLUGtd>;
	Wed, 20 Dec 2000 22:49:33 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 3E954F83F
	for <linux-xfs@oss.sgi.com>; Thu, 21 Dec 2000 07:49:31 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id E43812CA6F; Thu, 21 Dec 2000 07:49:30 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: XFS on PPC (Was: Re: TAKE - remove broken m_*devp)
Date:   21 Dec 2000 06:49:30 GMT
Organization: innominate AG, Berlin, Germany
Lines:  34
Distribution: local
Message-ID: <news2mail-91s95q$suk$1@mate.bln.innominate.de>
References: <200012210300.OAA82474@snort.melbourne.sgi.com> <002601c06b17$03f40f00$5ef1d092@chn.agilent.com>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 977381370 29652 10.0.0.31 (21 Dec 2000 06:49:30 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test11 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

"kerler" <kerler@newmail.net> wrote:
> The SPECS/kernel-2.4.spec does not include ppc support after
> kernel24-2.4.0-XFS_BETA_4.src.rpm is installed using rpm.
> how can i use xfs on ppc? and can xfs-cmds-1.0.5-1.src.rpm be used on ppc?

if you are willing to experiment a bit XFS is useable on ppc quite
good ... the best is to checkout the XFS from SGI and compile a kernel
by hand and try to boot it - it should work on some machines out of
the box (imac etc.) and will most probably not work on others (g4
etc.) - for those there are some ppc related changes missing in the
current linux tree (the normal -testxy tree has the same problem)
... what i did here is mix the pmac-devel and the SGI XFS tree which
resulted in a working XFS kernel on a g4 - so let me know if you
have a machine on which the stock kernel does not work - then i can
send you a diff

also the xfs-cmds-1.0.5-1.src.rpm builds just fine on ppc for me
(SuSE 7.0/ppc) with one little thing: i had to add the definition
of O_DIRECT from include/asm-i386/fcntl.h to /usr/include/bits/fcntl.h
top get it compiled cleanly

some more information about the status of XFS on ppc you may find at

  http://innominate.org/~graichen/projects/xfs/ppc/

good luck

t

-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Wed Dec 20 22:57:53 2000
Received:  by oss.sgi.com id <S553898AbQLUG5d>;
	Wed, 20 Dec 2000 22:57:33 -0800
Received: from nic-31-c12-053.mn.mediaone.net ([24.31.12.53]:62225 "EHLO
        lupo.thebarn.com") by oss.sgi.com with ESMTP id <S553729AbQLUG53>;
	Wed, 20 Dec 2000 22:57:29 -0800
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.1/8.11.0) with ESMTP id eBL6vKk01903;
	Thu, 21 Dec 2000 00:57:20 -0600 (CST)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3A41A9E4.6C55ECCC@thebarn.com>
Date:   Thu, 21 Dec 2000 00:57:41 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     kerler <kerler@newmail.net>
CC:     linux-xfs@oss.sgi.com
Subject: Re: TAKE - remove broken m_*devp
References: <200012210300.OAA82474@snort.melbourne.sgi.com> <002601c06b17$03f40f00$5ef1d092@chn.agilent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

kerler wrote:

> The SPECS/kernel-2.4.spec does not include ppc support after
> kernel24-2.4.0-XFS_BETA_4.src.rpm is installed using rpm.
> how can i use xfs on ppc? and can xfs-cmds-1.0.5-1.src.rpm be used on ppc?

The ppc is not going to be an officially supported platform by SGI.
(at this point only ia32 and in the future ia64 will be supported)
As such the pre packaged rpms may or may not work with other
architectures.

As far as making sure XFS actually works on other platforms, well again
most of development is being done on ia32.
The development team will make every effort to help support XFS on other
architectures.

Your bet bet is to download the source directly from the cvs tree and do the
compilation manually.
(And quite frankly it's a lot easier and less frustrating than mucking with
rpm)


> ----- Original Message -----
> From: Daniel Moore <dxm@snort.melbourne.sgi.com>
> To: <linux-xfs@oss.sgi.com>
> Sent: Thursday, December 21, 2000 11:00 AM
> Subject: TAKE - remove broken m_*devp
>
> > Modid:  2.4.x-xfs:slinx:81142a
> > Date:  Wed Dec 20 19:00:03 PST 2000
> > Workarea:  snort:/home/dxm/isms/slinx-xfs
> > Author:  dxm
> >
> > The following file(s) were checked into:
> >   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
> >
> > cmd/xfs/include/xfs_mount.h - 1.5
> http://gibble.americas.sgi.com/cgi-bin/cvsweb.cgi/slinx_2.4.x-xfs-nodel/> cmd/xfs/include/xfs_mount.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> cmd/xfs/include/xfs_mount.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h
> > linux/fs/xfs/xfs_mount.h - 1.123
> http://gibble.americas.sgi.com/cgi-bin/cvsweb.cgi/slinx_2.4.x-xfs-nodel/> linux/fs/xfs/xfs_mount.h.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/> linux/fs/xfs/xfs_mount.h.diff?r1=text&tr1=1.123&r2=text&tr2=1.122&f=h
> > - remove broken definitions of m_ddev_targ, m_logdev_targ & m_rtdev_targ
> >


From owner-linux-xfs@oss.sgi.com Wed Dec 20 23:32:44 2000
Received:  by oss.sgi.com id <S553663AbQLUHcd>;
	Wed, 20 Dec 2000 23:32:33 -0800
Received: from sgi.SGI.COM ([192.48.153.1]:43125 "EHLO sgi.com")
	by oss.sgi.com with ESMTP id <S553700AbQLUHcO>;
	Wed, 20 Dec 2000 23:32:14 -0800
Received: from sydney.sydney.sgi.com ([134.14.48.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id XAA00192
	for <linux-xfs@oss.sgi.com>; Wed, 20 Dec 2000 23:32:10 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id SAA10878; Thu, 21 Dec 2000 18:30:47 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Russell Cattelan <cattelan@thebarn.com>
cc:     kerler <kerler@newmail.net>, linux-xfs@oss.sgi.com
Subject: Re: TAKE - remove broken m_*devp 
In-reply-to: Your message of "Thu, 21 Dec 2000 00:57:41 MDT."
             <3A41A9E4.6C55ECCC@thebarn.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Thu, 21 Dec 2000 18:30:46 +1100
Message-ID: <6062.977383846@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, 21 Dec 2000 00:57:41 -0600, 
Russell Cattelan <cattelan@thebarn.com> wrote:
>kerler wrote:
>
>> The SPECS/kernel-2.4.spec does not include ppc support after
>> kernel24-2.4.0-XFS_BETA_4.src.rpm is installed using rpm.
>> how can i use xfs on ppc? and can xfs-cmds-1.0.5-1.src.rpm be used on ppc?
>
>Your bet bet is to download the source directly from the cvs tree and do the
>compilation manually.
>(And quite frankly it's a lot easier and less frustrating than mucking with
>rpm)

A word of warning.  XFS has just upgraded to kernel 2.4.0-test13-pre3
with Linus's new Makefile format.  Not all architectures have upgraded
yet, so standard test13-pre3 (and therefore XFS) is not guaranteed to
compile at the moment.  Now is not a good time to try XFS on a new
arch, it would be better to wait until the Makefile changes have died
down.

The following architectures have _not_ converted to the new Makefiles
as of 2.4.0-test13-pre3.

  alpha (only math-emu is a problem)
  arm
  ia64
  m68k
  mips64
  mips
  parisc
  s390
  sh (Hitachi Super-H)

There are also some drivers that are not up to date, drivers/acorn/*,
drivers/s390/*, drivers/sgi/char, drivers/tc and drivers/zorro.  Also
there is no guarantee that the Makefiles that have been changed are
accurate, Linus did a bulk change and people are finding bugs.


From owner-linux-xfs@oss.sgi.com Wed Dec 20 23:44:14 2000
Received:  by oss.sgi.com id <S553906AbQLUHn4>;
	Wed, 20 Dec 2000 23:43:56 -0800
Received: from [192.117.188.36] ([192.117.188.36]:36874 "HELO mail.tapuz.co.il")
	by oss.sgi.com with SMTP id <S553900AbQLUHnk>;
	Wed, 20 Dec 2000 23:43:40 -0800
Received: from csdc094 ([203.69.58.15]) by mail.tapuz.co.il ; Thu, 21 Dec 2000 09:54:45 +0000
Message-ID: <00a301c06b21$b33a5050$5ef1d092@chn.agilent.com>
From:   "kerler" <kerler@newmail.net>
To:     "Thomas Graichen" <graichen@innominate.de>,
        <thomas.graichen@innominate.com>, <linux-xfs@oss.sgi.com>
References: <200012210300.OAA82474@snort.melbourne.sgi.com> <002601c06b17$03f40f00$5ef1d092@chn.agilent.com> <news2mail-91s95q$suk$1@mate.bln.innominate.de>
Subject: Re: XFS on PPC (Was: Re: TAKE - remove broken m_*devp)
Date:   Thu, 21 Dec 2000 15:42:55 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

When i compile the kernel with xfs, it show the following error info.
Shall i use egcs-2.91.66 to compile?

======compile error========
make[1]: Leaving directory
`/opt/lbg/PROJECTs/journal-fs/xfs/linux-2.4.0-test11/
linux'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
scripts/split-include
scripts/split-include.c
scripts/split-include include/linux/autoconf.h include/config
gcc -V
egcs-2.91.66 -D__KERNEL__ -I/opt/lbg/PROJECTs/journal-fs/xfs/linux-2.4.0-
test11/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fom
it-f
rame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-
unin
itialized -mmultiple -mstring   -c -o init/main.o init/main.c
gcc: installation problem, cannot exec `cc1': No such file or directory
cpp: output pipe has been closed
gcc: file path prefix `/usr/lib/gcc-lib/powerpc-linux/egcs-2.91.66/' never
used
make: *** [init/main.o] Error 1
============================

----- Original Message -----
From: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
To: <linux-xfs@oss.sgi.com>
Sent: Thursday, December 21, 2000 2:49 PM
Subject: XFS on PPC (Was: Re: TAKE - remove broken m_*devp)


> "kerler" <kerler@newmail.net> wrote:
> > The SPECS/kernel-2.4.spec does not include ppc support after
> > kernel24-2.4.0-XFS_BETA_4.src.rpm is installed using rpm.
> > how can i use xfs on ppc? and can xfs-cmds-1.0.5-1.src.rpm be used on
ppc?
>
> if you are willing to experiment a bit XFS is useable on ppc quite
> good ... the best is to checkout the XFS from SGI and compile a kernel
> by hand and try to boot it - it should work on some machines out of
> the box (imac etc.) and will most probably not work on others (g4
> etc.) - for those there are some ppc related changes missing in the
> current linux tree (the normal -testxy tree has the same problem)
> ... what i did here is mix the pmac-devel and the SGI XFS tree which
> resulted in a working XFS kernel on a g4 - so let me know if you
> have a machine on which the stock kernel does not work - then i can
> send you a diff
>
> also the xfs-cmds-1.0.5-1.src.rpm builds just fine on ppc for me
> (SuSE 7.0/ppc) with one little thing: i had to add the definition
> of O_DIRECT from include/asm-i386/fcntl.h to /usr/include/bits/fcntl.h
> top get it compiled cleanly
>
> some more information about the status of XFS on ppc you may find at
>
>   http://innominate.org/~graichen/projects/xfs/ppc/
>
> good luck
>
> t
>
> --
> thomas.graichen@innominate.com
> technical director                                       innominate AG
> clustering & security                             the linux architects
> tel: +49-30-308806-13   fax: -77             http://www.innominate.com
>


From owner-linux-xfs@oss.sgi.com Wed Dec 20 23:48:43 2000
Received:  by oss.sgi.com id <S553918AbQLUHsX>;
	Wed, 20 Dec 2000 23:48:23 -0800
Received: from hermes.mixx.net ([212.84.196.2]:22789 "HELO hermes.mixx.net")
	by oss.sgi.com with SMTP id <S553905AbQLUHsK>;
	Wed, 20 Dec 2000 23:48:10 -0800
Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251])
	by hermes.mixx.net (Postfix) with ESMTP id 14F3AF81A
	for <linux-xfs@oss.sgi.com>; Thu, 21 Dec 2000 08:48:08 +0100 (CET)
Received: by mate.bln.innominate.de (Postfix, from userid 9)
	id B585D2CA70; Thu, 21 Dec 2000 08:48:07 +0100 (CET)
From:   Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
Reply-To: Thomas Graichen <graichen@innominate.de>
X-Newsgroups: innominate.list.sgi.xfs
Subject: Re: XFS on PPC
Date:   21 Dec 2000 07:48:07 GMT
Organization: innominate AG, Berlin, Germany
Lines:  86
Distribution: local
Message-ID: <news2mail-91scjn$suk$2@mate.bln.innominate.de>
References: <200012210300.OAA82474@snort.melbourne.sgi.com> <002601c06b17$03f40f00$5ef1d092@chn.agilent.com> <news2mail-91s95q$suk$1@mate.bln.innominate.de> <00a301c06b21$b33a5050$5ef1d092@chn.agilent.com>
Reply-To: thomas.graichen@innominate.com
X-Trace: mate.bln.innominate.de 977384887 29652 10.0.0.31 (21 Dec 2000 07:48:07 GMT)
X-Complaints-To: news@innominate.de
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.0-XFS-test11 (i686))
To:     linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

no it works with 2.95.2 on ppc - simply change the line:

  CC             = $(CROSS_COMPILE)gcc -V egcs-2.91.66

to

  CC             = $(CROSS_COMPILE)gcc

t

"kerler" <kerler@newmail.net> wrote:
> When i compile the kernel with xfs, it show the following error info.
> Shall i use egcs-2.91.66 to compile?

> ======compile error========
> make[1]: Leaving directory
> `/opt/lbg/PROJECTs/journal-fs/xfs/linux-2.4.0-test11/
> linux'
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> scripts/split-include
> scripts/split-include.c
> scripts/split-include include/linux/autoconf.h include/config
> gcc -V
> egcs-2.91.66 -D__KERNEL__ -I/opt/lbg/PROJECTs/journal-fs/xfs/linux-2.4.0-
> test11/linux/include -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fom
> it-f
> rame-pointer -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-
> unin
> itialized -mmultiple -mstring   -c -o init/main.o init/main.c
> gcc: installation problem, cannot exec `cc1': No such file or directory
> cpp: output pipe has been closed
> gcc: file path prefix `/usr/lib/gcc-lib/powerpc-linux/egcs-2.91.66/' never
> used
> make: *** [init/main.o] Error 1
> ============================

> ----- Original Message -----
> From: Thomas Graichen <news-innominate.list.sgi.xfs@innominate.de>
> To: <linux-xfs@oss.sgi.com>
> Sent: Thursday, December 21, 2000 2:49 PM
> Subject: XFS on PPC (Was: Re: TAKE - remove broken m_*devp)


>> "kerler" <kerler@newmail.net> wrote:
>> > The SPECS/kernel-2.4.spec does not include ppc support after
>> > kernel24-2.4.0-XFS_BETA_4.src.rpm is installed using rpm.
>> > how can i use xfs on ppc? and can xfs-cmds-1.0.5-1.src.rpm be used on
> ppc?
>>
>> if you are willing to experiment a bit XFS is useable on ppc quite
>> good ... the best is to checkout the XFS from SGI and compile a kernel
>> by hand and try to boot it - it should work on some machines out of
>> the box (imac etc.) and will most probably not work on others (g4
>> etc.) - for those there are some ppc related changes missing in the
>> current linux tree (the normal -testxy tree has the same problem)
>> ... what i did here is mix the pmac-devel and the SGI XFS tree which
>> resulted in a working XFS kernel on a g4 - so let me know if you
>> have a machine on which the stock kernel does not work - then i can
>> send you a diff
>>
>> also the xfs-cmds-1.0.5-1.src.rpm builds just fine on ppc for me
>> (SuSE 7.0/ppc) with one little thing: i had to add the definition
>> of O_DIRECT from include/asm-i386/fcntl.h to /usr/include/bits/fcntl.h
>> top get it compiled cleanly
>>
>> some more information about the status of XFS on ppc you may find at
>>
>>   http://innominate.org/~graichen/projects/xfs/ppc/
>>
>> good luck
>>
>> t
>>
>> --
>> thomas.graichen@innominate.com
>> technical director                                       innominate AG
>> clustering & security                             the linux architects
>> tel: +49-30-308806-13   fax: -77             http://www.innominate.com
>>


-- 
thomas.graichen@innominate.com
technical director                                       innominate AG
clustering & security                             the linux architects
tel: +49-30-308806-13   fax: -77             http://www.innominate.com

From owner-linux-xfs@oss.sgi.com Sun Dec 24 18:10:08 2000
Received:  by oss.sgi.com id <S553789AbQLYCJs>;
	Sun, 24 Dec 2000 18:09:48 -0800
Received: from femail2.rdc1.on.home.com ([24.2.9.89]:62174 "EHLO
        femail2.rdc1.on.home.com") by oss.sgi.com with ESMTP
	id <S553724AbQLYCJR>; Sun, 24 Dec 2000 18:09:17 -0800
Received: from acm.org ([24.64.181.43]) by femail2.rdc1.on.home.com
          (InterMail vM.4.01.03.00 201-229-121) with ESMTP
          id <20001225020907.WRQX21590.femail2.rdc1.on.home.com@acm.org>
          for <linux-xfs@oss.sgi.com>; Sun, 24 Dec 2000 18:09:07 -0800
Message-ID: <3A46AC5A.F876D7@acm.org>
Date:   Sun, 24 Dec 2000 21:09:30 -0500
From:   Andrew Ho <andrewho@acm.org>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0-XFS-test13-pre3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
Subject: swap file
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Merry Christmas

I create a swap file with xfs_mkfile.

     xfs_mkfile -v 500m /swap/swap1

    "/swap/swap1          swap        swap    defaults      0 0" is in
/etc/fstab.

I try to mount the swap file.

    /sbin/swapon -a /swap/swap1
    swapon: /swap/swap1: Invalid argument

How can I solve this problem.

Andrew Ho



From owner-linux-xfs@oss.sgi.com Sun Dec 24 18:55:08 2000
Received:  by oss.sgi.com id <S553806AbQLYCy6>;
	Sun, 24 Dec 2000 18:54:58 -0800
Received: from Cantor.suse.de ([194.112.123.193]:8205 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553758AbQLYCyr>;
	Sun, 24 Dec 2000 18:54:47 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 574BD1E0E9; Mon, 25 Dec 2000 03:54:46 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 2156D3E46F; Mon, 25 Dec 2000 03:54:46 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 878562F300; Mon, 25 Dec 2000 03:54:45 +0100 (MET)
Date:   Mon, 25 Dec 2000 03:54:45 +0100
From:   Andi Kleen <ak@suse.de>
To:     Andrew Ho <andrewho@acm.org>
Cc:     linux-xfs@oss.sgi.com
Subject: Re: swap file
Message-ID: <20001225035445.A17836@gruyere.muc.suse.de>
References: <3A46AC5A.F876D7@acm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A46AC5A.F876D7@acm.org>; from andrewho@acm.org on Sun, Dec 24, 2000 at 09:09:30PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, Dec 24, 2000 at 09:09:30PM -0500, Andrew Ho wrote:
> Merry Christmas
> 
> I create a swap file with xfs_mkfile.
> 
>      xfs_mkfile -v 500m /swap/swap1
> 
>     "/swap/swap1          swap        swap    defaults      0 0" is in
> /etc/fstab.
> 
> I try to mount the swap file.
> 
>     /sbin/swapon -a /swap/swap1
>     swapon: /swap/swap1: Invalid argument
> 
> How can I solve this problem.

You have to use mkswap on the file first.

-Andi

From owner-linux-xfs@oss.sgi.com Tue Dec 26 14:23:53 2000
Received:  by oss.sgi.com id <S553691AbQLZWXn>;
	Tue, 26 Dec 2000 14:23:43 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:13162 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553687AbQLZWXZ>;
	Tue, 26 Dec 2000 14:23:25 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA17882
	for <linux-xfs@oss.sgi.com>; Tue, 26 Dec 2000 14:22:34 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA28717; Tue, 26 Dec 2000 14:17:59 -0800 (PST)
Message-ID: <3A4919C0.55E6D97E@sgi.com>
Date:   Tue, 26 Dec 2000 14:20:48 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
CC:     linux-xfs@oss.sgi.com
Subject: Re: set_buffer_dirty_uptodate
References: <Pine.LNX.4.21.0012172303250.856-100000@freak.distro.conectiva>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Marcelo Tosatti wrote:
> 
> Hi,
> 
> I was looking at the pagebuf code while I noted that
> set_buffer_dirty_uptodate (pagebuf/page_buf_io.c:1188) may sleep waiting
> for bdflush to clean some dirty buffers because it calls balance_dirty().
> 
> set_buffer_dirty_update is called by functions which are part of the XFS's
> writepage codepath, which basically starts at linvfs_write_full_page
> (xfs/linux/xfs_iops.c).
> 
> The issue is that linvfs_write_full_page() is taking a vnode lock before
> going through this codepath, meaning that it can sleep waiting for bdflush
> while holding this lock which seems to be unecessary.
> 
> If this "vnode lock" suffers from contention because processes sleep while
> holding it, we can fix it by calling balance_dirty() _after_ we drop the
> vnode lock.
> 
> In practice, this vnode lock is a being used concurrently by a lot of
> users?

[ just getting back to mail after a vacation ]

Indeed this is a problem; the patch I've been sending out
pushes the balance_dirty call after all xfs locks have been
dropped. If you haven't seen the patch, I can send it again.

Even with that patch, we have a different issue. All write paths
take the xfs iolock (think of it as a inode lock) before checking
the pagecache for a given page. If the page is not in the pagecache
then it needs to be allocated - see __pagebuf_do_delwri() calls
to grab_cache_page(). This allocation can sleep for bdflush().
However, bdflush can call prune_dcache(), which inturn can wait
for this inode's iolock. I don't have a fix for this problem.

In general, it appears that any filesystem (FS) code that allocates
memory needs to be very careful, since it can wait for bdflush;
the latter, in turn, can do FS related activity that needs FS locks.
Any suggestions?

ananth.


--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue Dec 26 15:34:24 2000
Received:  by oss.sgi.com id <S553702AbQLZXeO>;
	Tue, 26 Dec 2000 15:34:14 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:51471 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553690AbQLZXdz>; Tue, 26 Dec 2000 15:33:55 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id VAA04132;
	Tue, 26 Dec 2000 21:33:23 -0200
Date:   Tue, 26 Dec 2000 19:41:09 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: set_buffer_dirty_uptodate
In-Reply-To: <3A4919C0.55E6D97E@sgi.com>
Message-ID: <Pine.LNX.4.21.0012261924330.872-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Tue, 26 Dec 2000, Rajagopal Ananthanarayanan wrote:

<snip>

> [ just getting back to mail after a vacation ]
> 
> Indeed this is a problem; the patch I've been sending out
> pushes the balance_dirty call after all xfs locks have been
> dropped. If you haven't seen the patch, I can send it again.
> 
> Even with that patch, we have a different issue. All write paths
> take the xfs iolock (think of it as a inode lock) before checking
> the pagecache for a given page. If the page is not in the pagecache
> then it needs to be allocated - see __pagebuf_do_delwri() calls
> to grab_cache_page(). This allocation can sleep for bdflush().
>
> However, bdflush can call prune_dcache(), which inturn can wait for
> this inode's iolock. I don't have a fix for this problem.
> 
> In general, it appears that any filesystem (FS) code that allocates
> memory needs to be very careful, since it can wait for bdflush;
> the latter, in turn, can do FS related activity that needs FS locks.
> Any suggestions?

The correct solution to your problem is to not pass __GFP_IO in the
allocation flag passed to __alloc_pages.

This way the allocation routines will not try to do any kind of IO and
will not wait for kswapd.

Its pretty easy to change page_cache_alloc() to pass our own
allocation flag and fix this problem.

I'm going home soon but I'll do that tomorrow if you're not going to do
it. 


From owner-linux-xfs@oss.sgi.com Tue Dec 26 17:15:15 2000
Received:  by oss.sgi.com id <S553720AbQL0BPG>;
	Tue, 26 Dec 2000 17:15:06 -0800
Received: from smtp6.xs4all.nl ([194.109.6.48]:46844 "EHLO smtp6.xs4all.nl")
	by oss.sgi.com with ESMTP id <S553655AbQL0BOu>;
	Tue, 26 Dec 2000 17:14:50 -0800
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp6.xs4all.nl (8.9.3/8.9.3) with ESMTP id CAA28753
	for <linux-xfs@oss.sgi.com>; Wed, 27 Dec 2000 02:14:49 +0100 (CET)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id CAA25524
	for <linux-xfs@oss.sgi.com>; Wed, 27 Dec 2000 02:14:48 +0100 (CET)
Date:   Wed, 27 Dec 2000 02:14:48 +0100 (CET)
From:   Seth Mos <knuffie@xs4all.nl>
To:     linux-xfs@oss.sgi.com
Subject: CD recording under latest CVS 2.4.0-XFS-test12
Message-ID: <Pine.BSI.4.10.10012270155020.24756-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi,

Has anyone succeeded in burning CDR's under the latest CVS?
Iam trying to figure out if this is also happened to ther people on this
list. If this is a XFS kernel only problem I don't need make a fool of
myself elsewhere ;-)

I know it broke around test8 anyways and under XFS-test8 (according
to the linux24 ToDo list http://linux24.sourceforge.net)

Someone reported it fixed after that, but it is still broken over here.

Following Specs that _work_ under XFS-test5

All scsi
Diamond Fireport 40 (sym53c8xx)
Philips CDD2600 (2x speed writer)
Plextor 32x cdrom

/proc/scsi/sym53c8xx/0 lists the adapter
/proc/scsi/scsi lists both devices

cd's are mountable in both drives.
however cdrecord 1.9 doesn't find the writer with 'cdrecord -scanbus'

cdrecord -scanbus -debug reports FFFFFFFF for every cookie on bus #0 - #15

Kind regards
Seth


From owner-linux-xfs@oss.sgi.com Wed Dec 27 10:41:13 2000
Received:  by oss.sgi.com id <S553750AbQL0SlE>;
	Wed, 27 Dec 2000 10:41:04 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:34832 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553733AbQL0Skt>; Wed, 27 Dec 2000 10:40:49 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id QAA10771;
	Wed, 27 Dec 2000 16:40:28 -0200
Date:   Wed, 27 Dec 2000 14:48:17 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
In-Reply-To: <Pine.LNX.4.21.0012261924330.872-100000@freak.distro.conectiva>
Message-ID: <Pine.LNX.4.21.0012271445500.11471-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing


On Tue, 26 Dec 2000, Marcelo Tosatti wrote:

> The correct solution to your problem is to not pass __GFP_IO in the
> allocation flag passed to __alloc_pages.
> 
> This way the allocation routines will not try to do any kind of IO and
> will not wait for kswapd.
> 
> Its pretty easy to change page_cache_alloc() to pass our own
> allocation flag and fix this problem.
> 
> I'm going home soon but I'll do that tomorrow if you're not going to do
> it. 

So here it goes. 

Ananth, 

Could you try to reproduce the deadlock with this patch applied?

The patch is against latest XFS CVS tree.


Index: linux/fs/nfs/dir.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/fs/nfs/dir.c,v
retrieving revision 1.24
diff -u -r1.24 dir.c
--- linux/fs/nfs/dir.c	2000/12/17 19:15:00	1.24
+++ linux/fs/nfs/dir.c	2000/12/27 18:32:52
@@ -321,7 +321,7 @@
 		desc->page = NULL;
 	}
 
-	page = page_cache_alloc();
+	page = page_cache_alloc(GFP_HIGHUSER);
 	if (!page) {
 		status = -ENOMEM;
 		goto out;
Index: linux/fs/pagebuf/page_buf_io.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/fs/pagebuf/page_buf_io.c,v
retrieving revision 1.37
diff -u -r1.37 page_buf_io.c
--- linux/fs/pagebuf/page_buf_io.c	2000/12/17 19:15:00	1.37
+++ linux/fs/pagebuf/page_buf_io.c	2000/12/27 18:32:56
@@ -1477,8 +1477,9 @@
 		int at_eof;
 		unsigned long offset_in_page;
 
-		page = grab_cache_page(inode->i_mapping,
-				rounded_offset >> PAGE_CACHE_SHIFT);
+		page = _grab_cache_page(inode->i_mapping,
+				rounded_offset >> PAGE_CACHE_SHIFT, 
+				__GFP_WAIT | __GFP_HIGHMEM);
 
 		if (!page) {
 			err = -ENOMEM;
Index: linux/include/linux/pagemap.h
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/include/linux/pagemap.h,v
retrieving revision 1.20
diff -u -r1.20 pagemap.h
--- linux/include/linux/pagemap.h	2000/12/21 05:48:12	1.20
+++ linux/include/linux/pagemap.h	2000/12/27 18:34:25
@@ -29,7 +29,7 @@
 #define PAGE_CACHE_ALIGN(addr)	(((addr)+PAGE_CACHE_SIZE-1)&PAGE_CACHE_MASK)
 
 #define page_cache_get(x)	get_page(x)
-#define page_cache_alloc()	alloc_pages(GFP_HIGHUSER, 0)
+#define page_cache_alloc(flag)	alloc_pages(flag, 0)
 #define page_cache_free(x)	__free_page(x)
 #define page_cache_release(x)	__free_page(x)
 
@@ -120,7 +120,8 @@
 		___wait_on_page(page);
 }
 
-extern struct page * grab_cache_page (struct address_space *, unsigned long);
+#define grab_cache_page(mapping, index) _grab_cache_page(mapping, index, GFP_HIGHUSER)
+extern struct page * _grab_cache_page (struct address_space *, unsigned long, unsigned long);
 
 typedef int filler_t(void *, struct page*);
 
Index: linux/kernel/ksyms.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/kernel/ksyms.c,v
retrieving revision 1.68
diff -u -r1.68 ksyms.c
--- linux/kernel/ksyms.c	2000/12/21 05:48:12	1.68
+++ linux/kernel/ksyms.c	2000/12/27 18:34:51
@@ -262,7 +262,7 @@
 EXPORT_SYMBOL(ROOT_DEV);
 EXPORT_SYMBOL(__find_lock_page);
 EXPORT_SYMBOL(__find_lock_page_nowait);
-EXPORT_SYMBOL(grab_cache_page);
+EXPORT_SYMBOL(_grab_cache_page);
 EXPORT_SYMBOL(read_cache_page);
 EXPORT_SYMBOL(vfs_readlink);
 EXPORT_SYMBOL(vfs_follow_link);
Index: linux/mm/filemap.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/mm/filemap.c,v
retrieving revision 1.60
diff -u -r1.60 filemap.c
--- linux/mm/filemap.c	2000/12/21 05:48:12	1.60
+++ linux/mm/filemap.c	2000/12/27 18:34:53
@@ -460,7 +460,7 @@
 	if (page)
 		return 0;
 
-	page = page_cache_alloc();
+	page = page_cache_alloc(GFP_HIGHUSER);
 	if (!page)
 		return -ENOMEM;
 
@@ -1113,7 +1113,7 @@
 #endif
 		if (!cached_page) {
 			spin_unlock(&pagecache_lock);
-			cached_page = page_cache_alloc();
+			cached_page = page_cache_alloc(GFP_HIGHUSER);
 			if (!cached_page) {
 				desc->error = -ENOMEM;
 				break;
@@ -1413,7 +1413,7 @@
 	 */
 	old_page = page;
 	if (no_share) {
-		struct page *new_page = page_cache_alloc();
+		struct page *new_page = page_cache_alloc(GFP_HIGHUSER);
 
 		if (new_page) {
 			copy_user_highpage(new_page, old_page, address);
@@ -2325,7 +2325,7 @@
 	page = __find_get_page(mapping, index, hash);
 	if (!page) {
 		if (!cached_page) {
-			cached_page = page_cache_alloc();
+			cached_page = page_cache_alloc(GFP_HIGHUSER);
 			if (!cached_page)
 				return ERR_PTR(-ENOMEM);
 		}
@@ -2381,14 +2381,15 @@
 }
 
 static inline struct page * __grab_cache_page(struct address_space *mapping,
-				unsigned long index, struct page **cached_page)
+				unsigned long index, struct page **cached_page,
+				unsigned long flags)
 {
 	struct page *page, **hash = page_hash(mapping, index);
 repeat:
 	page = __find_lock_page(mapping, index, hash);
 	if (!page) {
 		if (!*cached_page) {
-			*cached_page = page_cache_alloc();
+			*cached_page = page_cache_alloc(flags);
 			if (!*cached_page)
 				return NULL;
 		}
@@ -2404,10 +2405,11 @@
  * Returns locked page at given index in given cache, creating it if needed.
  */
 
-struct page *grab_cache_page(struct address_space *mapping, unsigned long index)
+struct page * _grab_cache_page(struct address_space *mapping, unsigned long index, 
+			unsigned long flags)
 {
 	struct page *cached_page = NULL;
-	struct page *page = __grab_cache_page(mapping,index,&cached_page);
+	struct page *page = __grab_cache_page(mapping,index,&cached_page,flags);
 	if (cached_page)
 		page_cache_free(cached_page);
 	return page;
@@ -2512,7 +2514,7 @@
 			bytes = count;
 
 		status = -ENOMEM;	/* we'll assign it later anyway */
-		page = __grab_cache_page(mapping, index, &cached_page);
+		page = __grab_cache_page(mapping, index, &cached_page, GFP_HIGHUSER);
 		if (!page)
 			break;
 
Index: linux/mm/memory.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/mm/memory.c,v
retrieving revision 1.40
diff -u -r1.40 memory.c
--- linux/mm/memory.c	2000/12/17 19:15:00	1.40
+++ linux/mm/memory.c	2000/12/27 18:34:54
@@ -865,7 +865,7 @@
 	 * Ok, we need to copy. Oh, well..
 	 */
 	spin_unlock(&mm->page_table_lock);
-	new_page = page_cache_alloc();
+	new_page = page_cache_alloc(GFP_HIGHUSER);
 	if (!new_page)
 		return -1;
 	spin_lock(&mm->page_table_lock);
Index: linux/mm/shmem.c
===================================================================
RCS file: /cvs/linux-2.4-xfs/linux/mm/shmem.c,v
retrieving revision 1.1
diff -u -r1.1 shmem.c
--- linux/mm/shmem.c	2000/12/21 05:48:12	1.1
+++ linux/mm/shmem.c	2000/12/27 18:34:54
@@ -317,7 +317,7 @@
 		inode->i_sb->u.shmem_sb.free_blocks--;
 		spin_unlock (&inode->i_sb->u.shmem_sb.stat_lock);
 		/* Ok, get a new page */
-		page = page_cache_alloc();
+		page = page_cache_alloc(GFP_HIGHUSER);
 		if (!page)
 			goto oom;
 		clear_user_highpage(page, address);
@@ -332,7 +332,7 @@
 	up(&inode->i_sem);
 
 	if (no_share) {
-		struct page *new_page = page_cache_alloc();
+		struct page *new_page = page_cache_alloc(GFP_HIGHUSER);
 
 		if (new_page) {
 			copy_user_highpage(new_page, page, address);


From owner-linux-xfs@oss.sgi.com Wed Dec 27 12:14:05 2000
Received:  by oss.sgi.com id <S553736AbQL0UN4>;
	Wed, 27 Dec 2000 12:13:56 -0800
Received: from sgi.SGI.COM ([192.48.153.1]:51785 "EHLO sgi.com")
	by oss.sgi.com with ESMTP id <S553661AbQL0UNl>;
	Wed, 27 Dec 2000 12:13:41 -0800
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id MAA01060
	for <linux-xfs@oss.sgi.com>; Wed, 27 Dec 2000 12:13:40 -0800 (PST)
	mail_from (yili@sgi.com)
Received: from mtv-mven006e--n.engr.sgi.com (mtv-mven006e--n.engr.sgi.com [163.154.47.74])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA56839;
	Wed, 27 Dec 2000 12:12:22 -0800 (PST)
Received: by mtv-mven006e--n.engr.sgi.com with Internet Mail Service (5.5.2650.21)
	id <ZJZAVJL5>; Wed, 27 Dec 2000 12:12:18 -0800
Message-ID: <4FAC40499714D31186C60060943F47A902C0C437@mtv-mven006e--n.engr.sgi.com>
From:   Yi Li <yili@sgi.com>
To:     "'Seth Mos'" <knuffie@xs4all.nl>,
        Michael Jonsson <micke@poldata.net>
Cc:     linux-xfs@oss.sgi.com
Subject: RE: comment on XFS release
Date:   Wed, 27 Dec 2000 12:12:16 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hi all - happy holidays!

Haven't seen anyone responding on this one - here's the comment I know of.

XFS requires the 2.4 kernel, which does not have a firm expected
availability date yet. Some may say it could be Jan/Feb. We will release XFS
on Linux asap when 2.4 releases.

Yi

-----Original Message-----
From: Seth Mos [mailto:knuffie@xs4all.nl]
Sent: Wednesday, December 20, 2000 5:34 PM
To: Michael Jonsson
Cc: linux-xfs@oss.sgi.com
Subject: Re: xfs patching ?????


On Wed, 20 Dec 2000, Michael Jonsson wrote:

> It work's now, thanks...
> When are the xfs moving from the beta to the final edition ?
> /Mike

I don't work for SGI myself so I don't know the exact time table.
Maybe someone from SGI can comment on this?

It looks like most of the bigger errors are out, now the mysteries remain
ofcourse that are not straightforward.

Bye Seth

From owner-linux-xfs@oss.sgi.com Thu Dec 28 03:24:01 2000
Received:  by oss.sgi.com id <S553668AbQL1LXv>;
	Thu, 28 Dec 2000 03:23:51 -0800
Received: from tux.mkp.net ([130.225.60.11]:49162 "EHLO tux.mkp.net")
	by oss.sgi.com with ESMTP id <S553660AbQL1LXe>;
	Thu, 28 Dec 2000 03:23:34 -0800
Received: from tux.mkp.net ([130.225.60.11] helo=jaguar.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.14 #2)
	id 14Bb8S-00073k-00; Thu, 28 Dec 2000 12:22:16 +0100
Received: (from mkp@localhost)
	by jaguar.mkp.net (8.9.3/8.9.3) id FAA00698;
	Thu, 28 Dec 2000 05:53:13 -0500
X-Authentication-Warning: jaguar.mkp.net: mkp set sender to mkp@mkp.net using -f
To:     "Lord, Steve" <SLord@tricord.com>
Cc:     "'Seth Mos'" <knuffie@xs4all.nl>, linux-xfs@oss.sgi.com
Subject: Re: XFS and root shell
References: <6DEE94132593D41182D200508BDCA59014E5B6@MAIL>
From:   "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date:   28 Dec 2000 05:53:13 -0500
In-Reply-To: "Lord, Steve"'s message of "Tue, 19 Dec 2000 22:33:19 -0600"
Message-ID: <yq1y9x0akbq.fsf@jaguar.mkp.net>
Lines:  14
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

>>>>> "Steve" == Lord, Steve <SLord@tricord.com> writes:

Steve> Also, ask Martin Peterson at LinuxCare about an xfs aware
Steve> version of the LinuxCare rescue disk, that would be a useful
Steve> thing to have.

Yes, it's indeed on my list of things to do.  I hope to have one ready
in February or so.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Moving Forward.


From owner-linux-xfs@oss.sgi.com Thu Dec 28 11:02:35 2000
Received:  by oss.sgi.com id <S553683AbQL1TCZ>;
	Thu, 28 Dec 2000 11:02:25 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47737 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553655AbQL1TCN>; Thu, 28 Dec 2000 11:02:13 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA00718
	for <linux-xfs@oss.sgi.com>; Thu, 28 Dec 2000 11:10:44 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA30969; Thu, 28 Dec 2000 10:56:41 -0800 (PST)
Message-ID: <3A4B8DB8.35A004CD@sgi.com>
Date:   Thu, 28 Dec 2000 11:00:08 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
CC:     linux-xfs@oss.sgi.com
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
References: <Pine.LNX.4.21.0012271445500.11471-100000@freak.distro.conectiva>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Marcelo Tosatti wrote:
> 
> On Tue, 26 Dec 2000, Marcelo Tosatti wrote:
> 
> > The correct solution to your problem is to not pass __GFP_IO in the
> > allocation flag passed to __alloc_pages.
> >
> > This way the allocation routines will not try to do any kind of IO and
> > will not wait for kswapd.
> >

The problem still happens with the patch, now under a different scenario.
The issue is that _any_ memory allocation under a FS lock can wait for
kswapd ... and kswapd can, in turn, wait for a FS lock while pruning the dcache.
Following is a typical backtrace of  (1) kswapd (2) a process waiting for
memory while trying to copy-in a part of user memory. Obviously, it will
be impossible to fix all these allocations to not have GFP_IO, so an alternate
strategy in __alloc_pages that does not wait for kswapd is one likely solution.
Another possibility is to have a seperate daemon for doing the pruning work.
A third possibility is to let FS's iput return failure when it can't get locks;
thus avoiding kswapd to wait indefinitely.

What do you think?

-----------------
[1]kdb> btp 3
    EBP       EIP         Function(args)
0xc1147e34 0xc0112832 schedule+0x416
                               kernel .text 0xc0100000 0xc011241c 0xc0112a40
           0xc486db0e [xfs_support]lock_wait+0xa6 (0xc1d535f0, 0xc1d53608, 0x0)
                               xfs_support .text 0xc486d060 0xc486da68 0xc486db3c
           0xc486dbac [xfs_support]mraccessf_Rsmp_c4d68361+0x48 (0xc1d535e4, 0x288)
                               xfs_support .text 0xc486d060 0xc486db64 0xc486dbc4
           0xc48ac176 [xfs]xfs_ilock_ra+0x8a (0xc1d53558, 0x8)
                               xfs .text 0xc4873060 0xc48ac0ec 0xc48ac180
           0xc48ac193 [xfs]xfs_ilock+0x13 (0xc48c60d4, 0xc1d53558, 0x8)
                               xfs .text 0xc4873060 0xc48ac180 0xc48ac198
           0xc48c60d4 [xfs]xfs_inactive_free_eofblocks+0xb8 (0xc2f41000, 0xc1d53558)
                               xfs .text 0xc4873060 0xc48c601c 0xc48c62ec
           0xc48c6ad8 [xfs]xfs_inactive+0x110 (0xc1d53570, 0x0)
                               xfs .text 0xc4873060 0xc48c69c8 0xc48c6e48
           0xc48d5558 [xfs]vn_put+0x44 (0xc3547bb4)
                               xfs .text 0xc4873060 0xc48d5514 0xc48d557c
           0xc48d4693 [xfs]linvfs_put_inode+0x17 (0xc3547ac0)
                               xfs .text 0xc4873060 0xc48d467c 0xc48d4698
           0xc014a10b iput+0x2b (0xc3547ac0)
                               kernel .text 0xc0100000 0xc014a0e0 0xc014a250
           0xc014829d prune_dcache+0xb9 (0xd)
[1]more> 
                               kernel .text 0xc0100000 0xc01481e4 0xc0148324
           0xc01485e9 shrink_dcache_memory+0x21 (0x5, 0x4)
                               kernel .text 0xc0100000 0xc01485c8 0xc01485f8
           0xc012d8ca refill_inactive+0xe2 (0x4, 0x0, 0x6, 0x4, 0x6)
                               kernel .text 0xc0100000 0xc012d7e8 0xc012d940
           0xc012d9a2 do_try_to_free_pages+0x62 (0x4, 0x0, 0xc1161fb4)
                               kernel .text 0xc0100000 0xc012d940 0xc012d9c8
           0xc012da56 kswapd+0x8e
                               kernel .text 0xc0100000 0xc012d9c8 0xc012db00
           0xc01074cb kernel_thread+0x23
                               kernel .text 0xc0100000 0xc01074a8 0xc01074d8
------------------

A random process waiting for memory:

------------------
[1]kdb> btp 9759
    EBP       EIP         Function(args)
0xc18c9c74 0xc0112832 schedule+0x416
                               kernel .text 0xc0100000 0xc011241c 0xc0112a40
           0xc012dbbb wakeup_kswapd+0xbb (0x1)
                               kernel .text 0xc0100000 0xc012db00 0xc012dbd8
           0xc012e8ee __alloc_pages+0x246
                               kernel .text 0xc0100000 0xc012e6a8 0xc012e9a0
           0xc012e9b4 __get_free_pages+0x14
                               kernel .text 0xc0100000 0xc012e9a0 0xc012e9c4
           0xc012f0b5 read_swap_cache_async+0x31 (0x1f3f00, 0x1, 0x1f3f00)
                               kernel .text 0xc0100000 0xc012f084 0xc012f120
           0xc0122966 do_swap_page+0x4a (0xc21a4360, 0xc3141960, 0x804b3a0, 0xc23a012c, 0x1f3f00)
                               kernel .text 0xc0100000 0xc012291c 0xc0122a88
           0xc0122d9b handle_mm_fault+0x143 (0xc21a4360, 0xc3141960, 0x804b3a0, 0x0, 0xc18c8000)
                               kernel .text 0xc0100000 0xc0122c58 0xc0122e00
           0xc0111937 do_page_fault+0x14f (0xc18c9df4, 0x0, 0x0, 0x380, 0x804c1a0)
                               kernel .text 0xc0100000 0xc01117e8 0xc0111c00
           0xc01090d8 error_code+0x34
                               kernel .text 0xc0100000 0xc01090a4 0xc01090e0
Interrupt registers:
eax = 0x00000000 ebx = 0x00000000 ecx = 0x00000380 edx = 0x0804c1a0 
esi = 0x0804b3a0 edi = 0xc04dc200 esp = 0xc18c9e28 eip = 0xc01e97dc 
[1]more> 
ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010202 
xds = 0x08040018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc18c9df4
           0xc01e97dc __generic_copy_from_user+0x30 (0xc04dc200, 0x804b3a0, 0xe00)
                               kernel .text 0xc0100000 0xc01e97ac 0xc01e97e8
           0xc4865464 [pagebuf]pagebuf_generic_file_write_Rsmp_1a301b89+0x344 (0xc1f03d80, 0x804b3a0, 0x1000, 0xc18c9f88,
0xc18c9f3c)
                               pagebuf .text 0xc4860060 0xc4865120 0xc486560c
           0xc48d026e [xfs]xfs_rdwr+0x6e (0xc3bd9bd4, 0xc1f03d80, 0x804b3a0, 0x1000, 0xc18c9f88)
                               xfs .text 0xc4873060 0xc48d0200 0xc48d027c
           0xc48d111f [xfs]xfs_write+0x19b (0xc3bd9bd4, 0xc18c9f7c, 0x0, 0x0, 0x0)
                               xfs .text 0xc4873060 0xc48d0f84 0xc48d11f8
           0xc48cd727 [xfs]linvfs_write+0xf3 (0xc1f03d80, 0x804b3a0, 0x1000, 0xc1f03da0)
                               xfs .text 0xc4873060 0xc48cd634 0xc48cd750
           0xc013401a sys_write+0x8e (0xb, 0x804b3a0, 0x1000, 0x38, 0x10c3)
                               kernel .text 0xc0100000 0xc0133f8c 0xc0134050
           0xc0108fa3 system_call+0x33
                               kernel .text 0xc0100000 0xc0108f70 0xc0108fa8
---------------------

ananth.

From owner-linux-xfs@oss.sgi.com Thu Dec 28 12:10:26 2000
Received:  by oss.sgi.com id <S553714AbQL1UKQ>;
	Thu, 28 Dec 2000 12:10:16 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:26641 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553696AbQL1UKH>; Thu, 28 Dec 2000 12:10:07 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id SAA20009;
	Thu, 28 Dec 2000 18:09:48 -0200
Date:   Thu, 28 Dec 2000 16:17:41 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
In-Reply-To: <3A4B8DB8.35A004CD@sgi.com>
Message-ID: <Pine.LNX.4.21.0012281616360.12364-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Thu, 28 Dec 2000, Rajagopal Ananthanarayanan wrote:

> Marcelo Tosatti wrote:
> > 
> > On Tue, 26 Dec 2000, Marcelo Tosatti wrote:
> > 
> > > The correct solution to your problem is to not pass __GFP_IO in the
> > > allocation flag passed to __alloc_pages.
> > >
> > > This way the allocation routines will not try to do any kind of IO and
> > > will not wait for kswapd.
> > >
> 
> The problem still happens with the patch, now under a different scenario.
> The issue is that _any_ memory allocation under a FS lock can wait for
> kswapd ... and kswapd can, in turn, wait for a FS lock while pruning the dcache.
> Following is a typical backtrace of  (1) kswapd (2) a process waiting for
> memory while trying to copy-in a part of user memory. Obviously, it will
> be impossible to fix all these allocations to not have GFP_IO, so an alternate
> strategy in __alloc_pages that does not wait for kswapd is one likely solution.
> Another possibility is to have a seperate daemon for doing the pruning work.
> A third possibility is to let FS's iput return failure when it can't get locks;
> thus avoiding kswapd to wait indefinitely.
> 
> What do you think?

I think the only clean solution for this case is to not hold any FS lock
while we're before calling copy_from_user(). 

Is that too hard to do with current XFS code? 


From owner-linux-xfs@oss.sgi.com Thu Dec 28 12:56:46 2000
Received:  by oss.sgi.com id <S553721AbQL1U40>;
	Thu, 28 Dec 2000 12:56:26 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:17473 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553716AbQL1U4F>;
	Thu, 28 Dec 2000 12:56:05 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA24184
	for <linux-xfs@oss.sgi.com>; Thu, 28 Dec 2000 12:55:14 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA30852; Thu, 28 Dec 2000 12:50:29 -0800 (PST)
Message-ID: <3A4BA83A.41E64D80@sgi.com>
Date:   Thu, 28 Dec 2000 12:53:14 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
CC:     linux-xfs@oss.sgi.com
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
References: <Pine.LNX.4.21.0012281616360.12364-100000@freak.distro.conectiva>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Marcelo Tosatti wrote:
> 

> 
> I think the only clean solution for this case is to not hold any FS lock
> while we're before calling copy_from_user().

Copy from/to user is only one situation. There
are other cases of kmalloc while holding some FS lock.
It will be nearly impossible to weed out those cases from XFS.

IMHO, it is too much of a constraint on the FS to exepect
not to hold any lock while allocating memory. Then there is
that GFP_IO comment in shrink_dcache memory which looks inelegant.
kswapd and/or the memory allocator looks like it can use some improvement.

ananth.

From owner-linux-xfs@oss.sgi.com Thu Dec 28 13:04:27 2000
Received:  by oss.sgi.com id <S553728AbQL1VER>;
	Thu, 28 Dec 2000 13:04:17 -0800
Received: from Cantor.suse.de ([194.112.123.193]:12554 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553719AbQL1VD5>;
	Thu, 28 Dec 2000 13:03:57 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id E0F5B1E271; Thu, 28 Dec 2000 22:03:55 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 281343E450; Thu, 28 Dec 2000 22:03:55 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 035FB2F300; Thu, 28 Dec 2000 22:03:53 +0100 (MET)
Date:   Thu, 28 Dec 2000 22:03:53 +0100
From:   Andi Kleen <ak@suse.de>
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
Cc:     Marcelo Tosatti <marcelo@conectiva.com.br>, linux-xfs@oss.sgi.com,
        andrea@suse.de
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
Message-ID: <20001228220353.A24415@gruyere.muc.suse.de>
References: <Pine.LNX.4.21.0012271445500.11471-100000@freak.distro.conectiva> <3A4B8DB8.35A004CD@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A4B8DB8.35A004CD@sgi.com>; from ananth@sgi.com on Thu, Dec 28, 2000 at 11:00:08AM -0800
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Thu, Dec 28, 2000 at 11:00:08AM -0800, Rajagopal Ananthanarayanan wrote:
> Marcelo Tosatti wrote:
> > 
> > On Tue, 26 Dec 2000, Marcelo Tosatti wrote:
> > 
> > > The correct solution to your problem is to not pass __GFP_IO in the
> > > allocation flag passed to __alloc_pages.
> > >
> > > This way the allocation routines will not try to do any kind of IO and
> > > will not wait for kswapd.
> > >
> 
> The problem still happens with the patch, now under a different scenario.
> The issue is that _any_ memory allocation under a FS lock can wait for
> kswapd ... and kswapd can, in turn, wait for a FS lock while pruning the dcache.
> Following is a typical backtrace of  (1) kswapd (2) a process waiting for
> memory while trying to copy-in a part of user memory. Obviously, it will
> be impossible to fix all these allocations to not have GFP_IO, so an alternate
> strategy in __alloc_pages that does not wait for kswapd is one likely solution.
> Another possibility is to have a seperate daemon for doing the pruning work.

The separate daemon (kiod) has just been removed from 2.2 because it was
broken -- it prevents write throttling for memory hooks, causing spurious
oom conditions. 

Andrea Arcangelli (cc'ed) did that work for 2.2, perhaps he can suggest a good
solution for 2.4/XFS too.


-Andi


> A third possibility is to let FS's iput return failure when it can't get locks;
> thus avoiding kswapd to wait indefinitely.
> 
> What do you think?
> 
> -----------------
> [1]kdb> btp 3
>     EBP       EIP         Function(args)
> 0xc1147e34 0xc0112832 schedule+0x416
>                                kernel .text 0xc0100000 0xc011241c 0xc0112a40
>            0xc486db0e [xfs_support]lock_wait+0xa6 (0xc1d535f0, 0xc1d53608, 0x0)
>                                xfs_support .text 0xc486d060 0xc486da68 0xc486db3c
>            0xc486dbac [xfs_support]mraccessf_Rsmp_c4d68361+0x48 (0xc1d535e4, 0x288)
>                                xfs_support .text 0xc486d060 0xc486db64 0xc486dbc4
>            0xc48ac176 [xfs]xfs_ilock_ra+0x8a (0xc1d53558, 0x8)
>                                xfs .text 0xc4873060 0xc48ac0ec 0xc48ac180
>            0xc48ac193 [xfs]xfs_ilock+0x13 (0xc48c60d4, 0xc1d53558, 0x8)
>                                xfs .text 0xc4873060 0xc48ac180 0xc48ac198
>            0xc48c60d4 [xfs]xfs_inactive_free_eofblocks+0xb8 (0xc2f41000, 0xc1d53558)
>                                xfs .text 0xc4873060 0xc48c601c 0xc48c62ec
>            0xc48c6ad8 [xfs]xfs_inactive+0x110 (0xc1d53570, 0x0)
>                                xfs .text 0xc4873060 0xc48c69c8 0xc48c6e48
>            0xc48d5558 [xfs]vn_put+0x44 (0xc3547bb4)
>                                xfs .text 0xc4873060 0xc48d5514 0xc48d557c
>            0xc48d4693 [xfs]linvfs_put_inode+0x17 (0xc3547ac0)
>                                xfs .text 0xc4873060 0xc48d467c 0xc48d4698
>            0xc014a10b iput+0x2b (0xc3547ac0)
>                                kernel .text 0xc0100000 0xc014a0e0 0xc014a250
>            0xc014829d prune_dcache+0xb9 (0xd)
> [1]more> 
>                                kernel .text 0xc0100000 0xc01481e4 0xc0148324
>            0xc01485e9 shrink_dcache_memory+0x21 (0x5, 0x4)
>                                kernel .text 0xc0100000 0xc01485c8 0xc01485f8
>            0xc012d8ca refill_inactive+0xe2 (0x4, 0x0, 0x6, 0x4, 0x6)
>                                kernel .text 0xc0100000 0xc012d7e8 0xc012d940
>            0xc012d9a2 do_try_to_free_pages+0x62 (0x4, 0x0, 0xc1161fb4)
>                                kernel .text 0xc0100000 0xc012d940 0xc012d9c8
>            0xc012da56 kswapd+0x8e
>                                kernel .text 0xc0100000 0xc012d9c8 0xc012db00
>            0xc01074cb kernel_thread+0x23
>                                kernel .text 0xc0100000 0xc01074a8 0xc01074d8
> ------------------
> 
> A random process waiting for memory:
> 
> ------------------
> [1]kdb> btp 9759
>     EBP       EIP         Function(args)
> 0xc18c9c74 0xc0112832 schedule+0x416
>                                kernel .text 0xc0100000 0xc011241c 0xc0112a40
>            0xc012dbbb wakeup_kswapd+0xbb (0x1)
>                                kernel .text 0xc0100000 0xc012db00 0xc012dbd8
>            0xc012e8ee __alloc_pages+0x246
>                                kernel .text 0xc0100000 0xc012e6a8 0xc012e9a0
>            0xc012e9b4 __get_free_pages+0x14
>                                kernel .text 0xc0100000 0xc012e9a0 0xc012e9c4
>            0xc012f0b5 read_swap_cache_async+0x31 (0x1f3f00, 0x1, 0x1f3f00)
>                                kernel .text 0xc0100000 0xc012f084 0xc012f120
>            0xc0122966 do_swap_page+0x4a (0xc21a4360, 0xc3141960, 0x804b3a0, 0xc23a012c, 0x1f3f00)
>                                kernel .text 0xc0100000 0xc012291c 0xc0122a88
>            0xc0122d9b handle_mm_fault+0x143 (0xc21a4360, 0xc3141960, 0x804b3a0, 0x0, 0xc18c8000)
>                                kernel .text 0xc0100000 0xc0122c58 0xc0122e00
>            0xc0111937 do_page_fault+0x14f (0xc18c9df4, 0x0, 0x0, 0x380, 0x804c1a0)
>                                kernel .text 0xc0100000 0xc01117e8 0xc0111c00
>            0xc01090d8 error_code+0x34
>                                kernel .text 0xc0100000 0xc01090a4 0xc01090e0
> Interrupt registers:
> eax = 0x00000000 ebx = 0x00000000 ecx = 0x00000380 edx = 0x0804c1a0 
> esi = 0x0804b3a0 edi = 0xc04dc200 esp = 0xc18c9e28 eip = 0xc01e97dc 
> [1]more> 
> ebp = 0x00000000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010202 
> xds = 0x08040018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc18c9df4
>            0xc01e97dc __generic_copy_from_user+0x30 (0xc04dc200, 0x804b3a0, 0xe00)
>                                kernel .text 0xc0100000 0xc01e97ac 0xc01e97e8
>            0xc4865464 [pagebuf]pagebuf_generic_file_write_Rsmp_1a301b89+0x344 (0xc1f03d80, 0x804b3a0, 0x1000, 0xc18c9f88,
> 0xc18c9f3c)
>                                pagebuf .text 0xc4860060 0xc4865120 0xc486560c
>            0xc48d026e [xfs]xfs_rdwr+0x6e (0xc3bd9bd4, 0xc1f03d80, 0x804b3a0, 0x1000, 0xc18c9f88)
>                                xfs .text 0xc4873060 0xc48d0200 0xc48d027c
>            0xc48d111f [xfs]xfs_write+0x19b (0xc3bd9bd4, 0xc18c9f7c, 0x0, 0x0, 0x0)
>                                xfs .text 0xc4873060 0xc48d0f84 0xc48d11f8
>            0xc48cd727 [xfs]linvfs_write+0xf3 (0xc1f03d80, 0x804b3a0, 0x1000, 0xc1f03da0)
>                                xfs .text 0xc4873060 0xc48cd634 0xc48cd750
>            0xc013401a sys_write+0x8e (0xb, 0x804b3a0, 0x1000, 0x38, 0x10c3)
>                                kernel .text 0xc0100000 0xc0133f8c 0xc0134050
>            0xc0108fa3 system_call+0x33
>                                kernel .text 0xc0100000 0xc0108f70 0xc0108fa8
> ---------------------
> 
> ananth.

From owner-linux-xfs@oss.sgi.com Fri Dec 29 09:00:26 2000
Received:  by oss.sgi.com id <S553664AbQL2RAQ>;
	Fri, 29 Dec 2000 09:00:16 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:22546 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553652AbQL2Q77>; Fri, 29 Dec 2000 08:59:59 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id OAA27008;
	Fri, 29 Dec 2000 14:59:41 -0200
Date:   Fri, 29 Dec 2000 13:07:37 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Andi Kleen <ak@suse.de>
cc:     Rajagopal Ananthanarayanan <ananth@sgi.com>, linux-xfs@oss.sgi.com,
        andrea@suse.de
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
In-Reply-To: <20001228220353.A24415@gruyere.muc.suse.de>
Message-ID: <Pine.LNX.4.21.0012291301070.13063-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Thu, 28 Dec 2000, Andi Kleen wrote:

> On Thu, Dec 28, 2000 at 11:00:08AM -0800, Rajagopal Ananthanarayanan wrote:
> > Marcelo Tosatti wrote:
> > > 
> > > On Tue, 26 Dec 2000, Marcelo Tosatti wrote:
> > > 
> > > > The correct solution to your problem is to not pass __GFP_IO in the
> > > > allocation flag passed to __alloc_pages.
> > > >
> > > > This way the allocation routines will not try to do any kind of IO and
> > > > will not wait for kswapd.
> > > >
> > 
> > The problem still happens with the patch, now under a different scenario.
> > The issue is that _any_ memory allocation under a FS lock can wait for
> > kswapd ... and kswapd can, in turn, wait for a FS lock while pruning the dcache.
> > Following is a typical backtrace of  (1) kswapd (2) a process waiting for
> > memory while trying to copy-in a part of user memory. Obviously, it will
> > be impossible to fix all these allocations to not have GFP_IO, so an alternate
> > strategy in __alloc_pages that does not wait for kswapd is one likely solution.
> > Another possibility is to have a seperate daemon for doing the pruning work.
> 
> The separate daemon (kiod) has just been removed from 2.2 because it was
> broken -- it prevents write throttling for memory hooks, causing spurious
> oom conditions. 
> 
> Andrea Arcangelli (cc'ed) did that work for 2.2, perhaps he can suggest a good
> solution for 2.4/XFS too.

Indeed.

Basically what Andrea did in 2.2 was to add a "has_io_locks" flag to the
task_struct structure which indicates if the current process has any fs
lock held. (the flag is increased when any fs lock is taken, and decreased
when any fs lock is unlocked)

With this scheme its possible to not sleep on kswapd if we have
"current->has_io_locks" > 0 and avoid the deadlock. 

Ananth, what do you think about this fix? 


From owner-linux-xfs@oss.sgi.com Fri Dec 29 09:45:56 2000
Received:  by oss.sgi.com id <S553669AbQL2Rph>;
	Fri, 29 Dec 2000 09:45:37 -0800
Received: from penguin.e-mind.com ([195.223.140.120]:33620 "EHLO
        penguin.e-mind.com") by oss.sgi.com with ESMTP id <S553665AbQL2RpQ>;
	Fri, 29 Dec 2000 09:45:16 -0800
Received: from black.random ([195.223.140.107])
	by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id TAA06250;
	Fri, 29 Dec 2000 19:51:29 +0100
Received: from athlon.random ([192.168.1.7])
	by black.random (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id eBTHkEV15016;
	Fri, 29 Dec 2000 18:46:14 +0100
Received: (from andrea@localhost)
	by athlon.random (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id eBTHiiT28588;
	Fri, 29 Dec 2000 18:44:44 +0100
Date:   Fri, 29 Dec 2000 18:44:44 +0100
From:   Andrea Arcangeli <andrea@suse.de>
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
Cc:     Andi Kleen <ak@suse.de>,
        Rajagopal Ananthanarayanan <ananth@sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
Message-ID: <20001229184444.H12791@athlon.random>
References: <20001228220353.A24415@gruyere.muc.suse.de> <Pine.LNX.4.21.0012291301070.13063-100000@freak.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0012291301070.13063-100000@freak.distro.conectiva>; from marcelo@conectiva.com.br on Fri, Dec 29, 2000 at 01:07:37PM -0200
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Hello!

On Fri, Dec 29, 2000 at 01:07:37PM -0200, Marcelo Tosatti wrote:
> Basically what Andrea did in 2.2 was to add a "has_io_locks" flag to the
> task_struct structure which indicates if the current process has any fs
> lock held. (the flag is increased when any fs lock is taken, and decreased
> when any fs lock is unlocked)
> 
> With this scheme its possible to not sleep on kswapd if we have
> "current->has_io_locks" > 0 and avoid the deadlock. 

Correct.

However I don't see why somebody is waiting for kswapd in first place ;). I see
kswapd only as a background thing, nothing should need to wait for kswapd to
finish. Every time we can block and we're under a certain min watermark we'd
better do the work ourselfs instead of waiting progress from kswapd (this
has performance advantage since it at first avoids the reschedule overhead).
If we're not under such min watermark but the system is low on memory kswapd
can free some memory in background (in parallel in SMP) and we don't need to
wait its completion either (or we would serialize the work).

Andrea

From owner-linux-xfs@oss.sgi.com Fri Dec 29 09:53:16 2000
Received:  by oss.sgi.com id <S553673AbQL2Rw4>;
	Fri, 29 Dec 2000 09:52:56 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:24594 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553667AbQL2Rwm>; Fri, 29 Dec 2000 09:52:42 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id PAA27303;
	Fri, 29 Dec 2000 15:51:09 -0200
Date:   Fri, 29 Dec 2000 13:59:05 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Andrea Arcangeli <andrea@suse.de>
cc:     Andi Kleen <ak@suse.de>,
        Rajagopal Ananthanarayanan <ananth@sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
In-Reply-To: <20001229184444.H12791@athlon.random>
Message-ID: <Pine.LNX.4.21.0012291358230.13063-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Fri, 29 Dec 2000, Andrea Arcangeli wrote:

> Hello!
> 
> On Fri, Dec 29, 2000 at 01:07:37PM -0200, Marcelo Tosatti wrote:
> > Basically what Andrea did in 2.2 was to add a "has_io_locks" flag to the
> > task_struct structure which indicates if the current process has any fs
> > lock held. (the flag is increased when any fs lock is taken, and decreased
> > when any fs lock is unlocked)
> > 
> > With this scheme its possible to not sleep on kswapd if we have
> > "current->has_io_locks" > 0 and avoid the deadlock. 
> 
> Correct.
> 
> However I don't see why somebody is waiting for kswapd in first place ;). 
  
from mm/page_alloc.c (__alloc_pages function) (2.4): 

                 /*
                 * When we arrive here, we are really tight on memory.
                 *
                 * We wake up kswapd and sleep until kswapd wakes us
                 * up again. After that we loop back to the start.
                 *
                 * We have to do this because something else might eat
                 * the memory kswapd frees for us and we need to be
                 * reliable. Note that we don't loop back for higher
                 * order allocations since it is possible that kswapd
                 * simply cannot free a large enough contiguous area
                 * of memory *ever*.
                 */
                if ((gfp_mask & (__GFP_WAIT|__GFP_IO)) == (__GFP_WAIT|__GFP_IO)) {
                        wakeup_kswapd(1);
                        memory_pressure++;
                        if (!order)
                                goto try_again;



From owner-linux-xfs@oss.sgi.com Fri Dec 29 10:37:15 2000
Received:  by oss.sgi.com id <S553698AbQL2ShF>;
	Fri, 29 Dec 2000 10:37:05 -0800
Received: from penguin.e-mind.com ([195.223.140.120]:21338 "EHLO
        penguin.e-mind.com") by oss.sgi.com with ESMTP id <S553671AbQL2Sgo>;
	Fri, 29 Dec 2000 10:36:44 -0800
Received: from black.random ([195.223.140.107])
	by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id UAA06955;
	Fri, 29 Dec 2000 20:43:16 +0100
Received: from athlon.random ([192.168.1.7])
	by black.random (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id eBTIc1V16000;
	Fri, 29 Dec 2000 19:38:01 +0100
Received: (from andrea@localhost)
	by athlon.random (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id eBTIaa117408;
	Fri, 29 Dec 2000 19:36:36 +0100
Date:   Fri, 29 Dec 2000 19:36:36 +0100
From:   Andrea Arcangeli <andrea@suse.de>
To:     Marcelo Tosatti <marcelo@conectiva.com.br>
Cc:     Andi Kleen <ak@suse.de>,
        Rajagopal Ananthanarayanan <ananth@sgi.com>,
        linux-xfs@oss.sgi.com
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
Message-ID: <20001229193636.A16261@athlon.random>
References: <20001229184444.H12791@athlon.random> <Pine.LNX.4.21.0012291358230.13063-100000@freak.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0012291358230.13063-100000@freak.distro.conectiva>; from marcelo@conectiva.com.br on Fri, Dec 29, 2000 at 01:59:05PM -0200
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Fri, Dec 29, 2000 at 01:59:05PM -0200, Marcelo Tosatti wrote:
>                  * We have to do this because something else might eat
>                  * the memory kswapd frees for us and we need to be
>                  * reliable. Note that we don't loop back for higher

This looks bad design.

Andrea

From owner-linux-xfs@oss.sgi.com Fri Dec 29 10:46:15 2000
Received:  by oss.sgi.com id <S553726AbQL2Sp4>;
	Fri, 29 Dec 2000 10:45:56 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:8558 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S553671AbQL2Spv>; Fri, 29 Dec 2000 10:45:51 -0800
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA06987
	for <linux-xfs@oss.sgi.com>; Fri, 29 Dec 2000 10:54:24 -0800 (PST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA32032; Fri, 29 Dec 2000 10:40:17 -0800 (PST)
Message-ID: <3A4CDB34.1E6DA86E@sgi.com>
Date:   Fri, 29 Dec 2000 10:43:00 -0800
From:   Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-xfs@oss.sgi.com
CC:     andrea@suse.de
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
References: <Pine.LNX.4.21.0012291301070.13063-100000@freak.distro.conectiva>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Marcelo Tosatti wrote:

	[ ... ]
> 
> Basically what Andrea did in 2.2 was to add a "has_io_locks" flag to the
> task_struct structure which indicates if the current process has any fs
> lock held. (the flag is increased when any fs lock is taken, and decreased
> when any fs lock is unlocked)
> 
> With this scheme its possible to not sleep on kswapd if we have
> "current->has_io_locks" > 0 and avoid the deadlock.
> 
> Ananth, what do you think about this fix?

Yes, that'll work ... currently, it is only the
XFS i[o]lock on the inode exhibits this problem.
And it seems to be only getting triggered when
xfs_inactive_free_eofblocks() is called as part
of inode deactivation. So, for starters we can
add this counter increment/decrement to xfs_ilock/xfs_iunlock.

For what it is worth, I tried to trigger the problem
with a smaller amount of memory. Perviously the problem
surfaced after ~7hours of heavy stress on a 2P 64M machine,
running dbench. Running on the same machine, this time
with mem=32M, the same test is still running after ~18hours!
So, it seems to be a fairly obscure deadlock for XFS ...

What is the likelyhood of getting current->has_io_locks
kind of thing in 2.4?


-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Fri Dec 29 12:20:35 2000
Received:  by oss.sgi.com id <S553738AbQL2UU0>;
	Fri, 29 Dec 2000 12:20:26 -0800
Received: from perninha.conectiva.com.br ([200.250.58.156]:37650 "EHLO
        perninha.conectiva.com.br") by oss.sgi.com with ESMTP
	id <S553685AbQL2UUE>; Fri, 29 Dec 2000 12:20:04 -0800
Received: from freak.distro.conectiva (freak.distro.conectiva [10.0.17.22])
	by perninha.conectiva.com.br (8.9.3/8.9.3) with ESMTP id SAA28139;
	Fri, 29 Dec 2000 18:19:36 -0200
Date:   Fri, 29 Dec 2000 16:27:33 -0200 (BRST)
From:   Marcelo Tosatti <marcelo@conectiva.com.br>
X-Sender: marcelo@freak.distro.conectiva
To:     Rajagopal Ananthanarayanan <ananth@sgi.com>
cc:     linux-xfs@oss.sgi.com, andrea@suse.de
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
In-Reply-To: <3A4CDB34.1E6DA86E@sgi.com>
Message-ID: <Pine.LNX.4.21.0012291625380.13267-100000@freak.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing



On Fri, 29 Dec 2000, Rajagopal Ananthanarayanan wrote:

> What is the likelyhood of getting current->has_io_locks
> kind of thing in 2.4?

I'm not sure if Linus will want to include it in the stock tree.

Anyway, I'll do a patch like this after the weekend so you can stress XFS
again.

 


From owner-linux-xfs@oss.sgi.com Sat Dec 30 17:45:24 2000
Received:  by oss.sgi.com id <S553759AbQLaBpP>;
	Sat, 30 Dec 2000 17:45:15 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:11898 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553657AbQLaBov>;
	Sat, 30 Dec 2000 17:44:51 -0800
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA02457
	for <linux-xfs@oss.sgi.com>; Sat, 30 Dec 2000 17:43:59 -0800 (PST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA10791
	for linux-xfs@oss.sgi.com; Sun, 31 Dec 2000 12:43:30 +1100 (EST)
Date:   Sun, 31 Dec 2000 12:43:30 +1100 (EST)
From:   Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200012310143.MAA10791@snort.melbourne.sgi.com>
To:     linux-xfs@oss.sgi.com
Subject: TAKE - doc
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Modid:  2.4.x-xfs:slinx:81357a
Date:  Sat Dec 30 17:42:22 PST 2000
Workarea:  snort:/diskb/build4/nathans/linux-xfs
Author:  nathans

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs

linux/Documentation/filesystems/00-INDEX - 1.7
	- add an entry for XFS + a couple of other missing entries.

linux/Documentation/filesystems/xfs.txt - 1.1
	- document xfs mount options, etc.


From owner-linux-xfs@oss.sgi.com Sat Dec 30 21:32:46 2000
Received:  by oss.sgi.com id <S553762AbQLaFcg>;
	Sat, 30 Dec 2000 21:32:36 -0800
Received: from pike.sover.net ([209.198.87.34]:28866 "EHLO pike.sover.net")
	by oss.sgi.com with ESMTP id <S553740AbQLaFcS>;
	Sat, 30 Dec 2000 21:32:18 -0800
Received: from [192.168.1.3] (pm1a21.stj.sover.net [209.198.94.21])
	by pike.sover.net (8.9.3/8.9.3) with ESMTP id AAA01878
	for <linux-xfs@oss.sgi.com>; Sun, 31 Dec 2000 00:31:59 -0500 (EST)
Comments: SoVerNet Verification (on pike.sover.net)
	[192.168.1.3] from pm1a21.stj.sover.net [209.198.94.21] 209.198.94.21
	Sun, 31 Dec 2000 00:31:59 -0500 (EST)
Date:   Sun, 31 Dec 2000 00:36:29 -0500 (EST)
From:   Jason Walker <unseen@sover.net>
X-Sender: unseen@surreal.localdomain
To:     SGI XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Root XFS partition
Message-ID: <Pine.LNX.4.10.10012310029100.290-100000@surreal.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Greetings all,

	I have XFS for a short time now, and just got around to making back ups of all my data.  I finally have a 10gb filesystem (over several partitions) for XFS, made all the filesystems, and went to boot....and it wouldn't mount the XFS / partition. left me with the generic:

	Kernel panic: VFS: Unable to mount root fs on 03:45

	I read on the FAQ that LILO now works with XFS (or vice-versa :) and I searched the mailing lsit archives and only found old things about trying to get  root XFS to mount, then later, issues with it being buggy...but I didn't see anything about how to get XFS / to work (what does  "Could be easier", from the FAQ,  mean, anyways? :)
	Can anyone shed some light on this?  I would *love* to get this working, thanks for your time.

	RegEx/Jason Walker



From owner-linux-xfs@oss.sgi.com Sat Dec 30 21:52:36 2000
Received:  by oss.sgi.com id <S553767AbQLaFwR>;
	Sat, 30 Dec 2000 21:52:17 -0800
Received: from lips.borg.umn.edu ([160.94.232.50]:39182 "EHLO
        lips.borg.umn.edu") by oss.sgi.com with ESMTP id <S553761AbQLaFvu>;
	Sat, 30 Dec 2000 21:51:50 -0800
Received: from thebarn.com (nic-31-c12-053.mn.mediaone.net [24.31.12.53])
	by lips.borg.umn.edu (8.11.1/8.10.1) with ESMTP id eBV5ple66755;
	Sat, 30 Dec 2000 23:51:47 -0600 (CST)
Message-ID: <3A4EC96C.2FA6DD32@thebarn.com>
Date:   Sat, 30 Dec 2000 23:51:41 -0600
From:   Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jason Walker <unseen@sover.net>
CC:     SGI XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Root XFS partition
References: <Pine.LNX.4.10.10012310029100.290-100000@surreal.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jason Walker wrote:

> Greetings all,
>
>         I have XFS for a short time now, and just got around to making back ups of all my data.  I finally have a 10gb filesystem (over several partitions) for XFS, made all the filesystems, and went to boot....and it wouldn't mount the XFS / partition. left me with the generic:
>
>         Kernel panic: VFS: Unable to mount root fs on 03:45
>
>         I read on the FAQ that LILO now works with XFS (or vice-versa :) and I searched the mailing lsit archives and only found old things about trying to get  root XFS to mount, then later, issues with it being buggy...but I didn't see anything about how to get XFS / to work (what does  "Could be easier", from the FAQ,  mean, anyways? :)
>         Can anyone shed some light on this?  I would *love* to get this working, thanks for your time.
>
>         RegEx/Jason Walker

XFS wasn't available at boot time.
You either need to build a kernel with XFS compiled in or
make an inital ramdisk with the xfs xfs_support and pagebuf modules included
A modified version of mkinitrd can be found in cmd/xfs/misc

You will also need to add the following to the append line in your lilo.conf file.

ramdisk_size=2500

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sat Dec 30 22:01:47 2000
Received:  by oss.sgi.com id <S553770AbQLaGBh>;
	Sat, 30 Dec 2000 22:01:37 -0800
Received: from femail2.rdc1.on.home.com ([24.2.9.89]:25816 "EHLO
        femail2.rdc1.on.home.com") by oss.sgi.com with ESMTP
	id <S553765AbQLaGBY>; Sat, 30 Dec 2000 22:01:24 -0800
Received: from acm.org ([24.64.181.43]) by femail2.rdc1.on.home.com
          (InterMail vM.4.01.03.00 201-229-121) with ESMTP
          id <20001231060113.OEDG21590.femail2.rdc1.on.home.com@acm.org>;
          Sat, 30 Dec 2000 22:01:13 -0800
Message-ID: <3A4ECBC3.533C9FF0@acm.org>
Date:   Sun, 31 Dec 2000 01:01:39 -0500
From:   Andrew Ho <andrewho@acm.org>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.4.0-XFS-test13-pre3 i686)
X-Accept-Language: en, zh, zh-CN, zh-TW
MIME-Version: 1.0
To:     Jason Walker <unseen@sover.net>,
        SGI XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Root XFS partition
References: <Pine.LNX.4.10.10012310029100.290-100000@surreal.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

Jason Walker wrote:

> Greetings all,
>
>         I have XFS for a short time now, and just got around to making back ups of all my data.  I finally have a 10gb filesystem (over several partitions) for XFS, made all the filesystems, and went to boot....and it wouldn't mount the XFS / partition. left me with the generic:
>
>         Kernel panic: VFS: Unable to mount root fs on 03:45
>
>         I read on the FAQ that LILO now works with XFS (or vice-versa :) and I searched the mailing lsit archives and only found old things about trying to get  root XFS to mount, then later, issues with it being buggy...but I didn't see anything about how to get XFS / to work (what does  "Could be easier", from the FAQ,  mean, anyways? :)
>         Can anyone shed some light on this?  I would *love* to get this working, thanks for your time.
>
>         RegEx/Jason Walker

03:45 that you mentioned is /dev/ttyrd.

I did not have any problem to mount / as xfs with linux-2.4.0.-test13-pre3 with /boot (ext2).

I made  the /boot partition (xfs), I have no luck to boot up this /boot partition with lilo.
Probably lilo is not support xfs as /boot partition at this moment.

Andrew Ho



From owner-linux-xfs@oss.sgi.com Sun Dec 31 19:09:46 2000
Received:  by oss.sgi.com id <S553758AbRAADJg>;
	Sun, 31 Dec 2000 19:09:36 -0800
Received: from ppp0.ocs.com.au ([203.34.97.3]:27664 "HELO mail.ocs.com.au")
	by oss.sgi.com with SMTP id <S553705AbRAADJN>;
	Sun, 31 Dec 2000 19:09:13 -0800
Received: (qmail 17561 invoked from network); 1 Jan 2001 03:09:07 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 1 Jan 2001 03:09:07 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Andrew Ho <andrewho@acm.org>
cc:     Jason Walker <unseen@sover.net>,
        SGI XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Root XFS partition 
In-reply-to: Your message of "Sun, 31 Dec 2000 01:01:39 CDT."
             <3A4ECBC3.533C9FF0@acm.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 01 Jan 2001 14:09:06 +1100
Message-ID: <2769.978318546@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-xfs@oss.sgi.com>
X-Orcpt: rfc822;linux-xfs-outgoing

On Sun, 31 Dec 2000 01:01:39 -0500, 
Andrew Ho <andrewho@acm.org> wrote:
>03:45 that you mentioned is /dev/ttyrd.

Block major 3 (First MFM, RLL and IDE hard disk/CD-ROM interface), not
char major 3 (Pseudo-TTY slaves).  Also the numbers are in hex, not
decimal (everybody gets caught by that one) so it is is block device
3,69 - hdb5.