Quantcast
Viewing all 4405 articles
Browse latest View live

i40e XL710 QDA2 as iSCSI initiator results in "RX driver issue detected, PF reset issued", and iscsi ping timeouts

Hi!

 

There is a dual E5-2690v3 box based on  Supermicro SYS-2028GR-TR/X10DRG-H, BIOS 1.0c, running Ubuntu 16.04.1, w. all current updates.

It has a XL710-QDA2 card, fw 5.0.40043 api 1.5 nvm 5.04 0x80002537, driver 1.5.25 (the stock Ubuntu i40e driver 1.4.25 resulted in a crash), that is planned to be used as an iSCSI initiator endpoint. But there seems to be a problem: the log file fills up with "RX driver issue detected" messages and occasionally the iSCSI link resets as ping times out. This is critical error, as the mounted device becomes unusable!

 

So, Question 1: Is there something that can be done to fix the iSCSI behaviour of the XL710 card? When testing the card with iperf (2 concurrent sessions, the other end had a 10G NIC), there were no problems. The problems started when the iSCSI connection was established.

 

Question 2: Is there a way to force the card to work in PCI Express 2.0 mode? The server downgraded the card once after several previous failures and then it became surprisingly stable. I cannot find a way to make it persist though.

 

Some excerpts from log files (there are also occasional TX driver issues, but much less frequently than RX problems):

 

 

[  263.116057] EXT4-fs (sdk): mounted filesystem with ordered data mode. Opts: (null)

[  321.030246] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[  332.512601] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

..lots of the above messages...

[  481.001787] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[  487.183237] NOHZ: local_softirq_pending 08

[  491.151322] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

..lots of the above messages...

[ 1181.099046] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1199.852665]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295189627, last ping 4295190878, now 4295192132

[ 1199.852694]  connection1:0: detected conn error (1022)

[ 1320.412312]  session1: session recovery timed out after 120 secs

[ 1320.412325] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412331] sd 10:0:0:0: [sdk] killing request

[ 1320.412347] sd 10:0:0:0: [sdk] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

[ 1320.412352] sd 10:0:0:0: [sdk] CDB: Write Same(10) 41 00 6b 40 69 00 00 08 00 00

[ 1320.412356] blk_update_request: I/O error, dev sdk, sector 1799383296

[ 1320.412411] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412423] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412428] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412433] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412438] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412442] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412446] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412451] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412455] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412460] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412464] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412469] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412473] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412477] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412482] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412486] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412555] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412566] Aborting journal on device sdk-8.

[ 1320.412571] sd 10:0:0:0: rejecting I/O to offline device

[ 1320.412576] JBD2: Error -5 detected when updating journal superblock for sdk-8.

[ 1332.831851] sd 10:0:0:0: rejecting I/O to offline device

[ 1332.831864] EXT4-fs error (device sdk): ext4_journal_check_start:56: Detected aborted journal

[ 1332.831869] EXT4-fs (sdk): Remounting filesystem read-only

[ 1332.831873] EXT4-fs (sdk): previous I/O error to superblock detected

 

Unloading the kernel module and modprobe-ing it again:

 

[ 1380.970732] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 1.5.25

[ 1380.970737] i40e: Copyright(c) 2013 - 2016 Intel Corporation.

[ 1380.987563] i40e 0000:81:00.0: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0

[ 1381.127289] i40e 0000:81:00.0: MAC address: 3c:xx:xx:xx:xx:xx

[ 1381.246815] i40e 0000:81:00.0 p5p1: renamed from eth0

[ 1381.358723] i40e 0000:81:00.0 p5p1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

[ 1381.416135] i40e 0000:81:00.0: PCI-Express: Speed 8.0GT/s Width x8

[ 1381.454729] i40e 0000:81:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[ 1381.471584] i40e 0000:81:00.1: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0

[ 1381.605866] i40e 0000:81:00.1: MAC address: 3c:xx:xx:xx:xx:xy

[ 1381.712287] i40e 0000:81:00.1 p5p2: renamed from eth0

[ 1381.751417] IPv6: ADDRCONF(NETDEV_UP): p5p2: link is not ready

[ 1381.810607] IPv6: ADDRCONF(NETDEV_UP): p5p2: link is not ready

[ 1381.820095] i40e 0000:81:00.1: PCI-Express: Speed 8.0GT/s Width x8

[ 1381.826141] i40e 0000:81:00.1: Features: PF-id[1] VFs: 64 VSIs: 66 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[ 1647.123056] EXT4-fs (sdk): recovery complete

[ 1647.123414] EXT4-fs (sdk): mounted filesystem with ordered data mode. Opts: (null)

[ 1668.179234] NOHZ: local_softirq_pending 08

