Hi, Bart, On 2016/12/6 23:51, Bart Van Assche wrote: > On 12/06/16 01:12, Wei Fang wrote: >> The scsi device is being setted to the SDEV_RUNNING state at the end of >> the scan work. When the remote port reappears, scsi_target_unblock() >> will be called, but the QUEUE_FLAG_STOPPED flag will not be cleared, >> since scsi_internal_device_unblock() ignores SCSI devices in SDEV_RUNNING >> state. It results in a permanent stop of the scsi device's request >> queue. Every requests sended to it will be blocked. > > Hello Wei, > > scsi_device_set_state() does not allow the transition from > SDEV_CREATED_BLOCK to SDEV_RUNNING. If a SCSI device is blocked after it > has been added to the __devices list and before scsi_add_lun() finishes > then I think the scan code will change its state into SDEV_BLOCK. Are > you sure what you described above is what happened?
Yes, we already encountered this case on out machine: The state of the scsi device first is changed to SDEV_BLOCK in scsi_add_lun() as you metioned, then it will be changed to SDEV_RUNNING in scsi_sysfs_add_sdev(). Thanks, Wei -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
