On Mon, Jan 15, 2018 at 04:59:13PM +0000, Loy, Matthias wrote: > we are syncronizing devices using ptp. The absolute time is not > relevant but all devices should be close to each other. > > Furthermore devices are connected and disconnected at any time and most > of the time there is no real grandmaster clock with higher priority. > > As a result, a new connected device may became ptp grandmaster and all > others adjust there time. > > If the new grandmaster is waaaay back in time, phc2sys refuses to set > the clock. I found the reason in the kernel and created a patch you can > find attached. > > What do you think about that? For my understanding it would be okay to > step the realtime clock backwards even below 0 because the value > holding the sceonds is a signed int variable.
I doubt your patch would find acceptance on the lkml. The check is a sanity check that makes sense for most use cases. You can work around this issue by setting some arbitrary date, like 1984, as part of your boot scripts. Thanks, Richard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
