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

Hi. I have X710-DA4 with Intel SFP+ moduls, which connected to optical splitter by single fiber (only receive mode). The link, which splitted, is 1000Base-LX. At firmare versions 5.05 and 4.53 everething is Ok, i can receive the signal. But after update to version 6.01 signal is loss, interfaces get out from RUNNING state. Downgrade to older versions of firmware lead back to RUNNINg state of interfaces. What wrong with new firmware.

OS: RHEL 7.5, kernel 3.10.0-862, driver - both 2.1.14 (built in kernel) and 2.7.11 with no difference.

Yhank you.

Hi Vince,

We have experienced PSOD's in ESXI 6.0 using the i40e 1.5.6 driver, and upgraded to the 1.7.11 driver and latest firmware to resolve. This has introduced the Malicious Driver Event issue, causing us downtime this morning and causing us to remove the X710 NICs from our vSwitch and run on 1GbE NICs. Appreciate any advice.

Kind regards,

Kye

Hi,

I have a Intel(R) I210 Gigabit Network Connection on my system, and I have the problem, that there is a huge (24s) delay between startup and Network link connected.

at 16:54:35:

The Intel(R) PROSet Monitoring Service service entered the running state.

at 16:54:36

Intel(R) 82579LM Gigabit Network Connection Network link is disconnected (this is ok, because there is no cable)

at 16:54:36

Intel(R) I210 Gigabit Network Connection Network link is disconnected. (this is not ok, because there is a cable connected on it)

at 16:54:59:

Intel(R) I210 Gigabit Network Connection Intel SmartSpeed has downgraded the link speed from the maximum advertised.

at 16:54:59:

Intel(R) I210 Gigabit Network Connection Network link has been established at 100Mbps full duplex.

If I plug in the cable on the other network adapter (Intel 825879LM, the network adapter is conneceted instantly).

I'm using the network driver Intel® Network Adapter Driver for Windows 7* Version 23.2 (latest).

Hi,

We have several HP DL380Gen9 with x520 10Gb NIC, and use CentOS. After Update CentOS 7.2 to 7.4, we found same SFP+ module (HP 10Gb SR SFP+) behave differently:

      1, Centos 7.2+ixgbe 5.3.7:  SFP+ Module works fine.

      2, CentOS 7.4+ixgbe 5.3.7: SFP+ Module doesnot work.  The value of comp_codes_10g/comp_codes_1g in ixgbe_identify_sfp_module_generic of ixgbe driver is zero, and cause the SFP+ modules cannot be identified.

By comparison test, we also found:

     1, Using allow_unsupported_sfp param cannot fix this problem.

     2, Using CentOS 7.4+x520+other SFP+ module(from HPE or other vendor), SFP+ Module can work fine.

These make us very confused and wanna to know:

     1, the reason of comp_codes_10g/comp_codes_1g becomes zero.

     2, how fix this problem.

     3, is it related to kernel or driver.

Any ideas and suggestions will be appreciated, Tks a lot!

Hello

I'm running Supermicro X11SSL-F motherboard with networking adapter Inter i210-AT

Next issue is faced after updating motherboard BIOS to latest version (2.2) -- with Windows Server 2012 R2 is being used -- network adapter becoming unstable after 10-14 GB of transmitted data. It either stop sending\receiveing data (like buffer overflow) or drops connection at all.

Tried recommendations, described in document TA-201, tried disable TCP offloading, tuning down to lower link speed, disabling power saving features - no luck, until restart system refuses to transmit big amounts of data, while may be still available sometimes via RDP (or sometimes starting to drop packets completely). Disabling\enabling adapter on running system has no effect.

Basically, I'm runned out of ideas. Main suggestion was a faulty BIOS update, but issue does not reproducing on Linux (Debian\Centos\Ubuntu), so this seems to be more driver issue.

OS: Windows Server 2012 R2, build 9600

Driver package version: 23.2

Driver version (from device properties) - 12.14.7.0, date 11/3/2017

Please advice.

Hello,

I use the I219-V network adapter and wanted to know why the "test cable connections and frequency response" test does not work.

