From owner-xfs@oss.sgi.com Sat Sep 1 17:09:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Sep 2007 17:09:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l8209R4p000640 for ; Sat, 1 Sep 2007 17:09:28 -0700 Received: from [89.49.172.106] (helo=[192.168.178.20]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IRaAk-0006dw-20 for xfs@oss.sgi.com; Sat, 01 Sep 2007 23:06:26 +0200 Date: Sat, 1 Sep 2007 23:06:25 +0200 (CEST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: xfs@oss.sgi.com Subject: lockdep annotations? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-archive-position: 12742 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs Hi, I try to follow -rc kernels and just upgraded to 2.6.23-rc5 and I still see: "INFO: possible circular locking dependency detected". Out of curiosity: (when) will these warnings be addressed? I mean, suits me for enabling CONFIG_LOCKDEP in the first place, but the only warnings I get is still xfs :) FWIW, full log is here: http://nerdbynature.de/bits/2.6.23-rc5/messages_2.6.23-rc5 Thanks, Christian. -- BOFH excuse #156: Zombie processes haunting the computer From owner-xfs@oss.sgi.com Sun Sep 2 04:43:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 04:43:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=BAYES_99,MSGID_FROM_MTA_HEADER autolearn=no version=3.2.0-pre1-r499012 Received: from mx05.syd.iprimus.net.au (mx05.syd.iprimus.net.au [210.50.30.235]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82Bgw4p017475 for ; Sun, 2 Sep 2007 04:43:03 -0700 Message-Id: <68bfp5$1t8kpt@smtp05.syd.iprimus.net.au> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFs72kY6s3Ob/2dsb2JhbAAMphA X-IronPort-AV: E=Sophos;i="4.20,199,1186322400"; d="scan'208";a="64246589" Received: from unknown (HELO [192.168.1.102]) ([58.179.115.155]) by smtp05.syd.iprimus.net.au with ESMTP; 02 Sep 2007 21:30:56 +1000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Description: Mail message body Subject: Start Sending Video Emails In Minutes To: Recipients X-IMBH: Yes From: mwpoz@iprimus.com.au Date: Sun, 02 Sep 2007 21:30:47 +1000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l82Bh34p017496 X-archive-position: 12743 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mwpoz@iprimus.com.au Precedence: bulk X-list: xfs TALK FUSION - The newest development in email technology Businesses and Talk Fusion make a great pair! From family-owned to Fortune 500, Talk Fusion is your answer. We have a perfect fit! Video email will build brand loyalty, increase customer relations and retention, reduce advertising costs, qualify sales leads and increase response rates. • Home Tours • Sale Announcements • Product Demos • Training • Promotions • Events • Advertising • Prospecting • New Lead Capture • Motivational Messages • Corporate News • Fundraising • Presentations • Customer Follow-Ups • Appointment Reminders • Special Instructions • Customer Appreciation • Qualify Leads • Invitations • Trackable Marketing Talk Fusion is even smart enough to notify you when your video message is being watched! With our real-time tracking technology, you will be able to see who has viewed your video email, when, and if they forwarded it to a friend or clicked through to your web site! Capture new leads and know exactly who’s interested. Learn more. Talk Fusion combines the power of television with the ease of email, allowing you to be in two places at once, share special moments and even build greater brand loyalty among customers. All without annoying downloads, pop-up windows, software to install or attachments to open. If you are one of the 700 million email users sending over 30 billion emails every day, you can point, click and send vibrant video emails to anyone, anywhere in the world, anytime. It is so simple, anyone can use it. No Internet experience necessary. Visit Talk Fusion http://www.jbdmarketing.com Sample Video Email http://www.talkfusion.com/samples/vistaprint_flv.htm Jeremy B Dwyer JBD Marketing ========================================================================================================= This is a once only mailing to an optin commercial mailing list supplied by a marketing company. If this email is considered SPAM, we apologies for any inconvenience. Should you receive further unwanted emails, please contact us at talkfusion@iprimus.com.au. ========================================================================================================= From owner-xfs@oss.sgi.com Sun Sep 2 07:44:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 07:44:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_50, DATE_IN_PAST_12_24 autolearn=no version=3.2.0-pre1-r499012 Received: from amanpulo.fs3.ph (amanpulo.fs3.ph [72.51.42.241]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82Eih4p012910 for ; Sun, 2 Sep 2007 07:44:45 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.fs3.ph (Postfix) with ESMTP id 8E7E61E0D5953 for ; Sun, 2 Sep 2007 21:46:50 +0800 (PHT) X-Virus-Scanned: Debian amavisd-new at fs3.ph Received: from amanpulo.fs3.ph ([127.0.0.1]) by localhost (amanpulo.fs3.ph [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dCbeMq+GSUE3 for ; Sun, 2 Sep 2007 21:46:41 +0800 (PHT) Received: from auctoritas.local (unknown [222.127.47.132]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by amanpulo.fs3.ph (Postfix) with ESMTP id D832D1E0E08B5 for ; Sun, 2 Sep 2007 21:46:40 +0800 (PHT) Subject: Re: ZFS, XFS, and EXT4 compared From: Federico Sevilla III To: xfs@oss.sgi.com In-Reply-To: <1188513751.24970.109.camel@edge.yarra.acx> References: <1188454611.23311.13.camel@toonses.gghcwest.com> <1188457666.24970.94.camel@edge.yarra.acx> <20070830132002.GA4086@infradead.org> <1188513751.24970.109.camel@edge.yarra.acx> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WuH1W4y6xpJyStAd+cd0" Organization: F S 3 Consulting Inc. Date: Sat, 01 Sep 2007 23:07:23 +0800 Message-Id: <1188659243.4430.8.camel@auctoritas.fs3.ph> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 12744 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jijo@fs3.ph Precedence: bulk X-list: xfs --=-WuH1W4y6xpJyStAd+cd0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2007-08-31 at 08:42 +1000, Nathan Scott wrote: > Possibly. Far more importantly for XFS, there really needs to be some > way for RAID drivers to say "even though I support write barriers, its > not a good idea for filesystems to enable write barriers by default on > me". Enabling write barriers everywhere, by default, seems to have a > far worse impact than any mkfs/mount option tweaking. On all my systems with software RAID or dm-crypt (or both), mounting XFS gives me a message about barriers being disabled because the underlying device doesn't support it. For good measure I disable write caching on all my systems with either software RAID or dm-crypt (or both). Am I reading the thread correctly that even with this message showing up, I still need to mount with nobarrier explicitly to improve performance? I also think it would be nice to add something like a modern-day tuning FAQ for XFS. I know there's a bit on the FAQ already but perhaps it needs an update? Thanks. --=20 Federico Sevilla III F S 3 Consulting Inc. http://www.fs3.ph --=-WuH1W4y6xpJyStAd+cd0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBG2YAr5rCBSJO3Rr4RAkH6AJ9sUGdQkS8qnaoY/Cb6i51vRtVTvgCZATVY l9LKoNVPbMi16yxXZ7Nx8uI= =Ymg2 -----END PGP SIGNATURE----- --=-WuH1W4y6xpJyStAd+cd0-- From owner-xfs@oss.sgi.com Sun Sep 2 13:17:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 13:17:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82KHS4p029282 for ; Sun, 2 Sep 2007 13:17:29 -0700 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l82KHRA5029867 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 2 Sep 2007 22:17:27 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l82KHRqV029864 for xfs@oss.sgi.com; Sun, 2 Sep 2007 22:17:27 +0200 Date: Sun, 2 Sep 2007 22:17:27 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: [PATCH] kill probe_* sysctl leftovers Message-ID: <20070902201727.GA29823@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 12745 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs After my recent changes the probe_* sysctls are unused because we do a proper request_module now if we actually know that we need the quota or dmapi module. Kill the leftovers that have no function anymore. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_globals.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_globals.c 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_globals.c 2007-09-02 22:02:29.000000000 +0200 @@ -32,9 +32,6 @@ xfs_param_t xfs_params = { .panic_mask = { 0, 0, 255 }, .error_level = { 0, 3, 11 }, .syncd_timer = { 1*100, 30*100, 7200*100}, - .probe_dmapi = { 0, 0, 1 }, - .probe_ioops = { 0, 0, 1 }, - .probe_quota = { 0, 1, 1 }, .stats_clear = { 0, 0, 1 }, .inherit_sync = { 0, 1, 1 }, .inherit_nodump = { 0, 1, 1 }, Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_linux.h 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_linux.h 2007-09-02 22:02:29.000000000 +0200 @@ -119,9 +119,6 @@ #define xfs_panic_mask xfs_params.panic_mask.val #define xfs_error_level xfs_params.error_level.val #define xfs_syncd_centisecs xfs_params.syncd_timer.val -#define xfs_probe_dmapi xfs_params.probe_dmapi.val -#define xfs_probe_ioops xfs_params.probe_ioops.val -#define xfs_probe_quota xfs_params.probe_quota.val #define xfs_stats_clear xfs_params.stats_clear.val #define xfs_inherit_sync xfs_params.inherit_sync.val #define xfs_inherit_nodump xfs_params.inherit_nodump.val Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_sysctl.c 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.c 2007-09-02 22:02:29.000000000 +0200 @@ -123,39 +123,6 @@ static ctl_table xfs_table[] = { .extra2 = &xfs_params.syncd_timer.max }, { - .ctl_name = XFS_PROBE_DMAPI, - .procname = "probe_dmapi", - .data = &xfs_params.probe_dmapi.val, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec_minmax, - .strategy = &sysctl_intvec, - .extra1 = &xfs_params.probe_dmapi.min, - .extra2 = &xfs_params.probe_dmapi.max - }, - { - .ctl_name = XFS_PROBE_IOOPS, - .procname = "probe_ioops", - .data = &xfs_params.probe_ioops.val, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec_minmax, - .strategy = &sysctl_intvec, - .extra1 = &xfs_params.probe_ioops.min, - .extra2 = &xfs_params.probe_ioops.max - }, - { - .ctl_name = XFS_PROBE_QUOTA, - .procname = "probe_quota", - .data = &xfs_params.probe_quota.val, - .maxlen = sizeof(int), - .mode = 0644, - .proc_handler = &proc_dointvec_minmax, - .strategy = &sysctl_intvec, - .extra1 = &xfs_params.probe_quota.min, - .extra2 = &xfs_params.probe_quota.max - }, - { .ctl_name = XFS_INHERIT_SYNC, .procname = "inherit_sync", .data = &xfs_params.inherit_sync.val, Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_sysctl.h 2007-09-02 21:48:26.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_sysctl.h 2007-09-02 22:02:29.000000000 +0200 @@ -39,9 +39,6 @@ typedef struct xfs_param { xfs_sysctl_val_t error_level; /* Degree of reporting for problems */ xfs_sysctl_val_t syncd_timer; /* Interval between xfssyncd wakeups */ xfs_sysctl_val_t stats_clear; /* Reset all XFS statistics to zero. */ - xfs_sysctl_val_t probe_dmapi; /* probe for DMAPI module on mount. */ - xfs_sysctl_val_t probe_ioops; /* probe for an IO module on mount. */ - xfs_sysctl_val_t probe_quota; /* probe for quota module on mount. */ xfs_sysctl_val_t inherit_sync; /* Inherit the "sync" inode flag. */ xfs_sysctl_val_t inherit_nodump;/* Inherit the "nodump" inode flag. */ xfs_sysctl_val_t inherit_noatim;/* Inherit the "noatime" inode flag. */ @@ -77,9 +74,9 @@ enum { XFS_PANIC_MASK = 6, XFS_ERRLEVEL = 7, XFS_SYNCD_TIMER = 8, - XFS_PROBE_DMAPI = 9, - XFS_PROBE_IOOPS = 10, - XFS_PROBE_QUOTA = 11, + /* XFS_PROBE_DMAPI = 9, */ + /* XFS_PROBE_IOOPS = 10, */ + /* XFS_PROBE_QUOTA = 11, */ XFS_STATS_CLEAR = 12, XFS_INHERIT_SYNC = 13, XFS_INHERIT_NODUMP = 14, From owner-xfs@oss.sgi.com Sun Sep 2 15:49:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 15:49:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l82Mn24p018419 for ; Sun, 2 Sep 2007 15:49:03 -0700 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA18993; Mon, 3 Sep 2007 08:48:57 +1000 Message-ID: <46DB3E4B.3030106@sgi.com> Date: Mon, 03 Sep 2007 08:50:51 +1000 From: Vlad Apostolov User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: David Chinner CC: Mark Goodwin , Lachlan McIlroy , Timothy Shimmin , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46D6480F.4040307@sgi.com> <46D64CAD.6050705@sgi.com> <46D67FE6.20205@sgi.com> <46D68510.1020404@sgi.com> <46D77B79.3040104@sgi.com> <46D792A1.7030308@sgi.com> <20070831154822.GD734179@sgi.com> In-Reply-To: <20070831154822.GD734179@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12746 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > An unlinked inode is only detectable by the mode parameter being zero. > The rest of the inode will look valid. What about the nlink count? Can't we detect unlinked inode by nlink == 0? Regards, Vlad From owner-xfs@oss.sgi.com Sun Sep 2 15:59:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 15:59:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l82MxG4p019923 for ; Sun, 2 Sep 2007 15:59:18 -0700 Received: from edge.yarra.acx (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 5911092C390; Mon, 3 Sep 2007 08:59:16 +1000 (EST) Subject: Re: ZFS, XFS, and EXT4 compared From: Nathan Scott Reply-To: nscott@aconex.com To: Federico Sevilla III Cc: xfs@oss.sgi.com In-Reply-To: <1188659243.4430.8.camel@auctoritas.fs3.ph> References: <1188454611.23311.13.camel@toonses.gghcwest.com> <1188457666.24970.94.camel@edge.yarra.acx> <20070830132002.GA4086@infradead.org> <1188513751.24970.109.camel@edge.yarra.acx> <1188659243.4430.8.camel@auctoritas.fs3.ph> Content-Type: text/plain Organization: Aconex Date: Mon, 03 Sep 2007 09:00:33 +1000 Message-Id: <1188774034.24970.123.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 12747 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Sat, 2007-09-01 at 23:07 +0800, Federico Sevilla III wrote: > > > Am I reading the thread correctly that even with this message showing > up, I still need to mount with nobarrier explicitly to improve > performance? > No, thats not needed if XFS explicitly says its not using barriers. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Sep 2 19:44:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 19:44:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l832iA4p030748 for ; Sun, 2 Sep 2007 19:44:15 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28800; Mon, 3 Sep 2007 12:44:04 +1000 Message-ID: <46DB7586.7040309@sgi.com> Date: Mon, 03 Sep 2007 12:46:30 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Christian Kujau CC: xfs@oss.sgi.com Subject: Re: lockdep annotations? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12748 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a locking inversion between the iolock and iprune_mutex. I hadn't seen this one before. Was your system running low on memory at the time? We can't drop the iolock in the write path so we'll have to avoid acquiring the iolock in xfs_ireclaim() which means we'll need another way to synchronise with xfs_sync_inodes(). Thanks for pointing this one out. Lachlan Christian Kujau wrote: > Hi, > > I try to follow -rc kernels and just upgraded to 2.6.23-rc5 and I still > see: "INFO: possible circular locking dependency detected". Out of > curiosity: (when) will these warnings be addressed? I mean, suits me for > enabling CONFIG_LOCKDEP in the first place, but the only warnings I get > is still xfs :) > > FWIW, full log is here: > http://nerdbynature.de/bits/2.6.23-rc5/messages_2.6.23-rc5 > > Thanks, > Christian. From owner-xfs@oss.sgi.com Sun Sep 2 20:04:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 20:04:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8334n4p002820 for ; Sun, 2 Sep 2007 20:04:52 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA29727; Mon, 3 Sep 2007 13:04:46 +1000 Message-ID: <46DB7A60.4050203@sgi.com> Date: Mon, 03 Sep 2007 13:07:12 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: xfs-dev CC: xfs-oss Subject: [PATCH] ensure file size is logged on synchronous writes Content-Type: multipart/mixed; boundary="------------060907010105080008020904" X-archive-position: 12749 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------060907010105080008020904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Synchronous writes currently log inode changes before syncing pages to disk. Since the file size is updated on I/O completion we wont be writing out the updated file size and if we crash the file will have the wrong size. This change moves the logging after the syncing of the pages to ensure we log the correct file size. Lachlan --------------060907010105080008020904 Content-Type: text/x-patch; name="xfs_write.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_write.diff" --- fs/xfs/linux-2.6/xfs_lrw.c_1.266 2007-08-30 17:38:53.000000000 +1000 +++ fs/xfs/linux-2.6/xfs_lrw.c 2007-08-31 15:38:49.000000000 +1000 @@ -895,20 +895,19 @@ retry: /* Handle various SYNC-type writes */ if ((file->f_flags & O_SYNC) || IS_SYNC(inode)) { - error = xfs_write_sync_logforce(mp, xip); - if (error) - goto out_unlock_internal; - + int error2; xfs_rwunlock(xip, locktype); if (need_i_mutex) mutex_unlock(&inode->i_mutex); - - error = sync_page_range(inode, mapping, pos, ret); + error2 = sync_page_range(inode, mapping, pos, ret); if (!error) - error = -ret; + error = error2; if (need_i_mutex) mutex_lock(&inode->i_mutex); xfs_rwlock(xip, locktype); + error2 = xfs_write_sync_logforce(mp, xip); + if (!error) + error = error2; } out_unlock_internal: --------------060907010105080008020904-- From owner-xfs@oss.sgi.com Sun Sep 2 23:33:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Sep 2007 23:33:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l836Xe4p005069 for ; Sun, 2 Sep 2007 23:33:43 -0700 Received: from [89.54.161.50] (helo=[192.168.178.25]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IS5VC-00060q-G0; Mon, 03 Sep 2007 08:33:38 +0200 Date: Mon, 3 Sep 2007 08:33:36 +0200 (CEST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Lachlan McIlroy cc: xfs@oss.sgi.com Subject: Re: lockdep annotations? In-Reply-To: <46DB7586.7040309@sgi.com> Message-ID: References: <46DB7586.7040309@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii; format=flowed X-archive-position: 12750 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Mon, 3 Sep 2007, Lachlan McIlroy wrote: > This is a locking inversion between the iolock and iprune_mutex. I > hadn't seen this one before. Was your system running low on memory > at the time? Usually, this might be the case, as lockdep reports only once and when it does it's usually the morning after the last reboot, when a script runs the backups (so the box is under load, probably memory pressure involved). However, this time I don't remember memory consuming tasks running. Unfortunately, I cannot reproduce this yet... thanks for your explanations, Christian. -- BOFH excuse #321: Scheduled global CPU outage From owner-xfs@oss.sgi.com Mon Sep 3 01:49:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 01:49:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l838nJ4p004199 for ; Mon, 3 Sep 2007 01:49:22 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA14150; Mon, 3 Sep 2007 18:49:18 +1000 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 l838nHdD4050522; Mon, 3 Sep 2007 18:49:18 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l838nGbV4050449; Mon, 3 Sep 2007 18:49:16 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Sep 2007 18:49:16 +1000 From: David Chinner To: Vlad Apostolov Cc: David Chinner , Mark Goodwin , Lachlan McIlroy , Timothy Shimmin , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070903084916.GG995458@sgi.com> References: <46D6279F.40601@sgi.com> <46D6480F.4040307@sgi.com> <46D64CAD.6050705@sgi.com> <46D67FE6.20205@sgi.com> <46D68510.1020404@sgi.com> <46D77B79.3040104@sgi.com> <46D792A1.7030308@sgi.com> <20070831154822.GD734179@sgi.com> <46DB3E4B.3030106@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB3E4B.3030106@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12751 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Sep 03, 2007 at 08:50:51AM +1000, Vlad Apostolov wrote: > David Chinner wrote: > >An unlinked inode is only detectable by the mode parameter being zero. > >The rest of the inode will look valid. > What about the nlink count? Can't we detect unlinked inode by nlink == 0? A file that is open but unlinked must still remain valid on disk until the last reference goes away. This inode will have a link count of zero, but it is still a valid, referenced inode. Hence detection of an inode with a link count of zero does not mean it has been fully removed yet - a zero link count and a non-zero mode indicates the inode should be onthe unlinked inode list. See xfs_ifree() - the mode is zeroed only after the inode has been pulled from the AGI unlinked list and marked free in the AGI btree. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Sep 3 02:01:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 02:01:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l8391C4p007258 for ; Mon, 3 Sep 2007 02:01:14 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA14675; Mon, 3 Sep 2007 19:01:05 +1000 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 l83914dD4027517; Mon, 3 Sep 2007 19:01:05 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l83913HY4059549; Mon, 3 Sep 2007 19:01:03 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Sep 2007 19:01:03 +1000 From: David Chinner To: Lachlan McIlroy Cc: Christian Kujau , xfs@oss.sgi.com Subject: Re: lockdep annotations? Message-ID: <20070903090103.GG734179@sgi.com> References: <46DB7586.7040309@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DB7586.7040309@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12752 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Sep 03, 2007 at 12:46:30PM +1000, Lachlan McIlroy wrote: > This is a locking inversion between the iolock and iprune_mutex. I > hadn't seen this one before. Was your system running low on memory > at the time? > > We can't drop the iolock in the write path so we'll have to avoid > acquiring the iolock in xfs_ireclaim() which means we'll need another > way to synchronise with xfs_sync_inodes(). I don't think a deadlock exists here - we have to be going through memory reclaim to hit this inversion, so the only place that we can deadlock is if we are holding the iprune_mutex across a memory allocation. I don't think we do that.... Not to mention that the inode we hold the iolock on won't be on the inode free list so we won't ever try to lock it during reclaim, either. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Sep 3 02:20:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 02:20:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.pawisda.de (mail.pawisda.de [213.157.4.156]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l839Ko4p011542 for ; Mon, 3 Sep 2007 02:20:51 -0700 Received: from localhost (localhost.intra.frontsite.de [127.0.0.1]) by mail.pawisda.de (Postfix) with ESMTP id 96955E7BD for ; Mon, 3 Sep 2007 11:20:51 +0200 (CEST) Received: from mail.pawisda.de ([127.0.0.1]) by localhost (ndb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24959-04 for ; Mon, 3 Sep 2007 11:20:40 +0200 (CEST) Received: from [192.168.51.2] (lw-pc002.intra.frontsite.de [192.168.51.2]) by mail.pawisda.de (Postfix) with ESMTP id 29277BE7E for ; Mon, 3 Sep 2007 11:20:40 +0200 (CEST) Message-ID: <46DBD1E7.4030701@linworks.de> Date: Mon, 03 Sep 2007 11:20:39 +0200 From: Ruben Porras User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070828) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: [PATCH] Implement ioctl to mark AGs as "don't use/use" References: <1182939325.5313.12.camel@localhost> <20070628045049.GF989688@sgi.com> <46838CAE.9030808@linworks.de> <20070629005417.GF31489@sgi.com> In-Reply-To: <20070629005417.GF31489@sgi.com> Content-Type: multipart/mixed; boundary="------------020905060609070803010108" X-Virus-Scanned: by amavisd-new at pawisda.de X-archive-position: 12753 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben.porras@linworks.de Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------020905060609070803010108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit David Chinner wrote: > OOC, do you have any test code for this? xfs_io would be the tool to > teach this ioctl to.... > I've implemented this on xfs_io, and tested, and it works :) Attached are the modifications needed to the xfsprogs source tree in form of a diff against the CVS tree. In a short time all the patches that I submitted will be available together under an url, so that they are not scattered across the mailing list. -- Rubén Porras LinWorks GmbH --------------020905060609070803010108 Content-Type: text/x-patch; name="xfsprogs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfsprogs.diff" diff -rNu xfs-cmds/xfsprogs/include/xfs_ag.h /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_ag.h --- xfs-cmds/xfsprogs/include/xfs_ag.h 2007-05-22 17:59:41.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_ag.h 2007-08-31 14:08:51.975160695 +0200 @@ -69,6 +69,7 @@ __be32 agf_freeblks; /* total free blocks */ __be32 agf_longest; /* longest free space */ __be32 agf_btreeblks; /* # of blocks held in AGF btrees */ + __be32 agf_flags; /* persistent AG state flags */ } xfs_agf_t; #define XFS_AGF_MAGICNUM 0x00000001 @@ -83,7 +84,8 @@ #define XFS_AGF_FREEBLKS 0x00000200 #define XFS_AGF_LONGEST 0x00000400 #define XFS_AGF_BTREEBLKS 0x00000800 -#define XFS_AGF_NUM_BITS 12 +#define XFS_AGF_FLAGS 0x00001000 +#define XFS_AGF_NUM_BITS 13 #define XFS_AGF_ALL_BITS ((1 << XFS_AGF_NUM_BITS) - 1) /* disk block (xfs_daddr_t) in the AG */ @@ -196,8 +198,17 @@ lock_t pagb_lock; /* lock for pagb_list */ #endif xfs_perag_busy_t *pagb_list; /* unstable blocks */ + __u32 pagf_flags; /* persistent AG state flags */ } xfs_perag_t; +typedef struct xfs_ioc_agflags +{ + xfs_agnumber_t ag; + __u32 flags; +} xfs_ioc_agflags_t; + +#define XFS_AGF_FLAGS_ALLOC_DENY (1<<0) + #define XFS_AG_MAXLEVELS(mp) ((mp)->m_ag_maxlevels) #define XFS_MIN_FREELIST_RAW(bl,cl,mp) \ (MIN(bl + 1, XFS_AG_MAXLEVELS(mp)) + MIN(cl + 1, XFS_AG_MAXLEVELS(mp))) diff -rNu xfs-cmds/xfsprogs/include/xfs_fs.h /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_fs.h --- xfs-cmds/xfsprogs/include/xfs_fs.h 2007-06-28 18:00:13.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/include/xfs_fs.h 2007-08-31 15:19:21.107148402 +0200 @@ -499,6 +499,8 @@ #define XFS_IOC_ATTRMULTI_BY_HANDLE _IOW ('X', 123, struct xfs_fsop_attrmulti_handlereq) #define XFS_IOC_FSGEOMETRY _IOR ('X', 124, struct xfs_fsop_geom) #define XFS_IOC_GOINGDOWN _IOR ('X', 125, __uint32_t) +#define XFS_IOC_GET_AGF_FLAGS _IOWR('X', 126, struct xfs_ioc_agflags) +#define XFS_IOC_SET_AGF_FLAGS _IOW ('X', 127, struct xfs_ioc_agflags) /* XFS_IOC_GETFSUUID ---------- deprecated 140 */ diff -rNu xfs-cmds/xfsprogs/io/agflags.c /home/ldap/campo/xfs-cmds/xfsprogs/io/agflags.c --- xfs-cmds/xfsprogs/io/agflags.c 1970-01-01 01:00:00.000000000 +0100 +++ /home/ldap/campo/xfs-cmds/xfsprogs/io/agflags.c 2007-08-31 13:56:48.861921728 +0200 @@ -0,0 +1,126 @@ + /* + * Copyright (c) 2007 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include +#include +#include +#include +#include +#include "init.h" +#include "io.h" + +static cmdinfo_t agflags_cmd; + +static void +agflags_help(void) +{ + printf(_( +"\n" +" get or set the diferent flags of a given AG\n" +"\n" +" Example:\n" +" 'agflags -d 0 -a 10' - unset the flag XFS_AGF_FLAGS_ALLOC_DENY from the AG\n" +" number 10\n" +"\n")); +} + +int +agflags_valid_ag( + int ag) +{ + xfs_fsop_geom_t fsgeo; + + if (ag < 0) + return 0; + + if (xfsctl(file->name, file->fd, XFS_IOC_FSGEOMETRY, &fsgeo) < 0) { + fprintf(stderr, _("%s: cannot get geometry of fs: %s\n"), + progname, strerror(errno)); + exitcode = 1; + return 0; + } + + return (ag <= fsgeo.agcount); +} + +int +agflags_f( + int argc, + char **argv) +{ + xfs_ioc_agflags_t ioc_flags; + unsigned int dflag; + int opt; + int set = 0; + + while ((opt = getopt(argc, argv, "d:a:")) != -1) { + switch (opt) { + case 'a': /* AG number. */ + ioc_flags.ag = atoi(optarg); + break; + case 'd': /* (Un)set XFS_AGF_FLAGS_ALLOC_DENY */ + dflag = atoi(optarg); + if (dflag != 0 && dflag != 1) + return command_usage(&agflags_cmd); + set = 1; + break; + default: /* ? */ + return command_usage(&agflags_cmd); + } + } + + if (! agflags_valid_ag(ioc_flags.ag)) { + fprintf(stderr, _("%s: AG number %d is not valid\n"), + progname, ioc_flags.ag); + return 0; + } + + if (set) + ioc_flags.flags = dflag; + + int ioctl; + ioctl = set ? XFS_IOC_SET_AGF_FLAGS : XFS_IOC_GET_AGF_FLAGS; + + if (xfsctl(file->name, file->fd, ioctl, &ioc_flags) < 0) { + fprintf(stderr, + _("%s: cannot %s flags %d on ag %d at %s: %s\n"), + progname, set ? "get" : "set", ioc_flags.flags, + ioc_flags.ag, file->name, strerror(errno)); + exitcode = 1; + return 0; + } + + return 0; +} + +void +agflags_init(void) +{ + agflags_cmd.name = _("agflags"); + agflags_cmd.cfunc = agflags_f; + agflags_cmd.argmin = 2; + agflags_cmd.argmax = 4; + agflags_cmd.flags = CMD_NOMAP_OK; + agflags_cmd.args = _("[-d 0|1] -a agno"); + agflags_cmd.oneline = _("Get or set the flags of an AG"); + agflags_cmd.help = agflags_help; + + if (expert) + add_command(&agflags_cmd); +} diff -rNu xfs-cmds/xfsprogs/io/init.c /home/ldap/campo/xfs-cmds/xfsprogs/io/init.c --- xfs-cmds/xfsprogs/io/init.c 2007-07-24 18:07:17.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/io/init.c 2007-08-31 14:10:19.697443490 +0200 @@ -54,6 +54,7 @@ static void init_commands(void) { + agflags_init(); attr_init(); bmap_init(); fadvise_init(); diff -rNu xfs-cmds/xfsprogs/io/Makefile /home/ldap/campo/xfs-cmds/xfsprogs/io/Makefile --- xfs-cmds/xfsprogs/io/Makefile 2006-06-17 08:12:23.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/io/Makefile 2007-08-13 10:42:08.536364577 +0200 @@ -10,7 +10,8 @@ HFILES = init.h io.h CFILES = init.c \ attr.c bmap.c file.c freeze.c fsync.c getrusage.c imap.c mmap.c \ - open.c parent.c pread.c prealloc.c pwrite.c shutdown.c truncate.c + open.c parent.c pread.c prealloc.c pwrite.c shutdown.c truncate.c \ + agflags.c LLDLIBS = $(LIBXCMD) $(LIBHANDLE) LTDEPENDENCIES = $(LIBXCMD) $(LIBHANDLE) diff -rNu xfs-cmds/xfsprogs/man/man8/xfs_io.8 /home/ldap/campo/xfs-cmds/xfsprogs/man/man8/xfs_io.8 --- xfs-cmds/xfsprogs/man/man8/xfs_io.8 2007-07-27 17:49:00.000000000 +0200 +++ /home/ldap/campo/xfs-cmds/xfsprogs/man/man8/xfs_io.8 2007-08-31 14:05:51.175595207 +0200 @@ -524,6 +524,15 @@ .IP .B [NOTE: Not currently operational on Linux.] .PD +.TP +.BR agflags " [ \-d " 0|1 " ] \-a " agno +This command get or set the different flags of the given AG. In moment the +only modifiable flag is XFS_AGF_FLAGS_ALLOC_DENY. +.RS 1.0i +.PD 0 +.TP 0.4i +.B \-d +0 or 1 to (un)set XFS_AGF_FLAGS_ALLOC_DENY. .SH SEE ALSO .BR mkfs.xfs (8), --------------020905060609070803010108-- From owner-xfs@oss.sgi.com Mon Sep 3 07:24:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 07:24:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l83EOL4p026025 for ; Mon, 3 Sep 2007 07:24:22 -0700 Received: by wa-out-1112.google.com with SMTP id k22so2006145waf for ; Mon, 03 Sep 2007 07:24:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aTi30IJKh0YgT+ExNbBZoaMsVt9qejvbMeGj8m9YhicBJinRnUwfhOUfKLr71GSdJY/qJDGMOzPWEARlJZtvWXwZUNMSWK/pngB4VntwIol7yYhP8LlllaiCNAdw4GvH/yWxkMMO4JgOlJv7/cyGtjclqBRahDm9wZH4muPad80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MKjkRmTzyAV7qIuNyZ6qGyAdazdIkEUvDo+5UFB+2g8lvSzLgGDNgOmOfPSccM5lA3gQvgRtSjClxEiZo3Rc4UoCeLVFvJcfpke8QSMvi8XG+uv6L6cf78Sb4rJPDRjctcWSojNqT+0HndKeUZ5/9+C27sXsCCo35cAUmCqmCrU= Received: by 10.115.90.1 with SMTP id s1mr3138733wal.1188829461758; Mon, 03 Sep 2007 07:24:21 -0700 (PDT) Received: by 10.114.13.15 with HTTP; Mon, 3 Sep 2007 07:24:21 -0700 (PDT) Message-ID: <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> Date: Mon, 3 Sep 2007 17:24:21 +0300 From: Raz To: "David Chinner" Subject: Re: raid50 and 9TB volumes Cc: linux-xfs@oss.sgi.com In-Reply-To: <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d96567b0707160542t2144c382mbfe3da92f0990694@mail.gmail.com> <5d96567b0707160653m5951fac9v5a56bb4c92174d63@mail.gmail.com> <20070716221831.GE31489@sgi.com> <18076.1449.138328.66699@notabene.brown> <20070717001205.GI31489@sgi.com> <18076.4940.845633.149160@notabene.brown> <20070717005854.GL31489@sgi.com> <5d96567b0707222309y61480271xa8220a0b179764e0@mail.gmail.com> <20070724010105.GN31489@sgi.com> <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> X-archive-position: 12754 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Dave hello. What is the curret status of this problem ? If you recall , xfs in 32bit over 10 TB md device ( raid50 in this case) sees only 8TB ( and no more). The disks I am using are 750GB hitachi. kernel is 2.6.17. thank you raz On 8/7/07, Raz wrote: > On 7/24/07, David Chinner wrote: > > On Mon, Jul 23, 2007 at 09:09:03AM +0300, Raz wrote: > > > My QA to re-installed the system. same kernel, different results. now, > > > /proc/paritions > > > reports : > > > 9 1 5114281984 md1 > > > 9 2 5128001536 md2 > > > 9 3 10242281472 md3 > > > > > > blockdev --getsize64 /dev/md3 > > > 10488096227328 > > > > > > but xfs keeps on crashing. when formatting it ot 6.3 TB we're OK. when > > > letting xfs's mkfs choose the > > > > So at 6.3TB everything is ok. At what point does it start having > > problems? 6.4TB, 6.8TB, 8TB, 9TB? > over 8 TB. we checked several times. in 8.5 it crashes. > > I know Neil pointed out that you shouldn't have 10TB but closer to > > 7TB - is this true? > the drives are of 750 GB each. > > Cheers, > > > > Dave. > > -- > > Dave Chinner > > Principal Engineer > > SGI Australian Software Group > > > > > -- > Raz > -- Raz From owner-xfs@oss.sgi.com Mon Sep 3 12:28:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 12:28:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l83JSI4p009335 for ; Mon, 3 Sep 2007 12:28:20 -0700 Received: from [89.54.161.50] (helo=[192.168.178.25]) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ISH52-0003S2-DN for linux-xfs@oss.sgi.com; Mon, 03 Sep 2007 20:55:25 +0200 Date: Mon, 3 Sep 2007 20:55:19 +0200 (CEST) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: linux-xfs@oss.sgi.com Subject: Re: raid50 and 9TB volumes In-Reply-To: <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> Message-ID: References: <5d96567b0707160542t2144c382mbfe3da92f0990694@mail.gmail.com> <5d96567b0707160653m5951fac9v5a56bb4c92174d63@mail.gmail.com> <20070716221831.GE31489@sgi.com> <18076.1449.138328.66699@notabene.brown> <20070717001205.GI31489@sgi.com> <18076.4940.845633.149160@notabene.brown> <20070717005854.GL31489@sgi.com> <5d96567b0707222309y61480271xa8220a0b179764e0@mail.gmail.com> <20070724010105.GN31489@sgi.com> <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii X-archive-position: 12755 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Mon, 3 Sep 2007, Raz wrote: > What is the curret status of this problem ? If you recall , xfs in 32bit > over 10 TB md device ( raid50 in this case) sees only 8TB ( and no more). > The disks I am using are 750GB hitachi. > kernel is 2.6.17. dunno about this particular issue, but you meant "kernel 2.6.17.7 or higher", right? If not: http://oss.sgi.com/projects/xfs/faq.html#dir2 -- BOFH excuse #374: It's the InterNIC's fault. From owner-xfs@oss.sgi.com Mon Sep 3 17:49:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 17:49:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l840nO4p024507 for ; Mon, 3 Sep 2007 17:49:26 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22719; Tue, 4 Sep 2007 10:49:16 +1000 Message-ID: <46DCAC20.9080002@sgi.com> Date: Tue, 04 Sep 2007 10:51:44 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Chinner CC: Christian Kujau , xfs@oss.sgi.com Subject: Re: lockdep annotations? References: <46DB7586.7040309@sgi.com> <20070903090103.GG734179@sgi.com> In-Reply-To: <20070903090103.GG734179@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12756 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Mon, Sep 03, 2007 at 12:46:30PM +1000, Lachlan McIlroy wrote: >> This is a locking inversion between the iolock and iprune_mutex. I >> hadn't seen this one before. Was your system running low on memory >> at the time? >> >> We can't drop the iolock in the write path so we'll have to avoid >> acquiring the iolock in xfs_ireclaim() which means we'll need another >> way to synchronise with xfs_sync_inodes(). > > I don't think a deadlock exists here - we have to be going through > memory reclaim to hit this inversion, so the only place that we > can deadlock is if we are holding the iprune_mutex across a memory > allocation. I don't think we do that.... > > Not to mention that the inode we hold the iolock on won't be on the > inode free list so we won't ever try to lock it during reclaim, either. > Yep. This is just another case where we've confused lockdep. From owner-xfs@oss.sgi.com Mon Sep 3 19:50:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Sep 2007 19:50:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l842ot4p010319 for ; Mon, 3 Sep 2007 19:50:56 -0700 Received: from Liberator.local (sandeen.net [209.173.210.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id ED14518009C3F; Mon, 3 Sep 2007 21:50:55 -0500 (CDT) Message-ID: <46DCC80F.8030000@sandeen.net> Date: Mon, 03 Sep 2007 21:50:55 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christian Kujau CC: linux-xfs@oss.sgi.com Subject: Re: raid50 and 9TB volumes References: <5d96567b0707160542t2144c382mbfe3da92f0990694@mail.gmail.com> <5d96567b0707160653m5951fac9v5a56bb4c92174d63@mail.gmail.com> <20070716221831.GE31489@sgi.com> <18076.1449.138328.66699@notabene.brown> <20070717001205.GI31489@sgi.com> <18076.4940.845633.149160@notabene.brown> <20070717005854.GL31489@sgi.com> <5d96567b0707222309y61480271xa8220a0b179764e0@mail.gmail.com> <20070724010105.GN31489@sgi.com> <5d96567b0708070220u23c895ffk54849fca947b5100@mail.gmail.com> <5d96567b0709030724w3098395bnbd511fa3819e5b22@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 12757 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christian Kujau wrote: > On Mon, 3 Sep 2007, Raz wrote: >> What is the curret status of this problem ? If you recall , xfs in 32bit >> over 10 TB md device ( raid50 in this case) sees only 8TB ( and no more). >> The disks I am using are 750GB hitachi. >> kernel is 2.6.17. > > dunno about this particular issue, but you meant "kernel 2.6.17.7 or > higher", right? If not: http://oss.sgi.com/projects/xfs/faq.html#dir2 That shouldn't be affected by volume size. Raz, are you certain that the MD volume is in good shape at this point, after Neil's questions? If it's something you can test on, I'd suggest getting lmdd and writing a pattern directly to the block device, spanning the 8T point, then go read it back & double check that all is well. XFS certainly has been tested at 8T and above; if I had to bet on it, I'd bet at a problem in another layer, or the configuration. -Eric From owner-xfs@oss.sgi.com Tue Sep 4 05:23:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 05:23:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_33, J_CHICKENPOX_62 autolearn=no version=3.2.0-pre1-r499012 Received: from bay0-omc2-s5.bay0.hotmail.com (bay0-omc2-s5.bay0.hotmail.com [65.54.246.141]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l84CNU4p020724 for ; Tue, 4 Sep 2007 05:23:31 -0700 Received: from hotmail.com ([65.54.174.78]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 4 Sep 2007 05:23:31 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Sep 2007 05:23:30 -0700 Message-ID: Received: from 85.36.106.214 by BAY103-DAV6.phx.gbl with DAV; Tue, 04 Sep 2007 12:23:27 +0000 X-Originating-IP: [85.36.106.214] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Christoph Lameter" Cc: , "David Chinner" , , "Marco Berizzi" References: Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) Date: Tue, 4 Sep 2007 14:22:04 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 04 Sep 2007 12:23:30.0884 (UTC) FILETIME=[67773040:01C7EEEE] X-archive-position: 12758 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Christoph Lameter wrote: > Could you try this with the SLUB allocator and then boot with > "slub_debug"? Hi Christoph, I have upgraded to 2.6.22.5 and I have selected the SLUB. I have also added append=slub_debug to lilo.conf After a week uptime I got this error. I hope it will be useful for you. Linux version 2.6.22.5 (root@Mimosa) (gcc version 3.3.5) #1 Mon Aug 27 16:57:18 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000a000000 (usable) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 160MB LOWMEM available. Entering add_active_range(0, 0, 40960) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 40960 early_node_map[1] active PFN ranges 0: 0 -> 40960 On node 0 totalpages: 40960 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 288 pages used for memmap Normal zone: 36576 pages, LIFO batch:7 DMI 2.1 present. Allocating PCI resources starting at 10000000 (gap: 0a000000:f5ff0000) Built 1 zonelists. Total pages: 40640 Kernel command line: auto BOOT_IMAGE=Linux ro root=301 slub_debug Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (01141000) Enabling fast FPU save and restore... done. Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Detected 267.281 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 158956k/163840k available (1975k kernel code, 4452k reserved, 628k data, 160k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB) vmalloc : 0xca800000 - 0xfffb5000 ( 855 MB) lowmem : 0xc0000000 - 0xca000000 ( 160 MB) .init : 0xc038e000 - 0xc03b6000 ( 160 kB) .data : 0xc02edd86 - 0xc038afa0 ( 628 kB) .text : 0xc0100000 - 0xc02edd86 (1975 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 535.19 BogoMIPS (lpj=1070387) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040 00000000 00000000 00000000 Compat vDSO mapped to ffffe000. CPU: Intel Celeron (Covington) stepping 00 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20070126] ACPI: Unable to load the System Description Tables NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfda61, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, * this clock source is slow. Consider trying other clock sources PCI quirk: region 6100-613f claimed by PIIX4 ACPI PCI quirk: region 5f00-5f0f claimed by PIIX4 SMB PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0 Time: tsc clocksource has been installed. PCI: Bridge: 0000:00:01.0 IO window: b000-bfff MEM window: efe00000-efefffff PREFETCH window: e5c00000-e7cfffff NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered SGI XFS with no debug enabled io scheduler noop registered io scheduler deadline registered (default) Limiting direct PCI/PCI transfers. Boot video device is 0000:01:00.0 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot 0000:00:07.1 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive hda: selected mode 0x42 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hdc: CRD-8160B, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 > PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice nf_conntrack version 0.5.0 (1280 buckets, 10240 max) ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Using IPI Shortcut mode input: AT Translated Set 2 keyboard as /class/input/input0 Filesystem "hda1": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda1 Ending clean XFS mount for filesystem: hda1 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 160k freed Adding 330584k swap on /dev/hda9. Priority:-1 extents:1 across:330584k Filesystem "hda1": Disabling barriers, not supported by the underlying device Filesystem "hda1": Disabling barriers, not supported by the underlying device PCI: setting IRQ 10 as level-triggered PCI: Found IRQ 10 for device 0000:00:09.0 3c59x: Donald Becker and others. 0000:00:09.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001dc00. PCI: setting IRQ 11 as level-triggered PCI: Found IRQ 11 for device 0000:00:0a.0 0000:00:0a.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001da00. PCI: setting IRQ 9 as level-triggered PCI: Found IRQ 9 for device 0000:00:0b.0 PCI: Sharing IRQ 9 with 0000:00:07.2 0000:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001d800. Filesystem "hda5": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda5 Ending clean XFS mount for filesystem: hda5 Filesystem "hda6": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda6 Ending clean XFS mount for filesystem: hda6 Filesystem "hda7": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda7 Ending clean XFS mount for filesystem: hda7 Filesystem "hda8": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda8 Ending clean XFS mount for filesystem: hda8 eth0: setting full-duplex. eth1: setting full-duplex. eth2: setting full-duplex. swapper: page allocation failure. order:2, mode:0x4020 [] __alloc_pages+0x1ed/0x2e0 [] allocate_slab+0x4b/0x90 [] new_slab+0x32/0x150 [] __slab_alloc+0xcb/0x120 [] __slab_alloc+0x79/0x120 [] tcp_collapse+0x113/0x3b0 [] __kmalloc_track_caller+0x75/0x80 [] tcp_collapse+0x113/0x3b0 [] __alloc_skb+0x4e/0x100 [] tcp_collapse+0x113/0x3b0 [] tcp_prune_queue+0x7d/0x180 [] tcp_data_queue+0x2b9/0x710 [] ipt_do_table+0x271/0x360 [] tcp_rcv_established+0x1cb/0x630 [] tcp_v4_do_rcv+0xe3/0xf0 [] tcp_v4_rcv+0x67f/0x800 [] ip_local_deliver_finish+0x0/0x1a0 [] nf_hook_slow+0x66/0xe0 [] ip_local_deliver+0x11c/0x230 [] ip_local_deliver_finish+0x0/0x1a0 [] ip_rcv+0x232/0x4d0 [] ip_rcv_finish+0x0/0x2a0 [] do_IRQ+0x3e/0x80 [] netif_receive_skb+0x207/0x290 [] process_backlog+0x77/0xf0 [] net_rx_action+0x6c/0xf0 [] __do_softirq+0x74/0x90 [] do_softirq+0x26/0x30 [] do_IRQ+0x3e/0x80 [] common_interrupt+0x23/0x28 [] default_idle+0x0/0x40 [] default_idle+0x27/0x40 [] cpu_idle+0x5c/0x70 [] start_kernel+0x17c/0x1c0 [] unknown_bootoption+0x0/0x1a0 ======================= Mem-info: DMA per-cpu: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Normal per-cpu: CPU 0: Hot: hi: 42, btch: 7 usd: 4 Cold: hi: 14, btch: 3 usd: 11 Active:29564 inactive:4492 dirty:418 writeback:0 unstable:0 free:845 slab:4194 mapped:901 pagetables:210 bounce:0 DMA free:632kB min:160kB low:200kB high:240kB active:9136kB inactive:1888kB present:16256kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 142 Normal free:2748kB min:1448kB low:1808kB high:2172kB active:109120kB inactive:16080kB present:146304kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 DMA: 48*4kB 3*8kB 0*16kB 1*32kB 0*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 632kB Normal: 571*4kB 40*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2748kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 330584kB Total swap = 330584kB Free swap: 330584kB 40960 pages of RAM 0 pages of HIGHMEM 1170 reserved pages 18768 pages shared 0 pages swap cached 418 pages dirty 0 pages writeback 901 pages mapped 4194 pages slab 210 pages pagetables From owner-xfs@oss.sgi.com Tue Sep 4 10:23:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 10:23:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l84HN34p009016 for ; Tue, 4 Sep 2007 10:23:03 -0700 Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [150.166.1.51]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 8D5D59088B for ; Tue, 4 Sep 2007 10:23:01 -0700 (PDT) Received: from clameter (helo=localhost) by schroedinger.engr.sgi.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1ISbjW-0001Vr-00; Tue, 04 Sep 2007 09:58:34 -0700 Date: Tue, 4 Sep 2007 09:58:34 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Marco Berizzi cc: linux-kernel@vger.kernel.org, David Chinner , xfs@oss.sgi.com, mel@skynet.ie Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 12759 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: clameter@sgi.com Precedence: bulk X-list: xfs On Tue, 4 Sep 2007, Marco Berizzi wrote: > After a week uptime I got this error. I hope it > will be useful for you. Yes indeed but this is a different type of failure. Looks like a higher allocation failure in the networking code. Someone created objects that required an order 2 allocations that failed. > SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Slub is restricted to order 0 and 1 allocs. > PREFETCH window: e5c00000-e7cfffff > NET: Registered protocol family 2 > IP route cache hash table entries: 2048 (order: 1, 8192 bytes) > TCP established hash table entries: 8192 (order: 4, 65536 bytes) > TCP bind hash table entries: 8192 (order: 3, 32768 bytes) Hmmmm. > eth2: setting full-duplex. > swapper: page allocation failure. order:2, mode:0x4020 > [] __alloc_pages+0x1ed/0x2e0 > [] allocate_slab+0x4b/0x90 > [] new_slab+0x32/0x150 > [] __slab_alloc+0xcb/0x120 > [] __slab_alloc+0x79/0x120 > [] tcp_collapse+0x113/0x3b0 tcp_collapse? This is due to a network configuration that required an order 2 kmalloc block. Jumbo frames? From owner-xfs@oss.sgi.com Tue Sep 4 16:49:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 16:49:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l84NnX4p002713 for ; Tue, 4 Sep 2007 16:49:36 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA18793; Wed, 5 Sep 2007 09:49:32 +1000 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 l84NnTdD6314321; Wed, 5 Sep 2007 09:49:32 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l84NnQQc6315667; Wed, 5 Sep 2007 09:49:26 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Sep 2007 09:49:26 +1000 From: David Chinner To: Shailendra Tripathi Cc: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070904234926.GI734179@sgi.com> References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DDE4A2.1070204@agami.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12760 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Sep 04, 2007 at 04:05:06PM -0700, Shailendra Tripathi wrote: > Hi, > Can someone explain how not checking the flushiter can losse > filesize updates. > Let me the take the case mentioned here in the fix statement: > > a. Clustered inode create - flush iter - X( 0) > b. size update --> flush iter --> Y > > X and Y will always hold as: X <= Y, that is, it is not possible to have > X >Y (unless size update is non -transactional. As far as I know, size > update is always transactional.) Size updates are not transactional. They are accidentally logged in other transactions (e.g. truncates) but size updates due to data writes are never logged. When we write an inode, we take the latest in memory size and write it to disk without logging that change so we can't rely on log recovery to get it right simply by replaying transactions. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Sep 4 16:51:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 16:51:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l84Npf4p003072 for ; Tue, 4 Sep 2007 16:51:44 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA18881; Wed, 5 Sep 2007 09:51:41 +1000 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 l84NpedD6315321; Wed, 5 Sep 2007 09:51:40 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l84NpdPE6315910; Wed, 5 Sep 2007 09:51:39 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Sep 2007 09:51:39 +1000 From: David Chinner To: David Chinner Cc: Shailendra Tripathi , Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070904235139.GJ734179@sgi.com> References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> <20070904234926.GI734179@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070904234926.GI734179@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12761 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Sep 05, 2007 at 09:49:26AM +1000, David Chinner wrote: > On Tue, Sep 04, 2007 at 04:05:06PM -0700, Shailendra Tripathi wrote: > > Hi, > > Can someone explain how not checking the flushiter can losse > > filesize updates. > > Let me the take the case mentioned here in the fix statement: > > > > a. Clustered inode create - flush iter - X( 0) > > b. size update --> flush iter --> Y > > > > X and Y will always hold as: X <= Y, that is, it is not possible to have > > X >Y (unless size update is non -transactional. As far as I know, size > > update is always transactional.) > > Size updates are not transactional. They are accidentally logged in s/accidentally/intentionally/ > other transactions (e.g. truncates) but size updates due to data > writes are never logged. When we write an inode, we take the latest > in memory size and write it to disk without logging that change > so we can't rely on log recovery to get it right simply by replaying > transactions. > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Sep 4 17:14:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 17:14:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_20,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l850Ej4p006337 for ; Tue, 4 Sep 2007 17:14:48 -0700 Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id l84N4ldm017111; Tue, 4 Sep 2007 16:04:50 -0700 Received: from [10.123.1.84] (timf-64.agami.com [10.123.1.84]) (authenticated bits=0) by agami.com (8.12.11/8.12.11) with ESMTP id l84N4iVQ027598; Tue, 4 Sep 2007 16:04:44 -0700 Message-ID: <46DDE4A2.1070204@agami.com> Date: Tue, 04 Sep 2007 16:05:06 -0700 From: Shailendra Tripathi User-Agent: Thunderbird 1.5.0.13 (X11/20070809) MIME-Version: 1.0 To: Lachlan McIlroy CC: xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> In-Reply-To: <46D6279F.40601@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-archive-position: 12762 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Hi, Can someone explain how not checking the flushiter can losse filesize updates. Let me the take the case mentioned here in the fix statement: a. Clustered inode create - flush iter - X( 0) b. size update --> flush iter --> Y X and Y will always hold as: X <= Y, that is, it is not possible to have X >Y (unless size update is non -transactional. As far as I know, size update is always transactional.) There are 2 cases here: a) log of Y reached to the disk --> 1) inode with flush iter was reached 2) inode didn't make. b) log of Y didn't reach the disk --> flush_iter Y should have never reached disk In none of cases, I can see the possibility that size update can be lost becuase of replaying of the logs in the sequential order. If Log of Y didn't reach, does it not make sense to have the flush_iter and size correctly set to the last known transaction on the disk. To me, it appears unsafe to do as the inode state will not match the state of the last known transaction after recovery. Regards, Shailendra Lachlan McIlroy wrote: > Log replay of clustered inodes currently ignores the flushiter > field in the inode that is used to determine if the on-disk inode > is more up to date than the copy in the log. As a result during > log replay the newer inode is being overwritten with an older > version and file size updates are being lost. > > I haven't handled the case of the flushiter counter overflowing > but that shouldn't be a problem in this case. The log buffer > contains newly created inodes so their flushiter values will be 0 > and the on-disk inodes should not be much greater. > > Lachlan > ------------------------------------------------------------------------ > > --- fs/xfs/xfs_log_recover.c_1.322 2007-08-27 17:45:45.000000000 +1000 > +++ fs/xfs/xfs_log_recover.c 2007-08-30 11:50:44.000000000 +1000 > @@ -1866,6 +1866,27 @@ xlog_recover_do_inode_buffer( > } > > /* > + * Check if we need to recover an inode from a buffer > + */ > +int > +xfs_recover_inode( > + char *dest, > + char *src) > +{ > + xfs_dinode_t *dip = (xfs_dinode_t *)dest; > + xfs_dinode_t *dilp = (xfs_dinode_t*)src; > + > + if ((be16_to_cpu(dip->di_core.di_magic) == XFS_DINODE_MAGIC) && > + (be16_to_cpu(dilp->di_core.di_magic) == XFS_DINODE_MAGIC) && > + (be16_to_cpu(dilp->di_core.di_flushiter) < > + be16_to_cpu(dip->di_core.di_flushiter))) { > + return 1; > + } > + > + return 0; > +} > + > +/* > * Perform a 'normal' buffer recovery. Each logged region of the > * buffer should be copied over the corresponding region in the > * given buffer. The bitmap in the buf log format structure indicates > @@ -1917,6 +1938,13 @@ xlog_recover_do_reg_buffer( > -1, 0, XFS_QMOPT_DOWARN, > "dquot_buf_recover"); > } > + /* > + * Sanity check if this is an inode buffer. > + */ > + if (!error) > + error = xfs_recover_inode(xfs_buf_offset(bp, > + (uint)bit << XFS_BLI_SHIFT), > + item->ri_buf[i].i_addr); > if (!error) > memcpy(xfs_buf_offset(bp, > (uint)bit << XFS_BLI_SHIFT), /* dest */ > From owner-xfs@oss.sgi.com Tue Sep 4 18:19:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 18:19:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l851Jn4p015559 for ; Tue, 4 Sep 2007 18:19:50 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22501; Wed, 5 Sep 2007 11:19:41 +1000 Message-ID: <46DE042D.8060103@sgi.com> Date: Wed, 05 Sep 2007 11:19:41 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Shailendra Tripathi CC: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> In-Reply-To: <46DDE4A2.1070204@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12763 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Shailendra Tripathi wrote: > Hi, > Can someone explain how not checking the flushiter can losse > filesize updates. > Let me the take the case mentioned here in the fix statement: > > a. Clustered inode create - flush iter - X( 0) > b. size update --> flush iter --> Y > > X and Y will always hold as: X <= Y, that is, it is not possible to have > X >Y (unless size update is non -transactional. As far as I know, size > update is always transactional.) > > There are 2 cases here: > a) log of Y reached to the disk --> 1) inode with flush iter was > reached 2) inode didn't make. > b) log of Y didn't reach the disk --> flush_iter Y should have never > reached disk > > In none of cases, I can see the possibility that size update can be lost > becuase of replaying of the logs in the sequential order. If Log of Y > didn't reach, does it not make sense to have the flush_iter and size > correctly set to the last known transaction on the disk. To me, it > appears unsafe to do as the inode state will not match the state of the > last known transaction after recovery. > > Regards, > Shailendra Dave answered this but yes this is a case where we are breaking the transaction model IMO. And my understanding is that we are doing this for performance reasons. One of Lachlan's proposals (IIRC) was to log the size change before the ondisk size change in xfs_aops.c/xfs_setfilesize() and thus follow the model but questions were raised about introducing performance overhead of log traffic in the write path. --Tim From owner-xfs@oss.sgi.com Tue Sep 4 18:38:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 18:38:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l851bw4p017927 for ; Tue, 4 Sep 2007 18:38:01 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23204; Wed, 5 Sep 2007 11:37:50 +1000 Message-ID: <46DE0906.2040602@sgi.com> Date: Wed, 05 Sep 2007 11:40:22 +1000 From: Lachlan McIlroy User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Timothy Shimmin CC: Shailendra Tripathi , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> <46DE042D.8060103@sgi.com> In-Reply-To: <46DE042D.8060103@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12764 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Timothy Shimmin wrote: > Shailendra Tripathi wrote: >> Hi, >> Can someone explain how not checking the flushiter can losse >> filesize updates. >> Let me the take the case mentioned here in the fix statement: >> >> a. Clustered inode create - flush iter - X( 0) >> b. size update --> flush iter --> Y >> >> X and Y will always hold as: X <= Y, that is, it is not possible to >> have X >Y (unless size update is non -transactional. As far as I know, >> size update is always transactional.) >> >> There are 2 cases here: >> a) log of Y reached to the disk --> 1) inode with flush iter was >> reached 2) inode didn't make. >> b) log of Y didn't reach the disk --> flush_iter Y should have never >> reached disk >> >> In none of cases, I can see the possibility that size update can be >> lost becuase of replaying of the logs in the sequential order. If Log >> of Y didn't reach, does it not make sense to have the flush_iter and >> size correctly set to the last known transaction on the disk. To me, >> it appears unsafe to do as the inode state will not match the state of >> the last known transaction after recovery. >> >> Regards, >> Shailendra > > Dave answered this but yes this is a case where we are breaking > the transaction model IMO. And my understanding is that we are doing > this for performance reasons. > One of Lachlan's proposals (IIRC) was to log the size change before the > ondisk size change in xfs_aops.c/xfs_setfilesize() > and thus follow the model but questions were raised about introducing > performance overhead of log traffic in the write path. > It would make life easier to do it that way - we wouldn't have to check the flushiter field of the ondisk inode because we know we will end up with the same thing by just replaying the log. But since the addition of the flushiter stuff pre-dates the NULL files changes there must be another reason we need it. Previously the size change would get logged with an extent allocation transaction but extending a file within the same last block would not send the new file size to the log. I think that may have been the reason for needing the flushiter stuff. If we log the file size change in xfs_setfilesize() we may not need the flushiter stuff at all, hmmm maybe for timestamp updates? From owner-xfs@oss.sgi.com Tue Sep 4 23:54:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Sep 2007 23:54:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l856sF4p029545 for ; Tue, 4 Sep 2007 23:54:18 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA05612; Wed, 5 Sep 2007 16:54:14 +1000 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 l856sCdD6572929; Wed, 5 Sep 2007 16:54:13 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l856s7aa6574796; Wed, 5 Sep 2007 16:54:07 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Sep 2007 16:54:07 +1000 From: David Chinner To: Lachlan McIlroy Cc: Timothy Shimmin , Shailendra Tripathi , xfs-dev , xfs-oss Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes Message-ID: <20070905065407.GO734179@sgi.com> References: <46D6279F.40601@sgi.com> <46DDE4A2.1070204@agami.com> <46DE042D.8060103@sgi.com> <46DE0906.2040602@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DE0906.2040602@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 12765 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Sep 05, 2007 at 11:40:22AM +1000, Lachlan McIlroy wrote: > >Dave answered this but yes this is a case where we are breaking > >the transaction model IMO. And my understanding is that we are doing > >this for performance reasons. > >One of Lachlan's proposals (IIRC) was to log the size change before the > >ondisk size change in xfs_aops.c/xfs_setfilesize() > >and thus follow the model but questions were raised about introducing > >performance overhead of log traffic in the write path. > > It would make life easier to do it that way - we wouldn't have to check > the flushiter field of the ondisk inode because we know we will end up > with the same thing by just replaying the log. But since the addition > of the flushiter stuff pre-dates the NULL files changes there must be > another reason we need it. Previously the size change would get logged > with an extent allocation transaction but extending a file within the > same last block would not send the new file size to the log. I think > that may have been the reason for needing the flushiter stuff. If we > log the file size change in xfs_setfilesize() we may not need the > flushiter stuff at all, hmmm maybe for timestamp updates? atime, size updates and inode version format conversion may be written without a transaction first logging the change. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Sep 5 01:14:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 01:14:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r499012 Received: from bay0-omc1-s17.bay0.hotmail.com (bay0-omc1-s17.bay0.hotmail.com [65.54.246.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l858EQ4p015973 for ; Wed, 5 Sep 2007 01:14:29 -0700 Received: from hotmail.com ([65.54.174.84]) by bay0-omc1-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 01:14:26 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Sep 2007 01:14:26 -0700 Message-ID: Received: from 85.36.106.198 by BAY103-DAV12.phx.gbl with DAV; Wed, 05 Sep 2007 08:14:21 +0000 X-Originating-IP: [85.36.106.198] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Christoph Lameter" Cc: , "David Chinner" , , , "Marco Berizzi" References: Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) Date: Wed, 5 Sep 2007 10:12:56 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 05 Sep 2007 08:14:26.0404 (UTC) FILETIME=[C6464240:01C7EF94] X-archive-position: 12766 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs "Christoph Lameter" wrote: > On Tue, 4 Sep 2007, Marco Berizzi wrote: > > > After a week uptime I got this error. I hope it > > will be useful for you. > > Yes indeed but this is a different type of failure. Looks like a higher > allocation failure in the networking code. Someone created objects that > required an order 2 allocations that failed. > > > SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 > > Slub is restricted to order 0 and 1 allocs. > > > PREFETCH window: e5c00000-e7cfffff > > NET: Registered protocol family 2 > > IP route cache hash table entries: 2048 (order: 1, 8192 bytes) > > TCP established hash table entries: 8192 (order: 4, 65536 bytes) > > TCP bind hash table entries: 8192 (order: 3, 32768 bytes) > > Hmmmm. > > > eth2: setting full-duplex. > > swapper: page allocation failure. order:2, mode:0x4020 > > [] __alloc_pages+0x1ed/0x2e0 > > [] allocate_slab+0x4b/0x90 > > [] new_slab+0x32/0x150 > > [] __slab_alloc+0xcb/0x120 > > [] __slab_alloc+0x79/0x120 > > [] tcp_collapse+0x113/0x3b0 > > tcp_collapse? This is due to a network configuration that required an > order 2 kmalloc block. Jumbo frames? I don't use jumbo frames. Hardware is very old (celeron with 3com 3c905). From owner-xfs@oss.sgi.com Wed Sep 5 02:15:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 02:15:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l859FU4p024958 for ; Wed, 5 Sep 2007 02:15:32 -0700 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11186; Wed, 5 Sep 2007 19:15:23 +1000 Message-ID: <46DE73AA.1090706@sgi.com> Date: Wed, 05 Sep 2007 19:15:22 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Morton , xfs-oss , Linux Kernel Mailing List Subject: some XFS fixes for 2.6.23 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 12767 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Hi Linus, We have a few XFS fixes for 2.6.23 (meant to do this earlier). They have been in sgi dev tree and mm tree for a while. Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus With shortlog: ------------------------- Christoph Hellwig (4): [XFS] Fix sparse NULL vs 0 warnings [XFS] Fix sparse warning in kmem_shake_allow [XFS] fix ASSERT and ASSERT_ALWAYS [XFS] fix sparse shadowed variable warnings David Chinner (1): [XFS] Set filestreams object timeout to something sane. Eric Sandeen (1): [XFS] fix nasty quota hashtable allocation bug ------------------------- This will update the following files: fs/xfs/linux-2.6/kmem.h | 2 +- fs/xfs/linux-2.6/xfs_aops.c | 8 ++++---- fs/xfs/linux-2.6/xfs_globals.c | 2 +- fs/xfs/quota/xfs_qm.c | 3 ++- fs/xfs/support/debug.h | 10 ++++++---- fs/xfs/xfs_da_btree.c | 1 - fs/xfs/xfs_log.c | 12 ++++++------ fs/xfs/xfs_log_recover.c | 12 ++++++------ 8 files changed, 26 insertions(+), 24 deletions(-) through these commits: commit 5995cb7d805496362e5af73235145667096fbc6f Author: Eric Sandeen Date: Thu Aug 16 16:49:11 2007 +1000 [XFS] fix nasty quota hashtable allocation bug This git mod: 77e4635ae191774526ed695482a151ac986f3806 converted to a "greedy" allocation interface, but for the quota hashtables it switched from allocating XFS_QM_HASHSIZE (nr of elements) xfs_dqhash_t's to allocating only XFS_QM_HASHSIZE *bytes* - quite a lot smaller! Then when we converted hsize "back" to nr of elements (the division line) hsize went to 0. This was leading to oopses when running any quota tests on the Fedora 8 test kernel, but the problem has been there for almost a year. SGI-PV: 968837 SGI-Modid: xfs-linux-melb:xfs-kern:29354a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 265c1fac38e37e828df09965406e9cc20bfa3588 Author: Christoph Hellwig Date: Thu Aug 16 15:38:19 2007 +1000 [XFS] fix sparse shadowed variable warnings - in xfs_probe_cluster rename the inner len to pg_len. There's no harm here because the outer len isn't used after the inner len comes into existence but it keeps the code clean. - in xfs_da_do_buf remove the inner i because they don't overlap and they are both the same type. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29311a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit ee5c80239d5f152d99f69165afbd115518353563 Author: Christoph Hellwig Date: Thu Aug 16 15:38:08 2007 +1000 [XFS] fix ASSERT and ASSERT_ALWAYS - remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now complains about comparisons between pointers and 0 - add a standalone ASSERT implementation because defining it to ASSERT_ALWAYS means the string is expanded before the token passing stringification. This way we get the actual content of the assertion in the assfail message and don't overflow sparse's stringification buffer leading to sparse error messages. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29310a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 34521c5e4971d01f6ef650fdee59e07be6c2c5e3 Author: Christoph Hellwig Date: Thu Aug 16 15:37:57 2007 +1000 [XFS] Fix sparse warning in kmem_shake_allow We can't return a masked result of a __bitwise type. Compare it to 0 first to keep the behaviour without the warning. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29309a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 4b80916b29170744632356dd2e801f7c374676eb Author: Christoph Hellwig Date: Thu Aug 16 15:37:36 2007 +1000 [XFS] Fix sparse NULL vs 0 warnings Sparse now warns about comparing pointers to 0, so change all instance where that happens to NULL instead. SGI-PV: 968555 SGI-Modid: xfs-linux-melb:xfs-kern:29308a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 8da22d7a3690818f6d340baa0ea585e71f0c506f Author: David Chinner Date: Thu Aug 16 15:20:56 2007 +1000 [XFS] Set filestreams object timeout to something sane. SGI-PV: 968554 SGI-Modid: xfs-linux-melb:xfs-kern:29303a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin From owner-xfs@oss.sgi.com Wed Sep 5 04:08:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 04:08:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r499012 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l85B834p008955 for ; Wed, 5 Sep 2007 04:08:04 -0700 Received: from schroedinger.engr.sgi.com (schroedinger.engr.sgi.com [150.166.1.51]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id D3F9F90893 for ; Wed, 5 Sep 2007 04:08:01 -0700 (PDT) Received: from clameter (helo=localhost) by schroedinger.engr.sgi.com with local-esmtp (Exim 3.36 #1 (Debian)) id 1ISsBS-000276-00; Wed, 05 Sep 2007 03:32:30 -0700 Date: Wed, 5 Sep 2007 03:32:30 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Marco Berizzi cc: linux-kernel@vger.kernel.org, David Chinner , xfs@oss.sgi.com, mel@skynet.ie Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 12768 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: clameter@sgi.com Precedence: bulk X-list: xfs On Wed, 5 Sep 2007, Marco Berizzi wrote: > > tcp_collapse? This is due to a network configuration that required an > > order 2 kmalloc block. Jumbo frames? > > I don't use jumbo frames. Hardware is > very old (celeron with 3com 3c905). Something must be doing allocations that requires between 8k and 16k that SLUB cannot satisfy from order 0 or order 1 allocations. From owner-xfs@oss.sgi.com Wed Sep 5 06:35:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Sep 2007 06:35:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_33, J_CHICKENPOX_62 autolearn=no version=3.2.0-pre1-r499012 Received: from bay0-omc1-s22.bay0.hotmail.com (bay0-omc1-s22.bay0.hotmail.com [65.54.246.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l85DZQ4p001433 for ; Wed, 5 Sep 2007 06:35:28 -0700 Received: from hotmail.com ([65.54.174.78]) by bay0-omc1-s22.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Sep 2007 06:35:28 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Sep 2007 06:35:28 -0700 Message-ID: Received: from 85.36.106.198 by BAY103-DAV6.phx.gbl with DAV; Wed, 05 Sep 2007 13:35:27 +0000 X-Originating-IP: [85.36.106.198] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Christoph Lameter" Cc: , "David Chinner" , , , "Marco Berizzi" References: Subject: Re: kernel BUG at mm/slab.c:2980 (was Re: [] xfs_bmap_search_multi_extents+0x6f/0xe0) Date: Wed, 5 Sep 2007 15:34:02 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 05 Sep 2007 13:35:28.0036 (UTC) FILETIME=[9F1A0E40:01C7EFC1] X-archive-position: 12769 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Christoph Lameter wrote: > On Wed, 5 Sep 2007, Marco Berizzi wrote: > > > > tcp_collapse? This is due to a network configuration that required an > > > order 2 kmalloc block. Jumbo frames? > > > > I don't use jumbo frames. Hardware is > > very old (celeron with 3com 3c905). > > Something must be doing allocations that requires between 8k and 16k that > SLUB cannot satisfy from order 0 or order 1 allocations. Me again. Another report from another machine. Linux version 2.6.22.5 (root@Gemini) (gcc version 3.3.6) #1 Mon Aug 27 17:20:33 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000a000000 (usable) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 160MB LOWMEM available. Entering add_active_range(0, 0, 40960) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 40960 early_node_map[1] active PFN ranges 0: 0 - 40960 On node 0 totalpages: 40960 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 288 pages used for memmap Normal zone: 36576 pages, LIFO batch:7 DMI 2.1 present. Allocating PCI resources starting at 10000000 (gap: 0a000000:f5ff0000) Built 1 zonelists. Total pages: 40640 Kernel command line: auto BOOT_IMAGE=Linux ro root=301 slub_debug Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (01141000) Enabling fast FPU save and restore... done. Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Detected 267.302 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 158956k/163840k available (1975k kernel code, 4452k reserved, 628k data, 160k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfffb7000 - 0xfffff000 ( 288 kB) vmalloc : 0xca800000 - 0xfffb5000 ( 855 MB) lowmem : 0xc0000000 - 0xca000000 ( 160 MB) .init : 0xc038e000 - 0xc03b6000 ( 160 kB) .data : 0xc02edc46 - 0xc038afa0 ( 628 kB) .text : 0xc0100000 - 0xc02edc46 (1975 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 535.24 BogoMIPS (lpj=1070484) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff 00000000 00000000 00000000 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: After all inits, caps: 0183f9ff 00000000 00000000 00000040 00000000 00000000 00000000 Compat vDSO mapped to ffffe000. CPU: Intel Celeron (Covington) stepping 00 Checking 'hlt' instruction... OK. ACPI: Core revision 20070126 ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20070126] ACPI: Unable to load the System Description Tables NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfda61, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) * Found PM-Timer Bug on the chipset. Due to workarounds for a bug, * this clock source is slow. Consider trying other clock sources PCI quirk: region 6100-613f claimed by PIIX4 ACPI PCI quirk: region 5f00-5f0f claimed by PIIX4 SMB PCI: Using IRQ router PIIX/ICH [8086/7110] at 0000:00:07.0 PCI: setting IRQ 11 as level-triggered PCI: Found IRQ 11 for device 0000:00:07.2 PCI: Sharing IRQ 11 with 0000:00:0b.0 Time: tsc clocksource has been installed. PCI: Bridge: 0000:00:01.0 IO window: b000-bfff MEM window: efe00000-efefffff PREFETCH window: e5c00000-e7cfffff NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered SGI XFS with no debug enabled io scheduler noop registered io scheduler deadline registered (default) Limiting direct PCI/PCI transfers. Boot video device is 0000:01:00.0 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot 0000:00:07.1 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: QUANTUM FIREBALL EX3.2A, ATA DISK drive hda: selected mode 0x42 ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... hda: max request size: 128KiB hda: 6306048 sectors (3228 MB) w/418KiB Cache, CHS=6256/16/63, UDMA(33) hda: cache flushes not supported hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 > PNP: No PS/2 controller found. Probing ports directly. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice nf_conntrack version 0.5.0 (1280 buckets, 10240 max) ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 15 Using IPI Shortcut mode Filesystem "hda1": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda1 Starting XFS recovery on filesystem: hda1 (logdev: internal) Ending XFS recovery on filesystem: hda1 (logdev: internal) VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 160k freed Adding 209624k swap on /dev/hda9. Priority:-1 extents:1 across:209624k Filesystem "hda1": Disabling barriers, not supported by the underlying device Filesystem "hda1": Disabling barriers, not supported by the underlying device PCI: setting IRQ 9 as level-triggered PCI: Found IRQ 9 for device 0000:00:09.0 3c59x: Donald Becker and others. 0000:00:09.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001de00. PCI: setting IRQ 10 as level-triggered PCI: Found IRQ 10 for device 0000:00:0a.0 0000:00:0a.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001dc00. PCI: Found IRQ 11 for device 0000:00:0b.0 PCI: Sharing IRQ 11 with 0000:00:07.2 0000:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0001da00. Filesystem "hda5": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda5 Starting XFS recovery on filesystem: hda5 (logdev: internal) Ending XFS recovery on filesystem: hda5 (logdev: internal) Filesystem "hda6": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda6 Starting XFS recovery on filesystem: hda6 (logdev: internal) Ending XFS recovery on filesystem: hda6 (logdev: internal) Filesystem "hda7": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda7 Ending clean XFS mount for filesystem: hda7 Filesystem "hda8": Disabling barriers, not supported by the underlying device XFS mounting filesystem hda8 Starting XFS recovery on filesystem: hda8 (logdev: internal) Ending XFS recovery on filesystem: hda8 (logdev: internal) eth0: setting full-duplex. eth1: setting full-duplex. eth2: setting full-duplex. input: AT Raw Set 2 keyboard as /class/input/input0 input: AT Translated Set 2 keyboard as /class/input/input1 Aug 31 12:32:04 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:04 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:04 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:04 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:04 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:04 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:04 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:04 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:04 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:04 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:04 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:04 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:04 Gemini kernel: [] tcp_data_queue+0x2b9/0x710 Aug 31 12:32:04 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:04 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:04 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:04 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:04 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:04 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:04 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:04 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:04 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:04 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:04 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:04 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:04 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:04 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:04 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:04 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:04 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:04 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:04 Gemini kernel: [] default_idle+0x27/0x40 Aug 31 12:32:04 Gemini kernel: [] cpu_idle+0x5c/0x70 Aug 31 12:32:04 Gemini kernel: [] start_kernel+0x17c/0x1c0 Aug 31 12:32:04 Gemini kernel: [] unknown_bootoption+0x0/0x1a0 Aug 31 12:32:04 Gemini kernel: ======================= Aug 31 12:32:04 Gemini kernel: DMA per-cpu: Aug 31 12:32:04 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:04 Gemini kernel: Normal per-cpu: Aug 31 12:32:04 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 41 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:04 Gemini kernel: Active:26797 inactive:4519 dirty:0 writeback:0 unstable:0 Aug 31 12:32:04 Gemini kernel: free:1544 slab:6392 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:04 Gemini kernel: DMA free:1388kB min:160kB low:200kB high:240kB active:7740kB inactive:1068kB present:16256kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:04 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:04 Gemini kernel: Normal free:4788kB min:1448kB low:1808kB high:2172kB active:99448kB inactive:17008kB present:146304kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:04 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:04 Gemini kernel: DMA: 315*4kB 14*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1388kB Aug 31 12:32:04 Gemini kernel: Normal: 995*4kB 83*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4788kB Aug 31 12:32:04 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x2b9/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x27/0x40 Aug 31 12:32:05 Gemini kernel: [] cpu_idle+0x5c/0x70 Aug 31 12:32:05 Gemini kernel: [] start_kernel+0x17c/0x1c0 Aug 31 12:32:05 Gemini kernel: [] unknown_bootoption+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 35 Cold: hi: 14, btch: 3 usd: 13 Aug 31 12:32:05 Gemini kernel: Active:26727 inactive:4495 dirty:3 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1690 slab:6345 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7740kB inactive:940kB present:16256kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:5208kB min:1448kB low:1808kB high:2172kB active:99168kB inactive:17040kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1090*4kB 88*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5208kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x2b9/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x27/0x40 Aug 31 12:32:05 Gemini kernel: [] cpu_idle+0x5c/0x70 Aug 31 12:32:05 Gemini kernel: [] start_kernel+0x17c/0x1c0 Aug 31 12:32:05 Gemini kernel: [] unknown_bootoption+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: swapper: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] default_idle+0x0/0x40 Aug 31 12:32:05 Gemini kernel: [] default_id Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_established+0x1cb/0x630 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_do_rcv+0xe3/0xf0 Aug 31 12:32:05 Gemini kernel: [] tcp_v4_rcv+0x67f/0x800 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] nf_hook_slow+0x66/0xe0 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver+0x11c/0x230 Aug 31 12:32:05 Gemini kernel: [] ip_local_deliver_finish+0x0/0x1a0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv+0x232/0x4d0 Aug 31 12:32:05 Gemini kernel: [] ip_rcv_finish+0x0/0x2a0 Aug 31 12:32:05 Gemini kernel: [] netif_receive_skb+0x207/0x290 Aug 31 12:32:05 Gemini kernel: [] process_backlog+0x77/0xf0 Aug 31 12:32:05 Gemini kernel: [] net_rx_action+0x6c/0xf0 Aug 31 12:32:05 Gemini kernel: [] __do_softirq+0x74/0x90 Aug 31 12:32:05 Gemini kernel: [] do_softirq+0x26/0x30 Aug 31 12:32:05 Gemini kernel: [] do_IRQ+0x3e/0x80 Aug 31 12:32:05 Gemini kernel: [] autoremove_wake_function+0x0/0x50 Aug 31 12:32:05 Gemini kernel: [] common_interrupt+0x23/0x28 Aug 31 12:32:05 Gemini kernel: [] __sched_text_start+0x30d/0x5c0 Aug 31 12:32:05 Gemini kernel: [] work_resched+0x5/0x16 Aug 31 12:32:05 Gemini kernel: [] build_expire+0x100/0x140 Aug 31 12:32:05 Gemini kernel: ======================= Aug 31 12:32:05 Gemini kernel: DMA per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0 Aug 31 12:32:05 Gemini kernel: Normal per-cpu: Aug 31 12:32:05 Gemini kernel: CPU 0: Hot: hi: 42, btch: 7 usd: 36 Cold: hi: 14, btch: 3 usd: 12 Aug 31 12:32:05 Gemini kernel: Active:26569 inactive:4526 dirty:4 writeback:0 unstable:0 Aug 31 12:32:05 Gemini kernel: free:1910 slab:6252 mapped:937 pagetables:124 bounce:0 Aug 31 12:32:05 Gemini kernel: DMA free:1552kB min:160kB low:200kB high:240kB active:7720kB inactive:960kB present:16256kB pages_scanned:34 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 142 Aug 31 12:32:05 Gemini kernel: Normal free:6088kB min:1448kB low:1808kB high:2172kB active:98556kB inactive:17144kB present:146304kB pages_scanned:0 all_unreclaimable? no Aug 31 12:32:05 Gemini kernel: lowmem_reserve[]: 0 0 Aug 31 12:32:05 Gemini kernel: DMA: 364*4kB 10*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1552kB Aug 31 12:32:05 Gemini kernel: Normal: 1298*4kB 94*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6088kB Aug 31 12:32:05 Gemini kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0 Aug 31 12:32:05 Gemini kernel: Free swap = 209624kB Aug 31 12:32:05 Gemini kernel: Total swap = 209624kB Aug 31 12:32:05 Gemini kernel: klogd: page allocation failure. order:2, mode:0x4020 Aug 31 12:32:05 Gemini kernel: [] __alloc_pages+0x1ed/0x2e0 Aug 31 12:32:05 Gemini kernel: [] allocate_slab+0x4b/0x90 Aug 31 12:32:05 Gemini kernel: [] new_slab+0x32/0x150 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0xcb/0x120 Aug 31 12:32:05 Gemini kernel: [] __slab_alloc+0x79/0x120 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __kmalloc_track_caller+0x75/0x80 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] __alloc_skb+0x4e/0x100 Aug 31 12:32:05 Gemini kernel: [] tcp_collapse+0x113/0x3b0 Aug 31 12:32:05 Gemini kernel: [] tcp_prune_queue+0x7d/0x180 Aug 31 12:32:05 Gemini kernel: [] tcp_data_queue+0x5ab/0x710 Aug 31 12:32:05 Gemini kernel: [] ipt_do_table+0x271/0x360 Aug 31 12:32:05 Gemini kernel: [] tcp_rcv_es