Hi All,

I was trying to test 100base T in Mdix mode,however Lanconf doesn't support MDI-x directly,looks like phy register has to be modified in order to get signal in mdix mode.

Does anybody know how to make these changes.?

Regards

bala

Hello,

I am trying to  use the x710 MAC/VLAN filtering option to steer packets to receive queues based on strict MAC address match.

I need to filter and steer around 100 MAC addresses to 8 receive queues.  Because of the development environment constraints I cannot use

SRIOV, IOV, VEB or flex partitioning.

My configuration is as follows:

Default simple switch configuration

One PF and one VSI with 8 queues

RSS, Ether type and Flow director filters are disabled and MAC/VLAN filter is  enabled.

I am  setting toQueue flag to steer packets to the appropriate queue.

However I don't see packets getting steered to the desired queue. Packet steering is not happening and packets always  land  on the same queue.

Do I need to configure the switch with "Set Switch" command to get filtering work as described above?

How do I initialize the VSI to support the above flow.

Are there any other other configuration settings that need to be done to get the packets steered as described above?

Thanks,

Sony

I am designing a system that will use the x550.  I want to have the future possibility of IEEE 1588 precision time protocol.  The SDP (software defined pins) of the x550 will be connected to an FPGA for this purpose.  Is it important to have an ultra accurate clock source on the x550 for 1588?  Or does the FPGA require this clock source?

I have trouble updating firmware for X710DA4 card.

This card drops connection at random with Linux 4.9.9 driver.

The driver requires firmware update.  But I tried all three versions

at Intel website and all said update not available.

Any help would be much appreciated.

ethtool -i ens4f1

driver: i40e

version: 2.0.19

firmware-version: 4.10 0x800011c5 0.0.0

expansion-rom-version:

bus-info: 0000:02:00.1

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

lspci does not show serial number:

Capabilities: [e0] Vital Product Data

                Product Name: XL710 40GbE Controller

                Read-only fields:

                        [PN] Part number:

                        [EC] Engineering changes:

                        [FG] Unknown:

                        [LC] Unknown:

                        [MN] Manufacture ID:

                        [PG] Unknown:

                        [SN] Serial number:

                        [V0] Vendor specific:

                        [RV] Reserved: checksum good, 0 byte(s) reserved

                Read/write fields:

                        [V1] Vendor specific:

                End

When I install the driver ver 21.1 Download Intel® Network Adapter Driver for Windows® 10  I get a message

"Important Note:  Creating Intel® ANS teams and VLANs on Microsoft Windows® 10 is currently not supported.  As a result, when created, teams and VLANs do not pass traffic.  We expect that ANS will be supported on Microsoft Windows 10 client in a future release"

I dont need teaming etc...but once the driver is installed, I dont see WOL in the ADVANCED option  ???

Where is the WOL feature???

Thanks,

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

Hello,

I would like to use the i210-AT as part of a 1000BASE-T backplane design. I have a plug-able network switch with on-board magnetics and would like to interface to an i210-AT without adding an additional transformer.

I came across a thread that discussed this application and included the name of an application note, but i have been unable to actually find the app note or any official documentation.

Link to old thread: Ethernet phy i210 transformerless |Embedded Community

Thanks,

Dave

Following all the events at I211/I217-V Windows 10 LACP teaming fails and networking - USB to Ethernet adapter supporting multiple virtual LANs - Hardware Recommendations Stack Exchange, we now have an Ethernet driver that should properly support the Intel Advanced Networking Suite (iANS) under Windows 10.

Using Windows 10.0.14393 with all updates installed, with an I217-LM adapter and the 22.0.1 driver installed.  Things seem to be very flaky.  My focus here is primarily on being able to work with multiple VLANs, with no trunking at present.

First - when creating new VLANs, ensure that the "Network Connections" window or any similar windows other than the "Intel(R) Ethernet Connection * Properties" dialog are closed.  Not doing so will frequently result in the operation hanging indefinitely.  (I remember the same from when we had the working drivers here in Windows 7 and Windows 8 days.)  Even with the other windows closed, sometimes it is taking almost 5 minutes to create a new VLAN - but it takes even longer to do so with the "Network Connections" window open (if it completes at all).

