ServerWorks/Broadcom HT1000 chipset errata saga
jhb at freebsd.org
Thu Mar 13 05:17:59 PDT 2008
On Wednesday 12 March 2008 03:51:07 pm Barney Cordoba wrote:
> --- Gregory Wright <gwright at antiope.com> wrote:
> > Hi,
> > On Jan 9, 2008, at 6:53 PM, Xin LI wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Travis Mikalson wrote:
> > >> Really hoping this will make it into RELENG_7_0.
> > It has successfully
> > >> worked around the crippling HT1000 SATA problems.
> > >
> > > Yes, the changeset was committed into RELENG_7_0
> > and RELENG_7.
> > > Because
> > > it's very late of release cycle, I am afraid that
> > we will not be
> > > able to
> > > incorporate this patchset in 6.3-RELEASE, but I
> > think it would be a
> > > good
> > > errata candidate after testing.
> > One note that might help out people with the Tyan
> > h2000M (S3992)
> > mobos --- for the HT1000 patch in RELENG_7 to work,
> > you need to make
> > sure the BIOS settings put the HT1000 SATA
> > controller in "S-ATA"
> > emulation
> > mode. If you use "P-ATA" emulation mode, you are
> > back in data
> > corruption hell.
> > There is also a BIOS option for "RAID" mode which I
> > have not tried.
> > Setting "S-ATA"
> > mode the box seems to run as reliable as it did
> > under 6.2.
> > BR,
> > Greg
> I'm a bit concerned that these "workarounds" for this
> and a couple of other chipsets indicate a problem with
> some underlying mechanism in the SATA driver code.
> There are no such workarounds required in the linux
> driver from what I've seen. Could it be a problem with
> buffer handling that might creep up under heavier
In the case of the Broadcom corruption the problem is asking the hardware to
do a full 64kb DMA. My understanding is that due to the way the Linux I/O
stack works, it never actually pushes the hardware that hard (i.e. never
makes that big of a request) so it doesn't encounter the problem.
More information about the freebsd-current