Hi Santosh,
On Wed, 2014-03-26 at 12:11 +0530, santosh kulkarni wrote:
> Hi Nab,
>
> I see that for NOPOUT requests, in scenarios where response for a
> NOPOUT,the NOPIN gets dropped
> before it reaches the initiator and you request a retransmission through
> a Type 1 Status SNACK for that NOPIN.
> What i see is that the target sends out a SCSI Response LUN (Op code
> 0x21) instead of a NOPIN PDU. Is this an expected behaviour.
>
So the original assumption in iscsit_handle_status_snack() was that the
initiator would only be requesting a status SNACK for ISCSI_OP_SCSI_CMD
PDUs.
Note the FIXME atop iscsit_handle_status_snack():
/* #warning FIXME: Status SNACK needs to be dependent on OPCODE!!! */
Generating a SCSI response for an NOP OUT is obviously wrong here, but
I'm still undecided if it's worth supporting generating status for non
ISCSI_OP_SCSI_CMD commands.
That said, here is a quick work-around to only generate a SCSI response
for ISCSI_OP_SCSI_CMD PDUs.
Care to test..?
diff --git a/drivers/target/iscsi/iscsi_target_erl1.c b/drivers/target/iscsi/iscsi_target_erl
index cda4d80..a65af25 100644
--- a/drivers/target/iscsi/iscsi_target_erl1.c
+++ b/drivers/target/iscsi/iscsi_target_erl1.c
@@ -524,6 +524,9 @@ int iscsit_handle_status_snack(
spin_lock_bh(&conn->cmd_lock);
list_for_each_entry(cmd, &conn->conn_cmd_list, i_conn_node) {
+ if (cmd->iscsi_opcode != ISCSI_OP_SCSI_CMD)
+ continue;
+
if (cmd->stat_sn == begrun) {
found_cmd = 1;
break;
> Also when i retry the NOPOUT with the same CmdSn the target is properly
> ignoring it as duplicate since it has properly responded to the previous
> NOPOUT.
This is correct behavior.
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
