After a day and a half of troubleshooting why my NIC was showing down in VMware ESXi 6 even though it had green lights on both ends of the fiber and my Cisco 8500 switch said the circuit was up-up, I finally found the answer.

Gee, the Cisco SFP-10G-LRM SFP+ module I use throughout my network isn't compatible in the Intel NIC.  Apparently I need an Intel E10GSFPLR SFP+ module in the NIC. 

Of course this should work with the SFP-10G-LRM on one end and the E10GSFPLR on the other end, but can anyone verify this?

I have a machine on Windows 10 that according to device manager is using the Intel(R) 82578DM Gigabit Network Connection.

The problem I have is that according to LatencyMon the ndis.sys and tcpip.sys drives are showing extremely large amounts of latency. This means everytime I refresh a web page my machine locks up for a split second and any audio or video currently playing stutters really heavily.

I've tried updating the drivers to no avail. At present device manager is showing the driver version as 12.12.50.6 provided by Microsoft.

I've tried downloading some drivers from the Intel website but those get to the "Copying drivers" stage and then fails stating that there were no Intel adapters found. This has confused me a lttile since device manager lists it as an Intel adapter.

Would massively appreciate it if someone could assist in resolving this issue.

Thanks.

Hello,

We bought 6 new laptops with an I218-LM Ethernet card. (Dell Latitude E5540).

Everything works fine, excepted when the user is resuming from sleep mode or hibernation.

Using Wireshark, the PC is effectively trying to renew it's DHCP lease; our DHCP server is offering a lease, with no effect, and after 2 minutes, the NIC takes an APIPA address.

User have to disable and enable the card to get an IP back.

After some investigation, the problem occurs after installing SEP with NTP (firewall) feature, but we cannot find any event in the firewall log stating that something was blocked.

Of course, Symantec blames Intel's drivers....

I've tried every driver that was released recently, from the Dell and Intel websites, with no success.
I've tried to disable "Energy efficient Ethernet".

Going through Symantec support, I found this post which helped me somehow : http://www.symantec.com/connect/forums/sep-firewall-blocking-dhcp-request-i-think-after-sleep-or-hibernation

I've uninstalled the tools for the card management and reinstalled the driver alone (using the one that was unzipped in the temp folder).

It works if I uncheck the "Allow the computer to turn off this device to save power" box.

As my case is lost in Dell's infernal call centre loop, (they are replacing the motherboards every 2 weeks or asking me to reinstall the OS), I was wondering if you were aware of such issues with theses NIC's.

OS= Windows 7 x64 Pro SP1

Symantec=12.1.4013.4013

Drivers tested: original one (from 07/2013), 12.11.77.0, 12.11.96.1

Thanks for your attention!

Kr,

Sagouain

I have old drivers from 2011 and want to update them

But can I safely remove them, eg system driver:

Intel(R) 6 Series/C200 Series Chipset Family PCI Express Root Port 1 - 1C10

and many others like it?

I've first removed network adapter driver which was also from 2011 and update that succesfully to latest version.

Now only the chipset, which installs fine on its own but through the update utlity it fails.

Hi,

some time ago I tried using Intel i350 with Debian Wheezy:

yyyy@xxxx:~/igb-5.2.9.4/src$ uname -a

Linux xxxx 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux

yyyy@xxxx:/home/yyyy/igb-5.2.9.4/src# modinfo igb

filename:       /lib/modules/3.2.0-4-amd64/kernel/drivers/net/igb/igb.ko

version:        5.2.9.4

license:        GPL

description:    Intel(R) Gigabit Ethernet Network Driver

author:         Intel Corporation, <e1000-devel@lists.sourceforge.net>

srcversion:     E377200391EBF74638FEDA2

yyyy@xxxx:/home/yyyy/igb-5.2.9.4/src# ip -V

ip utility, iproute2-ss140804

