On Mon, Feb 04 2008 at 20:32 +0200, "Salyzyn, Mark" <[EMAIL PROTECTED]> wrote: > ACK with condition that community accepts the RFC's entire premise. > > The removed code that shunted the REQUEST_SENSE was based on the assumption > that the sense data in the current scsi command packet was left over from the > previous command's execution with a check condition as the scsi command > packet > is reused to issue the REQUEST_SENSE. For a new, or second from the target's > point > of view, request sense to the target issued by these older kernels would > always > return an erased sense. The dpt_i2o driver does not itself maintain the sense > history, > nor does the Firmware. This behavior, I believe, is not the case for current > kernels so > the code fragment made little sense (pun not intended). If my historical > knowledge is > correct, this (now removed) workaround makes no more sense because the scsi > layer correctly > manages adapters that produce auto-request sense and does not ever turn > around the command > and send a second request for sense information.
> Given this understanding, I have no problem with the removed fragment of > REQUEST_SENSE shunting. > However, I do urge some target error recovery testing, tape drives being the > likely type of target > affected by this change. I have no such hardware to confirm... > Sincerely -- Mark Salyzyn I have removed this test because the midlayer does a scsi_eh_reset_sense() just before the new invocation of a command. So even if the second bad REQUEST_SENSE comes this will not filter it out anymore. If such a thing still happens? A driver state machine must be used to filter it out, or of course midlayer should be fixed. Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
