Hi,

We have 82579 Gigabit Ethernet Controller with our host CPU(x86). We are facing issue on eth0/eth1 of host not coming up sometimes after power cycling on Host.

We have come across errata for the same as per 82579_Errata.png attached by me. It is said that driver version 15.6 had this known issue which is fixed in 15.7.1

As per my understanding this versions are for windows drivers for e1000e, In our system we are using Redhat Scientific Linux with driver version for e1000e as 3.1.0.2

Can some one confirm whether 3.1.0.2 version of e1000e driver includes fix mentioned for 15.7.1 or not?

Regards,

Chandradhar Raval

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

my specs

Intel(R) 82579LM Gigabit Network Connection

windows 7 SP1 32bit + lastest windows update

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

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'm unable to easily get this information. It is working remote sever in the datacenter.

I just want to pay attention that your nvmupdate64e application doesn't work correctly on recent FreeBSD versions.

And this should not depend from serial number, application should print error message in case of unsupported vendor or device id,

but it should not dump core with segmentation fault.

Also, I want to note that nvmupdate64e does try to load nonexistent /boot/kernel/iqvfreebsd.ko kernel module. Maybe this is important.

24115 kldload  NAMI  "/boot/kernel/iqvfreebsd.ko"

24115 kldload  RET   kldload -1 errno 2 No such file or directory

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.

Greetings,

A recently acquired motherboard has an on-board Intel i219-V NIC. Within a fresh Win7 Pro SP1 x64 install with latest Intel drivers (driver v12.15.23.1, PROSet v21.0.504.0), I am experiencing stability issues with this NIC when a specific combination of factors are met:

1. NIC is set to any Link Speed above 10Mbps Full Duplex (100M-Full, 1G-Full, & Auto Negotiate)

2. Steam (the application from Valve) is downloading application and/or game updates

Basically once Steam starts its updates and reaches about 1MB/s transfer rate, the link drops and the whole computer loses its network connection (LAN and WAN) - all LAN ARP entries are flushed, cannot ping local gateway router, Windows shows the little yellow triangle over the network icon (link but no L2/L3, self-assigned 169 address)

Once this issue occurs, it is resolvable in only two ways:

- Reboot the computer

- Change the Link Speed settings under the NIC's Device Properties page in Device Manager. It doesn't matter what I set it to, just the action of re-setting this parameter is enough to re-negotiate the link again, it seems.

The only workaround that I've found so far is to manually set the NIC Link speed to 10Mbps Full - the NIC is stable (albeit much slower) in this configuration.

Other Troubleshooting & Notes:

- No other application or traffic type seems to result in this behavior. For example, speed tests, iperf tests, torrent, etc all max out my WAN (not LAN) with ease, without the NIC dropping the link

- Replaced relevant CAT6 patch cables (all test good as well)

- Tested different port on LAN switch (NIC is connected directly to an enterprise HP ProCurve switch)

- Tested with switchport speed/duplex settings always matching NIC Link Speed settings (100M-Full, 10M-Full, etc)

Edit: I tested with a USB3.0 Ethernet adapter, and Steam has no issues maxing out the ISP without the link dropping. All other equipment is the same and configured the same.

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

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

What is the specific functionality of a PF(Physical Function)  in SR-IOV ? Also what is the difference between virtual function and a physical function ? Does the VF communicate with a PF during the transfer of a packet from the VM ?@

I want to change I350 PCIe  link speed to Gen1 from EEPROM but I don't know address, who can 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!

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

Hello!

I have a problem with running X710-DA2 on my servers. When I try to load the i40e driver it crashes. It happened on a stock fw, drivers, etc. and on the upgraded versions too.

Platform: Supermicro X9DRW with dual Intel(R) Xeon(R) CPU E5-2620, latest BIOS

OS: Ubuntu 16.04.1 LTS, linux 4.4.0-57

NIC firmware: fw 5.0.40043 api 1.5 nvm 5.04 0x800024c6 0.0.0 (latest)

i40e driver: 1.5.25 (latest, downloaded and compiled)

Modules installed: GBC Photonics SP-MM85030D-GP -SFP+

dmesg:

Jan  3 18:01:58 ceph6 kernel: [  739.510036] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 1.5.25