I was using bonding in 802.3ad mode for bonding with an Extreme-Networks switch. I had 2 similar servers, with identical configuration. Old one was using old e1000 interfaces with 802.3ad bonding, l3+l4 hash. New one was using I350-T2 dual port adapter with the same configuration. No Virtual Machines. Issue was on I350 around 20% packets to/from some random source/destination IPs were dropped. Servers were actually cloned so I'm certain there was no misconfiguration. I've tried disabling anti spoof check (https://communities.intel.com/message/192668#192668) but no luck, it doesn't work on my iproute2 and kernel (has this been fixed yet?). Any hints how to compile driver without anti spoof? Did anyone experienced similar symptoms?

In the end the fix was not to use bonding at all. While using 2 separate ports on this I350-T2 adapter, with the same VLANs, the same IPs - everything works flawless. This is why I assume a problem with igb driver on I350-T2 using bonding (with VLANs).

UPDATE: actually I've found Latest Flexible Port Partitioning Paper is now available.  Learn about QoS and SR-IOV! which confirms there's an issue with 802.3ad. Can anyone give me a hint how to compile igb driver without anti spoofing feature?

Regards,

Wiadomość była edytowana przez: Bartek Krawczyk

Hi all,

I've installed FreeBSD 10.2-STABLE on a server with 2*CPU E5-2643v3 (with HyperThreading on) and Intel XL710 4*10G SFP+ card.

At first I updated FreeBSD drivers to 1.4.0 (from download.intel.com).

I see next strange thing - Every acive ixl interface creates 24 queues (6 core *2 (HT) *2 CPU) but uses only 16-17 of them:

irq284: ixl0:q0                164383663       1941

irq285: ixl0:q1                371238730       4384

irq286: ixl0:q2                378286557       4468

irq287: ixl0:q3                365073427       4312

irq288: ixl0:q4                371116376       4383

irq289: ixl0:q5                372589584       4400

irq290: ixl0:q6                361879025       4274

irq291: ixl0:q7                354607200       4188

irq292: ixl0:q8                223602267       2641

irq293: ixl0:q9                199067474       2351

irq294: ixl0:q10               212598000       2511

irq295: ixl0:q11               202534854       2392

irq296: ixl0:q12               212050675       2504

irq297: ixl0:q13               209106917       2469

irq298: ixl0:q14               201452403       2379

irq299: ixl0:q15               203896634       2408

irq300: ixl0:q16                76328643        901

irq301: ixl0:q17                    6030          0

irq302: ixl0:q18                    5433          0

irq303: ixl0:q19                    6804          0

irq304: ixl0:q20                    6098          0

irq305: ixl0:q21                    6603          0

irq306: ixl0:q22                    6476          0

irq307: ixl0:q23                    7141          0

irq309: ixl1:q0                161169757       1903

irq310: ixl1:q1                402042077       4748

irq311: ixl1:q2                399166615       4714

irq312: ixl1:q3                389702886       4602

irq313: ixl1:q4                383371508       4528

irq314: ixl1:q5                388621686       4590

irq315: ixl1:q6                385533771       4553

irq316: ixl1:q7                390478220       4612

irq317: ixl1:q8                232313544       2743

irq318: ixl1:q9                248387076       2933

irq319: ixl1:q10               233942388       2763

irq320: ixl1:q11               237794942       2808

irq321: ixl1:q12               227292626       2684

irq322: ixl1:q13               222151566       2623

irq323: ixl1:q14               234209020       2766

irq324: ixl1:q15               217878026       2573

irq325: ixl1:q16                80177041        947

irq326: ixl1:q17                      83          0

irq327: ixl1:q18                      74          0

irq328: ixl1:q19                     201          0

irq329: ixl1:q20                      98          0

irq330: ixl1:q21                      95          0

irq331: ixl1:q22                      91          0

irq332: ixl1:q23                      87          0

# top -aSCHP

last pid: 28661;  load averages:  7.06,  6.35,  6.23                                                                                                                                                                      up 0+23:35:07  17:15:12

391 processes: 31 running, 215 sleeping, 145 waiting

CPU 0:   0.0% user,  0.0% nice,  0.0% system, 39.4% interrupt, 60.6% idle

CPU 1:   0.0% user,  0.0% nice,  0.0% system, 48.8% interrupt, 51.2% idle

CPU 2:   0.0% user,  0.0% nice,  0.0% system, 42.1% interrupt, 57.9% idle

CPU 3:   0.0% user,  0.0% nice,  0.0% system, 40.2% interrupt, 59.8% idle

CPU 4:   0.0% user,  0.0% nice,  0.4% system, 41.3% interrupt, 58.3% idle

CPU 5:   0.0% user,  0.0% nice,  0.0% system, 37.0% interrupt, 63.0% idle

CPU 6:   0.0% user,  0.0% nice,  0.0% system, 35.8% interrupt, 64.2% idle

CPU 7:   0.0% user,  0.0% nice,  0.0% system, 39.0% interrupt, 61.0% idle

CPU 8:   0.0% user,  0.0% nice,  0.0% system, 22.0% interrupt, 78.0% idle

CPU 9:   0.0% user,  0.0% nice,  0.0% system, 26.0% interrupt, 74.0% idle

CPU 10:  0.0% user,  0.0% nice,  0.0% system, 17.7% interrupt, 82.3% idle

CPU 11:  0.0% user,  0.0% nice,  0.0% system, 19.3% interrupt, 80.7% idle

CPU 12:  0.0% user,  0.0% nice,  0.4% system, 25.2% interrupt, 74.4% idle

CPU 13:  0.0% user,  0.0% nice,  0.0% system, 23.6% interrupt, 76.4% idle

CPU 14:  0.0% user,  0.0% nice,  0.0% system, 22.4% interrupt, 77.6% idle

CPU 15:  0.0% user,  0.0% nice,  0.0% system, 26.8% interrupt, 73.2% idle

CPU 16:  0.0% user,  0.0% nice,  1.2% system,  1.6% interrupt, 97.2% idle

CPU 17:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle

CPU 18:  0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle

CPU 19:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle

CPU 20:  0.0% user,  0.0% nice,  3.5% system,  0.0% interrupt, 96.5% idle

CPU 21:  0.0% user,  0.0% nice,  1.6% system,  0.0% interrupt, 98.4% idle

CPU 22:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle

CPU 23:  0.0% user,  0.0% nice,  2.0% system,  0.0% interrupt, 98.0% idle

# netstat -I ixl0 -w1 -h

            input           ixl0           output

   packets  errs idrops      bytes    packets  errs      bytes colls

      235K     0     0       126M       300K     0       321M     0

      233K     0     0       114M       297K     0       312M     0

      232K     0     0       116M       300K     0       315M     0

      227K     0     0       108M       297K     0       316M     0

Where is the source of problem that network adapter doesn't utilize all queues ?

Hi there, I have an HP EliteDesk 800 G1 PC with I217-LM connected with Cisco Catalyst X-series Gigabit switch. I am configuring WOL feature. It seems like WOL doesn't work if switchport configured as speed 1000/duplex full, same as NIC. The only way I used to make it work - configure autonegotiation of speed and duplex or 100Mbit/s Full Duplex on the two sides (switchoprt and NIC) of connection. Does anyone know how it works when Intel NIC is in the WOL mode, how to debug ethernet events? Why 100 Mbit/s Full Duplex, not least possible speed? I want WOL working as i configure 1000Mbits/s Full Duplex on the two sides of connection. I tried turning off EEE, Reduce link speed and other Power Management features - with no success.

Hello

I have an old Dell Vostro 400 computer that I recently upgraded from Windows XP to Windows 7 (I know I’m a little behind the times!). Everything has been working fine except that I keep losing the internet connection.

The network adapter is an Intel 82562V-2 10/100.

I have downloaded the Intel update adviser but it tells me that I already have the most up to date drivers. I have found a page on the Intel site with some drivers for Windows 7 but I have no idea which one would be right and I cannot see my adapter mentioned there.

I would be grateful for any advice!

Hi,

I have an Asus P8Z77-V mother board with the stated NIC. The latest drivers are installed: Intel Pro Set Version 17.0.200.2, Driver Version 11.16.96.0. I also have the latest BIOS.

I must force my NIC to 10 Mb/s (half or full duplex works) in order for it to recongnize any connection at all. Auto-negotiate and 1 Gb/s yield no connection at all, and the 100 Mb/s setting yeilds a cycle of connects and disconnects and an unresponsive system. (Sometimes my Display Adapter driver drops out durring this, too.) A connection with a D-Link router seemed to work fine, but a connection to an old Linksys router or to my apartment's ethernet jack (managed by Korcett/SuddenLink) yields the stated problem. My NIC from my previous motherboard works fine, and I have tried multiple Cat 5 cables and recently a Cat 5e cable with the same result.

Hi,

It is regarding H/W Time Stamping features of XL710 40G NIC.

We are going to use XL710-QDA2(40G)  MOQ  - Intel® Ethernet Converged Network Adapter Dual Port Network Adapter.

We have a requirement that each RX packet(All Traffic) should be appended with H/W Time Stamp. Is it possible with this model?

From the DATA sheet, my understanding is it support IEEE 1588/PTP Time Synchronization and there is no support "Per-Packet Time Stamp" feature.

Here are my queries:

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

1. Is XL710 NIC supports Per-Packet H/W Time Stmaping(All RX Packets should be time stamped)?

2. In case if XL710 not supporting Per-Packet Time Stamp, is there any other mechanism/way to achieve the same from H/W level?

Pleas help me if in this regard.

Regards,

suresh.

Hi,

I updated NVM and used qcu for configuring Intel XL710QDA2 to 4x10 mode.

This adapter has two 40Gb ports.

However the qcu displayed that the adapter doesn’t support configuration modification as below.

How can I config to support 4x10 mode with this adapter?

Thanks,

Iris

I'd like to set up Intel XL710

[root@centos12 Linux_x64]# ethtool -i eth8

driver: i40e

version: 1.3.47

firmware-version: 4.42 0x80001932 0.0.0

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@centos12 Linux_x64]#

