Hi,

i'm a new engineer and i have a project with this. I have a sensor with output is a pulse. I think that i can use the Input Capture but dose the Galileo Gen 2 have it and how about the Example code ?

Thank you very much !

I am trying to enable a intel x520 10 Gb adapter to pxe boot.  Its a PCI add on card.  this is a bare bone systems that will be installed via PXE from the intel x520 card.  the system has no OS.  Has anyone encounter this issue before.  the instructions all point to and OS installed and runnning the utility,  The problem is it doesnt work with esxi5.0 and I tried with a boot iso which didnt work.  any thoughts

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

my specs

Intel(R) 82579LM Gigabit Network Connection

windows 7 SP1 32bit + lastest windows update

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

In the link below the pdf states some interesting figures but does not point to details about the signatures nor the test data. Where would this test data be located on the Intel site?

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/160gbps-dpi-performance-using-intel-architectur…

Hi All,

When we use netperf to generate traffic, i40e nics are down very soon(

the throughput is about 76Gbps).

CPU: "Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz" X2

TOPO:

port5, port6, port11, port12 are i40e interfaces.

port6 and port12 are in a net namespace.

port5<--->port6: port5 is connected port6 directly.

port11<--->port12: port11 is connected port12 directly.

nics interrupt bind cpu:

port5: 0, 1, 2, 3, 4 (CPU0)

port6: 10, 11, 12, 13, 14 (CPU1)

port11: 5, 6, 7, 8, 9(CPU0)

port12: 15, 16, 17, 18, 19 (CPU1)

kernel: 3.13.11

driver: i40e stable

