Praveen Krishnamoorthy
2014-10-01 21:25:54 UTC
Hi,
In a topology involving mpt2sas/mpt3sas drivers for a particular
scenario during disk addition through asynchronous scanning (post
target ID enumeration, but before device handle assignment by SCSI/SD
layer), the driver blocks the I/O to the disk using
scsi_internal_device_block() SCSI lib API, performs some cleanup in
the driver/FW, then unblock the I/O using
scsi_internal_device_unblock(). But before we unblock I notice that
the scsi_device->sdev_state is no longer SDEV_BLOCK (which the driver
had set to earlier) but the sdev_state is SDEV_RUNNING at that
juncture. I assume the SCSI Mid layer/SD driver somewhere in the disk
probe routine is setting the device to SDEV_RUNNING without checking
that it is in blocked state. Also, though the state is set to
SDEV_RUNNING by the SCSI/SD layer the block layer's request queue to
the disk is still frozen.
When we use scsi_internal_device_unblock() API to unblock from the
driver, the SCSI lib function exits with -EINVAL as the scsi_device is
already in SDEV_RUNNING state. ie, the block layer's request queue for
this disk is still frozen therefore no new I/Os could be sent to this
disk. I modified our driver with a workaround to check for the -EINVAL
return value and if it is, I perform a block followed by an unblock.
This seems to unfreeze the request queue and I/Os resume.
Therefore, we would like to understand if the behavior in the SCSI
layer could be changed by either of these 2 options in the future.
1. Ensuring the SCSI/SD layer doesn't set the device state to
SDEV_RUNNING without checking if it is already in SDEV_BLOCKED state.
2. Modifying the scsi_internal_device_unblock() function to
accommodate a case for SDEV_RUNNING state and unblocking the request
queue if it is in frozen state.
Regards,
Praveen
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
In a topology involving mpt2sas/mpt3sas drivers for a particular
scenario during disk addition through asynchronous scanning (post
target ID enumeration, but before device handle assignment by SCSI/SD
layer), the driver blocks the I/O to the disk using
scsi_internal_device_block() SCSI lib API, performs some cleanup in
the driver/FW, then unblock the I/O using
scsi_internal_device_unblock(). But before we unblock I notice that
the scsi_device->sdev_state is no longer SDEV_BLOCK (which the driver
had set to earlier) but the sdev_state is SDEV_RUNNING at that
juncture. I assume the SCSI Mid layer/SD driver somewhere in the disk
probe routine is setting the device to SDEV_RUNNING without checking
that it is in blocked state. Also, though the state is set to
SDEV_RUNNING by the SCSI/SD layer the block layer's request queue to
the disk is still frozen.
When we use scsi_internal_device_unblock() API to unblock from the
driver, the SCSI lib function exits with -EINVAL as the scsi_device is
already in SDEV_RUNNING state. ie, the block layer's request queue for
this disk is still frozen therefore no new I/Os could be sent to this
disk. I modified our driver with a workaround to check for the -EINVAL
return value and if it is, I perform a block followed by an unblock.
This seems to unfreeze the request queue and I/Os resume.
Therefore, we would like to understand if the behavior in the SCSI
layer could be changed by either of these 2 options in the future.
1. Ensuring the SCSI/SD layer doesn't set the device state to
SDEV_RUNNING without checking if it is already in SDEV_BLOCKED state.
2. Modifying the scsi_internal_device_unblock() function to
accommodate a case for SDEV_RUNNING state and unblocking the request
queue if it is in frozen state.
Regards,
Praveen
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html