FYI:
Sil3132 works well in general except one hardware bug for PCI read burst size.
Default is 128.
This limits the maximum SATA throughput.
As talked to Silicon Image level-2 FAE, they have not tested this feature yet
and they do not even know
how to do it. In my experience, setting this register will cause PCI-X hang or
crash.
It looks like 3132 holding the bus or generating some strange signal. We planned
to run PCI-X analyzer
on it, but this was dropped due to low priority.
-Jin
________________________________
From: Dieter BSD <***@engineer.com>
To: freebsd-***@freebsd.org
Sent: Mon, April 9, 2012 1:32:17 PM
Subject: Re: PCI-X SATA (non HW-RAID) controller recommendation
Post by Moritz WilhelmyPost by Moritz WilhelmyCan you (or someone else for that matter) recommend any decent PCI-X
controller for use in "serious environments"
I heard Silicon Image cards are supposed to be good?
Just wondering, do you (or anyone else) know whether there are PCI-X
SATA controllers with only 4 Ports with less issues than the ones
already mentioned? :-)
Maybe 4 are enough after all...
What do you mean by "serious environments"?
speed? reliability? harsh environment? support? other?
I have the Silicon Image 3132 which is PCIe-x1 with 2 sata ports.
Not as fast as it should be but fast enough for my needs.
Works well with FreeBSD siis(4), which provides NCQ.
Works well with the 3726 port multiplier. Talks to recent
600MB/s drives at 300MB/s, unlike JMB363 which doesn't like
600MB/s drives, even with the sata rev hint set.
Look into the 3124 which has 4 ports and is IIRC PCI-X.
Said to be faster than the 3132.
You probably want to avoid the first generation Silicon Image
sata chips. They are very slow and word is that FreeBSD doesn't
support them very well. (NetBSD does have good support, but they
are still very slow.)
If you don't need ueber speed on multiple ports at once,
port multipliers are a good way to get more ports.
Issue: if a port has a problem (flaky disk or whatever), siis(4) may
do a bunch of DELAY(big number) which interferes with other hardware
doing real-time data logging, causing data to be lost. Unacceptable.
Does not require power cycle though. I don't recall it even needing
a reboot.
_______________________________________________
freebsd-***@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "freebsd-hardware-***@freebsd.org"