With this out of the way:  Add a new VLAN10.  Only once one VLAN is created can we then create the "Untagged VLAN" (ID 0).  Reboot.  Everything still works and comes back up as expected.

Add a 2nd tagged VLAN, say VLAN11.  Reboot.  The "Untagged VLAN" fails to pull a DHCP lease.  The virtual adapter shows packets being sent and received.  I ran Wireshark on the Untagged VLAN adapter, saw DHCPDISCOVER packets go out, and other unrelated broadcasts and packets coming back - but no DHCPOFFERs returned.  I.E., it seems to be missing traffic in that state.  Disable the Untagged VLAN adapter, re-enable, and it instantly comes back with a valid lease.  This is constantly repeatable.  Nothing is even connected to the other side of these VLANs yet (the connected switchport isn't even trunked).  Remove the 2nd tagged VLAN leaving only one tagged VLAN and the untagged, and things work much better - but this kind of defeats the purpose.

Here's my ugly hack of a work-around for now:  Add a Windows Scheduled Task to run at System Startup, and to run with highest privileges.  Use a PowerShell similar to the following as the action:

$(  Get-Date  Write-Host "Starting..."  ipconfig.exe /all  Write-Host "Restarting..."  Restart-NetAdapter -Name "Ethernet - Untagged" -Confirm:$false  ipconfig.exe /all  Get-Date  Write-Host "Done."
) *>&1 > C:\FixIntelNetwork.log

I was worried about timing, and could add a 30 second delay or such in the startup trigger.  However, the ipconfig outputs show that this wasn't necessary.  In the first ipconfig output, the adapter was present and already had an auto-configured 169.254.x.y IP address.  In the second ipconfig output, a proper DHCP lease was shown.

As I don't have anything on the other VLANs to test with yet, I still need to determine - but may have to reset the other VLAN interfaces at startup as well.

The link to latest is 5.05, looking for 5.51 recommended for XVV710.

Currently, I have the following:

# ethtool -k p1p2

Features for p1p2:

rx-checksumming: on

tx-checksumming: on

    tx-checksum-ipv4: on

    tx-checksum-ip-generic: off [fixed]

    tx-checksum-ipv6: on

    tx-checksum-fcoe-crc: on [fixed]

    tx-checksum-sctp: on

scatter-gather: on

    tx-scatter-gather: on

    tx-scatter-gather-fraglist: off [fixed]

tcp-segmentation-offload: on

    tx-tcp-segmentation: on

    tx-tcp-ecn-segmentation: off [fixed]

    tx-tcp6-segmentation: on

udp-fragmentation-offload: off [fixed]

generic-segmentation-offload: on

generic-receive-offload: on

large-receive-offload: on

rx-vlan-offload: on

tx-vlan-offload: on

ntuple-filters: off

receive-hashing: on

highdma: on [fixed]

rx-vlan-filter: on [fixed]

vlan-challenged: off [fixed]

tx-lockless: off [fixed]

netns-local: off [fixed]

tx-gso-robust: off [fixed]

tx-fcoe-segmentation: on [fixed]

tx-gre-segmentation: off [fixed]

tx-udp_tnl-segmentation: on

fcoe-mtu: off [fixed]

tx-nocache-copy: on

loopback: off [fixed]

rx-fcs: off [fixed]

rx-all: off [fixed]

tx-vlan-stag-hw-insert: off [fixed]

rx-vlan-stag-hw-parse: off [fixed]

rx-vlan-stag-filter: off [fixed]

I need rx-fcs and rx-all on. The only message I could find on the topic was from 2014, and said that this might be supported in a future release.

We're using:

driver: ixgbe

version: 5.0.4

firmware-version: 0x18b30001

bus-info: 0000:04:00.1

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

Linux HOSTNAME 3.10.105-1.el6.elrepo.x86_64 #1 SMP Fri Feb 10 10:48:08 EST 2017 x86_64 x86_64 x86_64 GNU/Linux

LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch

Distributor ID:    CentOS

Description:    CentOS release 6.8 (Final)

Release:    6.8

Codename:    Final

Not sure what other data to provide.

If this card/chipset will not support this, what will?

Windows 8.1 Enterprise 64 bit edition

ASRock QC 5000 ITX Mainboard

Intel Desktop CT GBe PCIe adapter

Using Proset release 21

The OS will automatically detect and bring the card up. What I'm needing in addition is the ANS suite so I can team adapters in a LAG.

The OS installation is brand new as of 4 hours ago to a 240GB SSD.

Image may be NSFW.
Clik here to view.

Greetings,

I'm following the directions from document 513655. Running EEUPDATE shows my two i210 controllers (one working, and one blank). Using both EEUPDATE & LANConf to attempt to program the blank flash results in a timeout error that occurs after 5+ minutes of the tool claiming that it is writing to flash.

LANCOnf gives the following: c86a0004 - "Timeout Error" when programming i210 blank flash

I'm using the following versions on an Intel Atom E3815 processor on Ubuntu 16.04.2

eeupdate64e: EEUPDATE v5.26.17.11

lanconfig64e: LANConf v1.26.17.11

lshw shows the driver as: driver=igb driverversion=5.3.0-k

I've tried flashing with multiple 4Mb files onto a 4Mb flash On Semi LE25U40CMC

Below is the eeupdate log:

_________________________________________________________

root@ubuntu-serv-slim:/# ./eeupdate64e /NIC=1 /DATA Dev_Start_I210_Copper_NOMNG_4Mb_A2_3.25_0.03.bin

Using: Intel (R) PRO Network Connections SDK v2.26.17

EEUPDATE v5.26.17.11

Copyright (C) 1995 - 2015 Intel Corporation

Intel (R) Confidential and not for general distribution.

Driverless Mode

NIC Bus Dev Fun Vendor-Device  Branding string

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

  1   2  00  00   8086-1531    Intel(R) I210 Blank NVM Device

  2   4  00  00   8086-1533    Intel(R) I210 Gigabit Network Connection

Writing SHARED FLASH.  PLEASE DO NOT INTERRUPT THIS PROCESS.

  1:  Shared Flash image update FAILED! Timeout Error

_____________________________________________________

I've attempted to access the most recent tools in document 348742 below but get "Access Denied: Privileged Access Required"

I have R&DC privileges  and was able to download the I210 flash images.

https://www-ssl.intel.com/content/www/us/en/secure/embedded/nda/products/networking/networking-connections-software-tool…

Any suggestions you have are appreciated.

Enjoy,

Jason

Hi all,

Same problem here.

One tagged VLAN (6) and untagged VLAN. After every reboot the untagged VLAN doesn't work until I disable and re-enable the Untagged VLAN virtual adapter. The VLAN6 doesn't present this problem and can ping other hosts in the same VLAN.

NIC is connected to a Cisco switch with the following config:

nwcore2#sh run | s 2/0/39

interface GigabitEthernet2/0/39

description AURELIO (0B39D)

switchport trunk allowed vlan 1,6

switchport mode trunk

spanning-tree portfast trunk

spanning-tree bpduguard enable

Let me know if you need any information to try to detect the issue. As ziesemer I have no dump as the system doesn't crash.

Best regards

Aurelio Llorente

Hi,

I'd like to setup MAC loopback for a NIC interface? I attempted to modify (IXGBE) linux kernel driver to setup the loop back. Apparently, the kernel crashes with Tx hang detected with timeout.

The watchdog timer kicks in.

a) NIC is not connected to any SFP+. Thus, link does not come up. I'd like to setup MAC loopback (tx <--> rx).

