* Re: [PATCH 28/36] net,rcu: convert call_rcu(phonet_device_rcu_free) to kfree_rcu()
From: Rémi Denis-Courmont @ 2011-03-18 8:27 UTC (permalink / raw)
To: ext Lai Jiangshan
Cc: Paul E. McKenney, Ingo Molnar, David S. Miller, netdev,
linux-kernel
In-Reply-To: <4D82DADF.4010802@cn.fujitsu.com>
On Friday 18 March 2011 06:09:03 ext Lai Jiangshan, you wrote:
> The rcu callback phonet_device_rcu_free() just calls a kfree(),
> so we use kfree_rcu() instead of the call_rcu(phonet_device_rcu_free).
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
In principles, that's fine with me. But I think David is not taking that kind
of not-a-fix patch at the moment...
--
Rémi Denis-Courmont
http://www.remlab.net/
^ permalink raw reply
* Re: sctp panic
From: walter schloegl @ 2011-03-18 8:30 UTC (permalink / raw)
To: Wei Yongjun, richard.weinberger; +Cc: netdev, linux-kernel
In-Reply-To: <4D82DA2D.1020503@cn.fujitsu.com>
-------- Original-Nachricht --------
> Datum: Fri, 18 Mar 2011 12:06:05 +0800
> Von: Wei Yongjun <yjwei@cn.fujitsu.com>
> An: richard -rw- weinberger <richard.weinberger@gmail.com>
> CC: walter schloegl <sctp@muskelshirt.de>, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
> Betreff: Re: sctp panic
>
>
> > On Thu, Mar 17, 2011 at 11:49 AM, walter schloegl <sctp@muskelshirt.de>
> wrote:
> >> -------- Original-Nachricht --------
> >>> Datum: Thu, 17 Mar 2011 08:56:47 +0100
> >>> Von: richard -rw- weinberger <richard.weinberger@gmail.com>
> >>> An: sctp@muskelshirt.de
> >>> CC: linux-kernel@vger.kernel.org
> >>> Betreff: Re: sctp panic
> >>> On Thu, Mar 17, 2011 at 8:43 AM, <sctp@muskelshirt.de> wrote:
> >>>> Hi
> >>>>
> >>>> when doing the actions below I get a panic.
> >>>>
> >>>> - echo 1 > /proc/sys/net/sctp/addip_enable
> >>>> - In a C-Programm
> >>>> - socket(AF_INET,SOCK_STREAM,IPPROTO_SCTP);
> >>>> - connect(....) (with correct filled parameters)
> >>>>
> >>>> Its no process (waiting in accept) neccessary
> >>> Can you show us the panic message and your C prorgam?
> >>> This would help reproducing the panic...
> >> ...snip...
> >>
> >> The crash says:
> >>
> >> crash> bt
> >> PID: 14646 TASK: ffff8801f40c7560 CPU: 9 COMMAND: "x"
> >> #0 [ffff8801f6f5f6f0] machine_kexec at ffffffff8103697b
> >> #1 [ffff8801f6f5f750] crash_kexec at ffffffff810b9078
> >> #2 [ffff8801f6f5f820] oops_end at ffffffff814cc900
> >> #3 [ffff8801f6f5f850] die at ffffffff8101733b
> >> #4 [ffff8801f6f5f880] do_trap at ffffffff814cc1d4
> >> #5 [ffff8801f6f5f8e0] do_invalid_op at ffffffff81014ee5
> >> #6 [ffff8801f6f5f980] invalid_op at ffffffff81013f5b
> >> [exception RIP: skb_over_panic+93]
> >> RIP: ffffffff81404bdd RSP: ffff8801f6f5fa38 RFLAGS: 00010296
> >> RAX: 0000000000000083 RBX: 0000000000000040 RCX: 00000000000013f6
> >> RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246
> >> RBP: ffff8801f6f5fa58 R8: ffffffff818a3da0 R9: 0000000000000000
> >> R10: 0000000000000001 R11: 0000000000000000 R12: ffff8801f4e11000
> >> R13: 0000000000000004 R14: 000000000000003e R15: 0000000000000001
> >> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> >> #7 [ffff8801f6f5fa60] skb_put at ffffffff81405c1c
> >> #8 [ffff8801f6f5fa80] sctp_addto_chunk at ffffffffa0503c23
> >> #9 [ffff8801f6f5fad0] sctp_make_init at ffffffffa0506705
> >> #10 [ffff8801f6f5fba0] sctp_sf_do_prm_asoc at ffffffffa04f81d4
> >> #11 [ffff8801f6f5fbd0] sctp_do_sm at ffffffffa04fd381
> >> #12 [ffff8801f6f5fd60] sctp_primitive_ASSOCIATE at ffffffffa0513daf
> >> #13 [ffff8801f6f5fd80] __sctp_connect at ffffffffa0510f09
> >> #14 [ffff8801f6f5fe50] sctp_connect at ffffffffa0511248
> >> #15 [ffff8801f6f5fe80] inet_dgram_connect at ffffffff81471b6c
> >> #16 [ffff8801f6f5feb0] sys_connect at ffffffff813ff747
> >> #17 [ffff8801f6f5ff80] system_call_fastpath at ffffffff81013172
> >> RIP: 0000003015ee2150 RSP: 00007fffea7bdce8 RFLAGS: 00010206
> >> RAX: 000000000000002a RBX: ffffffff81013172 RCX: 0000000000000000
> >> RDX: 0000000000000010 RSI: 00007fffea7bdd00 RDI: 0000000000000003
> >> RBP: 00007fffea7bdd40 R8: 0000000000759020 R9: ff00000000000000
> >> R10: 00007fffea7bda70 R11: 0000000000000246 R12: 0000000000000000
> >> R13: 00007fffea7bde20 R14: 00000000004006e0 R15: 0000000000000000
> >> ORIG_RAX: 000000000000002a CS: 0033 SS: 002b
> >>
> >>
> >>
>
> Are you using old kernel? If it is, the following patch may fixed this
> issue.
>
> http://git.kernel.org/?p=linux/kernel/git/vxy/lksctp-dev.git;a=commitdiff;h=a8170c35e738d62e9919ce5b109cf4ed66e95bde;hp=81419d862db743fe4450a021893f24bab4698c1d
>
I am using:
Red Hat Enterprise Linux Server release 6.0 (Santiago)
2.6.32-71.18.1.el6.x86_64 #1 SMP Wed Feb 2 17:49:59 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
> >>>> br
> >>>> walter
> >>>> --
> >>>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> >>>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel"
> >>> in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>>> Please read the FAQ at http://www.tux.org/lkml/
> >>>>
> >>> --
> >>> Thanks,
> >>> //richard
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>> Please read the FAQ at http://www.tux.org/lkml/
> >> --
> >> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> >> Jetzt informieren: http://www.gmx.net/de/go/freephone
> >>
> > CC'ing netdev
> >
>
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
^ permalink raw reply
* Re: SO_BINDTODEVICE inconsistency between IPv4 and IPv6
From: David Woodhouse @ 2011-03-18 8:54 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev, Yuniverg, Michael, Yedvab, Nadav
In-Reply-To: <4D82B4DB.2060006@hp.com>
On Thu, 2011-03-17 at 21:26 -0400, Brian Haley wrote:
> Hmm, "connection refused", do you have any iptables rules installed? Connecting
> to a local global address worked fine for me on 2.6.32-30 using a home-grown
> test app.
Thanks for looking at this.
Just to confirm... after your server does SO_BINDTODEVICE to 'lo', your
clients on the same host can make a successful connection to global IPv6
addresses which are assigned to the *other* interfaces?
Can you show your version of the test app, and your results? What kernel
is this on?
--
dwmw2
^ permalink raw reply
* Re: VLAN over GRE segfault
From: Eric Dumazet @ 2011-03-18 10:27 UTC (permalink / raw)
To: Diddi Oscarsson, David Miller; +Cc: netdev, Herbert Xu, Patrick McHardy
In-Reply-To: <4D830AF9.8040007@diddi.se>
Le vendredi 18 mars 2011 à 08:34 +0100, Diddi Oscarsson a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello!
>
> I was trying to get ethernet over GRE to work when I found an obvious
> way NOT to do it.
> Basically I created a VLAN interface from the GRE interface (even
> though I had my fair doubts it would work) which gave me a nice segfault.
> The problem with this is that after the segfault, new network
> connections cannot be made (ping, ssh, http, whatever) and a reboot of
> the computer is necessary.
> I think an error message needs to be added when trying an operation
> like this.
>
> My system:
> Linux colalapp 2.6.37-2-amd64 #1 SMP Sun Feb 27 10:12:22 UTC 2011
> x86_64 GNU/Linux
> ip utility, iproute2-ss110107
> Debian unstable
>
> Steps to reproduce:
> ip tunnel add gre0 mode gre
> ip link add link gre0 name vlan1 type vlan id 1
> ip link set vlan1 address 00:15:14:13:12:11
> ip link set gre0 up
> ip link set vlan1 up
> <CRASH>
> Attached in the mail is an output from dmesg right after the segfault.
>
> Regarding ethernet over gre, I've just found out about gretap which
> I'm testing right now.
Hi Diddi
It might be a 2.6.28 regression, after commit c95b819ad7
(gre: Use needed_headroom)
Thanks
[PATCH] vlan: should take into account needed_headroom
Commit c95b819ad7 (gre: Use needed_headroom)
made gre use needed_headroom instead of hard_header_len
This uncover a bug in vlan code.
We should make sure vlan devices take into account their
real_dev->needed_headroom or we risk a crash in ipgre_header(), because
we dont have enough room to push IP header in skb.
Reported-by: Diddi Oscarsson <diddi@diddi.se>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
net/8021q/vlan_dev.c | 1 +
1 files changed, 1 insertion(+)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index ae610f0..e34ea9e 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -720,6 +720,7 @@ static int vlan_dev_init(struct net_device *dev)
dev->fcoe_ddp_xid = real_dev->fcoe_ddp_xid;
#endif
+ dev->needed_headroom = real_dev->needed_headroom;
if (real_dev->features & NETIF_F_HW_VLAN_TX) {
dev->header_ops = real_dev->header_ops;
dev->hard_header_len = real_dev->hard_header_len;
^ permalink raw reply related
* Re: [PATCH] netfilter: xtables: fix reentrancy
From: Jesper Dangaard Brouer @ 2011-03-18 10:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, Netfilter Developers, netdev
In-Reply-To: <1300367841.6315.9.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1883 bytes --]
On Thu, 17 Mar 2011, Eric Dumazet wrote:
> Le jeudi 17 mars 2011 à 12:45 +0100, Eric Dumazet a écrit :
>> Le jeudi 17 mars 2011 à 12:36 +0100, Jesper Dangaard Brouer a écrit :
>>> Hi Eric,
>>>
>>> How critial is this bug fix?
>>>
>>> Should I apply this on my stable production kernels?
>>> (I'm preparing a 2.6.38 kernel for prod usage, eventhougt its just been
>>> released, because I want your SFQ fixes...)
>>
>> I would say the race is there, but probability must be very small, and
>> might need malicious iptables rules (with RETURN targets)
Actually do have a large number of return targets.
In the filter forward chain.
>> Especially in routers, where OUTPUT path is taken from softirq handler
>> anyway ;)
>>
>> So dont worry at all, consider this as a cleanup :)
>>
>
> Almost forgot to mention your kernels probably have :
>
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT is not set
>
> So you can take it easy ;)
I have actually enabled PREEMPTion, am I in trouble then?
I have modified the .config I got from you, quite a lot, during my
attempts to find the CCISS/HPSA problem.
Which reminds me that I needed to enable, the follwing config options,
(which your config didn't have):
CONFIG_PCIEASPM=y
CONFIG_X86_X2APIC=y
In order to get rid of a PCI warning:
NMI: PCI system error (SERR) for reason b1 on CPU 0.
Dazed and confused, but trying to continue
The system worked fine, and you might not see this issue on your G6
servers, as its most likely BIOS related (my server is a HP DL370 G6).
FYI: Operations have deployed the kernel on prod server this morning.
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] netfilter: xtables: fix reentrancy
From: Eric Dumazet @ 2011-03-18 10:50 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, Patrick McHardy, Netfilter Developers, netdev
In-Reply-To: <Pine.LNX.4.64.1103181113040.21558@ask.diku.dk>
Le vendredi 18 mars 2011 à 11:27 +0100, Jesper Dangaard Brouer a écrit :
> I have actually enabled PREEMPTion, am I in trouble then?
>
Well, to get problem on localy generated trafic (as all forwarding is
done from softirq handler), you'll need a malicious -j RETURN in OUTPUT
hook (in the OUTPUT chain, not a called one)
Also, even for localy generated trafic, I guess most callers block BH
before calling ipt_do_table() anyway...
> I have modified the .config I got from you, quite a lot, during my
> attempts to find the CCISS/HPSA problem.
>
> Which reminds me that I needed to enable, the follwing config options,
> (which your config didn't have):
> CONFIG_PCIEASPM=y
> CONFIG_X86_X2APIC=y
>
> In order to get rid of a PCI warning:
> NMI: PCI system error (SERR) for reason b1 on CPU 0.
> Dazed and confused, but trying to continue
>
> The system worked fine, and you might not see this issue on your G6
> servers, as its most likely BIOS related (my server is a HP DL370 G6).
>
Mine is ProLiant BL460c G6
> FYI: Operations have deployed the kernel on prod server this morning.
Okay, lets pray ;)
^ permalink raw reply
* [PATCH RFC] net: unify features for drivers which use skb_copy_and_csum_dev
From: Cesar Eduardo Barros @ 2011-03-18 10:57 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Jeff Garzik, Lennert Buytenhek, Tristram Ha,
Roger Luethi, Michał Mirosław, Cesar Eduardo Barros
A few network drivers use skb_copy_and_csum_dev as the core of their
.ndo_start_xmit function. Which NETIF_F_* features these drivers can use
should depend only on the implementation of skb_copy_and_csum_dev, and
so should be the same for all of them. However, I could find three
different sets of feature flags on these drivers.
To prevent these drivers from getting out of sync again, move this set
of feature flags to a central location. With the advantage that if the
set of flags is later found to be wrong or skb_copy_and_csum_dev is
modified, it can be changed in a single place.
This also enables NETIF_F_FRAGLIST for these drivers. Unless I misread
the code behind skb_copy_and_csum_dev, it can also deal with frag lists.
There were other drivers using skb_copy_and_csum_dev (ksz884x and
via-rhine), but I did not touch them, since they are doing things on
their .ndo_start_xmit which are more complex than a simple call of
skb_copy_and_csum_dev.
Cc: Jeff Garzik <jgarzik@pobox.com> (8139too)
Cc: Lennert Buytenhek <kernel@wantstofly.org> (ep93xx_eth, ixp2000)
Cc: Tristram Ha <Tristram.Ha@micrel.com> (ksz884x)
Cc: Roger Luethi <rl@hellgate.ch> (via-rhine)
Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
drivers/net/8139too.c | 2 +-
drivers/net/arm/ep93xx_eth.c | 2 +-
drivers/net/ixp2000/ixpdev.c | 2 +-
drivers/net/sc92031.c | 3 +--
include/linux/netdevice.h | 4 ++++
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 98517a3..0fc2127 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -991,7 +991,7 @@ static int __devinit rtl8139_init_one (struct pci_dev *pdev,
* through the use of skb_copy_and_csum_dev we enable these
* features
*/
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
dev->irq = pdev->irq;
diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 5a77001..50ebd33 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -769,7 +769,7 @@ static struct net_device *ep93xx_dev_alloc(struct ep93xx_eth_data *data)
dev->ethtool_ops = &ep93xx_ethtool_ops;
dev->netdev_ops = &ep93xx_netdev_ops;
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
return dev;
}
diff --git a/drivers/net/ixp2000/ixpdev.c b/drivers/net/ixp2000/ixpdev.c
index 78ddd8b..0df0734 100644
--- a/drivers/net/ixp2000/ixpdev.c
+++ b/drivers/net/ixp2000/ixpdev.c
@@ -303,7 +303,7 @@ struct net_device *ixpdev_alloc(int channel, int sizeof_priv)
dev->netdev_ops = &ixpdev_netdev_ops;
- dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM;
+ dev->features |= NETIF_F_XMIT_COPY_AND_CSUM;
ip = netdev_priv(dev);
ip->dev = dev;
diff --git a/drivers/net/sc92031.c b/drivers/net/sc92031.c
index 76290a8..63db429 100644
--- a/drivers/net/sc92031.c
+++ b/drivers/net/sc92031.c
@@ -1449,8 +1449,7 @@ static int __devinit sc92031_probe(struct pci_dev *pdev,
dev->irq = pdev->irq;
/* faked with skb_copy_and_csum_dev */
- dev->features = NETIF_F_SG | NETIF_F_HIGHDMA |
- NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+ dev->features = NETIF_F_XMIT_COPY_AND_CSUM;
dev->netdev_ops = &sc92031_netdev_ops;
dev->watchdog_timeo = TX_TIMEOUT;
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5eeb2cd..680ed33 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1110,6 +1110,10 @@ struct net_device {
/* changeable features with no special hardware requirements */
#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO)
+ /* skb_copy_and_csum_dev is able to fake a few features */
+#define NETIF_F_XMIT_COPY_AND_CSUM (NETIF_F_SG | NETIF_F_HW_CSUM | \
+ NETIF_F_HIGHDMA | NETIF_F_FRAGLIST)
+
/* Interface index. Unique device identifier */
int ifindex;
int iflink;
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 05/36] block,rcu: convert call_rcu(disk_free_ptbl_rcu_cb) to kfree_rcu()
From: Matthew Wilcox @ 2011-03-18 11:20 UTC (permalink / raw)
To: Jens Axboe
Cc: Lai Jiangshan, Paul E. McKenney, Ingo Molnar, Robert Love,
James E.J. Bottomley, Neil Horman, David S. Miller,
Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Eric Dumazet,
Stephen Hemminger, Tejun Heo, Jarek Poplawski, linux-kernel,
devel, linux-scsi, netdev
In-Reply-To: <4D8302E9.30303@kernel.dk>
On Fri, Mar 18, 2011 at 07:59:53AM +0100, Jens Axboe wrote:
> On 2011-03-18 04:42, Lai Jiangshan wrote:
> >
> >
> > The rcu callback disk_free_ptbl_rcu_cb() just calls a kfree(),
> > so we use kfree_rcu() instead of the call_rcu(disk_free_ptbl_rcu_cb).
>
> Thanks, I'll add this.
Don't be in too much of a hurry ... kfree_rcu() doesn't appear to have
hit Linus' tree yet.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* LRO disable warnings on kernel 2.6.38
From: Jesper Dangaard Brouer @ 2011-03-18 11:12 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, Neil Horman, Alexander Duyck
Hi
I'm seeing the LRO disable warnings using kernel 2.6.38:
[ 8.664759] NET: Registered protocol family 10
[ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready
[ 8.872639] ------------[ cut here ]------------
[ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80()
[ 8.872647] Hardware name: ProLiant DL370 G6
[ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan]
[ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2
[ 8.872662] Call Trace:
[ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0
[ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20
[ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80
[ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180
[ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0
[ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20
[ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180
[ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90
[ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b
[ 8.872714] ---[ end trace 6245283cb8d484cc ]---
The strange part is that I didn't see this warning on my testlab and
pre-prod servers. The warning is from the first production server,
which got kernel 2.6.38 deployed this morning.
The NIC driver is igb.
The only difference in hardware between the production and
pre-production server (which didn't show the warning), is the
prod-server have an extra dual-port original Intel NIC, dev-named
"eth71". And its just after the init of eth71, the warning occurs.
We usually use a 6 port NIC from Hotlava, which is based on the same
chip 82576 and also uses the same igb driver.
Intel orig NIC eth71
albpd4:~# ethtool -i eth71
driver: igb
version: 2.1.0-k2
firmware-version: 1.2-1
bus-info: 0000:21:00.0
Hotlava Intel chip based NIC eth51:
albpd4:~# ethtool -i eth51
driver: igb
version: 2.1.0-k2
firmware-version: 1.2-1
bus-info: 0000:1d:00.1
I don't understand why I don't see the warning on my pre-prod server,
which only have the Hotlava NIC?!?
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: dccp test-tree [RFC] [Patch 1/1] dccp: Only activate NN values after receiving the Confirm option
From: Gerrit Renker @ 2011-03-18 11:30 UTC (permalink / raw)
To: Samuel Jero; +Cc: dccp, netdev
In-Reply-To: <1300164791.20638.64.camel@jero-laptop>
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
I have revised the patch set addressing the following comments of this thread:
1) Renamed function to dccp_feat_nn_get().
2) Added test to ensure that function is called for NN
features back in.
3) Replaced ccid2_ack_ratio_next() with calls to that
function (dccp_feat_nn_get(sk, DCCPF_ACK_RATIO)).
4) Replaced check for dccps_l_seq_win in ccid2_change_l_seq_window
with call to dccp_feat_nn_get(sk, DCCPF_SEQUENCE_WINDOW)
(for similar calls see separate, attached patch).
5) De-inlined ccid2_ack_ratio_next() wrapper as discussed.
6) Updated remaining patches with regard to 1-4.
In (4) I created a separate patch. You mentioned earlier replacing references to
local seq_window with a call to the accessor function, these were the remaining
references, I noticed no regression.
This is all in the test tree, just uploaded 2.6.38
git://eden-feed.erg.abdn.ac.uk/dccp_exp [subtree 'dccp']
| > I don't know if blocking the Ack Ratio code is the reason, but during the
| > initial slow-start there were ChangeL requests for Sequence Window on nearly
| > every packet, which seems too much.
|
| Right now, Change's are sent on every packet until the matching Confirm
| is received. That will be the cause of most of the Change's you are
| seeing.
|
| The other thing is that at the beginning of a connection the sequence
| window will be reduced and then increased. The initial window of 100
| packets is too wide for 5*cwnd at the start of the connection. So the
| window will be reduced as low as it will go at the very beginning of the
| connection. However, as slow start picks up, cwnd will increase and the
| sequence window will as well.
|
| I've seen the above behavior, but haven't thought of an effective
| solution (nor am I sure that we need a solution). Capping the minimum
| sequence window at the default (100 packets) would solve this, but that
| doesn't seem like a great solution.
|
| >
| > If low_threshold == high_threshold, it oscillates. I think you have already done
| > some work on this in the code using CCID2_WIN_CHANGE_FACTOR.
|
| I'm not entirely certain what low_threshold and high_threshold you are
| talking about. I have not seen sequence window oscillations other as the
| congestion window oscillates in congestion avoidance as is expected.
|
I meant a Schmitt Trigger like behaviour:
* low_threshold: to change from lower value to higher value
* hi_threshold: to revert from higher value back to lower value
In these electronic devices there is a gap between low and hi, to avoid fluctuations.
Also audio effect gates have a similar setting.
With regard to your comment about the 100 packets at the begin, I was wondering if
the connection could not grossly exaggerate, or maybe even use the 100 packets.
But all that is not a big deal, stuff for fine-tuning the now much better ccid2
engine.
Thank you for all your good work. The comments helped a great deal too.
[-- Attachment #2: remaining_l_seq_win_refs.diff --]
[-- Type: text/x-diff, Size: 1812 bytes --]
dccp ccid-2: replace remaining references to local Sequence Window value
This replaces the remaining references to dccps_l_seq_win with the corresponding
call to retrieve the current (STABLE if not in negotiation, CHANGING if being
negotiated) value of the feature-local sequence window.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/ccid2.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/net/dccp/ccids/ccid2.c
+++ b/net/dccp/ccids/ccid2.c
@@ -441,10 +441,10 @@ static void ccid2_new_ack(struct sock *s
{
struct ccid2_hc_tx_sock *hc = ccid2_hc_tx_sk(sk);
struct dccp_sock *dp = dccp_sk(sk);
+ u64 l_seq_win = dccp_feat_nn_get(sk, DCCPF_SEQUENCE_WINDOW);
int r_seq_used = hc->tx_cwnd / dp->dccps_l_ack_ratio;
- if (hc->tx_cwnd < dp->dccps_l_seq_win &&
- r_seq_used < dp->dccps_r_seq_win) {
+ if (hc->tx_cwnd < l_seq_win && r_seq_used < dp->dccps_r_seq_win) {
if (hc->tx_cwnd < hc->tx_ssthresh) {
if (*maxincr > 0 && ++hc->tx_packets_acked >= 2) {
hc->tx_cwnd += 1;
@@ -466,10 +466,10 @@ static void ccid2_new_ack(struct sock *s
else if (r_seq_used * CCID2_WIN_CHANGE_FACTOR < dp->dccps_r_seq_win/2)
ccid2_change_l_ack_ratio(sk, dp->dccps_l_ack_ratio / 2 ? : 1U);
- if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR >= dp->dccps_l_seq_win)
- ccid2_change_l_seq_window(sk, dp->dccps_l_seq_win * 2);
- else if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR < dp->dccps_l_seq_win/2)
- ccid2_change_l_seq_window(sk, dp->dccps_l_seq_win / 2);
+ if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR >= l_seq_win)
+ ccid2_change_l_seq_window(sk, l_seq_win * 2);
+ else if (hc->tx_cwnd * CCID2_WIN_CHANGE_FACTOR < l_seq_win / 2)
+ ccid2_change_l_seq_window(sk, l_seq_win / 2);
/*
* FIXME: RTT is sampled several times per acknowledgment (for each
^ permalink raw reply
* Re: dccp test-tree [RFC] [Patch 2/2] dccp: CCID2 check ack ratio when reducing cwnd
From: Gerrit Renker @ 2011-03-18 11:33 UTC (permalink / raw)
To: Samuel Jero; +Cc: dccp, netdev
In-Reply-To: <1300164797.20638.65.camel@jero-laptop>
| This patch causes CCID2 to check the ack ratio after reducing the
| congestion window.
Thanks a lot, it has been integrated with the other changes:
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitdiff;h=f7bcfc7ddf5c1f61c861c3d2b475df7874833ed3
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Eric Dumazet @ 2011-03-18 13:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, Neil Horman, Alexander Duyck
In-Reply-To: <1300446743.11985.317.camel@firesoul.comx.local>
Le vendredi 18 mars 2011 à 12:12 +0100, Jesper Dangaard Brouer a écrit :
> Hi
>
> I'm seeing the LRO disable warnings using kernel 2.6.38:
>
> [ 8.664759] NET: Registered protocol family 10
> [ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready
> [ 8.872639] ------------[ cut here ]------------
> [ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80()
> [ 8.872647] Hardware name: ProLiant DL370 G6
> [ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan]
> [ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2
> [ 8.872662] Call Trace:
> [ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0
> [ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20
> [ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80
> [ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180
> [ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0
> [ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20
> [ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180
> [ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90
> [ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b
> [ 8.872714] ---[ end trace 6245283cb8d484cc ]---
>
> The strange part is that I didn't see this warning on my testlab and
> pre-prod servers. The warning is from the first production server,
> which got kernel 2.6.38 deployed this morning.
>
> The NIC driver is igb.
>
> The only difference in hardware between the production and
> pre-production server (which didn't show the warning), is the
> prod-server have an extra dual-port original Intel NIC, dev-named
> "eth71". And its just after the init of eth71, the warning occurs.
>
> We usually use a 6 port NIC from Hotlava, which is based on the same
> chip 82576 and also uses the same igb driver.
>
> Intel orig NIC eth71
> albpd4:~# ethtool -i eth71
> driver: igb
> version: 2.1.0-k2
> firmware-version: 1.2-1
> bus-info: 0000:21:00.0
>
> Hotlava Intel chip based NIC eth51:
> albpd4:~# ethtool -i eth51
> driver: igb
> version: 2.1.0-k2
> firmware-version: 1.2-1
> bus-info: 0000:1d:00.1
>
> I don't understand why I don't see the warning on my pre-prod server,
> which only have the Hotlava NIC?!?
>
Hmm, WARN_ON() message is not very nice in this case I'm afraid, we dont
even know offender
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..571ab70 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1361,7 +1361,8 @@ void dev_disable_lro(struct net_device *dev)
dev->ethtool_ops->set_flags(dev, flags);
}
}
- WARN_ON(dev->features & NETIF_F_LRO);
+ if (dev->features & NETIF_F_LRO)
+ netdev_err(dev, "Could not disable LRO\n");
}
EXPORT_SYMBOL(dev_disable_lro);
^ permalink raw reply related
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Michael S. Tsirkin @ 2011-03-18 13:15 UTC (permalink / raw)
To: Shirley Ma; +Cc: Rusty Russell, David Miller, kvm, netdev, Herbert Xu
In-Reply-To: <1300418927.3255.62.camel@localhost.localdomain>
On Thu, Mar 17, 2011 at 08:28:47PM -0700, Shirley Ma wrote:
> On Thu, 2011-03-17 at 08:18 -0700, Shirley Ma wrote:
> > On Thu, 2011-03-17 at 07:02 +0200, Michael S. Tsirkin wrote:
> > > So, this just tries to make sure there's enough space for
> > > max packet in the ring, if not - drop and return OK.
> > > Why bother checking beforehand though?
> > > If that's what we want to do, we can just call add_buf and see
> > > if it fails?
> >
> > In add_buf, there is an additional kick, see below. I added check
> > capacity to avoid this, thought it would be better performance. I will
> > retest it w/i add_buf to see the performance difference.
> >
> > if (vq->num_free < out + in) {
> > pr_debug("Can't add buf len %i - avail = %i\n",
> > out + in, vq->num_free);
> > /* FIXME: for historical reasons, we force a notify
> > here
> > if
> > * there are outgoing parts to the buffer. Presumably
> > the
> > * host should service the ring ASAP. */
> > if (out)
> > vq->notify(&vq->vq);
> > END_USE(vq);
> > return -ENOSPC;
> > }
> >
Rusty, could you pls clarify what are the historical reasons here?
Are they still valid?
If yes we could dedicate a feature flag to disabling this,
or guess that the host is new by looking at some
other feature flag.
> More test results:
>
> UDP_STREAM test results (% is guest vcpu, guest has 2 vpus):
>
> Send(netperf)
> ----
>
> size 2.6.38-rc8 2.6.38-rc8+ 2.6.38-rc8
> addbuf failure check capacity
> -----------------------------------------------------
> 1K 1541.0/50.14% 2169.1/50.03% 3018.9/50%
> 2K 1649.7/33.74% 3362.6/50.18% 4518.8/50.47%
> 4K 2957.8/44.83% 5965.9/50.03% 9592.5/50%
> 8K 3788/39.01% 9852.8/50.25% 15483.8/50%
> 16K 4736.1/34.13% 14946.5/50.01% 21645.0/50%
Is this the local or remote throughput?
With UDP_STREAM you are mostly interested in
remote throughput, local one can be pretty high
while most packets get dropped.
> Looks like the additional guest notify in add_buf doesn't cost that much
> than I thought to be.
>
> Thanks
> Shirley
^ permalink raw reply
* [PATCH net-next-2.6 1/6] be2net: refactor code that decides adapter->num_rx_queues
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-1-git-send-email-sathya.perla@emulex.com>
The code has been refactored to not set num_rx_qs inside be_enable_msix().
num_rx_qs is now set at the time of queue creation based on the number of
available msix vectors.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be.h | 8 +++--
drivers/net/benet/be_main.c | 64 ++++++++++++++++++++++---------------------
2 files changed, 38 insertions(+), 34 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index f803c58..3937bca 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -84,7 +84,8 @@ static inline char *nic_name(struct pci_dev *pdev)
#define MCC_CQ_LEN 256
#define MAX_RSS_QS 4 /* BE limit is 4 queues/port */
-#define BE_MAX_MSIX_VECTORS (MAX_RSS_QS + 1 + 1)/* RSS qs + 1 def Rx + Tx */
+#define MAX_RX_QS (MAX_RSS_QS + 1) /* RSS qs + 1 def Rx */
+#define BE_MAX_MSIX_VECTORS (MAX_RX_QS + 1)/* RX + TX */
#define BE_NAPI_WEIGHT 64
#define MAX_RX_POST BE_NAPI_WEIGHT /* Frags posted at a time */
#define RX_FRAGS_REFILL_WM (RX_Q_LEN - MAX_RX_POST)
@@ -276,7 +277,7 @@ struct be_adapter {
spinlock_t mcc_cq_lock;
struct msix_entry msix_entries[BE_MAX_MSIX_VECTORS];
- bool msix_enabled;
+ u32 num_msix_vec;
bool isr_registered;
/* TX Rings */
@@ -287,7 +288,7 @@ struct be_adapter {
u32 cache_line_break[8];
/* Rx rings */
- struct be_rx_obj rx_obj[MAX_RSS_QS + 1]; /* one default non-rss Q */
+ struct be_rx_obj rx_obj[MAX_RX_QS];
u32 num_rx_qs;
u32 big_page_size; /* Compounded page size shared by rx wrbs */
@@ -351,6 +352,7 @@ struct be_adapter {
extern const struct ethtool_ops be_ethtool_ops;
+#define msix_enabled(adapter) (adapter->num_msix_vec > 0)
#define tx_stats(adapter) (&adapter->tx_stats)
#define rx_stats(rxo) (&rxo->stats)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index a71163f..97c5167 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1567,12 +1567,31 @@ static void be_rx_queues_destroy(struct be_adapter *adapter)
}
}
+static u32 be_num_rxqs_want(struct be_adapter *adapter)
+{
+ if (multi_rxq && (adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
+ !adapter->sriov_enabled && !(adapter->function_mode & 0x400)) {
+ return 1 + MAX_RSS_QS; /* one default non-RSS queue */
+ } else {
+ dev_warn(&adapter->pdev->dev,
+ "No support for multiple RX queues\n");
+ return 1;
+ }
+}
+
static int be_rx_queues_create(struct be_adapter *adapter)
{
struct be_queue_info *eq, *q, *cq;
struct be_rx_obj *rxo;
int rc, i;
+ adapter->num_rx_qs = min(be_num_rxqs_want(adapter),
+ msix_enabled(adapter) ?
+ adapter->num_msix_vec - 1 : 1);
+ if (adapter->num_rx_qs != MAX_RX_QS)
+ dev_warn(&adapter->pdev->dev,
+ "Can create only %d RX queues", adapter->num_rx_qs);
+
adapter->big_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE;
for_all_rx_queues(adapter, rxo, i) {
rxo->adapter = adapter;
@@ -1878,51 +1897,35 @@ reschedule:
static void be_msix_disable(struct be_adapter *adapter)
{
- if (adapter->msix_enabled) {
+ if (msix_enabled(adapter)) {
pci_disable_msix(adapter->pdev);
- adapter->msix_enabled = false;
- }
-}
-
-static int be_num_rxqs_get(struct be_adapter *adapter)
-{
- if (multi_rxq && (adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
- !adapter->sriov_enabled && !(adapter->function_mode & 0x400)) {
- return 1 + MAX_RSS_QS; /* one default non-RSS queue */
- } else {
- dev_warn(&adapter->pdev->dev,
- "No support for multiple RX queues\n");
- return 1;
+ adapter->num_msix_vec = 0;
}
}
static void be_msix_enable(struct be_adapter *adapter)
{
#define BE_MIN_MSIX_VECTORS (1 + 1) /* Rx + Tx */
- int i, status;
+ int i, status, num_vec;
- adapter->num_rx_qs = be_num_rxqs_get(adapter);
+ num_vec = be_num_rxqs_want(adapter) + 1;
- for (i = 0; i < (adapter->num_rx_qs + 1); i++)
+ for (i = 0; i < num_vec; i++)
adapter->msix_entries[i].entry = i;
- status = pci_enable_msix(adapter->pdev, adapter->msix_entries,
- adapter->num_rx_qs + 1);
+ status = pci_enable_msix(adapter->pdev, adapter->msix_entries, num_vec);
if (status == 0) {
goto done;
} else if (status >= BE_MIN_MSIX_VECTORS) {
+ num_vec = status;
if (pci_enable_msix(adapter->pdev, adapter->msix_entries,
- status) == 0) {
- adapter->num_rx_qs = status - 1;
- dev_warn(&adapter->pdev->dev,
- "Could alloc only %d MSIx vectors. "
- "Using %d RX Qs\n", status, adapter->num_rx_qs);
+ num_vec) == 0)
goto done;
- }
}
return;
done:
- adapter->msix_enabled = true;
+ adapter->num_msix_vec = num_vec;
+ return;
}
static void be_sriov_enable(struct be_adapter *adapter)
@@ -2003,8 +2006,7 @@ err_msix:
err:
dev_warn(&adapter->pdev->dev,
"MSIX Request IRQ failed - err %d\n", status);
- pci_disable_msix(adapter->pdev);
- adapter->msix_enabled = false;
+ be_msix_disable(adapter);
return status;
}
@@ -2013,7 +2015,7 @@ static int be_irq_register(struct be_adapter *adapter)
struct net_device *netdev = adapter->netdev;
int status;
- if (adapter->msix_enabled) {
+ if (msix_enabled(adapter)) {
status = be_msix_register(adapter);
if (status == 0)
goto done;
@@ -2046,7 +2048,7 @@ static void be_irq_unregister(struct be_adapter *adapter)
return;
/* INTx */
- if (!adapter->msix_enabled) {
+ if (!msix_enabled(adapter)) {
free_irq(netdev->irq, adapter);
goto done;
}
@@ -2088,7 +2090,7 @@ static int be_close(struct net_device *netdev)
be_cq_notify(adapter, rxo->cq.id, false, 0);
}
- if (adapter->msix_enabled) {
+ if (msix_enabled(adapter)) {
vec = be_msix_vec_get(adapter, tx_eq);
synchronize_irq(vec);
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 0/6] be2net: patch series
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
Please apply. Thanks!
Sathya Perla(6):
be2net: refactor code that decides adapter->num_rx_queues
be2net: fix to not drop unfiltered vlan pkts
be2net: parse vid and vtm fields of rx-compl only if vlanf bit is set
be2net: remove redundant code in be_worker()
be2net: cancel be_worker() in be_shutdown() even when i/f is down
be2net: remove one useless line
drivers/net/benet/be.h | 8 ++-
drivers/net/benet/be_main.c | 119 ++++++++++++++++++++++--------------------
2 files changed, 67 insertions(+), 60 deletions(-)
^ permalink raw reply
* [PATCH net-next-2.6 2/6] be2net: fix to not drop unfiltered vlan pkts
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-2-git-send-email-sathya.perla@emulex.com>
When the device is in promiscuous mode, the driver can receive vlan packets
(tag is always stripped by card) even when there is no vlan configuration.
Such packets must be sent to the stack and not dropped.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 97c5167..18c6da4 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1013,15 +1013,10 @@ static void be_rx_compl_process(struct be_adapter *adapter,
skb->truesize = skb->len + sizeof(struct sk_buff);
skb->protocol = eth_type_trans(skb, adapter->netdev);
- if (unlikely(rxcp->vlanf)) {
- if (!adapter->vlan_grp || adapter->vlans_added == 0) {
- kfree_skb(skb);
- return;
- }
+ if (unlikely(rxcp->vlanf))
vlan_hwaccel_receive_skb(skb, adapter->vlan_grp, rxcp->vid);
- } else {
+ else
netif_receive_skb(skb);
- }
}
/* Process the RX completion indicated by rxcp when GRO is enabled */
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 3/6] be2net: parse vid and vtm fields of rx-compl only if vlanf bit is set
From: Sathya Perla @ 2011-03-18 13:20 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-3-git-send-email-sathya.perla@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 34 +++++++++++++++++++++++-----------
1 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 18c6da4..6be06df 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1096,8 +1096,12 @@ static void be_parse_rx_compl_v1(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, cast_enc, compl);
- rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtm, compl);
- rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vlan_tag, compl);
+ if (rxcp->vlanf) {
+ rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtm,
+ compl);
+ rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vlan_tag,
+ compl);
+ }
}
static void be_parse_rx_compl_v0(struct be_adapter *adapter,
@@ -1122,8 +1126,12 @@ static void be_parse_rx_compl_v0(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, cast_enc, compl);
- rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtm, compl);
- rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vlan_tag, compl);
+ if (rxcp->vlanf) {
+ rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtm,
+ compl);
+ rxcp->vid = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vlan_tag,
+ compl);
+ }
}
static struct be_rx_compl_info *be_rx_compl_get(struct be_rx_obj *rxo)
@@ -1145,15 +1153,19 @@ static struct be_rx_compl_info *be_rx_compl_get(struct be_rx_obj *rxo)
else
be_parse_rx_compl_v0(adapter, compl, rxcp);
- /* vlanf could be wrongly set in some cards. ignore if vtm is not set */
- if ((adapter->function_mode & 0x400) && !rxcp->vtm)
- rxcp->vlanf = 0;
+ if (rxcp->vlanf) {
+ /* vlanf could be wrongly set in some cards.
+ * ignore if vtm is not set */
+ if ((adapter->function_mode & 0x400) && !rxcp->vtm)
+ rxcp->vlanf = 0;
- if (!lancer_chip(adapter))
- rxcp->vid = swab16(rxcp->vid);
+ if (!lancer_chip(adapter))
+ rxcp->vid = swab16(rxcp->vid);
- if ((adapter->pvid == rxcp->vid) && !adapter->vlan_tag[rxcp->vid])
- rxcp->vlanf = 0;
+ if ((adapter->pvid == rxcp->vid) &&
+ !adapter->vlan_tag[rxcp->vid])
+ rxcp->vlanf = 0;
+ }
/* As the compl has been parsed, reset it; we wont touch it again */
compl->dw[offsetof(struct amap_eth_rx_compl_v1, valid) / 32] = 0;
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 5/6] be2net: cancel be_worker() in be_shutdown() even when i/f is down
From: Sathya Perla @ 2011-03-18 13:21 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-5-git-send-email-sathya.perla@emulex.com>
As the be_worker() workqueue is scheduled in be_probe() it must
be canceled unconditionally in be_shutdown().
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 0efa639..acd53e6 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -3150,8 +3150,7 @@ static void be_shutdown(struct pci_dev *pdev)
struct be_adapter *adapter = pci_get_drvdata(pdev);
struct net_device *netdev = adapter->netdev;
- if (netif_running(netdev))
- cancel_delayed_work_sync(&adapter->work);
+ cancel_delayed_work_sync(&adapter->work);
netif_device_detach(netdev);
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 6/6] be2net: remove one useless line
From: Sathya Perla @ 2011-03-18 13:21 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-6-git-send-email-sathya.perla@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index acd53e6..cfe986f 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -2325,7 +2325,6 @@ static int be_setup(struct be_adapter *adapter)
return 0;
- be_mcc_queues_destroy(adapter);
rx_qs_destroy:
be_rx_queues_destroy(adapter);
tx_qs_destroy:
--
1.6.5.2
^ permalink raw reply related
* [PATCH net-next-2.6 4/6] be2net: remove redundant code in be_worker()
From: Sathya Perla @ 2011-03-18 13:21 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla
In-Reply-To: <1300454462-1234-4-git-send-email-sathya.perla@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/benet/be_main.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 6be06df..0efa639 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1863,6 +1863,9 @@ static void be_worker(struct work_struct *work)
struct be_rx_obj *rxo;
int i;
+ if (!adapter->ue_detected && !lancer_chip(adapter))
+ be_detect_dump_ue(adapter);
+
/* when interrupts are not yet enabled, just reap any pending
* mcc completions */
if (!netif_running(adapter->netdev)) {
@@ -1875,9 +1878,6 @@ static void be_worker(struct work_struct *work)
be_cq_notify(adapter, mcc_obj->cq.id, false, mcc_compl);
}
- if (!adapter->ue_detected && !lancer_chip(adapter))
- be_detect_dump_ue(adapter);
-
goto reschedule;
}
@@ -1895,8 +1895,6 @@ static void be_worker(struct work_struct *work)
be_post_rx_frags(rxo, GFP_KERNEL);
}
}
- if (!adapter->ue_detected && !lancer_chip(adapter))
- be_detect_dump_ue(adapter);
reschedule:
schedule_delayed_work(&adapter->work, msecs_to_jiffies(1000));
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Herbert Xu @ 2011-03-18 13:33 UTC (permalink / raw)
To: Shirley Ma; +Cc: mst, rusty, davem, kvm, netdev
In-Reply-To: <1300320775.3255.34.camel@localhost.localdomain>
Shirley Ma <mashirle@us.ibm.com> wrote:
>
> + /* Drop packet instead of stop queue for better performance */
I would like to see some justification as to why this is the right
way to go and not just papering over the real problem.
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
* Re: [PATCH 35/36] net/mac80211,rcu: convert call_rcu(work_free_rcu) to kfree_rcu()
From: John W. Linville @ 2011-03-18 13:51 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Paul E. McKenney, Ingo Molnar, Johannes Berg, David S. Miller,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D82DC17.2090106-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
On Fri, Mar 18, 2011 at 12:14:15PM +0800, Lai Jiangshan wrote:
>
>
> The rcu callback work_free_rcu() just calls a kfree(),
> so we use kfree_rcu() instead of the call_rcu(work_free_rcu).
>
> Signed-off-by: Lai Jiangshan <laijs-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
ACK -- seems fine to me...
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
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
* [PATCH] NET: smsc95xx: don't use stack for async writes to the device
From: Marc Zyngier @ 2011-03-18 13:53 UTC (permalink / raw)
To: netdev; +Cc: Steve Glendinning
The set_multicast operation performs asynchronous writes to the
device, with some addresses pointing to the stack. Bad things may
happen, and this is trapped CONFIG_DMA_API_DEBUG:
[ 5.237762] WARNING: at /build/buildd/linux-linaro-omap-2.6.38/lib/dma-debug.c:867 check_for_stack+0xd4/0x100()
[ 5.237792] ehci-omap ehci-omap.0: DMA-API: device driver maps memory fromstack [addr=d9c77dec]
[ 5.237792] Modules linked in: smsc95xx(+) usbnet twl6030_usb twl4030_pwrbutton leds_gpio omap_wdt omap2_mcspi
[ 5.237854] [<c006d618>] (unwind_backtrace+0x0/0xf8) from [<c00a6a14>] (warn_slowpath_common+0x54/0x64)
[ 5.237884] [<c00a6a14>] (warn_slowpath_common+0x54/0x64) from [<c00a6ab8>] (warn_slowpath_fmt+0x30/0x40)
[ 5.237915] [<c00a6ab8>] (warn_slowpath_fmt+0x30/0x40) from [<c034e9d8>] (check_for_stack+0xd4/0x100)
[ 5.237915] [<c034e9d8>] (check_for_stack+0xd4/0x100) from [<c034fea8>] (debug_dma_map_page+0xb4/0xdc)
[ 5.237976] [<c034fea8>] (debug_dma_map_page+0xb4/0xdc) from [<c04242f0>] (map_urb_for_dma+0x26c/0x304)
[ 5.237976] [<c04242f0>] (map_urb_for_dma+0x26c/0x304) from [<c0424594>] (usb_hcd_submit_urb+0x78/0x19c)
[ 5.238037] [<c0424594>] (usb_hcd_submit_urb+0x78/0x19c) from [<bf049c5c>] (smsc95xx_write_reg_async+0xb4/0x130 [smsc95xx])
[ 5.238067] [<bf049c5c>] (smsc95xx_write_reg_async+0xb4/0x130 [smsc95xx]) from [<bf049dd4>] (smsc95xx_set_multicast+0xfc/0x148 [smsc95xx])
[ 5.238098] [<bf049dd4>] (smsc95xx_set_multicast+0xfc/0x148 [smsc95xx]) from [<bf04a118>] (smsc95xx_reset+0x2f8/0x68c [smsc95xx])
[ 5.238128] [<bf04a118>] (smsc95xx_reset+0x2f8/0x68c [smsc95xx]) from [<bf04a8cc>] (smsc95xx_bind+0xcc/0x188 [smsc95xx])
[ 5.238159] [<bf04a8cc>] (smsc95xx_bind+0xcc/0x188 [smsc95xx]) from [<bf03ef1c>] (usbnet_probe+0x204/0x4c4 [usbnet])
[ 5.238220] [<bf03ef1c>] (usbnet_probe+0x204/0x4c4 [usbnet]) from [<c0429078>] (usb_probe_interface+0xe4/0x1c4)
[ 5.238250] [<c0429078>] (usb_probe_interface+0xe4/0x1c4) from [<c03a8770>] (really_probe+0x64/0x160)
[ 5.238250] [<c03a8770>] (really_probe+0x64/0x160) from [<c03a8a30>] (driver_probe_device+0x48/0x60)
[ 5.238281] [<c03a8a30>] (driver_probe_device+0x48/0x60) from [<c03a8ad4>] (__driver_attach+0x8c/0x90)
[ 5.238311] [<c03a8ad4>] (__driver_attach+0x8c/0x90) from [<c03a7b24>] (bus_for_each_dev+0x50/0x7c)
[ 5.238311] [<c03a7b24>] (bus_for_each_dev+0x50/0x7c) from [<c03a82ec>] (bus_add_driver+0x190/0x250)
[ 5.238311] [<c03a82ec>] (bus_add_driver+0x190/0x250) from [<c03a8cf8>] (driver_register+0x78/0x13c)
[ 5.238433] [<c03a8cf8>] (driver_register+0x78/0x13c) from [<c0428040>] (usb_register_driver+0x78/0x13c)
[ 5.238464] [<c0428040>] (usb_register_driver+0x78/0x13c) from [<c005b680>] (do_one_initcall+0x34/0x188)
[ 5.238494] [<c005b680>] (do_one_initcall+0x34/0x188) from [<c00e11f0>] (sys_init_module+0xb0/0x1c0)
[ 5.238525] [<c00e11f0>] (sys_init_module+0xb0/0x1c0) from [<c0065c40>] (ret_fast_syscall+0x0/0x30)
Move the two offenders to the private structure which is kmalloc-ed,
and thus safe.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
---
drivers/net/usb/smsc95xx.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index bc86f4b..727874d 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -49,6 +49,8 @@
struct smsc95xx_priv {
u32 mac_cr;
+ u32 hash_hi;
+ u32 hash_lo;
spinlock_t mac_cr_lock;
bool use_tx_csum;
bool use_rx_csum;
@@ -370,10 +372,11 @@ static void smsc95xx_set_multicast(struct net_device *netdev)
{
struct usbnet *dev = netdev_priv(netdev);
struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
- u32 hash_hi = 0;
- u32 hash_lo = 0;
unsigned long flags;
+ pdata->hash_hi = 0;
+ pdata->hash_lo = 0;
+
spin_lock_irqsave(&pdata->mac_cr_lock, flags);
if (dev->net->flags & IFF_PROMISC) {
@@ -394,13 +397,13 @@ static void smsc95xx_set_multicast(struct net_device *netdev)
u32 bitnum = smsc95xx_hash(ha->addr);
u32 mask = 0x01 << (bitnum & 0x1F);
if (bitnum & 0x20)
- hash_hi |= mask;
+ pdata->hash_hi |= mask;
else
- hash_lo |= mask;
+ pdata->hash_lo |= mask;
}
netif_dbg(dev, drv, dev->net, "HASHH=0x%08X, HASHL=0x%08X\n",
- hash_hi, hash_lo);
+ pdata->hash_hi, pdata->hash_lo);
} else {
netif_dbg(dev, drv, dev->net, "receive own packets only\n");
pdata->mac_cr &=
@@ -410,8 +413,8 @@ static void smsc95xx_set_multicast(struct net_device *netdev)
spin_unlock_irqrestore(&pdata->mac_cr_lock, flags);
/* Initiate async writes, as we can't wait for completion here */
- smsc95xx_write_reg_async(dev, HASHH, &hash_hi);
- smsc95xx_write_reg_async(dev, HASHL, &hash_lo);
+ smsc95xx_write_reg_async(dev, HASHH, &pdata->hash_hi);
+ smsc95xx_write_reg_async(dev, HASHL, &pdata->hash_lo);
smsc95xx_write_reg_async(dev, MAC_CR, &pdata->mac_cr);
}
--
1.7.0.4
^ permalink raw reply related
* Re: LRO disable warnings on kernel 2.6.38
From: Ben Hutchings @ 2011-03-18 14:17 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jesper Dangaard Brouer, netdev, Neil Horman, Alexander Duyck
In-Reply-To: <1300453519.2888.118.camel@edumazet-laptop>
On Fri, 2011-03-18 at 14:05 +0100, Eric Dumazet wrote:
> Le vendredi 18 mars 2011 à 12:12 +0100, Jesper Dangaard Brouer a écrit :
> > Hi
> >
> > I'm seeing the LRO disable warnings using kernel 2.6.38:
> >
> > [ 8.664759] NET: Registered protocol family 10
> > [ 8.838148] ADDRCONF(NETDEV_UP): eth71: link is not ready
> > [ 8.872639] ------------[ cut here ]------------
> > [ 8.872645] WARNING: at net/core/dev.c:1363 dev_disable_lro+0x7b/0x80()
> > [ 8.872647] Hardware name: ProLiant DL370 G6
> > [ 8.872648] Modules linked in: ipv6 nf_conntrack ip_tables loop i7core_edac edac_core ipmi_si ipmi_msghandler joydev hpilo pcspkr sg hpsa igb ata_piix netxen_nic dca [last unloaded: scsi_wait_scan]
> > [ 8.872660] Pid: 2221, comm: sysctl Not tainted 2.6.38-comx04 #2
> > [ 8.872662] Call Trace:
> > [ 8.872671] [<ffffffff81056e1f>] ? warn_slowpath_common+0x7f/0xc0
> > [ 8.872675] [<ffffffff81056e7a>] ? warn_slowpath_null+0x1a/0x20
> > [ 8.872680] [<ffffffff8140c0ab>] ? dev_disable_lro+0x7b/0x80
> > [ 8.872686] [<ffffffff81474f27>] ? devinet_sysctl_forward+0x147/0x180
> > [ 8.872691] [<ffffffff811872f7>] ? proc_sys_call_handler+0x97/0xd0
> > [ 8.872700] [<ffffffff81187344>] ? proc_sys_write+0x14/0x20
> > [ 8.872704] [<ffffffff81124148>] ? vfs_write+0xc8/0x180
> > [ 8.872707] [<ffffffff81124301>] ? sys_write+0x51/0x90
> > [ 8.872712] [<ffffffff8100b8c2>] ? system_call_fastpath+0x16/0x1b
> > [ 8.872714] ---[ end trace 6245283cb8d484cc ]---
> >
> > The strange part is that I didn't see this warning on my testlab and
> > pre-prod servers. The warning is from the first production server,
> > which got kernel 2.6.38 deployed this morning.
> >
> > The NIC driver is igb.
> >
> > The only difference in hardware between the production and
> > pre-production server (which didn't show the warning), is the
> > prod-server have an extra dual-port original Intel NIC, dev-named
> > "eth71". And its just after the init of eth71, the warning occurs.
> >
> > We usually use a 6 port NIC from Hotlava, which is based on the same
> > chip 82576 and also uses the same igb driver.
> >
> > Intel orig NIC eth71
> > albpd4:~# ethtool -i eth71
> > driver: igb
> > version: 2.1.0-k2
> > firmware-version: 1.2-1
> > bus-info: 0000:21:00.0
> >
> > Hotlava Intel chip based NIC eth51:
> > albpd4:~# ethtool -i eth51
> > driver: igb
> > version: 2.1.0-k2
> > firmware-version: 1.2-1
> > bus-info: 0000:1d:00.1
> >
> > I don't understand why I don't see the warning on my pre-prod server,
> > which only have the Hotlava NIC?!?
> >
>
> Hmm, WARN_ON() message is not very nice in this case I'm afraid, we dont
> even know offender
WARN is correct as this is a driver bug. But I agree that the
device/driver ID should be included.
Ben.
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0b88eba..571ab70 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1361,7 +1361,8 @@ void dev_disable_lro(struct net_device *dev)
> dev->ethtool_ops->set_flags(dev, flags);
> }
> }
> - WARN_ON(dev->features & NETIF_F_LRO);
> + if (dev->features & NETIF_F_LRO)
> + netdev_err(dev, "Could not disable LRO\n");
> }
> EXPORT_SYMBOL(dev_disable_lro);
>
>
>
>
>
> --
> 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
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: SO_BINDTODEVICE inconsistency between IPv4 and IPv6
From: Brian Haley @ 2011-03-18 14:31 UTC (permalink / raw)
To: David Woodhouse
Cc: netdev, Yuniverg, Michael, Yedvab, Nadav, YOSHIFUJI Hideaki
In-Reply-To: <1300438473.16342.18.camel@macbook.infradead.org>
On 03/18/2011 04:54 AM, David Woodhouse wrote:
> On Thu, 2011-03-17 at 21:26 -0400, Brian Haley wrote:
>> Hmm, "connection refused", do you have any iptables rules installed? Connecting
>> to a local global address worked fine for me on 2.6.32-30 using a home-grown
>> test app.
>
> Thanks for looking at this.
>
> Just to confirm... after your server does SO_BINDTODEVICE to 'lo', your
> clients on the same host can make a successful connection to global IPv6
> addresses which are assigned to the *other* interfaces?
>
> Can you show your version of the test app, and your results? What kernel
> is this on?
Sorry, I just re-ran my test again and noticed the SO_BINDTODEVICE failed,
since I was running it as myself, not root, so I see the same behavior as
you. I'm not sure if this is a bug per-se, and there is this comment
in ip6_rcv() pointing towards this:
/*
* Store incoming device index. When the packet will
* be queued, we cannot refer to skb->dev anymore.
*
* BTW, when we send a packet for our own local address on a
* non-loopback interface (e.g. ethX), it is being delivered
* via the loopback interface (lo) here; skb->dev = loopback_dev.
* It, however, should be considered as if it is being
* arrived via the sending interface (ethX), because of the
* nature of scoping architecture. --yoshfuji
*/
IP6CB(skb)->iif = skb_dst(skb) ? ip6_dst_idev(skb_dst(skb))->dev->ifindex : dev->ifindex;
That's probably why it's not matching.
I think Yoshifuji would be the best one to ask, cc'd.
-Brian
^ 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