We have procured over a dozen NUC6i7KYK (mfg 07/2017) to act as a receiver of a moderate rate (~320Mbps) UDP stream of data. We have found that the I219-LM adapter is dropping packets. We have been able to replicate the issue using the iperf tool. For the application (and for my troubleshooting tests) the NUC will be direct connected to the data source via a new, short (~1m), patch cord.

We have the latest BIOS (KYSKLi70.86A.0050.2017.0831.1924) and we are using Ubuntu 16.04.3. We have also tried Ubuntu 16.04.2 and 17.10. We have tried the distro provided e1000e 3.2.6-k driver as well as the latest e1000e 3.3.6 driver.

We have set net.core.rmem_max to 33554432 and net.core.wmem_max to 576000.

We have set coalescence to zero: ethtool -C eno1 rx-usecs 0.

We have maxed the receive ring buffer: ethtool -G eno1 rx 4096.

We have ensured max CPU frequency via cpufreq setting it to "performance".

Data loss is non-deterministic and sometimes happens immediately, after several minutes, or several hours. Typically it is a single missing packet. We can not afford any lost data.

I had a ZBOX-CI323NANO with openSuSE 42.3 on it. This low performance device has Realtek RTL8111/8168/8411 PCIe GbE adapters. It received UDP data with zero losses. That's the sort of results I expect from this NUC.

It has net.core.rmem_max and net.core.wmem_max set to 16777216.

We also have used a Pluggable USB3.0 GbE adapter. It also runs with no lost data - however, it tends to "go away" after indeterminate periods of time - not sure if that's a NUC, OS, or pluggable issue.

I saw this thread that looks familiar to my problem:UDP packets frozen with at least I219-V, I219-LM and I217-LM

When I run wireshark, occasionally I see the interpacket gap be ~10ms instead of the typical handful of microseconds.

Recently added Pro/1000 PT dual port card to the last PCIe2.0 slot on P8Z77-M Pro motherboard. slot was recently used for sound card and RAID card with no issues.

Added Pro/1000 PT NIC to Win10 Creators updated system and it came up working with no issues, streaming data, connecting to my NAS and everything, with ONLY that NIC being used.

Downloaded drivers and tools and try and get advanced features running but run into the same issue. ALL installers think there is no card in the system.

When I run the Intel Driver Support Assistant is tells me that the card is using driver version 9.13.41.3 dated 9/29/2011! and there are no software updates available and the device is working properly. Is this correct??

But yet any installer for Intel® Ethernet Adapter Complete Driver Pack versions 22.10, 22.9, 22.3 show the dreaded "No Intel Adapter are present in this computer"

Running the PROADMIN tool for the same version numbers just gets me a directory that had no further installer tools.

So far I have tried to uninstall the drivers/reboot/install drivers with no change in results.
Also have powered down, uninstalled card, reseated, and rebooted with no change.

Am lost and frustrated and just want to bond these damn ports.

Hi all,

I'm doing intensive testing of OPNsense (firewall solution based on FreeBSD 11.0/11.1) with a device from Jetway with 10 embedded i211-AT NICs: JBC390F541AA :: HBJC390F541AA19B :: Intel Celeron Bay Trail J1900 3.5" SBC Barebone :: JETWAY COMPUTER CORP.

From time to time, the link is not responding any more. E.g. a ping to a neighbor system does not work any more. I do not get any hints in log files.

Only doing a "ifconfig igbX down" followed by a "ifconfig igbX up" fixes the issue.

I did extensive testing which I have documented here:

WAN link gone sometimes (igb driver, I211 nics), ifconfig d/u fixes it (forum.opnsense.org)

As I'm still seeing this issue from time to time, I'd like to ask this question here in case that anybody else has ever seen this issue before.

Best regards,

Werner

I'm trying out mutlicast streaming of uncompressed HD and UHD video uisng VMs and SRIOV with an Intel X520-DA2 NIC (82599 Etherent Control VF).