[root@centos12 qcu]# ./qcu64e /devices

Intel(R) QSFP+ Configuration Utility

QCU version: v1.24.35.01

Copyright(C) 2015 by Intel Corporation.

Software released under Intel Proprietary License.

NIC B:D   Ven-Dev   Mode   Adapter Name

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

1) 08:00 8086-1583 N/A    Intel(R) Ethernet Converged Network Adapter XL710-Q2

[root@centos12 qcu]# ./qcu64e /nic=1 /info

Intel(R) QSFP+ Configuration Utility

QCU version: v1.24.35.01

Copyright(C) 2015 by Intel Corporation.

Software released under Intel Proprietary License.

QSFP+ Configuration modification is not supported by this adapter.

[root@centos12 qcu]#

I have HP Laptop i installed windows 8 and All my windows 7 drivers are working well on it except Intel 82566MM Network Card when i put my lan cable in it the system gone be mad alot of loss in packets and the device is laggy some times it gave me death screen i do all the trouble shooting for network and installed the update in compatibility mode for windows 7 nothing is worth it's driver problem as when i put the laptop battery mod to maximum performance some times it working well i do clean install and the same thing and tried to upgrade from windows 7 the same thing please suggest a working solution !!!!

Hello,

We bought 6 new laptops with an I218-LM Ethernet card. (Dell Latitude E5540).

Everything works fine, excepted when the user is resuming from sleep mode or hibernation.

Using Wireshark, the PC is effectively trying to renew it's DHCP lease; our DHCP server is offering a lease, with no effect, and after 2 minutes, the NIC takes an APIPA address.

User have to disable and enable the card to get an IP back.

After some investigation, the problem occurs after installing SEP with NTP (firewall) feature, but we cannot find any event in the firewall log stating that something was blocked.

Of course, Symantec blames Intel's drivers....

I've tried every driver that was released recently, from the Dell and Intel websites, with no success.
I've tried to disable "Energy efficient Ethernet".

Going through Symantec support, I found this post which helped me somehow : http://www.symantec.com/connect/forums/sep-firewall-blocking-dhcp-request-i-think-after-sleep-or-hibernation

I've uninstalled the tools for the card management and reinstalled the driver alone (using the one that was unzipped in the temp folder).

It works if I uncheck the "Allow the computer to turn off this device to save power" box.

As my case is lost in Dell's infernal call centre loop, (they are replacing the motherboards every 2 weeks or asking me to reinstall the OS), I was wondering if you were aware of such issues with theses NIC's.

OS= Windows 7 x64 Pro SP1

Symantec=12.1.4013.4013

Drivers tested: original one (from 07/2013), 12.11.77.0, 12.11.96.1

