Quantcast
Channel: Intel Communities : Discussion List - Wired Ethernet
Viewing all 4405 articles
Browse latest View live

FreeBSD ixl0: Malicious Driver Detection event / Flapping / Update firmware not work

$
0
0

Hello;

 

I have a Box (supermicro) with:

 

S.O :    FreeBSD 11.1-STABLE (FreeNAS)

NIC: - Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02).

- Intel(R) Ethernet Connection XL710/X722 Driver, Version - 1.7.12-k

- dev.ixl.0.fw_version: fw 5.0.40043 api 1.5 nvm 5.05 etid 80002a43 oem 1.261.0

 

I have issues with the connection  Flapping on the interfaces 10G and a lot of messages "ixl0: Malicious Driver Detection event 2 on TX queue 2, pf number 0"

 

I m trying to Upgrade the Firmware to 6.0.1; but the procedure (./nvmupdate64e) says:

 

 

 

Num Description                               Ver. DevId S:B    Status

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

01) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:001     Update not

                                                                                                             available

02) Intel(R) Ethernet Controller X710 for     5.05  1572 00:002     Update not

    10GbE SFP+                                                                                  available

 

Tool execution completed with the following status: Device not found.


Is there a MDIO Utility for ixgbe driver for Xeon-D/x552 for Linux

$
0
0

Is there any Linux utility to do MDIO read/write for external PHY on  Xeon-D / X552  SOC running ixgbe driver 5.3.5?

e1000e: GE NIC Link is Down/Up

$
0
0

Hi.

I am having problems with 82574L

 

Hardware :

03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

 

System:

Centos 7.3   kernel:3.10.0-514.el7.x86_64

 

 

Output from message

Feb 26 20:50:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 20:50:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 22:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 22:10:04 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 22:40:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 22:40:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 23:20:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 26 23:20:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 26 23:30:02 localhost kernel: e1000e: slot0_GE2 NIC Link is Down

Feb 26 23:30:02 localhost kernel: e1000e: slot0_GE2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 27 01:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 27 01:10:04 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

Feb 27 03:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Down

Feb 27 03:10:02 localhost kernel: e1000e: slot0_GE4 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

 

 

modinfo

filename:       /lib/modules/3.10.0-514.el7.x86_64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko

version:        3.3.6-NAPI

license:        GPL

description:    Intel(R) PRO/1000 Network Driver

author:         Intel Corporation, <linux.nics@intel.com>

rhelversion:    7.3

srcversion:     6453212B70344504D53DE09

alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*

depends:        ptp

vermagic:       3.10.0-514.el7.x86_64 SMP mod_unload modversions

parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)

parm:           TxIntDelay:Transmit Interrupt Delay (array of int)

parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)

parm:           RxIntDelay:Receive Interrupt Delay (array of int)

parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)

parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)

parm:           IntMode:Interrupt Mode (array of int)

parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)

parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)

parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)

parm:           EEE:Enable/disable on parts that support the feature (array of int)

parm:           Node:[ROUTING] Node to allocate memory on, default -1 (array of int)

parm:           debug:Debug level (0=none,...,16=all) (int)

 

[root@localhost ~]# ethtool -k slot0_GE4

Features for slot0_GE4:

rx-checksumming: on

tx-checksumming: on

tx-checksum-ipv4: off [fixed]

tx-checksum-ip-generic: on

tx-checksum-ipv6: off [fixed]

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

tx-checksum-sctp: off [fixed]

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: off [fixed]

rx-vlan-offload: on

tx-vlan-offload: on

ntuple-filters: off [fixed]

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: off [fixed]

tx-gre-segmentation: off [fixed]

tx-ipip-segmentation: off [fixed]

tx-sit-segmentation: off [fixed]

tx-udp_tnl-segmentation: off [fixed]

tx-mpls-segmentation: off [fixed]

fcoe-mtu: off [fixed]

tx-nocache-copy: off

loopback: off [fixed]

rx-fcs: off

rx-all: off

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

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

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