1.0.15(http://sourceforge.net/projects/e1000/files/i40e%20stable/1.0.15/):

version: 1.0.15

firmware-version: f4.1 a1.1 n04.10 e800010e0

bus-info: 0000:09:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: no

We also tried latest kernel 3.16.3 (with its own driver), it has the same issue.

netperf cmd:

netperf -T 14,19 -L 15.3.2.1 -H 15.3.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 13,18 -L 15.5.2.1 -H 15.5.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 12,17 -L 15.2.2.1 -H 15.2.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 11,16 -L 15.1.2.1 -H 15.1.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 10,15 -L 15.4.2.1 -H 15.4.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 4,9 -L 14.4.2.1 -H 14.4.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 3,8 -L 14.1.2.1 -H 14.1.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 2,7 -L 14.5.2.1 -H 14.5.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 1,6 -L 14.2.2.1 -H 14.2.1.100 -f m -D 1 -l 600 >/dev/null &

netperf -T 0,5 -L 14.3.2.1 -H 14.3.1.100 -f m -D 1 -l 600 >/dev/null &

dmesg:

...

i40e 0000:09:00.1 port6: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

i40e 0000:09:00.0 port5: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

IPv6: ADDRCONF(NETDEV_CHANGE): port6: link becomes ready

IPv6: ADDRCONF(NETDEV_CHANGE): port5: link becomes ready

i40e 0000:8a:00.0 port11: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

i40e 0000:8a:00.1 port12: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

IPv6: ADDRCONF(NETDEV_CHANGE): port11: link becomes ready

IPv6: ADDRCONF(NETDEV_CHANGE): port12: link becomes ready

------------[ cut here ]------------

WARNING: at net/sched/sch_generic.c:254 dev_watchdog+0x174/0x1da()

Hardware name: To be filled by O.E.M.

NETDEV WATCHDOG: port5 (i40e): transmit queue 3 timed out

Modules linked in: khttpc(O) khttpd(O) i40e(O) ixgbe(O)

Pid: 883, comm: kworker/0:1 Tainted: G           O 3.8.4+ #1

Call Trace:

<IRQ>  [<ffffffff8022d914>] ? warn_slowpath_common+0x76/0x8a

[<ffffffff8022d96f>] ? warn_slowpath_fmt+0x47/0x49

[<ffffffff802373b5>] ? mod_timer+0x107/0x11b

[<ffffffff80549ec7>] ? dev_watchdog+0x174/0x1da

[<ffffffff80549d53>] ? dev_graft_qdisc+0x61/0x61

[<ffffffff802375e8>] ? call_timer_fn.isra.35+0x1c/0x6f

[<ffffffff8023779e>] ? run_timer_softirq+0x163/0x182

[<ffffffff80232f11>] ? __do_softirq+0xa0/0x13d

[<ffffffff8066260c>] ? call_softirq+0x1c/0x26

[<ffffffff802032b5>] ? do_softirq+0x2a/0x64

[<ffffffff8023306f>] ? irq_exit+0x3d/0x5a

[<ffffffff80218af2>] ? smp_apic_timer_interrupt+0x81/0x8d

[<ffffffff8066200a>] ? apic_timer_interrupt+0x6a/0x70

<EOI>  [<ffffffffa003e220>] ? i40e_do_reset_safe+0xcd2/0xd84 [i40e]

[<ffffffffa003dff5>] ? i40e_do_reset_safe+0xaa7/0xd84 [i40e]

[<ffffffff803af706>] ? delay_tsc+0x20/0x44

[<ffffffffa0042412>] ? i40e_asq_send_command+0x316/0x441 [i40e]

[<ffffffffa0043546>] ? i40e_aq_get_link_info+0x47/0x123 [i40e]

[<ffffffffa0043d64>] ? i40e_get_link_status+0x20/0x28 [i40e]

[<ffffffffa0036e45>] ? i40e_ioctl+0x1858/0x1a0b [i40e]

[<ffffffffa003e228>] ? i40e_do_reset_safe+0xcda/0xd84 [i40e]

[<ffffffff802370ca>] ? internal_add_timer+0xd/0x28

[<ffffffff802373b5>] ? mod_timer+0x107/0x11b

[<ffffffff8023f37e>] ? process_one_work+0x1d6/0x2d8

[<ffffffff8023f6a4>] ? worker_thread+0x201/0x2eb

[<ffffffff8023f4a3>] ? process_scheduled_works+0x23/0x23

[<ffffffff80243034>] ? kthread+0xa9/0xb1

[<ffffffff80242f8b>] ? kthread_stop+0x49/0x49

[<ffffffff8066146c>] ? ret_from_fork+0x7c/0xb0

[<ffffffff80242f8b>] ? kthread_stop+0x49/0x49

---[ end trace bdce93fbb0280b12 ]---

i40e 0000:09:00.0 port5: tx_timeout recovery level 1

i40e 0000:09:00.0: i40e_vsi_control_tx: VSI seid 518 Tx ring 3 disable timeout

i40e 0000:09:00.0: i40e_ptp_init: added PHC on port5

i40e 0000:09:00.0 port5: adding 00:90:0b:38:4f:7c vid=0

i40e 0000:09:00.0 port5: set fc fail, aq_err -7

i40e 0000:09:00.0 port5: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

i40e 0000:09:00.0 port5: NIC Link is Down

i40e 0000:09:00.1 port6: NIC Link is Down

i40e 0000:09:00.1 port6: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

i40e 0000:09:00.0 port5: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

hi all:

       I want to send sk_buff by "dev_queue_xmit", when I just send 2 packets, the network card may be hang.

I want to know how to debug this condition.

the /var/log/messages is:

#########################################

[root@10g-host2 test]# tail -f /var/log/messages
Sep 29 10:38:22 10g-host2 acpid: waiting for events: event logging is off
Sep 29 10:38:23 10g-host2 acpid: client connected from 2018[68:68]
Sep 29 10:38:23 10g-host2 acpid: 1 client rule loaded
Sep 29 10:38:24 10g-host2 automount[2210]: lookup_read_master: lookup(nisplus): couldn't locate nis+ table auto.master
Sep 29 10:38:24 10g-host2 mcelog: failed to prefill DIMM database from DMI data
Sep 29 10:38:24 10g-host2 xinetd[2246]: xinetd Version 2.3.14 started with libwrap loadavg labeled-networking options compiled in.
Sep 29 10:38:24 10g-host2 xinetd[2246]: Started working: 0 available services
Sep 29 10:38:25 10g-host2 abrtd: Init complete, entering main loop
Sep 29 10:39:41 10g-host2 kernel: vmalloc mmap_buf=ffffc90016e29000  mmap_size=4096
Sep 29 10:39:41 10g-host2 kernel: insmod module wsmmap successfully!
Sep 29 10:39:49 10g-host2 kernel: mmap_buf + 1024 is ffffc90016e29400
Sep 29 10:39:49 10g-host2 kernel: data ffffc90016e2942a, len is 42
Sep 29 10:39:49 10g-host2 kernel: udp data ffffc90016e29422
Sep 29 10:39:49 10g-host2 kernel: ip data ffffc90016e2940e
Sep 29 10:39:49 10g-host2 kernel: eth data ffffc90016e29400
Sep 29 10:39:49 10g-host2 kernel: h_source is ffffc90016e29406, dev_addr is ffff880c235c4750, len is 6result is 0
Sep 29 10:39:50 10g-host2 kernel: mmap_buf + 1024 is ffffc90016e29400
Sep 29 10:39:50 10g-host2 kernel: data ffffc90016e2942a, len is 42
Sep 29 10:39:50 10g-host2 kernel: udp data ffffc90016e29422
Sep 29 10:39:50 10g-host2 kernel: ip data ffffc90016e2940e
Sep 29 10:39:50 10g-host2 kernel: eth data ffffc90016e29400
Sep 29 10:39:50 10g-host2 kernel: h_source is ffffc90016e29406, dev_addr is ffff880c235c4750, len is 6result is 0
Sep 29 10:39:52 10g-host2 kernel: ixgbe 0000:03:00.0: eth2: Detected Tx Unit Hang
Sep 29 10:39:52 10g-host2 kernel:  Tx Queue             <11>
Sep 29 10:39:52 10g-host2 kernel:  TDH, TDT             <0>, <5>
Sep 29 10:39:52 10g-host2 kernel:  next_to_use          <5>
Sep 29 10:39:52 10g-host2 kernel:  next_to_clean        <0>
Sep 29 10:39:52 10g-host2 kernel: ixgbe 0000:03:00.0: eth2: tx_buffer_info[next_to_clean]
Sep 29 10:39:52 10g-host2 kernel:  time_stamp           <fffd3dd8>
Sep 29 10:39:52 10g-host2 kernel:  jiffies              <fffd497f>
Sep 29 10:39:52 10g-host2 kernel: ixgbe 0000:03:00.0: eth2: tx hang 1 detected on queue 11, resetting adapter
Sep 29 10:39:52 10g-host2 kernel: ixgbe 0000:03:00.0: eth2: Reset adapter
Sep 29 10:39:52 10g-host2 kernel: ixgbe 0000:03:00.0: master disable timed out
Sep 29 10:39:53 10g-host2 kernel: ixgbe 0000:03:00.0: eth2: detected SFP+: 5
Sep 29 10:39:54 10g-host2 kernel: ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX

#########################################

some information of my computer is:

#########################################

#########################################

kernel version is: 2.6.32-431.el6.x86_64

Thank you for your help.

Hi all.  I am currently having an issue with Windows 8.1 and my wired Ethernet connection.  Whenever I am using web based browser games or downloading a large amount of content, my Ethernet connection will drop to limited.  My wireless connection has never had this problem, but it is much slower.  It is very frustrating because the only way to fix it is to either restart the computer or constantly run a fix connection.  I am wondering if this problem has any thing to do with my Ethernet driver? I am currently using Broadcom Netlink (TM) Gigabit Ethernet driver version 15.6.1.2.....It is currently the most up to date version of the driver.  I have read on some other support forums that this particular driver does not work well with windows 8.1 and to use a windows 7 driver.  If this is the case, what driver would I use and where do I find it?  If this isn't the case, do any of you have any ideas for what could be causing the issue, and if so, how do I fix it?

i350-T4 NIC

Windows Server 2012 R2

All 4 i350 ports configured as a Windows LBFO Team (switch independent / dynamic load balancing)

Converged networking (HyperV vSwitch bound to the LBFO team, with vNICs configured on the vSwitch for Host OS operations (Management, Cluster/CSV. and Live Migration)

VLAN tagging in use on VM's and vNICs except the vNIC used for management which is 'native'

VMQ enabled on all i350 ports

SR-IOV disabled on all i350 ports

Server 2012 R2 HyperV cluster

Fully patched with update rollups and hotfixes currently available

Drivers 19.3 (latest from intel website)

In the above configuration the destination server blue screens during live migration. I can sometimes get 1 live migration to work, but a second attempt to live migrate a different VM to the same destination host will cause the host to blue screen.

I can reproduce this issue very easily on any host in the cluster. They all have the same behaviour

If i disable VMQ then the issue stops

Also we dont see this issue with thie same hardware and same configuration using Server 2012 (non R2) though i note that the NIC driver is diferent on this Server 2012 (e1r63x64.sys on 2012 as opposed to e1r64x64.sys on 2012 R2)

crashdup analysis always shows the faulting driver as e1r64x64.sys

BugCheck 1E, {ffffffffc0000005, fffff802be6a2550, ffffd000575b3b58, ffffd000575b3360}

*** ERROR: Module load completed but symbols could not be loaded for e1r64x64.sys
Probably caused by : e1r64x64.sys ( e1r64x64+280e7 )

Followup: MachineOwner
---------

18: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff802be6a2550, The address that the exception occurred at
Arg3: ffffd000575b3b58, Parameter 0 of the exception
Arg4: ffffd000575b3360, Parameter 1 of the exception

Debugging Details:
------------------

WRITE_ADDRESS: unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
ffffd000575b3360

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!ExQueryDepthSList+0
fffff802`be6a2550 8b01            mov     eax,dword ptr [rcx]

EXCEPTION_PARAMETER1:  ffffd000575b3b58

EXCEPTION_PARAMETER2:  ffffd000575b3360

BUGCHECK_STR:  0x1E_c0000005

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

EXCEPTION_RECORD:  0000000000000001 -- (.exr 0x1)
Cannot read Exception record @ 0000000000000001

TRAP_FRAME:  ffffe800b6200000 -- (.trap 0xffffe800b6200000)
Unable to read trap frame at ffffe800`b6200000

LAST_CONTROL_TRANSFER:  from fffff802be7efefb to fffff802be768ca0

STACK_TEXT: 
ffffd000`575b2b38 fffff802`be7efefb : 00000000`0000001e ffffffff`c0000005 fffff802`be6a2550 ffffd000`575b3b58 : nt!KeBugCheckEx
ffffd000`575b2b40 fffff802`be779846 : 00000000`00000000 fffff800`35d0c991 ffffe800`b1172d02 ffffd000`575b2e29 : nt!KiFatalFilter+0x1f
ffffd000`575b2b80 fffff802`be757d56 : 00000000`00000000 fffff802`be6e19a6 ffffe000`516d3f90 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x696
ffffd000`575b2bc0 fffff802`be7701ed : 00000000`00000000 ffffd000`575b2d60 ffffd000`575b3b58 ffffd000`575b2d60 : nt!_C_specific_handler+0x86
ffffd000`575b2c30 fffff802`be6fd3a5 : 00000000`00000001 fffff802`be615000 ffffd000`575b3b00 fffff800`00000000 : nt!RtlpExecuteHandlerForException+0xd
ffffd000`575b2c60 fffff802`be6fc25f : ffffd000`575b3b58 ffffd000`575b3860 ffffd000`575b3b58 ffffe800`b12ee480 : nt!RtlDispatchException+0x1a5
ffffd000`575b3330 fffff802`be7748c2 : 00000000`00000001 fffffa80`1b6de000 ffffe800`b6200000 00000000`00000000 : nt!KiDispatchException+0x61f
ffffd000`575b3a20 fffff802`be772dfe : 00000000`00000011 00000000`00000002 00000000`00000001 fffff802`be8a929a : nt!KiExceptionDispatch+0xc2
ffffd000`575b3c00 fffff802`be6a2550 : fffff800`35d04875 ffffe800`b0f3c870 ffffd000`575b3e00 ffffe000`517cd000 : nt!KiGeneralProtectionFault+0xfe
ffffd000`575b3d98 fffff800`35d04875 : ffffe800`b0f3c870 ffffd000`575b3e00 ffffe000`517cd000 00000000`00000000 : nt!ExQueryDepthSList
ffffd000`575b3da0 fffff800`372520e7 : ffffe000`517ce540 ffffe000`517cd000 ffffe800`b1496c60 00000000`00000000 : NDIS!NdisFreeNetBufferList+0xb5
ffffd000`575b3e20 fffff800`372528a9 : ffffe000`517ce540 ffffe000`517cd000 00000000`00000001 00000000`00000000 : e1r64x64+0x280e7
ffffd000`575b3e50 fffff800`37252c00 : ffffe000`517ce540 00000000`00000001 00000000`00000000 ffffe000`517cd000 : e1r64x64+0x288a9
ffffd000`575b3e90 fffff800`37264a9d : ffffe000`517cd000 ffffe000`00000001 ffffe000`00000001 ffff0001`00000001 : e1r64x64+0x28c00
ffffd000`575b3ec0 fffff800`37261c7b : 00000000`00000000 ffffd000`575469a0 ffffe000`517cd000 00000000`00000000 : e1r64x64+0x3aa9d
ffffd000`575b3f00 fffff800`3725a909 : 00000000`00000002 00000000`00000000 ffffe000`517cd000 ffffd000`575469a0 : e1r64x64+0x37c7b
ffffd000`575b3f50 fffff800`3725b02b : ffffe800`b528cde0 fffff800`35d04671 ffffd000`575b40f0 ffffe000`51105ad0 : e1r64x64+0x30909
ffffd000`575b3fc0 fffff800`35d8f0fa : ffffe800`b5b87868 ffffe800`b5b87858 ffffe800`b5b87854 ffffe800`b0d501a0 : e1r64x64+0x3102b
ffffd000`575b4030 fffff800`35d033a3 : ffffe800`b0d501a0 ffffd000`575b40e9 ffffe800`b5b87820 00000000`00000011 : NDIS!ndisMInvokeOidRequest+0x4e
ffffd000`575b4070 fffff800`35d04324 : 00000000`00000000 ffffe800`b0d501a0 ffffe800`b5b87868 00000000`00000000 : NDIS!ndisMDoOidRequest+0x39b
ffffd000`575b4150 fffff800`35d0475e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : NDIS!ndisQueueOidRequest+0x4c4
ffffd000`575b42f0 fffff800`3679719e : ffffe800`b147b8c0 00000000`00010224 ffffe800`b147b8c0 ffffe000`52bf4010 : NDIS!NdisFOidRequest+0xc2
ffffd000`575b43b0 fffff800`35d038de : ffffe800`b5b87820 ffffe000`51105ad0 00000000`00000000 ffffe000`52bea010 : wfplwfs!LwfLowerOidRequest+0x6e
ffffd000`575b43e0 fffff802`be6e19a6 : ffffd000`575b46d0 ffffd000`575af000 00000000`00000000 00000000`00000000 : NDIS!ndisFDoOidRequestInternal+0x2ee
ffffd000`575b44e0 fffff800`35d04131 : fffff800`35d035f0 ffffe000`52bea010 ffffe800`b1a0b400 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0xe6
ffffd000`575b45d0 fffff800`35d03d27 : 00000000`00000102 ffffd000`53203200 00000000`00000000 ffffd000`575467d0 : NDIS!ndisQueueOidRequest+0x2d1
ffffd000`575b4770 fffff800`372ea204 : 00000000`00000120 ffffe000`516d4000 00000000`00000120 ffffe000`52bf5000 : NDIS!ndisMOidRequest+0x193
ffffd000`575b4880 fffff800`372e858d : ffffe000`5200ff00 ffffd000`00000001 ffffe000`52bf5020 ffffe800`b5b87820 : NdisImPlatform!implatDoOidRequestOnAdapter+0x22c
ffffd000`575b4900 fffff800`372ea32c : ffffe800`b1ae3880 fffff802`be6546c9 ffffe000`52bf5000 00000000`00000000 : NdisImPlatform!implatOidRequestInternal+0x1fd
ffffd000`575b4ac0 fffff802`be650f4a : ffffe800`b1b54ca0 ffffe000`52c10050 ffffe000`52c10050 fffff800`6977444e : NdisImPlatform!implatOidRequestWorkItem+0x24
ffffd000`575b4af0 fffff802`be651a2b : fffff800`362ed330 fffff802`be650ed4 ffffd000`575b4bd0 ffffe800`b1b54ca0 : nt!IopProcessWorkItem+0x76
ffffd000`575b4b50 fffff802`be6ee514 : 00000000`00000000 ffffe800`b1ae3880 ffffe800`b1ae3880 ffffe000`50832900 : nt!ExpWorkerThread+0x293
ffffd000`575b4c00 fffff802`be76f2c6 : ffffd000`55503180 ffffe800`b1ae3880 ffffd000`5550f7c0 00000014`00000006 : nt!PspSystemThreadStartup+0x58
ffffd000`575b4c60 00000000`00000000 : ffffd000`575b5000 ffffd000`575af000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND:  kb

FOLLOWUP_IP:
e1r64x64+280e7
fffff800`372520e7 813ddfd0030001000500 cmp dword ptr [e1r64x64+0x651d0 (fffff800`3728f1d0)],50001h

