When receiving a PRLO it just means that the operating parameters have changed, it does _not_ mean that the port doesn't want to communicate with us. So instead of implicitly logging out we should be issueing a PRLI to figure out the new operating parameters. We can always recover once PRLI fails. Signed-off-by: Hannes Reinecke <hare@xxxxxxxx> --- drivers/scsi/libfc/fc_rport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c index 7fb6685..0ea0d4f 100644 --- a/drivers/scsi/libfc/fc_rport.c +++ b/drivers/scsi/libfc/fc_rport.c @@ -2034,7 +2034,7 @@ static void fc_rport_recv_prlo_req(struct fc_rport_priv *rdata, spp->spp_type_ext = rspp->spp_type_ext; spp->spp_flags = FC_SPP_RESP_ACK; - fc_rport_enter_delete(rdata, RPORT_EV_LOGO); + fc_rport_enter_prli(rdata); fc_fill_reply_hdr(fp, rx_fp, FC_RCTL_ELS_REP, 0); lport->tt.frame_send(lport, fp); -- 1.8.5.6 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