busy-poll: off [fixed]

tx-sctp-segmentation: off [fixed]

l2-fwd-offload: off [fixed]

hw-tc-offload: off [fixed]

[root@localhost ~]#

X710 SR-IOV VF still working when PF is down

$
0
0

Hi there,

 

I'm using X710-DA4 with SR-IOV mode on Skylake servers.

latest fw and drivers (i40e) installed on system. and vf driver is added into blacklist.

 

there is a VF that belongs to a PF. and that VF is attached to a VM.

after that, I tried ping from VM to a pc that connected to the server port that has the PF.

 

it works well. ping packets are received by the pc.

 

the problem (or different behavior) is that,

even the PF link goes down using "ifconfig xx down or ip link set xxx down" but the VF still sending packet to the pc.

is this right behavior on X710/XL710?

if yes, any architectural/tech background that I can get?

 

Regards,

Intel I219-V VLAN blue screen

$
0
0

Hi.

I am having problems with I219-V VLAN tag. Whan adding  a tag I get blue screen every single time., reason Bad_pool_caller.

 

First step I am adding new VLAN in VLAN tab from Intel Ethernet conection I219-V:

image.png

 

And when adding new VLAN tag, let's say 13 it crashes:

image.png

 

I don't even get a chance to press second OK in Intel window, it crashes right here. It says Configuring for two seconds, maybe tree and the blue screen. I can make it anytime I want.
I tried with versions 12.17.8.7 and 12.15.25.6:

image.png

 

I have Lenovo T470s. Any help would be gratefull.

 

Regards

Intel Omni-path on Ubuntu 16.04 ?

$
0
0

According to documentation Omnipath only support Redhat /Centos /SLES .. Is there any driver or guide to compile driver for Omnipath card for Ubuntu 16.04 ?

 

 

/Zeeshan

i40e x710 4x10G card not working anymore with DAC

$
0
0

Using an updated driver, I cannot seem to get my interfaces up. Looks like the driver is not allowing the NIC to work due to the SFP+ module type, which worked previously on my Debian Stretch host. Clearly the NIC is detecting and reading the DAC, but I don't understand why it is not working. This is a 40G-breakout cable with 40-to-4x10G SFP+ DAC (TwinAx). I have tried adding the following to work around it, but it still does not work:

 

root@lab4:~# cat /etc/modprobe.d/i40e.conf

options i40e allow_unsupported_sfp=1

 

This was also discussed here, but there was no followup:

Intel Ethernet Drivers and Utilities / Mailing Lists

 

Output from dmesg:

[    4.439190] i40e 0000:08:00.3: PCI-Express: Speed 8.0GT/s Width x8

[    4.447918] i40e 0000:08:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 8 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[    4.453414] i40e 0000:08:00.2: Rx/Tx is disabled on this device because an unsupported SFP+ module type was detected.

[    4.465288] i40e 0000:08:00.2: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for a list of supported modules.

 

Other pertinent output:

root@lab4:~# ethtool -m eth6

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)                           : 3m

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                                 : 624400003

Vendor rev                                : A

Option values                             : 0x00 0x00

BR margin, max                            : 0%

BR margin, min                            : 0%

Vendor SN                                 : APF13470035GDT

Date code                                 : 131122

 

root@lab4:~# ethtool -i eth6

driver: i40e

version: 2.4.3

firmware-version: 6.01 0x800034af 1.1747.0

expansion-rom-version:

bus-info: 0000:08:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

 

root@lab4:~# ethtool eth6

Settings for eth6:

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

 

root@lab4:~# ip link show eth6

5: eth6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000

    link/ether 68:05:ca:2f:7c:b0 brd ff:ff:ff:ff:ff:ff

[X710] Secondary ip address doesn't answer arp anymore

$
0
0

Hello.

 

We have 2 servers using X70 nics (Debian Jessie, Kernel 4.14.15).

On each interface we have two ip on same subnet.

Randomly, the secondary ip address doesn’t answer to arp request anymore.