1) i run the "ethtool -t enp4s0f1" to setup mac loop back.

  Action:  I commented out the loop back run and loop back clear after setting up the loop back as I'd like to keep the MAC loop back persistent.

  Therefore, I commented out (ixgbe_run_loopback_test) and ixgbe_loopback_cleanup in the function ixgbe_loopback_test in ixgbe_ethtool.c

ethtool -t enp4s0f1

# ethtool -t enp4s0f1

The test result is PASS

The test extra info:

Register test  (offline)     0

Eeprom test    (offline)     0

Interrupt test (offline)     0

Loopback test  (offline)     0

Link test   (on/offline)     1

Then, in the kernel log (dmesg), The link comes back up for the interface (enp4s0f1) and kernel panics.

I also attempted to port DPDK loopback driver patch into linux kernel ixgbe driver (ixgbe-5.0.4). But, I'm still having issues with it.

Can you please tell me what needs to be done? Do you have linux kernel patch associated with it?

This is the patch that needs to be ported to Linux kernel driver.

DPDK Patch dpdk - Data Plane Development Kit

I'd appreciate if you could provide me the kernel patch or work around to this problem?

Thanks

Chakri

dmesg

-------

[ 2015.712158] ixgbe 0000:04:00.1 enp4s0f1: loopback testing starting