SYMBOL_STACK_INDEX:  b

SYMBOL_NAME:  e1r64x64+280e7

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: e1r64x64

IMAGE_NAME:  e1r64x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  531f9173

FAILURE_BUCKET_ID:  0x1E_c0000005_e1r64x64+280e7

BUCKET_ID:  0x1E_c0000005_e1r64x64+280e7

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x1e_c0000005_e1r64x64+280e7

FAILURE_ID_HASH:  {6d380028-1764-7d25-d8c5-05559a475808}

So it seems that this intel driver has issues with VMQ.

VMQ is quite famous for NIC vendors and buggy drivers in Server 2012 R2

Disabling VMQ is not an option for us in production. We need it to work

Can anyone please confirm this issue exists on the latest 19.3 driver in Server 2012 R2?

Any idea when it will get fixed?

I'm shocked that such an awful bug would exist 12 months after launch of Server 2012 R2 on latest intel drivers for a technology that MS and Intel co-developed.

I would expect this kind of thing from Broadcom, i wouldnt expect it from Intel. Thats why we buy Intel

Perhaps we made a mistake there...

Help and comments appreciated

I've run into a one-way transmission issue with FreeBSD and Virtual Functions on an Intel 10GbE X520. So far we've tested:

•     Ubuntu 12.04 LTS
•     CentOS 6.5
•     pfSense 2.1 / FreeBSD 8.3
•     pfSense 2.2 / FreeBSD 10.0 (alpha)
•     FreeBSD 8.3-STABLE