The only solution we have to fix the problem is to manually send arp announcements over the network using a script (while true, sendarp).

There is no proxy arp on neighbors.

 

# ethtool -i eth0

driver: i40e

version: 2.1.14-k

firmware-version: 6.01 0x80003485 1.1747.0

bus-info: 0000:82:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

 

This issue occurs on both servers, and we have same software configuration on a lot  sites, and the problem appear only when there is X710 nics.

 

Anyone already had this problem ?

 

Kind regards


X710 strips incoming vlan tag with SRIOV

$
0
0

Hi,

 

I have a VM using SRIOV interfaces based on X710 interfaces. This VM is connected to a physical router through the VF.

I would like to enable vlan tagging on the VM.

 

I can ping the physical router from the VM if I'm not using VLAN tagging on the interface.

When I add VLAN tagging on the interface (on the VM and on the physical router), the network connectivity is broken.

 

The physical router correctly receives the packets/frames from the VM.

The VM receives the packets/frames but without a VLAN tag, it seems that the VLAN tag has been stripped.

 

Here are some informations on my setup:

 

[root@SLI-SRV3 sysadmin]# ethtool -i eth1

driver: i40e

version: 1.6.27-k

firmware-version: 6.00 0x800034e6 18.3.6

expansion-rom-version:

bus-info: 0000:19:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

 

[root@SLI-SRV3 sysadmin]# ip link show eth1

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq portid 246e967eaabe state UP mode DEFAULT qlen 1000

    link/ether 24:6e:96:7e:aa:be brd ff:ff:ff:ff:ff:ff

    vf 0 MAC 52:54:00:5d:6a:60, spoof checking on, link-state auto, trust off

 

 

VIRSH network config:

    <interface type='hostdev' managed='yes'>

      <mac address='52:54:00:5d:6a:60'/>

      <driver name='vfio'/>

      <source>

        <address type='pci' domain='0x0000' bus='0x19' slot='0x02' function='0x0'/>

      </source>

      <alias name='hostdev0'/>

      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>

    </interface>

 

 

Any idea about what could be the issue ?

 

Thanks,

 

Stephane

Rx710 4x10G card not working anymore after upgrading the firmware

$
0
0

I am sorry to hijack this thread.

 

We are also seeing the similar issue at our hosts. After upgrading Intel NIC firmware, the NICs do not detect the link anymore. They were fine before the NIC firmware update. We tried updating i40e driver to the latest available, but it did not help.

 

Host information

 

Model                                            Dell R630

Bios Version                                 2.7.1

 

Linux Version           16.04.4 (Ubuntu Xenial)

 

Kernel Version          4.4.0-116-generic

 

 

# lspci -nn |grep X710

 

01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev 01)

01:00.1 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev 01)

 

 

# ethtool -i p1p1

 

driver: i40e

version: 2.4.6

firmware-version: 6.00 0x800034e6 18.3.6

expansion-rom-version:

bus-info: 0000:01:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

 

# ethtool p1p1

 

Settings for p1p1:

Supported ports: [ ]

Supported link modes:   10000baseT/Full

Supported pause frame use: Symmetric

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: internal

Auto-negotiation: off

Supports Wake-on: g

Wake-on: g

Current message level: 0x0000000f (15)

        drv probe link timer

Link detected: no

ESXi 6.5U1 X710 upgrade from firmware 6.00 to 6.01

$
0
0

Hello,

 

We are having an issue with updating the firmware of our X710 network cards, here is the output of the nvmupdaten64e command:

 

 

Num Description                               Ver. DevId S:B    Status

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

01) Intel(R) Ethernet 10G 4P X710 SFP+ rNDC   6.00  1572 00:001 Update not available

02) Intel(R) Gigabit 4P I350-t Adapter       1.103  1521 00:129 Update not available

 

We are running 9 hosts with ESXi 6.5U1 7388607

 

Please advise.

x520-sr2

$
0
0

I have pair of supermicro servers with intel x520-sr2.  With nic teaming getting 1000's of  log events per second stating it received packets on wrong nic.  Being a team I can see this as a posibilty, but does it need to flood me with messages about it ?

 