[ 2015.734989] ==> [ixgbe_setup_loopback_test] adapter enp4s0f1 orig_autoc = 0xC09C6084 hlreg=0x800afff

[ 2015.759805] ==> [ixgbe_setup_loopback_test] adapter enp4s0f1 wrote autoc = 0xC09C6085

[ 2015.759942] ixgbe 0000:04:00.1 enp4s0f1: NIC Link is Up 10 Gbps, Flow Control: RX/TX

[ 2020.125844] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0f1: link becomes ready

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

[ 2025.643280] WARNING: CPU: 1 PID: 22 at net/sched/sch_generic.c:306 dev_watchdog+0x246/0x250()

[ 2025.667460] NETDEV WATCHDOG: enp4s0f1 (ixgbe): transmit queue 1 timed out

[ 2025.688363] Modules linked in: ixgbe(O) vhost_net vhost macvtap macvlan tun xfs nbd vxlan ip6_udp_tunnel udp_tunnel binfmt_misc deflate twofish_generic twofish_avx_x86_64 twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 camellia_x86_64 serpent_avx2 serpent_avx_x86_64 serpent_sse2_x86_64 xts serpent_generic blowfish_generic blowfish_x86_64 blowfish_common cast5_avx_x86_64 cast5_generic cast_common des_generic cmac xcbc rmd160 sha512_ssse3 sha512_generic af_key rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache bonding vfat fat intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul aesni_intel lrw gf128mul glue_helper ablk_helper cryptd sb_edac edac_core sg 8250_fintek ipmi_si ipmi_msghandler acpi_power_meter shpchp

[ 2025.964188] Hardware name: Wiwynn SV7220G2-V 81.B0F01.007G/SV7220G2 MB, BIOS LP4B_V02 07/20/2015

[ 2025.964193]  0000000000000286 0000000088422274 ffff881feaa37c68 ffffffff81342f20

[ 2025.964196]  ffff881feaa37cb0 0000000000000009 ffff881feaa37ca0 ffffffff81081b72

[ 2025.964198]  0000000000000001 0000000000000001 ffff881ec89c7b00 ffff881ec8ae0000

[ 2025.964199] Call Trace:

[ 2025.964209]  [<ffffffff81342f20>] dump_stack+0x65/0x85

[ 2025.964215]  [<ffffffff81081b72>] warn_slowpath_common+0x82/0xd0

[ 2025.964220]  [<ffffffff81081c1c>] warn_slowpath_fmt+0x5c/0x80

[ 2025.964227]  [<ffffffff8160bf06>] dev_watchdog+0x246/0x250

[ 2025.964230]  [<ffffffff8160bcc0>] ? dev_graft_qdisc+0x80/0x80

[ 2025.964236]  [<ffffffff810f60f5>] call_timer_fn+0x35/0x1a0

[ 2025.964238]  [<ffffffff8160bcc0>] ? dev_graft_qdisc+0x80/0x80

[ 2025.964241]  [<ffffffff810f6399>] run_timer_softirq+0x139/0x300

[ 2025.964244]  [<ffffffff81086f4f>] do_current_softirqs+0x1ef/0x410

[ 2025.964247]  [<ffffffff81087216>] run_ksoftirqd+0x26/0x50