[ 1673.994586] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1676.871805] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1692.833097] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1735.179086] NOHZ: local_softirq_pending 08

[ 1767.357902] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

[ 1803.828762] i40e 0000:81:00.0: RX driver issue detected, PF reset issued

 

After several failures, the card loaded in PCI-Express 2.0 mode. It became stable then:

 

Jan  1 18:44:35  systemd[1]: Started ifup for p5p1.

Jan  1 18:44:35  systemd[1]: Found device Ethernet Controller XL710 for 40GbE QSFP+ (Ethernet Converged Network Adapter XL710-Q2).

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5028] devices added (path: /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/net/p5p1, iface: p5p1)

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5029] locking wired connection setting

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5029] get unmanaged devices count: 3

Jan  1 18:44:35  avahi-daemon[1741]: Joining mDNS multicast group on interface p5p1.IPv4 with address xx.xx.xx.xx.

Jan  1 18:44:35  avahi-daemon[1741]: New relevant interface p5p1.IPv4 for mDNS.

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.5577] device (p5p1): link connected

Jan  1 18:44:35  avahi-daemon[1741]: Registering new address record for xx.xx.xx.xx on p5p1.IPv4.

Jan  1 18:44:35  kernel: [11572.541797] i40e 0000:81:00.0 p5p1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None

Jan  1 18:44:35  kernel: [11572.579303] i40e 0000:81:00.0: PCI-Express: Speed 5.0GT/s Width x8

Jan  1 18:44:35  kernel: [11572.579309] i40e 0000:81:00.0: PCI-Express bandwidth available for this device may be insufficient for optimal performance.

Jan  1 18:44:35  kernel: [11572.579312] i40e 0000:81:00.0: Please move the device to a different PCI-e link with more lanes and/or higher transfer rate.

Jan  1 18:44:35  kernel: [11572.617328] i40e 0000:81:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 48 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA

Jan  1 18:44:35  kernel: [11572.635294] i40e 0000:81:00.1: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0

Jan  1 18:44:35  kernel: [11572.917343] i40e 0000:81:00.1: MAC address: 3c:xx:xx:xx:xx:xx

Jan  1 18:44:35  systemd[1]: Reloading OpenBSD Secure Shell server.

Jan  1 18:44:35  systemd[1]: Reloaded OpenBSD Secure Shell server.

Jan  1 18:44:35  kernel: [11572.921344] i40e 0000:81:00.1: SAN MAC: 3c:xx:xx:xx:xx:xx

Jan  1 18:44:35  NetworkManager[1911]: <warn>  [1483289075.9656] device (eth0): failed to find device 14 'eth0' with udev

Jan  1 18:44:35  NetworkManager[1911]: <info>  [1483289075.9671] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/13)

Jan  1 18:44:35  kernel: [11572.976596] i40e 0000:81:00.1 p5p2: renamed from eth0

 

Kind regards,

 

jpe

Image may be NSFW.
Clik here to view.

82574L & 82578DM no LACP group possible - AMT is blocking

Hi,

I am using a Supermicro C7SIM-Q Motherboard with WIN 7 pro.

 

I want to build a group of the two onboard NICs 82574L & 82578DM to run LACP ().

 

As soon as select IEEE 802.3ad I get a popup:  AMT activated devices cannot be added to 802.ad-, SLA- or VMLB-groups.

 

I disabled AMT in the BIOS and deinstalled the Intel Security Software.

 

What can I do?

 

Image may be NSFW.
Clik here to view.
LACP Gruppe_04.png

Image may be NSFW.
Clik here to view.
LACP Gruppe_06.png

Intel(R) Ethernet Connection (2) I219-V - Waking from sleep causes 10Mbp/s and no connectivity until rebooting or reconnecting cable.

Setup:

  • I have a Gigabyte GA-B150M-D3H motherboard with an Intel i5-6500 CPU and 8Gb DDR4 GSkill RAM.
  • I have wired ethernet with a CAT5e cable plugged from the Ethernet port into a TP-Link Gigabit 5 port switch and then eventually onto a TP-Link ADSL2 Router.
  • I am using a static IP setup (Static IP, Gateway, Subnet mask).
  • I am running Windows 10 Home 64bit
  • I am running Kaspersky 2017 Internet Security (I have uninstalled Kaspersky Secure Connection)
  • I am running the supplied Gigabyte drivers for the Intel Ethernet Adapter on the board (Version 20.7 - listed as 12.15.22.3 in the driver properties)

 

Problem:

  • Waking from S1 sleep causes the adapter to intialise at 10Mb/s and have no connectivity. The only solution is 1) reboot or 2) remove and re-insert the CAT5e cable. This cable has worked at Gigabit speeds for years on the previous Motherboard I had which had a Realtek based ethernet adapter on a GA-X38-DQ6.

 

