We are using the Gigabit CT Desktop Adapter on 2 identical Servers with the operating system Windows Server 2012 R2, Version 6.3, (Build 9600).

On both servers, the Gigabit CT Desktop Adapter sometimes suddenly stops working.

The event viewer shows this message:

Miniport Intel(R) Gigabit CT Desktop Adapter, {5bc59bfb-de9f-43cd-8291-5b76da5ea58c}, had event Fatal error: The miniport has detected an internal error

And the device manager a yellow triangle with exclamation point and errorcode 43.

Whe have changed the adapter on both machines and on one machine, whe have changed the mainboard. But nevertheless the error occurs again and again.

If we restart the machine, the adapter is working again for some time.

We are using a FUJITUS D3401-H1 mainboard:

System Manufacturer FUJITSU

System Model D3401-H1

System Type x64-based PC

System SKU S26361-Kxxx-Vyyy

Processor Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3401 Mhz, 4 Core(s), 8 Logical Processor(s)

BIOS Version/Date FUJITSU // American Megatrends Inc. V5.0.0.11 R1.14.0 for D3401-H1x, 6/9/2016

SMBIOS Version 3.0

Embedded Controller Version 255.255

BIOS Mode Legacy

BaseBoard Manufacturer FUJITSU

• Have the adapter incompatibilites with this mainboard?
• is the operating system supported for this adapter "Gigabit CT Desktop Adapter"?
• what is the reason for the errors and how they can be stopped?

I have also tried to uninstall and reinstall the adapter drivers.

I have downloaded the intel drivers and also the intel driver update utility, which searchs for intel hardware on the computer and updates the drivers. But the driver update utility do not find this hardware.

I have downloaded the suitable driver package "PROWinx64.exe" and have it installed. It has no effect.

The installed driver is:

C:\Windows\system32\DRIVERS\e1i63x64.sys

Provider: Intel

Version: 12.6.47.0

If I uninstall, this driver is installed again. It works for some time.

What is the reason for the error and what can we do to avoid it?

Hi All,

I am using RHEL7.3 with Intel-82599ES nic cards to launch VMs with SRIOV enabled nic cards. I am using configuring only one VF per PF. I am configuring this VF with vlan, trust mode on and disabling spoof chk.

But, when I am sending vlan tagged packets from Guest VM, I can see the "spoofed packet detected" message in dmesg for this PF card.

We have also disabled the rx/tx vlan offload using ethtool command.

Here are setup details:

Kernel version

# uname -r

3.10.0-514.el7.x86_64

PF/VF configuration:

# ip link show eth2

4: eth2: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP,LOWER_UP> mtu 9192 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 90:e2:ba:a5:98:7c brd ff:ff:ff:ff:ff:ff

    vf 0 MAC fa:16:3e:73:12:6c, vlan 1500, spoof checking off, link-state auto, trust on

IXGBE version

# ethtool -i eth2

driver: ixgbe

version: 4.4.0-k-rh7.3

firmware-version: 0x61bd0001

expansion-rom-version:

bus-info: 0000:81:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: no

Messages from dmesg

[441100.018278] ixgbe 0000:81:00.0 eth2: 3 Spoofed packets detected

[441102.022383] ixgbe 0000:81:00.0 eth2: 2 Spoofed packets detected

[441104.026460] ixgbe 0000:81:00.0 eth2: 3 Spoofed packets detected

[441106.030516] ixgbe 0000:81:00.0 eth2: 2 Spoofed packets detected

LSPCI output

# lspci -nn | grep Ether | grep 82599

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

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

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

Ethtool -k output

# ethtool -k eth2 | grep vlan

rx-vlan-offload: off

tx-vlan-offload: off

rx-vlan-filter: on

vlan-challenged: off [fixed]

tx-vlan-stag-hw-insert: off [fixed]

rx-vlan-stag-hw-parse: off [fixed]

rx-vlan-stag-filter: off [fixed]

Please let me know, if you any need any other information.

Regards

Pratik

Hi ,

I was  trying to set up Intel XL710 in 2x40 mode using the QCU but I am getting the error ""QSFP+ Configuration modification is not supported by this adapter."

Although If I try to check the current configuration it shows the mode as N/A.

All the steps that I followed:

[root@ndr730l:/tmp/EFIx64] ./qcu64e /devices

Intel(R) QSFP+ Configuration Utility

QCU version: v2.27.10.01

Copyright(C) 2016 by Intel Corporation.

Software released under Intel Proprietary License.

NIC Seg:Bus Ven-Dev Mode    Adapter Name

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

1) 000:005 8086-1583 N/A Intel(R) Ethernet Converged Network Adapter XL710-

[root@ndr730l:/tmp/EFIx64] ./qcu64e /info /nic=1

Intel(R) QSFP+ Configuration Utility

QCU version: v2.27.10.01

Copyright(C) 2016 by Intel Corporation.

Software released under Intel Proprietary License.

QSFP+ Configuration modification is not supported by this adapter.

MAC Address: 3CFDFE16FE80

Serial Number: XL710QDA2BLK

Firmware details:

ethtool -i vmnic4

driver: i40e

version: 1.4.28

firmware-version: 5.04 0x800024d8 17.5.10

bus-info: 0000:05:00.0

I have an issue with a classroom of Dell 7020 AIO computers that are using an Intel I217-LM adapter.  It seems that when these computers are rebooted, several of them, all random and never the same ones fail to reconnect to the network.  They are all showing connected but are pulling an APIPA address.  Strangely enough, all of these machines are statically addressed, not DHCP. Additionally, a simple click on the network adapter to disable then enable it resolves the connection issue.

I have investigated several possibilities, have made sure that these adapters have the latest drives from Intel and verified a few other obvious issues like a switch issue.  We are not using IPv6 here, so I have disabled IPv6 as well.  These machines do not have wireless adapters nor do they have any Virtual adapters to contend with that could be causing a conflict.

Has anyone seen this behavior before and if so did you come up with a resolution?

Lastly, I have been to Dell's site where I have updated the BIOS on all machines as well as the chip set.

How well do you know your cables and optics? This slide shows what cables and optics match up to which high speed ethernet technology.

Click to open the attached pdf below.

Hi,

I plan to run DPDK-pktgen on my Xeon D platform.

I have two MBs. Since i currently don't have 10G switch, my experiment is to use one MB to act as a 10G switch to generate traffic and the other one is to act as a receiver.

Each MB has two 10G port embedded. so total I have 4 10G ports and two on either one.

Below is my configuration:

OS: Ubuntu 16.04

CPU: Xeon-D 1541 & Xeon-D 1557

NIC: Intel X552/X557 10GBASE-T

My understanding is probably wrong, there might be better testing scenario for pktgen. If so, please kindly let me know.

If my testing scenario is reasonable, is there any document I can follow to set up the environment ?

Thanks

Sam

Flow control is a key part of keeping your 1 Gigabit and faster network running smoothly.  Somewhere along the line some websites started telling people to turn off flow control so their network would go faster.  In the short term this might be fine; in the long term you’re going to see bigger problems and probably drop more packets than you’ll make up by being able to send as needed.  The problem people would say is that Flow Control stops the traffic, and this costs performance.  Absolutely it stops traffic.  But it stops the traffic the receiver doesn’t have room for!  The flow control is like a stop light controlling access to the highway.  Instead of letting them all in at once, when there is no room for them and gumming up the works even further, flow control gives protection to the receiver.  This protection allows for long term speed and less dropped packets.

Consider the following data set that was gathered using ethtool -S eth0 from a real system.

NIC statistics:

     rx_packets: 329461
      tx_packets: 302120
      rx_bytes: 34897969
      tx_bytes: 32293428
      rx_no_buffer_count: 39147
      rx_missed_errors: 1097931
      rx_flow_control_xon: 0
      rx_flow_control_xoff: 0
      tx_flow_control_xon: 228
      tx_flow_control_xoff: 1098233

Let’s look at it in detail.  Tx Flow control XOFF is the NIC telling the link partner, “I’m overwhelmed, stop the packets”, Rx Flow Control is the Link partner telling the NIC “I’m overwhelmed, stop the packets”.  Note the difference.  TX FC is transmitting TO the partner, RX FC is receiving FROM the partner.  In this case, the NIC is basically screaming, I’m overwhelmed (More XOFF than packets), and the rx_no_buffer_count and rx_missed_error confirms it.  What this means is the NIC has no resources and is actively dropping packets.  But FC is on!  Why are we still dropping/missing packets?  The link partner is not honoring the flow control packets! In this case, the link partner has sent 1.4 million frames, but only 300K got through because the link partner didn’t care about flow control.  With flow control the packets might take a little longer to get there, but they will get there.

Looking at the data, see the 228 XON?  The NIC only caught up 228 times.  That’s not so good.  So what was causing all these missed packets?  Most likely cause is a slow PCI express and/or slow memory implementation.  Packets come all the time and memory slowness and getting combined with another busy device on a few narrow lanes can mean not enough PCI Express bus between something like the ESB or a switch cascaded off a switch.