[ 2025.964253]  [<ffffffff810a6184>] smpboot_thread_fn+0x244/0x330

[ 2025.964257]  [<ffffffff810a5f40>] ? smpboot_register_percpu_thread_cpumask+0x130/0x130

[ 2025.964260]  [<ffffffff810a26b8>] kthread+0xd8/0xf0

[ 2025.964263]  [<ffffffff810a25e0>] ? kthread_worker_fn+0x150/0x150

[ 2025.964268]  [<ffffffff81711aff>] ret_from_fork+0x3f/0x70

[ 2025.964271]  [<ffffffff810a25e0>] ? kthread_worker_fn+0x150/0x150

[ 2025.964273] ---[ end trace 0000000000000002 ]---

[ 2026.461693] ixgbe 0000:04:00.1 enp4s0f1: Fake Tx hang detected with timeout of 5 seconds

[ 2036.619964] ixgbe 0000:04:00.1 enp4s0f1: Reset adapter

I have a 10G 82599ES intel card on Ubuntu 14.04.5 LTS , details below :

description: Ethernet interface

product: 82599ES 10-Gigabit SFI/SFP+ Network Connection

vendor: Intel Corporation

physical id: 0

bus info: pci@0000:86:00.0

logical name: eth8

version: 01

serial: 90:e2:ba:c8:52:1c

width: 64 bits

clock: 33MHz

capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical fibre

configuration: autonegotiation=off broadcast=yes driver=ixgbe driverversion=3.15.1-k firmware=0x61b50001 latency=0 link=no multicast=yes

resources: irq:64 memory:fb180000-fb1fffff ioport:e020(size=32) memory:fb204000-fb207fff memory:fb580000-fb5fffff memory:fb900000-fb9fffff memory:fb80000

Other side is 1G port , i see link is not getting detected when cable is connected

root@blrvbng03:~# ethtool eth9

Settings for eth9:

        Supported ports: [ FIBRE ]

        Supported link modes:   10000baseT/Full

        Supported pause frame use: No

        Supports auto-negotiation: No

        Advertised link modes:  10000baseT/Full

        Advertised pause frame use: No

        Advertised auto-negotiation: No

        Speed: Unknown!

        Duplex: Unknown! (255)

        Port: Other

        PHYAD: 0

        Transceiver: external

        Auto-negotiation: off

        Supports Wake-on: d

        Wake-on: d

        Current message level: 0x00000007 (7)

                               drv probe link

        Link detected: no

root@blrvbng03:~#

Try setting the speed to 1000 and auto negotiation also, but failing

root@blrvbng03:~# ethtool -s eth9 autoneg on

Cannot set new settings: Invalid argument 

  not setting autoneg                     

root@blrvbng03:~#

root@blrvbng03:~# ethtool -s eth9 advertise 0x020

Cannot set new settings: Invalid argument

root@blrvbng03:~#

How i can resolve this issue ?

Thanks,

Agnel.

Hi all experts :

we are using the Intel I350AM2 ( Two GE Ports ) chip to interface the Cortex-A8 SoC from TI through PCIE x 2 bus .

The OS version is Linux 2.6.37

The I350 driver version is 5.0.6

and after some hours , we found the log as below with GDB backtrace info.

igb 0000:01:00.0: Detected Tx Unit Hang

  Tx Queue             <0>

  TDH                  <c9>

  TDT                  <c9>

  next_to_use          <c9>

  next_to_clean        <de>

buffer_info[next_to_clean]

  time_stamp           <91811>

  next_to_watch        <ffc17df0>

  jiffies              <91b40>

  desc.status          <1568200>

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

WARNING: at net/sched/sch_generic.c:258 dev_watchdog+0x148/0x230()

NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out

Modules linked in: aur5g8ke_face_lcd avst_digit_audio ti81xxhdmi ti81xxfb vpss osa_kermod syslink

Backtrace:

[<c004cfac>] (dump_backtrace+0x0/0x110) from [<c033900c>] (dump_stack+0x18/0x1c)

r6:c042b298 r5:00000102 r4:c0457df0 r3:60000113

