summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/lpfc/lpfc_disc.h
diff options
context:
space:
mode:
authorDick Kennedy <dick.kennedy@broadcom.com>2020-08-03 23:02:24 +0200
committerMartin K. Petersen <martin.petersen@oracle.com>2020-08-05 02:56:57 +0200
commit8ccd6926db7dd865dd6eabe3c25ae2696bffc07e (patch)
tree3e0c9176e344d06f39e97563f9f1351dd27ab17a /drivers/scsi/lpfc/lpfc_disc.h
parentscsi: lpfc: Fix no message shown for lpfc_hdw_queue out of range value (diff)
downloadlinux-8ccd6926db7dd865dd6eabe3c25ae2696bffc07e.tar.xz
linux-8ccd6926db7dd865dd6eabe3c25ae2696bffc07e.zip
scsi: lpfc: Fix RSCN timeout due to incorrect gidft counter
In configs with a large number of initiators in the same zone (>250), RSCN timeouts are seen when creating or deleting vports: lpfc 0000:07:00.1: 5:(0):0231 RSCN timeout Data: x0 x3 During RSCN processing driver issues GID_FT command to nameserver. A counter for number of simultaneous GID_FT commands is maintained (an unsigned value). The counter is incremented when the GID_FT is issued. If the GID_FT command fails for some reason the driver retries the GID_FT from the completion call back. But the counter was decremented before the retry was issued. When the second GID_FT completes, the callback again tries to decrement the counter, possibly wrapping to a very large non-zero value, which causes the RSCN cleanup code to not execute. Thus the RSCN timeout failure. Do not decrement the counter on a retry. Also add defensive checks to ensure the counter is not decremented if already zero. Link: https://lore.kernel.org/r/20200803210229.23063-4-jsmart2021@gmail.com Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'drivers/scsi/lpfc/lpfc_disc.h')
0 files changed, 0 insertions, 0 deletions