Date: Thu, 13 Mar 2008 08:12:31 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Gregory Wright <gwright@antiope.com>, Barney Cordoba <barney_cordoba@yahoo.com> Subject: Re: ServerWorks/Broadcom HT1000 chipset errata saga Message-ID: <200803130812.32381.jhb@freebsd.org> In-Reply-To: <517227.54685.qm@web63904.mail.re1.yahoo.com> References: <517227.54685.qm@web63904.mail.re1.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 12 March 2008 03:51:07 pm Barney Cordoba wrote: > --- Gregory Wright <gwright@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 > loads? 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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803130812.32381.jhb>