Re: [PATCH v3 1/3] scsi: hisi_sas: Enable force phy when SATA disk directly connected

[John Garry <john.g.garry@oracle.com>]

On 21/02/2025 01:59, yangxingui wrote:
> Hi, John
> 
> On 2025/2/21 1:35, John Garry wrote:
>> On 20/02/2025 13:05, Xingui Yang wrote:
>>
>> -john.garry@huawei.com (this has not worked in over 2 years ...)
> Sorry, I used the wrong one.
>>
>>> the SAS controller determines the disk to which I/Os are delivered based
>>> on the port id in the DQ entry when SATA disk directly connected.
>>>
>>> When many phys were disconnected immediately and connected again during
>>> I/O sending and port id of phys were changed and used by other link, I/O
>>> may be sent to incorrect disk and data inconsistency on the SATA disk 
>>> may
>>
>>
>> So is the disk reported gone (from libsas point-of-view) after you 
>> unplug? If not, why not?
> 
> The problem may occur in a scenario where multiple SATA disks are 
> inserted almost at the same time. When phy reset is executed in error 
> processing, other phys are also up, which may cause the hw port id 
> corresponding to the phy to change. The log is as follows:
> 
> [ 4588.608924] hisi_sas_v3_hw 0000:b4:02.0: phyup: phy2 link_rate=10(sata)
> [ 4588.609039] sas: phy-8:2 added to port-8:4, phy_mask:0x4 
> (5000000000000802)
> [ 4588.609267] sas: DOING DISCOVERY on port 4, pid:69294
> [ 4588.609276] hisi_sas_v3_hw 0000:b4:02.0: dev[13:5] found
> [ 4588.671362] sas: ata40: end_device-8:4: dev error handler
> [ 4588.846387] hisi_sas_v3_hw 0000:b4:02.0: phydown: phy2 
> phy_state=0xc3 // phy2's hw port id assign by chip is released
> [ 4588.846393] hisi_sas_v3_hw 0000:b4:02.0: ignore flutter phy2 down
> [ 4588.919837] hisi_sas_v3_hw 0000:b4:02.0: phyup: phy3 
> link_rate=10(sata) // phy3 is assigned the hw port id previously used by 
> phy2
> [ 4589.029656] hisi_sas_v3_hw 0000:b4:02.0: phyup: phy2 
> link_rate=10(sata) // phy2's hw port id is assigned a new one
> [ 4589.220662] ata40.00: ATA-9: HUH721010ALE600, T3C0, max UDMA/133
> [ 4589.220666] ata40.00: 19532873728 sectors, multi 0: LBA48 NCQ (depth 
> 32), AA
> [ 4589.233022] ata40.00: configured for UDMA/133
> 
> In view of the situation corresponding to the above log, the 
> hisi_sas_port.id corresponding to phy2 has not been updated, and the old 
> port id is still used, which will cause the IO delivered to phy2 to be 
> abnormally delivered to the disk of phy3.
> 
> After force phy, the chip will check whether the phy information matches 
> the port id and intercept this abnormal IO.
> 


So do you mean that all IO to this disk will error? If yes, then this is 
good.

But I still don't like the handling in this patch. If we get a phy up, 
then the directly-attached disk ideally should be gone already, so 
should not have to do this handling.

Thanks,
John