Hello,

I recently installed an Intel X520-2 NIC to my windows server.  Windows auto-installed it and I can access the device.  It is currently working as just a regular ethernet adapter.  I need to change it to iSCSI mode.  I did some research and found that I need to use the Intel Ethernet Flash Firmware Utility.  Here is what I am currently doing:

C:\Intel21.1\APPS\BootUtil\Winx64>BOOTUTILW64E.EXE

Intel(R) Ethernet Flash Firmware Utility

BootUtil version 1.6.20.1

Copyright (C) 2003-2016 Intel Corporation

Type BootUtil -? for help

Port Network Address Location Series  WOL Flash Firmware                Version

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

  1   90E2BAC2EE98     8:00.0 10GbE   N/A PXE                           2.1.40

  2   90E2BAC2EE99     8:00.1 10GbE   N/A PXE                           2.1.40

C:\Intel21.1\APPS\BootUtil\Winx64>BOOTUTILW64E.EXE -FLASHENABLE -ALL //Set to FlashEnabled

Intel(R) Ethernet Flash Firmware Utility

BootUtil version 1.6.20.1

Copyright (C) 2003-2016 Intel Corporation

Enabling boot ROM on port 1...Success

Reboot the system to enable the boot ROM on this port

Enabling boot ROM on port 2...Success

Reboot the system to enable the boot ROM on this port

Port Network Address Location Series  WOL Flash Firmware                Version

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

  1   90E2BAC2EE98     8:00.0 10GbE   N/A Reboot Required

  2   90E2BAC2EE99     8:00.1 10GbE   N/A Reboot Required

//I HAVE REBOOTED AFTER THIS STEP AND GOT SAME RESULTS

C:\Intel21.1\APPS\BootUtil\Winx64>BOOTUTILW64E.EXE -BOOTENABLE=iscsiprimary -ALL

Intel(R) Ethernet Flash Firmware Utility

BootUtil version 1.6.20.1

Copyright (C) 2003-2016 Intel Corporation

Found discrete ROM in the flash for NIC 1

The -BOOTENABLE command can only be used on flashed combo images

Found discrete ROM in the flash for NIC 2

The -BOOTENABLE command can only be used on flashed combo images

Port Network Address Location Series  WOL Flash Firmware                Version

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

  1   90E2BAC2EE98     8:00.0 10GbE   N/A PXE                           2.1.40

  2   90E2BAC2EE99     8:00.1 10GbE   N/A PXE                           2.1.40

What is  "The -BOOTENABLE command can only be used on flashed combo images"?  I have tried to DISABLE as well and it does not take (same error message).  I must be missing something but I am not sure what.

I have tried to PXE Boot to WINPE using NIC X710. I used iPXE and wimboot, iPXE uses snp drivers and when it hands over control to windows, WinPE hangs in the windows logo.

any suggestion?

I have an extremely odd situation with BPF expressions and VLAN tagging when using ixgbe devices on CentOS 6 (this is for Network Intrusion Detection software).

I have many other CentOS 6 boxes with igb devices and I'm successfully using complex BPF expressions to match VLAN IDs and port numbers, for example:

vlan and ( ether[14:2] == 0x0005 and port 25 || ether[14:2] == 0x0006 and port 25 )

Which means: Look for packets that are VLAN tagged, where the VLAN ID is 5 and the transport protocol port number is 25, or VLAN ID is 6 and the port is 25. The is necessary due to the way BPF works, which is it will shift the byte match by 4 bytes after each occurrence of "vlan" in the expression (hence you cannot construct an expression like (vlan 5 and port 25 || vlan 6 and port 25), because the second half of the expression would only match if traffic for VLAN 6 was encapsulated inside VLAN 5). Statically using ether[a:b] will always look a-bytes deep in the packet (starting at 0) and read b-number of bytes to match. This is supposed to work regardless of whether "vlan" has occurred in the expression (making it a reliable way to find the outer VLAN ID).

So here's the problem: It doesn't work on ixgbe (at least not in promiscuous mode). When I try to match on ether[15] (the low-order bytes of the VLAN ID) it will actually match on byte 19 (the 20th byte), which mean it's shifted 4 bytes over. If I try to match on ether[11], the expression returns true when *both* byte 11 (12) AND byte 15 (16) equal the expression, which is totally bizarre. I cannot seem to make a 2-byte pattern match at all (but maybe I just didn't run tcpdump for long enough for that amazing coincidence).

By the way, I can match any other bytes normally with ether[a:b] expressions, it's only the 12-15 bytes (VLAN ethertype and VLAN ID) that have bizarre behavior.

I strongly suspect this is due to rx_vlan_offload being enabled, but when I try to disable it with ethtool I get:

$ sudo ethtool -K eth1 rx-vlan-offload off

ethtool: bad command line argument(s)

For more information run ethtool -h

This happens with both ixgbe driver version: 4.2.1-k (shipped with the CentOS kernel package), and also with version: 4.4.6 (built from source).

I found a reference to an extremely similar sounding bug here https://sourceforge.net/p/e1000/bugs/375/, but that seems to be a much earlier version of the driver. This one appears to check for RHEL_RELEASE_VERSION > 6.1 and enable 802.1P support accordingly:

#if (RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6,1))

#define HAVE_8021P_SUPPORT

#endif

So two questions:

1. How can I resolve this issue of not being able to use ether[14:2] to match VLAN ID in BPF?

2. Why can't I disable rx_vlan_offload with ethtool? (it does not say [fixed])

