* 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
* [PATCH] Bluetooth: Fix null pointer dereference in l2cap_chan_send
From: Minho Ban @ 2012-05-21 0:58 UTC (permalink / raw)
To: Gustavo Padovan
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, linux-bluetooth,
netdev, linux-kernel
If l2cap_chan_send is called will null conn it will cause kernel Oops.
This patch checks if conn is valid before entering l2cap_chan_send.
2871 [ 177.271861] Unable to handle kernel NULL pointer dereference at virtual address 00000010
2872 [ 177.271867] pgd = eadc0000
2873 [ 177.271870] [00000010] *pgd=6ad03831, *pte=00000000, *ppte=00000000
2874 [ 177.271884] Internal error: Oops: 17 [#1] PREEMPT SMP
2875 [ 177.271891] Modules linked in:
2876 [ 177.271900] CPU: 3 Not tainted (3.0.15-00019-g097836e #36)
2877 [ 177.271925] PC is at l2cap_chan_send+0x8c/0x6f8
2878 [ 177.271933] LR is at 0xc089d59c
2879 [ 177.271940] pc : [<c0531514>] lr : [<c089d59c>] psr: 80000013
2880 [ 177.271943] sp : ddda1d50 ip : 0000035c fp : ddda1dac
2881 [ 177.271948] r10: 0000035c r9 : 00000000 r8 : ddda1f3c
2882 [ 177.271954] r7 : ed67ec00 r6 : 00000006 r5 : ed67ec00 r4 : 00000003
2883 [ 177.271959] r3 : ddda1d7c r2 : 0000035c r1 : 00000000 r0 : ed67ec00
2884 [ 177.271967] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
2885 [ 177.271973] Control: 10c5387d Table: 6adc004a DAC: 00000015
~~~ snip ~~~~~
3000 [ 177.272989] Backtrace:
3001 [ 177.273001] [<c0531488>] (l2cap_chan_send+0x0/0x6f8) from [<c053700c>] (l2cap_sock_sendmsg+0xc0/0x15c)
3002 [ 177.273023] [<c0536f4c>] (l2cap_sock_sendmsg+0x0/0x15c) from [<c0458afc>] (sock_sendmsg+0xcc/0xd4)
3003 [ 177.273035] [<c0458a30>] (sock_sendmsg+0x0/0xd4) from [<c0459558>] (sys_sendto+0xb8/0xdc)
3004 [ 177.273041] r9:ddda0000 r8:00004040 r7:00000000 r6:ebdf9d40 r5:0004fb00
3005 [ 177.273050] r4:0000035c
3006 [ 177.273059] [<c04594a0>] (sys_sendto+0x0/0xdc) from [<c045959c>] (sys_send+0x20/0x28)
3007 [ 177.273077] [<c045957c>] (sys_send+0x0/0x28) from [<c00431c0>] (ret_fast_syscall+0x0/0x30)
3008 [ 177.273087] Code: e5901004 e24b3030 e51ba050 e590e21c (e5914010)
3009 [ 177.273096] ---[ end trace 29a418305c9cffba ]---
Signed-off-by: Minho Ban <mhban@samsung.com>
---
net/bluetooth/l2cap_sock.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 3bb1611..98d4541 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -727,10 +727,12 @@ static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct ms
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;
- if (sk->sk_state != BT_CONNECTED)
+ l2cap_chan_lock(chan);
+ if (sk->sk_state != BT_CONNECTED || !chan->conn) {
+ l2cap_chan_unlock(chan);
return -ENOTCONN;
+ }
- l2cap_chan_lock(chan);
err = l2cap_chan_send(chan, msg, len, sk->sk_priority);
l2cap_chan_unlock(chan);
--
1.7.5.4
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the tree
From: Stephen Rothwell @ 2012-05-21 2:27 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Parav Pandit, Roland Dreier, linux-rdma,
Somnath Kotur, Somnath Kotur
[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit c72adfd767af
("be2net: Add functionality to support RoCE driver") from the infiniband
tree and commit 941a77d582c8 ("be2net: Fix to allow get/set of debug
levels in the firmware") from the net-next tree.
Just context changes. I fixed it up (see below) and carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/emulex/benet/be.h
index 7bb2e97,ff4eb8f..0000000
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -32,9 -32,8 +32,9 @@@
#include <linux/u64_stats_sync.h>
#include "be_hw.h"
+#include "be_roce.h"
- #define DRV_VER "4.2.116u"
+ #define DRV_VER "4.2.220u"
#define DRV_NAME "be2net"
#define BE_NAME "ServerEngines BladeEngine2 10Gbps NIC"
#define BE3_NAME "ServerEngines BladeEngine3 10Gbps NIC"
@@@ -379,22 -404,7 +406,18 @@@ struct be_adapter
u32 rx_fc; /* Rx flow control */
u32 tx_fc; /* Tx flow control */
bool stats_cmd_sent;
- int link_speed;
- u8 port_type;
- u8 transceiver;
- u8 autoneg;
u8 generation; /* BladeEngine ASIC generation */
+ u32 if_type;
+ struct {
+ u8 __iomem *base; /* Door Bell */
+ u32 size;
+ u32 total_size;
+ u64 io_addr;
+ } roce_db;
+ u32 num_msix_roce_vec;
+ struct ocrdma_dev *ocrdma_dev;
+ struct list_head entry;
+
u32 flash_status;
struct completion flash_compl;
@@@ -606,17 -603,7 +626,19 @@@ extern void be_link_status_update(struc
extern void be_parse_stats(struct be_adapter *adapter);
extern int be_load_fw(struct be_adapter *adapter, u8 *func);
extern bool be_is_wol_supported(struct be_adapter *adapter);
+ extern bool be_pause_supported(struct be_adapter *adapter);
+ extern u32 be_get_fw_log_level(struct be_adapter *adapter);
+/*
+ * internal function to initialize-cleanup roce device.
+ */
+extern void be_roce_dev_add(struct be_adapter *);
+extern void be_roce_dev_remove(struct be_adapter *);
+
+/*
+ * internal function to open-close roce device during ifup-ifdown.
+ */
+extern void be_roce_dev_open(struct be_adapter *);
+extern void be_roce_dev_close(struct be_adapter *);
+
#endif /* BE_H */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-05-21 3:56 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Tom Herbert, netdev, e1000-devel, jeffrey.t.kirsher,
jesse.brandeburg, davem
In-Reply-To: <ef780bd0e0b9b9e60e37fa74101f0f66@visp.net.lb>
On Sun, 2012-05-20 at 22:18 +0300, Denys Fedoryshchenko wrote:
> 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
Interesting
So your workload is a mix of pings, and receive.
Problem is softirq handler might use a lot of time to complete the
receives, because of TCP stack complexity. And BQL use softirq to
restart the transmits on the same cpu.
tcp_data_queue() can copy the received data directly to user space.
(taking page faults...)
Could you check if net-next behaves the same ?
^ permalink raw reply
* Network driver git tree
From: Kevin Wilson @ 2012-05-21 4:34 UTC (permalink / raw)
To: netdev
Hi,
In the past there was a git tree of Jeff Garzik for the network
drivers; once in a while
the net-next git tree pulled code from this tree. My short question
is: currently, is
a new, fresh network driver sent directly to net-next ? or is there
some git tree similar to
Jeff Garzik git tree (or maybe it does still exist)?
regards,
Kevin
^ permalink raw reply
* Re: Network driver git tree
From: David Miller @ 2012-05-21 4:40 UTC (permalink / raw)
To: wkevils; +Cc: netdev
In-Reply-To: <CAGXs5wX3VAWNsV49Eg_Nznhbsuo4t=4b5h6_KrgPzPZ0=Qp4og@mail.gmail.com>
From: Kevin Wilson <wkevils@gmail.com>
Date: Mon, 21 May 2012 07:34:52 +0300
> In the past there was a git tree of Jeff Garzik for the network
> drivers; once in a while the net-next git tree pulled code from this
> tree. My short question is: currently, is a new, fresh network
> driver sent directly to net-next ? or is there some git tree similar
> to Jeff Garzik git tree (or maybe it does still exist)?
Jeff's tree hasn't existed in years.
All networking changes are sent to the net-next tree directly.
^ permalink raw reply
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Jason Wang @ 2012-05-21 5:22 UTC (permalink / raw)
To: Shirley Ma
Cc: Michael S. Tsirkin, eric.dumazet, netdev, linux-kernel, ebiederm,
davem
In-Reply-To: <1337195303.10741.37.camel@oc3660625478.ibm.com>
On 05/17/2012 03:08 AM, Shirley Ma wrote:
> On Wed, 2012-05-16 at 21:36 +0300, Michael S. Tsirkin wrote:
>> On Wed, May 16, 2012 at 10:32:05AM -0700, Shirley Ma wrote:
>>> On Wed, 2012-05-16 at 18:14 +0300, Michael S. Tsirkin wrote:
>>>> On Wed, May 16, 2012 at 08:10:27AM -0700, Shirley Ma wrote:
>>>>> On Wed, 2012-05-16 at 10:58 +0800, Jason Wang wrote:
>>>>>>>> drivers/vhost/vhost.c | 1 +
>>>>>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
>>>>>>>> index 947f00d..7b75fdf 100644
>>>>>>>> --- a/drivers/vhost/vhost.c
>>>>>>>> +++ b/drivers/vhost/vhost.c
>>>>>>>> @@ -1604,6 +1604,7 @@ void vhost_zerocopy_callback(void
>> *arg)
>>>>>>>> struct vhost_ubuf_ref *ubufs = ubuf->arg;
>>>>>>>> struct vhost_virtqueue *vq = ubufs->vq;
>>>>>>>>
>>>>>>>> + vhost_poll_queue(&vq->poll);
>>>>>>>> /* set len = 1 to mark this desc buffers done DMA
>> */
>>>>>>>> vq->heads[ubuf->desc].len = VHOST_DMA_DONE_LEN;
>>>>>>>> kref_put(&ubufs->kref,
>> vhost_zerocopy_done_signal);
>>>>>>> Doing so, we might have redundant vhost_poll_queue(). Do you
>>>> know in
>>>>>>> which scenario there might be missing of adding and
>> signaling
>>>> during
>>>>>>> zerocopy?
>>>>>> Yes, as we only do signaling and adding during tx work, if
>> there's
>>>> no
>>>>>> tx
>>>>>> work when the skb were sent, we may lose the opportunity to
>> let
>>>> guest
>>>>>> know about the completion. It's easy to be reproduced with
>> netperf
>>>>>> test.
>>>>> The reason which host signals guest is to free guest tx buffers,
>> if
>>>>> there is no tx work, then it's not necessary to signal the guest
>>>> unless
>>>>> guest runs out of memory. The pending buffers will be released
>>>>> virtio_net device gone.
>>>>>
>>>>> What's the behavior of netperf test when you hit this situation?
>>>>>
>>>>> Thanks
>>>>> Shirley
>>>> IIRC guest networking seems to be lost.
>>> It seems vhost_enable_notify is missing in somewhere else?
>>>
>>> Thanks
>>> Shirley
>> Donnu. I see virtio sending packets but they do not get
>> to tun on host. debugging.
> I looked at the code, if (zerocopy) check is needed for below code:
>
> + if (zerocopy) {
> num_pends = likely(vq->upend_idx>= vq->done_idx) ?
> (vq->upend_idx - vq->done_idx) :
> (vq->upend_idx + UIO_MAXIOV - vq->done_idx);
> if (unlikely(num_pends> VHOST_MAX_PEND)) {
> tx_poll_start(net, sock);
> vhost_poll_queue
> set_bit(SOCK_ASYNC_NOSPACE,&sock->flags);
> break;
> }
> + }
> if (unlikely(vhost_enable_notify(&net->dev, vq))) {
> vhost_disable_notify(&net->dev, vq);
> continue;
> }
> break;
No objection to add this but looks no difference to me as we won't touch
upend_idx and done_idx when zercocopy is not used.
>
> Second, whether it's possible the problem comes from tx_poll_start()? In
> some situation, vhost_poll_wakeup() is not being called?
>
> Thanks
> Shirley
>
>
>
> --
> 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
^ permalink raw reply
* Re: [PATCH net-next 3/3] ipv6: use skb coalescing in reassembly
From: Eric Dumazet @ 2012-05-21 5:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, alexander.h.duyck
In-Reply-To: <20120519.183556.1085711138074171029.davem@davemloft.net>
On Sat, 2012-05-19 at 18:35 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Sat, 19 May 2012 15:02:35 +0200
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > ip6_frag_reasm() can use skb_try_coalesce() to build optimized skb,
> > reducing memory used by them (truesize), and reducing number of cache
> > line misses and overhead for the consumer.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Alexander Duyck <alexander.h.duyck@intel.com>
>
> Applied.
I'll do the same for net/ipv6/netfilter/nf_conntrack_reasm.c today.
Thanks
^ permalink raw reply
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Jason Wang @ 2012-05-21 6:05 UTC (permalink / raw)
To: Shirley Ma
Cc: Michael S. Tsirkin, eric.dumazet, netdev, linux-kernel, ebiederm,
davem
In-Reply-To: <1337354974.12999.12.camel@oc3660625478.ibm.com>
On 05/18/2012 11:29 PM, Shirley Ma wrote:
> On Fri, 2012-05-18 at 17:58 +0800, Jason Wang wrote:
>> On 05/17/2012 11:34 PM, Shirley Ma wrote:
>>> On Thu, 2012-05-17 at 10:50 +0800, Jason Wang wrote:
>>>> The problem is we may stop the tx queue when there no enough
>> capacity
>>>> to
>>>> place packets, at this moment we depends on the tx interrupt to
>>>> re-enable the tx queue. So if we didn't poll the vhost during
>>>> callback,
>>>> guest may lose the tx interrupt to re-enable the tx queue which
>> could
>>>> stall the whole tx queue.
>>> VHOST_MAX_PEND should handle the capacity.
>>>
>>> Hasn't the above situation been handled in handle_tx() code?:
>>> ...
>>> if (unlikely(num_pends> VHOST_MAX_PEND)) {
>>> tx_poll_start(net, sock);
>>>
>> set_bit(SOCK_ASYNC_NOSPACE,&sock->flags);
>>> break;
>>> }
>>> ...
>>>
>>> Thanks
>>> Shirley
>> It may not help in because:
>>
>> - tx polling depends on skb_orphan() which is often called by device
>> driver when it place the packet into the queue of the devices instead
>> of when the packets were sent. So it was too early for vhost to be
>> notified.
> Then do you think it's better to replace with vhost_poll_queue here
> instead?
Just like what does this patch do - calling vhost_poll_queue() in
vhost_zerocopy_callback().
>> - it only works when the pending DMAs exceeds VHOST_MAX_PEND, it's
>> highly possible that guest needs to be notified when the pending
>> packets
>> isn't so much.
> In which situation the guest needs to be notified when there is no TX
> besides buffers run out?
Consider guest call virtqueue_enable_cb_delayed() which means it only
need to be notified when 3/4 of pending buffers ( about 178 buffers
(256-MAX_SKB_FRAGS-2)*3/4 ) were sent by host. So vhost_net would notify
guest when about 60 buffers were pending. Since tx polling is only
enabled when pending packets exceeds VHOST_MAX_PEND 128, so tx work
would not be notified to run and guest would never get the interrupt it
expected to re-enable the queue.
And just like what we've discussed, tx polling based adding and
signaling is too early for vhost.
>> So this piece of code may not help and could be removed and we need
>> to
>> poll the virt-queue during zerocopy callback ( through it could be
>> further optimized but may not be easy).
> Thanks
> Shirley
>
> --
> 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
^ permalink raw reply
* [PATCH 3/3] TIPC: Stepping TIPC version to 2.1.0
From: Jon Maloy @ 2012-05-21 5:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, tipc-discussion, ying.xue, erik.hugne, allan.stephens,
maloy, Jon Maloy
In-Reply-To: <1337579954-17161-1-git-send-email-jon.maloy@ericsson.com>
Catch-up with out-of-tree version is done. We can go ahead
with more development.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/core.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/tipc/core.h b/net/tipc/core.h
index 2a9bb99..3ab29bf 100644
--- a/net/tipc/core.h
+++ b/net/tipc/core.h
@@ -1,7 +1,7 @@
/*
* net/tipc/core.h: Include file for TIPC global declarations
*
- * Copyright (c) 2005-2006, Ericsson AB
+ * Copyright (c) 2005-2006, 2012, Ericsson AB
* Copyright (c) 2005-2007, 2010-2011, Wind River Systems
* All rights reserved.
*
@@ -56,7 +56,7 @@
#include <linux/vmalloc.h>
-#define TIPC_MOD_VER "2.0.0"
+#define TIPC_MOD_VER "2.1.0"
struct tipc_msg; /* msg.h */
struct print_buf; /* log.h */
--
1.7.9.5
^ 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