SATA (libata) link reset problem with port multiplier (PMP): sil3132, sil3726
 

Using Slackware64 14.0, kernel version 3.2.29

I recently purchased and set-up a Rosewill RSV-S8 RAID enclosure (see http://www.rosewill.com/products/118...ifications.htm), which consists of two primary components:

* A PCI card using a Silicon Image 3132 chipset, with two eSATA ports.

* Two SATA port multipliers in the enclosure itself, each using a Silicon Image 3726 chipset. Note that, although this controller can support five SATA connections per multiplier, this hardware configuration only uses four per.

I've updated the sil3132 BIOS to the most recent available from the Silicon Image website (7.7.03), set to "non-RAID" mode (for a JBOD configuration). The PCI card shows up in my lspci as:

Before I get too deep into the bad behavior, let me establish that this is working, that is: I have drives plugged into the enclosure, they mount in my system, and I have a functional software RAID (using mdadm) over them.

The problem is that the kernel takes a very long time to recognize the drives. If I power-up the enclosure after my system is started up, it will take a few minutes for everything to show up. If I have the enclosure powered before I start up, this delay will block the boot process for that duration (that is, for several minutes).

At the bottom of this post I've pasted grepped versions of my dmesg output, as relevant to my issue. The "first" eSATA/PMP link is seen as ata5, and the "second" link is seen as ata6; as is shown in the output, I have four HDDs plugged into ata5, but none into ata6 (waiting for another good sale).

The behavior pattern is:

* The PMP is found;
* The PMP's hardware connections are enumerated and reset;
* The reset fails after a timeout (10 seconds, 10 seconds, 35 seconds, then 5 seconds), then is retried three more times (with corresponding timeouts);
* This whole enumerate/reset/fail-x4 process itself repeats twice more;
* Finally, the message "failed to recover link after 3 tries, disabling" occurs and the system can proceed. At this point, if there are actually drives plugged into the PMP, they get recognized almost instantly and the system can proceed.
* And then this happens all over again for the second PMP.

I've observed the same behavior with the enclosure completely empty, and with my HDDs plugged into the "second" PMP instead of the first.

Does anyone have any ideas on what might cause this repeated failed-reset issue (and hence delay)?

My personal theory is that this has to do with the missing fifth SATA link from the PMP, like libata (via the sil controllers) can't tell that nothing's there, and futilely waits for a response from a hardware port that doesn't exist. But I don't really know enough about libata to investigate this further.

I appreciate any input, but since as I said this is functional (eventually), I don't have any interest in replacing the hardware just yet.

I decided to rip open the enclosure today - just as a safety check for dangling hardware connections, etc - and noticed that the port multiplier is actually a Silicon Image 3826, not 3726 as advertised on the Rosewill site. (In retrospect this should have been obvious from the dmesg logs, which plainly show a PMP revision of 0x3826)

I'd be willing to bet that the 3826 is a minor update from the 3726, but from browsing the linux-ide mailing list and skimming some source (drivers/ata/libata-pmp.c) it looks like there are a number of quirk-hacks for the 3726 chipset, which probably need to apply to the 3826 as well.

I've never used a custom kernel before but I think that's probably my next step.

EDIT In fact, a quick google search shows that this should be the case:
https://bugzilla.redhat.com/show_bug.cgi?id=890237
The attached PDF (!?) shows that, yeah, the suggested patch is to apply the same quirks for the 3826 as for the 3726.
This still hasn't made its way into the main Linux sources, though.

After an embarrassing number of missteps in executing my custom kernel build, I did eventually verify that patching libata-pmp.c to use the same quirks for the 3826 as the 3726, solves this problem handily.