Message was edited by: Chort Zero

Someone on Twitter showed me 'rxvlan' is ethtool's shorthand for rx-vlan-offload, but it doesn't make any difference after disabling it.

Recently, I have had some issues with my PC that was built April 2016 and had to make some Bios changes. Before doing that, I found that my motherboard had a dual bios. The one that was not working and had to be repaired (side A) is now working but my network adapter I219-V is not. It says it needs drivers. So, I installed them from my board's manufacturer's site and that did not work. I tried the drivers from the Intel site and that did not work. I have Windows 10 Home - 64 bit. On side B of my bios, the internet works fine with this same adapter. I have been at it more than 24 hours trying to find a solution and I have come up with nothing.

In the device manager, the adapter (once the driver's were installed) has the yellow triangle and error code 10.

I'm trying to narrow down a connectivity issue with my ethernet adapter. I have an Intel(R) Ethernet Connection I217-V ethernet adapter connected to a Linksys RE6500 wireless extender. I've verified the Linksys has a full connection. The originating wireless AC signal is coming from an AT&T (Pace) 5268AC Residential Gateway. The machine is on Windows 10 64-bit with latest Anniversary Update.

Every so often at random, the connection drops and resets. I haven't been able to nail down a pattern that causes it, but it seems to happen mostly when browsing the web or connecting remotely via VNC. What's odd is that when I had it connected to an ASUS RT-AC68U via ethernet cable, it never dropped the connection, which leads me to believe it's an issue with the Linksys. I've got an open ticket with them right now, but to be sure, I want to make sure there isn't anything on my ethernet adapter settings I need to configure in order for it to work with the RE6500. Below are screenshots of the configuration and driver version, which seems to be the latest as far as I can tell.

All Power Management options are turned off on this tab:

No changes to the below settings have been made. All are set to the defaults:

I saw a few other posts where people had issues with the connection dropping, but there didn't seem to be any resolution to it. I welcome any and all assistance!

Hi,

  we have a board using a pair of i210s.  On the first run, all of our chips worked fine.  On our second run, on the first five boards tested, we have had two failures.

  The failures are roughly the same.  The i210s on the first PCIe bus work, but they identify their eeproms as a "Protected Flash" with an ID of 0xFAFA.  I have placed a CRO with an SPI decoder on the lines, and I can see the chips identifying themselves as an ID 0x2080, so I'm not sure what's going on here.  It is still able to read out values, so this is weird, but not a killer.

  The i210s on the second PCIe bus cannot find their internal PHY.  Using lanconf32 I can see that the "Raw Copper/MDIO PHY Registers" are all zero and "No PHY Found", as opposed to the other i210s which report valid data and an "Intel-M" 0x005043 PHY.

  To be clear here, three boards are fine, and two boards have issues with both of their i210s.  The same fault occurs for chips on the same PCIe bus.

  I have had a look at "General Registers (Raw)" which look pretty good:

Device Ctrl Reg    0x00000    081C0241

Ext Device Control    0x00018     001400C0

Device Status Reg    0x00008    00280780

  Compared with a working system, the Device Status Reg differs in bit 10, which indicates PHY has been reset.  This bit should be cleared by the driver.  Ext Device Control register differs in bit 29 which should be set to 1 to indicate the driver is loaded.  Most importantly, Ext Device Control bits 22 and 23 are zero, meaning the internal PHY should be in use.

  When I try and load my driver (Linux 4.4.10) the igb driver fails to load the second i210.  Following the driver's probe() function with a large number of prink()s, it all comes down to not having a valid PHY.

  I have compared the physical chips, and the markings on them are all the same, and all as I would expect.

  I have spent a couple of days trying to track this down, and I'm at a loss of what I can try now.  Any ideas are welcome.

Thanks

Scott

Hello,
We have a dual nic x520 on a hypervisor, and planning to use sr-iov and bridge as well.
Nics VF are working fine, however there is also a bridge (on a tagged vlan) on that host and the machines behind sr-iov vf cannot talk to machine in the bridge.
I turned off mac spoofing to no avail....

This is Centos 7.2 with all updates.
The reason for this is that not all machines require sr-iov functions/maintenance so some of them are used classically with a vnet on bridge.
Both machines (vf and bridged) are in the same vlan, I did a tcpdump session and I can see it does an ARP request but no reply

Any help would be appreciated, thank you

I have one issue, at customer machine the user space process is hogging up the processor (soft lockup)along with 2 kernel process and dump stack trace showing RIP at _ticket_spin_lock in all 3 process.

As i know "If an user-space process had caused the soft-lockup, a line identifying the process by its pid would logged, followed by the contents of various CPU-registers without a call-trace of any sorts" but in my case i am getting dump stack trace for user process too.

is it coming from a misbehaving user space app? is it normal functionality of soft lockup? if is it functionality of soft lockup then how to resolve the issue?

Any help will be highly appreciated.

it is x86_64 machine and kernel is 3.1.10. I know all 3 process are waiting for _ticket_spin_lock. see :-


Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492033] BUG: soft lockup - CPU#3 stuck for 22s! [virtio_shm/5/3:7874]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404215] BUG: soft lockup - CPU#31 stuck for 23s! [kni_thread:6605]
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172014] BUG: soft lockup - CPU#0 stuck for 22s! [gis:14145]



