* [PATCH 3/3] USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
From: Andrew Bird @ 2012-05-20 8:28 UTC (permalink / raw)
To: bjorn; +Cc: gregkh, linux-usb, netdev, linux-kernel, Andrew Bird
In-Reply-To: <1337502518-1444-1-git-send-email-ajb@spheresystems.co.uk>
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
---
drivers/net/usb/qmi_wwan.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 0646e45..f64dac3 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -356,6 +356,15 @@ static const struct driver_info qmi_wwan_gobi = {
};
/* ZTE suck at making USB descriptors */
+static const struct driver_info qmi_wwan_force_int1 = {
+ .description = "Qualcomm WWAN/QMI device",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_shared,
+ .unbind = qmi_wwan_unbind_shared,
+ .manage_power = qmi_wwan_manage_power,
+ .data = BIT(1), /* interface whitelist bitmap */
+};
+
static const struct driver_info qmi_wwan_force_int4 = {
.description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
@@ -430,6 +439,15 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 0xff,
.driver_info = (unsigned long)&qmi_wwan_force_int4,
},
+ { /* ZTE (Vodafone) K3520-Z */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x19d2,
+ .idProduct = 0x0055,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xff,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_force_int1,
+ },
{ /* ZTE (Vodafone) K3565-Z */
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
.idVendor = 0x19d2,
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/3] USB: qmi_wwan: Make forced int 4 whitelist generic
From: Andrew Bird @ 2012-05-20 8:28 UTC (permalink / raw)
To: bjorn; +Cc: gregkh, linux-usb, netdev, linux-kernel, Andrew Bird
Change the forced interface 4 whitelist to use the generic shared
binder instead of the Gobi specific one. Certain ZTE devices
(K3520-Z & K3765-Z) don't work with the Gobi version, but function
quite happily with the generic. This has been tested with the following
devices:
K3520-Z
K3565-Z
K3765-Z
K4505-Z
It hasn't been tested with the ZTE MF820D, which is the only other
device that uses this whitelist at present. Although Bjorn doesn't
expect any problems, any testing with that device would be appreciated.
Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
---
drivers/net/usb/qmi_wwan.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index d316503b..62a1a43 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -357,9 +357,9 @@ static const struct driver_info qmi_wwan_gobi = {
/* ZTE suck at making USB descriptors */
static const struct driver_info qmi_wwan_force_int4 = {
- .description = "Qualcomm Gobi wwan/QMI device",
+ .description = "Qualcomm WWAN/QMI device",
.flags = FLAG_WWAN,
- .bind = qmi_wwan_bind_gobi,
+ .bind = qmi_wwan_bind_shared,
.unbind = qmi_wwan_unbind_shared,
.manage_power = qmi_wwan_manage_power,
.data = BIT(4), /* interface whitelist bitmap */
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/3] USB: qmi_wwan: Make forced int 4 whitelist generic
From: Bjørn Mork @ 2012-05-20 10:50 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-1-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Change the forced interface 4 whitelist to use the generic shared
> binder instead of the Gobi specific one. Certain ZTE devices
> (K3520-Z & K3765-Z) don't work with the Gobi version, but function
> quite happily with the generic. This has been tested with the following
> devices:
> K3520-Z
> K3565-Z
> K3765-Z
> K4505-Z
> It hasn't been tested with the ZTE MF820D, which is the only other
> device that uses this whitelist at present. Although Bjorn doesn't
> expect any problems, any testing with that device would be appreciated.
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
> ---
> drivers/net/usb/qmi_wwan.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index d316503b..62a1a43 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -357,9 +357,9 @@ static const struct driver_info qmi_wwan_gobi = {
>
> /* ZTE suck at making USB descriptors */
> static const struct driver_info qmi_wwan_force_int4 = {
> - .description = "Qualcomm Gobi wwan/QMI device",
> + .description = "Qualcomm WWAN/QMI device",
> .flags = FLAG_WWAN,
> - .bind = qmi_wwan_bind_gobi,
> + .bind = qmi_wwan_bind_shared,
> .unbind = qmi_wwan_unbind_shared,
> .manage_power = qmi_wwan_manage_power,
> .data = BIT(4), /* interface whitelist bitmap */
Acked-by: Bjørn Mork <bjorn@mork.no>
This fixes a logical error in the code. Minidriver constructs with an
interface whitelist should not use qmi_wwan_bind_gobi. It was made to
prevent binding to the serial interfaces on Gobi devices, and serves no
useful purpose when used with a whitelist. The change is a no-op for
the ZTE MF820D, but is important for new devices.
Thanks for fixing this.
Bjør
^ permalink raw reply
* Re: [PATCH 2/3] USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z
From: Bjørn Mork @ 2012-05-20 10:52 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-2-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Add the ZTE (Vodafone) K3765-Z to the whitelist.
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* Re: [PATCH 3/3] USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
From: Bjørn Mork @ 2012-05-20 10:53 UTC (permalink / raw)
To: Andrew Bird; +Cc: gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-3-git-send-email-ajb@spheresystems.co.uk>
Andrew Bird <ajb@spheresystems.co.uk> writes:
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Acked-by: Bjørn Mork <bjorn@mork.no>
> /* ZTE suck at making USB descriptors */
> +static const struct driver_info qmi_wwan_force_int1 = {
> + .description = "Qualcomm WWAN/QMI device",
> + .flags = FLAG_WWAN,
> + .bind = qmi_wwan_bind_shared,
> + .unbind = qmi_wwan_unbind_shared,
> + .manage_power = qmi_wwan_manage_power,
> + .data = BIT(1), /* interface whitelist bitmap */
> +};
> +
> static const struct driver_info qmi_wwan_force_int4 = {
> .description = "Qualcomm WWAN/QMI device",
> .flags = FLAG_WWAN,
> @@ -430,6 +439,15 @@ static const struct usb_device_id products[] = {
> .bInterfaceProtocol = 0xff,
> .driver_info = (unsigned long)&qmi_wwan_force_int4,
> },
> + { /* ZTE (Vodafone) K3520-Z */
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
> + .idVendor = 0x19d2,
> + .idProduct = 0x0055,
> + .bInterfaceClass = 0xff,
> + .bInterfaceSubClass = 0xff,
> + .bInterfaceProtocol = 0xff,
> + .driver_info = (unsigned long)&qmi_wwan_force_int1,
> + },
> { /* ZTE (Vodafone) K3565-Z */
> .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
> .idVendor = 0x19d2,
Looking forward to changing all this to a single line device + interface
number macro in 3.6 :-)
Bjørn
^ permalink raw reply
* [PATCH] xen: do not disable netfront in dom0
From: Marek Marczykowski @ 2012-05-20 11:45 UTC (permalink / raw)
To: xen-devel
Cc: Jeremy Fitzhardinge, Konrad Rzeszutek Wilk, netdev,
Marek Marczykowski, linux-kernel, virtualization
Netfront driver can be also useful in dom0, eg when all NICs are assigned to
some domU (aka driver domain). Then using netback in domU and netfront in dom0
is the only way to get network access in dom0.
Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
---
drivers/net/xen-netfront.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 698b905..e31ebff 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1953,9 +1953,6 @@ static int __init netif_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_initial_domain())
- return 0;
-
printk(KERN_INFO "Initialising Xen virtual ethernet driver.\n");
return xenbus_register_frontend(&netfront_driver);
@@ -1965,9 +1962,6 @@ module_init(netif_init);
static void __exit netif_exit(void)
{
- if (xen_initial_domain())
- return;
-
xenbus_unregister_driver(&netfront_driver);
}
module_exit(netif_exit);
--
1.7.4.4
^ permalink raw reply related
* [PATCH RESENT] xen: do not disable netfront in dom0
From: Marek Marczykowski @ 2012-05-20 11:45 UTC (permalink / raw)
To: David Miller
Cc: Jeremy Fitzhardinge, Ian.Campbell, Konrad Rzeszutek Wilk, netdev,
Marek Marczykowski, xen-devel, virtualization, linux-kernel
In-Reply-To: <20120522194319.GA2691@phenom.dumpdata.com>
Netfront driver can be also useful in dom0, eg when all NICs are assigned to
some domU (aka driver domain). Then using netback in domU and netfront in dom0
is the only way to get network access in dom0.
Signed-off-by: Marek Marczykowski <marmarek@invisiblethingslab.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
drivers/net/xen-netfront.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 0ebbb19..2027afe 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1962,9 +1962,6 @@ static int __init netif_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_initial_domain())
- return 0;
-
if (xen_hvm_domain() && !xen_platform_pci_unplug)
return -ENODEV;
@@ -1977,9 +1974,6 @@ module_init(netif_init);
static void __exit netif_exit(void)
{
- if (xen_initial_domain())
- return;
-
xenbus_unregister_driver(&netfront_driver);
}
module_exit(netif_exit);
--
1.7.4.4
^ permalink raw reply related
* [PATCH] ipv6/exthdrs: strict Pad1 and PadN check
From: Eldad Zack @ 2012-05-20 11:59 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, linux-kernel, Eldad Zack
The following tightens the padding check from commit
c1412fce7eccae62b4de22494f6ab3ff8a90c0c6 :
* Take into account combinations of consecutive Pad1 and PadN.
* Catch the corner case of when only padding is present in the
header, when the extention header length is 0 (i.e., 8 bytes).
In this case, the header would have exactly 6 bytes of padding:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Next Header : Hdr Ext Len=0 : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: Padding (Pad1 or PadN) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
---
net/ipv6/exthdrs.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
index 50ec95f..6447dc4 100644
--- a/net/ipv6/exthdrs.c
+++ b/net/ipv6/exthdrs.c
@@ -144,6 +144,7 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
const unsigned char *nh = skb_network_header(skb);
int off = skb_network_header_len(skb);
int len = (skb_transport_header(skb)[1] + 1) << 3;
+ int padlen = 0;
if (skb_transport_offset(skb) + len > skb_headlen(skb))
goto bad;
@@ -158,6 +159,9 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
switch (nh[off]) {
case IPV6_TLV_PAD1:
optlen = 1;
+ padlen++;
+ if (padlen > 7)
+ goto bad;
break;
case IPV6_TLV_PADN:
@@ -166,7 +170,8 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
* of 8. 7 is therefore the highest valid value.
* See also RFC 4942, Section 2.1.9.5.
*/
- if (optlen > 7)
+ padlen += optlen;
+ if (padlen > 7)
goto bad;
/* RFC 4942 recommends receiving hosts to
* actively check PadN payload to contain
@@ -195,11 +200,19 @@ static bool ip6_parse_tlv(const struct tlvtype_proc *procs, struct sk_buff *skb)
if (ip6_tlvopt_unknown(skb, off) == 0)
return false;
}
+ padlen = 0;
break;
}
off += optlen;
len -= optlen;
}
+ /* This case will not be caught by above check since its padding
+ * length is smaller than 7:
+ * 1 byte NH + 1 byte Length + 6 bytes Padding
+ */
+ if ((padlen == 6) && ((off - skb_network_header_len(skb)) == 8))
+ goto bad;
+
if (len == 0)
return true;
bad:
--
1.7.10
^ permalink raw reply related
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Emmanuel Fusté @ 2012-05-20 16:02 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker
> On 18/05/2012 (Fri 20:16) Ondrej Zary wrote:
> > On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote:
> > > It was amusing that linux was able to make use of this 1980's
> > > technology on machines long past its intended lifespan, but
> > > it probably should go now -- it is causing issues in some
> > > distros[1], and while that might be fixable, it is just not
> > > worth it.
> > >
> > > [1]
> > > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-
> > >not-detecting-934344/
> >
> > That looks like a bug elsewhere and removing this driver will not fix it.
>
> You miss the point. We've got someone with a modern i7 machine who is
> getting confused by seeing messages from some ancient 3c501 driver, but
> he doesn't have the context to know it is ancient and the message is a
> red herring. Will it fix a distro's broken init that tries to modprobe
> everything? No. Will it help by not muddying the waters with
> meaningless printk from 3c501 that confuse users? Yes.
>
> Thanks,
> Paul.
>
> >
> > --
> > Ondrej Zary
Oh sh**, even if I could understand the arguments for the MCA part I
could not
agree anymore on this.
I you go to this road, kill the m68k architecture and four or five more and
remove half or more of the drivers.
"meaningless printk" ? kill the printk, not the driver. "confuse users" ?
which users ? What you call a users in you comments are people which
only use
mouse and graphic environments and for which printk are not for ...
Your whole patchset is build around the philosophy perfectly resumed by your
words:
"xxx is being removed, since the 20year old hardware simply isn't capable of
meeting today's software demands on CPU and memory resources."
Such subjective positions are not valid technicals arguments.
Following Linux since twenty years, I could say without making a big mistake
that this is not the Linux way of doing things. Linux would never be
what it is
today in term of pure code architecture if the easy way of removing
"disturbing"
and "obsolete in today standards" hardware support code was the way of doing
things.
But perhaps my old way of viewing things is no longer compatible with
the new
generations or in what Linux is going to be...
Emmanuel.
PS: My over reaction is PARTLY caused because of special historic symbol
3c501 hardware represent. It was one of the only (if not the only one)
ethernet
card supported by the Apollo platform and DomainOS. A great and
important part
of the computer / Unix history.
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Paul Gortmaker @ 2012-05-20 16:08 UTC (permalink / raw)
To: Alan Cox; +Cc: Ondrej Zary, davem, netdev
In-Reply-To: <20120519133038.282d0a7d@bob.linux.org.uk>
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 19/05/2012 (Sat 13:30) Alan Cox wrote:
> > You miss the point. We've got someone with a modern i7 machine who is
> > getting confused by seeing messages from some ancient 3c501 driver,
> > but he doesn't have the context to know it is ancient and the message
> > is a red herring. Will it fix a distro's broken init that tries to
> > modprobe everything? No. Will it help by not muddying the waters
> > with meaningless printk from 3c501 that confuse users? Yes.
>
> That seems a totally bogus reason for removing stuff. The kernel cannot
> manage every possible distribution and user screw up. They have more
> variety so they will always win the battle.
Unfortunate that Ondrej's comment led folks to focus on the above as if
it was the primary reason. It was not. The sheer unusability of it as
a real networking interface in today's world (that I listed) was the
prime motivation for removal. It was barely useable in the 1995 world,
and I can't imagine it has got better with age.
Getting rid of possibly misleading messages like the printk in the i7
user's messages is just a fringe benefit. I can remove the text:
"-- it is causing issues in some distros, and while
that might be fixable, it is just not worth it."
from the commit log[1] and I think the remaining description still stands
on its own as being justified.
>
> Removing it because nobody is running one even in a museum might be a
> good reason, but then the driver still works fine.
I would suspect that is the case here though. Based on its limitations
(one operation at a time please) - I can't imagine that anyone anywhere
is running one (with the possible exception of one or maybe two informal
museusms?).
>
> Also btw: the 3c501 isn't all TTL it's integrated. The 3c500 is all
> TTL and an amazing beast, its so big it won't fit a 16bit slot as it
> has to drop down after the connector to get all the chips on.
It has been at least 15 years since I've seen one, and google couldn't
find me a picture, so I was going on memory. 3c501 definitely still had a
lot of discrete TTL chips for bus glue logic then, since I'm sure it was
a busy looking board.
>
> (and yes I have a 3c500)
I've never seen one of those, and I count myself lucky. :)
>
> However I don't think this is the right way to tackle the ethernet
> history situation. As with MCA we should pull *all* the real
> historical interest only bits in one go so it's immediately obvious
> where the break point is for all devices.
MCA was fortunately reasonably bounded in time -- i.e. it was confined
largely to things unfit for any use today. EISA is somewhat the same.
>
> That or we'll replace confused distros and uses with confused ancient
> machine owners, and the latter can be far more persistent and
> irritating ;)
>
> So should we dump ISA ?
Per Dave's comments, we'd have to restrict ISA in this context to mean
ISA _drivers_ that support _only_ physical pluggable 8/16bit ISA bus
cards. With possible inclusion of onboard chips that were only deployed
on ancient motherboards well over 10 years ago -- e.g. onboard aha154x.c
and etherexpress on lp486e board type stuff. Maybe that is what you
implicitly meant anyways?
But since ISA isn't as nicely bounded in time, I could easily envision
someone with a 1GHz socket370 P3 and an ISA SMC-Ultra PnP connected to a
cable modem in a closet somewhere. Sure, it is old, but it could be
still doing the job of a _reliable_ workhorse.
Replace SMC-ultra with 3c501 in the above, and the story falls apart and
becomes laughable. This is with no disrespect for the 3c501 driver. It
is purely from the hardware being of a different era. Both ISA, but one
is 10-15 years newer than the other.
If we throw away the ISA card drivers all at once, we'll end up keeping
some things well past their best before date, and throwing out some
stuff that might actually still be used by real people. This isn't at
all fatal in itself, but something to consider when weighing against the
value of a consistent "all this stuff goes away on day X" message.
That, and the inevitable inability to get a consensus "yes" for a large
removal of ISA _card_ drivers from a decision committee, made me think
that piecemeal was better than no action. If folks think I'm wrong on
the consensus part, I will gladly start forming an ISA _card_ driver
list of candidates for some yet to be determined scheduled removal...
Paul.
[1] http://patchwork.ozlabs.org/patch/160144/
--
> Alan
^ permalink raw reply
* Re: [PATCH v5] tilegx network driver: initial support
From: Chris Metcalf @ 2012-05-20 16:35 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, arnd, linux-kernel, netdev
In-Reply-To: <1336744445.2874.57.camel@bwh-desktop.uk.solarflarecom.com>
On 5/11/2012 9:54 AM, Ben Hutchings wrote:
> Here's another very incomplete review for you.
Thanks, I (we) appreciate it!
>> +/* Define to support GSO. */
>> +#undef TILE_NET_GSO
> GSO is always enabled by the networking core.
>
>> +/* Define to support TSO. */
>> +#define TILE_NET_TSO
> No, put NETIF_F_TSO in hw_features so it can be switched at run-time.
We already had that; the TSO define was just to decide whether the driver
would even offer TSO support at all. But on reflection it seems pointless
not to offer TSO, so I've made it true unconditionally and deleted the
define. Similarly I got rid of the (totally pointless) GSO define and let
the core control whether it switches GSO on or not.
We are looking at GRO support for a following change, but obviously we need
to set up ethtool_ops for that first, so we'll be doing that as well.
>> +/* Use 3000 to enable the Linux Traffic Control (QoS) layer, else 0. */
>> +#define TILE_NET_TX_QUEUE_LEN 0
> This can be changed through sysfs, so there is no need for a compile-
> time option.
Fair enough, and in practice we don't change this default anyway, so I
eliminated it.
>> +/* Define to dump packets (prints out the whole packet on tx and rx). */
>> +#undef TILE_NET_DUMP_PACKETS
> Should really be controlled through a 'debug' module parameter (see
> netif_msg_init(), netif_msg_pktdata(), etc.)
We almost never use this functionality anyway, so for now, I've just
removed it. If we want to reintroduce something like it, we'll use the
netif_msg stuff.
>> + /* Reserve slots, or return NETDEV_TX_BUSY if "full". */
>> + slot = gxio_mpipe_equeue_try_reserve(equeue, num_frags);
>> + if (slot < 0) {
>> + local_irq_restore(irqflags);
>> + /* ISSUE: "Virtual device xxx asks to queue packet". */
>> + return NETDEV_TX_BUSY;
>> + }
> You're supposed to stop queues when they're full. And since that state
> appears to be per-CPU, I think this device needs to be multiqueue with
> one TX queue per CPU and ndo_select_queue defined accordingly.
>
> [...]
>
> I'm not convinced you should be processing completions here at all. But
> certainly you should have stopped the queue earlier rather than having
> to wait here.
This is a larger issue. We are working on improving performance in the
driver overall, and how we handle per-cpu or global queueing, how we stop
and restart the driver, etc., will be part of it. (The underlying mpipe
resources are not per-cpu, so it may or may not make sense to have the
driver believe it's multiqueue.) I added some placeholder comments and a
reference to our internal bug ID on this issue.
> You mustn't treat random fields to atomic_t. For one thing, atomic_t
> contains an int while stats are unsigned long...
>
> Also, you're adding cache contention between all your CPUs here. You
> should maintain these stats per-CPU and then sum them in
> tile_net_get_stats(). Then you can just use ordinary additions.
Oops, you're right that atomic_t is the wrong size. What I've done is
switch to atomic_long_t, but moved the cast to a separate
tile_net_stats_add() function that has a BUILD_BUG_ON() to validate that
the sizes match, and also a long comment explaining why tilegx's memory
network architecture makes atomic adds exactly the right kind of thing to
do here. It's easy to forget that 99% of the world has a model of atomics
based on the Intel architecture.
> [...]
>> +/* Ioctl commands. */
>> +static int tile_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
>> +{
>> + return -EOPNOTSUPP;
>> +}
> So why define it at all?
Because a following patch (not yet posted to LKML) adds support for
SIOCSHWTSTAMP and the ioctl was originally written that way to put the
framework in place.
The few suggestions I didn't respond to directly where pretty
straightforward and I just implemented them as you suggested.
Thanks again! The revised patch will follow momentarily.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Paul Gortmaker @ 2012-05-20 16:41 UTC (permalink / raw)
To: Ondrej Zary; +Cc: davem, netdev, Alan Cox
In-Reply-To: <201205191058.45328.linux@rainbow-software.org>
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 19/05/2012 (Sat 10:58) Ondrej Zary wrote:
> On Saturday 19 May 2012 00:03:06 Paul Gortmaker wrote:
> > [Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On
> 18/05/2012 (Fri 20:16) Ondrej Zary wrote:
> > > On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote:
> > > > It was amusing that linux was able to make use of this 1980's
> > > > technology on machines long past its intended lifespan, but
> > > > it probably should go now -- it is causing issues in some
> > > > distros[1], and while that might be fixable, it is just not
> > > > worth it.
> > > >
> > > > [1]
> > > > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-c
> > > >ard- not-detecting-934344/
> > >
> > > That looks like a bug elsewhere and removing this driver will not fix it.
> >
> > You miss the point. We've got someone with a modern i7 machine who is
> > getting confused by seeing messages from some ancient 3c501 driver, but
> > he doesn't have the context to know it is ancient and the message is a
> > red herring. Will it fix a distro's broken init that tries to modprobe
> > everything? No. Will it help by not muddying the waters with
> > meaningless printk from 3c501 that confuse users? Yes.
>
> Are you going to remove all drivers that complain that the HW is not present
> because some broken script is trying to modprobe them all? Or only the first
> one? 3c501 is probably the first in alphabet. You remove that and the script
> will modprobe 3c503 then...
Per my other mail, I think to focus on this one user's issue misses the
bigger picture entirely; the real issue was called out in the commit log:
But from a functional point of view, the real issue, as stated
in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can
only do one thing at a time -- while you are removing one packet
from the single-packet buffer it cannot receive another packet,
nor can it receive a packet while loading a transmit packet."
Regardless, to answer your questions:
1) No, obviously an rm-rf of all drivers that can't probe quietly was
not going to happen; that was never implicilty or explicitly proposed.
2) From memory while working on the 3c503 driver 15 odd years ago, it
could probe silently and semi reliably, which was impressive then, given
it was pre ISA-PnP. It was worlds ahead of a 3c501 card.
Paul.
--
>
> --
> Ondrej Zary
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Tom Herbert @ 2012-05-20 17:40 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: netdev, e1000-devel, jeffrey.t.kirsher, jesse.brandeburg,
eric.dumazet, davem
In-Reply-To: <79d6b56fdf5f4be4656079568d5a7445@visp.net.lb>
Tried to reproduce:
May 20 10:08:30 test kernel: [ 6.168240] e1000e 0000:06:00.0:
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to
dynamic conservative mode
May 20 10:08:30 test kernel: [ 6.221591] e1000e 0000:06:00.1:
(unregistered net_device): Interrupt Throttling Rate (ints/sec) set to
dynamic conservative mode
06:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
06:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
Ethernet Controller (Copper) (rev 01)
Following above instructions to repro gives:
1480 bytes from test2 (192.168.2.49): icmp_req=5875 ttl=64 time=0.358 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5876 ttl=64 time=0.330 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5877 ttl=64 time=0.337 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5878 ttl=64 time=0.375 ms
1480 bytes from test2 (192.168.2.49): icmp_req=5879 ttl=64 time=0.359 ms
1480 bytes from lpb49.prod.google.com (192.168.2.49): icmp_req=5880
ttl=64 time=0.380 ms
And I didn't see the stalls. This was on an Intel machine. The limit
was stable, went up to around 28K when opened large file and tended to
stay between 15-28K.
The describe problem seems to have characteristics that transmit
interrupts are not at all periodic, and it would seem that some are
taking hundreds of milliseconds to pop. I don't see anything that
would cause that in the NIC, is it possible there is some activity on
the machines periodically and often holding down interrupts for long
periods of time. Are there any peculiarities on Sun Fire in interrupt
handling?
Can you also provide an 'ethtool -c eth0'
Thanks,
Tom
On Fri, May 18, 2012 at 7:40 PM, Denys Fedoryshchenko <denys@visp.net.lb> wrote:
> On 2012-05-19 05:07, Tom Herbert wrote:
>>
>> 3) Have you tried a different interrupt mode?
>
>
> Now tested:
> e1000e.TxIntDelay=0,0,0,0
> [ 4.930570] e1000e 0000:04:00.0: (unregistered net_device): Transmit
> Interrupt Delay set to 0
> [ 4.930573] e1000e 0000:04:00.0: (unregistered net_device): Interrupt
> Throttling Rate (ints/sec) set to dynamic conservative mode
> Problem still occur.
>
> e1000e.TxIntDelay=0,0,0,0 e1000e.InterruptThrottleRate=0,0,0,0
> [ 4.971476] e1000e 0000:04:00.0: (unregistered net_device): Transmit
> Interrupt Delay set to 0
> [ 4.971478] e1000e 0000:04:00.0: (unregistered net_device): Interrupt
> Throttling Rate (ints/sec) turned off
> Problem also occur.
>
> Probably it is a case of this specific machine, this problem is happened on
> same hardware (Sun Fire X4150).
> The only "exotic" thing here is set of cards:
>
> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet
> Controller (Copper) (rev 01)
> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet
> Controller (Copper) (rev 01)
> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
> Controller (rev 06)
> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
> Controller (rev 06)
>
> I'm using first card.
>
>
>>
>> Per #3, I am wondering if dynamic conservative mode interrupt
>> throttling is not producing interrupts deterministically for BQL.
>> I'll try to reproduce the problem in this mode.
>>
>>> I can make a patch that will make minimum BQL value not less than MTU +
>>> overhead, is it ok like this?
>>> Probably it will solve issue, but it is more workaround and safety fuse,
>>> than a solution.
>>>
>> That would just be a bandaid and could just make this a latent issue
>> for the future.
>>
>> Tom
>>
>>>
>>> On 2012-05-17 19:54, Denys Fedoryshchenko wrote:
>>>>
>>>>
>>>> Also i notice, limit constantly changing over time (even i am not
>>>> touching it).
>>>>
>>>> centaur ~ # grep "" /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:0
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>
>>>>
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>> centaur ~ # grep "" /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:4542
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>
>>>>
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>>
>>>> Is it supposed to be like this?
>>>>
>>>> On 2012-05-17 16:42, Denys Fedoryshchenko wrote:
>>>>>
>>>>>
>>>>> Found commit that cause problem:
>>>>>
>>>>> author Tom Herbert <therbert@google.com>
>>>>> Mon, 28 Nov 2011 16:33:16 +0000 (16:33 +0000)
>>>>> committer David S. Miller <davem@davemloft.net>
>>>>> Tue, 29 Nov 2011 17:46:19 +0000 (12:46 -0500)
>>>>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>>>>> tree d6670a4f94b2b9dedacc38edb6f0e1306b889f6b tree | snapshot
>>>>> parent 114cf5802165ee93e3ab461c9c505cd94a08b800 commit | diff
>>>>> e1000e: Support for byte queue limits
>>>>>
>>>>> Changes to e1000e to use byte queue limits.
>>>>>
>>>>> Signed-off-by: Tom Herbert <therbert@google.com>
>>>>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>>
>>>>> If i reverse it, problem disappearing.
>>>>>
>>>>> How i reproduce it:
>>>>> In two consoles do "fast" ping to nearby host
>>>>> ping 194.146.XXX.XXX -s1472 -i0.0001
>>>>> ping 194.146.XXX.XXX -s1472 -i0.1
>>>>>
>>>>> For third open ssh to host with "problem", open mcedit, and just
>>>>> scroll down large text file.
>>>>> After few seconds some "stalls" will occur, and in ping history i can
>>>>> see:
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1797 ttl=64 time=0.161 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1798 ttl=64 time=0.198 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1799 ttl=64 time=0.340 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1800 ttl=64 time=0.381 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1801 ttl=64 time=914 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1802 ttl=64 time=804 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1803 ttl=64 time=704 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1804 ttl=64 time=594 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1805 ttl=64 time=0.287 ms
>>>>> 1480 bytes from 194.146.153.7: icmp_req=1806 ttl=64 time=0.226 ms
>>>>>
>>>>>
>>>>> If i apply small patch - problem will disappear. Sure it is not a
>>>>> solution, but
>>>>> let me know how i can help to debug problem more.
>>>>>
>>>>> --- netdev.c 2012-05-12 20:08:37.000000000 +0300
>>>>> +++ netdev.c.patched 2012-05-17 16:32:28.895760472 +0300
>>>>> @@ -1135,7 +1135,7 @@
>>>>>
>>>>> tx_ring->next_to_clean = i;
>>>>>
>>>>> - netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>> +// netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>>
>>>>> #define TX_WAKE_THRESHOLD 32
>>>>> if (count && netif_carrier_ok(netdev) &&
>>>>> @@ -2263,7 +2263,7 @@
>>>>> e1000_put_txbuf(adapter, buffer_info);
>>>>> }
>>>>>
>>>>> - netdev_reset_queue(adapter->netdev);
>>>>> +// netdev_reset_queue(adapter->netdev);
>>>>> size = sizeof(struct e1000_buffer) * tx_ring->count;
>>>>> memset(tx_ring->buffer_info, 0, size);
>>>>>
>>>>> @@ -5056,7 +5056,7 @@
>>>>> /* if count is 0 then mapping error has occurred */
>>>>> count = e1000_tx_map(adapter, skb, first, max_per_txd,
>>>>> nr_frags, mss);
>>>>> if (count) {
>>>>> - netdev_sent_queue(netdev, skb->len);
>>>>> +// netdev_sent_queue(netdev, skb->len);
>>>>> e1000_tx_queue(adapter, tx_flags, count);
>>>>> /* Make sure there is space in the ring for the next
>>>>> send.
>>>>> */
>>>>> e1000_maybe_stop_tx(netdev, MAX_SKB_FRAGS + 2);
>>>>>
>>>>>
>>>>>
>>>>> On 2012-05-15 17:15, Denys Fedoryshchenko wrote:
>>>>>>
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>> I have two identical servers, Sun Fire X4150, both has different
>>>>>> flavors of Linux, x86_64 and i386.
>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> I am using now interface:
>>>>>> #ethtool -i eth0
>>>>>> driver: e1000e
>>>>>> version: 1.9.5-k
>>>>>> firmware-version: 2.1-11
>>>>>> bus-info: 0000:04:00.0
>>>>>> There is 2 CPU , Intel(R) Xeon(R) CPU E5440 @ 2.83GHz .
>>>>>>
>>>>>> i386 was acting as NAT and shaper, and as soon as i removed shaper
>>>>>> from it, i started to experience strange lockups, e.g. traffic is
>>>>>> normal for 5-30 seconds, then short lockup for 500-3000ms (usually
>>>>>> around 1000ms) with dropped packets counter increasing. I was
>>>>>> suspecting it is due load, but it seems was wrong.
>>>>>> Recently, on another server, x86_64 i am using as development, i
>>>>>> upgrade kernel (it was old, from 2.6 series) and on completely idle
>>>>>> machine started to experience same latency spikes, while i am just
>>>>>> running mc and for example typing in text editor - i notice "stalls".
>>>>>> After i investigate it a little more, i notice also small amount of
>>>>>> drops on interface. No tcpdump running. Also this machine is idle, and
>>>>>> the only traffic there - some small broadcasts from network, my ssh,
>>>>>> and ping.
>>>>>>
>>>>>> Dropped packets in ifconfig
>>>>>> RX packets:3752868 errors:0 dropped:5350 overruns:0 frame:0
>>>>>> Counter is increasing sometimes, when this stall happening.
>>>>>>
>>>>>> ethtool -S is clean, there is no dropped packets.
>>>>>>
>>>>>> I did tried to check load (mpstat and perf), there is nothing
>>>>>> suspicious, latencytop also doesn't show anything suspicious.
>>>>>> dropwatch report a lot of drops, but mostly because there is some
>>>>>> broadcasts and etc. tcpdump at the moment of such drops doesn't show
>>>>>> anything suspicious.
>>>>>> Changed qdisc from default fifo_fast to bfifo, without any result.
>>>>>> Tried: ethtool -K eth0 tso off gso off gro off sg off , no result
>>>>>> Problem occured at 3.3.6 - 3.4.0-rc7, most probably 3.3.0 also, but i
>>>>>> don't remember for sure. I thik on some kernels like 3.1 probably it
>>>>>> doesn't occur, i will check it soon, because it is not always reliable
>>>>>> to reproduce it. All tests i did on 3.4.0-rc7.
>>>>>>
>>>>>> I did run also in background tcpdump, additionally iptables with
>>>>>> timestamps, and at time when stall occured, seems i am still receiving
>>>>>> packets properly, also on iperf udp (from some host to this SunFire)
>>>>>> at this moments no packets missing. But i am sure RX interface errors
>>>>>> are increasing.
>>>>>> If i do iperf from SunFire to test host - there is packetloss at
>>>>>> moments when stall occured.
>>>>>>
>>>>>> I suspect that by some reason network card stop to transmit, but
>>>>>> unable to pinpoint issue. All other hosts in this network are fine and
>>>>>> don't have such problems.
>>>>>> Can you help me with that please? Maybe i can provide more debug
>>>>>> information, compile with patches and etc. Also i will try to fallback
>>>>>> to 3.1 and 3.0 kernels.
>>>>>>
>>>>>> Here it is how it occurs and i am reproducing it:
>>>>>> I'm just opening file, and start to scroll it in mc, then in another
>>>>>> console i run ping
>>>>>> [1337089061.844167] 1480 bytes from 194.146.153.20: icmp_req=162
>>>>>> ttl=64 time=0.485 ms
>>>>>> [1337089061.944138] 1480 bytes from 194.146.153.20: icmp_req=163
>>>>>> ttl=64 time=0.470 ms
>>>>>> [1337089062.467759] 1480 bytes from 194.146.153.20: icmp_req=164
>>>>>> ttl=64 time=424 ms
>>>>>> [1337089062.467899] 1480 bytes from 194.146.153.20: icmp_req=165
>>>>>> ttl=64 time=324 ms
>>>>>> [1337089062.468058] 1480 bytes from 194.146.153.20: icmp_req=166
>>>>>> ttl=64 time=214 ms
>>>>>> [1337089062.468161] 1480 bytes from 194.146.153.20: icmp_req=167
>>>>>> ttl=64 time=104 ms
>>>>>> [1337089062.468958] 1480 bytes from 194.146.153.20: icmp_req=168
>>>>>> ttl=64 time=1.15 ms
>>>>>> [1337089062.568604] 1480 bytes from 194.146.153.20: icmp_req=169
>>>>>> ttl=64 time=0.477 ms
>>>>>> [1337089062.668909] 1480 bytes from 194.146.153.20: icmp_req=170
>>>>>> ttl=64 time=0.667 ms
>>>>>>
>>>>>> Remote host tcpdump:
>>>>>> 1337089061.934737 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 163, length 1480
>>>>>> 1337089062.458360 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 164, length 1480
>>>>>> 1337089062.458380 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 164, length 1480
>>>>>> 1337089062.458481 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 165, length 1480
>>>>>> 1337089062.458502 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 165, length 1480
>>>>>> 1337089062.458606 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 166, length 1480
>>>>>> 1337089062.458623 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 166, length 1480
>>>>>> 1337089062.458729 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 167, length 1480
>>>>>> 1337089062.458745 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 167, length 1480
>>>>>> 1337089062.459537 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 168, length 1480
>>>>>> 1337089062.459545 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 168, length 1480
>>>>>>
>>>>>> Local host(SunFire) tcpdump:
>>>>>> 1337089061.844140 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 162, length 1480
>>>>>> 1337089061.943661 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 163, length 1480
>>>>>> 1337089061.944124 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 163, length 1480
>>>>>> 1337089062.465622 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 164, length 1480
>>>>>> 1337089062.465630 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 165, length 1480
>>>>>> 1337089062.465632 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 166, length 1480
>>>>>> 1337089062.465634 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 167, length 1480
>>>>>> 1337089062.467730 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 164, length 1480
>>>>>> 1337089062.467785 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 168, length 1480
>>>>>> 1337089062.467884 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 165, length 1480
>>>>>> 1337089062.468035 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 166, length 1480
>>>>>> 1337089062.468129 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 167, length 1480
>>>>>> 1337089062.468928 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 168, length 1480
>>>>>> 1337089062.568112 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>> request, id 3486, seq 169, length 1480
>>>>>> 1337089062.568578 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>> reply, id 3486, seq 169, length 1480
>>>>>>
>>>>>> lspci -t
>>>>>> centaur src # lspci -t
>>>>>> -[0000:00]-+-00.0
>>>>>> +-02.0-[01-05]--+-00.0-[02-04]--+-00.0-[03]--
>>>>>> | | \-02.0-[04]--+-00.0
>>>>>> | | \-00.1
>>>>>> | \-00.3-[05]--
>>>>>> +-03.0-[06]--
>>>>>> +-04.0-[07]----00.0
>>>>>> +-05.0-[08]--
>>>>>> +-06.0-[09]--
>>>>>> +-07.0-[0a]--
>>>>>> +-08.0
>>>>>> +-10.0
>>>>>> +-10.1
>>>>>> +-10.2
>>>>>> +-11.0
>>>>>> +-13.0
>>>>>> +-15.0
>>>>>> +-16.0
>>>>>> +-1c.0-[0b]--+-00.0
>>>>>> | \-00.1
>>>>>> +-1d.0
>>>>>> +-1d.1
>>>>>> +-1d.2
>>>>>> +-1d.3
>>>>>> +-1d.7
>>>>>> +-1e.0-[0c]----05.0
>>>>>> +-1f.0
>>>>>> +-1f.1
>>>>>> +-1f.2
>>>>>> \-1f.3
>>>>>> lspci
>>>>>> 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory
>>>>>> Controller Hub (rev b1)
>>>>>> 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 2 (rev b1)
>>>>>> 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 3 (rev b1)
>>>>>> 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x8 Port 4-5 (rev b1)
>>>>>> 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 5 (rev b1)
>>>>>> 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x8 Port 6-7 (rev b1)
>>>>>> 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express
>>>>>> x4 Port 7 (rev b1)
>>>>>> 00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA
>>>>>> Engine (rev b1)
>>>>>> 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>> Registers (rev b1)
>>>>>> 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>> Registers (rev b1)
>>>>>> 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>> Registers (rev b1)
>>>>>> 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
>>>>>> Registers (rev b1)
>>>>>> 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved
>>>>>> Registers (rev b1)
>>>>>> 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>> Registers (rev b1)
>>>>>> 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>> Registers (rev b1)
>>>>>> 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset
>>>>>> PCI Express Root Port 1 (rev 09)
>>>>>> 00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #1 (rev 09)
>>>>>> 00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #2 (rev 09)
>>>>>> 00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #3 (rev 09)
>>>>>> 00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset UHCI USB Controller #4 (rev 09)
>>>>>> 00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>> Chipset EHCI USB2 Controller (rev 09)
>>>>>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
>>>>>> 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset
>>>>>> LPC Interface Controller (rev 09)
>>>>>> 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE
>>>>>> Controller (rev 09)
>>>>>> 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA AHCI
>>>>>> Controller (rev 09)
>>>>>> 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus
>>>>>> Controller (rev 09)
>>>>>> 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
>>>>>> Upstream Port (rev 01)
>>>>>> 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to
>>>>>> PCI-X Bridge (rev 01)
>>>>>> 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
>>>>>> Downstream Port E1 (rev 01)
>>>>>> 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express
>>>>>> Downstream Port E3 (rev 01)
>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>> 07:00.0 RAID bus controller: Adaptec AAC-RAID (rev 09)
>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>> Ethernet Controller (rev 06)
>>>>>> 0c:05.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
>>>>>> Graphics Family
>>>>>>
>>>>>>
>>>>>> dmesg:
>>>>>> [ 4.936885] e1000: Intel(R) PRO/1000 Network Driver - version
>>>>>> 7.3.21-k8-NAPI
>>>>>> [ 4.936887] e1000: Copyright (c) 1999-2006 Intel Corporation.
>>>>>> [ 4.936966] e1000e: Intel(R) PRO/1000 Network Driver - 1.9.5-k
>>>>>> [ 4.936967] e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
>>>>>> [ 4.938529] e1000e 0000:04:00.0: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 4.939598] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>> [ 4.992246] e1000e 0000:04:00.0: eth0: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:f8
>>>>>> [ 4.992657] e1000e 0000:04:00.0: eth0: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 4.992964] e1000e 0000:04:00.0: eth0: MAC: 5, PHY: 5, PBA No:
>>>>>> FFFFFF-0FF
>>>>>> [ 4.994745] e1000e 0000:04:00.1: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 4.996233] e1000e 0000:04:00.1: irq 66 for MSI/MSI-X
>>>>>> [ 5.050901] e1000e 0000:04:00.1: eth1: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:f9
>>>>>> [ 5.051317] e1000e 0000:04:00.1: eth1: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 5.051623] e1000e 0000:04:00.1: eth1: MAC: 5, PHY: 5, PBA No:
>>>>>> FFFFFF-0FF
>>>>>> [ 5.051857] e1000e 0000:0b:00.0: Disabling ASPM L1
>>>>>> [ 5.052168] e1000e 0000:0b:00.0: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 5.052611] e1000e 0000:0b:00.0: irq 67 for MSI/MSI-X
>>>>>> [ 5.223454] e1000e 0000:0b:00.0: eth2: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:fa
>>>>>> [ 5.223864] e1000e 0000:0b:00.0: eth2: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 5.224178] e1000e 0000:0b:00.0: eth2: MAC: 0, PHY: 4, PBA No:
>>>>>> C83246-002
>>>>>> [ 5.224412] e1000e 0000:0b:00.1: Disabling ASPM L1
>>>>>> [ 5.224709] e1000e 0000:0b:00.1: (unregistered net_device):
>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
>>>>>> [ 5.225168] e1000e 0000:0b:00.1: irq 68 for MSI/MSI-X
>>>>>> [ 5.397603] e1000e 0000:0b:00.1: eth3: (PCI Express:2.5GT/s:Width
>>>>>> x4) 00:1e:68:04:99:fb
>>>>>> [ 5.398021] e1000e 0000:0b:00.1: eth3: Intel(R) PRO/1000 Network
>>>>>> Connection
>>>>>> [ 5.398336] e1000e 0000:0b:00.1: eth3: MAC: 0, PHY: 4, PBA No:
>>>>>> C83246-002
>>>>>> [ 13.859817] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>> [ 13.962309] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>> [ 17.150392] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex,
>>>>>> Flow Control: None
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Network engineer
>>>>> Denys Fedoryshchenko
>>>>>
>>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>>> Beirut, Lebanon
>>>>> Tel: +961 1 247373
>>>>> E-Mail: denys@visp.net.lb
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> ---
>>>> Network engineer
>>>> Denys Fedoryshchenko
>>>>
>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>> Beirut, Lebanon
>>>> Tel: +961 1 247373
>>>> E-Mail: denys@visp.net.lb
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>> ---
>>> Network engineer
>>> Denys Fedoryshchenko
>>>
>>> Dora Highway - Center Cebaco - 2nd Floor
>>> Beirut, Lebanon
>>> Tel: +961 1 247373
>>> E-Mail: denys@visp.net.lb
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> ---
> Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-20 18:13 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: e1000-devel, netdev, jesse.brandeburg, davem, therbert
In-Reply-To: <d3a88d6c741394a48aee6179d58e4edf@visp.net.lb>
On Fri, 2012-05-18 at 17:04 +0300, Denys Fedoryshchenko wrote:
> It seems logic in BQL has serious issues. The most bad thing, if
> and it is empty. So in result, instead of eliminating latency, it is
> adding it.
There is maybe a misunderstanding here. BQL by itself only reduce amount
of buffering in TX ring. Now there's still the Qdisc layer.
On my laptop (e1000e NIC), and default pfifo_fast I can immediately see
the difference in ping results if I launch a single netperf TCP_STREAM
in another window :
1480 bytes from 172.30.42.1: icmp_seq=5047 ttl=64 time=0.185 ms
1480 bytes from 172.30.42.1: icmp_seq=5048 ttl=64 time=0.198 ms
1480 bytes from 172.30.42.1: icmp_seq=5049 ttl=64 time=0.255 ms
1480 bytes from 172.30.42.1: icmp_seq=5050 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=5051 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=5052 ttl=64 time=0.226 ms
1480 bytes from 172.30.42.1: icmp_seq=5053 ttl=64 time=0.186 ms
1480 bytes from 172.30.42.1: icmp_seq=5054 ttl=64 time=0.190 ms
1480 bytes from 172.30.42.1: icmp_seq=5055 ttl=64 time=0.223 ms
1480 bytes from 172.30.42.1: icmp_seq=5056 ttl=64 time=0.178 ms
1480 bytes from 172.30.42.1: icmp_seq=5057 ttl=64 time=0.191 ms
1480 bytes from 172.30.42.1: icmp_seq=5058 ttl=64 time=0.229 ms
1480 bytes from 172.30.42.1: icmp_seq=5059 ttl=64 time=0.229 ms
1480 bytes from 172.30.42.1: icmp_seq=5060 ttl=64 time=0.213 ms
1480 bytes from 172.30.42.1: icmp_seq=5061 ttl=64 time=0.187 ms
1480 bytes from 172.30.42.1: icmp_seq=5062 ttl=64 time=0.944 ms
1480 bytes from 172.30.42.1: icmp_seq=5063 ttl=64 time=4.67 ms
1480 bytes from 172.30.42.1: icmp_seq=5064 ttl=64 time=8.55 ms
1480 bytes from 172.30.42.1: icmp_seq=5065 ttl=64 time=12.8 ms
1480 bytes from 172.30.42.1: icmp_seq=5066 ttl=64 time=16.9 ms
1480 bytes from 172.30.42.1: icmp_seq=5067 ttl=64 time=20.5 ms
1480 bytes from 172.30.42.1: icmp_seq=5068 ttl=64 time=24.3 ms
1480 bytes from 172.30.42.1: icmp_seq=5069 ttl=64 time=27.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5070 ttl=64 time=26.8 ms
1480 bytes from 172.30.42.1: icmp_seq=5071 ttl=64 time=26.7 ms
1480 bytes from 172.30.42.1: icmp_seq=5072 ttl=64 time=26.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5073 ttl=64 time=27.0 ms
1480 bytes from 172.30.42.1: icmp_seq=5074 ttl=64 time=25.6 ms
1480 bytes from 172.30.42.1: icmp_seq=5075 ttl=64 time=26.7 ms
1480 bytes from 172.30.42.1: icmp_seq=5076 ttl=64 time=26.9 ms
1480 bytes from 172.30.42.1: icmp_seq=5077 ttl=64 time=25.0 ms
Now if I replace pfifo_fast by fq_codel : (still TSO and GSO are on)
1480 bytes from 172.30.42.1: icmp_seq=37 ttl=64 time=0.197 ms
1480 bytes from 172.30.42.1: icmp_seq=38 ttl=64 time=0.283 ms
1480 bytes from 172.30.42.1: icmp_seq=39 ttl=64 time=0.183 ms
1480 bytes from 172.30.42.1: icmp_seq=40 ttl=64 time=0.182 ms
1480 bytes from 172.30.42.1: icmp_seq=41 ttl=64 time=0.207 ms
1480 bytes from 172.30.42.1: icmp_seq=42 ttl=64 time=0.202 ms
1480 bytes from 172.30.42.1: icmp_seq=43 ttl=64 time=0.244 ms
1480 bytes from 172.30.42.1: icmp_seq=44 ttl=64 time=0.200 ms
1480 bytes from 172.30.42.1: icmp_seq=45 ttl=64 time=0.212 ms
1480 bytes from 172.30.42.1: icmp_seq=46 ttl=64 time=0.215 ms
1480 bytes from 172.30.42.1: icmp_seq=47 ttl=64 time=0.178 ms
1480 bytes from 172.30.42.1: icmp_seq=48 ttl=64 time=0.215 ms
1480 bytes from 172.30.42.1: icmp_seq=49 ttl=64 time=0.238 ms
1480 bytes from 172.30.42.1: icmp_seq=50 ttl=64 time=0.210 ms
1480 bytes from 172.30.42.1: icmp_seq=51 ttl=64 time=0.974 ms
1480 bytes from 172.30.42.1: icmp_seq=52 ttl=64 time=1.93 ms
1480 bytes from 172.30.42.1: icmp_seq=53 ttl=64 time=1.71 ms
1480 bytes from 172.30.42.1: icmp_seq=54 ttl=64 time=3.07 ms
1480 bytes from 172.30.42.1: icmp_seq=55 ttl=64 time=3.47 ms
1480 bytes from 172.30.42.1: icmp_seq=56 ttl=64 time=2.53 ms
1480 bytes from 172.30.42.1: icmp_seq=57 ttl=64 time=3.24 ms
1480 bytes from 172.30.42.1: icmp_seq=58 ttl=64 time=3.11 ms
1480 bytes from 172.30.42.1: icmp_seq=59 ttl=64 time=3.03 ms
1480 bytes from 172.30.42.1: icmp_seq=60 ttl=64 time=2.96 ms
1480 bytes from 172.30.42.1: icmp_seq=61 ttl=64 time=2.90 ms
1480 bytes from 172.30.42.1: icmp_seq=62 ttl=64 time=2.97 ms
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Denys Fedoryshchenko @ 2012-05-20 18:53 UTC (permalink / raw)
To: Tom Herbert; +Cc: e1000-devel, netdev, jesse.brandeburg, davem
In-Reply-To: <CA+mtBx_sF5GCMRpLQuTruZ=xpFTFpd5z8SZJaG_dBqf4oCXpwg@mail.gmail.com>
>
> And I didn't see the stalls. This was on an Intel machine. The limit
> was stable, went up to around 28K when opened large file and tended
> to
> stay between 15-28K.
>
> The describe problem seems to have characteristics that transmit
> interrupts are not at all periodic, and it would seem that some are
> taking hundreds of milliseconds to pop. I don't see anything that
> would cause that in the NIC, is it possible there is some activity on
> the machines periodically and often holding down interrupts for long
> periods of time. Are there any peculiarities on Sun Fire in
> interrupt
> handling?
>
> Can you also provide an 'ethtool -c eth0'
>
> Thanks,
> Tom
>
Technically i can install there fresh gentoo with latest vanilla kernel
and provide remote access.
But it will take some time. I will try now to play with IRQ pinning,
but not sure i will reach anything.
My kernel config http://www.nuclearcat.com/config_stall.txt
It is completely idle machine. I didn't notice any anomalies with
interrutps to
compare with other servers (not Sun Fire). If there is anomalies with
interrupts
(for example SMI), probably i should notice that even without BQL, but
this machine
works very well and i didn't notice any latency without BQL.
centaur ~ # pidstat 1
Linux 3.4.0-rc7-centaur (centaur) 05/20/12 _x86_64_
(8 CPU)
21:41:25 PID %usr %system %guest %CPU CPU Command
21:41:26 PID %usr %system %guest %CPU CPU Command
21:41:27 2617 0.00 1.00 0.00 1.00 2 pidstat
21:41:27 PID %usr %system %guest %CPU CPU Command
21:41:28 PID %usr %system %guest %CPU CPU Command
21:41:29 PID %usr %system %guest %CPU CPU Command
21:41:30 2617 0.00 1.00 0.00 1.00 2 pidstat
From powertop:
Wakeups-from-idle per second : 7.5 interval: 10.0s
ethtool -c eth0, sure i can provide, it is default values:
centaur ~ # ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: off TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
rx-usecs: 3
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0
tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 0
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
>
>
>
> On Fri, May 18, 2012 at 7:40 PM, Denys Fedoryshchenko
> <denys@visp.net.lb> wrote:
>> On 2012-05-19 05:07, Tom Herbert wrote:
>>>
>>> 3) Have you tried a different interrupt mode?
>>
>>
>> Now tested:
>> e1000e.TxIntDelay=0,0,0,0
>> [ 4.930570] e1000e 0000:04:00.0: (unregistered net_device):
>> Transmit
>> Interrupt Delay set to 0
>> [ 4.930573] e1000e 0000:04:00.0: (unregistered net_device):
>> Interrupt
>> Throttling Rate (ints/sec) set to dynamic conservative mode
>> Problem still occur.
>>
>> e1000e.TxIntDelay=0,0,0,0 e1000e.InterruptThrottleRate=0,0,0,0
>> [ 4.971476] e1000e 0000:04:00.0: (unregistered net_device):
>> Transmit
>> Interrupt Delay set to 0
>> [ 4.971478] e1000e 0000:04:00.0: (unregistered net_device):
>> Interrupt
>> Throttling Rate (ints/sec) turned off
>> Problem also occur.
>>
>> Probably it is a case of this specific machine, this problem is
>> happened on
>> same hardware (Sun Fire X4150).
>> The only "exotic" thing here is set of cards:
>>
>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>> Ethernet
>> Controller (Copper) (rev 01)
>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit
>> Ethernet
>> Controller (Copper) (rev 01)
>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>> Ethernet
>> Controller (rev 06)
>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>> Ethernet
>> Controller (rev 06)
>>
>> I'm using first card.
>>
>>
>>>
>>> Per #3, I am wondering if dynamic conservative mode interrupt
>>> throttling is not producing interrupts deterministically for BQL.
>>> I'll try to reproduce the problem in this mode.
>>>
>>>> I can make a patch that will make minimum BQL value not less than
>>>> MTU +
>>>> overhead, is it ok like this?
>>>> Probably it will solve issue, but it is more workaround and safety
>>>> fuse,
>>>> than a solution.
>>>>
>>> That would just be a bandaid and could just make this a latent
>>> issue
>>> for the future.
>>>
>>> Tom
>>>
>>>>
>>>> On 2012-05-17 19:54, Denys Fedoryshchenko wrote:
>>>>>
>>>>>
>>>>> Also i notice, limit constantly changing over time (even i am not
>>>>> touching it).
>>>>>
>>>>> centaur ~ # grep ""
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:0
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>>
>>>>>
>>>>>
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>>> centaur ~ # grep ""
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/*
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/hold_time:1000
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight:4542
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit:13018
>>>>>
>>>>>
>>>>>
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_max:1879048192
>>>>> /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit_min:0
>>>>>
>>>>> Is it supposed to be like this?
>>>>>
>>>>> On 2012-05-17 16:42, Denys Fedoryshchenko wrote:
>>>>>>
>>>>>>
>>>>>> Found commit that cause problem:
>>>>>>
>>>>>> author Tom Herbert <therbert@google.com>
>>>>>> Mon, 28 Nov 2011 16:33:16 +0000 (16:33 +0000)
>>>>>> committer David S. Miller <davem@davemloft.net>
>>>>>> Tue, 29 Nov 2011 17:46:19 +0000 (12:46 -0500)
>>>>>> commit 3f0cfa3bc11e7f00c9994e0f469cbc0e7da7b00c
>>>>>> tree d6670a4f94b2b9dedacc38edb6f0e1306b889f6b tree |
>>>>>> snapshot
>>>>>> parent 114cf5802165ee93e3ab461c9c505cd94a08b800 commit |
>>>>>> diff
>>>>>> e1000e: Support for byte queue limits
>>>>>>
>>>>>> Changes to e1000e to use byte queue limits.
>>>>>>
>>>>>> Signed-off-by: Tom Herbert <therbert@google.com>
>>>>>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>>>>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>>>
>>>>>> If i reverse it, problem disappearing.
>>>>>>
>>>>>> How i reproduce it:
>>>>>> In two consoles do "fast" ping to nearby host
>>>>>> ping 194.146.XXX.XXX -s1472 -i0.0001
>>>>>> ping 194.146.XXX.XXX -s1472 -i0.1
>>>>>>
>>>>>> For third open ssh to host with "problem", open mcedit, and just
>>>>>> scroll down large text file.
>>>>>> After few seconds some "stalls" will occur, and in ping history
>>>>>> i can
>>>>>> see:
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1797 ttl=64 time=0.161
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1798 ttl=64 time=0.198
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1799 ttl=64 time=0.340
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1800 ttl=64 time=0.381
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1801 ttl=64 time=914 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1802 ttl=64 time=804 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1803 ttl=64 time=704 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1804 ttl=64 time=594 ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1805 ttl=64 time=0.287
>>>>>> ms
>>>>>> 1480 bytes from 194.146.153.7: icmp_req=1806 ttl=64 time=0.226
>>>>>> ms
>>>>>>
>>>>>>
>>>>>> If i apply small patch - problem will disappear. Sure it is not
>>>>>> a
>>>>>> solution, but
>>>>>> let me know how i can help to debug problem more.
>>>>>>
>>>>>> --- netdev.c 2012-05-12 20:08:37.000000000 +0300
>>>>>> +++ netdev.c.patched 2012-05-17 16:32:28.895760472 +0300
>>>>>> @@ -1135,7 +1135,7 @@
>>>>>>
>>>>>> tx_ring->next_to_clean = i;
>>>>>>
>>>>>> - netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>>> +// netdev_completed_queue(netdev, pkts_compl, bytes_compl);
>>>>>>
>>>>>> #define TX_WAKE_THRESHOLD 32
>>>>>> if (count && netif_carrier_ok(netdev) &&
>>>>>> @@ -2263,7 +2263,7 @@
>>>>>> e1000_put_txbuf(adapter, buffer_info);
>>>>>> }
>>>>>>
>>>>>> - netdev_reset_queue(adapter->netdev);
>>>>>> +// netdev_reset_queue(adapter->netdev);
>>>>>> size = sizeof(struct e1000_buffer) * tx_ring->count;
>>>>>> memset(tx_ring->buffer_info, 0, size);
>>>>>>
>>>>>> @@ -5056,7 +5056,7 @@
>>>>>> /* if count is 0 then mapping error has occurred */
>>>>>> count = e1000_tx_map(adapter, skb, first, max_per_txd,
>>>>>> nr_frags, mss);
>>>>>> if (count) {
>>>>>> - netdev_sent_queue(netdev, skb->len);
>>>>>> +// netdev_sent_queue(netdev, skb->len);
>>>>>> e1000_tx_queue(adapter, tx_flags, count);
>>>>>> /* Make sure there is space in the ring for the
>>>>>> next
>>>>>> send.
>>>>>> */
>>>>>> e1000_maybe_stop_tx(netdev, MAX_SKB_FRAGS + 2);
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2012-05-15 17:15, Denys Fedoryshchenko wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have two identical servers, Sun Fire X4150, both has
>>>>>>> different
>>>>>>> flavors of Linux, x86_64 and i386.
>>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> I am using now interface:
>>>>>>> #ethtool -i eth0
>>>>>>> driver: e1000e
>>>>>>> version: 1.9.5-k
>>>>>>> firmware-version: 2.1-11
>>>>>>> bus-info: 0000:04:00.0
>>>>>>> There is 2 CPU , Intel(R) Xeon(R) CPU E5440 @
>>>>>>> 2.83GHz .
>>>>>>>
>>>>>>> i386 was acting as NAT and shaper, and as soon as i removed
>>>>>>> shaper
>>>>>>> from it, i started to experience strange lockups, e.g. traffic
>>>>>>> is
>>>>>>> normal for 5-30 seconds, then short lockup for 500-3000ms
>>>>>>> (usually
>>>>>>> around 1000ms) with dropped packets counter increasing. I was
>>>>>>> suspecting it is due load, but it seems was wrong.
>>>>>>> Recently, on another server, x86_64 i am using as development,
>>>>>>> i
>>>>>>> upgrade kernel (it was old, from 2.6 series) and on completely
>>>>>>> idle
>>>>>>> machine started to experience same latency spikes, while i am
>>>>>>> just
>>>>>>> running mc and for example typing in text editor - i notice
>>>>>>> "stalls".
>>>>>>> After i investigate it a little more, i notice also small
>>>>>>> amount of
>>>>>>> drops on interface. No tcpdump running. Also this machine is
>>>>>>> idle, and
>>>>>>> the only traffic there - some small broadcasts from network, my
>>>>>>> ssh,
>>>>>>> and ping.
>>>>>>>
>>>>>>> Dropped packets in ifconfig
>>>>>>> RX packets:3752868 errors:0 dropped:5350 overruns:0
>>>>>>> frame:0
>>>>>>> Counter is increasing sometimes, when this stall happening.
>>>>>>>
>>>>>>> ethtool -S is clean, there is no dropped packets.
>>>>>>>
>>>>>>> I did tried to check load (mpstat and perf), there is nothing
>>>>>>> suspicious, latencytop also doesn't show anything suspicious.
>>>>>>> dropwatch report a lot of drops, but mostly because there is
>>>>>>> some
>>>>>>> broadcasts and etc. tcpdump at the moment of such drops doesn't
>>>>>>> show
>>>>>>> anything suspicious.
>>>>>>> Changed qdisc from default fifo_fast to bfifo, without any
>>>>>>> result.
>>>>>>> Tried: ethtool -K eth0 tso off gso off gro off sg off , no
>>>>>>> result
>>>>>>> Problem occured at 3.3.6 - 3.4.0-rc7, most probably 3.3.0 also,
>>>>>>> but i
>>>>>>> don't remember for sure. I thik on some kernels like 3.1
>>>>>>> probably it
>>>>>>> doesn't occur, i will check it soon, because it is not always
>>>>>>> reliable
>>>>>>> to reproduce it. All tests i did on 3.4.0-rc7.
>>>>>>>
>>>>>>> I did run also in background tcpdump, additionally iptables
>>>>>>> with
>>>>>>> timestamps, and at time when stall occured, seems i am still
>>>>>>> receiving
>>>>>>> packets properly, also on iperf udp (from some host to this
>>>>>>> SunFire)
>>>>>>> at this moments no packets missing. But i am sure RX interface
>>>>>>> errors
>>>>>>> are increasing.
>>>>>>> If i do iperf from SunFire to test host - there is packetloss
>>>>>>> at
>>>>>>> moments when stall occured.
>>>>>>>
>>>>>>> I suspect that by some reason network card stop to transmit,
>>>>>>> but
>>>>>>> unable to pinpoint issue. All other hosts in this network are
>>>>>>> fine and
>>>>>>> don't have such problems.
>>>>>>> Can you help me with that please? Maybe i can provide more
>>>>>>> debug
>>>>>>> information, compile with patches and etc. Also i will try to
>>>>>>> fallback
>>>>>>> to 3.1 and 3.0 kernels.
>>>>>>>
>>>>>>> Here it is how it occurs and i am reproducing it:
>>>>>>> I'm just opening file, and start to scroll it in mc, then in
>>>>>>> another
>>>>>>> console i run ping
>>>>>>> [1337089061.844167] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=162
>>>>>>> ttl=64 time=0.485 ms
>>>>>>> [1337089061.944138] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=163
>>>>>>> ttl=64 time=0.470 ms
>>>>>>> [1337089062.467759] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=164
>>>>>>> ttl=64 time=424 ms
>>>>>>> [1337089062.467899] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=165
>>>>>>> ttl=64 time=324 ms
>>>>>>> [1337089062.468058] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=166
>>>>>>> ttl=64 time=214 ms
>>>>>>> [1337089062.468161] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=167
>>>>>>> ttl=64 time=104 ms
>>>>>>> [1337089062.468958] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=168
>>>>>>> ttl=64 time=1.15 ms
>>>>>>> [1337089062.568604] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=169
>>>>>>> ttl=64 time=0.477 ms
>>>>>>> [1337089062.668909] 1480 bytes from 194.146.153.20:
>>>>>>> icmp_req=170
>>>>>>> ttl=64 time=0.667 ms
>>>>>>>
>>>>>>> Remote host tcpdump:
>>>>>>> 1337089061.934737 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 163, length 1480
>>>>>>> 1337089062.458360 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 164, length 1480
>>>>>>> 1337089062.458380 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 164, length 1480
>>>>>>> 1337089062.458481 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 165, length 1480
>>>>>>> 1337089062.458502 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 165, length 1480
>>>>>>> 1337089062.458606 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 166, length 1480
>>>>>>> 1337089062.458623 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 166, length 1480
>>>>>>> 1337089062.458729 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 167, length 1480
>>>>>>> 1337089062.458745 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 167, length 1480
>>>>>>> 1337089062.459537 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 168, length 1480
>>>>>>> 1337089062.459545 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 168, length 1480
>>>>>>>
>>>>>>> Local host(SunFire) tcpdump:
>>>>>>> 1337089061.844140 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 162, length 1480
>>>>>>> 1337089061.943661 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 163, length 1480
>>>>>>> 1337089061.944124 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 163, length 1480
>>>>>>> 1337089062.465622 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 164, length 1480
>>>>>>> 1337089062.465630 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 165, length 1480
>>>>>>> 1337089062.465632 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 166, length 1480
>>>>>>> 1337089062.465634 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 167, length 1480
>>>>>>> 1337089062.467730 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 164, length 1480
>>>>>>> 1337089062.467785 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 168, length 1480
>>>>>>> 1337089062.467884 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 165, length 1480
>>>>>>> 1337089062.468035 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 166, length 1480
>>>>>>> 1337089062.468129 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 167, length 1480
>>>>>>> 1337089062.468928 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 168, length 1480
>>>>>>> 1337089062.568112 IP 194.146.153.22 > 194.146.153.20: ICMP echo
>>>>>>> request, id 3486, seq 169, length 1480
>>>>>>> 1337089062.568578 IP 194.146.153.20 > 194.146.153.22: ICMP echo
>>>>>>> reply, id 3486, seq 169, length 1480
>>>>>>>
>>>>>>> lspci -t
>>>>>>> centaur src # lspci -t
>>>>>>> -[0000:00]-+-00.0
>>>>>>> +-02.0-[01-05]--+-00.0-[02-04]--+-00.0-[03]--
>>>>>>> | | \-02.0-[04]--+-00.0
>>>>>>> | | \-00.1
>>>>>>> | \-00.3-[05]--
>>>>>>> +-03.0-[06]--
>>>>>>> +-04.0-[07]----00.0
>>>>>>> +-05.0-[08]--
>>>>>>> +-06.0-[09]--
>>>>>>> +-07.0-[0a]--
>>>>>>> +-08.0
>>>>>>> +-10.0
>>>>>>> +-10.1
>>>>>>> +-10.2
>>>>>>> +-11.0
>>>>>>> +-13.0
>>>>>>> +-15.0
>>>>>>> +-16.0
>>>>>>> +-1c.0-[0b]--+-00.0
>>>>>>> | \-00.1
>>>>>>> +-1d.0
>>>>>>> +-1d.1
>>>>>>> +-1d.2
>>>>>>> +-1d.3
>>>>>>> +-1d.7
>>>>>>> +-1e.0-[0c]----05.0
>>>>>>> +-1f.0
>>>>>>> +-1f.1
>>>>>>> +-1f.2
>>>>>>> \-1f.3
>>>>>>> lspci
>>>>>>> 00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory
>>>>>>> Controller Hub (rev b1)
>>>>>>> 00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 2 (rev b1)
>>>>>>> 00:03.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 3 (rev b1)
>>>>>>> 00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x8 Port 4-5 (rev b1)
>>>>>>> 00:05.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 5 (rev b1)
>>>>>>> 00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x8 Port 6-7 (rev b1)
>>>>>>> 00:07.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI
>>>>>>> Express
>>>>>>> x4 Port 7 (rev b1)
>>>>>>> 00:08.0 System peripheral: Intel Corporation 5000 Series
>>>>>>> Chipset DMA
>>>>>>> Engine (rev b1)
>>>>>>> 00:10.0 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>>> Registers (rev b1)
>>>>>>> 00:10.1 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>>> Registers (rev b1)
>>>>>>> 00:10.2 Host bridge: Intel Corporation 5000 Series Chipset FSB
>>>>>>> Registers (rev b1)
>>>>>>> 00:11.0 Host bridge: Intel Corporation 5000 Series Chipset
>>>>>>> Reserved
>>>>>>> Registers (rev b1)
>>>>>>> 00:13.0 Host bridge: Intel Corporation 5000 Series Chipset
>>>>>>> Reserved
>>>>>>> Registers (rev b1)
>>>>>>> 00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>>> Registers (rev b1)
>>>>>>> 00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD
>>>>>>> Registers (rev b1)
>>>>>>> 00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset
>>>>>>> PCI Express Root Port 1 (rev 09)
>>>>>>> 00:1d.0 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #1 (rev 09)
>>>>>>> 00:1d.1 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #2 (rev 09)
>>>>>>> 00:1d.2 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #3 (rev 09)
>>>>>>> 00:1d.3 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset UHCI USB Controller #4 (rev 09)
>>>>>>> 00:1d.7 USB controller: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset EHCI USB2 Controller (rev 09)
>>>>>>> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
>>>>>>> 00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100
>>>>>>> Chipset
>>>>>>> LPC Interface Controller (rev 09)
>>>>>>> 00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE
>>>>>>> Controller (rev 09)
>>>>>>> 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA
>>>>>>> AHCI
>>>>>>> Controller (rev 09)
>>>>>>> 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset
>>>>>>> SMBus
>>>>>>> Controller (rev 09)
>>>>>>> 01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express
>>>>>>> Upstream Port (rev 01)
>>>>>>> 01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express to
>>>>>>> PCI-X Bridge (rev 01)
>>>>>>> 02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express
>>>>>>> Downstream Port E1 (rev 01)
>>>>>>> 02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI
>>>>>>> Express
>>>>>>> Downstream Port E3 (rev 01)
>>>>>>> 04:00.0 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 04:00.1 Ethernet controller: Intel Corporation 80003ES2LAN
>>>>>>> Gigabit
>>>>>>> Ethernet Controller (Copper) (rev 01)
>>>>>>> 07:00.0 RAID bus controller: Adaptec AAC-RAID (rev 09)
>>>>>>> 0b:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> 0b:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit
>>>>>>> Ethernet Controller (rev 06)
>>>>>>> 0c:05.0 VGA compatible controller: ASPEED Technology, Inc.
>>>>>>> ASPEED
>>>>>>> Graphics Family
>>>>>>>
>>>>>>>
>>>>>>> dmesg:
>>>>>>> [ 4.936885] e1000: Intel(R) PRO/1000 Network Driver -
>>>>>>> version
>>>>>>> 7.3.21-k8-NAPI
>>>>>>> [ 4.936887] e1000: Copyright (c) 1999-2006 Intel
>>>>>>> Corporation.
>>>>>>> [ 4.936966] e1000e: Intel(R) PRO/1000 Network Driver -
>>>>>>> 1.9.5-k
>>>>>>> [ 4.936967] e1000e: Copyright(c) 1999 - 2012 Intel
>>>>>>> Corporation.
>>>>>>> [ 4.938529] e1000e 0000:04:00.0: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 4.939598] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>>> [ 4.992246] e1000e 0000:04:00.0: eth0: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:f8
>>>>>>> [ 4.992657] e1000e 0000:04:00.0: eth0: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 4.992964] e1000e 0000:04:00.0: eth0: MAC: 5, PHY: 5, PBA
>>>>>>> No:
>>>>>>> FFFFFF-0FF
>>>>>>> [ 4.994745] e1000e 0000:04:00.1: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 4.996233] e1000e 0000:04:00.1: irq 66 for MSI/MSI-X
>>>>>>> [ 5.050901] e1000e 0000:04:00.1: eth1: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:f9
>>>>>>> [ 5.051317] e1000e 0000:04:00.1: eth1: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 5.051623] e1000e 0000:04:00.1: eth1: MAC: 5, PHY: 5, PBA
>>>>>>> No:
>>>>>>> FFFFFF-0FF
>>>>>>> [ 5.051857] e1000e 0000:0b:00.0: Disabling ASPM L1
>>>>>>> [ 5.052168] e1000e 0000:0b:00.0: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 5.052611] e1000e 0000:0b:00.0: irq 67 for MSI/MSI-X
>>>>>>> [ 5.223454] e1000e 0000:0b:00.0: eth2: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:fa
>>>>>>> [ 5.223864] e1000e 0000:0b:00.0: eth2: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 5.224178] e1000e 0000:0b:00.0: eth2: MAC: 0, PHY: 4, PBA
>>>>>>> No:
>>>>>>> C83246-002
>>>>>>> [ 5.224412] e1000e 0000:0b:00.1: Disabling ASPM L1
>>>>>>> [ 5.224709] e1000e 0000:0b:00.1: (unregistered net_device):
>>>>>>> Interrupt Throttling Rate (ints/sec) set to dynamic
>>>>>>> conservative mode
>>>>>>> [ 5.225168] e1000e 0000:0b:00.1: irq 68 for MSI/MSI-X
>>>>>>> [ 5.397603] e1000e 0000:0b:00.1: eth3: (PCI
>>>>>>> Express:2.5GT/s:Width
>>>>>>> x4) 00:1e:68:04:99:fb
>>>>>>> [ 5.398021] e1000e 0000:0b:00.1: eth3: Intel(R) PRO/1000
>>>>>>> Network
>>>>>>> Connection
>>>>>>> [ 5.398336] e1000e 0000:0b:00.1: eth3: MAC: 0, PHY: 4, PBA
>>>>>>> No:
>>>>>>> C83246-002
>>>>>>> [ 13.859817] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>>> [ 13.962309] e1000e 0000:04:00.0: irq 65 for MSI/MSI-X
>>>>>>> [ 17.150392] e1000e: eth0 NIC Link is Up 1000 Mbps Full
>>>>>>> Duplex,
>>>>>>> Flow Control: None
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>> netdev" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at
>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Network engineer
>>>>>> Denys Fedoryshchenko
>>>>>>
>>>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>>>> Beirut, Lebanon
>>>>>> Tel: +961 1 247373
>>>>>> E-Mail: denys@visp.net.lb
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at
>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>>
>>>>> ---
>>>>> Network engineer
>>>>> Denys Fedoryshchenko
>>>>>
>>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>>> Beirut, Lebanon
>>>>> Tel: +961 1 247373
>>>>> E-Mail: denys@visp.net.lb
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev"
>>>>> in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at
>>>>> http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> ---
>>>> Network engineer
>>>> Denys Fedoryshchenko
>>>>
>>>> Dora Highway - Center Cebaco - 2nd Floor
>>>> Beirut, Lebanon
>>>> Tel: +961 1 247373
>>>> E-Mail: denys@visp.net.lb
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>> ---
>> Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-20 19:07 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: e1000-devel, netdev, jesse.brandeburg, davem, Tom Herbert
In-Reply-To: <4775d023592b876909aceb152f94aa01@visp.net.lb>
On Sun, 2012-05-20 at 21:53 +0300, Denys Fedoryshchenko wrote:
> >
> My kernel config http://www.nuclearcat.com/config_stall.txt
>
> It is completely idle machine. I didn't notice any anomalies with
> interrutps to
> compare with other servers (not Sun Fire). If there is anomalies with
> interrupts
> (for example SMI), probably i should notice that even without BQL, but
> this machine
> works very well and i didn't notice any latency without BQL.
You could try latencytop, I am not sure if some obvious things will
popup.
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Denys Fedoryshchenko @ 2012-05-20 19:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: e1000-devel, netdev, jesse.brandeburg, davem, Tom Herbert
In-Reply-To: <1337540825.3361.0.camel@edumazet-glaptop>
On 2012-05-20 22:07, Eric Dumazet wrote:
>
> You could try latencytop, I am not sure if some obvious things will
> popup.
For sure i did. Nothing unusual here, max 5ms latency
Cause Maximum
Percentage
[__skb_recv_datagram] 4.1 msec
45.4 %
Waiting for event (select) 3.9 msec
54.6 %
Page fault 0.7 msec
0.0 %
Waiting for a process to die 0.3 msec
0.0 %
Writing data to TTY 0.1 msec
0.0 %
I will try also to find SMI interrupts detector (if i will find
source), but i don't think it is an issue.
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH v6] tilegx network driver: initial support
From: David Miller @ 2012-05-20 20:55 UTC (permalink / raw)
To: cmetcalf; +Cc: bhutchings, arnd, linux-kernel, netdev
In-Reply-To: <201205201636.q4KGaoA3003845@farm-0027.internal.tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Sun, 20 May 2012 00:42:03 -0400
> +static int tile_net_tx_tso(struct sk_buff *skb, struct net_device *dev)
This function has 80 lines of local variable declarations,
that's absolutely rediculous.
A comment and an empty line interspacing many of these local
variable declarations, also rediculous, and part of why it
is 80 lines long.
This function is completely unreadable, if I have to scan
multiple pages before I get to real code, the function is
broken.
You either need to compartmentalize these variable declarations
and/or write helper functions to spread it out.
This is some of the most unpleasant code I've had to review in quite
some time. Look at other networking drivers in the tree, such as
drivers/net/ethernet/broadcom/tg3.c, and try to mimick their style and
layout. Anything in your driver that is different is likely to get
you into trouble and make your driver hard to review.
^ permalink raw reply
* Re: [PATCH 1/3] USB: qmi_wwan: Make forced int 4 whitelist generic
From: David Miller @ 2012-05-20 20:59 UTC (permalink / raw)
To: ajb; +Cc: bjorn, gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-1-git-send-email-ajb@spheresystems.co.uk>
From: Andrew Bird <ajb@spheresystems.co.uk>
Date: Sun, 20 May 2012 09:28:36 +0100
> Change the forced interface 4 whitelist to use the generic shared
> binder instead of the Gobi specific one. Certain ZTE devices
> (K3520-Z & K3765-Z) don't work with the Gobi version, but function
> quite happily with the generic. This has been tested with the following
> devices:
> K3520-Z
> K3565-Z
> K3765-Z
> K4505-Z
> It hasn't been tested with the ZTE MF820D, which is the only other
> device that uses this whitelist at present. Although Bjorn doesn't
> expect any problems, any testing with that device would be appreciated.
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 2/3] USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z
From: David Miller @ 2012-05-20 20:59 UTC (permalink / raw)
To: ajb; +Cc: bjorn, gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-2-git-send-email-ajb@spheresystems.co.uk>
From: Andrew Bird <ajb@spheresystems.co.uk>
Date: Sun, 20 May 2012 09:28:37 +0100
> Add the ZTE (Vodafone) K3765-Z to the whitelist. This requires the
> previous patch to make the whitelist with forced interface 4 generic
> or the device fails to initialise. After applying this patch and
> loading the Option driver without usb-modeswitch's bind all
> interfaces trick, a wwan0 net interface and /dev/cdc-wdm0 device
> file were created. Using Bjorn Mork's perl connection script a
> connection was made to a mobile network using QMI and the network
> interface's IPv4 address was configured OK.
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] ipv6/exthdrs: strict Pad1 and PadN check
From: David Miller @ 2012-05-20 20:59 UTC (permalink / raw)
To: eldad; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1337515173-23648-1-git-send-email-eldad@fogrefinery.com>
From: Eldad Zack <eldad@fogrefinery.com>
Date: Sun, 20 May 2012 13:59:33 +0200
> The following tightens the padding check from commit
> c1412fce7eccae62b4de22494f6ab3ff8a90c0c6 :
>
> * Take into account combinations of consecutive Pad1 and PadN.
>
> * Catch the corner case of when only padding is present in the
> header, when the extention header length is 0 (i.e., 8 bytes).
> In this case, the header would have exactly 6 bytes of padding:
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> : Next Header : Hdr Ext Len=0 : :
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
> : Padding (Pad1 or PadN) :
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
Applied to net-next, thanks a lot.
^ permalink raw reply
* Re: [PATCH 2/3] USB: qmi_wwan: Add ZTE (Vodafone) K3765-Z
From: David Miller @ 2012-05-20 20:59 UTC (permalink / raw)
To: ajb; +Cc: bjorn, gregkh, linux-usb, netdev, linux-kernel
In-Reply-To: <1337502518-1444-2-git-send-email-ajb@spheresystems.co.uk>
From: Andrew Bird <ajb@spheresystems.co.uk>
Date: Sun, 20 May 2012 09:28:37 +0100
> Add the ZTE (Vodafone) K3765-Z to the whitelist. This requires the
> previous patch to make the whitelist with forced interface 4 generic
> or the device fails to initialise. After applying this patch and
> loading the Option driver without usb-modeswitch's bind all
> interfaces trick, a wwan0 net interface and /dev/cdc-wdm0 device
> file were created. Using Bjorn Mork's perl connection script a
> connection was made to a mobile network using QMI and the network
> interface's IPv4 address was configured OK.
>
> Signed-off-by: Andrew Bird <ajb@spheresystems.co.uk>
Applied to net-next.
^ permalink raw reply
* Re:
From: Mr. Peter Wong @ 2012-05-20 22:27 UTC (permalink / raw)
Good-Day Friend,
I Mr. Peter Wong, I Need Your Assistance
^ permalink raw reply
* [PATCH] drivers/net/stmmac: seq_file fix memory leak
From: Djalal Harouni @ 2012-05-20 23:55 UTC (permalink / raw)
To: Giuseppe Cavallaro; +Cc: netdev, David Miller
Use single_release() instead of seq_release() to free memory allocated
by single_open().
Signed-off-by: Djalal Harouni <tixxdz@opendz.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 48d56da..a27e46c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1584,7 +1584,7 @@ static const struct file_operations stmmac_rings_status_fops = {
.open = stmmac_sysfs_ring_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = single_release,
};
static int stmmac_sysfs_dma_cap_read(struct seq_file *seq, void *v)
@@ -1656,7 +1656,7 @@ static const struct file_operations stmmac_dma_cap_fops = {
.open = stmmac_sysfs_dma_cap_open,
.read = seq_read,
.llseek = seq_lseek,
- .release = seq_release,
+ .release = single_release,
};
static int stmmac_init_fs(struct net_device *dev)
--
1.7.1
^ permalink raw reply related
* [RFC/PATCH] Bluetooth: prevent double l2cap_chan_destroy
From: Minho Ban @ 2012-05-21 0:56 UTC (permalink / raw)
To: Gustavo Padovan
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, linux-bluetooth,
netdev, linux-kernel
l2cap_sock_kill can be called in l2cap_sock_release and l2cap_sock_close_cb
either. This lead l2cap_chan_destroy to be called twice for same channel.
To prevent double list_del and double chan_put, chan_destroy should be protected
with chan->refcnt and chan_list_lock so that reentrance could be forbidden.
Signed-off-by: Minho Ban <mhban@samsung.com>
---
net/bluetooth/l2cap_core.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 24f144b..156ca14 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -400,10 +400,14 @@ struct l2cap_chan *l2cap_chan_create(void)
void l2cap_chan_destroy(struct l2cap_chan *chan)
{
write_lock(&chan_list_lock);
+ /* Check if channel is valid */
+ if (!atomic_read(&chan->refcnt)) {
+ write_unlock(&chan_list_lock);
+ return;
+ }
list_del(&chan->global_l);
- write_unlock(&chan_list_lock);
-
l2cap_chan_put(chan);
+ write_unlock(&chan_list_lock);
}
void l2cap_chan_set_defaults(struct l2cap_chan *chan)
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox