On 2023/02/08 3:40, marius@xxxxxxxxxxxxxx wrote: > January 31, 2023 9:28 AM, "Damien Le Moal" <damien.lemoal@xxxxxxxxxxxxxxxxxx> 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. -- Damien Le Moal Western Digital Research