All are instances are running on top of KVM installed on Ubuntu 14, hosted on Intel Grizzly Pass OEM hardware with the above-mentioned card installed. The card's two 10GbE ports are connected back-to-back.

In our test case, all instances above have a VF inside VLAN 100 and are bridged via the 82599 controller's internal L2 'switch.' The Ubuntu and CentOS instances can reach each other on their VF/VLAN100 interfaces, but any FreeBSD instance spun up cannot. tcpdump on a CentOS instance and a FreeBSD instance show the FreeBSD instance send an ARP request, the CentOS instance receive it and respond, but it never reaches the FreeBSD instance. Since this is not an issue on Ubuntu or CentOS, and has persisted across two versions of FreeBSD and two Intel VF driver versions, I have to assume it's unique to FreeBSD. The examples below are between FreeBSD 8.3-STABLE and CentOS 6.5:

freebsd1# tcpdump -i ix0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ix0, link-type EN10MB (Ethernet), capture size 96 bytes
21:24:44.137249 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:45.144856 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:46.154881 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:47.164913 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:48.174898 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:49.184903 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:50.194905 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:51.204917 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:52.214924 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:53.224947 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:54.234961 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:55.245032 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
21:24:56.255034 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
^C
13 packets captured
13 packets received by filter
0 packets dropped by kernel