i thing problem in igb driver!! Because gis anf kni_thread both had igb driver logs

Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492033] BUG: soft lockup - CPU#3 stuck for 22s! [virtio_shm/5/3:7874]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492036] Modules linked in: xt_sharedlimit xt_hashlimit ip_set_hash_ipport ip_set_hash_ipportip xt_NOTRACK ip_set_bitmap_port xt_sctp nf_conntrack_ipv6 nf_defrag_ipv6 xt_CT arpt_mangle ip_set_hash_ipnet xt_NFLOG xt_limit xt_hashcounter ip_set_hash_ipip xt_set ip_set_hash_ip deflate ctr twofish_x86_64 twofish_common camellia serpent blowfish cast5 des_generic cbc xcbc rmd160 crypto_null af_key iptable_mangle ip_set arptable_filter arp_tables iptable_raw iptable_nat nfnetlink_log nfnetlink ipt_ULOG ipt_PORTMAP af_packet zlib zlib_deflate sha512_generic sha256_generic sha1_generic md5 icp_qa_al pcie8120 rte_kni pfe_pep virtio_rte virtio_shm virtio_vtnet virtio_uio igb_uio virtio_ring virtio uio xt_tcpudp xt_state xt_pkttype nf_conntrack_control bonding binfmt_misc iptable_filter ip6table_filter ip6_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables x_tables mperf ipmi_devintf ipmi_si ipmi_msghandler edd nf_conntrack_proto_sctp nf_conntrack sctp 8021q garp stp llc gb_sys usb_storage uas iTCO_wdt ioatdma pcspkr iTCO_vendor_support ixgbe igb wmi i2c_i801 mdio dca sg button container ipv6 autofs4 usbhid ehci_hcd megasr(P) usbcore processor thermal_sys
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492126] CPU 3
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492127] Modules linked in: xt_sharedlimit xt_hashlimit ip_set_hash_ipport ip_set_hash_ipportip xt_NOTRACK ip_set_bitmap_port xt_sctp nf_conntrack_ipv6 nf_defrag_ipv6 xt_CT arpt_mangle ip_set_hash_ipnet xt_NFLOG xt_limit xt_hashcounter ip_set_hash_ipip xt_set ip_set_hash_ip deflate ctr twofish_x86_64 twofish_common camellia serpent blowfish cast5 des_generic cbc xcbc rmd160 crypto_null af_key iptable_mangle ip_set arptable_filter arp_tables iptable_raw iptable_nat nfnetlink_log nfnetlink ipt_ULOG ipt_PORTMAP af_packet zlib zlib_deflate sha512_generic sha256_generic sha1_generic md5 icp_qa_al pcie8120 rte_kni pfe_pep virtio_rte virtio_shm virtio_vtnet virtio_uio igb_uio virtio_ring virtio uio xt_tcpudp xt_state xt_pkttype nf_conntrack_control bonding binfmt_misc iptable_filter ip6table_filter ip6_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables x_tables mperf ipmi_devintf ipmi_si ipmi_msghandler edd nf_conntrack_proto_sctp nf_conntrack sctp 8021q garp stp llc gb_sys usb_storage uas iTCO_wdt ioatdma pcspkr iTCO_vendor_support ixgbe igb wmi i2c_i801 mdio dca sg button container ipv6 autofs4 usbhid ehci_hcd megasr(P) usbcore processor thermal_sys
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492193]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492196] Pid: 7874, comm: virtio_shm/5/3 Tainted: P            3.1.10-gb20-default #1 Intel Corporation S2600CO/S2600CO
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492201] RIP: 0010:[<ffffffff81020650>]  [<ffffffff81020650>] __ticket_spin_lock+0x18/0x1b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492208] RSP: 0018:ffff88043ee63de8  EFLAGS: 00000293
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492210] RAX: 00000000000069be RBX: ffff880423772740 RCX: 000000000000000e
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492213] RDX: 00000000000069bc RSI: 000000000000000e RDI: ffff88041e56a484
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492215] RBP: ffff88041e56a484 R08: ffff88041e56a740 R09: ffff88041554f04c
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492217] R10: 0000000000000048 R11: ffff88041ee7fbc0 R12: ffff88043ee63d58
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492219] R13: ffffffff813f831e R14: ffff88041e56a484 R15: ffff88041ee7fbc0
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492222] FS:  0000000000000000(0000) GS:ffff88043ee60000(0000) knlGS:0000000000000000
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492225] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492227] CR2: 000000000078a410 CR3: 000000080b8df000 CR4: 00000000000406e0
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492229] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492232] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492234] Process virtio_shm/5/3 (pid: 7874, threadinfo ffff880811e52000, task ffff880821e320c0)
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492236] Stack:
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492238]  ffffffff8106b766 ffffffffa05e3a1e 000000001201fea9 ffffffffa03ef8b8
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492244]  0000002e1201fea9 ffff880423772000 ffff88043ee63e48 ffff880423772000
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492249]  ffffffff8192a870 0000000000000608 0000000000000000 ffffffff81928b00
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492255] Call Trace:
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492266]  [<ffffffff8106b766>] do_raw_spin_lock+0x5/0x8
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492275]  [<ffffffffa05e3a1e>] packet_rcv+0x254/0x2ab [af_packet]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492299]  [<ffffffff81337bbf>] __netif_receive_skb+0x2e1/0x36b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492304]  [<ffffffff81339722>] netif_receive_skb+0x7e/0x84
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492311]  [<ffffffffa03e2b49>] virtio_rte_recv_packets+0x2c/0x49 [virtio_rte]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492318]  [<ffffffffa03e2b78>] virtio_rte_poll+0x12/0x8c [virtio_rte]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492325]  [<ffffffff81339c88>] net_rx_action+0x65/0x178
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492331]  [<ffffffff81045c73>] __do_softirq+0xb2/0x19d
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492337]  [<ffffffff813f9aac>] call_softirq+0x1c/0x30
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492343]  [<ffffffff81003931>] do_softirq+0x3c/0x7b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492348]  [<ffffffff81045971>] _local_bh_enable_ip.isra.12+0x75/0x9b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492355]  [<ffffffffa03d8cdc>] virtio_shm_interrupt.isra.8+0xd6/0xeb [virtio_shm]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492363]  [<ffffffffa03d8e0c>] virtio_shm_intr_task+0x11b/0x15f [virtio_shm]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492371]  [<ffffffff8105975a>] kthread+0x76/0x7e
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492377]  [<ffffffff813f99b4>] kernel_thread_helper+0x4/0x10
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492379] Code: b7 c9 40 0f b6 ff 48 89 c2 44 89 ce e9 8e fb ff ff 90 90 b8 00 00 01 00 f0 0f c1 07 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 17 <eb> f5 c3 8b 07 89 c2 c1 c0 10 39 c2 8d 90 00 00 01 00 75 04 f0
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492409] Call Trace:
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492413]  [<ffffffff8106b766>] do_raw_spin_lock+0x5/0x8
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492418]  [<ffffffffa05e3a1e>] packet_rcv+0x254/0x2ab [af_packet]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492428]  [<ffffffff81337bbf>] __netif_receive_skb+0x2e1/0x36b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492432]  [<ffffffff81339722>] netif_receive_skb+0x7e/0x84
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492437]  [<ffffffffa03e2b49>] virtio_rte_recv_packets+0x2c/0x49 [virtio_rte]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492444]  [<ffffffffa03e2b78>] virtio_rte_poll+0x12/0x8c [virtio_rte]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492450]  [<ffffffff81339c88>] net_rx_action+0x65/0x178
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492454]  [<ffffffff81045c73>] __do_softirq+0xb2/0x19d
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492459]  [<ffffffff813f9aac>] call_softirq+0x1c/0x30
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492463]  [<ffffffff81003931>] do_softirq+0x3c/0x7b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492467]  [<ffffffff81045971>] _local_bh_enable_ip.isra.12+0x75/0x9b
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492472]  [<ffffffffa03d8cdc>] virtio_shm_interrupt.isra.8+0xd6/0xeb [virtio_shm]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492480]  [<ffffffffa03d8e0c>] virtio_shm_intr_task+0x11b/0x15f [virtio_shm]
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492486]  [<ffffffff8105975a>] kthread+0x76/0x7e
Aug 26 09:31:58 at-vie01a-cq21b kernel: [115452.492491]  [<ffffffff813f99b4>] kernel_thread_helper+0x4/0x10
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404215] BUG: soft lockup - CPU#31 stuck for 23s! [kni_thread:6605]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404219] Modules linked in: xt_sharedlimit xt_hashlimit ip_set_hash_ipport ip_set_hash_ipportip xt_NOTRACK ip_set_bitmap_port xt_sctp nf_conntrack_ipv6 nf_defrag_ipv6 xt_CT arpt_mangle ip_set_hash_ipnet xt_NFLOG xt_limit xt_hashcounter ip_set_hash_ipip xt_set ip_set_hash_ip deflate ctr twofish_x86_64 twofish_common camellia serpent blowfish cast5 des_generic cbc xcbc rmd160 crypto_null af_key iptable_mangle ip_set arptable_filter arp_tables iptable_raw iptable_nat nfnetlink_log nfnetlink ipt_ULOG ipt_PORTMAP af_packet zlib zlib_deflate sha512_generic sha256_generic sha1_generic md5 icp_qa_al pcie8120 rte_kni pfe_pep virtio_rte virtio_shm virtio_vtnet virtio_uio igb_uio virtio_ring virtio uio xt_tcpudp xt_state xt_pkttype nf_conntrack_control bonding binfmt_misc iptable_filter ip6table_filter ip6_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables x_tables mperf ipmi_devintf ipmi_si ipmi_msghandler edd nf_conntrack_proto_sctp nf_conntrack sctp 8021q garp stp llc gb_sys usb_storage uas iTCO_wdt ioatdma pcspkr iTCO_vendor_support ixgbe igb wmi i2c_i801 mdio dca sg button container ipv6 autofs4 usbhid ehci_hcd megasr(P) usbcore processor thermal_sys
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404306] CPU 31
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404308] Modules linked in: xt_sharedlimit xt_hashlimit ip_set_hash_ipport ip_set_hash_ipportip xt_NOTRACK ip_set_bitmap_port xt_sctp nf_conntrack_ipv6 nf_defrag_ipv6 xt_CT arpt_mangle ip_set_hash_ipnet xt_NFLOG xt_limit xt_hashcounter ip_set_hash_ipip xt_set ip_set_hash_ip deflate ctr twofish_x86_64 twofish_common camellia serpent blowfish cast5 des_generic cbc xcbc rmd160 crypto_null af_key iptable_mangle ip_set arptable_filter arp_tables iptable_raw iptable_nat nfnetlink_log nfnetlink ipt_ULOG ipt_PORTMAP af_packet zlib zlib_deflate sha512_generic sha256_generic sha1_generic md5 icp_qa_al pcie8120 rte_kni pfe_pep virtio_rte virtio_shm virtio_vtnet virtio_uio igb_uio virtio_ring virtio uio xt_tcpudp xt_state xt_pkttype nf_conntrack_control bonding binfmt_misc iptable_filter ip6table_filter ip6_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables x_tables mperf ipmi_devintf ipmi_si ipmi_msghandler edd nf_conntrack_proto_sctp nf_conntrack sctp 8021q garp stp llc gb_sys usb_storage uas iTCO_wdt ioatdma pcspkr iTCO_vendor_support ixgbe igb wmi i2c_i801 mdio dca sg button container ipv6 autofs4 usbhid ehci_hcd megasr(P) usbcore processor thermal_sys
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404373]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404376] Pid: 6605, comm: kni_thread Tainted: P            3.1.10-gb20-default #1 Intel Corporation S2600CO/S2600CO
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404380] RIP: 0010:[<ffffffff81020650>]  [<ffffffff81020650>] __ticket_spin_lock+0x18/0x1b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404389] RSP: 0018:ffff88083ede3cf0  EFLAGS: 00000297
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404391] RAX: 00000000000069bd RBX: 0000000000000000 RCX: 000000000000000e
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404393] RDX: 00000000000069bc RSI: 000000000000000e RDI: ffff88041e56a484
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404395] RBP: ffff88041e56a484 R08: ffff88041e56a740 R09: ffff880808f20440
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404397] R10: ffff88080d395084 R11: 000000000000001f R12: ffff88083ede3c68
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404400] R13: ffffffff813f831e R14: ffff88041e56a484 R15: ffff88080b97d0c0
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404402] FS:  0000000000000000(0000) GS:ffff88083ede0000(0000) knlGS:0000000000000000
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404405] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404407] CR2: 00007f0ad3e5e000 CR3: 0000000001805000 CR4: 00000000000406e0
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404409] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404412] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404414] Process kni_thread (pid: 6605, threadinfo ffff88080cab8000, task ffff8808138562c0)
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404416] Stack:
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404418]  ffffffff8106b766 ffffffffa05e3a1e 0000000000000000 0000000000000000
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404424]  0000002e00000000 ffff88042488a000 0000000000000000 ffff88042488a000
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404429]  ffffffff8192a870 0000000000000608 0000000000000000 ffffffff81928b00
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404435] Call Trace:
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404446]  [<ffffffff8106b766>] do_raw_spin_lock+0x5/0x8
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404454]  [<ffffffffa05e3a1e>] packet_rcv+0x254/0x2ab [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404477]  [<ffffffff81337bbf>] __netif_receive_skb+0x2e1/0x36b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404482]  [<ffffffff81339722>] netif_receive_skb+0x7e/0x84
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404487]  [<ffffffff8133979e>] napi_skb_finish+0x1c/0x31
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404497]  [<ffffffffa031adee>] igb_clean_rx_irq+0x30d/0x39e [igb]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404517]  [<ffffffffa031aecd>] igb_poll+0x4e/0x74 [igb]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404532]  [<ffffffff81339c88>] net_rx_action+0x65/0x178
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404538]  [<ffffffff81045c73>] __do_softirq+0xb2/0x19d
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404544]  [<ffffffff813f9aac>] call_softirq+0x1c/0x30
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404550]  [<ffffffff81003931>] do_softirq+0x3c/0x7b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404555]  [<ffffffff81045f98>] irq_exit+0x3c/0xac
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404558]  [<ffffffff81003655>] do_IRQ+0x82/0x98
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404565]  [<ffffffff813f24ee>] common_interrupt+0x6e/0x6e
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404573]  [<ffffffffa05e0003>] atomic_inc+0x3/0x4 [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404579]  [<ffffffffa05e3a33>] packet_rcv+0x269/0x2ab [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404477]  [<ffffffff81337bbf>] __netif_receive_skb+0x2e1/0x36b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404482]  [<ffffffff81339722>] netif_receive_skb+0x7e/0x84
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404487]  [<ffffffff8133979e>] napi_skb_finish+0x1c/0x31
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404497]  [<ffffffffa031adee>] igb_clean_rx_irq+0x30d/0x39e [igb]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404517]  [<ffffffffa031aecd>] igb_poll+0x4e/0x74 [igb]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404532]  [<ffffffff81339c88>] net_rx_action+0x65/0x178
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404538]  [<ffffffff81045c73>] __do_softirq+0xb2/0x19d
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404544]  [<ffffffff813f9aac>] call_softirq+0x1c/0x30
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404550]  [<ffffffff81003931>] do_softirq+0x3c/0x7b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404555]  [<ffffffff81045f98>] irq_exit+0x3c/0xac
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404558]  [<ffffffff81003655>] do_IRQ+0x82/0x98
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404565]  [<ffffffff813f24ee>] common_interrupt+0x6e/0x6e
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404573]  [<ffffffffa05e0003>] atomic_inc+0x3/0x4 [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404579]  [<ffffffffa05e3a33>] packet_rcv+0x269/0x2ab [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404589]  [<ffffffff81337bbf>] __netif_receive_skb+0x2e1/0x36b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404593]  [<ffffffff81339722>] netif_receive_skb+0x7e/0x84
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404610]  [<ffffffffa041bd4b>] kni_net_rx_normal+0x12d/0x178 [rte_kni]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404690]  [<ffffffffa041ae58>] kni_thread+0x39/0x91 [rte_kni]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404758]  [<ffffffff8105975a>] kthread+0x76/0x7e
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404763]  [<ffffffff813f99b4>] kernel_thread_helper+0x4/0x10
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404766] Code: b7 c9 40 0f b6 ff 48 89 c2 44 89 ce e9 8e fb ff ff 90 90 b8 00 00 01 00 f0 0f c1 07 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 17 <eb> f5 c3 8b 07 89 c2 c1 c0 10 39 c2 8d 90 00 00 01 00 75 04 f0
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404795] Call Trace:
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404800]  [<ffffffff8106b766>] do_raw_spin_lock+0x5/0x8
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404805]  [<ffffffffa05e3a1e>] packet_rcv+0x254/0x2ab [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404814]  [<ffffffff81337bbf>] __netif_receive_skb+0x2e1/0x36b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404818]  [<ffffffff81339722>] netif_receive_skb+0x7e/0x84
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404822]  [<ffffffff8133979e>] napi_skb_finish+0x1c/0x31
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404831]  [<ffffffffa031adee>] igb_clean_rx_irq+0x30d/0x39e [igb]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404849]  [<ffffffffa031aecd>] igb_poll+0x4e/0x74 [igb]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404863]  [<ffffffff81339c88>] net_rx_action+0x65/0x178
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404868]  [<ffffffff81045c73>] __do_softirq+0xb2/0x19d
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404872]  [<ffffffff813f9aac>] call_softirq+0x1c/0x30
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404875]  [<ffffffff81003931>] do_softirq+0x3c/0x7b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404880]  [<ffffffff81045f98>] irq_exit+0x3c/0xac
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404883]  [<ffffffff81003655>] do_IRQ+0x82/0x98
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404887]  [<ffffffff813f24ee>] common_interrupt+0x6e/0x6e
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404893]  [<ffffffffa05e0003>] atomic_inc+0x3/0x4 [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404899]  [<ffffffffa05e3a33>] packet_rcv+0x269/0x2ab [af_packet]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404908]  [<ffffffff81337bbf>] __netif_receive_skb+0x2e1/0x36b
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404912]  [<ffffffff81339722>] netif_receive_skb+0x7e/0x84
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404921]  [<ffffffffa041bd4b>] kni_net_rx_normal+0x12d/0x178 [rte_kni]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.404996]  [<ffffffffa041ae58>] kni_thread+0x39/0x91 [rte_kni]
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.405064]  [<ffffffff8105975a>] kthread+0x76/0x7e
Aug 26 09:32:00 at-vie01a-cq21b kernel: [115455.405068]  [<ffffffff813f99b4>] kernel_thread_helper+0x4/0x10
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172014] BUG: soft lockup - CPU#0 stuck for 22s! [gis:14145]
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172017] Modules linked in: xt_sharedlimit xt_hashlimit ip_set_hash_ipport ip_set_hash_ipportip xt_NOTRACK ip_set_bitmap_port xt_sctp nf_conntrack_ipv6 nf_defrag_ipv6 xt_CT arpt_mangle ip_set_hash_ipnet xt_NFLOG xt_limit xt_hashcounter ip_set_hash_ipip xt_set ip_set_hash_ip deflate ctr twofish_x86_64 twofish_common camellia serpent blowfish cast5 des_generic cbc xcbc rmd160 crypto_null af_key iptable_mangle ip_set arptable_filter arp_tables iptable_raw iptable_nat nfnetlink_log nfnetlink ipt_ULOG ipt_PORTMAP af_packet zlib zlib_deflate sha512_generic sha256_generic sha1_generic md5 icp_qa_al pcie8120 rte_kni pfe_pep virtio_rte virtio_shm virtio_vtnet virtio_uio igb_uio virtio_ring virtio uio xt_tcpudp xt_state xt_pkttype nf_conntrack_control bonding binfmt_misc iptable_filter ip6table_filter ip6_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables x_tables mperf ipmi_devintf ipmi_si ipmi_msghandler edd nf_conntrack_proto_sctp nf_conntrack sctp 8021q garp stp llc gb_sys usb_storage uas iTCO_wdt ioatdma pcspkr iTCO_vendor_support ixgbe igb wmi i2c_i801 mdio dca sg button container ipv6 autofs4 usbhid ehci_hcd megasr(P) usbcore processor thermal_sys
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172098] CPU 0
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172099] Modules linked in: xt_sharedlimit xt_hashlimit ip_set_hash_ipport ip_set_hash_ipportip xt_NOTRACK ip_set_bitmap_port xt_sctp nf_conntrack_ipv6 nf_defrag_ipv6 xt_CT arpt_mangle ip_set_hash_ipnet xt_NFLOG xt_limit xt_hashcounter ip_set_hash_ipip xt_set ip_set_hash_ip deflate ctr twofish_x86_64 twofish_common camellia serpent blowfish cast5 des_generic cbc xcbc rmd160 crypto_null af_key iptable_mangle ip_set arptable_filter arp_tables iptable_raw iptable_nat nfnetlink_log nfnetlink ipt_ULOG ipt_PORTMAP af_packet zlib zlib_deflate sha512_generic sha256_generic sha1_generic md5 icp_qa_al pcie8120 rte_kni pfe_pep virtio_rte virtio_shm virtio_vtnet virtio_uio igb_uio virtio_ring virtio uio xt_tcpudp xt_state xt_pkttype nf_conntrack_control bonding binfmt_misc iptable_filter ip6table_filter ip6_tables nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables x_tables mperf ipmi_devintf ipmi_si ipmi_msghandler edd nf_conntrack_proto_sctp nf_conntrack sctp 8021q garp stp llc gb_sys usb_storage uas iTCO_wdt ioatdma pcspkr iTCO_vendor_support ixgbe igb wmi i2c_i801 mdio dca sg button container ipv6 autofs4 usbhid ehci_hcd megasr(P) usbcore processor thermal_sys
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172163]
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172166] Pid: 14145, comm: gis Tainted: P            3.1.10-gb20-default #1 Intel Corporation S2600CO/S2600CO
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172170] RIP: 0010:[<ffffffff8102064d>]  [<ffffffff8102064d>] __ticket_spin_lock+0x15/0x1b
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172178] RSP: 0000:ffff88043ee03cf0  EFLAGS: 00000293
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172180] RAX: 00000000000069bf RBX: 00000000020110ac RCX: 000000000000000e
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172182] RDX: 00000000000069bc RSI: 000000000000000e RDI: ffff88041e56a484
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172184] RBP: ffff88041e56a484 R08: ffff88041e56a740 R09: ffff8804154a5840
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172187] R10: 00007f0afce77000 R11: 0000000000000000 R12: ffff88043ee03c68
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172189] R13: ffffffff813f831e R14: ffff88041e56a484 R15: ffff88041e568280
Aug 26 09:32:01 at-vie01a-cq21b kernel: [115456.172192] FS:  00007f0afd70b700(0000) GS:ffff88043ee00000(0000) knlGS:0000000000000000

