I think we need more details before we can proceed. There's no indication of what the system time was at any given point, no log from what the link partner was doing, no statement about whether we were the clock master or slave, etc.
We would recommend swapping the configuration around and make the link partner the slave (there's a ptp4l option for doing this) for an initial test. We generally expect SYSTIM to increment, but there is nothing explicitly enforcing that. If something causes the slave clock to be too far ahead of the master, it's valid for ptp4l to hard reset our clock back to a closer time. If you need further help, it would be nice to see ftrace/debug statements to show what functions are getting called when this happens to confirm if we're getting the call to settime or not. Thanks Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation [email protected] (503) 712-4565 -----Original Message----- From: Julien Houles [mailto:[email protected]] Sent: Thursday, November 21, 2013 5:59 AM To: [email protected] Subject: [E1000-devel] Problem with SYSTIMH register readout Hello, When I use linuxptp with phc2sys or ptp4l, after an variable amount of time, I've got an offset explosion. I use an Intel 82574l chip. I investigated in the code and I found out that the problem comes from the readout of the SYSTIMH register (ine1000e_cyclecounter_read function). The value read in this register should always increase (or at least be equal to the last value read). But sometimes, the value read is smaller that the last one ! Here are three examples : ex 1 : er32(SYSTIMH) -> 0x00D3842C er32(SYSTIML)->0x0C600000 er32(SYSTIMH) -> 0x00D3842D er32(SYSTIML)->0x79600000 er32(SYSTIMH) -> 0x00D3842E er32(SYSTIML)->0x54200000 er32(SYSTIMH) -> 0x00D3842F er32(SYSTIML)->0x29E00000 er32(SYSTIMH) -> 0x00D38420 er32(SYSTIML)->0xFFA00000 Problem ! er32(SYSTIMH) -> 0x00D39326 er32(SYSTIML)->0x16C00000 er32(SYSTIMH) -> 0x00D39327 er32(SYSTIML)->0x5EE00000 er32(SYSTIMH) -> 0x00D39328 er32(SYSTIML)->0x3AE00000 er32(SYSTIMH) -> 0x00D39329 er32(SYSTIML)->0x10000000 er32(SYSTIMH) -> 0x00D39329 er32(SYSTIML)->0xE4800000 ex 2 : er32(SYSTIMH) -> 0x0799808E er32(SYSTIML)->0x07A00000 er32(SYSTIMH) -> 0x0799808D er32(SYSTIML)->0x7A400000 er32(SYSTIMH) -> 0x0799808C er32(SYSTIML)->0x55A00000 er32(SYSTIMH) -> 0x0799808F er32(SYSTIML)->0x2AC00000 er32(SYSTIMH) -> 0x07998089 er32(SYSTIML)->0xFFE00000 Problem ! er32(SYSTIMH) -> 0x07998F86 er32(SYSTIML)->0x1DE00000 er32(SYSTIMH) -> 0x07998F87 er32(SYSTIML)->0x6F600000 er32(SYSTIMH) -> 0x07998F88 er32(SYSTIML)->0x4DE00000 er32(SYSTIMH) -> 0x07998F89 er32(SYSTIML)->0x23A00000 er32(SYSTIMH) -> 0x07998F89 er32(SYSTIML)->0xF8C00000 ex 3 : er32(SYSTIMH) -> 0x0D8854EB er32(SYSTIML)->0x4A800000 er32(SYSTIMH) -> 0x0D8863E1 er32(SYSTIML)->0xD5E00000 er32(SYSTIMH) -> 0x0D8863E3 er32(SYSTIML)->0x23A00000 er32(SYSTIMH) -> 0x0D8863E1 er32(SYSTIML)->0xFFA00000 Problem ! er32(SYSTIMH) -> 0x0D8863E4 er32(SYSTIML)->0xD6000000 er32(SYSTIMH) -> 0x0D8863E5 er32(SYSTIML)->0xA9400000 er32(SYSTIMH) -> 0x0D8872DD er32(SYSTIML)->0x8F800000 Does someone know what could be the origin of that ? It seems that it only affects the 4 first bits of the register. The value read after the iteration when the problem occurs seems to be good (regarding to the value before the bad iteration) if I consider the average interval between two readings (five consecutive readings). So, the problem doesn't seem to come from the counter but the reading of it. By the way, I've got an other problem with phc2sys which could come from the driver or the ethernet chip : The offset between the phc and CLOCK_REALTIME can be good (less than a 100 ns) but a few days after, without any identified reason, it can be very bad (several microseconds) et be good again after a while. All that with the same hardware, software and similar environmental conditions ! Any idea ? Thank you, Julien. ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
