Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-66252

4.21 PTP Daemon Dual card T-BC after reboot takes a long time to lock

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Normal Normal
    • 4.21
    • 4.21
    • Networking / ptp
    • None
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • Critical
    • None
    • 2026-1-19: The likely reason is linuxptp version mismatch. ART builds install linuxptp-4.2, while in RHEL9.6 there should be linuxptp-4.4-1.el9_6.4
    • None
    • None
    • CNF RAN Sprint 281, CNF RAN Sprint 282, CNF RAN Sprint 283, CNF RAN Sprint 284
    • 4
    • Done
    • Known Issue
    • Hide
      * The PTP Daemon failed to lock after reboot due to an initial offset convergence issue, which caused long reboot times for the PTP Daemon and the clock to never lock. To work around this problem, wait for the fix in the next created 4.21 nightly and release. (link:https://issues.redhat.com/browse/OCPBUGS-66252[OCPBUGS-66252])

      When a user restarts the server running linuxptp-daemon, T-BC might fail to lock onto a valid time source within one hour. As a workaround, delete the linuxptp-daemon pod to allow it to restart and re-establish synchronization.
      Show
      * The PTP Daemon failed to lock after reboot due to an initial offset convergence issue, which caused long reboot times for the PTP Daemon and the clock to never lock. To work around this problem, wait for the fix in the next created 4.21 nightly and release. (link: https://issues.redhat.com/browse/OCPBUGS-66252 [ OCPBUGS-66252 ]) When a user restarts the server running linuxptp-daemon, T-BC might fail to lock onto a valid time source within one hour. As a workaround, delete the linuxptp-daemon pod to allow it to restart and re-establish synchronization.
    • None
    • None
    • None
    • None

      Description of problem:

      4.21 PTP Daemon Dual card T-BC after reboot takes a long time to lock

      Version-Release number of selected component (if applicable):

      4.20.0-202509080953    

      How reproducible:

          100%

      Steps to Reproduce:

          1.Reboot the node
    2.Shortly after booting the DPLL will perform a single offset correction, and stop.
    3.Clock never locks.

      Actual results:

      [kni@registry.kni-qe-79 dpopsuev]$ oc -n openshift-ptp logs ds/linuxptp-daemon linuxptp-daemon-container -f | grep "setting phase" | grep ens2
I1202 16:43:45.920159    9569 dpll.go:391] setting phase offset to 187614597 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:47.522094    9569 dpll.go:391] setting phase offset to 187614715 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:48.062729    9569 dpll.go:391] setting phase offset to 14 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:49.133005    9569 dpll.go:391] setting phase offset to 111 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:50.190744    9569 dpll.go:391] setting phase offset to 190 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:51.259971    9569 dpll.go:391] setting phase offset to 254 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:52.333338    9569 dpll.go:391] setting phase offset to 307 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:53.391045    9569 dpll.go:391] setting phase offset to 349 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:54.470272    9569 dpll.go:391] setting phase offset to 383 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:55.539213    9569 dpll.go:391] setting phase offset to 411 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:56.078879    9569 dpll.go:391] setting phase offset to 434 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:56.495266    9569 dpll.go:391] setting phase offset to 434 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:56.518148    9569 dpll.go:391] setting phase offset to 434 ns for clock id 5799633565433967420 iface ens2f0
I1202 16:43:56.648659    9569 dpll.go:391] setting phase offset to 0 ns for clock id 5799633565433967420 iface ens2f0

DPLL stops reporting

      Expected results:

          Steady stream of DPLL corrections until reaching the threshold.

      Additional info:

      By killing the pod the DPLL returns to function as intended, and the clock finally locks.

              vgrinber@redhat.com Vitaly Grinberg
              rh-ee-dpopsuev Daniel Popsuevich
              None
              None
              Daniel Popsuevich Daniel Popsuevich
              None
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: