Re: [E1000-devel] Problem with SYSTIMH register readout

[Fujinaka, T. <tod...@in...>]

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
tod...@in...
(503) 712-4565


-----Original Message-----
From: Julien Houles [mailto:ju...@ya...] 
Sent: Thursday, November 21, 2013 5:59 AM
To: e10...@li...
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.