I can send a mutlicast stream from a VM OK and receive a mutlicast stream on a VM using a SRIOV VF. I'm not using VLANs, just separate MAC/IP address on the same LAN.

If I have 2 VMs on the same host, using separate SRIOV VFs from the same Intel NIC, I can see multicast traffic on both VM interfaces (when only 1 VM has joined the stream).

I have tried turning allmutlicast & promisc mode on/off, but it seems to make no difference.

I can see the traffic using the network stats and using tcpdump in the unjoined VM.

Is this a feature of the NIC, or is there a way to stop traffic going to both VFs/VMs.

For the purpose of testing, I'm using KVM (Virtual Machine Manager) on Ubuntu 16.04, my setup is as follows:

$ lsb_release -a

Ubuntu 16.04.3 LTS, xenial

$ uname -a

Linux ap-z420-0 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -nn | grep -i 'Ethernet Controller'

06:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

06:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

07:10.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

07:10.1 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

07:10.2 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

07:10.3 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

# modinfo ixgbevf
filename:       /lib/modules/4.4.0-104-generic/updates/dkms/ixgbevf.ko
version:        4.2.2
license:        GPL
description:    Intel(R) 10 Gigabit Virtual Function Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     0F89E29947DD944E62FA118

$ ip link show ens3f0
5: ens3f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:72:70:e0 brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 52:54:00:1d:e1:aa, spoof checking on, link-state auto
    vf 1 MAC 52:54:00:1d:e1:ab, spoof checking on, link-state auto

Any suggestions gratefully received.

I have a system I use as a gateway:

Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)

It is a component of a fit/PC Intense running Linux is the 4.9.67-1-lts #1 SMP kernel from Arch Linux.  This problem has been going on for several kernels now over the last month.

Intense PC models specifications

It has been having trouble reseting and possibly check summing.  I use a ssh proxy tunnel which has always remained open and stable to panix.com.  Now it dies

debug1: Connection to port 9000 forwarding to 127.0.0.1 port 8008 requested.

debug1: channel 3: new [direct-tcpip]

debug1: Connection to port 9000 forwarding to 127.0.0.1 port 8008 requested.

debug1: channel 44: new [direct-tcpip]

debug1: Connection to port 9000 forwarding to 127.0.0.1 port 8008 requested.

debug1: channel 45: new [direct-tcpip]

debug1: Connection to port 9000 forwarding to 127.0.0.1 port 8008 requested.

debug1: channel 46: new [direct-tcpip]

debug1: Connection to port 9000 forwarding to 127.0.0.1 port 8008 requested.

debug1: channel 47: new [direct-tcpip]

debug1: Connection to port 9000 forwarding to 127.0.0.1 port 8008 requested.

debug1: channel 48: new [direct-tcpip]

ssh_dispatch_run_fatal: Connection to 166.84.1.2 port 22: message authentication code incorrect

[ruben@flatbush ~]$

from dmesg:

[38972.211043] ffff88041f798da0: f4 6e af f6 83 02 1d 62 8c 12 0f 1a e9 99 89 cf  .n.....b........

[38972.211044] ffff88041f798db0: d3 b9 fc d0 d4 7a dc 96 d0 b0 f9 c3 bb fe c7 ea  .....z..........

[38972.211046] ffff88041f798dc0: 39 51 ea 2c 6d 80 64 43 59 da 15 91 3a 6c 40 05  9Q.,m.dCY...:l@.

[38972.211047] ffff88041f798dd0: a6 50 40 98 d0 bb cf f3 c7 1f e2 41 bd ec 19 05  .P@........A....

