On Thu, 14 Apr 2011 14:41:18 +0300 Tapani Tarvainen <raid@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Apr 14, 2011 at 05:25:28PM +0600, Roman Mamedov (rm@xxxxxxxxxx) > wrote: > > > > > I suggest that you avoid Silicon Image 3132, they have data corruption > > > > issue (on some board designs?), triggered or amplified by transferring > > > > via both ports at the same time, at full speed. > > > See this thread: http://comments.gmane.org/gmane.linux.raid/30629 > > Thanks! Based on that, it'd seem it's not so much Sil3132 per se, > but some (too cheaply?) boards built around it Maybe, but in my opinion a chip design should be 'well-rugged' against this kind of board-design blunders, under no circumstance it should pass silent corruption of user data just like that. There are checksums built in into the SATA protocol, and parity in PCI-E, so the data path itself is protected quite well against a flaky trace or solder or whatever. Silicon Image, on the other hand, had multiple data corruption reports with 3112/3114/3124 in the past, and many of those were fixable by turning off PCI performance optimizations, i.e. likely logic-level chip design problems. So I suspect 3132 has some less than ideal design decisions as well. And maybe some of those can be worked around by adding more external components (e.g. bigger capacitors etc), which are not present on cheaper board designs. So to me this seems to be a split blame, both the board designers and the chip designer are at fault. > and the obvious conclusion is that they should only be bought with plan to > test them before real use and return flakey ones. That's a good idea at all times. > On the other hand I've had similar trouble with a JMicron card > and a Marvell-based card. So planning to test and return > bad cards is probably a good idea with them as well. I have one semi-bad JMicron based card - its problem is manifesting itself as one SATA port at first throwing a lot of CRC errors then switching itself down to 1.5GBps from 3.0GBps, and continuing to work perfectly at the slower speed. To me this is an example of error-handling done right. -- With respect, Roman
Attachment:
signature.asc
Description: PGP signature
