Re: [PATCH 5/9] lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled

[Hannes Reinecke]

On 12/09/2017 02:18 AM, James Smart wrote:
> When enabled for both SCSI and NVME support, and connected pt2pt to a
> SCSI only target, the driver nodelist entry for the remote port is
> left in PRLI_ISSUE state and no SCSI LUNs are discovered. Works fine
> if only configured for SCSI support.
> 
> Error was due to some of the prli points still reflecting the need
> to send only 1 PRLI. On a lot of fabric configs, targets were NVME
> only, which meant the fabric-reported protocol attributes were only
> telling the driver one protocol or the other. Thus things worked
> fine. With pt2pt, the driver must send a PRLI for both protocols as
> there are no hints on what the target supports. Thus pt2pt targets
> were hitting the multiple PRLI issues.
> 
> Complete the dual PRLI support. Track explicitly whether scsi (fcp)
> or nvme prli's have been sent. Accurately track protocol support
> detected on each node as reported by the fabric or probed by PRLI
> traffic.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_ct.c|  1 +
>  drivers/scsi/lpfc/lpfc_els.c   | 30 --
>  drivers/scsi/lpfc/lpfc_nportdisc.c | 30 +-
>  3 files changed, 34 insertions(+), 27 deletions(-)
> Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[PATCH 5/9] lpfc: Fix SCSI LUN discovery when SCSI and NVME enabled

[James Smart]

When enabled for both SCSI and NVME support, and connected pt2pt to a
SCSI only target, the driver nodelist entry for the remote port is
left in PRLI_ISSUE state and no SCSI LUNs are discovered. Works fine
if only configured for SCSI support.

Error was due to some of the prli points still reflecting the need
to send only 1 PRLI. On a lot of fabric configs, targets were NVME
only, which meant the fabric-reported protocol attributes were only
telling the driver one protocol or the other. Thus things worked
fine. With pt2pt, the driver must send a PRLI for both protocols as
there are no hints on what the target supports. Thus pt2pt targets
were hitting the multiple PRLI issues.

Complete the dual PRLI support. Track explicitly whether scsi (fcp)
or nvme prli's have been sent. Accurately track protocol support
detected on each node as reported by the fabric or probed by PRLI
traffic.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
 drivers/scsi/lpfc/lpfc_ct.c|  1 +
 drivers/scsi/lpfc/lpfc_els.c   | 30 --
 drivers/scsi/lpfc/lpfc_nportdisc.c | 30 +-
 3 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
index 2c1fe5ab3128..9d20d2c208c7 100644
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -471,6 +471,7 @@ lpfc_prep_node_fc4type(struct lpfc_vport *vport, uint32_t 
Did, uint8_t fc4_type)
"Parse GID_FTrsp: did:x%x flg:x%x x%x",
Did, ndlp->nlp_flag, vport->fc_flag);
 
+   ndlp->nlp_fc4_type &= ~(NLP_FC4_FCP | NLP_FC4_NVME);
/* By default, the driver expects to support FCP FC4 */
if (fc4_type == FC_TYPE_FCP)
ndlp->nlp_fc4_type |= NLP_FC4_FCP;
diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 6ffd65a935c4..dfb21d9efb0d 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -2094,6 +2094,10 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdiocb,
ndlp = (struct lpfc_nodelist *) cmdiocb->context1;
spin_lock_irq(shost->host_lock);
ndlp->nlp_flag &= ~NLP_PRLI_SND;
+
+   /* Driver supports multiple FC4 types.  Counters matter. */
+   vport->fc_prli_sent--;
+   ndlp->fc4_prli_sent--;
spin_unlock_irq(shost->host_lock);
 
lpfc_debugfs_disc_trc(vport, LPFC_DISC_TRC_ELS_CMD,
@@ -2101,9 +2105,6 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdiocb,
irsp->ulpStatus, irsp->un.ulpWord[4],
ndlp->nlp_DID);
 
-   /* Ddriver supports multiple FC4 types.  Counters matter. */
-   vport->fc_prli_sent--;
-
/* PRLI completes to NPort  */
lpfc_printf_vlog(vport, KERN_INFO, LOG_ELS,
 "0103 PRLI completes to NPort x%06x "
@@ -2117,7 +2118,6 @@ lpfc_cmpl_els_prli(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdiocb,
 
if (irsp->ulpStatus) {
/* Check for retry */
-   ndlp->fc4_prli_sent--;
if (lpfc_els_retry(phba, cmdiocb, rspiocb)) {
/* ELS command is being retried */
goto out;
@@ -2196,6 +2196,15 @@ lpfc_issue_els_prli(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp,
ndlp->nlp_fc4_type |= NLP_FC4_NVME;
local_nlp_type = ndlp->nlp_fc4_type;
 
+   /* This routine will issue 1 or 2 PRLIs, so zero all the ndlp
+* fields here before any of them can complete.
+*/
+   ndlp->nlp_type &= ~(NLP_FCP_TARGET | NLP_FCP_INITIATOR);
+   ndlp->nlp_type &= ~(NLP_NVME_TARGET | NLP_NVME_INITIATOR);
+   ndlp->nlp_fcp_info &= ~NLP_FCP_2_DEVICE;
+   ndlp->nlp_flag &= ~NLP_FIRSTBURST;
+   ndlp->nvme_fb_size = 0;
+
  send_next_prli:
if (local_nlp_type & NLP_FC4_FCP) {
/* Payload is 4 + 16 = 20 x14 bytes. */
@@ -2304,6 +2313,13 @@ lpfc_issue_els_prli(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp,
elsiocb->iocb_cmpl = lpfc_cmpl_els_prli;
spin_lock_irq(shost->host_lock);
ndlp->nlp_flag |= NLP_PRLI_SND;
+
+   /* The vport counters are used for lpfc_scan_finished, but
+* the ndlp is used to track outstanding PRLIs for different
+* FC4 types.
+*/
+   vport->fc_prli_sent++;
+   ndlp->fc4_prli_sent++;
spin_unlock_irq(shost->host_lock);
if (lpfc_sli_issue_iocb(phba, LPFC_ELS_RING, elsiocb, 0) ==
IOCB_ERROR) {
@@ -2314,12 +2330,6 @@ lpfc_issue_els_prli(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp,
return 1;
}
 
-   /* The vport counters are used for lpfc_scan_finished, but
-* the ndlp is used to track outstanding PRLIs for different
-* FC4