On Fri, Jan 21, 2011 at 5:25 PM, Robert Love <[email protected]>wrote:
> On Fri, 2011-01-21 at 16:46 -0800, Robert Love wrote: > > On Thu, 2010-10-28 at 17:15 -0700, Joe Eykholt wrote: > > > > > > On 10/28/10 11:48 AM, Kiran Patil wrote: > > > > From: Kiran Patil <[email protected]> > > > > > > > > Problem: VN2VN connection setup between initiator and target is > failing because both > > > > side (initiator and target) failed to respond to FLOGI. > > > > > > > > Reason: If RPORT is in state INIT and receives FLOGI request, > > > > function fc_rport.c:fc_rport_recv_flogi_req rejects > > > > FIP (FLOGI) request, hence VN2VN (point to point) connection > setup fails. > > > > > > > > Fix: It is normal and expected the state of RPORT (which are > created after discovery) > > > > to be INIT. Allow RPORT state machine to continue and accept > FLOGI requests > > > > instead of rejecting it. > > > > > > > > Technical Details: N/A > > > > > > > > Signed-off-by: Kiran Patil <[email protected]> > > > > --- > > > > > > > > drivers/scsi/libfc/fc_rport.c | 7 ++++++- > > > > 1 files changed, 6 insertions(+), 1 deletions(-) > > > > > > > > diff --git a/drivers/scsi/libfc/fc_rport.c > b/drivers/scsi/libfc/fc_rport.c > > > > index ed84b59..b04f939 100644 > > > > --- a/drivers/scsi/libfc/fc_rport.c > > > > +++ b/drivers/scsi/libfc/fc_rport.c > > > > @@ -787,12 +787,17 @@ static void fc_rport_recv_flogi_req(struct > fc_lport *lport, > > > > fc_rport_state(rdata)); > > > > > > > > switch (rdata->rp_state) { > > > > - case RPORT_ST_INIT: > > > > case RPORT_ST_DELETE: > > > > mutex_unlock(&rdata->rp_mutex); > > > > rjt_data.reason = ELS_RJT_FIP; > > > > rjt_data.explan = ELS_EXPL_NOT_NEIGHBOR; > > > > goto reject; > > > > + /* > > > > + * Moved RPORT_ST_INIT case here, to allow RPORT state machine to > > > > + * continue instead of rejecting the FIP if state of RPORT is INIT > > > > + * (which is normal) > > > > + */ > > > > + case RPORT_ST_INIT: > > > > > > I think it was correct before. If FIP is really ready, the rport > should > > > be in FLOGI state. Otherwise we might accept a FLOGI before FIP is > ready. > > > FIP calls rport_login() once it has received a beacon from the rport. > > > Until then, it isn't supposed to accept FLOGIs. > > > > > > > Joe, is there a reason that we wait for a beacon before sending a FLOGI > > to an rport? > > > > From fcoe_ctlr_vn_disc: > > > > if (frport->time) > > lport->tt.rport_login(rdata); > > > > Where frport->time is only incremented from 0 when we receive a beacon. > > > > From what I can find in the various documents/presentations after we > > claim the LUID we should wait ANNOUNCE_WAIT, so that we can collect > > claim responses) and then go to operational mode. To me, operational > > mode means that we can send a FLOGI. > > > > We create new fcoe_rports when we either receive claim replies or claim > > notifications. So, there's nothing else to wait for. We've claimed our > > LUID and we know the other rports exist, because they notified us of > > their existence. Why wait to login? > > > > I think I understand now. The beacon is an indication that the entity is > in operational mode and can be logged into; claim is not enough. > > Thanks, //Rob > Yes, I think that's right. It means the other end has proceeded far enough to be sending beacons and we can receive them. In particular I think the LLD may need to register its MAC address after the claim. I don't remember all the cases, but I think there was some concern that even if someone sent out a claim notification there could still be a conflict or a non-reachability issue. Joe _______________________________________________ devel mailing list [email protected] https://lists.open-fcoe.org/mailman/listinfo/devel
