hi Richard, In BC mode, Port 2 is connected to TestingUnit and Port 1 is connected to BC/GM unit. Observing below behavior on reboot of TestingUnit, Port 1 is going from SLAVE to UNCALIBRATED, which is not correct.
Below are the ptp4l and phc2sys command used. ptp4l -2 -A -i enp175s0f1 -i enp95s0f1 -f /etc/ptp4l_bc.conf phc2sys_slave -a -r -n 24 ptp4l: [325741.182] rms 6 max 15 freq +648 +/- 10 delay 373 +/- 1 phc2sya: [325741.509] CLOCK_REALTIME phc offset 19 s2 freq -81940 delay 1150 phc2sys: [325741.510] enp95s0f1 phc offset 4 s2 freq -2830 delay 3808 ptp4l: [325742.182] rms 3 max 7 freq +647 +/- 5 delay 375 +/- 0 phc2sys: [325742.510] CLOCK_REALTIME phc offset 2 s2 freq -81952 delay 1164 phc2sys: [325742.510] enp95s0f1 phc offset -2 s2 freq -2835 delay 3820 ptp4l: [325743.182] rms 5 max 11 freq +646 +/- 9 delay 374 +/- 1 phc2sys: [325743.510] CLOCK_REALTIME phc offset -9 s2 freq -81962 delay 1166 phc2sys: [325743.510] enp95s0f1 phc offset 0 s2 freq -2834 delay 3817 kernel: [324954.668590] i40e 0000:5f:00.1 enp95s0f1: NIC Link is Down ptp4l: [325744.218] timed out while polling for tx timestamp ptp4l: [325744.218] increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l: [325744.218] port 2: send sync failed ptp4l: [325744.218] port 2: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l: [325744.259] clockcheck: clock jumped backward or running slower than expected! ptp4l: [325744.259] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l: [325744.259] PS_SLAVE: port_e2e_transition ptp4l: [325744.259] port 2: link down ptp4l: [325744.259] port 2: NEC received link status notification DOWN ptp4l: [325744.259] selected best master clock 000580.fffe.07cc8a ptp4l: [325744.259] updating UTC offset to 37 ptp4l: [325744.259] rms 5 max 13 freq +643 +/- 6 delay 374 +/- 1 ptp4l: [325744.259] port 2: NEC received link status notification DOWN ptp4l: [325744.366] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l: [325744.366] PS_SLAVE: port_e2e_transition ptp4l: [325744.430] clockcheck: clock jumped forward or running faster than expected! ptp4l: [325744.430] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l: [325744.430] PS_SLAVE: port_e2e_transition phc2sys: [325744.510] port 40a6b7.fffe.0da261-2 changed state phc2sys: [325744.510] port 40a6b7.fffe.0da261-1 changed state phc2sys: message repeated 2 times: [ [325744.510] port 40a6b7.fffe.0da261-1 changed state] phc2sys: [325744.510] reconfiguring after port state change phc2sys: [325744.510] selecting enp95s0f1 for synchronization phc2sys: [325744.510] master clock not ready, waiting... ptp4l: [325744.678] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l: [325744.678] PS_SLAVE: port_e2e_transition ptp4l: [325745.182] rms 16 max 31 freq +646 +/- 44 delay 374 +/- 1 phc2sys: [325745.510] port 40a6b7.fffe.0da261-1 changed state phc2sys: [325745.510] reconfiguring after port state change phc2sys: [325745.510] selecting enp95s0f1 for synchronization phc2sys: [325745.510] selecting CLOCK_REALTIME for synchronization phc2sys: [325745.510] selecting enp175s0f1 as the master clock phc2sys: [325745.510] CLOCK_REALTIME phc offset -11 s2 freq -81967 delay 1149 phc2sys: [325745.510] clockcheck: clock jumped backward or running slower than expected! phc2sys: [325745.510] enp95s0f1 phc offset -1106433060 s0 freq -2834 delay 194 Please suggest. regards, Ramesh On Friday, January 7, 2022, 12:38:31 AM GMT+5:30, ramesh t <ramesh...@yahoo.com> wrote: hi Richard, >>Why does BC/GM port go to PS_FAULTY? Link down? Sorry, could be issues with my side of the changes. Tried looking into code to find out if there is any variable in port or clock struct which will tell if the interface is acting as client (slave) or server side of PTP. Please suggest. regards, Ramesh On Thursday, January 6, 2022, 08:03:06 AM GMT+5:30, Richard Cochran <richardcoch...@gmail.com> wrote: On Wed, Jan 05, 2022 at 07:34:07PM +0000, ramesh t wrote: > On resetting of the testing unit, observing ptp port state of the > interface connected to BC/GM going to PS_FAULTY temporarily though > it shouldn't be impacted due to reset of testing unit. Why does BC/GM port go to PS_FAULTY? Link down? Thanks, Richard _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
