I've got six Dell worstation class computers (Precision T5500 and Precision 670) that I am trying to use I210-T1 network adapters in.  The computers are running Windows 7.  When I boot the computers after the NIC's are installed, the computers fails to make it to post.  All I get is a black screen with a blinking cursor in the top left corner.  I have tried them in various slots, but I get the same result every time.  I cannot get into the BIOS during this failure mode.

I had previously ordered and installed roughly 30 of these cards in the same model computers with no problem around 6 months ago.  Because of this, I started checking to see if there were any differences between that batch of cards and the latest ones that I bought.  The older cards have a manufacture date of 03/2014.  The newer ones have a manufacture date of 08/2014.  The newer ones, according to the Intel documentation, have 2 resistors added to them and a newer firmware.

I decided to try the older cards in the computers with the issues.  The computers booted up and ran fine with the older cards.

Anyone have any ideas as to what the problem with the newer cards could be and what can be done to resolve or work around this issue?

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?

  Hi,

  I would like to modify the i40e driver to make xl710 receive bad packets as well (for example, ignore crc errors). From the datasheet I see that I should set the SBP bit in the PRT_SBPVSI register. But, I don't know how to do this. I don't even know what is the address of this register.

  I would be grateful for any help.

  Best wishes,

    Codrut

Hi,

I have some Windows 10 1607 Pro mobile computers using the i211 ethernet adapter. The checkbox for Register this connection's address in DNS will not stay checked like every other computer we have and the DNS will not register unless I do it manually using ipconfig /registerdns.  I am using the latest Intel drivers .Has anyone seen this behavior?

Thanks,

Steve

I am looking for a couple Intel X710-DA4 and Intel XL710-QDA2 Cards. Used and/or branded versions (Dell, etc) should be fine. Please let me know if you have any you want to let go of. Thanks Much!

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 ?

Hi All,

  We have "Intel Ethernet Converged Network Adapter XL710-QDA2".

  1) Configured in 2x40 mode

  2) The two ports on the board are connected back to back with below SFP:

        MACROREER

        40GBase-CU QSFP+ Cable 1m

      We are able to observe that the link status on both ports is UP. And, we are able to run tests between the ports.

  3) When we use the below Intel SFP's on both ports connected with MTP 24 fibre optical cable, the ports are not coming UP (Link status shows down)

        E40GQSFPSR

        QSFP-40G-SR4  16-26

        Class 1  21CFR1040.10

        LN#50 6/2007

        FTL410QE2C-IT

     Please help us in understanding why the ports are not coming up with the above mentioned Intel SPF's (point 3).

Is the optical cable we are using compatible with the SPF's or need to use some other optical cable or SFP to bring the ports UP?

Should we configure the board in any specific mode ?

Looking ahead for your response

Thanks in advance

-- Anand Prasad

I am running review of project which has been initiated in 2013 comparing huge amount of different incidents versus programmed software and hardware issues or missed focus of support team on drivers update requirements (as is report I am doing is a big lesson learned paper which should show that's our support teams needs to have more improved way of external hardware/software tracking). On current stage I can see that this is very hard to follow information related to fixes of bugs on NICs 82754L and 82579LM as errata published in specifications most of the times not covered by information in notes of drivers. So I would like to know if there is any page at intel.com where that's possible to check if particular NIC's bug depend on chipset and was it fixed and using what version of drivers.

It's Windows 10 2016 LTSB 1607, build 14393 using PRO Set version 22.4

The VLAN configuration tab tells me to update Windows 10, I'm using the version specified here: https://www.intel.nl/content/www/nl/nl/support/network-and-i-o/000022282.html

This is for embedded devices that won't have an internet connection, so if I need a Windows update I'd like to know which update(s).

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 a have Intel s2600wt motherboard this two X540-AT2 ehernet adapters. Link speed in auto negatiation is only 100mbps, then i set 1000mbps on switch or in ethernet adapter properties - link lost. My os is Windows Server 2012 R2 and my switch is Cisco 6509 running on ios  version 15.1(2)SY9. Also i tried  Cisco 2960G with ios Version 15.0(2)SE8 this same result.

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?

HI Everyone,

We are using XL710 hardware on Linux 4.1.20 kernel.

We have an issue where the following behavior is noticed.

• When we send a simple loop back traffic to the XL710, it works fine.
• When a specific PPPoE packet is sent from an external port to the XL710, on Linux we notice that the XL710 driver has no response. There is no interrupt is raised for this received packet.
• After the above condition, XL710 stops receiving any packet.

Here is the packet contents for a good packet and the failing packet.

I can send any number of good packets, and XL710 is able to received it.

After I send a single failing packet, XL710 stop receiving packets. In fact, it does not receive even the good packets after this.

Good Packet:

Frame 2: 128 bytes on wire (1024 bits), 124 bytes captured (992 bits) on interface 0

    Interface id: 0 (\\.\pipe\view_capture_172-27-5-51_6_89_07182017_154149)

    Encapsulation type: Ethernet (1)

    Arrival Time: Jul 18, 2017 15:41:13.680293000 India Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1500372673.680293000 seconds

    [Time delta from previous captured frame: 0.496532000 seconds]

    [Time delta from previous displayed frame: 0.496532000 seconds]

    [Time since reference or first frame: 0.496532000 seconds]

    Frame Number: 2

    Frame Length: 128 bytes (1024 bits)

    Capture Length: 124 bytes (992 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:mpls:pwethheuristic:pwethcw:eth:ethertype:vlan:ethertype:vlan:ethertype:pppoes:ppp:ipcp]

Ethernet II, Src: Performa_00:00:02 (00:10:94:00:00:02), Dst: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

    Destination: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        Address: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:02 (00:10:94:00:00:02)

        Address: Performa_00:00:02 (00:10:94:00:00:02)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header, Label: 1 (Router Alert), Exp: 0, S: 1, TTL: 64

    0000 0000 0000 0000 0001 .... .... .... = MPLS Label: Router Alert (1)

    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0

    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1

    .... .... .... .... .... .... 0100 0000 = MPLS TTL: 64

PW Ethernet Control Word

    Sequence Number: 0

Ethernet II, Src: Performa_00:00:03 (00:10:94:00:00:03), Dst: Superlan_00:00:01 (00:00:01:00:00:01)

    Destination: Superlan_00:00:01 (00:00:01:00:00:01)

        Address: Superlan_00:00:01 (00:00:01:00:00:01)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:03 (00:10:94:00:00:03)

        Address: Performa_00:00:03 (00:10:94:00:00:03)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: PPPoE Session (0x8864)

PPP-over-Ethernet Session

    0001 .... = Version: 1

    .... 0001 = Type: 1

    Code: Session Data (0x00)

    Session ID: 0x0001

    Payload Length: 74

Point-to-Point Protocol

    Protocol: Internet Protocol Control Protocol (0x8021)

PPP IP Control Protocol

    Code: Configuration Request (1)

    Identifier: 2 (0x02)

    Length: 10

    Options: (6 bytes), IP address

        IP address: 0.0.0.0

            Type: IP address (3)

            Length: 6

            IP Address: 0.0.0.0

Failing Packet:

Frame 1: 128 bytes on wire (1024 bits), 124 bytes captured (992 bits) on interface 0

    Interface id: 0 (\\.\pipe\view_capture_172-27-5-51_6_89_07182017_154149)

    Encapsulation type: Ethernet (1)

    Arrival Time: Jul 18, 2017 15:41:13.183761000 India Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1500372673.183761000 seconds

    [Time delta from previous captured frame: 0.000000000 seconds]

    [Time delta from previous displayed frame: 0.000000000 seconds]

    [Time since reference or first frame: 0.000000000 seconds]

    Frame Number: 1

    Frame Length: 128 bytes (1024 bits)

    Capture Length: 124 bytes (992 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:mpls:pwethheuristic:pwethcw:eth:ethertype:vlan:ethertype:vlan:ethertype:pppoes:ppp:ipcp]

Ethernet II, Src: Performa_00:00:02 (00:10:94:00:00:02), Dst: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

    Destination: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        Address: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:02 (00:10:94:00:00:02)

        Address: Performa_00:00:02 (00:10:94:00:00:02)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header, Label: 1 (Router Alert), Exp: 0, S: 1, TTL: 64

    0000 0000 0000 0000 0001 .... .... .... = MPLS Label: Router Alert (1)

    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0

    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1

    .... .... .... .... .... .... 0100 0000 = MPLS TTL: 64

PW Ethernet Control Word

    Sequence Number: 0

Ethernet II, Src: Performa_00:00:03 (00:10:94:00:00:03), Dst: Superlan_00:00:01 (00:00:01:00:00:01)

    Destination: Superlan_00:00:01 (00:00:01:00:00:01)

        Address: Superlan_00:00:01 (00:00:01:00:00:01)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:03 (00:10:94:00:00:03)

        Address: Performa_00:00:03 (00:10:94:00:00:03)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: PPPoE Session (0x8864)

PPP-over-Ethernet Session

    0001 .... = Version: 1

    .... 0001 = Type: 1

    Code: Session Data (0x00)

    Session ID: 0x0001

    Payload Length: 74

Point-to-Point Protocol

    Protocol: Internet Protocol Control Protocol (0x8021)

PPP IP Control Protocol

    Code: Configuration Request (1)

    Identifier: 2 (0x02)

    Length: 10

    Options: (6 bytes), IP address

        IP address: 20.6.0.23

            Type: IP address (3)

            Length: 6

            IP Address: 20.6.0.23

Regards,

Sadashivan

How can the transceiver module's serial number be extracted in the pf driver ? Also is it possible to extract the transceiver serial number in the VF driver ?

Hi!

There is a dual E5-2690v3 box based on  Supermicro SYS-2028GR-TR/X10DRG-H, BIOS 1.0c, running Ubuntu 16.04.1, w. all current updates.

It has a XL710-QDA2 card, fw 5.0.40043 api 1.5 nvm 5.04 0x80002537, driver 1.5.25 (the stock Ubuntu i40e driver 1.4.25 resulted in a crash), that is planned to be used as an iSCSI initiator endpoint. But there seems to be a problem: the log file fills up with "RX driver issue detected" messages and occasionally the iSCSI link resets as ping times out. This is critical error, as the mounted device becomes unusable!

So, Question 1: Is there something that can be done to fix the iSCSI behaviour of the XL710 card? When testing the card with iperf (2 concurrent sessions, the other end had a 10G NIC), there were no problems. The problems started when the iSCSI connection was established.

Question 2: Is there a way to force the card to work in PCI Express 2.0 mode? The server downgraded the card once after several previous failures and then it became surprisingly stable. I cannot find a way to make it persist though.

Some excerpts from log files (there are also occasional TX driver issues, but much less frequently than RX problems):

[  263.116057] EXT4-fs (sdk): mounted filesystem with ordered data mode. Opts: (null)

[  321.030246] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[  332.512601] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

..lots of the above messages...

[  481.001787] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[  487.183237] NOHZ: local_softirq_pending 08

[  491.151322] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

..lots of the above messages...

[ 1181.099046] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1199.852665]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295189627, last ping 4295190878, now 4295192132

[ 1199.852694]  connection1:0: detected conn error (1022)

[ 1320.412312]  session1: session recovery timed out after 120 secs

[ 1320.412325] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412331] sd 10:0:0:0: [sdk] killing request

[ 1320.412347] sd 10:0:0:0: [sdk] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

[ 1320.412352] sd 10:0:0:0: [sdk] CDB: Write Same(10) 41 00 6b 40 69 00 00 08 00 00

[ 1320.412356] blk_update_request: I/O error, dev sdk, sector 1799383296

[ 1320.412411] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412423] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412428] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412433] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412438] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412442] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412446] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412451] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412455] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412460] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412464] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412469] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412473] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412477] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412482] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412486] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412555] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412566] Aborting journal on device sdk-8.

[ 1320.412571] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412576] JBD2: Error -5 detected when updating journal superblock for sdk-8.

[ 1332.831851] sd 10:0:0:0: rejecting I/O to offline device

[ 1332.831864] EXT4-fs error (device sdk): ext4_journal_check_start:56: Detected aborted journal

[ 1332.831869] EXT4-fs (sdk): Remounting filesystem read-only

[ 1332.831873] EXT4-fs (sdk): previous I/O error to superblock detected

Unloading the kernel module and modprobe-ing it again:

[ 1380.970732] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 1.5.25

[ 1380.970737] i40e: Copyright(c) 2013 - 2016 Intel Corporation.

[ 1380.987563] i40e 0000:81:00.0: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0

[ 1381.127289] i40e 0000:81:00.0: MAC address: 3c:xx:xx:xx:xx:xx

[ 1381.246815] i40e 0000:81:00.0 p5p1: renamed from eth0

[ 1381.358723] i40e 0000:81:00.0 p5p1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

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

[ 1381.454729] i40e 0000:81:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[ 1381.471584] i40e 0000:81:00.1: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0

[ 1381.605866] i40e 0000:81:00.1: MAC address: 3c:xx:xx:xx:xx:xy

[ 1381.712287] i40e 0000:81:00.1 p5p2: renamed from eth0

[ 1381.751417] IPv6: ADDRCONF(NETDEV_UP): p5p2: link is not ready

[ 1381.810607] IPv6: ADDRCONF(NETDEV_UP): p5p2: link is not ready

[ 1381.820095] i40e 0000:81:00.1: PCI-Express: Speed 8.0GT/s Width x8

[ 1381.826141] i40e 0000:81:00.1: Features: PF-id[1] VFs: 64 VSIs: 66 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[ 1647.123056] EXT4-fs (sdk): recovery complete

[ 1647.123414] EXT4-fs (sdk): mounted filesystem with ordered data mode. Opts: (null)

[ 1668.179234] NOHZ: local_softirq_pending 08

[ 1673.994586] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1676.871805] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1692.833097] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1735.179086] NOHZ: local_softirq_pending 08

[ 1767.357902] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1803.828762] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

After several failures, the card loaded in PCI-Express 2.0 mode. It became stable then:

Jan  1 18:44:35  systemd[1]: Started ifup for p5p1.

Jan  1 18:44:35  systemd[1]: Found device Ethernet Controller XL710 for 40GbE QSFP+ (Ethernet Converged Network Adapter XL710-Q2).

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5028] devices added (path: /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/net/p5p1, iface: p5p1)

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5029] locking wired connection setting

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5029] get unmanaged devices count: 3

Jan  1 18:44:35  avahi-daemon[1741]: Joining mDNS multicast group on interface p5p1.IPv4 with address xx.xx.xx.xx.

Jan  1 18:44:35  avahi-daemon[1741]: New relevant interface p5p1.IPv4 for mDNS.

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5577] device (p5p1): link connected

Jan  1 18:44:35  avahi-daemon[1741]: Registering new address record for xx.xx.xx.xx on p5p1.IPv4.

Jan  1 18:44:35  kernel: [11572.541797] i40e 0000:81:00.0 p5p1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

Jan  1 18:44:35  kernel: [11572.579303] i40e 0000:81:00.0: PCI-Express: Speed 5.0GT/s Width x8

Jan  1 18:44:35  kernel: [11572.579309] i40e 0000:81:00.0: PCI-Express bandwidth available for this device may be insufficient for optimal performance.

Jan  1 18:44:35  kernel: [11572.579312] i40e 0000:81:00.0: Please move the device to a different PCI-e link with more lanes and/or higher transfer rate.

Jan  1 18:44:35  kernel: [11572.617328] i40e 0000:81:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 48 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA

Jan  1 18:44:35  kernel: [11572.635294] i40e 0000:81:00.1: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0

Jan  1 18:44:35  kernel: [11572.917343] i40e 0000:81:00.1: MAC address: 3c:xx:xx:xx:xx:xx

Jan  1 18:44:35  systemd[1]: Reloading OpenBSD Secure Shell server.

Jan  1 18:44:35  systemd[1]: Reloaded OpenBSD Secure Shell server.

Jan  1 18:44:35  kernel: [11572.921344] i40e 0000:81:00.1: SAN MAC: 3c:xx:xx:xx:xx:xx

Jan  1 18:44:35  NetworkManager[1911]: <warn>  [1483289075.9656] device (eth0): failed to find device 14 'eth0' with udev

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.9671] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/13)

Jan  1 18:44:35  kernel: [11572.976596] i40e 0000:81:00.1 p5p2: renamed from eth0

Kind regards,

jpe

Hi, I have several X710-DA4 that I purchased at different times, and some of them I was able to grab the latest firmware (5.05) and upgrade them. nvmupdate64e and ethool show this on the good ones:

driver: i40e

version: 1.6.42

firmware-version: 5.05 0x8000289d 1.1568.0

bus-info: 0000:85:00.2

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

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                               Ver. DevId S:B    Status

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

01) Intel(R) Ethernet Converged Network       5.05  1572 00:004 Up to date

    Adapter X710-4

02) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:129 Update not

                                                                available

03) Intel(R) Ethernet Converged Network       5.05  1572 00:133 Up to date

    Adapter X710-4

On the other box, it will not let me upgrade:

driver: i40e

version: 2.0.23

firmware-version: 4.10 0x800011c5 0.0.0

bus-info: 0000:01:00.1

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

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                               Ver. DevId S:B    Status

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