Moving to 10 Gigabit it is, well, ten times worse.  You have 1/10^th the time and ripple effect of delaying a packet moves faster.  It was so problematic that Data Center Bridging (DCB) and DCBx came out to make flow control end to end.  Instead of just link partner to link partner, DCBx allows one overwhelmed end point to tell the overwhelming source to chill out.  This moves the delay caused by flow control to the point most able to deal with it.  While some backplanes of switches can temporarily store terabits of data, having the starting node just not send it right now is the best result.  We’ll do a deeper dive on DCBx another time, but with it you get effectively lossless Ethernet with DCBx and that lets you do FCoE and other storage technologies.

Thanks for using Intel Ethernet and turn on your Flow Control!!

Hi,

We are interested to use the X540 Twinville Dual Port 10GbE MAC/PHY in our application. The marketing data sheet

Intel® Ethernet Controllers and PHYs

lists the operating temperature at 0-55C. Yet the data sheet

http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-x540-datasheet.pdf

on pg 1188 lists a maximum case temperature of Tcase Max = 107C.

Please elaborate on the difference and meaning between these two figures. We need the 0-70C temperature range if we are to use this part.

Thank you.

What installs it and is it relevant with Intel Network Connections 21.1.30.0?  We are very security conscience and want to remove this software if it has no purpose. I am wondering if this was installed by an older version of Intel Network Connections and is no longer needed. Is this just a registry file that can be removed?

I can't replicate the issue but every few weeks my NIC disables itself and I have to restart my computer to get it to work again since disabling / re enabling in Device Manager stalls.

From searching online, "Receive Side Scaling" is the reason.  Why would this be the case?   Would this be due to the manufacturer of the motherboard or Intel?  I tried Asus' drivers and also tried the latest Intel drivers - doesn't matter.

How well do you know your cables and optics? This slide shows what cables and optics match up to which high speed ethernet technology.

Click to open the attached pdf below.

Flow control is a key part of keeping your 1 Gigabit and faster network running smoothly.  Somewhere along the line some websites started telling people to turn off flow control so their network would go faster.  In the short term this might be fine; in the long term you’re going to see bigger problems and probably drop more packets than you’ll make up by being able to send as needed.  The problem people would say is that Flow Control stops the traffic, and this costs performance.  Absolutely it stops traffic.  But it stops the traffic the receiver doesn’t have room for!  The flow control is like a stop light controlling access to the highway.  Instead of letting them all in at once, when there is no room for them and gumming up the works even further, flow control gives protection to the receiver.  This protection allows for long term speed and less dropped packets.

Consider the following data set that was gathered using ethtool -S eth0 from a real system.

NIC statistics:

     rx_packets: 329461
      tx_packets: 302120
      rx_bytes: 34897969
      tx_bytes: 32293428
      rx_no_buffer_count: 39147
      rx_missed_errors: 1097931
      rx_flow_control_xon: 0
      rx_flow_control_xoff: 0
      tx_flow_control_xon: 228
      tx_flow_control_xoff: 1098233

Let’s look at it in detail.  Tx Flow control XOFF is the NIC telling the link partner, “I’m overwhelmed, stop the packets”, Rx Flow Control is the Link partner telling the NIC “I’m overwhelmed, stop the packets”.  Note the difference.  TX FC is transmitting TO the partner, RX FC is receiving FROM the partner.  In this case, the NIC is basically screaming, I’m overwhelmed (More XOFF than packets), and the rx_no_buffer_count and rx_missed_error confirms it.  What this means is the NIC has no resources and is actively dropping packets.  But FC is on!  Why are we still dropping/missing packets?  The link partner is not honoring the flow control packets! In this case, the link partner has sent 1.4 million frames, but only 300K got through because the link partner didn’t care about flow control.  With flow control the packets might take a little longer to get there, but they will get there.

Looking at the data, see the 228 XON?  The NIC only caught up 228 times.  That’s not so good.  So what was causing all these missed packets?  Most likely cause is a slow PCI express and/or slow memory implementation.  Packets come all the time and memory slowness and getting combined with another busy device on a few narrow lanes can mean not enough PCI Express bus between something like the ESB or a switch cascaded off a switch.

Moving to 10 Gigabit it is, well, ten times worse.  You have 1/10^th the time and ripple effect of delaying a packet moves faster.  It was so problematic that Data Center Bridging (DCB) and DCBx came out to make flow control end to end.  Instead of just link partner to link partner, DCBx allows one overwhelmed end point to tell the overwhelming source to chill out.  This moves the delay caused by flow control to the point most able to deal with it.  While some backplanes of switches can temporarily store terabits of data, having the starting node just not send it right now is the best result.  We’ll do a deeper dive on DCBx another time, but with it you get effectively lossless Ethernet with DCBx and that lets you do FCoE and other storage technologies.

Thanks for using Intel Ethernet and turn on your Flow Control!!

Hi,

We are interested to use the X540 Twinville Dual Port 10GbE MAC/PHY in our application. The marketing data sheet

