[Linuxptp-users] Fwd: PTP Timeouts on Kernel 3.14.3-7-desktop

[Mason W. <mas...@gm...>]

Hey guys,

I know this is a common question, and have researched the vast majority of
similar questions, but there still isn't much information for my
configuration. Also, I'm brand new to PTP as a concept, so please forgive
my ignorance. I'll start with a quick rundown of the current configuration,
outputs of relevant programs, etc.

*OpenSuse 13.1, Custom built kernel 3.14.3-7-desktop*

All required PTP/PPS/PHY options enabled

*Broadcom NetXtreme 5720*,

Tigon3 driver version 3.136

*LinuxPTP v. 1.4*

-Output of '*ethtool -T eth0*'

Time stamping parameters for eth0:
Capabilities:
hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
 software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
 software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
 hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off                   (HWTSTAMP_TX_OFF)
 on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
 none                  (HWTSTAMP_FILTER_NONE)
ptpv1-l4-event        (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
 ptpv2-l4-event        (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
ptpv2-l2-event        (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)


-Output of '*pmc -u -b 0 'GET CURRENT_DATA_SET'*'

sending: GET CURRENT_DATA_SET
90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT CURRENT_DATA_SET
 stepsRemoved     0
 offsetFromMaster 0.0
meanPathDelay    0.0

-Output of '*pmc -u -b 0 '**GET TIME_STATUS_NP**'*'

sending: GET TIME_STATUS_NP
90b11c.fffe.2e1b2d-0 seq 0 RESPONSE MANAGMENT TIME_STATUS_NP
 master_offset              0
ingress_time               0
 cumulativeScaledRateOffset +1.000000000
scaledLastGmPhaseChange    0
 gmTimeBaseIndicator        0
lastGmPhaseChange          0x0000'0000000000000000.0000
 gmPresent                  false
gmIdentity                 90b11c.fffe.2e1b2d


-Output of '*ptp4l -S -i eth0 -m -l7*'

ptp4l[3401.186]: PI servo: sync interval 1.000 kp 0.100 ki 0.001000
ptp4l[3401.186]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[3401.186]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[3407.916]: port 1: announce timeout
ptp4l[3407.916]: port 1: LISTENING to MASTER on
ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[3407.916]: selected best master clock 90b11c.fffe.2e1b2d
ptp4l[3407.916]: assuming the grand master role
ptp4l[3407.917]: port 1: master tx announce timeout
ptp4l[3407.918]: port 1: setting asCapable
ptp4l[3408.917]: port 1: master sync timeout
ptp4l[3409.917]: port 1: master sync timeout
ptp4l[3409.918]: port 1: master tx announce timeout
ptp4l[3410.917]: port 1: master sync timeout
ptp4l[3411.917]: port 1: master sync timeout
...


-Output of '*phc2sys -c eth0 -s /dev/ptp0 -w -m*'

phc2sys[5786.385]: phc offset    16 s0 freq      +0 delay   3968
phc2sys[5787.385]: phc offset    -8 s2 freq     -24 delay   3984
phc2sys[5788.386]: phc offset     0 s2 freq     -24 delay   4000
phc2sys[5789.386]: phc offset     8 s2 freq     -16 delay   3952
...


This will continue on indefinitely.
I have heard of systems being incapable of syncing due to time disparity,
but I have manually synced these clocks in an attempt to rule this
possibility out. I have also tried increasing all timeouts, delays, etc. I
have even gone so far as to use NTP as the source for PTP, just to see if
it would help. It didn't.

Regardless, from everything I've seen, this appears to be more of a
driver/kernel issue, though everything I've been able to identify has
checked out as the proper version, setting, etc. When I was having this
issue on kernel 3.11, I upgraded to 3.14 to no avail. I'm more than willing
and happy to send more information upon request and any information you
guys may have would be hugely helpful.

Many Thanks,
Mason