Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-28 Thread Richard Cochran 
On Wed, Mar 24, 2021 at 02:10:59PM +0100, Luigi 'Comio' Mantellini wrote:
> Yes, it works for me.

I am going to apply a fix.  May I add this tag into the git commit to
give you credit?

Reported-by: Luigi 'Comio' Mantellini 


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-24 Thread Luigi 'Comio' Mantellini 
Yes, it works for me.

thanks

luigi

Il giorno mar 23 mar 2021 alle ore 15:06 Richard Cochran <
richardcoch...@gmail.com> ha scritto:

> On Mon, Mar 15, 2021 at 12:38:58PM +0100, Luigi 'Comio' Mantellini wrote:
> > Inside port_synchronize() I noticed this:
> >
> > case SERVO_LOCKED:
> > port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0);
> > break;
> > case SERVO_LOCKED_STABLE:
> > message_interval_request(p, last_state, sync_interval);
> > break;
> >
> > Supposing to have the port X as SLAVE with "SERVO_LOCKED_STABLE" state,
> > after a while I disable the ingoing traffic (SYNC/ANNUNCE) to the port X,
> > switching to another port Y still keeping the SERVO_LOCKED_STABLE
> > condition. The check_offset_threshold(), called by sample_sample(),
> should
> > always return "1' (true) because the s->curr_offset_values == 0  (and it
> is
> > fixed to servo_num_offset_values only in SERV_UNLOCKED and SERVO_JUMP
> > conditions).
> >
> > In these conditions the SERVO_LOCKED will not happen and the
> > port_dispatach(p, EV_MASTER_CLOCK_SELECTED, 0) should never be called,
> > resulting in a forever "UNCALIBRATED" condition.
>
> Does changing port_synchronize() to this fix the issue for you?
>
> case SERVO_LOCKED_STABLE:
> message_interval_request(p, last_state, sync_interval);
> +   port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0);
> break;
>
> Thanks,
> Richard
>


-- 
*Luigi 'Comio' Mantellini*
My Professional Profile 

*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-23 Thread Richard Cochran 
On Mon, Mar 15, 2021 at 12:38:58PM +0100, Luigi 'Comio' Mantellini wrote:
> Inside port_synchronize() I noticed this:
> 
> case SERVO_LOCKED:
> port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0);
> break;
> case SERVO_LOCKED_STABLE:
> message_interval_request(p, last_state, sync_interval);
> break;
> 
> Supposing to have the port X as SLAVE with "SERVO_LOCKED_STABLE" state,
> after a while I disable the ingoing traffic (SYNC/ANNUNCE) to the port X,
> switching to another port Y still keeping the SERVO_LOCKED_STABLE
> condition. The check_offset_threshold(), called by sample_sample(), should
> always return "1' (true) because the s->curr_offset_values == 0  (and it is
> fixed to servo_num_offset_values only in SERV_UNLOCKED and SERVO_JUMP
> conditions).
> 
> In these conditions the SERVO_LOCKED will not happen and the
> port_dispatach(p, EV_MASTER_CLOCK_SELECTED, 0) should never be called,
> resulting in a forever "UNCALIBRATED" condition.

Does changing port_synchronize() to this fix the issue for you?

case SERVO_LOCKED_STABLE:
message_interval_request(p, last_state, sync_interval);
+   port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0);
break;

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-15 Thread Luigi 'Comio' Mantellini 
continuing:

In your opinion, can a servo->curr_offset_values =
servo->num_offset_values call inside clock_udpdate_slave() help?

ciao

luigi


Il giorno lun 15 mar 2021 alle ore 12:38 Luigi 'Comio' Mantellini
 ha scritto:
