Yes, it's because when fc_remote_port_add gets called it only revives ports in a blocked state if the wwnames match was well as the id. So the old directory server port stays in a blocked state until the dev_loss_tmo fires and deletes it.
I'll look at it, but I think it's more an a problem in scsi_transport_fc with creating rports before all the names are known. James Smart and I talked briefly about changing that, so we could get rid of the temporary ID and name holders during discovery as well. - Chris Joe Eykholt wrote: > I sometimes see multiple rports to the directory server. I think > this may happen after a host reset because the old rport gets blocked > and when we restart discovery we create a new one. Note that the > number in the /sys file name gets incremented each time and can get > large. > > I think we should look up the directory server without regard to the > port name or host name, and change them to whatever we have from the > PLOGI response. > > Here's a portion of fcc output: > > host5 Remote Ports: > Path Port Name Port ID State Roles > 5:0-1 2100002037329f5a 1300dc Online FCP Target > 5:0-2 2100002037323844 1300e0 Online FCP Target > 5:0-28 250d000dec6da040 fffffc Blocked Directory Server > 5:0-29 250d000dec6da040 fffffc Online Directory Server > ... > > Joe > _______________________________________________ > devel mailing list > [email protected] > http://www.open-fcoe.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
