On Mon, 2018-08-20 at 17:47 -0700, Patel, Vedang wrote: > On Sat, 2018-08-18 at 00:03 -0400, Richard Cochran wrote: > > > > On Thu, Aug 16, 2018 at 10:42:10AM -0700, Vedang Patel wrote: > > > > > > > > > - In port_p2p_transition(), we are setting up the delay timer > > > when > > > BMCA is set > > > as ‘noop’. Usually it is initialized then the device > > > transitions > > > to > > > PS_LISTENING. But, we are skipping the LISTENING state. Another > > > alternative > > > is to transition to PS_LISTENING and then unconditionally > > > transfer to > > > PS_MASTER/PS_SLAVE. But, that seems more of an hack than what > > > is > > > currently > > > being done. Any other alternatives? > > Another idea: > > > > Can you have INITIALIZING -> LISTENING, and arrange for > > EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES to happen right away? > > > > Then your fsm does LISTENING -> SLAVE on the > > EV_ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES event. > > > > (haven't looked at arranging that timeout, just brainstorming...) > > > We can do something on the lines of the following (completely > untested) > snippet: > > diff --git a/port.c b/port.c > index f4a9fbb5a8d7..214a8329d27e 100644 > --- a/port.c > +++ b/port.c > @@ -1623,7 +1623,7 @@ int port_initialize(struct port *p) > p->fda.fd[FD_FIRST_TIMER + i] = fd[i]; > } > > - if (port_set_announce_tmo(p)) { > + if (set_tmo_log(p->fda.fd[FD_ANNOUNCE_TIMER], 1, -10)) { > goto no_tmo; > } > if (unicast_client_enabled(p) && unicast_client_set_tmo(p)) { > > This way, the timer will fire once (immediately after it's setup) > even > if inhibit_announce is set. > > But, there is going to be a likely effect on the normal working of > linuxptp. We can fix this by only doing this when BMCA == noop. > Again, > will have to actually test this to see what issues might pop up. > The above approach does work if I set the timer to expire in something like 2^-100 secs.
But, I had another concern with the code flow here. Following is the flow with relevant functions called to explain what is going on: bc_dispatch() { .... port_state_update() { ... port_initialize() { ... // to be replaced by set_tmo_log() port_set_announce_tmo(); ... } ... } port_p2p_transition() { port_clr_tmo(p->fda.fd[FD_ANNOUNCE_TIMER]); } } Here, port_clr_tmo() is happening almost immediately after port_set_announce_tmo() is setting up the timer. So, the timer never fires. This is also occuring when I try to run the lastest upstream code with gPTP profile. Seems like the timer is not going to fire in any scenario. Is there something I am missing here or this is a bug? Thanks, Vedang > Thanks, > Vedang > > > > Thanks, > > Richard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel