On Mon, Apr 10, 2017 at 03:18:32PM +0000, Ian Thompson wrote: > I still see the issue with 3.18 but I haven't yet seen it on 4.9. > Unfortunately, we have a proprietary driver for a device on the pcie bus > which doesn't yet support 4.x kernels and it is this that generates (via an > application) most of the network traffic. > I might have to port all of the stmmac changes back to 3.18.
Maybe I wasn't clear enough in my answer, but the loss of one time stamp is unfortunate but understandable, and it normally should be tolerable. The resetting of the PHC time (the cause of the 37 second error) in the driver is just plain wrong, and you should fix that. > If I add 37 seconds to getnstimeofday then the effect of the "glitch" is less > pronounced. > Kernel 3.18 introduced timekeeping.c, with timekeeping_get_tai_offset(), > which I thought might give me the UTC offset but it returns 0 at the point I > call it. > Is there a call within the kernel to find the UTC offset? The offset has to be provided to the kernel by user space by calling adjtimex() with the ADJ_TAI mode set. 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-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
