Hello, I am using following Ethernet controller on one of our systems, and once in a while I run into following error after bootup, resulting in the port not sending/receiving packets. 

2016-12-13T01:06:55.499000+00:00 kernel: i40e 0000:20:00.3: eeprom check failed (-2), Tx/Rx traffic disabled

Following is the current version we use (which is quite old; we are in process of upgrading).  But does anyone know if this is a known issue and may be fixed in an upgraded driver and/or NVM?

System# lspci -s 0000:20:00.3

20:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GBASE-T (rev 01)

System# ethtool -i eth1

driver: i40e

version: 1.3.47

firmware-version: 4.43 0x80001c3f 1.1018.0

bus-info: 0000:20:00.3

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

System#

Thank you very much!

Hi,

I'm looking for help establishing (and troubleshooting) a link to a SPAN in promiscuous mode on Ubuntu Server 14.04.

This link was up and running and seeing packets for a few weeks. To help with an application issue, we installed the PF_RING kernel module, and after a server reboot, we have not been able to establish a link. We've rolled back our changes and removed PF_RING, but we are still not able to establish a link, and I'm looking for some help.

We've looked at our Gigamon SPAN and it appears to be sending data to our device but we have not been able to see any traffic ('tcpdump -i em1 -vv' does not see any traffic).

Any help would be greatly appreciated.

Jeff

$ifconfig  em1

em1      Link encap:Ethernet  HWaddr ec:f4:bb:**:**:**

          UP BROADCAST NOARP PROMISC MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:7180 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

$ sudo ethtool em1

Settings for em1:

  Supported ports: [ FIBRE ]

  Supported link modes:   1000baseT/Full

                          10000baseT/Full

  Supported pause frame use: No

  Supports auto-negotiation: Yes

  Advertised link modes:  1000baseT/Full

                          10000baseT/Full

  Advertised pause frame use: No

  Advertised auto-negotiation: Yes

  Speed: Unknown!

  Duplex: Unknown! (255)

  Port: FIBRE

  PHYAD: 0

  Transceiver: external

  Auto-negotiation: on

  Supports Wake-on: umbg

  Wake-on: g

  Current message level: 0x00000007 (7)

        drv probe link

  Link detected: no

$ cat /var/log/syslog | grep ixgbe

Feb 17 15:16:46 servername kernel: [    7.371724] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.15.1-k

Feb 17 15:16:46 servername kernel: [    7.371727] ixgbe: Copyright (c) 1999-2013 Intel Corporation.

$ cat /var/log/syslog | grep em1

Feb 17 15:16:46 servername kernel: [  11.789614] systemd-udevd[572]: renamed network interface eth0 to em1

Feb 17 15:16:46 servername kernel: [  14.071614] IPv6: ADDRCONF(NETDEV_UP): em1: link is not ready

Feb 17 15:16:46 servername kernel: [  15.404429] ixgbe 0000:01:00.0: registered PHC device on em1

Feb 17 15:16:46 servername kernel: [  15.509280] IPv6: ADDRCONF(NETDEV_UP): em1: link is not ready

Feb 17 15:16:47 servername kernel: [  15.580413] ixgbe 0000:01:00.0 em1: detected SFP+: 6

Feb 17 15:16:48 servername kernel: [  16.713425] device em1 entered promiscuous mode

Feb 17 15:16:48 servername kernel: [  17.498677] ixgbe 0000:01:00.0 em1: detected SFP+: 6

