Silicon Image SIL3124 SATA cards and FreeBSD

A system I am looking into purchasing comes with a 4-port SATA RAID card that is based on the Silicon Image SIL3124 chipset. Are these well-supported? I don't really care about the hardware RAID part, I just want to make sure FreeBSD can see and use disks attached to the 4 SATA ports provided by the card.
 
Thats pretty expensive, i got my SiI-3132 PCIe x1 for less than 15 euro. Also, the Silicon Image RAID drivers do not work under BSD. But you can use software RAID.

With these fakeRAID controllers; you need to leave the last sector untouched; so create partitions on the individual disks that are slightly smaller than the full capacity. That would make sure the on-disk data does not interfere with metadata sector used by the RAID BIOS. Without this, the last sector may get overwritten with the controller's data next time you boot.
 
SiI3124 is the one of the most featured SATA controllers now in 8-STABLE. Just make sure to use it with new siis(4) driver. If you put it into a proper bus - it will be very fast.

Cheaper SiI3132 mentioned here is also fine, but it only has two ports and it's bandwidth is quite limited by PCIe x1 bus.
 
mav: if the SiI-3132 is 2 SATA 3Gbps ports on PCIe x1 2.5Gbps, and the SiI-3124 is 4 SATA 3Gbps ports on PCIe x1 2.5Gbps; then the latter will have the most bandwidth restrictions, my logic dictates.

Perhaps some Silicon Image products with PCIe x4 interface exists, but i only got some with x1 interface and the original PCI-express spec (2.5Gbps). That would get you to about 60MB/s per drive if you all use them at the same time (RAID). Still not bad for regular HDDs.
 
SiI3124 is a PCI-X chip. Installed in proper PCI-X slot it really gives about 1GB/s total bandwidth, completely fulfilling 4 SATA 3Gb/s ports requirements. I have also tested PCIe x1 and PCIe x8 cards, based on SiI3124. They were using additional PCI bridge chips to convert interfaces. PCIe x8 version is almost as fast as native PCI-X one. PCIe x1 version is indeed limited by bus, but it still gives up to 200MB/s in practice, while SiI3132 - only 150-170MB/s.
 
I see, so this is actually a PCI-X chip with a bridge-chip to make it work under PCI-e.

However you say i should only be able to reach 150-170MB/s with SiI-3132? Is this chip also based on PCI-X or is it a native PCI-express chip? I'm pretty sure i got full bandwidth from my HDDs on SiI-3132 as i've benchmarked disks on it frequently. My disks don't do more than 100MB/s however. But that means i get ~200MB/s from this controller with two disks.

I dislike PCI-X for the simple reason its EOL and any PCI-X product you buy means you're locked-in to older technology not allowing you to update your system because you still got those PCI-X cards.

Even Areca used such a bridge chip solution, with the actual controller being PCI-X instead. That was already the reason of my BIOS problems; if it were a native PCI-express card i wouldn't have my problems.
 
SiI3132 is a PCIe native chip. At least as it can be seen from outside. I am not sure why, but on my tests it didn't show very impressive numbers, comparing to others. Yes, it was fine for random I/O, it nicely supports port multipliers, it is cheap. But as I have said, it shown to me not so high bandwidth. It was varying depending on workload, number of drives and I/O direction. May be in some cases 200MB/s could be reached (especially in bidirectional I/O), but SiI3124 gave them to me easier, even using single SATA port with port multiplier or single fast SSD.

I would also like to see something shiny new from SiI for PCIe x4/x8 bus and SATA 6Gbps support, but I haven't heard anything yet.
 
You can check out this:

Supermicro USAS2 L8e (8x SATA/600 on PCIe x8 gen 2 = 4GB/s)
http://www.supermicro.com/products/accessories/addon/AOC-USAS2-L8i.cfm?TYP=E

Supermicro USAS L8i (8x SATA/300 on PCIe x8 gen 1 = 2GB/s)
http://www.supermicro.com/products/accessories/addon/AOC-USAS-L8i.cfm