Intel® Ethernet Controllers and PHYs

lists the operating temperature at 0-55C. Yet the data sheet

http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-x540-datasheet.pdf

on pg 1188 lists a maximum case temperature of Tcase Max = 107C.

Please elaborate on the difference and meaning between these two figures. We need the 0-70C temperature range if we are to use this part.

Thank you.

Howdy,

I've been wondering since I installed Windows 10 how to install the drivers (right now, 22.4.0.1; here) for Intel Gigabit CT Desktop adapter? I've tried several other versions, but all just say: "Cannot install drivers. No Intel(R) Adapters are present in this computer." I think this would install just fine with Windows 7, but not in Windows 10. Anyway, screenshot attached below.

What is the MTBF for the 8391GT network adapter?

Why i cant install your driver for my desktop on windows server 2012? Drivers cant find lan adapter I219-V !!! Help please? This trouble so old time!

HI

I want to config cir (Committed Information Rate) for PF，and config eir (Excess Information Rate) for VF, how can i do this?

NIC: 82599

hi, i would like to report that the new intel nic drivers version 19.3 that just released recently has huge 6000+ dpc latency spike once in a few secs.

my specs

Intel(R) 82579LM Gigabit Network Connection

windows 7 SP1 32bit + lastest windows update

i downgrade to intel nic drivers previous version 19.1 and the problem is just gone.

Hi Everyone, Im trying to track down an issue with my LAN port,,My motherboard uses a Intel i219V controller and this is a new htpc mini itx build.

So far Ive looked over a few things such as downloading the latest drivers for the chipset and updating the bios on the asus board,,from the very first post

I have been skeptical of a hardware issue due to a lack of any port activity via the normal lights one expects to see from the ethernet port, in my limited experience

I usually see a light in or near the port no matter if it is active or not, this boards port has been silent of any lights so far,,however I thought i might run this by the

community here just in case someone else might have encountered a lan issue with this controller or a problem with Asus ROG products in respect to the network

controller, i am open to suggestions and have a fair amount experience with PC hardware and sometimes do repairs for friends and family.

any troubleshooting suggestions ? I hope maybe I would be so lucky as to have missed an option in the bios setup, but I havent looked into that yet,

Wireless on the asus board appears to work well and uses a qualcomm Atheros Dual band adapter and antenna. So far it performs well in any part of my home

but I prefer old school wired networking if at all possible,

This was motherboard number 2 as the first board came with some bent pins and had signs of being an open box,,this board however came packaged sealed and everything

checked out ok, first post went well after breadboarding it just to confirm it wasnt DOA,,anyone who has built into a small form factor case knows how much trouble this can save you.

So is the i219v have any current issues that might cause a ethernet port to appear dead ?

We are using the Gigabit CT Desktop Adapter on 2 identical Servers with the operating system Windows Server 2012 R2, Version 6.3, (Build 9600).

On both servers, the Gigabit CT Desktop Adapter sometimes suddenly stops working.

The event viewer shows this message:

Miniport Intel(R) Gigabit CT Desktop Adapter, {5bc59bfb-de9f-43cd-8291-5b76da5ea58c}, had event Fatal error: The miniport has detected an internal error

And the device manager a yellow triangle with exclamation point and errorcode 43.

Whe have changed the adapter on both machines and on one machine, whe have changed the mainboard. But nevertheless the error occurs again and again.

If we restart the machine, the adapter is working again for some time.

We are using a FUJITUS D3401-H1 mainboard:

System Manufacturer FUJITSU

System Model D3401-H1

System Type x64-based PC

System SKU S26361-Kxxx-Vyyy

Processor Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3401 Mhz, 4 Core(s), 8 Logical Processor(s)

BIOS Version/Date FUJITSU // American Megatrends Inc. V5.0.0.11 R1.14.0 for D3401-H1x, 6/9/2016

SMBIOS Version 3.0

Embedded Controller Version 255.255

BIOS Mode Legacy

BaseBoard Manufacturer FUJITSU

• Have the adapter incompatibilites with this mainboard?
• is the operating system supported for this adapter "Gigabit CT Desktop Adapter"?
• what is the reason for the errors and how they can be stopped?

I have also tried to uninstall and reinstall the adapter drivers.

I have downloaded the intel drivers and also the intel driver update utility, which searchs for intel hardware on the computer and updates the drivers. But the driver update utility do not find this hardware.

I have downloaded the suitable driver package "PROWinx64.exe" and have it installed. It has no effect.

The installed driver is:

C:\Windows\system32\DRIVERS\e1i63x64.sys

Provider: Intel

Version: 12.6.47.0

If I uninstall, this driver is installed again. It works for some time.

What is the reason for the error and what can we do to avoid it?