Event Logs:

  • When the problem occurs: "Intel(R) Ethernet Connection (2) I219-V Network link has been established at 10Mbps full duplex."
  • When the system works fine: "Intel(R) Ethernet Connection (2) I219-V Network link has been established at 1Gbps full duplex."

 

Things I have tried:

I have tried the following Intel drivers:

  • 20.4.1 (from the Intel site)
  • 20.7 (from the Gigabyte site)
  • 21.1 (from the Intel site)

I have tried disabling all of the power management properties in the Intel driver properties

Xeon-D 1541 SR-IOV VF in Promiscuous mode

Hi,

 

I am using a Xeon-D 1541, with (2) x552/x557 10G Ethernet cards. I am able to enable VFs and have the latest Linux Kernel/iproute2 (both v4.8.0). I am attempting to put a VF into "Promiscuous Mode" with a VLAN tag for a security monitoring container. I can enable "trust mode", which should allow promiscuous traffic, however I can only see packets that are destined for the VF MAC address or broadcast packets.

 

Does the x552/x557 support unicast/multicast promiscuous mode in VFs?

 

Some Specific configuration information:

[root@localhost ~]# modinfo ixgbe

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

version:        4.4.0-k-rh7.3

license:        GPL

description:    Intel(R) 10 Gigabit PCI Express Network Driver

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

rhelversion:    7.3

srcversion:     E85AB43E463B4B0083D9BE3

 

 

[root@localhost ~]#ip link show

5: eno4: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 0c:c4:7a:c4:ad:7f brd ff:ff:ff:ff:ff:ff

    vf 0 MAC 06:9f:fb:7b:1b:9f, vlan 1000, spoof checking off, link-state auto, trust on

    vf 1 MAC 7e:12:a8:d2:59:76, vlan 2000, spoof checking off, link-state auto, trust on

 

[root@localhost ~]#ifconfig