The cable is a goobay patch cable CAT6 S / FTP 30 meters, double shielded, with a connection to the VDSL modem / router. I'm using Windows 10 1803 x64 with the latest Intel Lan driver.

3 pictures:

greetings

Delt64

I have been trying S3 Resume using WOL feature. Tried 2 different cards on the same machine.

->With broadCom external NIC, WOL S3 resume worknig fine.

-> With Intel EXPI9301CT Adapter, WOL not working on the same platform with the same BIOS and device manager settings..

Operating system Used:Windows 10.

Enabled all the settings. Enabled "allow this device to wake the computer" is enabled under "Power Management" tab of the CT adapter in Device Manager, Enabled "Enable PME" settings in BIOS.

In the working Boradcom adapter case, after S3 sleep the link light on the adapter port was lit. But for Intel EXPI9301CT card, the link light was not lit after S3 sleep.

Whether the WOL was supported for EXPI9301CT card? Whether any settings needed for this card?

Thanks in advance,

Vas

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

We added a new node to our cluster and we've got 2 of the Intel X710-T4 cards in the server. Both of our SANs are currently only 1Gb (we have a Tegile T3100 and a Lenovo px12-450r). Whenever i try to setup SAN connections using one of the ports on these NICs it causes all sorts of issues. We have CSVs go offline and report being corrupted and unreadable, we've lost VM configs and VMs stop booting from any volumes that are being hosted by this node (2016 Hyper V cluster). The odd part is that this same node was working fine in our 2012 cluster before we updated/migrated into 2016. I have the latest drivers for the adapter. Here are some things that have happened:

- When I initially brought the node into the cluster I configured all 3 connections to the SANs using the X710-T4 (2 for the tegile for each independent switch/controller and 1 for the lenovo which is directly connected). Right off the bat each time this node took ownership of either volume on the Lenovo the VMs that were on that volume would no longer boot. They would give different weird boot errors and eventually it would even hard lock the Lenovo SAN itself and I'd have to hard boot it. I moved that connection down to the onboard broadcom 1Gb NIC and that solved those issues. The tegile was still connected via the X710-T4 and while it continued to operate, some odd things happened here as well. Sometimes the list of connected iSCSI devices would just be blank on that node even though it was still operating. In the latest case the node took ownership of a LUN from the Tegile and immediately all the VMs on that LUN stopped working and the CSV reported as corrupt and unreadable. I moved the CSV to another node and after a while it finally started working again. Problem is this node insists on taking ownership of storage nodes and there doesnt appear to be a way to stop it (cant set node preferences on CSVs). So right now I'm scared to unpause this node and am contemplating just moving the Tegile connections into the broadcom as well and hopefully avoid all the hassle.... but when we eventually do upgrade our SAN and go 10Gb I dont want to run into this issue again.

I realize this is probably incredibly hard to decipher... at this point I'm just looking for suggestions. Is it one of the adapter properties? The adapters that connect to the SANs have all protocols except IPv4 unchecked, they have jumbo frames set to 9014 and they are set to not allow the OS to turn them off (power saving thing). Aside from that they are basically at default settings. I think I could probably disable SRV-IO on these adapters but is that causing my issue (I doubt it). Let me know what you think!

I've been trying to run the DSA, but it just says...

               Oops, something went wrong while trying to scan. Please try again, or see our FAQs for help.

There's nothing in the FAQs which seems relevant. I've tried uninstalling and reinstalling DSA, with no change. Is there an error log file somewhere?

I'm running Windows 10 1809 on an HP Tower system. The same result occurs in Chrome (version 69), Edge and Firefox (version 62). IE simply leaves spinning icon running indefinite;y.

Dear Friends,

Please help me with native driver for Windows XP 32 bit (not for 64 bit!) for one Intel network chip (discontinued).

Intel 82579LM (wired gigabit NIC)

also me need native driver for Windows XP 32 bit ˜(not for 64 bit!) for wireless chip (discontinued):

Intel Centurion Advanced-N 6205 (WiFi chip)

Yes, i understand what these device are discontinued but in any case i'm need of these drivers.

