* RE: TCP performance regression
From: Eric Dumazet @ 2013-11-11 17:41 UTC (permalink / raw)
To: David Laight; +Cc: Sujith Manoharan, netdev, Dave Taht
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73FD@saturn3.aculab.com>
On Mon, 2013-11-11 at 16:35 +0000, David Laight wrote:
> > > It should be ok if the mac driver only gives the hardware a small
> > > number of bytes/packets - or one appropriate for the link speed.
> >
> > There is some confusion here.
> >
> > mvneta has a TX ring buffer, which can hold up to 532 TX descriptors.
> >
> > If this driver used skb_orphan(), a single TCP flow could use the whole
> > TX ring.
> >
> > TCP Small Queue would only limit the number of skbs on Qdisc.
> >
> > Try then to send a ping message, it will have to wait a lot.
>
> 532 is a ridiculously large number especially for a slow interface.
> At a guess you don't want more than 10-20ms of data in the tx ring.
> You might need extra descriptors for badly fragmented packets.
Thats why we invented BQL.
Problem is most driver authors don't care of the problem.
They already have hard time to make bug free drivers.
BQL is adding pressure and expose long standing bugs.
Some drivers have large TX rings to lower race probabilities.
^ permalink raw reply
* Re: TCP performance regression
From: Felix Fietkau @ 2013-11-11 17:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sujith Manoharan, netdev, Dave Taht
In-Reply-To: <1384191515.16391.49.camel@edumazet-glaptop2.roam.corp.google.com>
On 2013-11-11 18:38, Eric Dumazet wrote:
> On Mon, 2013-11-11 at 17:38 +0100, Felix Fietkau wrote:
>> I don't think this issue is about something as simple as timer handling
>> for tx completion (or even broken/buggy drivers).
>>
>> There's simply no way to make 802.11 aggregation work well and have
>> similar tx completion latency characteristics as Ethernet devices.
>>
>> 802.11 aggregation reduces the per-packet airtime overhead by combining
>> multiple packets into one transmission (saving a lot of time getting a
>> tx opportunity, transmitting the PHY header, etc.), which makes the
>> 'line rate' heavily depend on the amount of buffering.
>
> How long a TX packet is put on hold hoping a following packet will
> come ?
TX packets in the aggregation queue are held as long as the hardware
queue holds two A-MPDUs (each of which can contain up to 32 packets).
If the aggregation queues are empty and the hardware queue is not full,
the next tx packet from the network stack is pushed to the hardware
queue immediately.
- Felix
^ permalink raw reply
* Re: TCP performance regression
From: Dave Taht @ 2013-11-11 18:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Felix Fietkau, Sujith Manoharan, netdev@vger.kernel.org
In-Reply-To: <1384191515.16391.49.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Nov 11, 2013 at 9:38 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2013-11-11 at 17:38 +0100, Felix Fietkau wrote:
>> On 2013-11-11 17:13, Sujith Manoharan wrote:
>> > Eric Dumazet wrote:
>> >> We have many choices.
>> >>
>> >> 1) Add back a minimum of ~128 K of outstanding bytes per TCP session,
>> >> so that buggy drivers can sustain 'line rate'.
>> >>
>> >> Note that with 100 concurrent TCP streams, total amount of bytes
>> >> queued on the NIC is 12 MB.
>> >> And pfifo_fast qdisc will drop packets anyway.
>> >>
>> >> Thats what we call 'BufferBloat'
>> >>
>> >> 2) Try lower values like 64K. Still bufferbloat.
>> >>
>> >> 3) Fix buggy drivers, using a proper logic, or shorter timers (mvneta
>> >> case for example)
>> >>
>> >> 4) Add a new netdev attribute, so that well behaving NIC drivers do not
>> >> have to artificially force TCP stack to queue too many bytes in
>> >> Qdisc/NIC queues.
>> >
>> > I think the quirks of 802.11 aggregation should be taken into account.
>> > I am adding Felix to this thread, who would have more to say on latency/bufferbloat
>> > with wireless drivers.
As I just got dropped in the middle of this convo, I tend to think
that the mac80211 questions is should be handled in it's own thread as
this conversation seemed to be about a certain ethernet driver's
flaws.
>> I don't think this issue is about something as simple as timer handling
>> for tx completion (or even broken/buggy drivers).
>>
>> There's simply no way to make 802.11 aggregation work well and have
>> similar tx completion latency characteristics as Ethernet devices.
I don't quite share all of felix's pessimism. It will tend to be
burstier, yes, but I felt that would not look that much different than
napi -> BQL.
>> 802.11 aggregation reduces the per-packet airtime overhead by combining
>> multiple packets into one transmission (saving a lot of time getting a
>> tx opportunity, transmitting the PHY header, etc.), which makes the
>> 'line rate' heavily depend on the amount of buffering.
making aggregation work well is key to fixing wifi worldwide.
Presently aggregation performance is pretty universally terrible under
real loads and tcp.
(looking further ahead, getting multi-user mimo to work in 802.11ac
would also be helpful but I'm not even sure the IEEE figured that out
yet. Ath10k hw2 do it?)
> How long a TX packet is put on hold hoping a following packet will
> come ?
>
>
>
>> Aggregating multiple packets into one transmission also causes extra
>> packet loss, which is compensated by retransmission and reordering, thus
>> introducing additional latency.
I was extremely encouraged by Yucheng's presentation at ietf on some
vast improvements on managing re-ordering problems. I daydreamed that
it would become possible to eliminate the reorder buffer in lower
levels of the wireless stack(s?).
See slides and fantasize:
http://www.ietf.org/proceedings/88/slides/slides-88-iccrg-6.pdf
The rest of the preso was good, too.
I also thought the new pacing stuff would cause trouble in wifi and aggregation.
>> I don't think that TSQ can do a decent job of mitigating bufferbloat on
>> 802.11n devices without a significant performance hit, so adding a new
>> netdev attribute might be a good idea.
I am not sure which part of what subsystem(s) is really under debate
here. TSQ limits the number of packets that can be outstanding in a
stream. The characteristics of a wifi connection (EDCA scheduling and
aggregated batching) play merry hell with TCP assumptions. The recent
work on fixing TSO offloads shows what can happen if that underlying
set of assumptions is fixed.
My overall take on this, tho, is to take the latest bits of TSQ and
"fq" code, and go measure the effect on wifi stations rather than
discuss what layer is busted or what options need to be added to
netdev. Has anyone done that? I've been busy with 3.10.x
Personally I don't have much of a problem if TSQ hurts single stream
TCP throughput on wifi. I would vastly prefer aggregation to work
better for multiple streams with vastly smaller buffers than it does.
That would be a bigger win, overall.
> The netdev attribute would work, but might not work well if using a
> tunnel...
I am going to make some coffee and catch up. Please excuse whatever
noise I just introduced.
>
>
>
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
^ permalink raw reply
* Re: [PATCH v2] mac80211: add assoc beacon timeout logic
From: Felipe Contreras @ 2013-11-11 18:06 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless Mailing List, netdev, John W. Linville,
David S. Miller
In-Reply-To: <1384189227.14334.48.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>
On Mon, Nov 11, 2013 at 11:00 AM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Mon, 2013-11-11 at 10:53 -0600, Felipe Contreras wrote:
>> > Like I said before - trying to work with an AP without beacons at all is
>> > really bad, we shouldn't be doing it.
>>
>> Why not? For all intents and purposes my system is not receiving any
>> beacons, and I don't see any problems.
>
> The not receiving part is a bug. I think you're probably receiving
> beacons once associated though?
Nope. Never.
>> What would you prefer? That nothing works at all?
>
> Yes, that'd be much safer.
How exactly?
>> > We might not properly react to
>> > radar events, and other things, for example.
>>
>> So? I don't know what that means, but it can't be worst than not being
>> able to connect to the Internet whatsoever at all.
>
> It can make you break the law.
How?
I'm reading this document[1], and if that's what you are referring to,
then for starters it only applies to the master mode, my patch changes
the behavior only on station mode.
Moreover, if continuing the association without beacons has a legal a
problem, that problem would exist for drivers that don't have the
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC flag, wouldn't it? How exactly
would trying to associate with need_beacon break the law, but not if
!need_beacon?
[1] http://wireless.kernel.org/en/developers/DFS
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: TCP performance regression
From: Dave Taht @ 2013-11-11 18:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Felix Fietkau, Sujith Manoharan, netdev@vger.kernel.org,
Avery Pennarun
In-Reply-To: <CAA93jw56T32c7NN6Ttnbda6v5mciQhdhD50nC_SoXW8nFti+8g@mail.gmail.com>
Ah, this thread started with a huge regression in ath10k performance
with the new TSQ stuff, and isn't actually about a two line fix to the
mv ethernet driver.
http://comments.gmane.org/gmane.linux.network/290269
I suddenly care a lot more. And I'll care a lot, lot, lot more, if
someone can post a rrul test for before and after the new fq scheduler
and tsq change on this driver on this hardware... What, if anything,
in terms of improvements or regressions, happened to multi-stream
throughput and latency?
https://github.com/tohojo/netperf-wrapper
^ permalink raw reply
* Re: TCP performance regression
From: Sujith Manoharan @ 2013-11-11 18:29 UTC (permalink / raw)
To: Dave Taht; +Cc: Eric Dumazet, Felix Fietkau, netdev@vger.kernel.org
In-Reply-To: <CAA93jw56T32c7NN6Ttnbda6v5mciQhdhD50nC_SoXW8nFti+8g@mail.gmail.com>
Dave Taht wrote:
> Personally I don't have much of a problem if TSQ hurts single stream
> TCP throughput on wifi. I would vastly prefer aggregation to work
> better for multiple streams with vastly smaller buffers than it does.
> That would be a bigger win, overall.
ath9k doesn't hold very deep queues for aggregated traffic. A maximum
of 128 packets can be buffered for each Access Class queue and still
good throughput is obtained, even for 3x3 scenarios.
A loss of almost 50% throughput is seen in 1x1 setups and the penalty
becomes higher with more streams. I don't think such a big loss
in performance is acceptable to achieve low latency.
Sujith
^ permalink raw reply
* Re: [patch net-next RFC 0/2] ipv6: allow temporary address management for user-created addresses
From: David Miller @ 2013-11-11 18:42 UTC (permalink / raw)
To: jiri
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, thaller, stephen,
hannes, vyasevich, dcbw
In-Reply-To: <1384181359-23199-1-git-send-email-jiri@resnulli.us>
I'm not really going to read patches not properly at least CC:'d to
netdev, sorry Jiri.
^ permalink raw reply
* gso: Handle new frag_list of frags GRO packets
From: Herbert Xu @ 2013-11-11 18:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107070647.GB31638@gondor.apana.org.au>
Recently GRO started generating packets with frag_lists of frags.
This was not handled by GSO, thus leading to a crash.
Thankfully these packets are of a regular form and are easy to
handle. This patch handles them in two ways. For completely
non-linear frag_list entries, we simply continue to iterate over
the frag_list frags once we exhaust the normal frags. For frag_list
entries with linear parts, we call pskb_trim on the first part
of the frag_list skb, and then process the rest of the frags in
the usual way.
This patch also kills a chunk of dead frag_list code that has
obviously never ever been run since it ends up generating a bogus
GSO-segmented packet with a frag_list entry.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3735fad..557e1a5 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2776,6 +2776,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
struct sk_buff *segs = NULL;
struct sk_buff *tail = NULL;
struct sk_buff *fskb = skb_shinfo(skb)->frag_list;
+ skb_frag_t *skb_frag = skb_shinfo(skb)->frags;
unsigned int mss = skb_shinfo(skb)->gso_size;
unsigned int doffset = skb->data - skb_mac_header(skb);
unsigned int offset = doffset;
@@ -2815,16 +2816,38 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (hsize > len || !sg)
hsize = len;
- if (!hsize && i >= nfrags) {
- BUG_ON(fskb->len != len);
+ if (!hsize && i >= nfrags && skb_headlen(fskb) &&
+ (skb_headlen(fskb) == len || sg)) {
+ BUG_ON(skb_headlen(fskb) > len);
+
+ i = 0;
+ nfrags = skb_shinfo(fskb)->nr_frags;
+ skb_frag = skb_shinfo(fskb)->frags;
+ pos += skb_headlen(fskb);
+
+ while (pos < offset + len) {
+ BUG_ON(i >= nfrags);
+
+ size = skb_frag_size(skb_frag);
+ if (pos + size > offset + len)
+ break;
+
+ i++;
+ pos += size;
+ skb_frag++;
+ }
- pos += len;
nskb = skb_clone(fskb, GFP_ATOMIC);
fskb = fskb->next;
if (unlikely(!nskb))
goto err;
+ if (unlikely(pskb_trim(nskb, len))) {
+ kfree_skb(nskb);
+ goto err;
+ }
+
hsize = skb_end_offset(nskb);
if (skb_cow_head(nskb, doffset + headroom)) {
kfree_skb(nskb);
@@ -2861,7 +2884,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
nskb->data - tnl_hlen,
doffset + tnl_hlen);
- if (fskb != skb_shinfo(skb)->frag_list)
+ if (nskb->len == len + doffset)
goto perform_csum_check;
if (!sg) {
@@ -2879,8 +2902,28 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_shinfo(nskb)->tx_flags = skb_shinfo(skb)->tx_flags & SKBTX_SHARED_FRAG;
- while (pos < offset + len && i < nfrags) {
- *frag = skb_shinfo(skb)->frags[i];
+ while (pos < offset + len) {
+ if (i >= nfrags) {
+ BUG_ON(skb_headlen(fskb));
+
+ i = 0;
+ nfrags = skb_shinfo(fskb)->nr_frags;
+ skb_frag = skb_shinfo(fskb)->frags;
+
+ BUG_ON(!nfrags);
+
+ fskb = fskb->next;
+ }
+
+ if (unlikely(skb_shinfo(nskb)->nr_frags >=
+ MAX_SKB_FRAGS)) {
+ net_warn_ratelimited(
+ "skb_segment: too many frags: %u %u\n",
+ pos, mss);
+ goto err;
+ }
+
+ *frag = *skb_frag;
__skb_frag_ref(frag);
size = skb_frag_size(frag);
@@ -2893,6 +2936,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (pos + size <= offset + len) {
i++;
+ skb_frag++;
pos += size;
} else {
skb_frag_size_sub(frag, pos + size - (offset + len));
@@ -2902,25 +2946,6 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
frag++;
}
- if (pos < offset + len) {
- struct sk_buff *fskb2 = fskb;
-
- BUG_ON(pos + fskb->len != offset + len);
-
- pos += fskb->len;
- fskb = fskb->next;
-
- if (fskb2->next) {
- fskb2 = skb_clone(fskb2, GFP_ATOMIC);
- if (!fskb2)
- goto err;
- } else
- skb_get(fskb2);
-
- SKB_FRAG_ASSERT(nskb);
- skb_shinfo(nskb)->frag_list = fskb2;
- }
-
skip_fraglist:
nskb->data_len = len - hsize;
nskb->len += nskb->data_len;
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH net-next] xfrm: check function pointer of xfrm_mgr before use it
From: Stephen Hemminger @ 2013-11-11 18:52 UTC (permalink / raw)
To: baker.kernel; +Cc: herbert, davem, steffen.klassert, netdev
In-Reply-To: <1384093556-8987-1-git-send-email-baker.kernel@gmail.com>
On Sun, 10 Nov 2013 22:25:56 +0800
baker.kernel@gmail.com wrote:
> For current kernel source, there is no problem.
>
> In our vpn product, we need a xfrm_km in kernel module
> to monitor the xfrm state change.
> thus, the 'acquire' and 'compile_policy' may be NULL.
>
> So I think we should do the check before use it
The upstream kernel does not accept or make changes to accommodate code that
is not part of the kernel source.
The only way this change would be considered would be as part of a submission
of the kernel module. I.e. part 1 of N.
So if you are willing to submit your module upstream under GPLv2, then
it will be reviewed an possibly accepted. If you just want this change to
make your product easier, then sorry no.
^ permalink raw reply
* Re: BCM5720 transmit queue 1 timed out
From: Nithin Nayak Sujir @ 2013-11-11 18:52 UTC (permalink / raw)
To: Atif Faheem, netdev@vger.kernel.org
In-Reply-To: <59CC998F-C7A6-4879-9BD0-2B9800FE6164@btisystems.com>
On 11/08/2013 09:24 PM, Atif Faheem wrote:
> Hi. I need some help with transmit Q timeouts on the 5720. We are using Linux kernel 3.4.34, with channel bonding on 5720 on embedded. Occasionally immediately after a reboot or a power cycle we get a lockup on the 5720, which looks like given below; the problem seems to happen on some 5720’s more often. Recently there has been a lot of discussion on this issue on the list and based on that I have incorporated the following 2 patches from upstream into the driver, but the problem still continues to happen.
>
Hi Atif,
The symptom you're describing matches the fixes that went in for the DMA workaround.
> -- After Power-on-reset, the 5719's TX DMA length registers may contain
> uninitialized values and cause TX DMA to stall. Check for invalid
> values and set a register bit to flush the TX channels. The bit
> needs to be turned off after the DMA channels have been flushed.
>
> -- There was a subsequent fix (06/13) that applies the patch above to the 5720. Commit 091f0ea30074bc43f9250961b3247af713024bc6.
>
This commit id is for the 5719 fix. The 5720 fix is
9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8.
> Is there anything else that might be missing from 3.4.34 as far as the transmit lockups are concerned? Any ideas will be great.
>
No, these two patches should fix the issue. Are you certain both patches are
applied and being used? Also, would you mind trying the latest stable 3.11.x kernel?
Please make sure to *power cycle* the system after a previous timeout. A reboot
may not be enough once the hardware is already in a bad state for this issue.
Pull the plug and power down and wait a few seconds before powering on.
Thanks,
Nithin.
> Thanks.
> Atif Faheem
> BTI Systems
> net
>
> ------------[ cut here ]------------
> WARNING: at /home/jenkins/jobs/r102-os/workspace/opt/os/wrlinux/builds/atom64/bitbake_build/tmp/work/intel_atom_64-wrs-linux/linux-windriver-3.4-r0/linux/net/sched/sch_generic.c:256 dev_watchdog+0x277/0x280()
> Hardware name: To be filled by O.E.M.
> NETDEV WATCHDOG: eth1 (tg3): transmit queue 1 timed out
> Modules linked in: firmware_class libphy tg3 bonding
> Pid: 0, comm: swapper/0 Not tainted 3.4.34-WR5.0.1.3_standard #1
> Call Trace:
> <IRQ> [<ffffffff81030c84>] warn_slowpath_common+0x84/0xc0
> [<ffffffff81030d77>] warn_slowpath_fmt+0x47/0x50
> [<ffffffff816799f7>] dev_watchdog+0x277/0x280
> [<ffffffff81040784>] run_timer_softirq+0x134/0x420
> [<ffffffff8134f5ee>] ? timerqueue_add+0x6e/0xc0
> [<ffffffff81679780>] ? qdisc_reset+0x50/0x50
> [<ffffffff8103811d>] __do_softirq+0xbd/0x280
> [<ffffffff81079375>] ? clockevents_program_event+0x75/0xf0
> [<ffffffff8107a7b4>] ? tick_program_event+0x24/0x30
> [<ffffffff81777b8c>] call_softirq+0x1c/0x30
> [<ffffffff810037b5>] do_softirq+0x55/0x90
> [<ffffffff810385ee>] irq_exit+0x8e/0xb0
> [<ffffffff817781e9>] smp_apic_timer_interrupt+0x99/0x1cd
> [<ffffffff817773c7>] apic_timer_interrupt+0x67/0x70
> <EOI> [<ffffffff813c2689>] ? acpi_idle_enter_bm+0x240/0x281
> [<ffffffff813c2684>] ? acpi_idle_enter_bm+0x23b/0x281
> [<ffffffff815cc58f>] ? menu_select+0xff/0x3c0
> [<ffffffff815ca8d8>] cpuidle_enter+0x18/0x20
> [<ffffffff815caf59>] cpuidle_idle_call+0xc9/0x3b0
> [<ffffffff8100b59f>] cpu_idle+0x7f/0xd0
> [<ffffffff8174b3a7>] rest_init+0x7b/0x84
> [<ffffffff81cd3b76>] start_kernel+0x35b/0x369
> [<ffffffff81cd3616>] ? repair_env_string+0x5a/0x5a
> [<ffffffff81cd3321>] x86_64_start_reservations+0x131/0x135
> [<ffffffff81cd3416>] x86_64_start_kernel+0xf1/0xf9
> ---[ end trace b625d70ff7be1bd7 ]—
> kernel: tg3 0000:03:00.1: eth1: transmit timed out, resetting
> kernel: tg3 0000:03:00.1: eth1: 0x00000000: 0x165f14e4, 0x00100406, 0x02000000, 0x00800010
> kernel: tg3 0000:03:00.1: eth1: 0x00000010: 0xbc14000c, 0x00000000, 0xbc13000c, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000020: 0xbc12000c, 0x00000000, 0x00000000, 0x165f14e4
> kernel: tg3 0000:03:00.1: eth1: 0x00000030: 0x00000000, 0x00000048, 0x00000000, 0x0000020b
> kernel: tg3 0000:03:00.1: eth1: 0x00000040: 0x00000000, 0x03000000, 0xc8035001, 0x64002008
> kernel: tg3 0000:03:00.1: eth1: 0x00000050: 0x00005803, 0x00000000, 0x0086a005, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000060: 0x00000000, 0x00000000, 0xf0000298, 0x00380081
> kernel: tg3 0000:03:00.1: eth1: 0x00000070: 0x00071090, 0xffffe0ff, 0x00000438, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000080: 0x0000024c, 0x40000040, 0x00000000, 0x0000000c
> kernel: tg3 0000:03:00.1: eth1: 0x00000090: 0x00000000, 0x00000000, 0x00000000, 0x000000e8
> kernel: tg3 0000:03:00.1: eth1: 0x000000a0: 0x8010ac11, 0x00000004, 0x00001004, 0x00020010
> kernel: tg3 0000:03:00.1: eth1: 0x000000b0: 0x15048d81, 0x00102400, 0x0004cc22, 0x10110040
> kernel: tg3 0000:03:00.1: eth1: 0x000000d0: 0x0000001f, 0x00000000, 0x00000000, 0x00010000
> kernel: tg3 0000:03:00.1: eth1: 0x000000f0: 0x00000000, 0x05720000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000100: 0x13c10001, 0x00000000, 0x00000000, 0x00062030
> kernel: tg3 0000:03:00.1: eth1: 0x00000110: 0x00002080, 0x00002000, 0x000000a0, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000130: 0x00000000, 0x00000000, 0x00000000, 0x15010003
> kernel: tg3 0000:03:00.1: eth1: 0x00000140: 0xd0400c65, 0x00000014, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000150: 0x16010004, 0x00000000, 0x0007811b, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000160: 0x00010002, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000170: 0x00000000, 0x800000ff, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000200: 0x00000000, 0x03000000, 0x00000000, 0x0d000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000210: 0x00000000, 0x07000000, 0x00000000, 0x0b000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000220: 0x00000000, 0x04000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000260: 0x00000000, 0x00000000, 0x00000000, 0x000000e8
> kernel: tg3 0000:03:00.1: eth1: 0x00000280: 0x00000000, 0x0000000c, 0x00000000, 0x00000006
> kernel: tg3 0000:03:00.1: eth1: 0x00000290: 0x00000000, 0x0000000a, 0x00000000, 0x00000004
> kernel: tg3 0000:03:00.1: eth1: 0x00000300: 0x00000001, 0x00000000, 0x00000000, 0x00000001
> kernel: tg3 0000:03:00.1: eth1: 0x00000400: 0x18e04808, 0x00400000, 0x00001000, 0x00000880
> kernel: tg3 0000:03:00.1: eth1: 0x00000410: 0x00000014, 0xd0400c64, 0x00000014, 0xd0400c64
> kernel: tg3 0000:03:00.1: eth1: 0x00000420: 0x00000014, 0xd0400c64, 0x00000014, 0xd0400c64
> kernel: tg3 0000:03:00.1: eth1: 0x00000430: 0x00000400, 0x00000000, 0x000002dd, 0x000005f2
> kernel: tg3 0000:03:00.1: eth1: 0x00000440: 0x00000000, 0x00000000, 0x00000000, 0x04584400
> kernel: tg3 0000:03:00.1: eth1: 0x00000450: 0x00000001, 0x00008000, 0x00000000, 0x00000102
> kernel: tg3 0000:03:00.1: eth1: 0x00000460: 0x00000008, 0x00002620, 0x01ff0002, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000470: 0x80000000, 0x00000080, 0x00000000, 0x40200000
> kernel: tg3 0000:03:00.1: eth1: 0x00000480: 0x42000000, 0x7fffffff, 0x06000004, 0x7fffffff
> kernel: tg3 0000:03:00.1: eth1: 0x00000500: 0x00000008, 0x00000002, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000540: 0x00000014, 0xd0400c66, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000590: 0x00e00000, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000005b0: 0x00000000, 0x00000008, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000005c0: 0xb26ff6f0, 0xa1d5ff82, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000600: 0xffffffff, 0x00f80011, 0x00000000, 0x00001f04
> kernel: tg3 0000:03:00.1: eth1: 0x00000610: 0xffffffff, 0x00000000, 0x07c00004, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000620: 0x00000040, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000630: 0x01230123, 0x01230123, 0x01230123, 0x01230123
> kernel: tg3 0000:03:00.1: eth1: 0x00000640: 0x01230123, 0x01230123, 0x01230123, 0x01230123
> kernel: tg3 0000:03:00.1: eth1: 0x00000650: 0x01230123, 0x01230123, 0x01230123, 0x01230123
> kernel: tg3 0000:03:00.1: eth1: 0x00000660: 0x01230123, 0x01230123, 0x01230123, 0x01230123
> kernel: tg3 0000:03:00.1: eth1: 0x00000670: 0x5f865437, 0xe4ac62cc, 0x50103a45, 0x36621985
> kernel: tg3 0000:03:00.1: eth1: 0x00000680: 0xbf14c0e8, 0x1bc27a1e, 0x84f4b556, 0x094ea6fe
> kernel: tg3 0000:03:00.1: eth1: 0x00000690: 0x7dda01e7, 0xc04d7481, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000006c0: 0x00000000, 0x00000000, 0x04000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000006d0: 0x00000001, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000800: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000810: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000820: 0x00000000, 0x00000000, 0xffffffff, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000830: 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
> kernel: tg3 0000:03:00.1: eth1: 0x00000840: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> kernel: tg3 0000:03:00.1: eth1: 0x00000850: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> kernel: tg3 0000:03:00.1: eth1: 0x00000860: 0xffffffff, 0xffffffff, 0xffffffff, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000880: 0x00000108, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000890: 0x00000002, 0x00000001, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000008f0: 0x00000001, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000900: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000910: 0x00000000, 0xffffffff, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000920: 0x00000000, 0x00000000, 0xffffffff, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000930: 0x00000000, 0xffffffff, 0xffffffff, 0xffffffff
> kernel: tg3 0000:03:00.1: eth1: 0x00000940: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> kernel: tg3 0000:03:00.1: eth1: 0x00000950: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff
> kernel: tg3 0000:03:00.1: eth1: 0x00000960: 0xffffffff, 0xffffffff, 0xffffffff, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000980: 0x00000108, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000990: 0x0000000a, 0x00000020, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000c00: 0x0000000a, 0x00000000, 0x00000003, 0x00000001
> kernel: tg3 0000:03:00.1: eth1: 0x00000c10: 0x00000000, 0x00000000, 0x00000000, 0x01420000
> kernel: tg3 0000:03:00.1: eth1: 0x00000c80: 0x00000002, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00000ce0: 0x79fa6c02, 0x00000001, 0x00000142, 0x00040028
> kernel: tg3 0000:03:00.1: eth1: 0x00000cf0: 0x00000000, 0x50000001, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00001000: 0x00000002, 0x00000000, 0xa0000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00001400: 0x00000006, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00001440: 0x00000000, 0x00000001, 0x00000001, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00001480: 0x00003321, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00001800: 0x00000036, 0x00000000, 0x00000000, 0x00000001
> kernel: tg3 0000:03:00.1: eth1: 0x00001810: 0x00000001, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00001830: 0x00000000, 0x00000000, 0x00000000, 0x74218000
> kernel: tg3 0000:03:00.1: eth1: 0x00001840: 0x79012000, 0x00000001, 0x00000204, 0xc0000000
> kernel: tg3 0000:03:00.1: eth1: 0x00001850: 0x0000001f, 0x00000000, 0x00004800, 0x00000001
> kernel: tg3 0000:03:00.1: eth1: 0x00001860: 0x01000100, 0x00000000, 0x78f2e000, 0x00000001
> kernel: tg3 0000:03:00.1: eth1: 0x00001c00: 0x00000002, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002000: 0x00000002, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002010: 0x00000181, 0x00000001, 0x00780003, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002100: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002110: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002120: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002130: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002140: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002150: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002160: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002170: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002180: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002190: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000021a0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000021b0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000021c0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000021d0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000021e0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000021f0: 0x0008c061, 0x0008c061, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002200: 0x0000002a, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002250: 0x0000000a, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002400: 0x00010012, 0x00000000, 0x00204001, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002410: 0x0000000f, 0x00005d00, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002440: 0x00000000, 0x00000000, 0x00000002, 0x00044400
> kernel: tg3 0000:03:00.1: eth1: 0x00002450: 0x00000001, 0x73a10000, 0x08001800, 0x00040000
> kernel: tg3 0000:03:00.1: eth1: 0x00002470: 0x00000000, 0x00000020, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002500: 0x00000000, 0x00000000, 0x00000002, 0x00044800
> kernel: tg3 0000:03:00.1: eth1: 0x00002510: 0x00000000, 0x00000000, 0x00000002, 0x00040400
> kernel: tg3 0000:03:00.1: eth1: 0x00002520: 0x00000000, 0x00000000, 0x00000002, 0x00044c00
> kernel: tg3 0000:03:00.1: eth1: 0x00002530: 0x00000000, 0x00000000, 0x00000002, 0x00040800
> kernel: tg3 0000:03:00.1: eth1: 0x00002540: 0x00000000, 0x00000000, 0x00000002, 0x00045000
> kernel: tg3 0000:03:00.1: eth1: 0x00002550: 0x00000000, 0x00000000, 0x00000002, 0x00040c00
> kernel: tg3 0000:03:00.1: eth1: 0x00002560: 0x00000000, 0x00000000, 0x00000002, 0x00045400
> kernel: tg3 0000:03:00.1: eth1: 0x00002570: 0x00000000, 0x00000000, 0x00000002, 0x00041000
> kernel: tg3 0000:03:00.1: eth1: 0x00002580: 0x00000000, 0x00000000, 0x00000002, 0x00045800
> kernel: tg3 0000:03:00.1: eth1: 0x00002590: 0x00000000, 0x00000000, 0x00000002, 0x00041400
> kernel: tg3 0000:03:00.1: eth1: 0x000025a0: 0x00000000, 0x00000000, 0x00000002, 0x00045c00
> kernel: tg3 0000:03:00.1: eth1: 0x000025b0: 0x00000000, 0x00000000, 0x00000002, 0x00041800
> kernel: tg3 0000:03:00.1: eth1: 0x000025c0: 0x00000000, 0x00000000, 0x00000002, 0x00046000
> kernel: tg3 0000:03:00.1: eth1: 0x000025d0: 0x00000000, 0x00000000, 0x00000002, 0x00041c00
> kernel: tg3 0000:03:00.1: eth1: 0x000025e0: 0x00000000, 0x00000000, 0x00000002, 0x00046400
> kernel: tg3 0000:03:00.1: eth1: 0x000025f0: 0x00000000, 0x00000000, 0x00000002, 0x00042000
> kernel: tg3 0000:03:00.1: eth1: 0x00002600: 0x00000000, 0x00000000, 0x00000002, 0x00046800
> kernel: tg3 0000:03:00.1: eth1: 0x00002610: 0x00000000, 0x00000000, 0x00000002, 0x00042400
> kernel: tg3 0000:03:00.1: eth1: 0x00002620: 0x00000000, 0x00000000, 0x00000002, 0x00046c00
> kernel: tg3 0000:03:00.1: eth1: 0x00002630: 0x00000000, 0x00000000, 0x00000002, 0x00042800
> kernel: tg3 0000:03:00.1: eth1: 0x00002640: 0x00000000, 0x00000000, 0x00000002, 0x00047000
> kernel: tg3 0000:03:00.1: eth1: 0x00002650: 0x00000000, 0x00000000, 0x00000002, 0x00042c00
> kernel: tg3 0000:03:00.1: eth1: 0x00002660: 0x00000000, 0x00000000, 0x00000002, 0x00047400
> kernel: tg3 0000:03:00.1: eth1: 0x00002670: 0x00000000, 0x00000000, 0x00000002, 0x00043000
> kernel: tg3 0000:03:00.1: eth1: 0x00002680: 0x00000000, 0x00000000, 0x00000002, 0x00047800
> kernel: tg3 0000:03:00.1: eth1: 0x00002690: 0x00000000, 0x00000000, 0x00000002, 0x00043400
> kernel: tg3 0000:03:00.1: eth1: 0x000026a0: 0x00000000, 0x00000000, 0x00000002, 0x00047c00
> kernel: tg3 0000:03:00.1: eth1: 0x000026b0: 0x00000000, 0x00000000, 0x00000002, 0x00043800
> kernel: tg3 0000:03:00.1: eth1: 0x000026c0: 0x00000000, 0x00000000, 0x00000002, 0x00048000
> kernel: tg3 0000:03:00.1: eth1: 0x000026d0: 0x00000000, 0x00000000, 0x00000002, 0x00043c00
> kernel: tg3 0000:03:00.1: eth1: 0x000026e0: 0x00000000, 0x00000000, 0x00000002, 0x00048400
> kernel: tg3 0000:03:00.1: eth1: 0x000026f0: 0x00000000, 0x00000000, 0x00000002, 0x00044000
> kernel: tg3 0000:03:00.1: eth1: 0x00002800: 0x00000006, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002c00: 0x00000006, 0x00000000, 0x00000000, 0x000000a0
> kernel: tg3 0000:03:00.1: eth1: 0x00002c10: 0x00000000, 0x00000000, 0x00000019, 0x0000000c
> kernel: tg3 0000:03:00.1: eth1: 0x00002c20: 0x00000001, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00002d00: 0x00000080, 0x00000040, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003000: 0x00000006, 0x00000000, 0x00000000, 0x000000a0
> kernel: tg3 0000:03:00.1: eth1: 0x00003440: 0x00000000, 0x00000000, 0x00000000, 0x00000110
> kernel: tg3 0000:03:00.1: eth1: 0x00003600: 0x00000600, 0x00170000, 0x00110000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003610: 0x00170000, 0x00000000, 0x00130000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003620: 0x00110011, 0x00000000, 0x00000000, 0x40032080
> kernel: tg3 0000:03:00.1: eth1: 0x00003630: 0x00800000, 0x87748774, 0x02c01000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003640: 0x00000000, 0x00000000, 0x00000020, 0x00000019
> kernel: tg3 0000:03:00.1: eth1: 0x00003650: 0x00000171, 0x000f03ff, 0x05720000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003660: 0x00000000, 0x00000000, 0x02000000, 0x00000202
> kernel: tg3 0000:03:00.1: eth1: 0x00003670: 0x00000000, 0xfeffbff7, 0x00000000, 0x00000020
> kernel: tg3 0000:03:00.1: eth1: 0x00003680: 0x30018010, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000036a0: 0x000001a0, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000036b0: 0x0010034c, 0x07ff07ff, 0x07ff07ff, 0x01000004
> kernel: tg3 0000:03:00.1: eth1: 0x000036c0: 0xffffffff, 0x00000000, 0x00000000, 0x000001c6
> kernel: tg3 0000:03:00.1: eth1: 0x000036d0: 0x0000019d, 0x00000000, 0x00000000, 0x0000485f
> kernel: tg3 0000:03:00.1: eth1: 0x000036f0: 0x00000000, 0x00000000, 0x00000000, 0x00013301
> kernel: tg3 0000:03:00.1: eth1: 0x00003800: 0x00000001, 0x00000000, 0x0000000e, 0x0516028b
> kernel: tg3 0000:03:00.1: eth1: 0x00003810: 0x000001f6, 0x00000052, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003c00: 0x00000306, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003c30: 0x00000000, 0x00000000, 0x00000001, 0x74320000
> kernel: tg3 0000:03:00.1: eth1: 0x00003c40: 0x00000000, 0x00000b00, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003c50: 0x00000000, 0x00000020, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003c80: 0x0000000c, 0x00000006, 0x0000000a, 0x00000004
> kernel: tg3 0000:03:00.1: eth1: 0x00003cd0: 0x00000000, 0x0000000f, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00003d00: 0x00000001, 0x790b7000, 0x00000001, 0x7429d000
> kernel: tg3 0000:03:00.1: eth1: 0x00003d10: 0x00000001, 0x76be5000, 0x00000001, 0x79abb000
> kernel: tg3 0000:03:00.1: eth1: 0x00003d80: 0x00000014, 0x00000048, 0x00000005, 0x00000035
> kernel: tg3 0000:03:00.1: eth1: 0x00003d90: 0x00000005, 0x00000005, 0x00000014, 0x00000048
> kernel: tg3 0000:03:00.1: eth1: 0x00003da0: 0x00000005, 0x00000035, 0x00000005, 0x00000005
> kernel: tg3 0000:03:00.1: eth1: 0x00003db0: 0x00000014, 0x00000048, 0x00000005, 0x00000035
> kernel: tg3 0000:03:00.1: eth1: 0x00003dc0: 0x00000005, 0x00000005, 0x00000014, 0x00000048
> kernel: tg3 0000:03:00.1: eth1: 0x00003dd0: 0x00000005, 0x00000035, 0x00000005, 0x00000005
> kernel: tg3 0000:03:00.1: eth1: 0x00003fc0: 0x00000026, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004000: 0x00000002, 0x00000000, 0x0003afe9, 0x0014654c
> kernel: tg3 0000:03:00.1: eth1: 0x00004010: 0x00000000, 0x00261012, 0x00000480, 0x00848042
> kernel: tg3 0000:03:00.1: eth1: 0x00004020: 0x00000000, 0x00000000, 0x00000010, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004030: 0x00000010, 0x00000050, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004040: 0x00000000, 0x00000000, 0x01090020, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004050: 0x00000000, 0x00000000, 0x0025d010, 0x00000002
> kernel: tg3 0000:03:00.1: eth1: 0x00004060: 0x00400000, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004400: 0x00000016, 0x00000000, 0x00010000, 0x0000a000
> kernel: tg3 0000:03:00.1: eth1: 0x00004410: 0x00000000, 0x0000002a, 0x000000a0, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004420: 0x0000003d, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004440: 0x00000000, 0x00000000, 0x00000000, 0x00000001
> kernel: tg3 0000:03:00.1: eth1: 0x00004450: 0x0002033f, 0x00620063, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004800: 0x380303fe, 0x00000000, 0x00000000, 0x00000100
> kernel: tg3 0000:03:00.1: eth1: 0x00004810: 0x00000000, 0x00000004, 0x00009c80, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004820: 0x737c0014, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004840: 0x00000000, 0x00000000, 0x00d73500, 0x00fd175d
> kernel: tg3 0000:03:00.1: eth1: 0x00004850: 0xe58e042e, 0xd1927a2c, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004860: 0x00000014, 0x11548788, 0x00100800, 0x00040000
> kernel: tg3 0000:03:00.1: eth1: 0x00004870: 0x05ea0000, 0x003e1820, 0x003e1820, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004880: 0x00000014, 0xd0400c66, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004900: 0x28190404, 0x00305407, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004910: 0x000f001c, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004a00: 0x180303fe, 0x00200000, 0x00200020, 0x00210000
> kernel: tg3 0000:03:00.1: eth1: 0x00004a10: 0x73a113a0, 0x008ca924, 0x00200012, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004a20: 0x00000000, 0x00000000, 0xf02c0000, 0x73a11400
> kernel: tg3 0000:03:00.1: eth1: 0x00004a30: 0x00000000, 0x00000084, 0x00000084, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004a40: 0x73a11380, 0x73a113a0, 0x73a11340, 0x73a11360
> kernel: tg3 0000:03:00.1: eth1: 0x00004a50: 0x00200020, 0x00200020, 0x00200020, 0x00200020
> kernel: tg3 0000:03:00.1: eth1: 0x00004a70: 0x28190404, 0x00305407, 0x000f001c, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004b00: 0x180303fe, 0x005a0003, 0x30000000, 0x01420160
> kernel: tg3 0000:03:00.1: eth1: 0x00004b10: 0xe01a0000, 0x00000003, 0x005adc88, 0x00001692
> kernel: tg3 0000:03:00.1: eth1: 0x00004b20: 0x00000000, 0x02000000, 0x00000000, 0x005a0000
> kernel: tg3 0000:03:00.1: eth1: 0x00004b30: 0x00000000, 0x00420000, 0x00000000, 0x001a0000
> kernel: tg3 0000:03:00.1: eth1: 0x00004b50: 0x00000000, 0x00000000, 0x88000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004b60: 0x00000000, 0x00000000, 0x88000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004b70: 0x00000000, 0x00000000, 0x88000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004b80: 0x00000000, 0x11548788, 0x00100800, 0x00040000
> kernel: tg3 0000:03:00.1: eth1: 0x00004b90: 0x05ea0000, 0x28190404, 0x00305407, 0x000f001c
> kernel: tg3 0000:03:00.1: eth1: 0x00004ba0: 0x330c3000, 0x00000000, 0x11548788, 0x000f001c
> kernel: tg3 0000:03:00.1: eth1: 0x00004bc0: 0x738e8002, 0x79fa6c02, 0x1ce29ebe, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004bd0: 0x79fa6402, 0x746ed002, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004be0: 0x0142005a, 0x0000e01a, 0x00460142, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004bf0: 0x00000000, 0x00000000, 0x88000000, 0x00003333
> kernel: tg3 0000:03:00.1: eth1: 0x00004c00: 0x200003fe, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004c10: 0x0000002a, 0x00000000, 0x00000006, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004c20: 0x00000000, 0x00000000, 0x00000000, 0x00000006
> kernel: tg3 0000:03:00.1: eth1: 0x00004c30: 0x00000000, 0x00018000, 0x00108000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00004c40: 0x00000020, 0x00000000, 0x001d0020, 0x00040020
> kernel: tg3 0000:03:00.1: eth1: 0x00004c50: 0x0900500b, 0x0000b003, 0x0400a006, 0x00200303
> kernel: tg3 0000:03:00.1: eth1: 0x00004c60: 0x00000020, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005000: 0x00009800, 0x80004000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005010: 0x00000000, 0x00000000, 0x00000000, 0x08002c9c
> kernel: tg3 0000:03:00.1: eth1: 0x00005020: 0x0e000b25, 0x00000000, 0x00000000, 0x40000020
> kernel: tg3 0000:03:00.1: eth1: 0x00005030: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005040: 0x00000000, 0x00000000, 0x080019d2, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005080: 0x00009800, 0x80000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005090: 0x00000000, 0x00000000, 0x00000000, 0x08001fac
> kernel: tg3 0000:03:00.1: eth1: 0x000050a0: 0x30422000, 0x00000000, 0x00000000, 0x40000020
> kernel: tg3 0000:03:00.1: eth1: 0x000050b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000050c0: 0x00000000, 0x00000000, 0x08000088, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005100: 0x00009800, 0x80000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005110: 0x00000000, 0x00000000, 0x00000000, 0x080019c4
> kernel: tg3 0000:03:00.1: eth1: 0x00005120: 0x30422000, 0x00000000, 0x00000000, 0x40000020
> kernel: tg3 0000:03:00.1: eth1: 0x00005130: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005140: 0x00000000, 0x00000000, 0x08002cd4, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005180: 0x00009800, 0x80004000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005190: 0x00000000, 0x00000000, 0x00000000, 0x08002ca0
> kernel: tg3 0000:03:00.1: eth1: 0x000051a0: 0x00621024, 0x00000000, 0x00000000, 0x40000020
> kernel: tg3 0000:03:00.1: eth1: 0x000051b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000051c0: 0x00000000, 0x00000000, 0x08000088, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005200: 0x14600027, 0x144001e2, 0x144001e2, 0x3c038000
> kernel: tg3 0000:03:00.1: eth1: 0x00005210: 0x01020000, 0x01020000, 0xc0000000, 0xdeaddead
> kernel: tg3 0000:03:00.1: eth1: 0x00005220: 0xdeaddead, 0x3c038000, 0xc0000000, 0x01020000
> kernel: tg3 0000:03:00.1: eth1: 0x00005230: 0x14600027, 0x00000000, 0xc0000000, 0x14600027
> kernel: tg3 0000:03:00.1: eth1: 0x00005240: 0xb49a89ab, 0x144001e2, 0x144001e2, 0x14600027
> kernel: tg3 0000:03:00.1: eth1: 0x00005250: 0x00000b50, 0x144001e2, 0x3c038000, 0xc0010000
> kernel: tg3 0000:03:00.1: eth1: 0x00005260: 0x00000000, 0x00000b50, 0x01020000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005270: 0x00000000, 0x14600027, 0xb49a89ab, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005280: 0x00009800, 0x80000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005290: 0x00000000, 0x00000000, 0x00000000, 0x08002c9c
> kernel: tg3 0000:03:00.1: eth1: 0x000052a0: 0x30422000, 0x00000000, 0x00000000, 0x40000020
> kernel: tg3 0000:03:00.1: eth1: 0x000052b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000052c0: 0x00000000, 0x00000000, 0x080027fc, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005300: 0x00009800, 0x80004000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005310: 0x00000000, 0x00000000, 0x00000000, 0x08001fc0
> kernel: tg3 0000:03:00.1: eth1: 0x00005320: 0x00831824, 0x00000000, 0x00000000, 0x40000020
> kernel: tg3 0000:03:00.1: eth1: 0x00005330: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005340: 0x00000000, 0x00000000, 0x08002cb6, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005380: 0x00009800, 0x80004000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005390: 0x00000000, 0x00000000, 0x00000000, 0x08002068
> kernel: tg3 0000:03:00.1: eth1: 0x000053a0: 0x8c434014, 0x00000000, 0x00000000, 0x40000020
> kernel: tg3 0000:03:00.1: eth1: 0x000053b0: 0x00000000, 0x0000001d, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000053c0: 0x00000000, 0x00000000, 0x080027fc, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005800: 0x03000000, 0x03000000, 0x0d000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005810: 0x07000000, 0x00000000, 0x0b000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005820: 0x04000000, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005860: 0x00000000, 0x00000000, 0x000000e8, 0x000000e8
> kernel: tg3 0000:03:00.1: eth1: 0x00005880: 0x0000000c, 0x0000000c, 0x00000006, 0x00000006
> kernel: tg3 0000:03:00.1: eth1: 0x00005890: 0x0000000a, 0x0000000a, 0x00000004, 0x00000004
> kernel: tg3 0000:03:00.1: eth1: 0x00005900: 0x00000000, 0x00000000, 0x00000001, 0x00000001
> kernel: tg3 0000:03:00.1: eth1: 0x00005980: 0x00000000, 0x00000001, 0x00000001, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00005a00: 0x000f601f, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006000: 0x00010082, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006400: 0x00000000, 0x00000000, 0x00010091, 0xc0000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006410: 0x0a000064, 0x0a000064, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006430: 0x00000000, 0x14e4165f, 0x165f14e4, 0x00020000
> kernel: tg3 0000:03:00.1: eth1: 0x00006440: 0x0000304f, 0x000002e4, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000064c0: 0x00000010, 0x00000004, 0x00001004, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000064d0: 0x00000000, 0x10008d81, 0x00000000, 0x00315e22
> kernel: tg3 0000:03:00.1: eth1: 0x000064e0: 0x00000031, 0x0000001f, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000064f0: 0x00000002, 0x00000031, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006500: 0x01e10003, 0xd0400c65, 0x00000014, 0x00000003
> kernel: tg3 0000:03:00.1: eth1: 0x00006510: 0x0007811b, 0x00058116, 0x00046113, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006550: 0x00000000, 0x02800000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000065f0: 0x00000000, 0x00000109, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006800: 0x14130034, 0x20099082, 0x01000008, 0x00a16dd0
> kernel: tg3 0000:03:00.1: eth1: 0x00006810: 0x01020000, 0xffffffff, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006830: 0xffffffff, 0xffffffff, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006840: 0x00000000, 0x00000001, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00006890: 0x00000000, 0x88003800, 0x00000000, 0x04102040
> kernel: tg3 0000:03:00.1: eth1: 0x000068a0: 0x00000020, 0x00000001, 0x03ff03ff, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000068b0: 0xe0011514, 0x00000000, 0x00000000, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x000068f0: 0x00ff000e, 0x00ff0000, 0x00000000, 0x04444444
> kernel: tg3 0000:03:00.1: eth1: 0x00006920: 0x00000000, 0x00000000, 0x00000001, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0x00007000: 0x00000008, 0x00000000, 0x00000000, 0x00004868
> kernel: tg3 0000:03:00.1: eth1: 0x00007010: 0x1a5876c2, 0x01c080f3, 0x00d70081, 0x03008200
> kernel: tg3 0000:03:00.1: eth1: 0x00007020: 0x00000000, 0x00000000, 0x00000406, 0x10004000
> kernel: tg3 0000:03:00.1: eth1: 0x00007030: 0x000e0000, 0x0000486c, 0x00170030, 0x00000000
> kernel: tg3 0000:03:00.1: eth1: 0: Host status block [00000005:00000003:(0000:0000:0000):(0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 0: NAPI info [00000003:00000003:(0000:0000:01ff):0000:(00f2:0000:0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 1: Host status block [00000001:00000013:(0000:0000:0000):(0012:0000)]
> kernel: tg3 0000:03:00.1: eth1: 1: NAPI info [00000013:00000013:(0000:0000:01ff):0012:(0012:0012:0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 2: Host status block [00000001:00000007:(0006:0000:0000):(0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 2: NAPI info [00000007:00000007:(0001:0000:01ff):0006:(0006:0006:0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 3: Host status block [00000001:0000000b:(0000:0000:0000):(0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 3: NAPI info [0000000b:0000000b:(0001:0000:01ff):000a:(000a:000a:0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 4: Host status block [00000001:00000007:(0000:0000:0008):(0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: 4: NAPI info [00000007:00000007:(0000:0000:01ff):0008:(0008:0008:0000:0000)]
> kernel: tg3 0000:03:00.1: eth1: Link is down
>
>
> 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
> Subsystem: Broadcom Corporation NetXtreme BCM5720 Gigabit Ethernet PCIe
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin B routed to IRQ 19
> Region 0: Memory at bc140000 (64-bit, prefetchable) [size=64K]
> Region 2: Memory at bc130000 (64-bit, prefetchable) [size=64K]
> Region 4: Memory at bc120000 (64-bit, prefetchable) [size=64K]
> Capabilities: [48] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data
> Product Name: Broadcom NetXtreme Gigabit Ethernet Controller
> Read-only fields:
> [PN] Part number: BCM95720
> [EC] Engineering changes: 106679-15
> [MN] Manufacture ID: 31 34 65 34
> [RV] Reserved: checksum good, 28 byte(s) reserved
> --
> 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: [2/3] gso: Handle new frag_list of frags GRO packets
From: Herbert Xu @ 2013-11-11 18:54 UTC (permalink / raw)
To: Ben Hutchings
Cc: Eric Dumazet, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <1383848204.3802.6.camel@bwh-desktop.uk.level5networks.com>
On Thu, Nov 07, 2013 at 06:16:44PM +0000, Ben Hutchings wrote:
> On Thu, 2013-11-07 at 15:06 +0800, Herbert Xu wrote:
> > Recently GRO started generating packets with frag_lists of frags.
> > This was not handled by GSO, thus leading to a crash.
> >
> > Thankfully these packets are of a regular form and are easy to
> > handle. This patch handles them by calling skb_segment for each
> > frag_list entry. The depth of recursion is limited to just one.
> >
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> >
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 88b7dc6..bcc3f1c 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> [...]
> > @@ -2855,8 +2853,40 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> > nskb->data - tnl_hlen,
> > doffset + tnl_hlen);
> >
> > - if (fskb != skb_shinfo(skb)->frag_list)
> > - goto perform_csum_check;
> > + if (fskb != skb_shinfo(skb)->frag_list) {
> > + struct sk_buff *nsegs;
> > +
> > + if (nskb->len == len + doffset)
> > + goto perform_csum_check;
> > +
> > + SKB_FRAG_ASSERT(nskb);
> > +
> > + __skb_pull(nskb, doffset);
> > + skb_shinfo(nskb)->gso_size = mss;
> > + nsegs = skb_segment(nskb, features);
> > +
> > + err = PTR_ERR(nsegs);
> > + if (IS_ERR(nsegs)) {
> > + kfree(nskb);
>
> Should be kfree_skb().
Thanks for catching this and I have incorporated this into the
newer (albeit completely different) version of the patch.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [3/3] gso: Handle malicious GRO packets without crashing
From: Herbert Xu @ 2013-11-11 18:55 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Eric Dumazet, Ben Hutchings, David Miller, christoph.paasch,
netdev, hkchu, mwdalton
In-Reply-To: <527BE659.9060702@cogentembedded.com>
On Thu, Nov 07, 2013 at 10:13:29PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 11/07/2013 10:08 AM, Herbert Xu wrote:
>
> >As virtio_net can now generate GRO frag_list packets without
> >sufficient verification, we need to handle malicious GRO packets
> >thrown at us.
>
> >This patch converts to affected BUG_ONs in skb_segment to rate-
> >limited warnings.
>
> >Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> >diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> >index bcc3f1c..fb1106d 100644
> >--- a/net/core/skbuff.c
> >+++ b/net/core/skbuff.c
> >@@ -2881,7 +2881,15 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> > while (tail->next)
> > tail = tail->next;
> >
> >- BUG_ON(fskb && tail->len != len + doffset);
> >+ if (fskb && tail->len != len + doffset) {
> >+ net_warn_ratelimited(
> >+ "skb_segment: "
> >+ "illegal GSO fragment: %u %u\n",
>
> Don't break up the message -- chekpatch.pl should allow that...
Thanks for the comment. In the latest version of this patch
this should no longer be an issue.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: Herbert Xu @ 2013-11-11 18:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, bhutchings, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <1383889212.9412.219.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 07, 2013 at 09:40:12PM -0800, Eric Dumazet wrote:
> On Fri, 2013-11-08 at 13:21 +0800, Herbert Xu wrote:
>
> > My point is that even if you did that GRO with your frag_list
> > patch should still be a win because the stack prior to the qdisc
> > gets run once instead of two or three times.
> >
>
> OK, lets me repeat again.
>
> 64KB packet receive/aggregation time is more than 540 us on 1Gbps link.
I presume you're still talking about the case where we're CPU-
bound on receive. In that case I totally agree that you need to
impose a limit on the NAPI/GRO run so that we don't keep doing GRO
forever.
However, the limit should be based on time and not an arbitrary
number such as MAX_SKB_FRAGS. IOW relying on not having a frag_list
to provide a bound to GRO is just wrong.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ethernet/arc/arc_emac: add missing platform_set_drvdata() in arc_emac_probe()
From: David Miller @ 2013-11-11 19:02 UTC (permalink / raw)
To: weiyj.lk; +Cc: grant.likely, rob.herring, abrodkin, vgupta, yongjun_wei, netdev
In-Reply-To: <CAPgLHd_aDFExSewd3ENBgVU1Ru9LaV2Hwg=wjaO5ygo1qXRQQw@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Mon, 11 Nov 2013 14:15:12 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add missing platform_set_drvdata() in arc_emac_probe(), otherwise
> calling platform_get_drvdata() in arc_emac_remove() may returns NULL.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] macmace: add missing platform_set_drvdata() in mace_probe()
From: David Miller @ 2013-11-11 19:02 UTC (permalink / raw)
To: weiyj.lk; +Cc: wfp5p, gregkh, joe, yongjun_wei, netdev
In-Reply-To: <CAPgLHd8tvWttse-CzOcLeAfk0jySZLRhsJ2FCWsxiGaBHfBHMQ@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Mon, 11 Nov 2013 14:16:16 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add missing platform_set_drvdata() in mace_probe(), otherwise
> calling platform_get_drvdata() in mac_mace_device_remove() may
> returns NULL.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH] xtsonic: add missing platform_set_drvdata() in xtsonic_probe()
From: David Miller @ 2013-11-11 19:02 UTC (permalink / raw)
To: weiyj.lk; +Cc: wfp5p, gregkh, michael.opdenacker, joe, yongjun_wei, netdev
In-Reply-To: <CAPgLHd8pm_g=PCNJXo2iEvuWykyP_ewnsfS9FQ2qmQwRGjVuCg@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Mon, 11 Nov 2013 14:17:17 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Add missing platform_set_drvdata() in xtsonic_probe(), otherwise
> calling platform_get_drvdata() in xtsonic_device_remove() may
> returns NULL.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net-next] xfrm: Add check to prevent un-complete key manager
From: David Miller @ 2013-11-11 19:04 UTC (permalink / raw)
To: baker.kernel; +Cc: herbert, steffen.klassert, netdev, linux-kernel
In-Reply-To: <1384151951-13549-1-git-send-email-baker.kernel@gmail.com>
From: baker.kernel@gmail.com
Date: Mon, 11 Nov 2013 14:39:11 +0800
> + if (km->acquire == NULL || km->compile_policy == NULL)
> + return -EINVAL;
There are 7 function pointer methods that must be fully implemented
in an xfrm_mgr object, not just two.
And really we absolutely do not care at all about your out-of-tree
product, it has no bearing upon what should happen here.
^ permalink raw reply
* Re: [PATCH] PHY: Add RTL8201CP phy_driver to realtek
From: David Miller @ 2013-11-11 19:05 UTC (permalink / raw)
To: jonas.jensen; +Cc: netdev, r58129, linux-kernel
In-Reply-To: <1384181166-15501-1-git-send-email-jonas.jensen@gmail.com>
From: Jonas Jensen <jonas.jensen@gmail.com>
Date: Mon, 11 Nov 2013 15:46:06 +0100
> Add RTL8201CP phy_driver.
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: TCP performance regression
From: Ben Greear @ 2013-11-11 19:11 UTC (permalink / raw)
To: Dave Taht
Cc: Eric Dumazet, Felix Fietkau, Sujith Manoharan,
netdev@vger.kernel.org, Avery Pennarun
In-Reply-To: <CAA93jw7ciONyyUKNei5COVTA51tFWVBD4LQMp60wwxGGD=VBEQ@mail.gmail.com>
On 11/11/2013 10:31 AM, Dave Taht wrote:
> Ah, this thread started with a huge regression in ath10k performance
> with the new TSQ stuff, and isn't actually about a two line fix to the
> mv ethernet driver.
>
> http://comments.gmane.org/gmane.linux.network/290269
>
> I suddenly care a lot more. And I'll care a lot, lot, lot more, if
> someone can post a rrul test for before and after the new fq scheduler
> and tsq change on this driver on this hardware... What, if anything,
> in terms of improvements or regressions, happened to multi-stream
> throughput and latency?
>
> https://github.com/tohojo/netperf-wrapper
Not directly related, but we have run some automated tests against
an older buffer-bloat enabled AP (not ath10k hardware, don't know the
exact details at the moment), and in general the performance
is horrible compared to all of the other APs we test against.
Our tests are concerned mostly with throughput.
For reference, here are some graphs with supplicant/hostapd
running on higher-end x86-64 hardware and ath9k:
http://www.candelatech.com/lf_wifi_examples.php
We see somewhat similar results with most commercial APs, though
often they max out at 128 or fewer stations instead of the several
hundred we get on our own AP configs.
We'll update to more recent buffer-bloat AP software and post some
results when we get a chance.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCP performance regression
From: Dave Taht @ 2013-11-11 19:24 UTC (permalink / raw)
To: Ben Greear
Cc: Eric Dumazet, Felix Fietkau, Sujith Manoharan,
netdev@vger.kernel.org, Avery Pennarun
In-Reply-To: <52812BF2.7090605@candelatech.com>
On Mon, Nov 11, 2013 at 11:11 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 11/11/2013 10:31 AM, Dave Taht wrote:
>> Ah, this thread started with a huge regression in ath10k performance
>> with the new TSQ stuff, and isn't actually about a two line fix to the
>> mv ethernet driver.
>>
>> http://comments.gmane.org/gmane.linux.network/290269
>>
>> I suddenly care a lot more. And I'll care a lot, lot, lot more, if
>> someone can post a rrul test for before and after the new fq scheduler
>> and tsq change on this driver on this hardware... What, if anything,
>> in terms of improvements or regressions, happened to multi-stream
>> throughput and latency?
>>
>> https://github.com/tohojo/netperf-wrapper
>
> Not directly related, but we have run some automated tests against
> an older buffer-bloat enabled AP (not ath10k hardware, don't know the
> exact details at the moment), and in general the performance
> is horrible compared to all of the other APs we test against.
I was not happy with the dlink product and the streamboost
implementation, if that is what it was.
> Our tests are concerned mostly with throughput.
:(
> For reference, here are some graphs with supplicant/hostapd
> running on higher-end x86-64 hardware and ath9k:
>
> http://www.candelatech.com/lf_wifi_examples.php
>
> We see somewhat similar results with most commercial APs, though
> often they max out at 128 or fewer stations instead of the several
> hundred we get on our own AP configs.
>
> We'll update to more recent buffer-bloat AP software and post some
> results when we get a chance.
Are you talking cerowrt (on the wndr3800) here? I am well aware that
it doesn't presently scale well with large numbers of clients, which
is awaiting the per-sta queue work. (most of the work to date has been
on the aqm-to-the-universe code)
This is the most recent stable firmware for that:
http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.17-6/
I just did 3.10.18 but haven't tested it.
Cero also runs HT20 by default, and there are numerous other things
that are configured more for "science" than throughput. Notably the
size of the aggregation queues is limited. But I'd LOVE a test through
your suite.
I note I'd also love to see TCP tests through your suite with the AP
configured thusly
(server) - (100ms delay box running a recent netem and a packet limit
of 100000+) - AP (w 1000 packets buffering/wo AQM, and with AQM) -
(wifi clients)
(and will gladly help set that up. Darn, I just drove past your offices)
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
--
Dave Täht
^ permalink raw reply
* Re: [PATCH net-next 0/6] prandom fixes/improvements
From: David Miller @ 2013-11-11 19:33 UTC (permalink / raw)
To: dborkman; +Cc: shemminger, fweimer, netdev
In-Reply-To: <cover.1384160397.git.dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Mon, 11 Nov 2013 12:20:31 +0100
> It would be great if you could still consider this series that fixes and
> improves prandom for 3.13. We have sent it to netdev as prandom() originally
> came from net/core/utils.c and networking is its main user. For a detailled
> description, please see individual patches.
Ok, series applied, I'll give Linus the merge conflict resolution
instructions.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/6] prandom fixes/improvements
From: Hannes Frederic Sowa @ 2013-11-11 19:44 UTC (permalink / raw)
To: David Miller; +Cc: dborkman, shemminger, fweimer, netdev
In-Reply-To: <20131111.143341.148954332177473990.davem@davemloft.net>
On Mon, Nov 11, 2013 at 02:33:41PM -0500, David Miller wrote:
> From: Daniel Borkmann <dborkman@redhat.com>
> Date: Mon, 11 Nov 2013 12:20:31 +0100
>
> > It would be great if you could still consider this series that fixes and
> > improves prandom for 3.13. We have sent it to netdev as prandom() originally
> > came from net/core/utils.c and networking is its main user. For a detailled
> > description, please see individual patches.
>
> Ok, series applied, I'll give Linus the merge conflict resolution
> instructions.
We would also suggest to push Patch #1 to -stable.
Thank you,
Hannes
^ permalink raw reply
* Re: [patch net-next RFC 0/2] ipv6: allow temporary address management for user-created addresses
From: Jiri Pirko @ 2013-11-11 19:49 UTC (permalink / raw)
To: David Miller
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, thaller, stephen,
hannes, vyasevich, dcbw
In-Reply-To: <20131111.134243.26261596699898567.davem@davemloft.net>
Mon, Nov 11, 2013 at 07:42:43PM CET, davem@davemloft.net wrote:
>
>I'm not really going to read patches not properly at least CC:'d to
>netdev, sorry Jiri.
netdev is in "To:"
I marked the patches as "RFC" on patchwork. Maybe I should not do it
next time, right?
Thanks
Jiri
^ permalink raw reply
* Re: [PATCH net-next 0/6] prandom fixes/improvements
From: David Miller @ 2013-11-11 20:00 UTC (permalink / raw)
To: hannes; +Cc: dborkman, shemminger, fweimer, netdev
In-Reply-To: <20131111194432.GA3043@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 11 Nov 2013 20:44:32 +0100
> On Mon, Nov 11, 2013 at 02:33:41PM -0500, David Miller wrote:
>> From: Daniel Borkmann <dborkman@redhat.com>
>> Date: Mon, 11 Nov 2013 12:20:31 +0100
>>
>> > It would be great if you could still consider this series that fixes and
>> > improves prandom for 3.13. We have sent it to netdev as prandom() originally
>> > came from net/core/utils.c and networking is its main user. For a detailled
>> > description, please see individual patches.
>>
>> Ok, series applied, I'll give Linus the merge conflict resolution
>> instructions.
>
> We would also suggest to push Patch #1 to -stable.
Yes Daniel mentioned that, I queued it up already.
Thanks.
^ permalink raw reply
* Re: [patch net-next RFC 0/2] ipv6: allow temporary address management for user-created addresses
From: David Miller @ 2013-11-11 20:01 UTC (permalink / raw)
To: jiri
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, thaller, stephen,
hannes, vyasevich, dcbw
In-Reply-To: <20131111194901.GA2397@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 11 Nov 2013 20:49:01 +0100
> Mon, Nov 11, 2013 at 07:42:43PM CET, davem@davemloft.net wrote:
>>
>>I'm not really going to read patches not properly at least CC:'d to
>>netdev, sorry Jiri.
>
> netdev is in "To:"
>
> I marked the patches as "RFC" on patchwork. Maybe I should not do it
> next time, right?
I think you sent this multiple times, once without netdev in the CC: and
then again with it present.
In any event you did the right thing in the end, sorry about that :)
^ permalink raw reply
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