On Tue, 2008-09-30 at 11:08 -0400, Alan Stern wrote: > 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.) The etymology is probably from Rugby: a knock on takes the ball further than allowed by the rules, usually as an unintended consequence of some other action. > > 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? Yes, sorry, that one needs a re-prepare requeue. > > 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? Right, which is a nice side effect. James -- 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
