On Mon, 2011-01-24 at 23:34 -0600, Mike Christie wrote: > 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. Just so I'm clear ... that's you withdrawing all objections to this patch, so I can put it in scsi-misc for testing? James -- 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
