Re: Bug report for ahci-mvebu driver

Damien Le Moal
2023-02-07T23:40:01Z

On 2023/02/08 3:40, marius@psihoexpert.ro wrote:
> January 31, 2023 9:28 AM, "Damien Le Moal" <damien.lemoal@opensource.wdc.com> wrote:
>
>> I did testing on Intel & AMD machines with different adpaters/drives/pmp that I
>> have (AHCI, ASMedia and Marvell adapters). Everything was OK on my end.
>>
>> The tag is for this kernel only. If backporting to 5.15 does not solve the
>> issue, we will need to take that separately and redo debugging on that version.
>> I would like to send the patch to Linus by the end of the week...
>>
>> --
>> Damien Le Moal
>> Western Digital Research
>
> I saw that the patch was applied to v5.15 too. That was probably not a good ideea. This weekend I tried to test the patch in OpenWrt kernel v5.15. It doesn't work:
>
> --- RAID box connected ---
> [ 1772.100899] ata2: SATA link down (SStatus 111 SControl 310)
> [ 1772.114132] ata2: limiting SATA link speed to 1.5 Gbps
> ...and these two lines repeat forever. There is no "giving up".
>
> I tried the workaround "libata.force=2:1.5Gbps". It works, but with a delay:
>
> [ 116.705772] ata2: SATA link down (SStatus 101 SControl 300)
> [ 119.175752] ata2: COMRESET failed (errno=-32)

EPIPE is supposed to be to tell the upper layer to lower the speed...

> [ 119.180133] ata2: reset failed (errno=-32), retrying in 8 secs
> [ 127.205713] ata2: limiting SATA link speed to <unknown>

...which here ends up not looking good as the speed limit is still UINT_MAX, so
unknown for that drive. So I guess that for 5.15, we need to fix not only the
current speed, but also the speed limit.

> [ 129.475703] ata2: COMRESET failed (errno=-32)
> [ 129.480084] ata2: reset failed (errno=-32), retrying in 8 secs
> [ 137.445667] ata2: limiting SATA link speed to <unknown>
> [ 139.715666] ata2: COMRESET failed (errno=-32)
> [ 139.720052] ata2: reset failed (errno=-32), retrying in 33 secs
> [ 172.645529] ata2: limiting SATA link speed to <unknown>
> [ 173.585525] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 3D0)

And then here, automagically, the libata.force limit seem to kick in... Very weird.

> [ 173.591831] ata2.15: Port Multiplier 1.2, 0x197b:0x0325 r193, 8 ports, feat 0xf/0x1f
> [ 173.600838] ahci-mvebu f10a8000.sata: FBS is enabled
> [ 173.605977] ata2.00: hard resetting link
> [ 173.937078] ata2.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 173.943563] ata2.01: hard resetting link
> [ 174.277073] ata2.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 174.283555] ata2.02: hard resetting link
> [ 174.617075] ata2.02: SATA link down (SStatus 0 SControl 300)
> [ 174.622787] ata2.03: hard resetting link
> [ 174.957074] ata2.03: SATA link down (SStatus 0 SControl 300)
> [ 174.962785] ata2.04: hard resetting link
> [ 175.297075] ata2.04: SATA link down (SStatus 0 SControl 300)
> [ 175.302784] ata2.05: hard resetting link
> [ 175.637072] ata2.05: SATA link down (SStatus 0 SControl 300)
> [ 175.642781] ata2.06: hard resetting link
> [ 175.977071] ata2.06: SATA link down (SStatus 0 SControl 300)
> [ 175.982781] ata2.07: hard resetting link
> [ 176.317063] ata2.07: SATA link down (SStatus 0 SControl 300)

That is weird too. No point in repeatedly resetting if the link is up. So the
patch really screwed up something for 5.15.

> [ 176.322839] ata2.00: ATA-6: WDC WD50ARC-5040-VOL#01, 0100 AX, max UDMA/133
> [ 176.329758] ata2.00: 976773168 sectors, multi 0: LBA48
> [ 176.335595] ata2.00: configured for UDMA/133
> [ 176.339944] ata2.01: ATA-6: Areca Archive, 0100 AX, max UDMA/133
> [ 176.346160] ata2.01: 23437498368 sectors, multi 0: LBA48
> [ 176.351830] ata2.01: configured for UDMA/133
> [ 176.356303] ata2: EH complete
>
> So probably some other commit needs backporting before this one works. Any ideea which might it be?
> I will try another bisect when I have time. Any clues would help a lot.

No clue either. Will have a look.