On 01/24/2011 02:17 PM, Mike Christie wrote:
For example, with your patch if for the scsi_send_eh_cmnd/scsi_eh_completed_normally/scsi_check_sense path we got 02/04/01 (not ready - becomming ready), scsi_send_eh_cmnd would see SOFT_ERROR and fail the scsi eh. And, I am saying don't we want retry this like we would if we were going through the normal IO path, so we do not offline devices on this type of failure?
Just some corrections/clarifications. The device, target and bus reset handling are ok, but just host reset handling seems like the problem (at least the problem I was hitting I think). We do not call __scsi_report_device_reset for host reset handling, but some LLD eh_host_reset_handler implementations execute operations that can cause us to get something like a UA for the scsi eh TUR. For your patch do you also want to call __scsi_report_device_reset for the host reset handling for these drivers then?
-- 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
