diff options
| author | James Smart <jsmart2021@gmail.com> | 2020-07-15 00:14:12 +0300 |
|---|---|---|
| committer | Martin K. Petersen <martin.petersen@oracle.com> | 2020-07-15 23:10:00 +0300 |
| commit | 1f546823147693a054320d05d94f4515fb01748f (patch) | |
| tree | c762ae242b35e51162645ddfeff8f8f3bfe26978 /arch/nios2 | |
| parent | ba8ca097089b1372d36d5b789c231b6c2c797d31 (diff) | |
| download | linux-1f546823147693a054320d05d94f4515fb01748f.tar.xz | |
scsi: lpfc: NVMe remote port devloss_tmo from lldd
nvme-fc allows the driver to specify a default devloss_tmo value when
registering the remote port. The lpfc driver is currently not doing so,
although it is implementing a driver internal node loss value of 30s which
also is used on the SCSI FC remote port. As no devloss_tmo is set, the
nvme-fc transport defaults to 60s. So there are competing timers.
Additionally, due to the competing timers, it is possible the NVMe rport is
removed but the SCSI rport remains. It is possible that the SCSI FC rport,
which was registered for the NVMe port even if it doesn't utilize the SCSI
protocol, had been tuned to not match either the 60s (nvme-fc default) or
30s (lldd default), it gets out of whack. The lldd will defer to the SCSI
FC rport as long as the SCSI FC rport has not had its devloss_tmo expire.
Correct the situation by specifying a default devloss_tmo to the nvme-fc
transport when registering the rport. Take the value from the SCSI FC
rport if it exists, otherwise use the driver default.
Link: https://lore.kernel.org/r/20200714211412.11773-1-jsmart2021@gmail.com
Tested-by: Martin George <Martin.George@netapp.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'arch/nios2')
0 files changed, 0 insertions, 0 deletions