Hi wb,

I want to update the driver of wired ethernet adapter from version 1.3 to 1.5,

so do i need to update the adapter firmware or not? If need which version shold be better?Wired Ethernet

[root@node2 ~]# ethtool -i slot1_10GE1

driver: i40e

version: 1.3.47

firmware-version: 4.26 0x800014af 0.0.0

bus-info: 0000:07:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

FWIW, I to have this issue, I don't want to hijack these thread but I thought it pertinent to outline issues here too. I wanted to search for "Intel(R) Ethernet Connection I219-V" and this was the second on the list

However, my setup is somewhat different:

Laptop - HP EliteBook 1040 G3

BIOS update (01.08) - latest

Windows 10 64 bit, build 14955

Tried Driver version 12.13.17.7 (13/08/2015) and the latest Version 21.1 (September 28, 2016),

With the same issue. When the laptop is completely shutdown power off), then started from cold, the Ethernet NIC will detect a link of 1Gbs immediately and connect with no issue.

As son as the laptop is put to sleep, then woken up, the NIC will only say the link is 10Mbps, but not actually connect properly and pickup and IP address.

I have tried to disconnect the Ethernet cable, disable/re-enable the adaptor, it hasn't resolved the issue. Only a full shut down will cure the problem. .

Any further thoughts beyond what you have said above.

