We're going to try to reproduce this locally. We may or may not have the same
motherboard so can you make sure you have the latest BIOS?
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
[email protected]
(503) 712-4565
From: Julien Houles [mailto:[email protected]]
Sent: Friday, November 22, 2013 1:24 PM
To: Fujinaka, Todd; [email protected]
Subject: Re: [E1000-devel] Problem with SYSTIMH register readout
Thank you for your answer.
In fact, I only use phc2sys in these examples (there is no call to settime
because ptp4l is not running and the phc clock is master). The slave clock is
CLOCK_REALTIME and the master clock is the phc clock. The phenomenon I talk
about occurs in only one readout among the five consecutive ones made at each
phc2sys interation. Each readout takes about 5 microseconds. If I look at the
phc time of the readout before the problematical readout and the one after, I
get a difference of 10 microseconds. There is only one read in the middle which
is false.
Unfortunately, I don't have the traces containing the system time anymore. I'll
send them to you when I'll make measurements, I'll add traces in the settime
function too.
Contrary to what I said, the problem doesn't seem to affect only SYSTIMH, I
noticed irregularities in the SYSTIML register too.
More details :
driver version : e1000e-2.5.4
boards : jetway NF9I-2550 (atom processor) + daughter board with four 82574l
kernel : 3.11.6-200
linuxptp version 1.3
Le Vendredi 22 novembre 2013 19h21, "Fujinaka, Todd"
<[email protected]<mailto:[email protected]>> a écrit :
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]<mailto:[email protected]>
(503) 712-4565
-----Original Message-----
From: Julien Houles [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, November 21, 2013 5:59 AM
To: [email protected]<mailto:[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.
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&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