I had read what Intel has delete drivers for discontinued NICs for some reason. I will not have any claims to Intel and not to all, me need drivers.

Please help me!

Thanks in advance!

Sergey

Using Intel Ethernet 700 Series Network Adapters in VMware ESXi 6.x

The Intel® Ethernet 700 Series (700 Series) is made up of several discrete controllers and a network connection that is part of the Intel® 620 Chipset:

• Intel® Ethernet Controller XL710
• Intel® Ethernet Controller XXV710
• Intel® Ethernet Controller X710
• Intel® Ethernet Connection X722

All devices in the series share the same architecture and the same set of drivers, with the exception that the Intel® Ethernet Connection X722 has up to four 10 GbE ports and is RDMA iWARP capable.

As with many network devices, there are currently two different API-based drivers that are available for the Network Adapters based on the 700 Series Controllers and Connection.

1. The legacy VMKLinux API-based ESXi driver: i40e
2. Native Mode API-based ESXi driver: i40en

Intel recommends using the Native Mode API-based ESXi drivers for all Intel Ethernet Network Adapters.  Native Mode API-based ESXi driver’s naming scheme ends with the letter “n”, as seen with the 700 Series Network Adapter Native Mode API-based ESXi driver is named “i40en”.  When selecting a driver from the VMware VCG site, ensure that you select the Native Mode API-based ESXi driver (i40en,) since the version number may be lower than the legacy (VMKLinux API-based) driver.

The following table shows examples of the recent retail versions of the 700 Series Network Adapters, and how they are mapped to controllers and VMware Native Mode API-based ESXi driver.

There are two different types for each of the drivers:

• inbox driver - Version included by VMware in the ESXi ISO image.
• async driver - Posted on the VMware driver support site and updates the inbox driver .

In some cases, the inbox driver is still the i40e legacy (VMKLinux API-based) ESXi driver and should be updated to the latest i40en (Native Mode API-based) ESXi driver.  In general, all the firmware versions should be at the same level, and the latest i40en driver should be used.  In some cases, firmware versions may be displayed as a family version, which is different than the actual firmware version number.  In this case, check the firmware readme or release notes for the actual firmware version.

Since the features and configuration of the 700 Series use a combination of firmware and an OS driver that should be updated per the support matrix found in the Intel® Ethernet Controller X710/ XXV710/XL710 Feature Support Matrix document or Intel support site.

https://www.intel.com/content/dam/www/public/us/en/documents/release-notes/xl710-ethernet-controller-feature-matrix.pdf

The following information provides the recommended combinations of VMware ESXi* driver and NVM firmware versions for 700 Series Controllers, Network Adapters, and Connections to use in a VMware environment.

Intel® Ethernet 700 Series Network Adapters

Intel® Ethernet Connection X722

1. NVM image version on the 700 Series Network Adapters might be version 5.04 or 6.01.  These versions are also compatible with the NIC driver associated on that same row above.
2. NVM image version on the Intel Ethernet Connection X722 might be version 3.28 or 3.51.  These versions are also compatible with the NIC driver associated on that same row above.

Acronyms used in tables:

• NVM = Refers to non-volatile memory (typically EEPROM, Serial EEPROM memory)
• NIC = Network Interface Controller
• CIM = Common Information Model
• FW = Firmware

For a listing of all devices supported by VMware*, see VMware* Compatibility Guide: I/O Device Search.

1. Go to VMware Compatibility Guide: I/O Device Search.
2. Select Product Release Version: Pick the product version (optional).
3. Select Brand Name: Intel.
4. Select I/O Device Type: Network.
5. In Keyword, enter part of the device or driver name in quotes. For example, “X710” or “i40en”.
6. In Search Results, click the adapter name in the model column.
7. In Model Release Details, view the list of all releases and compatible device drivers.
8. For details on the release and driver, including a link to the driver download site, click + to expand the row.

