On 12/07/2012 03:05 PM, Jeremy Linton wrote: > On 12/7/2012 1:58 PM, Chad Dupuis wrote: >> Also, are there certain port types we wouldn't want to send this reset to >> such as tape? > > AFAIK, for tape it shouldn't cause any more harm than the target reset which > happens immediately before it. This patch is infinitely better than the > previous "bus" reset behavior. > > That said, its far from perfect. The code (as I understand it) isn't > differentiating between isolating the failure, or bringing out the big > hammer in an attempt to correct problems on a specific I_T_L. If you > drop/reset the I_T because one of the LUN's is misbehaving before verifying > the status of other LUN's on the target, you risk interrupting operations to > functional devices. > When this code is called the scsi eh has run the abort handler for each outstanding command and that has failed, and it has run the lun/device reset handler and that has failed (or the eh operations succeeded but the TUR checkup the scsi eh does failed). -- 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
