From: Guus Sliepen <Guus.Sliepen@astro.su.se> To: Peter Klotz <peter.klotz99@gmail.com> Cc: Nick Piggin <npiggin@kernel.dk>, Christoph Hellwig <hch@infradead.org>, Roman Kononov <kernel@kononov.ftml.net>, linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: BUG: soft lockup - is this XFS problem? Date: Thu, 14 Jul 2011 21:29:45 +0200 [thread overview] Message-ID: <20110714192945.GX18364@sliepen.org> (raw) In-Reply-To: <4E1F2F5D.8060505@gmail.com> [-- Attachment #1: Type: text/plain, Size: 1444 bytes --] On Thu, Jul 14, 2011 at 08:03:09PM +0200, Peter Klotz wrote: > On 07/14/2011 01:23 PM, Guus Sliepen wrote: > > >I'm having a problem with a system having an XFS filesystem on RAID locking up > >fairly consistently when writing large amounts of data to it, with several > >kernels, including 2.6.38.2 and 2.6.39.3, on both AMD and Intel multi-core > >processors. The kernel always logs this several times: > > > >BUG: soft lockup - CPU#2 stuck for 67s! [kswapd0:33] [...] > This Bugzilla entry documents the XFS bug from 2009 in detail > including links: > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=805 Aha, I did not look at that before. > The problem was finally solved by a patch proposed by Linus. This is > the reason the original patch developed by Nick never made it into > the kernel. > > My tests back then showed that both patches fixed the problem. > > It seems you have found a test case where just Nick's patch helps. Yes. I agree with Linus that the root cause should be fixed, not the symptoms. I don't have time to dive in the kernel code myself, but I do have several nearly identical machines where I can test things on. I will be happy to test out patches and/or different kernel versions or kernel configurations, and I can provide dmesg output and perhaps other information if necessary. -- Met vriendelijke groet / with kind regards, Guus Sliepen <Guus.Sliepen@astro.su.se> [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Guus Sliepen <Guus.Sliepen@astro.su.se> To: Peter Klotz <peter.klotz99@gmail.com> Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com, Nick Piggin <npiggin@kernel.dk>, Roman Kononov <kernel@kononov.ftml.net>, linux-kernel@vger.kernel.org Subject: Re: BUG: soft lockup - is this XFS problem? Date: Thu, 14 Jul 2011 21:29:45 +0200 [thread overview] Message-ID: <20110714192945.GX18364@sliepen.org> (raw) In-Reply-To: <4E1F2F5D.8060505@gmail.com> [-- Attachment #1.1: Type: text/plain, Size: 1444 bytes --] On Thu, Jul 14, 2011 at 08:03:09PM +0200, Peter Klotz wrote: > On 07/14/2011 01:23 PM, Guus Sliepen wrote: > > >I'm having a problem with a system having an XFS filesystem on RAID locking up > >fairly consistently when writing large amounts of data to it, with several > >kernels, including 2.6.38.2 and 2.6.39.3, on both AMD and Intel multi-core > >processors. The kernel always logs this several times: > > > >BUG: soft lockup - CPU#2 stuck for 67s! [kswapd0:33] [...] > This Bugzilla entry documents the XFS bug from 2009 in detail > including links: > > http://oss.sgi.com/bugzilla/show_bug.cgi?id=805 Aha, I did not look at that before. > The problem was finally solved by a patch proposed by Linus. This is > the reason the original patch developed by Nick never made it into > the kernel. > > My tests back then showed that both patches fixed the problem. > > It seems you have found a test case where just Nick's patch helps. Yes. I agree with Linus that the root cause should be fixed, not the symptoms. I don't have time to dive in the kernel code myself, but I do have several nearly identical machines where I can test things on. I will be happy to test out patches and/or different kernel versions or kernel configurations, and I can provide dmesg output and perhaps other information if necessary. -- Met vriendelijke groet / with kind regards, Guus Sliepen <Guus.Sliepen@astro.su.se> [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 121 bytes --] _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-07-14 19:29 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-12-19 6:59 BUG: soft lockup - is this XFS problem? Roman Kononov 2008-12-23 17:12 ` Christoph Hellwig 2008-12-23 17:12 ` Christoph Hellwig 2008-12-30 4:23 ` Nick Piggin 2008-12-30 4:23 ` Nick Piggin 2009-01-03 21:44 ` Christoph Hellwig 2009-01-03 21:44 ` Christoph Hellwig 2009-01-05 1:48 ` Nick Piggin 2009-01-05 1:48 ` Nick Piggin 2009-01-05 4:19 ` Nick Piggin 2009-01-05 4:19 ` Nick Piggin 2009-01-05 6:48 ` Nick Piggin 2009-01-05 6:48 ` Nick Piggin 2009-01-05 14:25 ` Roman Kononov 2009-01-05 14:25 ` Roman Kononov 2009-01-05 16:21 ` Peter Klotz 2009-01-05 16:21 ` Peter Klotz 2009-01-05 16:41 ` [patch] mm: fix lockless pagecache reordering bug (was Re: BUG: soft lockup - is this XFS problem?) Nick Piggin 2009-01-05 16:41 ` Nick Piggin 2009-01-05 16:41 ` Nick Piggin 2009-01-05 17:30 ` Linus Torvalds 2009-01-05 17:30 ` Linus Torvalds 2009-01-05 17:30 ` Linus Torvalds 2009-01-05 18:00 ` Nick Piggin 2009-01-05 18:00 ` Nick Piggin 2009-01-05 18:00 ` Nick Piggin 2009-01-05 18:44 ` Linus Torvalds 2009-01-05 18:44 ` Linus Torvalds 2009-01-05 18:44 ` Linus Torvalds 2009-01-05 19:39 ` Linus Torvalds 2009-01-05 19:39 ` Linus Torvalds 2009-01-05 19:39 ` Linus Torvalds 2009-01-06 17:17 ` Paul E. McKenney 2009-01-06 17:17 ` Paul E. McKenney 2009-01-06 17:17 ` Paul E. McKenney 2009-01-05 20:12 ` Paul E. McKenney 2009-01-05 20:12 ` Paul E. McKenney 2009-01-05 20:12 ` Paul E. McKenney 2009-01-05 20:39 ` Linus Torvalds 2009-01-05 20:39 ` Linus Torvalds 2009-01-05 20:39 ` Linus Torvalds 2009-01-05 21:57 ` Paul E. McKenney 2009-01-05 21:57 ` Paul E. McKenney 2009-01-05 21:57 ` Paul E. McKenney 2009-01-06 2:05 ` Nick Piggin 2009-01-06 2:05 ` Nick Piggin 2009-01-06 2:05 ` Nick Piggin 2009-01-06 2:23 ` Paul E. McKenney 2009-01-06 2:23 ` Paul E. McKenney 2009-01-06 2:23 ` Paul E. McKenney 2009-01-06 2:29 ` Linus Torvalds 2009-01-06 2:29 ` Linus Torvalds 2009-01-06 2:29 ` Linus Torvalds 2009-01-06 8:38 ` Peter Klotz 2009-01-06 8:38 ` Peter Klotz 2009-01-06 8:38 ` Peter Klotz 2009-01-06 8:43 ` Nick Piggin 2009-01-06 8:43 ` Nick Piggin 2009-01-06 8:43 ` Nick Piggin 2009-01-06 16:16 ` Roman Kononov 2009-01-06 16:16 ` Roman Kononov 2009-01-06 16:16 ` Roman Kononov 2009-01-05 21:04 ` [patch] mm: fix lockless pagecache reordering bug (was Peter Zijlstra 2009-01-05 21:04 ` Peter Zijlstra 2009-01-05 21:04 ` Peter Zijlstra 2009-01-05 21:58 ` Paul E. McKenney 2009-01-05 21:58 ` Paul E. McKenney 2009-01-05 21:58 ` Paul E. McKenney 2011-07-14 11:23 ` BUG: soft lockup - is this XFS problem? Guus Sliepen 2011-07-14 11:23 ` Guus Sliepen 2011-07-14 18:03 ` Peter Klotz 2011-07-14 18:03 ` Peter Klotz 2011-07-14 19:29 ` Guus Sliepen [this message] 2011-07-14 19:29 ` Guus Sliepen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110714192945.GX18364@sliepen.org \ --to=guus.sliepen@astro.su.se \ --cc=hch@infradead.org \ --cc=kernel@kononov.ftml.net \ --cc=linux-kernel@vger.kernel.org \ --cc=npiggin@kernel.dk \ --cc=peter.klotz99@gmail.com \ --cc=xfs@oss.sgi.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.