Jan  3 18:01:58 ceph6 kernel: [  739.510041] i40e: Copyright(c) 2013 - 2016 Intel Corporation.

Jan  3 18:01:58 ceph6 kernel: [  739.527324] i40e 0000:04:00.0: fw 5.0.40043 api 1.5 nvm 5.04 0x800024c6 0.0.0

Jan  3 18:01:58 ceph6 kernel: [  739.765165] i40e 0000:04:00.0: MAC address: 3c:fd:fe:a2:19:54

Jan  3 18:01:58 ceph6 kernel: [  739.789909] i40e 0000:04:00.0: AQ command Config VSI BW allocation per TC failed = 14

Jan  3 18:01:58 ceph6 kernel: [  739.789912] i40e 0000:04:00.0: Failed configuring TC map 255 for VSI 390

Jan  3 18:01:58 ceph6 kernel: [  739.789915] i40e 0000:04:00.0: failed to configure TCs for main VSI tc_map 0x000000ff, err I40E_ERR_INVALID_QP_ID aq_err I40E_AQ_RC_EINVAL

Jan  3 18:01:59 ceph6 kernel: [  739.833189] divide error: 0000 [#1] SMP

Jan  3 18:01:59 ceph6 kernel: [  739.833324] Modules linked in: i40e(OE+) vxlan ip6_udp_tunnel udp_tunnel intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni

_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper input_leds joydev sb_edac cryptd serio_raw edac_core ipmi_si mei_me 8250_fintek mei ipmi_msghandler shpchp ioatdma lpc_ich mac_hid autofs4 hid_generic usbhid hid psmouse isci

igb ahci libsas libahci dca ptp scsi_transport_sas megaraid_sas pps_core i2c_algo_bit wmi fjes

Jan  3 18:01:59 ceph6 kernel: [  739.835034] CPU: 0 PID: 2386 Comm: insmod Tainted: G           OE   4.4.0-57-generic #78-Ubuntu

Jan  3 18:01:59 ceph6 kernel: [  739.835306] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0c 03/24/2014

Jan  3 18:01:59 ceph6 kernel: [  739.835518] task: ffff880868b9f000 ti: ffff88046c1c0000 task.ti: ffff88046c1c0000

Jan  3 18:01:59 ceph6 kernel: [  739.835754] RIP: 0010:[<ffffffffc03a4faf>]  [<ffffffffc03a4faf>] i40e_pf_config_rss+0x1ef/0x230 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.836059] RSP: 0018:ffff88046c1c37a0  EFLAGS: 00010246

Jan  3 18:01:59 ceph6 kernel: [  739.836227] RAX: 0000000000000000 RBX: ffff88086bd33c00 RCX: 0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.836452] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000200

Jan  3 18:01:59 ceph6 kernel: [  739.836679] RBP: ffff88046c1c3808 R08: ffff88046fc1a120 R09: ffff88046f8032c0

Jan  3 18:01:59 ceph6 kernel: [  739.836904] R10: ffff88086bd33c00 R11: 0000000000000000 R12: 0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.837130] R13: ffff88046da74008 R14: ffff88046c099000 R15: ffff88046da74000

Jan  3 18:01:59 ceph6 kernel: [  739.837359] FS:  00007f5815768700(0000) GS:ffff88046fc00000(0000) knlGS:0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.837615] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

Jan  3 18:01:59 ceph6 kernel: [  739.837796] CR2: 00007fe8a4fcc13c CR3: 000000046a7f2000 CR4: 00000000000406f0

Jan  3 18:01:59 ceph6 kernel: [  739.838022] Stack:

Jan  3 18:01:59 ceph6 kernel: [  739.838085]  0000000000000005 00000000001c0ac0 00000000000e0000 ffff88046c1c37e8

Jan  3 18:01:59 ceph6 kernel: [  739.838335]  ffffffffc03b9e39 ffff88046da74f28 ffff88046da74008 00000000ffd84a52

Jan  3 18:01:59 ceph6 kernel: [  739.847061]  ffff88046da74000 0000000000000000 ffff88046da74008 0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.855800] Call Trace:

Jan  3 18:01:59 ceph6 kernel: [  739.864529]  [<ffffffffc03b9e39>] ? i40e_write_rx_ctl+0x39/0x90 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.873487]  [<ffffffffc03a7ba8>] i40e_setup_pf_switch+0x308/0x590 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.882566]  [<ffffffffc03ab5c0>] i40e_probe.part.58+0xd50/0x1be0 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.891572]  [<ffffffff813fcbdd>] ? radix_tree_lookup+0xd/0x10

