Hi,
we have an issue about the I210-IS, when we set the PCIE root port to "disable", the speed LED and active LED will light up.
when set it to "enable", and there was no link, the LEDs will go out.
We co-lay I210-AT and I210-IS on the schematic, and when mount I210-AT，there was no this issue.
Could you please check whether it is related to the EEPROM or not?
Our EEPROM version is 3.25
Thanks.
Vicky
I download the driver on 下载 用于 FreeBSD 的英特尔®网络适配器千兆位基本驱动程序 * , which is suitable for the device Intel Corporation Ethernet Connection I219-V.
But when I go into the src folder and type "make" command, it comes out Makefile: 34: missing seperator. stop.
So how can i make it right? I didn't modify the 'Makefile' in the src folder.
Hi,
I'm trying to get my XL710 NIC to send packets to different queues but so far without any luck. I'm running Ubuntu with kernel version 4.16.1. I downloaded version 2.4.6 of the i40e driver from the Intel download center. Because my packets weren't arriving as expected I modified the driver to print the queue being cleaned and the incoming packets to dmesg. The commands I'm using to set up the rules are as follows:
sudo ethtool -N enp1s0f1 flow-type ip4 dst-ip 6.6.6.6 action 0
sudo ethtool -N enp1s0f1 flow-type ip4 dst-ip 6.6.6.7 action 1
ethtool -n enp1s0f1 confirms the rules have been set properly. However, when I check dmesg I can see the packets are not landing in the specified queues. I have tried different versions of the ethtool command such as -U instead of -N and tcp4 or udp4 instead of ip4. Any suggestions as to why this could happen?
Dear Sir or Madam,
we have to carry out a new MTBF calculation of an entire system for our customer.
In this regard, I wanted to ask if you could provide the corresponding data for the network controller card I340-T4 E1G44HTBLK.
Thank you in advance,
Best regards Steffen
Hi
I'm new with that NIC
I'm trying to create a loop from one interface to the other - XL710 - qda2
The link are down
I actually connected a cable between them - Do I need a special cable to that?
I've manage to that on our former NIC
using SFP+
What I'm missing over here?
ifconfig
enp5s0f0 Link encap:Ethernet HWaddr 3c:fd:fe:b7:b6:30
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
enp5s0f1 Link encap:Ethernet HWaddr 3c:fd:fe:b7:b6:31
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Hi !
We have some workstations that have the following problem :
They have the OOB ip address active and different from windows although the configuration is DHCP for both.
Windows is not cloning the ip address it gets from dhcp to the oob config and we have an ip address that is used simultaneously - that was solved when fixed the broadcast domain.
It is amazing as you can see below : a workstation has 2 ip address - 1 for OOB adm and another for windows although they are configured to use dhcp so windows should clone its ip config to OOB
These packets came from the same workstation as you can from wireshark filter
Image may be NSFW.
Clik here to view.
The problem now is - why windows 7 is not cloning the ip address configuration to oob ip config ?
Thanks
Our proprietary motherboards have two i210-AT NIC's. Our vendor currently supplies the boards with both NIC NVRAM's loaded with firmware version 3.16.
We are trying to update the NIC's to firmware version 3.25 in our production process using Windows PE, but have encountered a strange intermittent problem.
The EEUPDATE command ("EEUPDATEW64e.exe /All /D I210_Ver.3.25_20171012.bin") appears to be successful, per this output:
EEUPDATE v5.30.22.00
Copyright (C) 1995 - 2017 Intel Corporation
Intel (R) Confidential and not for general distribution.
NIC Bus Dev Fun Vendor-Device Branding string
=== === === === ============= =================================================
1 1 00 00 8086-1533 Intel(R) I210 Gigabit Network Connection
2 2 00 00 8086-1533 Intel(R) I210 Gigabit Network Connection
1: EEPROM Image Version: 3.25
2: EEPROM Image Version: 3.25
After cycling power to the board, we can confirm the NIC firmware version displayed in our BIOS settings. Usually, we will see 3.25 for both NIC's, as expected.
However on some units, the 2nd NIC will still report version 3.16 in the BIOS settings. (As I understand, the BIOS code is reading the firmware version via an offset to PCI BAR1 address.) In this case, the EEUPDATE tool does report firmware version 3.25 is installed. It is not clear which is correct, EEUPDATE or the BIOS.
We can usually repair this problem when it happens by simply rerunning the same EEUPDATE command as above. But this should not be necessary.
Any idea how we are getting this contradictory result, and what to do about it?
Hi.
So my problems is that with latest version of windows VLANS dont activate they stay disabled state, reinstalling drivers does nothing and they are newest version from intels website.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Ou snap
Message was edited by: Tiit Talts
We have been using the 32-bit version of eeupdate (eeupdate32 from the Quartzville tools package) for programming the MAC addresses in our Intel 82574L NICs for a while now.
After updating the OS to 64 bit (CentOS 6), I get an error running the
64 bit version of the tool:
================
$ uname -a
Linux test0 2.6.32-696.28.1.el6.x86_64 #1 SMP Wed May 9 23:09:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ sudo /usr/local/bin/eeupdate64e /d /home/test/intel/tools/quartzville/TOOLS/Linux32/OEM_Mfg/82574_APT_A1_EE.eep /mac=00a069020d3\
b /nic=2
Using: Intel (R) PRO Network Connections SDK v2.28.1
EEUPDATE v5.28.01.06
Copyright (C) 1995 - 2016 Intel Corporation
Intel (R) Confidential and not for general distribution.
Driverless Mode
NIC Bus Dev Fun Vendor-Device Branding string
=== === === === ============= =================================================
1 0 25 00 8086-1502 Intel(R) 82579LM Gigabit Network Connection
2 2 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
3 3 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
4 4 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
5 5 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
Unable to initialize adapter 2 code c86a2002
Adapter initialization failed
The kernel log messages show:
kernel: Program eeupdate64e tried to access /dev/mem between f7000000->f7020000.
kernel: Program eeupdate64e tried to access /dev/mem between f7020000->f7024000.
================
That was the 20161005 version of the quartzville tools that we've been using
successfully (32 bit version). I downloaded the 20180202 version of
the tools (23.0) and got the same result with the 64 bit flavor
(eeupdate64e):
Using: Intel (R) PRO Network Connections SDK v2.30.25
EEUPDATE v5.30.25.06
Copyright (C) 1995 - 2017 Intel Corporation
It also added another complaint:
Connection to QV driver failed - please reinstall it!
But I've had success in the past running in "QV Driverless Mode".
Anyone have an explanation of that error code spewed by eeupdate? Why does the 32 bit version of eeupdate32 work and the 64 bit does not?
Hi
We have computers that have Intel AMT enabled. The OOB IP is configured for dhcp but they are not releasing the ip address althought the lease is 24 hrs. Because of that we are having ip address conflicts - the TCPIP stack of one windows machine when it is booted takes a new ip address but the OOB ip of that nic is an old one that conflicts with another windows machine.
Has anyone heard anything about that ? Is this a bug or misconfiguration ?
Thanks a lot
Got the code 10 issue with my I218-V adapter, can someone send me the ULP utility so I can try it?
I also have teaming problem with I350-T2 + I219V
I use win10 64-bit with build 14393.2214 (released at 17th, April) and the latest driver (Download Intel® Network Adapter Driver for Windows® 10 )
I can successfully teaming these two adapters(using intel ANS adaptive load balancing), and it works fine in normal situation.
BUT, its fail-over function doesn't work at all.
Here is how I test fail-over function:
I connect with 3 client pc and use Iperf2.0.10 to test the connection speed.
Then, I intentionally disable one adapter, theoretically, it will continue connecting with all 3 pc with a lower speed(which I saw under win8), but the result I see is connection abort (sometimes one or two of them, sometimes all) with two kinds of error message : "write failed, connection reset by peer" or "software cause connection abort".
This problem didn't happen under win8 I test couple weeks ago.
Does anyone have any idea?
Hi all, I have an Intel XL710-QDA2 dual port 40Gb adapter.
Intel® Ethernet Converged Network Adapter XL710-QDA2 Product Specifications
I am trying to connect the adapter to my network but do not have any certified XLDACBL1, XLDACBL2, and XLDACBL3 or QSFP+ transceiver at the moment.
I have a few units of Dell Networking Cable QSFP+ to QSFP+ 40GbE Passive Copper Direct Attach Cable, believed to be OEM from Amphenol.
http://accessories.euro.dell.com/sna/PopupProductDetail.aspx?cs=nldhs1&l=en&c=nl&sku=470-AAWN
Not sure if the cable can work with XL710-QDA2 adapter? Fyi, the adapter will used to support iSCSI. Appreciate any advise / experience sharing.
Many thanks!
I had a pair of I210 NICs (a dual-NIC motherboard) teamed via Static Link Aggregation and all was working fine until today when Windows 10 x64 decided to apply the April 2018 cumulative update. The page providing the respective drivers with ANS support (https://downloadcenter.intel.com/download/25016/Intel-Network-Adapter-Driver-for-Windows-10?product=64399) states that the latest version is 23.1 (dated 2018-02-21). Even with this latest driver, however, I can re-create the team, but it cannot be enabled. The only way to keep things in a sort of working state is to disable one of the NICs as well as the virtual team interface and keep only the other NIC active (i.e., not an ideal scenario).
Is there any chance that a new version of the driver will be available soon?
Thanks.
nvx
Hello,
I just received my new dell server and the Intel x550-t2 card does not show up in the vmware console. Do I need to install drivers for it to work properly? It is displayed as compatible with VMWare so I thought it would work right out of the box but that doesn't seem to be the case.
This issue was covered here but was NOT resolved and mark answered by accident.
VLANs disabled in Windows 10 Build 17133.1 Version 1803
My steps were as follows
In conclusion, the latest Intel NIC driver 23.1 seems fine but there is something wrong with Windows 10 Build 17133.1 Version 1803 Springs Creators Update, aka Redstone 4.
Hi Sharon and Ninwardspiral,
We are having similar problems with the exact same NIC, and by coincidence with the same breakout cable (although we tested many).
Driver and firmware are updated to the latest versions available (2.4.3 and 6.01 respectively):
version: 2.4.3
firmware-version: 6.01 0x800034af 1.1853.0
First cable that does not work: ( QSFP to 4x10G SFP+, amphenol, 2m)
From the manufacturer website: Each QSFP-SFP+ splitter cable features a single QSFP+ connector (SFF-8436) rated for 40-Gbps on one end and (4) SFP+ connectors (SFF-8431), each rated for 10-Gbps, on the other.
SF-QSFP4SFPPS-002 Amphenol Commercial Products | Cable Assemblies | DigiKey (exact cable we bought)
ethtool -m output:
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x21 (Copper pigtail)
Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00
Transceiver type : FC: Copper Passive
Encoding : 0x00 (unspecified)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 2m
Length (OM3) : 0m
Passive Cu cmplnce. : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]
Vendor name : Amphenol
Vendor OUI : 78:a7:14
Vendor PN : 624400002
Vendor rev : A
Option values : 0x00 0x00
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : APF1718002044N
Date code : 170513
ethtool <intf> output (after bringing interfaces up):
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: Symmetric
Supports auto-negotiation: No
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: Unknown!
Duplex: Unknown! (255)
Port: Other
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Current message level: 0x0000000f (15)
drv probe link timer
Link detected: no
Second cable that does not work: ( QSFP to 4x10G SFP+, generic brand):
2m(6.6ft) 40G QSFP+ to 4SFP+ Passive Breakout DAC Cable | FS.COM
ethtool -m <intf> output:
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x21 (Copper pigtail)
Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00
Transceiver type : FC: Copper Passive
Encoding : 0x00 (unspecified)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 2m
Length (OM3) : 0m
Passive Cu cmplnce. : 0x03 (unknown) [SFF-8472 rev10.4 only]
Vendor name : FIBERSTORE
Vendor OUI : 00:00:00
Vendor PN : QSFP-4SFP10G-DAC
Vendor rev :
Third Cable, it does work but its not what we need:
https://www.brack.ch/delock-direct-attach-kabel-330520
As a way to see if the NICs work, we also bought a SFP+ to SFP+ cable that is supposed to support SFP MSA and SFF-8431, but not SFF-8472. What is impressive is that this cable is detected and allows us to bring the link up
and even exchange some data at 10gbps. However, that is not what we need.
Encoding : 0x00 (unspecified)
BR, Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 1m
Length (OM3) : 0m
Active Cu cmplnce. : 0x0c (unknown) [SFF-8472 rev10.4 only]
Vendor name : CISCO-TYCO
Vendor OUI : 00:40:20
Vendor PN : 2127493-1
Vendor rev : A
Option values : 0x00 0x12
Option : RX_LOS implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : 164800277_______
Settings for ens787f3:
Supported ports: [ FIBRE ]
Supported link modes: Not reported
Supported pause frame use: Symmetric
Supports auto-negotiation: No
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: 10000Mb/s
Duplex: Full
Port: Direct Attach Copper
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Current message level: 0x0000000f (15)
drv probe link timer
Link detected: yes
Fourth Cable (to be delivered):
Intel X4DACBL3 40G QSFP+ Breakout DAC Cable | FS.COM
We are waiting for a fourth cable (this time is supposed to be intel compatible, but we dont know if it will be compatible with our switch...).
Why is the amphenol cable not working if the output of ethernet says: (SFF-8431 appendix E) [SFF-8472 rev10.4 only] which as stated in : Compatible SFP+ Modules, SFP Modules, and Cables for Intel® Ethernet... should be enough to be compatible. Why
only SFP+ to SFP+ cables work? What should we do? We spent to many resources and time buying different cables.
And to finish, would this NIC Intel® Ethernet Network Adapter XXV710-DA2 Product Specifications give us better results?
Thanks.
Edgar
I have a Windows 10 system on Z370 chipset with INTEL® ETHERNET CONNECTION I219-V.
Latest drivers is installed.
When I'm trying to use "cast to" option, it falls with error "can't connect to device".
But when I insert additional USB Ethernet adapter, connect it to the same ethernet patch cord, option "cast to" works fine.
So, problem is in I219-V.
How ti fix this problem with DLNA casting?
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, we have been redirected here from this thread in the embedded community: ARM tools for 82574 |Embedded Community
To summarize the important parts of our previous discussion, we have an Intel EXPI9301CT Gigabit CT PCI-e Desktop Adapter, which has an 82574 controller and a Winbond W25X40BVNIG flash. We are trying to use the eepromARMtool to reprogram the MAC address in the flash.
Running ./eepromARMtool -dump -NIC=1 gives us a file whose first line is:
8888 8888 8887 0C20 F746 2014 FFFF FFFF
We want to change the MAC address, so we edit the file that was dumped and change the first line to:
70B3 D501 C307 0C20 F746 2014 FFFF FFFF
Then we run ./eepromARMtool -write -NIC=1 -f=new_mac.otp. If we run the dump command again, the flash appears to have the correct contents. However, if we reboot or power cycle the machine and dump again, the output has returned to its original contents. This seems to imply that our changes were not actually flushed to the flash.
Do you have any advice for how to fix this problem? Thank you!