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

Reply via email to