linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Hancock <hancockrwd@gmail.com>
To: "Ulli.Brennenstuhl" <Ulli.Brennenstuhl@fs.ei.tum.de>
Cc: linux-ide@vger.kernel.org
Subject: Re: Corrupt data - RAID sata_sil 3114 chip
Date: Fri, 29 Jan 2010 13:37:06 -0600	[thread overview]
Message-ID: <4B6338E2.1040507@gmail.com> (raw)
In-Reply-To: <4B630914.9010503@fs.ei.tum.de>

On 01/29/2010 10:13 AM, Ulli.Brennenstuhl wrote:
> The last message of this discussion is more than one year old, but still
> there was no solution to this problem.
>
> I recently encountered the same problem that a raid created with mdadm
> consisting of three SAMSUNG HD154UI sata harddisks had random errors and
> mdadm --examine would randomly report that checksums are wrong/correct.
>
> The sata controller with the SIL 3114 chipset runs on an old Epox 8K3A
> board with a VIA KT133 chipset. I noticed that placing the controller in
> another pci slot would change the results of mdadm --examine.
> While in one slot it was the checksums were randomly changing between
> correct and wrong in another slot it was always displayed as wrong.
>
> After deactivating every single bios option that somehow optimizes the
> pci bus the problem seems to be gone. After some more testing I could
> narrow the problem down to the option "PCI Master 0 WS Write", which
> controls if requests to the pci bus are executed immediately (with zero
> wait states) or if every write request will be delayed by one wait state.
>
> Obviously this reduces the performance. I didn't perform tests but the
> resync speed of the raid dropped from ~ 28mb/s to ~ 17mb/s.
>
> I hope this also solves the problems for other people and it would be
> interesting if any change to the driver would allow to reenable the "PCI
> Master 0 WS Write" option.

I don't imagine there's anything the driver's likely to be able to do to 
avoid it. That sounds like a definite chipset bug. The PCI interface on 
older VIA chipsets was pretty notorious for them.

  reply	other threads:[~2010-01-29 19:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-29 16:13 Corrupt data - RAID sata_sil 3114 chip Ulli.Brennenstuhl
2010-01-29 19:37 ` Robert Hancock [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2009-01-03 20:04 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
2009-01-20  2:50               ` Robert Hancock
2009-01-20 20:07                 ` Dave Jones
     [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=4B6338E2.1040507@gmail.com \
    --to=hancockrwd@gmail.com \
    --cc=Ulli.Brennenstuhl@fs.ei.tum.de \
    --cc=linux-ide@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).