>
> Hi Richard,
>
> sorry again to continue this thread.
>
> Inside port_synchronize() I noticed this:
>
> case SERVO_LOCKED:
> port_dispatch(p, EV_MASTER_CLOCK_SELECTED, 0);
> break;
> case SERVO_LOCKED_STABLE:
> message_interval_request(p, last_state, sync_interval);
> break;
>
> Supposing to have the port X as SLAVE with "SERVO_LOCKED_STABLE" state, after 
> a while I disable the ingoing traffic (SYNC/ANNUNCE) to the port X, switching 
> to another port Y still keeping the SERVO_LOCKED_STABLE condition. The 
> check_offset_threshold(), called by sample_sample(), should always return "1' 
> (true) because the s->curr_offset_values == 0  (and it is fixed to 
> servo_num_offset_values only in SERV_UNLOCKED and SERVO_JUMP conditions).
>
> In these conditions the SERVO_LOCKED will not happen and the 
> port_dispatach(p, EV_MASTER_CLOCK_SELECTED, 0) should never be called, 
> resulting in a forever "UNCALIBRATED" condition.
>
> Are my deductions right?
>
> Thanks again for your support,
>
> luigi
>
>
> [global]
> ...
> servo_offset_threshold 100
> servo_num_offset_values 64
> ...
>
> Il giorno dom 14 mar 2021 alle ore 19:37 Luigi 'Comio' Mantellini 
>  ha scritto:
>>
>>
>>
>> Il giorno dom 14 mar 2021 alle ore 16:58 Richard Cochran 
>>  ha scritto:
>>>
>>> On Sun, Mar 14, 2021 at 10:30:31AM +0100, Luigi 'Comio' Mantellini wrote:
>>> > The failures are part of the test and after the HW restoring I'm pretty
>>> > sure that the protocol waltzer is running fine. I noticed that the ptp4l
>>> > shows master offset and delay summaries. In order to have offset and delay
>>> > values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I
>>> > right?
>>>
>>> Right.
>>>
>>
>>>
>>> > Another observation is that Killing and restarting again the ptp4l I reach
>>> > the SLAVE state without servo jump.
>>>
>>> Probably because the offset is below the threshold.
>>>
>> I knew, I remarked this only to say that the clock was attached.
>>
>>> > Just now I placed the servo_reset() inside handle_state_decision_event()
>>> > when we have a fresh new best master, after the clock_freq_est_reset()
>>> > method.
>>>
>>> Don't do that.  That spoils your synchronization for nothing.
>>>
>> I will better investigate.
>>
>> Thanks again
>>
>> luigi
>>
>>> Thanks,
>>> Richard
>>
>>
>>
>> --
>> Luigi 'Comio' Mantellini
>> My Professional Profile
>>
>> "UNIX is very simple, it just needs a genius to understand its simplicity." 
>> [cit.]
>>
>
>
> --
> Luigi 'Comio' Mantellini
> My Professional Profile
>
> "UNIX is very simple, it just needs a genius to understand its simplicity." 
> [cit.]
>


-- 
Luigi 'Comio' Mantellini
My Professional Profile

"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-14 Thread Luigi 'Comio' Mantellini 
Il giorno dom 14 mar 2021 alle ore 16:58 Richard Cochran <
richardcoch...@gmail.com> ha scritto:

> On Sun, Mar 14, 2021 at 10:30:31AM +0100, Luigi 'Comio' Mantellini wrote:
> > The failures are part of the test and after the HW restoring I'm pretty
> > sure that the protocol waltzer is running fine. I noticed that the ptp4l
> > shows master offset and delay summaries. In order to have offset and
> delay
> > values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I
> > right?
>
> Right.
>
>

> > Another observation is that Killing and restarting again the ptp4l I
> reach
> > the SLAVE state without servo jump.
>
> Probably because the offset is below the threshold.
>
> I knew, I remarked this only to say that the clock was attached.

> Just now I placed the servo_reset() inside handle_state_decision_event()
> > when we have a fresh new best master, after the clock_freq_est_reset()
> > method.
>
> Don't do that.  That spoils your synchronization for nothing.
>
> I will better investigate.

Thanks again

luigi

Thanks,
> Richard
>


-- 
*Luigi 'Comio' Mantellini*
My Professional Profile 

*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-14 Thread Richard Cochran 
On Sun, Mar 14, 2021 at 10:30:31AM +0100, Luigi 'Comio' Mantellini wrote:
> The failures are part of the test and after the HW restoring I'm pretty
> sure that the protocol waltzer is running fine. I noticed that the ptp4l
> shows master offset and delay summaries. In order to have offset and delay
> values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I
> right?

Right.

> Another observation is that Killing and restarting again the ptp4l I reach
> the SLAVE state without servo jump.

Probably because the offset is below the threshold.

> Just now I placed the servo_reset() inside handle_state_decision_event()
> when we have a fresh new best master, after the clock_freq_est_reset()
> method.

Don't do that.  That spoils your synchronization for nothing.

Thanks,
Richard


___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-14 Thread Luigi 'Comio' Mantellini 
HI Richard,

thanks for your answer.
The failures are part of the test and after the HW restoring I'm pretty
sure that the protocol waltzer is running fine. I noticed that the ptp4l
shows master offset and delay summaries. In order to have offset and delay
values, the Sync/DelayReq/DelayResp should be correctly exchanged, am I
right?
Another observation is that Killing and restarting again the ptp4l I reach
the SLAVE state without servo jump.

Just now I placed the servo_reset() inside handle_state_decision_event()
when we have a fresh new best master, after the clock_freq_est_reset()
method.

Thanks for your help,


luigi

luigi





Il giorno ven 12 mar 2021 alle ore 20:04 Richard Cochran <
richardcoch...@gmail.com> ha scritto:

> On Fri, Mar 12, 2021 at 10:03:39AM +0100, luigi.mantell...@gmail.com
> wrote:
>
> > The issue that I'm facing is the following:
> >  - After a fault, the port lost the SLAVE role (correct) passing to
> > MASTER state (cortect)
> >  - After this transition, and after restoring the working condition I'm
> > unable to move from UNCALIBRATED state to SLAVE state.
>
> The main reason for getting stuck in UNCALIBRATED is that the port is
> not able to complete a delay request/response exchange.
>
> > My suspect is a wrong servo condition and my idea is to add a
> > servo_reset() into clock_update_slave() function.
> >
> > Is it a good idea or a comlete non-sense?
>
> That doesn't make any sense to me.  You need to find the root cause
> and fix it.
>
> HTH,
> Richard
>
>

