Thanks for the pointers - the mentioned patch does work beautifully for our use case.
Do you have any plans for a release that would include it? Thanks, Alex On Thu, Jan 14, 2021 at 5:34 AM Richard Cochran <richardcoch...@gmail.com> wrote: > On Thu, Jan 14, 2021 at 10:48:20AM +0100, Miroslav Lichvar wrote: > > Then I'd say the right fix should be about phc2sys avoiding calling > > those functions unless it is synchronizing the system clock. It is not > > supposed to touch the source clock. There was a fix in that direction > > recently. > > That was the following commit. Alex, please see whether it fixes the > issue for you. > > Thanks, > Richard > --- > commit 194dc845103c783e5f9bd6f9f025eedd6a5f3d36 > Author: Miroslav Lichvar <mlich...@redhat.com> > Date: Thu Aug 6 16:16:10 2020 +0200 > > phc2sys: Postpone adding of servo to clock. > > Instead of unconditionally creating a servo for each clock in their > initialization, add the servo later on the first update of the clock, > when it is known the clock needs to be synchronized. > > This fixes an issue with phc2sys disrupting the system clock when > it is synchronized by another process and should be used by phc2sys > only > as a source. Creating a servo for the system clock caused a reset of > its > frequency and status. >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