No matching TeamNic found for packets received from member NDISIMPLATFORM\Parameters\Adapters\

Received LACPDU on Member {27EF013E-0DD4-497E-90A2-7E5AC30E6E84}. Buffer= 0x0180C2000002C4F57C565A6F880901010114008001E0520000021904008031043D0000000214000090E2BA92F1D80000000001001F0000000310050000000000000000000000000000000...

 

event id 25,26, 27

drivers are the most current -

 

 

 

 

boatmn810

Convert X710 to an XXV710?

$
0
0

I noticed the XXV710 is part of the Fontville series, which includes the X710 and XL710. Additionally the NVM package is the same for all 3 of these NICs.

Intel® Ethernet Controller XXV710-AM2 Product Specifications

 

Is it possible to flash the 4-port 10GE X710, or the 1-port 40GE XL710 to function as a XXV710? Even if it can only support 2x25G connections, it would be fine.

docker SR-IOV with IXGBE - Vlan packets getting spoofed

$
0
0

environment:

Redhat 7.4

ixgbe, ixgbevf  (82599es ethernet controller)

docker 1.13

 

requirement:

The docker container had to have a trunk port which is mapped to a VF.

docker guest running in privileged mode.

 

Problem:

when the container emits the q-in-q packets, the kernel drops as the packets are spoofed.

in the recv direction how can i classify based on the vlan (with no vlan interface in the container)?

 

Thanks for the help

Forwarding packets using XL710 network controller

$
0
0

Hi,

 

I have a XL710QDA2 40GB NIC and I also have the INTEL Ethernet QSFP+ cable. I have two problems:

1- This NIC does not get IPV4 address automatically. What should I do to force it to get IPV4 address upon boot?

2- I have tried to send packets through this NIC to other devices, but it can not forward any packet (IPV4, IPV6, or even broadcast packets). How can I enable the packet forwarding and receiving of this NIC?

 

Thanks for your time. I would appreciate it if you could help me out.

 

Best,

Marjan


Duplicates of packets on VMSwitch using Intel x722

$
0
0

We have Hyper-V Server on which we created VMSwitch (with Switch Embedded Teaming) on two built in Intel722 adapters.

 

On VMSwitch we have NetAdapter for Management OS with ip assigned(created along with vmswitch). After creation everything works fine until reboot, after which we are observing duplicates of packets ie:

 

18 bytes from xxx: icmp_seq=1 ttl=128

18 bytes from xxx: icmp_seq=1 ttl=128 (DUP!)

18 bytes from xxx: icmp_seq=2 ttl=128

18 bytes from xxx: icmp_seq=2 ttl=128 (DUP!)

 

If we remove VMSwitch and create it again, everything works fine until reboot.

MacAddress/IP configuration is always the same and don't change after reboot. We investigated the network, but it seems that those macaddressess exist only on that host and we see (using Wireshark/tcpdump) that duplicates are indeed coming from that server. If we use different network card (Intel x550) to create VMSwitch on that server it all works fine. Also if we use those cards without VMSwitch there are no duplicates.

 

 

Mobo: X11SPH-nCTF + built in Intel X722 for 10GBASE-T

Processor: Intel Xeon Silver 4110 2.1GHz

OS: MS Hyper-V Server 2016 Version  10.0.14393 Build 14393 + all updates (also tested on MS Windows Server Standard 2016 + all updates)

Driver: c:\windows\system32\drivers\i40eb65.sys (1.8.94.0, 996.54 KB (1,020,456 bytes), 2/19/2018 11:50 PM) (from latest 23.1 Driver Pack)

 

We don't see anything in logs. We tried reinstalling, even with different OS, situation seems to be the same.

We have the same OS + VMSwitch configuration on different Motherboards/Network Cards but there we don't observe any problems.

 

Are there any known bugs related to x722 and Microsoft VMSwitch or do you have any suggestion?

duplicate MAC address of two different X520-DA2 NICs

