* Re: [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Patrick McHardy @ 2009-11-19 14:38 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Eric Dumazet, linux-kernel, netdev, David Miller,
Stephen Hemminger, Herbert Xu, Patrick Mullaney,
Eric W. Biederman, Edge Virtual Bridging, Anna Fischer, bridge,
virtualization, Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <200911181059.45331.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 18 November 2009, Eric Dumazet wrote:
>>> --- a/drivers/net/macvlan.c
>>> +++ b/drivers/net/macvlan.c
>>> @@ -33,12 +33,6 @@
>>>
>>> #define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
>>>
>>> -enum macvlan_type {
>>> - MACVLAN_PRIVATE = 1,
>>> - MACVLAN_VEPA = 2,
>>> - MACVLAN_BRIDGE = 4,
>>> -};
>> I realize you defined MACVLAN_PRIVATE in patch 2, but used MACVLAN_MODE_PRIVATE,
>> so patch 2 is not compilable and breaks bisection ?
>>
>
> Hmm, right. I'll fix that up as well.
> +enum ifla_macvlan_mode {
> + MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
> + MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
> + MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
> +};
Please also keep the enum named something without ifla_ since
the mode values themselves are not netlink attributes. Just
macvlan_mode seems fine.
^ permalink raw reply
* Re: [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Arnd Bergmann @ 2009-11-19 14:47 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric Dumazet, linux-kernel, netdev, David Miller,
Stephen Hemminger, Herbert Xu, Patrick Mullaney,
Eric W. Biederman, Edge Virtual Bridging, Anna Fischer, bridge,
virtualization, Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B05586C.5020308@trash.net>
On Thursday 19 November 2009, Patrick McHardy wrote:
> > +enum ifla_macvlan_mode {
> > + MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
> > + MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
> > + MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
> > +};
>
> Please also keep the enum named something without ifla_ since
> the mode values themselves are not netlink attributes. Just
> macvlan_mode seems fine.
Ok, good. I was unsure on the naming and also changed between MACVLAN_*
and MACVLAN_MODE_* a few times.
Thanks for the clarification,
Arnd <><
^ permalink raw reply
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Patrick McHardy @ 2009-11-19 14:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Eric W. Biederman, Eric Dumazet, linux-kernel, netdev,
David Miller, Stephen Hemminger, Herbert Xu, Patrick Mullaney,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <200911191244.43916.arnd@arndb.de>
Arnd Bergmann wrote:
> On Thursday 19 November 2009, Eric W. Biederman wrote:
>>> It seems that we should never drop dst then. We either forward the frame to
>>> netif_rx or to dev_queue_xmit, and from how I read it now, we want to keep
>>> the dst in both cases.
>> When we loop back on our selves we certainly need to have dst clear because
>> we don't know how to cache routes through multiple network namespaces.
>
> Ah, right. So should I add the explicit dst_drop to the new dev_forward_skb()
> then? The veth driver doesn't need it, but it also looks like it won't hurt.
Yes, I think that should be fine.
^ permalink raw reply
* Re: NET: Questions about supporting older kernel's with kmods
From: Ben Hutchings @ 2009-11-19 14:53 UTC (permalink / raw)
To: Gregory Haskins; +Cc: netdev, linux-kernel
In-Reply-To: <4B055479.8070101@gmail.com>
On Thu, 2009-11-19 at 09:21 -0500, Gregory Haskins wrote:
> Hi All,
>
> So I was in the process of packaging up my venet driver so that it could
> not only support the in-tree build (in -next), but also build as a KMP
> for inclusion in existing distros that already shipped (like SLE, RHEL,
> CentOS, etc).
>
> The problem I ran into is that the ethtool and netdev_ops components of
> the in-tree version do not necessarily align with the substrate
> capabilities of older kernels. What are the best-practices surrounding
> this issue?
>
> Q1) Is there any official CONFIG tags (e.g. HAVE_NETDEV_OPS) I can key
> off of,
These feature test macros are not consistently provided.
> or should I simply look at the kernel version?
That works up to a point, but the 'enterprise' distros backport a lot to
earlier kernel versions which can make version tests invalid.
Some out-of-tree/backported drivers use autoconf-style tests, but there
is no standard way of doing this.
[...]
> Q2) Is it considered "bad form" to include such compile-time directives
> in the version of the code going upstream?
[...]
Yes. Don't do that.
Ben.
--
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: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Ben Hutchings @ 2009-11-19 14:54 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA69A337F@rrsmsx501.amr.corp.intel.com>
On Wed, 2009-11-18 at 16:33 -0700, Williams, Mitch A wrote:
[...]
> In the case of SR-IOV on our hardware, these filters are perfect - no
> hash tables are required. (We do use hash tables when we have a bunch
> of multicast addresses, but that's not what this is about.)
>
> MAC filters deny packets by default, so you won't get anything without
> a valid MAC filter on the queue.
>
> A queue with no VLAN filters will receive packets from all VLANs,
> albeit with the tags passed up intact. So in that sense, the VLAN
> filters are default-allow.
>
> However, once you enable any VLAN filter, the hardware starts
> stripping tags and begins to deny packets by default.
>
> Based on these semantics, the filtering operation that I've described
> above makes perfect sense.
[...]
But they are not the semantics we would want in supposedly generic
netdev operations.
Ben.
--
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
* netfilter 00/02: Netfilter fixes
From: Patrick McHardy @ 2009-11-19 14:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy, netfilter-devel
Hi Dave,
following are two patches for netfilter, fixing
- a positive errno return value in the osf match
- a sleeping function called under RCU lock in the nf_log seq_show function
Please apply or pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Thanks!
net/netfilter/nf_log.c | 18 +++++-------------
net/netfilter/xt_osf.c | 2 +-
2 files changed, 6 insertions(+), 14 deletions(-)
Roel Kluin (1):
netfilter: xt_osf: fix xt_osf_remove_callback() return value
Wu Fengguang (1):
netfilter: nf_log: fix sleeping function called from invalid context in seq_show()
^ permalink raw reply
* netfilter 01/02: xt_osf: fix xt_osf_remove_callback() return value
From: Patrick McHardy @ 2009-11-19 14:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20091119145902.18633.28666.sendpatchset@x2.localnet>
commit 1c622ae67bfc729891f5cd80795b15b87e6ac471
Author: Roel Kluin <roel.kluin@gmail.com>
Date: Fri Nov 13 09:31:35 2009 +0100
netfilter: xt_osf: fix xt_osf_remove_callback() return value
Return a negative error value.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/xt_osf.c b/net/netfilter/xt_osf.c
index 63e1905..4d1a41b 100644
--- a/net/netfilter/xt_osf.c
+++ b/net/netfilter/xt_osf.c
@@ -118,7 +118,7 @@ static int xt_osf_remove_callback(struct sock *ctnl, struct sk_buff *skb,
{
struct xt_osf_user_finger *f;
struct xt_osf_finger *sf;
- int err = ENOENT;
+ int err = -ENOENT;
if (!osf_attrs[OSF_ATTR_FINGER])
return -EINVAL;
^ permalink raw reply related
* netfilter 02/02: nf_log: fix sleeping function called from invalid context in seq_show()
From: Patrick McHardy @ 2009-11-19 14:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Patrick McHardy, netfilter-devel
In-Reply-To: <20091119145902.18633.28666.sendpatchset@x2.localnet>
commit 7378396cd172cc058fa62220c6486419046c4e0c
Author: Wu Fengguang <fengguang.wu@intel.com>
Date: Fri Nov 13 09:34:44 2009 +0100
netfilter: nf_log: fix sleeping function called from invalid context in seq_show()
[ 171.925285] BUG: sleeping function called from invalid context at kernel/mutex.c:280
[ 171.925296] in_atomic(): 1, irqs_disabled(): 0, pid: 671, name: grep
[ 171.925306] 2 locks held by grep/671:
[ 171.925312] #0: (&p->lock){+.+.+.}, at: [<c10b8acd>] seq_read+0x25/0x36c
[ 171.925340] #1: (rcu_read_lock){.+.+..}, at: [<c1391dac>] seq_start+0x0/0x44
[ 171.925372] Pid: 671, comm: grep Not tainted 2.6.31.6-4-netbook #3
[ 171.925380] Call Trace:
[ 171.925398] [<c105104e>] ? __debug_show_held_locks+0x1e/0x20
[ 171.925414] [<c10264ac>] __might_sleep+0xfb/0x102
[ 171.925430] [<c1461521>] mutex_lock_nested+0x1c/0x2ad
[ 171.925444] [<c1391c9e>] seq_show+0x74/0x127
[ 171.925456] [<c10b8c5c>] seq_read+0x1b4/0x36c
[ 171.925469] [<c10b8aa8>] ? seq_read+0x0/0x36c
[ 171.925483] [<c10d5c8e>] proc_reg_read+0x60/0x74
[ 171.925496] [<c10d5c2e>] ? proc_reg_read+0x0/0x74
[ 171.925510] [<c10a4468>] vfs_read+0x87/0x110
[ 171.925523] [<c10a458a>] sys_read+0x3b/0x60
[ 171.925538] [<c1002a49>] syscall_call+0x7/0xb
Fix it by replacing RCU with nf_log_mutex.
Reported-by: "Yin, Kangkai" <kangkai.yin@intel.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nf_log.c b/net/netfilter/nf_log.c
index c93494f..d65d348 100644
--- a/net/netfilter/nf_log.c
+++ b/net/netfilter/nf_log.c
@@ -128,9 +128,8 @@ EXPORT_SYMBOL(nf_log_packet);
#ifdef CONFIG_PROC_FS
static void *seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(RCU)
{
- rcu_read_lock();
+ mutex_lock(&nf_log_mutex);
if (*pos >= ARRAY_SIZE(nf_loggers))
return NULL;
@@ -149,9 +148,8 @@ static void *seq_next(struct seq_file *s, void *v, loff_t *pos)
}
static void seq_stop(struct seq_file *s, void *v)
- __releases(RCU)
{
- rcu_read_unlock();
+ mutex_unlock(&nf_log_mutex);
}
static int seq_show(struct seq_file *s, void *v)
@@ -161,7 +159,7 @@ static int seq_show(struct seq_file *s, void *v)
struct nf_logger *t;
int ret;
- logger = rcu_dereference(nf_loggers[*pos]);
+ logger = nf_loggers[*pos];
if (!logger)
ret = seq_printf(s, "%2lld NONE (", *pos);
@@ -171,22 +169,16 @@ static int seq_show(struct seq_file *s, void *v)
if (ret < 0)
return ret;
- mutex_lock(&nf_log_mutex);
list_for_each_entry(t, &nf_loggers_l[*pos], list[*pos]) {
ret = seq_printf(s, "%s", t->name);
- if (ret < 0) {
- mutex_unlock(&nf_log_mutex);
+ if (ret < 0)
return ret;
- }
if (&t->list[*pos] != nf_loggers_l[*pos].prev) {
ret = seq_printf(s, ",");
- if (ret < 0) {
- mutex_unlock(&nf_log_mutex);
+ if (ret < 0)
return ret;
- }
}
}
- mutex_unlock(&nf_log_mutex);
return seq_printf(s, ")\n");
}
^ permalink raw reply related
* Re: NET: Questions about supporting older kernel's with kmods
From: Gregory Haskins @ 2009-11-19 14:59 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, linux-kernel
In-Reply-To: <1258642393.2837.5.camel@achroite.uk.solarflarecom.com>
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Ben Hutchings wrote:
> On Thu, 2009-11-19 at 09:21 -0500, Gregory Haskins wrote:
[...]
>
>> or should I simply look at the kernel version?
>
> That works up to a point, but the 'enterprise' distros backport a lot to
> earlier kernel versions which can make version tests invalid.
Good point
>
> Some out-of-tree/backported drivers use autoconf-style tests, but there
> is no standard way of doing this.
>
Yeah, this might be the only sane way. It turns out that my ETHTOOL
issue was trivial. I was missing "#include <linux/ethtool.h>" which
worked in upstream, but not in older kernels. So that issue is resolved.
Now I just need to figure out netdev_ops. Perhaps I will just patch the
netdev_ops out when building a kmod, since its just
a different way to describe the same thing, and the resulting driver
will perform the same.
> [...]
>> Q2) Is it considered "bad form" to include such compile-time directives
>> in the version of the code going upstream?
> [...]
>
> Yes. Don't do that.
Ok.
Thanks Ben,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 15:16 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
Hi,
I have a problem with tg3 driver on a custom MPC8536 based board
running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
The problem I'm seeing is that the downing and interface leads to
permanent link loss, even after interface is upped again. E.g, to
reproduce the problem it is sufficient to run:
modprobe tg3
ifconfig eth2 up
ifconfig eth2 down
ifconfig eth2 up
After ifdown PHY LEDs also go down and do not come back
after ifup. Ethtool reports that no link is detected. After reloading
the driver the link comes back.
Am I the only one seeing this problem ?
Any help on fixing this is appreciated.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: Problem with VLANs and via-velocity driver
From: Patrick McHardy @ 2009-11-19 15:17 UTC (permalink / raw)
To: Séguier Régis; +Cc: Kevin Shanahan, netdev
In-Reply-To: <4AFD4595.1070904@e-teleport.net>
Séguier Régis wrote:
> Patrick McHardy a écrit :
>>
>>>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>>>> Does "ip link add link eth0 type vlan id 0" make any difference?
>>>> If not, does "ip link set eth0 promisc on"?
>>>>
>>> When we patch the driver to support multiple vlan, we decide to use the
>>> vlan 0 to desactivate the vlan filtering.
>>>
>>
>> Why? The usual behaviour is to receive both tagged and untagged
>> frames.
>>
> We decide this with françois as an alternative to desactivate the NIC
> vlan filtering instead of creating a modul parameter.
> The vlan id 0 need to be created but not necessary activate.
That doesn't seem like a good idea since it behaves differently than
any other driver supporting VLAN.
> In september 2008, we had a discution about exactly the same problem.
> You speak about the possibility of an ALLVLAN device flag.
That was meant for the case where hardware filtering for specific VLANs
is active and you want to see traffic of VLANs not configured locally
without switching to promiscous mode.
> I think i proposed a patch to desactivate NIC vlan filtering when we are
> in promisc mode but not used.
Yes, in promiscous mode VLAN filtering should be disabled.
^ permalink raw reply
* Re: Problem with VLANs and via-velocity driver
From: Patrick McHardy @ 2009-11-19 15:18 UTC (permalink / raw)
To: Kevin Shanahan; +Cc: netdev
In-Reply-To: <20091116005750.GR838@cubit>
Kevin Shanahan wrote:
> On Fri, Nov 13, 2009 at 07:40:39AM +0100, Patrick McHardy wrote:
>> Kevin Shanahan wrote:
>>> Hi,
>>>
>>> I've had some problems with getting a fairly simple (I thought) VLAN
>>> configuration working with the on board Via NICs on my Via M700
>>> board. Looks like as soon as a tagged VLAN interface is added, the
>>> underlying "raw" (untagged) interface stops responding.
>>>
>>> ...
>>>
>>> A bit of searching found a few references to similar problems going
>>> back a few years (2005, 2007). Sounded like there were some driver
>>> issues, but it wasn't clear from the messages I found whether they
>>> were believed to be fixed or not. I tried the same test using a
>>> differnt NIC with the tg3 driver and there were no problems, so it
>>> looks to me like it's still a via-velocity issue. Unfortunately I
>>> don't have room to add NICs to this machine and need to use the on
>>> board Via hardware.
>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>> Does "ip link add link eth0 type vlan id 0" make any difference?
>
> Thanks Patrick, this command got the untagged interface working again
> (eth1 in my case). I can use this as a work around.
>
> I didn't really understand if there was a good reason for the
> special-casing in this driver, but from at least from my user
> perspective I think it would be better if the drivers were consistent
> in how they handle this.
I agree.
^ permalink raw reply
* Re: Oops in Unix sockets code
From: Sebastian Ott @ 2009-11-19 15:46 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Christian Borntraeger, Blaschka, netdev, linux-s390
In-Reply-To: <4B05542D.7060401@gmail.com>
On Thu, 19 Nov 2009, Eric Dumazet wrote:
...
> 2.6.31 has a known bug
>
> 2.6.31.4 should correct it
>
> commit 657453424a3c382035983f9a47306fafea730f6d
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu Sep 24 10:49:24 2009 +0000
indeed, problem didn't show up with d99927f applied. thanks for
pointing that out.
sebastian
^ permalink raw reply
* Re: [PATCH] ieee802154: dont leak skbs in ieee802154_fake_xmit()
From: Dmitry Eremin-Solenikov @ 2009-11-19 15:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4B052BCA.4020901@gmail.com>
On Thu, Nov 19, 2009 at 2:28 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> ieee802154_fake_xmit() should free skbs since it returns NETDEV_TX_OK
Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
David, please apply.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: tg3: link is permanently down after ifdown and ifup
From: Felix Radensky @ 2009-11-19 16:08 UTC (permalink / raw)
To: netdev@vger.kernel.org, linuxppc-dev@ozlabs.org
In-Reply-To: <4B056158.5060104@embedded-sol.com>
Hi,
The problem goes away if I remove the call to
tg3_set_power_state(tp, PCI_D3hot);
from tg3_close().
Some relevant stuff from dmesg:
pci 0002:05:00.0: PME# supported from D3hot D3cold
pci 0002:05:00.0: PME# disabled
tg3.c:v3.102 (September 1, 2009)
tg3 0002:05:00.0: enabling device (0000 -> 0002)
tg3 0002:05:00.0: PME# disabled
tg3 mdio bus: probed
eth2: Tigon3 [partno(BCM57760) rev 57780001] (PCI Express) MAC address
00:10:18:00:00:00
eth2: attached PHY driver [Broadcom BCM57780] (mii_bus:phy_addr=500:01)
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth2: dma_rwctrl[76180000] dma_mask[64-bit]
Is my problem related to hardware or it's a tg3 driver bug ?
Thanks a lot.
Felix.
Felix Radensky wrote:
> Hi,
>
> I have a problem with tg3 driver on a custom MPC8536 based board
> running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
> linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
>
> The problem I'm seeing is that the downing and interface leads to
> permanent link loss, even after interface is upped again. E.g, to
> reproduce the problem it is sufficient to run:
>
> modprobe tg3
> ifconfig eth2 up
> ifconfig eth2 down
> ifconfig eth2 up
>
> After ifdown PHY LEDs also go down and do not come back
> after ifup. Ethtool reports that no link is detected. After reloading
> the driver the link comes back.
>
> Am I the only one seeing this problem ?
> Any help on fixing this is appreciated.
>
> Thanks a lot.
>
> Felix.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Jens Rosenboom @ 2009-11-19 16:39 UTC (permalink / raw)
To: netdev; +Cc: Dhananjay Phadke
My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1. With the
newer kernel I can see packets been received on the switch it is connected to, but
the kernel doesn't report any sent packets in the interface counters and nothing
is being received either.
I've tried to bisect this, but only seems the end up with kernels that do not boot
at all because some SCSI stuff goes bad.
Any hints how to address this further? Please keep me on CC:.
Yours,
Jens
^ permalink raw reply
* RE: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Dhananjay Phadke @ 2009-11-19 18:07 UTC (permalink / raw)
To: Jens Rosenboom, netdev@vger.kernel.org; +Cc: Amit Salecha
In-Reply-To: <20091119163908.GJ14661@jayr.de>
> My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1.
> With the
> newer kernel I can see packets been received on the switch it is
> connected to, but
> the kernel doesn't report any sent packets in the interface counters and
> nothing
> is being received either.
>
> I've tried to bisect this, but only seems the end up with kernels that do
> not boot
> at all because some SCSI stuff goes bad.
Any particular reason for using -rc1 kernel and not 2.6.31 stable kernel?
-Dhananjay
^ permalink raw reply
* Re: [BUG] netxen: Stops working between 2.6.30 and 2.6.31-rc1
From: Jens Rosenboom @ 2009-11-19 18:36 UTC (permalink / raw)
To: Dhananjay Phadke; +Cc: Jens Rosenboom, netdev@vger.kernel.org, Amit Salecha
In-Reply-To: <7608421F3572AB4292BB2532AE89D5658B0B95BD5C@AVEXMB1.qlogic.org>
On Thu, Nov 19, 2009 at 10:07:21AM -0800, Dhananjay Phadke wrote:
> > My netxen 10G card stops working somewhere between 2.6.30 and 2.6.31-rc1.
> > With the
> > newer kernel I can see packets been received on the switch it is
> > connected to, but
> > the kernel doesn't report any sent packets in the interface counters and
> > nothing
> > is being received either.
> >
> > I've tried to bisect this, but only seems the end up with kernels that do
> > not boot
> > at all because some SCSI stuff goes bad.
>
> Any particular reason for using -rc1 kernel and not 2.6.31 stable kernel?
Sorry, I forgot to mention that all later kernels that I tested
including 2.6.31 and the current net-2.6 also fail, so the badness
comes in somewhere in between 2.6.30 and 2.6.31-rc1.
I also noticed that the newer kernel allocate four interrupts for the
card instead of only one, but none of them seem to get triggered, the
/proc/interrupts counters all stay at zero.
^ permalink raw reply
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-19 18:43 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1258642493.2837.8.camel@achroite.uk.solarflarecom.com>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Thursday, November 19, 2009 6:55 AM
>[...]
>> In the case of SR-IOV on our hardware, these filters are perfect - no
>> hash tables are required. (We do use hash tables when we have a bunch
>> of multicast addresses, but that's not what this is about.)
>>
>> MAC filters deny packets by default, so you won't get anything without
>> a valid MAC filter on the queue.
>>
>> A queue with no VLAN filters will receive packets from all VLANs,
>> albeit with the tags passed up intact. So in that sense, the VLAN
>> filters are default-allow.
>>
>> However, once you enable any VLAN filter, the hardware starts
>> stripping tags and begins to deny packets by default.
>>
>> Based on these semantics, the filtering operation that I've described
>> above makes perfect sense.
>[...]
>
>But they are not the semantics we would want in supposedly generic
>netdev operations.
>
OK, point taken. Specific hardware features/limitations shouldn't affect kernel policy.
However, I'm still back to code complexity, and general usage models.
Please explain specifically what you perceive to be the difference between:
$ ip link set eth1 queue 1 mac <blah>
$ ip link set eth1 queue 1 vlan <foo>
and
$ ip link set eth1 queue 1 mac <blah> vlan <foo>
The two filter types are, in my mind, completely orthogonal. You can have one, or the other, or both, or neither. What do we gain by glomming both options on one command line? And is this worth the tradeoff of more complex code?
-Mitch
^ permalink raw reply
* Re: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Patrick McHardy @ 2009-11-19 18:58 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Ben Hutchings, Kirsher, Jeffrey T, davem@davemloft.net,
shemminger@vyatta.com, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA6A1FF82@rrsmsx501.amr.corp.intel.com>
Williams, Mitch A wrote:
> However, I'm still back to code complexity, and general usage models.
>
> Please explain specifically what you perceive to be the difference between:
>
> $ ip link set eth1 queue 1 mac <blah>
> $ ip link set eth1 queue 1 vlan <foo>
>
> and
>
> $ ip link set eth1 queue 1 mac <blah> vlan <foo>
>
> The two filter types are, in my mind, completely orthogonal. You can have one, or the other, or both, or neither. What do we gain by glomming both options on one command line? And is this worth the tradeoff of more complex code?
One argument would be that "ip link show" should probably display
all filters, so they all need to be included in the dump message.
And this is exactly the same message type used for configuring
links and the API is supposed to be symetric, meaning you can
send a dump message with NLM_F_REQUEST to the kernel again and
it (re-)creates the same object.
^ permalink raw reply
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Ben Hutchings @ 2009-11-19 18:59 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA6A1FF82@rrsmsx501.amr.corp.intel.com>
On Thu, 2009-11-19 at 11:43 -0700, Williams, Mitch A wrote:
[...]
> OK, point taken. Specific hardware features/limitations shouldn't affect kernel policy.
>
> However, I'm still back to code complexity, and general usage models.
>
> Please explain specifically what you perceive to be the difference between:
>
> $ ip link set eth1 queue 1 mac <blah>
> $ ip link set eth1 queue 1 vlan <foo>
>
> and
>
> $ ip link set eth1 queue 1 mac <blah> vlan <foo>
>
> The two filter types are, in my mind, completely orthogonal. You can
> have one, or the other, or both, or neither. What do we gain by
> glomming both options on one command line? And is this worth the
> tradeoff of more complex code?
I think you need to state clearly what semantics you are now proposing
before I can make any judgement on them.
Ben.
--
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: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-19 19:12 UTC (permalink / raw)
To: Patrick McHardy
Cc: Ben Hutchings, Kirsher, Jeffrey T, davem@davemloft.net,
shemminger@vyatta.com, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <4B059563.3010702@trash.net>
>From: Patrick McHardy [mailto:kaber@trash.net]
>Sent: Thursday, November 19, 2009 10:59 AM
[snip]
>
>One argument would be that "ip link show" should probably display
>all filters, so they all need to be included in the dump message.
>
>And this is exactly the same message type used for configuring
>links and the API is supposed to be symetric, meaning you can
>send a dump message with NLM_F_REQUEST to the kernel again and
>it (re-)creates the same object.
Yeah, we've indentified that as a need - that's one reason we sent this out as an RFC. I'll implement the "show" semantics before we repost.
-Mitch
^ permalink raw reply
* [PATCH] drivers/net: tasklet_init - Remove unnecessary leading & from second arg
From: Joe Perches @ 2009-11-19 19:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Changed function pointer use from non-majority address-of style
to majority short form without & via: (was: 8 with &, 36 without)
grep -rPl "\btasklet_init\s*\([^,\)]+,\s*\&" drivers/net | while read file ; do \
perl -i -e 'local $/; while (<>) { s@(\btasklet_init\s*\([^,\)]+,\s*)\&@\1@g ; print ; }' $file ;\
done
Compile tested allyesconfig x86
Signed-off-by: Joe Perches <joe@perches.com>
drivers/net/cnic.c | 4 ++--
drivers/net/jme.c | 10 +++++-----
drivers/net/skge.c | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index e503384..ee7eb9e 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -3387,7 +3387,7 @@ static int cnic_init_bnx2_irq(struct cnic_dev *dev)
cp->bnx2_status_blk = cp->status_blk;
cp->last_status_idx = cp->bnx2_status_blk->status_idx;
- tasklet_init(&cp->cnic_irq_task, &cnic_service_bnx2_msix,
+ tasklet_init(&cp->cnic_irq_task, cnic_service_bnx2_msix,
(unsigned long) dev);
err = request_irq(ethdev->irq_arr[0].vector, cnic_irq, 0,
"cnic", dev);
@@ -3787,7 +3787,7 @@ static int cnic_init_bnx2x_irq(struct cnic_dev *dev)
struct cnic_eth_dev *ethdev = cp->ethdev;
int err = 0;
- tasklet_init(&cp->cnic_irq_task, &cnic_service_bnx2x_bh,
+ tasklet_init(&cp->cnic_irq_task, cnic_service_bnx2x_bh,
(unsigned long) dev);
if (ethdev->drv_state & CNIC_DRV_STATE_USING_MSIX) {
err = request_irq(ethdev->irq_arr[0].vector, cnic_irq, 0,
diff --git a/drivers/net/jme.c b/drivers/net/jme.c
index 1d2a325..6c1b92f 100644
--- a/drivers/net/jme.c
+++ b/drivers/net/jme.c
@@ -2764,19 +2764,19 @@ jme_init_one(struct pci_dev *pdev,
atomic_set(&jme->rx_empty, 1);
tasklet_init(&jme->pcc_task,
- &jme_pcc_tasklet,
+ jme_pcc_tasklet,
(unsigned long) jme);
tasklet_init(&jme->linkch_task,
- &jme_link_change_tasklet,
+ jme_link_change_tasklet,
(unsigned long) jme);
tasklet_init(&jme->txclean_task,
- &jme_tx_clean_tasklet,
+ jme_tx_clean_tasklet,
(unsigned long) jme);
tasklet_init(&jme->rxclean_task,
- &jme_rx_clean_tasklet,
+ jme_rx_clean_tasklet,
(unsigned long) jme);
tasklet_init(&jme->rxempty_task,
- &jme_rx_empty_tasklet,
+ jme_rx_empty_tasklet,
(unsigned long) jme);
tasklet_disable_nosync(&jme->linkch_task);
tasklet_disable_nosync(&jme->txclean_task);
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index ba5eb14..34b4e7d 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -3947,7 +3947,7 @@ static int __devinit skge_probe(struct pci_dev *pdev,
hw->pdev = pdev;
spin_lock_init(&hw->hw_lock);
spin_lock_init(&hw->phy_lock);
- tasklet_init(&hw->phy_task, &skge_extirq, (unsigned long) hw);
+ tasklet_init(&hw->phy_task, skge_extirq, (unsigned long) hw);
hw->regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000);
if (!hw->regs) {
^ permalink raw reply related
* RE: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Williams, Mitch A @ 2009-11-19 19:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: Kirsher, Jeffrey T, davem@davemloft.net, shemminger@vyatta.com,
netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1258657155.2837.10.camel@achroite.uk.solarflarecom.com>
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Thursday, November 19, 2009 10:59 AM
>> Please explain specifically what you perceive to be the difference
>between:
>>
>> $ ip link set eth1 queue 1 mac <blah>
>> $ ip link set eth1 queue 1 vlan <foo>
>>
>> and
>>
>> $ ip link set eth1 queue 1 mac <blah> vlan <foo>
>>
>> The two filter types are, in my mind, completely orthogonal. You can
>> have one, or the other, or both, or neither. What do we gain by
>> glomming both options on one command line? And is this worth the
>> tradeoff of more complex code?
>
>I think you need to state clearly what semantics you are now proposing
>before I can make any judgement on them.
>
OK, now I'm really confused, Ben. It seems that we are both asking each other the same question.
What I'm proposing is really the same as we have now for single-queue devices:
- A MAC filter is enabled by default. If you want to change the MAC address, you use a tool (ip or ifconfig) to change it.
- A VLAN filter is not enabled by default. If you want to filter on VLANs, then you load the 8021q module, and enable a filter.
The MAC filter is configured completely separately from the VLAN filter. Either one can be changed without affecting the other one and, in fact, you use two different tools to do these operations.
For SR-IOV VF devices, my proposed changes implement exactly the same thing. You use one command to change the MAC address. You use another command to change the VLAN filter. Changing one does not affect the other.
In this case, we use the same tool for both operations, but they're still separate operations.
-Mitch
N.B.
The major difference in VLAN filtering is that this implementation allows the VF to participate in only one VLAN, and the filter is applied independently of the VF driver. So you can put a specific VM on a VLAN without its knowledge. If you want the VM to have more intelligent VLAN filtering, you don't use this filter, and you load 8021q in the VM and set your filters there.
^ permalink raw reply
* [PATCH net-next] drivers/isdn/gigaset: tasklet_init - Remove unnecessary leading & from second arg
From: Joe Perches @ 2009-11-19 19:55 UTC (permalink / raw)
To: David Miller
Cc: netdev, Hansjoerg Lipp, Tilman Schmidt, Karsten Keil,
gigaset307x-common
Changed function pointer use from non-majority address-of style
to majority short form without & via:
grep -rPl "\btasklet_init\s*\([^,\)]+,\s*\&" drivers/isdn | while read file ; do \
perl -i -e 'local $/; while (<>) { s@(\btasklet_init\s*\([^,\)]+,\s*)\&@\1@g ; print ; }' $file ;\
done
Compile tested allyesconfig x86
Signed-off-by: Joe Perches <joe@perches.com>
drivers/isdn/gigaset/bas-gigaset.c | 4 ++--
drivers/isdn/gigaset/common.c | 2 +-
drivers/isdn/gigaset/interface.c | 2 +-
drivers/isdn/gigaset/ser-gigaset.c | 2 +-
drivers/isdn/gigaset/usb-gigaset.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/isdn/gigaset/bas-gigaset.c b/drivers/isdn/gigaset/bas-gigaset.c
index 9fd19db..95ebc51 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -2117,7 +2117,7 @@ static int gigaset_initbcshw(struct bc_state *bcs)
return 0;
}
tasklet_init(&ubc->sent_tasklet,
- &write_iso_tasklet, (unsigned long) bcs);
+ write_iso_tasklet, (unsigned long) bcs);
spin_lock_init(&ubc->isoinlock);
for (i = 0; i < BAS_INURBS; ++i)
@@ -2138,7 +2138,7 @@ static int gigaset_initbcshw(struct bc_state *bcs)
ubc->shared0s = 0;
ubc->stolen0s = 0;
tasklet_init(&ubc->rcvd_tasklet,
- &read_iso_tasklet, (unsigned long) bcs);
+ read_iso_tasklet, (unsigned long) bcs);
return 1;
}
diff --git a/drivers/isdn/gigaset/common.c b/drivers/isdn/gigaset/common.c
index c438cfc..82ed1cd 100644
--- a/drivers/isdn/gigaset/common.c
+++ b/drivers/isdn/gigaset/common.c
@@ -727,7 +727,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
cs->ev_tail = 0;
cs->ev_head = 0;
- tasklet_init(&cs->event_tasklet, &gigaset_handle_event,
+ tasklet_init(&cs->event_tasklet, gigaset_handle_event,
(unsigned long) cs);
cs->commands_pending = 0;
cs->cur_at_seq = 0;
diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
index 577809c..d2260b0 100644
--- a/drivers/isdn/gigaset/interface.c
+++ b/drivers/isdn/gigaset/interface.c
@@ -584,7 +584,7 @@ void gigaset_if_init(struct cardstate *cs)
if (!drv->have_tty)
return;
- tasklet_init(&cs->if_wake_tasklet, &if_wake, (unsigned long) cs);
+ tasklet_init(&cs->if_wake_tasklet, if_wake, (unsigned long) cs);
mutex_lock(&cs->mutex);
cs->tty_dev = tty_register_device(drv->tty, cs->minor_index, NULL);
diff --git a/drivers/isdn/gigaset/ser-gigaset.c b/drivers/isdn/gigaset/ser-gigaset.c
index ac3409e..168d585 100644
--- a/drivers/isdn/gigaset/ser-gigaset.c
+++ b/drivers/isdn/gigaset/ser-gigaset.c
@@ -434,7 +434,7 @@ static int gigaset_initcshw(struct cardstate *cs)
dev_set_drvdata(&cs->hw.ser->dev.dev, cs);
tasklet_init(&cs->write_tasklet,
- &gigaset_modem_fill, (unsigned long) cs);
+ gigaset_modem_fill, (unsigned long) cs);
return 1;
}
diff --git a/drivers/isdn/gigaset/usb-gigaset.c b/drivers/isdn/gigaset/usb-gigaset.c
index f56b2a8..3ab1dae 100644
--- a/drivers/isdn/gigaset/usb-gigaset.c
+++ b/drivers/isdn/gigaset/usb-gigaset.c
@@ -614,7 +614,7 @@ static int gigaset_initcshw(struct cardstate *cs)
ucs->bulk_out_urb = NULL;
ucs->read_urb = NULL;
tasklet_init(&cs->write_tasklet,
- &gigaset_modem_fill, (unsigned long) cs);
+ gigaset_modem_fill, (unsigned long) cs);
return 1;
}
^ 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