| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: 2.6.38.8 kernel bug in XFS or megaraid driver with heavy I/O load |
| From: | Anders Ossowicki <aowi@xxxxxxxxxxxxx> |
| Date: | Tue, 11 Oct 2011 16:13:38 +0200 |
| Cc: | <linux-kernel@xxxxxxxxxxxxxxx>, <aradford@xxxxxxxxx>, <xfs@xxxxxxxxxxx> |
| In-reply-to: | <20111011133448.GA10692@xxxxxxxxxxxxx> |
| Mail-followup-to: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, aradford@xxxxxxxxx, xfs@xxxxxxxxxxx |
| References: | <20111011091757.GA32589@xxxxxxxxxxxxxxx> <20111011133448.GA10692@xxxxxxxxxxxxx> |
| Reply-to: | <aowi@xxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
On Tue, Oct 11, 2011 at 03:34:48PM +0200, Christoph Hellwig wrote: > This is core VM code, and operates purely on on-stack variables except > for the page cache radix tree nodes / pages. So this either could be a > core VM bug that no one has noticed yet, or memory corruption. Can you > run memtest86 on the box? Unfortunately not, as it is a production server. Pulling it out to memtest 256G properly would take too long. But it seems unlikely to me that it should be memory corruption. The machine has been running with the same (ecc) memory for more than a year and neither the service processor nor the kernel (according to dmesg) has caught anything before this. It would be a rare (though I admit not impossible) coincidence if we got catastrophic, undetected memory corruption a week after attaching a new raid controller with a new disk array. -- Anders Ossowicki |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 2.6.38.8 kernel bug in XFS or megaraid driver with heavy I/O load, Christoph Hellwig |
|---|---|
| Next by Date: | [PATCH 3/3 v2] xfstests: allow 091 for non-xfs filesystems, Christoph Hellwig |
| Previous by Thread: | Re: 2.6.38.8 kernel bug in XFS or megaraid driver with heavy I/O load, Christoph Hellwig |
| Next by Thread: | Re: 2.6.38.8 kernel bug in XFS or megaraid driver with heavy I/O load, Jesper Krogh |
| Indexes: | [Date] [Thread] [Top] [All Lists] |