In the latest versions of Intel Network Adapters driver, I'm missing Prosetcl.exe which I use to change the link speed / duplex. Why is this no longer available in the latest releases? Last I saw was 20.4.1. What is the replacement command?

Hi, 

I have some problems running Intel 82579 driver (E1C51CE6) in Windows CE 6.0. Communication with the ethernet interface is aparently OK but after some time connectivity is lost.

In addition I can see the following traces to be printed:  

WINCE 6.0 E1Q::PhyUpdateAdaptiveIFS: Adaptive IFS exiting--adapter is stopped or resetting

ndisMResetCompleteStage2: Internal reset

I have some concerns I want to share with you: 

1- I got this driver dll from "Intel® Ethernet Drivers for Microsoft* Embedded Operating Systems v12" https://downloadcenter.intel.com/download/24555/Intel-Ethernet-Drivers-for-Microsoft-Embedded-Operating-Systems. Is there any newer release of this driver?

2- I guess this controller is no more supported by Intel for Windows CE 6.0. Howerver, is it possible to get the source code of this driver?

3- Any idea related to the traces that are printed? 

Any hint is appreciated! 

Thanks

Hi,

i am an IT student at a german university. Currently i am working on my bachelor´s thesis about the PTP protocol. For this reason i got a Intel network adapter I210-T1, which has support for the IEEE 1588 (=PTP) protocol.

