On Sat, Jul 23, 2005 at 11:00:55PM -0500, Karl Denninger wrote:
> On Sun, Jul 24, 2005 at 05:43:34AM +0200, Erik Trulsson wrote:
> > On Sat, Jul 23, 2005 at 09:01:36PM -0500, Karl Denninger wrote:
> > > Done.
> > >
> > > Note that the Bustek and Adaptec cards which exhibit the problem BOTH
> > > identify the same (on two different machines) as SII 3112 boards, and
> > > BOTH fail.
> > >
> > > There are minor differences in the interrupts and memory mapping used
> > > (which is to be expected, as there are peripherals in the production
> > > machines that are NOT in the sandbox, specifically, an additional dual-port
> > > 100TX network card and a SCSI host adapter for the DLT backup device) so
> > > the PCI mapping would be expected to be slightly different.
> > >
> > > This pretty clearly looks like some kind of software problem with the SII
> > > 3112 support.... which just happens to be the chipset that is on basically
> > > ALL the "plain-jane" PCI SATA cards out there, no matter who makes them.
> > Quoting from the commitlogs for sys/dev/ata/ata-chipset.c:
> > ----------------------------
> > revision 1.50
> > date: 2003/12/08 09:22:20; author: sos; state: Exp; lines: +3 -1
> > More errata fixing for the SiI3112A disaster chip:
> > Serialize access to the SATA channels, the chip messes up if
> > both channels are used at the same time.
> > The SiI3112 hereby takes the price as the most crappy SATA chip in
> > existance by a significant amount.
> > My advise to our userbase is to avoid this chip like the plague...
> > ----------------------------
> > There are plenty of SATA-controllers that do not use this chip - all the
> > Promise controllers for example - some of which are reasonably cheap.
> > The only cards that seem to use the SiI 3112 are the very cheapest cards -
> > and it is generally a good idea to avoid the really low-end stuff, since it
> > is usually substandard and not worth its price.
> > I will also note that though the SiI 3112 seemed quite common on early
> > AMD64-motherboards, it is almost unknown on later motherboards which seem
> > to often use the SiI 3114 instead - I assume there was a good reason for
> > this switch.
> Near as I can find out, the 3114's only difference is that it has 4 ports
> instead of 2 (which seems obvious, but if you look around, that's what it
> looks like)
I assume that the people at Silicon Image also fixed a bunch of bugs.
> I bet this problem bites anyone with a 3114 chipset too - can someone test
> and confirm?
> How common is this chipset? Looks damn common to me, just from looking
> around at what one can buy in the retail marketplace....
> Next.... So..... was there a fix for this problem committed back in 1.50,
> and then it was NOT rolled forward into ATA-NG (note the date on that
> commit!)? Why not?
That commit is part of what is known as ata-NG. RELENG_5 was not branched
until several months later, so that fix is included in 5.3-RELEASE and
It seems that you have run into either a new bug in the SiI 3112, or an old
bug that has not been worked around correctly.
My point in quoting that commit message was not it might fix your bug rather
to point out the comment that:
"The SiI3112 hereby takes the price as the most crappy SATA chip in
existance by a significant amount.
My advise to our userbase is to avoid this chip like the plague..."
> Should not there be an EXPLICIT note in the release notes for hardware that
> this chipset WILL NOT WORK PROPERLY?
It does seem to work for many users, or there would be much complaints about
it on the mailing lists.
> Or perhaps better, the solution is to put the fix from 1.50 into ATA-NG,
> eh (and recommend for performance reasons to use something else in the
> release notes....)
> Finally, this begs an obvious further question - since my original PR was
> opened in February of this year, if there is a KNOWN incompatability with
> this chipset, why is the PR still open, rather than a response being
> posted back ("hardware unsupported") AND the driver flags/init for that
> chipset being either removed or a STRONG warning printed when it is
> identified on boot?
> That DOES appear to be the right choice, assuming the fixes that sos
> committed back in '03 can't be rolled forward into ATA-NG..... If they
> CAN, then how about it? I mean, c'mon - this change was all of three
> lines of code added, and one removed!
As I said: You are already running with those fixes - and they apparently
don't fix your problems.
Most likely the bug you have run into is difficult or impossible to
reproduce on other hardware than the particular combination you are using.
<Insert your favourite quote here.>