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 _______________________________________________ devel mailing list [email protected] https://lists.open-fcoe.org/mailman/listinfo/devel