On Linux Ubuntu works everything pretty fine. The card is working as expected. The first time i wanted to use it on Windows, my system frezzed. And still after rebooting the OS, the network card can not be used.

First of all my HW specifications:

- MB:          Asus P7H55-M Pro

- CPU:        Intel Core I5 650 @ 3.20GHz

- RAM:       16.0GB DDR3

- Graphic:  Intel HD Graphics

- Storage:  223GB OCZ-VERTEX3 (SSD)

The SW specifications for Linux (everything is fine here):

- OS:         Ubuntu   16.04 LTS

- Driver:    igb-5.3.5.4

- Other:     linuxptp package

And for Windows (with the issue):

- OS:        Windows 7 Pro 64-bit SP1

- Driver:    Intel Network Adapter Driver for Windows 7 (Version 21.1, 64-bit)

Problem:

The main problem in Windows is located in the device manager. Here it says on my adapter, that the error code 31 appeared. See the attachment. This means, that i absolutely can not use the card. The first time after installing the card, Windows tried to search and install the driver by itself. Then, as i said, the whole system frezzed. I had to power it off with the switch. After rebooting Windows, it said, that it was not able to install the driver. I tried to do that manually with the driver of the support website, but with no success. Only the error code 31 appears.

What i already have done:

- Let Windows try to install the driver by itself -> No success