$
0
0

Hello,

 

my question is directed to Intel NIC developers - we (CDN77) are using your X520-DA2 cards in thousands of servers - we have discovered that two different X520-DA2 NICs we have in our network do use the SAME MAC address.

 

The conflicting MAC is 00:1b:21:bc:32:15.

 

Is this something what 'can happen from time to time'? It would be a real flaw in the design - this makes makes me think the duplicate MAC is caused by some Chinese copy of the genuine Intel NIC.

 

You can imagine what mess can this cause.

 

If it helps, I can send more detail information regarding both NICs.

 

 

Thank you!

Eth card 82579LM

$
0
0

Good morning!

I have a problem with the 82579LM card.

Let me start with a description of the situation, we have been producing mining machines for the explosion-risk zone for years. We have been using an Ethernet connection of a PLC with a PC for about 10 years. The connection is 4-core 10Mb. Between the PC and the PLC, ethernet separators (EI-0D2-10Y-10B from pepperl-fuchs) are used. These barriers are "transparent".

For many years, this configuration works with an industrial PC of B & R APC620, which has an Intel PRO / 100 VE card. Currently, its production has ended, therefore I am installing a newer APC910 model. This model has an INTEL 82579LM network card.

Unfortunately, I can not configure it to work in this configuration.

If I omit the Ethernet separators, the connection works.

If I apply the switch between the PC and the barrier, the connection works.

If I install a USB Ethernet card to the computer, the connection works.

If I put an older type of computer in place of the new one, it also works.

 

 

If I connect the computer in accordance with the diagram in place of the old one, the system detects the network, however with a mistake.

The system is Windows 7 Standard Embedded.

The most up-to-date Bios, the most up-to-date drivers.

 

 

Please help

Regards

Lukasz

x710 4x10G card not working Amphenol cable

$
0
0

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_______

Date code

amphenol

 

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

Intel DX79SI Motherboard Ethernet Error

$
0
0

I have an Intel DX79SI model motherboard. I can find out which operating system this motherboard is installed on. He does not see Ethernet. Even though there is 2 Ethernet on the motherboard, Windows only sees one: Intel (R) 82579LM Gigabit Network. When I look at the features, I get Error Code 10. I also helped record the whole event as a video. I'm sorry for my bad english.

 

Operating System:

Windows 10.

I Try Operating System:

Vmware Esxi

Centos

 

Thanks.

 

Intel® Desktop Board DX79SI Technical Product Specification:

 

1.10 LAN Subsystem The Intel GbE Dual LAN subsystem consists of the following:

• Intel 82579L and Intel 82574L Gigabit Ethernet Controllers (10/100/1000 Mbits/s)

• Intel X79 Express Chipset

• RJ-45 LAN connectors with integrated status LEDs

Additional features of the LAN subsystem include:

• CSMA/CD protocol engine

• LAN connect interface between the PCH and the LAN controller

• Conventional PCI bus power management  ACPI technology support  LAN wake capabilities (only the Intel 82579L Gigabit Ethernet Controller supports PXE)

• LAN subsystem software For information about Refer to LAN software and drivers http://downloadcenter.intel.com

 

1.10.1 Intel® 82579L and Intel 82574L Gigabit Ethernet Controllers

The Intel 82579L and Intel 82574L Gigabit Ethernet Controllers support the following features:

• 10/100/1000 BASE-T IEEE 802.3 compliant

• Energy Efficient Ethernet (EEE) IEEE802.3az support [Low Power Idle (LPI) mode]

• Dual interconnect between the Integrated LAN Controller and the Physical Layer (PHY):

     - PCI Express-based interface for active state operation (S0) state

     - SMBUS for host and management traffic (Sx low power state)

• Compliant to IEEE 802.3x flow control support

• 802.1p and 802.1q

• TCP, IP, and UDP checksum offload (for IPv4 and IPv6)

•Full device driver compatibility

• Provides lower power usage to meet Energy Star 5.0 and ErP specifications

Viewing all 4405 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>