eno4: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        ether 0c:c4:7a:c4:ad:7f  txqueuelen 1000  (Ethernet)

        RX packets 22  bytes 6232 (6.0 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

 

enp3s16f1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        inet6 fe80::49f:fbff:fe7b:1b9f  prefixlen 64  scopeid 0x20<link>

        ether 06:9f:fb:7b:1b:9f  txqueuelen 1000  (Ethernet)

        RX packets 21  bytes 6126 (5.9 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 8  bytes 648 (648.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

 

enp3s16f3: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        ether 7e:12:a8:d2:59:76  txqueuelen 1000  (Ethernet)

        RX packets 1  bytes 78 (78.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 49  bytes 8310 (8.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

The physical interface (eno4) is able to see all packets, but the VF interface (enp3s16f1) is not able to show promiscuous packets.

 

Does the x552/x557 support unicast/multicast promiscuous mode in VFs? If so, is this a hardware, driver, kernel, or user error.

 

Thanks in advance!

I210 MAC Address Factory Setting

Does the I210 ship with a unique MAC Address for each chip, or do MACs need to be purchased and manually assigned?  In my experience it's always been the latter, but the manual has some bits that suggest that there's a unique factory setting that can be reapplied over a user MAC.

Image may be NSFW.
Clik here to view.

What is the command in the host to see the counters for XL710 switch – ethernet frames switched/dropped/error’ed

Hi All,

Currently I am using following NIC adapter

X710-AM2

In order to monitor the packet transmission what is the command used in internal switch of xl710 switch

 

 

 

 



   
 
 
 
 
 
 
 
 
 
 
 





Intel I210: Synchronized Output Clock on SDP Pins

Hi,

 

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

 

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

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

 

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

Have someone tried this before ?

 

Registers I configured (for CLK1 on SDP1) are:

IMS - set Time sync interrupts

TSIM - enable interrupt for Target Time1(TT1)

TSSDP - enable SDP1 and assign CLK1

TSAUXC - enable CLK1

CTRL - set SDP as output

FREQOUT - set clock half-cycle

 

Please let me know if any more information is required.

 

Thanks.

Why not for intel 9400PT 82572GI wired ethernet driver?

Only find intel®82572 and 82572EI, not found 82572GI


I210 Configuration PCIe Only

My platform is a Q7 module which already implements an I210 on PCIe.  I am designing a carrier board which includes 2 additional I210s on the Q7 PCIe bus.  The Q7 module is currently being tested on a development board and is running Ubuntu Server 14.04.5 and reports Intel Gigabit Ethernet Network Driver - version 5.2.15-k.  Its onboard I210 works fine in the development environment.

 

All I need is for the I210s to be recognized as a PCIe device by Linux and treated like any other unmanaged Ethernet adapter.  I only need to perform very basic config such as setting the MAC address, IPv4 details, and setting link speed.  Initiating Ethernet Compliance test patterns would also be desirable but not strictly required.

 

I would prefer to avoid implementing SPI flash configuration if possible.  The manufacturer of the Q7 module has also discouraged us from connecting the SMBus to external devices, so I would like to avoid that as well.  What level of functionality is available using only the PCIe link for configuration?

 

If I do need to use the SMBus, is it possible to change the SMBus Slave Address over PCIe?  Or will I need to implement an SPI Flash to write that register?

Image may be NSFW.
Clik here to view.

i40e / X710-DA2 segfault on Ubuntu 16.04

Hello!

I have problem with running X710-DA2 on my servers. When I try to load the i40e driver it crashes. It happened on a stock fw, drivers, etc. and on the upgraded versions.

 

Platform: Supermicro X9DRW with dual Intel(R) Xeon(R) CPU E5-2620, latest BIOS

OS: Ubuntu 16.04.1 LTS, linux 4.4.0-57

NIC firmware: fw 5.0.40043 api 1.5 nvm 5.04 0x800024c6 0.0.0 (latest)

i40e driver: 1.5.25 (downloaded and compiled)

Modules installed: GBC Photonics SP-MM85030D-GP -SFP+

 

dmesg:

 

Jan  3 18:01:58 ceph6 kernel: [  739.510036] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 1.5.25

Jan  3 18:01:58 ceph6 kernel: [  739.510041] i40e: Copyright(c) 2013 - 2016 Intel Corporation.

Jan  3 18:01:58 ceph6 kernel: [  739.527324] i40e 0000:04:00.0: fw 5.0.40043 api 1.5 nvm 5.04 0x800024c6 0.0.0

Jan  3 18:01:58 ceph6 kernel: [  739.765165] i40e 0000:04:00.0: MAC address: 3c:fd:fe:a2:19:54

Jan  3 18:01:58 ceph6 kernel: [  739.789909] i40e 0000:04:00.0: AQ command Config VSI BW allocation per TC failed = 14

Jan  3 18:01:58 ceph6 kernel: [  739.789912] i40e 0000:04:00.0: Failed configuring TC map 255 for VSI 390

Jan  3 18:01:58 ceph6 kernel: [  739.789915] i40e 0000:04:00.0: failed to configure TCs for main VSI tc_map 0x000000ff, err I40E_ERR_INVALID_QP_ID aq_err I40E_AQ_RC_EINVAL

Jan  3 18:01:59 ceph6 kernel: [  739.833189] divide error: 0000 [#1] SMP

Jan  3 18:01:59 ceph6 kernel: [  739.833324] Modules linked in: i40e(OE+) vxlan ip6_udp_tunnel udp_tunnel intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni

_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper input_leds joydev sb_edac cryptd serio_raw edac_core ipmi_si mei_me 8250_fintek mei ipmi_msghandler shpchp ioatdma lpc_ich mac_hid autofs4 hid_generic usbhid hid psmouse isci

igb ahci libsas libahci dca ptp scsi_transport_sas megaraid_sas pps_core i2c_algo_bit wmi fjes

Jan  3 18:01:59 ceph6 kernel: [  739.835034] CPU: 0 PID: 2386 Comm: insmod Tainted: G           OE   4.4.0-57-generic #78-Ubuntu

Jan  3 18:01:59 ceph6 kernel: [  739.835306] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0c 03/24/2014

Jan  3 18:01:59 ceph6 kernel: [  739.835518] task: ffff880868b9f000 ti: ffff88046c1c0000 task.ti: ffff88046c1c0000

Jan  3 18:01:59 ceph6 kernel: [  739.835754] RIP: 0010:[<ffffffffc03a4faf>]  [<ffffffffc03a4faf>] i40e_pf_config_rss+0x1ef/0x230 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.836059] RSP: 0018:ffff88046c1c37a0  EFLAGS: 00010246

Jan  3 18:01:59 ceph6 kernel: [  739.836227] RAX: 0000000000000000 RBX: ffff88086bd33c00 RCX: 0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.836452] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000200

Jan  3 18:01:59 ceph6 kernel: [  739.836679] RBP: ffff88046c1c3808 R08: ffff88046fc1a120 R09: ffff88046f8032c0

Jan  3 18:01:59 ceph6 kernel: [  739.836904] R10: ffff88086bd33c00 R11: 0000000000000000 R12: 0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.837130] R13: ffff88046da74008 R14: ffff88046c099000 R15: ffff88046da74000

Jan  3 18:01:59 ceph6 kernel: [  739.837359] FS:  00007f5815768700(0000) GS:ffff88046fc00000(0000) knlGS:0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.837615] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

Jan  3 18:01:59 ceph6 kernel: [  739.837796] CR2: 00007fe8a4fcc13c CR3: 000000046a7f2000 CR4: 00000000000406f0

Jan  3 18:01:59 ceph6 kernel: [  739.838022] Stack:

Jan  3 18:01:59 ceph6 kernel: [  739.838085]  0000000000000005 00000000001c0ac0 00000000000e0000 ffff88046c1c37e8

Jan  3 18:01:59 ceph6 kernel: [  739.838335]  ffffffffc03b9e39 ffff88046da74f28 ffff88046da74008 00000000ffd84a52

Jan  3 18:01:59 ceph6 kernel: [  739.847061]  ffff88046da74000 0000000000000000 ffff88046da74008 0000000000000000

Jan  3 18:01:59 ceph6 kernel: [  739.855800] Call Trace:

Jan  3 18:01:59 ceph6 kernel: [  739.864529]  [<ffffffffc03b9e39>] ? i40e_write_rx_ctl+0x39/0x90 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.873487]  [<ffffffffc03a7ba8>] i40e_setup_pf_switch+0x308/0x590 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.882566]  [<ffffffffc03ab5c0>] i40e_probe.part.58+0xd50/0x1be0 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  739.891572]  [<ffffffff813fcbdd>] ? radix_tree_lookup+0xd/0x10

Jan  3 18:01:59 ceph6 kernel: [  739.900540]  [<ffffffff810da827>] ? irq_to_desc+0x17/0x20

Jan  3 18:01:59 ceph6 kernel: [  739.909424]  [<ffffffff810de48e>] ? irq_get_irq_data+0xe/0x20

Jan  3 18:01:59 ceph6 kernel: [  739.918278]  [<ffffffff81057695>] ? mp_map_pin_to_irq+0xb5/0x300

Jan  3 18:01:59 ceph6 kernel: [  739.927153]  [<ffffffff814b55cc>] ? acpi_ut_remove_reference+0x2e/0x31

Jan  3 18:01:59 ceph6 kernel: [  739.936072]  [<ffffffff811ed69b>] ? __slab_free+0xcb/0x2c0

Jan  3 18:01:59 ceph6 kernel: [  739.944972]  [<ffffffff81057e98>] ? mp_map_gsi_to_irq+0x98/0xc0

Jan  3 18:01:59 ceph6 kernel: [  739.953757]  [<ffffffff8104f72e>] ? acpi_register_gsi_ioapic+0xbe/0x180

Jan  3 18:01:59 ceph6 kernel: [  739.962466]  [<ffffffff81495726>] ? acpi_pci_irq_enable+0x1bf/0x1e4

Jan  3 18:01:59 ceph6 kernel: [  739.971114]  [<ffffffff817058c8>] ? pci_conf1_read+0xb8/0xf0

Jan  3 18:01:59 ceph6 kernel: [  739.979739]  [<ffffffff817093e3>] ? raw_pci_read+0x23/0x40

Jan  3 18:01:59 ceph6 kernel: [  739.988340]  [<ffffffff8143bc3c>] ? pci_bus_read_config_word+0x9c/0xb0

Jan  3 18:01:59 ceph6 kernel: [  739.996976]  [<ffffffff81444ced>] ? do_pci_enable_device+0xdd/0x110

Jan  3 18:01:59 ceph6 kernel: [  740.005459]  [<ffffffff81446104>] ? pci_enable_device_flags+0xe4/0x130

Jan  3 18:01:59 ceph6 kernel: [  740.013867]  [<ffffffffc03ac46e>] i40e_probe+0x1e/0x30 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  740.022228]  [<ffffffff81447585>] local_pci_probe+0x45/0xa0

Jan  3 18:01:59 ceph6 kernel: [  740.030571]  [<ffffffff814489c3>] pci_device_probe+0x103/0x150

Jan  3 18:01:59 ceph6 kernel: [  740.038806]  [<ffffffff8155a7a2>] driver_probe_device+0x222/0x4a0

Jan  3 18:01:59 ceph6 kernel: [  740.046946]  [<ffffffff8155aaa4>] __driver_attach+0x84/0x90

Jan  3 18:01:59 ceph6 kernel: [  740.055009]  [<ffffffff8155aa20>] ? driver_probe_device+0x4a0/0x4a0

Jan  3 18:01:59 ceph6 kernel: [  740.063118]  [<ffffffff815583cc>] bus_for_each_dev+0x6c/0xc0

Jan  3 18:01:59 ceph6 kernel: [  740.071205]  [<ffffffff81559f5e>] driver_attach+0x1e/0x20