Thanks for your attention!

Kr,

Sagouain

After a day and a half of troubleshooting why my NIC was showing down in VMware ESXi 6 even though it had green lights on both ends of the fiber and my Cisco 8500 switch said the circuit was up-up, I finally found the answer.

Gee, the Cisco SFP-10G-LRM SFP+ module I use throughout my network isn't compatible in the Intel NIC.  Apparently I need an Intel E10GSFPLR SFP+ module in the NIC. 

Of course this should work with the SFP-10G-LRM on one end and the E10GSFPLR on the other end, but can anyone verify this?

Hello,

I wonder if someone can help me with a seemingly simple but elusive question. I'm looking to

make a purchase of several Cisco SFP-10G-LRM modules to support 10Gb communications over our

OS2 fibre infrastructure. All runs are less than 300m so this is cost effective compared to

using SFP-10G-LR.

On the other end of the fibre will be some servers using Intel E10GSFPLR optics at 10Gb.

My question is this - are these optics compatible for the situation I've described? I've done

some searching and can't find any definite information either way, despite these being popular

choices (I guess).

Any help is appreciated.

Thanks,

Andrew

Hi all,

I've installed FreeBSD 10.2-STABLE on a server with 2*CPU E5-2643v3 (with HyperThreading on) and Intel XL710 4*10G SFP+ card.

At first I updated FreeBSD drivers to 1.4.0 (from download.intel.com).

I see next strange thing - Every acive ixl interface creates 24 queues (6 core *2 (HT) *2 CPU) but uses only 16-17 of them:

irq284: ixl0:q0                164383663       1941

irq285: ixl0:q1                371238730       4384

irq286: ixl0:q2                378286557       4468

irq287: ixl0:q3                365073427       4312

irq288: ixl0:q4                371116376       4383

irq289: ixl0:q5                372589584       4400

irq290: ixl0:q6                361879025       4274

irq291: ixl0:q7                354607200       4188

irq292: ixl0:q8                223602267       2641

irq293: ixl0:q9                199067474       2351

irq294: ixl0:q10               212598000       2511

irq295: ixl0:q11               202534854       2392

irq296: ixl0:q12               212050675       2504

irq297: ixl0:q13               209106917       2469

irq298: ixl0:q14               201452403       2379

irq299: ixl0:q15               203896634       2408

irq300: ixl0:q16                76328643        901

irq301: ixl0:q17                    6030          0

irq302: ixl0:q18                    5433          0

irq303: ixl0:q19                    6804          0

irq304: ixl0:q20                    6098          0

irq305: ixl0:q21                    6603          0

irq306: ixl0:q22                    6476          0

irq307: ixl0:q23                    7141          0

irq309: ixl1:q0                161169757       1903

irq310: ixl1:q1                402042077       4748

irq311: ixl1:q2                399166615       4714

irq312: ixl1:q3                389702886       4602

irq313: ixl1:q4                383371508       4528

irq314: ixl1:q5                388621686       4590

irq315: ixl1:q6                385533771       4553

irq316: ixl1:q7                390478220       4612

irq317: ixl1:q8                232313544       2743

irq318: ixl1:q9                248387076       2933

irq319: ixl1:q10               233942388       2763

irq320: ixl1:q11               237794942       2808

