On Tue, 30 Sep 2008, James Bottomley wrote: > I don't really think this is the right approach, since the retry case > needs to be split apart again. > > The only time scsi_requeue_command() needs to be called is if the > request completes successfully but has leftovers. The reason is that > the command will be different next time around, so it has to be > re-prepared. In all the other cases, the same command can be reused. > This will have the knock on effect of not resetting the timers or the > counters, so it has to be done carefully. All right. (Incidentally, do you happen to know the derivation of "knock on effect"? The American form, "side effect", seems more self-explanatory.) > Of the three requeue cases: > > UNIT_ATTENTION needs immediate retry > NOT_READY needs delayed retry > ILLEGAL_REQUEST with cmd switch (assuming we still do it) needs > immediate retry If the command is switched from 10-byte to 6-byte form, won't it need to be re-prepared? > DID_RESET is arguable either way, but probably needs delayed. > > immediate requeue is done by: > > scsi_queue_insert(cmd, SCSI_MLQUEUE_EH_RETRY); > > And delayed by > > scsi_queue_insert(cmd, SCSI_MLQUEUE_DEVICE_BUSY); Easily fixed. And it looks like neither of these needs a call to scsi_next_command(), right? Alan Stern -- 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