Jan  3 18:01:59 ceph6 kernel: [  740.079029]  [<ffffffff81559a9b>] bus_add_driver+0x1eb/0x280

Jan  3 18:01:59 ceph6 kernel: [  740.086629]  [<ffffffffc01ea000>] ? 0xffffffffc01ea000

Jan  3 18:01:59 ceph6 kernel: [  740.093977]  [<ffffffff8155b3b0>] driver_register+0x60/0xe0

Jan  3 18:01:59 ceph6 kernel: [  740.101076]  [<ffffffff81446eac>] __pci_register_driver+0x4c/0x50

Jan  3 18:01:59 ceph6 kernel: [  740.107997]  [<ffffffffc01ea0a6>] i40e_init_module+0xa6/0x1000 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  740.114831]  [<ffffffff81002123>] do_one_initcall+0xb3/0x200

Jan  3 18:01:59 ceph6 kernel: [  740.121523]  [<ffffffff811ecbd3>] ? kmem_cache_alloc_trace+0x183/0x1f0

Jan  3 18:01:59 ceph6 kernel: [  740.128183]  [<ffffffff8118d9f3>] do_init_module+0x5f/0x1cf

Jan  3 18:01:59 ceph6 kernel: [  740.134706]  [<ffffffff8110a98f>] load_module+0x166f/0x1c10

Jan  3 18:01:59 ceph6 kernel: [  740.141064]  [<ffffffff81106f30>] ? __symbol_put+0x60/0x60

Jan  3 18:01:59 ceph6 kernel: [  740.147352]  [<ffffffff81214760>] ? kernel_read+0x50/0x80

Jan  3 18:01:59 ceph6 kernel: [  740.153662]  [<ffffffff8110b174>] SYSC_finit_module+0xb4/0xe0

Jan  3 18:01:59 ceph6 kernel: [  740.159956]  [<ffffffff8110b1be>] SyS_finit_module+0xe/0x10

Jan  3 18:01:59 ceph6 kernel: [  740.166220]  [<ffffffff818374f2>] entry_SYSCALL_64_fastpath+0x16/0x71

Jan  3 18:01:59 ceph6 kernel: [  740.172496] Code: 40 5b 41 5c 41 5d 41 5e 41 5f 5d c3 41 0f b7 be a8 04 00 00 31 c9 41 0f b7 b6 aa 04 00 00 66 85 ff 0f 84 5a ff ff ff 89 c8 31 d2 <66> f7 f6 88 14 0b 48 83 c1 01 66 39 cf 77 ed e9 42 ff ff ff 4c

Jan  3 18:01:59 ceph6 kernel: [  740.185825] RIP  [<ffffffffc03a4faf>] i40e_pf_config_rss+0x1ef/0x230 [i40e]

Jan  3 18:01:59 ceph6 kernel: [  740.192377]  RSP <ffff88046c1c37a0>

Jan  3 18:01:59 ceph6 kernel: [  740.215988] ---[ end trace ab2ce900f55f1c7a ]---

 

After that one of the interfaces appears in the system, but it's unaccesible:

root@ceph6:~# ip link set up eth2

RTNETLINK answers: Invalid argument

 

 

Kind regards,

Dominik

VLAN creation on Windows 10 Enterprise TP

Hello, there.

 

This morning I upgraded my fully functionnal Windows 8.1 Enterprise installation to Windows 10 Technical Preview. Before that, I downloaded the Intel Network Adapter Driver from this website, version 20.1, for Windows 10 64 bits. After the driver installation, I had the VLANs tab in the network card properties. However, i'm unable to create a VLAN. The network card is automatically disabled then I receive an error message saying this (translated from french):

 

One or more vlans could not be created. Please check the adapter status and try again.


The window freezes and I have to force-close it. 802.1 option is of course enabled in the Advanced options tab. The event viewer always shows the same error when I try to create a VLAN:


Nom de l’application défaillante NCS2Prov.exe, version : 20.1.1021.0, horodatage : 0x554ba6a4

Nom du module défaillant : NcsColib.dll, version : 20.1.1021.0, horodatage : 0x554ba57d

Code d’exception : 0xc0000005

Décalage d’erreur : 0x0000000000264064

ID du processus défaillant : 0x19d4

Heure de début de l’application défaillante : 0x01d0ada33fd50576

Chemin d’accès de l’application défaillante : C:\Program Files\Intel\NCS2\WMIProv\NCS2Prov.exe

Chemin d’accès du module défaillant: C:\WINDOWS\SYSTEM32\NcsColib.dll

ID de rapport : eefb5842-9220-4bad-93d3-774828c5736e