Jan  3 18:01:59 ceph6 kernel: [  739.900540]  [<ffffffff810da827>] ? irq_to_desc+0x17/0x20

Jan  3 18:01:59 ceph6 kernel: [  739.909424]  [<ffffffff810de48e>] ? irq_get_irq_data+0xe/0x20

Jan  3 18:01:59 ceph6 kernel: [  739.918278]  [<ffffffff81057695>] ? mp_map_pin_to_irq+0xb5/0x300

Jan  3 18:01:59 ceph6 kernel: [  739.927153]  [<ffffffff814b55cc>] ? acpi_ut_remove_reference+0x2e/0x31

Jan  3 18:01:59 ceph6 kernel: [  739.936072]  [<ffffffff811ed69b>] ? __slab_free+0xcb/0x2c0

Jan  3 18:01:59 ceph6 kernel: [  739.944972]  [<ffffffff81057e98>] ? mp_map_gsi_to_irq+0x98/0xc0

Jan  3 18:01:59 ceph6 kernel: [  739.953757]  [<ffffffff8104f72e>] ? acpi_register_gsi_ioapic+0xbe/0x180

Jan  3 18:01:59 ceph6 kernel: [  739.962466]  [<ffffffff81495726>] ? acpi_pci_irq_enable+0x1bf/0x1e4

Jan  3 18:01:59 ceph6 kernel: [  739.971114]  [<ffffffff817058c8>] ? pci_conf1_read+0xb8/0xf0

Jan  3 18:01:59 ceph6 kernel: [  739.979739]  [<ffffffff817093e3>] ? raw_pci_read+0x23/0x40

Jan  3 18:01:59 ceph6 kernel: [  739.988340]  [<ffffffff8143bc3c>] ? pci_bus_read_config_word+0x9c/0xb0

Jan  3 18:01:59 ceph6 kernel: [  739.996976]  [<ffffffff81444ced>] ? do_pci_enable_device+0xdd/0x110

Jan  3 18:01:59 ceph6 kernel: [  740.005459]  [<ffffffff81446104>] ? pci_enable_device_flags+0xe4/0x130

Jan  3 18:01:59 ceph6 kernel: [  740.013867]  [<ffffffffc03ac46e>] i40e_probe+0x1e/0x30 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  740.022228]  [<ffffffff81447585>] local_pci_probe+0x45/0xa0

Jan  3 18:01:59 ceph6 kernel: [  740.030571]  [<ffffffff814489c3>] pci_device_probe+0x103/0x150

Jan  3 18:01:59 ceph6 kernel: [  740.038806]  [<ffffffff8155a7a2>] driver_probe_device+0x222/0x4a0

Jan  3 18:01:59 ceph6 kernel: [  740.046946]  [<ffffffff8155aaa4>] __driver_attach+0x84/0x90

Jan  3 18:01:59 ceph6 kernel: [  740.055009]  [<ffffffff8155aa20>] ? driver_probe_device+0x4a0/0x4a0

Jan  3 18:01:59 ceph6 kernel: [  740.063118]  [<ffffffff815583cc>] bus_for_each_dev+0x6c/0xc0

Jan  3 18:01:59 ceph6 kernel: [  740.071205]  [<ffffffff81559f5e>] driver_attach+0x1e/0x20

Jan  3 18:01:59 ceph6 kernel: [  740.079029]  [<ffffffff81559a9b>] bus_add_driver+0x1eb/0x280

Jan  3 18:01:59 ceph6 kernel: [  740.086629]  [<ffffffffc01ea000>] ? 0xffffffffc01ea000

Jan  3 18:01:59 ceph6 kernel: [  740.093977]  [<ffffffff8155b3b0>] driver_register+0x60/0xe0

Jan  3 18:01:59 ceph6 kernel: [  740.101076]  [<ffffffff81446eac>] __pci_register_driver+0x4c/0x50

Jan  3 18:01:59 ceph6 kernel: [  740.107997]  [<ffffffffc01ea0a6>] i40e_init_module+0xa6/0x1000 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  740.114831]  [<ffffffff81002123>] do_one_initcall+0xb3/0x200

