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.
If the patch "mpt3sas: Fix calltrace observed while running IO & host
reset" would be allowed upstream, will the issues mentioned above ever
be addressed?
Bart.
