Re: [E1000-devel] X710 / i40e interface resets
> -Original Message- > From: Christian Ruppert [mailto:id...@qasl.de] > Sent: Monday, November 09, 2015 1:17 AM > To: Rose, Gregory V > Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > Subject: RE: [E1000-devel] X710 / i40e interface resets > > > The system is running about a month without any resets but having TSO and > GSO disabled. Does it have a performance impact with TSO/GSO disabled, or > any other disadvantages? We haven't done any benchmarks yet. Yes, I'm certain there are performance disadvantages with certain traffic profiles. However, I've been pulled off of this issue and working others for the last few weeks. I do hope to get back to this. Thanks, - Greg > > -- > Regards, > Christian Ruppert -- Presto, an open source distributed SQL query engine for big data, initially developed by Facebook, enables you to easily query your data on Hadoop in a more interactive manner. Teradata is also now providing full enterprise support for Presto. Download a free open source copy now. http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] X710 / i40e interface resets
On 2015-10-23 09:34, Christian Ruppert wrote: > On 2015-10-21 01:30, Rose, Gregory V wrote: >>> -Original Message- >>> From: Christian Ruppert [mailto:id...@qasl.de] >>> Sent: Thursday, October 15, 2015 4:02 AM >>> To: Rose, Gregory V >>> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >>> Subject: RE: [E1000-devel] X710 / i40e interface resets >>> >>> On 2015-10-08 17:05, Rose, Gregory V wrote: >>> >> -Original Message- >>> >> From: Christian Ruppert [mailto:id...@qasl.de] >>> >> Sent: Thursday, October 08, 2015 7:34 AM >>> >> To: Rose, Gregory V >>> >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >>> >> Subject: RE: [E1000-devel] X710 / i40e interface resets >>> > Please try turning off TSO/GSO to see if that helps. >>> >>> That seems to help. No more resets. Do you want me to enable TSO or >>> GSO >>> again to see which one exactly cause those resets? Or do you want me >>> to do >>> anything else? >>> >> >> Sorry for the delayed response but I've been out of the office for the >> last week. > > No problem! ;) > >> >> Yes, please do try disabling TSO and GSO separately - I suspect that >> internally to the driver it won't make a difference but if it does >> then it would be good to know. > > You seem to be right, no resets, nothing unusual currently. > >> >> Thanks! >> >> - Greg The system is running about a month without any resets but having TSO and GSO disabled. Does it have a performance impact with TSO/GSO disabled, or any other disadvantages? We haven't done any benchmarks yet. -- Regards, Christian Ruppert -- Presto, an open source distributed SQL query engine for big data, initially developed by Facebook, enables you to easily query your data on Hadoop in a more interactive manner. Teradata is also now providing full enterprise support for Presto. Download a free open source copy now. http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140 ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] X710 / i40e interface resets
On 2015-10-21 01:30, Rose, Gregory V wrote: >> -Original Message- >> From: Christian Ruppert [mailto:id...@qasl.de] >> Sent: Thursday, October 15, 2015 4:02 AM >> To: Rose, Gregory V >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> >> On 2015-10-08 17:05, Rose, Gregory V wrote: >> >> -Original Message- >> >> From: Christian Ruppert [mailto:id...@qasl.de] >> >> Sent: Thursday, October 08, 2015 7:34 AM >> >> To: Rose, Gregory V >> >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> > Please try turning off TSO/GSO to see if that helps. >> >> That seems to help. No more resets. Do you want me to enable TSO or >> GSO >> again to see which one exactly cause those resets? Or do you want me >> to do >> anything else? >> > > Sorry for the delayed response but I've been out of the office for the > last week. No problem! ;) > > Yes, please do try disabling TSO and GSO separately - I suspect that > internally to the driver it won't make a difference but if it does > then it would be good to know. You seem to be right, no resets, nothing unusual currently. > > Thanks! > > - Greg -- Regards, Christian Ruppert -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] X710 / i40e interface resets
> -Original Message- > From: Christian Ruppert [mailto:id...@qasl.de] > Sent: Thursday, October 15, 2015 4:02 AM > To: Rose, Gregory V > Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > Subject: RE: [E1000-devel] X710 / i40e interface resets > > On 2015-10-08 17:05, Rose, Gregory V wrote: > >> -Original Message- > >> From: Christian Ruppert [mailto:id...@qasl.de] > >> Sent: Thursday, October 08, 2015 7:34 AM > >> To: Rose, Gregory V > >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > >> Subject: RE: [E1000-devel] X710 / i40e interface resets > > Please try turning off TSO/GSO to see if that helps. > > That seems to help. No more resets. Do you want me to enable TSO or GSO > again to see which one exactly cause those resets? Or do you want me to do > anything else? > Sorry for the delayed response but I've been out of the office for the last week. Yes, please do try disabling TSO and GSO separately - I suspect that internally to the driver it won't make a difference but if it does then it would be good to know. Thanks! - Greg -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] X710 / i40e interface resets
On 2015-10-08 17:05, Rose, Gregory V wrote: >> -Original Message- >> From: Christian Ruppert [mailto:id...@qasl.de] >> Sent: Thursday, October 08, 2015 7:34 AM >> To: Rose, Gregory V >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> >> On 2015-10-08 16:23, Rose, Gregory V wrote: >> >> -Original Message- >> >> From: Christian Ruppert [mailto:id...@qasl.de] >> >> Sent: Wednesday, October 07, 2015 10:54 AM >> >> To: Rose, Gregory V >> >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> >> >> >> On 2015-10-07 18:49, Rose, Gregory V wrote: >> >> >> -Original Message- >> >> >> From: Christian Ruppert [mailto:id...@qasl.de] >> >> >> Sent: Wednesday, October 07, 2015 8:00 AM >> >> >> To: Rose, Gregory V >> >> >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> >> >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> >> >> >> >> > >> > >> > [snip] >> > >> >> > Maybe, but first let me ask you if you're using the VEPA mode work >> >> > around for bonding? >> >> > >> >> >> >> No, just the basic bonding in 802.3ad mode. We don't use VEPA at all. >> > >> > Can you send me the output of the command "bridge link show"? >> >> 3: eth0 state UP : <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 >> master >> bond0 hwmode VEPA >> 5: eth1 state UP : <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 >> master >> bond0 hwmode VEPA >> >> hm, now that's interesting... > > That is exactly what we want to see. The XL710/X710 controllers have > an internal switch for when SR-IOV mode is used so that all the VFs on > that controller can communicate with each other across the bridge. If > the hwmode had been VEB then that would indicate a problem. However, > you're in the correct internal switch mode for LACP operation. > > Please try turning off TSO/GSO to see if that helps. That seems to help. No more resets. Do you want me to enable TSO or GSO again to see which one exactly cause those resets? Or do you want me to do anything else? > > If not can I get you to enter a bug ticket at the Intel SF site? > > Please include the following: > > Results of 'ethtool -i' on each X710 interface. > Results of 'ehtool' on each X710 interface. > Results of 'ip link show' and 'ip addr show'. > The system log obtained via 'dmesg' *after* the error has occurred. > > That should get us started. > > Thanks! > > - Greg > >> >> > >> > Thanks, >> > >> > - Greg >> >> -- >> Regards, >> Christian Ruppert -- Regards, Christian Ruppert -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] X710 / i40e interface resets
> -Original Message- > From: Christian Ruppert [mailto:id...@qasl.de] > Sent: Wednesday, October 07, 2015 10:54 AM > To: Rose, Gregory V > Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > Subject: RE: [E1000-devel] X710 / i40e interface resets > > On 2015-10-07 18:49, Rose, Gregory V wrote: > >> -Original Message- > >> From: Christian Ruppert [mailto:id...@qasl.de] > >> Sent: Wednesday, October 07, 2015 8:00 AM > >> To: Rose, Gregory V > >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > >> Subject: RE: [E1000-devel] X710 / i40e interface resets > >> > > [snip] > > Maybe, but first let me ask you if you're using the VEPA mode work > > around for bonding? > > > > No, just the basic bonding in 802.3ad mode. We don't use VEPA at all. Can you send me the output of the command "bridge link show"? Thanks, - Greg -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] X710 / i40e interface resets
> -Original Message- > From: Christian Ruppert [mailto:id...@qasl.de] > Sent: Thursday, October 08, 2015 7:34 AM > To: Rose, Gregory V > Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > Subject: RE: [E1000-devel] X710 / i40e interface resets > > On 2015-10-08 16:23, Rose, Gregory V wrote: > >> -Original Message- > >> From: Christian Ruppert [mailto:id...@qasl.de] > >> Sent: Wednesday, October 07, 2015 10:54 AM > >> To: Rose, Gregory V > >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > >> Subject: RE: [E1000-devel] X710 / i40e interface resets > >> > >> On 2015-10-07 18:49, Rose, Gregory V wrote: > >> >> -Original Message- > >> >> From: Christian Ruppert [mailto:id...@qasl.de] > >> >> Sent: Wednesday, October 07, 2015 8:00 AM > >> >> To: Rose, Gregory V > >> >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > >> >> Subject: RE: [E1000-devel] X710 / i40e interface resets > >> >> > >> > > > > > [snip] > > > >> > Maybe, but first let me ask you if you're using the VEPA mode work > >> > around for bonding? > >> > > >> > >> No, just the basic bonding in 802.3ad mode. We don't use VEPA at all. > > > > Can you send me the output of the command "bridge link show"? > > 3: eth0 state UP : <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 master > bond0 hwmode VEPA > 5: eth1 state UP : <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 master > bond0 hwmode VEPA > > hm, now that's interesting... That is exactly what we want to see. The XL710/X710 controllers have an internal switch for when SR-IOV mode is used so that all the VFs on that controller can communicate with each other across the bridge. If the hwmode had been VEB then that would indicate a problem. However, you're in the correct internal switch mode for LACP operation. Please try turning off TSO/GSO to see if that helps. If not can I get you to enter a bug ticket at the Intel SF site? Please include the following: Results of 'ethtool -i' on each X710 interface. Results of 'ehtool' on each X710 interface. Results of 'ip link show' and 'ip addr show'. The system log obtained via 'dmesg' *after* the error has occurred. That should get us started. Thanks! - Greg > > > > > Thanks, > > > > - Greg > > -- > Regards, > Christian Ruppert -- ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] X710 / i40e interface resets
On 2015-10-07 16:14, Rose, Gregory V wrote: >> -Original Message- >> From: Christian Ruppert [mailto:id...@qasl.de] >> Sent: Wednesday, October 07, 2015 12:59 AM >> To: Rose, Gregory V >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> >> Is there anything else I can do to help to get that debugged/fixed? >> We upgraded the connection from 1G to 10G btw (it was 1G before). > > We'll need to get a setup to reproduce the problem so we can debug it. > Can you provide that information? Or perhaps you've provided it > before and I'm just not seeing it? If that's the case can you point > me to it again? > > Thanks, > > - Greg Hi Greg, in this case it's a Supermicro 5017C-MTF (X9SCL/X9SCM) using a X710 10GE card, both ports connected to 10GE switch ports (LACP). WAN->Router->Swich->Host The host in this case acts as a loadbalancer using e.g. Varnish and HAProxy and doing mostly HTTP traffic (also SSL termination). Do you need anything else? > >> >> On 2015-09-28 16:53, Christian Ruppert wrote: >> > And there we go: >> > >> > [77571.409182] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [77572.245943] bond0: link status up again after 0 ms for interface >> > eth1 >> > [94412.738896] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [94413.569379] bond0: link status up again after 0 ms for interface >> > eth1 >> > [94516.443592] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [94516.718341] bond0: link status up again after 0 ms for interface >> > eth1 >> > [96850.580882] i40e :02:00.0: TX driver issue detected, PF reset >> > issued >> > [96851.036998] bond0: link status up again after 0 ms for interface >> > eth0 >> > [96939.474122] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [96940.217799] bond0: link status up again after 0 ms for interface >> > eth1 >> > [96945.007365] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [96945.225029] bond0: link status up again after 0 ms for interface >> > eth1 >> > [96965.362669] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [96966.255350] bond0: link status up again after 0 ms for interface >> > eth1 >> > [99844.991331] i40e :02:00.0: TX driver issue detected, PF reset >> > issued >> > [99845.360288] bond0: link status up again after 0 ms for interface >> > eth0 >> > [159908.054220] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [159909.165679] bond0: link status up again after 0 ms for interface >> > eth1 >> > [329531.138706] i40e :02:00.1: TX driver issue detected, PF reset >> > issued >> > [329532.167421] bond0: link status up again after 0 ms for interface >> > eth1 >> > >> > On 2015-09-25 16:19, Christian Ruppert wrote: >> >> Hi, >> >> >> >> the card came back and I had to flash it again but it worked perfectly >> >> fine this time :) >> >> So I setup a new Kernel (3.18.20) and the most recent i40e driver >> >> (1.3.39.1) and removed the previous workaround to disable ntuples on >> >> both interfaces. So basically a vanilla setup. >> >> That host is up for several hours no and there was no spam so far and >> >> only one reset yet: >> >> Sep 25 12:38:54 somehost kernel: [77571.409182] i40e :02:00.1: TX >> >> driver issue detected, PF reset issued >> >> Sep 25 12:38:55 somehost kernel: [77572.245943] bond0: link status up >> >> again after 0 ms for interface eth1 >> >> >> >> and here's the requested dmesg again: >> >> [0.00] Initializing cgroup subsys cpuset >> >> [0.00] Initializing cgroup subsys cpu >> >> [0.00] Initializing cgroup subsys cpuacct >> >> [0.00] Linux version 3.18.20 (fud@somehost) (gcc version 4.7.2 >> >> (Debian 4.7.2-5) ) #1 SMP Wed Aug 26 14:25:15 CEST 2015 >> >> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.18.20 >> >> root=UUID=ea7a13a2-a96b-4165-801a-119b0f0d9b8f ro ipv6.disable=1 >> >> intel_pstate=disable earlyprintk=ttyS0,115200,keep intel_iommu=off >> >> [0.00] e820: BIOS-provided physical RAM map: >> >> [0.00] BIOS-e820: [mem 0x000
Re: [E1000-devel] X710 / i40e interface resets
On 2015-10-07 17:00, Christian Ruppert wrote: > On 2015-10-07 16:14, Rose, Gregory V wrote: >>> -Original Message- >>> From: Christian Ruppert [mailto:id...@qasl.de] >>> Sent: Wednesday, October 07, 2015 12:59 AM >>> To: Rose, Gregory V >>> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >>> Subject: RE: [E1000-devel] X710 / i40e interface resets >>> >>> Is there anything else I can do to help to get that debugged/fixed? >>> We upgraded the connection from 1G to 10G btw (it was 1G before). >> >> We'll need to get a setup to reproduce the problem so we can debug it. >> Can you provide that information? Or perhaps you've provided it >> before and I'm just not seeing it? If that's the case can you point >> me to it again? >> >> Thanks, >> >> - Greg > > Hi Greg, > > in this case it's a Supermicro 5017C-MTF (X9SCL/X9SCM) using a X710 > 10GE card, both ports connected to 10GE switch ports (LACP). > WAN->Router->Swich->Host > The host in this case acts as a loadbalancer using e.g. Varnish and > HAProxy and doing mostly HTTP traffic (also SSL termination). > Do you need anything else? Oh, and it's a Debian Wheezy, using a 3.18.30 Kernel (based on the Debian config though) and recent i40e drivers (1.3.39.1). > >> >>> >>> On 2015-09-28 16:53, Christian Ruppert wrote: >>> > And there we go: >>> > >>> > [77571.409182] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [77572.245943] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > [94412.738896] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [94413.569379] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > [94516.443592] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [94516.718341] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > [96850.580882] i40e :02:00.0: TX driver issue detected, PF reset >>> > issued >>> > [96851.036998] bond0: link status up again after 0 ms for interface >>> > eth0 >>> > [96939.474122] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [96940.217799] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > [96945.007365] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [96945.225029] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > [96965.362669] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [96966.255350] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > [99844.991331] i40e :02:00.0: TX driver issue detected, PF reset >>> > issued >>> > [99845.360288] bond0: link status up again after 0 ms for interface >>> > eth0 >>> > [159908.054220] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [159909.165679] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > [329531.138706] i40e :02:00.1: TX driver issue detected, PF reset >>> > issued >>> > [329532.167421] bond0: link status up again after 0 ms for interface >>> > eth1 >>> > >>> > On 2015-09-25 16:19, Christian Ruppert wrote: >>> >> Hi, >>> >> >>> >> the card came back and I had to flash it again but it worked perfectly >>> >> fine this time :) >>> >> So I setup a new Kernel (3.18.20) and the most recent i40e driver >>> >> (1.3.39.1) and removed the previous workaround to disable ntuples on >>> >> both interfaces. So basically a vanilla setup. >>> >> That host is up for several hours no and there was no spam so far and >>> >> only one reset yet: >>> >> Sep 25 12:38:54 somehost kernel: [77571.409182] i40e :02:00.1: TX >>> >> driver issue detected, PF reset issued >>> >> Sep 25 12:38:55 somehost kernel: [77572.245943] bond0: link status up >>> >> again after 0 ms for interface eth1 >>> >> >>> >> and here's the requested dmesg again: >>> >> [0.00] Initializing cgroup subsys cpuset >>> >> [0.00] Initializing cgroup subsys cpu >>> >> [0.00] Initializing cgroup subs
Re: [E1000-devel] X710 / i40e interface resets
On 2015-10-07 18:49, Rose, Gregory V wrote: >> -Original Message- >> From: Christian Ruppert [mailto:id...@qasl.de] >> Sent: Wednesday, October 07, 2015 8:00 AM >> To: Rose, Gregory V >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> >> On 2015-10-07 16:14, Rose, Gregory V wrote: >> >> -Original Message- >> >> From: Christian Ruppert [mailto:id...@qasl.de] >> >> Sent: Wednesday, October 07, 2015 12:59 AM >> >> To: Rose, Gregory V >> >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net >> >> Subject: RE: [E1000-devel] X710 / i40e interface resets >> >> >> >> Is there anything else I can do to help to get that debugged/fixed? >> >> We upgraded the connection from 1G to 10G btw (it was 1G before). >> > >> > We'll need to get a setup to reproduce the problem so we can debug it. >> > Can you provide that information? Or perhaps you've provided it >> > before and I'm just not seeing it? If that's the case can you point >> > me to it again? >> > >> > Thanks, >> > >> > - Greg >> >> Hi Greg, >> >> in this case it's a Supermicro 5017C-MTF (X9SCL/X9SCM) using a X710 >> 10GE >> card, both ports connected to 10GE switch ports (LACP). >> WAN->Router->Swich->Host >> The host in this case acts as a loadbalancer using e.g. Varnish and >> HAProxy and doing mostly HTTP traffic (also SSL termination). >> Do you need anything else? > > Maybe, but first let me ask you if you're using the VEPA mode work > around for bonding? > No, just the basic bonding in 802.3ad mode. We don't use VEPA at all. > - Greg > >> >> > >> >> >> >> On 2015-09-28 16:53, Christian Ruppert wrote: >> >> > And there we go: >> >> > >> >> > [77571.409182] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [77572.245943] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > [94412.738896] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [94413.569379] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > [94516.443592] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [94516.718341] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > [96850.580882] i40e :02:00.0: TX driver issue detected, PF reset >> >> > issued >> >> > [96851.036998] bond0: link status up again after 0 ms for interface >> >> > eth0 >> >> > [96939.474122] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [96940.217799] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > [96945.007365] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [96945.225029] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > [96965.362669] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [96966.255350] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > [99844.991331] i40e :02:00.0: TX driver issue detected, PF reset >> >> > issued >> >> > [99845.360288] bond0: link status up again after 0 ms for interface >> >> > eth0 >> >> > [159908.054220] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [159909.165679] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > [329531.138706] i40e :02:00.1: TX driver issue detected, PF reset >> >> > issued >> >> > [329532.167421] bond0: link status up again after 0 ms for interface >> >> > eth1 >> >> > >> >> > On 2015-09-25 16:19, Christian Ruppert wrote: >> >> >> Hi, >> >> >> >> >> >> the card came back and I had to flash it again but it worked >> perfectly >> >> >> fine this time :) >> >> >> So I setup a new Kernel (3.18.20) and the most recent i40e driver >> >> >> (1.3.39.1) and removed the previous workaround to disable ntuples on >
Re: [E1000-devel] X710 / i40e interface resets
> -Original Message- > From: Christian Ruppert [mailto:id...@qasl.de] > Sent: Wednesday, October 07, 2015 12:59 AM > To: Rose, Gregory V > Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > Subject: RE: [E1000-devel] X710 / i40e interface resets > > Is there anything else I can do to help to get that debugged/fixed? > We upgraded the connection from 1G to 10G btw (it was 1G before). We'll need to get a setup to reproduce the problem so we can debug it. Can you provide that information? Or perhaps you've provided it before and I'm just not seeing it? If that's the case can you point me to it again? Thanks, - Greg > > On 2015-09-28 16:53, Christian Ruppert wrote: > > And there we go: > > > > [77571.409182] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [77572.245943] bond0: link status up again after 0 ms for interface > > eth1 > > [94412.738896] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [94413.569379] bond0: link status up again after 0 ms for interface > > eth1 > > [94516.443592] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [94516.718341] bond0: link status up again after 0 ms for interface > > eth1 > > [96850.580882] i40e :02:00.0: TX driver issue detected, PF reset > > issued > > [96851.036998] bond0: link status up again after 0 ms for interface > > eth0 > > [96939.474122] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [96940.217799] bond0: link status up again after 0 ms for interface > > eth1 > > [96945.007365] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [96945.225029] bond0: link status up again after 0 ms for interface > > eth1 > > [96965.362669] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [96966.255350] bond0: link status up again after 0 ms for interface > > eth1 > > [99844.991331] i40e :02:00.0: TX driver issue detected, PF reset > > issued > > [99845.360288] bond0: link status up again after 0 ms for interface > > eth0 > > [159908.054220] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [159909.165679] bond0: link status up again after 0 ms for interface > > eth1 > > [329531.138706] i40e :02:00.1: TX driver issue detected, PF reset > > issued > > [329532.167421] bond0: link status up again after 0 ms for interface > > eth1 > > > > On 2015-09-25 16:19, Christian Ruppert wrote: > >> Hi, > >> > >> the card came back and I had to flash it again but it worked perfectly > >> fine this time :) > >> So I setup a new Kernel (3.18.20) and the most recent i40e driver > >> (1.3.39.1) and removed the previous workaround to disable ntuples on > >> both interfaces. So basically a vanilla setup. > >> That host is up for several hours no and there was no spam so far and > >> only one reset yet: > >> Sep 25 12:38:54 somehost kernel: [77571.409182] i40e :02:00.1: TX > >> driver issue detected, PF reset issued > >> Sep 25 12:38:55 somehost kernel: [77572.245943] bond0: link status up > >> again after 0 ms for interface eth1 > >> > >> and here's the requested dmesg again: > >> [0.00] Initializing cgroup subsys cpuset > >> [0.00] Initializing cgroup subsys cpu > >> [0.00] Initializing cgroup subsys cpuacct > >> [0.00] Linux version 3.18.20 (fud@somehost) (gcc version 4.7.2 > >> (Debian 4.7.2-5) ) #1 SMP Wed Aug 26 14:25:15 CEST 2015 > >> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.18.20 > >> root=UUID=ea7a13a2-a96b-4165-801a-119b0f0d9b8f ro ipv6.disable=1 > >> intel_pstate=disable earlyprintk=ttyS0,115200,keep intel_iommu=off > >> [0.00] e820: BIOS-provided physical RAM map: > >> [0.00] BIOS-e820: [mem 0x-0x00099bff] > >> usable > >> [0.00] BIOS-e820: [mem 0x00099c00-0x0009] > >> reserved > >> [0.00] BIOS-e820: [mem 0x000e-0x000f] > >> reserved > >> [0.00] BIOS-e820: [mem 0x0010-0xbecc8fff] > >> usable > >> [0.00] BIOS-e820: [mem 0xbecc9000-0xbed0bfff] > >> ACPI NVS > >> [0.00] BIOS-e820: [mem 0xbed0c000-0xce491fff] > >> usable > >> [0.00] BIOS-e820: [mem 0xce492000-0xce534fff] > >> reserved > >> [0.00] BIOS-e820: [mem 0x00
Re: [E1000-devel] X710 / i40e interface resets
> -Original Message- > From: Christian Ruppert [mailto:id...@qasl.de] > Sent: Wednesday, October 07, 2015 8:00 AM > To: Rose, Gregory V > Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > Subject: RE: [E1000-devel] X710 / i40e interface resets > > On 2015-10-07 16:14, Rose, Gregory V wrote: > >> -Original Message- > >> From: Christian Ruppert [mailto:id...@qasl.de] > >> Sent: Wednesday, October 07, 2015 12:59 AM > >> To: Rose, Gregory V > >> Cc: Fujinaka, Todd; e1000-de...@lists.sf.net > >> Subject: RE: [E1000-devel] X710 / i40e interface resets > >> > >> Is there anything else I can do to help to get that debugged/fixed? > >> We upgraded the connection from 1G to 10G btw (it was 1G before). > > > > We'll need to get a setup to reproduce the problem so we can debug it. > > Can you provide that information? Or perhaps you've provided it > > before and I'm just not seeing it? If that's the case can you point > > me to it again? > > > > Thanks, > > > > - Greg > > Hi Greg, > > in this case it's a Supermicro 5017C-MTF (X9SCL/X9SCM) using a X710 10GE > card, both ports connected to 10GE switch ports (LACP). > WAN->Router->Swich->Host > The host in this case acts as a loadbalancer using e.g. Varnish and > HAProxy and doing mostly HTTP traffic (also SSL termination). > Do you need anything else? Maybe, but first let me ask you if you're using the VEPA mode work around for bonding? - Greg > > > > >> > >> On 2015-09-28 16:53, Christian Ruppert wrote: > >> > And there we go: > >> > > >> > [77571.409182] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [77572.245943] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > [94412.738896] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [94413.569379] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > [94516.443592] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [94516.718341] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > [96850.580882] i40e :02:00.0: TX driver issue detected, PF reset > >> > issued > >> > [96851.036998] bond0: link status up again after 0 ms for interface > >> > eth0 > >> > [96939.474122] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [96940.217799] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > [96945.007365] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [96945.225029] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > [96965.362669] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [96966.255350] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > [99844.991331] i40e :02:00.0: TX driver issue detected, PF reset > >> > issued > >> > [99845.360288] bond0: link status up again after 0 ms for interface > >> > eth0 > >> > [159908.054220] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [159909.165679] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > [329531.138706] i40e :02:00.1: TX driver issue detected, PF reset > >> > issued > >> > [329532.167421] bond0: link status up again after 0 ms for interface > >> > eth1 > >> > > >> > On 2015-09-25 16:19, Christian Ruppert wrote: > >> >> Hi, > >> >> > >> >> the card came back and I had to flash it again but it worked > perfectly > >> >> fine this time :) > >> >> So I setup a new Kernel (3.18.20) and the most recent i40e driver > >> >> (1.3.39.1) and removed the previous workaround to disable ntuples on > >> >> both interfaces. So basically a vanilla setup. > >> >> That host is up for several hours no and there was no spam so far > and > >> >> only one reset yet: > >> >> Sep 25 12:38:54 somehost kernel: [77571.409182] i40e :02:00.1: > TX > >> >> driver issue detected, PF reset issued > >> >> Sep 25 12:38:55 somehost kernel: [77572.245943] bond0: link status > up > >> >> again after 0 ms
Re: [E1000-devel] X710 / i40e interface resets
And there we go: [77571.409182] i40e :02:00.1: TX driver issue detected, PF reset issued [77572.245943] bond0: link status up again after 0 ms for interface eth1 [94412.738896] i40e :02:00.1: TX driver issue detected, PF reset issued [94413.569379] bond0: link status up again after 0 ms for interface eth1 [94516.443592] i40e :02:00.1: TX driver issue detected, PF reset issued [94516.718341] bond0: link status up again after 0 ms for interface eth1 [96850.580882] i40e :02:00.0: TX driver issue detected, PF reset issued [96851.036998] bond0: link status up again after 0 ms for interface eth0 [96939.474122] i40e :02:00.1: TX driver issue detected, PF reset issued [96940.217799] bond0: link status up again after 0 ms for interface eth1 [96945.007365] i40e :02:00.1: TX driver issue detected, PF reset issued [96945.225029] bond0: link status up again after 0 ms for interface eth1 [96965.362669] i40e :02:00.1: TX driver issue detected, PF reset issued [96966.255350] bond0: link status up again after 0 ms for interface eth1 [99844.991331] i40e :02:00.0: TX driver issue detected, PF reset issued [99845.360288] bond0: link status up again after 0 ms for interface eth0 [159908.054220] i40e :02:00.1: TX driver issue detected, PF reset issued [159909.165679] bond0: link status up again after 0 ms for interface eth1 [329531.138706] i40e :02:00.1: TX driver issue detected, PF reset issued [329532.167421] bond0: link status up again after 0 ms for interface eth1 On 2015-09-25 16:19, Christian Ruppert wrote: > Hi, > > the card came back and I had to flash it again but it worked perfectly > fine this time :) > So I setup a new Kernel (3.18.20) and the most recent i40e driver > (1.3.39.1) and removed the previous workaround to disable ntuples on > both interfaces. So basically a vanilla setup. > That host is up for several hours no and there was no spam so far and > only one reset yet: > Sep 25 12:38:54 somehost kernel: [77571.409182] i40e :02:00.1: TX > driver issue detected, PF reset issued > Sep 25 12:38:55 somehost kernel: [77572.245943] bond0: link status up > again after 0 ms for interface eth1 > > and here's the requested dmesg again: > [0.00] Initializing cgroup subsys cpuset > [0.00] Initializing cgroup subsys cpu > [0.00] Initializing cgroup subsys cpuacct > [0.00] Linux version 3.18.20 (fud@somehost) (gcc version 4.7.2 > (Debian 4.7.2-5) ) #1 SMP Wed Aug 26 14:25:15 CEST 2015 > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.18.20 > root=UUID=ea7a13a2-a96b-4165-801a-119b0f0d9b8f ro ipv6.disable=1 > intel_pstate=disable earlyprintk=ttyS0,115200,keep intel_iommu=off > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x00099bff] > usable > [0.00] BIOS-e820: [mem 0x00099c00-0x0009] > reserved > [0.00] BIOS-e820: [mem 0x000e-0x000f] > reserved > [0.00] BIOS-e820: [mem 0x0010-0xbecc8fff] > usable > [0.00] BIOS-e820: [mem 0xbecc9000-0xbed0bfff] > ACPI NVS > [0.00] BIOS-e820: [mem 0xbed0c000-0xce491fff] > usable > [0.00] BIOS-e820: [mem 0xce492000-0xce534fff] > reserved > [0.00] BIOS-e820: [mem 0xce535000-0xce5c6fff] > usable > [0.00] BIOS-e820: [mem 0xce5c7000-0xce68bfff] > ACPI NVS > [0.00] BIOS-e820: [mem 0xce68c000-0xcf7fefff] > reserved > [0.00] BIOS-e820: [mem 0xcf7ff000-0xcf7f] > usable > [0.00] BIOS-e820: [mem 0xe000-0xefff] > reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] > reserved > [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] > reserved > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] > reserved > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] > reserved > [0.00] BIOS-e820: [mem 0xff00-0x] > reserved > [0.00] BIOS-e820: [mem 0x0001-0x00082fff] > usable > [0.00] console [earlyser0] enabled > [0.00] NX (Execute Disable) protection: active > [0.00] SMBIOS 2.7 present. > [0.00] DMI: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.2 > 02/20/2015 > [0.00] e820: update [mem 0x-0x0fff] usable ==> > reserved > [0.00] e820: remove [mem 0x000a-0x000f] usable > [0.00] AGP: No AGP bridge found > [0.00] e820: last_pfn = 0x83 max_arch_pfn = 0x4 > [0.00] MTRR default type: uncachable > [0.00] MTRR fixed ranges enabled: > [0.00] 0-9 write-back > [0.00] A-B uncachable > [0.00] C-CBFFF write-protect > [0.00] CC000-E7FFF uncachable
Re: [E1000-devel] X710 / i40e interface resets
Hi, the card came back and I had to flash it again but it worked perfectly fine this time :) So I setup a new Kernel (3.18.20) and the most recent i40e driver (1.3.39.1) and removed the previous workaround to disable ntuples on both interfaces. So basically a vanilla setup. That host is up for several hours no and there was no spam so far and only one reset yet: Sep 25 12:38:54 somehost kernel: [77571.409182] i40e :02:00.1: TX driver issue detected, PF reset issued Sep 25 12:38:55 somehost kernel: [77572.245943] bond0: link status up again after 0 ms for interface eth1 and here's the requested dmesg again: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.18.20 (fud@somehost) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Wed Aug 26 14:25:15 CEST 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.18.20 root=UUID=ea7a13a2-a96b-4165-801a-119b0f0d9b8f ro ipv6.disable=1 intel_pstate=disable earlyprintk=ttyS0,115200,keep intel_iommu=off [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00099bff] usable [0.00] BIOS-e820: [mem 0x00099c00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbecc8fff] usable [0.00] BIOS-e820: [mem 0xbecc9000-0xbed0bfff] ACPI NVS [0.00] BIOS-e820: [mem 0xbed0c000-0xce491fff] usable [0.00] BIOS-e820: [mem 0xce492000-0xce534fff] reserved [0.00] BIOS-e820: [mem 0xce535000-0xce5c6fff] usable [0.00] BIOS-e820: [mem 0xce5c7000-0xce68bfff] ACPI NVS [0.00] BIOS-e820: [mem 0xce68c000-0xcf7fefff] reserved [0.00] BIOS-e820: [mem 0xcf7ff000-0xcf7f] usable [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00082fff] usable [0.00] console [earlyser0] enabled [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: Supermicro X9SCL/X9SCM/X9SCL/X9SCM, BIOS 2.2 02/20/2015 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x83 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-CBFFF write-protect [0.00] CC000-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask 8 write-back [0.00] 1 base 8 mask FE000 write-back [0.00] 2 base 82000 mask FF000 write-back [0.00] 3 base 0E000 mask FE000 uncachable [0.00] 4 base 0D000 mask FF000 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] e820: update [mem 0xd000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xcf800 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fd7b0-0x000fd7bf] mapped at [880fd7b0] [0.00] Base memory trampoline at [88093000] 93000 size 24576 [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x01b02000, 0x01b02fff] PGTABLE [0.00] BRK [0x01b03000, 0x01b03fff] PGTABLE [0.00] BRK [0x01b04000, 0x01b04fff] PGTABLE [0.00] init_memory_mapping: [mem 0x82fe0-0x82fff] [0.00] [mem 0x82fe0-0x82fff] page 2M [0.00] BRK [0x01b05000, 0x01b05fff] PGTABLE [0.00] init_memory_mapping: [mem 0x82c00-0x82fdf] [0.00] [mem 0x82c00-0x82fdf] page 2M [0.00] init_memory_mapping: [mem 0x8-0x82bff] [0.00] [mem 0x8-0x82bff] page 2M [0.00] init_memory_mapping: [mem 0x0010-0xbecc8fff] [0.00] [mem
Re: [E1000-devel] X710 / i40e interface resets
-Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Thursday, August 27, 2015 4:54 AM To: Fujinaka, Todd Cc: Rose, Gregory V; e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets Well, that's it for now anyway... ... Power cycle is required to complete the update process. Tool execution completed with the following status: All operations completed successfully The card doesn't even appear in lspci anymore... :/ I used a Win7 to flash it since a co-worker already broke one when flashing via Linux. No idea how to unbrick it. Christian, I'm very sorry to hear that. It is pretty rare for this sort of thing to happen but not unheard of. Please contact supp...@intel.com to get help replacing the part. - Greg On 2015-08-27 01:25, Fujinaka, Todd wrote: Attachments don't work on this mailing list (though they may have gotten to Greg). Please file a bug on e1000.sourceforge.net and attach the files there. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Wednesday, August 26, 2015 10:24 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: Re: [E1000-devel] X710 / i40e interface resets On 2015-08-26 01:19, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Friday, August 21, 2015 7:06 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets On 2015-07-28 18:51, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Tuesday, July 28, 2015 5:43 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets [snip] I've been told that the Tx driver issue detected message is due to a MDD (Malicious Driver Detection) event. We need to find out what is causing that so if you could please send me your system log and the output of ethtool intf and ethtool -i intf perhaps I can see what might be occurring. If not then we'll have to debug further. See the initial Mail for ethtool -k and so on. Also: # ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Advertised link modes: 1000baseT/Full 1baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Speed: 1Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x000f (15) drv probe link timer Link detected: yes # ethtool -i eth0 driver: i40e version: 1.2.48 firmware-version: f4.33.31377 a1.2 n4.42 e191b bus-info: :02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes I also need the output of 'dmesg' - and I need to figure out how to determine what specific MDD event is occurring. I'll get back to you with instructions on how to do that when I get the system log from you. See the attached file. It's a dmesg from boot + some minutes. I'll upgrade the card's firmware tomorrow I guess and try out the new drivers btw. Thanks, - Greg -- Regards, Christian Ruppert -- Regards, Christian Ruppert -- ___ E1000-devel mailing list E1000-devel@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: [E1000-devel] X710 / i40e interface resets
Well, that's it for now anyway... ... Power cycle is required to complete the update process. Tool execution completed with the following status: All operations completed successfully The card doesn't even appear in lspci anymore... :/ I used a Win7 to flash it since a co-worker already broke one when flashing via Linux. No idea how to unbrick it. On 2015-08-27 01:25, Fujinaka, Todd wrote: Attachments don't work on this mailing list (though they may have gotten to Greg). Please file a bug on e1000.sourceforge.net and attach the files there. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Wednesday, August 26, 2015 10:24 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: Re: [E1000-devel] X710 / i40e interface resets On 2015-08-26 01:19, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Friday, August 21, 2015 7:06 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets On 2015-07-28 18:51, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Tuesday, July 28, 2015 5:43 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets [snip] I've been told that the Tx driver issue detected message is due to a MDD (Malicious Driver Detection) event. We need to find out what is causing that so if you could please send me your system log and the output of ethtool intf and ethtool -i intf perhaps I can see what might be occurring. If not then we'll have to debug further. See the initial Mail for ethtool -k and so on. Also: # ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Advertised link modes: 1000baseT/Full 1baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Speed: 1Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x000f (15) drv probe link timer Link detected: yes # ethtool -i eth0 driver: i40e version: 1.2.48 firmware-version: f4.33.31377 a1.2 n4.42 e191b bus-info: :02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes I also need the output of 'dmesg' - and I need to figure out how to determine what specific MDD event is occurring. I'll get back to you with instructions on how to do that when I get the system log from you. See the attached file. It's a dmesg from boot + some minutes. I'll upgrade the card's firmware tomorrow I guess and try out the new drivers btw. Thanks, - Greg -- Regards, Christian Ruppert -- Regards, Christian Ruppert -- ___ E1000-devel mailing list E1000-devel@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: [E1000-devel] X710 / i40e interface resets
On 2015-08-26 01:19, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Friday, August 21, 2015 7:06 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets On 2015-07-28 18:51, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Tuesday, July 28, 2015 5:43 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets [snip] I've been told that the Tx driver issue detected message is due to a MDD (Malicious Driver Detection) event. We need to find out what is causing that so if you could please send me your system log and the output of ethtool intf and ethtool -i intf perhaps I can see what might be occurring. If not then we'll have to debug further. See the initial Mail for ethtool -k and so on. Also: # ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Advertised link modes: 1000baseT/Full 1baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Speed: 1Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x000f (15) drv probe link timer Link detected: yes # ethtool -i eth0 driver: i40e version: 1.2.48 firmware-version: f4.33.31377 a1.2 n4.42 e191b bus-info: :02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes I also need the output of 'dmesg' - and I need to figure out how to determine what specific MDD event is occurring. I'll get back to you with instructions on how to do that when I get the system log from you. See the attached file. It's a dmesg from boot + some minutes. I'll upgrade the card's firmware tomorrow I guess and try out the new drivers btw. Thanks, - Greg -- Regards, Christian Ruppert-- ___ E1000-devel mailing list E1000-devel@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: [E1000-devel] X710 / i40e interface resets
Attachments don't work on this mailing list (though they may have gotten to Greg). Please file a bug on e1000.sourceforge.net and attach the files there. Todd Fujinaka Software Application Engineer Networking Division (ND) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Wednesday, August 26, 2015 10:24 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: Re: [E1000-devel] X710 / i40e interface resets On 2015-08-26 01:19, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Friday, August 21, 2015 7:06 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets On 2015-07-28 18:51, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Tuesday, July 28, 2015 5:43 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets [snip] I've been told that the Tx driver issue detected message is due to a MDD (Malicious Driver Detection) event. We need to find out what is causing that so if you could please send me your system log and the output of ethtool intf and ethtool -i intf perhaps I can see what might be occurring. If not then we'll have to debug further. See the initial Mail for ethtool -k and so on. Also: # ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Advertised link modes: 1000baseT/Full 1baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Speed: 1Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x000f (15) drv probe link timer Link detected: yes # ethtool -i eth0 driver: i40e version: 1.2.48 firmware-version: f4.33.31377 a1.2 n4.42 e191b bus-info: :02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes I also need the output of 'dmesg' - and I need to figure out how to determine what specific MDD event is occurring. I'll get back to you with instructions on how to do that when I get the system log from you. See the attached file. It's a dmesg from boot + some minutes. I'll upgrade the card's firmware tomorrow I guess and try out the new drivers btw. Thanks, - Greg -- Regards, Christian Ruppert -- ___ E1000-devel mailing list E1000-devel@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: [E1000-devel] X710 / i40e interface resets
-Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Friday, August 21, 2015 7:06 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets On 2015-07-28 18:51, Rose, Gregory V wrote: -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Tuesday, July 28, 2015 5:43 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets [snip] I've been told that the Tx driver issue detected message is due to a MDD (Malicious Driver Detection) event. We need to find out what is causing that so if you could please send me your system log and the output of ethtool intf and ethtool -i intf perhaps I can see what might be occurring. If not then we'll have to debug further. See the initial Mail for ethtool -k and so on. Also: # ethtool eth0 Settings for eth0: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Advertised link modes: 1000baseT/Full 1baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Speed: 1Mb/s Duplex: Full Port: FIBRE PHYAD: 0 Transceiver: external Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x000f (15) drv probe link timer Link detected: yes # ethtool -i eth0 driver: i40e version: 1.2.48 firmware-version: f4.33.31377 a1.2 n4.42 e191b bus-info: :02:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes I also need the output of 'dmesg' - and I need to figure out how to determine what specific MDD event is occurring. I'll get back to you with instructions on how to do that when I get the system log from you. Thanks, - Greg -- ___ E1000-devel mailing list E1000-devel@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: [E1000-devel] X710 / i40e interface resets
-Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Tuesday, July 28, 2015 5:43 AM To: Rose, Gregory V Cc: e1000-de...@lists.sf.net Subject: RE: [E1000-devel] X710 / i40e interface resets Greg, On 2015-07-27 18:20, Christian Ruppert wrote: On 2015-07-27 18:02, Rose, Gregory V wrote: So to make sure I've got your report right... Since updating the FW the link flap issue occurs much less frequently and VRRP is not causing a switch to a different host but your log is getting spammed with ATR messages. Is that correct? Exactly! Have you tried turning off ntuple-filters? I'll try that. No more: [341397.489477] i40e :02:00.0: FD filter space full, new ntuple rules will not be added [341398.041918] i40e :02:00.0: FD Filter table flushed and FD-SB replayed. [341398.049403] i40e :02:00.0: FD Sideband/ntuple is being enabled since we have space in the table now [341398.059858] i40e :02:00.0: ATR is being enabled since we have space in the table now [341850.732707] i40e :02:00.0: ATR re-enabled. since I disabled ntuple. So that is gone (not fixed though) for now. OK - I think the messages you're seeing are part of normal operation but they are quite noisy. I know the i40e dev team is trying to reduce the amount of message spam to the system log so I'll point this out to them and perhaps something can be done to reduce the message volume. The flaps are still persistent: [354195.790717] i40e :02:00.0: TX driver issue detected, PF reset issued [354196.551366] i40e :02:00.0: FCoE capability is disabled [354196.593458] i40e :02:00.0: PHC enabled [354196.653574] i40e :02:00.0: enabling bridge mode: VEPA [354196.672095] i40e :02:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None I've been told that the Tx driver issue detected message is due to a MDD (Malicious Driver Detection) event. We need to find out what is causing that so if you could please send me your system log and the output of ethtool intf and ethtool -i intf perhaps I can see what might be occurring. If not then we'll have to debug further. I'll be out the next few days but returning Monday so I'll be able to follow up on this issue then. Thanks, - Greg -- ___ E1000-devel mailing list E1000-devel@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
[E1000-devel] X710 / i40e interface resets
Hi List, after having some serious issues with the X520 ones I wanted to give the X710 a try. At first I had some trouble again. Started to flap sometimes and later flapping until VRRP switched to a different host. The Kernel log was spammed with: Jul 24 12:02:10 somehost kernel: [ 1446.325468] i40e :02:00.0: TX driver issue detected, PF reset issued Jul 24 12:02:11 somehost kernel: [ 1447.154720] i40e :02:00.0: FCoE capability is disabled Jul 24 12:02:11 somehost kernel: [ 1447.196823] i40e :02:00.0: PHC enabled Jul 24 12:02:11 somehost kernel: [ 1447.255115] i40e :02:00.0: enabling bridge mode: VEPA Jul 24 12:02:11 somehost kernel: [ 1447.267922] i40e :02:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None and: Jul 24 12:16:08 somehost kernel: [ 2285.524925] i40e :02:00.0: FD filter space full, new ntuple rules will not be added Jul 24 12:16:09 somehost kernel: [ 2286.348784] i40e :02:00.0: FD Filter table flushed and FD-SB replayed. Jul 24 12:16:09 somehost kernel: [ 2286.356063] i40e :02:00.0: FD Sideband/ntuple is being enabled since we have space in the table now Jul 24 12:16:09 somehost kernel: [ 2286.365777] i40e :02:00.0: ATR is being enabled since we have space in the table now Then I read something about updating the NVM/preboot (here on the ML) which I did then. After having some issues with flashing (the update utility doesn't like CONFIG_STRICT_DEVMEM=y, there's also no warning about it. disabling it did help but not entirely) I decided to flash from a Windows host (I had to setup one...) as it seemed somewhat easier and safer, for now. The preboot util still complained about having an older NVM than expected but somehow it worked and it's a more recent version now than it was before. So here is the initialization of the 20.2 version/revision and also using the most recent 1.2.48 driver on a 3.18.17 Kernel: Jul 24 11:38:13 somehost kernel: [2.251951] i40e: Intel(R) Ethernet Connection XL710 Network Driver - version 1.2.48 Jul 24 11:38:13 somehost kernel: [2.259620] i40e: Copyright (c) 2013 - 2015 Intel Corporation. Jul 24 11:38:13 somehost kernel: [2.283072] i40e :02:00.0: f4.33.31377 a1.2 n4.42 e191b Jul 24 11:38:13 somehost kernel: [2.528098] i40e :02:00.0: FCoE capability is disabled Jul 24 11:38:13 somehost kernel: [2.541226] i40e :02:00.0: MAC address: 68:05:ca:33:17:50 Jul 24 11:38:13 somehost kernel: [2.545296] i40e :02:00.0: SAN MAC: 68:05:ca:33:17:52 Jul 24 11:38:13 somehost kernel: [2.559708] i40e :02:00.0: fcoe queues = 0 Jul 24 11:38:13 somehost kernel: [2.588853] i40e :02:00.0: enabling bridge mode: VEPA Jul 24 11:38:13 somehost kernel: [2.623476] i40e :02:00.0: PHC enabled Jul 24 11:38:13 somehost kernel: [2.639801] i40e :02:00.0: PCI-Express: Speed 8.0GT/s Width x8 Jul 24 11:38:13 somehost kernel: [2.653156] i40e :02:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 8 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB PTP Jul 24 11:38:13 somehost kernel: [2.672182] i40e :02:00.1: f4.33.31377 a1.2 n4.42 e191b Jul 24 11:38:13 somehost kernel: [2.921075] i40e :02:00.1: FCoE capability is disabled Jul 24 11:38:13 somehost kernel: [2.935064] i40e :02:00.1: MAC address: 68:05:ca:33:17:51 Jul 24 11:38:13 somehost kernel: [2.944833] i40e :02:00.1: SAN MAC: 68:05:ca:33:17:53 Jul 24 11:38:13 somehost kernel: [2.971041] i40e :02:00.1: fcoe queues = 0 Jul 24 11:38:13 somehost kernel: [3.004728] i40e :02:00.1: enabling bridge mode: VEPA Jul 24 11:38:13 somehost kernel: [3.290178] i40e :02:00.1: PHC enabled Jul 24 11:38:13 somehost kernel: [3.310646] i40e :02:00.1: PCI-Express: Speed 8.0GT/s Width x8 Jul 24 11:38:13 somehost kernel: [3.331079] i40e :02:00.1: Features: PF-id[1] VFs: 64 VSIs: 66 QP: 8 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB PTP Jul 24 11:38:13 somehost kernel: [4.279754] i40e :02:00.1 rename5: renamed from eth3 Jul 24 11:38:13 somehost kernel: [4.315533] i40e :02:00.0 eth0: renamed from eth1 Jul 24 11:38:13 somehost kernel: [4.387610] i40e :02:00.1 eth1: renamed from rename5 Jul 24 11:38:13 somehost kernel: [6.276102] i40e :02:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Jul 24 11:38:14 somehost kernel: [8.396154] i40e :02:00.1 eth1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None The above mentioned issues are still persistent even though less frequent and it's running about 3 days now without flapping that much that the VRRP switches to a different host. I'm not happy yet as it's still flapping and complaining about ntuple/ATR and such. Can I somehow help (by providing the necessary details) to get those issues fixed? # ethtool -i eth0 driver: i40e version: 1.2.48 firmware-version: f4.33.31377 a1.2 n4.42 e191b bus-info: :02:00.0 supports-statistics: yes
Re: [E1000-devel] X710 / i40e interface resets
So to make sure I've got your report right... Since updating the FW the link flap issue occurs much less frequently and VRRP is not causing a switch to a different host but your log is getting spammed with ATR messages. Is that correct? Have you tried turning off ntuple-filters? As for the link flap I don't think we've seen a lot of customers running the XL710 at 1Gbps speeds, most are using the 10Gbps or 40Gbps speeds. I'll do some research and see if there are any other reports of issues with the XL710 running at 1Gbps speed and get back to you. - Greg -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Monday, July 27, 2015 8:47 AM To: e1000-de...@lists.sf.net Subject: [E1000-devel] X710 / i40e interface resets Hi List, after having some serious issues with the X520 ones I wanted to give the X710 a try. At first I had some trouble again. Started to flap sometimes and later flapping until VRRP switched to a different host. The Kernel log was spammed with: Jul 24 12:02:10 somehost kernel: [ 1446.325468] i40e :02:00.0: TX driver issue detected, PF reset issued Jul 24 12:02:11 somehost kernel: [ 1447.154720] i40e :02:00.0: FCoE capability is disabled Jul 24 12:02:11 somehost kernel: [ 1447.196823] i40e :02:00.0: PHC enabled Jul 24 12:02:11 somehost kernel: [ 1447.255115] i40e :02:00.0: enabling bridge mode: VEPA Jul 24 12:02:11 somehost kernel: [ 1447.267922] i40e :02:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None and: Jul 24 12:16:08 somehost kernel: [ 2285.524925] i40e :02:00.0: FD filter space full, new ntuple rules will not be added Jul 24 12:16:09 somehost kernel: [ 2286.348784] i40e :02:00.0: FD Filter table flushed and FD-SB replayed. Jul 24 12:16:09 somehost kernel: [ 2286.356063] i40e :02:00.0: FD Sideband/ntuple is being enabled since we have space in the table now Jul 24 12:16:09 somehost kernel: [ 2286.365777] i40e :02:00.0: ATR is being enabled since we have space in the table now Then I read something about updating the NVM/preboot (here on the ML) which I did then. After having some issues with flashing (the update utility doesn't like CONFIG_STRICT_DEVMEM=y, there's also no warning about it. disabling it did help but not entirely) I decided to flash from a Windows host (I had to setup one...) as it seemed somewhat easier and safer, for now. The preboot util still complained about having an older NVM than expected but somehow it worked and it's a more recent version now than it was before. So here is the initialization of the 20.2 version/revision and also using the most recent 1.2.48 driver on a 3.18.17 Kernel: Jul 24 11:38:13 somehost kernel: [2.251951] i40e: Intel(R) Ethernet Connection XL710 Network Driver - version 1.2.48 Jul 24 11:38:13 somehost kernel: [2.259620] i40e: Copyright (c) 2013 - 2015 Intel Corporation. Jul 24 11:38:13 somehost kernel: [2.283072] i40e :02:00.0: f4.33.31377 a1.2 n4.42 e191b Jul 24 11:38:13 somehost kernel: [2.528098] i40e :02:00.0: FCoE capability is disabled Jul 24 11:38:13 somehost kernel: [2.541226] i40e :02:00.0: MAC address: 68:05:ca:33:17:50 Jul 24 11:38:13 somehost kernel: [2.545296] i40e :02:00.0: SAN MAC: 68:05:ca:33:17:52 Jul 24 11:38:13 somehost kernel: [2.559708] i40e :02:00.0: fcoe queues = 0 Jul 24 11:38:13 somehost kernel: [2.588853] i40e :02:00.0: enabling bridge mode: VEPA Jul 24 11:38:13 somehost kernel: [2.623476] i40e :02:00.0: PHC enabled Jul 24 11:38:13 somehost kernel: [2.639801] i40e :02:00.0: PCI-Express: Speed 8.0GT/s Width x8 Jul 24 11:38:13 somehost kernel: [2.653156] i40e :02:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 8 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB PTP Jul 24 11:38:13 somehost kernel: [2.672182] i40e :02:00.1: f4.33.31377 a1.2 n4.42 e191b Jul 24 11:38:13 somehost kernel: [2.921075] i40e :02:00.1: FCoE capability is disabled Jul 24 11:38:13 somehost kernel: [2.935064] i40e :02:00.1: MAC address: 68:05:ca:33:17:51 Jul 24 11:38:13 somehost kernel: [2.944833] i40e :02:00.1: SAN MAC: 68:05:ca:33:17:53 Jul 24 11:38:13 somehost kernel: [2.971041] i40e :02:00.1: fcoe queues = 0 Jul 24 11:38:13 somehost kernel: [3.004728] i40e :02:00.1: enabling bridge mode: VEPA Jul 24 11:38:13 somehost kernel: [3.290178] i40e :02:00.1: PHC enabled Jul 24 11:38:13 somehost kernel: [3.310646] i40e :02:00.1: PCI-Express: Speed 8.0GT/s Width x8 Jul 24 11:38:13 somehost kernel: [3.331079] i40e :02:00.1: Features: PF-id[1] VFs: 64 VSIs: 66 QP: 8 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB PTP Jul 24 11:38:13 somehost kernel: [4.279754] i40e :02:00.1 rename5: renamed from eth3 Jul 24 11:38:13 somehost kernel: [4.315533] i40e :02:00.0 eth0: renamed from eth1 Jul 24 11:38:13 somehost kernel: [4.387610
Re: [E1000-devel] X710 / i40e interface resets
On 2015-07-27 18:02, Rose, Gregory V wrote: So to make sure I've got your report right... Since updating the FW the link flap issue occurs much less frequently and VRRP is not causing a switch to a different host but your log is getting spammed with ATR messages. Is that correct? Exactly! Have you tried turning off ntuple-filters? I'll try that. As for the link flap I don't think we've seen a lot of customers running the XL710 at 1Gbps speeds, most are using the 10Gbps or 40Gbps speeds. I'll do some research and see if there are any other reports of issues with the XL710 running at 1Gbps speed and get back to you. Thanks! - Greg -Original Message- From: Christian Ruppert [mailto:id...@qasl.de] Sent: Monday, July 27, 2015 8:47 AM To: e1000-de...@lists.sf.net Subject: [E1000-devel] X710 / i40e interface resets Hi List, after having some serious issues with the X520 ones I wanted to give the X710 a try. At first I had some trouble again. Started to flap sometimes and later flapping until VRRP switched to a different host. The Kernel log was spammed with: Jul 24 12:02:10 somehost kernel: [ 1446.325468] i40e :02:00.0: TX driver issue detected, PF reset issued Jul 24 12:02:11 somehost kernel: [ 1447.154720] i40e :02:00.0: FCoE capability is disabled Jul 24 12:02:11 somehost kernel: [ 1447.196823] i40e :02:00.0: PHC enabled Jul 24 12:02:11 somehost kernel: [ 1447.255115] i40e :02:00.0: enabling bridge mode: VEPA Jul 24 12:02:11 somehost kernel: [ 1447.267922] i40e :02:00.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None and: Jul 24 12:16:08 somehost kernel: [ 2285.524925] i40e :02:00.0: FD filter space full, new ntuple rules will not be added Jul 24 12:16:09 somehost kernel: [ 2286.348784] i40e :02:00.0: FD Filter table flushed and FD-SB replayed. Jul 24 12:16:09 somehost kernel: [ 2286.356063] i40e :02:00.0: FD Sideband/ntuple is being enabled since we have space in the table now Jul 24 12:16:09 somehost kernel: [ 2286.365777] i40e :02:00.0: ATR is being enabled since we have space in the table now Then I read something about updating the NVM/preboot (here on the ML) which I did then. After having some issues with flashing (the update utility doesn't like CONFIG_STRICT_DEVMEM=y, there's also no warning about it. disabling it did help but not entirely) I decided to flash from a Windows host (I had to setup one...) as it seemed somewhat easier and safer, for now. The preboot util still complained about having an older NVM than expected but somehow it worked and it's a more recent version now than it was before. So here is the initialization of the 20.2 version/revision and also using the most recent 1.2.48 driver on a 3.18.17 Kernel: Jul 24 11:38:13 somehost kernel: [2.251951] i40e: Intel(R) Ethernet Connection XL710 Network Driver - version 1.2.48 Jul 24 11:38:13 somehost kernel: [2.259620] i40e: Copyright (c) 2013 - 2015 Intel Corporation. Jul 24 11:38:13 somehost kernel: [2.283072] i40e :02:00.0: f4.33.31377 a1.2 n4.42 e191b Jul 24 11:38:13 somehost kernel: [2.528098] i40e :02:00.0: FCoE capability is disabled Jul 24 11:38:13 somehost kernel: [2.541226] i40e :02:00.0: MAC address: 68:05:ca:33:17:50 Jul 24 11:38:13 somehost kernel: [2.545296] i40e :02:00.0: SAN MAC: 68:05:ca:33:17:52 Jul 24 11:38:13 somehost kernel: [2.559708] i40e :02:00.0: fcoe queues = 0 Jul 24 11:38:13 somehost kernel: [2.588853] i40e :02:00.0: enabling bridge mode: VEPA Jul 24 11:38:13 somehost kernel: [2.623476] i40e :02:00.0: PHC enabled Jul 24 11:38:13 somehost kernel: [2.639801] i40e :02:00.0: PCI-Express: Speed 8.0GT/s Width x8 Jul 24 11:38:13 somehost kernel: [2.653156] i40e :02:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 8 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB PTP Jul 24 11:38:13 somehost kernel: [2.672182] i40e :02:00.1: f4.33.31377 a1.2 n4.42 e191b Jul 24 11:38:13 somehost kernel: [2.921075] i40e :02:00.1: FCoE capability is disabled Jul 24 11:38:13 somehost kernel: [2.935064] i40e :02:00.1: MAC address: 68:05:ca:33:17:51 Jul 24 11:38:13 somehost kernel: [2.944833] i40e :02:00.1: SAN MAC: 68:05:ca:33:17:53 Jul 24 11:38:13 somehost kernel: [2.971041] i40e :02:00.1: fcoe queues = 0 Jul 24 11:38:13 somehost kernel: [3.004728] i40e :02:00.1: enabling bridge mode: VEPA Jul 24 11:38:13 somehost kernel: [3.290178] i40e :02:00.1: PHC enabled Jul 24 11:38:13 somehost kernel: [3.310646] i40e :02:00.1: PCI-Express: Speed 8.0GT/s Width x8 Jul 24 11:38:13 somehost kernel: [3.331079] i40e :02:00.1: Features: PF-id[1] VFs: 64 VSIs: 66 QP: 8 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB PTP Jul 24 11:38:13 somehost kernel: [4.279754] i40e :02:00.1 rename5: renamed from eth3 Jul 24 11:38