irq321: ixl1:q12               227292626       2684

irq322: ixl1:q13               222151566       2623

irq323: ixl1:q14               234209020       2766

irq324: ixl1:q15               217878026       2573

irq325: ixl1:q16                80177041        947

irq326: ixl1:q17                      83          0

irq327: ixl1:q18                      74          0

irq328: ixl1:q19                     201          0

irq329: ixl1:q20                      98          0

irq330: ixl1:q21                      95          0

irq331: ixl1:q22                      91          0

irq332: ixl1:q23                      87          0

# top -aSCHP

last pid: 28661;  load averages:  7.06,  6.35,  6.23                                                                                                                                                                      up 0+23:35:07  17:15:12

391 processes: 31 running, 215 sleeping, 145 waiting

CPU 0:   0.0% user,  0.0% nice,  0.0% system, 39.4% interrupt, 60.6% idle

CPU 1:   0.0% user,  0.0% nice,  0.0% system, 48.8% interrupt, 51.2% idle

CPU 2:   0.0% user,  0.0% nice,  0.0% system, 42.1% interrupt, 57.9% idle

CPU 3:   0.0% user,  0.0% nice,  0.0% system, 40.2% interrupt, 59.8% idle

CPU 4:   0.0% user,  0.0% nice,  0.4% system, 41.3% interrupt, 58.3% idle

CPU 5:   0.0% user,  0.0% nice,  0.0% system, 37.0% interrupt, 63.0% idle

CPU 6:   0.0% user,  0.0% nice,  0.0% system, 35.8% interrupt, 64.2% idle

CPU 7:   0.0% user,  0.0% nice,  0.0% system, 39.0% interrupt, 61.0% idle

CPU 8:   0.0% user,  0.0% nice,  0.0% system, 22.0% interrupt, 78.0% idle

CPU 9:   0.0% user,  0.0% nice,  0.0% system, 26.0% interrupt, 74.0% idle

CPU 10:  0.0% user,  0.0% nice,  0.0% system, 17.7% interrupt, 82.3% idle

CPU 11:  0.0% user,  0.0% nice,  0.0% system, 19.3% interrupt, 80.7% idle

CPU 12:  0.0% user,  0.0% nice,  0.4% system, 25.2% interrupt, 74.4% idle

CPU 13:  0.0% user,  0.0% nice,  0.0% system, 23.6% interrupt, 76.4% idle

CPU 14:  0.0% user,  0.0% nice,  0.0% system, 22.4% interrupt, 77.6% idle

CPU 15:  0.0% user,  0.0% nice,  0.0% system, 26.8% interrupt, 73.2% idle

CPU 16:  0.0% user,  0.0% nice,  1.2% system,  1.6% interrupt, 97.2% idle

CPU 17:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle

CPU 18:  0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle

CPU 19:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle

CPU 20:  0.0% user,  0.0% nice,  3.5% system,  0.0% interrupt, 96.5% idle

CPU 21:  0.0% user,  0.0% nice,  1.6% system,  0.0% interrupt, 98.4% idle

CPU 22:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle

CPU 23:  0.0% user,  0.0% nice,  2.0% system,  0.0% interrupt, 98.0% idle

# netstat -I ixl0 -w1 -h

            input           ixl0           output

   packets  errs idrops      bytes    packets  errs      bytes colls

      235K     0     0       126M       300K     0       321M     0

      233K     0     0       114M       297K     0       312M     0

      232K     0     0       116M       300K     0       315M     0

      227K     0     0       108M       297K     0       316M     0

Where is the source of problem that network adapter doesn't utilize all queues ?

<><> Apologies if this has been posted in the wrong place <><>

Ok I'll keep this brief.

Problem:- LAN regulary disconnects and reconnets 30 seconds later.

Symptons:- Loose connection to Lan / Internet for around 30 seconds.

Background:- Had this problem with both P8P67 B2 and P8P67 pro boards. I have several other computers connected to the switch (not hub) and they are working fine. Have replaced the lead to no avail. Have even used the same lead in several other computers which works fine.

