The following list identifies all PTP alarms generated by sfptpd. Active alarms are present in the topology file and in state files, all within the following
directory:
/var/lib/sfptpdFrom version 3.3.0.1007 onwards, sfptpd logs
changes to alarm states in the sfptpd message log.
no-sync-pkts
PTP Sync packet(s) are not being received. From a tcpdump pcap
file, identify if packets are actually being received at the PTP interface.
Sync/FollowUp pairs have sequential sequence ID values. If some or all Sync packets are missing, the user should check these are being generated by the upstream master clock.
no-follow-ups
PTP FollowUp packet(s) are not being received. From a tcpdump
pcap file, identify if packets are actually being received at the PTP interface.
When the upstream master is using 2-step synchronization it sends a FollowUp packet for every Sync packet sent. Sync/FollowUp pairs have sequential sequence ID values. If some or all FollowUp packets are missing, the user should check these are being generated by the upstream master clock.
The counters in the stats-<clock id> files identify the number of FollowUp messages received. There should be the same number of FollowUps as there are Sync messages received.
no-delay-resps
The slave sends periodic Delay-Request messages to the upstream master clock. The master clock should respond to each with a Delay-Response message having the same sequence ID value as the request.
From a tcpdump pcap file, identify if packets reported as
missing are actually being received at the PTP interface.
If some or all Delay-Request packets are missing, the user should check the master clock configuration or consult the master clock vendor.
If Delay-Response messages, reported as missing, are actually being received on the PTP interface, check that the requestingSourcePortidentity and requestingSourcePortID values in the response message match the clockIdentity and sourcePortID values in the corresponding request message. It these values do not match, the response messages are ignored.
no-pdelay-resps
When using the peer-to-peer delay method this alarm identifies that PDelay-Response messages are not being received for all PDelay-Request messages sent by the slave server.
no-pdelay-resp-follow-ups
When using the peer-to-peer delay method this alarm identifies that
PDelay-Response-FollowUp messages are not being received by the
sfptpd slave.
no-tx-timestamps
Identifies that sfptpd is not able to timestamp outgoing
packets.
no-rx-timestamps
Identifies that sfptpd is not able to recover adapter timestamps
for received PTP packets.
no-interface
In a bond, there are no slave interfaces available.
clock-ctrl-failure
An instance or clock servo is unable to control a clock and attempts to control it result in errors.
pps-no-signal
sfptpd is unable to detect any incoming PPS signal. Check that
the upstream clock is generating the PPS signal. Check that PPS cable is connected
to the PPS INPUT on the Solarflare adapter.
pps-seq-num-error
sfptpd is receiving PPS pulses, but reports missing or
unexpected PPS sequence numbers. Ensure the driver and firmware being by the adapter
are up to date. If the issue persists, run the sfreport script and
return the HTML output along with the sfptpd stats log output to
support-nic@amd.com.
pps-bad-signal
sfptpd has detected an invalid PPS period. The
measured PPS period is too long to be a pulse because it exceeds 1 second.
no-time-of-day
sfptpd is not detecting a time-of-day signal. This is normally
seen when running sfptpd in one of the supported NTP/PPS modes.
Time-of-day is the time supplied by the NTP server.