$sudo ethtool -m em1

  Identifier                                : 0x03 (SFP)

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

  Connector                                : 0x07 (LC)

  Transceiver codes                        : 0x10 0x00 0x00 0x01 0x00 0x00 0x00 0x00

  Transceiver type                          : 10G Ethernet: 10G Base-SR

  Transceiver type                          : Ethernet: 1000BASE-SX

  Encoding                                  : 0x06 (64B/66B)

  BR, Nominal                              : 10300MBd

  Rate identifier                          : 0x02 (8/4/2G Rx Rate_Select only)

  Length (SMF,km)                          : 0km

  Length (SMF)                              : 0m

  Length (50um)                            : 80m

  Length (62.5um)                          : 30m

  Length (Copper)                          : 0m

  Length (OM3)                              : 300m

  Laser wavelength                          : 850nm

  Vendor name                              : Intel Corp     

  Vendor OUI                                : 00:1b:21

  Vendor PN                                : FTLX8571D3BCV-IT

  Vendor rev                                : A 

  Optical diagnostics support              : Yes

  Laser bias current                        : 26.446 mA

  Laser output power                        : 0.6639 mW / -1.78 dBm

  Receiver signal average optical power    : 0.0014 mW / -28.54 dBm

  Module temperature                        : 51.65 degrees C / 124.97 degrees F

  Module voltage                            : 3.3214 V

  Alarm/warning flags implemented          : Yes

  Laser bias current high alarm            : Off

  Laser bias current low alarm              : Off

  Laser bias current high warning          : Off

  Laser bias current low warning            : Off

  Laser output power high alarm            : Off

  Laser output power low alarm              : Off

  Laser output power high warning          : Off

  Laser output power low warning            : Off

  Module temperature high alarm            : Off

  Module temperature low alarm              : Off

  Module temperature high warning          : Off

  Module temperature low warning            : Off

  Module voltage high alarm                : Off

  Module voltage low alarm                  : Off

  Module voltage high warning              : Off

  Module voltage low warning                : Off

  Laser rx power high alarm                : Off

  Laser rx power low alarm                  : On

  Laser rx power high warning              : Off

  Laser rx power low warning                : On

  Laser bias current high alarm threshold  : 11.800 mA

  Laser bias current low alarm threshold    : 2.000 mA

  Laser bias current high warning threshold : 10.800 mA

  Laser bias current low warning threshold  : 3.000 mA

  Laser output power high alarm threshold  : 0.8318 mW / -0.80 dBm

  Laser output power low alarm threshold    : 0.1585 mW / -8.00 dBm

  Laser output power high warning threshold : 0.6607 mW / -1.80 dBm

  Laser output power low warning threshold  : 0.1995 mW / -7.00 dBm

  Module temperature high alarm threshold  : 78.00 degrees C / 172.40 degrees F

  Module temperature low alarm threshold    : -13.00 degrees C / 8.60 degrees F

  Module temperature high warning threshold : 73.00 degrees C / 163.40 degrees F

  Module temperature low warning threshold  : -8.00 degrees C / 17.60 degrees F

  Module voltage high alarm threshold      : 3.7000 V

  Module voltage low alarm threshold        : 2.9000 V

  Module voltage high warning threshold    : 3.6000 V

  Module voltage low warning threshold      : 3.0000 V

  Laser rx power high alarm threshold      : 1.0000 mW / 0.00 dBm

  Laser rx power low alarm threshold        : 0.0100 mW / -20.00 dBm

  Laser rx power high warning threshold    : 0.7943 mW / -1.00 dBm

  Laser rx power low warning threshold      : 0.0158 mW / -18.01 dBm

Hello.

I started a new thread, because the old thread (SNMP issue with ANS ) don't have any answer from Intel's team since 2013 year.

I have installed the last version of PROWinx32.exe (21.1) with activation of the SNMP option on Windows 7 (32-bit).

I have configured an AFT teaming  from two network interfaces. By using PROSetCL.exe, I have checked that this teaming works correctly.

My problem is when I make a SNMP dump of the intel-Ian-adapters MIB, I have the following results:

• baseDriverLoadedAnsNotLoaded(1) for the status when I am expecting baseDriverLoadedAnsLoaded(3)
• standAlone(0) for the type of the adapters involved in the teaming when I am expecting teamMember(1)
• no data under ansAttrTables MIB subtree.

Previously, we used data from ansAttrTable MIB subtree on Windows XP with PROWin32.exe (v16.3) without any problems.

Under Windows 7 with the same (v16.3) driver and latest (v21.1) driver no data under ansAttrTable MIB subtree.

Is there something specific to do to have ANS loaded at SNMP level ?

My platform is a Q7 module which already implements an I210 on PCIe.  I am designing a carrier board which includes 2 additional I210s on the Q7 PCIe bus.  The Q7 module is currently being tested on a development board and is running Ubuntu Server 14.04.5 and reports Intel Gigabit Ethernet Network Driver - version 5.2.15-k.  Its onboard I210 works fine in the development environment.

All I need is for the I210s to be recognized as a PCIe device by Linux and treated like any other unmanaged Ethernet adapter.  I only need to perform very basic config such as setting the MAC address, IPv4 details, and setting link speed.  Initiating Ethernet Compliance test patterns would also be desirable but not strictly required.

I would prefer to avoid implementing SPI flash configuration if possible.  The manufacturer of the Q7 module has also discouraged us from connecting the SMBus to external devices, so I would like to avoid that as well.  What level of functionality is available using only the PCIe link for configuration?