[root@centos1 ~]# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:24:44.274997 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:44.275053 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:45.282609 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:45.282651 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:46.292589 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:46.292602 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:47.302563 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:47.302576 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:48.312541 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:48.312553 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:49.322596 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:49.322609 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:50.332542 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:50.332553 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:51.342602 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:51.342614 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:52.352554 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:52.352566 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:53.362614 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:53.362627 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:54.372599 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:54.372611 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
17:24:55.382681 ARP, Request who-has 192.168.100.101 tell 192.168.100.253, length 28
17:24:55.382802 ARP, Reply 192.168.100.101 is-at 52:54:00:db:57:b2 (oui Unknown), length 28
^C
24 packets captured
24 packets received by filter
0 packets dropped by kernel

freebsd1# uname -a
FreeBSD freebsd1 8.3-RELEASE FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64

freebsd1# dmesg | grep Virtual
CPU: QEMU Virtual CPU version 2.0.0 (2793.29-MHz K8-class CPU)
ix0: <Intel(R) PRO/10GbE Virtual Function Network Driver, Version - 1.1.2> mem 0xfebf0000-0xfebf3fff,0xfebf4000-0xfebf7fff at device 5.0 on pci0

freebsd1# ifconfig ix0
ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
ether 52:54:00:44:99:6c
inet6 fe80::5054:ff:fe44:996c%ix0 prefixlen 64 scopeid 0x3
inet 192.168.100.253 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect
status: active

