Thread: [Linuxptp-users] 3.1.1 -> 4.0 evolution?
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users
|
From: <jmf...@fe...> - 2023-07-10 09:47:32
|
I have a Compute Module4 single board computer controlled using linuxptp to a White Rabbit switch as grand master. The client is controlled by the server with linuxptp 3.1.1 ptp4l[8729.388]: selected /dev/ptp0 as PTP clock ptp4l[8729.432]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[8729.433]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[8729.724]: port 1: new foreign master e06ca6.fffe.000e54-5 ptp4l[8734.286]: selected best master clock 70b3d5.fffe.91ea78 ptp4l[8734.286]: updating UTC offset to 37 ptp4l[8734.286]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[8736.325]: master offset -1688969011985876110 s0 freq +0 path delay 1126 ptp4l[8737.385]: master offset -1688969011985878320 s1 freq -2093 path delay 1160 ptp4l[8738.508]: master offset -830824 s2 freq -832917 path delay 1160 ptp4l[8738.508]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[8739.704]: master offset 162030 s2 freq -89310 path delay 1160 ptp4l[8740.704]: master offset 258626 s2 freq +55895 path delay -7581 ptp4l[8741.649]: master offset 204019 s2 freq +78876 path delay -7581 ptp4l[8742.831]: master offset 99626 s2 freq +35688 path delay 1092 ... ptp4l[8769.831]: master offset -3 s2 freq -2082 path delay 643 ptp4l[8771.008]: master offset -9 s2 freq -2088 path delay 643 ptp4l[8772.026]: master offset -4 s2 freq -2086 path delay 643 and all goes well. I upgraded to linuxptp 4.0 in order to activate some of the newer options and now in the exact same context I am unable to lock with the messages ptp4l[9584.467]: selected /dev/ptp0 as PTP clock ptp4l[9584.512]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[9584.513]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[9584.513]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[9585.065]: port 1 (eth0): new foreign master e06ca6.fffe.000e54-5 ptp4l[9589.075]: selected best master clock 70b3d5.fffe.91ea78 ptp4l[9589.076]: port 1 (eth0): LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[9590.139]: timed out while polling for tx timestamp ptp4l[9590.139]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[9590.140]: port 1 (eth0): send delay request failed ptp4l[9590.140]: port 1 (eth0): UNCALIBRATED to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[9606.206]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE ptp4l[9606.817]: port 1 (eth0): new foreign master e06ca6.fffe.000e54-5 and this message repeats endlessly. Since I saw some recent updates I git cloned https://git.code.sf.net/p/linuxptp/code to assess the latest revisions but same result. There have been so many changes between 3.1.1 and 4.0 5 (diff tells me 10000 lines changed) that I do not know where to start for debugging. Any hint from these error messages ? Thank you -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 13:50:29
|
"don't you use automotive profile or 802.1 AS profiles?": I am not
(yet) familiar enough with linuxptp to comment. I did not change
anything to the settings, using the default configuration, whatever
that is.
I git bisected and the faulty commit is
2a2532d66121d0060b042c5bd6020a62153f1e0a is the first bad commit
commit 2a2532d66121d0060b042c5bd6020a62153f1e0a
Author: Yangbo Lu <yan...@nx...>
Date: Tue Mar 2 14:13:02 2021 +0800
Bump to IEEE 1588-2019 version
IEEE 1588-2019 specified new UInteger4 type minorVersionPTP field
in header, and minorVersionNumber data in portDS. It has the value
1 for IEEE 1588-2019, and has the value 0 for IEEE 1588-2008.
However missing minorVersionNumber definition in PORT_DATA_SET and
VERSION_NUMBER management TLVs was an oversight in this standard.
This patch is to bump to IEEE 1588-2019 version directly in message,
considering v2.1 and even future v2.x are all backward compatible.
For PORT_DATA_SET and VERSION_NUMBER TLVs, keep using only
versionNumber (major version) per current active IEEE 1588-2019
standard regardless.
Signed-off-by: Yangbo Lu <yan...@nx...>
msg.c | 5 +----
msg.h | 9 +++++++--
pmc.c | 7 ++++---
port.c | 2 +-
port_private.h | 2 +-
5 files changed, 14 insertions(+), 11 deletions(-)
Thank you, Jean-Michel
--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
Besancon, France
--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
Besancon, France
|
|
From: Miroslav L. <mli...@re...> - 2023-07-10 14:29:42
|
On Mon, Jul 10, 2023 at 03:49:52PM +0200, jmfriedt wrote: > I git bisected and the faulty commit is > Bump to IEEE 1588-2019 version I think that means the hardware cannot timestamp PTPv2.1 packets, only PTPv2.0 packets. You can change PTP_MINOR_VERSION in msg.h to 0 and see if that helps. -- Miroslav Lichvar |
|
From: Emmanuel F. <man...@gm...> - 2023-07-10 15:12:42
|
Le 10/07/2023 à 16:29, Miroslav Lichvar a écrit : > On Mon, Jul 10, 2023 at 03:49:52PM +0200, jmfriedt wrote: >> I git bisected and the faulty commit is >> Bump to IEEE 1588-2019 version > I think that means the hardware cannot timestamp PTPv2.1 packets, only > PTPv2.0 packets. Something fixable by the white rabbit projet as it is a full fpga implementation. Emmanuel. |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 15:37:44
|
> > I think that means the hardware cannot timestamp PTPv2.1 packets, > > only PTPv2.0 packets. > Something fixable by the white rabbit projet as it is a full fpga > implementation. Is it the WRS that needs to be updated? their web page says "Technically, the White Rabbit Network is a Bridged Local Area Network with VLANs (IEEE 802.1Q) that uses Ethernet (IEEE 802.3) to interconnect switches and nodes, and the Precision Time Protocol (PTP, IEEE 1588-2008) to synchronise them." and I understand that 1588-2008 is 2.0 whie 1588-2019 is 2.1, isn't it? so I am not clear if WRS is broadcasting PTP v2.1 packets. Is there a rationale for preventing out of the box linuxptp from working with both PTP 2.0 and 2.1 packets, since changing the constant in the header file seems to make the protocol operational again? Thanks -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: Richard C. <ric...@gm...> - 2023-07-11 02:58:22
|
On Mon, Jul 10, 2023 at 05:37:10PM +0200, jmfriedt wrote: > Is there a > rationale for preventing out of the box linuxptp from working with both > PTP 2.0 and 2.1 packets, since changing the constant in the header file > seems to make the protocol operational again? linuxptp works with both ptp v2.0 and v2.1 frames. Your hardware is rejecting v2.1 frames based on a field that is reserved in v2.0 Probably reserved fields should be ignored by PTP clients. That seems to be the expectation from the PTP standards. Thanks, Richard |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 14:21:35
|
I actually see a comment about this patch at https://github.com/richardcochran/linuxptp/commit/2a2532d66121d0060b042c5bd6020a62153f1e0a stating that "it seems that this commit breaks compatibility with some GMs, e.g., Microchip's TP4100. Tested with G.8275.2 profile. The reason being that this particular GMs do not reply to Delay_Req messages with minor version set to 1. Below find a fragment of the Delay_Req message from wireshark dump, which is not being replied to. As soon as I change the minorVersionPTP to 0, the appropriate Delay_Resp is being sent. All other messages work just fine (Signaling requests, etc.)." ... could be that the issue is with my use of a White Rabbit Switch acting as PTP server (https://ohwr.org/project/wr-switch-hw/wikis/home) rather than the Compute Module 4 slave. Thank you. -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: jmfriedt <jmf...@fe...> - 2023-07-10 14:25:13
|
... and I can confirm that the correction proposed at https://github.com/richardcochran/linuxptp/commit/2a2532d66121d0060b042c5bd6020a62153f1e0a namely setting the PTP_MINOR_VERSION from 1 to 0 in msg.h returns proper operation of the PTP client on the current git version of linuxptp. Thanks, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France |
|
From: Maciek M. <ma...@ma...> - 2023-07-10 21:08:10
|
On 7/10/2023 4:21 PM, jmfriedt wrote: > I actually see a comment about this patch at > https://github.com/richardcochran/linuxptp/commit/2a2532d66121d0060b042c5bd6020a62153f1e0a > > stating that > "it seems that this commit breaks compatibility with some GMs, e.g., > Microchip's TP4100. Tested with G.8275.2 profile. The reason being that > this particular GMs do not reply to Delay_Req messages with minor > version set to 1. Below find a fragment of the Delay_Req message from > wireshark dump, which is not being replied to. As soon as I change the > minorVersionPTP to 0, the appropriate Delay_Resp is being sent. All > other messages work just fine (Signaling requests, etc.)." > > ... > > could be that the issue is with my use of a White Rabbit Switch acting > as PTP server (https://ohwr.org/project/wr-switch-hw/wikis/home) rather > than the Compute Module 4 slave. CM4 can't timestamp TX packets that has the minor version set to a non-zero value. You can integrate this patch and set the required parameter to fix that problem: https://www.mail-archive.com/lin...@li.../msg06374.html Thanks, Maciek |
|
From: Miroslav L. <mli...@re...> - 2023-07-10 10:36:39
|
On Mon, Jul 10, 2023 at 11:47:00AM +0200, jmf...@fe... wrote: > I have a Compute Module4 single board computer controlled using > linuxptp to a White Rabbit switch as grand master. The client is > controlled by the server with linuxptp 3.1.1 > and all goes well. I upgraded to linuxptp 4.0 in order to activate some > of the newer options and now in the exact same context I am unable to > lock with the messages Is linuxptp the only thing you have upgraded? This is most likely a driver issue as the log message suggests. The CM4 HW timestamping support is quite problematic from what I read. If you are sure it's linuxptp, you can try git bisect start v4.0 v3.1 and follow with git bisect good or git bisect bad after testing each step. In about 7 steps you should have the offending commit. -- Miroslav Lichvar |
Thanks for helping keep SourceForge clean.
X