Both these controllers are UIO cards, meaning the components are on the "wrong" side (actually i think its the right side as heat wants to travel up and this just makes sense to me). You may need to remove the bracket to make it fit in your PC. It also uses Mini-SAS cables; one cable connects four normal SATA/300 or SATA/600 disks. With two of those cable you can connect 8 disks without using port multipliers.

The latter (USAS L8i) is supported under FreeBSD, but is the 'older' version. The newer version (first mentioned) has 6Gbps SATA and uses PCI-express 2.0 with double the bandwidth. Problem is, it is likely not yet supported.

I mailed scottl@ about this controller, as i found a reference of him working on driver support for the chip in FreeBSD. However, i did not receive a reply as of yet. My assumption is that the 6Gbps SAS/SATA controller doesn't work (properly) yet.
 
I have a sil3124, and the OS sees the drives, however the second i go to write to them ,it locks up the bus..

Im running 8.1-release

Has anyone gotten one of these cards to work with all four ports full? Im using a enclosure with 12 drives in it. Im just trying to write to one drive now using zfs.
 
ill copy and paste some things from /var/log/messages..

whenever i access the disk, it locks up the bus, and leaves me stuck..

Code:
Jul 21 12:33:00 fs1 kernel: FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010

Jul 22 07:04:45 fs1 kernel: siisch2: siis_timeout is 00040000 ss 40000000 rs 40000000 es 00000000 sts 801e0000 serr 00000000
Jul 22 07:05:00 fs1 kernel: siisch2: Timeout on slot 30
Jul 22 07:05:00 fs1 kernel: siisch2: siis_timeout is 00040000 ss 40000000 rs 40000000 es 00000000 sts 801e0000 serr 00000000
Jul 22 07:05:16 fs1 kernel: siisch2: Timeout on slot 30


Jul 21 13:03:21 fs1 kernel: siis0: <SiI3124 SATA controller> port 0xecf0-0xecff mem 0xfe7ffc00-0xfe7ffc7f,0xfe7f0000-0xfe7f7fff irq 37 at 
device 11.0 on pci3
Jul 21 13:03:21 fs1 kernel: siis0: [ITHREAD]
Jul 21 13:03:21 fs1 kernel: siisch0: <SIIS channel> at channel 0 on siis0
Jul 21 13:03:21 fs1 kernel: siisch0: [ITHREAD]
Jul 21 13:03:21 fs1 kernel: siisch1: <SIIS channel> at channel 1 on siis0
Jul 21 13:03:21 fs1 kernel: siisch1: [ITHREAD]
Jul 21 13:03:21 fs1 kernel: siisch2: <SIIS channel> at channel 2 on siis0
Jul 21 13:03:21 fs1 kernel: siisch2: [ITHREAD]
Jul 21 13:03:21 fs1 kernel: siisch3: <SIIS channel> at channel 3 on siis0
Jul 21 13:03:21 fs1 kernel: siisch3: [ITHREAD]