[38972.211049] ffff88041f798de0: ab 51 d0 9a 46 90 9b db 3b b2 fd c1 c9 c0 ef 7b  .Q..F...;......{

[38972.211051] ffff88041f798df0: 2a 45 2b f6 fb 42 96 56 af 45 89 23 99 51 4e ef  *E+..B.V.E.#.QN.

[38972.211053] ffff88041f798e00: fd 6c 9a df 51 66 db 3e ca d9 4c f2 ad cb 89 7a  .l..Qf.>..L....z

[38972.211054] ffff88041f798e10: c4 10 47 21 fc a5 4d f3 06 79 1f 8a ba d1 45 53  ..G!..M..y....ES

[38972.211056] ffff88041f798e20: bb 68 0b 8a ab 63 ae b2 1c 38 b0 35 6f 37 66 ec  .h...c...8.5o7f.

[38972.211057] ffff88041f798e30: 02 4a                                            .J

[38972.211062] e1000e 0000:00:19.0 eth1: Reset adapter unexpectedly

[38978.157727] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

[39014.162430] elogind[1369]: New session c4 of user ruben.

[39089.012361] lp: driver loaded but no devices found

[39089.040701] st: Version 20160209, fixed bufsize 32768, s/g segs 256

It has been suggested that I can monkey with the module settings, but I'm not certain what to try or to procede with.  Guessing blindly is usually not useful

modinfo give me this:

Hi!

I need to buy a network card Intel EXPI9301CT and want to know how to distinguish original card from counterfeit.

I know that original card have the following:

1) RJ-45 within opened bus pins and orange tape over it

2) Transformer 'Delta'

3) YottaMark golographic mark (for cards produced since 2009 year)

BUT cards I have seen in the market are differ from original one:

1) RJ-45 pinout contained in the black box

2) Transormer 'Pulse'

3) No any YottaMarks

They looks like as one the ebay page: INTEL EXPI9301CT Gigabit CT Desktop PCI-e Network Adapter 82574L Chipset NIC | eBay

Please help me to know how to distinguish original Intel expi9301ct:

1) Is Intel uses 'Pulse' transformers on its network cards? Is it means that the card is counterfeit?

2) Is YottaMark should be on ALL Intel cards?

Thank you!

Hello,

I have purchased a new Asrock X99 Taichi. The motherboard has two network chips installed onboard:

1. Giga PHY Intel® I218V
2. GigaLAN Intel® I211AT

After trying to install the driver for my Windows Server 2016 operating system I receive the error message 'Not intel adapter available' I have try to install the original drivers from Asrock and Intel but both is not working?

Can anyone help on this issue,

Thanks in advanced

I compiled and installed the network adapter driver for PCIe 40 Gb Ethernet(version 3.4.2). The driver is also loaded in the kernel successfully (Ubuntu 16.04). However, when I connect QSFP+ cables I am getting the following error message:

Rx/Tx is disabled on this device because an unsupported SFP+ module type was detected.

Is this because I am not using Intel QSFP+ cables?

Is there any way to allow unsupported SFP?

Best,

Marjan

Hello everyone,

I'd like to use the XL710-QDA2 QSFP+ network adapter as PCIe expansion card to connect my workstation - Windows 10 PC to my centOS homeserver. However, Windows 10 seems to be lacking compatibility for this card according to official documentation. Can anyone confirm or deny this card would work in a W10 PC ?

Best regards,

Using an updated driver, I cannot seem to get my interfaces up. Looks like the driver is not allowing the NIC to work due to the SFP+ module type, which worked previously on my Debian Stretch host. Clearly the NIC is detecting and reading the DAC, but I don't understand why it is not working. This is a 40G-breakout cable with 40-to-4x10G SFP+ DAC (TwinAx). I have tried adding the following to work around it, but it still does not work:

root@lab4:~# cat /etc/modprobe.d/i40e.conf

options i40e allow_unsupported_sfp=1

This was also discussed here, but there was no followup:

Intel Ethernet Drivers and Utilities / Mailing Lists

Output from dmesg:

[    4.439190] i40e 0000:08:00.3: PCI-Express: Speed 8.0GT/s Width x8

[    4.447918] i40e 0000:08:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 8 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[    4.453414] i40e 0000:08:00.2: Rx/Tx is disabled on this device because an unsupported SFP+ module type was detected.

