diff options
author | James Smart <jsmart2021@gmail.com> | 2017-12-08 17:18:08 -0800 |
---|---|---|
committer | Martin K. Petersen <martin.petersen@oracle.com> | 2017-12-20 21:11:47 -0500 |
commit | e06351a002214d152142906a546006e3446d1ef7 (patch) | |
tree | 5a4997e94271bd37bbc7070ff5b1ded552c38f31 /arch/arm/mm | |
parent | 9de416ac67b54d666327ba927a190f4b7259f4a0 (diff) | |
download | linux-stable-e06351a002214d152142906a546006e3446d1ef7.tar.gz linux-stable-e06351a002214d152142906a546006e3446d1ef7.tar.bz2 linux-stable-e06351a002214d152142906a546006e3446d1ef7.zip |
scsi: lpfc: Fix issues connecting with nvme initiator
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 <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'arch/arm/mm')
0 files changed, 0 insertions, 0 deletions