On 01/24/2011 11:18 PM, Mike Christie wrote:
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?
Ignore that. I see it is getting called for the host reset code. I am
not sure what happened when I was testing it.
--
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
