>Babu, regarding the migration event that you are seeing, are you sure that it >is from the migration transition that does not occur? Possibly, the >problematic transition is the second one, which occurs after specifying a new >alternate path and rearming APM? > > I am sure that it is when the cable is disconnected for the first time, and not by the second transition. I will reload the alternate path with LAP messages only when the port's state changes to IB_PORT_ACTIVE. If the remote passive node's port has disconnected then I am expecting for the notice event saying that remote port transitioned to IB_PORT_ACTIVE. In gen1 I was using tsIbSetInServiceNoticeHandler() for this. In OFED we don't have these interfaces yet.
>It seems more likely to me that the first transition does occur, since you >receive a MIG event on both sides, and since the alt path data is loaded by >you during the initial bringup of the RC QP pair(either at init->rtr, or at >rtr->rts). If you are receiving the MIGRATED event, the qp is already in the >migrated state. > >However, after the first migration occurs, you need to do the following: >1. send a LAP packet to the remote node, containing the new alt path info. >2. load NEW alt path information (ib_modify_qp, rts->rts), including remote >LID received in LAP packet. >3. Rearm path migration (ib_modify_qp, rts->rts) > >Are you certain that the above 3 steps have taken place? > > Yes I am doing all these steps only when I get the event IB_PORT_ACTIVE or InServiceNotice event is received for the remote port. >Note that 1. and 2. above are a separate phase from 3., since the IB Spec >allows changing the alternate path while the QP is still armed, not just when >it has migrated. > >- Jack > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
