[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <458CA1DE.70804@scientia.net>
Date: Sat, 23 Dec 2006 04:26:22 +0100
From: Christoph Anton Mitterer <calestyo@...entia.net>
To: John A Chaves <chaves@...puter.org>
CC: Karsten Weiss <K.Weiss@...ence-computing.de>,
Chris Wedgwood <cw@...f.org>, linux-kernel@...r.kernel.org,
Erik Andersen <andersen@...epoet.org>, Andi Kleen <ak@...e.de>,
muli@...ibm.com
Subject: Re: data corruption with nvidia chipsets and IDE/SATA drives // memory
hole mapping related bug?!
John A Chaves wrote:
> I didn't need to run a specific test for this. The normal workload of the
> machine approximates a continuous selftest for almost the last year.
>
> Large files (4-12GB is typical) are being continuously packed and unpacked
> with gzip and bzip2. Statistical analysis of the datasets is followed by
> verification of the data, sometimes using diff, or md5sum, or python
> scripts using numarray to mmap 2GB chunks at a time. The machine
> often goes for days with a load level of 20+ and 32GB RAM + another 32GB
> swap in use. It would be very unlikely for data corruption to go unnoticed.
>
> When I first got the machine I did have some problems with disks being
> dropped from the RAID and occasional log messages implicating the IOMMU.
> But that was with kernel 2.6.16.?, Kernels since 2.6.17 haven't had any
> problem.
>
Ah thanks for that info,.. as far as I can tell,.. this "testing
environment" should have found any corruptions I there had been any.
So I think we could take this as our first working system where the
issue don't occur although we would expect it...
Chris.
View attachment "calestyo.vcf" of type "text/x-vcard" (156 bytes)
Powered by blists - more mailing lists