On Sat, Jun 23, 2018 at 2:56 AM, Bart Van Assche <bart.vanassche@xxxxxxx> wrote:
> On 06/22/18 09:38, Sreekanth Reddy wrote:
>>
>> In driver's .resume() callback function, driver is doing IOC reset
>> operation. And as per your suggestion we tried using
>> scsi_internal_device_block_nowait() to block the all the devices
>> attached to the HBA before going for IOC reset operation. During
>> system resume time as drives will be in quiesce state and calling
>> scsi_internal_device_block_nowait() return with error status -22.
>>
>> So you suggested us to try using lock_system_sleep() API before
>> calling scsi_internal_device_block_nowait(), so that we don't get -22
>> return status when we call scsi_internal_device_block_nowait() API
>> during resume time. We tried the same and we see system get hang
>> during hibernation. Please correct me if I am wrong or if I have
>> wrongly understood your suggestions.
>>
>> I feel that the fix which have posted is the better fix then using
>> scsi_internal_device_block_nowait()/scsi_internal_device_unblock_nowait()
>> APIs.
>
>
> Hello Sreekanth,
>
> It seems like there is a misunderstanding: what I proposed was to use
> lock_system_sleep() to delay hibernation until unlock_system_sleep() has
> been called. I had not realized that the mpt3sas driver can call
> scsi_internal_device_block_nowait() during system resume.
>
> There is another issue with the scsi_internal_device_block_nowait() calls by
> the mpt3sas driver: callers like _scsih_sas_broadcast_primitive_event() seem
> to assume that all scsih_qcmd() calls have finished as soon as
> scsi_internal_device_block_nowait() has returned. However, that assumption
> is not correct, especially when using scsi-mq.
>
Hello Bart,
Before calling scsi_internal_device_block_nowait() API; driver sets
sas_device_priv_data->block flag as one. And in the scsih_qcmd()
driver checks for this flag as shown below and return the commands
with host busy status.
} else if (sas_target_priv_data->tm_busy ||
sas_device_priv_data->block)
return SCSI_MLQUEUE_DEVICE_BUSY;
Also as a part of processing the braodcast primitive event driver
issues the task query TM to determine where the IO command is and will
only abort those IOs (by issuing task abort TM) which are queued in
the target devices. Hope I have clarified the issue which you have
pointed out.
> If the patch "mpt3sas: Fix calltrace observed while running IO & host reset"
> would be allowed upstream, will the issues mentioned above ever be
> addressed?
If their are any issues we are always avilable to address them.
Thanks,
Sreekanth
>
> Bart.