-- 
*Luigi 'Comio' Mantellini*
My Professional Profile 

*"UNIX is very simple, it just needs a genius to understand its
simplicity." [cit.]*
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-12 Thread Richard Cochran 
On Fri, Mar 12, 2021 at 10:03:39AM +0100, luigi.mantell...@gmail.com wrote:

> The issue that I'm facing is the following:
>  - After a fault, the port lost the SLAVE role (correct) passing to
> MASTER state (cortect)
>  - After this transition, and after restoring the working condition I'm
> unable to move from UNCALIBRATED state to SLAVE state.

The main reason for getting stuck in UNCALIBRATED is that the port is
not able to complete a delay request/response exchange.

> My suspect is a wrong servo condition and my idea is to add a
> servo_reset() into clock_update_slave() function.
> 
> Is it a good idea or a comlete non-sense?

That doesn't make any sense to me.  You need to find the root cause
and fix it.

HTH,
Richard



___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

[Linuxptp-devel] Unable to have UNCALIBRAT to SLAVE transition

2021-03-12 Thread luigi . mantellini 
Dear All,

I'm working on a ptp4l solution on a custom board. We are performing
test creating faults (like missing messages, hw fault...), then you
should consider the faults in the following log as part of the test.

The issue that I'm facing is the following:
 - After a fault, the port lost the SLAVE role (correct) passing to
MASTER state (cortect)
 - After this transition, and after restoring the working condition I'm
unable to move from UNCALIBRATED state to SLAVE state.

My suspect is a wrong servo condition and my idea is to add a
servo_reset() into clock_update_slave() function.

Is it a good idea or a comlete non-sense?

Thanks a lot for your opinion and any suggestion,

Luigi




LOG:
ptp4l[1167.787]: selected /dev/ptp0 as PTP clock
ptp4l[1167.800]: port 5: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1167.802]: port 28: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1167.820]: port 109: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1167.821]: port 111: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1167.822]: port 209: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1167.844]: port 213: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1167.845]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1167.846]: port 109: link down
ptp4l[1167.846]: port 109: LISTENING to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[1167.846]: port 111: link down
ptp4l[1167.846]: port 111: LISTENING to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[1167.847]: port 209: link down
ptp4l[1167.847]: port 209: LISTENING to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[1167.847]: selected local clock aabbcc.fffe.ddeeff as best master
ptp4l[1167.847]: port 109: assuming the grand master role
ptp4l[1167.847]: port 111: assuming the grand master role
ptp4l[1167.847]: port 209: assuming the grand master role
ptp4l[1167.858]: port 5: new foreign master 112233.fffe.445566-2
ptp4l[1167.927]: port 28: new foreign master 040506.fffe.070809-17
ptp4l[1168.108]: selected best master clock 112233.fffe.445566
ptp4l[1168.108]: running in a temporal vortex
ptp4l[1168.108]: updating UTC offset to 35
ptp4l[1168.108]: port 5: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1168.166]: pi_sample:79 sono qui
ptp4l[1168.177]: updating UTC offset to 35
ptp4l[1168.229]: pi_sample:102 sono qui
ptp4l[1168.232]: port 213: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1168.232]: updating UTC offset to 35
ptp4l[1168.239]: port 28: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1168.239]: updating UTC offset to 35
ptp4l[1168.291]: pi_sample:102 sono qui
ptp4l[1168.408]: port 5: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[1200.142]: rms   32 max   77 freq +3 +/-  17 delay   181 +/-
14
ptp4l[1232.116]: rms   30 max   74 freq +0 +/-   0 delay   182 +/-
14
ptp4l[1235.147]: port 111: link up
ptp4l[1235.147]: port 111: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1235.148]: port 109: link up
ptp4l[1235.148]: port 109: FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1235.584]: port 111: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1235.584]: updating UTC offset to 35
ptp4l[1235.600]: port 109: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1235.601]: updating UTC offset to 35
ptp4l[1236.648]: timed out while polling for tx timestamp
ptp4l[1236.648]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1236.648]: port 111: Echo frame too short
ptp4l[1237.649]: timed out while polling for tx timestamp
ptp4l[1237.649]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1237.649]: port 111: Echo frame too short
ptp4l[1238.649]: timed out while polling for tx timestamp
ptp4l[1238.649]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1238.650]: port 111: Echo frame too short
ptp4l[1239.651]: timed out while polling for tx timestamp
ptp4l[1239.651]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1239.651]: port 111: Echo frame too short
ptp4l[1240.652]: timed out while polling for tx timestamp
ptp4l[1240.652]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1240.652]: port 111: Echo frame too short
ptp4l[1241.653]: timed out while polling for tx timestamp
ptp4l[1241.653]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1241.653]: port 111: Echo frame too short
ptp4l[1242.654]: timed out while polling for tx timestamp
ptp4l[1242.654]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1242.654]: port 111: Echo frame too short
ptp4l[1243.655]: timed out while polling for tx timestamp
ptp4l[1243.655]: increasing tx_timestamp_timeout may correct this
issue, but it is likely caused by a driver bug
ptp4l[1243.655]: port