With port bounce/address swaps and timing between initiator GID queries
vs remote port FC4 support registrations, the driver may be in a situation
where it sends PRLIs for both FCP and NVME even though the target may not
support one of the protocols. In this case, the remote port will reject
the PRLI and usually indicate it does not support the request. However,
the driver currently ignores the status of the failure and immediately
retries the PRLI, which is pointless. In the case of this one remote port,
the reception of the PRLI retry caused it to decide to send a LOGO.
The LOGO restarted the process and the same results happened. It made
the remote port undiscoverable to either protocol.
Add logic to detect the non-support status and not attempt the retry
of the PRLI.
Signed-off-by: Dick Kennedy <dick.kennedy@xxxxxxxxxxxx>
Signed-off-by: James Smart <jsmart2021@xxxxxxxxx>
---
drivers/scsi/lpfc/lpfc_els.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 85d4e4000c25..48dc63f22cca 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -3937,10 +3937,14 @@ lpfc_els_retry(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb,
case LSRJT_UNABLE_TPC:
/* The driver has a VALID PLOGI but the rport has
* rejected the PRLI - can't do it now. Delay
- * for 1 second and try again - don't care about
- * the explanation.
+ * for 1 second and try again.
+ *
+ * However, if explanation is REQ_UNSUPPORTED there's
+ * no point to retry PRLI.
*/
- if (cmd == ELS_CMD_PRLI || cmd == ELS_CMD_NVMEPRLI) {
+ if ((cmd == ELS_CMD_PRLI || cmd == ELS_CMD_NVMEPRLI) &&
+ stat.un.b.lsRjtRsnCodeExp !=
+ LSEXP_REQ_UNSUPPORTED) {
delay = 1000;
maxretry = lpfc_max_els_tries + 1;
retry = 1;
--
2.26.2