If I do need to use the SMBus, is it possible to change the SMBus Slave Address over PCIe?  Or will I need to implement an SPI Flash to write that register?

Does the I210 ship with a unique MAC Address for each chip, or do MACs need to be purchased and manually assigned?  In my experience it's always been the latter, but the manual has some bits that suggest that there's a unique factory setting that can be reapplied over a user MAC.

Hi,

I am using Ubuntu 16.04 LTS operating system, with igb-5.3.5.4 driver. I have two I210 Ics on board.

I have programmed iNVM in both devices and

"lspci" is identifying the devices and lsmod also showing igb module with no user for it(i.e. 0)

"lshw" is also showing devices with network -UNCLAIMED.

How to bind this igb driver to i210 controllers?

The board is also having I217 controller with e1000e driver and it is working fine.

Please help me in resolving this issue

Hi

i am using Ethernet CTLR Single Chip at my product

and there is some failure at my product come from this chip

i have debug the unit and found that it keep sending reset signal to processor chip

right now i am having trouble to found at which part that this chip decide to sent reset signal

need the intelligent from intel to help me on this

the part number is WG82574L S LBA9

and i found the reset signal come from pin 17 which mark as pex_rst

Hi,

I just upgraded a Dell T7600 Workstation. I also wanted to add a 10Gbit ethernet card, but the computer does not boost correct. The BIOS is starting with loading but it hangs before the OS is loading. I'm also not able to get access to the BIOS settings. If i take out the card, the computer is booting without any problems. Also the PCIe slot that i used works with a graphics card.

I take this card from a actual Dell T7910 workstation, so i know the card is working. I also tried a second card - also with not success. I updated the BIOS to the latest version...

I found on other pages that a PCIe 2.0 slot could help, but i'm not able to set this in the BIOS settings.

Does anybody has an idea? I would like to start with 10Gbit in our company.

I have an I210IS device, interfacing to Broadcom BCM5461S in SGMII mode.

Currently I don't have MDIO from I210 connected to PHY, I loaded "Dev_Start_I210_Sgmii_NOMNG_16Mb_A2_3.25_0.03.bin" driver into the device flash.

The PHY is set to SGMII mode. I have signals on both RX and TX line, but no link

Any help would be appreciated

Hello i am trying to enable ethernet in Dell Precision supporting Ubuntu 14.04. When i downloaded the drivers from the download site

and try "make" the make has support for only cleaning files and no compilation. how can i enable Ethernet in Ubuntu 14.04.

My system supports Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (rev 31).

regards

Manikantan

Is there any possibility to get an 540-T2 running on Windows 10 1607?

After Driverinstallation i got an Code 10, Driver could not be startet Error.

Thanks for any Help.

I have two NICs that are suppose to be the same part number, however, one is recognized as a dual port server adapter, while the other is recognized as a dual port network connector. Can anyone tell me why?

Thanks,

Johnathon

My platform is a Q7 module which already implements an I210 on PCIe.  I am designing a carrier board which includes 2 additional I210s on the Q7 PCIe bus.  The Q7 module is currently being tested on a development board and is running Ubuntu Server 14.04.5 and reports Intel Gigabit Ethernet Network Driver - version 5.2.15-k.  Its onboard I210 works fine in the development environment.

All I need is for the I210s to be recognized as a PCIe device by Linux and treated like any other unmanaged Ethernet adapter.  I only need to perform very basic config such as setting the MAC address, IPv4 details, and setting link speed.  Initiating Ethernet Compliance test patterns would also be desirable but not strictly required.

I would prefer to avoid implementing SPI flash configuration if possible.  The manufacturer of the Q7 module has also discouraged us from connecting the SMBus to external devices, so I would like to avoid that as well.  What level of functionality is available using only the PCIe link for configuration?

If I do need to use the SMBus, is it possible to change the SMBus Slave Address over PCIe?  Or will I need to implement an SPI Flash to write that register?

Hi,

I am using a Xeon-D 1541, with (2) x552/x557 10G Ethernet cards. I am able to enable VFs and have the latest Linux Kernel/iproute2 (both v4.8.0). I am attempting to put a VF into "Promiscuous Mode" with a VLAN tag for a security monitoring container. I can enable "trust mode", which should allow promiscuous traffic, however I can only see packets that are destined for the VF MAC address or broadcast packets.

Does the x552/x557 support unicast/multicast promiscuous mode in VFs?

Some Specific configuration information:

[root@localhost ~]# modinfo ixgbe

filename:       /lib/modules/3.10.0-514.el7.x86_64/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko

version:        4.4.0-k-rh7.3

license:        GPL

description:    Intel(R) 10 Gigabit PCI Express Network Driver

author:         Intel Corporation, <linux.nics@intel.com>

rhelversion:    7.3

srcversion:     E85AB43E463B4B0083D9BE3

[root@localhost ~]#ip link show

5: eno4: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 0c:c4:7a:c4:ad:7f brd ff:ff:ff:ff:ff:ff

    vf 0 MAC 06:9f:fb:7b:1b:9f, vlan 1000, spoof checking off, link-state auto, trust on

    vf 1 MAC 7e:12:a8:d2:59:76, vlan 2000, spoof checking off, link-state auto, trust on

[root@localhost ~]#ifconfig

eno4: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        ether 0c:c4:7a:c4:ad:7f  txqueuelen 1000  (Ethernet)

        RX packets 22  bytes 6232 (6.0 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s16f1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        inet6 fe80::49f:fbff:fe7b:1b9f  prefixlen 64  scopeid 0x20<link>

        ether 06:9f:fb:7b:1b:9f  txqueuelen 1000  (Ethernet)

        RX packets 21  bytes 6126 (5.9 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 8  bytes 648 (648.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s16f3: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        ether 7e:12:a8:d2:59:76  txqueuelen 1000  (Ethernet)

        RX packets 1  bytes 78 (78.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 49  bytes 8310 (8.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The physical interface (eno4) is able to see all packets, but the VF interface (enp3s16f1) is not able to show promiscuous packets.

Does the x552/x557 support unicast/multicast promiscuous mode in VFs? If so, is this a hardware, driver, kernel, or user error.

Thanks in advance!

I have downloaded Intel NIC driver for “Intel(R) Gigabit 4P
I350-t rNDC“ NIC adapter for Windows 10 OS from below link

https://downloadcenter.intel.com/download/22283/Intel-Ethernet-Adapters-Connections-CD?product=59679

Below are the steps I performed for driver installation

1. Extracted 21_1_cd.zip
   file to C drive on the target system.
2. Open
   command prompt in administrative mode.
3. Go to C:\21_1_cd\APPS\PROSETDX\Winx64
   path. (21_1_cd is the extracted folder name in C drive)
4. Execute
   below command to install the driver
   1. Start /w DxSetup.exe /qn /norestart

The driver does not get installed including proset software. If I
don’t pass /norestart, the driver and proset gets installed but it reboot
automatically.

I want to know how to install the driver and proset without
auto-rebooting. I will take care of rebooting the system immediately after the
driver is installed.

Hello

I have 10 host Dell R730xd with Ethernet Converged Network Adapter X710-DA4 and we have installed VMware 6.0u2 hosts and vSAN. The cards at first seem to work well and preform well however we now have an issue where the links on all of our hots flap and performance is very poor.The logs show

TX driver issue detected, PF reset issued. and drop packages.

I search information and show issues with drivers Intel X710 and Vmware 6.0u2 and with Beta 1.6.6?

Thanks 

My server chassis has two LEDs for LAN connectivity and/or activity.

The motherboard does not have any such jumper, and I wanted to know if Intel had *any* NIC cards with a jumper for LAN activity and/or connectivity?

Dear Intel Community

In our device we have two WGI210IT ethernet controllers and we are facing an issue with them: Very rarley, let's say less than once per 100 boot ups, we see that the device ID is 1531 instead of 1533. At the moment we cannot reproduce it, it just appears sometimes on our devices.

lspci under linux shows it like this:

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

02:00.0 Ethernet controller: Intel Corporation Device 1531 (rev 03)

After a reboot the Ethernet controller has ID 1533 again:

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

Early at bootup of Linux the following message apears:

kernel: pci 0000:02:00.0: [8086:1531] type 00 class 0x020000

So it we doubt that any operating system related action causes the wrong ID.

The configuration is as follows:

- Ethernet controller firmware: Dev_Start_I210_Copper_SMB_8Mb_A2_3.25_0.03.bin

- Changes in Flash (On some devices done with Lanconf.exe under DOS and in others with eeupdate64e under Linux):

--> Word 0x20: Set bit 4 to '1' (disables Gbit Ethernet)

--> Changed MAC Address

- Gigabit Ethernet is not supported on HW side. MDI_PLUS_2 / MDI_MINUS_2 / MDI_PLUS_3 / MDI_MINUS_3 are pull-up to 1.5V via 49.9R resistors

- Flash: MX25L1606EZNI-12G

- 33R resistors in SPI lines (NVM_SI, NVM_SO, SVM_SK, NVM_CS#)

- Pin 12 is pulled-down with 10k (strap pin --> non secure mode)

Hardware checks:

- The I210 and the flash are powered from the same 3.3V source. First flash access happens after 25ms after 3.3V is reached. The flash itself requires 200us to be ready after Vmin is reached. So the flash is ready at first access.

- The signal levels of all SPI lines are fine.

- The solder points are checked and nothing wrong was seen.

We checked a few register values while the problem was seen:

Read at 0x90012010 | 0x40 0x2A 0x48 0x00 (Base address is 0x90000000)

The 1533 controller shows:

Read at 0x91312010 | 0x40 0x2B 0x08 0x06 (Base address is 0x91300000)

Differences:

EEPROM-Mode Control Register - EEC (0x12010) bit 8 is '0'. --> EE_PRES: No Flash with correct signature or empty iNVM

EEPROM-Mode Control Register - EEC (0x12010) bit 22 is '0'. --> Reserved: No info from datasheet

EEPROM-Mode Control Register - EEC (0x12010) bit 25 is '0'. --> SEC1VAL: Sector 1 not valid (but not meaning full due to bit 8 is '0')

EEPROM-Mode Control Register - EEC (0x12010) bit 26 is '0'. --> FLUDONE: No flash update done

Have you got any idea what could cause this problem?

Thank you in advance and best regards

Stefan

Hello,

In this thread the XL710 J3 jumper is mentioned:

Re: STAG support on XL710?

I found two types of jumpers:

closed:

https://www.google.com/imgres?imgurl=https%3A%2F%2Fcdn.sparkfun.com%2F%2Fassets%2Fparts%2F2%2F4%2F0%2F7%2F09044-02-L.jpg…

Opened:

https://www.google.com/imgres?imgurl=http%3A%2F%2Fi.ebayimg.com%2Fimages%2Fg%2F-IkAAOxyTMdTPUz1%2Fs-l300.jpg&imgrefurl=h…

Both fit XL710 J3 .

Will both types work for XL710 J3 ? is there any significant difference between them ?

Or only one of them should be used?

Hi,

We are using 82576 Gigabit Ethernet Controller, as per the document (8.10.1 Receive Control Register - RCTL (0x00100; R/W)

, page No. 515) attached and also the ethtool output,

- Even if the UPE (Unicast Promiscuous Enable) bit is reset (disabled) we still seem to receive any Unknown Unicast Packets.

- If we disable the MPE (Multicast Promiscuous Enable) bit then we stop receiving any Unknown Unicast Packets.

While I do not see any reason why any one would disable UPE and enable MPE, just wanted to know if it is expected behavior.

Our assumption was that if the UPE bit is disabled then we should NOT receive any Unknown Unicast (assume we do not have any

RAL entries for MAC filtering)

Linux# ethtool -d eth1

0x00000: CTRL (Device control register)               0x40D00240

       Invert Loss-Of-Signal:                         no

       Receive flow control:                          disabled

       Transmit flow control:                         disabled

       VLAN mode:                                     enabled

       Set link up:                                   1

       D3COLD WakeUp capability advertisement:        enabled

       Auto speed detect:                             disabled

       Speed select:                                  1000Mb/s

       Force speed:                                   no

       Force duplex:                                  no

0x00008: STATUS (Device status register)              0x00080383

       Duplex:                                        full

       Link up:                                       link config

       Transmission:                                  on

       DMA clock gating:                              disabled

       TBI mode:                                      disabled

       Link speed:                                    1000Mb/s

       Bus type:                                      PCI Express

0x00100: RCTL (Receive control register)              0x0400803A

       Receiver:                                      enabled

       Store bad packets:                             disabled

       Unicast promiscuous:                           disabled

       Multicast promiscuous:                         enabled

       Long packet:                                   enabled

       Descriptor minimum threshold size:             1/2

       Broadcast accept mode:                         accept

       VLAN filter:                                   disabled

       Cononical form indicator:                      disabled

       Discard pause frames:                          filtered

       Pass MAC control frames:                       don't pass

       Loopback mode:                                 normal

       Receive buffer size:                           2048