[    4.465288] i40e 0000:08:00.2: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for a list of supported modules.

Other pertinent output:

root@lab4:~# ethtool -m eth6

Identifier                                : 0x03 (SFP)

Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)

Connector                                 : 0x21 (Copper pigtail)

Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00

Transceiver type                          : FC: Copper Passive

Encoding                                  : 0x00 (unspecified)

BR, Nominal                               : 10300MBd

Rate identifier                           : 0x00 (unspecified)

Length (SMF,km)                           : 0km

Length (SMF)                              : 0m

Length (50um)                             : 0m

Length (62.5um)                           : 0m

Length (Copper)                           : 3m

Length (OM3)                              : 0m

Passive Cu cmplnce.                       : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]

Vendor name                               : Amphenol

Vendor OUI                                : 78:a7:14

Vendor PN                                 : 624400003

Vendor rev                                : A

Option values                             : 0x00 0x00

BR margin, max                            : 0%

BR margin, min                            : 0%

Vendor SN                                 : APF13470035GDT

Date code                                 : 131122

root@lab4:~# ethtool -i eth6

driver: i40e

version: 2.4.3

firmware-version: 6.01 0x800034af 1.1747.0

expansion-rom-version:

bus-info: 0000:08:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

root@lab4:~# ethtool eth6

Settings for eth6:

Supported ports: [ ]

Supported link modes:   Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes:  Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: Unknown!

Duplex: Unknown! (255)

Port: Other

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

       drv probe link timer

Link detected: no

root@lab4:~# ip link show eth6

5: eth6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000

    link/ether 68:05:ca:2f:7c:b0 brd ff:ff:ff:ff:ff:ff

Hi. We have Dell PowerEdge 730s that have Intel X710 cards. LLDP does not work at all. Latest Dell firmware for the card and driver from the VMware HCL. We are running latest ESXi v6.5. I have noticed some threads that LLDP just does not work.

This is very important to us. Is there a time frame when this will be fixed? Thanks,,,

Can an I210* and I217-LM be configured for teaming together?  In Windows 10 and Windows Server 2016?

Same questions for: I210 and I219-LM - can they be teamed?

* As an aside:  I'm a little confused by the I210 designation.  Can somebody clarify this for me?

• I'm pretty sure these motherboards have an I210-AT NIC.
• The Intel SSU tool identifies the NIC as I210 with no suffix.
• I don't see an Ark page for I210, but there is a data sheet for I210.
• There are Ark pages for the five I210 variants (I210-AS, I210-AT, I210-CS, I210-IS, I210-IT) listed in the "Ethernet Controller I210 Series" (Intel® Ethernet Controller I210 Series Product Specifications)
• So are the five I210 variants all function- and feature- same?

Card is in a Dell PE M620.  Seeing multiple cases where trying to create a static link aggregation is failing with the message "All device in a Static Link Aggregation team must be capable of running at the same speed.  At least one device in the team is not capable of running at a lower speed."

This message appears even when trying to create a team with just one adapter.   Both the switch ports and the NICs are set to 10 Gb Full.  Operating system is WIndows Server 2012R2 but has also happened on Server 2008R2,

Hello,

after the update to Windows 10 (x64, Build 10240) the creation of a teaming group (static or IEEE802.3ad) with a I211+I217-V NIC fails.

Drivers have been upgraded to the latest version available and multiple reinstallations with reboots din't help either. Whenever the group creation wizzard is used and a groupname (several tried), the adapters and LACP have been selected, a Windows pop-up appears to tell me group creation has failed.

However the Windows Device Manager shows a newly created "Intel Advanced Network Services Virtual Adapter", so some kind of configuration seems to get done.

Using Windows 7 SP1 x64 the exact same setup worked flawlessly for months, so Win10/the driver are the likely culprit.

Is anyone experiencing similar problems and/or is this a known bug? Feedback on this issue is greatly appreciated.