While some use the same version of the firmware and drivers as their Intel-branded counterpart, other OEM network adapters do have specific firmware and OS drivers, and are managed via the OEM’s configuration and update tools.  In the case where a server is using a combination of OEM -branded and Intel-branded retail network adapters, it may be necessary to use more than one firmware update tool.  For example, use the Intel update tool to update the Intel-branded network adapters, and the OEM update tools to update the OEM-branded network adapters.  It is also important to follow the server configuration and supported hardware requirements that can vary from server to server.

Link to Intel® Ethernet NVM Update Tool Quick Usage Guide for VMware ESX:

https://www.intel.com/content/www/us/en/embedded/products/networking/nvm-update-tool-vmware-esx-quick-usage-guide.html

Link to Non-Volatile Memory (NVM) Update Utility for Intel® Ethernet 700 Series Network Adapter download:

https://downloadcenter.intel.com/download/24769

 
Example Update and Output:

[root@localhost:/vmfs/volumes/datastore(1)/XL710/ESXi_x64] ./nvmupdaten64e

Intel(R) Ethernet NVM Update Tool

NVMUpdate version 1.30.2.0

Copyright (C) 2013 - 2017 Intel Corporation.

WARNING: To avoid damage to your device, do not stop the update or reboot or power off the

system during this update.

Inventory in progress. Please wait [..+*******]

Num Description                                 Device-Id B:D   Adapter Status

=== ======================================      ========= ===== ====================

01) Intel(R) Ethernet 10G 4P X710/I350 rNDC     8086-1572 01:00 Update not available

02) Intel(R) Ethernet Converged Network Ad      8086-1572 03:00 Update available

03) Intel(R) Ethernet Converged Network Ad      8086-1572 05:00 Up to date

Options: Adapter Index List (comma-separated), [A]ll, e[X]it

Enter selection: 2

Would you like to back up the NVM images? [Y]es/[N]o: y

Update in progress. This operation may take several minutes.

[...*******]

Please Power Cycle your system now and run the NVM update utility again to complete the

update. Failure to do so will result in an incomplete NVM update.

Tool execution completed with the following status: All operations completed successfully.

Press any key to exit.

There are several ways to determine which firmware update tool is required.

• Search on the server OEM’s support site for the latest firmware update tool. If all the network devices are listed as up-to-date or show that an update is available, only the OEM update tool is needed.
• If the OEM update tools reports back a lower firmware version then the latest, but the status shows “Update not available”, try running the Intel firmware update tool found on the Intel support site.

How do I find 700 Series Network Adapters or OEM-branded version drivers in the VMware Compatibility Guide?

1. Go to VMware Compatibility Guide: I/O Device Search.
2. Select Product Release Version: Pick the product version (optional).
3. Select Brand Name: Intel or OEM name.
4. Select I/O Device Type: Network.
5. In Keyword, enter part of the device or driver name in quotes. For example, “X710” or “i40en”.
6. Optional for SR-IOV: In Features, select SR-IOV.
7. In Search Results, click the adapter name in the model column.
8. In Model Release Details, view the list of all releases and compatible device drivers.
   NOTE: Select the i40en (Native Driver).
9. For details on the release and driver, including a link to the driver download site, click + to expand the row.

The primary issue is after several hours to upwards of a couple weeks a single VF will get into a bad state for a guest and we will see the following errors on the parent and child.

Versions:

Centos = 7.5.1804

Kernel = 4.4.121-1.el7.centos.x86_64 (Current); Tried 3.10.0, 4.4.75, 4.9.52, 4.14.68

IXGBE = 5.3.7 (Current); Tried 5.3.5, 4.2.1-k, ......

IXGBEVF = 4.3.5 (Current); Tried 2.12.1-k, ....

QEMU = 1.5.3 (Current); Tried 2.0.0

Libvirt = 3.9.0 (Current)

On the parent we will see this error:

ixgbe 0000:05:00.0 ethx: 193 Spoofed packets detected
ixgbe 0000:05:00.0 ethx: 45 Spoofed packets detected
ixgbe 0000:05:00.0 ethx: 3 Spoofed packets detected
ixgbe 0000:05:00.0 ethx: 126 Spoofed packets detected

