during a test that creates a CRC error (target to initiator) by dropping a data word from a frame w/o recomputing the CRC, i can induce a 'loop' case. the controller sees the the CRC error, issues a device reset, and the scsi request comes back w/ DID_RESET set (rather than DID_PARITY or something else since it has already done the reset). i have an issue out to the controller vendor about this, but sallying forth to linux-scsi-land regardless... scsi_decide_disposition() looking at a command w/ DID_RESET returns SUCCESS and then scsi_io_completion() unconditionally retries the command. w/ our injector setup to corrupt alternating data frames i can induce an 'infinite loop' in the case where the controller's reset works and then the scsi READ(10) fails. anyway, i'd like to avoid this loop regardless of 'odd' controller behavior so am asking about the two possible fixes i see and to see if there's some other way. - make scsi_decide_disposition()'s handling of DID_RESET just use the maybe_retry logic. however, (being new to this area) scsi_io_completion() calls scsi_end_request() in case some data actually got read. i don't see that a request w/ DID_RESET set can have data, but if it really can, then... - copy retry logic to scsi_io_completion() in the DID_RESET case. using cmd->retries seems safe here since it won't ahve gotten updated in scsi_decide_disposition(), but maybe a comment there might be nice. am i offbase/missing something/lacking sufficient details? \p -- 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
