linuxptp-users Mailing List for linuxptp (Page 140)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Richard C. <ric...@gm...> - 2013-11-06 19:26:43
|
On Tue, Nov 05, 2013 at 04:26:21PM -0500, Rich Schmidt wrote: > > Things seem to work fine for a while, then I get a single large phase > offset detected by ptp4l. The -L freq limit was an attempt to control > these offsets, but did not help. How long before the first jump appears after a cold start? I have a 82547 PCIe card, and I will see if I can reproduce this effect. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-06 19:23:40
|
A couple of things to try, below... On Tue, Nov 05, 2013 at 04:26:21PM -0500, Rich Schmidt wrote: > Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI firmware-version: 1.9-0 > Debian with kernel 3.12.0-rc 1. This driver also supports software time stamping. So please try 'ptp4l -S' and no phc2sys. (In this case, ptp4l will adjust the Linux system clock.) If that works without the jumps, then the issue is most likely a driver or kernel issue. 2. You gave the e1000e version as 2.5.4, but in the kernel source drivers/net/ethernet/intel/e1000e/netdev.c I see version 2.3.2, so you must using the SF drivers. You might also try the driver from the kernel. 3. Are you using your own kernel.org kernel build from source? If so, that is good, but you should know that v3.12 has been released, and it is better to drop the -rc kernel. Thanks, Richard |
|
From: Rich S. <sch...@gm...> - 2013-11-06 17:18:23
|
*1. Last night ptp4 and phc2sys got into a loop of sorts:* Nov 6 01:34:47 pluto ptp4l: [381207.181] master offset -3312879535876 s2 freq -599999999 path delay -332476904 Nov 6 01:34:47 pluto phc2sys: [381207.216] phc offset 3313004697655 s2 freq +500000 delay 4863 Nov 6 01:34:49 pluto ptp4l: [381209.180] master offset -3311679354743 s2 freq -599999999 path delay -332476904 Nov 6 01:34:51 pluto ptp4l: [381211.178] master offset -3310479396557 s2 freq -599999999 path delay -332476904 Nov 6 01:34:51 pluto phc2sys: [381211.216] phc offset 3310601232712 s2 freq +500000 delay 4713 Nov 6 01:34:52 pluto ptp4l: [381211.853] negative path delay -192163390 Nov 6 01:34:52 pluto ptp4l: [381211.853] path_delay = (t2 - t3) + (t4 - t1) Nov 6 01:34:52 pluto ptp4l: [381211.853] t2 - t3 = -1024845438 Nov 6 01:34:52 pluto ptp4l: [381211.853] t4 - t1 = +640518657 Nov 6 01:34:52 pluto ptp4l: [381211.853] c1 0 Nov 6 01:34:52 pluto ptp4l: [381211.853] c2 0 Nov 6 01:34:52 pluto ptp4l: [381211.854] c3 0 Nov 6 01:34:53 pluto ptp4l: [381213.178] master offset -3309260051493 s2 freq -599999999 path delay -351664636 Nov 6 01:34:55 pluto ptp4l: [381215.177] master offset -3308059890747 s2 freq -599999999 path delay -351664636 Nov 6 01:35:11 pluto phc2sys: [381231.217] phc offset -67053297050824 s2 freq -500000 delay 4718 Nov 6 01:35:13 pluto ptp4l: [381233.183] master offset 67052031445161 s2 freq +599999999 path delay -97064991 ... during the night a number of jumps are detected by phc2sys (lines deleted)... Nov 6 05:14:00 pluto ptp4l: [394359.794] master offset 66882744861346 s2 freq +599999999 path delay -32382521 Nov 6 05:14:00 pluto phc2sys: [394359.859] phc offset -66882716164068 s2 freq -500000 delay 4717 Nov 6 05:14:02 pluto ptp4l: [394361.796] master offset 66881544843520 s2 freq +599999999 path delay -32382521 Nov 6 05:14:04 pluto ptp4l: [394363.797] master offset 66880344836655 s2 freq +599999999 path delay -32382521 Nov 6 05:14:04 pluto phc2sys: [394363.859] phc offset -66880315280640 s2 freq -500000 delay 4717 Nov 6 05:14:06 pluto ptp4l: [394365.798] master offset 66879099025472 s2 freq +599999999 path delay 13411172 Nov 6 05:14:08 pluto ptp4l: [394367.799] master offset 66877899010215 s2 freq +599999999 path delay 13411172 Nov 6 05:14:08 pluto phc2sys: [394367.859] phc offset -66877914394903 s2 freq -500000 delay 4727 Nov 6 05:14:10 pluto ptp4l: [394369.800] master offset 66876589756605 s2 freq +599999999 path delay 122641620 ...lines deleted... Nov 6 06:40:17 pluto ptp4l: [399536.604] master offset 63777989946575 s2 freq +599999999 path delay 283612433 Nov 6 06:40:19 pluto ptp4l: [399538.605] master offset 63776799780537 s2 freq +599999999 path delay 273757038 Nov 6 06:40:20 pluto phc2sys: [399540.146] phc offset -134142308172546 s2 freq -500000 delay 4717 Nov 6 06:40:21 pluto ptp4l: [399540.605] clockcheck: clock jumped forward or running faster than expected! Nov 6 06:40:21 pluto ptp4l: [399540.606] master offset 134144343946703 s0 freq +0 path delay 273757038 ... lines deleted... Nov 6 06:41:11 pluto ptp4l: [399591.102] negative path delay -66539 Nov 6 06:41:11 pluto ptp4l: [399591.102] path_delay = (t2 - t3) + (t4 - t1) Nov 6 06:41:11 pluto ptp4l: [399591.102] t2 - t3 = -484054584 Nov 6 06:41:11 pluto ptp4l: [399591.102] t4 - t1 = +483921505 Nov 6 06:41:11 pluto ptp4l: [399591.102] c1 0 Nov 6 06:41:11 pluto ptp4l: [399591.102] c2 0 Nov 6 06:41:11 pluto ptp4l: [399591.102] c3 0 Nov 6 06:41:12 pluto phc2sys: [399592.148] phc offset 2561210209 s2 freq +500000 delay 4713 Nov 6 06:41:13 pluto ptp4l: [399592.586] master offset 31642 s2 freq -72514 path delay 1932384 Nov 6 06:41:15 pluto ptp4l: [399594.585] master offset 155956 s2 freq -5611 path delay 2021789 Nov 6 06:41:16 pluto phc2sys: [399596.149] phc offset 2558838385 s2 freq +500000 delay 4712 Nov 6 06:41:17 pluto ptp4l: [399596.584] master offset 235565 s2 freq +57587 path delay 2021789 Nov 6 06:41:19 pluto ptp4l: [399598.583] master offset 189166 s2 freq +69722 path delay 2021789 ... *2. This morning ptp4 reports that clock time is 17.1 hours offset:* Nov 6 16:14:27 pluto ptp4l: [433991.680] master offset 61591498021410 s2 freq +599999999 path delay 383379265 Nov 6 16:14:29 pluto ptp4l: [433993.680] master offset 61590330241412 s2 freq +599999999 path delay 351150078 Nov 6 16:14:31 pluto ptp4l: [433995.680] master offset 61589133175281 s2 freq +599999999 path delay 348198056 Nov 6 16:14:33 pluto ptp4l: [433997.680] master offset 61587955406085 s2 freq +599999999 path delay 325950874 Nov 6 16:14:35 pluto ptp4l: [433999.680] master offset 61586755389932 s2 freq +599999999 path delay 325950874 Nov 6 16:14:37 pluto ptp4l: [434001.680] master offset 61585555381755 s2 freq +599999999 path delay 325950874 Nov 6 16:14:39 pluto ptp4l: [434003.681] master offset 61584332985592 s2 freq +599999999 path delay 348330452 Nov 6 16:14:41 pluto ptp4l: [434005.681] master offset 61583132971605 s2 freq +599999999 path delay 348330452 Nov 6 16:14:43 pluto ptp4l: [434007.681] master offset 61581932953300 s2 freq +599999999 path delay 348330452 Nov 6 16:14:45 pluto ptp4l: [434009.681] master offset 61580761060120 s2 freq +599999999 path delay 320211807 Nov 6 16:14:47 pluto ptp4l: [434011.681] master offset 61579561037423 s2 freq +599999999 path delay 320211807 Nov 6 16:14:49 pluto ptp4l: [434013.681] master offset 61578361028013 s2 freq +599999999 path delay 320211807 Nov 6 16:14:51 pluto ptp4l: [434015.681] master offset 61577183886161 s2 freq +599999999 path delay 29733548217.1 Actually it is (24 - 17.1) = 6h 53m behind: root@pluto:/tmp# testptp -g -d /dev/ptp1;date clock time: 1383816008.279232658 or Thu Nov 7 09:20:08 2013 Wed Nov 6 16:12:23 UTC 2013 *3. I set the correct time on the clock using ntpdate, and sync the PHC:root@pluto:/tmp# testptp -s -d /dev/ptp1set time okayroot@pluto:/tmp# testptp -g -d /dev/ptp1;dateclock time: 1383754501.245498330 or Wed Nov 6 16:15:01 2013Wed Nov 6 16:14:59 UTC 20134. ptp4l responds:* Nov 6 16:14:53 pluto ptp4l: [434017.681] master offset 61575983886672 s2 freq +599999999 path delay 297335482 Nov 6 16:14:55 pluto ptp4l: [434019.680] clockcheck: clock jumped backward or running slower than expected! Nov 6 16:14:55 pluto ptp4l: [434019.681] master offset -360063735 s0 freq +0 path delay 277518883 Nov 6 16:14:55 pluto ptp4l: [434019.681] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT Nov 6 16:14:57 pluto ptp4l: [434021.681] master offset -1560079696 s1 freq -599999999 path delay 277518883 Nov 6 16:14:59 pluto ptp4l: [434023.681] master offset 1198240376 s2 freq -879811 path delay 277518883 Nov 6 16:14:59 pluto ptp4l: [434023.681] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED Nov 6 16:15:01 pluto ptp4l: [434025.681] master offset 1201022077 s2 freq +180247096 path delay 277518883 Nov 6 16:15:03 pluto ptp4l: [434027.682] master offset 840864807 s2 freq +180321772 path delay 277518883 Nov 6 16:15:05 pluto ptp4l: [434029.682] master offset 480264272 s2 freq +126151226 path delay 277518883 Nov 6 16:15:07 pluto ptp4l: [434031.682] master offset 277988358 s2 freq +97052910 path delay 227454323 ...lines deleted... *# testptp -g -d /dev/ptp1;dateclock time: 1383754506.107142710 or Wed Nov 6 16:15:06 2013Wed Nov 6 16:15:05 UTC 2013# testptp -s -d /dev/ptp1set time okay# testptp -g -d /dev/ptp1;dateclock time: 1383754512.793827793 or Wed Nov 6 16:15:12 2013Wed Nov 6 16:15:12 UTC 2013# testptp -g -d /dev/ptp1;dateclock time: 1383754517.291075454 or Wed Nov 6 16:15:17 2013Wed Nov 6 16:15:17 UTC 2013*... Now I'm running ptp4l without phc2sys and will watch for any clock jumps today. On Wed, Nov 6, 2013 at 5:22 AM, Richard Cochran <ric...@gm...>wrote: > On Tue, Nov 05, 2013 at 04:26:21PM -0500, Rich Schmidt wrote: > > This is Rich Schmidt, linuxptp newbie. > > > > I am testing linuxptp on this system at the US Naval Observatory: > > Supermicro SYS-5015A-EHF-D525 (Atom) > > Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI firmware-version: > > 1.9-0 > > Debian with kernel 3.12.0-rc > > > > Running: > > Sync PHC to USNO Master Clock via Zyfer Gsync PTP GrandMaster: > > ptp4l -i eth1 -l 7 -s -p /dev/ptp1 > > > > Sync CLOCK_REALTIME to PHC: > > phc2sys -s /dev/ptp1 -L 100000000 -l 7 -R 0.25 -O 0 > > Can you try this again running ptp4l alone without phc2sys? > > If no funny offsets appear, this would indicate a certain kind of > driver problem, when both programs access the PHC. > > Thanks, > Richard > |
|
From: Richard C. <ric...@gm...> - 2013-11-06 10:22:32
|
On Tue, Nov 05, 2013 at 04:26:21PM -0500, Rich Schmidt wrote: > This is Rich Schmidt, linuxptp newbie. > > I am testing linuxptp on this system at the US Naval Observatory: > Supermicro SYS-5015A-EHF-D525 (Atom) > Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI firmware-version: > 1.9-0 > Debian with kernel 3.12.0-rc > > Running: > Sync PHC to USNO Master Clock via Zyfer Gsync PTP GrandMaster: > ptp4l -i eth1 -l 7 -s -p /dev/ptp1 > > Sync CLOCK_REALTIME to PHC: > phc2sys -s /dev/ptp1 -L 100000000 -l 7 -R 0.25 -O 0 Can you try this again running ptp4l alone without phc2sys? If no funny offsets appear, this would indicate a certain kind of driver problem, when both programs access the PHC. Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2013-11-06 10:13:55
|
On Tue, Nov 05, 2013 at 06:50:33PM -0500, Rich Schmidt wrote: > > My real question is can the clock_sanity check in linuxptp filter out crazy > big offsets that are say, greater than 3 s.d. from the mean? The check code does not filter out any samples. It only prints a warning and resets the servo. Thanks, Richard |
|
From: Miroslav L. <mli...@re...> - 2013-11-06 08:03:25
|
On Wed, Nov 06, 2013 at 12:13:57AM +0000, Keller, Jacob E wrote: > On Tue, 2013-11-05 at 18:50 -0500, Rich Schmidt wrote: > > Well, it is a jump of 19.55 hours in the last example that you note. > > We would notice that on the GrandMaster. These jumps happen four or > > 5 times per hour at random times. I am using a newer e1000e driver > > than the sourceforge driver (oh, oh). From the Intel site, > > 2.5.4-NAPI. I will try the sourceforge version next. > If the Grand Master is having these jumps, there's no way to filter > them.. that is the remote clock simply being jumped, and we can't > "filter" it, because what we do is reset the servo, and then relock on > the new target. It looks like a "you should filter this out" but in > reality the values you see are the time offset from the master, not the > current time. It's not the Grand Master jumping as the sanity check includes the corrections made by the local servo. If there is a warning it means something else is touching the synchronized clock or the clock/driver is broken. -- Miroslav Lichvar |
|
From: Keller, J. E <jac...@in...> - 2013-11-06 00:14:07
|
On Tue, 2013-11-05 at 18:50 -0500, Rich Schmidt wrote: > Thanks, Jake, > Well, it is a jump of 19.55 hours in the last example that you note. > We would notice that on the GrandMaster. These jumps happen four or > 5 times per hour at random times. I am using a newer e1000e driver > than the sourceforge driver (oh, oh). From the Intel site, > 2.5.4-NAPI. I will try the sourceforge version next. > > # testptp -c -d /dev/ptp1 > capabilities: > 599999999 maximum frequency adjustment (ppb) > 0 programmable alarms > 0 external time stamp channels > 0 programmable periodic signals > 0 pulse per second > > # testptp -g -d /dev/ptp1;date > clock time: 1383695290.199580197 or Tue Nov 5 23:48:10 2013 > Tue Nov 5 23:48:10 UTC 2013 > # ethtool -T eth1 > > Time stamping parameters for eth1: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 1 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC) > ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ) > > > My real question is can the clock_sanity check in linuxptp filter out > crazy big offsets that are say, greater than 3 s.d. from the mean? > > If the Grand Master is having these jumps, there's no way to filter them.. that is the remote clock simply being jumped, and we can't "filter" it, because what we do is reset the servo, and then relock on the new target. It looks like a "you should filter this out" but in reality the values you see are the time offset from the master, not the current time. That is, the ptp4l log output doesn't really do a good job of showing the current time on the clock, so it isn't obvious whether you are actually going forward or not. Does this make sense? If the Grand Master is *not* jumping and you are just seeing your local clock reset, that's a bug. Thanks, Jake > > On Tue, Nov 5, 2013 at 5:02 PM, Keller, Jacob E > <jac...@in...> wrote: > Hi Rich, > > On Tue, 2013-11-05 at 16:26 -0500, Rich Schmidt wrote: > > This is Rich Schmidt, linuxptp newbie. > > > > I am testing linuxptp on this system at the US Naval > Observatory: > > > > Supermicro SYS-5015A-EHF-D525 (Atom) > > > > Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI > > firmware-version: 1.9-0 > > Debian with kernel 3.12.0-rc > > > > > > Running: > > Sync PHC to USNO Master Clock via Zyfer Gsync PTP > GrandMaster: > > ptp4l -i eth1 -l 7 -s -p /dev/ptp1 > > > > Sync CLOCK_REALTIME to PHC: > > phc2sys -s /dev/ptp1 -L 100000000 -l 7 -R 0.25 -O 0 > > > > > > > > Things seem to work fine for a while, then I get a single > large phase > > offset detected by ptp4l. The -L freq limit was an attempt > to > > control these offsets, but did not help. > > > > > > Are these large phase jumps filtered out by ptp4l? It seems > not, > > because phc2sys sees them. Or is this some unreliability in > the Intel > > > > 82547L NICs? Is the PHC read failing? Thank you for your > thoughts. > > > > > > > > Here is a sample. The clock is not being steered by NTP or > any other > > program. > > > > > Are you sure? I can't think of anything else controlling the > clock, but > something is obviously controlling it as seen in the logs. > > > Nov 5 18:12:27 pluto ptp4l: [354666.428] master offset > 57 s2 > > freq +34356 path delay 6086 > > Nov 5 18:12:29 pluto ptp4l: [354668.428] master offset > -139 s2 > > freq +34266 path delay 6092 > > Nov 5 18:12:30 pluto phc2sys: [354669.993] phc offset > 4529 s2 > > freq +8805 delay 4715 > > Nov 5 18:12:31 pluto ptp4l: [354670.428] master offset > -32 s2 > > freq +34299 path delay 6092 > > Nov 5 18:12:33 pluto ptp4l: [354672.428] master offset > 20 s2 > > freq +34320 path delay 6092 > > Nov 5 18:12:34 pluto phc2sys: [354673.993] phc offset > 470 s2 > > freq +7931 delay 4705 > > Nov 5 18:12:35 pluto ptp4l: [354674.428] master offset > 54 s2 > > freq +34340 path delay 6095 > > Nov 5 18:12:37 pluto ptp4l: [354676.428] master offset > -15 s2 > > freq +34314 path delay 6095 > > Nov 5 18:12:38 pluto phc2sys: [354677.993] phc offset > -6992 s2 > > freq +3968 delay 4870 > > Nov 5 18:12:39 pluto ptp4l: [354678.428] master offset > -19 s2 > > freq +34309 path delay 6096 > > Nov 5 18:12:41 pluto ptp4l: [354680.429] master offset > 55 s2 > > freq +34344 path delay 6096 > > Nov 5 18:12:42 pluto phc2sys: [354681.994] phc offset > 11326 s2 > > freq +11945 delay 4715 > > Nov 5 18:12:43 pluto ptp4l: [354682.428] master offset > -90 s2 > > freq +34279 path delay 6096 > > Nov 5 18:12:45 pluto ptp4l: [354684.429] master offset > -49 s2 > > freq +34286 path delay 6096 > > Nov 5 18:12:46 pluto phc2sys: [354685.994] phc offset > -70368744182111 > > s2 freq -500000 delay 4715 > > Nov 5 18:12:47 pluto ptp4l: [354686.428] clockcheck: clock > jumped > > forward or running faster than expected! > > > This should pretty much be caused by something managing the > clock > causing a jump. Possibly your grand master on the other end is > doing > something? I can't think of any other reason this would > occur... Do you > have the ability to monitor the grand master state and see if > it was > jumped? > > Since you're doing hardware timestamping, nothing would > control the > clock on the device except ptp4l.. so even NTP running > shouldn't cause > an issue (other than phc2sys trying to interfere with it... > but that > wouldn't be in the ptp4l logs) > > My gut says the driver is resetting the clock to 0 somehow on > accident... > > What about the driver, what version are you using? The debian > in-kernel > e1000e driver? Could you try this against the one available on > sourceforge.net from our e1000 project? This could > theoretically be > caused by a bug in the driver.. > > Since I am not part of the e1000e team, I don't know the > specifics for > that driver... maybe they have some logic that is resetting > the register > values incorrectly.. > > You could also check the output of the clock directly by using > the ptp > test program provided in the Documentation folder in the > kernel source.. > you might be able to kill ptp4l in time and check to see what > the value > of the ptp device clock says it is at that point... > > Could you show us some of the dmesg output as well? Maybe that > might > indicate some other issue occurring.. I'm not really sure.. > > Regards, > Jake > > > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users |
|
From: Rich S. <sch...@gm...> - 2013-11-05 23:50:42
|
Thanks, Jake,
Well, it is a jump of 19.55 hours in the last example that you note. We
would notice that on the GrandMaster. These jumps happen four or 5 times
per hour at random times. I am using a newer e1000e driver than the
sourceforge driver (oh, oh). From the Intel site, 2.5.4-NAPI. I will try
the sourceforge version next.
# testptp -c -d /dev/ptp1
capabilities:
599999999 maximum frequency adjustment (ppb)
0 programmable alarms
0 external time stamp channels
0 programmable periodic signals
0 pulse per second
# testptp -g -d /dev/ptp1;date
clock time: 1383695290.199580197 or Tue Nov 5 23:48:10 2013
Tue Nov 5 23:48:10 UTC 2013
# ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)
ptpv2-sync (HWTSTAMP_FILTER_PTP_V2_SYNC)
ptpv2-delay-req (HWTSTAMP_FILTER_PTP_V2_DELAY_REQ)
My real question is can the clock_sanity check in linuxptp filter out crazy
big offsets that are say, greater than 3 s.d. from the mean?
On Tue, Nov 5, 2013 at 5:02 PM, Keller, Jacob E <jac...@in...>wrote:
> Hi Rich,
>
> On Tue, 2013-11-05 at 16:26 -0500, Rich Schmidt wrote:
> > This is Rich Schmidt, linuxptp newbie.
> >
> > I am testing linuxptp on this system at the US Naval Observatory:
> >
> > Supermicro SYS-5015A-EHF-D525 (Atom)
> >
> > Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI
> > firmware-version: 1.9-0
> > Debian with kernel 3.12.0-rc
> >
> >
> > Running:
> > Sync PHC to USNO Master Clock via Zyfer Gsync PTP GrandMaster:
> > ptp4l -i eth1 -l 7 -s -p /dev/ptp1
> >
> > Sync CLOCK_REALTIME to PHC:
> > phc2sys -s /dev/ptp1 -L 100000000 -l 7 -R 0.25 -O 0
> >
> >
> >
> > Things seem to work fine for a while, then I get a single large phase
> > offset detected by ptp4l. The -L freq limit was an attempt to
> > control these offsets, but did not help.
> >
> >
> > Are these large phase jumps filtered out by ptp4l? It seems not,
> > because phc2sys sees them. Or is this some unreliability in the Intel
> >
> > 82547L NICs? Is the PHC read failing? Thank you for your thoughts.
> >
> >
> >
> > Here is a sample. The clock is not being steered by NTP or any other
> > program.
> >
>
> Are you sure? I can't think of anything else controlling the clock, but
> something is obviously controlling it as seen in the logs.
>
> > Nov 5 18:12:27 pluto ptp4l: [354666.428] master offset 57 s2
> > freq +34356 path delay 6086
> > Nov 5 18:12:29 pluto ptp4l: [354668.428] master offset -139 s2
> > freq +34266 path delay 6092
> > Nov 5 18:12:30 pluto phc2sys: [354669.993] phc offset 4529 s2
> > freq +8805 delay 4715
> > Nov 5 18:12:31 pluto ptp4l: [354670.428] master offset -32 s2
> > freq +34299 path delay 6092
> > Nov 5 18:12:33 pluto ptp4l: [354672.428] master offset 20 s2
> > freq +34320 path delay 6092
> > Nov 5 18:12:34 pluto phc2sys: [354673.993] phc offset 470 s2
> > freq +7931 delay 4705
> > Nov 5 18:12:35 pluto ptp4l: [354674.428] master offset 54 s2
> > freq +34340 path delay 6095
> > Nov 5 18:12:37 pluto ptp4l: [354676.428] master offset -15 s2
> > freq +34314 path delay 6095
> > Nov 5 18:12:38 pluto phc2sys: [354677.993] phc offset -6992 s2
> > freq +3968 delay 4870
> > Nov 5 18:12:39 pluto ptp4l: [354678.428] master offset -19 s2
> > freq +34309 path delay 6096
> > Nov 5 18:12:41 pluto ptp4l: [354680.429] master offset 55 s2
> > freq +34344 path delay 6096
> > Nov 5 18:12:42 pluto phc2sys: [354681.994] phc offset 11326 s2
> > freq +11945 delay 4715
> > Nov 5 18:12:43 pluto ptp4l: [354682.428] master offset -90 s2
> > freq +34279 path delay 6096
> > Nov 5 18:12:45 pluto ptp4l: [354684.429] master offset -49 s2
> > freq +34286 path delay 6096
> > Nov 5 18:12:46 pluto phc2sys: [354685.994] phc offset -70368744182111
> > s2 freq -500000 delay 4715
> > Nov 5 18:12:47 pluto ptp4l: [354686.428] clockcheck: clock jumped
> > forward or running faster than expected!
>
> This should pretty much be caused by something managing the clock
> causing a jump. Possibly your grand master on the other end is doing
> something? I can't think of any other reason this would occur... Do you
> have the ability to monitor the grand master state and see if it was
> jumped?
>
> Since you're doing hardware timestamping, nothing would control the
> clock on the device except ptp4l.. so even NTP running shouldn't cause
> an issue (other than phc2sys trying to interfere with it... but that
> wouldn't be in the ptp4l logs)
>
> My gut says the driver is resetting the clock to 0 somehow on
> accident...
>
> What about the driver, what version are you using? The debian in-kernel
> e1000e driver? Could you try this against the one available on
> sourceforge.net from our e1000 project? This could theoretically be
> caused by a bug in the driver..
>
> Since I am not part of the e1000e team, I don't know the specifics for
> that driver... maybe they have some logic that is resetting the register
> values incorrectly..
>
> You could also check the output of the clock directly by using the ptp
> test program provided in the Documentation folder in the kernel source..
> you might be able to kill ptp4l in time and check to see what the value
> of the ptp device clock says it is at that point...
>
> Could you show us some of the dmesg output as well? Maybe that might
> indicate some other issue occurring.. I'm not really sure..
>
> Regards,
> Jake
>
>
>
|
|
From: Keller, J. E <jac...@in...> - 2013-11-05 22:02:32
|
Hi Rich, On Tue, 2013-11-05 at 16:26 -0500, Rich Schmidt wrote: > This is Rich Schmidt, linuxptp newbie. > > I am testing linuxptp on this system at the US Naval Observatory: > > Supermicro SYS-5015A-EHF-D525 (Atom) > > Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI > firmware-version: 1.9-0 > Debian with kernel 3.12.0-rc > > > Running: > Sync PHC to USNO Master Clock via Zyfer Gsync PTP GrandMaster: > ptp4l -i eth1 -l 7 -s -p /dev/ptp1 > > Sync CLOCK_REALTIME to PHC: > phc2sys -s /dev/ptp1 -L 100000000 -l 7 -R 0.25 -O 0 > > > > Things seem to work fine for a while, then I get a single large phase > offset detected by ptp4l. The -L freq limit was an attempt to > control these offsets, but did not help. > > > Are these large phase jumps filtered out by ptp4l? It seems not, > because phc2sys sees them. Or is this some unreliability in the Intel > > 82547L NICs? Is the PHC read failing? Thank you for your thoughts. > > > > Here is a sample. The clock is not being steered by NTP or any other > program. > Are you sure? I can't think of anything else controlling the clock, but something is obviously controlling it as seen in the logs. > Nov 5 18:12:27 pluto ptp4l: [354666.428] master offset 57 s2 > freq +34356 path delay 6086 > Nov 5 18:12:29 pluto ptp4l: [354668.428] master offset -139 s2 > freq +34266 path delay 6092 > Nov 5 18:12:30 pluto phc2sys: [354669.993] phc offset 4529 s2 > freq +8805 delay 4715 > Nov 5 18:12:31 pluto ptp4l: [354670.428] master offset -32 s2 > freq +34299 path delay 6092 > Nov 5 18:12:33 pluto ptp4l: [354672.428] master offset 20 s2 > freq +34320 path delay 6092 > Nov 5 18:12:34 pluto phc2sys: [354673.993] phc offset 470 s2 > freq +7931 delay 4705 > Nov 5 18:12:35 pluto ptp4l: [354674.428] master offset 54 s2 > freq +34340 path delay 6095 > Nov 5 18:12:37 pluto ptp4l: [354676.428] master offset -15 s2 > freq +34314 path delay 6095 > Nov 5 18:12:38 pluto phc2sys: [354677.993] phc offset -6992 s2 > freq +3968 delay 4870 > Nov 5 18:12:39 pluto ptp4l: [354678.428] master offset -19 s2 > freq +34309 path delay 6096 > Nov 5 18:12:41 pluto ptp4l: [354680.429] master offset 55 s2 > freq +34344 path delay 6096 > Nov 5 18:12:42 pluto phc2sys: [354681.994] phc offset 11326 s2 > freq +11945 delay 4715 > Nov 5 18:12:43 pluto ptp4l: [354682.428] master offset -90 s2 > freq +34279 path delay 6096 > Nov 5 18:12:45 pluto ptp4l: [354684.429] master offset -49 s2 > freq +34286 path delay 6096 > Nov 5 18:12:46 pluto phc2sys: [354685.994] phc offset -70368744182111 > s2 freq -500000 delay 4715 > Nov 5 18:12:47 pluto ptp4l: [354686.428] clockcheck: clock jumped > forward or running faster than expected! This should pretty much be caused by something managing the clock causing a jump. Possibly your grand master on the other end is doing something? I can't think of any other reason this would occur... Do you have the ability to monitor the grand master state and see if it was jumped? Since you're doing hardware timestamping, nothing would control the clock on the device except ptp4l.. so even NTP running shouldn't cause an issue (other than phc2sys trying to interfere with it... but that wouldn't be in the ptp4l logs) My gut says the driver is resetting the clock to 0 somehow on accident... What about the driver, what version are you using? The debian in-kernel e1000e driver? Could you try this against the one available on sourceforge.net from our e1000 project? This could theoretically be caused by a bug in the driver.. Since I am not part of the e1000e team, I don't know the specifics for that driver... maybe they have some logic that is resetting the register values incorrectly.. You could also check the output of the clock directly by using the ptp test program provided in the Documentation folder in the kernel source.. you might be able to kill ptp4l in time and check to see what the value of the ptp device clock says it is at that point... Could you show us some of the dmesg output as well? Maybe that might indicate some other issue occurring.. I'm not really sure.. Regards, Jake |
|
From: Rich S. <sch...@gm...> - 2013-11-05 21:26:29
|
This is Rich Schmidt, linuxptp newbie. I am testing linuxptp on this system at the US Naval Observatory: Supermicro SYS-5015A-EHF-D525 (Atom) Intel 82547L NICs driver: e1000e version: 2.5.4-NAPI firmware-version: 1.9-0 Debian with kernel 3.12.0-rc Running: Sync PHC to USNO Master Clock via Zyfer Gsync PTP GrandMaster: ptp4l -i eth1 -l 7 -s -p /dev/ptp1 Sync CLOCK_REALTIME to PHC: phc2sys -s /dev/ptp1 -L 100000000 -l 7 -R 0.25 -O 0 Things seem to work fine for a while, then I get a single large phase offset detected by ptp4l. The -L freq limit was an attempt to control these offsets, but did not help. Are these large phase jumps filtered out by ptp4l? It seems not, because phc2sys sees them. Or is this some unreliability in the Intel 82547L NICs? Is the PHC read failing? Thank you for your thoughts. Here is a sample. The clock is not being steered by NTP or any other program. Nov 5 18:12:27 pluto ptp4l: [354666.428] master offset 57 s2 freq +34356 path delay 6086 Nov 5 18:12:29 pluto ptp4l: [354668.428] master offset -139 s2 freq +34266 path delay 6092 Nov 5 18:12:30 pluto phc2sys: [354669.993] phc offset 4529 s2 freq +8805 delay 4715 Nov 5 18:12:31 pluto ptp4l: [354670.428] master offset -32 s2 freq +34299 path delay 6092 Nov 5 18:12:33 pluto ptp4l: [354672.428] master offset 20 s2 freq +34320 path delay 6092 Nov 5 18:12:34 pluto phc2sys: [354673.993] phc offset 470 s2 freq +7931 delay 4705 Nov 5 18:12:35 pluto ptp4l: [354674.428] master offset 54 s2 freq +34340 path delay 6095 Nov 5 18:12:37 pluto ptp4l: [354676.428] master offset -15 s2 freq +34314 path delay 6095 Nov 5 18:12:38 pluto phc2sys: [354677.993] phc offset -6992 s2 freq +3968 delay 4870 Nov 5 18:12:39 pluto ptp4l: [354678.428] master offset -19 s2 freq +34309 path delay 6096 Nov 5 18:12:41 pluto ptp4l: [354680.429] master offset 55 s2 freq +34344 path delay 6096 Nov 5 18:12:42 pluto phc2sys: [354681.994] phc offset 11326 s2 freq +11945 delay 4715 Nov 5 18:12:43 pluto ptp4l: [354682.428] master offset -90 s2 freq +34279 path delay 6096 Nov 5 18:12:45 pluto ptp4l: [354684.429] master offset -49 s2 freq +34286 path delay 6096 Nov 5 18:12:46 pluto phc2sys: [354685.994] phc offset -70368744182111 s2 freq -500000 delay 4715 *Nov 5 18:12:47 pluto ptp4l: [354686.428] clockcheck: clock jumped forward or running faster than expected!Nov 5 18:12:47 pluto ptp4l: [354686.429] master offset 70368744177715 s0 freq +0 path delay 6095* Nov 5 18:12:47 pluto ptp4l: [354686.430] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT Nov 5 18:12:49 pluto ptp4l: [354688.430] master offset 70368744177775 s1 freq +34334 path delay 6095 Nov 5 18:12:50 pluto phc2sys: [354689.994] phc offset 2028439 s2 freq +500000 delay 4717 Nov 5 18:12:51 pluto ptp4l: [354690.431] master offset -4473 s2 freq +32097 path delay 6095 Nov 5 18:12:51 pluto ptp4l: [354690.431] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED Nov 5 18:12:53 pluto ptp4l: [354692.430] master offset -48 s2 freq +33639 path delay 6095 Nov 5 18:12:54 pluto phc2sys: [354693.994] phc offset 52807 s2 freq +38158 delay 4712 Nov 5 18:12:55 pluto ptp4l: [354694.429] master offset 1367 s2 freq +34339 path delay 6095 Nov 5 18:12:57 pluto ptp4l: [354696.429] master offset 1179 s2 freq +34450 path delay 6095 Nov 5 18:12:58 pluto phc2sys: [354697.995] phc offset -65029 s2 freq -10810 delay 4715 Nov 5 18:12:59 pluto ptp4l: [354698.429] master offset 866 s2 freq +34470 path delay 6104 ... Nov 5 18:19:02 pluto phc2sys: [355062.012] phc offset 6991 s2 freq +10913 delay 4704 Nov 5 18:19:03 pluto ptp4l: [355062.442] master offset -8 s2 freq +34342 path delay 6109 Nov 5 18:19:05 pluto ptp4l: [355064.442] master offset -160 s2 freq +34265 path delay 6109 Nov 5 18:19:06 pluto phc2sys: [355066.012] phc offset -11133 s2 freq +3042 delay 4715 Nov 5 18:19:07 pluto ptp4l: [355066.442] master offset -73 s2 freq +34285 path delay 6102 Nov 5 18:19:09 pluto ptp4l: [355068.442] master offset 8 s2 freq +34314 path delay 6102 Nov 5 18:19:10 pluto phc2sys: [355070.012] phc offset 6061 s2 freq +9159 delay 4715 Nov 5 18:19:11 pluto ptp4l: [355070.442] master offset 89 s2 freq +34356 path delay 6098 Nov 5 18:19:13 pluto ptp4l: [355072.442] master offset 20 s2 freq +34335 path delay 6098 *Nov 5 18:19:14 pluto phc2sys: [355074.012] phc offset -70368744173547 s2 freq -500000 delay 4715Nov 5 18:19:15 pluto ptp4l: [355074.441] clockcheck: clock jumped forward or running faster than expected!* Nov 5 18:19:15 pluto ptp4l: [355074.442] master offset 70368744177526 s0 freq +0 path delay 6103 Nov 5 18:19:15 pluto ptp4l: [355074.443] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT Nov 5 18:19:17 pluto ptp4l: [355076.444] master offset 70368744177457 s1 freq +34293 path delay 6103 Nov 5 18:19:18 pluto phc2sys: [355078.013] phc offset 2034086 s2 freq +500000 delay 4762 Nov 5 18:19:19 pluto ptp4l: [355078.444] master offset -4252 s2 freq +32167 path delay 6103 Nov 5 18:19:19 pluto ptp4l: [355078.445] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED Nov 5 18:19:21 pluto ptp4l: [355080.443] master offset 71 s2 freq +33691 path delay 6103 Nov 5 18:19:22 pluto phc2sys: [355082.013] phc offset 54724 s2 freq +37742 delay 4713 Nov 5 18:19:23 pluto ptp4l: [355082.443] master offset 1255 s2 freq +34294 path delay 6103 Nov 5 18:19:25 pluto ptp4l: [355084.443] master offset 1298 s2 freq +34503 path delay 6102 Nov 5 18:19:26 pluto phc2sys: [355086.013] phc offset -71161 s2 freq -15078 delay 4706 Nov 5 18:19:27 pluto ptp4l: [355086.443] master offset 1034 s2 freq +34566 path delay 6102 Nov 5 18:19:29 pluto ptp4l: [355088.443] master offset 540 s2 freq +34474 path delay 6106 ... Nov 5 19:16:34 pluto phc2sys: [358514.174] phc offset -691 s2 freq +10120 delay 4714 Nov 5 19:16:35 pluto ptp4l: [358514.563] master offset 56 s2 freq +34310 path delay 6097 Nov 5 19:16:37 pluto ptp4l: [358516.563] master offset 98 s2 freq +34340 path delay 6097 Nov 5 19:16:38 pluto phc2sys: [358518.174] phc offset -37068 s2 freq -10095 delay 4716 *Nov 5 19:16:39 pluto ptp4l: [358518.562] clockcheck: clock jumped forward or running faster than expected!Nov 5 19:16:39 pluto ptp4l: [358518.563] master offset 70368744177566 s0 freq +0 path delay 6100* Nov 5 19:16:39 pluto ptp4l: [358518.563] port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT Nov 5 19:16:41 pluto ptp4l: [358520.563] master offset 70368744177456 s1 freq +34250 path delay 6100 Nov 5 19:16:42 pluto phc2sys: [358522.175] phc offset 59749 s2 freq +32034 delay 4714 Nov 5 19:16:43 pluto ptp4l: [358522.563] master offset -4442 s2 freq +32029 path delay 6100 Nov 5 19:16:43 pluto ptp4l: [358522.563] port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED Nov 5 19:16:45 pluto ptp4l: [358524.564] master offset 126 s2 freq +33647 path delay 6100 Nov 5 19:16:46 pluto phc2sys: [358526.175] phc offset -32436 s2 freq -743 delay 4933 Nov 5 19:16:47 pluto ptp4l: [358526.563] master offset 1510 s2 freq +34358 path delay 6100 Nov 5 19:16:49 pluto ptp4l: [358528.563] master offset 1356 s2 freq +34508 path delay 6106 Nov 5 19:16:50 pluto phc2sys: [358530.175] phc offset -19275 s2 freq -3235 delay 4716 ... |
|
From: Flavio L. <fb...@re...> - 2013-10-30 12:18:25
|
On Mon, Oct 28, 2013 at 03:29:57PM +0000, Gabe Black wrote:
> Hi William,
>
> I installed redhat 6.4 and have the intel i350 (with igb driver) and am having trouble getting it to work with a meinberg master.
>
> The output I get is:
>
> ptp4l[246980.523]: selected /dev/ptp1 as PTP clock
> ptp4l[246980.525]: port 1: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[246980.526]: port 0: INITIALIZING to LISTENING on INITIALIZE
> ptp4l[246980.773]: port 1: new foreign master 00606e.fffe.7c230e-1
> ptp4l[246985.014]: selected best master clock 00606e.fffe.7c230e
> ptp4l[246985.014]: foreign master not using PTP timescale
> ptp4l[246985.014]: running in a temporal vortex
> ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
> ptp4l[246985.989]: recvmsg tx timestamp failed: Resource temporarily unavailable
> ptp4l[246985.989]: port 1: send delay request failed
> ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on FAULT_DETECTED
>
> Did you have to do anything differently on the stock RH6.4 install to get it to work?
Sorry, I am very late to this thread. Apparently there is a bug in
RHEL-6.4 kernel to that specific device. Could you please try the patch
below?
BTW, as said already, a big number of PTP fixes are applied in RHEL-6.5,
so please consider to update.
fbl
---8<----
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 12dfb62..36ab8e1 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1395,6 +1395,14 @@ static void igb_irq_enable(struct igb_adapter *adapter)
wr32(E1000_MBVFIMR, 0xFF);
ims |= E1000_IMS_VMMB;
}
+#ifdef CONFIG_IGB_PTP
+ /*
+ * Need to set this here as it might get cleared by the VLAN
+ * code, see igb_vlan_rx_register() and igb_vlan_rx_kill_vid().
+ */
+ if (hw->mac.type >= e1000_82580)
+ ims |= E1000_IMS_TS;
+#endif /* CONFIG_IGB_PTP */
wr32(E1000_IMS, ims);
} else {
wr32(E1000_IMS, IMS_ENABLE_MASK |
---8<----
>
> Thanks,
> Gabe
>
> > -----Original Message-----
> > From: Ledda William EXT [mailto:Wil...@it...]
> > Sent: Monday, October 21, 2013 1:02 AM
> > To: Richard Cochran; Gabe Black
> > Cc: lin...@li...
> > Subject: RE: [Linuxptp-users] Which distributions have native ptp
> > support?
> >
> > I'm currently using RH 6.4 with Intel i350 (igb driver) with success
> > (no need to recompile the kernel). About RH 6.5 I know that there will
> > be many improvements, more eth driver supported, and it should include
> > version 1.3 of linuxptp package.
> >
> > William
> >
> > ----Original Message-----
> > From: Richard Cochran [mailto:ric...@gm...]
> > Sent: 19 October 2013 08:01
> > To: Gabe Black
> > Cc: lin...@li...
> > Subject: Re: [Linuxptp-users] Which distributions have native ptp
> > support?
> >
> > On Thu, Oct 10, 2013 at 07:18:29PM +0000, Gabe Black wrote:
> >
> > > I've been trying to search and find which distributions have native
> > > ptp support. I am finding it difficult to find out without actually
> > > installing the distribution.
> > >
> > > So far I have found that Redhat 6.5 will have support (according to
> > > their release notes). Are there any others?
> >
> > There are a few distro people on this list, but they are all silent :(
> >
> > I can only say that I use debian or my own SLIM for embedded (github),
> > but on debian I compile my own kernel and also linuxptp.
> >
> > In general, I think the distros will need more time, since you really
> > want at least kernel 3.5 for ETHTOOL_GET_TS_INFO, and 3.9 for the
> > latest drivers.
> >
> > Thanks,
> > Richard
> >
> > -----------------------------------------------------------------------
> > -------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > most from the latest Intel processors and coprocessors. See abstracts
> > and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.cl
> > ktrk
> > _______________________________________________
> > Linuxptp-users mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
>
|
|
From: Richard C. <ric...@gm...> - 2013-10-30 09:17:16
|
On Wed, Oct 30, 2013 at 10:12:55AM +0100, Richard Cochran wrote:
>
> So, based on this thread, other recent threads, and my own past
> experience, I can only recommend to avoid vendor kernels like the
^^^^^^
Oops, I meant "distro" kernels, but avoid vendor kernels, too.
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2013-10-30 09:13:14
|
On Fri, Oct 25, 2013 at 05:47:26PM +0200, Jean-Baptiste Maillet wrote: > On 10/25/2013 05:09 PM, Richard Cochran wrote: > > On Fri, Oct 25, 2013 at 04:10:36PM +0200, Jean-Baptiste Maillet wrote: > >> > >> On the kernel side, for driver/ptp/ I'm on 0d8c3e7 "ptp_pch: fix error handling in pch_probe()" for stmmac, > >> Debian 3.10.7-1 for i210. > > > > So 0d8c3e7 means a pure mainstream kernel (v3.10-rc5~25^2~36)? > > Nope, the sha is just the reference to where I am regarding ptp compared to upstream. > This is a SoC with specific BSP and platform drivers. > > > And Debian kernel is from testing or unstable? > > Testing (but at least pure Debian upstream). Okay, so I just tried linux-image-3.10-0.bpo.2-686-pae from wheezy-backports, and it is definitely broken WRT igb. Even commands like "ifdown" and "ifconfig" stall forever. In contrast, a plain old 3.10.17 kernel works just fine with i210, igb and ptp4l. So, based on this thread, other recent threads, and my own past experience, I can only recommend to avoid vendor kernels like the plague. Thanks, Richard |
|
From: Ledda W. E. <Wil...@it...> - 2013-10-30 07:37:03
|
Also RH real time kernel is based on 3.x (available with MRG-R extension). It should be interesting to understand if it works as well -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: 29 October 2013 20:25 To: Gabe Black; Trudeau, Brian; Ledda William EXT; Vick, Matthew Cc: lin...@li... Subject: RE: [Linuxptp-users] Which distributions have native ptp support? Nice :) My guess is because OpenSuse 12.3 is based on a 3.x kernel, they just came with the PTP module already there, including any bug fixes for igb that have happened. Redhat's case is due to backporting onto a 2.6.32 kernel, which likely they had some bugs in the process. That, or their version of igb does not have all the proper PTP fixes from upstream. Regards, Jake > -----Original Message----- > From: Gabe Black [mailto:Gab...@jd...] > Sent: Tuesday, October 29, 2013 12:14 PM > To: Trudeau, Brian; Ledda William EXT; Keller, Jacob E; Vick, Matthew > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > I installed opensuse 12.3. It didn't seem to come with linuxptp > (ptp4l) and instead comes with ptpd. However, the kernel did have the > native PTP support. I downloaded linuxptp and compiled and ptp4l > worked without a hitch on the exact same VM. > > It appears to perform very well. > > Thanks! > Gabe > > > -----Original Message----- > > From: Trudeau, Brian [mailto:btr...@On...] > > Sent: Tuesday, October 29, 2013 1:09 PM > > To: Ledda William EXT; Keller, Jacob E; Vick, Matthew; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > We're attempting to work with the base redhat kernel without > > recompiling, when you plan to work with 100s(sure there are case > > with some of you 1000s) of servers you don't want to have to create > > your > own > > little patch repo and also drop any support you'll have with redhat... > > > > Brian Trudeau > > > > > > -----Original Message----- > > From: Ledda William EXT [mailto:Wil...@it...] > > Sent: Tuesday, October 29, 2013 1:09 PM > > To: Keller, Jacob E; Trudeau, Brian; Vick, Matthew; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > It's curious that you can't work with RH 6.4 and i350... I'm the > > only "lucky" guy that can works with RH 6.4 and i350 without issues? > > How is the network configuration? On RH could be required to modify > the > > rp_filter configuration in some cases > > https://access.redhat.com/site/solutions/53031 > > > > I used also a Broadcom NetXtreme BCM5719 chipset. I have installed > the > > tg3 driver provided by Broadcom (since that one included in RH > > distribution didn't have PHC support) and it works even with HW time > > stamping. > > > > Again, the only trouble that I had was related to the firewall enabled! > > > > -----Original Message----- > > From: Keller, Jacob E [mailto:jac...@in...] > > Sent: 29 October 2013 18:04 > > To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > Redhat 6.4 would have to be a backport of the PTP code which is > > probably troublesome. > > > > Likely, the in kernel driver in their 2.6.32+patches kernel is > > causing the poll to time out. > > > > I doubt the kernel compatability layer for the sourceforge driver > > has code for Redhat 6.4 to enable PTP (as it's not enabled by > > default) and I believe it does some static checking against 3.0 kernel version. > > > > I would suggest trying on a newer distribution. > > > > Regards, > > Jake > > > > > -----Original Message----- > > > From: Trudeau, Brian [mailto:btr...@On...] > > > Sent: Tuesday, October 29, 2013 8:57 AM > > > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > > > Cc: lin...@li... > > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > I've been having this same issue with the redhat built version as > > > well, I've contacted support and they just brushed it off as being > > > a technical preview and is nether supported or guarantee it to be > > > supported in any future release as well. I think they are having > > > issues back porting as you said... > > > > > > Brian Trudeau > > > > > > > > > -----Original Message----- > > > From: Vick, Matthew [mailto:mat...@in...] > > > Sent: Tuesday, October 29, 2013 10:08 AM > > > To: Ledda William EXT; Gabe Black; Keller, Jacob E > > > Cc: lin...@li... > > > Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > Gabe, > > > > > > To chime in as well, if you continue to have problems I would > > > recommend filing a Bugzilla with Red Hat. They own the version of > > > igb and ptp4l included in their kernel and it could be something > > > else in their stack interfering specifically with your configuration. > > > > > > Another option for you to try is the latest version of igb from > > > SourceForge > > > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > > > that works for you. > > > > > > I'm not sure what all the VM changes (other than obviously > > introducing > > > some delay around when the app can run), but I would hope the > device > > > continues to operate correctly. > > > > > > Cheers, > > > Matthew > > > > > > Matthew Vick > > > Linux Development > > > Networking Division > > > Intel Corporation > > > > > > > > > On 10/29/13, 1:11 AM, "Ledda William EXT" > <Wil...@it...> > > > wrote: > > > > > > >Dear all, > > > >Have you check the firewall? Is it enabled? The only problem that > > > >I had > > > >(initially) was related to the firewall. After disabling the > > firewall > > > >everything works! > > > > > > > >I worked without problem with the version released with RH 6.4 > > > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also > work > > > with > > > >1.2 and now I'm working with 1.3 without any problem. > > > >How do you have compiled version 1.3? Do you have disabled the > one > > > step > > > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC > symbol? > > > Base > > > >kernel > > > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in > linux/net_tstamp.h, > > > so in > > > >order to compile, you should define this symbol or change the > > > >sk.c > > in > > > >order to don't check for one step clocks. > > > > > > > >My syetem configuration: > > > > > > > >$ uname -a > > > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 > > > >SMP Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > > > > > >$ ethtool -i eth1 > > > >driver: igb > > > >version: 4.0.1-k > > > >firmware-version: 1.61, 0x090f8000 > > > >bus-info: 0000:10:00.1 > > > >supports-statistics: yes > > > >supports-test: yes > > > >supports-eeprom-access: yes > > > >supports-register-dump: yes > > > >supports-priv-flags: no > > > > > > > >$ ethtool -T eth1 > > > >Time stamping parameters for eth1: > > > >Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > >PTP Hardware Clock: 1 > > > >Hardware Transmit Timestamp Modes: > > > > off (HWTSTAMP_TX_OFF) > > > > on (HWTSTAMP_TX_ON) > > > >Hardware Receive Filter Modes: > > > > none (HWTSTAMP_FILTER_NONE) > > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > > > > > >-----Original Message----- > > > >From: Gabe Black [mailto:Gab...@jd...] > > > >Sent: 29 October 2013 01:18 > > > >To: Gabe Black; Keller, Jacob E > > > >Cc: lin...@li... > > > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > > > >same, except now poll times out. I have increased the timeout > > > >and even modified the code to see what packet was getting > > > >transmitted > to > > > >verify things. > > > > > > > >I verified that in wireshark I see the delay req message go out, > > > >and the delay response as well. > > > > > > > >Looking at the code and reading > > > Documentation/networking/timestamping > > > >it looks like the code is trying to get the transmit timestamp of > > the > > > >packet which is expected to be found in the socket error queue. > > > > > > > >So this leads me to believe that the timestamp is simply not > > > >making it in to the MSG_ERRQUEUE... Again, I have the default > > > >RH6.4 kernel/install and the igb driver seems to have support for > > > >it as shown > > > below: > > > > > > > >ethtool -T eth3 > > > >Time stamping parameters for eth3: > > > >Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > >PTP Hardware Clock: 1 > > > >Hardware Transmit Timestamp Modes: > > > > off (HWTSTAMP_TX_OFF) > > > > on (HWTSTAMP_TX_ON) > > > >Hardware Receive Filter Modes: > > > > none (HWTSTAMP_FILTER_NONE) > > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > >ethtool -I eth3 > > > >driver: igb > > > >version: 4.0.1-k > > > > > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to > > > >do a bunch of work to back-port the stuff to get things like "ethtool -T" > > > >to work. Probably still buggy... > > > > > > > >Anyway, not sure what William did to get it to work... I think I > > > >am going to just switch to a different distribution that has it > > > >supported out of the box as well. Apparently on this thread > > > >Fedora > > > >19 and OpenSuse have it. > > > > > > > >Oh, I am running in a virtualized environment using DirectPath > > > >I/O (a.k.a > > > >"passthrough") to assign the I350 driver directly to the VM. > > > >Maybe that matters; but I'm fairly certain that DirectPath > > > >presents the hardware registers/configuration in all its glory to > > > >the VM, thus letting the igb-driver operate the device. The > > > >software is the > > same, > > > >so we should be getting timestamps... > > > > > > > >Oh well, on to the next distribution! > > > > > > > >Thanks! > > > >Gabe > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Gabe Black [mailto:Gab...@jd...] > > > >> Sent: Monday, October 28, 2013 5:19 PM > > > >> To: Keller, Jacob E > > > >> Cc: lin...@li... > > > >> Subject: Re: [Linuxptp-users] Which distributions have native > > > >> ptp support? > > > >> > > > >> I am using the version that comes with a fresh install of the > > > >> RH > > > >> 6.4 > > > >> release: > > > >> > > > >> rpm -qa | grep ptp > > > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > > > >> > > > >> ptp4l doesn't appear to have a version option (in this release) > > and > > > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > > > either. > > > >> > > > >> At any rate, I will get the latest version and try that and > > report. > > > >> > > > >> Thank you for the feedback! > > > >> > > > >> > -----Original Message----- > > > >> > From: Keller, Jacob E [mailto:jac...@in...] > > > >> > Sent: Monday, October 28, 2013 4:37 PM > > > >> > To: Gabe Black > > > >> > Cc: Ledda William EXT; lin...@li... > > > >> > Subject: Re: [Linuxptp-users] Which distributions have native > > ptp > > > >> > support? > > > >> > > > > >> > What version of linuxPTP are you using? > > > >> > > > > >> > It appears you aren't using the 1.3 version as we moved to a > > > >> > method for obtaining the Tx timestamp that uses the poll() call. > > > >> > That might fix your issue. > > > >> > > > > >> > The other option would be to increase the > tx_timestamp_timeout > > > >> > value, but I think moving to the newest Linux PTP should be a > > fix. > > > >> > > > > >> > Regards, > > > >> > Jake > > > >> > > > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > > > >> > > Nm, it was right. We have two subnets that will route to > > > >> > > the > > > >> > meinberg, and they both work... So that means I still I > > > >> > don't know what it is... > > > >> > > > > > >> > > strace it shows: > > > >> > > sendto(11, > > > >> > > > > > >> > > > > >> > > > > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > > > 3\0\1 > > > >> \ > > > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > > > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > > > >> > > 44 > > > >> > > Followed by a bunch of: > > > >> > > > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > > temporarily unavailable) ... > > > >> > > > > > >> > > > > > >> > > > > > >> > > > -----Original Message----- > > > >> > > > From: Gabe Black > > > >> > > > Sent: Monday, October 28, 2013 2:20 PM > > > >> > > > To: Gabe Black; 'Keller, Jacob E' > > > >> > > > Cc: 'Ledda William EXT'; 'linuxptp- > > us...@li...' > > > >> > > > Subject: RE: [Linuxptp-users] Which distributions have > > native > > > >> > > > ptp support? > > > >> > > > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > > > >> > > > > > > >> > > > It is working now! > > > >> > > > > > > >> > > > > -----Original Message----- > > > >> > > > > From: Gabe Black > > > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > > > >> > > > > To: 'Keller, Jacob E' > > > >> > > > > Cc: Ledda William EXT; linuxptp- > > us...@li... > > > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > > > >> > > > > native ptp support? > > > >> > > > > > > > >> > > > > > -----Original Message----- > > > >> > > > > > From: Keller, Jacob E > > > >> > > > > > [mailto:jac...@in...] You shouldn't have > > > >> > > > > > to, however, I would suggest > > disabling > > > >> > > > > > EEE support, as this has been known to cause issues > > > >> > > > > > on the i350 > > > >> > > > > > > > > >> > > > > > ethtool --set-eee device eee off > > > >> > > > > > > > > >> > > > > > This should fix your issue, if not please me know. > > > >> > > > > > > > >> > > > > Thank you for the reply. > > > >> > > > > > > > >> > > > > That option does not appear to be available with the > > > >> > > > > stock igb driver of RH6.4 > > > >> > > > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > > > >> > > > > driver: igb > > > >> > > > > version: 4.0.1-k > > > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > > > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot > > get > > > >> > > > > EEE > > > >> > > > > settings: Operation not supported > > > >> > > > > > > > >> > > > > Is there another way to disable EEE? Or would not > > > >> > > > > having that option in ethtool mean it is off? > > > >> > > > > > > > >> > > > > Gabe > > > >> > > > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > > > >> > > > > > > Hi William, > > > >> > > > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 > > > >> > > > > > > (with igb > > > >> > > > > > > driver) > > > >> > > > > and > > > >> > > > > > am having trouble getting it to work with a meinberg > > master. > > > >> > > > > > > > > > >> > > > > > > The output I get is: > > > >> > > > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > > > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to > > > >> > > > > > > LISTENING > > on > > > >> > > > INITIALIZE > > > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to > > > >> > > > > > > LISTENING > > on > > > >> > > > INITIALIZE > > > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > > > >> > > > > > > 00606e.fffe.7c230e- > > > >> > > > 1 > > > >> > > > > > > ptp4l[246985.014]: selected best master clock > > > >> > > > > > > 00606e.fffe.7c230e > > > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > > > >> > > > > > > timescale > > > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > > > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to > UNCALIBRATED > > on > > > >> > > > > > > RS_SLAVE > > > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > > > >> > > > > > > Resource > > > >> > > > > temporarily > > > >> > > > > > > unavailable > > > >> > > > > > > ptp4l[246985.989]: port 1: send delay request > > > >> > > > > > > failed > > > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY > on > > > >> > > > > > > FAULT_DETECTED > > > >> > > > > > > > > > >> > > > > > > Did you have to do anything differently on the > > > >> > > > > > > stock > > > >> > > > > > > RH6.4 > > > >> > > > install > > > >> > > > > > > to > > > >> > > > > > get it to work? > > > >> > > > > > > > > > >> > > > > > > Thanks, > > > >> > > > > > > Gabe > > > >> > > > > > > > > > >> > > > > > > > -----Original Message----- > > > >> > > > > > > > From: Ledda William EXT > > > >> > > > > > > > [mailto:Wil...@it...] > > > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > > > >> > > > > > > > To: Richard Cochran; Gabe Black > > > >> > > > > > > > Cc: lin...@li... > > > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > > > >> > > > > > > > have native ptp support? > > > >> > > > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > > > >> > > > > > > > driver) > > > >> > with > > > >> > > > > > success > > > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > > > >> > > > > > > > know that there will be many improvements, more > eth > > > >> > > > > > > > driver supported, and it should include version > > > >> > > > > > > > 1.3 of linuxptp > > > >> package. > > > >> > > > > > > > > > > >> > > > > > > > William > > > >> > > > > > > > > > > >> > > > > > >> > > > > >> > > > >> --------------------------------------------------------------- > > > >> --- > > - > > > >> -- > > > >> - > > > >> - > > > >> ------- > > > >> Android is increasing in popularity, but the open development > > > >> platform that developers love is also attractive to malware > > creators. > > > >> Download this white paper to learn more about secure code > signing > > > >> practices that can help keep Android apps secure. > > > >> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > > g. > > > >> c > > > >> l > > > >> ktrk > > > >> _______________________________________________ > > > >> Linuxptp-users mailing list > > > >> Lin...@li... > > > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > >----------------------------------------------------------------- > > > >--- > > - > > > >-- > > > >--- > > > >---- > > > >Android is increasing in popularity, but the open development > > > >platform that developers love is also attractive to malware > > creators. > > > >Download this white paper to learn more about secure code signing > > > >practices that can help keep Android apps secure. > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > > stg.cl > > > >ktr > > > >k > > > >_______________________________________________ > > > >Linuxptp-users mailing list > > > >Lin...@li... > > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > >----------------------------------------------------------------- > > > >--- > > - > > > >-- > > > >--- > > > >---- > > > >Android is increasing in popularity, but the open development > > > >platform that developers love is also attractive to malware > > creators. > > > >Download this white paper to learn more about secure code signing > > > >practices that can help keep Android apps secure. > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > > stg.cl > > > >ktr > > > >k > > > >_______________________________________________ > > > >Linuxptp-users mailing list > > > >Lin...@li... > > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > > > ------------------------------------------------------------------ > > > --- > > - > > > -------- Android is increasing in popularity, but the open > > development > > > platform that developers love is also attractive to malware creators. > > > Download this white paper to learn more about secure code signing > > > practices that can help keep Android apps secure. > > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > > g.clktrk > > > _______________________________________________ > > > Linuxptp-users mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > The information transmitted herein is intended only for the person > > > or entity to which it is addressed and may contain confidential > > > and/or privileged material. This message is not a recommendation, > > > offer or solicitation to buy or sell anything. Any examples, > > > prices or quotations contained herein are indicative only and an > > > order based > on > > > such information can only be executed through a duly registered > > > broker/dealer or futures commission merchant. Any review, > > > retransmission, dissemination or other use of, or taking of any > > action > > > in reliance upon, this information is prohibited. If you received > > this > > > in error, please contact the sender and delete the material from > > > any > > computer. > > > OneChicago, LLC is a Delaware limited liability company. > > > > The information transmitted herein is intended only for the person > > or entity to which it is addressed and may contain confidential > > and/or privileged material. This message is not a recommendation, > > offer or solicitation to buy or sell anything. Any examples, prices > > or quotations contained herein are indicative only and an order > > based on such information can only be executed through a duly > > registered broker/dealer or futures commission merchant. Any review, > > retransmission, dissemination or other use of, or taking of any > > action in reliance upon, this information is prohibited. If you > > received this in error, please contact the sender and delete the > > material from any computer. OneChicago, LLC is a Delaware limited liability company. |
|
From: Keller, J. E <jac...@in...> - 2013-10-29 19:25:09
|
Nice :) My guess is because OpenSuse 12.3 is based on a 3.x kernel, they just came with the PTP module already there, including any bug fixes for igb that have happened. Redhat's case is due to backporting onto a 2.6.32 kernel, which likely they had some bugs in the process. That, or their version of igb does not have all the proper PTP fixes from upstream. Regards, Jake > -----Original Message----- > From: Gabe Black [mailto:Gab...@jd...] > Sent: Tuesday, October 29, 2013 12:14 PM > To: Trudeau, Brian; Ledda William EXT; Keller, Jacob E; Vick, Matthew > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > I installed opensuse 12.3. It didn't seem to come with linuxptp (ptp4l) and > instead comes with ptpd. However, the kernel did have the native PTP > support. I downloaded linuxptp and compiled and ptp4l worked without a > hitch on the exact same VM. > > It appears to perform very well. > > Thanks! > Gabe > > > -----Original Message----- > > From: Trudeau, Brian [mailto:btr...@On...] > > Sent: Tuesday, October 29, 2013 1:09 PM > > To: Ledda William EXT; Keller, Jacob E; Vick, Matthew; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > We're attempting to work with the base redhat kernel without > > recompiling, when you plan to work with 100s(sure there are case with > > some of you 1000s) of servers you don't want to have to create your > own > > little patch repo and also drop any support you'll have with redhat... > > > > Brian Trudeau > > > > > > -----Original Message----- > > From: Ledda William EXT [mailto:Wil...@it...] > > Sent: Tuesday, October 29, 2013 1:09 PM > > To: Keller, Jacob E; Trudeau, Brian; Vick, Matthew; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > It's curious that you can't work with RH 6.4 and i350... I'm the only > > "lucky" guy that can works with RH 6.4 and i350 without issues? > > How is the network configuration? On RH could be required to modify > the > > rp_filter configuration in some cases > > https://access.redhat.com/site/solutions/53031 > > > > I used also a Broadcom NetXtreme BCM5719 chipset. I have installed > the > > tg3 driver provided by Broadcom (since that one included in RH > > distribution didn't have PHC support) and it works even with HW time > > stamping. > > > > Again, the only trouble that I had was related to the firewall enabled! > > > > -----Original Message----- > > From: Keller, Jacob E [mailto:jac...@in...] > > Sent: 29 October 2013 18:04 > > To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > Redhat 6.4 would have to be a backport of the PTP code which is > > probably troublesome. > > > > Likely, the in kernel driver in their 2.6.32+patches kernel is causing > > the poll to time out. > > > > I doubt the kernel compatability layer for the sourceforge driver has > > code for Redhat 6.4 to enable PTP (as it's not enabled by default) and > > I believe it does some static checking against 3.0 kernel version. > > > > I would suggest trying on a newer distribution. > > > > Regards, > > Jake > > > > > -----Original Message----- > > > From: Trudeau, Brian [mailto:btr...@On...] > > > Sent: Tuesday, October 29, 2013 8:57 AM > > > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > > > Cc: lin...@li... > > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > I've been having this same issue with the redhat built version as > > > well, I've contacted support and they just brushed it off as being a > > > technical preview and is nether supported or guarantee it to be > > > supported in any future release as well. I think they are having > > > issues back porting as you said... > > > > > > Brian Trudeau > > > > > > > > > -----Original Message----- > > > From: Vick, Matthew [mailto:mat...@in...] > > > Sent: Tuesday, October 29, 2013 10:08 AM > > > To: Ledda William EXT; Gabe Black; Keller, Jacob E > > > Cc: lin...@li... > > > Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > Gabe, > > > > > > To chime in as well, if you continue to have problems I would > > > recommend filing a Bugzilla with Red Hat. They own the version of igb > > > and ptp4l included in their kernel and it could be something else in > > > their stack interfering specifically with your configuration. > > > > > > Another option for you to try is the latest version of igb from > > > SourceForge > > > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > > > that works for you. > > > > > > I'm not sure what all the VM changes (other than obviously > > introducing > > > some delay around when the app can run), but I would hope the > device > > > continues to operate correctly. > > > > > > Cheers, > > > Matthew > > > > > > Matthew Vick > > > Linux Development > > > Networking Division > > > Intel Corporation > > > > > > > > > On 10/29/13, 1:11 AM, "Ledda William EXT" > <Wil...@it...> > > > wrote: > > > > > > >Dear all, > > > >Have you check the firewall? Is it enabled? The only problem that I > > > >had > > > >(initially) was related to the firewall. After disabling the > > firewall > > > >everything works! > > > > > > > >I worked without problem with the version released with RH 6.4 > > > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also > work > > > with > > > >1.2 and now I'm working with 1.3 without any problem. > > > >How do you have compiled version 1.3? Do you have disabled the > one > > > step > > > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC > symbol? > > > Base > > > >kernel > > > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in > linux/net_tstamp.h, > > > so in > > > >order to compile, you should define this symbol or change the sk.c > > in > > > >order to don't check for one step clocks. > > > > > > > >My syetem configuration: > > > > > > > >$ uname -a > > > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP > > > >Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > > > > > >$ ethtool -i eth1 > > > >driver: igb > > > >version: 4.0.1-k > > > >firmware-version: 1.61, 0x090f8000 > > > >bus-info: 0000:10:00.1 > > > >supports-statistics: yes > > > >supports-test: yes > > > >supports-eeprom-access: yes > > > >supports-register-dump: yes > > > >supports-priv-flags: no > > > > > > > >$ ethtool -T eth1 > > > >Time stamping parameters for eth1: > > > >Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > >PTP Hardware Clock: 1 > > > >Hardware Transmit Timestamp Modes: > > > > off (HWTSTAMP_TX_OFF) > > > > on (HWTSTAMP_TX_ON) > > > >Hardware Receive Filter Modes: > > > > none (HWTSTAMP_FILTER_NONE) > > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > > > > > >-----Original Message----- > > > >From: Gabe Black [mailto:Gab...@jd...] > > > >Sent: 29 October 2013 01:18 > > > >To: Gabe Black; Keller, Jacob E > > > >Cc: lin...@li... > > > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > > > >same, except now poll times out. I have increased the timeout and > > > >even modified the code to see what packet was getting transmitted > to > > > >verify things. > > > > > > > >I verified that in wireshark I see the delay req message go out, and > > > >the delay response as well. > > > > > > > >Looking at the code and reading > > > Documentation/networking/timestamping > > > >it looks like the code is trying to get the transmit timestamp of > > the > > > >packet which is expected to be found in the socket error queue. > > > > > > > >So this leads me to believe that the timestamp is simply not making > > > >it in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > > > >kernel/install and the igb driver seems to have support for it as > > > >shown > > > below: > > > > > > > >ethtool -T eth3 > > > >Time stamping parameters for eth3: > > > >Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > >PTP Hardware Clock: 1 > > > >Hardware Transmit Timestamp Modes: > > > > off (HWTSTAMP_TX_OFF) > > > > on (HWTSTAMP_TX_ON) > > > >Hardware Receive Filter Modes: > > > > none (HWTSTAMP_FILTER_NONE) > > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > >ethtool -I eth3 > > > >driver: igb > > > >version: 4.0.1-k > > > > > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > > > >bunch of work to back-port the stuff to get things like "ethtool -T" > > > >to work. Probably still buggy... > > > > > > > >Anyway, not sure what William did to get it to work... I think I am > > > >going to just switch to a different distribution that has it > > > >supported out of the box as well. Apparently on this thread Fedora > > > >19 and OpenSuse have it. > > > > > > > >Oh, I am running in a virtualized environment using DirectPath I/O > > > >(a.k.a > > > >"passthrough") to assign the I350 driver directly to the VM. Maybe > > > >that matters; but I'm fairly certain that DirectPath presents the > > > >hardware registers/configuration in all its glory to the VM, thus > > > >letting the igb-driver operate the device. The software is the > > same, > > > >so we should be getting timestamps... > > > > > > > >Oh well, on to the next distribution! > > > > > > > >Thanks! > > > >Gabe > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Gabe Black [mailto:Gab...@jd...] > > > >> Sent: Monday, October 28, 2013 5:19 PM > > > >> To: Keller, Jacob E > > > >> Cc: lin...@li... > > > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > >> support? > > > >> > > > >> I am using the version that comes with a fresh install of the RH > > > >> 6.4 > > > >> release: > > > >> > > > >> rpm -qa | grep ptp > > > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > > > >> > > > >> ptp4l doesn't appear to have a version option (in this release) > > and > > > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > > > either. > > > >> > > > >> At any rate, I will get the latest version and try that and > > report. > > > >> > > > >> Thank you for the feedback! > > > >> > > > >> > -----Original Message----- > > > >> > From: Keller, Jacob E [mailto:jac...@in...] > > > >> > Sent: Monday, October 28, 2013 4:37 PM > > > >> > To: Gabe Black > > > >> > Cc: Ledda William EXT; lin...@li... > > > >> > Subject: Re: [Linuxptp-users] Which distributions have native > > ptp > > > >> > support? > > > >> > > > > >> > What version of linuxPTP are you using? > > > >> > > > > >> > It appears you aren't using the 1.3 version as we moved to a > > > >> > method for obtaining the Tx timestamp that uses the poll() call. > > > >> > That might fix your issue. > > > >> > > > > >> > The other option would be to increase the > tx_timestamp_timeout > > > >> > value, but I think moving to the newest Linux PTP should be a > > fix. > > > >> > > > > >> > Regards, > > > >> > Jake > > > >> > > > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > > > >> > > Nm, it was right. We have two subnets that will route to the > > > >> > meinberg, and they both work... So that means I still I don't > > > >> > know what it is... > > > >> > > > > > >> > > strace it shows: > > > >> > > sendto(11, > > > >> > > > > > >> > > > > >> > > > > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > > > 3\0\1 > > > >> \ > > > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > > > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > > > >> > > 44 > > > >> > > Followed by a bunch of: > > > >> > > > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > > temporarily unavailable) ... > > > >> > > > > > >> > > > > > >> > > > > > >> > > > -----Original Message----- > > > >> > > > From: Gabe Black > > > >> > > > Sent: Monday, October 28, 2013 2:20 PM > > > >> > > > To: Gabe Black; 'Keller, Jacob E' > > > >> > > > Cc: 'Ledda William EXT'; 'linuxptp- > > us...@li...' > > > >> > > > Subject: RE: [Linuxptp-users] Which distributions have > > native > > > >> > > > ptp support? > > > >> > > > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > > > >> > > > > > > >> > > > It is working now! > > > >> > > > > > > >> > > > > -----Original Message----- > > > >> > > > > From: Gabe Black > > > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > > > >> > > > > To: 'Keller, Jacob E' > > > >> > > > > Cc: Ledda William EXT; linuxptp- > > us...@li... > > > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > > > >> > > > > native ptp support? > > > >> > > > > > > > >> > > > > > -----Original Message----- > > > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] > > > >> > > > > > You shouldn't have to, however, I would suggest > > disabling > > > >> > > > > > EEE support, as this has been known to cause issues on > > > >> > > > > > the i350 > > > >> > > > > > > > > >> > > > > > ethtool --set-eee device eee off > > > >> > > > > > > > > >> > > > > > This should fix your issue, if not please me know. > > > >> > > > > > > > >> > > > > Thank you for the reply. > > > >> > > > > > > > >> > > > > That option does not appear to be available with the stock > > > >> > > > > igb driver of RH6.4 > > > >> > > > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > > > >> > > > > driver: igb > > > >> > > > > version: 4.0.1-k > > > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > > > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot > > get > > > >> > > > > EEE > > > >> > > > > settings: Operation not supported > > > >> > > > > > > > >> > > > > Is there another way to disable EEE? Or would not having > > > >> > > > > that option in ethtool mean it is off? > > > >> > > > > > > > >> > > > > Gabe > > > >> > > > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > > > >> > > > > > > Hi William, > > > >> > > > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with > > > >> > > > > > > igb > > > >> > > > > > > driver) > > > >> > > > > and > > > >> > > > > > am having trouble getting it to work with a meinberg > > master. > > > >> > > > > > > > > > >> > > > > > > The output I get is: > > > >> > > > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > > > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING > > on > > > >> > > > INITIALIZE > > > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING > > on > > > >> > > > INITIALIZE > > > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > > > >> > > > > > > 00606e.fffe.7c230e- > > > >> > > > 1 > > > >> > > > > > > ptp4l[246985.014]: selected best master clock > > > >> > > > > > > 00606e.fffe.7c230e > > > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > > > >> > > > > > > timescale > > > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > > > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to > UNCALIBRATED > > on > > > >> > > > > > > RS_SLAVE > > > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > > > >> > > > > > > Resource > > > >> > > > > temporarily > > > >> > > > > > > unavailable > > > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > > > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY > on > > > >> > > > > > > FAULT_DETECTED > > > >> > > > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > > > >> > > > > > > RH6.4 > > > >> > > > install > > > >> > > > > > > to > > > >> > > > > > get it to work? > > > >> > > > > > > > > > >> > > > > > > Thanks, > > > >> > > > > > > Gabe > > > >> > > > > > > > > > >> > > > > > > > -----Original Message----- > > > >> > > > > > > > From: Ledda William EXT > > > >> > > > > > > > [mailto:Wil...@it...] > > > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > > > >> > > > > > > > To: Richard Cochran; Gabe Black > > > >> > > > > > > > Cc: lin...@li... > > > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > > > >> > > > > > > > have native ptp support? > > > >> > > > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > > > >> > > > > > > > driver) > > > >> > with > > > >> > > > > > success > > > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > > > >> > > > > > > > know that there will be many improvements, more > eth > > > >> > > > > > > > driver supported, and it should include version 1.3 > > > >> > > > > > > > of linuxptp > > > >> package. > > > >> > > > > > > > > > > >> > > > > > > > William > > > >> > > > > > > > > > > >> > > > > > >> > > > > >> > > > >> ------------------------------------------------------------------ > > - > > > >> -- > > > >> - > > > >> - > > > >> ------- > > > >> Android is increasing in popularity, but the open development > > > >> platform that developers love is also attractive to malware > > creators. > > > >> Download this white paper to learn more about secure code > signing > > > >> practices that can help keep Android apps secure. > > > >> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > > g. > > > >> c > > > >> l > > > >> ktrk > > > >> _______________________________________________ > > > >> Linuxptp-users mailing list > > > >> Lin...@li... > > > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > >-------------------------------------------------------------------- > > - > > > >-- > > > >--- > > > >---- > > > >Android is increasing in popularity, but the open development > > > >platform that developers love is also attractive to malware > > creators. > > > >Download this white paper to learn more about secure code signing > > > >practices that can help keep Android apps secure. > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > > stg.cl > > > >ktr > > > >k > > > >_______________________________________________ > > > >Linuxptp-users mailing list > > > >Lin...@li... > > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > >-------------------------------------------------------------------- > > - > > > >-- > > > >--- > > > >---- > > > >Android is increasing in popularity, but the open development > > > >platform that developers love is also attractive to malware > > creators. > > > >Download this white paper to learn more about secure code signing > > > >practices that can help keep Android apps secure. > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > > stg.cl > > > >ktr > > > >k > > > >_______________________________________________ > > > >Linuxptp-users mailing list > > > >Lin...@li... > > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > > > --------------------------------------------------------------------- > > - > > > -------- Android is increasing in popularity, but the open > > development > > > platform that developers love is also attractive to malware creators. > > > Download this white paper to learn more about secure code signing > > > practices that can help keep Android apps secure. > > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > > g.clktrk > > > _______________________________________________ > > > Linuxptp-users mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > The information transmitted herein is intended only for the person or > > > entity to which it is addressed and may contain confidential and/or > > > privileged material. This message is not a recommendation, offer or > > > solicitation to buy or sell anything. Any examples, prices or > > > quotations contained herein are indicative only and an order based > on > > > such information can only be executed through a duly registered > > > broker/dealer or futures commission merchant. Any review, > > > retransmission, dissemination or other use of, or taking of any > > action > > > in reliance upon, this information is prohibited. If you received > > this > > > in error, please contact the sender and delete the material from any > > computer. > > > OneChicago, LLC is a Delaware limited liability company. > > > > The information transmitted herein is intended only for the person or > > entity to which it is addressed and may contain confidential and/or > > privileged material. This message is not a recommendation, offer or > > solicitation to buy or sell anything. Any examples, prices or > > quotations contained herein are indicative only and an order based on > > such information can only be executed through a duly registered > > broker/dealer or futures commission merchant. Any review, > > retransmission, dissemination or other use of, or taking of any action > > in reliance upon, this information is prohibited. If you received this > > in error, please contact the sender and delete the material from any > > computer. OneChicago, LLC is a Delaware limited liability company. |
|
From: Keller, J. E <jac...@in...> - 2013-10-29 19:23:19
|
You are correct. The suggestions I make are only in an attempt to determine the root cause, and possibly get the information forwarded so Redhat can fix any bugs they might have in their driver in the 6.4 kernel. Regards, Jake > -----Original Message----- > From: Trudeau, Brian [mailto:btr...@On...] > Sent: Tuesday, October 29, 2013 12:09 PM > To: Ledda William EXT; Keller, Jacob E; Vick, Matthew; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > We're attempting to work with the base redhat kernel without > recompiling, when you plan to work with 100s(sure there are case with > some of you 1000s) of servers you don't want to have to create your own > little patch repo and also drop any support you'll have with redhat... > > Brian Trudeau > > > -----Original Message----- > From: Ledda William EXT [mailto:Wil...@it...] > Sent: Tuesday, October 29, 2013 1:09 PM > To: Keller, Jacob E; Trudeau, Brian; Vick, Matthew; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > It's curious that you can't work with RH 6.4 and i350... I'm the only "lucky" > guy that can works with RH 6.4 and i350 without issues? > How is the network configuration? On RH could be required to modify the > rp_filter configuration in some cases > https://access.redhat.com/site/solutions/53031 > > I used also a Broadcom NetXtreme BCM5719 chipset. I have installed the > tg3 driver provided by Broadcom (since that one included in RH > distribution didn't have PHC support) and it works even with HW time > stamping. > > Again, the only trouble that I had was related to the firewall enabled! > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: 29 October 2013 18:04 > To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > Redhat 6.4 would have to be a backport of the PTP code which is > probably troublesome. > > Likely, the in kernel driver in their 2.6.32+patches kernel is causing the > poll to time out. > > I doubt the kernel compatability layer for the sourceforge driver has code > for Redhat 6.4 to enable PTP (as it's not enabled by default) and I believe > it does some static checking against 3.0 kernel version. > > I would suggest trying on a newer distribution. > > Regards, > Jake > > > -----Original Message----- > > From: Trudeau, Brian [mailto:btr...@On...] > > Sent: Tuesday, October 29, 2013 8:57 AM > > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > I've been having this same issue with the redhat built version as > > well, I've contacted support and they just brushed it off as being a > > technical preview and is nether supported or guarantee it to be > > supported in any future release as well. I think they are having > > issues back porting as you said... > > > > Brian Trudeau > > > > > > -----Original Message----- > > From: Vick, Matthew [mailto:mat...@in...] > > Sent: Tuesday, October 29, 2013 10:08 AM > > To: Ledda William EXT; Gabe Black; Keller, Jacob E > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] Which distributions have native ptp > > support? > > > > Gabe, > > > > To chime in as well, if you continue to have problems I would > > recommend filing a Bugzilla with Red Hat. They own the version of igb > > and ptp4l included in their kernel and it could be something else in > > their stack interfering specifically with your configuration. > > > > Another option for you to try is the latest version of igb from > > SourceForge > > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > > that works for you. > > > > I'm not sure what all the VM changes (other than obviously introducing > > some delay around when the app can run), but I would hope the device > > continues to operate correctly. > > > > Cheers, > > Matthew > > > > Matthew Vick > > Linux Development > > Networking Division > > Intel Corporation > > > > > > On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> > > wrote: > > > > >Dear all, > > >Have you check the firewall? Is it enabled? The only problem that I > > >had > > >(initially) was related to the firewall. After disabling the firewall > > >everything works! > > > > > >I worked without problem with the version released with RH 6.4 > > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work > > with > > >1.2 and now I'm working with 1.3 without any problem. > > >How do you have compiled version 1.3? Do you have disabled the one > > step > > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? > > Base > > >kernel > > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, > > so in > > >order to compile, you should define this symbol or change the sk.c in > > >order to don't check for one step clocks. > > > > > >My syetem configuration: > > > > > >$ uname -a > > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP > > >Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > > > >$ ethtool -i eth1 > > >driver: igb > > >version: 4.0.1-k > > >firmware-version: 1.61, 0x090f8000 > > >bus-info: 0000:10:00.1 > > >supports-statistics: yes > > >supports-test: yes > > >supports-eeprom-access: yes > > >supports-register-dump: yes > > >supports-priv-flags: no > > > > > >$ ethtool -T eth1 > > >Time stamping parameters for eth1: > > >Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > >PTP Hardware Clock: 1 > > >Hardware Transmit Timestamp Modes: > > > off (HWTSTAMP_TX_OFF) > > > on (HWTSTAMP_TX_ON) > > >Hardware Receive Filter Modes: > > > none (HWTSTAMP_FILTER_NONE) > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > > >-----Original Message----- > > >From: Gabe Black [mailto:Gab...@jd...] > > >Sent: 29 October 2013 01:18 > > >To: Gabe Black; Keller, Jacob E > > >Cc: lin...@li... > > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > > support? > > > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > > >same, except now poll times out. I have increased the timeout and > > >even modified the code to see what packet was getting transmitted to > > >verify things. > > > > > >I verified that in wireshark I see the delay req message go out, and > > >the delay response as well. > > > > > >Looking at the code and reading > > Documentation/networking/timestamping > > >it looks like the code is trying to get the transmit timestamp of the > > >packet which is expected to be found in the socket error queue. > > > > > >So this leads me to believe that the timestamp is simply not making > > >it in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > > >kernel/install and the igb driver seems to have support for it as > > >shown > > below: > > > > > >ethtool -T eth3 > > >Time stamping parameters for eth3: > > >Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > >PTP Hardware Clock: 1 > > >Hardware Transmit Timestamp Modes: > > > off (HWTSTAMP_TX_OFF) > > > on (HWTSTAMP_TX_ON) > > >Hardware Receive Filter Modes: > > > none (HWTSTAMP_FILTER_NONE) > > > all (HWTSTAMP_FILTER_ALL) > > > > > >ethtool -I eth3 > > >driver: igb > > >version: 4.0.1-k > > > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > > >bunch of work to back-port the stuff to get things like "ethtool -T" > > >to work. Probably still buggy... > > > > > >Anyway, not sure what William did to get it to work... I think I am > > >going to just switch to a different distribution that has it > > >supported out of the box as well. Apparently on this thread Fedora > > >19 and OpenSuse have it. > > > > > >Oh, I am running in a virtualized environment using DirectPath I/O > > >(a.k.a > > >"passthrough") to assign the I350 driver directly to the VM. Maybe > > >that matters; but I'm fairly certain that DirectPath presents the > > >hardware registers/configuration in all its glory to the VM, thus > > >letting the igb-driver operate the device. The software is the same, > > >so we should be getting timestamps... > > > > > >Oh well, on to the next distribution! > > > > > >Thanks! > > >Gabe > > > > > > > > > > > >> -----Original Message----- > > >> From: Gabe Black [mailto:Gab...@jd...] > > >> Sent: Monday, October 28, 2013 5:19 PM > > >> To: Keller, Jacob E > > >> Cc: lin...@li... > > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > > >> support? > > >> > > >> I am using the version that comes with a fresh install of the RH > > >> 6.4 > > >> release: > > >> > > >> rpm -qa | grep ptp > > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > > >> > > >> ptp4l doesn't appear to have a version option (in this release) and > > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > > either. > > >> > > >> At any rate, I will get the latest version and try that and report. > > >> > > >> Thank you for the feedback! > > >> > > >> > -----Original Message----- > > >> > From: Keller, Jacob E [mailto:jac...@in...] > > >> > Sent: Monday, October 28, 2013 4:37 PM > > >> > To: Gabe Black > > >> > Cc: Ledda William EXT; lin...@li... > > >> > Subject: Re: [Linuxptp-users] Which distributions have native ptp > > >> > support? > > >> > > > >> > What version of linuxPTP are you using? > > >> > > > >> > It appears you aren't using the 1.3 version as we moved to a > > >> > method for obtaining the Tx timestamp that uses the poll() call. > > >> > That might fix your issue. > > >> > > > >> > The other option would be to increase the tx_timestamp_timeout > > >> > value, but I think moving to the newest Linux PTP should be a fix. > > >> > > > >> > Regards, > > >> > Jake > > >> > > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > > >> > > Nm, it was right. We have two subnets that will route to the > > >> > meinberg, and they both work... So that means I still I don't > > >> > know what it is... > > >> > > > > >> > > strace it shows: > > >> > > sendto(11, > > >> > > > > >> > > > >> > > > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > > 3\0\1 > > >> \ > > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > > >> > > 44 > > >> > > Followed by a bunch of: > > >> > > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > > temporarily unavailable) ... > > >> > > > > >> > > > > >> > > > > >> > > > -----Original Message----- > > >> > > > From: Gabe Black > > >> > > > Sent: Monday, October 28, 2013 2:20 PM > > >> > > > To: Gabe Black; 'Keller, Jacob E' > > >> > > > Cc: 'Ledda William EXT'; 'lin...@li...' > > >> > > > Subject: RE: [Linuxptp-users] Which distributions have native > > >> > > > ptp support? > > >> > > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > > >> > > > > > >> > > > It is working now! > > >> > > > > > >> > > > > -----Original Message----- > > >> > > > > From: Gabe Black > > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > > >> > > > > To: 'Keller, Jacob E' > > >> > > > > Cc: Ledda William EXT; lin...@li... > > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > > >> > > > > native ptp support? > > >> > > > > > > >> > > > > > -----Original Message----- > > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] > > >> > > > > > You shouldn't have to, however, I would suggest disabling > > >> > > > > > EEE support, as this has been known to cause issues on > > >> > > > > > the i350 > > >> > > > > > > > >> > > > > > ethtool --set-eee device eee off > > >> > > > > > > > >> > > > > > This should fix your issue, if not please me know. > > >> > > > > > > >> > > > > Thank you for the reply. > > >> > > > > > > >> > > > > That option does not appear to be available with the stock > > >> > > > > igb driver of RH6.4 > > >> > > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > > >> > > > > driver: igb > > >> > > > > version: 4.0.1-k > > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot > get > > >> > > > > EEE > > >> > > > > settings: Operation not supported > > >> > > > > > > >> > > > > Is there another way to disable EEE? Or would not having > > >> > > > > that option in ethtool mean it is off? > > >> > > > > > > >> > > > > Gabe > > >> > > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > > >> > > > > > > Hi William, > > >> > > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with > > >> > > > > > > igb > > >> > > > > > > driver) > > >> > > > > and > > >> > > > > > am having trouble getting it to work with a meinberg > master. > > >> > > > > > > > > >> > > > > > > The output I get is: > > >> > > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING on > > >> > > > INITIALIZE > > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING on > > >> > > > INITIALIZE > > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > > >> > > > > > > 00606e.fffe.7c230e- > > >> > > > 1 > > >> > > > > > > ptp4l[246985.014]: selected best master clock > > >> > > > > > > 00606e.fffe.7c230e > > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > > >> > > > > > > timescale > > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED > on > > >> > > > > > > RS_SLAVE > > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > > >> > > > > > > Resource > > >> > > > > temporarily > > >> > > > > > > unavailable > > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on > > >> > > > > > > FAULT_DETECTED > > >> > > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > > >> > > > > > > RH6.4 > > >> > > > install > > >> > > > > > > to > > >> > > > > > get it to work? > > >> > > > > > > > > >> > > > > > > Thanks, > > >> > > > > > > Gabe > > >> > > > > > > > > >> > > > > > > > -----Original Message----- > > >> > > > > > > > From: Ledda William EXT > > >> > > > > > > > [mailto:Wil...@it...] > > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > > >> > > > > > > > To: Richard Cochran; Gabe Black > > >> > > > > > > > Cc: lin...@li... > > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > > >> > > > > > > > have native ptp support? > > >> > > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > > >> > > > > > > > driver) > > >> > with > > >> > > > > > success > > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > > >> > > > > > > > know that there will be many improvements, more eth > > >> > > > > > > > driver supported, and it should include version 1.3 > > >> > > > > > > > of linuxptp > > >> package. > > >> > > > > > > > > > >> > > > > > > > William > > >> > > > > > > > > > >> > > > > >> > > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> - > > >> ------- > > >> Android is increasing in popularity, but the open development > > >> platform that developers love is also attractive to malware creators. > > >> Download this white paper to learn more about secure code signing > > >> practices that can help keep Android apps secure. > > >> > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > g. > > >> c > > >> l > > >> ktrk > > >> _______________________________________________ > > >> Linuxptp-users mailing list > > >> Lin...@li... > > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > >--------------------------------------------------------------------- > > >-- > > >--- > > >---- > > >Android is increasing in popularity, but the open development > > >platform that developers love is also attractive to malware creators. > > >Download this white paper to learn more about secure code signing > > >practices that can help keep Android apps secure. > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > stg.cl > > >ktr > > >k > > >_______________________________________________ > > >Linuxptp-users mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > >--------------------------------------------------------------------- > > >-- > > >--- > > >---- > > >Android is increasing in popularity, but the open development > > >platform that developers love is also attractive to malware creators. > > >Download this white paper to learn more about secure code signing > > >practices that can help keep Android apps secure. > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > stg.cl > > >ktr > > >k > > >_______________________________________________ > > >Linuxptp-users mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > ---------------------------------------------------------------------- > > -------- Android is increasing in popularity, but the open development > > platform that developers love is also attractive to malware creators. > > Download this white paper to learn more about secure code signing > > practices that can help keep Android apps secure. > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > g.clktrk > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > The information transmitted herein is intended only for the person or > > entity to which it is addressed and may contain confidential and/or > > privileged material. This message is not a recommendation, offer or > > solicitation to buy or sell anything. Any examples, prices or > > quotations contained herein are indicative only and an order based on > > such information can only be executed through a duly registered > > broker/dealer or futures commission merchant. Any review, > > retransmission, dissemination or other use of, or taking of any action > > in reliance upon, this information is prohibited. If you received this > > in error, please contact the sender and delete the material from any > computer. > > OneChicago, LLC is a Delaware limited liability company. > > The information transmitted herein is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. This message is not a recommendation, offer or > solicitation to buy or sell anything. Any examples, prices or quotations > contained herein are indicative only and an order based on such > information can only be executed through a duly registered > broker/dealer or futures commission merchant. Any review, > retransmission, dissemination or other use of, or taking of any action in > reliance upon, this information is prohibited. If you received this in error, > please contact the sender and delete the material from any computer. > OneChicago, LLC is a Delaware limited liability company. |
|
From: Gabe B. <Gab...@jd...> - 2013-10-29 19:14:18
|
I installed opensuse 12.3. It didn't seem to come with linuxptp (ptp4l) and instead comes with ptpd. However, the kernel did have the native PTP support. I downloaded linuxptp and compiled and ptp4l worked without a hitch on the exact same VM. It appears to perform very well. Thanks! Gabe > -----Original Message----- > From: Trudeau, Brian [mailto:btr...@On...] > Sent: Tuesday, October 29, 2013 1:09 PM > To: Ledda William EXT; Keller, Jacob E; Vick, Matthew; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > We're attempting to work with the base redhat kernel without > recompiling, when you plan to work with 100s(sure there are case with > some of you 1000s) of servers you don't want to have to create your own > little patch repo and also drop any support you'll have with redhat... > > Brian Trudeau > > > -----Original Message----- > From: Ledda William EXT [mailto:Wil...@it...] > Sent: Tuesday, October 29, 2013 1:09 PM > To: Keller, Jacob E; Trudeau, Brian; Vick, Matthew; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > It's curious that you can't work with RH 6.4 and i350... I'm the only > "lucky" guy that can works with RH 6.4 and i350 without issues? > How is the network configuration? On RH could be required to modify the > rp_filter configuration in some cases > https://access.redhat.com/site/solutions/53031 > > I used also a Broadcom NetXtreme BCM5719 chipset. I have installed the > tg3 driver provided by Broadcom (since that one included in RH > distribution didn't have PHC support) and it works even with HW time > stamping. > > Again, the only trouble that I had was related to the firewall enabled! > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: 29 October 2013 18:04 > To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > Redhat 6.4 would have to be a backport of the PTP code which is > probably troublesome. > > Likely, the in kernel driver in their 2.6.32+patches kernel is causing > the poll to time out. > > I doubt the kernel compatability layer for the sourceforge driver has > code for Redhat 6.4 to enable PTP (as it's not enabled by default) and > I believe it does some static checking against 3.0 kernel version. > > I would suggest trying on a newer distribution. > > Regards, > Jake > > > -----Original Message----- > > From: Trudeau, Brian [mailto:btr...@On...] > > Sent: Tuesday, October 29, 2013 8:57 AM > > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > I've been having this same issue with the redhat built version as > > well, I've contacted support and they just brushed it off as being a > > technical preview and is nether supported or guarantee it to be > > supported in any future release as well. I think they are having > > issues back porting as you said... > > > > Brian Trudeau > > > > > > -----Original Message----- > > From: Vick, Matthew [mailto:mat...@in...] > > Sent: Tuesday, October 29, 2013 10:08 AM > > To: Ledda William EXT; Gabe Black; Keller, Jacob E > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] Which distributions have native ptp > > support? > > > > Gabe, > > > > To chime in as well, if you continue to have problems I would > > recommend filing a Bugzilla with Red Hat. They own the version of igb > > and ptp4l included in their kernel and it could be something else in > > their stack interfering specifically with your configuration. > > > > Another option for you to try is the latest version of igb from > > SourceForge > > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > > that works for you. > > > > I'm not sure what all the VM changes (other than obviously > introducing > > some delay around when the app can run), but I would hope the device > > continues to operate correctly. > > > > Cheers, > > Matthew > > > > Matthew Vick > > Linux Development > > Networking Division > > Intel Corporation > > > > > > On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> > > wrote: > > > > >Dear all, > > >Have you check the firewall? Is it enabled? The only problem that I > > >had > > >(initially) was related to the firewall. After disabling the > firewall > > >everything works! > > > > > >I worked without problem with the version released with RH 6.4 > > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work > > with > > >1.2 and now I'm working with 1.3 without any problem. > > >How do you have compiled version 1.3? Do you have disabled the one > > step > > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? > > Base > > >kernel > > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, > > so in > > >order to compile, you should define this symbol or change the sk.c > in > > >order to don't check for one step clocks. > > > > > >My syetem configuration: > > > > > >$ uname -a > > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP > > >Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > > > >$ ethtool -i eth1 > > >driver: igb > > >version: 4.0.1-k > > >firmware-version: 1.61, 0x090f8000 > > >bus-info: 0000:10:00.1 > > >supports-statistics: yes > > >supports-test: yes > > >supports-eeprom-access: yes > > >supports-register-dump: yes > > >supports-priv-flags: no > > > > > >$ ethtool -T eth1 > > >Time stamping parameters for eth1: > > >Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > >PTP Hardware Clock: 1 > > >Hardware Transmit Timestamp Modes: > > > off (HWTSTAMP_TX_OFF) > > > on (HWTSTAMP_TX_ON) > > >Hardware Receive Filter Modes: > > > none (HWTSTAMP_FILTER_NONE) > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > > >-----Original Message----- > > >From: Gabe Black [mailto:Gab...@jd...] > > >Sent: 29 October 2013 01:18 > > >To: Gabe Black; Keller, Jacob E > > >Cc: lin...@li... > > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > > support? > > > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > > >same, except now poll times out. I have increased the timeout and > > >even modified the code to see what packet was getting transmitted to > > >verify things. > > > > > >I verified that in wireshark I see the delay req message go out, and > > >the delay response as well. > > > > > >Looking at the code and reading > > Documentation/networking/timestamping > > >it looks like the code is trying to get the transmit timestamp of > the > > >packet which is expected to be found in the socket error queue. > > > > > >So this leads me to believe that the timestamp is simply not making > > >it in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > > >kernel/install and the igb driver seems to have support for it as > > >shown > > below: > > > > > >ethtool -T eth3 > > >Time stamping parameters for eth3: > > >Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > >PTP Hardware Clock: 1 > > >Hardware Transmit Timestamp Modes: > > > off (HWTSTAMP_TX_OFF) > > > on (HWTSTAMP_TX_ON) > > >Hardware Receive Filter Modes: > > > none (HWTSTAMP_FILTER_NONE) > > > all (HWTSTAMP_FILTER_ALL) > > > > > >ethtool -I eth3 > > >driver: igb > > >version: 4.0.1-k > > > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > > >bunch of work to back-port the stuff to get things like "ethtool -T" > > >to work. Probably still buggy... > > > > > >Anyway, not sure what William did to get it to work... I think I am > > >going to just switch to a different distribution that has it > > >supported out of the box as well. Apparently on this thread Fedora > > >19 and OpenSuse have it. > > > > > >Oh, I am running in a virtualized environment using DirectPath I/O > > >(a.k.a > > >"passthrough") to assign the I350 driver directly to the VM. Maybe > > >that matters; but I'm fairly certain that DirectPath presents the > > >hardware registers/configuration in all its glory to the VM, thus > > >letting the igb-driver operate the device. The software is the > same, > > >so we should be getting timestamps... > > > > > >Oh well, on to the next distribution! > > > > > >Thanks! > > >Gabe > > > > > > > > > > > >> -----Original Message----- > > >> From: Gabe Black [mailto:Gab...@jd...] > > >> Sent: Monday, October 28, 2013 5:19 PM > > >> To: Keller, Jacob E > > >> Cc: lin...@li... > > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > > >> support? > > >> > > >> I am using the version that comes with a fresh install of the RH > > >> 6.4 > > >> release: > > >> > > >> rpm -qa | grep ptp > > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > > >> > > >> ptp4l doesn't appear to have a version option (in this release) > and > > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > > either. > > >> > > >> At any rate, I will get the latest version and try that and > report. > > >> > > >> Thank you for the feedback! > > >> > > >> > -----Original Message----- > > >> > From: Keller, Jacob E [mailto:jac...@in...] > > >> > Sent: Monday, October 28, 2013 4:37 PM > > >> > To: Gabe Black > > >> > Cc: Ledda William EXT; lin...@li... > > >> > Subject: Re: [Linuxptp-users] Which distributions have native > ptp > > >> > support? > > >> > > > >> > What version of linuxPTP are you using? > > >> > > > >> > It appears you aren't using the 1.3 version as we moved to a > > >> > method for obtaining the Tx timestamp that uses the poll() call. > > >> > That might fix your issue. > > >> > > > >> > The other option would be to increase the tx_timestamp_timeout > > >> > value, but I think moving to the newest Linux PTP should be a > fix. > > >> > > > >> > Regards, > > >> > Jake > > >> > > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > > >> > > Nm, it was right. We have two subnets that will route to the > > >> > meinberg, and they both work... So that means I still I don't > > >> > know what it is... > > >> > > > > >> > > strace it shows: > > >> > > sendto(11, > > >> > > > > >> > > > >> > > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > > 3\0\1 > > >> \ > > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > > >> > > 44 > > >> > > Followed by a bunch of: > > >> > > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > > temporarily unavailable) ... > > >> > > > > >> > > > > >> > > > > >> > > > -----Original Message----- > > >> > > > From: Gabe Black > > >> > > > Sent: Monday, October 28, 2013 2:20 PM > > >> > > > To: Gabe Black; 'Keller, Jacob E' > > >> > > > Cc: 'Ledda William EXT'; 'linuxptp- > us...@li...' > > >> > > > Subject: RE: [Linuxptp-users] Which distributions have > native > > >> > > > ptp support? > > >> > > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > > >> > > > > > >> > > > It is working now! > > >> > > > > > >> > > > > -----Original Message----- > > >> > > > > From: Gabe Black > > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > > >> > > > > To: 'Keller, Jacob E' > > >> > > > > Cc: Ledda William EXT; linuxptp- > us...@li... > > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > > >> > > > > native ptp support? > > >> > > > > > > >> > > > > > -----Original Message----- > > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] > > >> > > > > > You shouldn't have to, however, I would suggest > disabling > > >> > > > > > EEE support, as this has been known to cause issues on > > >> > > > > > the i350 > > >> > > > > > > > >> > > > > > ethtool --set-eee device eee off > > >> > > > > > > > >> > > > > > This should fix your issue, if not please me know. > > >> > > > > > > >> > > > > Thank you for the reply. > > >> > > > > > > >> > > > > That option does not appear to be available with the stock > > >> > > > > igb driver of RH6.4 > > >> > > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > > >> > > > > driver: igb > > >> > > > > version: 4.0.1-k > > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot > get > > >> > > > > EEE > > >> > > > > settings: Operation not supported > > >> > > > > > > >> > > > > Is there another way to disable EEE? Or would not having > > >> > > > > that option in ethtool mean it is off? > > >> > > > > > > >> > > > > Gabe > > >> > > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > > >> > > > > > > Hi William, > > >> > > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with > > >> > > > > > > igb > > >> > > > > > > driver) > > >> > > > > and > > >> > > > > > am having trouble getting it to work with a meinberg > master. > > >> > > > > > > > > >> > > > > > > The output I get is: > > >> > > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING > on > > >> > > > INITIALIZE > > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING > on > > >> > > > INITIALIZE > > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > > >> > > > > > > 00606e.fffe.7c230e- > > >> > > > 1 > > >> > > > > > > ptp4l[246985.014]: selected best master clock > > >> > > > > > > 00606e.fffe.7c230e > > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > > >> > > > > > > timescale > > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED > on > > >> > > > > > > RS_SLAVE > > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > > >> > > > > > > Resource > > >> > > > > temporarily > > >> > > > > > > unavailable > > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on > > >> > > > > > > FAULT_DETECTED > > >> > > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > > >> > > > > > > RH6.4 > > >> > > > install > > >> > > > > > > to > > >> > > > > > get it to work? > > >> > > > > > > > > >> > > > > > > Thanks, > > >> > > > > > > Gabe > > >> > > > > > > > > >> > > > > > > > -----Original Message----- > > >> > > > > > > > From: Ledda William EXT > > >> > > > > > > > [mailto:Wil...@it...] > > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > > >> > > > > > > > To: Richard Cochran; Gabe Black > > >> > > > > > > > Cc: lin...@li... > > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > > >> > > > > > > > have native ptp support? > > >> > > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > > >> > > > > > > > driver) > > >> > with > > >> > > > > > success > > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > > >> > > > > > > > know that there will be many improvements, more eth > > >> > > > > > > > driver supported, and it should include version 1.3 > > >> > > > > > > > of linuxptp > > >> package. > > >> > > > > > > > > > >> > > > > > > > William > > >> > > > > > > > > > >> > > > > >> > > > >> > > >> ------------------------------------------------------------------ > - > > >> -- > > >> - > > >> - > > >> ------- > > >> Android is increasing in popularity, but the open development > > >> platform that developers love is also attractive to malware > creators. > > >> Download this white paper to learn more about secure code signing > > >> practices that can help keep Android apps secure. > > >> > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > g. > > >> c > > >> l > > >> ktrk > > >> _______________________________________________ > > >> Linuxptp-users mailing list > > >> Lin...@li... > > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > >-------------------------------------------------------------------- > - > > >-- > > >--- > > >---- > > >Android is increasing in popularity, but the open development > > >platform that developers love is also attractive to malware > creators. > > >Download this white paper to learn more about secure code signing > > >practices that can help keep Android apps secure. > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > stg.cl > > >ktr > > >k > > >_______________________________________________ > > >Linuxptp-users mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > >-------------------------------------------------------------------- > - > > >-- > > >--- > > >---- > > >Android is increasing in popularity, but the open development > > >platform that developers love is also attractive to malware > creators. > > >Download this white paper to learn more about secure code signing > > >practices that can help keep Android apps secure. > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > stg.cl > > >ktr > > >k > > >_______________________________________________ > > >Linuxptp-users mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > --------------------------------------------------------------------- > - > > -------- Android is increasing in popularity, but the open > development > > platform that developers love is also attractive to malware creators. > > Download this white paper to learn more about secure code signing > > practices that can help keep Android apps secure. > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > g.clktrk > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > The information transmitted herein is intended only for the person or > > entity to which it is addressed and may contain confidential and/or > > privileged material. This message is not a recommendation, offer or > > solicitation to buy or sell anything. Any examples, prices or > > quotations contained herein are indicative only and an order based on > > such information can only be executed through a duly registered > > broker/dealer or futures commission merchant. Any review, > > retransmission, dissemination or other use of, or taking of any > action > > in reliance upon, this information is prohibited. If you received > this > > in error, please contact the sender and delete the material from any > computer. > > OneChicago, LLC is a Delaware limited liability company. > > The information transmitted herein is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. This message is not a recommendation, offer or > solicitation to buy or sell anything. Any examples, prices or > quotations contained herein are indicative only and an order based on > such information can only be executed through a duly registered > broker/dealer or futures commission merchant. Any review, > retransmission, dissemination or other use of, or taking of any action > in reliance upon, this information is prohibited. If you received this > in error, please contact the sender and delete the material from any > computer. OneChicago, LLC is a Delaware limited liability company. |
|
From: Trudeau, B. <btr...@On...> - 2013-10-29 19:08:47
|
We're attempting to work with the base redhat kernel without recompiling, when you plan to work with 100s(sure there are case with some of you 1000s) of servers you don't want to have to create your own little patch repo and also drop any support you'll have with redhat... Brian Trudeau -----Original Message----- From: Ledda William EXT [mailto:Wil...@it...] Sent: Tuesday, October 29, 2013 1:09 PM To: Keller, Jacob E; Trudeau, Brian; Vick, Matthew; Gabe Black Cc: lin...@li... Subject: RE: [Linuxptp-users] Which distributions have native ptp support? It's curious that you can't work with RH 6.4 and i350... I'm the only "lucky" guy that can works with RH 6.4 and i350 without issues? How is the network configuration? On RH could be required to modify the rp_filter configuration in some cases https://access.redhat.com/site/solutions/53031 I used also a Broadcom NetXtreme BCM5719 chipset. I have installed the tg3 driver provided by Broadcom (since that one included in RH distribution didn't have PHC support) and it works even with HW time stamping. Again, the only trouble that I had was related to the firewall enabled! -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: 29 October 2013 18:04 To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black Cc: lin...@li... Subject: RE: [Linuxptp-users] Which distributions have native ptp support? Redhat 6.4 would have to be a backport of the PTP code which is probably troublesome. Likely, the in kernel driver in their 2.6.32+patches kernel is causing the poll to time out. I doubt the kernel compatability layer for the sourceforge driver has code for Redhat 6.4 to enable PTP (as it's not enabled by default) and I believe it does some static checking against 3.0 kernel version. I would suggest trying on a newer distribution. Regards, Jake > -----Original Message----- > From: Trudeau, Brian [mailto:btr...@On...] > Sent: Tuesday, October 29, 2013 8:57 AM > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > I've been having this same issue with the redhat built version as > well, I've contacted support and they just brushed it off as being a > technical preview and is nether supported or guarantee it to be > supported in any future release as well. I think they are having > issues back porting as you said... > > Brian Trudeau > > > -----Original Message----- > From: Vick, Matthew [mailto:mat...@in...] > Sent: Tuesday, October 29, 2013 10:08 AM > To: Ledda William EXT; Gabe Black; Keller, Jacob E > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Which distributions have native ptp > support? > > Gabe, > > To chime in as well, if you continue to have problems I would > recommend filing a Bugzilla with Red Hat. They own the version of igb > and ptp4l included in their kernel and it could be something else in > their stack interfering specifically with your configuration. > > Another option for you to try is the latest version of igb from > SourceForge > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > that works for you. > > I'm not sure what all the VM changes (other than obviously introducing > some delay around when the app can run), but I would hope the device > continues to operate correctly. > > Cheers, > Matthew > > Matthew Vick > Linux Development > Networking Division > Intel Corporation > > > On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> > wrote: > > >Dear all, > >Have you check the firewall? Is it enabled? The only problem that I > >had > >(initially) was related to the firewall. After disabling the firewall > >everything works! > > > >I worked without problem with the version released with RH 6.4 > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work > with > >1.2 and now I'm working with 1.3 without any problem. > >How do you have compiled version 1.3? Do you have disabled the one > step > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? > Base > >kernel > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, > so in > >order to compile, you should define this symbol or change the sk.c in > >order to don't check for one step clocks. > > > >My syetem configuration: > > > >$ uname -a > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP > >Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > >$ ethtool -i eth1 > >driver: igb > >version: 4.0.1-k > >firmware-version: 1.61, 0x090f8000 > >bus-info: 0000:10:00.1 > >supports-statistics: yes > >supports-test: yes > >supports-eeprom-access: yes > >supports-register-dump: yes > >supports-priv-flags: no > > > >$ ethtool -T eth1 > >Time stamping parameters for eth1: > >Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > >PTP Hardware Clock: 1 > >Hardware Transmit Timestamp Modes: > > off (HWTSTAMP_TX_OFF) > > on (HWTSTAMP_TX_ON) > >Hardware Receive Filter Modes: > > none (HWTSTAMP_FILTER_NONE) > > all (HWTSTAMP_FILTER_ALL) > > > > > >-----Original Message----- > >From: Gabe Black [mailto:Gab...@jd...] > >Sent: 29 October 2013 01:18 > >To: Gabe Black; Keller, Jacob E > >Cc: lin...@li... > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > support? > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > >same, except now poll times out. I have increased the timeout and > >even modified the code to see what packet was getting transmitted to > >verify things. > > > >I verified that in wireshark I see the delay req message go out, and > >the delay response as well. > > > >Looking at the code and reading > Documentation/networking/timestamping > >it looks like the code is trying to get the transmit timestamp of the > >packet which is expected to be found in the socket error queue. > > > >So this leads me to believe that the timestamp is simply not making > >it in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > >kernel/install and the igb driver seems to have support for it as > >shown > below: > > > >ethtool -T eth3 > >Time stamping parameters for eth3: > >Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > >PTP Hardware Clock: 1 > >Hardware Transmit Timestamp Modes: > > off (HWTSTAMP_TX_OFF) > > on (HWTSTAMP_TX_ON) > >Hardware Receive Filter Modes: > > none (HWTSTAMP_FILTER_NONE) > > all (HWTSTAMP_FILTER_ALL) > > > >ethtool -I eth3 > >driver: igb > >version: 4.0.1-k > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > >bunch of work to back-port the stuff to get things like "ethtool -T" > >to work. Probably still buggy... > > > >Anyway, not sure what William did to get it to work... I think I am > >going to just switch to a different distribution that has it > >supported out of the box as well. Apparently on this thread Fedora > >19 and OpenSuse have it. > > > >Oh, I am running in a virtualized environment using DirectPath I/O > >(a.k.a > >"passthrough") to assign the I350 driver directly to the VM. Maybe > >that matters; but I'm fairly certain that DirectPath presents the > >hardware registers/configuration in all its glory to the VM, thus > >letting the igb-driver operate the device. The software is the same, > >so we should be getting timestamps... > > > >Oh well, on to the next distribution! > > > >Thanks! > >Gabe > > > > > > > >> -----Original Message----- > >> From: Gabe Black [mailto:Gab...@jd...] > >> Sent: Monday, October 28, 2013 5:19 PM > >> To: Keller, Jacob E > >> Cc: lin...@li... > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > >> support? > >> > >> I am using the version that comes with a fresh install of the RH > >> 6.4 > >> release: > >> > >> rpm -qa | grep ptp > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > >> > >> ptp4l doesn't appear to have a version option (in this release) and > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > either. > >> > >> At any rate, I will get the latest version and try that and report. > >> > >> Thank you for the feedback! > >> > >> > -----Original Message----- > >> > From: Keller, Jacob E [mailto:jac...@in...] > >> > Sent: Monday, October 28, 2013 4:37 PM > >> > To: Gabe Black > >> > Cc: Ledda William EXT; lin...@li... > >> > Subject: Re: [Linuxptp-users] Which distributions have native ptp > >> > support? > >> > > >> > What version of linuxPTP are you using? > >> > > >> > It appears you aren't using the 1.3 version as we moved to a > >> > method for obtaining the Tx timestamp that uses the poll() call. > >> > That might fix your issue. > >> > > >> > The other option would be to increase the tx_timestamp_timeout > >> > value, but I think moving to the newest Linux PTP should be a fix. > >> > > >> > Regards, > >> > Jake > >> > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > >> > > Nm, it was right. We have two subnets that will route to the > >> > meinberg, and they both work... So that means I still I don't > >> > know what it is... > >> > > > >> > > strace it shows: > >> > > sendto(11, > >> > > > >> > > >> > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > 3\0\1 > >> \ > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > >> > > 44 > >> > > Followed by a bunch of: > >> > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > > temporarily unavailable) ... > >> > > > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: Gabe Black > >> > > > Sent: Monday, October 28, 2013 2:20 PM > >> > > > To: Gabe Black; 'Keller, Jacob E' > >> > > > Cc: 'Ledda William EXT'; 'lin...@li...' > >> > > > Subject: RE: [Linuxptp-users] Which distributions have native > >> > > > ptp support? > >> > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > >> > > > > >> > > > It is working now! > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Gabe Black > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > >> > > > > To: 'Keller, Jacob E' > >> > > > > Cc: Ledda William EXT; lin...@li... > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > >> > > > > native ptp support? > >> > > > > > >> > > > > > -----Original Message----- > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] > >> > > > > > You shouldn't have to, however, I would suggest disabling > >> > > > > > EEE support, as this has been known to cause issues on > >> > > > > > the i350 > >> > > > > > > >> > > > > > ethtool --set-eee device eee off > >> > > > > > > >> > > > > > This should fix your issue, if not please me know. > >> > > > > > >> > > > > Thank you for the reply. > >> > > > > > >> > > > > That option does not appear to be available with the stock > >> > > > > igb driver of RH6.4 > >> > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > >> > > > > driver: igb > >> > > > > version: 4.0.1-k > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot get > >> > > > > EEE > >> > > > > settings: Operation not supported > >> > > > > > >> > > > > Is there another way to disable EEE? Or would not having > >> > > > > that option in ethtool mean it is off? > >> > > > > > >> > > > > Gabe > >> > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > >> > > > > > > Hi William, > >> > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with > >> > > > > > > igb > >> > > > > > > driver) > >> > > > > and > >> > > > > > am having trouble getting it to work with a meinberg master. > >> > > > > > > > >> > > > > > > The output I get is: > >> > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING on > >> > > > INITIALIZE > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING on > >> > > > INITIALIZE > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > >> > > > > > > 00606e.fffe.7c230e- > >> > > > 1 > >> > > > > > > ptp4l[246985.014]: selected best master clock > >> > > > > > > 00606e.fffe.7c230e > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > >> > > > > > > timescale > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED on > >> > > > > > > RS_SLAVE > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > >> > > > > > > Resource > >> > > > > temporarily > >> > > > > > > unavailable > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on > >> > > > > > > FAULT_DETECTED > >> > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > >> > > > > > > RH6.4 > >> > > > install > >> > > > > > > to > >> > > > > > get it to work? > >> > > > > > > > >> > > > > > > Thanks, > >> > > > > > > Gabe > >> > > > > > > > >> > > > > > > > -----Original Message----- > >> > > > > > > > From: Ledda William EXT > >> > > > > > > > [mailto:Wil...@it...] > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > >> > > > > > > > To: Richard Cochran; Gabe Black > >> > > > > > > > Cc: lin...@li... > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > >> > > > > > > > have native ptp support? > >> > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > >> > > > > > > > driver) > >> > with > >> > > > > > success > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > >> > > > > > > > know that there will be many improvements, more eth > >> > > > > > > > driver supported, and it should include version 1.3 > >> > > > > > > > of linuxptp > >> package. > >> > > > > > > > > >> > > > > > > > William > >> > > > > > > > > >> > > > >> > > >> > >> ------------------------------------------------------------------- > >> -- > >> - > >> - > >> ------- > >> Android is increasing in popularity, but the open development > >> platform that developers love is also attractive to malware creators. > >> Download this white paper to learn more about secure code signing > >> practices that can help keep Android apps secure. > >> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > g. > >> c > >> l > >> ktrk > >> _______________________________________________ > >> Linuxptp-users mailing list > >> Lin...@li... > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > >--------------------------------------------------------------------- > >-- > >--- > >---- > >Android is increasing in popularity, but the open development > >platform that developers love is also attractive to malware creators. > >Download this white paper to learn more about secure code signing > >practices that can help keep Android apps secure. > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > stg.cl > >ktr > >k > >_______________________________________________ > >Linuxptp-users mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > >--------------------------------------------------------------------- > >-- > >--- > >---- > >Android is increasing in popularity, but the open development > >platform that developers love is also attractive to malware creators. > >Download this white paper to learn more about secure code signing > >practices that can help keep Android apps secure. > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > stg.cl > >ktr > >k > >_______________________________________________ > >Linuxptp-users mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > ---------------------------------------------------------------------- > -------- Android is increasing in popularity, but the open development > platform that developers love is also attractive to malware creators. > Download this white paper to learn more about secure code signing > practices that can help keep Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > g.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > The information transmitted herein is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. This message is not a recommendation, offer or > solicitation to buy or sell anything. Any examples, prices or > quotations contained herein are indicative only and an order based on > such information can only be executed through a duly registered > broker/dealer or futures commission merchant. Any review, > retransmission, dissemination or other use of, or taking of any action > in reliance upon, this information is prohibited. If you received this > in error, please contact the sender and delete the material from any computer. > OneChicago, LLC is a Delaware limited liability company. The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. This message is not a recommendation, offer or solicitation to buy or sell anything. Any examples, prices or quotations contained herein are indicative only and an order based on such information can only be executed through a duly registered broker/dealer or futures commission merchant. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. OneChicago, LLC is a Delaware limited liability company. |
|
From: Keller, J. E <jac...@in...> - 2013-10-29 18:41:01
|
The poll error is due to the driver software not responding within the time limit. However, you said you increased the poll timeout value? In this case the issue is simply that the timestamp did not occur properly. It is likely a bug in the driver that causes this. It would be best if you could use the sourceforge version, but it appears to not work properly due to backport issues with the PTP core. If possible, please try after updating the kernel package with any recent RH64 updates. I would bet that they could have fixed bugs in the driver in an update. Regards, Jake > -----Original Message----- > From: Gabe Black [mailto:Gab...@jd...] > Sent: Tuesday, October 29, 2013 11:27 AM > To: Ledda William EXT; Keller, Jacob E; Trudeau, Brian; Vick, Matthew > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > Firewall was the first thing I checked... so it wasn't the firewall. Besides, > looking at the code, the error is not in receiving the packet, but rather > trying to get the timestamp of the packet that was sent out. It seems that > the timestamp is just not making it in to the MSG_ERRQUEUE. > > Two things I can think of that might be different: 1) I'm running in a VM > (under VmWare ESX 5.1), and 2) I didn't apply any of the RH64 updates > (just used initial 6.4 release installation). > > Network configuration is simple, with no asymmetric routes. > > Anyway, I've blown away the VM and am trying opensuse 12.3 right now... > > Gabe > > > -----Original Message----- > > From: Ledda William EXT [mailto:Wil...@it...] > > Sent: Tuesday, October 29, 2013 12:09 PM > > To: Keller, Jacob E; Trudeau, Brian; Vick, Matthew; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > It's curious that you can't work with RH 6.4 and i350... I'm the only > > "lucky" guy that can works with RH 6.4 and i350 without issues? > > How is the network configuration? On RH could be required to modify > the > > rp_filter configuration in some cases > > https://access.redhat.com/site/solutions/53031 > > > > I used also a Broadcom NetXtreme BCM5719 chipset. I have installed > the > > tg3 driver provided by Broadcom (since that one included in RH > > distribution didn't have PHC support) and it works even with HW time > > stamping. > > > > Again, the only trouble that I had was related to the firewall enabled! > > > > -----Original Message----- > > From: Keller, Jacob E [mailto:jac...@in...] > > Sent: 29 October 2013 18:04 > > To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > Redhat 6.4 would have to be a backport of the PTP code which is > > probably troublesome. > > > > Likely, the in kernel driver in their 2.6.32+patches kernel is causing > > the poll to time out. > > > > I doubt the kernel compatability layer for the sourceforge driver has > > code for Redhat 6.4 to enable PTP (as it's not enabled by default) and > > I believe it does some static checking against 3.0 kernel version. > > > > I would suggest trying on a newer distribution. > > > > Regards, > > Jake > > > > > -----Original Message----- > > > From: Trudeau, Brian [mailto:btr...@On...] > > > Sent: Tuesday, October 29, 2013 8:57 AM > > > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > > > Cc: lin...@li... > > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > I've been having this same issue with the redhat built version as > > > well, I've contacted support and they just brushed it off as being a > > > technical preview and is nether supported or guarantee it to be > > > supported in any future release as well. I think they are having > > > issues back porting as you said... > > > > > > Brian Trudeau > > > > > > > > > -----Original Message----- > > > From: Vick, Matthew [mailto:mat...@in...] > > > Sent: Tuesday, October 29, 2013 10:08 AM > > > To: Ledda William EXT; Gabe Black; Keller, Jacob E > > > Cc: lin...@li... > > > Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > Gabe, > > > > > > To chime in as well, if you continue to have problems I would > > > recommend filing a Bugzilla with Red Hat. They own the version of igb > > > and ptp4l included in their kernel and it could be something else in > > > their stack interfering specifically with your configuration. > > > > > > Another option for you to try is the latest version of igb from > > > SourceForge > > > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > > > that works for you. > > > > > > I'm not sure what all the VM changes (other than obviously > > introducing > > > some delay around when the app can run), but I would hope the > device > > > continues to operate correctly. > > > > > > Cheers, > > > Matthew > > > > > > Matthew Vick > > > Linux Development > > > Networking Division > > > Intel Corporation > > > > > > > > > On 10/29/13, 1:11 AM, "Ledda William EXT" > <Wil...@it...> > > > wrote: > > > > > > >Dear all, > > > >Have you check the firewall? Is it enabled? The only problem that I > > > >had > > > >(initially) was related to the firewall. After disabling the > > firewall > > > >everything works! > > > > > > > >I worked without problem with the version released with RH 6.4 > > > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also > work > > > with > > > >1.2 and now I'm working with 1.3 without any problem. > > > >How do you have compiled version 1.3? Do you have disabled the > one > > > step > > > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC > symbol? > > > Base > > > >kernel > > > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in > linux/net_tstamp.h, > > > so in > > > >order to compile, you should define this symbol or change the sk.c > > in > > > >order to don't check for one step clocks. > > > > > > > >My syetem configuration: > > > > > > > >$ uname -a > > > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP > > > >Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > > > > > >$ ethtool -i eth1 > > > >driver: igb > > > >version: 4.0.1-k > > > >firmware-version: 1.61, 0x090f8000 > > > >bus-info: 0000:10:00.1 > > > >supports-statistics: yes > > > >supports-test: yes > > > >supports-eeprom-access: yes > > > >supports-register-dump: yes > > > >supports-priv-flags: no > > > > > > > >$ ethtool -T eth1 > > > >Time stamping parameters for eth1: > > > >Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > >PTP Hardware Clock: 1 > > > >Hardware Transmit Timestamp Modes: > > > > off (HWTSTAMP_TX_OFF) > > > > on (HWTSTAMP_TX_ON) > > > >Hardware Receive Filter Modes: > > > > none (HWTSTAMP_FILTER_NONE) > > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > > > > > >-----Original Message----- > > > >From: Gabe Black [mailto:Gab...@jd...] > > > >Sent: 29 October 2013 01:18 > > > >To: Gabe Black; Keller, Jacob E > > > >Cc: lin...@li... > > > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > support? > > > > > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > > > >same, except now poll times out. I have increased the timeout and > > > >even modified the code to see what packet was getting transmitted > to > > > >verify things. > > > > > > > >I verified that in wireshark I see the delay req message go out, and > > > >the delay response as well. > > > > > > > >Looking at the code and reading > > > Documentation/networking/timestamping > > > >it looks like the code is trying to get the transmit timestamp of > > the > > > >packet which is expected to be found in the socket error queue. > > > > > > > >So this leads me to believe that the timestamp is simply not making > > > >it in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > > > >kernel/install and the igb driver seems to have support for it as > > > >shown > > > below: > > > > > > > >ethtool -T eth3 > > > >Time stamping parameters for eth3: > > > >Capabilities: > > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > > >PTP Hardware Clock: 1 > > > >Hardware Transmit Timestamp Modes: > > > > off (HWTSTAMP_TX_OFF) > > > > on (HWTSTAMP_TX_ON) > > > >Hardware Receive Filter Modes: > > > > none (HWTSTAMP_FILTER_NONE) > > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > >ethtool -I eth3 > > > >driver: igb > > > >version: 4.0.1-k > > > > > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > > > >bunch of work to back-port the stuff to get things like "ethtool -T" > > > >to work. Probably still buggy... > > > > > > > >Anyway, not sure what William did to get it to work... I think I am > > > >going to just switch to a different distribution that has it > > > >supported out of the box as well. Apparently on this thread Fedora > > > >19 and OpenSuse have it. > > > > > > > >Oh, I am running in a virtualized environment using DirectPath I/O > > > >(a.k.a > > > >"passthrough") to assign the I350 driver directly to the VM. Maybe > > > >that matters; but I'm fairly certain that DirectPath presents the > > > >hardware registers/configuration in all its glory to the VM, thus > > > >letting the igb-driver operate the device. The software is the > > same, > > > >so we should be getting timestamps... > > > > > > > >Oh well, on to the next distribution! > > > > > > > >Thanks! > > > >Gabe > > > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Gabe Black [mailto:Gab...@jd...] > > > >> Sent: Monday, October 28, 2013 5:19 PM > > > >> To: Keller, Jacob E > > > >> Cc: lin...@li... > > > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > > > >> support? > > > >> > > > >> I am using the version that comes with a fresh install of the RH > > > >> 6.4 > > > >> release: > > > >> > > > >> rpm -qa | grep ptp > > > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > > > >> > > > >> ptp4l doesn't appear to have a version option (in this release) > > and > > > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > > > either. > > > >> > > > >> At any rate, I will get the latest version and try that and > > report. > > > >> > > > >> Thank you for the feedback! > > > >> > > > >> > -----Original Message----- > > > >> > From: Keller, Jacob E [mailto:jac...@in...] > > > >> > Sent: Monday, October 28, 2013 4:37 PM > > > >> > To: Gabe Black > > > >> > Cc: Ledda William EXT; lin...@li... > > > >> > Subject: Re: [Linuxptp-users] Which distributions have native > > ptp > > > >> > support? > > > >> > > > > >> > What version of linuxPTP are you using? > > > >> > > > > >> > It appears you aren't using the 1.3 version as we moved to a > > > >> > method for obtaining the Tx timestamp that uses the poll() call. > > > >> > That might fix your issue. > > > >> > > > > >> > The other option would be to increase the > tx_timestamp_timeout > > > >> > value, but I think moving to the newest Linux PTP should be a > > fix. > > > >> > > > > >> > Regards, > > > >> > Jake > > > >> > > > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > > > >> > > Nm, it was right. We have two subnets that will route to the > > > >> > meinberg, and they both work... So that means I still I don't > > > >> > know what it is... > > > >> > > > > > >> > > strace it shows: > > > >> > > sendto(11, > > > >> > > > > > >> > > > > >> > > > > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > > > 3\0\1 > > > >> \ > > > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > > > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > > > >> > > 44 > > > >> > > Followed by a bunch of: > > > >> > > > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > temporarily unavailable) > > > >> > > nanosleep({0, 1000}, NULL) = 0 > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > > (Resource > > > >> > > temporarily unavailable) ... > > > >> > > > > > >> > > > > > >> > > > > > >> > > > -----Original Message----- > > > >> > > > From: Gabe Black > > > >> > > > Sent: Monday, October 28, 2013 2:20 PM > > > >> > > > To: Gabe Black; 'Keller, Jacob E' > > > >> > > > Cc: 'Ledda William EXT'; 'linuxptp- > > us...@li...' > > > >> > > > Subject: RE: [Linuxptp-users] Which distributions have > > native > > > >> > > > ptp support? > > > >> > > > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > > > >> > > > > > > >> > > > It is working now! > > > >> > > > > > > >> > > > > -----Original Message----- > > > >> > > > > From: Gabe Black > > > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > > > >> > > > > To: 'Keller, Jacob E' > > > >> > > > > Cc: Ledda William EXT; linuxptp- > > us...@li... > > > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > > > >> > > > > native ptp support? > > > >> > > > > > > > >> > > > > > -----Original Message----- > > > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] > > > >> > > > > > You shouldn't have to, however, I would suggest > > disabling > > > >> > > > > > EEE support, as this has been known to cause issues on > > > >> > > > > > the i350 > > > >> > > > > > > > > >> > > > > > ethtool --set-eee device eee off > > > >> > > > > > > > > >> > > > > > This should fix your issue, if not please me know. > > > >> > > > > > > > >> > > > > Thank you for the reply. > > > >> > > > > > > > >> > > > > That option does not appear to be available with the stock > > > >> > > > > igb driver of RH6.4 > > > >> > > > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > > > >> > > > > driver: igb > > > >> > > > > version: 4.0.1-k > > > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > > > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot > > get > > > >> > > > > EEE > > > >> > > > > settings: Operation not supported > > > >> > > > > > > > >> > > > > Is there another way to disable EEE? Or would not having > > > >> > > > > that option in ethtool mean it is off? > > > >> > > > > > > > >> > > > > Gabe > > > >> > > > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > > > >> > > > > > > Hi William, > > > >> > > > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with > > > >> > > > > > > igb > > > >> > > > > > > driver) > > > >> > > > > and > > > >> > > > > > am having trouble getting it to work with a meinberg > > master. > > > >> > > > > > > > > > >> > > > > > > The output I get is: > > > >> > > > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > > > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING > > on > > > >> > > > INITIALIZE > > > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING > > on > > > >> > > > INITIALIZE > > > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > > > >> > > > > > > 00606e.fffe.7c230e- > > > >> > > > 1 > > > >> > > > > > > ptp4l[246985.014]: selected best master clock > > > >> > > > > > > 00606e.fffe.7c230e > > > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > > > >> > > > > > > timescale > > > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > > > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to > UNCALIBRATED > > on > > > >> > > > > > > RS_SLAVE > > > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > > > >> > > > > > > Resource > > > >> > > > > temporarily > > > >> > > > > > > unavailable > > > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > > > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY > on > > > >> > > > > > > FAULT_DETECTED > > > >> > > > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > > > >> > > > > > > RH6.4 > > > >> > > > install > > > >> > > > > > > to > > > >> > > > > > get it to work? > > > >> > > > > > > > > > >> > > > > > > Thanks, > > > >> > > > > > > Gabe > > > >> > > > > > > > > > >> > > > > > > > -----Original Message----- > > > >> > > > > > > > From: Ledda William EXT > > > >> > > > > > > > [mailto:Wil...@it...] > > > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > > > >> > > > > > > > To: Richard Cochran; Gabe Black > > > >> > > > > > > > Cc: lin...@li... > > > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > > > >> > > > > > > > have native ptp support? > > > >> > > > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > > > >> > > > > > > > driver) > > > >> > with > > > >> > > > > > success > > > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > > > >> > > > > > > > know that there will be many improvements, more > eth > > > >> > > > > > > > driver supported, and it should include version 1.3 > > > >> > > > > > > > of linuxptp > > > >> package. > > > >> > > > > > > > > > > >> > > > > > > > William > > > >> > > > > > > > > > > >> > > > > > >> > > > > >> > > > >> ------------------------------------------------------------------ > > - > > > >> -- > > > >> - > > > >> - > > > >> ------- > > > >> Android is increasing in popularity, but the open development > > > >> platform that developers love is also attractive to malware > > creators. > > > >> Download this white paper to learn more about secure code > signing > > > >> practices that can help keep Android apps secure. > > > >> > > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > > g. > > > >> c > > > >> l > > > >> ktrk > > > >> _______________________________________________ > > > >> Linuxptp-users mailing list > > > >> Lin...@li... > > > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > >-------------------------------------------------------------------- > > - > > > >-- > > > >--- > > > >---- > > > >Android is increasing in popularity, but the open development > > > >platform that developers love is also attractive to malware > > creators. > > > >Download this white paper to learn more about secure code signing > > > >practices that can help keep Android apps secure. > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > > stg.cl > > > >ktr > > > >k > > > >_______________________________________________ > > > >Linuxptp-users mailing list > > > >Lin...@li... > > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > >-------------------------------------------------------------------- > > - > > > >-- > > > >--- > > > >---- > > > >Android is increasing in popularity, but the open development > > > >platform that developers love is also attractive to malware > > creators. > > > >Download this white paper to learn more about secure code signing > > > >practices that can help keep Android apps secure. > > > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > > stg.cl > > > >ktr > > > >k > > > >_______________________________________________ > > > >Linuxptp-users mailing list > > > >Lin...@li... > > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > > > > --------------------------------------------------------------------- > > - > > > -------- Android is increasing in popularity, but the open > > development > > > platform that developers love is also attractive to malware creators. > > > Download this white paper to learn more about secure code signing > > > practices that can help keep Android apps secure. > > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > > g.clktrk > > > _______________________________________________ > > > Linuxptp-users mailing list > > > Lin...@li... > > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > The information transmitted herein is intended only for the person or > > > entity to which it is addressed and may contain confidential and/or > > > privileged material. This message is not a recommendation, offer or > > > solicitation to buy or sell anything. Any examples, prices or > > > quotations contained herein are indicative only and an order based > on > > > such information can only be executed through a duly registered > > > broker/dealer or futures commission merchant. Any review, > > > retransmission, dissemination or other use of, or taking of any > > action > > > in reliance upon, this information is prohibited. If you received > > this > > > in error, please contact the sender and delete the material from any > > computer. > > > OneChicago, LLC is a Delaware limited liability company. |
|
From: Gabe B. <Gab...@jd...> - 2013-10-29 18:27:46
|
Firewall was the first thing I checked... so it wasn't the firewall. Besides, looking at the code, the error is not in receiving the packet, but rather trying to get the timestamp of the packet that was sent out. It seems that the timestamp is just not making it in to the MSG_ERRQUEUE. Two things I can think of that might be different: 1) I'm running in a VM (under VmWare ESX 5.1), and 2) I didn't apply any of the RH64 updates (just used initial 6.4 release installation). Network configuration is simple, with no asymmetric routes. Anyway, I've blown away the VM and am trying opensuse 12.3 right now... Gabe > -----Original Message----- > From: Ledda William EXT [mailto:Wil...@it...] > Sent: Tuesday, October 29, 2013 12:09 PM > To: Keller, Jacob E; Trudeau, Brian; Vick, Matthew; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > It's curious that you can't work with RH 6.4 and i350... I'm the only > "lucky" guy that can works with RH 6.4 and i350 without issues? > How is the network configuration? On RH could be required to modify the > rp_filter configuration in some cases > https://access.redhat.com/site/solutions/53031 > > I used also a Broadcom NetXtreme BCM5719 chipset. I have installed the > tg3 driver provided by Broadcom (since that one included in RH > distribution didn't have PHC support) and it works even with HW time > stamping. > > Again, the only trouble that I had was related to the firewall enabled! > > -----Original Message----- > From: Keller, Jacob E [mailto:jac...@in...] > Sent: 29 October 2013 18:04 > To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > Redhat 6.4 would have to be a backport of the PTP code which is > probably troublesome. > > Likely, the in kernel driver in their 2.6.32+patches kernel is causing > the poll to time out. > > I doubt the kernel compatability layer for the sourceforge driver has > code for Redhat 6.4 to enable PTP (as it's not enabled by default) and > I believe it does some static checking against 3.0 kernel version. > > I would suggest trying on a newer distribution. > > Regards, > Jake > > > -----Original Message----- > > From: Trudeau, Brian [mailto:btr...@On...] > > Sent: Tuesday, October 29, 2013 8:57 AM > > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > > Cc: lin...@li... > > Subject: RE: [Linuxptp-users] Which distributions have native ptp > > support? > > > > I've been having this same issue with the redhat built version as > > well, I've contacted support and they just brushed it off as being a > > technical preview and is nether supported or guarantee it to be > > supported in any future release as well. I think they are having > > issues back porting as you said... > > > > Brian Trudeau > > > > > > -----Original Message----- > > From: Vick, Matthew [mailto:mat...@in...] > > Sent: Tuesday, October 29, 2013 10:08 AM > > To: Ledda William EXT; Gabe Black; Keller, Jacob E > > Cc: lin...@li... > > Subject: Re: [Linuxptp-users] Which distributions have native ptp > > support? > > > > Gabe, > > > > To chime in as well, if you continue to have problems I would > > recommend filing a Bugzilla with Red Hat. They own the version of igb > > and ptp4l included in their kernel and it could be something else in > > their stack interfering specifically with your configuration. > > > > Another option for you to try is the latest version of igb from > > SourceForge > > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > > that works for you. > > > > I'm not sure what all the VM changes (other than obviously > introducing > > some delay around when the app can run), but I would hope the device > > continues to operate correctly. > > > > Cheers, > > Matthew > > > > Matthew Vick > > Linux Development > > Networking Division > > Intel Corporation > > > > > > On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> > > wrote: > > > > >Dear all, > > >Have you check the firewall? Is it enabled? The only problem that I > > >had > > >(initially) was related to the firewall. After disabling the > firewall > > >everything works! > > > > > >I worked without problem with the version released with RH 6.4 > > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work > > with > > >1.2 and now I'm working with 1.3 without any problem. > > >How do you have compiled version 1.3? Do you have disabled the one > > step > > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? > > Base > > >kernel > > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, > > so in > > >order to compile, you should define this symbol or change the sk.c > in > > >order to don't check for one step clocks. > > > > > >My syetem configuration: > > > > > >$ uname -a > > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP > > >Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > > > >$ ethtool -i eth1 > > >driver: igb > > >version: 4.0.1-k > > >firmware-version: 1.61, 0x090f8000 > > >bus-info: 0000:10:00.1 > > >supports-statistics: yes > > >supports-test: yes > > >supports-eeprom-access: yes > > >supports-register-dump: yes > > >supports-priv-flags: no > > > > > >$ ethtool -T eth1 > > >Time stamping parameters for eth1: > > >Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > >PTP Hardware Clock: 1 > > >Hardware Transmit Timestamp Modes: > > > off (HWTSTAMP_TX_OFF) > > > on (HWTSTAMP_TX_ON) > > >Hardware Receive Filter Modes: > > > none (HWTSTAMP_FILTER_NONE) > > > all (HWTSTAMP_FILTER_ALL) > > > > > > > > >-----Original Message----- > > >From: Gabe Black [mailto:Gab...@jd...] > > >Sent: 29 October 2013 01:18 > > >To: Gabe Black; Keller, Jacob E > > >Cc: lin...@li... > > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > > support? > > > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > > >same, except now poll times out. I have increased the timeout and > > >even modified the code to see what packet was getting transmitted to > > >verify things. > > > > > >I verified that in wireshark I see the delay req message go out, and > > >the delay response as well. > > > > > >Looking at the code and reading > > Documentation/networking/timestamping > > >it looks like the code is trying to get the transmit timestamp of > the > > >packet which is expected to be found in the socket error queue. > > > > > >So this leads me to believe that the timestamp is simply not making > > >it in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > > >kernel/install and the igb driver seems to have support for it as > > >shown > > below: > > > > > >ethtool -T eth3 > > >Time stamping parameters for eth3: > > >Capabilities: > > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > >PTP Hardware Clock: 1 > > >Hardware Transmit Timestamp Modes: > > > off (HWTSTAMP_TX_OFF) > > > on (HWTSTAMP_TX_ON) > > >Hardware Receive Filter Modes: > > > none (HWTSTAMP_FILTER_NONE) > > > all (HWTSTAMP_FILTER_ALL) > > > > > >ethtool -I eth3 > > >driver: igb > > >version: 4.0.1-k > > > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > > >bunch of work to back-port the stuff to get things like "ethtool -T" > > >to work. Probably still buggy... > > > > > >Anyway, not sure what William did to get it to work... I think I am > > >going to just switch to a different distribution that has it > > >supported out of the box as well. Apparently on this thread Fedora > > >19 and OpenSuse have it. > > > > > >Oh, I am running in a virtualized environment using DirectPath I/O > > >(a.k.a > > >"passthrough") to assign the I350 driver directly to the VM. Maybe > > >that matters; but I'm fairly certain that DirectPath presents the > > >hardware registers/configuration in all its glory to the VM, thus > > >letting the igb-driver operate the device. The software is the > same, > > >so we should be getting timestamps... > > > > > >Oh well, on to the next distribution! > > > > > >Thanks! > > >Gabe > > > > > > > > > > > >> -----Original Message----- > > >> From: Gabe Black [mailto:Gab...@jd...] > > >> Sent: Monday, October 28, 2013 5:19 PM > > >> To: Keller, Jacob E > > >> Cc: lin...@li... > > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > > >> support? > > >> > > >> I am using the version that comes with a fresh install of the RH > > >> 6.4 > > >> release: > > >> > > >> rpm -qa | grep ptp > > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > > >> > > >> ptp4l doesn't appear to have a version option (in this release) > and > > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > > either. > > >> > > >> At any rate, I will get the latest version and try that and > report. > > >> > > >> Thank you for the feedback! > > >> > > >> > -----Original Message----- > > >> > From: Keller, Jacob E [mailto:jac...@in...] > > >> > Sent: Monday, October 28, 2013 4:37 PM > > >> > To: Gabe Black > > >> > Cc: Ledda William EXT; lin...@li... > > >> > Subject: Re: [Linuxptp-users] Which distributions have native > ptp > > >> > support? > > >> > > > >> > What version of linuxPTP are you using? > > >> > > > >> > It appears you aren't using the 1.3 version as we moved to a > > >> > method for obtaining the Tx timestamp that uses the poll() call. > > >> > That might fix your issue. > > >> > > > >> > The other option would be to increase the tx_timestamp_timeout > > >> > value, but I think moving to the newest Linux PTP should be a > fix. > > >> > > > >> > Regards, > > >> > Jake > > >> > > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > > >> > > Nm, it was right. We have two subnets that will route to the > > >> > meinberg, and they both work... So that means I still I don't > > >> > know what it is... > > >> > > > > >> > > strace it shows: > > >> > > sendto(11, > > >> > > > > >> > > > >> > > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > > 3\0\1 > > >> \ > > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > > >> > > 44 > > >> > > Followed by a bunch of: > > >> > > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > temporarily unavailable) > > >> > > nanosleep({0, 1000}, NULL) = 0 > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > > (Resource > > >> > > temporarily unavailable) ... > > >> > > > > >> > > > > >> > > > > >> > > > -----Original Message----- > > >> > > > From: Gabe Black > > >> > > > Sent: Monday, October 28, 2013 2:20 PM > > >> > > > To: Gabe Black; 'Keller, Jacob E' > > >> > > > Cc: 'Ledda William EXT'; 'linuxptp- > us...@li...' > > >> > > > Subject: RE: [Linuxptp-users] Which distributions have > native > > >> > > > ptp support? > > >> > > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > > >> > > > > > >> > > > It is working now! > > >> > > > > > >> > > > > -----Original Message----- > > >> > > > > From: Gabe Black > > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > > >> > > > > To: 'Keller, Jacob E' > > >> > > > > Cc: Ledda William EXT; linuxptp- > us...@li... > > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > > >> > > > > native ptp support? > > >> > > > > > > >> > > > > > -----Original Message----- > > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] > > >> > > > > > You shouldn't have to, however, I would suggest > disabling > > >> > > > > > EEE support, as this has been known to cause issues on > > >> > > > > > the i350 > > >> > > > > > > > >> > > > > > ethtool --set-eee device eee off > > >> > > > > > > > >> > > > > > This should fix your issue, if not please me know. > > >> > > > > > > >> > > > > Thank you for the reply. > > >> > > > > > > >> > > > > That option does not appear to be available with the stock > > >> > > > > igb driver of RH6.4 > > >> > > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > > >> > > > > driver: igb > > >> > > > > version: 4.0.1-k > > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot > get > > >> > > > > EEE > > >> > > > > settings: Operation not supported > > >> > > > > > > >> > > > > Is there another way to disable EEE? Or would not having > > >> > > > > that option in ethtool mean it is off? > > >> > > > > > > >> > > > > Gabe > > >> > > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > > >> > > > > > > Hi William, > > >> > > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with > > >> > > > > > > igb > > >> > > > > > > driver) > > >> > > > > and > > >> > > > > > am having trouble getting it to work with a meinberg > master. > > >> > > > > > > > > >> > > > > > > The output I get is: > > >> > > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING > on > > >> > > > INITIALIZE > > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING > on > > >> > > > INITIALIZE > > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > > >> > > > > > > 00606e.fffe.7c230e- > > >> > > > 1 > > >> > > > > > > ptp4l[246985.014]: selected best master clock > > >> > > > > > > 00606e.fffe.7c230e > > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > > >> > > > > > > timescale > > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED > on > > >> > > > > > > RS_SLAVE > > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > > >> > > > > > > Resource > > >> > > > > temporarily > > >> > > > > > > unavailable > > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on > > >> > > > > > > FAULT_DETECTED > > >> > > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > > >> > > > > > > RH6.4 > > >> > > > install > > >> > > > > > > to > > >> > > > > > get it to work? > > >> > > > > > > > > >> > > > > > > Thanks, > > >> > > > > > > Gabe > > >> > > > > > > > > >> > > > > > > > -----Original Message----- > > >> > > > > > > > From: Ledda William EXT > > >> > > > > > > > [mailto:Wil...@it...] > > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > > >> > > > > > > > To: Richard Cochran; Gabe Black > > >> > > > > > > > Cc: lin...@li... > > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > > >> > > > > > > > have native ptp support? > > >> > > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > > >> > > > > > > > driver) > > >> > with > > >> > > > > > success > > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > > >> > > > > > > > know that there will be many improvements, more eth > > >> > > > > > > > driver supported, and it should include version 1.3 > > >> > > > > > > > of linuxptp > > >> package. > > >> > > > > > > > > > >> > > > > > > > William > > >> > > > > > > > > > >> > > > > >> > > > >> > > >> ------------------------------------------------------------------ > - > > >> -- > > >> - > > >> - > > >> ------- > > >> Android is increasing in popularity, but the open development > > >> platform that developers love is also attractive to malware > creators. > > >> Download this white paper to learn more about secure code signing > > >> practices that can help keep Android apps secure. > > >> > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > g. > > >> c > > >> l > > >> ktrk > > >> _______________________________________________ > > >> Linuxptp-users mailing list > > >> Lin...@li... > > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > >-------------------------------------------------------------------- > - > > >-- > > >--- > > >---- > > >Android is increasing in popularity, but the open development > > >platform that developers love is also attractive to malware > creators. > > >Download this white paper to learn more about secure code signing > > >practices that can help keep Android apps secure. > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > stg.cl > > >ktr > > >k > > >_______________________________________________ > > >Linuxptp-users mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > >-------------------------------------------------------------------- > - > > >-- > > >--- > > >---- > > >Android is increasing in popularity, but the open development > > >platform that developers love is also attractive to malware > creators. > > >Download this white paper to learn more about secure code signing > > >practices that can help keep Android apps secure. > > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > > stg.cl > > >ktr > > >k > > >_______________________________________________ > > >Linuxptp-users mailing list > > >Lin...@li... > > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > > > --------------------------------------------------------------------- > - > > -------- Android is increasing in popularity, but the open > development > > platform that developers love is also attractive to malware creators. > > Download this white paper to learn more about secure code signing > > practices that can help keep Android apps secure. > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > > g.clktrk > > _______________________________________________ > > Linuxptp-users mailing list > > Lin...@li... > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > > The information transmitted herein is intended only for the person or > > entity to which it is addressed and may contain confidential and/or > > privileged material. This message is not a recommendation, offer or > > solicitation to buy or sell anything. Any examples, prices or > > quotations contained herein are indicative only and an order based on > > such information can only be executed through a duly registered > > broker/dealer or futures commission merchant. Any review, > > retransmission, dissemination or other use of, or taking of any > action > > in reliance upon, this information is prohibited. If you received > this > > in error, please contact the sender and delete the material from any > computer. > > OneChicago, LLC is a Delaware limited liability company. |
|
From: Ledda W. E. <Wil...@it...> - 2013-10-29 18:09:39
|
It's curious that you can't work with RH 6.4 and i350... I'm the only "lucky" guy that can works with RH 6.4 and i350 without issues? How is the network configuration? On RH could be required to modify the rp_filter configuration in some cases https://access.redhat.com/site/solutions/53031 I used also a Broadcom NetXtreme BCM5719 chipset. I have installed the tg3 driver provided by Broadcom (since that one included in RH distribution didn't have PHC support) and it works even with HW time stamping. Again, the only trouble that I had was related to the firewall enabled! -----Original Message----- From: Keller, Jacob E [mailto:jac...@in...] Sent: 29 October 2013 18:04 To: Trudeau, Brian; Vick, Matthew; Ledda William EXT; Gabe Black Cc: lin...@li... Subject: RE: [Linuxptp-users] Which distributions have native ptp support? Redhat 6.4 would have to be a backport of the PTP code which is probably troublesome. Likely, the in kernel driver in their 2.6.32+patches kernel is causing the poll to time out. I doubt the kernel compatability layer for the sourceforge driver has code for Redhat 6.4 to enable PTP (as it's not enabled by default) and I believe it does some static checking against 3.0 kernel version. I would suggest trying on a newer distribution. Regards, Jake > -----Original Message----- > From: Trudeau, Brian [mailto:btr...@On...] > Sent: Tuesday, October 29, 2013 8:57 AM > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > I've been having this same issue with the redhat built version as > well, I've contacted support and they just brushed it off as being a > technical preview and is nether supported or guarantee it to be > supported in any future release as well. I think they are having > issues back porting as you said... > > Brian Trudeau > > > -----Original Message----- > From: Vick, Matthew [mailto:mat...@in...] > Sent: Tuesday, October 29, 2013 10:08 AM > To: Ledda William EXT; Gabe Black; Keller, Jacob E > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Which distributions have native ptp > support? > > Gabe, > > To chime in as well, if you continue to have problems I would > recommend filing a Bugzilla with Red Hat. They own the version of igb > and ptp4l included in their kernel and it could be something else in > their stack interfering specifically with your configuration. > > Another option for you to try is the latest version of igb from > SourceForge > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > that works for you. > > I'm not sure what all the VM changes (other than obviously introducing > some delay around when the app can run), but I would hope the device > continues to operate correctly. > > Cheers, > Matthew > > Matthew Vick > Linux Development > Networking Division > Intel Corporation > > > On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> > wrote: > > >Dear all, > >Have you check the firewall? Is it enabled? The only problem that I > >had > >(initially) was related to the firewall. After disabling the firewall > >everything works! > > > >I worked without problem with the version released with RH 6.4 > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work > with > >1.2 and now I'm working with 1.3 without any problem. > >How do you have compiled version 1.3? Do you have disabled the one > step > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? > Base > >kernel > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, > so in > >order to compile, you should define this symbol or change the sk.c in > >order to don't check for one step clocks. > > > >My syetem configuration: > > > >$ uname -a > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP > >Wed Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > >$ ethtool -i eth1 > >driver: igb > >version: 4.0.1-k > >firmware-version: 1.61, 0x090f8000 > >bus-info: 0000:10:00.1 > >supports-statistics: yes > >supports-test: yes > >supports-eeprom-access: yes > >supports-register-dump: yes > >supports-priv-flags: no > > > >$ ethtool -T eth1 > >Time stamping parameters for eth1: > >Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > >PTP Hardware Clock: 1 > >Hardware Transmit Timestamp Modes: > > off (HWTSTAMP_TX_OFF) > > on (HWTSTAMP_TX_ON) > >Hardware Receive Filter Modes: > > none (HWTSTAMP_FILTER_NONE) > > all (HWTSTAMP_FILTER_ALL) > > > > > >-----Original Message----- > >From: Gabe Black [mailto:Gab...@jd...] > >Sent: 29 October 2013 01:18 > >To: Gabe Black; Keller, Jacob E > >Cc: lin...@li... > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > support? > > > >I downloaded ptp4l and compiled and ran it. The behavior is the > >same, except now poll times out. I have increased the timeout and > >even modified the code to see what packet was getting transmitted to > >verify things. > > > >I verified that in wireshark I see the delay req message go out, and > >the delay response as well. > > > >Looking at the code and reading > Documentation/networking/timestamping > >it looks like the code is trying to get the transmit timestamp of the > >packet which is expected to be found in the socket error queue. > > > >So this leads me to believe that the timestamp is simply not making > >it in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > >kernel/install and the igb driver seems to have support for it as > >shown > below: > > > >ethtool -T eth3 > >Time stamping parameters for eth3: > >Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > >PTP Hardware Clock: 1 > >Hardware Transmit Timestamp Modes: > > off (HWTSTAMP_TX_OFF) > > on (HWTSTAMP_TX_ON) > >Hardware Receive Filter Modes: > > none (HWTSTAMP_FILTER_NONE) > > all (HWTSTAMP_FILTER_ALL) > > > >ethtool -I eth3 > >driver: igb > >version: 4.0.1-k > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > >bunch of work to back-port the stuff to get things like "ethtool -T" > >to work. Probably still buggy... > > > >Anyway, not sure what William did to get it to work... I think I am > >going to just switch to a different distribution that has it > >supported out of the box as well. Apparently on this thread Fedora > >19 and OpenSuse have it. > > > >Oh, I am running in a virtualized environment using DirectPath I/O > >(a.k.a > >"passthrough") to assign the I350 driver directly to the VM. Maybe > >that matters; but I'm fairly certain that DirectPath presents the > >hardware registers/configuration in all its glory to the VM, thus > >letting the igb-driver operate the device. The software is the same, > >so we should be getting timestamps... > > > >Oh well, on to the next distribution! > > > >Thanks! > >Gabe > > > > > > > >> -----Original Message----- > >> From: Gabe Black [mailto:Gab...@jd...] > >> Sent: Monday, October 28, 2013 5:19 PM > >> To: Keller, Jacob E > >> Cc: lin...@li... > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > >> support? > >> > >> I am using the version that comes with a fresh install of the RH > >> 6.4 > >> release: > >> > >> rpm -qa | grep ptp > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > >> > >> ptp4l doesn't appear to have a version option (in this release) and > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > either. > >> > >> At any rate, I will get the latest version and try that and report. > >> > >> Thank you for the feedback! > >> > >> > -----Original Message----- > >> > From: Keller, Jacob E [mailto:jac...@in...] > >> > Sent: Monday, October 28, 2013 4:37 PM > >> > To: Gabe Black > >> > Cc: Ledda William EXT; lin...@li... > >> > Subject: Re: [Linuxptp-users] Which distributions have native ptp > >> > support? > >> > > >> > What version of linuxPTP are you using? > >> > > >> > It appears you aren't using the 1.3 version as we moved to a > >> > method for obtaining the Tx timestamp that uses the poll() call. > >> > That might fix your issue. > >> > > >> > The other option would be to increase the tx_timestamp_timeout > >> > value, but I think moving to the newest Linux PTP should be a fix. > >> > > >> > Regards, > >> > Jake > >> > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > >> > > Nm, it was right. We have two subnets that will route to the > >> > meinberg, and they both work... So that means I still I don't > >> > know what it is... > >> > > > >> > > strace it shows: > >> > > sendto(11, > >> > > > >> > > >> > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > 3\0\1 > >> \ > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > >> > > 44 > >> > > Followed by a bunch of: > >> > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > > temporarily unavailable) ... > >> > > > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: Gabe Black > >> > > > Sent: Monday, October 28, 2013 2:20 PM > >> > > > To: Gabe Black; 'Keller, Jacob E' > >> > > > Cc: 'Ledda William EXT'; 'lin...@li...' > >> > > > Subject: RE: [Linuxptp-users] Which distributions have native > >> > > > ptp support? > >> > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > >> > > > > >> > > > It is working now! > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Gabe Black > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > >> > > > > To: 'Keller, Jacob E' > >> > > > > Cc: Ledda William EXT; lin...@li... > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have > >> > > > > native ptp support? > >> > > > > > >> > > > > > -----Original Message----- > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] > >> > > > > > You shouldn't have to, however, I would suggest disabling > >> > > > > > EEE support, as this has been known to cause issues on > >> > > > > > the i350 > >> > > > > > > >> > > > > > ethtool --set-eee device eee off > >> > > > > > > >> > > > > > This should fix your issue, if not please me know. > >> > > > > > >> > > > > Thank you for the reply. > >> > > > > > >> > > > > That option does not appear to be available with the stock > >> > > > > igb driver of RH6.4 > >> > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > >> > > > > driver: igb > >> > > > > version: 4.0.1-k > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot get > >> > > > > EEE > >> > > > > settings: Operation not supported > >> > > > > > >> > > > > Is there another way to disable EEE? Or would not having > >> > > > > that option in ethtool mean it is off? > >> > > > > > >> > > > > Gabe > >> > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > >> > > > > > > Hi William, > >> > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with > >> > > > > > > igb > >> > > > > > > driver) > >> > > > > and > >> > > > > > am having trouble getting it to work with a meinberg master. > >> > > > > > > > >> > > > > > > The output I get is: > >> > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING on > >> > > > INITIALIZE > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING on > >> > > > INITIALIZE > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > >> > > > > > > 00606e.fffe.7c230e- > >> > > > 1 > >> > > > > > > ptp4l[246985.014]: selected best master clock > >> > > > > > > 00606e.fffe.7c230e > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP > >> > > > > > > timescale > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED on > >> > > > > > > RS_SLAVE > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: > >> > > > > > > Resource > >> > > > > temporarily > >> > > > > > > unavailable > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on > >> > > > > > > FAULT_DETECTED > >> > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > >> > > > > > > RH6.4 > >> > > > install > >> > > > > > > to > >> > > > > > get it to work? > >> > > > > > > > >> > > > > > > Thanks, > >> > > > > > > Gabe > >> > > > > > > > >> > > > > > > > -----Original Message----- > >> > > > > > > > From: Ledda William EXT > >> > > > > > > > [mailto:Wil...@it...] > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > >> > > > > > > > To: Richard Cochran; Gabe Black > >> > > > > > > > Cc: lin...@li... > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions > >> > > > > > > > have native ptp support? > >> > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb > >> > > > > > > > driver) > >> > with > >> > > > > > success > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I > >> > > > > > > > know that there will be many improvements, more eth > >> > > > > > > > driver supported, and it should include version 1.3 > >> > > > > > > > of linuxptp > >> package. > >> > > > > > > > > >> > > > > > > > William > >> > > > > > > > > >> > > > >> > > >> > >> ------------------------------------------------------------------- > >> -- > >> - > >> - > >> ------- > >> Android is increasing in popularity, but the open development > >> platform that developers love is also attractive to malware creators. > >> Download this white paper to learn more about secure code signing > >> practices that can help keep Android apps secure. > >> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > g. > >> c > >> l > >> ktrk > >> _______________________________________________ > >> Linuxptp-users mailing list > >> Lin...@li... > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > >--------------------------------------------------------------------- > >-- > >--- > >---- > >Android is increasing in popularity, but the open development > >platform that developers love is also attractive to malware creators. > >Download this white paper to learn more about secure code signing > >practices that can help keep Android apps secure. > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > stg.cl > >ktr > >k > >_______________________________________________ > >Linuxptp-users mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > >--------------------------------------------------------------------- > >-- > >--- > >---- > >Android is increasing in popularity, but the open development > >platform that developers love is also attractive to malware creators. > >Download this white paper to learn more about secure code signing > >practices that can help keep Android apps secure. > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > stg.cl > >ktr > >k > >_______________________________________________ > >Linuxptp-users mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > ---------------------------------------------------------------------- > -------- Android is increasing in popularity, but the open development > platform that developers love is also attractive to malware creators. > Download this white paper to learn more about secure code signing > practices that can help keep Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > g.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > The information transmitted herein is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. This message is not a recommendation, offer or > solicitation to buy or sell anything. Any examples, prices or > quotations contained herein are indicative only and an order based on > such information can only be executed through a duly registered > broker/dealer or futures commission merchant. Any review, > retransmission, dissemination or other use of, or taking of any action > in reliance upon, this information is prohibited. If you received this > in error, please contact the sender and delete the material from any computer. > OneChicago, LLC is a Delaware limited liability company. |
|
From: Keller, J. E <jac...@in...> - 2013-10-29 17:03:46
|
Redhat 6.4 would have to be a backport of the PTP code which is probably troublesome. Likely, the in kernel driver in their 2.6.32+patches kernel is causing the poll to time out. I doubt the kernel compatability layer for the sourceforge driver has code for Redhat 6.4 to enable PTP (as it's not enabled by default) and I believe it does some static checking against 3.0 kernel version. I would suggest trying on a newer distribution. Regards, Jake > -----Original Message----- > From: Trudeau, Brian [mailto:btr...@On...] > Sent: Tuesday, October 29, 2013 8:57 AM > To: Vick, Matthew; Ledda William EXT; Gabe Black; Keller, Jacob E > Cc: lin...@li... > Subject: RE: [Linuxptp-users] Which distributions have native ptp > support? > > I've been having this same issue with the redhat built version as well, I've > contacted support and they just brushed it off as being a technical > preview and is nether supported or guarantee it to be supported in any > future release as well. I think they are having issues back porting as you > said... > > Brian Trudeau > > > -----Original Message----- > From: Vick, Matthew [mailto:mat...@in...] > Sent: Tuesday, October 29, 2013 10:08 AM > To: Ledda William EXT; Gabe Black; Keller, Jacob E > Cc: lin...@li... > Subject: Re: [Linuxptp-users] Which distributions have native ptp > support? > > Gabe, > > To chime in as well, if you continue to have problems I would recommend > filing a Bugzilla with Red Hat. They own the version of igb and ptp4l > included in their kernel and it could be something else in their stack > interfering specifically with your configuration. > > Another option for you to try is the latest version of igb from SourceForge > (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if > that works for you. > > I'm not sure what all the VM changes (other than obviously introducing > some delay around when the app can run), but I would hope the device > continues to operate correctly. > > Cheers, > Matthew > > Matthew Vick > Linux Development > Networking Division > Intel Corporation > > > On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> > wrote: > > >Dear all, > >Have you check the firewall? Is it enabled? The only problem that I had > >(initially) was related to the firewall. After disabling the firewall > >everything works! > > > >I worked without problem with the version released with RH 6.4 > >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work > with > >1.2 and now I'm working with 1.3 without any problem. > >How do you have compiled version 1.3? Do you have disabled the one > step > >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? > Base > >kernel > >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, > so in > >order to compile, you should define this symbol or change the sk.c in > >order to don't check for one step clocks. > > > >My syetem configuration: > > > >$ uname -a > >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed > >Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > > > >$ ethtool -i eth1 > >driver: igb > >version: 4.0.1-k > >firmware-version: 1.61, 0x090f8000 > >bus-info: 0000:10:00.1 > >supports-statistics: yes > >supports-test: yes > >supports-eeprom-access: yes > >supports-register-dump: yes > >supports-priv-flags: no > > > >$ ethtool -T eth1 > >Time stamping parameters for eth1: > >Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > >PTP Hardware Clock: 1 > >Hardware Transmit Timestamp Modes: > > off (HWTSTAMP_TX_OFF) > > on (HWTSTAMP_TX_ON) > >Hardware Receive Filter Modes: > > none (HWTSTAMP_FILTER_NONE) > > all (HWTSTAMP_FILTER_ALL) > > > > > >-----Original Message----- > >From: Gabe Black [mailto:Gab...@jd...] > >Sent: 29 October 2013 01:18 > >To: Gabe Black; Keller, Jacob E > >Cc: lin...@li... > >Subject: Re: [Linuxptp-users] Which distributions have native ptp > support? > > > >I downloaded ptp4l and compiled and ran it. The behavior is the same, > >except now poll times out. I have increased the timeout and even > >modified the code to see what packet was getting transmitted to verify > >things. > > > >I verified that in wireshark I see the delay req message go out, and > >the delay response as well. > > > >Looking at the code and reading > Documentation/networking/timestamping > >it looks like the code is trying to get the transmit timestamp of the > >packet which is expected to be found in the socket error queue. > > > >So this leads me to believe that the timestamp is simply not making it > >in to the MSG_ERRQUEUE... Again, I have the default RH6.4 > >kernel/install and the igb driver seems to have support for it as shown > below: > > > >ethtool -T eth3 > >Time stamping parameters for eth3: > >Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > >PTP Hardware Clock: 1 > >Hardware Transmit Timestamp Modes: > > off (HWTSTAMP_TX_OFF) > > on (HWTSTAMP_TX_ON) > >Hardware Receive Filter Modes: > > none (HWTSTAMP_FILTER_NONE) > > all (HWTSTAMP_FILTER_ALL) > > > >ethtool -I eth3 > >driver: igb > >version: 4.0.1-k > > > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a > >bunch of work to back-port the stuff to get things like "ethtool -T" to > >work. Probably still buggy... > > > >Anyway, not sure what William did to get it to work... I think I am > >going to just switch to a different distribution that has it supported > >out of the box as well. Apparently on this thread Fedora 19 and > >OpenSuse have it. > > > >Oh, I am running in a virtualized environment using DirectPath I/O > >(a.k.a > >"passthrough") to assign the I350 driver directly to the VM. Maybe > >that matters; but I'm fairly certain that DirectPath presents the > >hardware registers/configuration in all its glory to the VM, thus > >letting the igb-driver operate the device. The software is the same, > >so we should be getting timestamps... > > > >Oh well, on to the next distribution! > > > >Thanks! > >Gabe > > > > > > > >> -----Original Message----- > >> From: Gabe Black [mailto:Gab...@jd...] > >> Sent: Monday, October 28, 2013 5:19 PM > >> To: Keller, Jacob E > >> Cc: lin...@li... > >> Subject: Re: [Linuxptp-users] Which distributions have native ptp > >> support? > >> > >> I am using the version that comes with a fresh install of the RH 6.4 > >> release: > >> > >> rpm -qa | grep ptp > >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 > >> > >> ptp4l doesn't appear to have a version option (in this release) and > >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't > either. > >> > >> At any rate, I will get the latest version and try that and report. > >> > >> Thank you for the feedback! > >> > >> > -----Original Message----- > >> > From: Keller, Jacob E [mailto:jac...@in...] > >> > Sent: Monday, October 28, 2013 4:37 PM > >> > To: Gabe Black > >> > Cc: Ledda William EXT; lin...@li... > >> > Subject: Re: [Linuxptp-users] Which distributions have native ptp > >> > support? > >> > > >> > What version of linuxPTP are you using? > >> > > >> > It appears you aren't using the 1.3 version as we moved to a method > >> > for obtaining the Tx timestamp that uses the poll() call. That > >> > might fix your issue. > >> > > >> > The other option would be to increase the tx_timestamp_timeout > >> > value, but I think moving to the newest Linux PTP should be a fix. > >> > > >> > Regards, > >> > Jake > >> > > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: > >> > > Nm, it was right. We have two subnets that will route to the > >> > meinberg, and they both work... So that means I still I don't > >> > know what it is... > >> > > > >> > > strace it shows: > >> > > sendto(11, > >> > > > >> > > >> > "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\21 > 3\0\1 > >> \ > >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), > >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ > >> > > 44 > >> > > Followed by a bunch of: > >> > > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > temporarily unavailable) > >> > > nanosleep({0, 1000}, NULL) = 0 > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN > (Resource > >> > > temporarily unavailable) ... > >> > > > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: Gabe Black > >> > > > Sent: Monday, October 28, 2013 2:20 PM > >> > > > To: Gabe Black; 'Keller, Jacob E' > >> > > > Cc: 'Ledda William EXT'; 'lin...@li...' > >> > > > Subject: RE: [Linuxptp-users] Which distributions have native > >> > > > ptp support? > >> > > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... > >> > > > > >> > > > It is working now! > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: Gabe Black > >> > > > > Sent: Monday, October 28, 2013 1:18 PM > >> > > > > To: 'Keller, Jacob E' > >> > > > > Cc: Ledda William EXT; lin...@li... > >> > > > > Subject: RE: [Linuxptp-users] Which distributions have native > >> > > > > ptp support? > >> > > > > > >> > > > > > -----Original Message----- > >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] You > >> > > > > > shouldn't have to, however, I would suggest disabling EEE > >> > > > > > support, as this has been known to cause issues on the i350 > >> > > > > > > >> > > > > > ethtool --set-eee device eee off > >> > > > > > > >> > > > > > This should fix your issue, if not please me know. > >> > > > > > >> > > > > Thank you for the reply. > >> > > > > > >> > > > > That option does not appear to be available with the stock > >> > > > > igb driver of RH6.4 > >> > > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 > >> > > > > driver: igb > >> > > > > version: 4.0.1-k > >> > > > > firmware-version: 0.1470, 0x05fc8000 ... > >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot get > >> > > > > EEE > >> > > > > settings: Operation not supported > >> > > > > > >> > > > > Is there another way to disable EEE? Or would not having that > >> > > > > option in ethtool mean it is off? > >> > > > > > >> > > > > Gabe > >> > > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: > >> > > > > > > Hi William, > >> > > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with igb > >> > > > > > > driver) > >> > > > > and > >> > > > > > am having trouble getting it to work with a meinberg master. > >> > > > > > > > >> > > > > > > The output I get is: > >> > > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock > >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING on > >> > > > INITIALIZE > >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING on > >> > > > INITIALIZE > >> > > > > > > ptp4l[246980.773]: port 1: new foreign master > >> > > > > > > 00606e.fffe.7c230e- > >> > > > 1 > >> > > > > > > ptp4l[246985.014]: selected best master clock > >> > > > > > > 00606e.fffe.7c230e > >> > > > > > > ptp4l[246985.014]: foreign master not using PTP timescale > >> > > > > > > ptp4l[246985.014]: running in a temporal vortex > >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED on > >> > > > > > > RS_SLAVE > >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: Resource > >> > > > > temporarily > >> > > > > > > unavailable > >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed > >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on > >> > > > > > > FAULT_DETECTED > >> > > > > > > > >> > > > > > > Did you have to do anything differently on the stock > >> > > > > > > RH6.4 > >> > > > install > >> > > > > > > to > >> > > > > > get it to work? > >> > > > > > > > >> > > > > > > Thanks, > >> > > > > > > Gabe > >> > > > > > > > >> > > > > > > > -----Original Message----- > >> > > > > > > > From: Ledda William EXT [mailto:Wil...@it...] > >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM > >> > > > > > > > To: Richard Cochran; Gabe Black > >> > > > > > > > Cc: lin...@li... > >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions have > >> > > > > > > > native ptp support? > >> > > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb driver) > >> > with > >> > > > > > success > >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I know > >> > > > > > > > that there will be many improvements, more eth driver > >> > > > > > > > supported, and it should include version 1.3 of > >> > > > > > > > linuxptp > >> package. > >> > > > > > > > > >> > > > > > > > William > >> > > > > > > > > >> > > > >> > > >> > >> --------------------------------------------------------------------- > >> - > >> - > >> ------- > >> Android is increasing in popularity, but the open development > >> platform that developers love is also attractive to malware creators. > >> Download this white paper to learn more about secure code signing > >> practices that can help keep Android apps secure. > >> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > g. > >> c > >> l > >> ktrk > >> _______________________________________________ > >> Linuxptp-users mailing list > >> Lin...@li... > >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > >----------------------------------------------------------------------- > >--- > >---- > >Android is increasing in popularity, but the open development platform > >that developers love is also attractive to malware creators. Download > >this white paper to learn more about secure code signing practices that > >can help keep Android apps secure. > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > stg.cl > >ktr > >k > >_______________________________________________ > >Linuxptp-users mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > >----------------------------------------------------------------------- > >--- > >---- > >Android is increasing in popularity, but the open development platform > >that developers love is also attractive to malware creators. Download > >this white paper to learn more about secure code signing practices that > >can help keep Android apps secure. > >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/o > stg.cl > >ktr > >k > >_______________________________________________ > >Linuxptp-users mailing list > >Lin...@li... > >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform > that developers love is also attractive to malware creators. Download this > white paper to learn more about secure code signing practices that can > help keep Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ost > g.clktrk > _______________________________________________ > Linuxptp-users mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > The information transmitted herein is intended only for the person or > entity to which it is addressed and may contain confidential and/or > privileged material. This message is not a recommendation, offer or > solicitation to buy or sell anything. Any examples, prices or quotations > contained herein are indicative only and an order based on such > information can only be executed through a duly registered > broker/dealer or futures commission merchant. Any review, > retransmission, dissemination or other use of, or taking of any action in > reliance upon, this information is prohibited. If you received this in error, > please contact the sender and delete the material from any computer. > OneChicago, LLC is a Delaware limited liability company. |
|
From: Richard C. <ric...@gm...> - 2013-10-29 16:19:17
|
On Mon, Oct 28, 2013 at 08:40:50AM -0700, Jon Deon wrote: > I'm working on a project using linuxptp where I may need to set up > multiple clock synchronization domains on the same subnet. I may > have two (or more) masters and will need to specify on the slaves > which master to synchronize with. It sounds like the "domainNumber" option is what you are looking for. You can place masters and slaves into separate groups, even when they are on the same network. HTH, Richard |
|
From: Trudeau, B. <btr...@On...> - 2013-10-29 16:09:55
|
I've been having this same issue with the redhat built version as well, I've contacted support and they just brushed it off as being a technical preview and is nether supported or guarantee it to be supported in any future release as well. I think they are having issues back porting as you said... Brian Trudeau -----Original Message----- From: Vick, Matthew [mailto:mat...@in...] Sent: Tuesday, October 29, 2013 10:08 AM To: Ledda William EXT; Gabe Black; Keller, Jacob E Cc: lin...@li... Subject: Re: [Linuxptp-users] Which distributions have native ptp support? Gabe, To chime in as well, if you continue to have problems I would recommend filing a Bugzilla with Red Hat. They own the version of igb and ptp4l included in their kernel and it could be something else in their stack interfering specifically with your configuration. Another option for you to try is the latest version of igb from SourceForge (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to see if that works for you. I'm not sure what all the VM changes (other than obviously introducing some delay around when the app can run), but I would hope the device continues to operate correctly. Cheers, Matthew Matthew Vick Linux Development Networking Division Intel Corporation On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> wrote: >Dear all, >Have you check the firewall? Is it enabled? The only problem that I had >(initially) was related to the firewall. After disabling the firewall >everything works! > >I worked without problem with the version released with RH 6.4 >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work with >1.2 and now I'm working with 1.3 without any problem. >How do you have compiled version 1.3? Do you have disabled the one step >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? Base >kernel >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, so in >order to compile, you should define this symbol or change the sk.c in >order to don't check for one step clocks. > >My syetem configuration: > >$ uname -a >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed >Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux > >$ ethtool -i eth1 >driver: igb >version: 4.0.1-k >firmware-version: 1.61, 0x090f8000 >bus-info: 0000:10:00.1 >supports-statistics: yes >supports-test: yes >supports-eeprom-access: yes >supports-register-dump: yes >supports-priv-flags: no > >$ ethtool -T eth1 >Time stamping parameters for eth1: >Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) >PTP Hardware Clock: 1 >Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) >Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > > >-----Original Message----- >From: Gabe Black [mailto:Gab...@jd...] >Sent: 29 October 2013 01:18 >To: Gabe Black; Keller, Jacob E >Cc: lin...@li... >Subject: Re: [Linuxptp-users] Which distributions have native ptp support? > >I downloaded ptp4l and compiled and ran it. The behavior is the same, >except now poll times out. I have increased the timeout and even >modified the code to see what packet was getting transmitted to verify >things. > >I verified that in wireshark I see the delay req message go out, and >the delay response as well. > >Looking at the code and reading Documentation/networking/timestamping >it looks like the code is trying to get the transmit timestamp of the >packet which is expected to be found in the socket error queue. > >So this leads me to believe that the timestamp is simply not making it >in to the MSG_ERRQUEUE... Again, I have the default RH6.4 >kernel/install and the igb driver seems to have support for it as shown below: > >ethtool -T eth3 >Time stamping parameters for eth3: >Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) >PTP Hardware Clock: 1 >Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on (HWTSTAMP_TX_ON) >Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > all (HWTSTAMP_FILTER_ALL) > >ethtool -I eth3 >driver: igb >version: 4.0.1-k > >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a >bunch of work to back-port the stuff to get things like "ethtool -T" to >work. Probably still buggy... > >Anyway, not sure what William did to get it to work... I think I am >going to just switch to a different distribution that has it supported >out of the box as well. Apparently on this thread Fedora 19 and >OpenSuse have it. > >Oh, I am running in a virtualized environment using DirectPath I/O >(a.k.a >"passthrough") to assign the I350 driver directly to the VM. Maybe >that matters; but I'm fairly certain that DirectPath presents the >hardware registers/configuration in all its glory to the VM, thus >letting the igb-driver operate the device. The software is the same, >so we should be getting timestamps... > >Oh well, on to the next distribution! > >Thanks! >Gabe > > > >> -----Original Message----- >> From: Gabe Black [mailto:Gab...@jd...] >> Sent: Monday, October 28, 2013 5:19 PM >> To: Keller, Jacob E >> Cc: lin...@li... >> Subject: Re: [Linuxptp-users] Which distributions have native ptp >> support? >> >> I am using the version that comes with a fresh install of the RH 6.4 >> release: >> >> rpm -qa | grep ptp >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 >> >> ptp4l doesn't appear to have a version option (in this release) and >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't either. >> >> At any rate, I will get the latest version and try that and report. >> >> Thank you for the feedback! >> >> > -----Original Message----- >> > From: Keller, Jacob E [mailto:jac...@in...] >> > Sent: Monday, October 28, 2013 4:37 PM >> > To: Gabe Black >> > Cc: Ledda William EXT; lin...@li... >> > Subject: Re: [Linuxptp-users] Which distributions have native ptp >> > support? >> > >> > What version of linuxPTP are you using? >> > >> > It appears you aren't using the 1.3 version as we moved to a method >> > for obtaining the Tx timestamp that uses the poll() call. That >> > might fix your issue. >> > >> > The other option would be to increase the tx_timestamp_timeout >> > value, but I think moving to the newest Linux PTP should be a fix. >> > >> > Regards, >> > Jake >> > >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: >> > > Nm, it was right. We have two subnets that will route to the >> > meinberg, and they both work... So that means I still I don't >> > know what it is... >> > > >> > > strace it shows: >> > > sendto(11, >> > > >> > >> "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\213\0\1 >> \ >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ >> > > 44 >> > > Followed by a bunch of: >> > > >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> > temporarily unavailable) >> > > nanosleep({0, 1000}, NULL) = 0 >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> > temporarily unavailable) >> > > nanosleep({0, 1000}, NULL) = 0 >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> > temporarily unavailable) >> > > nanosleep({0, 1000}, NULL) = 0 >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> > > temporarily unavailable) ... >> > > >> > > >> > > >> > > > -----Original Message----- >> > > > From: Gabe Black >> > > > Sent: Monday, October 28, 2013 2:20 PM >> > > > To: Gabe Black; 'Keller, Jacob E' >> > > > Cc: 'Ledda William EXT'; 'lin...@li...' >> > > > Subject: RE: [Linuxptp-users] Which distributions have native >> > > > ptp support? >> > > > >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... >> > > > >> > > > It is working now! >> > > > >> > > > > -----Original Message----- >> > > > > From: Gabe Black >> > > > > Sent: Monday, October 28, 2013 1:18 PM >> > > > > To: 'Keller, Jacob E' >> > > > > Cc: Ledda William EXT; lin...@li... >> > > > > Subject: RE: [Linuxptp-users] Which distributions have native >> > > > > ptp support? >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] You >> > > > > > shouldn't have to, however, I would suggest disabling EEE >> > > > > > support, as this has been known to cause issues on the i350 >> > > > > > >> > > > > > ethtool --set-eee device eee off >> > > > > > >> > > > > > This should fix your issue, if not please me know. >> > > > > >> > > > > Thank you for the reply. >> > > > > >> > > > > That option does not appear to be available with the stock >> > > > > igb driver of RH6.4 >> > > > > >> > > > > [root@ network-scripts]# ethtool -i eth3 >> > > > > driver: igb >> > > > > version: 4.0.1-k >> > > > > firmware-version: 0.1470, 0x05fc8000 ... >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot get >> > > > > EEE >> > > > > settings: Operation not supported >> > > > > >> > > > > Is there another way to disable EEE? Or would not having that >> > > > > option in ethtool mean it is off? >> > > > > >> > > > > Gabe >> > > > > >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: >> > > > > > > Hi William, >> > > > > > > >> > > > > > > I installed redhat 6.4 and have the intel i350 (with igb >> > > > > > > driver) >> > > > > and >> > > > > > am having trouble getting it to work with a meinberg master. >> > > > > > > >> > > > > > > The output I get is: >> > > > > > > >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING on >> > > > INITIALIZE >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING on >> > > > INITIALIZE >> > > > > > > ptp4l[246980.773]: port 1: new foreign master >> > > > > > > 00606e.fffe.7c230e- >> > > > 1 >> > > > > > > ptp4l[246985.014]: selected best master clock >> > > > > > > 00606e.fffe.7c230e >> > > > > > > ptp4l[246985.014]: foreign master not using PTP timescale >> > > > > > > ptp4l[246985.014]: running in a temporal vortex >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED on >> > > > > > > RS_SLAVE >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: Resource >> > > > > temporarily >> > > > > > > unavailable >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on >> > > > > > > FAULT_DETECTED >> > > > > > > >> > > > > > > Did you have to do anything differently on the stock >> > > > > > > RH6.4 >> > > > install >> > > > > > > to >> > > > > > get it to work? >> > > > > > > >> > > > > > > Thanks, >> > > > > > > Gabe >> > > > > > > >> > > > > > > > -----Original Message----- >> > > > > > > > From: Ledda William EXT [mailto:Wil...@it...] >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM >> > > > > > > > To: Richard Cochran; Gabe Black >> > > > > > > > Cc: lin...@li... >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions have >> > > > > > > > native ptp support? >> > > > > > > > >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb driver) >> > with >> > > > > > success >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I know >> > > > > > > > that there will be many improvements, more eth driver >> > > > > > > > supported, and it should include version 1.3 of >> > > > > > > > linuxptp >> package. >> > > > > > > > >> > > > > > > > William >> > > > > > > > >> > > >> > >> >> --------------------------------------------------------------------- >> - >> - >> ------- >> Android is increasing in popularity, but the open development >> platform that developers love is also attractive to malware creators. >> Download this white paper to learn more about secure code signing >> practices that can help keep Android apps secure. >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg. >> c >> l >> ktrk >> _______________________________________________ >> Linuxptp-users mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > >----------------------------------------------------------------------- >--- >---- >Android is increasing in popularity, but the open development platform >that developers love is also attractive to malware creators. Download >this white paper to learn more about secure code signing practices that >can help keep Android apps secure. >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.cl >ktr >k >_______________________________________________ >Linuxptp-users mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > >----------------------------------------------------------------------- >--- >---- >Android is increasing in popularity, but the open development platform >that developers love is also attractive to malware creators. Download >this white paper to learn more about secure code signing practices that >can help keep Android apps secure. >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.cl >ktr >k >_______________________________________________ >Linuxptp-users mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linuxptp-users ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Linuxptp-users mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-users The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. This message is not a recommendation, offer or solicitation to buy or sell anything. Any examples, prices or quotations contained herein are indicative only and an order based on such information can only be executed through a duly registered broker/dealer or futures commission merchant. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. OneChicago, LLC is a Delaware limited liability company. |
|
From: Vick, M. <mat...@in...> - 2013-10-29 15:20:25
|
Gabe, My apologies--I forgot that since RHEL 6.4 is a 2.6.32 kernel, the PTP build of igb will not succeed. Had you asked me post-coffee, I would have answered correctly. :) Yes, please do follow up with Red Hat if you continue to have issues. Cheers, Matthew On 10/29/13, 8:13 AM, "Gabe Black" <Gab...@jd...> wrote: >Thanks, > >I may consider filing a bug if it works out of the box in another >distribution. I did try compiling the igb driver, but it gave so many >compile errors when I tried to use the CFLAGS_EXTRA=-DIGB_PTP. After >fixing a static check for a version greater than the 2.6 kernel redhat >supplies in the igb code, I got a ton of compile errors. I decided not >to pursue all the missing PTP related constants... (driver compiles fine >without defining IGB_PTP). > >Gabe > > >> -----Original Message----- >> From: Vick, Matthew [mailto:mat...@in...] >> Sent: Tuesday, October 29, 2013 9:08 AM >> To: Ledda William EXT; Gabe Black; Keller, Jacob E >> Cc: lin...@li... >> Subject: Re: [Linuxptp-users] Which distributions have native ptp >> support? >> >> Gabe, >> >> To chime in as well, if you continue to have problems I would recommend >> filing a Bugzilla with Red Hat. They own the version of igb and ptp4l >> included in their kernel and it could be something else in their stack >> interfering specifically with your configuration. >> >> Another option for you to try is the latest version of igb from >> SourceForge (5.0.6) and compiling with "CFLAGS_EXTRA=-DIGB_PTP make" to >> see if that works for you. >> >> I'm not sure what all the VM changes (other than obviously introducing >> some delay around when the app can run), but I would hope the device >> continues to operate correctly. >> >> Cheers, >> Matthew >> >> Matthew Vick >> Linux Development >> Networking Division >> Intel Corporation >> >> >> On 10/29/13, 1:11 AM, "Ledda William EXT" <Wil...@it...> >> wrote: >> >> >Dear all, >> >Have you check the firewall? Is it enabled? The only problem that I >> had >> >(initially) was related to the firewall. After disabling the firewall >> >everything works! >> > >> >I worked without problem with the version released with RH 6.4 >> >(linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64) but I have also work >> with >> >1.2 and now I'm working with 1.3 without any problem. >> >How do you have compiled version 1.3? Do you have disabled the one >> step >> >option or do you have define HWTSTAMP_TX_ONESTEP_SYNC symbol? Base >> >kernel >> >2.36.32 haven't HWTSTAMP_TX_ONESTEP_SYNC in linux/net_tstamp.h, so in >> >order to compile, you should define this symbol or change the sk.c in >> >order to don't check for one step clocks. >> > >> >My syetem configuration: >> > >> >$ uname -a >> >Linux fc-vitro-tcn.codac.iter.org 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed >> >Feb 20 12:17:37 EST 2013 x86_64 x86_64 x86_64 GNU/Linux >> > >> >$ ethtool -i eth1 >> >driver: igb >> >version: 4.0.1-k >> >firmware-version: 1.61, 0x090f8000 >> >bus-info: 0000:10:00.1 >> >supports-statistics: yes >> >supports-test: yes >> >supports-eeprom-access: yes >> >supports-register-dump: yes >> >supports-priv-flags: no >> > >> >$ ethtool -T eth1 >> >Time stamping parameters for eth1: >> >Capabilities: >> > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) >> > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) >> > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) >> >PTP Hardware Clock: 1 >> >Hardware Transmit Timestamp Modes: >> > off (HWTSTAMP_TX_OFF) >> > on (HWTSTAMP_TX_ON) >> >Hardware Receive Filter Modes: >> > none (HWTSTAMP_FILTER_NONE) >> > all (HWTSTAMP_FILTER_ALL) >> > >> > >> >-----Original Message----- >> >From: Gabe Black [mailto:Gab...@jd...] >> >Sent: 29 October 2013 01:18 >> >To: Gabe Black; Keller, Jacob E >> >Cc: lin...@li... >> >Subject: Re: [Linuxptp-users] Which distributions have native ptp >> support? >> > >> >I downloaded ptp4l and compiled and ran it. The behavior is the same, >> >except now poll times out. I have increased the timeout and even >> >modified the code to see what packet was getting transmitted to verify >> >things. >> > >> >I verified that in wireshark I see the delay req message go out, and >> >the delay response as well. >> > >> >Looking at the code and reading Documentation/networking/timestamping >> >it looks like the code is trying to get the transmit timestamp of the >> >packet which is expected to be found in the socket error queue. >> > >> >So this leads me to believe that the timestamp is simply not making it >> >in to the MSG_ERRQUEUE... Again, I have the default RH6.4 >> >kernel/install and the igb driver seems to have support for it as >> shown below: >> > >> >ethtool -T eth3 >> >Time stamping parameters for eth3: >> >Capabilities: >> > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) >> > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) >> > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) >> >PTP Hardware Clock: 1 >> >Hardware Transmit Timestamp Modes: >> > off (HWTSTAMP_TX_OFF) >> > on (HWTSTAMP_TX_ON) >> >Hardware Receive Filter Modes: >> > none (HWTSTAMP_FILTER_NONE) >> > all (HWTSTAMP_FILTER_ALL) >> > >> >ethtool -I eth3 >> >driver: igb >> >version: 4.0.1-k >> > >> >Since RH6.4 still is on 2.6.32 kernel, I'm guessing they had to do a >> >bunch of work to back-port the stuff to get things like "ethtool -T" >> to >> >work. Probably still buggy... >> > >> >Anyway, not sure what William did to get it to work... I think I am >> >going to just switch to a different distribution that has it supported >> >out of the box as well. Apparently on this thread Fedora 19 and >> >OpenSuse have it. >> > >> >Oh, I am running in a virtualized environment using DirectPath I/O >> >(a.k.a >> >"passthrough") to assign the I350 driver directly to the VM. Maybe >> >that matters; but I'm fairly certain that DirectPath presents the >> >hardware registers/configuration in all its glory to the VM, thus >> >letting the igb-driver operate the device. The software is the same, >> >so we should be getting timestamps... >> > >> >Oh well, on to the next distribution! >> > >> >Thanks! >> >Gabe >> > >> > >> > >> >> -----Original Message----- >> >> From: Gabe Black [mailto:Gab...@jd...] >> >> Sent: Monday, October 28, 2013 5:19 PM >> >> To: Keller, Jacob E >> >> Cc: lin...@li... >> >> Subject: Re: [Linuxptp-users] Which distributions have native ptp >> >> support? >> >> >> >> I am using the version that comes with a fresh install of the RH 6.4 >> >> release: >> >> >> >> rpm -qa | grep ptp >> >> linuxptp-0-0.6.20121114gite6bbbb.el6.x86_64 >> >> >> >> ptp4l doesn't appear to have a version option (in this release) and >> >> the readme file in /usr/shar/doc/linuxptp-0/README.org doesn't >> either. >> >> >> >> At any rate, I will get the latest version and try that and report. >> >> >> >> Thank you for the feedback! >> >> >> >> > -----Original Message----- >> >> > From: Keller, Jacob E [mailto:jac...@in...] >> >> > Sent: Monday, October 28, 2013 4:37 PM >> >> > To: Gabe Black >> >> > Cc: Ledda William EXT; lin...@li... >> >> > Subject: Re: [Linuxptp-users] Which distributions have native ptp >> >> > support? >> >> > >> >> > What version of linuxPTP are you using? >> >> > >> >> > It appears you aren't using the 1.3 version as we moved to a >> method >> >> > for obtaining the Tx timestamp that uses the poll() call. That >> >> > might fix your issue. >> >> > >> >> > The other option would be to increase the tx_timestamp_timeout >> >> > value, but I think moving to the newest Linux PTP should be a fix. >> >> > >> >> > Regards, >> >> > Jake >> >> > >> >> > On Mon, 2013-10-28 at 21:35 +0000, Gabe Black wrote: >> >> > > Nm, it was right. We have two subnets that will route to the >> >> > meinberg, and they both work... So that means I still I don't >> >> > know what it is... >> >> > > >> >> > > strace it shows: >> >> > > sendto(11, >> >> > > >> >> > >> >> >> "\1\2\0,\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2406\237\377\376\30*\213\0\1 >> >> \ >> >> > > 0\0"..., 44, 0, {sa_family=AF_INET, sin_port=htons(319), >> >> > > sin_addr=inet_addr("224.0.1.129")}, 16) = \ >> >> > > 44 >> >> > > Followed by a bunch of: >> >> > > >> >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> >> > temporarily unavailable) >> >> > > nanosleep({0, 1000}, NULL) = 0 >> >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> >> > temporarily unavailable) >> >> > > nanosleep({0, 1000}, NULL) = 0 >> >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> >> > temporarily unavailable) >> >> > > nanosleep({0, 1000}, NULL) = 0 >> >> > > recvmsg(11, 0x7fff67459250, MSG_ERRQUEUE) = -1 EAGAIN (Resource >> >> > > temporarily unavailable) ... >> >> > > >> >> > > >> >> > > >> >> > > > -----Original Message----- >> >> > > > From: Gabe Black >> >> > > > Sent: Monday, October 28, 2013 2:20 PM >> >> > > > To: Gabe Black; 'Keller, Jacob E' >> >> > > > Cc: 'Ledda William EXT'; 'linuxptp- >> us...@li...' >> >> > > > Subject: RE: [Linuxptp-users] Which distributions have native >> >> > > > ptp support? >> >> > > > >> >> > > > Oh sheesh.. I had a typo and was on the wrong subnet... >> >> > > > >> >> > > > It is working now! >> >> > > > >> >> > > > > -----Original Message----- >> >> > > > > From: Gabe Black >> >> > > > > Sent: Monday, October 28, 2013 1:18 PM >> >> > > > > To: 'Keller, Jacob E' >> >> > > > > Cc: Ledda William EXT; lin...@li... >> >> > > > > Subject: RE: [Linuxptp-users] Which distributions have >> native >> >> > > > > ptp support? >> >> > > > > >> >> > > > > > -----Original Message----- >> >> > > > > > From: Keller, Jacob E [mailto:jac...@in...] >> You >> >> > > > > > shouldn't have to, however, I would suggest disabling EEE >> >> > > > > > support, as this has been known to cause issues on the >> i350 >> >> > > > > > >> >> > > > > > ethtool --set-eee device eee off >> >> > > > > > >> >> > > > > > This should fix your issue, if not please me know. >> >> > > > > >> >> > > > > Thank you for the reply. >> >> > > > > >> >> > > > > That option does not appear to be available with the stock >> >> > > > > igb driver of RH6.4 >> >> > > > > >> >> > > > > [root@ network-scripts]# ethtool -i eth3 >> >> > > > > driver: igb >> >> > > > > version: 4.0.1-k >> >> > > > > firmware-version: 0.1470, 0x05fc8000 ... >> >> > > > > [root@ network-scripts]# ethtool --show-eee eth3 Cannot get >> >> > > > > EEE >> >> > > > > settings: Operation not supported >> >> > > > > >> >> > > > > Is there another way to disable EEE? Or would not having >> that >> >> > > > > option in ethtool mean it is off? >> >> > > > > >> >> > > > > Gabe >> >> > > > > >> >> > > > > > On Mon, 2013-10-28 at 15:29 +0000, Gabe Black wrote: >> >> > > > > > > Hi William, >> >> > > > > > > >> >> > > > > > > I installed redhat 6.4 and have the intel i350 (with igb >> >> > > > > > > driver) >> >> > > > > and >> >> > > > > > am having trouble getting it to work with a meinberg >> master. >> >> > > > > > > >> >> > > > > > > The output I get is: >> >> > > > > > > >> >> > > > > > > ptp4l[246980.523]: selected /dev/ptp1 as PTP clock >> >> > > > > > > ptp4l[246980.525]: port 1: INITIALIZING to LISTENING on >> >> > > > INITIALIZE >> >> > > > > > > ptp4l[246980.526]: port 0: INITIALIZING to LISTENING on >> >> > > > INITIALIZE >> >> > > > > > > ptp4l[246980.773]: port 1: new foreign master >> >> > > > > > > 00606e.fffe.7c230e- >> >> > > > 1 >> >> > > > > > > ptp4l[246985.014]: selected best master clock >> >> > > > > > > 00606e.fffe.7c230e >> >> > > > > > > ptp4l[246985.014]: foreign master not using PTP >> timescale >> >> > > > > > > ptp4l[246985.014]: running in a temporal vortex >> >> > > > > > > ptp4l[246985.014]: port 1: LISTENING to UNCALIBRATED on >> >> > > > > > > RS_SLAVE >> >> > > > > > > ptp4l[246985.989]: recvmsg tx timestamp failed: Resource >> >> > > > > temporarily >> >> > > > > > > unavailable >> >> > > > > > > ptp4l[246985.989]: port 1: send delay request failed >> >> > > > > > > ptp4l[246985.989]: port 1: UNCALIBRATED to FAULTY on >> >> > > > > > > FAULT_DETECTED >> >> > > > > > > >> >> > > > > > > Did you have to do anything differently on the stock >> >> > > > > > > RH6.4 >> >> > > > install >> >> > > > > > > to >> >> > > > > > get it to work? >> >> > > > > > > >> >> > > > > > > Thanks, >> >> > > > > > > Gabe >> >> > > > > > > >> >> > > > > > > > -----Original Message----- >> >> > > > > > > > From: Ledda William EXT >> [mailto:Wil...@it...] >> >> > > > > > > > Sent: Monday, October 21, 2013 1:02 AM >> >> > > > > > > > To: Richard Cochran; Gabe Black >> >> > > > > > > > Cc: lin...@li... >> >> > > > > > > > Subject: RE: [Linuxptp-users] Which distributions have >> >> > > > > > > > native ptp support? >> >> > > > > > > > >> >> > > > > > > > I'm currently using RH 6.4 with Intel i350 (igb >> driver) >> >> > with >> >> > > > > > success >> >> > > > > > > > (no need to recompile the kernel). About RH 6.5 I know >> >> > > > > > > > that there will be many improvements, more eth driver >> >> > > > > > > > supported, and it should include version 1.3 of >> >> > > > > > > > linuxptp >> >> package. >> >> > > > > > > > >> >> > > > > > > > William >> >> > > > > > > > >> >> > > >> >> > >> >> >> >> -------------------------------------------------------------------- >> - >> >> - >> >> - >> >> ------- >> >> Android is increasing in popularity, but the open development >> >> platform that developers love is also attractive to malware >> creators. >> >> Download this white paper to learn more about secure code signing >> >> practices that can help keep Android apps secure. >> >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg. >> >> c >> >> l >> >> ktrk >> >> _______________________________________________ >> >> Linuxptp-users mailing list >> >> Lin...@li... >> >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users >> > >> >---------------------------------------------------------------------- >> - >> >--- >> >---- >> >Android is increasing in popularity, but the open development platform >> >that developers love is also attractive to malware creators. Download >> >this white paper to learn more about secure code signing practices >> that >> >can help keep Android apps secure. >> >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c >> l >> >ktr >> >k >> >_______________________________________________ >> >Linuxptp-users mailing list >> >Lin...@li... >> >https://lists.sourceforge.net/lists/listinfo/linuxptp-users >> > >> >---------------------------------------------------------------------- >> - >> >--- >> >---- >> >Android is increasing in popularity, but the open development platform >> >that developers love is also attractive to malware creators. Download >> >this white paper to learn more about secure code signing practices >> that >> >can help keep Android apps secure. >> >http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.c >> l >> >ktr >> >k >> >_______________________________________________ >> >Linuxptp-users mailing list >> >Lin...@li... >> >https://lists.sourceforge.net/lists/listinfo/linuxptp-users > |
27 messages has been excluded from this view by a project administrator.
