From: Roland Dreier <roland@xxxxxxxxxxxxxxx> When we return sense data instead of a response, the FC protocol requires us to set the FCP_RESID_UNDER bit and set FCP_RESID appropriately (it should be the original FCP_DL value, since we are not returning any data). Make sure we set the se_cmd fields appropriately so qla2xxx does this. Otherwise, initiators get confused when we fail a command and return a check condition (eg because of an unimplemented mode page), because we would leave FCP_RESID as 0 but on the other hand don't transfer any data in an exchange; this would lead to FC link layer problems. Sometimes initiators wouldn't see the sense data at all and would go into a loop retrying the failing command over and over for a long time. Signed-off-by: Roland Dreier <roland@xxxxxxxxxxxxxxx> --- Hi Nick, This patch definitely fixes real problems we see with FC initiators going crazy retrying commands. However I'm not sure if this is the right place to fix this -- if I read the iSCSI spec correctly, it looks like the letter of the protocol requires similar handling of the residual field there, and I suspect the FCoE target also wants this. drivers/target/tcm_qla2xxx/tcm_qla2xxx_fabric.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/target/tcm_qla2xxx/tcm_qla2xxx_fabric.c b/drivers/target/tcm_qla2xxx/tcm_qla2xxx_fabric.c index 305f554..22d4051 100644 --- a/drivers/target/tcm_qla2xxx/tcm_qla2xxx_fabric.c +++ b/drivers/target/tcm_qla2xxx/tcm_qla2xxx_fabric.c @@ -787,6 +787,9 @@ int tcm_qla2xxx_queue_status(struct se_cmd *se_cmd) * For FCP_READ with CHECK_CONDITION status, clear cmd->bufflen * for qla2xxx_xmit_response LLD code */ + se_cmd->se_cmd_flags |= SCF_UNDERFLOW_BIT; + se_cmd->residual_count = se_cmd->data_length; + cmd->bufflen = 0; } /* -- 1.7.5.4 -- 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
