On 6/18/24 22:29, Yihang Li wrote:
> Hi Damien,
>
> I found out that two issues is caused by commit 0c76106cb975 ("scsi: sd:
> Fix TCG OPAL unlock on system resume") and 626b13f015e0 ("scsi: Do not
> rescan devices with a suspended queue").
>
> The two issues as follows for the situation that there are ATA disks
> connected with SAS controller:
Which controller ? What is the driver ?
> (1) FLR is triggered after all disks and controller are suspended. As a
> result, the number of disks is abnormal.
I am assuming here that FLR means PCI "Function Level Reset" ?
FLR and disk/controller suspend execution timing are unrelated. FLR can be
triggered at any time through sysfs. So please give details here. Why is FLR
done when the system is being suspended ?
> (2) After all disks and controller are suspended, and resuming all disks
> again, the driver reference counting is not 0 (The value of "Used" in the
> lsmod command output is not 0).
Resuming all disks again ? So you mean system resume ?
Are we talking about system suspend to ram ? Hybernation ? or something else ?
(e.g. a controller reset through PCI FLR ?)
Please clarify exactly what your adapter is and the full procedure you do to
trigger the issue so that we can try to recreate it.
> For the issue 1, After all disks and controller are suspended, FLR command
> will resuming the controller and all sas ports. libsas layer will call
> ata_sas_port_resume() to resume ata port and schedule EH to recover it.
> In libata standard error handler ata_std_error_handler(), it will call ata
> reset function, revalidate ATA devices and issue ATA device command
> ATA_CMD_READ_NATIVE_MAX_EXT to read native max address. This command will
> failed due to the controller enter suspend state again and libata disable
> the device finally. The controller enter suspend state again because FLR
> command completes and the runtime PM usage counter is 0.
>
> In commit 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume")
> and 626b13f015e0 ("scsi: Do not rescan devices with a suspended queue"),
> use blk_queue_pm_only() to check the device request queue state, if the
> device request queue is not running, the device will not be rescanned.
> Therefore, the runtime PM usage counter of the controller will not
> increase so that the controller enters the suspended state again.
>
> For the issue 2, the cause is unknown.
>
> How to solve these two issues?
>
> regards,
> Yihang
>
--
Damien Le Moal
Western Digital Research