Nom complet du package défaillant :

ID de l’application relative au package défaillant :

 

I already tried to uninstall all the packages and drivers related to the network card. I deleted fantom network cards then cleaned up the registry. I tried to set some compatibility options to the given executable file, with no success. I tried to reinstall the driver with Drivers Signature disabled, tried to disable IPv4/IPv6 from the network card before trying to add a VLAN... I tried everything I found on Google.

 

Could someone help me, please?

I211/I217-V Windows 10 LACP teaming fails

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

I210 driver issue in Linux

Hi,

 

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

I have programmed iNVM in both devices and

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

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

 

How to bind this igb driver to i210 controllers?

 

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

Please help me in resolving this issue

Image may be NSFW.
Clik here to view.

Xeon-D 1541 SR-IOV VF in Promiscuous mode

Hi,

 

I am using a Xeon-D 1541, with (2) x552/x557 10G Ethernet cards. I am able to enable VFs and have the latest Linux Kernel/iproute2 (both v4.8.0). I am attempting to put a VF into "Promiscuous Mode" with a VLAN tag for a security monitoring container. I can enable "trust mode", which should allow promiscuous traffic, however I can only see packets that are destined for the VF MAC address or broadcast packets.

 

Does the x552/x557 support unicast/multicast promiscuous mode in VFs?

 

Some Specific configuration information:

[root@localhost ~]# modinfo ixgbe

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

version:        4.4.0-k-rh7.3

license:        GPL

description:    Intel(R) 10 Gigabit PCI Express Network Driver

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

rhelversion:    7.3

srcversion:     E85AB43E463B4B0083D9BE3

 

 

[root@localhost ~]#ip link show

5: eno4: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 0c:c4:7a:c4:ad:7f brd ff:ff:ff:ff:ff:ff

    vf 0 MAC 06:9f:fb:7b:1b:9f, vlan 1000, spoof checking off, link-state auto, trust on

    vf 1 MAC 7e:12:a8:d2:59:76, vlan 2000, spoof checking off, link-state auto, trust on

 

[root@localhost ~]#ifconfig

