gmane.linux.drivers.e1000.devel

link loss with Intel I340-T4 and CentOS 6.2

Nick — 2012-05-25T20:38:39

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi gang,

I'm writing to you with a very odd problem that I've been unable to
resolve.

I have a machine (SuperMicro H8SCM, AMD Opteron) with an I340-T4 PCIe
NIC connected.  I'm running CentOS 6.2 with the latest updated kernel.
 There's a single cable connecting the first port on the card to a switch.

When the machine POST's, the link light is on.  Even at the GRUB menu,
the link light is still on.  However, as soon as the kernel begins to
load, the link light disappears until I reboot.  Even rmmod'ing the
driver won't bring it back.

At first I thought it was a hardware problem.  So I swapped it out
with the other one I had.  (I bought two.)  Same issue.   Then I tried
a Fedora 16 live CD.  And everything "just worked."

FWIW, Ubuntu 10.04.4 has the same issue when I tested it.

So at this point, I know my hardware and network configuration are good.

What I can't figure out, is why the igb driver initializes perfectly,
but the link light never turns on?  I m

Re: Proper way to turn off VLAN tag stripping for 82599 (ixgbe 3.9.15 driver)?

Jesse Brandeburg — 2012-05-25T20:39:09

On Thu, 24 May 2012 11:08:02 -0700
Maniquis Angelo <amaniquis< at >yahoo.com> wrote:
 

Can't you just disable using ethtool?

        ethtool -K|--offload DEVNAME    Set protocol offload
                [ rx on|off ]
                [ tx on|off ]
                [ sg on|off ]
                [ tso on|off ]
                [ ufo on|off ]
                [ gso on|off ]
                [ gro on|off ]
                [ lro on|off ]
                [ rxvlan on|off ]
                [ txvlan on|off ]
                [ ntuple on|off ]
                [ rxhash on|off ]

You may need a more recent version of ethtool depending on which
version is shipped with your distro.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accela

Re: DMA mapping type and its performance impact

Alexander Duyck — 2012-05-25T16:42:01

William,

Based on the fact things are dropping to 0 it sounds like you might be
losing interrupts.  We have code that will re-trigger the interrupts
once every 2 seconds to deal with platforms that may occasionally lose
an MSI-X interrupt.  That could be one reason you are seeing it recover
after a second or so.  Try commenting out the ixgbe_irq_rearm_queues
call in the ixgbe_check_hang_subtask.  If the adapter completely stalls
and doesn't recover then the issue is lost interrupts and may be a signs
of problems with the MR-IOV environment.

The other thing that you might want to check for would be to determine
if your test is using UDP or TCP.  Typically for an issue like this I
would recommend running with UDP in order to guarantee something like a
dropped acknowledgement doesn't stall the stream.

If you still see issues after that the only other possibility I can
think of would be a problem with the DMA flow to/from the device.

Thanks,

Alex

On 05/23/2012 10:19 PM, William Tu wrote:


----------------

Re: Dell R720 SR-IOV failure with igb

Greg Rose — 2012-05-25T15:26:23

On Fri, 25 May 2012 09:03:21 -0600
Dax Kelson <dkelson< at >gurulabs.com> wrote:


OK, that's what I suspected.  Your config is missing the SR-IOV
capability structure.  It would look something like this:

        Capabilities: [160] Single Root I/O Virtualization (SR-IOV)
                IOVCap: Migration-, Interrupt Message Number: 000
                IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
                IOVSta: Migration-
                Initial VFs: 8, Total VFs: 8, Number of VFs: 0, Function Depende
ncy Link: 00
                VF offset: 384, stride: 4, Device ID: 1520
                Supported Page Size: 00000553, System Page Size: 00000001
                VF Migration: offset: 00000000, BIR: 1

This is from a dump on an I350 controller on one of my lab systems.