01) Intel(R) Ethernet Converged Network       4.10  1572 00:001 Update not

    Adapter X710-4                                              available

02) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:129 Update not

                                                                available

03) Intel(R) Ethernet Converged Network       4.10  1572 00:130 Update not

    Adapter X710-4                                              available

Does anyone know what's wrong?

Hello All,

We have been trying to make Unicast promiscuous mode work with RHEL7.3 with latest native ixgbe driver (ixgbe-5.1.3), but it seems that unicast promiscuous mode is not enabled for 82599 series nic cards in the native driver.

I can see an explicit check in ixgbe_sriov.c code, where before enabling promiscuous mode, it checks if NIC card is equal(or lower) than 82599EB, it returns.

Adding snippet below:

        case IXGBEVF_XCAST_MODE_PROMISC:

                if (hw->mac.type <= ixgbe_mac_82599EB)

                        return -EOPNOTSUPP;

                fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);

                if (!(fctrl & IXGBE_FCTRL_UPE)) {

                        /* VF promisc requires PF in promisc */

                        e_warn(drv,

                               "Enabling VF promisc requires PF in promisc\n");

                        return -EPERM;

                }

                disable = 0;

                enable = IXGBE_VMOLR_BAM | IXGBE_VMOLR_ROMPE |

                         IXGBE_VMOLR_MPE | IXGBE_VMOLR_UPE | IXGBE_VMOLR_VPE;

                break;

But, when I see the corresponding code in DPDK16.11 version, I can see the support has been added for 82599 NICs family. The feature seems to have implemented using IXGBE_VMOLR_ROPE  flag.

Relevant snippet from DPDK code:

uint32_t

ixgbe_convert_vm_rx_mask_to_val(uint16_t rx_mask, uint32_t orig_val)

{

        uint32_t new_val = orig_val;

        if (rx_mask & ETH_VMDQ_ACCEPT_UNTAG)

                new_val |= IXGBE_VMOLR_AUPE;

        if (rx_mask & ETH_VMDQ_ACCEPT_HASH_MC)

                new_val |= IXGBE_VMOLR_ROMPE;

        if (rx_mask & ETH_VMDQ_ACCEPT_HASH_UC)

                new_val |= IXGBE_VMOLR_ROPE;

        if (rx_mask & ETH_VMDQ_ACCEPT_BROADCAST)

                new_val |= IXGBE_VMOLR_BAM;

        if (rx_mask & ETH_VMDQ_ACCEPT_MULTICAST)

                new_val |= IXGBE_VMOLR_MPE;

        return new_val;

}

So, can you please let us know, why such difference between supported NIC ? and can we also have similar functionality ported to the native ixgbe driver?

Other setup details

Kernel version

# uname -r

3.10.0-514.el7.x86_64

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 -i eth2

driver: ixgbe

version: 5.1.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: yes

Regards

Pratik

I was trying to install an intel pro/1000 pt dual-port card into a Ubuntu linux server computer and ran into the "NVM Checksum is Invalid" message.  I tried to run the bootutil utility on the card, but now only ports 1 & 2 show and the mac addresses are gone.  Is this card salvageable or is it bricked?  I ordered another single-port card, but does anyone know the proper way to handle this issue?

Brian

Hi:

I am using the i40e_4.4.0 driver for XL710 Network Card. Currently, I am trying to loopback the connections.

For this purpose, I had to set the two ports on promiscuous mode. Thus, using my application, I crated custom UDP packets.

For the Rx Queue setting, I have set the flow director as:

ethtool -N ens1f0 flow-type udp4 dst-port 319 action 3 loc

ethtool -N ens1f1 flow-type udp4 dst-port 319 action 3 loc

Essentially, I want all the packets with this dst-port to be forwarded to Queue 3. I can also see the rule has been inserted.

But, as seen in the attached picture, the flow director is not able to match the incoming packet. Thus, it does not forward the incoming packet to my desired queue.

Is this error due to promiscuous mode that I had set on the NIC ports ?

I am not sure what's creating this issue. Also, I have verified that the incoming packet is destined for Port 319.

I will be able to provide other details, if needed !

I would appreciate any help.

Thanks !

Hi,

I have some Windows 10 1607 Pro mobile computers using the i211 ethernet adapter. The checkbox for Register this connection's address in DNS will not stay checked like every other computer we have and the DNS will not register unless I do it manually using ipconfig /registerdns.  I am using the latest Intel drivers .Has anyone seen this behavior?

Thanks,

Steve