Our issue is identical in description to this post. However, there is no "Simulated MSI Support" option in our BIOS and I believe that particular option was unique to his board based on Intel's BIOS release notes. Another individual ran into a similar problem with FreeBSD 10.0.

Note that pfSense runs v1.1.4 of the Intel VF driver. If you look here, Intel provides a link to e1000 FreeBSD VF drivers. However, no VF-specific drivers are mentioned for ixgbe. There is _vf.h and _vf.c source code in the FreeBSD tree, but we have been unable to compile newer drivers and get them to load.

I'm currently at a loss. I can provide whatever additional information may be helpful; I'm not sure what else is useful at this point. I've dumped some additional info below.

On the host, SR-IOV and IOMMU are enabled. The 10GbE card is on PCI bus 81:00:

root@ubuntu:~# dmesg | grep Intel | grep ixgbe
[ 8.690398] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 3.15.1-k
[ 8.690398] ixgbe: Copyright (c) 1999-2013 Intel Corporation.
[ 8.950982] ixgbe 0000:81:00.0: Intel(R) 10 Gigabit Network Connection
[ 9.211614] ixgbe 0000:81:00.1: Intel(R) 10 Gigabit Network Connection

VFs are enabled at the host level:

root@ubuntu:~# lspci -s 81:
81:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
81:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
81:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:10.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:10.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:11.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:12.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
81:13.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)

The virtual functions with several instances spun up. VF3 is centos1, VF6 is freebsd1.

root@ubuntu:~# ip link show dev eth4
5: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 90:e2:ba:47:2c:30 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 2 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 3 MAC 52:54:00:db:57:b2, vlan 100, spoof checking on, link-state auto
vf 4 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 5 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 6 MAC 52:54:00:44:99:6c, vlan 100, spoof checking on, link-state auto
vf 7 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 8 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 9 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 10 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 11 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 12 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 13 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 14 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
vf 15 MAC 00:00:00:00:00:00, spoof checking on, link-state auto

KVM is also pleased:

