Re: [PATCH 2/3] scsi: core: Retry after a delay if the device is becoming ready

[Bart Van Assche <bvanassche@acm.org>]

On 6/28/22 18:21, Ming Lei wrote:
> On Tue, Jun 28, 2022 at 03:21:30PM -0700, Bart Van Assche wrote:
>> If a logical unit reports that it is becoming ready, retry the command
>> after a delay instead of retrying immediately.
>>
>> Cc: Ming Lei <ming.lei@redhat.com>
>> Cc: Hannes Reinecke <hare@suse.de>
>> Cc: John Garry <john.garry@huawei.com>
>> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
>> ---
>>   drivers/scsi/scsi_error.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
>> index 49ef864df581..fb7e363c4c00 100644
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -625,10 +625,10 @@ enum scsi_disposition scsi_check_sense(struct scsi_cmnd *scmd)
>>   			return NEEDS_RETRY;
>>   		/*
>>   		 * if the device is in the process of becoming ready, we
>> -		 * should retry.
>> +		 * should retry after a delay.
>>   		 */
>>   		if ((sshdr.asc == 0x04) && (sshdr.ascq == 0x01))
>> -			return NEEDS_RETRY;
>> +			return ADD_TO_MLQUEUE;
> 
> The above code & commit log just said changing to retry after a delay, but not
> explains why, care to document reason why the delay is useful?

I came up with this patch because I was concerned about the impact of the LOGICAL
UNIT IS IN PROCESS OF BECOMING READY response on the START command. While reviewing
SBC-4 I noticed that that response can be produced for any command but not for the
START command with IMM=0. So I think this patch can be dropped since
sd_start_stop_device() does not set the IMM flag.

Thanks,

Bart.