[Linuxptp-devel] Missing state transition on PS_PASSIVE ports

[Jesuiter, Henry (ALC NetworX GmbH)]

Hi,

I did recently some more tests with multiple ports on out devices here. So I connected a two port device to a switch and started ptp4l that way:
> ptp4l -m -i eth0 -i eth1

Then the output on ptp4l is as following:
ptp4l[174593.550]: eth0: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[174593.553]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[174593.559]: driver rejected most general HWTSTAMP filter
ptp4l[174593.562]: eth1: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[174593.565]: port 2: INITIALIZING to LISTENING on INITIALIZE
ptp4l[174593.569]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[174593.578]: port 1: link up
ptp4l[174593.581]: port 2: link up
ptp4l[174593.586]: port 1: new foreign master 008063.fffe.b6706b-3
ptp4l[174593.589]: port 2: new foreign master 008063.fffe.b6706b-3
ptp4l[174595.572]: selected best master clock 00606e.fffe.7c230f
port 1: PS_SLAVE S1
ptp4l[174595.577]: running in a temporal vortex
ptp4l[174595.581]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
port 2: PS_PASSIVE P2
ptp4l[174595.584]: port 2: LISTENING to PASSIVE on RS_PASSIVE
ptp4l[174596.709]: port 1: minimum delay request interval 2^3
ptp4l[174597.572]: rms 951 max 967 freq -33 +/- 33 delay 3791 +/- 0
ptp4l[174597.575]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[174598.572]: rms 1353 max 1651 freq -1602 +/- 482

So this looks pretty nice. It recognizes that both ports are in the same network, connected to the same Grandmaster, so the second port goes into PASSIVE-state.
Now I disconnect the first (currently on SLAVE state) port, and expect that the second will get SLAVE state now, but that never happens:
ptp4l[176670.930]: port 1: link down
ptp4l[176670.931]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

So it recognizes the link down on port 1 and then just stays silent. After investigating into the code, I recognize, that probably there is a
handle_state_decision_event(c) on a link down event necessary (just to give the other ports the chance to recognize that link state change). Therfore I added one in
clock.c:clock_link_status(), right behind the FAULT_DETECTED event.

Now the ptp4l works as expected (takes the former PASSIVE Port into SLAVE mode on a link down and vice versa on a link up). But I'm unsure if I have done the fix right, since
I now get on each such transition a "running in a temporal vortex" warning. So I would be glad if someone here could check this and may be find a better fix for that behavior.

Best regards
Henry Jesuiter

[Richard Cochran]

On Thu, Jan 19, 2017 at 01:52:24PM +0000, Jesuiter, Henry (ALC NetworX GmbH) wrote:
> After investigating into the code, I recognize, that probably there
> is a handle_state_decision_event(c) on a link down event necessary
> (just to give the other ports the chance to recognize that link
> state change).

Yes, you are right.

> Therfore I added one in clock.c:clock_link_status(),
> right behind the FAULT_DETECTED event.

I just posted two patches to fix this issue. Can you please try them?

Thanks,
Richard

[Richard Cochran]

On Sun, Feb 05, 2017 at 06:37:13PM +0100, Richard Cochran wrote:
> I just posted two patches to fix this issue. Can you please try them?

Ping?

[Jesuiter, Henry (ALC NetworX GmbH)]

Sorry, I thought I already answered a week ago. These patches work fine for us, and I already integrated them in our current firmware for further real live tests.

Best regards
Henry

> Am 14.02.2017 um 07:44 schrieb Richard Cochran <***@gmail.com>:
>
>> On Sun, Feb 05, 2017 at 06:37:13PM +0100, Richard Cochran wrote:
>> I just posted two patches to fix this issue. Can you please try them?
>
> Ping?

[Richard Cochran]

On Tue, Feb 14, 2017 at 07:47:32AM +0000, Jesuiter, Henry (ALC NetworX GmbH) wrote:
> Sorry, I thought I already answered a week ago. These patches work fine for us, and I already integrated them in our current firmware for further real live tests.

That is good news, thanks!

Richard