root@ubuntu:~# virsh nodedev-list | grep 81
pci_0000_81_00_0
pci_0000_81_00_1
pci_0000_81_10_0
pci_0000_81_10_1
pci_0000_81_10_2
pci_0000_81_10_3
pci_0000_81_10_4
pci_0000_81_10_5
pci_0000_81_10_6
pci_0000_81_10_7
pci_0000_81_11_0
pci_0000_81_11_1
pci_0000_81_11_2
pci_0000_81_11_3
pci_0000_81_11_4
pci_0000_81_11_5
pci_0000_81_11_6
pci_0000_81_11_7
pci_0000_81_12_0
pci_0000_81_12_1
pci_0000_81_12_2
pci_0000_81_12_3
pci_0000_81_12_4
pci_0000_81_12_5
pci_0000_81_12_6
pci_0000_81_12_7
pci_0000_81_13_0
pci_0000_81_13_1
pci_0000_81_13_2
pci_0000_81_13_3
pci_0000_81_13_4
pci_0000_81_13_5
pci_0000_81_13_6
pci_0000_81_13_7

The FreeBSD instance in question is on pci_0000_81_11_4, which maps to VF6 above.

KVM XML for the freebsd1's interface:

        <interface type='hostdev' managed='yes'>          <mac address='52:54:00:44:99:6c'/>          <source>            <address type='pci' domain='0x0000' bus='0x81' slot='0x11' function='0x4'/>          </source>          <vlan>            <tag id='100'/>          </vlan>          <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>        </interface>

FYI - we allow KVM to assign the MAC, etc. We only supply the bus, slot, and function numbers when adding a VF-based interface to the instance.

Thanks to anyone who reads and responds. I could really use some help. I've made similar posts on the FreeBSD and pfSense forums, as well as in both /r/freebsd and /r/pfsense on reddit. gonzopancho on reddit directed me to this link, which has a number of patches written by Ryan Stone. It seems like this may be a known issue. At this point we're just looking for confirmation that we aren't crazy. I've felt like this for a week.

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

Hi all

Currently with the all available versions of the Windows 8.1 x64 I218-V you cannot use Wake On Lan if you have fastboot enabled, which is extremely painful.

Specs of system:

Operating System: Windows 8.1 Pro 64-bit

CPU: Intel Pentium G3420

RAM: 8.00GB DDR3 (9-9-9-27)

Motherboard: ASUS Z97M-PLUS

HDD: 500gb WD Black

This is a media pc, which really would make use of fastboot.

I've tried the drivers, all versions available, from the ASUS site:

Intel LAN Driver V12.11.96.1

Intel LAN Driver V19.0.27.0

This new driver from Intel site:

PROWinx64.exe 19.3

BIOS has correct settings to allow wake on lan.

Every single kind of power related setting imaginable to disable management on ALL devices, full power mode ahead. No joy.

No matter what options you use this horrendous set of drivers does not allow wake on lan with fast boot enabled, unlike every single realtek nic based mobo i've ever used.

I doubt that it will be fixed, or if Intel engineers even read these forums. But here's to hoping...

While it works without fast boot enabled, this is not a fixed. Merely a bandaid to the dodgy driver.

Hi, when I try to install on my NUC D34010WYKH2 + Intel Dual Band Wireless-AC 7260 the latest build of WiDi program on Windows 8.1, I get the message that the OS isn't compatible! How it's possible? 8.1 is certified for work with WiDi, I ask someone for help, please.

My NIC stops working by showing an .  I disabled it., uninstalled, tried to update it, the problem remains the same.  Shutting down the computer or Reboot it will prompt the error message:  PXE-E05: The LAN adapter's NVM configuration is corrupted. But, it will boot properly after.

When I tried to update it, it will stop by prompting: "Cannot install drivers. No Intel(R) Adapters are present in this computer (see attachment)".  In the BIOS, I reset it to the default, checked the boot order (the NIC is the last one in the list, which is normal).  I disable WOL. The problem persists.

I don't know what to do now.  I'm wondering if resetting the Laptop to the Factory default, by the reinstalling the OS, will solve the issue?  Since it said, while updating the driver, No Intel(R) Adapters are present.  In device manager, the adapter is still present with the .

I restored my laptop to a previous Restore Point. Nothing!

If someone has a solution, please, Help!

Hi, Is the intel lan chip I217 can support Wake On Lan after remove AC -> plug AC

If yes, how to use it?

If not, why? Any limitations?

I have installed Intel Pro/1000 dual (EXPI9402PTBLK) - with two ports/connections.

My software tells me that I have two MAC adresses but how do I know which one belongs to upper/lower port ?

Hi,

I recently installed Network Connections 19.3.141.0 for a 82579LM LAN adapter and all appears OK, except when looking at the driver Link Speed tab, Link Status is displaying

"1.00 GbpsNotAvailable"

