[prev in list] [next in list] [prev in thread] [next in thread]
List: e1000-devel
Subject: Re: [E1000-devel] Problem with SYSTIMH register readout
From: "Fujinaka, Todd" <todd.fujinaka () intel ! com>
Date: 2014-02-21 17:17:25
Message-ID: 9B4A1B1917080E46B64F07F2989DADD652939A8A () ORSMSX102 ! amr ! corp ! intel ! com
[Download RAW message or body]
We haven't been able to reproduce this, but there should be a fix in the latest \
driver and a spec update is forthcoming.
Thanks.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujinaka@intel.com
(503) 712-4565
-----Original Message-----
From: Fujinaka, Todd [mailto:todd.fujinaka@intel.com]
Sent: Thursday, December 05, 2013 11:01 AM
To: Julien Houles; e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Problem with SYSTIMH register readout
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
todd.fujinaka@intel.com
(503) 712-4565
From: Julien Houles [mailto:jugean@yahoo.fr]
Sent: Friday, November 22, 2013 1:24 PM
To: Fujinaka, Todd; e1000-devel@lists.sourceforge.net
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" \
<todd.fujinaka@intel.com<mailto:todd.fujinaka@intel.com>> 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
todd.fujinaka@intel.com<mailto:todd.fujinaka@intel.com>
(503) 712-4565
-----Original Message-----
From: Julien Houles [mailto:jugean@yahoo.fr<mailto:jugean@yahoo.fr>]
Sent: Thursday, November 21, 2013 5:59 AM
To: e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
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.
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit \
http://communities.intel.com/community/wired
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic