From: Tejun Heo <tj@kernel.org>
To: Bernd Schubert <bs@q-leap.de>
Cc: Robert Hancock <hancockr@shaw.ca>,
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: Wed, 07 Jan 2009 13:59:48 +0900 [thread overview]
Message-ID: <496436C4.4070305@kernel.org> (raw)
In-Reply-To: <200901032104.15242.bs@q-leap.de>
Hello,
Bernd Schubert wrote:
> But now more than a year has passed again without doing anything
> about it and actually this is what I strongly criticize. Most people
> don't know about issues like that and don't run file checksum tests
> as I now always do before taking a disk into production. So users
> are exposed to known data corruption problems without even being
> warned about it. Usually even backups don't help, since one creates
> a backup of the corrupted data.
sata_sil being one of the most popular controllers && data corruption
reports seem to be concentrated on certain chipsets, I don't think
it's a wide spread problem. In some cases, the corruption was very
reproducible too.
I think it's something related to setting up the PCI side of things.
There have been hints that incorrect CLS setting was the culprit and I
tried thte combinations but without any success and unfortunately the
problem wasn't reproducible with the hardware I have here. :-(
Anyways, there was an interesting report that updating the BIOS on the
controller fixed the problem.
http://bugzilla.kernel.org/show_bug.cgi?id=10480
Taking "lspci -nnvvvxxx" output of before and after such BIOS update
will shed some light on what's really going on. Can you please try
that?
> So IMHO, the driver should be deactived for sil3114 until a real
> solution is found. And it only should be possible to force activate
> it by a kernel flag, which then also would print a huuuge warning
> about possible data corruption (unfortunately most distributions
> disables inital kernel messages *grumble*).
The problem is serious but the scope is quite limited and we can't
tell where the problem lies, so I'm not too sure about taking such
drastic measure. Grumble...
Yeah, I really want to see this long standing problem fixed. To my
knowledge, this is one of two still open data corruption bugs - the
other one being via putting CDB bytes into burnt CD/DVDs.
So, if you can try the BIOS update thing, please give it a shot.
Thanks.
--
tejun
next prev parent reply other threads:[~2009-01-07 5:01 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 [this message]
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
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=496436C4.4070305@kernel.org \
--to=tj@kernel.org \
--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 \
/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).