On the child you will see an increase in dropped packets.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:5e:a9:f8 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    455429589913 520093667 0       375674  0       375680
    TX: bytes  packets  errors  dropped carrier collsns
    463147231075 514071570 0       0       0       0

I don't have a way to view the spoofed packets going out, but I can see the incoming packets getting corrupted and dropped by the guest. Best example is an ARP since it will hit every parent, child. (IPs censored)

Parent capture:

10:36:26.492879 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has ZZZ.ZZZ.ZZZ.ZZZ tell XXX.XXX.XXX.XXX, length 46
10:36:26.540880 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has BBB.BBB.BBB.BBB tell XXX.XXX.XXX.XXX, length 46
10:36:26.553161 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has AAA.AAA.AAA.AAA tell XXX.XXX.XXX.XXX, length 46
10:36:26.559508 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has YYY.YYY.YYY.YYY tell XXX.XXX.XXX.XXX, length 46

Child Capture:

10:36:26.501491 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has ZZZ.ZZZ.ZZZ.ZZZ tell XXX.XXX.XXX.XXX, length 46
10:36:26.549499 00:00:00:00:00:00 > 00:00:00:00:00:00, 802.3, length 0: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Command], length 46
        0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
10:36:26.561776 00:00:00:00:00:00 > 00:00:00:00:00:00, 802.3, length 0: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Command], length 46
        0x0000:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0010:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............
10:36:26.568122 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has YYY.YYY.YYY.YYY tell XXX.XXX.XXX.XXX, length 46

During the time this one VF is in a bad state, all other guests will see the same packets as the parent. The only current solution is to reboot the guest. Sometimes destroy the guest and start it back up.

Hello All,

I am facing an issue where I am running OVS+DPDK on my host machine to provide networking between VM's. Additionally, I am using a separate NIC to provide SRIOV VF's to VM.

When I launch a VM with a combination of VIRTIO (mgmt - eth0 interface) + SRIOV-VF (data plane interface), I am noticing that when GUEST VM'S DPDK RIOT starts running with VF NIC as one of the nic card, the VM loses connectivity over other virtio interfaces. I have verified that Guest VM's dpdk is only binding the given VF and other VirtIO based NIC cards are managed by Kernel Driver.

Though, the VF NIC on the host machine is added to DPDK managed NICS on the host machine. Please note, the PF is still part of kernel managed nic cards.

Upon further debugging, I have noticed that, as soon as the DPDK RIOT starts running inside the Guest VM, the OVS+DPDK (running on host) removes the other Virtio Ports.

Host VM : RHEL7.2 - Guest VM - WRL6

Please let me know, if any further information is needed.

Thanks

Pratik

Hello,

I'm having some issues using VLANs on a new system. (See system Specs at Bottom)

Last coupe of days I have tried to update the drivers to make VLANs work on my laptop.

First driver I tried to install went well. I could see The VLAN tab when configuring my network connection.
However when I tried to add a VLAN the laptop gave me a BSOD with BAD_POOL_CALLER as error message.

I tried to reinstall a couple of times, rebooted a few times and it alway repaired itself to the previous Driver installed.
Driver used: Download Intel® Network Adapter Driver for Windows® 10

After some searching on the web I found that  alot of people had an issue like this. There was a problem with the ProSet option during the driver installation and one post suggested another driver provided by Intel that would fix the issue crashing.

Using this driver solved the BSOD issue, but whenever I make a VLAN, it deactivates itself. activating it doesn't work, it just stays deactivated.
Driver used: https://downloadcenter.intel.com/download/25016/Intel-Network-Adapter-Driver-for-Windows-10?product=...

After some searching on the web I found this article from 2016 saying that VLAN or teaming or not supported by windows 10 with the ProSet driver.

Because it was an old article I searched for a more  recent one and found this.

So I tried to install every driver beginning from the newest one and ending on 22.3 as the article says following:

Every driver has these same issues.

Driver page: Download Intel® Network Adapter Driver for Windows® 10

Anyone here who had/has similar issues?

Are there any known solutions for these issues?

Best regards,

Bert
----------------------------------------------------System Specifications