- Install driver manually -> No success

- Make sure Windows Update is up to date -> No success

- Reinstall and/or update the asus driver for the motherboard (also the chipset driver etc...) -> No success

- Update BIOS to newest version -> No success

- Testing the card on an other pc -> Success

- Testing the card under Ubuntu -> Success

- Tried to execute this solution -> http://www.tomshardware.co.uk/answers/id-1750879/code-error-network-adapter.htm -> No success

I know that there is always the possible solution for a reinstall of Windows, but this current installed OS is actually only a month old, so pretty new. What else can i do besides this?

Thank you,

doritsep

Update

Found an old post of another forum with the exact same problem, but with no solution. -> i210 driver installation freezes Windows 7 x64 | FreeNAS Community

According to the Intel X550 datasheet (1), the controller supports IEEE 802.3az Energy Efficient Ethernet (EEE). It's also added as a key feature on the Intel's X550 Product Brief (2). However, it seems that 802.3az support has been silently dropped from the Intel X550-T1/T2 product brief (2) even if a product guide from Lenovo clearly mark this feature as supported. This feature is important for EE datacenters, especially for power-hungry 10GBase-T connectivity. We tried to get EEE working on X550-T1/T2 CNA on various switches without success. It seems this features is disabled or broken. PROSet 21.1 does not include any settings related to EEE.