eno4: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        ether 0c:c4:7a:c4:ad:7f  txqueuelen 1000  (Ethernet)

        RX packets 22  bytes 6232 (6.0 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

 

enp3s16f1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        inet6 fe80::49f:fbff:fe7b:1b9f  prefixlen 64  scopeid 0x20<link>

        ether 06:9f:fb:7b:1b:9f  txqueuelen 1000  (Ethernet)

        RX packets 21  bytes 6126 (5.9 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 8  bytes 648 (648.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

 

enp3s16f3: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>  mtu 1500

        ether 7e:12:a8:d2:59:76  txqueuelen 1000  (Ethernet)

        RX packets 1  bytes 78 (78.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 49  bytes 8310 (8.1 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

The physical interface (eno4) is able to see all packets, but the VF interface (enp3s16f1) is not able to show promiscuous packets.

 

Does the x552/x557 support unicast/multicast promiscuous mode in VFs? If so, is this a hardware, driver, kernel, or user error.

 

Thanks in advance!

Image may be NSFW.
Clik here to view.

Jumpers for remote LED?

My server chassis has two LEDs for LAN connectivity and/or activity.

 

The motherboard does not have any such jumper, and I wanted to know if Intel had *any* NIC cards with a jumper for LAN activity and/or connectivity?


X550 Driver for Windows 10 (10.0.14393) WOL (Wake on LAN) not working

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,

Image may be NSFW.
Clik here to view.

I210: Device ID 1533 is sometimes 1531

Dear Intel Community

 

In our device we have two WGI210IT ethernet controllers and we are facing an issue with them: Very rarley, let's say less than once per 100 boot ups, we see that the device ID is 1531 instead of 1533. At the moment we cannot reproduce it, it just appears sometimes on our devices.

 

lspci under linux shows it like this:

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

02:00.0 Ethernet controller: Intel Corporation Device 1531 (rev 03)

 

After a reboot the Ethernet controller has ID 1533 again:

01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

 

Early at bootup of Linux the following message apears:

kernel: pci 0000:02:00.0: [8086:1531] type 00 class 0x020000

So it we doubt that any operating system related action causes the wrong ID.

 

The configuration is as follows:

- Ethernet controller firmware: Dev_Start_I210_Copper_SMB_8Mb_A2_3.25_0.03.bin

- Changes in Flash (On some devices done with Lanconf.exe under DOS and in others with eeupdate64e under Linux):

--> Word 0x20: Set bit 4 to '1' (disables Gbit Ethernet)

--> Changed MAC Address

- Gigabit Ethernet is not supported on HW side. MDI_PLUS_2 / MDI_MINUS_2 / MDI_PLUS_3 / MDI_MINUS_3 are pull-up to 1.5V via 49.9R resistors

- Flash: MX25L1606EZNI-12G

- 33R resistors in SPI lines (NVM_SI, NVM_SO, SVM_SK, NVM_CS#)

- Pin 12 is pulled-down with 10k (strap pin --> non secure mode)

 

Hardware checks:

- The I210 and the flash are powered from the same 3.3V source. First flash access happens after 25ms after 3.3V is reached. The flash itself requires 200us to be ready after Vmin is reached. So the flash is ready at first access.

- The signal levels of all SPI lines are fine.

- The solder points are checked and nothing wrong was seen.

 

We checked a few register values while the problem was seen:

Read at 0x90012010 | 0x40 0x2A 0x48 0x00 (Base address is 0x90000000)

The 1533 controller shows:

Read at 0x91312010 | 0x40 0x2B 0x08 0x06 (Base address is 0x91300000)

Differences:

EEPROM-Mode Control Register - EEC (0x12010) bit 8 is '0'. --> EE_PRES: No Flash with correct signature or empty iNVM

EEPROM-Mode Control Register - EEC (0x12010) bit 22 is '0'. --> Reserved: No info from datasheet

EEPROM-Mode Control Register - EEC (0x12010) bit 25 is '0'. --> SEC1VAL: Sector 1 not valid (but not meaning full due to bit 8 is '0')

EEPROM-Mode Control Register - EEC (0x12010) bit 26 is '0'. --> FLUDONE: No flash update done

 

Have you got any idea what could cause this problem?

 

Thank you in advance and best regards

Stefan

Rate limiting on Virtual Function

Hi,

I am using Intel 10 Gig Dual-Port Ethernet PCI Card (BN8110470) ixgbe driver on Ubuntu 14.04 Host.

I was able to create VF's which are listed below from lspci command:

 

02:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)

02:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01)

03:10.0 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:10.1 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:10.2 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:10.3 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:10.4 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:10.5 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:10.6 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:10.7 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:11.0 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:11.1 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:11.2 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:11.3 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:11.4 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

03:11.5 Ethernet controller: Intel Corporation X540 Ethernet Controller Virtual Function (rev 01)

 

The VF's are also listed from ip link command:

 

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

    link/ether a0:36:9f:11:b8:10 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 00:00:00:00:00:00, 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 00:00:00:00:00:00, spoof checking on, link-state auto

 

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

    link/ether a0:36:9f:11:b8:12 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 00:00:00:00:00:00, 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 00:00:00:00:00:00, vlan 10, spoof checking on, link-state auto

 

As visible from dev rename28, vf 6, assigning vlan is working as expected,

ip link set rename28 vf 6 vlan 10

But setting rate limit on same VF is working,

sudo ip link set rename28 vf 6 rate 250

RTNETLINK answers: Invalid argument

 

The guide used to realize this configuration is here, Configure QoS with Intel® Flexible Port Partitioning

I know that I should be using the latest iproute2, I am using iproute2-ss131122 which is never version.

Image may be NSFW.
Clik here to view.

X710 - eeprom check failed - Tx/Rx traffic disabled

Hello, I am using following Ethernet controller on one of our systems, and once in a while I run into following error after bootup, resulting in the port not sending/receiving packets. 

 

2016-12-13T01:06:55.499000+00:00 kernel: i40e 0000:20:00.3: eeprom check failed (-2), Tx/Rx traffic disabled

 

 

Following is the current version we use (which is quite old; we are in process of upgrading).  But does anyone know if this is a known issue and may be fixed in an upgraded driver and/or NVM?

 

System# lspci -s 0000:20:00.3

20:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GBASE-T (rev 01)

System# ethtool -i eth1

driver: i40e

version: 1.3.47

firmware-version: 4.43 0x80001c3f 1.1018.0

bus-info: 0000:20:00.3

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

System#

Thank you very much!

 

Intel(R) Ethernet Connection (2) I219-V - Windows Server 2012

On the download page it is clearly presented a download link for Intel(R) Ethernet Connection (2) I219-V...

 

The issue(s) are:

 

1. SSU.exe does not detect the HW too but presented at the device manager as a missing HW & driver

 

2. Installed a fresh MS Server 2012 with equal issue!

 

3. Installed Win 10 Pro and using the installer it shows the net1ic64.inf with 12.15.23.7 version

 

4. on same path are drivers for Win64/ NDIS62...NDIS65 meaning drivers for the WIn7....Win10

 

While using a brand new main-board with B150N chipset

 

Any help is welcome

 

Hp

Viewing all 4405 articles
Browse latest View live


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