Jul 21 13:03:21 fs1 kernel: pmp0 at siisch0 bus 0 scbus0 target 15 lun 0
Jul 21 13:03:21 fs1 kernel: pmp0: <Port Multiplier 37261095 1706> ATA-0 device
Jul 21 13:03:21 fs1 kernel: pmp0: 300.000MB/s transfers (SATA 2.x, NONE, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: pmp0: 5 fan-out ports
Jul 21 13:03:21 fs1 kernel: pmp1 at siisch1 bus 0 scbus1 target 15 lun 0
Jul 21 13:03:21 fs1 kernel: pmp1: <Port Multiplier 37261095 1706> ATA-0 device
Jul 21 13:03:21 fs1 kernel: pmp1: 300.000MB/s transfers (SATA 2.x, NONE, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: pmp1: 5 fan-out ports
Jul 21 13:03:21 fs1 kernel: ada0 at siisch0 bus 0 scbus0 target 0 lun 0
Jul 21 13:03:21 fs1 kernel: ada0: <Hitachi HDS722020ALA330 JKAOA3EA> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada0: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada1 at siisch0 bus 0 scbus0 target 1 lun 0
Jul 21 13:03:21 fs1 kernel: ada1: <Hitachi HDS722020ALA330 JKAOA3EA> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada1: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada2 at siisch0 bus 0 scbus0 target 2 lun 0
Jul 21 13:03:21 fs1 kernel: ada2: <Hitachi HDS722020ALA330 JKAOA20N> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada2: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada2: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada3 at siisch0 bus 0 scbus0 target 3 lun 0
Jul 21 13:03:21 fs1 kernel: ada3: <Hitachi HDS722020ALA330 JKAOA20N> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada3: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada4 at siisch0 bus 0 scbus0 target 4 lun 0
Jul 21 13:03:21 fs1 kernel: ada4: <Hitachi HDS722020ALA330 JKAOA3EA> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada4: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada4: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada5 at siisch1 bus 0 scbus1 target 0 lun 0
Jul 21 13:03:21 fs1 kernel: ada5: <Hitachi HDS722020ALA330 JKAOA28A> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada5: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada5: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada5: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada6 at siisch1 bus 0 scbus1 target 1 lun 0
Jul 21 13:03:21 fs1 kernel: ada6: <Hitachi HDS722020ALA330 JKAOA28A> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada6: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada6: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada6: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada7 at siisch1 bus 0 scbus1 target 2 lun 0
Jul 21 13:03:21 fs1 kernel: ada7: <Hitachi HDS722020ALA330 JKAOA3EA> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada7: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada7: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada7: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada8 at siisch1 bus 0 scbus1 target 3 lun 0
Jul 21 13:03:21 fs1 kernel: ada8: <Hitachi HDS722020ALA330 JKAOA3EA> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada8: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada9: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada9: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada9: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada10 at siisch2 bus 0 scbus2 target 0 lun 0
Jul 21 13:03:21 fs1 kernel: ada10: <Hitachi HDS722020ALA330 JKAOA28A> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada10: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada10: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada10: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
Jul 21 13:03:21 fs1 kernel: ada11 at siisch3 bus 0 scbus3 target 0 lun 0
Jul 21 13:03:21 fs1 kernel: ada11: <Hitachi HDS722020ALA330 JKAOA3EA> ATA-8 SATA 2.x device
Jul 21 13:03:21 fs1 kernel: ada11: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
Jul 21 13:03:21 fs1 kernel: ada11: Command Queueing enabled
Jul 21 13:03:21 fs1 kernel: ada11: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)

Jul 21 13:06:53 fs1 root: ZFS: vdev I/O failure, zpool=storage path=/dev/ada0 offset=135168 size=1024 error=22
Jul 21 13:06:53 fs1 root: ZFS: vdev I/O failure, zpool=storage path=/dev/ada0 offset=397312 size=1024 error=22
Jul 21 13:06:53 fs1 root: ZFS: vdev I/O failure, zpool=storage path=/dev/ada0 offset=2000398454784 size=1024 error=22
Jul 21 13:06:53 fs1 root: ZFS: vdev I/O failure, zpool=storage path=/dev/ada0 offset=2000398716928 size=1024 error=22
Jul 21 13:06:53 fs1 root: ZFS: vdev I/O failure, zpool=storage path= offset= size= error=
 
Sorry, I am not very understand events chronology. How timeouts shown first related to errors shown below?
 
ok:

Using a Dell 1850 server, Port 1 (pcix slot)..

I moved the card to slot 2 and the problem totally went away.

so far so good, i will keep you posted.
 
sub_mesa said:
With these fakeRAID controllers; you need to leave the last sector untouched; so create partitions on the individual disks that are slightly smaller than the full capacity. That would make sure the on-disk data does not interfere with metadata sector used by the RAID BIOS. Without this, the last sector may get overwritten with the controller's data next time you boot.

Is that really true? That's a massive potential issue to people using these cards who haven't read this thread. It doesnt mention anything about this in the SIIS driver man page for example....
 
What he means is maybe the ability to use this chip with the ata driver. The siis driver does not support any "fake"raid it seems like.

http://www.FreeBSD.org/cgi/man.cgi?query=siis&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html

Code:
Same hardware is also supported by atasiliconimage driver from ata(4)
     subsystem. If both drivers are loaded at the same time, this one will be
     given precedence as the more functional of the two.

And if you use the ata driver FreeBSD and have a Raid0 or 1 configured it could be detected as a ataraid. The problem with that solutions is, that FreeBSD often can only read the meta data but cannot write it. If one drive fail FreeBSD is unable to write this in the controller specific ondisk metadata, so after a reboot the controller could still think everything is ok (except the drive is really dead) ... but it isnt.

http://www.FreeBSD.org/cgi/man.cgi?query=ata&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html

http://www.FreeBSD.org/cgi/man.cgi?query=ataraid&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE&format=html

Personally i think ataraid is obsolete anyway, because gmirror or zfs are doing a good job and are much more flexible.
 
User23 said:
What he means is maybe the ability to use this chip with the ata driver. The siis driver does not support any "fake"raid it seems like.

Yah, I have it on the authority of the SIIS dev mav@ that the SIIS driver only supports JBOD (no RAID). But the comment I quoted about not using the last sector in case the controller decides to overwrite it is very worrying if true. I understand that if you use the RAID functionality of this card that it may or may not write meta data to the disk, but the important thing for me is if it does or does not write some metadata to a disk when configured under FreeBSD using the SIIS driver. If it did that would be disastrous....

thanks Andy.
 
mav@ said:
SiI3124 is the one of the most featured SATA controllers now in 8-STABLE. Just make sure to use it with new siis(4) driver. If you put it into a proper bus - it will be very fast.

I have a file server with FreeBSD 7.3 RELEASE (p2), with 4 drives running ZFS v13 in stripped mirror pools (RAID 1+0). Since the motherboard was short on SATA ports, I've installed an add-in 4 SATA2 ports PCI-X card based on the SiI3124 chipset.

Reading this thread, I was expecting to have to upgrade to 8.1 RELEASE (which include the SIIS(4) driver) in order to have a functional SiI3124 add-in card. However, when I reboot the 7.3 RELEASE, I noticed that the SiI3124 card was recognized and I can run a "diskinfo -t" benchmark on the SATA2 drives attached to the card.

I was a bit puzzled at first but after a few GREP in the source code, I found that the ATA(4) driver also support the SiI3124 chipset, which explain why FreeBSD 7.3 recognized my SiI3124 card.

So, my question is the following : what are the advantages to use the SIIS(4) driver, compared to the more generic ATA(4) driver? My box is running very stable and I'm not in a hurry to upgrade to 8.1.

Any hints will be very appreciated. Thanks anyone!
 
hansivers said:
So, my question is the following : what are the advantages to use the SIIS(4) driver, compared to the more generic ATA(4) driver? My box is running very stable and I'm not in a hurry to upgrade to 8.1.

AHCI support.
 
Does the siis-driver hide the last 512 bytes used for RAID metadata? The normal ata interface for Silicon Image cards do not do this; and if you overwrote the last sector with data, then booting may fail as the RAID BIOS firmware forces you to update configuration and overwrite that 512 bytes.

When using the old ataraid interface; the provider would be smaller than the consumer; just like it should be. So it hides the 512-bytes used for metadata. If siis-driver doesn't already do so, this may be good practice, preferably a sysctl setting.
 
If I'm not mistaken, I believe the geom_pseudoraid class will reimplement ataraid in a GEOM-class instead. Then it can be used with new CAM-on-ATA infrastructure. Right now ataraid implies the older ata driver.
 
Back
Top