Tried uninstall and reinstall, and on three different machines - all the same problem.  Previous version gave duplex status, rather than "NotAvailable".

Screen shot attached.

Any ideas please?

Driver version: 12.10.29.0

OS: Win 7 Pro 64bit

Hi,

I was wondering. On the Intel driver under Windows 2008 R2, in the driver settings, there is an option called "Low Latency Interrupts" where we can define particular TCP ports to bypass the interrupt moderation and trigger immediate interrupt.

I would be interested in that feature however I would like intel to confirm it would work on my system.

Earlier this year I have asked if the 1200v3 series Xeon E3 supported I/OAT and I have been answered by a negative answer.

Therefore, I'm not too sure if my system would support low latency inetrrupts.

If I cannot use Low Latency Interrupts, I'll just turn off interrupt moderation, altough it could be useful for less latency sensitive traffic.

So my question is :

Can Low Latency Interrupts work on an E3-1200v3 series system (I have an E3-1241v3), or not? Because I see it in driver options...

However, here at this link: Intel® I/O Acceleration Technology, it seems that Low Latency Interrupts are part of I/OAT.

And if the answer to this question is not, I would have a feature request:

PLEASE have this feature greyed out or non apparent on the systems that do not support it, because it's confusing and could lead to bad decisions taken thinking it works.

Thanks

I am in the process of setting up a Synology NAS which connects to a Netgear ProSafe XS712T through an SFP+ card.

I have 5 PCs (all Win 7 ultimate) that will be using X540-T2 cards. We have installed one card today and have 4 more shipping in.

Installation of the card and drivers went fine and I can see/configure the ports. However, no matter what cable I use to connect to the XS712T switch, I cannot get a visual signal through LED connection and windows just says Network Cable Unplugged. I have used Cat5, Cat6, and Cat 7 (shielded) cables and none of them provide any response. I have even tried connecting to a 1gig switch I also have on the network.

Any suggestions to help diagnose this problem are appreciated.

Thank you!

Hi Everybody

I am facing a scalability issue when using SR-IOV with multiple 82599ES NICs. I have 2 x520 Network adapters containing a total of 4 82599ES controllers. SR-IOV is enabled on each of them with "modprobe ixgbe max_vfs=8" option. The server used is Dell PowerEdge M620 with 4 KVM hosted VMs. Each VM has a VF added from a separate 82599 NIC.

The problem is that the combined RX+TX rate for 64 Bytes UDP packets doesn't extend beyond ~23MPPS.

So if only 1 VM is started, it can RX+TX at ~23 MPPS (almost ~11.5 MPPS each). However when second VM is booted, the rate for each VM becomes 5.5 MPPS for RX and 5.5 MPPS for TX (still a 23 MPPS combined RX+TX for both VMs). Kindly see the table below:

No. of VMs:                                1          2          4

Each VM's RX rate (MPPS):       11.5       5.5       2.8

Each VM's TX rate (MPPS):       11.5        5.5       2.8

So a total of ~23MPPS in each case. Any idea where the bottleneck can be?

I have tried these optimizations/settings but no improvement is seen:

1) Guest Memory is backed by (mapped on) hugepages on Host. Memory is from same socket on which VM is running. Also sibling cores are used.

2) vCPUs have been pinned down to physical CPUs.

3) The MSI-X interrupts of the VF used are mapped on the respective VM cores.

4) SR-IOV global, Intel VT-d and IOAT is enabled in BIOS.

5) Updating the IXGBE driver on host to latest (3.22.3) version didn't improve this.

Testbed details:

My system is Dell PowerEdge M620.

Host OS: RHEL 6.5

Guest OS: Ubuntu 13.10

IXGBE driver version: 3.15.1-k

I am running DPDK 1.6.0 on KVM hosted Guests.

Any help will be greatly appreciated.

Thank you

Umar

I have 3 HP Z800 workstations I am installing X540-T2 card into which are teamed to 802.3ad.

The first PC has installed fine and running smooth.

PC 2 and 3 the cards installed fine and work for about 5 minutes and then shut off due to overheating. The syncs are noticeably hot to touch.

The only difference spec wise is PC 1 has a mid range card where PC 2 and PC 3 have Nvidia GTX 980 cards and sata cards installed in each.

I have taken the cards out and put them into another Z800 box that is similar to PC 1 and have not had any issues overheating. Though I was only able to test over a 1gb connection.

I am fairly certain the cards were seated correctly in all instances.

I have the most current drivers/firmware for the X540-T2 cards installed.

Cards are installed into the last slot, closet to the bottom of the case. I believe this is slot 8.

Looking for any help or guidance as to where/how to check temperatures and power to the cards. Or any other information that might help me control this overheating issue.

Thank you in advance!