On 01/24/2018 11:45 PM, James Smart wrote: > In a test that is doing large numbers of cable swaps on the target, > the nvme controllers wouldn't reconnect. > > During the cable swaps, the targets n_port_id would change. This > information was passed to the nvme-fc transport, in the new remoteport > registration. However, the nvme-fc transport didn't update the n_port_id > value in the remoteport struct when it reused an existing structure. > Later, when a new association was attempted on the remoteport, the > driver's NVME LS routine would use the stale n_port_id from the remoteport > struct to address the LS. As the device is no longer at that address, > the LS would go into never never land. > > Separately, the nvme-fc transport will be corrected to update the > n_port_id value on a re-registration. > > However, for now, there's no reason to use the transports values. > The private pointer points to the drivers node structure and the > node structure is up to date. Therefore, revise the LS routine to > use the drivers data structures for the LS. Augmented the debug > message for better debugging in the future. > > Also removed a duplicate if check that seems to have slipped in. > > Signed-off-by: Dick Kennedy <dick.kennedy@xxxxxxxxxxxx> > Signed-off-by: James Smart <james.smart@xxxxxxxxxxxx> > --- > drivers/scsi/lpfc/lpfc_nvme.c | 24 +++++++++++++----------- > 1 file changed, 13 insertions(+), 11 deletions(-) > Reviewed-by: Hannes Reinecke <hare@xxxxxxxx> Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +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)