Jan  3 18:01:59 ceph6 kernel: [  740.121523]  [<ffffffff811ecbd3>] ? kmem_cache_alloc_trace+0x183/0x1f0

Jan  3 18:01:59 ceph6 kernel: [  740.128183]  [<ffffffff8118d9f3>] do_init_module+0x5f/0x1cf

Jan  3 18:01:59 ceph6 kernel: [  740.134706]  [<ffffffff8110a98f>] load_module+0x166f/0x1c10

Jan  3 18:01:59 ceph6 kernel: [  740.141064]  [<ffffffff81106f30>] ? __symbol_put+0x60/0x60

Jan  3 18:01:59 ceph6 kernel: [  740.147352]  [<ffffffff81214760>] ? kernel_read+0x50/0x80

Jan  3 18:01:59 ceph6 kernel: [  740.153662]  [<ffffffff8110b174>] SYSC_finit_module+0xb4/0xe0

Jan  3 18:01:59 ceph6 kernel: [  740.159956]  [<ffffffff8110b1be>] SyS_finit_module+0xe/0x10

Jan  3 18:01:59 ceph6 kernel: [  740.166220]  [<ffffffff818374f2>] entry_SYSCALL_64_fastpath+0x16/0x71

Jan  3 18:01:59 ceph6 kernel: [  740.172496] Code: 40 5b 41 5c 41 5d 41 5e 41 5f 5d c3 41 0f b7 be a8 04 00 00 31 c9 41 0f b7 b6 aa 04 00 00 66 85 ff 0f 84 5a ff ff ff 89 c8 31 d2 <66> f7 f6 88 14 0b 48 83 c1 01 66 39 cf 77 ed e9 42 ff ff ff 4c

Jan  3 18:01:59 ceph6 kernel: [  740.185825] RIP  [<ffffffffc03a4faf>] i40e_pf_config_rss+0x1ef/0x230 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  740.192377]  RSP <ffff88046c1c37a0>

Jan  3 18:01:59 ceph6 kernel: [  740.215988] ---[ end trace ab2ce900f55f1c7a ]---

After that one of the interfaces appears in the system, but it's unaccesible:

root@ceph6:~# ip link set up eth2

RTNETLINK answers: Invalid argument

Kind regards,

Dominik

Further design support with the implementation of mulitple Intel i210 NICs on a system board.

The design has x3 i210 devices. One i210 is on the system CPU module (E3875 Intel Baytrail). The other x2 i210 devices are on the system carrier board.

I can only able operate x2 i210 device simultaneously(x1 on the CPU and x1 on the carrier board). When a 3^rd i210 is enabled the device manager shows an exclamation mark.

I do not have a hardware issue as I have tested all the devices independently.  Each device as its own PCI lane. I have tried different configuration modes for the i210’s. ie. Configured all with 1533 device ID. Configured x2 as 157B device ID and 3^rd as device ID 1533. Configured x2 as 1533 device and the other as 157B.

Do I need to change the device, sub device ID for one of the i210 on the carrier board? If so how do I change the device ID

Please let me know if further detail is required.

Thanks

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 are bringing up a new board with an XL710.

Need eeupdate/lanconf or whatever is now being used to program these.

Is the NVMupdate all that is needed?

What about the image file?

We've done 82576 and i210s in the past, has the process changed?

Thanks

21.1 drivers did not help

- other party says link up no matter what - any clue ?

Thanks

Lior

Hi,

we are currently using 3 I210 MACs on a Windows embedded compact 2013 system. We found the driver package EmbProSw12.exe from December 19, 2014.

Is this the latest driver package? I saw there were several updates for e.g. Linux. Is there also any newer WEC 2013 driver?

Hi,

I have few clarifications on the Receive side scaling (RSS) setting in a Windows 7 OS. I want to disable the RSS because it gives some performance issues, so executed the command "netsh int tcp set global rss=disabled" and when I checked at the Network adapter properties, I still see the Recieve side scaling is enabled.

1. I would like to understand the difference between setting the RSS disabled using the command and disabling the same using the Network adapter properties. (How it works, which takes priority)

2. Is there any known issues if the RSS is disabled using the command line.

please share any info on this topic.

Appreciate your help!

Regards,

Prabu