[<c0338ff4>] (dump_stack+0x0/0x1c) from [<c0072910>] (warn_slowpath_common+0x54/0x6c)

[<c00728bc>] (warn_slowpath_common+0x0/0x6c) from [<c00729cc>] (warn_slowpath_fmt+0x38/0x40)

r8:c02c78bc r7:00000100 r6:00000000 r5:c04cb59c r4:cdc0c000

r3:00000009

[<c0072994>] (warn_slowpath_fmt+0x0/0x40) from [<c02c7a04>] (dev_watchdog+0x148/0x230)

r3:cdc0c000 r2:c042b2b0

[<c02c78bc>] (dev_watchdog+0x0/0x230) from [<c007cc1c>] (run_timer_softirq+0x130/0x1c8)

r6:00000100 r5:c0456000 r4:c04b7c40

[<c007caec>] (run_timer_softirq+0x0/0x1c8) from [<c00777b4>] (__do_softirq+0x84/0x114)

[<c0077730>] (__do_softirq+0x0/0x114) from [<c0077ba4>] (irq_exit+0x48/0x98)

[<c0077b5c>] (irq_exit+0x0/0x98) from [<c003f07c>] (asm_do_IRQ+0x7c/0x9c)

[<c003f000>] (asm_do_IRQ+0x0/0x9c) from [<c033aff4>] (__irq_svc+0x34/0xa0)

Exception stack(0xc0457f18 to 0xc0457f60)

7f00:                                                       c0496610 00000002

7f20: cbaa8000 5efe1920 cbaa801c c0459040 00000015 c982f8c0 ccd24300 413fc082

7f40: ccd24300 c0457f6c c0457f70 c0457f60 c033b460 c033d01c 60000013 ffffffff

r5:fa200000 r4:ffffffff

[<c033d010>] (atomic_notifier_call_chain+0x0/0x28) from [<c033b460>] (__switch_to+0x2c/0x4c)

[<c0339564>] (schedule+0x0/0x304) from [<c004a69c>] (cpu_idle+0x80/0x90)

[<c004a61c>] (cpu_idle+0x0/0x90) from [<c032d8dc>] (rest_init+0x60/0x78)

r6:c06d0900 r5:c002dd50 r4:c04babbc r3:00000000

[<c032d87c>] (rest_init+0x0/0x78) from [<c0008c08>] (start_kernel+0x264/0x2b8)

[<c00089a4>] (start_kernel+0x0/0x2b8) from [<80008048>] (0x80008048)

---[ end trace bb79dcc8c86613b8 ]---

we have tried to disable the offload option as below but not work , the I350AM2 still hang , btw , we only use the eth0 port now .

Offload parameters for eth0:

rx-checksumming: on

tx-checksumming: on

scatter-gather: off

tcp-segmentation-offload: off

udp-fragmentation-offload: off

generic-segmentation-offload: off

generic-receive-offload: off

large-receive-offload: off

rx-vlan-offload: on

tx-vlan-offload: on

ntuple-filters: off

receive-hashing: on

is there any suggestions on this case ?

Platform is a Dell E6520 Latitude

NIC is the Intel 82579LM GigE

Windows 7 Enterprise x64, fully patched and up to date

Drivers are the latest available from the Intel site.

After updating to the latest version of the Intel Network Connections (INC) v20.7, 201.0 and 21.1 there is a problem when

the Configure button in the NIC properties is selected. Among other things this launches the ncs2prov.exe with this command line.

     "C:\Program Files\Intel\NCS2\WMIProv\NCS2Prov.exe" -Embedding

This program spends the next several minutes issuing millions of I/O calls to enumerate items in the registry and then scan what appears to be most of the C: drive looking for every *.INF it can find among other things...

Tracing this with ProcMon from the MS System Internals tools counts >3.5 million events just from launching the program.  If the machine did not have an SSD, this process would have likely taken a VERY long time in the range of tens of minutes at least I would think.  As it is, it takes a minute or two where the machine appears to be not responding to the Configure request at first launch.

I have tried all three of the latest versions as describe, but they all have the same issue.  Once the program is loaded finally, selecting a different tab starts the same behavior over again and a single tab can take minutes to display and update.  A tab change generates about 2.1 million events each time...

