> -----Original Message----- > From: Richard Cochran [mailto:richardcoch...@gmail.com] > Sent: Wednesday, August 08, 2018 7:32 PM > To: Keller, Jacob E <jacob.e.kel...@intel.com> > Cc: Jord Pool <jord.p...@outlook.com>; Cliff Spradlin via Linuxptp-users > <linuxptp-users@lists.sourceforge.net>; Chris Caudle <ch...@chriscaudle.org>; > Cliff Spradlin <csprad...@waymo.com> > Subject: Re: PXE Boot PTP Issues > > On Wed, Aug 08, 2018 at 05:34:02PM +0000, Keller, Jacob E wrote: > > Yea, I double checked the e1000e source, it looks like e1000e_systim_reset > > is > using the kernel time to reset the system timer. I suspect this is what > causes the > 36second alignment issue, after it tries to reset to recover... > > Yes, that explains the offset. > > > I don't know what triggers the reset... Maybe the driver should cache the > current time and restore it after? This does mean that any time lost during > the > reset will be lost, but that's inevitible with a hardware reset that clears > the > register... > > But in any case, it is a driver/HW issue, and it isn't something we > can solve on this list. > > Sorry, > Richard
Hi Richard, A bit unrelated, and I guess technically this should be discussed on the netdev mailing list.... But I was looking at the e1000e driver code, and it looks like it is doing a timecounter_init during reset. Would it make more sense to have some "timecounter_reset()" function, which uses the current nsec value and just resets the internal cycles? Then, as long as the timecounter was updated as close as possible to before the hardware reset, we'd only lose a few cycles, instead of getting the UTC/TAI conversion. Thanks, Jake ------------------------------------------------------------------------------ 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
