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