Le 28 octobre 2010 13:22, weasel@xxxxxxxx <weasel@xxxxxxxx> a écrit : > > 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... i should have added that my mumbling about frames is because the controller is doing SAS to SATA translation. their target reset logic and how they 'squash' the scsi request's 'return value' are done in their firmware block, and i'm not sure how doable/convenient/etc it is to get more verbose errors from their firmware (ie, they can't translate dropped words into an underrun, but they might be able to say something like ata's ICRC). > 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 -- 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
