From owner-linux-xfs@oss.sgi.com Wed Mar 1 04:52:41 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Mar 2006 04:52:44 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k21Cqdm2013114 for ; Wed, 1 Mar 2006 04:52:40 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA12859; Wed, 1 Mar 2006 23:53:21 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 20FDA49F1681; Wed, 1 Mar 2006 23:53:20 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Message-Id: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> Date: Wed, 1 Mar 2006 23:53:20 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 7412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs using a spinlock per cpu for superblock counter exclusion results in a preempt counter overflow at 256p and above. Change the exclusion mechanism to use atomic bit operations and busy wait loops to emulate the spin lock exclusion mechanism but without the preempt count issues. Date: Wed Mar 1 23:52:17 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:25338a fs/xfs/xfs_mount.h - 1.216 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.216&r2=text&tr2=1.215&f=h - Use a flag bit for per-cpu counter exclusion rather than a spin lock to prevent preempt count overflows. fs/xfs/xfs_mount.c - 1.372 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.372&r2=text&tr2=1.371&f=h - Use a flag bit for per-cpu counter exclusion rather than a spin lock to prevent preempt count overflows. fs/xfs/linux-2.6/xfs_linux.h - 1.142 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.142&r2=text&tr2=1.141&f=h - Per-cpu superblock counter locks need to busy wait. From owner-linux-xfs@oss.sgi.com Wed Mar 1 13:35:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Mar 2006 13:35:38 -0800 (PST) Received: from mx2.suse.de ([195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k21LZVm2004247 for ; Wed, 1 Mar 2006 13:35:36 -0800 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 5AF601D7DB; Wed, 1 Mar 2006 22:36:10 +0100 (CET) X-Authentication-Warning: verdi.suse.de: ak set sender to ak@suse.de using -f To: dgc@sgi.com (David Chinner) Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> From: Andi Kleen Date: 01 Mar 2006 22:36:05 +0100 In-Reply-To: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs dgc@sgi.com (David Chinner) writes: > using a spinlock per cpu for superblock counter exclusion results in > a preempt counter overflow at 256p and above. Change the exclusion mechanism > to use atomic bit operations and busy wait loops to emulate the spin > lock exclusion mechanism but without the preempt count issues. That sounds like the totally wrong place to fix this. Wouldn't it be better to fix the spinlocks instead instead of hacking around this? After all any other code on that big box could run into the same issue. -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 1 19:06:21 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Mar 2006 19:06:31 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k2236JW6002653 for ; Wed, 1 Mar 2006 19:06:20 -0800 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 OAA28221; Thu, 2 Mar 2006 14:06:56 +1100 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 k2236neS5132104; Thu, 2 Mar 2006 14:06:49 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k2236lsh5130749; Thu, 2 Mar 2006 14:06:47 +1100 (EST) Date: Thu, 2 Mar 2006 14:06:47 +1100 From: David Chinner To: Andi Kleen Cc: David Chinner , linux-xfs@oss.sgi.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Message-ID: <20060302030647.GV1174024@melbourne.sgi.com> References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 7414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Mar 01, 2006 at 10:36:05PM +0100, Andi Kleen wrote: > dgc@sgi.com (David Chinner) writes: > > > using a spinlock per cpu for superblock counter exclusion results in > > a preempt counter overflow at 256p and above. Change the exclusion mechanism > > to use atomic bit operations and busy wait loops to emulate the spin > > lock exclusion mechanism but without the preempt count issues. > > That sounds like the totally wrong place to fix this. > Wouldn't it be better to fix the spinlocks instead instead of hacking > around this? After all any other code on that big box could run > into the same issue. The issue is one cpu taking all the spin locks for a mount point to exclude per-cpu access while we do something global to the counter (e.g a rebalance). I initially used spinlocks because it was simple to implement, I knew it would prevent preemption in the critical sections and I knew of nothing that would prevent a single cpu from taking up to NR_CPU + 1 nested spinlocks. Turns out I made an incorrect assumption. However, when we are excluding the counters, we are already running atomic due to holding the in-core superblock spinlock and the per-cpu code uses get_cpu()/put_cpu() so neither can get preempted in the critical sections the spinlocks used to protect. So the only considerations are having an atomic exclusion mechanism and a wait method that does not sleep. In hindsight, spinlocks were a bad implementation choice. If I knew about the limits on the preempt counter in the first place, I would not have used spinlocks. Instead, I would have used the mechanism that I just checked in. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Wed Mar 1 20:55:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Mar 2006 20:55:11 -0800 (PST) Received: from mx1.suse.de ([195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k224t7W6015981 for ; Wed, 1 Mar 2006 20:55:08 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 186B6E98D; Thu, 2 Mar 2006 05:55:46 +0100 (CET) X-Authentication-Warning: verdi.suse.de: ak set sender to ak@suse.de using -f To: David Chinner Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <20060302030647.GV1174024@melbourne.sgi.com> From: Andi Kleen Date: 02 Mar 2006 05:55:43 +0100 In-Reply-To: <20060302030647.GV1174024@melbourne.sgi.com> Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs David Chinner writes: > > However, when we are excluding the counters, we are already running > atomic due to holding the in-core superblock spinlock and the > per-cpu code uses get_cpu()/put_cpu() so neither can get preempted > in the critical sections the spinlocks used to protect. So the only > considerations are having an atomic exclusion mechanism and a wait > method that does not sleep. spinlocks are should be fine for this in theory. All CPUs spinning on a spinlock shouldn't happen normally, but it is supposed to work correctly if it happens. If preemptible spinlocks don't scale to this for large NR_CPUs they're broken and need to be fixed. You discovered a important limitation in them and now instead of fixing them properly you're trying to work around it. Please try to see the big picture a bit more instead of just XFS. -Andi From owner-linux-xfs@oss.sgi.com Wed Mar 1 22:57:47 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Mar 2006 22:57:52 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k226vjW6025131 for ; Wed, 1 Mar 2006 22:57:46 -0800 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 RAA01534; Thu, 2 Mar 2006 17:58:16 +1100 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 k226w9eS5190330; Thu, 2 Mar 2006 17:58:09 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k226w7No5044995; Thu, 2 Mar 2006 17:58:07 +1100 (EST) Date: Thu, 2 Mar 2006 17:58:07 +1100 From: David Chinner To: Andi Kleen Cc: David Chinner , linux-xfs@oss.sgi.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Message-ID: <20060302065807.GG1173973@melbourne.sgi.com> References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <20060302030647.GV1174024@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 7416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Mar 02, 2006 at 05:55:43AM +0100, Andi Kleen wrote: > David Chinner writes: > > > > However, when we are excluding the counters, we are already running > > atomic due to holding the in-core superblock spinlock and the > > per-cpu code uses get_cpu()/put_cpu() so neither can get preempted > > in the critical sections the spinlocks used to protect. So the only > > considerations are having an atomic exclusion mechanism and a wait > > method that does not sleep. > > spinlocks are should be fine for this in theory. All CPUs spinning > on a spinlock shouldn't happen normally, but it is supposed to work > correctly if it happens. And that does work correctly. However, that's not the problem being solved here. The problem is one thread grabbing > 245 spinlocks and holding them locked. The preempt count is per thread, so it has to be a single thread that holds all the locks at the same time to cause the problem. > If preemptible spinlocks don't scale to this for large NR_CPUs they're > broken and need to be fixed. > You discovered a important limitation in them and now instead > of fixing them properly you're trying to work around it. It's not NR_CPUs that they need to scale to - I could have 2 locks per cpu that need to be held, and then it's 2*NR_CPUs that the pre-empt count must scale to. Where do you draw the line? Or do you just say "Don't do that" because there are other ways of acheiving the same goal? > Please try to see the big picture a bit more instead of just XFS. Sure, I try to. From my POV, we've got a regression in new code that will affect a tiny, tiny minority of machines out there. The new code is arguably broken or stupid and has been easily fixed without affecting anything else. Seems like a no-brainer compared to changing code that affects core functionality of all plaforms of which all but one would never be affected by the problem in the first place.... Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu Mar 2 04:07:06 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 04:07:19 -0800 (PST) Received: from mx1.suse.de (mx1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k22C75W6020795 for ; Thu, 2 Mar 2006 04:07:06 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 41A80E072; Thu, 2 Mar 2006 13:07:49 +0100 (CET) From: Andi Kleen To: David Chinner Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Date: Thu, 2 Mar 2006 13:09:45 +0100 User-Agent: KMail/1.9.1 Cc: linux-xfs@oss.sgi.com, mingo@elte.hu, torvalds@osdl.org, tony.luck@intel.com References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <20060302065807.GG1173973@melbourne.sgi.com> In-Reply-To: <20060302065807.GG1173973@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603021309.46495.ak@suse.de> X-archive-position: 7417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Thursday 02 March 2006 07:58, David Chinner wrote: > On Thu, Mar 02, 2006 at 05:55:43AM +0100, Andi Kleen wrote: > > David Chinner writes: > > > However, when we are excluding the counters, we are already running > > > atomic due to holding the in-core superblock spinlock and the > > > per-cpu code uses get_cpu()/put_cpu() so neither can get preempted > > > in the critical sections the spinlocks used to protect. So the only > > > considerations are having an atomic exclusion mechanism and a wait > > > method that does not sleep. > > > > spinlocks are should be fine for this in theory. All CPUs spinning > > on a spinlock shouldn't happen normally, but it is supposed to work > > correctly if it happens. > > And that does work correctly. However, that's not the problem being > solved here. > > The problem is one thread grabbing > 245 spinlocks and holding them > locked. The preempt count is per thread, so it has to be a single > thread that holds all the locks at the same time to cause the problem. > > If preemptible spinlocks don't scale to this for large NR_CPUs they're > > broken and need to be fixed. > > You discovered a important limitation in them and now instead > > of fixing them properly you're trying to work around it. > > It's not NR_CPUs that they need to scale to - I could have 2 locks > per cpu that need to be held, and then it's 2*NR_CPUs that the > pre-empt count must scale to. Where do you draw the line? 2*NR_CPUS is still quite reasonable. And bits in a counter are cheap anyways. We can easily go to 16bit. Or even more on a 64bit architecture It just requires to tweak the bit shifts in linux/hardirq.h I suspect 256 softirq nestings are not needed, so how about setting PREEMPT_BITS to 16 and SOFTIRQ_BITS to 4 and hardirq bits to 11 and PREEMPT_ACTIVE to 31? I don't see anything that would rely on the count being positive so using the sign bit is probably ok. Hardirq 11 might be a bit tight though, so maybe it would be better to move 64bit machines to 64bit here. Ingo, Linus, Tony, what do you think? XFS is running into trouble on preemptive kernels on >256CPU systems because there are cases where one thread can hold 2*NR_CPUS spinlocks and that overflows the current 8 bit preempt count. > Seems like a no-brainer compared to changing code that affects core > functionality of all plaforms of which all but one would never be > affected by the problem in the first place.... I disagree because I can easily see other code running into the same problem. You were just the first to notice. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 2 09:52:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 09:52:19 -0800 (PST) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k22HqEW6021024 for ; Thu, 2 Mar 2006 09:52:17 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id k22GrvDZ019311 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Mar 2006 08:53:57 -0800 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id k22GrpWr028036; Thu, 2 Mar 2006 08:53:53 -0800 Date: Thu, 2 Mar 2006 08:53:51 -0800 (PST) From: Linus Torvalds To: Andi Kleen cc: David Chinner , linux-xfs@oss.sgi.com, mingo@elte.hu, tony.luck@intel.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p In-Reply-To: <200603021309.46495.ak@suse.de> Message-ID: References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <20060302065807.GG1173973@melbourne.sgi.com> <200603021309.46495.ak@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.129 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: linux-xfs On Thu, 2 Mar 2006, Andi Kleen wrote: > > I suspect 256 softirq nestings are not needed, so how about setting > PREEMPT_BITS to 16 and SOFTIRQ_BITS to 4 and hardirq bits > to 11 and PREEMPT_ACTIVE to 31? I'd rather be a bit more gentle: instead of taking away _half_ the SOFTIRQ bits, take away just one or two. The HARDIRQ bits are also pretty dangerous, I'd say. So I'm not happy with your choice of numbers. Right now we actally have three bits unused, I think, so it would be much better to just make PREEMPT_ACTIVE be 31, and just make PREEMPT_BITS be 11. Problem solved, without making anything worse. > I don't see anything that would rely on the count being positive > so using the sign bit is probably ok. Hardirq 11 might be a bit > tight though, so maybe it would be better to move 64bit machines > to 64bit here. And yes, I think it may make sense to just use the full 64 bits on a 64-bit machine. Eventually. Somebody should check what the larger constants result in, though. And not for now, but obviously the 11 bits will run out for even bigger machines. But for a "let's fix it quickly", adding three bits should be plenty good enough, no? Need to check the things that check PREEMPT_ACTIVE, but making i tbit #31 migt actually _help_ (you can test it more easily). Linus From owner-linux-xfs@oss.sgi.com Thu Mar 2 09:52:01 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 09:52:11 -0800 (PST) Received: from mx1.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k22HpvW6020974 for ; Thu, 2 Mar 2006 09:52:00 -0800 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 2C191ECB8; Thu, 2 Mar 2006 18:52:41 +0100 (CET) From: Andi Kleen To: Linus Torvalds Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Date: Thu, 2 Mar 2006 18:52:34 +0100 User-Agent: KMail/1.9.1 Cc: David Chinner , linux-xfs@oss.sgi.com, mingo@elte.hu, tony.luck@intel.com References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <200603021309.46495.ak@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603021852.35443.ak@suse.de> X-archive-position: 7418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Thursday 02 March 2006 17:53, Linus Torvalds wrote: >nything worse. > > > I don't see anything that would rely on the count being positive > > so using the sign bit is probably ok. Hardirq 11 might be a bit > > tight though, so maybe it would be better to move 64bit machines > > to 64bit here. Yes agreed, it just would be a bigger patch probably affecting many architectures. > And yes, I think it may make sense to just use the full 64 bits on a > 64-bit machine. Eventually. Somebody should check what the larger > constants result in, though. > > And not for now, but obviously the 11 bits will run out for even bigger > machines. But for a "let's fix it quickly", adding three bits should be > plenty good enough, no? That would be spinlock nesting of 2 per CPU on a 1024 CPU machine. Not exactly plenty. Better 12-14 at least. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 2 10:06:19 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 10:06:21 -0800 (PST) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k22I6JW6022977 for ; Thu, 2 Mar 2006 10:06:19 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id k22I6wDZ023656 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Mar 2006 10:06:58 -0800 Received: from localhost (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id k22I6oGx031560; Thu, 2 Mar 2006 10:06:53 -0800 Date: Thu, 2 Mar 2006 10:06:50 -0800 (PST) From: Linus Torvalds To: Andi Kleen cc: David Chinner , linux-xfs@oss.sgi.com, mingo@elte.hu, tony.luck@intel.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p In-Reply-To: <200603021852.35443.ak@suse.de> Message-ID: References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <200603021309.46495.ak@suse.de> <200603021852.35443.ak@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIMEDefang-Filter: osdl$Revision: 1.129 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: linux-xfs On Thu, 2 Mar 2006, Andi Kleen wrote: > > That would be spinlock nesting of 2 per CPU on a 1024 CPU machine. > Not exactly plenty. Better 12-14 at least. That's PLENTY. First off, name somebody who sells bigger systems than that. Second, taking two spinlocks per CPU is crazy in the first place. Who does that? Talk about scaling badly. Third, code that cares can avoid it entirely by just bumping the preempt counter _once_, and then using the raw spinlock code. That's how you should do it for big-rw-locks anyway, just because it's less insane, if that is what XFS is doing with its "two spinlocks per CPU" thing. Fourth, you ignore the very real possibility that decreasing the size of the other fields can cause problems, and you're completely fixated on the crazy XFS usage. Linus From owner-linux-xfs@oss.sgi.com Thu Mar 2 10:14:27 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 10:14:29 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k22IEQW6023977 for ; Thu, 2 Mar 2006 10:14:27 -0800 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id EFAFD1D8D3; Thu, 2 Mar 2006 19:15:14 +0100 (CET) From: Andi Kleen To: Linus Torvalds Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Date: Thu, 2 Mar 2006 19:15:08 +0100 User-Agent: KMail/1.9.1 Cc: David Chinner , linux-xfs@oss.sgi.com, mingo@elte.hu, tony.luck@intel.com References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <200603021852.35443.ak@suse.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603021915.10041.ak@suse.de> X-archive-position: 7421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Thursday 02 March 2006 19:06, Linus Torvalds wrote: > That's PLENTY. > > First off, name somebody who sells bigger systems than that. 512 socket Altix with Montecitos - 4 threads per socket = 2048 virtual CPUs. Not quite selling, but at some point it will. > Second, taking two spinlocks per CPU is crazy in the first place. Who does > that? Talk about scaling badly. It would be reasonable for slow path code. And I'm worrying more about corner cases that might be only taken in exception situations etc. [e.g. i was just debugging a problem in stop_machine() on a large system - these are exactly these kinds of nasty corner cases] Also I think we need some margin here - so that even code that is slow path etc. is not likely to run into the ceiling. > Third, code that cares can avoid it entirely by just bumping the preempt > counter _once_, and then using the raw spinlock code. That's how you > should do it for big-rw-locks anyway, just because it's less insane, if > that is what XFS is doing with its "two spinlocks per CPU" thing. The issue I'm worrying about is that this code will be likely written to small machines and never bump into this so nobody will care. And then suddenly it explodes when the code runs on a larger machine. It's a nasty trap. > Fourth, you ignore the very real possibility that decreasing the size of > the other fields can cause problems, 256 softirq nestings would be really crazy in my opinion. It cannot be real softirqs because the stack would just overflow and code just shouldn't be that deeply nested. Agreed 64bits would be better though. -Andi From owner-linux-xfs@oss.sgi.com Thu Mar 2 11:31:57 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 11:32:01 -0800 (PST) Received: from scsfmr001.sc.intel.com (fmr21.intel.com [143.183.121.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k22JVvW6004244 for ; Thu, 2 Mar 2006 11:31:57 -0800 Received: from scsfmr101.sc.intel.com (scsfmr101.sc.intel.com [10.3.253.10]) by scsfmr001.sc.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id k22H9Bx1008710; Thu, 2 Mar 2006 17:09:11 GMT Received: from scsmsxvs040.sc.intel.com (scsmsxvs040.sc.intel.com [10.3.90.8]) by scsfmr101.sc.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id k22H3Xfk016877; Thu, 2 Mar 2006 17:03:47 GMT Received: from scsmsx331.amr.corp.intel.com ([10.3.90.4]) by scsmsxvs040.sc.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2006030209091012012 ; Thu, 02 Mar 2006 09:09:10 -0800 Received: from scsmsx401.amr.corp.intel.com ([10.3.90.12]) by scsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Mar 2006 09:09:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Date: Thu, 2 Mar 2006 09:09:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Thread-Index: AcY98mF5Ecik/hImRIugcoCw4ms8OQAKGX5g From: "Luck, Tony" To: "Andi Kleen" , "David Chinner" Cc: , , X-OriginalArrivalTime: 02 Mar 2006 17:09:10.0306 (UTC) FILETIME=[05BF3020:01C63E1C] X-Scanned-By: MIMEDefang 2.52 on 10.3.253.10 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k22JVvW6004247 X-archive-position: 7422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tony.luck@intel.com Precedence: bulk X-list: linux-xfs > Ingo, Linus, Tony, what do you think? XFS is running into trouble > on preemptive kernels on >256CPU systems because there are > cases where one thread can hold 2*NR_CPUS spinlocks > and that overflows the current 8 bit preempt count. NR_CPUS can be 1024 now ... I thought that spinlocks were intended for code that will be held for a _short_ time. Even if the code in XFS only wants to execute a single instruction inside this hyper- critical region, you need to contend with the fact that the first one of those locks that XFS acquired is going to be held while you acquire and then release the other 2047 locks. Does that sound like a short time (rhetorical question)? -Tony From owner-linux-xfs@oss.sgi.com Thu Mar 2 12:32:11 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 12:32:17 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k22KW9W6015189 for ; Thu, 2 Mar 2006 12:32:10 -0800 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 HAA12000; Fri, 3 Mar 2006 07:32:45 +1100 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 k22KWZeS5771096; Fri, 3 Mar 2006 07:32:36 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k22KWTkt5766097; Fri, 3 Mar 2006 07:32:29 +1100 (EST) Date: Fri, 3 Mar 2006 07:32:29 +1100 From: David Chinner To: Linus Torvalds Cc: Andi Kleen , David Chinner , linux-xfs@oss.sgi.com, mingo@elte.hu, tony.luck@intel.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Message-ID: <20060302203229.GI1173973@melbourne.sgi.com> References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <200603021309.46495.ak@suse.de> <200603021852.35443.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 7423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Mar 02, 2006 at 10:06:50AM -0800, Linus Torvalds wrote: > > > On Thu, 2 Mar 2006, Andi Kleen wrote: > > > > That would be spinlock nesting of 2 per CPU on a 1024 CPU machine. > > Not exactly plenty. Better 12-14 at least. > > That's PLENTY. > > First off, name somebody who sells bigger systems than that. > > Second, taking two spinlocks per CPU is crazy in the first place. Who does > that? Talk about scaling badly. Nobody does that - it was a purely hypothetical question. The algorithm needs to lock out all the per-cpu counters while state transitions occur (i.e. does global manipulations of the counters). > Third, code that cares can avoid it entirely by just bumping the preempt > counter _once_, and then using the raw spinlock code. That's how you > should do it for big-rw-locks anyway, just because it's less insane, if > that is what XFS is doing with its "two spinlocks per CPU" thing. Exactly the change I made, except it uses an atomic bit field and ndelay rather than raw spinlocks. Spinlocks were a bad choice in the first place because I was not aware of the counter overflow problem. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu Mar 2 12:43:19 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 12:43:21 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k22KhHW6016375 for ; Thu, 2 Mar 2006 12:43:18 -0800 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 HAA12185; Fri, 3 Mar 2006 07:43:54 +1100 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 k22KhieS5779325; Fri, 3 Mar 2006 07:43:45 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k22KheUo5779914; Fri, 3 Mar 2006 07:43:40 +1100 (EST) Date: Fri, 3 Mar 2006 07:43:40 +1100 From: David Chinner To: Andi Kleen Cc: David Chinner , linux-xfs@oss.sgi.com, mingo@elte.hu, torvalds@osdl.org, tony.luck@intel.com Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Message-ID: <20060302204340.GJ1173973@melbourne.sgi.com> References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <20060302065807.GG1173973@melbourne.sgi.com> <200603021309.46495.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603021309.46495.ak@suse.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 7424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Mar 02, 2006 at 01:09:45PM +0100, Andi Kleen wrote: > > Ingo, Linus, Tony, what do you think? XFS is running into trouble > on preemptive kernels on >256CPU systems because there are > cases where one thread can hold 2*NR_CPUS spinlocks > and that overflows the current 8 bit preempt count. 2 * NR_CPU spinlocks held by a single thread was a purely hypothetical question. THe code does not do that. It requires a barrier per CPU, and as I've said before, spinlocks were a bad implementation choice. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu Mar 2 13:23:18 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 13:23:23 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k22LNGW6020008 for ; Thu, 2 Mar 2006 13:23:17 -0800 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 IAA13027; Fri, 3 Mar 2006 08:23:52 +1100 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 k22LNfeS5843694; Fri, 3 Mar 2006 08:23:42 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k22LNYjF5837663; Fri, 3 Mar 2006 08:23:34 +1100 (EST) Date: Fri, 3 Mar 2006 08:23:34 +1100 From: David Chinner To: "Luck, Tony" Cc: Andi Kleen , David Chinner , linux-xfs@oss.sgi.com, mingo@elte.hu, torvalds@osdl.org Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p Message-ID: <20060302212334.GK1173973@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 7425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Mar 02, 2006 at 09:09:08AM -0800, Luck, Tony wrote: > > Ingo, Linus, Tony, what do you think? XFS is running into trouble > > on preemptive kernels on >256CPU systems because there are > > cases where one thread can hold 2*NR_CPUS spinlocks > > and that overflows the current 8 bit preempt count. > > NR_CPUS can be 1024 now ... I thought that spinlocks were intended > for code that will be held for a _short_ time. Even if the code in > XFS only wants to execute a single instruction inside this hyper- > critical region, you need to contend with the fact that the first > one of those locks that XFS acquired is going to be held while you > acquire and then release the other 2047 locks. Does that sound like > a short time (rhetorical question)? Perspective: In filesystem and disk I/O terms, yes, it is a _very_ short time. CPUs are orders of magnitudes faster than disks, so something that seems very wasteful in terms of CPU time that saves a disk seek or two or doubles the I/O sizes or reduces fragmentation pays off very quickly in terms of I/O performance. Burn that CPU as much as you need, as long as you get the expected payoff at the end. The tradeoff being made here is that we spend a millisecond or two every few seconds to lock and rebalance counters instead of wasting large amounts of CPU time on a single lock. The result is a _major_ improvement in parallel buffered write throughput (an order of magnitude on our test rig) because it removes the only point of global contention within XFS for this load. It also changes the CPU usage scaling from increasing linearly with thread count to scaling linearly with throughput. And we get this without any other measurable performance regressions, so I think that this is good tradeoff to make. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Thu Mar 2 14:25:53 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 14:25:55 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k22MPqW6023272 for ; Thu, 2 Mar 2006 14:25:53 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA14553; Fri, 3 Mar 2006 09:26:33 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7409249F1681; Fri, 3 Mar 2006 09:26:31 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 950264 - xfs_copy Message-Id: <20060302222631.7409249F1681@chook.melbourne.sgi.com> Date: Fri, 3 Mar 2006 09:26:31 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Fix a bug in the xfs_copy log re-write code avoiding duplicate UUIDs. Also fix the logic for sizing the direct write buffer, which fails for large maxdio sizes. Date: Fri Mar 3 09:25:19 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25351a xfsprogs/copy/xfs_copy.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/copy/xfs_copy.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h From owner-linux-xfs@oss.sgi.com Thu Mar 2 15:14:57 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 15:14:58 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k22NEuW6027685 for ; Thu, 2 Mar 2006 15:14:57 -0800 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k22NFjOX005109 for ; Thu, 2 Mar 2006 17:15:45 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k22NWu2n17102849; Thu, 2 Mar 2006 15:32:56 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k22NFiSQ2472777; Thu, 2 Mar 2006 17:15:44 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 3682) id 4904D9E2A249; Thu, 2 Mar 2006 17:15:36 -0600 (CST) To: linux-xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: PARTIAL TAKE 928864 - [SUSE#76685] Inode extent management causes high order page allocations Message-Id: <20060302231536.4904D9E2A249@attica.americas.sgi.com> Date: Thu, 2 Mar 2006 17:15:36 -0600 (CST) From: alkirkco@sgi.com (Amanda Kirkconnell) X-archive-position: 7427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs This mod re-organizes some of the in-core file extent code to prepare for an upcoming mod which will introduce multi-level in-core extent allocations. Although the in-core extent management is using a new code path in this mod, the functionality remains the same. Major changes include: - Introduce 10 new subroutines which re-orgainze the existing code but do NOT change functionality: xfs_iext_get_ext() xfs_iext_insert() xfs_iext_add() xfs_iext_remove() xfs_iext_remove_inline() xfs_iext_remove_direct() xfs_iext_realloc_direct() xfs_iext_direct_to_inline() xfs_iext_inline_to_direct() xfs_iext_destroy() - Remove 2 subroutines (functionality moved to new subroutines above): xfs_iext_realloc() -replaced by xfs_iext_add() and xfs_iext_remove() xfs_bmap_insert_exlist() - replaced by xfs_iext_insert() xfs_bmap_delete_exlist() - replaced by xfs_iext_remove() - Replace all hard-coded (indexed) extent assignments with a call to xfs_iext_get_ext() - Replace all extent record pointer arithmetic (ep++, ep--, base + lastx,..) with calls to xfs_iext_get_ext() - Update comments to remove the idea of a single "extent list" and introduce "extent record" terminology instead Date: Thu Mar 2 15:08:14 PST 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica2/alkirkco/XFS/2.6.x-xfs Inspected by: olaf,gwehrman,dgc,nathans,felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:207390a fs/xfs/xfsidbg.c - 1.293 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.293&r2=text&tr2=1.292&f=h - Replace indexed extent assignment with a call to xfs_iext_get_ext() fs/xfs/xfs_bmap_btree.c - 1.151 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.151&r2=text&tr2=1.150&f=h - Change first parameter of xfs_check_nostate_extents() from an extent pointer (*xfs_bmbt_rec_t*) to two parameters: 1) inode fork pointer (xfs_ifork_t*), and 2) the index of the extent (xfs_extnum_t). These new parameters are needed for the call to xfs_iext_get_ext() in xfs_check_nostate_extents(). - Replace indexed extent assignment with a call to xfs_iext_get_ext() fs/xfs/xfs_inode.c - 1.426 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.426&r2=text&tr2=1.425&f=h - Add 10 new subroutines to re-organize the in-core extent management code: xfs_iext_get_ext() xfs_iext_insert() xfs_iext_add() xfs_iext_remove() xfs_iext_remove_inline() xfs_iext_remove_direct() xfs_iext_realloc_direct() xfs_iext_direct_to_inline() xfs_iext_inline_to_direct() xfs_iext_destroy() - Replace indexed extent assignments with calls to xfs_iext_get_ext() - Replace extent record pointer arithmetic (ep++, ep--, base + lastx,..) with calls to xfs_iext_get_ext() - Modify xfs_validate_extents() parameters so that xfs_iext_get_ext() can be called from xfs_validate_extents() - Update comments to remove the idea of a single "extent list" and replace with "extent record" terminology instead fs/xfs/xfs_inode.h - 1.208 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.208&r2=text&tr2=1.207&f=h - Add prototypes for new xfs_iext_* functions in xfs_inode.c. - Remove XFS_MAX_INCORE_EXTENTS macro, which is 1) never used, and 2) a bogus number. fs/xfs/xfs_bmap.h - 1.93 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.93&r2=text&tr2=1.92&f=h - Change first parameter of xfs_check_nostate_extents() from an extent pointer (*xfs_bmbt_rec_t*) to two parameters: 1) inode fork pointer (xfs_ifork_t*), and 2) the index of the extent (xfs_extnum_t). These new parameters are needed for the call to xfs_iext_get_ext() in xfs_check_nostate_extents(). fs/xfs/xfs_bmap.c - 1.340 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.340&r2=text&tr2=1.339&f=h - Replace indexed extent assignments with calls to xfs_iext_get_ext() - Remove xfs_bmap_insert_exlist() and xfs_bmap_delete_exlist() and replace all calls by xfs_iext_insert() and xfs_iext_remove(), respectively. - Update documentation and replace "extent list" terminology with "extent record" fs/xfs/quota/xfs_qm.c - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h - Replace indexed extent assignment with a call to xfs_iext_get_ext() fs/xfs/linux-2.6/xfs_ksyms.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h - Export new functions needed by CXFS 4.1: xfs_iext_add() xfs_iext_destroy() xfs_iext_get_ext() xfs_iext_insert() xfs_iext_remove() fs/xfs/linux-2.4/xfs_ksyms.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h - Export new functions needed by CXFS 4.1: xfs_iext_add() xfs_iext_destroy() xfs_iext_get_ext() xfs_iext_insert() xfs_iext_remove() From owner-linux-xfs@oss.sgi.com Thu Mar 2 15:56:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 15:57:04 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k22NuvW6004056 for ; Thu, 2 Mar 2006 15:56:58 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16408; Fri, 3 Mar 2006 10:57:40 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id C653849F1681; Fri, 3 Mar 2006 10:57:38 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 950489 - xfsprogs Message-Id: <20060302235738.C653849F1681@chook.melbourne.sgi.com> Date: Fri, 3 Mar 2006 10:57:38 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Fix mishandling of external log/rt devices in userspace for old kernels where procfs output was subtely different. Date: Fri Mar 3 10:53:49 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25352a xfsprogs/libxcmd/paths.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxpaths.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h Bump xfsprogs version number for recent changes. Date: Fri Mar 3 10:57:19 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25353a xfsprogs/VERSION - 1.147 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.147&r2=text&tr2=1.146&f=h xfsprogs/doc/CHANGES - 1.196 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.196&r2=text&tr2=1.195&f=h xfsprogs/debian/changelog - 1.134 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.134&r2=text&tr2=1.133&f=h From owner-linux-xfs@oss.sgi.com Thu Mar 2 16:24:00 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 16:24:02 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k230NwW6011154 for ; Thu, 2 Mar 2006 16:23:59 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16973; Fri, 3 Mar 2006 11:24:40 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 0DB7349F1681; Fri, 3 Mar 2006 11:24:39 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 950491 - extra SB validation Message-Id: <20060303002439.0DB7349F1681@chook.melbourne.sgi.com> Date: Fri, 3 Mar 2006 11:24:39 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Additional mount time superblock validation checks. Date: Fri Mar 3 11:24:08 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25354a xfs_mount.c - 1.373 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.373&r2=text&tr2=1.372&f=h From owner-linux-xfs@oss.sgi.com Thu Mar 2 16:42:35 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Mar 2006 16:42:39 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k230gYW6013643 for ; Thu, 2 Mar 2006 16:42:34 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k230hMOX011441 for ; Thu, 2 Mar 2006 18:43:23 -0600 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k232npf4022699 for ; Thu, 2 Mar 2006 18:49:51 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k2310U2n17114878; Thu, 2 Mar 2006 17:00:30 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k230hISQ2488095; Thu, 2 Mar 2006 18:43:18 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 3682) id 10BAE9E2A249; Thu, 2 Mar 2006 18:43:18 -0600 (CST) To: linux-xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 928864 - [SUSE#76685] Inode extent management causes high order page allocations Message-Id: <20060303004318.10BAE9E2A249@attica.americas.sgi.com> Date: Thu, 2 Mar 2006 18:43:18 -0600 (CST) From: alkirkco@sgi.com (Amanda Kirkconnell) X-archive-position: 7430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs This mod introduces multi-level in-core file extent functionality, building upon the new layout introduced in mod xfs-linux:xfs-kern:207390a. The new multi-level extent allocations are only required for heavily fragmented files, so the old-style linear extent list is used on files until the extents reach a pre-determined size of 4k. 4k buffers are used because this is the system page size on Linux i386 and systems with larger page sizes don't seem to gain much, if anything, by using their native page size as the extent buffer size. Also, using 4k extent buffers everywhere provides a consistent interface for CXFS across different platforms. The 4k extent buffers are managed by an indirection array (xfs_ext_irec_t) which is basically just a pointer array with a bit of extra information to keep track of the number of extents in each buffer as well as the extent offset of each buffer. Major changes include: - Add multi-level in-core file extent functionality to the xfs_iext_ subroutines introduced in mod: xfs-linux:xfs-kern:207390a - Introduce 13 new subroutines which add functionality for multi-level in-core file extents: xfs_iext_add_indirect_multi() xfs_iext_remove_indirect() xfs_iext_realloc_indirect() xfs_iext_indirect_to_direct() xfs_iext_bno_to_irec() xfs_iext_idx_to_irec() xfs_iext_irec_init() xfs_iext_irec_new() xfs_iext_irec_remove() xfs_iext_irec_compact() xfs_iext_irec_compact_pages() xfs_iext_irec_compact_full() xfs_iext_irec_update_extoffs() Date: Thu Mar 2 16:40:32 PST 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica2/alkirkco/XFS/2.6.x-xfs Inspected by: olaf,gwehrman,dgc,nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:207393a fs/xfs/xfs_bmap_btree.h - 1.72 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.72&r2=text&tr2=1.71&f=h - Remove xfs_bmap_do_search_extents() prototype, move to xfs_bmap.h (which is where it should have gone in the first place). fs/xfs/xfs_inode.c - 1.427 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.427&r2=text&tr2=1.426&f=h - Add multi-level in-core extent functionality to xfs_iext_* subroutines introduced in mod xfs-linux:xfs-kern:207390a. - Add 13 new subroutines which add functionality for multi-level in-core file extents: xfs_iext_add_indirect_multi() xfs_iext_remove_indirect() xfs_iext_realloc_indirect() xfs_iext_indirect_to_direct() xfs_iext_bno_to_irec() xfs_iext_idx_to_irec() xfs_iext_irec_init() xfs_iext_irec_new() xfs_iext_irec_remove() xfs_iext_irec_compact() xfs_iext_irec_compact_pages() xfs_iext_irec_compact_full() xfs_iext_irec_update_extoffs() fs/xfs/xfs_inode.h - 1.209 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.209&r2=text&tr2=1.208&f=h - Define xfs_ext_irec_t struct to manage multiple extent buffers - Define macro for XFS_IEXT_BUFSZ, hard-coded to 4k - Define macro for XFS_LINEAR_EXTS (ext buf size / ext rec size) - Define XFS_IFEXTIREC ifork flag (if_flag ) to switch between regular (linear) extent allocations and multi-level extent allocations - Add prototypes for new xfs_iext_* functions in xfs_inode.c. fs/xfs/xfs_bmap.h - 1.94 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.94&r2=text&tr2=1.93&f=h - Move xfs_bmap_do_search_extents() prototype from xfs_bmap_btree.h to xfs_bmap.h (which is where it should have gone in the first place) - Define prototype for new xfs_bmap_search_multi_extents(). fs/xfs/xfs_bmap.c - 1.341 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.341&r2=text&tr2=1.340&f=h - Add a new subroutine called xfs_bmap_search_multi_extents(), which locates the target extent buffer, if in multi-level allocation mode, then calls xfs_bmap_do_search_extents() with either the target extent list or the direct extent list (depending on which allocation mode is being used). - Modify xfs_bmap_search_extents() to call xfs_bmap_search_multi_extents() rather than xfs_bmap_do_search_extents(). fs/xfs/linux-2.6/xfs_ksyms.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h - Export new function needed by CXFS 4.1: xfs_iext_idx_to_irec() fs/xfs/linux-2.4/xfs_ksyms.c - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h - Export new function needed by CXFS 4.1: xfs_iext_idx_to_irec() From owner-linux-xfs@oss.sgi.com Fri Mar 3 07:14:23 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Mar 2006 07:14:30 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k23FEMW6010749 for ; Fri, 3 Mar 2006 07:14:23 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k23FFAOX007040 for ; Fri, 3 Mar 2006 09:15:10 -0600 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k23HLhUK003024 for ; Fri, 3 Mar 2006 09:21:43 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k23FWJ2n17221504; Fri, 3 Mar 2006 07:32:19 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k23FF5SQ2530804; Fri, 3 Mar 2006 09:15:06 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 3682) id D585E9E2A249; Fri, 3 Mar 2006 09:15:05 -0600 (CST) To: linux-xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 928864 - [SUSE#76685] Inode extent management causes high order page allocations Message-Id: <20060303151505.D585E9E2A249@attica.americas.sgi.com> Date: Fri, 3 Mar 2006 09:15:05 -0600 (CST) From: alkirkco@sgi.com (Amanda Kirkconnell) X-archive-position: 7431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: linux-xfs Export xfs_bmap_search_multi_extents(), needed by CXFS 4.1. Date: Fri Mar 3 07:13:07 PST 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica2/alkirkco/XFS/xfs-linux Inspected by: olaf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:207407a linux-2.6/xfs_ksyms.c - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h linux-2.4/xfs_ksyms.c - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h - Export xfs_bmap_search_multi_extents(), needed by CXFS 4.1. From owner-linux-xfs@oss.sgi.com Sat Mar 4 19:19:52 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Mar 2006 19:19:56 -0800 (PST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k253JlW6021658 for ; Sat, 4 Mar 2006 19:19:52 -0800 Received: from saturn.flamingspork.com (ppp163-199.static.internode.on.net [150.101.163.199]) by smtp1.adl2.internode.on.net (8.13.5/8.13.5) with ESMTP id k253KPjV032515 for ; Sun, 5 Mar 2006 13:50:26 +1030 (CST) (envelope-from stewart@flamingspork.com) Received: from localhost.localdomain (unknown [192.168.1.100]) by saturn.flamingspork.com (Postfix) with ESMTP id F2522C3E3CA for ; Sun, 5 Mar 2006 14:20:24 +1100 (EST) Received: by localhost.localdomain (Postfix, from userid 1000) id 1AF381427A53; Sun, 5 Mar 2006 14:21:51 +1100 (EST) Subject: Re: TAKE 928864 - [SUSE#76685] Inode extent management causes high order page allocations From: Stewart Smith To: Linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-s228G4KWKwMsSy3Lx6WZ" Date: Sun, 05 Mar 2006 14:21:51 +1100 Message-Id: <1141528911.16486.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-archive-position: 7434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Content-Length: 1631 Lines: 43 --=-s228G4KWKwMsSy3Lx6WZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-03-02 at 18:43 -0600, Amanda Kirkconnell wrote: > This mod introduces multi-level in-core file extent functionality, > building upon the new layout introduced in mod xfs-linux:xfs-kern:207390a. >=20 > The new multi-level extent allocations are only required for heavily > fragmented files, so the old-style linear extent list is used on files > until the extents reach a pre-determined size of 4k. 4k buffers are > used because this is the system page size on Linux i386 and systems > with larger page sizes don't seem to gain much, if anything, by using > their native page size as the extent buffer size. Also, using 4k extent > buffers everywhere provides a consistent interface for CXFS across > different platforms. So does this aim to speed up file offset to extent lookup on heavily fragmented files when we have all (most) of extents in core? And also to not require such large contiguous kernel memory allocations for lots of extents? (e.g. 10,000 extents) I'm assuming this is more noticeable with CXFS? i.e. less stuff over the wire when only caring about small parts of highly fragmented file. --=20 Stewart Smith (stewart@flamingspork.com) --=-s228G4KWKwMsSy3Lx6WZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBECllPKglWCUL+FDoRAq4GAJ9vXajx6CtHPVM6mn7pc8mn8dLFVwCeNZ9g kVQMcDDR0y6mYSeZuYUWx1M= =FN3u -----END PGP SIGNATURE----- --=-s228G4KWKwMsSy3Lx6WZ-- From owner-linux-xfs@oss.sgi.com Sun Mar 5 11:40:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Mar 2006 11:40:43 -0800 (PST) Received: from imr-m04.mx.aol.com (imr-m04.mx.aol.com [64.12.138.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k25JefW6022477 for ; Sun, 5 Mar 2006 11:40:41 -0800 Received: from imo-d03.mx.aol.com (imo-d03.mail.aol.com [172.18.150.227]) by imr-m04.mx.aol.com (v107.10) with ESMTP id RELAYIN7-8440b3ee11b; Sun, 05 Mar 2006 14:41:21 -0500 Received: from AndyLiebman@aol.com by imo-d03.mx.aol.com (mail_out_v38_r7.3.) id 4.22f.77b7db9 (15699) for ; Sun, 5 Mar 2006 14:25:55 -0500 (EST) Received: from [192.168.1.100] (146-115-27-35.c3-0.abr-ubr2.sbo-abr.ma.cable.rcn.com [146.115.27.35]) by air-id05.mx.aol.com (vx) with ESMTP id MAILINID51-3d53440b3b42107; Sun, 05 Mar 2006 14:25:55 -0500 Message-ID: <440B3B44.2050308@aol.com> Date: Sun, 05 Mar 2006 14:25:56 -0500 From: andy liebman User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS Error Possibly Related To Quota? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 172.18.150.227 X-Mailer: Unknown (No Version) X-archive-position: 7435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andyliebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 14196 Lines: 350 Hi, I'm hoping one of the XFS gurus can weigh in on the incident described below: I just experienced an XFS Error on an 11 TB volume. It seems that I was able to repair the error with "xfs_repair", but I am looking for some insights into why the error occurred. To make a long story short, at 13:11 on February 28, users of this system -- which serves video files for video editing -- noticed two odd symptoms: 1) For the most part, tens of thousands of clips that had previously been captured prior to February 28 played back fine. But any new files that were captured or rendered to the volume after 13:11 on February 28 played back with green flashes or parts of frames missing (the missing parts showing up green). Green is usually what you get when data is missing from a digital video file. 2) SOME files that had been captured prior to February 28 periodically displayed images from completely unrelated files when played back. It's as if bits of different clips got mixed together -- as if the xfs filesystem suddenly start pointing to some incorrect bits of data in the middle of otherwise intact files. Below, I include a snippet from /var/log messages showing when the trouble started. The "messages" file is actually 1 GB in size -- because so many xfs error messages were generated. When compressed as tar.gz, it is still 12 MB! I also include the output from xfs_repair. After running repair, the files seem to play fine again, and we can render and capture new files without getting the green stuff. But the question is, what happened?? /var/log/messages: Feb 28 13:01:00 eshare CROND[498]: (root) CMD (nice -n 19 run-parts /etc/cron.hourly) Feb 28 13:11:11 eshare kernel: 0x0: 76 22 86 22 76 22 86 22 76 22 86 22 76 22 86 22 Feb 28 13:11:11 eshare kernel: Filesystem "md2": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/xf s/xfs_alloc.c. Caller 0xf8c1880a Feb 28 13:11:11 eshare kernel: [pg0+948030533/1069556736] xfs_alloc_read_agf+0x111/0x1f9 [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_read_agf+0x111/0x1f9 [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948029450/1069556736] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948029450/1069556736] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948029450/1069556736] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948386575/1069556736] xfs_trans_log_buf+0x6b/0xa4 [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_trans_log_buf+0x6b/0xa4 [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948033063/1069556736] xfs_alloc_search_busy+0x97/0xdc [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_search_busy+0x97/0xdc [xfs] Feb 28 13:11:11 eshare kernel: [activate_task+147/167] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [activate_task+147/167] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [pg0+948031275/1069556736] xfs_alloc_vextent+0x1fe/0x5bb [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_vextent+0x1fe/0x5bb [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948100610/1069556736] xfs_bmap_alloc+0x1190/0x195d [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmap_alloc+0x1190/0x195d [xfs] Feb 28 13:11:11 eshare kernel: [lock_timer_base+36/73] lock_timer_base+0x24/0x49 Feb 28 13:11:11 eshare kernel: [] lock_timer_base+0x24/0x49 Feb 28 13:11:11 eshare kernel: [sk_reset_timer+28/41] sk_reset_timer+0x1c/0x29 Feb 28 13:11:11 eshare kernel: [] sk_reset_timer+0x1c/0x29 Feb 28 13:11:11 eshare kernel: [pg0+948148400/1069556736] xfs_bmbt_get_state+0x2f/0x3b [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmbt_get_state+0x2f/0x3b [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948109278/1069556736] xfs_bmap_do_search_extents+0xf7/0x48d [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmap_do_search_extents+0xf7/0x48d [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948119268/1069556736]4> [free_pages_bulk+471/497] free_pages_bulk+0x1d7/0x1f 1 Feb 28 13:11:11 eshare kernel: 4> [] free_pages_bulk+0x1d7/0x1f1 Feb 28 13:11:11 eshare kernel: [test_clear_page_dirty+188/250] test_clear_page_dirty+0xbc/0xfa Feb 28 13:11:11 eshare kernel: 4> [] free_pages_bulk+0x1d7/0x1f1 Feb 28 13:11:11 eshare kernel: [test_clear_page_dirty+188/250] test_clear_page_dirty+0xbc/0xfa Feb 28 13:11:11 eshare kernel: [] test_clear_page_dirty+0xbc/0xfa Feb 28 13:11:11 eshare kernel: [pg0+948444228/1069556736] linvfs_writepage+0x72/0x128 [xfs] Feb 28 13:11:11 eshare kernel: [] linvfs_writepage+0x72/0x128 [xfs] Feb 28 13:11:11 eshare kernel: [pageout+179/309] pageout+0xb3/0x135 Feb 28 13:11:11 eshare kernel: [] pageout+0xb3/0x135 Feb 28 13:11:11 eshare kernel: [__remove_from_page_cache+30/99] __remove_from_page_cache+0x1e/0x63 Feb 28 13:11:11 eshare kernel: [] __remove_from_page_cache+0x1e/0x63 Feb 28 13:11:11 eshare kernel: [shrink_list+482/1070] shrink_list+0x1e2/0x42e Feb 28 13:11:11 eshare kernel: [] shrink_list+0x1e2/0x42e Feb 28 13:11:11 eshare kernel: [try_to_wake_up+680/869] try_to_wake_up+0x2a8/0x365 Feb 28 13:11:11 eshare kernel: [] try_to_wake_up+0x2a8/0x365 Feb 28 13:11:11 eshare kernel: [shrink_cache+275/669] shrink_cache+0x113/0x29d Feb 28 13:11:11 eshare kernel: [] shrink_cache+0x113/0x29d Feb 28 13:11:11 eshare kernel: [wake_up_process+30/32] wake_up_process+0x1e/0x20 Feb 28 13:11:11 eshare kernel: [] wake_up_process+0x1e/0x20 Feb 28 13:11:11 eshare kernel: [shrink_slab+149/415] shrink_slab+0x95/0x19f Feb 28 13:11:11 eshare kernel: [] shrink_slab+0x95/0x19f Feb 28 13:11:11 eshare kernel: [shrink_zone+184/222] shrink_zone+0xb8/0xde Feb 28 13:11:11 eshare kernel: [] shrink_zone+0xb8/0xde Feb 28 13:11:11 eshare kernel: [balance_pgdat+612/1005] balance_pgdat+0x264/0x3ed Feb 28 13:11:11 eshare kernel: [] balance_pgdat+0x264/0x3ed Feb 28 13:11:11 eshare kernel: [prepare_to_wait+32/105] prepare_to_wait+0x20/0x69 Feb 28 13:11:11 eshare kernel: [] prepare_to_wait+0x20/0x69 Feb 28 13:11:11 eshare kernel: [kswapd+232/312] kswapd+0xe8/0x138 Feb 28 13:11:11 eshare kernel: [] kswapd+0xe8/0x138 Feb 28 13:11:11 eshare kernel: [autoremove_wake_function+0/87] autoremove_wake_function+0x0/0x57 Feb 28 13:11:11 eshare kernel: [] autoremove_wake_function+0x0/0x57 Feb 28 13:11:11 eshare kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14 Feb 28 13:11:11 eshare kernel: [] ret_from_fork+0x6/0x14 Feb 28 13:11:11 eshare kernel: [autoremove_wake_function+0/87] autoremove_wake_function+0x0/0x57 Feb 28 13:11:11 eshare kernel: [] autoremove_wake_function+0x0/0x57 Feb 28 13:11:11 eshare kernel: [kswapd+0/312] kswapd+0x0/0x138 Feb 28 13:11:11 eshare kernel: [] kswapd+0x0/0x138 Feb 28 13:11:11 eshare kernel: [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb Feb 28 13:11:11 eshare kernel: [] kernel_thread_helper+0x5/0xb Feb 28 13:11:11 eshare kernel: 0x0: 76 22 86 22 76 22 86 22 76 22 86 22 76 22 86 22 Feb 28 13:11:11 eshare kernel: Filesystem "md2": XFS internal error xfs_alloc_read_agf at line 2195 of file fs/xf s/xfs_alloc.c. Caller 0xf8c1880a Feb 28 13:11:11 eshare kernel: [pg0+948030533/1069556736] xfs_alloc_read_agf+0x111/0x1f9 [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_read_agf+0x111/0x1f9 [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948029450/1069556736] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948029450/1069556736] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948029450/1069556736] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_fix_freelist+0x44a/0x48e [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948386575/1069556736] xfs_trans_log_buf+0x6b/0xa4 [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_trans_log_buf+0x6b/0xa4 [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948033063/1069556736] xfs_alloc_search_busy+0x97/0xdc [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_search_busy+0x97/0xdc [xfs] Feb 28 13:11:11 eshare kernel: [activate_task+147/167] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [activate_task+147/167] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [] activate_task+0x93/0xa7 Feb 28 13:11:11 eshare kernel: [pg0+948031275/1069556736] xfs_alloc_vextent+0x1fe/0x5bb [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_alloc_vextent+0x1fe/0x5bb [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948100610/1069556736] xfs_bmap_alloc+0x1190/0x195d [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmap_alloc+0x1190/0x195d [xfs] Feb 28 13:11:11 eshare kernel: [lock_timer_base+36/73] lock_timer_base+0x24/0x49 Feb 28 13:11:11 eshare kernel: [] lock_timer_base+0x24/0x49 Feb 28 13:11:11 eshare kernel: [sk_reset_timer+28/41] sk_reset_timer+0x1c/0x29 Feb 28 13:11:11 eshare kernel: [] sk_reset_timer+0x1c/0x29 Feb 28 13:11:11 eshare kernel: [pg0+948148400/1069556736] xfs_bmbt_get_state+0x2f/0x3b [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmbt_get_state+0x2f/0x3b [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948109278/1069556736] xfs_bmap_do_search_extents+0xf7/0x48d [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmap_do_search_extents+0xf7/0x48d [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948119268/1069556736] xfs_bmapi+0xff9/0x1826 [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmapi+0xff9/0x1826 [xfs] Feb 28 13:11:11 eshare kernel: [mempool_alloc+51/230] mempool_alloc+0x33/0xe6 Feb 28 13:11:11 eshare kernel: [] mempool_alloc+0x33/0xe6 Feb 28 13:11:11 eshare kernel: [pg0+948148400/1069556736] xfs_bmbt_get_state+0x2f/0x3b [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmbt_get_state+0x2f/0x3b [xfs] Feb 28 13:11:11 eshare kernel: [pg0+948109278/1069556736] xfs_bmap_do_search_extents+0xf7/0x48d [xfs] Feb 28 13:11:11 eshare kernel: [] xfs_bmap_do_search_extents+0xf7/0x48d [xfs] XFS_REPAIR [root@eshare RAID_1]# xfs_repair -v /dev/md2 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 40861 tail block 40861 - scan filesystem freespace and inode maps... bad on-disk superblock 31 - bad magic number primary/secondary superblock 31 conflict - AG superblock geometry info conflicts with filesystem geometry non-null user quota inode field in superblock 31 non-null group quota inode field in superblock 31 bad magic # 0x76228622 for agf 31 bad version # 1981974050 for agf 31 bad sequence # 1981974050 for agf 31 bad length 1981974050 for agf 31, should be 83919936 flfirst 1965262628 in agf 31 too large (max = 128) fllast 1948550948 in agf 31 too large (max = 128) bad magic # 0x752f862f for agi 31 bad version # 1965983278 for agi 31 bad sequence # 1982760492 for agi 31 bad length # 1965590054 for agi 31, should be 83919936 reset bad sb for ag 31 reset bad agf for ag 31 reset bad agi for ag 31 bad agbno 1748602424 in agfl, agno 31 freeblk count 1 != flcount 1948550948 in ag 31 bad agbno 1981974050 for btbno root, agno 31 bad agbno 1981974050 for btbcnt root, agno 31 bad agbno 1948550948 for inobt root, agno 31 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 31 unlinked list - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done Andy Liebman From owner-linux-xfs@oss.sgi.com Sun Mar 5 14:40:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Mar 2006 14:40:04 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k25Me2W6006908 for ; Sun, 5 Mar 2006 14:40:02 -0800 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id k25Mel2V019773; Sun, 5 Mar 2006 14:40:47 -0800 Message-ID: <440B68D7.8060106@tlinx.org> Date: Sun, 05 Mar 2006 14:40:23 -0800 From: Linda Walsh User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Linux-Xfs CC: Linux-Kernel Subject: XFS _apparent_ corruption: "DATA POINT" (worked around); 2.6.15.4-biglowmem Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2633 Lines: 76 Running 2.6.15.4 with the "biglowmem" patch (to allow using last 128M of 1G address space w/o calling it HIGHMEM, and using a 3+1G memory split. System has been _stable_: uptime was 20days+11:04. I tried doing an 'ls' of a directory and my system hung -- no panic, no message. Had been doing compiles/tests on same disk w/no problems (~26G used, 94G total, 68G free). * Rebooted, went back to same dir -- hung again. * Rebooted, unmounted partition > xfs_check claimed a journal needed to play. * Remounted partition -- no problem; unmount; > xfs_check -- claimed journal present > xfs_repair -- claimed journal present *> remount & unmount; xfs_repair still sees journal; * xfs_logprint gave: ---- ls ->hang fs_logprint: xfs_logprint: /dev/hde1 contains a mounted and writable filesystem data device: 0x2101 log device: 0x2101 daddr: 100663328 length: 95392 Header 0x3ef wanted 0xfeedbabe ********************************************************************** * ERROR: header cycle=1007 block=38747 * ********************************************************************** Bad log record header -------- * Decide to delete bad log: run xfs_repair -L /dev/hde1 : runs completely through: NO ERRORS; * run xfs_check again (partition is unmounted(!)): output: sb_ifree 47759, counted 47758 * mount partition, try to access bad directory: > immediate system hang * reboot under earlier kernel (2.6.14.4 - vanilla) * go to same directory, ls: > NO HANG; * unmount and respect with xfs_{check,repair}: expect to see no errors > WRONG (sorta): both believe there is a log again: * xfs_logprint: ------ (slightly different output) Bad log record header xfs_logprint: data device: 0x2101 log device: 0x2101 daddr: 156288352 length: 152624 Header 0x84 wanted 0xfeedbabe ********************************************************************** * ERROR: header cycle=132 block=52801 * ********************************************************************** --------- * This time, I run xfs_repair with -L; remembering "no errors, and not wanting to wait through another full "xfs_fsck", I abort after it starts (and after -L has removed problem log). * I run xfs_check: > no output (no errors found). * To try to avoid problem, I copy the troublesome directory to another directory name and delete the old directory. * run xfs_check: > no output (no error indicated) => Problem seems to have been dealt with; this report is meant as a datapoint in case other problems come in... -linda _ _ From owner-linux-xfs@oss.sgi.com Sun Mar 5 16:03:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Mar 2006 16:03:27 -0800 (PST) Received: from larry.melbourne.sgi.com ([61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k2603MW6012719 for ; Sun, 5 Mar 2006 16:03:23 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27276; Mon, 6 Mar 2006 11:03:51 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 34B3249F1681; Mon, 6 Mar 2006 11:03:50 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 947312 - reduce stack footprint Message-Id: <20060306000350.34B3249F1681@chook.melbourne.sgi.com> Date: Mon, 6 Mar 2006 11:03:50 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4788 Lines: 130 [Bunch of stuff, all over the map, to help reduce our stack use] Dynamically allocate local kiocb structures in readv/writev routines to reduce stack footprint. Date: Fri Mar 3 14:18:51 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan,sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25358a linux-2.6/xfs_file.c - 1.129 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.129&r2=text&tr2=1.128&f=h Dynamically allocate xfs_dir2_put_args_t structure to reduce stack pressure in xfs_dir2_leaf_getdents routine. Date: Fri Mar 3 14:22:33 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25359a xfs_dir2_leaf.c - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h Reduce complexity in xfs_trans_init by pushing complex macros out into functions and hence reduce the stack footprint there. Date: Fri Mar 3 14:23:28 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25360a xfs_trans.c - 1.170 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.170&r2=text&tr2=1.169&f=h Take a dentry structure off the stack into the data segment. Date: Fri Mar 3 14:24:30 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25361a linux-2.6/xfs_export.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h Dynamically allocate vattr in places it makes sense to do so, to reduce stack use. Also re-use vattr in some places so that multiple copies are not held on-stack. Date: Mon Mar 6 10:38:43 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25369a linux-2.6/xfs_ioctl.c - 1.131 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h linux-2.6/xfs_file.c - 1.130 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h linux-2.6/xfs_vnode.c - 1.136 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.c.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h linux-2.6/xfs_vnode.h - 1.115 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.115&r2=text&tr2=1.114&f=h linux-2.6/xfs_iops.c - 1.240 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.240&r2=text&tr2=1.239&f=h Reduce xfs_bmapi stack use by removing some local state variables, and directly testing flags instead. Date: Mon Mar 6 10:40:50 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25370a xfs_bmap.c - 1.342 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.342&r2=text&tr2=1.341&f=h Reduce dmapi stack use. Date: Mon Mar 6 10:47:28 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: bobo,cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25371a dmapi/xfs_dm.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Reduce stack usage within xfs_bmapi by rearranging some code, splitting realtime/btree allocators apart. Based on Glens original patches. Date: Mon Mar 6 11:02:56 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: overby,cattelan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25372a xfs_bmap.c - 1.343 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.343&r2=text&tr2=1.342&f=h From owner-linux-xfs@oss.sgi.com Sun Mar 5 21:19:43 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Mar 2006 21:19:47 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k265JfW6012188 for ; Sun, 5 Mar 2006 21:19:42 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA00892; Mon, 6 Mar 2006 16:20:22 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 31FF049F1681; Mon, 6 Mar 2006 16:20:22 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 950556 - remove (some) linvfs names Message-Id: <20060306052022.31FF049F1681@chook.melbourne.sgi.com> Date: Mon, 6 Mar 2006 16:20:22 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 7720 Lines: 144 Remove a couple of no-longer-used macros/types from XFS. Date: Mon Mar 6 16:09:53 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: kbeck The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25377a xfs_mount.h - 1.217 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h linux-2.6/kmem.h - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.h.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h linux-2.4/kmem.h - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/kmem.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h Switch over from linvfs names for address space ops for consistent naming. Date: Mon Mar 6 16:14:35 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: kbeck The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25378a linux-2.6/xfs_super.c - 1.358 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.358&r2=text&tr2=1.357&f=h linux-2.6/xfs_iops.c - 1.241 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.241&r2=text&tr2=1.240&f=h linux-2.6/xfs_aops.c - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h linux-2.4/xfs_linux.h - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h linux-2.4/xfs_super.c - 1.324 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.324&r2=text&tr2=1.323&f=h linux-2.4/xfs_iops.c - 1.220 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.220&r2=text&tr2=1.219&f=h linux-2.4/xfs_iops.h - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.h.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h linux-2.4/xfs_aops.c - 1.97 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.97&r2=text&tr2=1.96&f=h linux-2.6/xfs_ksyms.c - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h linux-2.4/xfs_ksyms.c - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h linux-2.6/xfs_aops.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Switch over from linvfs names for file operations for consistent naming. Date: Mon Mar 6 16:15:59 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: kbeck The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25379a linux-2.6/xfs_ioctl.c - 1.132 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.132&r2=text&tr2=1.131&f=h linux-2.6/xfs_file.c - 1.131 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h linux-2.6/xfs_super.c - 1.359 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.359&r2=text&tr2=1.358&f=h linux-2.6/xfs_iops.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h linux-2.4/xfs_ioctl.c - 1.127 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h linux-2.4/xfs_file.c - 1.122 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.122&r2=text&tr2=1.121&f=h linux-2.4/xfs_super.c - 1.325 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.325&r2=text&tr2=1.324&f=h linux-2.4/xfs_iops.h - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h linux-2.6/xfs_ksyms.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h linux-2.4/xfs_ksyms.c - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h dmapi/xfs_dm_fsops.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_fsops.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h dmapi/xfs_dm.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Switch over from linvfs names for inode operations for consistent naming. Date: Mon Mar 6 16:17:29 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: kbeck The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25381a linux-2.6/xfs_super.c - 1.360 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.360&r2=text&tr2=1.359&f=h linux-2.6/xfs_iops.c - 1.242 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.242&r2=text&tr2=1.241&f=h linux-2.6/xfs_iops.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h linux-2.4/xfs_super.c - 1.326 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.326&r2=text&tr2=1.325&f=h linux-2.4/xfs_iops.c - 1.221 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.221&r2=text&tr2=1.220&f=h linux-2.4/xfs_iops.h - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h linux-2.6/xfs_ksyms.c - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h linux-2.4/xfs_ksyms.c - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h Switch over from linvfs names for sb/quotactl operations for consistent naming. Date: Mon Mar 6 16:19:26 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: kbeck The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25382a linux-2.6/xfs_super.h - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.h.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h linux-2.6/xfs_super.c - 1.361 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.361&r2=text&tr2=1.360&f=h linux-2.4/xfs_super.c - 1.327 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.327&r2=text&tr2=1.326&f=h linux-2.6/xfs_ioctl32.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h linux-2.6/xfs_ioctl32.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h linux-2.6/xfs_export.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h From owner-linux-xfs@oss.sgi.com Sun Mar 5 23:13:51 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Mar 2006 23:13:53 -0800 (PST) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.179]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k267DoW6020225 for ; Sun, 5 Mar 2006 23:13:50 -0800 Received: by pproxy.gmail.com with SMTP id s49so781962pyc for ; Sun, 05 Mar 2006 23:14:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=d5GNTxMTleSYB6hrDETHAh7v/1R39goUthb6vZQjbM8RfvzshIJGs8gy5p0qIzGxPydzySY2F4djoup5BNd3TCNGkOtdOii9X+D8aB+dJn7X46grSCIzHVCrsFTpiaUJj522lh9QzoCdr17xUtfW1Jw+5uK4h+IXwHxMbvOUI3c= Received: by 10.65.158.12 with SMTP id k12mr2410087qbo; Sun, 05 Mar 2006 20:43:37 -0800 (PST) Received: by 10.65.139.12 with HTTP; Sun, 5 Mar 2006 20:43:37 -0800 (PST) Message-ID: <3aa654a40603052043v17624b4fv1916e4e7f31e52aa@mail.gmail.com> Date: Sun, 5 Mar 2006 20:43:37 -0800 From: "Avuton Olrich" To: "Linux Kernel Mailing List" Subject: XFS oops in v2.6.16-rc5 Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id k267DpW6020228 X-archive-position: 7440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 32720 Lines: 140 I'm not sure when this started, but it has been happening (at least)for the last week, I regularly pull git. I just haven't had the timeto record this oops output until now, and I had to use thehand-and-paper method. I did try to verify as well as possible. Also,I ran fsck to fix errorson this disk in the last week, but it appears the problem still exists. It does happen often, but I haven't happened to have netconsole onwhen it happens. Also S3 does work on this laptop and I use it often,although I'm not sure that's any help. I'm not sure when I changed to XFS (within the last two months) andI'm also not sure when this appeared to start happening :/ Thisproblem does corrupt whatever I was last working on (usually sourcefiles, it makes them into binaries, at least until I fsck) Linux micromachine 2.6.16-rc5 #16 PREEMPT Sun Mar 5 13:13:58 PST 2006i686 Transmeta(tm) Crusoe(tm) Processor TM5800 GNU/Linux kernel: 2.6.16-rc5 git: >master ea088b8d481fcff001f7e628c44daf39a229d9fc Unable to handle kernel NULL pointer dereference at virtual address: 00000000print eip:c022b3c1*pde = 00000000Oops: 0000 [#1]PREEMPTModules linked in: snd_seq snd_seq_device snd_ali5154 snd_ac97_codecsnd_ac97_bus snd_pcm snd_timer snd snd_page_alloc ext2 vfatCPU: 0EIP: 0060:[] Not tainted VLIEFLAGS: 00010246 (2.6.16-rc5 #15)EIP is at xfs_read+0x121/0x2e0eax: 00000000 ebx: 00001000 ecx: d0a30768 edx: cd2660b8esi: fffffffb edi: 00000000 ebp: 00000001 esp: d89d5e68ds: 007b es: 0076 ss: 0068Process xdm (pid 29670, threadinfo=d89d5000 task=d6cc7a90)Stack: <0>db6c1000 c1578990 c145f220 c01457bd b7fdb000 d89d5f64d89d5ed0 d89d5ef8 d0a30788 cd26b0b8 00000000 00000000 c6258f40 cd26b5d4d0a30768 c154c400 00000000 c0416ba0 00000000 d89d5ef8 cd26b5d4 c0227ff6 00000001 d89d5f40 Call Trace:[] unmap_region+0xad/0x110[] linvfs_aio_read+0x76/0xa0[] do_sync_read+0xb8/0x100[] autoremove_wake_function+0x0/0x50[] vfs_read+0xa1/0x160[] do_sync_read+0x0/0x100[] sys_read+0x41/0x70[] sysenter_past_esp+0x54/0x75 Code: 00 89 d1 83 e0 10 09 c1 75 c2 8b 44 24 2c 85 c0 0f 85 bc 01 0000 8b 44 24 38 ba 02 00 00 00 e8 26 2e fd ff 8b 54 24 24 8b 42 04 00 04 0f 8513 01 00 00 8b 44 24 5c 89 e9 8b 54 24 18 89 04 dmesg: # Automatically generated make config: don't edit# Linux kernel version: 2.6.16-rc5# Sat Mar 4 23:24:09 2006#CONFIG_X86_32=yCONFIG_SEMAPHORE_SLEEPERS=yCONFIG_X86=yCONFIG_MMU=yCONFIG_GENERIC_ISA_DMA=yCONFIG_GENERIC_IOMAP=yCONFIG_ARCH_MAY_HAVE_PC_FDC=yCONFIG_DMI=y ## Code maturity level options#CONFIG_EXPERIMENTAL=yCONFIG_BROKEN_ON_SMP=yCONFIG_LOCK_KERNEL=yCONFIG_INIT_ENV_ARG_LIMIT=32 ## General setup#CONFIG_LOCALVERSION=""# CONFIG_LOCALVERSION_AUTO is not setCONFIG_SWAP=yCONFIG_SYSVIPC=y# CONFIG_POSIX_MQUEUE is not set# CONFIG_BSD_PROCESS_ACCT is not setCONFIG_SYSCTL=y# CONFIG_AUDIT is not setCONFIG_IKCONFIG=yCONFIG_IKCONFIG_PROC=yCONFIG_INITRAMFS_SOURCE=""CONFIG_UID16=yCONFIG_VM86=y# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set# CONFIG_EMBEDDED is not setCONFIG_KALLSYMS=y# CONFIG_KALLSYMS_ALL is not set# CONFIG_KALLSYMS_EXTRA_PASS is not setCONFIG_HOTPLUG=yCONFIG_PRINTK=yCONFIG_BUG=yCONFIG_ELF_CORE=yCONFIG_BASE_FULL=yCONFIG_FUTEX=yCONFIG_EPOLL=yCONFIG_SHMEM=yCONFIG_CC_ALIGN_FUNCTIONS=0CONFIG_CC_ALIGN_LABELS=0CONFIG_CC_ALIGN_LOOPS=0CONFIG_CC_ALIGN_JUMPS=0CONFIG_SLAB=y# CONFIG_TINY_SHMEM is not setCONFIG_BASE_SMALL=0# CONFIG_SLOB is not set ## Loadable module support#CONFIG_MODULES=yCONFIG_MODULE_UNLOAD=y# CONFIG_MODULE_FORCE_UNLOAD is not setCONFIG_OBSOLETE_MODPARM=y# CONFIG_MODVERSIONS is not set# CONFIG_MODULE_SRCVERSION_ALL is not setCONFIG_KMOD=y ## Block layer#CONFIG_LBD=y ## IO Schedulers#CONFIG_IOSCHED_NOOP=yCONFIG_IOSCHED_AS=yCONFIG_IOSCHED_DEADLINE=mCONFIG_IOSCHED_CFQ=mCONFIG_DEFAULT_AS=y# CONFIG_DEFAULT_DEADLINE is not set# CONFIG_DEFAULT_CFQ is not set# CONFIG_DEFAULT_NOOP is not setCONFIG_DEFAULT_IOSCHED="anticipatory" ## Processor type and features#CONFIG_X86_PC=y# CONFIG_X86_ELAN is not set# CONFIG_X86_VOYAGER is not set# CONFIG_X86_NUMAQ is not set# CONFIG_X86_SUMMIT is not set# CONFIG_X86_BIGSMP is not set# CONFIG_X86_VISWS is not set# CONFIG_X86_GENERICARCH is not set# CONFIG_X86_ES7000 is not set# CONFIG_M386 is not set# CONFIG_M486 is not set# CONFIG_M586 is not set# CONFIG_M586TSC is not set# CONFIG_M586MMX is not set# CONFIG_M686 is not set# CONFIG_MPENTIUMII is not set# CONFIG_MPENTIUMIII is not set# CONFIG_MPENTIUMM is not set# CONFIG_MPENTIUM4 is not set# CONFIG_MK6 is not set# CONFIG_MK7 is not set# CONFIG_MK8 is not setCONFIG_MCRUSOE=y# CONFIG_MEFFICEON is not set# CONFIG_MWINCHIPC6 is not set# CONFIG_MWINCHIP2 is not set# CONFIG_MWINCHIP3D is not set# CONFIG_MGEODEGX1 is not set# CONFIG_MGEODE_LX is not set# CONFIG_MCYRIXIII is not set# CONFIG_MVIAC3_2 is not set# CONFIG_X86_GENERIC is not setCONFIG_X86_CMPXCHG=yCONFIG_X86_XADD=yCONFIG_X86_L1_CACHE_SHIFT=5CONFIG_RWSEM_XCHGADD_ALGORITHM=yCONFIG_GENERIC_CALIBRATE_DELAY=yCONFIG_X86_WP_WORKS_OK=yCONFIG_X86_INVLPG=yCONFIG_X86_BSWAP=yCONFIG_X86_POPAD_OK=yCONFIG_X86_CMPXCHG64=yCONFIG_X86_TSC=yCONFIG_HPET_TIMER=yCONFIG_HPET_EMULATE_RTC=y# CONFIG_SMP is not set# CONFIG_PREEMPT_NONE is not set# CONFIG_PREEMPT_VOLUNTARY is not setCONFIG_PREEMPT=yCONFIG_PREEMPT_BKL=y# CONFIG_X86_UP_APIC is not set# CONFIG_X86_MCE is not setCONFIG_TOSHIBA=y# CONFIG_I8K is not set# CONFIG_X86_REBOOTFIXUPS is not set# CONFIG_MICROCODE is not setCONFIG_X86_MSR=yCONFIG_X86_CPUID=y ## Firmware Drivers## CONFIG_EDD is not set# CONFIG_DELL_RBU is not set# CONFIG_DCDBAS is not setCONFIG_NOHIGHMEM=y# CONFIG_HIGHMEM4G is not set# CONFIG_HIGHMEM64G is not setCONFIG_VMSPLIT_3G=y# CONFIG_VMSPLIT_3G_OPT is not set# CONFIG_VMSPLIT_2G is not set# CONFIG_VMSPLIT_1G is not setCONFIG_PAGE_OFFSET=0xC0000000CONFIG_ARCH_FLATMEM_ENABLE=yCONFIG_ARCH_SPARSEMEM_ENABLE=yCONFIG_ARCH_SELECT_MEMORY_MODEL=yCONFIG_SELECT_MEMORY_MODEL=yCONFIG_FLATMEM_MANUAL=y# CONFIG_DISCONTIGMEM_MANUAL is not set# CONFIG_SPARSEMEM_MANUAL is not setCONFIG_FLATMEM=yCONFIG_FLAT_NODE_MEM_MAP=yCONFIG_SPARSEMEM_STATIC=yCONFIG_SPLIT_PTLOCK_CPUS=4# CONFIG_MATH_EMULATION is not setCONFIG_MTRR=y# CONFIG_EFI is not setCONFIG_REGPARM=y# CONFIG_SECCOMP is not set# CONFIG_HZ_100 is not setCONFIG_HZ_250=y# CONFIG_HZ_1000 is not setCONFIG_HZ=250CONFIG_KEXEC=yCONFIG_PHYSICAL_START=0x100000CONFIG_DOUBLEFAULT=y ## Power management options (ACPI, APM)#CONFIG_PM=y# CONFIG_PM_LEGACY is not set# CONFIG_PM_DEBUG is not set# CONFIG_SOFTWARE_SUSPEND is not set ## ACPI (Advanced Configuration and Power Interface) Support#CONFIG_ACPI=yCONFIG_ACPI_SLEEP=yCONFIG_ACPI_SLEEP_PROC_FS=y# CONFIG_ACPI_SLEEP_PROC_SLEEP is not setCONFIG_ACPI_AC=yCONFIG_ACPI_BATTERY=yCONFIG_ACPI_BUTTON=yCONFIG_ACPI_VIDEO=yCONFIG_ACPI_HOTKEY=yCONFIG_ACPI_FAN=yCONFIG_ACPI_PROCESSOR=yCONFIG_ACPI_THERMAL=y# CONFIG_ACPI_ASUS is not set# CONFIG_ACPI_IBM is not setCONFIG_ACPI_TOSHIBA=yCONFIG_ACPI_BLACKLIST_YEAR=0# CONFIG_ACPI_DEBUG is not setCONFIG_ACPI_EC=yCONFIG_ACPI_POWER=yCONFIG_ACPI_SYSTEM=yCONFIG_X86_PM_TIMER=y# CONFIG_ACPI_CONTAINER is not set ## APM (Advanced Power Management) BIOS Support## CONFIG_APM is not set ## CPU Frequency scaling#CONFIG_CPU_FREQ=yCONFIG_CPU_FREQ_TABLE=m# CONFIG_CPU_FREQ_DEBUG is not set# CONFIG_CPU_FREQ_STAT is not setCONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not setCONFIG_CPU_FREQ_GOV_PERFORMANCE=y# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set# CONFIG_CPU_FREQ_GOV_USERSPACE is not set# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set ## CPUFreq processor drivers## CONFIG_X86_ACPI_CPUFREQ is not set# CONFIG_X86_POWERNOW_K6 is not set# CONFIG_X86_POWERNOW_K7 is not set# CONFIG_X86_POWERNOW_K8 is not set# CONFIG_X86_GX_SUSPMOD is not set# CONFIG_X86_SPEEDSTEP_CENTRINO is not set# CONFIG_X86_SPEEDSTEP_ICH is not set# CONFIG_X86_SPEEDSTEP_SMI is not set# CONFIG_X86_P4_CLOCKMOD is not set# CONFIG_X86_CPUFREQ_NFORCE2 is not setCONFIG_X86_LONGRUN=y# CONFIG_X86_LONGHAUL is not set ## shared options## CONFIG_X86_SPEEDSTEP_LIB is not set ## Bus options (PCI, PCMCIA, EISA, MCA, ISA)#CONFIG_PCI=y# CONFIG_PCI_GOBIOS is not set# CONFIG_PCI_GOMMCONFIG is not set# CONFIG_PCI_GODIRECT is not setCONFIG_PCI_GOANY=yCONFIG_PCI_BIOS=yCONFIG_PCI_DIRECT=yCONFIG_PCI_MMCONFIG=y# CONFIG_PCIEPORTBUS is not set# CONFIG_PCI_LEGACY_PROC is not set# CONFIG_PCI_DEBUG is not setCONFIG_ISA_DMA_API=y# CONFIG_ISA is not set# CONFIG_MCA is not set# CONFIG_SCx200 is not set ## PCCARD (PCMCIA/CardBus) support#CONFIG_PCCARD=m# CONFIG_PCMCIA_DEBUG is not setCONFIG_PCMCIA=mCONFIG_PCMCIA_LOAD_CIS=yCONFIG_PCMCIA_IOCTL=yCONFIG_CARDBUS=y ## PC-card bridges#CONFIG_YENTA=mCONFIG_YENTA_O2=yCONFIG_YENTA_RICOH=yCONFIG_YENTA_TI=yCONFIG_YENTA_ENE_TUNE=yCONFIG_YENTA_TOSHIBA=y# CONFIG_PD6729 is not set# CONFIG_I82092 is not setCONFIG_PCCARD_NONSTATIC=m ## PCI Hotplug Support## CONFIG_HOTPLUG_PCI is not set ## Executable file formats#CONFIG_BINFMT_ELF=yCONFIG_BINFMT_AOUT=yCONFIG_BINFMT_MISC=y ## Networking#CONFIG_NET=y ## Networking options## CONFIG_NETDEBUG is not setCONFIG_PACKET=yCONFIG_PACKET_MMAP=yCONFIG_UNIX=yCONFIG_XFRM=y# CONFIG_XFRM_USER is not setCONFIG_NET_KEY=mCONFIG_INET=yCONFIG_IP_MULTICAST=y# CONFIG_IP_ADVANCED_ROUTER is not setCONFIG_IP_FIB_HASH=y# CONFIG_IP_PNP is not set# CONFIG_NET_IPIP is not set# CONFIG_NET_IPGRE is not set# CONFIG_IP_MROUTE is not set# CONFIG_ARPD is not set# CONFIG_SYN_COOKIES is not set# CONFIG_INET_AH is not set# CONFIG_INET_ESP is not set# CONFIG_INET_IPCOMP is not set# CONFIG_INET_TUNNEL is not set# CONFIG_INET_DIAG is not set# CONFIG_TCP_CONG_ADVANCED is not setCONFIG_TCP_CONG_BIC=y ## IP: Virtual Server Configuration## CONFIG_IP_VS is not set# CONFIG_IPV6 is not setCONFIG_NETFILTER=y# CONFIG_NETFILTER_DEBUG is not set ## Core Netfilter Configuration## CONFIG_NETFILTER_NETLINK is not set# CONFIG_NETFILTER_XTABLES is not set ## IP: Netfilter Configuration#CONFIG_IP_NF_CONNTRACK=y# CONFIG_IP_NF_CT_ACCT is not set# CONFIG_IP_NF_CONNTRACK_MARK is not set# CONFIG_IP_NF_CONNTRACK_EVENTS is not set# CONFIG_IP_NF_CT_PROTO_SCTP is not set# CONFIG_IP_NF_FTP is not set# CONFIG_IP_NF_IRC is not set# CONFIG_IP_NF_NETBIOS_NS is not set# CONFIG_IP_NF_TFTP is not set# CONFIG_IP_NF_AMANDA is not set# CONFIG_IP_NF_PPTP is not setCONFIG_IP_NF_QUEUE=y ## DCCP Configuration (EXPERIMENTAL)## CONFIG_IP_DCCP is not set ## SCTP Configuration (EXPERIMENTAL)## CONFIG_IP_SCTP is not set ## TIPC Configuration (EXPERIMENTAL)## CONFIG_TIPC is not set# CONFIG_ATM is not set# CONFIG_BRIDGE is not set# CONFIG_VLAN_8021Q is not set# CONFIG_DECNET is not set# CONFIG_LLC2 is not set# CONFIG_IPX is not set# CONFIG_ATALK is not set# CONFIG_X25 is not set# CONFIG_LAPB is not set# CONFIG_NET_DIVERT is not set# CONFIG_ECONET is not set# CONFIG_WAN_ROUTER is not set ## QoS and/or fair queueing## CONFIG_NET_SCHED is not set ## Network testing## CONFIG_NET_PKTGEN is not set# CONFIG_HAMRADIO is not set# CONFIG_IRDA is not set# CONFIG_BT is not set# CONFIG_IEEE80211 is not set ## Device Drivers# ## Generic Driver Options#CONFIG_STANDALONE=yCONFIG_PREVENT_FIRMWARE_BUILD=yCONFIG_FW_LOADER=m# CONFIG_DEBUG_DRIVER is not set ## Connector - unified userspace <-> kernelspace linker## CONFIG_CONNECTOR is not set ## Memory Technology Devices (MTD)## CONFIG_MTD is not set ## Parallel port support## CONFIG_PARPORT is not set ## Plug and Play support## CONFIG_PNP is not set ## Block devices## CONFIG_BLK_DEV_FD is not set# CONFIG_BLK_CPQ_DA is not set# CONFIG_BLK_CPQ_CISS_DA is not set# CONFIG_BLK_DEV_DAC960 is not set# CONFIG_BLK_DEV_UMEM is not set# CONFIG_BLK_DEV_COW_COMMON is not setCONFIG_BLK_DEV_LOOP=mCONFIG_BLK_DEV_CRYPTOLOOP=m# CONFIG_BLK_DEV_NBD is not set# CONFIG_BLK_DEV_SX8 is not set# CONFIG_BLK_DEV_UB is not set# CONFIG_BLK_DEV_RAM is not setCONFIG_BLK_DEV_RAM_COUNT=16# CONFIG_CDROM_PKTCDVD is not set# CONFIG_ATA_OVER_ETH is not set ## ATA/ATAPI/MFM/RLL support#CONFIG_IDE=yCONFIG_BLK_DEV_IDE=y ## Please see Documentation/ide.txt for help/info on IDE drives## CONFIG_BLK_DEV_IDE_SATA is not set# CONFIG_BLK_DEV_HD_IDE is not setCONFIG_BLK_DEV_IDEDISK=yCONFIG_IDEDISK_MULTI_MODE=y# CONFIG_BLK_DEV_IDECS is not setCONFIG_BLK_DEV_IDECD=m# CONFIG_BLK_DEV_IDETAPE is not set# CONFIG_BLK_DEV_IDEFLOPPY is not setCONFIG_BLK_DEV_IDESCSI=y# CONFIG_IDE_TASK_IOCTL is not set ## IDE chipset support/bugfixes## CONFIG_IDE_GENERIC is not set# CONFIG_BLK_DEV_CMD640 is not setCONFIG_BLK_DEV_IDEPCI=yCONFIG_IDEPCI_SHARE_IRQ=y# CONFIG_BLK_DEV_OFFBOARD is not set# CONFIG_BLK_DEV_GENERIC is not set# CONFIG_BLK_DEV_OPTI621 is not set# CONFIG_BLK_DEV_RZ1000 is not setCONFIG_BLK_DEV_IDEDMA_PCI=y# CONFIG_BLK_DEV_IDEDMA_FORCED is not setCONFIG_IDEDMA_PCI_AUTO=y# CONFIG_IDEDMA_ONLYDISK is not set# CONFIG_BLK_DEV_AEC62XX is not setCONFIG_BLK_DEV_ALI15X3=y# CONFIG_WDC_ALI15X3 is not set# CONFIG_BLK_DEV_AMD74XX is not set# CONFIG_BLK_DEV_ATIIXP is not set# CONFIG_BLK_DEV_CMD64X is not set# CONFIG_BLK_DEV_TRIFLEX is not set# CONFIG_BLK_DEV_CY82C693 is not set# CONFIG_BLK_DEV_CS5520 is not set# CONFIG_BLK_DEV_CS5530 is not set# CONFIG_BLK_DEV_CS5535 is not set# CONFIG_BLK_DEV_HPT34X is not set# CONFIG_BLK_DEV_HPT366 is not set# CONFIG_BLK_DEV_SC1200 is not set# CONFIG_BLK_DEV_PIIX is not set# CONFIG_BLK_DEV_IT821X is not set# CONFIG_BLK_DEV_NS87415 is not set# CONFIG_BLK_DEV_PDC202XX_OLD is not set# CONFIG_BLK_DEV_PDC202XX_NEW is not set# CONFIG_BLK_DEV_SVWKS is not set# CONFIG_BLK_DEV_SIIMAGE is not set# CONFIG_BLK_DEV_SIS5513 is not set# CONFIG_BLK_DEV_SLC90E66 is not set# CONFIG_BLK_DEV_TRM290 is not set# CONFIG_BLK_DEV_VIA82CXXX is not set# CONFIG_IDE_ARM is not setCONFIG_BLK_DEV_IDEDMA=y# CONFIG_IDEDMA_IVB is not setCONFIG_IDEDMA_AUTO=y# CONFIG_BLK_DEV_HD is not set ## SCSI device support## CONFIG_RAID_ATTRS is not setCONFIG_SCSI=y# CONFIG_SCSI_PROC_FS is not set ## SCSI support type (disk, tape, CD-ROM)#CONFIG_BLK_DEV_SD=y# CONFIG_CHR_DEV_ST is not set# CONFIG_CHR_DEV_OSST is not setCONFIG_BLK_DEV_SR=y# CONFIG_BLK_DEV_SR_VENDOR is not setCONFIG_CHR_DEV_SG=y# CONFIG_CHR_DEV_SCH is not set ## Some SCSI devices (e.g. CD jukebox) support multiple LUNs#CONFIG_SCSI_MULTI_LUN=y# CONFIG_SCSI_CONSTANTS is not set# CONFIG_SCSI_LOGGING is not set ## SCSI Transport Attributes## CONFIG_SCSI_SPI_ATTRS is not set# CONFIG_SCSI_FC_ATTRS is not set# CONFIG_SCSI_ISCSI_ATTRS is not set# CONFIG_SCSI_SAS_ATTRS is not set ## SCSI low-level drivers## CONFIG_ISCSI_TCP is not set# CONFIG_BLK_DEV_3W_XXXX_RAID is not set# CONFIG_SCSI_3W_9XXX is not set# CONFIG_SCSI_ACARD is not set# CONFIG_SCSI_AACRAID is not set# CONFIG_SCSI_AIC7XXX is not set# CONFIG_SCSI_AIC7XXX_OLD is not set# CONFIG_SCSI_AIC79XX is not set# CONFIG_SCSI_DPT_I2O is not set# CONFIG_MEGARAID_NEWGEN is not set# CONFIG_MEGARAID_LEGACY is not set# CONFIG_MEGARAID_SAS is not set# CONFIG_SCSI_SATA is not set# CONFIG_SCSI_BUSLOGIC is not set# CONFIG_SCSI_DMX3191D is not set# CONFIG_SCSI_EATA is not set# CONFIG_SCSI_FUTURE_DOMAIN is not set# CONFIG_SCSI_GDTH is not set# CONFIG_SCSI_IPS is not set# CONFIG_SCSI_INITIO is not set# CONFIG_SCSI_INIA100 is not set# CONFIG_SCSI_SYM53C8XX_2 is not set# CONFIG_SCSI_IPR is not set# CONFIG_SCSI_QLOGIC_FC is not set# CONFIG_SCSI_QLOGIC_1280 is not set# CONFIG_SCSI_QLA_FC is not set# CONFIG_SCSI_LPFC is not set# CONFIG_SCSI_DC395x is not set# CONFIG_SCSI_DC390T is not set# CONFIG_SCSI_NSP32 is not set# CONFIG_SCSI_DEBUG is not set ## PCMCIA SCSI adapter support## CONFIG_PCMCIA_AHA152X is not set# CONFIG_PCMCIA_FDOMAIN is not set# CONFIG_PCMCIA_NINJA_SCSI is not set# CONFIG_PCMCIA_QLOGIC is not set# CONFIG_PCMCIA_SYM53C500 is not set ## Multi-device support (RAID and LVM)## CONFIG_MD is not set ## Fusion MPT device support## CONFIG_FUSION is not set# CONFIG_FUSION_SPI is not set# CONFIG_FUSION_FC is not set# CONFIG_FUSION_SAS is not set ## IEEE 1394 (FireWire) support#CONFIG_IEEE1394=m ## Subsystem Options## CONFIG_IEEE1394_VERBOSEDEBUG is not setCONFIG_IEEE1394_OUI_DB=y# CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not setCONFIG_IEEE1394_EXPORT_FULL_API=y ## Device Drivers## CONFIG_IEEE1394_PCILYNX is not setCONFIG_IEEE1394_OHCI1394=m ## Protocol Drivers## CONFIG_IEEE1394_VIDEO1394 is not setCONFIG_IEEE1394_SBP2=m# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set# CONFIG_IEEE1394_ETH1394 is not set# CONFIG_IEEE1394_DV1394 is not set# CONFIG_IEEE1394_RAWIO is not set ## I2O device support## CONFIG_I2O is not set ## Network device support#CONFIG_NETDEVICES=yCONFIG_DUMMY=m# CONFIG_BONDING is not set# CONFIG_EQUALIZER is not set# CONFIG_TUN is not set ## ARCnet devices## CONFIG_ARCNET is not set ## PHY device support## CONFIG_PHYLIB is not set ## Ethernet (10 or 100Mbit)#CONFIG_NET_ETHERNET=yCONFIG_MII=y# CONFIG_HAPPYMEAL is not set# CONFIG_SUNGEM is not set# CONFIG_CASSINI is not set# CONFIG_NET_VENDOR_3COM is not set ## Tulip family network device support## CONFIG_NET_TULIP is not set# CONFIG_HP100 is not setCONFIG_NET_PCI=y# CONFIG_PCNET32 is not set# CONFIG_AMD8111_ETH is not set# CONFIG_ADAPTEC_STARFIRE is not set# CONFIG_B44 is not set# CONFIG_FORCEDETH is not set# CONFIG_DGRS is not set# CONFIG_EEPRO100 is not set# CONFIG_E100 is not set# CONFIG_FEALNX is not set# CONFIG_NATSEMI is not set# CONFIG_NE2K_PCI is not set# CONFIG_8139CP is not setCONFIG_8139TOO=y# CONFIG_8139TOO_PIO is not set# CONFIG_8139TOO_TUNE_TWISTER is not set# CONFIG_8139TOO_8129 is not set# CONFIG_8139_OLD_RX_RESET is not set# CONFIG_SIS900 is not set# CONFIG_EPIC100 is not set# CONFIG_SUNDANCE is not set# CONFIG_TLAN is not set# CONFIG_VIA_RHINE is not set ## Ethernet (1000 Mbit)## CONFIG_ACENIC is not set# CONFIG_DL2K is not set# CONFIG_E1000 is not set# CONFIG_NS83820 is not set# CONFIG_HAMACHI is not set# CONFIG_YELLOWFIN is not set# CONFIG_R8169 is not set# CONFIG_SIS190 is not set# CONFIG_SKGE is not set# CONFIG_SKY2 is not set# CONFIG_SK98LIN is not set# CONFIG_VIA_VELOCITY is not set# CONFIG_TIGON3 is not set# CONFIG_BNX2 is not set ## Ethernet (10000 Mbit)## CONFIG_CHELSIO_T1 is not set# CONFIG_IXGB is not set# CONFIG_S2IO is not set ## Token Ring devices## CONFIG_TR is not set ## Wireless LAN (non-hamradio)## CONFIG_NET_RADIO is not set ## PCMCIA network device support## CONFIG_NET_PCMCIA is not set ## Wan interfaces## CONFIG_WAN is not set# CONFIG_FDDI is not set# CONFIG_HIPPI is not set# CONFIG_PPP is not set# CONFIG_SLIP is not set# CONFIG_NET_FC is not set# CONFIG_SHAPER is not setCONFIG_NETCONSOLE=mCONFIG_NETPOLL=y# CONFIG_NETPOLL_RX is not set# CONFIG_NETPOLL_TRAP is not setCONFIG_NET_POLL_CONTROLLER=y ## ISDN subsystem## CONFIG_ISDN is not set ## Telephony Support## CONFIG_PHONE is not set ## Input device support#CONFIG_INPUT=y ## Userland interfaces#CONFIG_INPUT_MOUSEDEV=y# CONFIG_INPUT_MOUSEDEV_PSAUX is not setCONFIG_INPUT_MOUSEDEV_SCREEN_X=1024CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768CONFIG_INPUT_JOYDEV=y# CONFIG_INPUT_TSDEV is not setCONFIG_INPUT_EVDEV=y# CONFIG_INPUT_EVBUG is not set ## Input Device Drivers#CONFIG_INPUT_KEYBOARD=yCONFIG_KEYBOARD_ATKBD=y# CONFIG_KEYBOARD_SUNKBD is not set# CONFIG_KEYBOARD_LKKBD is not set# CONFIG_KEYBOARD_XTKBD is not set# CONFIG_KEYBOARD_NEWTON is not setCONFIG_INPUT_MOUSE=yCONFIG_MOUSE_PS2=y# CONFIG_MOUSE_SERIAL is not set# CONFIG_MOUSE_VSXXXAA is not set# CONFIG_INPUT_JOYSTICK is not set# CONFIG_INPUT_TOUCHSCREEN is not set# CONFIG_INPUT_MISC is not set ## Hardware I/O ports#CONFIG_SERIO=yCONFIG_SERIO_I8042=y# CONFIG_SERIO_SERPORT is not set# CONFIG_SERIO_CT82C710 is not set# CONFIG_SERIO_PCIPS2 is not setCONFIG_SERIO_LIBPS2=y# CONFIG_SERIO_RAW is not set# CONFIG_GAMEPORT is not set ## Character devices#CONFIG_VT=yCONFIG_VT_CONSOLE=yCONFIG_HW_CONSOLE=y# CONFIG_SERIAL_NONSTANDARD is not set ## Serial drivers## CONFIG_SERIAL_8250 is not set ## Non-8250 serial port support## CONFIG_SERIAL_JSM is not setCONFIG_UNIX98_PTYS=y# CONFIG_LEGACY_PTYS is not set ## IPMI## CONFIG_IPMI_HANDLER is not set ## Watchdog Cards## CONFIG_WATCHDOG is not set# CONFIG_HW_RANDOM is not set# CONFIG_NVRAM is not setCONFIG_RTC=y# CONFIG_DTLK is not set# CONFIG_R3964 is not set# CONFIG_APPLICOM is not set# CONFIG_SONYPI is not set ## Ftape, the floppy tape device driver## CONFIG_FTAPE is not setCONFIG_AGP=y# CONFIG_AGP_ALI is not set# CONFIG_AGP_ATI is not set# CONFIG_AGP_AMD is not set# CONFIG_AGP_AMD64 is not set# CONFIG_AGP_INTEL is not set# CONFIG_AGP_NVIDIA is not set# CONFIG_AGP_SIS is not set# CONFIG_AGP_SWORKS is not set# CONFIG_AGP_VIA is not setCONFIG_AGP_EFFICEON=yCONFIG_DRM=y# CONFIG_DRM_TDFX is not set# CONFIG_DRM_R128 is not setCONFIG_DRM_RADEON=y# CONFIG_DRM_MGA is not set# CONFIG_DRM_SIS is not set# CONFIG_DRM_VIA is not set# CONFIG_DRM_SAVAGE is not set ## PCMCIA character devices## CONFIG_SYNCLINK_CS is not set# CONFIG_CARDMAN_4000 is not set# CONFIG_CARDMAN_4040 is not set# CONFIG_MWAVE is not set# CONFIG_CS5535_GPIO is not set# CONFIG_RAW_DRIVER is not set# CONFIG_HPET is not set# CONFIG_HANGCHECK_TIMER is not set ## TPM devices## CONFIG_TCG_TPM is not set# CONFIG_TELCLOCK is not set ## I2C support#CONFIG_I2C=y# CONFIG_I2C_CHARDEV is not set ## I2C Algorithms#CONFIG_I2C_ALGOBIT=y# CONFIG_I2C_ALGOPCF is not set# CONFIG_I2C_ALGOPCA is not set ## I2C Hardware Bus support## CONFIG_I2C_ALI1535 is not set# CONFIG_I2C_ALI1563 is not set# CONFIG_I2C_ALI15X3 is not set# CONFIG_I2C_AMD756 is not set# CONFIG_I2C_AMD8111 is not set# CONFIG_I2C_I801 is not set# CONFIG_I2C_I810 is not set# CONFIG_I2C_PIIX4 is not set# CONFIG_I2C_NFORCE2 is not set# CONFIG_I2C_PARPORT_LIGHT is not set# CONFIG_I2C_PROSAVAGE is not set# CONFIG_I2C_SAVAGE4 is not set# CONFIG_SCx200_ACB is not set# CONFIG_I2C_SIS5595 is not set# CONFIG_I2C_SIS630 is not set# CONFIG_I2C_SIS96X is not set# CONFIG_I2C_STUB is not set# CONFIG_I2C_VIA is not set# CONFIG_I2C_VIAPRO is not set# CONFIG_I2C_VOODOO3 is not set# CONFIG_I2C_PCA_ISA is not set ## Miscellaneous I2C Chip support## CONFIG_SENSORS_DS1337 is not set# CONFIG_SENSORS_DS1374 is not set# CONFIG_SENSORS_EEPROM is not set# CONFIG_SENSORS_PCF8574 is not set# CONFIG_SENSORS_PCA9539 is not set# CONFIG_SENSORS_PCF8591 is not set# CONFIG_SENSORS_RTC8564 is not set# CONFIG_SENSORS_MAX6875 is not set# CONFIG_RTC_X1205_I2C is not set# CONFIG_I2C_DEBUG_CORE is not set# CONFIG_I2C_DEBUG_ALGO is not set# CONFIG_I2C_DEBUG_BUS is not set# CONFIG_I2C_DEBUG_CHIP is not set ## SPI support## CONFIG_SPI is not set# CONFIG_SPI_MASTER is not set ## Dallas's 1-wire bus## CONFIG_W1 is not set ## Hardware Monitoring support## CONFIG_HWMON is not set# CONFIG_HWMON_VID is not set ## Misc devices## CONFIG_IBM_ASM is not set ## Multimedia Capabilities Port drivers# ## Multimedia devices## CONFIG_VIDEO_DEV is not set ## Digital Video Broadcasting Devices## CONFIG_DVB is not set ## Graphics support#CONFIG_FB=yCONFIG_FB_CFB_FILLRECT=yCONFIG_FB_CFB_COPYAREA=yCONFIG_FB_CFB_IMAGEBLIT=y# CONFIG_FB_MACMODES is not setCONFIG_FB_MODE_HELPERS=yCONFIG_FB_TILEBLITTING=y# CONFIG_FB_CIRRUS is not set# CONFIG_FB_PM2 is not set# CONFIG_FB_CYBER2000 is not set# CONFIG_FB_ARC is not set# CONFIG_FB_ASILIANT is not set# CONFIG_FB_IMSTT is not set# CONFIG_FB_VGA16 is not set# CONFIG_FB_VESA is not setCONFIG_VIDEO_SELECT=y# CONFIG_FB_HGA is not set# CONFIG_FB_S1D13XXX is not set# CONFIG_FB_NVIDIA is not set# CONFIG_FB_RIVA is not set# CONFIG_FB_I810 is not set# CONFIG_FB_INTEL is not set# CONFIG_FB_MATROX is not set# CONFIG_FB_RADEON_OLD is not setCONFIG_FB_RADEON=yCONFIG_FB_RADEON_I2C=y# CONFIG_FB_RADEON_DEBUG is not set# CONFIG_FB_ATY128 is not set# CONFIG_FB_ATY is not set# CONFIG_FB_SAVAGE is not set# CONFIG_FB_SIS is not set# CONFIG_FB_NEOMAGIC is not set# CONFIG_FB_KYRO is not set# CONFIG_FB_3DFX is not set# CONFIG_FB_VOODOO1 is not set# CONFIG_FB_CYBLA is not set# CONFIG_FB_TRIDENT is not set# CONFIG_FB_GEODE is not set# CONFIG_FB_VIRTUAL is not set ## Console display driver support#CONFIG_VGA_CONSOLE=yCONFIG_DUMMY_CONSOLE=yCONFIG_FRAMEBUFFER_CONSOLE=y# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set# CONFIG_FONTS is not setCONFIG_FONT_8x8=yCONFIG_FONT_8x16=y ## Logo configuration## CONFIG_LOGO is not set# CONFIG_BACKLIGHT_LCD_SUPPORT is not set ## Sound#CONFIG_SOUND=y ## Advanced Linux Sound Architecture## CONFIG_SND is not set ## Open Sound System## CONFIG_SOUND_PRIME is not set ## USB support#CONFIG_USB_ARCH_HAS_HCD=yCONFIG_USB_ARCH_HAS_OHCI=yCONFIG_USB=y# CONFIG_USB_DEBUG is not set ## Miscellaneous USB options#CONFIG_USB_DEVICEFS=y# CONFIG_USB_BANDWIDTH is not set# CONFIG_USB_DYNAMIC_MINORS is not setCONFIG_USB_SUSPEND=y# CONFIG_USB_OTG is not set ## USB Host Controller Drivers#CONFIG_USB_EHCI_HCD=m# CONFIG_USB_EHCI_SPLIT_ISO is not set# CONFIG_USB_EHCI_ROOT_HUB_TT is not setCONFIG_USB_ISP116X_HCD=mCONFIG_USB_OHCI_HCD=y# CONFIG_USB_OHCI_BIG_ENDIAN is not setCONFIG_USB_OHCI_LITTLE_ENDIAN=yCONFIG_USB_UHCI_HCD=mCONFIG_USB_SL811_HCD=mCONFIG_USB_SL811_CS=m ## USB Device Class drivers## CONFIG_OBSOLETE_OSS_USB_DRIVER is not setCONFIG_USB_ACM=mCONFIG_USB_PRINTER=m ## NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'# ## may also be needed; see USB_STORAGE Help for more information#CONFIG_USB_STORAGE=yCONFIG_USB_STORAGE_DEBUG=yCONFIG_USB_STORAGE_DATAFAB=yCONFIG_USB_STORAGE_FREECOM=yCONFIG_USB_STORAGE_ISD200=yCONFIG_USB_STORAGE_DPCM=yCONFIG_USB_STORAGE_USBAT=yCONFIG_USB_STORAGE_SDDR09=yCONFIG_USB_STORAGE_SDDR55=yCONFIG_USB_STORAGE_JUMPSHOT=yCONFIG_USB_STORAGE_ALAUDA=yCONFIG_USB_LIBUSUAL=y ## USB Input Devices#CONFIG_USB_HID=mCONFIG_USB_HIDINPUT=y# CONFIG_USB_HIDINPUT_POWERBOOK is not set# CONFIG_HID_FF is not setCONFIG_USB_HIDDEV=y ## USB HID Boot Protocol drivers## CONFIG_USB_KBD is not set# CONFIG_USB_MOUSE is not set# CONFIG_USB_AIPTEK is not set# CONFIG_USB_WACOM is not set# CONFIG_USB_ACECAD is not set# CONFIG_USB_KBTAB is not set# CONFIG_USB_POWERMATE is not set# CONFIG_USB_MTOUCH is not set# CONFIG_USB_ITMTOUCH is not set# CONFIG_USB_EGALAX is not set# CONFIG_USB_YEALINK is not setCONFIG_USB_XPAD=mCONFIG_USB_ATI_REMOTE=mCONFIG_USB_ATI_REMOTE2=m# CONFIG_USB_KEYSPAN_REMOTE is not set# CONFIG_USB_APPLETOUCH is not set ## USB Imaging devices## CONFIG_USB_MDC800 is not set# CONFIG_USB_MICROTEK is not set ## USB Multimedia devices## CONFIG_USB_DABUSB is not set ## Video4Linux support is needed for USB Multimedia device support# ## USB Network Adapters## CONFIG_USB_CATC is not set# CONFIG_USB_KAWETH is not set# CONFIG_USB_PEGASUS is not set# CONFIG_USB_RTL8150 is not set# CONFIG_USB_USBNET is not setCONFIG_USB_MON=y ## USB port drivers# ## USB Serial Converter support## CONFIG_USB_SERIAL is not set ## USB Miscellaneous drivers## CONFIG_USB_EMI62 is not set# CONFIG_USB_EMI26 is not set# CONFIG_USB_AUERSWALD is not set# CONFIG_USB_RIO500 is not set# CONFIG_USB_LEGOTOWER is not set# CONFIG_USB_LCD is not set# CONFIG_USB_LED is not set# CONFIG_USB_CYTHERM is not set# CONFIG_USB_PHIDGETKIT is not set# CONFIG_USB_PHIDGETSERVO is not set# CONFIG_USB_IDMOUSE is not set# CONFIG_USB_SISUSBVGA is not set# CONFIG_USB_LD is not set# CONFIG_USB_TEST is not set ## USB DSL modem support# ## USB Gadget Support## CONFIG_USB_GADGET is not set ## MMC/SD Card support## CONFIG_MMC is not set ## InfiniBand support## CONFIG_INFINIBAND is not set ## EDAC - error detection and reporting (RAS)## CONFIG_EDAC is not set ## File systems#CONFIG_EXT2_FS=m# CONFIG_EXT2_FS_XATTR is not set# CONFIG_EXT2_FS_XIP is not set# CONFIG_EXT3_FS is not set# CONFIG_REISERFS_FS is not set# CONFIG_JFS_FS is not set# CONFIG_FS_POSIX_ACL is not setCONFIG_XFS_FS=yCONFIG_XFS_EXPORT=y# CONFIG_XFS_QUOTA is not set# CONFIG_XFS_SECURITY is not set# CONFIG_XFS_POSIX_ACL is not set# CONFIG_XFS_RT is not set# CONFIG_OCFS2_FS is not set# CONFIG_MINIX_FS is not set# CONFIG_ROMFS_FS is not setCONFIG_INOTIFY=y# CONFIG_QUOTA is not setCONFIG_DNOTIFY=y# CONFIG_AUTOFS_FS is not set# CONFIG_AUTOFS4_FS is not set# CONFIG_FUSE_FS is not set ## CD-ROM/DVD Filesystems#CONFIG_ISO9660_FS=yCONFIG_JOLIET=y# CONFIG_ZISOFS is not setCONFIG_UDF_FS=yCONFIG_UDF_NLS=y ## DOS/FAT/NT Filesystems#CONFIG_FAT_FS=yCONFIG_MSDOS_FS=yCONFIG_VFAT_FS=mCONFIG_FAT_DEFAULT_CODEPAGE=437CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"# CONFIG_NTFS_FS is not set ## Pseudo filesystems#CONFIG_PROC_FS=yCONFIG_PROC_KCORE=yCONFIG_SYSFS=yCONFIG_TMPFS=y# CONFIG_HUGETLBFS is not set# CONFIG_HUGETLB_PAGE is not setCONFIG_RAMFS=y# CONFIG_RELAYFS_FS is not set# CONFIG_CONFIGFS_FS is not set ## Miscellaneous filesystems## CONFIG_ADFS_FS is not set# CONFIG_AFFS_FS is not set# CONFIG_HFS_FS is not set# CONFIG_HFSPLUS_FS is not set# CONFIG_BEFS_FS is not set# CONFIG_BFS_FS is not set# CONFIG_EFS_FS is not set# CONFIG_CRAMFS is not set# CONFIG_VXFS_FS is not set# CONFIG_HPFS_FS is not set# CONFIG_QNX4FS_FS is not set# CONFIG_SYSV_FS is not set# CONFIG_UFS_FS is not set ## Network File Systems#CONFIG_NFS_FS=yCONFIG_NFS_V3=y# CONFIG_NFS_V3_ACL is not set# CONFIG_NFS_V4 is not s