Config:-

Study

Netgear 8 port SWITCH 10/100/1000
Server
VOIP
PC

Switch connected to lounge hard wired via outdoor sheilded cat6 lead.

Lounge

Netgear 8 port SWITCH 10/100/1000
Router
XBOX 360
Wii
<><><>

Message in System Event Logs;-

<><>
Warning message - date time - source = e1cexpress
Event ID = 27

Intel 82579V Gigabit Network Connection
- Network link is disconnected
<><>

Then it states its connected again.

Have also tried the following;-

Remove Kaspersky 2011
Ensure ALL power management even OS is disabled
Use IPV4 instead of IPv6 in prefix policies
Disable nativue IPv6
Disable tunnel IPv6
Disable IPv6

netsh interface tcp set global rss=disabled
netsh interface tcp set global autotuninglevel=disabled
netsh int ip set global taskoffload=disabled

Disabled SNP;-
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters]
EnableTCPChimney=dword:00000000
EnableTCPA=dword:00000000
EnableRSS=dword:00000000

Have tried driver from Asus MB CD, Asus Website, Your Website, Windows Update all to no avail.

Please help.

Hello,

last week i tried to install Windows 10 and recognized that the actual driver from here

Download Network Adapter Driver for Windows® 10

does not support the VLAN Feature. Because i need the VLAN function it is not possible for me to use Windows 10 at the moment.

i have found another entry in the community from September (Intel 82579V issues on Windows 10) where it is said that ANS and VLAN will be supported in future releases.

Is there any suggested timeline for such a release ?

Best Regards

Sven

Is there a Windows 10 driver for Intel(R) 82578DC Gigabit Network Connection?  I have no internet access after upgrading from Windows 7 to Windows 10.

When starting on both FreeBSD and Linux the latest driver complains that the NVM should be updated.

As there's no FreeBSD NVM update utility available I got the machine temporarily booted into Linux however the updater reports:

"Update not available"

The log from an inventory run identifies the card as a dual port X710:

[02:00:00]: Intel(R) Ethernet Converged Network Adapter X710

      LAN MAC: 3CFDFE007460

      Alt MAC: 000000000000

      SAN MAC: 3CFDFE007461

      EEPROM: ETrackId: 80001867, Checksum valid

      VPD: Size: 152

      Flash: Size: 8388608, CIVD: 16.5.10

      Vendor: 8086 Device: 1572 Subvendor: 8086 Subdevice: 6 Revision: 1

          Type: PXE, Version: 1.0.10, Checksum: Not Relevant

          Type: ISCSI, Version: 3.0.44, Checksum: Not Relevant

          Type: ISCSI_SETUP, Version: 3.0.44, Checksum: Not Relevant

          Type: EFI_X64, Version: 1.1.33, Checksum: None

          Type: CLP_LOADER, Version: 3.0.30, Checksum: Valid

          Type: IMAGE_SHARED_40G, Version: 1.0.7, Checksum: Not Relevant

Looking in nvmupdate.cfg the device matches the XL710 but there's no match for EEPID which I believe corresponds to the EEPROM: EtrackID of 80001867.

So the question is where do I get the right NVM update from?

./nvmupdate64e -l update.log

Intel(R) Ethernet NVM Update Tool

NVMUpdate version 1.25.20.12

Copyright (C) 2013 - 2015 Intel Corporation.

WARNING: TO AVOID DAMAGE TO YOUR DEVICE, DO NOT EXIT OR REBOOT OR POWER OFF THE SYSTEM DURING THIS UPDATE

Inventory in progress. Please wait [*-........]

Num Description                            Device-Id B:D   Adapter Status

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

01) Intel(R) Ethernet Converged Network Ad 8086-1572 02:00 Update not available

02) Intel(R) 82574L Gigabit Network Connec 8086-10D3 03:00 Not supported

03) Intel(R) 82574L Gigabit Network Connec 8086-10D3 04:00 Not supported

Tool execution completed with the following status: All operations completed successfully

Press any key to exit.