Thanks in advance!

Kind regards,

Famaku

Like others, I bought an X550-T2 (direct from Amazon themselves) and the Yottamark is valid, but the MAC doesn’t match.

Is this going to be an on-going production problem?

I'm trying out mutlicast streaming of uncompressed HD and UHD video uisng VMs and SRIOV with an Intel X520-DA2 NIC (82599 Etherent Control VF).

I can send a mutlicast stream from a VM OK and receive a mutlicast stream on a VM using a SRIOV VF. I'm not using VLANs, just separate MAC/IP address on the same LAN.

If I have 2 VMs on the same host, using separate SRIOV VFs from the same Intel NIC, I can see multicast traffic on both VM interfaces (when only 1 VM has joined the stream).

I have tried turning allmutlicast & promisc mode on/off, but it seems to make no difference.

I can see the traffic using the network stats and using tcpdump in the unjoined VM.

Is this a feature of the NIC, or is there a way to stop traffic going to both VFs/VMs.

For the purpose of testing, I'm using KVM (Virtual Machine Manager) on Ubuntu 16.04, my setup is as follows:

$ lsb_release -a

Ubuntu 16.04.3 LTS, xenial

$ uname -a

Linux ap-z420-0 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ lspci -nn | grep -i 'Ethernet Controller'

06:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

06:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

07:10.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

07:10.1 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

07:10.2 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

07:10.3 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

# modinfo ixgbevf
filename:       /lib/modules/4.4.0-104-generic/updates/dkms/ixgbevf.ko
version:        4.2.2
license:        GPL
description:    Intel(R) 10 Gigabit Virtual Function Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     0F89E29947DD944E62FA118

$ ip link show ens3f0
5: ens3f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:72:70:e0 brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 52:54:00:1d:e1:aa, spoof checking on, link-state auto
    vf 1 MAC 52:54:00:1d:e1:ab, spoof checking on, link-state auto

Any suggestions gratefully received.

Hi,

I have an Dell CS24-TY server fitted by manufacturer (as I know this series is made by Quanta) with a dual NIC (Intel® 82576) and with up to date Windows 2012 R2 OS. The two nic's are regularly configured in NIC-Team (but also where sometimes let alone). I noticed that from some time (let say some four, five months ago), regularly but in a random way Windows reports that media was disconnected. The only way to solve this condition is to restart the server. This bother me in many way since is my DNS server, my domain controller and so on. I may not believe that is a hardware condition since after reboot it restores connection. So before considering to buy another PCI-e NIC (that is somehow expensive) I try to find that maybe this condition is a kind of miss-configuration.

In Windows Event Viwer regularly I found entries like this:

//

Member Nic {b0978897-b852-4cef-a552-e0cc7adc0010} Disconnected.

//

The description for Event ID 27 from source e1iexpress cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Intel(R) 82576 Gigabit Dual Port Network Connection

the message resource is present but the message is not found in the string/message table

//

followed at seconds

//

Member Nic {14ae3c8c-2f85-4b17-91d6-bf591a9014ef} Disconnected.

//

The description for Event ID 27 from source e1iexpress cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Intel(R) 82576 Gigabit Dual Port Network... [5,0,1]

the message resource is present but the message is not found in the string/message table

//

After digging the event log I may find issues like this that by any appreciations are followed by a "natural" restore (a very temporary condition), but mainly after this I have to manually reboot the server.

Any hints to investigate this are welcomed.

Regards

Setup:

Debian 8 (Jessie)

Kernel: Linux 3.16.0-4-686-pae

IGB Driver: 5.3.5.12 (the same problem occurs with the original driver from Debian, 5.0.5-k)

After several days (between 2-20) our systems stop receiving multicast packets for certain groups they belong to. Each of these systems has two interfaces, an IGB and e1000e which are bonded together (Bonding Mode: fault-tolerance (active-backup)). The problem only ever occurs when the IGB is the Active Interface.