Manufacturer:Lenovo

Model: X1 Carbon

OS: Windows 10 Pro 64 Bit

Processor: Intel(R)  Core(TM) i7-7500U CPU @2.70GHz 2.90GHz

RAM: 16GB

Ethernet adapter: Intel(R) Ethernet Connection (4) I219-V

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

Hi all,

I have a weird problem with a Dell branded X710 4*10G SFP+,  on a Dell R740.

The card is receiving traffic on one port for traffic analysis (I have a SPAN port on a switch).

The software that receives the packets, either stops receiving packets from the card or it receives less packets.

For example:

root@lts16:~/.ssh# pfcount -i ens16

Using PF_RING v.7.2.0

Capturing from ens16 [mac: 3C:FD:FE:99:99:13][if_index: 5][speed: 0Mb/s]

# Device RX channels: 4

# Polling threads:    1

Dumping statistics on /proc/net/pf_ring/stats/24791-ens16.24

=========================

Absolute Stats: [0 pkts total][0 pkts dropped][0.0% dropped]

[0 pkts rcvd][0 bytes rcvd]

=========================

=========================

Absolute Stats: [0 pkts total][0 pkts dropped][0.0% dropped]

[0 pkts rcvd][0 bytes rcvd][0.00 pkt/sec][0.00 Mbit/sec]

=========================

