Re: [Linuxptp-users] Anyone using Intel i350v2-T2 on RedHat Linux?
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
Re: [Linuxptp-users] Anyone using Intel i350v2-T2 on RedHat Linux?
|
From: Ledda W. E. <Wil...@it...> - 2015-01-28 08:38:53
|
Hello Rich
I’m using a i350-AM2 (integrated in the motherboard) with RH 6.5 with both kernels 2.6.32-431.20.3.el6.x86_64 and 3.10.33-rt32.52.el6rt.x86_64. I can run ptp4l version 1.3 without issues. I have also tested it on RH 6.4 and I have always used the driver provided by RH. Why have you installed a different driver? Remember that while the PTP support was introduced starting from kernel 3.10, RH has backported it into kernel 2.6x so it is highly customized. It is possible that the “community driver” is not fully compatible with RH.
$ uname -r
2.6.32-431.20.3.el6.x86_64
$ ethtool -i eth2
driver: igb
version: 5.0.5-k
firmware-version: 1.61, 0x8000090f
bus-info: 0000:24:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
$ ethtool -T eth2
Time stamping parameters for eth2:
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: 2
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
From: Rich Schmidt [mailto:sch...@gm...]
Sent: 28 January 2015 00:42
To: linuxptp-users
Subject: [Linuxptp-users] Anyone using Intel i350v2-T2 on RedHat Linux?
I have tested the Intel 82547L and the i210 NICs with linuxptp 1.4 and 1.5.
They work fine on our Red Hat Linux kernel make -C /lib/modules/2.6.32-504.3.3.el6.x86_64.
But I cannot get the i350T2V2BLK to work.
It sees the correct PTP Grandmaster 0019dd.fffe.00085c, but all I get this, even increasing tx_timestamp_timeout to 1000:
ptp4l -i eth2 -f /etc/ptp4l.conf -m -l 7
ptp4l[181.099]: eth2: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[181.099]: port 1: UNCALIBRATED to LISTENING on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[183.076]: port 1: setting asCapable
ptp4l[183.078]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[187.079]: selected best master clock 0019dd.fffe.00085c
ptp4l[187.079]: foreign master not using PTP timescale
ptp4l[187.079]: running in a temporal vortex
ptp4l[187.079]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[194.076]: port 1: delay timeout
ptp4l[194.176]: timed out while polling for tx timestamp
ptp4l[194.176]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[194.176]: port 1: send delay request failed
...
I have installed the latest igb driver 5.1.15.
ethtool -i eth2
driver: igb
version: 5.2.15
firmware-version: 1.63, 0x80000cbb
bus-info: 0000:10:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
[root@ptp2 ~]# ethtool -T eth2
Time stamping parameters for eth2:
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)
I have installed an i210, which uses the same driver, and it works nicely:
ptp4l -i eth4 -f /etc/ptp4l.conf -m -l 7
option pi_offset_const is deprecated, please use step_threshold instead
option pi_f_offset_const is deprecated, please use first_step_threshold instead
option pi_max_frequency is deprecated, please use max_frequency instead
ptp4l[1301.376]: selected /dev/ptp0 as PTP clock
ptp4l[1301.376]: PI servo: sync interval 1.000 kp 0.700 ki 0.300000
ptp4l[1301.377]: eth4: SO_SELECT_ERR_QUEUE: Protocol not available
ptp4l[1301.377]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1301.377]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[1301.827]: port 1: setting asCapable
ptp4l[1301.829]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[1305.829]: selected best master clock 0019dd.fffe.00085c
ptp4l[1305.829]: foreign master not using PTP timescale
ptp4l[1305.829]: running in a temporal vortex
ptp4l[1305.829]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[1307.828]: PI servo: sync interval 2.000 kp 0.350 ki 0.150000
ptp4l[1309.441]: port 1: delay timeout
ptp4l[1309.494]: path delay 14356 14356
ptp4l[1309.829]: master offset -16816366 s0 freq -16632 path delay 14356
.
.
.
ptp4l[1341.934]: port 1: delay timeout
ptp4l[1342.034]: path delay 947 947
ptp4l[1342.992]: port 1: delay timeout
ptp4l[1343.092]: path delay 957 968
ptp4l[1343.272]: port 1: delay timeout
ptp4l[1343.372]: path delay 957 979
ptp4l[1343.830]: master offset -264 s2 freq -16676 path delay 957
ptp4l[1345.830]: master offset -315 s2 freq -16741 path delay 957
ptp4l[1347.830]: master offset -216 s2 freq -16739 path delay 957
ptp4l[1349.830]: master offset -116 s2 freq -16721 path delay 957
ptp4l[1351.217]: port 1: delay timeout
ptp4l[1351.318]: path delay 928 910
ptp4l[1351.830]: master offset 12 s2 freq -16675 path delay 928
ptp4l[1353.830]: master offset -79 s2 freq -16718 path delay 928
ptp4l[1355.830]: master offset 61 s2 freq -16660 path delay 928
ptp4l[1355.865]: port 1: delay timeout
ptp4l[1355.965]: path delay 928 956
ptp4l[1357.713]: port 1: delay timeout
ptp4l[1357.813]: path delay 928 1015
ptp4l[1357.830]: master offset -70 s2 freq -16716 path delay 928
If anyone has had success, please reply.
With thanks, Rich Schmidt
|
