Hello,
Grant Grundler wrote:
>> [59719.989422] ata7: irq_stat 0x01100010, PHY RDY changed
>> [59719.989477] ata7: SError: { 10B8B }
>> [59722.781043] ata7: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
>> [59722.781112] ata7: irq_stat 0x00b40090, PHY RDY changed
>> [59791.300259] ata7.15: failed to write PMP_FEAT_EN (Emask=0x40)
>> [59791.300324] ata7: failed to recover PMP after 5 tries, giving up
>> [59791.300323] ata7: exception Emask 0x3 SAct 0x0 SErr 0x0 action 0x6 frozen t4
>> [59791.300483] ata7: irq_stat 0x00060002, device error via D2H FIS
>
> The "6 ports" is the clue I was looking for.
>
> [ 7.080266] ata7.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6
> ports, feat 0x1/0x9
> [ 7.080531] ata7.00: hard resetting link
> [ 7.430307] ata7.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
> [ 7.430311] ata7.01: hard resetting link
> [ 7.780305] ata7.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 7.780309] ata7.02: hard resetting link
> [ 8.130305] ata7.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 8.130310] ata7.03: hard resetting link
> [ 8.480305] ata7.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 8.480310] ata7.04: hard resetting link
> [ 8.830317] ata7.04: SATA link down (SStatus 0 SControl 320)
> [ 8.830321] ata7.05: hard resetting link
> [ 9.180232] ata7.05: failed to read SCR 1 (Emask=0x1)
> [ 9.180233] ata7.05: failed to read SCR 0 (Emask=0x40)
>
> I don't believe port ata7.05 exists. AFAIK, sil3736 only has 5 ports (0 to 4).
> One of the quirks isn't applying or needs to be added to the kernel.
> I don't recall what the psuedo port is for but Tejun or "Sans Digital
> TRM4-B" vendor might know.
>
> I think this comment in libata-pmp.c might be relevant:
> /* port 5 is for SEMB device and it doesn't like SRST */
>
> But it looks like port 5 isn't responding at all. You might add a hack to change
> "6" to "5" inside the "sil3726 quirks" code chunk.
Ah... right, it's the SEMB port which is causing the problem. I left
it there just in case someone would extend on it and make it useful,
which never really happened and given the general flakiness of this
first generation PMPs, I think we would be better off simply disabling
these SEMB and configuration devices altogether. Any objections?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
