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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
