From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Chris Wedgwood <cw@f00f.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!
Date: Sat, 02 Dec 2006 13:10:16 +0100 [thread overview]
Message-ID: <45716D28.5000708@scientia.net> (raw)
In-Reply-To: <20061202051720.GA12580@tuatara.stupidest.org>
Chris Wedgwood wrote:
> Heh, I see this also with an Tyan S2866 (nforce4 chipset). I've been
> aware something is a miss for a while because if I transfer about 40GB
> of data from one machine to another there are checksum mismatches and
> some files have to be transfered again.
>
It seems that this may be occur on _all_ nvidia chipsets (of course I'm
talking about mainboard chips ;) )
Which harddisk types to you use (vendor an interface type)
> I've kept quite about it so far because it's not been clear what the
> cause is and because i can mostly ignore it now that I checksum all my
> data and check after xfer that it's sane (so I have 2+ copies of all
> this stuff everywhere).
>
I assume that a large number of users actually experience this error,..
but as it's so rare only few correctly identify it.
Most of them might think that its filesystem related or so.
>> The corrupted data is not one single completely wrong block of data
>> or so,.. but if you look at the area of the file where differences
>> are found,.. than some bytes are ok,.. some are wrong,.. and so on
>> (seems to be randomly).
>>
>
> For me it seems that a single block in the file would be bad and the
> rest OK --- we I'm talking about 2 random blocks in 30BG or so.
>
Did you check this with an hex editor? I did it an while the errors were
restricted to one "region" of a file.... it was not so that that region
was completely corrupted but only some single bytes.
Actually it was that mostly one bit was wrong,..
Chris.
next prev parent reply other threads:[~2006-12-02 12:10 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-02 0:56 data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?! Christoph Anton Mitterer
2006-12-02 1:15 ` Erik Andersen
2006-12-02 1:28 ` Christoph Anton Mitterer
2006-12-02 5:17 ` Chris Wedgwood
2006-12-02 12:10 ` Christoph Anton Mitterer [this message]
[not found] ` <20061202111644.GF9995@vianova.fi>
2006-12-08 2:16 ` Christoph Anton Mitterer
2006-12-02 11:00 ` Karsten Weiss
2006-12-02 11:37 ` Alan
2006-12-02 11:39 ` Christoph Anton Mitterer
2006-12-13 18:52 ` Christoph Anton Mitterer
2006-12-13 19:56 ` Karsten Weiss
2006-12-13 20:11 ` Christoph Anton Mitterer
2006-12-14 9:34 ` Chris Wedgwood
2007-01-15 22:26 ` Christoph Anton Mitterer
2006-12-03 1:17 ` data corruption with nvidia chipsets and IDE/SATA drives Kurtis D. Rader
2006-12-03 3:35 ` Kurtis D. Rader
2006-12-03 14:17 ` Steffen Moser
2006-12-04 1:58 ` data corruption with nvidia nForce 4 " Kurtis D. Rader
2006-12-04 12:47 ` Alan
2006-12-05 6:00 ` data corruption with nvidia " Kurtis D. Rader
2006-12-06 11:11 ` Christian
2006-12-06 21:25 ` Chris Wedgwood
2006-12-14 23:39 ` data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?! Dax Kelson
[not found] <Pine.LNX.4.64.0612021202000.2981@addx.localnet>
2006-12-11 9:24 ` Karsten Weiss
2006-12-13 19:18 ` Christoph Anton Mitterer
2006-12-13 19:53 ` Chris Wedgwood
2006-12-13 20:34 ` Karsten Weiss
2006-12-14 9:22 ` Muli Ben-Yehuda
2006-12-23 2:04 ` Christoph Anton Mitterer
2006-12-23 2:56 ` John A Chaves
2006-12-23 3:26 ` Christoph Anton Mitterer
2006-12-13 19:20 ` Christoph Anton Mitterer
2006-12-13 19:54 ` Chris Wedgwood
2006-12-13 19:57 ` Christoph Anton Mitterer
2006-12-13 22:39 ` Lennart Sorensen
2006-12-13 23:00 ` Christoph Anton Mitterer
2006-12-13 19:53 ` Erik Andersen
2006-12-13 19:59 ` Karsten Weiss
2006-12-13 20:02 ` Christoph Anton Mitterer
2006-12-13 20:29 ` Erik Andersen
2006-12-13 20:32 ` Christoph Anton Mitterer
2006-12-13 23:33 ` Christoph Anton Mitterer
2006-12-14 9:24 ` Muli Ben-Yehuda
2006-12-14 19:23 ` Christoph Anton Mitterer
2006-12-14 9:23 ` Muli Ben-Yehuda
2006-12-14 9:52 ` Erik Andersen
2006-12-14 9:56 ` Muli Ben-Yehuda
2007-01-03 15:02 ` Christoph Anton Mitterer
2007-01-04 13:04 ` Christoph Anton Mitterer
-- strict thread matches above, loose matches on Subject: below --
2006-12-15 15:57 Paul Slootman
[not found] <fa.E9jVXDLMKzMZNCbslzUxjMhsInE@ifi.uio.no>
2007-01-03 23:41 ` Robert Hancock
2007-01-15 22:56 ` Christoph Anton Mitterer
2007-01-15 23:05 ` Christoph Anton Mitterer
2007-01-16 0:23 ` Robert Hancock
2007-01-16 13:54 ` Christoph Anton Mitterer
2007-01-16 14:26 ` Robert Hancock
2007-03-22 12:32 ` Christoph Anton Mitterer
2007-03-22 14:48 Dan Halbert
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=45716D28.5000708@scientia.net \
--to=calestyo@scientia.net \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox