Hello,

Can I please ask clarifications on XL710 on VLAN steering. I have few questions regarding it on top of what was asked before. Really appreciate for your valuable input please

1. 7.4.8.4 "VEB/VEPA Switching Algorithm" states that filtering happens by MAC+VLAN. It is impossible to perform filtering by VLAN only, as I understand it is HW limitation.

XL710 has something called "7.4.8.2 S-comp Forwarding Algorithm" which looks like exactly what we want. It does forwarding of packets to specific VSI based on S-tag. S-tag is a part of "7.4.9.5.5.1 Add VSI (0x0210)" command. I guess we can configure several VSIs for expected S-tags. Can you help us understand how to use this algorithm please?

As I understood "port virtualizer" (7.4.2.4.3 "Cascaded VEB and port virtualizers") supposed to be configured to use this switching algorithm. In i40e driver (kernel or DPDK) I do not see anything related to configuration of "port virtualizers", except "i40e_aq_add_pvirt" function which is not used anywhere.

Is it possible to configure "port virtualizer" with existing latest i40e driver?

Another question is about "i40e_aq_set_vsi_uc_promisc_on_vlan" function in i40e driver (7.4.9.5.9.5 "Set VSI Promiscuous Modes"). It enables promiscuous mode for unicast packets with specific VLAN, so all packets with that VLAN will be replicated to configured VSI. In XL710 datasheet I`ve found that it works only in "Cloud VEB algorithm" (7.4.8.6). Can we somehow enable this algorithm with existing i40e drivers?

Thannk you so much

Hello.

We have 2 servers using X70 nics (Debian Jessie, Kernel 4.14.15).

On each interface we have two ip on same subnet.

Randomly, the secondary ip address doesn’t answer to arp request anymore.

The only solution we have to fix the problem is to manually send arp announcements over the network using a script (while true, sendarp).

There is no proxy arp on neighbors.

# ethtool -i eth0

driver: i40e

version: 2.1.14-k

firmware-version: 6.01 0x80003485 1.1747.0

bus-info: 0000:82:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

This issue occurs on both servers, and we have same software configuration on a lot  sites, and the problem appear only when there is X710 nics.

Anyone already had this problem ?

Kind regards

Hi Sharon and Ninwardspiral,

We are having similar problems with the exact same NIC, and by coincidence with the same breakout cable (although we tested many).

Driver and firmware are updated to the latest versions available (2.4.3 and 6.01 respectively):

version: 2.4.3

firmware-version: 6.01 0x800034af 1.1853.0

First cable that does not work: ( QSFP to 4x10G SFP+, amphenol, 2m)

From the manufacturer website: Each QSFP-SFP+ splitter cable features a single QSFP+ connector (SFF-8436) rated for 40-Gbps on one end and (4) SFP+ connectors (SFF-8431), each rated for 10-Gbps, on the other.

SF-QSFP4SFPPS-002 Amphenol Commercial Products | Cable Assemblies | DigiKey (exact cable we bought)

ethtool -m output:

Identifier : 0x03 (SFP)

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

Connector : 0x21 (Copper pigtail)

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

Transceiver type : FC: Copper Passive

Encoding : 0x00 (unspecified)

BR, Nominal : 10300MBd

Rate identifier : 0x00 (unspecified)

Length (SMF,km) : 0km

Length (SMF) : 0m

Length (50um) : 0m

Length (62.5um) : 0m

Length (Copper) : 2m

Length (OM3) : 0m

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

Vendor name : Amphenol

Vendor OUI : 78:a7:14

Vendor PN : 624400002

Vendor rev : A

Option values : 0x00 0x00

BR margin, max : 0%

BR margin, min : 0%

Vendor SN : APF1718002044N

Date code : 170513

ethtool <intf> output (after bringing interfaces up):

Supported ports: [ ]

Supported link modes: Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes: Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: Unknown!

Duplex: Unknown! (255)

Port: Other

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

drv probe link timer

Link detected: no

Second cable that does not work: ( QSFP to 4x10G SFP+, generic brand):

2m(6.6ft) 40G QSFP+ to 4SFP+ Passive Breakout DAC Cable | FS.COM

ethtool -m <intf> output:

Identifier : 0x03 (SFP)

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

Connector : 0x21 (Copper pigtail)

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

Transceiver type : FC: Copper Passive

Encoding : 0x00 (unspecified)

BR, Nominal : 10300MBd

Rate identifier : 0x00 (unspecified)

Length (SMF,km) : 0km

Length (SMF) : 0m

Length (50um) : 0m

Length (62.5um) : 0m

Length (Copper) : 2m

Length (OM3) : 0m

Passive Cu cmplnce. : 0x03 (unknown) [SFF-8472 rev10.4 only]

Vendor name : FIBERSTORE

Vendor OUI : 00:00:00

Vendor PN : QSFP-4SFP10G-DAC

Vendor rev :

Third Cable, it does work but its not what we need:

https://www.brack.ch/delock-direct-attach-kabel-330520

As a way to see if the NICs work, we also bought a SFP+ to SFP+ cable that is supposed to support SFP MSA and SFF-8431, but not SFF-8472. What is impressive is that this cable is detected and allows us to bring the link up

and even exchange some data at 10gbps. However, that is not what we need.

Encoding : 0x00 (unspecified)

BR, Nominal : 10300MBd

Rate identifier : 0x00 (unspecified)

Length (SMF,km) : 0km

Length (SMF) : 0m

Length (50um) : 0m

Length (62.5um) : 0m

Length (Copper) : 1m

Length (OM3) : 0m

Active Cu cmplnce. : 0x0c (unknown) [SFF-8472 rev10.4 only]

Vendor name : CISCO-TYCO

Vendor OUI : 00:40:20

Vendor PN : 2127493-1

Vendor rev : A

Option values : 0x00 0x12

Option : RX_LOS implemented

Option : TX_DISABLE implemented

BR margin, max : 0%

BR margin, min : 0%

Vendor SN : 164800277_______

Settings for ens787f3:

Supported ports: [ FIBRE ]

Supported link modes: Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes: Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: 10000Mb/s

Duplex: Full

Port: Direct Attach Copper

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

drv probe link timer

Link detected: yes

Fourth Cable (to be delivered):

Intel X4DACBL3 40G QSFP+ Breakout DAC Cable | FS.COM

We are waiting for a fourth cable (this time is supposed to be intel compatible, but we dont know if it will be compatible with our switch...).

Why is the amphenol cable not working if the output of ethernet says: (SFF-8431 appendix E) [SFF-8472 rev10.4 only] which as stated in : Compatible SFP+ Modules, SFP Modules, and Cables for Intel® Ethernet...  should be enough to be compatible. Why

only SFP+ to SFP+ cables work? What should we do? We spent to many resources and time buying different cables.

And to finish, would this NIC Intel® Ethernet Network Adapter XXV710-DA2 Product Specifications  give us better results?

Thanks.

Edgar

Hello;

I have a Box (supermicro) with:

S.O :    FreeBSD 11.1-STABLE (FreeNAS)

NIC: - Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02).

- Intel(R) Ethernet Connection XL710/X722 Driver, Version - 1.7.12-k

- dev.ixl.0.fw_version: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002a43 oem 1.261.0

I have issues with the connection  Flapping on the interfaces 10G and a lot of messages "ixl0: Malicious Driver Detection event 2 on TX queue 2, pf number 0"

I m trying to Upgrade the Firmware to 6.0.1; but the procedure (./nvmupdate64e) says:

Num Description                               Ver. DevId S:B    Status

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

01) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:001     Update not

                                                                                                             available

02) Intel(R) Ethernet Controller X710 for     5.05  1572 00:002     Update not

    10GbE SFP+                                                                                  available

Tool execution completed with the following status: Device not found.

I have got that problem on few laptops Dell Precision 3150. I have tried different versions of drivers, bios and clean Windows installation and problem still persist.

Hi,

We are working on a i210 flash-less design in which the i210 operates in Serdes/1000Base-BX mode attached to an external optical module. We have already validated the design as it has passed all acceptance tests.

Our application requires changing the value of one register (Fiber Specific Control Register 2). This that can only be done from the driver. We have successfully tested it under Linux. We would like to make it also work under Windows 7 Embedded Edition. Is it possible for us to have access to the source code of the Windows version of the driver?

Thanks in advance.

Best regards,

Manuel

Does the X540-T2 NIC supported on Windows Server 2016?

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

Here is some information about my environment :

Hardware :

Supermicro X10SRi-F motherboard with Onboard i350 controller;

Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz;

Intel Corporation 82576 Gigabit Network Adapter;

System:

Centos 7

Kernel:4.15.4-1.el7.elrepo.x86_64

Hypervisor:KVM

So far, vt-d and SR-IOV are all enabled on the BIOS and intel_iommu=on is enabled on the host system and it is verify by virt-host-validate command line.

Both onboard i350 controller and intel 82576 are virtualized into different virtual functions(vf). Things are getting different about iommu group. Each vf from i350 could successfully be in individual iommu group, but vf from intel 82576 are grouped into the same iommu.

Since all the vfs from intel 82576 are in the same IOMMU group, whenever I want to attach any of them to VM, it will generate the error as below:

“

…

2018-02-23T17:16:18.202445Z qemu-kvm: -device vfio-pci,host=04:10.1,id=hostdev0,bus=pci.0,addr=0x9: vfio: error, group 34 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver.

…

“

As for the i350, I don’t have this problem.

I have read some posts, saying that this is maybe the ACS problem but my cpu does support that:

“

00:01.0 PCI bridge: Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D PCI Express Root Port 1 (rev 01) (prog-if 00 [Normal decode])

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+

….

        Capabilities: [100 v1] Vendor Specific Information: ID=0002 Rev=0 Len=00c <?>

        Capabilities: [110 v1] Access Control Services

…

“

From Intel 82576 specification, it says it supports SR-IOV, however, it does not work unless each VF has its own individual IOMMU group.Does anyone know how to do it?

Thank you!

I'm trying to install the Proset driver and utilities but the installation says it cannot find any Intel adapters.

Windows 10 found the adapter just fine and installed the Windows Update version of the drivers but I was hoping to experiment with teaming on this system.

Is this board fully supported?

Windows 10 Build 1709

Hi,

  We are observing that when Intel NIC I350 AAP (PCIE Endpoint) is used with Nvidia PCIE Root port, PCIE link fails to enter into L2 states in some cases.

Failure Scenario:

The application software initiates lower power sequence to bring the  PCIE link to enter into L2 state by first bringing the endpoint device into D3hot state followed by PME_Turn_Off request from Nvidia Root port to the endpoint device(NIC).

It is observed that  the endpoint device(NIC) does bring the link into L1 and also responds with PME_TO_ACK as expected but it does not initiate L2 entry request. So the PCIE Link (Root port) fails to enter into L2 state.

Details of the failure sequence and observations:

There seems to be some issue with the NIC I350 AAP during the L2 entry using Sequence-1 below, whereas same sequence works for the  NIC -  I350AM4. The Sequence-1 followed for the L2 entry and device details are described below.

Sequence-1 (Failing Sequence): L0 → L1 → L0 → L2/L3 Ready: Intel NIC I350 AAP Failing while   NIC - I350AM4 works fine.
1. Device is in L0 and System software directs all Functions of a Downstream component to D3hot.
2. The Downstream component then initiates the transition of the Link to L1 as required.
3. System software then causes the Root Complex to broadcast the PME_Turn_Off Message in preparation for removing the main power source.
4. This Message causes the subject Link to transition back to L0 in order to send it and to enable the Downstream component to respond with PME_TO_Ack.
5. After sending the PME_TO_Ack, the Downstream component initiates the L2/L3 Ready transition protocol. (Intel NIC I350 AAP fails in this step)

Failing Device Details :

I210T1BLK - Single Port NIC ( I350 AAP)

Date of Manufacture : 05/2014

Device 8086:1533 (rev 03)

Working Device Details :

Dual Port NIC -  I350AM4

Date of Manufacture  :  06/2013

Device 8086:1521 (rev 01)

It is also observed that bothIntel NIC I350 AAP and NIC   I350AM4 enter into L2 without any issue while following sequence-2 below.

Sequence-2 (passing sequence):
1. Device is in L0 and system software causes the Root Complex to broadcast the PME_Turn_Off Message in preparation for removing the main power source.
2. The Downstream components respond with PME_TO_Ack.
3. After sending the PME_TO_Ack, the Downstream component initiates the L2/L3 Ready transition protocol.

I am looking for help from your team if there is any known issue with Intel NIC I350 AAP related to  Link entering into L2 while following Sequence-1 describe above.

Please also suggest how can we proceed further to root cause the issue and avoid the failure for the L2 entry while following the sequence-1.

Thanks & Regards,

Alap

Baltazar

Hi.

I am having problems with I219-V VLAN tag. Whan adding  a tag I get blue screen every single time., reason Bad_pool_caller.

First step I am adding new VLAN in VLAN tab from Intel Ethernet conection I219-V:

And when adding new VLAN tag, let's say 13 it crashes:

I don't even get a chance to press second OK in Intel window, it crashes right here. It says Configuring for two seconds, maybe tree and the blue screen. I can make it anytime I want.
I tried with versions 12.17.8.7 and 12.15.25.6:

I have Lenovo T470s. Any help would be gratefull.

Regards

Hi,

I am observing a strange issue with i354 when auto-negotiation is turned off.

The device I have has 6 ethernet ports. Port 1 and 2 are based on i210 and port

3 to 6 are based on i354 (connected thru an external PHY). The CPU is Atom

Rangeley (4 core).

I have connected ports 3 and 4 back to back with an external cable. When the

link is forced to 100M/Full duplex with auto-negotiation off on both the ports,

the link does not come up.

Whereas the link comes up fine when eth3 (i354) and eth1 (i210) are connected

back to back and forced to 100M/Full duplex with auto-negotiation off.

This issue is seen with linux kernel (ubuntu 14.04).

Is this a known issue ?

Following are logs when running the test using ethtool from linux

admin@Ananda-Desk:~$ lspci | grep Ethernet

00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev

03)  - eth2

00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev

03)  - eth3

00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev

03)  - eth4

00:14.3 Ethernet controller: Intel Corporation Ethernet Connection I354 (rev

03)  - eth5

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection

(rev 03) - eth0

02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection

(rev 03) - eth1

admin@Ananda-Desk:~$ ethtool -i eth3

driver: igb

version: 5.2.13-k

firmware-version: 0.0.0

bus-info: 0000:00:14.1

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: no

[Force 100M/Full on eth3]

admin@Ananda-Desk:~$ sudo ethtool -s eth3 autoneg off duplex full speed 100

admin@Ananda-Desk:~$ ethtool eth3

Settings for eth3:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supported pause frame use: Symmetric

        Supports auto-negotiation: Yes

        Advertised link modes:  Not reported

        Advertised pause frame use: Symmetric

        Advertised auto-negotiation: No

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: off

        MDI-X: off (auto)

Cannot get wake-on-lan settings: Operation not permitted

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: yes

admin@Ananda-Desk:~$ ethtool eth4

Settings for eth4:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supported pause frame use: Symmetric

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Advertised pause frame use: Symmetric

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Half

        Port: Twisted Pair

        PHYAD: 2

        Transceiver: internal

        Auto-negotiation: on

        MDI-X: on (auto)

Cannot get wake-on-lan settings: Operation not permitted

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: yes

[Force 100M/Full on eth4]

admin@Ananda-Desk:~$ sudo ethtool -s eth4 autoneg off duplex full speed 100

admin@Ananda-Desk:~$

admin@Ananda-Desk:~$ ethtool eth4

Settings for eth4:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supported pause frame use: Symmetric

        Supports auto-negotiation: Yes

        Advertised link modes:  Not reported

        Advertised pause frame use: Symmetric

        Advertised auto-negotiation: No

        Speed: Unknown!

        Duplex: Unknown! (255)

        Port: Twisted Pair

        PHYAD: 2

        Transceiver: internal

        Auto-negotiation: off

        MDI-X: on (auto)

Cannot get wake-on-lan settings: Operation not permitted

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: no <<<<<<<<<<<<<<

admin@Ananda-Desk:~$ ethtool eth3

Settings for eth3:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supported pause frame use: Symmetric

        Supports auto-negotiation: Yes

        Advertised link modes:  Not reported

        Advertised pause frame use: Symmetric

        Advertised auto-negotiation: No

        Speed: Unknown!

        Duplex: Unknown! (255)

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: off

        MDI-X: off (auto)

Cannot get wake-on-lan settings: Operation not permitted

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: no <<<<<<<<<<<

[Connect cables between eth1 and eth3]

[Force 100M/Full on eth1]

admin@Ananda-Desk:~$

admin@Ananda-Desk:~$ sudo ethtool -s eth1 autoneg off duplex full speed 100

admin@Ananda-Desk:~$

admin@Ananda-Desk:~$ ethtool eth1

Settings for eth1:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supported pause frame use: Symmetric

        Supports auto-negotiation: Yes

        Advertised link modes:  Not reported

        Advertised pause frame use: Symmetric

        Advertised auto-negotiation: No

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: off

        MDI-X: on (auto)

Cannot get wake-on-lan settings: Operation not permitted

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: yes <<<<<<<<<<<<

admin@Ananda-Desk:~$ ethtool eth3

Settings for eth3:

        Supported ports: [ TP ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

                                1000baseT/Full

        Supported pause frame use: Symmetric

        Supports auto-negotiation: Yes

        Advertised link modes:  Not reported

        Advertised pause frame use: Symmetric

        Advertised auto-negotiation: No

        Speed: 100Mb/s

        Duplex: Full

        Port: Twisted Pair

        PHYAD: 1

        Transceiver: internal

        Auto-negotiation: off

        MDI-X: off (auto)

Cannot get wake-on-lan settings: Operation not permitted

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: yes <<<<<<<<<<<<

Hi,

I have a XL710QDA2 40GB NIC and I also have the INTEL Ethernet QSFP+ cable. I have two problems:

1- This NIC does not get IPV4 address automatically. What should I do to force it to get IPV4 address upon boot?

2- I have tried to send packets through this NIC to other devices, but it can not forward any packet (IPV4, IPV6, or even broadcast packets). How can I enable the packet forwarding and receiving of this NIC?

Thanks for your time. I would appreciate it if you could help me out.

Best,

Marjan

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

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

options i40e allow_unsupported_sfp=1

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

Intel Ethernet Drivers and Utilities / Mailing Lists

Output from dmesg:

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

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

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

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

Other pertinent output:

root@lab4:~# ethtool -m eth6

Identifier                                : 0x03 (SFP)

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

Connector                                 : 0x21 (Copper pigtail)

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

Transceiver type                          : FC: Copper Passive

Encoding                                  : 0x00 (unspecified)

BR, Nominal                               : 10300MBd

Rate identifier                           : 0x00 (unspecified)

Length (SMF,km)                           : 0km

Length (SMF)                              : 0m

Length (50um)                             : 0m

Length (62.5um)                           : 0m

Length (Copper)                           : 3m

Length (OM3)                              : 0m

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

Vendor name                               : Amphenol

Vendor OUI                                : 78:a7:14

Vendor PN                                 : 624400003

Vendor rev                                : A

Option values                             : 0x00 0x00

BR margin, max                            : 0%

BR margin, min                            : 0%

Vendor SN                                 : APF13470035GDT

Date code                                 : 131122

root@lab4:~# ethtool -i eth6

driver: i40e

version: 2.4.3

firmware-version: 6.01 0x800034af 1.1747.0

expansion-rom-version:

bus-info: 0000:08:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

root@lab4:~# ethtool eth6

Settings for eth6:

Supported ports: [ ]

Supported link modes:   Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes:  Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: Unknown!

Duplex: Unknown! (255)

Port: Other

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

       drv probe link timer

Link detected: no

root@lab4:~# ip link show eth6

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

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

Hello,

We are having an issue with updating the firmware of our X710 network cards, here is the output of the nvmupdaten64e command:

Num Description                               Ver. DevId S:B    Status

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

01) Intel(R) Ethernet 10G 4P X710 SFP+ rNDC   6.00  1572 00:001 Update not available

02) Intel(R) Gigabit 4P I350-t Adapter       1.103  1521 00:129 Update not available

We are running 9 hosts with ESXi 6.5U1 7388607

Please advise.

Hi.

I am having problems with 82574L

Hardware :

03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

System:

Centos 7.3   kernel：3.10.0-514.el7.x86_64

Output from message

Feb 26 20:50:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 20:50:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 22:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 22:10:04 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 22:40:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 22:40:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 23:20:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 23:20:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 23:30:02 localhost kernel: e1000e: slot0_GE2 NIC Link is Down

Feb 26 23:30:02 localhost kernel: e1000e: slot0_GE2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 27 01:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 27 01:10:04 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 27 03:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 27 03:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

modinfo

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

version:        3.3.6-NAPI

license:        GPL

description:    Intel(R) PRO/1000 Network Driver

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

rhelversion:    7.3

srcversion:     6453212B70344504D53DE09

alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*

depends:        ptp

vermagic:       3.10.0-514.el7.x86_64 SMP mod_unload modversions

parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)

parm:           TxIntDelay:Transmit Interrupt Delay (array of int)

parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)

parm:           RxIntDelay:Receive Interrupt Delay (array of int)

parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)

parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)

parm:           IntMode:Interrupt Mode (array of int)

parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)

parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)

parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)

parm:           EEE:Enable/disable on parts that support the feature (array of int)

parm:           Node:[ROUTING] Node to allocate memory on, default -1 (array of int)

parm:           debug:Debug level (0=none,...,16=all) (int)

[root@localhost ~]# ethtool -k slot0_GE4

Features for slot0_GE4:

rx-checksumming: on

tx-checksumming: on

tx-checksum-ipv4: off [fixed]

tx-checksum-ip-generic: on

tx-checksum-ipv6: off [fixed]

tx-checksum-fcoe-crc: off [fixed]

tx-checksum-sctp: off [fixed]

scatter-gather: on

tx-scatter-gather: on

tx-scatter-gather-fraglist: off [fixed]

tcp-segmentation-offload: on

tx-tcp-segmentation: on

tx-tcp-ecn-segmentation: off [fixed]

tx-tcp6-segmentation: on

udp-fragmentation-offload: off [fixed]

generic-segmentation-offload: on

generic-receive-offload: on

large-receive-offload: off [fixed]

rx-vlan-offload: on

tx-vlan-offload: on

ntuple-filters: off [fixed]

receive-hashing: on

highdma: on [fixed]

rx-vlan-filter: on [fixed]

vlan-challenged: off [fixed]

tx-lockless: off [fixed]

netns-local: off [fixed]

tx-gso-robust: off [fixed]

tx-fcoe-segmentation: off [fixed]

tx-gre-segmentation: off [fixed]

tx-ipip-segmentation: off [fixed]

tx-sit-segmentation: off [fixed]

tx-udp_tnl-segmentation: off [fixed]

tx-mpls-segmentation: off [fixed]

fcoe-mtu: off [fixed]

tx-nocache-copy: off

loopback: off [fixed]

rx-fcs: off

rx-all: off

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

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

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

busy-poll: off [fixed]

tx-sctp-segmentation: off [fixed]

l2-fwd-offload: off [fixed]

hw-tc-offload: off [fixed]

[root@localhost ~]#

Hi there,

I'm using X710-DA4 with SR-IOV mode on Skylake servers.

latest fw and drivers (i40e) installed on system. and vf driver is added into blacklist.

there is a VF that belongs to a PF. and that VF is attached to a VM.

after that, I tried ping from VM to a pc that connected to the server port that has the PF.

it works well. ping packets are received by the pc.

the problem (or different behavior) is that,

even the PF link goes down using "ifconfig xx down or ip link set xxx down" but the VF still sending packet to the pc.

is this right behavior on X710/XL710?

if yes, any architectural/tech background that I can get?

Regards,

hi,

I am currently using a network adapter from Intel.I can see some information from the command line "lspci" and it is "Intel Corporation 82576 Gigabit Network Connection", so I think it is "Intel® 82576 Gigabit Ethernet Controller" but it seems there are two types of adapters under this category, one is 82576EB and the other one 82576NS. Are there any ways can allow customer to further find out what exact model of network adapter they are using? I have the Serial Number:"1CA2CE0341ADG18771-002" but I just done know how to use this number to search on the Intel website.

Thanks

Here is some information about my environment :

Hardware :

Supermicro X10SRi-F motherboard with Onboard i350 controller;

Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz;

Intel Corporation 82576 Gigabit Network Adapter;

System:

Centos 7

Kernel:4.15.4-1.el7.elrepo.x86_64

Hypervisor:KVM

So far, vt-d and SR-IOV are all enabled on the BIOS and intel_iommu=on is enabled on the host system and it is verify by virt-host-validate command line.

Both onboard i350 controller and intel 82576 are virtualized into different virtual functions(vf). Things are getting different about iommu group. Each vf from i350 could successfully be in individual iommu group, but vf from intel 82576 are grouped into the same iommu.

Since all the vfs from intel 82576 are in the same IOMMU group, whenever I want to attach any of them to VM, it will generate the error as below:

“

…

2018-02-23T17:16:18.202445Z qemu-kvm: -device vfio-pci,host=04:10.1,id=hostdev0,bus=pci.0,addr=0x9: vfio: error, group 34 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver.

…

“

As for the i350, I don’t have this problem.

I have read some posts, saying that this is maybe the ACS problem but my cpu does support that:

“

00:01.0 PCI bridge: Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D PCI Express Root Port 1 (rev 01) (prog-if 00 [Normal decode])

        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+

….

        Capabilities: [100 v1] Vendor Specific Information: ID=0002 Rev=0 Len=00c <?>

        Capabilities: [110 v1] Access Control Services

…

“

From Intel 82576 specification, it says it supports SR-IOV, however, it does not work unless each VF has its own individual IOMMU group.Does anyone know how to do it?

Thank you!