Thanks for pointing the fix/commit. Rebuilt based on master branch and that
fixed the issue of using IPv6 in multicast mode. For unicast mode, i can
now enter a proper IPv6 address in the UMT table.

Running in IPv6 multicast, came across the dreaded 'tx_timestamp_timeout'
when using hardware timestamping (software timestamping is ok). I tried to
increase the timeout value but without any success.  I assume that the NIC
card is having problems returning the timestamp value to the stack when PTP
is configured for IPv6 (IPv4 works ok for both sw & hw timestamping).
Copied the observed logs below.

MULTICAST IPv6 logs:
---------------------------------

Software timestamping (logs show everything is ok):
----------------------------------------------------------------------------

ptp4l -i enp25s0f0 -f /root/linuxptp/configs/default.cfg -6 -S -m -l 7

ptp4l[508710.413]: config item (null).uds_address is '/var/run/ptp4l'
ptp4l[508710.413]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[508710.413]: port 1: received link status notification
ptp4l[508710.413]: interface index 2 is up
ptp4l[508713.814]: port 1: setting asCapable
ptp4l[508717.426]: port 1: announce timeout
ptp4l[508717.426]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[508717.426]: selected local clock 000f53.fffe.572740 as best master
ptp4l[508717.426]: port 1: assuming the grand master role
ptp4l[508717.427]: port 1: master tx announce timeout
ptp4l[508718.426]: port 1: master sync timeout
ptp4l[508719.426]: port 1: master sync timeout
ptp4l[508719.427]: port 1: master tx announce timeout
ptp4l[508720.426]: port 1: master sync timeout
ptp4l[508721.426]: port 1: master sync timeout


Hardware timestamping (logs show the tx_timestamp_timeout error):
--------------------------------------------------------------------------------------------------

ptp4l -i enp25s0f0 -f /root/linuxptp/configs/default.cfg -6 -S -m -l 7

ptp4l[509643.285]: config item (null).uds_address is '/var/run/ptp4l'
ptp4l[509643.285]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[509643.286]: port 1: received link status notification
ptp4l[509643.286]: interface index 2 is up
ptp4l[509645.875]: port 1: setting asCapable
ptp4l[509650.186]: port 1: announce timeout
ptp4l[509650.186]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[509650.186]: selected local clock 000f53.fffe.572740 as best master
ptp4l[509650.186]: port 1: assuming the grand master role
ptp4l[509650.187]: port 1: master tx announce timeout
ptp4l[509651.186]: port 1: master sync timeout


*ptp4l[509656.191]: timed out while polling for tx
timestampptp4l[509656.191]: increasing tx_timestamp_timeout may correct
this issue, but it is likely caused by a driver bugptp4l[509656.191]: port
1: send sync failed*
ptp4l[509656.191]: port 1: MASTER to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[509656.191]: waiting 2^{4} seconds to clear fault on port 1


On Fri, Mar 27, 2020 at 6:21 AM Richard Cochran <richardcoch...@gmail.com>
wrote:

> On Thu, Mar 26, 2020 at 08:58:44PM -0700, Michel Ouellette wrote:
> > Line 35 is the UDPv6 configuration as shown above. Seems like str2addr
> > returns this error.  I'm assuming that I'm wrongly entering the IPv6
> > address. I've tried various IP addresses (link-local, unique local,
> global)
> > without any success.
>
> What version of ptp4l are you running?
>
> There is a fix for this issue, commit
> d88b4ff2298b9b6588e03fe94c2e7c0263fb4750.
>
> However, that commit is not contained in the most recently released
> 2.0 version.  I suggest building the master branch from source.
>
> Thanks,
> Richard
>
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Reply via email to