From: James Smart <>

[ Upstream commit e06351a002214d152142906a546006e3446d1ef7 ]

In the lpfc discovery engine, when as a nvme target, where the driver
was performing mailbox io with the adapter for port login when a NVME
PRLI is received from the host. Rather than queue and eventually get
back to sending a response after the mailbox traffic, the driver
rejected the io with an error response.

Turns out this particular initiator didn't like the rejection values
(unable to process command/command in progress) so it never attempted a
retry of the PRLI. Thus the host never established nvme connectivity
with the lpfc target.

By changing the rejection values (to Logical Busy/nothing more), the
initiator accepted the response and would retry the PRLI, resulting in
nvme connectivity.

Signed-off-by: Dick Kennedy <>
Signed-off-by: James Smart <>
Reviewed-by: Hannes Reinecke <>
Signed-off-by: Martin K. Petersen <>
Signed-off-by: Sasha Levin <>
 drivers/scsi/lpfc/lpfc_nportdisc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c 
index 678bfdd53eb2..d489f6827cc1 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -1569,8 +1569,8 @@ lpfc_rcv_prli_reglogin_issue(struct lpfc_vport *vport,
                                         ndlp->nlp_rpi, ndlp->nlp_state,
                        memset(&stat, 0, sizeof(struct ls_rjt));
-                       stat.un.b.lsRjtRsnCode = LSRJT_UNABLE_TPC;
-                       stat.un.b.lsRjtRsnCodeExp = LSEXP_CMD_IN_PROGRESS;
+                       stat.un.b.lsRjtRsnCode = LSRJT_LOGICAL_BSY;
+                       stat.un.b.lsRjtRsnCodeExp = LSEXP_NOTHING_MORE;
                        lpfc_els_rsp_reject(vport, stat.un.lsRjtError, cmdiocb,
                                            ndlp, NULL);
                        return ndlp->nlp_state;

Reply via email to