Can you please give us the current status of 802.3az (EEE) on Intel's X550-T1/T2 CNA?

PS : Additionally, do you have an ETA for NBase-T support on these NICs? According to the product brief, this feature is marked as "to be enabled in a post-launch firmware release".

(1) http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/ethernet-x550-datasheet.pdf

(2) http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/x550-ethernet-controller-product-brief.pdf

(3) http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ethernet-x550-brief.pdf

(4) https://lenovopress.com/lp0097.pdf

Hi.

Is it possible to change mac address on virtual NICs associated with VLANs created under Windows 10 using last Intel drivers for i210?

I cant find the way to do it.

Thanks.

Hi,

I am not sure if this is the right place to post this question, if not please correct me.

I am using an Intel I210 card on my linux PC. I was trying to generate a clock output on one of the SDP pins, so I followed the section-7.8.3.3.3 in Intel-i210 data sheet.

According to Time Sync Interrupt Cause Register(TSICR) description, we can get interrupts to driver for "every output clock half-cycle on SDP pin". So I configured the registers accordingly from the "igb_avb driver" (few changes to original driver in Open-AVB).

The problem is, I am not getting those clock interrupts. Basically what I was looking for is, to get periodic interrupts from the SDP clock to igb_avb driver, to perform some tasks.

Have someone tried this before ?

Registers I configured (for CLK1 on SDP1) are:

IMS - set Time sync interrupts

TSIM - enable interrupt for Target Time1(TT1)

TSSDP - enable SDP1 and assign CLK1

TSAUXC - enable CLK1

CTRL - set SDP as output

FREQOUT - set clock half-cycle

Please let me know if any more information is required.

Thanks.

During installation of Intel Network Adapter Driver for Windows® 10 64-bit, this warning message appear. I installed it anyway but after a week, my Ethernet driver starts to crash randomly and gets stuck in restarting when i restart my PC.

What does this excatly mean?

I have use SR-IOV in my proxmox, and I was passthrough 2 virtual Function NIC card to my vm-pfsense

[code]

root@pve:~# lspci |grep Eth|grep I350

07:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

07:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)

08:10.0 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01)

08:10.1 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01)

08:10.4 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01)

08:10.5 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01)

08:11.1 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01)

[/code]

But one of ethernet port have to tag 2 vlan id

[code]

root@pve:~# ip link show eth11

6: eth11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

    link/ether 0c:c4:7a:c3:9f:07 brd ff:ff:ff:ff:ff:ff

    vf 0 MAC 7e:ba:b6:b5:ec:13, spoof checking on, link-state auto

    vf 1 MAC 7e:ba:b6:b5:ec:14, spoof checking on, link-state auto

    vf 2 MAC 7e:ba:b6:b5:ec:15, vlan 300, spoof checking on, link-state auto

[/code]

I was use Trunk port in DGS-1510 switch, and I can see 7e:ba:b6:b5:ec:15 this mac tag vlan id 300 on switch web gui.

Any in pfsense, I can see 7e:ba:b6:b5:ec:15 this interface status was up. so I set static ip 192.168.55.1 on this interface.

But DGS-1510 and pfsense cannot ping each other.

How can I solve this error?

Hi.

We've met some issue with I210 controller.
I210 is used in linux environment (MSI-X, multiqueue).

RX queues seems to be working (we can receive packets).

But we've found that each and every transmitted TX descriptor contains E1000_TXD_STAT_EC (i.e 0x00000002, Excess Collisions) bit in status field.

So, what are the possible reasons of "Excess Collision" on every TX packet?

Thanks in advance.

Hi,

I am using Ubuntu 16.04 LTS operating system, with igb-5.3.5.4 driver. I have two I210 Ics on board.

I have programmed iNVM in both devices and

"lspci" is identifying the devices and lsmod also showing igb module with no user for it(i.e. 0)

"lshw" is also showing devices with network -UNCLAIMED.

How to bind this igb driver to i210 controllers?

The board is also having I217 controller with e1000e driver and it is working fine.

Please help me in resolving this issue