> Le 25 mai 2011 06:50, <scameron@xxxxxxxxxxxxxxxxxx> a écrit : > > Or, maybe I should be reporting the CMD_ABORTED case back as > > > > cmd->result = DID_SOFT_ERROR << 16; > > look at scsi_error.c:scsi_decide_disposition(). DID_SOFT_ERROR > triggers retry handling while DID_ABORT does not (at least in the tree > that i'm looking at). > Yes this is what I was looking at, and part of what is confusing me. This makes me think that DID_ABORT is the wrong thing to do, because it would seem that there is no retry, and yet, dd does not complain that one of the reads initiated on it's behalf has been aborted. Does that mean it copied bogus data (uninitialized memory)? Not sure, but if so, that would be bad. (Easy enough to test this case.) So this makes me wonder what DID_ABORT is intended to be used for, and that I am using in a wrong way. DID_SOFT_ERROR seems as you say like it will cause the command to be retried. However, if a command is aborted by the error handler at the mid-layer's request, is it up to the driver to tell the mid layer to retry the command? Seems like it would be up to the midlayer to know if it wanted to retry the command or not.. Then there seems to be some sense key that means the command is aborted (wondering if the firmware ought to be returning those instead of some vendor specific way of reporting aborted commands as it seems to do now.) Maybe the mid-layer is expecting a particular sense key back from a command which it has aborted, and maybe I'm not setting that? -- steve -- 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
