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 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.