Actual Stats: [0 pkts rcvd][1'000.32 ms][0.00 pps][0.00 Gbps]

=========================

When I poke the PF card via ethtool, like "ethtool -G ens16 rx 2048 tx 2048", the packets starting flowing  and after sometime they stop or are less that expected.

=========================
Absolute Stats: [2'097'129 pkts total][0 pkts dropped][0.0% dropped]
[2'097'129 pkts rcvd][1'852'821'532 bytes rcvd][149'759.86 pkt/sec][1'058.50 Mbit/sec]
=========================
Actual Stats: [573'636 pkts rcvd][1'000.14 ms][573'550.54 pps][4.07 Gbps]
=========================

The above example is with the pfring software, but the same happens with AFPacket or any other low level packet capture method I have tried.

One more clue, is that when packets stop flowing, they stop flowing for one or more queues of the card. I'm not sure about the terminology (and the schematics) but If my card sends packets with 4 RSS queues, each time a queue stops sending packets and the traffic is reduced by 1/4th, until all queues stop seding packets.

It is not a kernel issue or software issue (we have done debugging for that with the vendors of the software). I have updated the firmware on the card and I used the latest drivers. The problem exists with SRIOV or without it.

Info on my setup:

Linux lts16 4.15.0-38-generic #41~16.04.1-Ubuntu

# ethtool -i ens16f1

driver: i40evf

version: 3.6.10

firmware-version: N/A

expansion-rom-version:

bus-info: 0000:00:10.1

supports-statistics: yes

supports-test: no

supports-eeprom-access: no

supports-register-dump: no

supports-priv-flags: yes

On VM:

i40evf: Intel(R) 40-10 Gigabit Virtual Function Network Driver - version 3.6.10

i40evf 0000:00:10.0: Multiqueue Enabled: Queue pair count = 4

i40evf 0000:00:10.0: MAC address: 3c:fd:fe:99:99:11

i40evf 0000:00:10.0: GRO is enabled

On host:

[    1.710251] i40e: Intel(R) Ethernet Connection XL710 Network Driver - version 2.1.14-k

[    1.710252] i40e: Copyright (c) 2013 - 2014 Intel Corporation.

[    1.787911] i40e 0000:19:00.0: fw 6.80.48812 api 1.7 nvm 6.00 0x8000374f 18.5.17

[    2.022039] i40e 0000:19:00.0: MAC address: 24:6e:96:86:7d:de

[    2.054975] i40e 0000:19:00.0: PCI-Express: Speed 8.0GT/s Width x8

[    2.064812] i40e 0000:19:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 56 RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA

Any ideas?

Thanx,

Spiros

I an having difficulty in upgrading my NIC drivers from version 17.3.0 to 22.7.1.  The workstation I am using is running Windows 10.

Here is what I am trying to install:

When I run the install program, I get the following message:

Ok, it sounds simple enough.  I run the Intel utility to uninstall version 17.3.0, then I do the install of 22.7.1.

Doing the uninstall removes the NICs from the Device Manager, and I get an error message that 22.7.1 can't install since it cannot find any NIC in Device Manager.

If I do the uninstall and then reboot, Windows automatically installs the Microsoft drivers.

The install of 22.7.1 gives the same error message about no support for upgrades.

The though has occurred to me that these are Windows 8 drivers, not Windows 10 drivers.

The driver downloads for the 82574L NIC did not show any Windows 10 drivers.

Any assistance would be greatly appreciated.

Hi,

I have tried this card on two different computers:

- one with a MSI Z87-G43 motherboard with an integrated Realtek RTL8111E chip

- a Dell EliteDesk 800 G1 PC with an integrated Intel I217-LM Ethernet chip

In each case, it behaved exactly the same, running Windows 10 64bit or Debian

GNU/Linux (4.18.0-1-amd64) : Wake-on-LAN works fine on the integrated

controller, and it does not work on the Intel Gigabit CT Desktop Adapter.

I have tried disabling the integrated controller, I have made sure PCI-E

wake up and S5 wake up options were set properly in the UEFI setup tool, I have

tried multiple BIOS/UEFI firmware versions, including latest available.

I also tried every possible option in the Intel BootUtil tool (made sure WoL

is enabled, tried every available Option ROM (PXE/UEFI/Combo).

And in each case, I have the same result: link goes down on the Gigabit CT

Adapter as soon as the system goes to suspend or shutdown, and cannot be woken

up through this interface, but the other one works (unless disabled, of course).

So, is WoL actually supposed to work ? Is there something I overlooked ?

Something else I could try ?

Thanks in advance,

Alex

We added a new node to our cluster and we've got 2 of the Intel X710-T4 cards in the server. Both of our SANs are currently only 1Gb (we have a Tegile T3100 and a Lenovo px12-450r). Whenever i try to setup SAN connections using one of the ports on these NICs it causes all sorts of issues. We have CSVs go offline and report being corrupted and unreadable, we've lost VM configs and VMs stop booting from any volumes that are being hosted by this node (2016 Hyper V cluster). The odd part is that this same node was working fine in our 2012 cluster before we updated/migrated into 2016. I have the latest drivers for the adapter. Here are some things that have happened:

- When I initially brought the node into the cluster I configured all 3 connections to the SANs using the X710-T4 (2 for the tegile for each independent switch/controller and 1 for the lenovo which is directly connected). Right off the bat each time this node took ownership of either volume on the Lenovo the VMs that were on that volume would no longer boot. They would give different weird boot errors and eventually it would even hard lock the Lenovo SAN itself and I'd have to hard boot it. I moved that connection down to the onboard broadcom 1Gb NIC and that solved those issues. The tegile was still connected via the X710-T4 and while it continued to operate, some odd things happened here as well. Sometimes the list of connected iSCSI devices would just be blank on that node even though it was still operating. In the latest case the node took ownership of a LUN from the Tegile and immediately all the VMs on that LUN stopped working and the CSV reported as corrupt and unreadable. I moved the CSV to another node and after a while it finally started working again. Problem is this node insists on taking ownership of storage nodes and there doesnt appear to be a way to stop it (cant set node preferences on CSVs). So right now I'm scared to unpause this node and am contemplating just moving the Tegile connections into the broadcom as well and hopefully avoid all the hassle.... but when we eventually do upgrade our SAN and go 10Gb I dont want to run into this issue again.

I realize this is probably incredibly hard to decipher... at this point I'm just looking for suggestions. Is it one of the adapter properties? The adapters that connect to the SANs have all protocols except IPv4 unchecked, they have jumbo frames set to 9014 and they are set to not allow the OS to turn them off (power saving thing). Aside from that they are basically at default settings. I think I could probably disable SRV-IO on these adapters but is that causing my issue (I doubt it). Let me know what you think!