This is a feature that is controlled by EEPROM settings.  I'm guessing
that Dell has decided to defeature SR-IOV support for the I350 devices
on their daughter card.  Or they could have made a mistake in
programming the EEPROM.

Re: Dell R720 SR-IOV failure with igb

Dax Kelson — 2012-05-25T15:03:21


Thanks for replying Greg. Here is the information requested:

# lspci -vvv -s 08:00.0
08:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01)
Subsystem: Dell Gigabit 4P X540/I350 rNDC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin D routed to IRQ 19
Region 0: Memory at dae80000 (32-bit, non-prefetchable) [size=512K]
Region 2: I/O ports at ecc0 [size=32]
Region 3: Memory at daff8000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at da000000 [disabled] [size=512K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000  Data: 0000
Masking: 0000000

Re: Dell R720 SR-IOV failure with igb

Greg Rose — 2012-05-25T14:57:18

On Thu, 24 May 2012 17:17:44 -0600
Dax Kelson <dkelson< at >gurulabs.com> wrote:


I haven't seen one of these NIC daughterboards from Dell before but I
had heard about them.  Could you please send along the output of lspci
-vvv -s 08:00.0 and lspci -vvv -s 08:00.1?

The I350 should be supporting SR-IOV and in our lab we have 4 port NICs
with the I350 that work fine.  Having not seen these daughter cards
before I wonder if there is some difference between them.  Inspecting
the PCIe config might help.

Thanks,

- Greg




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel< at >lists.sourceforge.ne

Re: speed and speed_hi setting in ethtool_cmd

Shashidhara Shamaiah — 2012-05-25T12:18:33

Hi Bruce,

As the customer's release work is getting delayed due to inconsistent
ethtool behavior. Can you please have a look at my previous query and
provide a response.  

Thanks and Regards
Shashidhara

-----Original Message-----
From: Shashidhara Shamaiah 
Sent: Thursday, May 24, 2012 12:21 PM
To: 'Allan, Bruce W'
Cc: e1000-devel< at >lists.sourceforge.net; 'decot< at >google.com'
Subject: RE: [E1000-devel] speed and speed_hi setting in ethtool_cmd

Hi Allan,

Thanks for the information. My question is after setting speed =-1, if
the control unit executes either the if or the else blocks ( where speed
is modified). Then the next ethtool_cmd_speed_set(ecmd, speed) is called
which sets the 
ethool->speed and ethtool->speed_hi values . Is there a possible
scenario where neither the if nor the else block gets executed, and the
function ethtool_cmd_speed_set() sets the speed_hi and speed fields to
65535.  
Please do let me know if you need any other details.

Thanks and Regards
Shashidhara 

-----Original Message-----

免费国际拍卖网站是全新C2C,B2C用户网上购物商城

Perry — 2012-05-25T04:04:44

免费国外拍卖网站，免费C2C，B2C拍卖网站，免费外贸平台
想知道如何轻松把您的商品销售到欧美消费者，月赚5-10万美元吗？
全免费国外C2C,B2C外贸销售网平台，无须验证信用卡，电话号码，身份证明！！！
强力推荐全英文全免费国外C2C，B2C外贸平台，像EBAY,TAOBAO一样免费上传物品 
国外免费C2C，B2C，免费贸易平台，免费EBAy，免费外贸销售网 
有必得(uBider)-国际拍卖网站是全新C2C,B2C用户网上购物商城系统程序,整合了拍卖和一口价交易自带了多用户网店系统在线支付系统和物流系统等，有必得(uBider)-是C2C（客户对客户）的个人网上交易平台和平台型B2C电子商务服务商城，主要用于商品网上零售. 
http://www.ubider.com 
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has ch

Dell R720 SR-IOV failure with igb

Dax Kelson — 2012-05-24T23:17:44

I'm working on a Dell R720 server. The NIC daugherboard has 4 ports.
Qty 2 ports with X540-AT2 and Qty 2 ports with I350.

Using kernel 2.6.39-100.7.1.el6uek.x86_64 using ixgbe 3.9.15 and igb 3.4.7.

The max_vfs parameter is working properly with ixgbe NIC ports, but
max_vfs is failing with the igb driver.

# cat /etc/modprobe.d/ixgbe.conf
options ixgbe max_vfs=32,32
# cat /etc/modprobe.d/igb.conf
options igb max_vfs=7,7

# lspci
01:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10
Gigabit X540-AT2 (rev 01)
01:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10
Gigabit X540-AT2 (rev 01)
08:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network
Connection (rev 01)
08:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network
Connection (rev 01)

# dmesg
Intel(R) Gigabit Ethernet Network Driver - version 3.4.7
Copyright (c) 2007-2011 Intel Corporation.
igb 0000:08:00.0: PCI INT D -> GSI 19 (level, low) -> IRQ 19
igb 0000:08:00.0: setting latency timer to 64
igb:

Proper way to turn off VLAN tag stripping for 82599(ixgbe 3.9.15 driver)?

Maniquis Angelo — 2012-05-24T18:08:02

We had an issue where our Intel X520-SR2 was dropping VLAN tagged traffic in promiscuous mode.  I am no driver developer and have a rudimentary knowledge of linux kernels, so I took a hammer to the issue and got VLAN tagged traffic to show up by making the following modifications to the ixgbe-3.9.15 source and creating a new ixgbe.ko from that.


=====

--- ixgbe_main.c.orig    2012-05-23 18:31:34.000000000 +0000
+++ ixgbe_main.c    2012-05-23 19:12:13.000000000 +0000
< at >< at > -4227,17 +4227,7 < at >< at >
         ixgbe_irq_enable(adapter, true, true);
 #endif
 #ifdef HAVE_8021P_SUPPORT
-#ifdef HAVE_VLAN_RX_REGISTER
-    bool enable = (grp || (adapter->flags & IXGBE_FLAG_DCB_ENABLED));
-#else
-    bool enable = !!(features & NETIF_F_HW_VLAN_RX);
-#endif
-    if (enable)
-        /* enable VLAN tag insert/strip */
-        ixgbe_vlan_stripping_enable(adapter);
-    else
-        /* disable VLAN tag insert/strip */
-        ixgbe_vlan_stripping_disable(adapter);
+    ixg

Re: speed and speed_hi setting in ethtool_cmd

Shashidhara Shamaiah — 2012-05-24T06:51:20

Hi Allan,

Thanks for the information. My question is after setting speed =-1, if
the control unit executes either the if or the else blocks ( where speed
is modified). Then the next ethtool_cmd_speed_set(ecmd, speed) is called
which sets the 
ethool->speed and ethtool->speed_hi values . Is there a possible
scenario where neither the if nor the else block gets executed, and the
function ethtool_cmd_speed_set() sets the speed_hi and speed fields to
65535.  
Please do let me know if you need any other details.

Thanks and Regards
Shashidhara 

-----Original Message-----
From: Allan, Bruce W [mailto:bruce.w.allan< at >intel.com] 
Sent: Thursday, May 24, 2012 6:47 AM
To: Shashidhara Shamaiah; e1000-devel< at >lists.sourceforge.net
Subject: RE: [E1000-devel] speed and speed_hi setting in ethtool_cmd


The upstream commits that introduced these code changes were provided by
David Decotigny <decot< at >google.com> and are believed to be correct.  Are
you having any issues with the operation of the driver?


Information transmitte

problem with simplified balancing on 82574 chips

Nishit Shah — 2012-05-24T06:42:47

Hi,

     We are getting good amount of delay even on a normal ping when we 
set InterruptThrottleRate as 4 (simplified balancing) on 82574 chips. On 
the other side it is working properly with 82571,82572 and 82573 chips.
     Second issue is when we do ethtool -C eth0 rx-usecs 4, we require 
to do ifconfig eth0 down and up to have the effect whereas 82571,82572 
and 82573 don't require it.

     Driver used: e1000e-1.9.5

     Ping reply with rx-usecs 3

     # ping 10.1.0.2
     PING 10.1.0.2 (10.1.0.2): 56 data bytes
     64 bytes from 10.1.0.2: seq=0 ttl=64 time=0.088 ms
     64 bytes from 10.1.0.2: seq=1 ttl=64 time=0.068 ms
     64 bytes from 10.1.0.2: seq=2 ttl=64 time=0.118 ms
     64 bytes from 10.1.0.2: seq=3 ttl=64 time=0.065 ms
     64 bytes from 10.1.0.2: seq=4 ttl=64 time=0.131 ms

     Ping reply with rx-usecs 4

     # ping 10.1.0.2
     PING 10.1.0.2 (10.1.0.2): 56 data bytes
     64 bytes from 10.1.0.2: seq=0 ttl=64 *time=32.178 ms*
     64 bytes from 10.1.0.2: seq=1 ttl=64 *time=15.137 m

全免费国外C2C,B2C外贸销售网平台，无须验证信用卡，电话号码

GREgary — 2012-05-23T05:39:46

免费国外拍卖网站，免费C2C，B2C拍卖网站，免费外贸平台
想知道如何轻松把您的商品销售到欧美消费者，月赚5-10万美元吗？
全免费国外C2C,B2C外贸销售网平台，无须验证信用卡，电话号码，身份证明！！！
强力推荐全英文全免费国外C2C，B2C外贸平台，像EBAY,TAOBAO一样免费上传物品 
国外免费C2C，B2C，免费贸易平台，免费EBAy，免费外贸销售网 
有必得(uBider)-国际拍卖网站是全新C2C,B2C用户网上购物商城系统程序,整合了拍卖和一口价交易自带了多用户网店系统在线支付系统和物流系统等，有必得(uBider)-是C2C（客户对客户）的个人网上交易平台和平台型B2C电子商务服务商城，主要用于商品网上零售. 
http://www.ubider.com 
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has ch

Re: DMA mapping type and its performance impact

William Tu — 2012-05-24T05:19:23

Hi Alex,

Thanks for the suggestion! It turns out that the overhead of skb_copy
and netdev_alloc_skb is because I turned on the kernel debugging
option for SLUB memory allocator (CONFIG_SLUB_DEBUG). That's why I got
an extremely longer memory allocation time, which slows down my RX
throughput!

In our case, we are trying to deliver a software-based MR-SRIOV
system. We run the PF driver on one host (H1) and multiple VF drivers
on another host (H2). Between H1 and H2, there is a memory
sharing/interrupt forwarding device for H2 VF to communicate with H1
PF.

Right now my RX performance is achieving 9G but is a little bit unstable:
* About every 10 seconds the throughput is dropped to almost zero and
resume full speed again. Does anyone run into this issue before? Or
any suggestions are appreciated!

[  3] local 192.168.1.4 port 35451 connected with 192.168.1.21 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 1.0 sec   428 MBytes  3.59 Gbits/sec
[  3]  1.0- 2.0 sec  0.00 Bytes  0.00 bits/sec
[

Re: speed and speed_hi setting in ethtool_cmd

Allan, Bruce W — 2012-05-24T01:17:29

The upstream commits that introduced these code changes were provided by David Decotigny <decot< at >google.com> and are believed to be correct.  Are you having any issues with the operation of the driver?


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

Re: [Bug 43277] New: net/e1000e set mtu larger than1500 fails

Stephen Hemminger — 2012-05-22T21:29:23

On Tue, 22 May 2012 19:59:16 +0100
Ben Hutchings <bhutchings< at >solarflare.com> wrote:


Agreed. Principal of least surprise says the best thing to
do would be turn off features that are performance improvements to allow
user to do what they wanted (and turn the error into a warning).

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

Re: [Bug 43277] New: net/e1000e set mtu larger than1500 fails

Christer Ekholm — 2012-05-22T18:39:49

 > On Tue, 22 May 2012 11:19:50 -0700
 > Stephen Hemminger <shemminger< at >vyatta.com> wrote:
 > 
 > 
 > I believe the problem is detected here. Check system console log (dmesg).
 > The hardware does not allow receive hashing and checksum offload together
 > in Jumbo mode.
 > 
 > /*
 >  * IP payload checksum (enabled with jumbos/packet-split when
 >  * Rx checksum is enabled) and generation of RSS hash is
 >  * mutually exclusive in the hardware.
 >  */
 > if ((netdev->features & NETIF_F_RXCSUM) &&
 >     (netdev->features & NETIF_F_RXHASH)) {
 > e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled.  Disable one of the receive offload features before enabling jumbos.\n");
 > return -EINVAL;
 > }

Yes you are right.

 e1000e 0000:05:00.1: eth1: Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled.  Disable one of the receive offload features before enabling jumbos.

How stupid of me to not see that. 

Afte

Re: [Bug 43277] New: net/e1000e set mtu larger than1500 fails

Ben Hutchings — 2012-05-22T18:59:16

It's not a waste of time.

I think this behaviour is broken: NETIF_F_RXHASH is turned on by default
and user and distribution scripts that set MTU will now be broken until
they know that they need to work around this hardware limitation.  And
why should they ever need to know that?

I think the proper thing to do is to automatically turn off
NETIF_F_RXHASH when the MTU is too high for it to work.  The netdev
still keeps track of whether it is 'wanted'.

Ben.

Fw: [Bug 43277] New: net/e1000e set mtu larger than1500 fails

Stephen Hemminger — 2012-05-22T18:19:50


Begin forwarded message:

Date: Tue, 22 May 2012 18:13:21 +0000 (UTC)
From: bugzilla-daemon< at >bugzilla.kernel.org
To: shemminger< at >linux-foundation.org
Subject: [Bug 43277] New: net/e1000e set mtu larger than 1500 fails


https://bugzilla.kernel.org/show_bug.cgi?id=43277

           Summary: net/e1000e set mtu larger than 1500 fails
           Product: Networking
           Version: 2.5
    Kernel Version: 3.4
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
        AssignedTo: shemminger< at >linux-foundation.org
        ReportedBy: che< at >chrekh.se
        Regression: Yes


In kernel 3.4 I can no longer use jumbo-frames with my e1000e network
interface.

 $ sudo ip link set eth1 mtu 9000
 RTNETLINK answers: Invalid argument

Card-info (from kernel-log)

 e1000e 0000:05:00.1: eth1: (PCI Express:2.5GT/s:Width x4) 00:1b:78:59:84:25
 e1000e 0000:05:00.1: eth1: Intel(R) PRO/1000 Network Connect

Re: [Bug 43277] New: net/e1000e set mtu larger than1500 fails

Stephen Hemminger — 2012-05-22T18:25:18

On Tue, 22 May 2012 11:19:50 -0700
Stephen Hemminger <shemminger< at >vyatta.com> wrote:


I believe the problem is detected here. Check system console log (dmesg).
The hardware does not allow receive hashing and checksum offload together
in Jumbo mode.

/*
 * IP payload checksum (enabled with jumbos/packet-split when
 * Rx checksum is enabled) and generation of RSS hash is
 * mutually exclusive in the hardware.
 */
if ((netdev->features & NETIF_F_RXCSUM) &&
    (netdev->features & NETIF_F_RXHASH)) {
e_err("Jumbo frames cannot be enabled when both receive checksum offload and receive hashing are enabled.  Disable one of the receive offload features before enabling jumbos.\n");
return -EINVAL;
}

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the l

Re: [Bug 43277] New: net/e1000e set mtu larger than1500 fails

Allan, Bruce W — 2012-05-22T18:28:12

That is correct.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired