From: Dave Jones <davej@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Robert Hancock <hancockr@shaw.ca>, Bernd Schubert <bs@q-leap.de>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Justin Piszcz <jpiszcz@lucidpixels.com>,
debian-user@lists.debian.org, linux-raid@vger.kernel.org,
linux-ide@vger.kernel.org
Subject: Re: Corrupt data - RAID sata_sil 3114 chip
Date: Mon, 19 Jan 2009 13:43:04 -0500 [thread overview]
Message-ID: <20090119184304.GB30365@redhat.com> (raw)
In-Reply-To: <496A9D42.4000302@kernel.org>
On Mon, Jan 12, 2009 at 10:30:42AM +0900, Tejun Heo wrote:
> Robert Hancock wrote:
> >> There are apparently some reports of issues on NVidia chipsets as
> >> well, though I don't have any details at hand.
> >
> > Well, Carlos' email bounces, so much for that one. Anyone have any other
> > contacts at Silicon Image?
>
> I'll ping my SIMG contacts but I've pinged about this problem in the
> past but it didn't get anywhere.
I wish I'd read this thread last week.. I've been beating my head
against this problem all weekend.
I picked up a cheap 3114 card, and found that when I created a filesystem
with it on a 250GB disk, it got massive corruption very quickly.
My experience echos most the other peoples in this thread, but here's
a few data points I've been able to figure out..
I ran badblocks -v -w -s on the disk, and after running
for nearly 24 hours, it reported a huge number of blocks
failing at the upper part of the disk.
I created a partition in this bad area to speed up testing..
Device Boot Start End Blocks Id System
/dev/sde1 1 30000 240974968+ 83 Linux
/dev/sde2 30001 30200 1606500 83 Linux
/dev/sde3 30201 30401 1614532+ 83 Linux
Rerunning badblocks on /dev/sde2 consistently fails when
it gets to the reading back 0x00 stage.
(Somehow it passes reading back 0xff, 0xaa and 0x55)
I was beginning to suspect the disk may be bad, but when I
moved it to a box with Intel sata, the badblocks run on that
same partition succeeds with no problems at all.
Given the corruption happens at high block numbers, I'm wondering
if maybe there's some kind of wraparound bug happening here.
(Though why only the 0x00 pattern fails would still be a mystery).
After reading about the firmware update fixing it, I thought I'd
give that a shot. This was pretty much complete fail.
The DOS utility for flashing claims I'm running BIOS 5.0.39,
which looking at http://www.siliconimage.com/support/searchresults.aspx?pid=28&cat=15
is quite ancient. So I tried the newer ones.
Same experience with both 5.4.0.3, and 5.0.73
"BIOS version in the input file is not a newer version"
Forcing it to write anyway gets..
"Data is different at address 65f6h"
Dave
--
http://www.codemonkey.org.uk
next prev parent reply other threads:[~2009-01-19 18:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-03 20:04 Corrupt data - RAID sata_sil 3114 chip Bernd Schubert
2009-01-03 20:53 ` Robert Hancock
2009-01-03 21:11 ` Bernd Schubert
2009-01-03 23:23 ` Robert Hancock
2009-01-07 4:59 ` Tejun Heo
2009-01-07 5:38 ` Robert Hancock
2009-01-07 15:31 ` Bernd Schubert
2009-01-11 0:32 ` Robert Hancock
2009-01-11 0:43 ` Robert Hancock
2009-01-12 1:30 ` Tejun Heo
2009-01-19 18:43 ` Dave Jones [this message]
2009-01-20 2:50 ` Robert Hancock
2009-01-20 20:07 ` Dave Jones
-- strict thread matches above, loose matches on Subject: below --
2010-01-29 16:13 Ulli.Brennenstuhl
2010-01-29 19:37 ` Robert Hancock
2010-02-06 3:54 ` Tejun Heo
2010-02-06 15:16 ` Tim Small
2010-02-07 16:09 ` Robert Hancock
2010-02-08 2:31 ` Tejun Heo
2010-02-08 14:25 ` Tim Small
[not found] <bQVFb-3SB-37@gated-at.bofh.it>
[not found] ` <bQVFb-3SB-39@gated-at.bofh.it>
[not found] ` <bQVFb-3SB-41@gated-at.bofh.it>
[not found] ` <bQVFc-3SB-43@gated-at.bofh.it>
[not found] ` <bQVFc-3SB-45@gated-at.bofh.it>
[not found] ` <bQVFc-3SB-47@gated-at.bofh.it>
[not found] ` <bQVFb-3SB-35@gated-at.bofh.it>
[not found] ` <4963306F.4060504@sm7jqb.se>
2009-01-06 10:48 ` Justin Piszcz
[not found] <495E01E3.9060903@sm7jqb.se>
[not found] ` <alpine.DEB.1.10.0901020741200.11852@p34.internal.lan>
2009-01-02 21:30 ` Bernd Schubert
2009-01-02 21:47 ` Twigathy
2009-01-03 2:31 ` Redeeman
2009-01-03 13:13 ` Bernd Schubert
2009-01-03 13:39 ` Alan Cox
2009-01-03 16:20 ` Bernd Schubert
2009-01-03 18:31 ` Robert Hancock
2009-01-03 22:19 ` James Youngman
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=20090119184304.GB30365@redhat.com \
--to=davej@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bs@q-leap.de \
--cc=debian-user@lists.debian.org \
--cc=hancockr@shaw.ca \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=tj@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;
as well as URLs for NNTP newsgroup(s).