Hi,

For a study, I would like to know the differences between two Intel Network driver versions (example: delta changes/fixes/improvements from v18.6 and v21.1)

In the Intel websites, I don't get this information. can you please update from where can I get these information?

Appreciate your help!

Hi, I have QAT8920 and QAT8955 adapters, and I want to use it to accelerate the LZS compression speed, but I can not find the start guide and  LZS smaple patch, can some body help with this?  Thanks a lot!

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

Hi,

I am receiving the follwoing error when I installed the NIC card on HP Server

igb 0000:07:00.0: The NVM Checksum Is Not Valid

Please provide troubleshooting steps.

Regards,

Rahul

Hello Intel community. I need help for Intel(R) Ethernet Connection I217-V wich isn't working suddenly after a Windows update on end december (don't remember the date). After that I was looking for solutions like uptading my bios, LAN, switching to windows 7 (I'm back to Win10) and other sh*t... nothing works. So I want to share a screenshot of the problem here. And a last thing, I tried the intel driver uptade utility and it found that my chipest needs update from 10.0.14393.594 to 10.1.1.14. So I did it but after the reboot I opened the utility again and it says the same thing  that it needs an update from 10.0.14393.594 to 10.1.1.14.

Thanks for any info, any solution. And sorry if there are some mistakes I have a low level of english

Hi,

I started my Windows 10 PC and got a blue screen message:

IQRL not less or equal ... Windows will fix this and restart.

After that I can no longer connect to the internet.

I get a "Windows couldn't automatically bind the IP protocol stack to the network adapter."

... message.

I have searched high and low in forums and tried all sort of things, but no result.

ipconfig gives a black screen. It doesn't connect.

I do not see a "Network Reset option in Windows 10, so there seems to be something wrong there as well.

I had a 82579LM which was working, but I thought I try an update. Now I have both, an 82579LM (older) and an 82579V (newer) network adapter on my computer.

I can't seem to uninstall them, they just keep coming back.

The 82579LM is now greyed out and right click says "error getting adapter info"

I can't reinstall the 82579LM because it says there already is a newer driver and I need to unintall that first.

When I uninstall the 82579V driver and do a restart, it is back. I can't get rid of it.

Do the two driver interfere with each other?

How do I reset this?

I have many other things listed, but I don't have a clue what they are?

Any help? Desperate!

I want to change I350 PCIe  link speed to Gen1 from EEPROM but I don't know address, who can help~

Hello,

Is it possible to have multiple VLAN ID in Intel I210 network card on Windows Server 2016 ?

I installed the Intel drivers but apparently you can only define one VLAN ID?

Pilote version : 12.15.184.0 (04/08/2016)

Thanks for you help

Best Regards,

Fabien

Hi,

I have a system with an Intel X710 (supermicro onboard card).

There is a somewhat unusual configuration on this system, but this does work everywhere else I've seen (including other intel cards on other systems):

I have an interface, with two vlans, eg:

eth0.10

eth0.11

If I configure eth0.10 with a specific mac address, it appears that something happens in the driver/hardware level that prevents the network card from receiving (tcpdump does not see them) packets with that source mac address, even when they are coming in vlan11

Running the latest driver (not the OS-included one): 1.6.42

OS is Ubuntu Linux, 14.04.5 with 4.4 kernel    

Any idea how to disable this behavior?

Thanks,

-Adam

Hi

just upgraded to windows 10.

There is a Intel pro 1000 and in windows 7 after installing Advanced Network services from Intel the VLAN feature was very helpful

after upgrading to Windows 10 the  VLANS are no longer available.

When attempting to install Advanced Network services from Intel,  the following error is displayed

there is an issue with Microsoft* windows* 10 the prevents the Intel(R) Advanced Network Services from working correctly

where can the correct drivers be found, searches have been unsuccessful thus far.

Any help appreciated.

Chris

I was installing the latest drivers for my motherboard, I211 + I219-V on a fresh W10 x64, the 21.1 package.

I219-V work fine

But the new Drivers for I211 (at least, maybe others too) inside ProSet 21.1 are signed ¿Wrong? by INTELNPG1, and Windows refuse them with the classical Error 52.

ProSet 21.0, in other hands, work fine, the sign are correct. issued not by INTELNPG1, but Intel(R) Intel Network Drivers.

Not a drama, but it would be nice to install a properly signed driver to use it.

More strange, Drivers for I219-V are signed by INTELNPG1 too, and work fine (same cert)

• We have been using the X710 and designers have been investing time in this card and driver
• If we wanted to look at the XL710 would it be transparent,  same driver and all?  or not?

I got the board with i5 CPU 3550S and Intel 82579LM onboard NIC .Found intermittent failed running internal & external LAN loop-back test by using Intel LAN DOS Utility Celo v1.17.  The test only failed after running for few cycles , Anyone have idea what cause the test failed?

A latest version V1.21 found in Intel download center, any changes in Celo from V1.17 to 1.21?

Thanks.

Hello,

I am currently writing a driver for the i219 and tried to access the received data, but I am missing the Receive Descriptor Base Address (RDBAL/RDBAH)?

I couldn't find this information in the datasheet (http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-connection-i219-datasheet.pdf).

Was also looking at the datasheet of the PCH (http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-series-chipset-datasheet-vol-2.pdf).

The datasheet of the i217 (http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i217-ethernet-controller-datasheet.pdf ) contains the RDBAL/RDBAH but I am not entirely convinced that these addresses are also correct for the i219.

I really appreciate any help you can provide,

Akir

Hello experts,

I added my question at the end of some old link (SR-IOV on NIC 82599: Are VF MAC Addresses unique? ) but no one answer that. So I'm asking here again.

I'm looking for a way to reset VF MAC, not just OS MAC, according to Patrick it is called "administratively assigned MAC".

At initially when a VF is created it is assigned with 00:00:00:00:00:00 (iproute show) as though in OS log say different. After spawning a virtual machine with the VF having some specific MAC, whenever I destroy that virtual machine libvirt try to revert the mac address of VF but eventually failed. Here's the log.

Dec 27 12:57:13 mita-nova1 kvm: 0 guests now active

Dec 27 12:57:14 mita-nova1 systemd-machined: Machine qemu-6-iovtest terminated.

Dec 27 12:57:14 mita-nova1 journal: End of file while reading data: Input/output error

Dec 27 12:57:14 mita-nova1 journal: Cannot set interface MAC/vlanid to 00:00:00:00:00:00/0 for ifname ens1f1 ifindex -1 vf 1: Invalid argument

Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: enabling device (0000 -> 0002)

Dec 27 12:57:14 mita-nova1 kernel: ixgbe 0000:05:00.1 ens1f1: VF Reset msg received from vf 1

Dec 27 12:57:14 mita-nova1 journal: Failed to open file '/var/run/libvirt/qemu/ens1f1_vf1': No such file or directory

Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: fe:ff:ff:ff:ff:ff

Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: MAC: 1

Dec 27 12:57:14 mita-nova1 kernel: ixgbevf 0000:05:10.3: Intel(R) 82599 Virtual Function

This lead to MAC address collision because the VF will remain in previous MAC address. If I start new virtual machine with the other VF having that MAC address then it won't work.

The host machine is running RHEL 7.3 and ixgbe version is 4.0.1-k-rh7.2. If you need any more information just let me know.

Thanks in advance,

Minho Ban

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

Hello,

We have servers with 2 XL710 quad cards each.

In first, we got this firmware version:

firmware-version: f4.22 a1.1 n04.26 e8000152d

LLDP was working fine, no problem, trames are correctly received.

But after upgrading to (seems to be the last version):

firmware-version: 4.53 0x80001da6 0.0.0

We don't receive any LLDP frames anymore.

It seems that theses frames are dropped by the X710 cards.

I tried to downgrade to 4.42 firmware but ... same thing

The problem occurs on both vSphere 6.0 and Linux (RHEL 6.6) on the 5 servers that have theses ethernet adapter and their firmware updated

We have other cards from other vendor on theses servers that are plugged on the same network equipments and they receive LLDP frames without problems.

Some debug informations (vsphere side, we upgraded the driver to the last version according the HCL, but the problem is the same with the "base" driver):

# lspci|grep Ethernet

0000:02:00.0 Network controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet [vmnic0]

0000:02:00.1 Network controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet [vmnic1]

0000:02:00.2 Network controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet [vmnic2]

0000:02:00.3 Network controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet [vmnic3]

0000:04:00.0 Network controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet [vmnic4]

0000:04:00.1 Network controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet [vmnic5]

0000:08:00.0 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic10]

0000:08:00.1 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic11]

0000:08:00.2 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic12]

0000:08:00.3 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic13]

0000:0b:00.0 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic6]

0000:0b:00.1 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic7]

0000:0b:00.2 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic8]

0000:0b:00.3 Network controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [vmnic9]

# vmkchdev -l|grep vmnic6

0000:0b:00.0 8086:1572 8086:0002 vmkernel vmnic6

# ethtool -i vmnic6

driver: i40e

version: 1.3.38

firmware-version: 4.53 0x80001da6 0.0.0

bus-info: 0000:0b:00.0

 

 

 

Some debug informations (Linux side, i40e driver upgraded too, but problem is the same with the "base" driver):

# lspci | grep Ethernet

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)

02:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)

02:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)

02:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)

04:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)

04:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)

08:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

08:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

08:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

08:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

0b:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

0b:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

0b:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

0b:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

 

# ethtool -i eth6

driver: i40e

version: 1.3.39.1

firmware-version: 4.53 0x80001da6 0.0.0

bus-info: 0000:0b:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

 

# ethtool -k eth6

Features for eth6:

rx-checksumming: on

tx-checksumming: on

        tx-checksum-ipv4: on

        tx-checksum-unneeded: off

        tx-checksum-ip-generic: off

        tx-checksum-ipv6: on

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

        tx-checksum-sctp: on [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: on

        tx-tcp6-segmentation: on

udp-fragmentation-offload: off [fixed]

generic-segmentation-offload: on

generic-receive-offload: on

large-receive-offload: off

rx-vlan-offload: on

tx-vlan-offload: on

ntuple-filters: on

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-udp_tnl-segmentation: off [fixed]

fcoe-mtu: off [fixed]

loopback: off [fixed]

 

vSphere says that "Link Layer Discovery Protocol is not available on this physical network adapter"

LLDPD under Linux don't output any informations on neighbors switchs for the XL710's cards

From switch perspective we are seeing the LLDP frame well transmitted on the port !

But when trying to capture LLDP frames both tcpdump under linux (tcpdump -i eth6 -s 1500 -XX 'ether proto 0x88cc') and pktcap-uw under vSphere (pktcap-uw --uplink vmnic1 --ethtype 0x88cc -c 1) never output any frames.

Hello,

after the update to Windows 10 (x64, Build 10240) the creation of a teaming group (static or IEEE802.3ad) with a I211+I217-V NIC fails.

Drivers have been upgraded to the latest version available and multiple reinstallations with reboots din't help either. Whenever the group creation wizzard is used and a groupname (several tried), the adapters and LACP have been selected, a Windows pop-up appears to tell me group creation has failed.

However the Windows Device Manager shows a newly created "Intel Advanced Network Services Virtual Adapter", so some kind of configuration seems to get done.

Using Windows 7 SP1 x64 the exact same setup worked flawlessly for months, so Win10/the driver are the likely culprit.

Is anyone experiencing similar problems and/or is this a known bug? Feedback on this issue is greatly appreciated.

Thanks in advance!

Kind regards,

Famaku

Hi,

I have read somewhere that Intel is NOT (directly) responsible for whatever Intel driver Microsoft is pushing through Windows update.

However I would like to ask a question, after a bit of context.

I have business laptop configured Windows 7 Enterprise, x64, SP 1:

     Microsoft Windows [Version 6.1.7601]

absolutely up to date.

The wired network is built with

     "Intel® Ethernet Connection (2) I219-LM"

so I have installed latest version of

     "Intel® Network Adapter Driver for Windows 7 / ProWin64.exe"

which is Version:21.1 (Latest)Date:10/11/2016

the specific version on the file driver as shown in Device Manager being:  12.15.23.7 dated 07/26/2016

So far so good.

Then why Microsoft Windows Update for Windows 7 keeps pushing a obsolete driver dated November 2015 update with the following description:

     Intel - LAN, LAN (Server) - Intel(R) Ethernet Connection (2) I219-LM

     Download size: 731 KB

     You may need to restart your computer for this update to take effect.

     Update type: Optional

     Intel LAN, LAN (Server) software update released in November, 2015

I mean even if it is optional, what is the point ? because it is definitely confusing.

What do you think ?

Please advise.

Hassan

Hello,

I am trying to control precisely packet spacing on an Intel X710 NIC using DPDK i40e poll mode driver. To do so i just try the naive way : the software loop asks for a packet burst of 1 packet every 10us (i'm working around 1 Gbps with packets of size 1400). But what i'm seeing on the other side is bursts of around 10 packets (precisely around 9 packets spaced by ~2us, then 1 spaced by ~100us).

I have also tried to push more packets each time, using 5 packets bursts and spacing calls by 50us, but the result seems to be the same.

I know that controlling packet gap in software can be tricky, but i was wondering if anyone had some ideas on how to improve the behaviour (i could be very happy with bursts of 3-4 packets spaced by 30-40us).

I have also read this paper on the subject : https://www.net.in.tum.de/fileadmin/bibtex/publications/papers/MoonGen_IMC2015.pdf  but sadly i cannot use tx queue rate control on i40e (only available on ixgbe), so i can't tell if this could be a solution. I am currently evaluating the "fill gaps with bad packets" solution, but it is more a dirty hack to me than a proper solution.

Finally, i am not familiar on how the NIC is supposed to behave on the matter. Maybe this NIC is not ideal for what i'm trying to do, and an other one could be better.

Any advice is welcome

Thanks

Sylvain