* Re: [PATCH 3/4 v2] ks8851: companion eeprom access through ethtool
From: David Miller @ 2010-05-06 7:20 UTC (permalink / raw)
To: s-jan; +Cc: netdev, linux-omap, x0066660, ben-linux, Tristram.Ha
In-Reply-To: <1273085155-1260-4-git-send-email-s-jan@ti.com>
From: Sebastien Jan <s-jan@ti.com>
Date: Wed, 5 May 2010 20:45:54 +0200
> Accessing ks8851 companion eeprom permits modifying the ks8851 stored
> MAC address.
>
> Example how to change the MAC address using ethtool, to set the
> 01:23:45:67:89:AB MAC address:
> $ echo "0:AB8976452301" | xxd -r > mac.bin
> $ sudo ethtool -E eth0 magic 0x8870 offset 2 < mac.bin
>
> Signed-off-by: Sebastien Jan <s-jan@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4 v2] ks8851: Low level functions for read/write to companion eeprom
From: David Miller @ 2010-05-06 7:20 UTC (permalink / raw)
To: s-jan; +Cc: netdev, linux-omap, x0066660, ben-linux, Tristram.Ha
In-Reply-To: <1273085155-1260-3-git-send-email-s-jan@ti.com>
From: Sebastien Jan <s-jan@ti.com>
Date: Wed, 5 May 2010 20:45:53 +0200
> Low-level functions provide 16bits words read and write capability
> to ks8851 companion eeprom.
>
> Signed-off-by: Sebastien Jan <s-jan@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/4 v2] ks8851: Add caching of CCR register
From: David Miller @ 2010-05-06 7:20 UTC (permalink / raw)
To: s-jan; +Cc: netdev, linux-omap, x0066660, ben-linux, Tristram.Ha
In-Reply-To: <1273085155-1260-2-git-send-email-s-jan@ti.com>
From: Sebastien Jan <s-jan@ti.com>
Date: Wed, 5 May 2010 20:45:52 +0200
> CCR register contains information on companion eeprom availability.
>
> Signed-off-by: Sebastien Jan <s-jan@ti.com>
APplied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 4/4] e1000e: Save irq into netdev structure
From: David Miller @ 2010-05-06 7:19 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, therbert, bruce.w.allan
In-Reply-To: <20100506000330.8042.91540.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 17:03:32 -0700
> From: Tom Herbert <therbert@google.com>
>
> Set net->devirq to pdev->irq. This should be consistent with other
> drivers.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/4] e1000e: Remove unnessary log message
From: David Miller @ 2010-05-06 7:19 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, therbert, bruce.w.allan
In-Reply-To: <20100506000309.8042.9387.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 17:03:11 -0700
> From: Tom Herbert <therbert@google.com>
>
> Remove e_info message printed whenever TSO is enabled or disabled.
> This is not very useful and just clutters dmesg.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/4] e1000e: reduce writes of RX producer ptr
From: David Miller @ 2010-05-06 7:19 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, therbert, bruce.w.allan
In-Reply-To: <20100506000247.8042.97827.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 17:02:49 -0700
> From: Tom Herbert <therbert@google.com>
>
> Reduce number of writes to RX producer pointer. When alloc'ing RX
> buffers, only write the RX producer pointer once every
> E1000_RX_BUFFER_WRITE (16) buffers created.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/4] e1000e: save skb counts in TX to avoid cache misses
From: David Miller @ 2010-05-06 7:19 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, therbert, bruce.w.allan
In-Reply-To: <20100506000221.8042.64794.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 05 May 2010 17:02:27 -0700
> From: Tom Herbert <therbert@google.com>
>
> In e1000_tx_map, precompute number of segements and bytecounts which
> are derived from fields in skb; these are stored in buffer_info. When
> cleaning tx in e1000_clean_tx_irq use the values in the associated
> buffer_info for statistics counting, this eliminates cache misses
> on skb fields.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/6] netdev: octeon_mgmt: Remove some gratuitous blank lines.
From: David Miller @ 2010-05-06 7:19 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1273100593-11043-7-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 5 May 2010 16:03:13 -0700
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH 5/6] netdev: octeon_mgmt: Try not to drop TX packets when stopping the queue.
From: David Miller @ 2010-05-06 7:19 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1273100593-11043-6-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 5 May 2010 16:03:12 -0700
> Stop the queue when we add the packet that will fill it instead of dropping the packet
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH 4/6] netdev: octeon_mgmt: Free TX skbufs in a timely manner.
From: David Miller @ 2010-05-06 7:19 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1273100593-11043-5-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 5 May 2010 16:03:11 -0700
> We also reduce the high water mark to 1 so skbufs are not stranded for
> long periods of time. Since we are cleaning after each packet, no
> need to do it in the transmit path.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/6] netdev: octeon_mgmt: Fix race manipulating irq bits.
From: David Miller @ 2010-05-06 7:18 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1273100593-11043-4-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 5 May 2010 16:03:10 -0700
> Don't re-read the interrupt status register, clear the exact bits we
> will be testing.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/6] netdev: octeon_mgmt: Fix race condition freeing TX buffers.
From: David Miller @ 2010-05-06 7:18 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1273100593-11043-3-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 5 May 2010 16:03:09 -0700
> Under heavy load the TX cleanup tasklet and xmit threads would race
> and try to free too many buffers.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/6] netdev: octeon_mgmt: Use proper MAC addresses.
From: David Miller @ 2010-05-06 7:18 UTC (permalink / raw)
To: ddaney; +Cc: netdev, linux-mips
In-Reply-To: <1273100593-11043-2-git-send-email-ddaney@caviumnetworks.com>
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 5 May 2010 16:03:08 -0700
> The original implementation incorrectly uses netdev->dev_addrs.
>
> Use netdev->uc instead. Also use netdev_for_each_uc_addr to iterate
> over the addresses. Fix comment.
>
> Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Applied.
^ permalink raw reply
* Re: [PATCH] forcedeth: Account for consumed budget in napi poll
From: David Miller @ 2010-05-06 7:14 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.1.00.1005052111440.31888@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 5 May 2010 21:15:21 -0700 (PDT)
> Repeated calls to nv_rx_process in napi poll routine do not take
> portion of budget that has been consumed in previous calls. Fix by
> subtracting the number of packets processed.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bnx2x: Fix check to get RX hash
From: David Miller @ 2010-05-06 7:14 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.1.00.1005052054590.27018@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 5 May 2010 20:57:16 -0700 (PDT)
> Flag used in check to get rxhash out of the descriptor is incorrect one.
> Fix to use the proper features flag.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied.
^ permalink raw reply
* Re: linux kernel's IPV6_MULTICAST_HOPS default is 64; should be 1?
From: David Miller @ 2010-05-06 7:10 UTC (permalink / raw)
To: brian.haley; +Cc: dlstevens, enh, netdev, netdev-owner
In-Reply-To: <4BE2205A.3050900@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Wed, 05 May 2010 21:50:18 -0400
> David Miller wrote:
>> From: Brian Haley <brian.haley@hp.com>
>> Date: Wed, 05 May 2010 11:36:31 -0400
>>
>>> I now see that in Elliot's email, but I think it's incorrect. The RFC
>>> says that setting it to -1 should get you the kernel default, which is
>>> now 1. Without this change, setting it to -1 will get you 64, the
>>> old behavior. If the user wants to, they can always just set it to
>>> 64 themselves, that's better than assuming when you set it to -1
>>> you're going to get 64.
>>
>> It's not 64, it's whatever the per-route metric is.
>
> Not unless that metric's been set via RTAX_HOPLIMIT (and I believe
> this is the unicast hop limit value anyways), and that metric
> defaults to -1.
Right, if it is, and anyone who does set it and expects the default
multicast hop limit to follow along have no portable way to code their
application in a way that works before and after fixing the RFC
issues.
I gave them a way, by making explicit setting of "-1" do what it's
always done.
> At this point in time I'll gladly implement a per-interface sysctl
> to end this discussion.
The game is over, the result decided, and this is just post-game
discussion as far as I'm concerned. :-)
^ permalink raw reply
* Re: kernel panic when using netns+bridges+tc(netem)
From: Eric Dumazet @ 2010-05-06 6:59 UTC (permalink / raw)
To: Martín Ferrari, Arnd Bergmann; +Cc: netdev, Mathieu Lacage, David Miller
In-Reply-To: <1273128429.2304.5.camel@edumazet-laptop>
Le jeudi 06 mai 2010 à 08:47 +0200, Eric Dumazet a écrit :
> Le jeudi 06 mai 2010 à 08:40 +0200, Eric Dumazet a écrit :
> > Le jeudi 06 mai 2010 à 03:01 +0200, Martín Ferrari a écrit :
> > > Hi there,
> > >
> > > While working on my project that uses netns, I found another bug. This
> > > one causes a "Kernel panic - not syncing: Fatal exception in
> > > interrupt", and I can reproduce it in 2.6.33 and 2.6.34-rc5, but not
> > > in 2.6.32. It dies during a call to __free_skb.
> > > I tested this on my x86_64 laptop (2 cores) and on qemu. In qemu it
> > > was not triggered until I asked it to emulate 2 cpus instead of one,
> > > so it is probably a SMP-only issue.
> > >
> > > Scenario:
> > >
> > > I set up a number of network namespaces, each with two veths to netns
> > > 1. In the main namespace I take those veths and bridge them in pairs,
> > > to configure a linear topology; also I configure the netem qdisc to
> > > simulate link delay.
> > >
> > > Once the network is set up, I run a client/server program to send UDP
> > > packets from one end of the topology to the other. After a few seconds
> > > of sending packets (not really deterministic) it panics.
> > >
> > > Note that I didn't experience this problem when using only 2
> > > namespaces (so, no routing)
> > >
> > > below the dumps. These all come from the qemu, as I couldn't use
> > > netconsole in the network at work, but I checked and the backtraces
> > > were essentially the same
> > >
...
> > Could you please try following patch ?
> >
> > Thanks
> >
> > [PATCH] veth: Dont kfree_skb() after dev_forward_skb()
> >
> > In case of congestion, dev_forward_skb() already free the skb
> >
> > Reported-by: Martín Ferrari <martin.ferrari@gmail.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> > diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> > index f9f0730..5ec542d 100644
> > --- a/drivers/net/veth.c
> > +++ b/drivers/net/veth.c
> > @@ -187,7 +187,6 @@ tx_drop:
> > return NETDEV_TX_OK;
> >
> > rx_drop:
> > - kfree_skb(skb);
> > rcv_stats->rx_dropped++;
> > return NETDEV_TX_OK;
> > }
> >
>
> Hmm, scratch that one, I'll resubmit a proper fix in few minutes
>
> (We must change dev_forward_skb() too)
>
David, this is a stable candidate, once tested and acked, thanks !
[PATCH] veth: Dont kfree_skb() after dev_forward_skb()
In case of congestion, netif_rx() frees the skb, so we must assume
dev_forward_skb() also consume skb.
Bug introduced by commit 445409602c092
(veth: move loopback logic to common location)
We must change dev_forward_skb() to always consume skb, and veth to not
double free it.
Bug report : http://marc.info/?l=linux-netdev&m=127310770900442&w=3
Reported-by: Martín Ferrari <martin.ferrari@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/veth.c | 1 -
net/core/dev.c | 11 +++++------
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index f9f0730..5ec542d 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -187,7 +187,6 @@ tx_drop:
return NETDEV_TX_OK;
rx_drop:
- kfree_skb(skb);
rcv_stats->rx_dropped++;
return NETDEV_TX_OK;
}
diff --git a/net/core/dev.c b/net/core/dev.c
index f769098..264137f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1451,7 +1451,7 @@ static inline void net_timestamp(struct sk_buff *skb)
*
* return values:
* NET_RX_SUCCESS (no congestion)
- * NET_RX_DROP (packet was dropped)
+ * NET_RX_DROP (packet was dropped, but freed)
*
* dev_forward_skb can be used for injecting an skb from the
* start_xmit function of one device into the receive queue
@@ -1465,12 +1465,11 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
{
skb_orphan(skb);
- if (!(dev->flags & IFF_UP))
- return NET_RX_DROP;
-
- if (skb->len > (dev->mtu + dev->hard_header_len))
+ if (!(dev->flags & IFF_UP) ||
+ (skb->len > (dev->mtu + dev->hard_header_len))) {
+ kfree_skb(skb);
return NET_RX_DROP;
-
+ }
skb_set_dev(skb, dev);
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
^ permalink raw reply related
* Re: kernel panic when using netns+bridges+tc(netem)
From: Eric Dumazet @ 2010-05-06 6:47 UTC (permalink / raw)
To: Martín Ferrari; +Cc: netdev, Mathieu Lacage, David Miller
In-Reply-To: <1273128002.2304.4.camel@edumazet-laptop>
Le jeudi 06 mai 2010 à 08:40 +0200, Eric Dumazet a écrit :
> Le jeudi 06 mai 2010 à 03:01 +0200, Martín Ferrari a écrit :
> > Hi there,
> >
> > While working on my project that uses netns, I found another bug. This
> > one causes a "Kernel panic - not syncing: Fatal exception in
> > interrupt", and I can reproduce it in 2.6.33 and 2.6.34-rc5, but not
> > in 2.6.32. It dies during a call to __free_skb.
> > I tested this on my x86_64 laptop (2 cores) and on qemu. In qemu it
> > was not triggered until I asked it to emulate 2 cpus instead of one,
> > so it is probably a SMP-only issue.
> >
> > Scenario:
> >
> > I set up a number of network namespaces, each with two veths to netns
> > 1. In the main namespace I take those veths and bridge them in pairs,
> > to configure a linear topology; also I configure the netem qdisc to
> > simulate link delay.
> >
> > Once the network is set up, I run a client/server program to send UDP
> > packets from one end of the topology to the other. After a few seconds
> > of sending packets (not really deterministic) it panics.
> >
> > Note that I didn't experience this problem when using only 2
> > namespaces (so, no routing)
> >
> > below the dumps. These all come from the qemu, as I couldn't use
> > netconsole in the network at work, but I checked and the backtraces
> > were essentially the same
> >
> > First, two panics with 2.6.34, each one with a slightly different backtrace
> >
> > [ 65.272131] ------------[ cut here ]------------
> > [ 65.272135] kernel BUG at mm/slub.c:2846!
> > [ 65.272135] invalid opcode: 0000 [#1] SMP
> > [ 65.272135] last sysfs file: /sys/devices/virtual/net/lo/operstate
> > [ 65.272135] CPU 1
> > [ 65.272135] Modules linked in: sch_netem veth bridge stp netconsole
> > configfs loop parport_pc parport evdev tpm_tis tpm snd_pcm tpm_bios
> > snd_timer snd soundcore snd_page_alloc pcspkr psmouse serio_raw
> > i2c_piix4 button i2c_core processor ext3 jbd mbcache ide_cd_mod cdrom
> > ide_gd_mod ata_generic ata_piix libata 8139too scsi_mod floppy piix
> > 8139cp mii ide_core thermal thermal_sys [last unloaded: configfs]
> > [ 65.272135]
> > [ 65.272135] Pid: 1518, comm: udp-perf Not tainted 2.6.34-rc5 #1 /
> > [ 65.272135] RIP: 0010:[<ffffffff810e0d6b>] [<ffffffff810e0d6b>]
> > kfree+0x55/0xc6
> > [ 65.272135] RSP: 0018:ffff880001a23d90 EFLAGS: 00010246
> > [ 65.272135] RAX: 0100000000000000 RBX: ffff88007d6bc600 RCX: 0000000000012850
> > [ 65.272135] RDX: ffff88007d6bc600 RSI: 000000000000000e RDI: ffffea0001b6f610
> > [ 65.272135] RBP: ffff88007d6ae200 R08: ffff88007d6bc600 R09: ffffffffa0280690
> > [ 65.272135] R10: 0000000000000002 R11: ffff88007d6bc500 R12: ffffffff8123a77f
> > [ 65.272135] R13: 000000000000002b R14: ffff88007d39b600 R15: ffff88007d6bc600
> > [ 65.272135] FS: 00007f637c9dd6f0(0000) GS:ffff880001a20000(0000)
> > knlGS:0000000000000000
> > [ 65.272135] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 65.272135] CR2: 00000000009deaa0 CR3: 000000007d82d000 CR4: 00000000000006e0
> > [ 65.272135] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 65.272135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 65.272135] Process udp-perf (pid: 1518, threadinfo
> > ffff88007d92a000, task ffff88007e7ff810)
> > [ 65.272135] Stack:
> > [ 65.272135] ffff88007d6bc600 ffff88007d6bc600 0000000000000246
> > ffffffff8123a77f
> > [ 65.272135] <0> ffff880001a32860 ffffffff81241e01 ffffe8ffff623280
> > ffffe8ffff83ffc0
> > [ 65.272135] <0> ffff88007d6bc600 ffffffffa028057d 000000027d4c06c8
> > ffff88007d4c0600
> > [ 65.272135] Call Trace:
> > [ 65.272135] <IRQ>
> > [ 65.272135] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 65.272135] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> > [ 65.272135] [<ffffffffa028057d>] ? veth_xmit+0x6e/0xad [veth]
> > [ 65.272135] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> > [ 65.272135] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> > [ 65.272135] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> > [ 65.272135] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> > [ 65.272135] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> > [ 65.272135] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> > [ 65.272135] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> > [ 65.272135] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> > [ 65.272135] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> > [ 65.272135] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> > [ 65.272135] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> > [ 65.272135] <EOI>
> > [ 65.272135] [<ffffffff8114c1ea>] ? cap_sk_getsecid+0x0/0x1
> > [ 65.272135] [<ffffffff812a0b0f>] ? __xfrm_lookup+0x2/0xb04
> > [ 65.272135] [<ffffffff81264b8d>] ? ip_route_output_flow+0x77/0x1cc
> > [ 65.272135] [<ffffffff812887c6>] ? udp_sendmsg+0x32d/0x5f3
> > [ 65.272135] [<ffffffff81009400>] ? irq_entries_start+0x3c0/0x400
> > [ 65.272135] [<ffffffff8128e112>] ? inet_sendmsg+0x53/0x58
> > [ 65.272135] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> > [ 65.272135] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> > [ 65.272135] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 65.272135] [<ffffffff81185d4b>] ? _copy_from_user+0x1b/0x30
> > [ 65.272135] [<ffffffff8100765f>] ? __switch_to+0x1b5/0x2a6
> > [ 65.272135] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> > [ 65.272135] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> > [ 65.272135] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> > [ 65.272135] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 65.272135] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
> > [ 65.272135] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 84
> > 00 00 00 48 89 ef e8 f4 e2 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
> > 00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 fb 57 fd ff 48 8b 4c 24 18 4c
> > 8b 47
> > [ 65.272135] RIP [<ffffffff810e0d6b>] kfree+0x55/0xc6
> > [ 65.272135] RSP <ffff880001a23d90>
> > [ 65.385803] ---[ end trace 42d2fb5b94980ab5 ]---
> > [ 65.386337] Kernel panic - not syncing: Fatal exception in interrupt
> > [ 65.386943] Pid: 1518, comm: udp-perf Tainted: G D 2.6.34-rc5 #1
> > [ 65.387557] Call Trace:
> > [ 65.388011] <IRQ> [<ffffffff812eef9b>] ? panic+0x77/0xf7
> > [ 65.388729] [<ffffffff81046b88>] ? kmsg_dump+0xa6/0x13e
> > [ 65.389292] [<ffffffff8100c8c2>] ? oops_end+0xa7/0xb4
> > [ 65.389871] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 65.390441] [<ffffffff8100a695>] ? do_invalid_op+0x8b/0x95
> > [ 65.391032] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> > [ 65.391587] [<ffffffffa026f301>] ?
> > br_nf_pre_routing_finish+0x0/0x25e [bridge]
> > [ 65.392512] [<ffffffffa026f301>] ?
> > br_nf_pre_routing_finish+0x0/0x25e [bridge]
> > [ 65.393399] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
> > [ 65.393978] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 65.394547] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> > [ 65.395091] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 65.395668] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> > [ 65.396438] [<ffffffffa028057d>] ? veth_xmit+0x6e/0xad [veth]
> > [ 65.397026] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> > [ 65.397640] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> > [ 65.398222] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> > [ 65.398788] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> > [ 65.399365] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> > [ 65.399935] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> > [ 65.400560] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> > [ 65.401125] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> > [ 65.401708] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> > [ 65.402267] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> > [ 65.402869] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> > [ 65.403463] <EOI> [<ffffffff8114c1ea>] ? cap_sk_getsecid+0x0/0x1
> > [ 65.404210] [<ffffffff812a0b0f>] ? __xfrm_lookup+0x2/0xb04
> > [ 65.404779] [<ffffffff81264b8d>] ? ip_route_output_flow+0x77/0x1cc
> > [ 65.405375] [<ffffffff812887c6>] ? udp_sendmsg+0x32d/0x5f3
> > [ 65.405945] [<ffffffff81009400>] ? irq_entries_start+0x3c0/0x400
> > [ 65.406534] [<ffffffff8128e112>] ? inet_sendmsg+0x53/0x58
> > [ 65.407102] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> > [ 65.407674] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> > [ 65.408296] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 65.408854] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 65.409468] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 65.410084] [<ffffffff81185d4b>] ? _copy_from_user+0x1b/0x30
> > [ 65.410667] [<ffffffff8100765f>] ? __switch_to+0x1b5/0x2a6
> > [ 65.510031] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> > [ 65.510818] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> > [ 65.511608] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> > [ 65.512465] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 65.513229] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 65.514040] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
> >
> > [ 1438.042568] ------------[ cut here ]------------
> > [ 1438.043170] kernel BUG at mm/slub.c:2846!
> > [ 1438.043711] invalid opcode: 0000 [#1] SMP
> > [ 1438.044531] last sysfs file: /sys/devices/virtual/net/lo/operstate
> > [ 1438.045148] CPU 1
> > [ 1438.045350] Modules linked in: sch_netem veth bridge stp netconsole
> > configfs loop parport_pc tpm_tis tpm snd_pcm psmouse parport tpm_bios
> > snd_timer snd soundcore snd_page_alloc evdev pcspkr serio_raw
> > i2c_piix4 i2c_core button processor ext3 jbd mbcache ide_cd_mod cdrom
> > ide_gd_mod ata_generic ata_piix 8139too libata scsi_mod floppy 8139cp
> > mii thermal thermal_sys piix ide_core [last unloaded: scsi_wait_scan]
> > [ 1438.046215]
> > [ 1438.046215] Pid: 1476, comm: udp-perf Not tainted 2.6.34-rc5 #1 /
> > [ 1438.046215] RIP: 0010:[<ffffffff810e0d6b>] [<ffffffff810e0d6b>]
> > kfree+0x55/0xc6
> > [ 1438.046215] RSP: 0018:ffff880001a23d90 EFLAGS: 00010246
> > [ 1438.046215] RAX: 0100000000000000 RBX: ffff88007d882200 RCX: 0000000000012850
> > [ 1438.046215] RDX: ffff88007d882200 RSI: 000000000000000e RDI: ffffea0001b972a0
> > [ 1438.046215] RBP: ffff88007e20c000 R08: ffff88007d882200 R09: ffffffffa026c690
> > [ 1438.046215] R10: 0000000000000002 R11: ffff88007d882100 R12: ffffffff8123a77f
> > [ 1438.046215] R13: 0000000000000032 R14: ffff8800378e0700 R15: ffff88007d882200
> > [ 1438.046215] FS: 00007f1c1d07f6f0(0000) GS:ffff880001a20000(0000)
> > knlGS:0000000000000000
> > [ 1438.046215] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 1438.046215] CR2: 00007f6ea9e07310 CR3: 0000000037834000 CR4: 00000000000006e0
> > [ 1438.046215] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 1438.046215] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 1438.046215] Process udp-perf (pid: 1476, threadinfo
> > ffff88007db0e000, task ffff8800379a2350)
> > [ 1438.046215] Stack:
> > [ 1438.046215] ffff88007d882200 ffff88007d882200 0000000000000246
> > ffffffff8123a77f
> > [ 1438.046215] <0> ffff880001a32860 ffffffff81241e01 ffffe8ffffa3f430
> > ffffe8ffffa3d180
> > [ 1438.046215] <0> ffff88007d882200 ffffffffa026c57d 0000000201a30500
> > ffff88007d171200
> > [ 1438.046215] Call Trace:
> > [ 1438.046215] <IRQ>
> > [ 1438.046215] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 1438.046215] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> > [ 1438.046215] [<ffffffffa026c57d>] ? veth_xmit+0x6e/0xad [veth]
> > [ 1438.046215] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> > [ 1438.046215] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> > [ 1438.046215] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> > [ 1438.046215] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> > [ 1438.046215] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> > [ 1438.046215] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> > [ 1438.046215] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> > [ 1438.046215] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> > [ 1438.046215] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> > [ 1438.046215] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> > [ 1438.046215] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> > [ 1438.046215] <EOI>
> > [ 1438.046215] [<ffffffff81288499>] ? udp_sendmsg+0x0/0x5f3
> > [ 1438.046215] [<ffffffff8128850f>] ? udp_sendmsg+0x76/0x5f3
> > [ 1438.046215] [<ffffffff812889a7>] ? udp_sendmsg+0x50e/0x5f3
> > [ 1438.046215] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> > [ 1438.046215] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> > [ 1438.046215] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.046215] [<ffffffff810e93ed>] ? fget_light+0x0/0xa1
> > [ 1438.046215] [<ffffffff81185e40>] ? copy_user_generic_string+0x30/0x40
> > [ 1438.046215] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> > [ 1438.046215] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> > [ 1438.046215] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> > [ 1438.046215] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.046215] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
> > [ 1438.046215] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 84
> > 00 00 00 48 89 ef e8 f4 e2 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
> > 00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 fb 57 fd ff 48 8b 4c 24 18 4c
> > 8b 47
> > [ 1438.046215] RIP [<ffffffff810e0d6b>] kfree+0x55/0xc6
> > [ 1438.046215] RSP <ffff880001a23d90>
> > [ 1438.102706] ---[ end trace ab36062dcf233d6a ]---
> > [ 1438.103251] Kernel panic - not syncing: Fatal exception in interrupt
> > [ 1438.103912] Pid: 1476, comm: udp-perf Tainted: G D 2.6.34-rc5 #1
> > [ 1438.104563] Call Trace:
> > [ 1438.105017] <IRQ> [<ffffffff812eef9b>] ? panic+0x77/0xf7
> > [ 1438.105718] [<ffffffff81046b88>] ? kmsg_dump+0xa6/0x13e
> > [ 1438.106293] [<ffffffff8100c8c2>] ? oops_end+0xa7/0xb4
> > [ 1438.106866] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 1438.107451] [<ffffffff8100a695>] ? do_invalid_op+0x8b/0x95
> > [ 1438.108036] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> > [ 1438.108799] [<ffffffffa025b301>] ?
> > br_nf_pre_routing_finish+0x0/0x25e [bridge]
> > [ 1438.109699] [<ffffffffa025b301>] ?
> > br_nf_pre_routing_finish+0x0/0x25e [bridge]
> > [ 1438.110604] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
> > [ 1438.111172] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 1438.111753] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> > [ 1438.112359] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> > [ 1438.112952] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> > [ 1438.113527] [<ffffffffa026c57d>] ? veth_xmit+0x6e/0xad [veth]
> > [ 1438.114123] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> > [ 1438.114734] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> > [ 1438.115334] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> > [ 1438.115912] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> > [ 1438.116544] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> > [ 1438.117128] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> > [ 1438.117732] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> > [ 1438.118420] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> > [ 1438.119066] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> > [ 1438.147879] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> > [ 1438.148615] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> > [ 1438.149294] <EOI> [<ffffffff81288499>] ? udp_sendmsg+0x0/0x5f3
> > [ 1438.150101] [<ffffffff8128850f>] ? udp_sendmsg+0x76/0x5f3
> > [ 1438.150681] [<ffffffff812889a7>] ? udp_sendmsg+0x50e/0x5f3
> > [ 1438.151276] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> > [ 1438.151853] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> > [ 1438.152508] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 1438.153078] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.153687] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.154295] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.154902] [<ffffffff810e93ed>] ? fget_light+0x0/0xa1
> > [ 1438.155477] [<ffffffff81185e40>] ? copy_user_generic_string+0x30/0x40
> > [ 1438.156097] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> > [ 1438.156720] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> > [ 1438.157376] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> > [ 1438.157970] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> > [ 1438.158557] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> > [ 1438.159153] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
> >
> > ------------
> >
> > Finally, a panic in 2.6.33. Note that the line in wioch BUG is
> > triggered is different
> >
> > [ 102.442815] ------------[ cut here ]------------
> > [ 102.443433] kernel BUG at
> > /build/mattems-linux-2.6_2.6.33-1~experimental.4-amd64-ieqSsa/linux-2.6-2.6.33-1~experimental.4/debian/build/source_amd64_none/mm/slub.c:2969!
> > [ 102.444874] invalid opcode: 0000 [#1] SMP
> > [ 102.444958] last sysfs file: /sys/devices/virtual/net/lo/operstate
> > [ 102.444958] CPU 0
> > [ 102.444958] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.33-2-amd64 #1 /
> > [ 102.444958] RIP: 0010:[<ffffffff810e1e2c>] [<ffffffff810e1e2c>]
> > kfree+0x55/0xcb
> > [ 102.444958] RSP: 0018:ffff880001a03df8 EFLAGS: 00010246
> > [ 102.444958] RAX: 0100000000000000 RBX: ffff88007e439000 RCX: 0000000000012d70
> > [ 102.444958] RDX: 000000000000006a RSI: ffffea0001b76a70 RDI: ffffea0000c1a328
> > [ 102.444958] RBP: ffff880037533c00 R08: ffff88007e21e500 R09: ffffffff8162bbe0
> > [ 102.444958] R10: 000000037e439e00 R11: ffff88007e439e00 R12: ffffffff81239cf2
> > [ 102.444958] R13: 000000000000006a R14: ffff88007efb3000 R15: ffff88007e21e500
> > [ 102.444958] FS: 0000000000000000(0000) GS:ffff880001a00000(0000)
> > knlGS:0000000000000000
> > [ 102.444958] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 102.444958] CR2: 00007fc8e25cd0f0 CR3: 000000007d088000 CR4: 00000000000006f0
> > [ 102.444958] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 102.444958] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 102.444958] Process ksoftirqd/0 (pid: 4, threadinfo
> > ffff88007fb78000, task ffff88007fb61500)
> > [ 102.444958] Stack:
> > [ 102.444958] ffff88007e439000 ffff88007e439000 0000000000000246
> > ffffffff81239cf2
> > [ 102.444958] <0> ffff880001a12d80 ffffffff8124125d ffffe8ffff818190
> > ffffe8ffff815ee0
> > [ 102.444958] <0> ffff88007e439000 ffffffffa025254b ffff880001a10010
> > ffff88007ef95200
> > [ 102.444958] Call Trace:
> > [ 102.444958] <IRQ>
> > [ 102.444958] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> > [ 102.444958] [<ffffffff8124125d>] ? netif_rx+0xe2/0xee
> > [ 102.444958] [<ffffffffa025254b>] ? veth_xmit+0x6e/0xad [veth]
> > [ 102.444958] [<ffffffff8124243a>] ? dev_hard_start_xmit+0x221/0x2dc
> > [ 102.444958] [<ffffffff81255514>] ? sch_direct_xmit+0x5b/0x15d
> > [ 102.444958] [<ffffffff812556cf>] ? __qdisc_run+0xb9/0xda
> > [ 102.444958] [<ffffffff8123fa99>] ? net_tx_action+0xd6/0x149
> > [ 102.444958] [<ffffffff8104c918>] ? __do_softirq+0xdd/0x1a1
> > [ 102.444958] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> > [ 102.444958] <EOI>
> > [ 102.444958] [<ffffffff8100b85f>] ? do_softirq+0x3f/0x79
> > [ 102.444958] [<ffffffff8104c504>] ? run_ksoftirqd+0x6a/0x118
> > [ 102.444958] [<ffffffff8104c49a>] ? run_ksoftirqd+0x0/0x118
> > [ 102.444958] [<ffffffff8105ee99>] ? kthread+0x79/0x81
> > [ 102.444958] [<ffffffff810098e4>] ? kernel_thread_helper+0x4/0x10
> > [ 102.444958] [<ffffffff8105ee20>] ? kthread+0x0/0x81
> > [ 102.444958] [<ffffffff810098e0>] ? kernel_thread_helper+0x0/0x10
> > [ 102.444958] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 89
> > 00 00 00 48 89 ef e8 f0 e6 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
> > 00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 45 5a fd ff 48 8b 4c 24 18 4c
> > 8b 4f
> > [ 102.444958] RIP [<ffffffff810e1e2c>] kfree+0x55/0xcb
> > [ 102.444958] RSP <ffff880001a03df8>
> > [ 102.484000] ---[ end trace b1157390d40df1cb ]---
> > [ 102.485018] Kernel panic - not syncing: Fatal exception in interrupt
> > [ 102.485647] Pid: 4, comm: ksoftirqd/0 Tainted: G D 2.6.33-2-amd64 #1
> > [ 102.486630] Call Trace:
> > [ 102.487112] <IRQ> [<ffffffff812ec605>] ? panic+0x86/0x14b
> > [ 102.487870] [<ffffffff8104c799>] ? irq_exit+0x48/0x76
> > [ 102.488474] [<ffffffff812ee893>] ? ret_from_intr+0x0/0x11
> > [ 102.489068] [<ffffffff810478c0>] ? kmsg_dump+0xa6/0x13e
> > [ 102.489661] [<ffffffff8100c89a>] ? oops_end+0xa7/0xb4
> > [ 102.490245] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> > [ 102.490836] [<ffffffff8100a690>] ? do_invalid_op+0x8b/0x95
> > [ 102.491436] [<ffffffff810e1e2c>] ? kfree+0x55/0xcb
> > [ 102.492020] [<ffffffffa0244aee>] ?
> > br_nf_pre_routing_finish+0x284/0x2a6 [bridge]
> > [ 102.492942] [<ffffffffa024486a>] ?
> > br_nf_pre_routing_finish+0x0/0x2a6 [bridge]
> > [ 102.493857] [<ffffffff8125f204>] ? nf_hook_slow+0x62/0xc3
> > [ 102.523082] [<ffffffffa024486a>] ?
> > br_nf_pre_routing_finish+0x0/0x2a6 [bridge]
> > [ 102.524008] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
> > [ 102.524631] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> > [ 102.525225] [<ffffffff810e1e2c>] ? kfree+0x55/0xcb
> > [ 102.525795] [<ffffffff810e1e1c>] ? kfree+0x45/0xcb
> > [ 102.526402] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> > [ 102.526992] [<ffffffff8124125d>] ? netif_rx+0xe2/0xee
> > [ 102.527576] [<ffffffffa025254b>] ? veth_xmit+0x6e/0xad [veth]
> > [ 102.528199] [<ffffffff8124243a>] ? dev_hard_start_xmit+0x221/0x2dc
> > [ 102.528821] [<ffffffff81255514>] ? sch_direct_xmit+0x5b/0x15d
> > [ 102.529429] [<ffffffff812556cf>] ? __qdisc_run+0xb9/0xda
> > [ 102.530018] [<ffffffff8123fa99>] ? net_tx_action+0xd6/0x149
> > [ 102.530618] [<ffffffff8104c918>] ? __do_softirq+0xdd/0x1a1
> > [ 102.531214] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> > [ 102.531804] <EOI> [<ffffffff8100b85f>] ? do_softirq+0x3f/0x79
> > [ 102.532572] [<ffffffff8104c504>] ? run_ksoftirqd+0x6a/0x118
> > [ 102.533169] [<ffffffff8104c49a>] ? run_ksoftirqd+0x0/0x118
> > [ 102.533764] [<ffffffff8105ee99>] ? kthread+0x79/0x81
> > [ 102.534340] [<ffffffff810098e4>] ? kernel_thread_helper+0x4/0x10
> > [ 102.534954] [<ffffffff8105ee20>] ? kthread+0x0/0x81
> > [ 102.535526] [<ffffffff810098e0>] ? kernel_thread_helper+0x0/0x10
> >
>
> Could you please try following patch ?
>
> Thanks
>
> [PATCH] veth: Dont kfree_skb() after dev_forward_skb()
>
> In case of congestion, dev_forward_skb() already free the skb
>
> Reported-by: Martín Ferrari <martin.ferrari@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index f9f0730..5ec542d 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -187,7 +187,6 @@ tx_drop:
> return NETDEV_TX_OK;
>
> rx_drop:
> - kfree_skb(skb);
> rcv_stats->rx_dropped++;
> return NETDEV_TX_OK;
> }
>
Hmm, scratch that one, I'll resubmit a proper fix in few minutes
(We must change dev_forward_skb() too)
^ permalink raw reply
* Re: kernel panic when using netns+bridges+tc(netem)
From: Eric Dumazet @ 2010-05-06 6:40 UTC (permalink / raw)
To: Martín Ferrari; +Cc: netdev, Mathieu Lacage, David Miller
In-Reply-To: <o2wb9800b71005051801uc575c6abp5bad3bd50d54ef96@mail.gmail.com>
Le jeudi 06 mai 2010 à 03:01 +0200, Martín Ferrari a écrit :
> Hi there,
>
> While working on my project that uses netns, I found another bug. This
> one causes a "Kernel panic - not syncing: Fatal exception in
> interrupt", and I can reproduce it in 2.6.33 and 2.6.34-rc5, but not
> in 2.6.32. It dies during a call to __free_skb.
> I tested this on my x86_64 laptop (2 cores) and on qemu. In qemu it
> was not triggered until I asked it to emulate 2 cpus instead of one,
> so it is probably a SMP-only issue.
>
> Scenario:
>
> I set up a number of network namespaces, each with two veths to netns
> 1. In the main namespace I take those veths and bridge them in pairs,
> to configure a linear topology; also I configure the netem qdisc to
> simulate link delay.
>
> Once the network is set up, I run a client/server program to send UDP
> packets from one end of the topology to the other. After a few seconds
> of sending packets (not really deterministic) it panics.
>
> Note that I didn't experience this problem when using only 2
> namespaces (so, no routing)
>
> below the dumps. These all come from the qemu, as I couldn't use
> netconsole in the network at work, but I checked and the backtraces
> were essentially the same
>
> First, two panics with 2.6.34, each one with a slightly different backtrace
>
> [ 65.272131] ------------[ cut here ]------------
> [ 65.272135] kernel BUG at mm/slub.c:2846!
> [ 65.272135] invalid opcode: 0000 [#1] SMP
> [ 65.272135] last sysfs file: /sys/devices/virtual/net/lo/operstate
> [ 65.272135] CPU 1
> [ 65.272135] Modules linked in: sch_netem veth bridge stp netconsole
> configfs loop parport_pc parport evdev tpm_tis tpm snd_pcm tpm_bios
> snd_timer snd soundcore snd_page_alloc pcspkr psmouse serio_raw
> i2c_piix4 button i2c_core processor ext3 jbd mbcache ide_cd_mod cdrom
> ide_gd_mod ata_generic ata_piix libata 8139too scsi_mod floppy piix
> 8139cp mii ide_core thermal thermal_sys [last unloaded: configfs]
> [ 65.272135]
> [ 65.272135] Pid: 1518, comm: udp-perf Not tainted 2.6.34-rc5 #1 /
> [ 65.272135] RIP: 0010:[<ffffffff810e0d6b>] [<ffffffff810e0d6b>]
> kfree+0x55/0xc6
> [ 65.272135] RSP: 0018:ffff880001a23d90 EFLAGS: 00010246
> [ 65.272135] RAX: 0100000000000000 RBX: ffff88007d6bc600 RCX: 0000000000012850
> [ 65.272135] RDX: ffff88007d6bc600 RSI: 000000000000000e RDI: ffffea0001b6f610
> [ 65.272135] RBP: ffff88007d6ae200 R08: ffff88007d6bc600 R09: ffffffffa0280690
> [ 65.272135] R10: 0000000000000002 R11: ffff88007d6bc500 R12: ffffffff8123a77f
> [ 65.272135] R13: 000000000000002b R14: ffff88007d39b600 R15: ffff88007d6bc600
> [ 65.272135] FS: 00007f637c9dd6f0(0000) GS:ffff880001a20000(0000)
> knlGS:0000000000000000
> [ 65.272135] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 65.272135] CR2: 00000000009deaa0 CR3: 000000007d82d000 CR4: 00000000000006e0
> [ 65.272135] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 65.272135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 65.272135] Process udp-perf (pid: 1518, threadinfo
> ffff88007d92a000, task ffff88007e7ff810)
> [ 65.272135] Stack:
> [ 65.272135] ffff88007d6bc600 ffff88007d6bc600 0000000000000246
> ffffffff8123a77f
> [ 65.272135] <0> ffff880001a32860 ffffffff81241e01 ffffe8ffff623280
> ffffe8ffff83ffc0
> [ 65.272135] <0> ffff88007d6bc600 ffffffffa028057d 000000027d4c06c8
> ffff88007d4c0600
> [ 65.272135] Call Trace:
> [ 65.272135] <IRQ>
> [ 65.272135] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 65.272135] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> [ 65.272135] [<ffffffffa028057d>] ? veth_xmit+0x6e/0xad [veth]
> [ 65.272135] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> [ 65.272135] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> [ 65.272135] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> [ 65.272135] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> [ 65.272135] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> [ 65.272135] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> [ 65.272135] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> [ 65.272135] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> [ 65.272135] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> [ 65.272135] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> [ 65.272135] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> [ 65.272135] <EOI>
> [ 65.272135] [<ffffffff8114c1ea>] ? cap_sk_getsecid+0x0/0x1
> [ 65.272135] [<ffffffff812a0b0f>] ? __xfrm_lookup+0x2/0xb04
> [ 65.272135] [<ffffffff81264b8d>] ? ip_route_output_flow+0x77/0x1cc
> [ 65.272135] [<ffffffff812887c6>] ? udp_sendmsg+0x32d/0x5f3
> [ 65.272135] [<ffffffff81009400>] ? irq_entries_start+0x3c0/0x400
> [ 65.272135] [<ffffffff8128e112>] ? inet_sendmsg+0x53/0x58
> [ 65.272135] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> [ 65.272135] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> [ 65.272135] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 65.272135] [<ffffffff81185d4b>] ? _copy_from_user+0x1b/0x30
> [ 65.272135] [<ffffffff8100765f>] ? __switch_to+0x1b5/0x2a6
> [ 65.272135] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> [ 65.272135] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> [ 65.272135] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> [ 65.272135] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 65.272135] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 65.272135] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
> [ 65.272135] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 84
> 00 00 00 48 89 ef e8 f4 e2 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
> 00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 fb 57 fd ff 48 8b 4c 24 18 4c
> 8b 47
> [ 65.272135] RIP [<ffffffff810e0d6b>] kfree+0x55/0xc6
> [ 65.272135] RSP <ffff880001a23d90>
> [ 65.385803] ---[ end trace 42d2fb5b94980ab5 ]---
> [ 65.386337] Kernel panic - not syncing: Fatal exception in interrupt
> [ 65.386943] Pid: 1518, comm: udp-perf Tainted: G D 2.6.34-rc5 #1
> [ 65.387557] Call Trace:
> [ 65.388011] <IRQ> [<ffffffff812eef9b>] ? panic+0x77/0xf7
> [ 65.388729] [<ffffffff81046b88>] ? kmsg_dump+0xa6/0x13e
> [ 65.389292] [<ffffffff8100c8c2>] ? oops_end+0xa7/0xb4
> [ 65.389871] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 65.390441] [<ffffffff8100a695>] ? do_invalid_op+0x8b/0x95
> [ 65.391032] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> [ 65.391587] [<ffffffffa026f301>] ?
> br_nf_pre_routing_finish+0x0/0x25e [bridge]
> [ 65.392512] [<ffffffffa026f301>] ?
> br_nf_pre_routing_finish+0x0/0x25e [bridge]
> [ 65.393399] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
> [ 65.393978] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 65.394547] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> [ 65.395091] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 65.395668] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> [ 65.396438] [<ffffffffa028057d>] ? veth_xmit+0x6e/0xad [veth]
> [ 65.397026] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> [ 65.397640] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> [ 65.398222] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> [ 65.398788] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> [ 65.399365] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> [ 65.399935] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> [ 65.400560] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> [ 65.401125] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> [ 65.401708] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> [ 65.402267] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> [ 65.402869] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> [ 65.403463] <EOI> [<ffffffff8114c1ea>] ? cap_sk_getsecid+0x0/0x1
> [ 65.404210] [<ffffffff812a0b0f>] ? __xfrm_lookup+0x2/0xb04
> [ 65.404779] [<ffffffff81264b8d>] ? ip_route_output_flow+0x77/0x1cc
> [ 65.405375] [<ffffffff812887c6>] ? udp_sendmsg+0x32d/0x5f3
> [ 65.405945] [<ffffffff81009400>] ? irq_entries_start+0x3c0/0x400
> [ 65.406534] [<ffffffff8128e112>] ? inet_sendmsg+0x53/0x58
> [ 65.407102] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> [ 65.407674] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> [ 65.408296] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 65.408854] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 65.409468] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 65.410084] [<ffffffff81185d4b>] ? _copy_from_user+0x1b/0x30
> [ 65.410667] [<ffffffff8100765f>] ? __switch_to+0x1b5/0x2a6
> [ 65.510031] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> [ 65.510818] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> [ 65.511608] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> [ 65.512465] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 65.513229] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 65.514040] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
>
> [ 1438.042568] ------------[ cut here ]------------
> [ 1438.043170] kernel BUG at mm/slub.c:2846!
> [ 1438.043711] invalid opcode: 0000 [#1] SMP
> [ 1438.044531] last sysfs file: /sys/devices/virtual/net/lo/operstate
> [ 1438.045148] CPU 1
> [ 1438.045350] Modules linked in: sch_netem veth bridge stp netconsole
> configfs loop parport_pc tpm_tis tpm snd_pcm psmouse parport tpm_bios
> snd_timer snd soundcore snd_page_alloc evdev pcspkr serio_raw
> i2c_piix4 i2c_core button processor ext3 jbd mbcache ide_cd_mod cdrom
> ide_gd_mod ata_generic ata_piix 8139too libata scsi_mod floppy 8139cp
> mii thermal thermal_sys piix ide_core [last unloaded: scsi_wait_scan]
> [ 1438.046215]
> [ 1438.046215] Pid: 1476, comm: udp-perf Not tainted 2.6.34-rc5 #1 /
> [ 1438.046215] RIP: 0010:[<ffffffff810e0d6b>] [<ffffffff810e0d6b>]
> kfree+0x55/0xc6
> [ 1438.046215] RSP: 0018:ffff880001a23d90 EFLAGS: 00010246
> [ 1438.046215] RAX: 0100000000000000 RBX: ffff88007d882200 RCX: 0000000000012850
> [ 1438.046215] RDX: ffff88007d882200 RSI: 000000000000000e RDI: ffffea0001b972a0
> [ 1438.046215] RBP: ffff88007e20c000 R08: ffff88007d882200 R09: ffffffffa026c690
> [ 1438.046215] R10: 0000000000000002 R11: ffff88007d882100 R12: ffffffff8123a77f
> [ 1438.046215] R13: 0000000000000032 R14: ffff8800378e0700 R15: ffff88007d882200
> [ 1438.046215] FS: 00007f1c1d07f6f0(0000) GS:ffff880001a20000(0000)
> knlGS:0000000000000000
> [ 1438.046215] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1438.046215] CR2: 00007f6ea9e07310 CR3: 0000000037834000 CR4: 00000000000006e0
> [ 1438.046215] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1438.046215] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1438.046215] Process udp-perf (pid: 1476, threadinfo
> ffff88007db0e000, task ffff8800379a2350)
> [ 1438.046215] Stack:
> [ 1438.046215] ffff88007d882200 ffff88007d882200 0000000000000246
> ffffffff8123a77f
> [ 1438.046215] <0> ffff880001a32860 ffffffff81241e01 ffffe8ffffa3f430
> ffffe8ffffa3d180
> [ 1438.046215] <0> ffff88007d882200 ffffffffa026c57d 0000000201a30500
> ffff88007d171200
> [ 1438.046215] Call Trace:
> [ 1438.046215] <IRQ>
> [ 1438.046215] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 1438.046215] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> [ 1438.046215] [<ffffffffa026c57d>] ? veth_xmit+0x6e/0xad [veth]
> [ 1438.046215] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> [ 1438.046215] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> [ 1438.046215] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> [ 1438.046215] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> [ 1438.046215] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> [ 1438.046215] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> [ 1438.046215] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> [ 1438.046215] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> [ 1438.046215] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> [ 1438.046215] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> [ 1438.046215] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> [ 1438.046215] <EOI>
> [ 1438.046215] [<ffffffff81288499>] ? udp_sendmsg+0x0/0x5f3
> [ 1438.046215] [<ffffffff8128850f>] ? udp_sendmsg+0x76/0x5f3
> [ 1438.046215] [<ffffffff812889a7>] ? udp_sendmsg+0x50e/0x5f3
> [ 1438.046215] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> [ 1438.046215] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> [ 1438.046215] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.046215] [<ffffffff810e93ed>] ? fget_light+0x0/0xa1
> [ 1438.046215] [<ffffffff81185e40>] ? copy_user_generic_string+0x30/0x40
> [ 1438.046215] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> [ 1438.046215] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> [ 1438.046215] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> [ 1438.046215] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 1438.046215] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.046215] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
> [ 1438.046215] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 84
> 00 00 00 48 89 ef e8 f4 e2 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
> 00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 fb 57 fd ff 48 8b 4c 24 18 4c
> 8b 47
> [ 1438.046215] RIP [<ffffffff810e0d6b>] kfree+0x55/0xc6
> [ 1438.046215] RSP <ffff880001a23d90>
> [ 1438.102706] ---[ end trace ab36062dcf233d6a ]---
> [ 1438.103251] Kernel panic - not syncing: Fatal exception in interrupt
> [ 1438.103912] Pid: 1476, comm: udp-perf Tainted: G D 2.6.34-rc5 #1
> [ 1438.104563] Call Trace:
> [ 1438.105017] <IRQ> [<ffffffff812eef9b>] ? panic+0x77/0xf7
> [ 1438.105718] [<ffffffff81046b88>] ? kmsg_dump+0xa6/0x13e
> [ 1438.106293] [<ffffffff8100c8c2>] ? oops_end+0xa7/0xb4
> [ 1438.106866] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 1438.107451] [<ffffffff8100a695>] ? do_invalid_op+0x8b/0x95
> [ 1438.108036] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> [ 1438.108799] [<ffffffffa025b301>] ?
> br_nf_pre_routing_finish+0x0/0x25e [bridge]
> [ 1438.109699] [<ffffffffa025b301>] ?
> br_nf_pre_routing_finish+0x0/0x25e [bridge]
> [ 1438.110604] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
> [ 1438.111172] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 1438.111753] [<ffffffff810e0d6b>] ? kfree+0x55/0xc6
> [ 1438.112359] [<ffffffff8123a77f>] ? __kfree_skb+0x11/0x7d
> [ 1438.112952] [<ffffffff81241e01>] ? netif_rx+0xe2/0xee
> [ 1438.113527] [<ffffffffa026c57d>] ? veth_xmit+0x6e/0xad [veth]
> [ 1438.114123] [<ffffffff8124301f>] ? dev_hard_start_xmit+0x221/0x301
> [ 1438.114734] [<ffffffff81256d9a>] ? sch_direct_xmit+0x5b/0x15d
> [ 1438.115334] [<ffffffff81256f55>] ? __qdisc_run+0xb9/0xd8
> [ 1438.115912] [<ffffffff81240511>] ? net_tx_action+0xd6/0x149
> [ 1438.116544] [<ffffffff8104ba02>] ? __do_softirq+0xdd/0x19f
> [ 1438.117128] [<ffffffff8101e515>] ? lapic_next_event+0x18/0x1d
> [ 1438.117732] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> [ 1438.118420] [<ffffffff8100b863>] ? do_softirq+0x3f/0x79
> [ 1438.119066] [<ffffffff8104b88e>] ? irq_exit+0x36/0x76
> [ 1438.147879] [<ffffffff8101f000>] ? smp_apic_timer_interrupt+0x86/0x94
> [ 1438.148615] [<ffffffff81009493>] ? apic_timer_interrupt+0x13/0x20
> [ 1438.149294] <EOI> [<ffffffff81288499>] ? udp_sendmsg+0x0/0x5f3
> [ 1438.150101] [<ffffffff8128850f>] ? udp_sendmsg+0x76/0x5f3
> [ 1438.150681] [<ffffffff812889a7>] ? udp_sendmsg+0x50e/0x5f3
> [ 1438.151276] [<ffffffff8123388d>] ? sock_sendmsg+0x83/0x9b
> [ 1438.151853] [<ffffffff8103a042>] ? pick_next_task_fair+0xca/0xd6
> [ 1438.152508] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 1438.153078] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.153687] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.154295] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.154902] [<ffffffff810e93ed>] ? fget_light+0x0/0xa1
> [ 1438.155477] [<ffffffff81185e40>] ? copy_user_generic_string+0x30/0x40
> [ 1438.156097] [<ffffffff81232227>] ? copy_from_user+0x13/0x25
> [ 1438.156720] [<ffffffff812353cb>] ? sys_sendto+0xd7/0x117
> [ 1438.157376] [<ffffffff8103f7b1>] ? finish_task_switch+0x34/0xa1
> [ 1438.157970] [<ffffffff812ef74a>] ? schedule+0x52b/0x593
> [ 1438.158557] [<ffffffff8100948e>] ? apic_timer_interrupt+0xe/0x20
> [ 1438.159153] [<ffffffff81008ac2>] ? system_call_fastpath+0x16/0x1b
>
> ------------
>
> Finally, a panic in 2.6.33. Note that the line in wioch BUG is
> triggered is different
>
> [ 102.442815] ------------[ cut here ]------------
> [ 102.443433] kernel BUG at
> /build/mattems-linux-2.6_2.6.33-1~experimental.4-amd64-ieqSsa/linux-2.6-2.6.33-1~experimental.4/debian/build/source_amd64_none/mm/slub.c:2969!
> [ 102.444874] invalid opcode: 0000 [#1] SMP
> [ 102.444958] last sysfs file: /sys/devices/virtual/net/lo/operstate
> [ 102.444958] CPU 0
> [ 102.444958] Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.33-2-amd64 #1 /
> [ 102.444958] RIP: 0010:[<ffffffff810e1e2c>] [<ffffffff810e1e2c>]
> kfree+0x55/0xcb
> [ 102.444958] RSP: 0018:ffff880001a03df8 EFLAGS: 00010246
> [ 102.444958] RAX: 0100000000000000 RBX: ffff88007e439000 RCX: 0000000000012d70
> [ 102.444958] RDX: 000000000000006a RSI: ffffea0001b76a70 RDI: ffffea0000c1a328
> [ 102.444958] RBP: ffff880037533c00 R08: ffff88007e21e500 R09: ffffffff8162bbe0
> [ 102.444958] R10: 000000037e439e00 R11: ffff88007e439e00 R12: ffffffff81239cf2
> [ 102.444958] R13: 000000000000006a R14: ffff88007efb3000 R15: ffff88007e21e500
> [ 102.444958] FS: 0000000000000000(0000) GS:ffff880001a00000(0000)
> knlGS:0000000000000000
> [ 102.444958] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 102.444958] CR2: 00007fc8e25cd0f0 CR3: 000000007d088000 CR4: 00000000000006f0
> [ 102.444958] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 102.444958] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 102.444958] Process ksoftirqd/0 (pid: 4, threadinfo
> ffff88007fb78000, task ffff88007fb61500)
> [ 102.444958] Stack:
> [ 102.444958] ffff88007e439000 ffff88007e439000 0000000000000246
> ffffffff81239cf2
> [ 102.444958] <0> ffff880001a12d80 ffffffff8124125d ffffe8ffff818190
> ffffe8ffff815ee0
> [ 102.444958] <0> ffff88007e439000 ffffffffa025254b ffff880001a10010
> ffff88007ef95200
> [ 102.444958] Call Trace:
> [ 102.444958] <IRQ>
> [ 102.444958] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> [ 102.444958] [<ffffffff8124125d>] ? netif_rx+0xe2/0xee
> [ 102.444958] [<ffffffffa025254b>] ? veth_xmit+0x6e/0xad [veth]
> [ 102.444958] [<ffffffff8124243a>] ? dev_hard_start_xmit+0x221/0x2dc
> [ 102.444958] [<ffffffff81255514>] ? sch_direct_xmit+0x5b/0x15d
> [ 102.444958] [<ffffffff812556cf>] ? __qdisc_run+0xb9/0xda
> [ 102.444958] [<ffffffff8123fa99>] ? net_tx_action+0xd6/0x149
> [ 102.444958] [<ffffffff8104c918>] ? __do_softirq+0xdd/0x1a1
> [ 102.444958] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> [ 102.444958] <EOI>
> [ 102.444958] [<ffffffff8100b85f>] ? do_softirq+0x3f/0x79
> [ 102.444958] [<ffffffff8104c504>] ? run_ksoftirqd+0x6a/0x118
> [ 102.444958] [<ffffffff8104c49a>] ? run_ksoftirqd+0x0/0x118
> [ 102.444958] [<ffffffff8105ee99>] ? kthread+0x79/0x81
> [ 102.444958] [<ffffffff810098e4>] ? kernel_thread_helper+0x4/0x10
> [ 102.444958] [<ffffffff8105ee20>] ? kthread+0x0/0x81
> [ 102.444958] [<ffffffff810098e0>] ? kernel_thread_helper+0x0/0x10
> [ 102.444958] Code: 83 c3 08 48 83 3b 00 eb ec 48 83 fd 10 0f 86 89
> 00 00 00 48 89 ef e8 f0 e6 ff ff 48 89 c7 48 8b 00 84 c0 78 13 66 a9
> 00 c0 75 04 <0f> 0b eb fe 5b 5d 41 5c e9 45 5a fd ff 48 8b 4c 24 18 4c
> 8b 4f
> [ 102.444958] RIP [<ffffffff810e1e2c>] kfree+0x55/0xcb
> [ 102.444958] RSP <ffff880001a03df8>
> [ 102.484000] ---[ end trace b1157390d40df1cb ]---
> [ 102.485018] Kernel panic - not syncing: Fatal exception in interrupt
> [ 102.485647] Pid: 4, comm: ksoftirqd/0 Tainted: G D 2.6.33-2-amd64 #1
> [ 102.486630] Call Trace:
> [ 102.487112] <IRQ> [<ffffffff812ec605>] ? panic+0x86/0x14b
> [ 102.487870] [<ffffffff8104c799>] ? irq_exit+0x48/0x76
> [ 102.488474] [<ffffffff812ee893>] ? ret_from_intr+0x0/0x11
> [ 102.489068] [<ffffffff810478c0>] ? kmsg_dump+0xa6/0x13e
> [ 102.489661] [<ffffffff8100c89a>] ? oops_end+0xa7/0xb4
> [ 102.490245] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> [ 102.490836] [<ffffffff8100a690>] ? do_invalid_op+0x8b/0x95
> [ 102.491436] [<ffffffff810e1e2c>] ? kfree+0x55/0xcb
> [ 102.492020] [<ffffffffa0244aee>] ?
> br_nf_pre_routing_finish+0x284/0x2a6 [bridge]
> [ 102.492942] [<ffffffffa024486a>] ?
> br_nf_pre_routing_finish+0x0/0x2a6 [bridge]
> [ 102.493857] [<ffffffff8125f204>] ? nf_hook_slow+0x62/0xc3
> [ 102.523082] [<ffffffffa024486a>] ?
> br_nf_pre_routing_finish+0x0/0x2a6 [bridge]
> [ 102.524008] [<ffffffff8100975b>] ? invalid_op+0x1b/0x20
> [ 102.524631] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> [ 102.525225] [<ffffffff810e1e2c>] ? kfree+0x55/0xcb
> [ 102.525795] [<ffffffff810e1e1c>] ? kfree+0x45/0xcb
> [ 102.526402] [<ffffffff81239cf2>] ? __kfree_skb+0x11/0x7d
> [ 102.526992] [<ffffffff8124125d>] ? netif_rx+0xe2/0xee
> [ 102.527576] [<ffffffffa025254b>] ? veth_xmit+0x6e/0xad [veth]
> [ 102.528199] [<ffffffff8124243a>] ? dev_hard_start_xmit+0x221/0x2dc
> [ 102.528821] [<ffffffff81255514>] ? sch_direct_xmit+0x5b/0x15d
> [ 102.529429] [<ffffffff812556cf>] ? __qdisc_run+0xb9/0xda
> [ 102.530018] [<ffffffff8123fa99>] ? net_tx_action+0xd6/0x149
> [ 102.530618] [<ffffffff8104c918>] ? __do_softirq+0xdd/0x1a1
> [ 102.531214] [<ffffffff810099dc>] ? call_softirq+0x1c/0x30
> [ 102.531804] <EOI> [<ffffffff8100b85f>] ? do_softirq+0x3f/0x79
> [ 102.532572] [<ffffffff8104c504>] ? run_ksoftirqd+0x6a/0x118
> [ 102.533169] [<ffffffff8104c49a>] ? run_ksoftirqd+0x0/0x118
> [ 102.533764] [<ffffffff8105ee99>] ? kthread+0x79/0x81
> [ 102.534340] [<ffffffff810098e4>] ? kernel_thread_helper+0x4/0x10
> [ 102.534954] [<ffffffff8105ee20>] ? kthread+0x0/0x81
> [ 102.535526] [<ffffffff810098e0>] ? kernel_thread_helper+0x0/0x10
>
Could you please try following patch ?
Thanks
[PATCH] veth: Dont kfree_skb() after dev_forward_skb()
In case of congestion, dev_forward_skb() already free the skb
Reported-by: Martín Ferrari <martin.ferrari@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index f9f0730..5ec542d 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -187,7 +187,6 @@ tx_drop:
return NETDEV_TX_OK;
rx_drop:
- kfree_skb(skb);
rcv_stats->rx_dropped++;
return NETDEV_TX_OK;
}
^ permalink raw reply related
* Re: virtio: put last_used and last_avail index into ring itself.
From: Michael S. Tsirkin @ 2010-05-06 6:27 UTC (permalink / raw)
To: Rusty Russell
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, s.hetze, Daniel Walker, Eric Dumazet
In-Reply-To: <201005061022.13815.rusty@rustcorp.com.au>
On Thu, May 06, 2010 at 10:22:12AM +0930, Rusty Russell wrote:
> On Wed, 5 May 2010 03:52:36 am Michael S. Tsirkin wrote:
> > > virtio: put last_used and last_avail index into ring itself.
> > >
> > > Generally, the other end of the virtio ring doesn't need to see where
> > > you're up to in consuming the ring. However, to completely understand
> > > what's going on from the outside, this information must be exposed.
> > > For example, if you want to save and restore a virtio_ring, but you're
> > > not the consumer because the kernel is using it directly.
> > >
> > > Fortunately, we have room to expand: the ring is always a whole number
> > > of pages and there's hundreds of bytes of padding after the avail ring
> > > and the used ring, whatever the number of descriptors (which must be a
> > > power of 2).
> > >
> > > We add a feature bit so the guest can tell the host that it's writing
> > > out the current value there, if it wants to use that.
> > >
> > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
> >
> > I've been looking at this patch some more (more on why
> > later), and I wonder: would it be better to add some
> > alignment to the last used index address, so that
> > if we later add more stuff at the tail, it all
> > fits in a single cache line?
>
> In theory, but not in practice. We don't have many rings, so the
> difference between 1 and 2 cache lines is not very much.
Fair enough.
> > We use a new feature bit anyway, so layout change should not be
> > a problem.
> >
> > Since I raised the question of caches: for used ring,
> > the ring is not aligned to 64 bit, so on CPUs with 64 bit
> > or larger cache lines, used entries will often cross
> > cache line boundaries. Am I right and might it
> > have been better to align ring entries to cache line boundaries?
> >
> > What do you think?
>
> I think everyone is settled on 128 byte cache lines for the forseeable
> future, so it's not really an issue.
>
> Cheers,
> Rusty.
You mean with 64 bit descriptors we will be bouncing a cache line
between host and guest, anyway?
--
MST
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: linux-next: manual merge of the staging-next tree with the net tree
From: Greg KH @ 2010-05-06 6:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Prashant P. Shah, Jiri Pirko,
David Miller, netdev
In-Reply-To: <20100506142139.c1b1c1c3.sfr@canb.auug.org.au>
On Thu, May 06, 2010 at 02:21:39PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Wed, 5 May 2010 21:20:48 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > Thanks for doing this. Hm, the arlan driver is scheduled to be deleted
> > in .35, so it would make things easier if I just do it now to keep these
> > kinds of merge issues from happening. I'll queue that up tomorrow.
>
> Ah, yes, that would be easier. Thanks.
It is now deleted, along with 3 other drivers that were scheduled to be
deleted in .35, so you will not have any merge issues with them anymore.
thanks,
greg k-h
^ permalink raw reply
* Re: 3 packet TCP window limit?
From: Lars Eggert @ 2010-05-06 6:15 UTC (permalink / raw)
To: dormando; +Cc: Rick Jones, Brian Bloniarz, netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.00.1005051421010.28957@d>
[-- Attachment #1: Type: text/plain, Size: 1459 bytes --]
Hi,
On 2010-5-5, at 23:31, dormando wrote:
> The RFC clearly states "around 4k",
no, it doesn't. RFC3390 gives a very precise formula for calculating the initial window:
min (4*MSS, max (2*MSS, 4380 bytes))
Please see the RFC for why. More reading at http://www.icir.org/floyd/tcp_init_win.html I believe that Linux implements behavior this pretty faithfully.
> but these other OS's/products have an
> extra kilobyte snuck in? Could this be on purpose via rfc
> interpretation, or an off by one on the initcwnd estimator? :)
I'm surprised to hear that OpenBSD doesn't follow the RFC. Can you share a measurement? Are you sure the box you are measuring is using the default configuration?
I don't think the RFC can be misread (it's pretty clear), and the formula is also not exactly complicated. My guess would be that some vendors have convinced themselves that using a slightly larger value is OK, esp. if they can show customers that "their" TCP is "faster" than some competitors' TCPs. An arms race between vendors in this space would really not be good for anyone - it's clear that at some point, problems due to overshoot will occur.
(We can definitely argue about whether the current RFC-recommended value is too low, and Google and others are gathering data in support of making a convincing and backed-up argument for increasing the initial window to the IETF. Which is exactly the correct way of going about this.)
Lars
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2490 bytes --]
^ permalink raw reply
* [net-next-2.6 PATCH 3/3] ixgbevf: Cache PF ack bit in interrupt
From: Jeff Kirsher @ 2010-05-06 5:57 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
In-Reply-To: <20100506055703.8482.16515.stgit@localhost.localdomain>
From: Greg Rose <gregory.v.rose@intel.com>
When the PF acks a message from the VF the VF gets an interrupt. It
must cache the ack bit so that polling SW will not miss the ack. Also
avoid reading the message buffer on acks because that also will clear
the ack bit.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbevf/ixgbevf_main.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c
index 0870740..460c37f 100644
--- a/drivers/net/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ixgbevf/ixgbevf_main.c
@@ -961,12 +961,28 @@ static irqreturn_t ixgbevf_msix_mbx(int irq, void *data)
eicr = IXGBE_READ_REG(hw, IXGBE_VTEICS);
IXGBE_WRITE_REG(hw, IXGBE_VTEICR, eicr);
+ if (!hw->mbx.ops.check_for_ack(hw)) {
+ /*
+ * checking for the ack clears the PFACK bit. Place
+ * it back in the v2p_mailbox cache so that anyone
+ * polling for an ack will not miss it. Also
+ * avoid the read below because the code to read
+ * the mailbox will also clear the ack bit. This was
+ * causing lost acks. Just cache the bit and exit
+ * the IRQ handler.
+ */
+ hw->mbx.v2p_mailbox |= IXGBE_VFMAILBOX_PFACK;
+ goto out;
+ }
+
+ /* Not an ack interrupt, go ahead and read the message */
hw->mbx.ops.read(hw, &msg, 1);
if ((msg & IXGBE_MBVFICR_VFREQ_MASK) == IXGBE_PF_CONTROL_MSG)
mod_timer(&adapter->watchdog_timer,
round_jiffies(jiffies + 1));
+out:
return IRQ_HANDLED;
}
^ permalink raw reply related
* [net-next-2.6 PATCH 2/3] ixgbe: Streamline MC filter setup for VFs
From: Jeff Kirsher @ 2010-05-06 5:57 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
In-Reply-To: <20100506055703.8482.16515.stgit@localhost.localdomain>
From: Greg Rose <gregory.v.rose@intel.com>
The driver was calling the set Rx mode function for every multicast
filter set by the VF. When starting many VMs where each might have
multiple VLAN interfaces this would result in the function being
called hundreds or even thousands of times. This is unnecessary
for the case of the imperfect filters used in the MTA and has been
streamlined to be more efficient.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_sriov.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_sriov.c b/drivers/net/ixgbe/ixgbe_sriov.c
index c4e5150..f6cee94 100644
--- a/drivers/net/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ixgbe/ixgbe_sriov.c
@@ -48,7 +48,11 @@ int ixgbe_set_vf_multicasts(struct ixgbe_adapter *adapter,
int entries, u16 *hash_list, u32 vf)
{
struct vf_data_storage *vfinfo = &adapter->vfinfo[vf];
+ struct ixgbe_hw *hw = &adapter->hw;
int i;
+ u32 vector_bit;
+ u32 vector_reg;
+ u32 mta_reg;
/* only so many hash values supported */
entries = min(entries, IXGBE_MAX_VF_MC_ENTRIES);
@@ -68,8 +72,13 @@ int ixgbe_set_vf_multicasts(struct ixgbe_adapter *adapter,
vfinfo->vf_mc_hashes[i] = hash_list[i];;
}
- /* Flush and reset the mta with the new values */
- ixgbe_set_rx_mode(adapter->netdev);
+ for (i = 0; i < vfinfo->num_vf_mc_hashes; i++) {
+ vector_reg = (vfinfo->vf_mc_hashes[i] >> 5) & 0x7F;
+ vector_bit = vfinfo->vf_mc_hashes[i] & 0x1F;
+ mta_reg = IXGBE_READ_REG(hw, IXGBE_MTA(vector_reg));
+ mta_reg |= (1 << vector_bit);
+ IXGBE_WRITE_REG(hw, IXGBE_MTA(vector_reg), mta_reg);
+ }
return 0;
}
^ permalink raw reply related
* [net-next-2.6 PATCH 1/3] ixgbe: Remove unneeded register writes in VF VLAN setup
From: Jeff Kirsher @ 2010-05-06 5:57 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
From: Greg Rose <gregory.v.rose@intel.com>
The driver is unnecessarily writing values to VLAN control registers.
These writes already done elsewhere and are superfluous here.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_sriov.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_sriov.c b/drivers/net/ixgbe/ixgbe_sriov.c
index 221b2ca..c4e5150 100644
--- a/drivers/net/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ixgbe/ixgbe_sriov.c
@@ -98,17 +98,6 @@ void ixgbe_restore_vf_multicasts(struct ixgbe_adapter *adapter)
int ixgbe_set_vf_vlan(struct ixgbe_adapter *adapter, int add, int vid, u32 vf)
{
- u32 ctrl;
-
- /* Check if global VLAN already set, if not set it */
- ctrl = IXGBE_READ_REG(&adapter->hw, IXGBE_VLNCTRL);
- if (!(ctrl & IXGBE_VLNCTRL_VFE)) {
- /* enable VLAN tag insert/strip */
- ctrl |= IXGBE_VLNCTRL_VFE;
- ctrl &= ~IXGBE_VLNCTRL_CFIEN;
- IXGBE_WRITE_REG(&adapter->hw, IXGBE_VLNCTRL, ctrl);
- }
-
return adapter->hw.mac.ops.set_vfta(&adapter->hw, vid, vf, (bool)add);
}
^ 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