Does anyone know how to stop this behavior?  Why is it scanning the entire C: drive looking for *.INF files?  It is not actually reading their contents most of the time that I can see, it just rescans the C: looking for them....  I know what the .INF and .CAT files are for and generally understand at least the basics of installing drivers and their support files.

It does not appear that it actually has anything to do with the hardware platform, but is a problem with the INC software running on Windows 7 x64.

Any thoughts as to how to stop this would be appreciated.  We can switch back to even older versions, if we knew where the problems were introduced.  Apparently this has existed for a year or maybe more based on the version we have tested thus far.  The drivers overall work well and are much better that the official Dell drivers which do not allow most of the hardware features of the NIC driver to be exposed.  (RSS, R/W buffers, TCP checksum off-loads, disable EEE, etc...)  They are performing at ~60% of the network wire speed instead of about 35% with the OEM drivers.

Thank you,

-CoreyMac

Hello.

Trying to split XL710QDA1 in FreeBSD 12 and get:

[root@host ~]# ./qcu64e /devices                                                                                                                                                                                             [18:42:30]

Intel(R) QSFP+ Configuration Utility

QCU version: v2.27.10.01

Copyright(C) 2016 by Intel Corporation.

Software released under Intel Proprietary License.

NIC Seg:Bus Ven-Dev   Mode    Adapter Name

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

zsh: segmentation fault (core dumped)  ./qcu64e /devices

[root@host ~]# gdb core qcu64e.core                                                                                                                                                                                          [18:43:21]

GNU gdb 6.1.1 [FreeBSD]

Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "amd64-marcel-freebsd"...core: No such file or directory.

Core was generated by `./qcu64e /devices'.

Program terminated with signal 11, Segmentation fault.

#0  0x00000000005051b1 in ?? ()

(gdb)

I tryed fw versions 4.22.26225 and  5.0.40043 . Driver we use 1.6.6.

And I succesfully split it from UEFI.

Hi,

We are using 82576 Gigabit Ethernet Controller, as per the document (8.10.1 Receive Control Register - RCTL (0x00100; R/W)

, page No. 515) attached and also the ethtool output,

- Even if the UPE (Unicast Promiscuous Enable) bit is reset (disabled) we still seem to receive any Unknown Unicast Packets.

- If we disable the MPE (Multicast Promiscuous Enable) bit then we stop receiving any Unknown Unicast Packets.

While I do not see any reason why any one would disable UPE and enable MPE, just wanted to know if it is expected behavior.

Our assumption was that if the UPE bit is disabled then we should NOT receive any Unknown Unicast (assume we do not have any

RAL entries for MAC filtering)

Linux# ethtool -d eth1

0x00000: CTRL (Device control register)               0x40D00240

       Invert Loss-Of-Signal:                         no

       Receive flow control:                          disabled

       Transmit flow control:                         disabled

       VLAN mode:                                     enabled

       Set link up:                                   1

       D3COLD WakeUp capability advertisement:        enabled

       Auto speed detect:                             disabled

       Speed select:                                  1000Mb/s

       Force speed:                                   no

       Force duplex:                                  no

0x00008: STATUS (Device status register)              0x00080383

       Duplex:                                        full

       Link up:                                       link config

       Transmission:                                  on

       DMA clock gating:                              disabled

       TBI mode:                                      disabled

       Link speed:                                    1000Mb/s

       Bus type:                                      PCI Express

0x00100: RCTL (Receive control register)              0x0400803A

       Receiver:                                      enabled

       Store bad packets:                             disabled

       Unicast promiscuous:                           disabled

       Multicast promiscuous:                         enabled

       Long packet:                                   enabled

       Descriptor minimum threshold size:             1/2

       Broadcast accept mode:                         accept

       VLAN filter:                                   disabled

       Cononical form indicator:                      disabled

       Discard pause frames:                          filtered

       Pass MAC control frames:                       don't pass

       Loopback mode:                                 normal

       Receive buffer size:                           2048

The link to latest is 5.05, looking for 5.51 recommended for XVV710.