The switch to which the IGB interface is connected, is sending the relevant multicast packets to the Interface - this has been verified by using port-mirroring on the switch. However if I run tcpdump in non-promiscuous mode, I do not see any incoming packets for that group but I do see the outgoing IGMP Group Report.

Using tcpdump in promiscuous mode will reset the interface, which immediately fixes the problem and I will see the traffic.

Netstat always reports active membership of the intended groups:

root@vlab-210-03:~# netstat -gn

IPv6/IPv4 Group Memberships

Interface       RefCnt Group

--------------- ------ ---------------------

lo              1      224.0.0.1

eth1            1      224.0.0.1

bond0           1      224.0.0.251

bond0           1      224.0.0.1

bond0           1      239.255.10.10

bond0           1      239.255.10.11

bond0           4      239.110.92.1

bond0           2      224.0.0.107

bond0           3      224.0.1.129

eth0            1      224.0.0.1

It is only ever the groups 239.255.10.10 and 239.255.10.11 which fail, and this only occurs when using the IGB interface. Other multicast traffic functions normally.

The two affected groups are carrying a large volume of video traffic.

The system is still running in a failed state, so I can query it for more information.

Thanks,

Tom.

Using an updated driver, I cannot seem to get my interfaces up. Looks like the driver is not allowing the NIC to work due to the SFP+ module type, which worked previously on my Debian Stretch host. Clearly the NIC is detecting and reading the DAC, but I don't understand why it is not working. This is a 40G-breakout cable with 40-to-4x10G SFP+ DAC (TwinAx). I have tried adding the following to work around it, but it still does not work:

root@lab4:~# cat /etc/modprobe.d/i40e.conf

options i40e allow_unsupported_sfp=1

This was also discussed here, but there was no followup:

Intel Ethernet Drivers and Utilities / Mailing Lists

Output from dmesg:

[    4.439190] i40e 0000:08:00.3: PCI-Express: Speed 8.0GT/s Width x8

[    4.447918] i40e 0000:08:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 8 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[    4.453414] i40e 0000:08:00.2: Rx/Tx is disabled on this device because an unsupported SFP+ module type was detected.

[    4.465288] i40e 0000:08:00.2: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for a list of supported modules.

Other pertinent output:

root@lab4:~# ethtool -m eth6

Identifier                                : 0x03 (SFP)

Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)

Connector                                 : 0x21 (Copper pigtail)

Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00

Transceiver type                          : FC: Copper Passive

Encoding                                  : 0x00 (unspecified)

BR, Nominal                               : 10300MBd

Rate identifier                           : 0x00 (unspecified)

Length (SMF,km)                           : 0km

Length (SMF)                              : 0m

Length (50um)                             : 0m

Length (62.5um)                           : 0m

Length (Copper)                           : 3m

Length (OM3)                              : 0m

Passive Cu cmplnce.                       : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]

Vendor name                               : Amphenol

Vendor OUI                                : 78:a7:14

Vendor PN                                 : 624400003

Vendor rev                                : A

Option values                             : 0x00 0x00

BR margin, max                            : 0%

BR margin, min                            : 0%

Vendor SN                                 : APF13470035GDT

Date code                                 : 131122

root@lab4:~# ethtool -i eth6

driver: i40e

version: 2.4.3

firmware-version: 6.01 0x800034af 1.1747.0

expansion-rom-version:

bus-info: 0000:08:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

root@lab4:~# ethtool eth6

Settings for eth6:

Supported ports: [ ]

Supported link modes:   Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes:  Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: Unknown!

Duplex: Unknown! (255)

Port: Other

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

       drv probe link timer

Link detected: no

root@lab4:~# ip link show eth6

5: eth6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000

    link/ether 68:05:ca:2f:7c:b0 brd ff:ff:ff:ff:ff:ff

I have recently found the PTP protocol was disabled on x710 due to security reason (L4 timestamping rejected, intel-SA-00063) . Just wondering any plan to enable PTP in the future?