* Re: [PATCH v2 01/16] net: Move check of checksum features to netdev_fix_features()
From: David Miller @ 2011-01-24 23:29 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, bhutchings
In-Reply-To: <056dc972c354cb7904f63640117c75ac26d1a32b.1295734271.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sat, 22 Jan 2011 23:14:12 +0100 (CET)
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH v2 02/16] net: change netdev->features to u32
From: David Miller @ 2011-01-24 23:30 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, bhutchings
In-Reply-To: <d9fe088556152bd3b43390e0fb5ea20d83aef233.1295734271.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sat, 22 Jan 2011 23:14:12 +0100 (CET)
> Quoting Ben Hutchings: we presumably won't be defining features that
> can only be enabled on 64-bit architectures.
>
> Occurences found by `grep -r` on net/, drivers/net, include/
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
I'll apply this, with one change, adding the suggestion that
features and vlan_features be moved next to each other in
struct netdev, from Eric Dumazet.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 03/16] net: reduce and unify printk level in netdev_fix_features()
From: David Miller @ 2011-01-24 23:45 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, bhutchings
In-Reply-To: <29e476c368b6580f7ff5215ca759b69c75d0e021.1295734271.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sat, 22 Jan 2011 23:14:12 +0100 (CET)
> Reduce printk() levels to KERN_INFO in netdev_fix_features() as this will
> be used by ethtool and might spam dmesg unnecessarily.
>
> This converts the function to use netdev_info() instead of plain printk().
>
> As a side effect, bonding and bridge devices will now log dropped features
> on every slave device change.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
I've applied this with the 80-column issues fixed up, we can discuss
using KERN_DEBUG or whatever in follow-up patches.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 04/16] net: Introduce new feature setting ops
From: David Miller @ 2011-01-24 23:51 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, bhutchings
In-Reply-To: <7f0bf8e3fa40db0e188fc6310a5dd670718c0fc0.1295734271.git.mirq-linux@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Sat, 22 Jan 2011 23:14:13 +0100 (CET)
> This introduces a new framework to handle device features setting.
> It consists of:
> - new fields in struct net_device:
> + hw_features - features that hw/driver supports toggling
> + wanted_features - features that user wants enabled, when possible
> - new netdev_ops:
> + feat = ndo_fix_features(dev, feat) - API checking constraints for
> enabling features or their combinations
> + ndo_set_features(dev) - API updating hardware state to match
> changed dev->features
> - new ethtool commands:
> + ETHTOOL_GFEATURES/ETHTOOL_SFEATURES: get/set dev->wanted_features
> and trigger device reconfiguration if resulting dev->features
> changed
> + ETHTOOL_GSTRINGS(ETH_SS_FEATURES): get feature bits names (meaning)
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Ok, I'll stop applying patches right before this one as I'd like to see
at least some feedback from Ben wrt. the ethtool bits.
FWIW I like these changes (a lot). :-)
^ permalink raw reply
* [PATCH net-2.6] bnx2: Always set ETH_FLAG_TXVLAN
From: Michael Chan @ 2011-01-24 22:59 UTC (permalink / raw)
To: davem; +Cc: eric.dumazet, jesse, netdev
TSO does not work if the VLAN tag is in the packet (non-accelerated).
We may be able to remove this restriction in future firmware.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index df99edf..99e7652 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -7553,6 +7553,10 @@ bnx2_set_flags(struct net_device *dev, u32 data)
!(data & ETH_FLAG_RXVLAN))
return -EINVAL;
+ /* TSO with VLAN tag won't work with current firmware */
+ if (!(data & ETH_FLAG_TXVLAN))
+ return -EINVAL;
+
rc = ethtool_op_set_flags(dev, data, ETH_FLAG_RXHASH | ETH_FLAG_RXVLAN |
ETH_FLAG_TXVLAN);
if (rc)
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH v3 00/16] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-01-24 23:55 UTC (permalink / raw)
To: Trond Myklebust, J. Bruce Fields, Neil Brown, Kirill A. Shutemov,
Pavel Emelyanov
In-Reply-To: <1295012954-7769-1-git-send-email-kas@openvz.org>
On Fri, Jan 14, 2011 at 03:48:58PM +0200, Kirill A. Shutemov wrote:
> Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
> Only for client for now.
>
> It's step forwart to get nfs work from container.
Any feedback?
> Changelog:
>
> v3:
> - rebase to the current Linus' tree (52cfd503ad)
> - rework get_rpc_pipefs() once again;
> - solve problem with rmmod sunrpc moudle;
> - free dns cache on killing rpc_pipefs superblock.
>
> v2:
> - one of rpc_create() calls was missed initially, fixed;
> - change logic for get_rpc_pipefs(NULL);
> - export get_rpc_pipefs() to be able to use from modules (tnx J. Bruce Field);
> - change "From:" and "Signed-off-by:" addresses.
>
> v1:
> - initial revision of the patchset.
>
> Kirill A. Shutemov (16):
> sunrpc: mount rpc_pipefs on initialization
> sunrpc: introduce init_rpc_pipefs
> sunrpc: push init_rpc_pipefs up to rpc_create() callers
> sunrpc: tag svc_serv with rpc_pipefs mount point
> sunrpc: get rpc_pipefs mount point for svc_serv from callers
> lockd: get rpc_pipefs mount point from callers
> sunrpc: get rpc_pipefs mount point for rpcb_create[_local] from
> callers
> sunrpc: tag pipefs field of cache_detail with rpc_pipefs mount point
> sunrpc: introduce rpc_pipefs_add_destroy_cb()
> nfs: per-rpc_pipefs dns cache
> Export iterate_mounts symbol to be able to use from sunrpc module.
> sunrpc: introduce get_rpc_pipefs()
> nfs: introduce mount option 'rpcmount'
> sunrpc: make rpc_pipefs be mountable multiple times
> sunrpc: remove global init_rpc_pipefs
> Rework get_rpc_pipefs and introduce put_rpc_pipefs()
>
> fs/lockd/clntlock.c | 8 +-
> fs/lockd/host.c | 15 ++-
> fs/lockd/mon.c | 13 ++-
> fs/lockd/svc.c | 4 +-
> fs/namespace.c | 1 +
> fs/nfs/cache_lib.c | 18 +--
> fs/nfs/cache_lib.h | 3 +-
> fs/nfs/callback.c | 7 +-
> fs/nfs/callback.h | 3 +-
> fs/nfs/client.c | 45 ++++++-
> fs/nfs/dns_resolve.c | 137 ++++++++++++++++-----
> fs/nfs/dns_resolve.h | 15 +--
> fs/nfs/inode.c | 9 +--
> fs/nfs/internal.h | 10 ++-
> fs/nfs/mount_clnt.c | 1 +
> fs/nfs/namespace.c | 3 +-
> fs/nfs/nfs4namespace.c | 20 ++--
> fs/nfs/super.c | 20 +++
> fs/nfsd/nfs4callback.c | 5 +
> fs/nfsd/nfssvc.c | 20 +++-
> include/linux/lockd/bind.h | 3 +-
> include/linux/lockd/lockd.h | 4 +-
> include/linux/nfs_fs_sb.h | 1 +
> include/linux/sunrpc/cache.h | 9 +-
> include/linux/sunrpc/clnt.h | 5 +-
> include/linux/sunrpc/rpc_pipe_fs.h | 7 +-
> include/linux/sunrpc/svc.h | 9 +-
> net/sunrpc/cache.c | 16 ++-
> net/sunrpc/clnt.c | 19 ++--
> net/sunrpc/rpc_pipe.c | 235 ++++++++++++++++++++++++++++++++----
> net/sunrpc/rpcb_clnt.c | 19 ++-
> net/sunrpc/svc.c | 52 +++++---
> 32 files changed, 549 insertions(+), 187 deletions(-)
>
> --
> 1.7.3.4
>
--
Kirill A. Shutemov
^ permalink raw reply
* Re: Problems with /proc/net/tcp6 - possible bug - ipv6
From: David Miller @ 2011-01-25 0:02 UTC (permalink / raw)
To: runningdoglackey; +Cc: eric.dumazet, linux-kernel, netdev
In-Reply-To: <115440.16148.qm@web63902.mail.re1.yahoo.com>
From: PK <runningdoglackey@yahoo.com>
Date: Sat, 22 Jan 2011 11:42:54 -0800 (PST)
> These warnings show up when I run the script (or I presume any tcp6 connection
> flooder) with /proc/sys/net/tcp/ipv4/tcp_tw_recycle enabled. There's textual
> corruption of the traces a lot of the time. Here's a sample trace that doesn't
> appear to be corrupt. All the warnings I've seen are from route.c:209, and I
> don't see how that would cause memory corruption.
Please give this patch a try:
--------------------
>From d80bc0fd262ef840ed4e82593ad6416fa1ba3fc4 Mon Sep 17 00:00:00 2001
From: David S. Miller <davem@davemloft.net>
Date: Mon, 24 Jan 2011 16:01:58 -0800
Subject: [PATCH] ipv6: Always clone offlink routes.
Do not handle PMTU vs. route lookup creation any differently
wrt. offlink routes, always clone them.
Reported-by: PK <runningdoglackey@yahoo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv6/route.c | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 373bd04..1534508 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -72,8 +72,6 @@
#define RT6_TRACE(x...) do { ; } while (0)
#endif
-#define CLONE_OFFLINK_ROUTE 0
-
static struct rt6_info * ip6_rt_copy(struct rt6_info *ort);
static struct dst_entry *ip6_dst_check(struct dst_entry *dst, u32 cookie);
static unsigned int ip6_default_advmss(const struct dst_entry *dst);
@@ -738,13 +736,8 @@ restart:
if (!rt->rt6i_nexthop && !(rt->rt6i_flags & RTF_NONEXTHOP))
nrt = rt6_alloc_cow(rt, &fl->fl6_dst, &fl->fl6_src);
- else {
-#if CLONE_OFFLINK_ROUTE
+ else
nrt = rt6_alloc_clone(rt, &fl->fl6_dst);
-#else
- goto out2;
-#endif
- }
dst_release(&rt->dst);
rt = nrt ? : net->ipv6.ip6_null_entry;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v3 00/16] make rpc_pipefs be mountable multiple time
From: J. Bruce Fields @ 2011-01-25 0:25 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Trond Myklebust, Neil Brown, Pavel Emelyanov,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Rob Landley,
Al Viro, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110124235545.GA793-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
On Tue, Jan 25, 2011 at 01:55:45AM +0200, Kirill A. Shutemov wrote:
> On Fri, Jan 14, 2011 at 03:48:58PM +0200, Kirill A. Shutemov wrote:
> > Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
> > Only for client for now.
> >
> > It's step forwart to get nfs work from container.
>
> Any feedback?
I haven't seen any more problems with them, but also haven't looked all
that closely; I'm assuming Trond will handle them up at some point....
(Trond, tell me if I assume wrong.)
--b.
>
> > Changelog:
> >
> > v3:
> > - rebase to the current Linus' tree (52cfd503ad)
> > - rework get_rpc_pipefs() once again;
> > - solve problem with rmmod sunrpc moudle;
> > - free dns cache on killing rpc_pipefs superblock.
> >
> > v2:
> > - one of rpc_create() calls was missed initially, fixed;
> > - change logic for get_rpc_pipefs(NULL);
> > - export get_rpc_pipefs() to be able to use from modules (tnx J. Bruce Field);
> > - change "From:" and "Signed-off-by:" addresses.
> >
> > v1:
> > - initial revision of the patchset.
> >
> > Kirill A. Shutemov (16):
> > sunrpc: mount rpc_pipefs on initialization
> > sunrpc: introduce init_rpc_pipefs
> > sunrpc: push init_rpc_pipefs up to rpc_create() callers
> > sunrpc: tag svc_serv with rpc_pipefs mount point
> > sunrpc: get rpc_pipefs mount point for svc_serv from callers
> > lockd: get rpc_pipefs mount point from callers
> > sunrpc: get rpc_pipefs mount point for rpcb_create[_local] from
> > callers
> > sunrpc: tag pipefs field of cache_detail with rpc_pipefs mount point
> > sunrpc: introduce rpc_pipefs_add_destroy_cb()
> > nfs: per-rpc_pipefs dns cache
> > Export iterate_mounts symbol to be able to use from sunrpc module.
> > sunrpc: introduce get_rpc_pipefs()
> > nfs: introduce mount option 'rpcmount'
> > sunrpc: make rpc_pipefs be mountable multiple times
> > sunrpc: remove global init_rpc_pipefs
> > Rework get_rpc_pipefs and introduce put_rpc_pipefs()
> >
> > fs/lockd/clntlock.c | 8 +-
> > fs/lockd/host.c | 15 ++-
> > fs/lockd/mon.c | 13 ++-
> > fs/lockd/svc.c | 4 +-
> > fs/namespace.c | 1 +
> > fs/nfs/cache_lib.c | 18 +--
> > fs/nfs/cache_lib.h | 3 +-
> > fs/nfs/callback.c | 7 +-
> > fs/nfs/callback.h | 3 +-
> > fs/nfs/client.c | 45 ++++++-
> > fs/nfs/dns_resolve.c | 137 ++++++++++++++++-----
> > fs/nfs/dns_resolve.h | 15 +--
> > fs/nfs/inode.c | 9 +--
> > fs/nfs/internal.h | 10 ++-
> > fs/nfs/mount_clnt.c | 1 +
> > fs/nfs/namespace.c | 3 +-
> > fs/nfs/nfs4namespace.c | 20 ++--
> > fs/nfs/super.c | 20 +++
> > fs/nfsd/nfs4callback.c | 5 +
> > fs/nfsd/nfssvc.c | 20 +++-
> > include/linux/lockd/bind.h | 3 +-
> > include/linux/lockd/lockd.h | 4 +-
> > include/linux/nfs_fs_sb.h | 1 +
> > include/linux/sunrpc/cache.h | 9 +-
> > include/linux/sunrpc/clnt.h | 5 +-
> > include/linux/sunrpc/rpc_pipe_fs.h | 7 +-
> > include/linux/sunrpc/svc.h | 9 +-
> > net/sunrpc/cache.c | 16 ++-
> > net/sunrpc/clnt.c | 19 ++--
> > net/sunrpc/rpc_pipe.c | 235 ++++++++++++++++++++++++++++++++----
> > net/sunrpc/rpcb_clnt.c | 19 ++-
> > net/sunrpc/svc.c | 52 +++++---
> > 32 files changed, 549 insertions(+), 187 deletions(-)
> >
> > --
> > 1.7.3.4
> >
>
> --
> Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: panic in tg3 driver
From: Matt Carlson @ 2011-01-25 0:59 UTC (permalink / raw)
To: Stephen Clark
Cc: Matthew Carlson, Linux Kernel Network Developers, Michael Chan
In-Reply-To: <4D3334E6.40100@earthlink.net>
On Sun, Jan 16, 2011 at 10:11:50AM -0800, Stephen Clark wrote:
> On 01/13/2011 08:12 AM, Stephen Clark wrote:
> > On 01/11/2011 10:06 PM, Matt Carlson wrote:
> >> lspci -vvv -xxx -s 81:00.0
> >
> >
> >
> > Further information - I found these messages in /var/log/messages. It
> > looks
> > like after it switched to INTx mode interrupts for other devices were
> > hosed.
> >
> > Jan 12 08:37:49 localhost kernel: tg3 0000:81:00.0: eth2: No interrupt
> > was gener
> > ated using MSI. Switching to INTx mode. Please report this failure to
> > the PCI ma
> > intainer and include system chipset information
> > Jan 12 08:37:49 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is
> > not ready
> > Jan 12 08:38:50 localhost kernel: ata2: lost interrupt (Status 0x50)
> > Jan 12 08:38:50 localhost kernel: ata2.01: exception Emask 0x0 SAct
> > 0x0 SErr 0x0
> > action 0x6 frozen
> > Jan 12 08:38:50 localhost kernel: ata2.01: failed command: WRITE DMA
> > Jan 12 08:38:50 localhost kernel: ata2.01: cmd
> > ca/00:08:e0:bc:51/00:00:00:00:00/f0 tag 0 dma 4096 out
> > Jan 12 08:38:50 localhost kernel: res
> > 40/00:01:00:4f:c2/00:00:00:00:00/b0 Emask 0x4 (timeout)
> > Jan 12 08:38:50 localhost kernel: ata2.01: status: { DRDY }
> > Jan 12 08:38:50 localhost kernel: ata2: soft resetting link
> > Jan 12 08:38:50 localhost kernel: do_IRQ: 0.64 No irq handler for
> > vector (irq -1)
> > Jan 12 08:38:50 localhost kernel: ata2.01: configured for UDMA/33
> > Jan 12 08:38:54 localhost pppd[1983]: No response to 3 echo-requests
> > Jan 12 08:39:55 localhost pppoe[1988]: Inactivity timeout... something
> > wicked happened on session 3363
> Just checking to make sure you have everything you need?
Sorry for the delay Stephen.
It looks to me like interrupts aren't being setup correctly on this
system. I tested MSI and INTx interrupt modes locally and they both
work. I'm guessing one of two things could be happening:
1) The 2nd parameter of the low-level ISR (tg3_interrupt_tagged()) is
not correct. The ISR tries to tell the hardware the interrupt is
acknowledged, but the message goes unheard. (This might also explain
why other devices are also afflicted.)
2) Something is blocking the delivery of the interrupt to the tg3 driver
altogether.
In both cases, the hardware persistently nags the host to ack the
interrupt, hence the interrupt storm.
^ permalink raw reply
* Re: [PATCH] GRO: fix merging a paged skb after non-paged skbs
From: Ben Hutchings @ 2011-01-25 1:24 UTC (permalink / raw)
To: Michal Schmidt; +Cc: David Miller, netdev, Herbert Xu, linux-net-drivers
In-Reply-To: <20110124184752.1d0947dd@delilah>
On Mon, 2011-01-24 at 18:47 +0100, Michal Schmidt wrote:
> Suppose that several linear skbs of the same flow were received by GRO. They
> were thus merged into one skb with a frag_list. Then a new skb of the same flow
> arrives, but it is a paged skb with data starting in its frags[].
>
> Before adding the skb to the frag_list skb_gro_receive() will of course adjust
> the skb to throw away the headers. It correctly modifies the page_offset and
> size of the frag, but it leaves incorrect information in the skb:
> ->data_len is not decreased at all.
> ->len is decreased only by headlen, as if no change were done to the frag.
> Later in a receiving process this causes skb_copy_datagram_iovec() to return
> -EFAULT and this is seen in userspace as the result of the recv() syscall.
>
> In practice the bug can be reproduced with the sfc driver. By default the
> driver uses an adaptive scheme when it switches between using
> napi_gro_receive() (with skbs) and napi_gro_frags() (with pages). The bug is
> reproduced when under rx load with enough successful GRO merging the driver
> decides to switch from the former to the latter.
[...]
This is odd because I thought we made sure to flush before making such a
change. Perhaps that got lost during the conversion from inet_lro to
GRO?
Anyway, thanks very much for fixing this.
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: [PATCH v2 04/16] net: Introduce new feature setting ops
From: Ben Hutchings @ 2011-01-25 1:26 UTC (permalink / raw)
To: David Miller; +Cc: mirq-linux, netdev
In-Reply-To: <20110124.155144.35028895.davem@davemloft.net>
On Mon, 2011-01-24 at 15:51 -0800, David Miller wrote:
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Date: Sat, 22 Jan 2011 23:14:13 +0100 (CET)
>
> > This introduces a new framework to handle device features setting.
> > It consists of:
> > - new fields in struct net_device:
> > + hw_features - features that hw/driver supports toggling
> > + wanted_features - features that user wants enabled, when possible
> > - new netdev_ops:
> > + feat = ndo_fix_features(dev, feat) - API checking constraints for
> > enabling features or their combinations
> > + ndo_set_features(dev) - API updating hardware state to match
> > changed dev->features
> > - new ethtool commands:
> > + ETHTOOL_GFEATURES/ETHTOOL_SFEATURES: get/set dev->wanted_features
> > and trigger device reconfiguration if resulting dev->features
> > changed
> > + ETHTOOL_GSTRINGS(ETH_SS_FEATURES): get feature bits names (meaning)
> >
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> Ok, I'll stop applying patches right before this one as I'd like to see
> at least some feedback from Ben wrt. the ethtool bits.
>
> FWIW I like these changes (a lot). :-)
These are on my list to review. I'm at LCA now (and not on work time)
but I'll try to get through them in the next day or two.
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: [PATCH v3 00/16] make rpc_pipefs be mountable multiple time
From: Rob Landley @ 2011-01-25 1:53 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Trond Myklebust, J. Bruce Fields, Neil Brown, Pavel Emelyanov,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Al Viro,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110124235545.GA793-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
On 01/24/2011 05:55 PM, Kirill A. Shutemov wrote:
> On Fri, Jan 14, 2011 at 03:48:58PM +0200, Kirill A. Shutemov wrote:
>> Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
>> Only for client for now.
>>
>> It's step forwart to get nfs work from container.
>
> Any feedback?
I didn't see anything to object to, and I'll give a:
Reviewed-by: Rob Landley <rlandley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To the one that you rewrote for me (um, 12/16). I still don't
understand at the design level why init_rpc_pipefs exists if containers
don't need it, but it seems to be implementing what it sets out to do.
But it doesn't apply to my test environment (nfsv3 unauthenticated), and
I'm still trying to finish up that before switching gears to look at v4.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 18/79] IPVS: Remove useless { } block from ip_vs_process_message()
From: Simon Horman @ 2011-01-25 2:10 UTC (permalink / raw)
To: Joe Perches; +Cc: kaber, davem, netfilter-devel, netdev
In-Reply-To: <1295466052.1952.29.camel@Joe-Laptop>
On Wed, Jan 19, 2011 at 11:40:52AM -0800, Joe Perches wrote:
> On Wed, 2011-01-19 at 20:14 +0100, kaber@trash.net wrote:
> > From: Simon Horman <horms@verge.net.au>
> > net/netfilter/ipvs/ip_vs_sync.c | 24 +++++++++++-------------
> > diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
> > @@ -381,20 +381,18 @@ static void ip_vs_process_message(const char *buffer, const size_t buflen)
> > }
> > }
> >
> > - {
> > - if (ip_vs_conn_fill_param_sync(AF_INET, s->protocol,
> > - (union nf_inet_addr *)&s->caddr,
> > - s->cport,
> > - (union nf_inet_addr *)&s->vaddr,
> > - s->vport, ¶m)) {
> > - pr_err("ip_vs_conn_fill_param_sync failed");
> > - return;
> > - }
> > - if (!(flags & IP_VS_CONN_F_TEMPLATE))
> > - cp = ip_vs_conn_in_get(¶m);
> > - else
> > - cp = ip_vs_ct_in_get(¶m);
> > + if (ip_vs_conn_fill_param_sync(AF_INET, s->protocol,
> > + (union nf_inet_addr *)&s->caddr,
> > + s->cport,
> > + (union nf_inet_addr *)&s->vaddr,
> > + s->vport, ¶m)) {
> > + pr_err("ip_vs_conn_fill_param_sync failed");
>
> The original and this pr_err is missing a \n before close quote.
Thanks Joe, I'll get this fixed once nf-next-2.6 opens up again.
^ permalink raw reply
* Re: does intel X520-SR(ixgbe) support RSS on single VLAN?
From: Rui @ 2011-01-25 2:10 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net
In-Reply-To: <4D3DB248.5070802@intel.com>
On Tue, Jan 25, 2011 at 1:09 AM, Alexander Duyck
<alexander.h.duyck@intel.com> wrote:
> On 1/24/2011 6:18 AM, Rui wrote:
>>
>> hi
>> does intel X520-SR support RSS on single VLAN?
>>
>> tested with 3 different vlan id and priority packets
>> What I saw is that all packets were always delivered to the same RxQ.
>> looks can not get a different RSS index for these packet?
>> any setting needed?
>> --
>> 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
>
> The X520 should have no problems hashing on a single VLAN tagged frame.
> However the VLAN will not be a part of the RSS hash. The only components
> of the hash are the IPv4/IPv6 source and destination addresses, and if the
> flow is TCP then the port numbers.
>
hi alexander
I got these information from the intel community:
'I asked our software engineers about your question, and this is what I learned.
You cannot filter by just VLAN or VLAN priority. The L4 type will
also play a role in the filter and as such you would only be able to
filter TCP, UDP, and SCTP packets that are bound for a VLAN.
The command itself to setup a filter is “ethtool –U ethX flow-type
tcp4 vlan 0x2000 vlan-mask 0xE000 action Y” where X is the correct
index for the interface and Y is the queue you want to route the
traffic to. This would have to be repeated for udp4 and sctp4.
I hope this will help.
Mark H"
so my question is that the VLAN is PART of the RSS or not? looks the
perfect filter support vlan id ?can the perfect filter support
wildchar,such as: flow-type ANY?
thanks
> I would recommend testing with something like the "netperf -t TCP_CRR" test
> which should open a number of ports and spread traffic out between multiple
> queues.
>
> Thanks,
>
> Alex
>
^ permalink raw reply
* Re: [PATCH 1/1] IPVS netns BUG, register sysctl for root ns
From: Simon Horman @ 2011-01-25 2:15 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: ja, wensong, lvs-devel, netdev, netfilter-devel, hans
In-Reply-To: <1295878481-13623-1-git-send-email-hans.schillstrom@ericsson.com>
On Mon, Jan 24, 2011 at 03:14:41PM +0100, Hans Schillstrom wrote:
> The newly created table was not used when register sysctl for a new namespace.
> I.e. sysctl doesn't work for other than root namespace (init_net)
>
> Signed-off-by: Hans Schillstrom <hans.schillstrom@ericsson.com>
Thanks Hans.
Patrick, please pull this change from
git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git for-patrick
^ permalink raw reply
* Re: panic in tg3 driver
From: Matt Carlson @ 2011-01-25 2:25 UTC (permalink / raw)
To: Matt Carlson; +Cc: Stephen Clark, Linux Kernel Network Developers, Michael Chan
In-Reply-To: <20110125005922.GA19701@mcarlson.broadcom.com>
On Mon, Jan 24, 2011 at 04:59:22PM -0800, Matt Carlson wrote:
> On Sun, Jan 16, 2011 at 10:11:50AM -0800, Stephen Clark wrote:
> > On 01/13/2011 08:12 AM, Stephen Clark wrote:
> > > On 01/11/2011 10:06 PM, Matt Carlson wrote:
> > >> lspci -vvv -xxx -s 81:00.0
> > >
> > >
> > >
> > > Further information - I found these messages in /var/log/messages. It
> > > looks
> > > like after it switched to INTx mode interrupts for other devices were
> > > hosed.
> > >
> > > Jan 12 08:37:49 localhost kernel: tg3 0000:81:00.0: eth2: No interrupt
> > > was gener
> > > ated using MSI. Switching to INTx mode. Please report this failure to
> > > the PCI ma
> > > intainer and include system chipset information
> > > Jan 12 08:37:49 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is
> > > not ready
> > > Jan 12 08:38:50 localhost kernel: ata2: lost interrupt (Status 0x50)
> > > Jan 12 08:38:50 localhost kernel: ata2.01: exception Emask 0x0 SAct
> > > 0x0 SErr 0x0
> > > action 0x6 frozen
> > > Jan 12 08:38:50 localhost kernel: ata2.01: failed command: WRITE DMA
> > > Jan 12 08:38:50 localhost kernel: ata2.01: cmd
> > > ca/00:08:e0:bc:51/00:00:00:00:00/f0 tag 0 dma 4096 out
> > > Jan 12 08:38:50 localhost kernel: res
> > > 40/00:01:00:4f:c2/00:00:00:00:00/b0 Emask 0x4 (timeout)
> > > Jan 12 08:38:50 localhost kernel: ata2.01: status: { DRDY }
> > > Jan 12 08:38:50 localhost kernel: ata2: soft resetting link
> > > Jan 12 08:38:50 localhost kernel: do_IRQ: 0.64 No irq handler for
> > > vector (irq -1)
> > > Jan 12 08:38:50 localhost kernel: ata2.01: configured for UDMA/33
> > > Jan 12 08:38:54 localhost pppd[1983]: No response to 3 echo-requests
> > > Jan 12 08:39:55 localhost pppoe[1988]: Inactivity timeout... something
> > > wicked happened on session 3363
> > Just checking to make sure you have everything you need?
>
> Sorry for the delay Stephen.
>
> It looks to me like interrupts aren't being setup correctly on this
> system. I tested MSI and INTx interrupt modes locally and they both
> work. I'm guessing one of two things could be happening:
>
> 1) The 2nd parameter of the low-level ISR (tg3_interrupt_tagged()) is
> not correct. The ISR tries to tell the hardware the interrupt is
> acknowledged, but the message goes unheard. (This might also explain
> why other devices are also afflicted.)
>
> 2) Something is blocking the delivery of the interrupt to the tg3 driver
> altogether.
>
> In both cases, the hardware persistently nags the host to ack the
> interrupt, hence the interrupt storm.
Just curious, is the problem still there if you add pci=nomsi to the
kernel command line?
^ permalink raw reply
* Re: [PATCH v5] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-25 2:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, bhutchings, joe, dilinger, mirqus,
Po-Yu Chuang
In-Reply-To: <1295881662.2755.34.camel@edumazet-laptop>
Dear Eric,
On Mon, Jan 24, 2011 at 11:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 24 janvier 2011 à 20:39 +0800, Po-Yu Chuang a écrit :
>> From: Po-Yu Chuang <ratbert@faraday-tech.com>
>> +
>> + priv->tx_pending++;
>> + if (priv->tx_pending == TX_QUEUE_ENTRIES) {
>> + if (net_ratelimit())
>> + netdev_info(netdev, "tx queue full\n");
>
> Hmm, I guess you didnt tested your driver with a pktgen flood ;)
>
> This 'netdev_info(netdev, "tx queue full\n");' is not necessary, since
> its a pretty normal condition for a driver (to fill its TX ring buffer)
Errr... No, I didn't test it with pktgen. I tested it with normal NFS usages.
I'll try it.
best regards,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH v4] net: add Faraday FTMAC100 10/100 Ethernet driver
From: Po-Yu Chuang @ 2011-01-25 2:46 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev, linux-kernel, bhutchings, eric.dumazet, joe, dilinger,
Po-Yu Chuang
In-Reply-To: <AANLkTimWuBfeYPOsOFpTiAGS5uHysevAHiOg0svBQ4zW@mail.gmail.com>
Dear Michał,
2011/1/25 Michał Mirosław <mirqus@gmail.com>:
> W dniu 24 stycznia 2011 09:26 użytkownik Po-Yu Chuang
> <ratbert.chuang@gmail.com> napisał:
>> 2011/1/21 Michał Mirosław <mirqus@gmail.com>:
>>> Did you test this? This looks like it will result in double free after
>>> packet RX, as you are giving the same page (referenced once) to two
>>> distinct RX descriptors, that may be assigned different packets.
>>
>> Yes, this is tested.
>>
>>> Since your not implementing any RX offloads, you might just allocate
>>> fresh skb's with alloc_skb() and store skb pointer in rxdes3. Since
>>
>> rxdes3 does not store virtual address of an skb.
>> It stores the address of the buffer allocated while open() and freed
>> only when stop().
>> The data in that buffer will be memcpy()ed to an skb allocated in
>> ftmac100_rx_packet().
>> No double free happens.
>
> Ah, I blindly assumed that you're just appending the buffers to the
> skb (using skb_fill_page_desc() and friends). Since you have to mark
> descriptors for the device anyway, it might be faster to allocate new
> skbs and map those as rx buffers (changing the descriptor's buffer
> address after every RX) instead of keeping static buffer and copying
> every time. (For small packets it wastes lot of memory, though - so
> the right choice depends on the expected workload.)
The reason I chose to use memcpy rx buffer to skb is that I didn't know
how to deal with multi-segment packets if I preallocated skb for each
rx descriptor. This function seems to be what I need.
Let me rework this. Thanks.
best regards,
Po-Yu Chuang
^ permalink raw reply
* Re: does intel X520-SR(ixgbe) support RSS on single VLAN?
From: Ben Hutchings @ 2011-01-25 3:05 UTC (permalink / raw)
To: Rui
Cc: Alexander Duyck, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <AANLkTimFuUp+wbgJY4koZ96st1eBbFqVOxOPj4tU_-Ao@mail.gmail.com>
On Tue, 2011-01-25 at 10:10 +0800, Rui wrote:
> On Tue, Jan 25, 2011 at 1:09 AM, Alexander Duyck
> <alexander.h.duyck@intel.com> wrote:
> > On 1/24/2011 6:18 AM, Rui wrote:
> >>
> >> hi
> >> does intel X520-SR support RSS on single VLAN?
> >>
> >> tested with 3 different vlan id and priority packets
> >> What I saw is that all packets were always delivered to the same RxQ.
> >> looks can not get a different RSS index for these packet?
> >> any setting needed?
> >> --
> >> 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
> >
> > The X520 should have no problems hashing on a single VLAN tagged frame.
> > However the VLAN will not be a part of the RSS hash. The only components
> > of the hash are the IPv4/IPv6 source and destination addresses, and if the
> > flow is TCP then the port numbers.
> >
> hi alexander
> I got these information from the intel community:
>
> 'I asked our software engineers about your question, and this is what I learned.
> You cannot filter by just VLAN or VLAN priority. The L4 type will
> also play a role in the filter and as such you would only be able to
> filter TCP, UDP, and SCTP packets that are bound for a VLAN.
> The command itself to setup a filter is “ethtool –U ethX flow-type
> tcp4 vlan 0x2000 vlan-mask 0xE000 action Y” where X is the correct
> index for the interface and Y is the queue you want to route the
> traffic to. This would have to be repeated for udp4 and sctp4.
> I hope this will help.
> Mark H"
The mask specifies bits to be ignored, so if you want to filter on the
basis of only the priority bits you should use vlan-mask 0xfff. Unless
this is another inconsistency I failed to notice...
> so my question is that the VLAN is PART of the RSS or not?
It's not part of any specified Toeplitz hash. However, some hardware
supports adding the hash (after indirection) to the queue number
specified by a filter. Currently the ethtool API doesn't have a way to
request that.
> looks the
> perfect filter support vlan id ?can the perfect filter support
> wildchar,such as: flow-type ANY?
It is possible to specify this using flow-type ether, but the ixgbe
driver does not yet support that (and I have no idea whether the
hardware does).
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
* [PATCH] net: remove tests on 64bit platforms
From: Changli Gao @ 2011-01-25 4:21 UTC (permalink / raw)
To: David S. Miller
Cc: Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, Changli Gao
On 64bit platforms, >31 bit shifting of a unsigned long variable is
valid, so we can remove the related boundary tests, which may slow
down the CPU if branch prediction fails.
The size of text becomes smaller:
before:
text data bss dec hex filename
15721 16 16 15753 3d89 net/ipv4/fib_trie.o
after:
text data bss dec hex filename
15656 16 16 15688 3d48 net/ipv4/fib_trie.o
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/ipv4/fib_trie.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 0f28034..95c8bb3 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -219,15 +219,23 @@ static inline int tnode_child_length(const struct tnode *tn)
static inline t_key mask_pfx(t_key k, unsigned short l)
{
+#if BITS_PER_LONG > 32
+ return ((u64)k) >> (KEYLENGTH-l) << (KEYLENGTH-l);
+#else
return (l == 0) ? 0 : k >> (KEYLENGTH-l) << (KEYLENGTH-l);
+#endif
}
static inline t_key tkey_extract_bits(t_key a, int offset, int bits)
{
+#if BITS_PER_LONG > 32
+ return (t_key)((u64)a << offset) >> (KEYLENGTH - bits);
+#else
if (offset < KEYLENGTH)
return ((t_key)(a << offset)) >> (KEYLENGTH - bits);
else
return 0;
+#endif
}
static inline int tkey_equals(t_key a, t_key b)
^ permalink raw reply related
* Re: [PATCH] net: remove tests on 64bit platforms
From: Ben Hutchings @ 2011-01-25 4:28 UTC (permalink / raw)
To: Changli Gao
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1295929298-13163-1-git-send-email-xiaosuo@gmail.com>
On Tue, 2011-01-25 at 12:21 +0800, Changli Gao wrote:
> On 64bit platforms, >31 bit shifting of a unsigned long variable is
> valid, so we can remove the related boundary tests, which may slow
> down the CPU if branch prediction fails.
[...]
It seems like it would be better to define generic shift functions that
correctly handle the case of a shift count >= word size. There are many
places these would be useful.
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: [PATCH net-next-2.6 v5 1/1] can: c_can: Added support for Bosch C_CAN controller
From: Bhupesh SHARMA @ 2011-01-25 4:36 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Marc Kleine-Budde,
David Miller
In-Reply-To: <4D3B2F66.8090603-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Hi Wolfgang,
Thanks for your review.
Please see my comments inline:
> Hi Bhupesh,
>
> at a closer look, I realized one more issue, apart from some minor
> ones...
>
> On 01/20/2011 10:20 AM, Bhupesh Sharma wrote:
> > Bosch C_CAN controller is a full-CAN implementation which is
> compliant
> > to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can
> be
> > obtained from:
> > http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/
> > c_can/users_manual_c_can.pdf
> >
> > This patch adds the support for this controller.
> > The following are the design choices made while writing the
> controller
> > driver:
> > 1. Interface Register set IF1 has be used only in the current design.
> > 2. Out of the 32 Message objects available, 16 are kept aside for RX
> > purposes and the rest for TX purposes.
> > 3. NAPI implementation is such that both the TX and RX paths function
> > in polling mode.
> >
> > Signed-off-by: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
> > ---
> > Changes since V4:
> > 1. Insured correct ISR implementation to allow shared IRQs.
> > 2. To ensure better understanding of message object numbers
> > and thierusage modified C_CAN_MSG_OBJ_RX_FIRST value from 0
>
> Typo!
Ok :)
> > to 1.
> > 3. Corrected coding style globally.
> > 4. Renamed Interface registers as *ifregs*.
> >
> > drivers/net/can/Kconfig | 2 +
> > drivers/net/can/Makefile | 1 +
> > drivers/net/can/c_can/Kconfig | 15 +
> > drivers/net/can/c_can/Makefile | 8 +
> > drivers/net/can/c_can/c_can.c | 958
> ++++++++++++++++++++++++++++++++
> > drivers/net/can/c_can/c_can.h | 229 ++++++++
> > drivers/net/can/c_can/c_can_platform.c | 207 +++++++
> > 7 files changed, 1420 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/net/can/c_can/Kconfig
> > create mode 100644 drivers/net/can/c_can/Makefile
> > create mode 100644 drivers/net/can/c_can/c_can.c
> > create mode 100644 drivers/net/can/c_can/c_can.h
> > create mode 100644 drivers/net/can/c_can/c_can_platform.c
> >
> > diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
> > index 9d9e453..50549b5 100644
> > --- a/drivers/net/can/Kconfig
> > +++ b/drivers/net/can/Kconfig
> > @@ -86,6 +86,8 @@ source "drivers/net/can/mscan/Kconfig"
> >
> > source "drivers/net/can/sja1000/Kconfig"
> >
> > +source "drivers/net/can/c_can/Kconfig"
> > +
> > source "drivers/net/can/usb/Kconfig"
> >
> > config CAN_DEBUG_DEVICES
> > diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
> > index 0057537..c3efeb3 100644
> > --- a/drivers/net/can/Makefile
> > +++ b/drivers/net/can/Makefile
> > @@ -11,6 +11,7 @@ obj-y += usb/
> >
> > obj-$(CONFIG_CAN_SJA1000) += sja1000/
> > obj-$(CONFIG_CAN_MSCAN) += mscan/
> > +obj-$(CONFIG_CAN_C_CAN) += c_can/
> > obj-$(CONFIG_CAN_AT91) += at91_can.o
> > obj-$(CONFIG_CAN_TI_HECC) += ti_hecc.o
> > obj-$(CONFIG_CAN_MCP251X) += mcp251x.o
> > diff --git a/drivers/net/can/c_can/Kconfig
> b/drivers/net/can/c_can/Kconfig
> > new file mode 100644
> > index 0000000..ffb9773
> > --- /dev/null
> > +++ b/drivers/net/can/c_can/Kconfig
> > @@ -0,0 +1,15 @@
> > +menuconfig CAN_C_CAN
> > + tristate "Bosch C_CAN devices"
> > + depends on CAN_DEV && HAS_IOMEM
> > +
> > +if CAN_C_CAN
> > +
> > +config CAN_C_CAN_PLATFORM
> > + tristate "Generic Platform Bus based C_CAN driver"
> > + ---help---
> > + This driver adds support for the C_CAN chips connected to
> > + the "platform bus" (Linux abstraction for directly to the
> > + processor attached devices) which can be found on various
> > + boards from ST Microelectronics (http://www.st.com)
> > + like the SPEAr1310 and SPEAr320 evaluation boards.
> > +endif
> > diff --git a/drivers/net/can/c_can/Makefile
> b/drivers/net/can/c_can/Makefile
> > new file mode 100644
> > index 0000000..9273f6d
> > --- /dev/null
> > +++ b/drivers/net/can/c_can/Makefile
> > @@ -0,0 +1,8 @@
> > +#
> > +# Makefile for the Bosch C_CAN controller drivers.
> > +#
> > +
> > +obj-$(CONFIG_CAN_C_CAN) += c_can.o
> > +obj-$(CONFIG_CAN_C_CAN_PLATFORM) += c_can_platform.o
> > +
> > +ccflags-$(CONFIG_CAN_DEBUG_DEVICES) := -DDEBUG
> > diff --git a/drivers/net/can/c_can/c_can.c
> b/drivers/net/can/c_can/c_can.c
> > new file mode 100644
> > index 0000000..66a400b
> > --- /dev/null
> > +++ b/drivers/net/can/c_can/c_can.c
>
> ...
>
> > +static void c_can_handle_lost_msg_obj(struct net_device *dev,
> > + int iface, int objno)
> > +{
> > + struct c_can_priv *priv = netdev_priv(dev);
> > + struct net_device_stats *stats = &dev->stats;
> > + struct sk_buff *skb;
> > + struct can_frame *frame;
> > +
> > + netdev_err(dev, "msg lost in buffer %d\n", objno);
> > +
> > + c_can_object_get(dev, iface, objno, IF_COMM_ALL &
> > + ~IF_COMM_TXRQST);
>
> Does fit on one line.
OK.
> ...
>
> > +static void c_can_inval_msg_object(struct net_device *dev, int
> iface, int objno)
> > +{
> > + struct c_can_priv *priv = netdev_priv(dev);
> > +
> > + priv->write_reg(priv, &priv->regs->ifregs[iface].arb1, 0);
> > + priv->write_reg(priv, &priv->regs->ifregs[iface].arb2, 0);
> > + priv->write_reg(priv, &priv->regs->ifregs[iface].msg_cntrl, 0);
> > +
> > + c_can_object_put(dev, iface, objno,
> > + IF_COMM_ARB | IF_COMM_CONTROL);
>
> Ditto
Ok.
> ...
>
> > +static inline int c_can_has_and_handle_berr(struct c_can_priv *priv)
> > +{
> > + return (priv->can.ctrlmode & CAN_CTRLMODE_BERR_REPORTING) &&
> > + (priv->current_status & STATUS_LEC_MASK);
> > +}
> > +
> > +static int c_can_err(struct net_device *dev,
> > + enum c_can_bus_error_types error_type,
> > + enum c_can_lec_type lec_type)
> > +{
> > + unsigned int reg_err_counter;
> > + unsigned int rx_err_passive;
> > + struct c_can_priv *priv = netdev_priv(dev);
> > + struct net_device_stats *stats = &dev->stats;
> > + struct can_frame *cf;
> > + struct sk_buff *skb;
> > + struct can_berr_counter bec;
> > +
> > + /* propogate the error condition to the CAN stack */
> > + skb = alloc_can_err_skb(dev, &cf);
> > + if (unlikely(!skb))
> > + return 0;
> > +
> > + c_can_get_berr_counter(dev, &bec);
> > + reg_err_counter = priv->read_reg(priv, &priv->regs->err_cnt);
> > + rx_err_passive = (reg_err_counter & ERR_CNT_RP_MASK) >>
> > + ERR_CNT_RP_SHIFT;
> > +
> > + if (error_type & C_CAN_ERROR_WARNING) {
> > + /* error warning state */
> > + priv->can.can_stats.error_warning++;
> > + priv->can.state = CAN_STATE_ERROR_WARNING;
> > + cf->can_id |= CAN_ERR_CRTL;
> > + if (bec.rxerr > 96)
> > + cf->data[1] |= CAN_ERR_CRTL_RX_WARNING;
> > + if (bec.txerr > 96)
> > + cf->data[1] |= CAN_ERR_CRTL_TX_WARNING;
> > + }
> > + if (error_type & C_CAN_ERROR_PASSIVE) {
> > + /* error passive state */
> > + priv->can.can_stats.error_passive++;
> > + priv->can.state = CAN_STATE_ERROR_PASSIVE;
> > + cf->can_id |= CAN_ERR_CRTL;
> > + if (rx_err_passive)
> > + cf->data[1] |= CAN_ERR_CRTL_RX_PASSIVE;
> > + if (bec.txerr > 127)
> > + cf->data[1] |= CAN_ERR_CRTL_TX_PASSIVE;
> > + }
> > + if (error_type & C_CAN_BUS_OFF) {
> > + /* bus-off state */
> > + priv->can.state = CAN_STATE_BUS_OFF;
> > + cf->can_id |= CAN_ERR_BUSOFF;
> > + /*
> > + * disable all interrupts in bus-off mode to ensure that
> > + * the CPU is not hogged down
> > + */
> > + c_can_enable_all_interrupts(priv, DISABLE_ALL_INTERRUPTS);
> > + can_bus_off(dev);
> > + }
> > +
> > + /*
> > + * check for 'last error code' which tells us the
> > + * type of the last error to occur on the CAN bus
> > + */
> > +
> > + /* common for all type of bus errors */
> > + priv->can.can_stats.bus_error++;
>
> Does a state change always come together with a bus error?
>
> > + stats->rx_errors++;
> > + cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
> > + cf->data[2] |= CAN_ERR_PROT_UNSPEC;
> > +
> > + switch (lec_type) {
> > + case LEC_STUFF_ERROR:
> > + netdev_dbg(dev, "stuff error\n");
> > + cf->data[2] |= CAN_ERR_PROT_STUFF;
> > + break;
> > +
> > + case LEC_FORM_ERROR:
> > + netdev_dbg(dev, "form error\n");
> > + cf->data[2] |= CAN_ERR_PROT_FORM;
> > + break;
> > +
> > + case LEC_ACK_ERROR:
> > + netdev_dbg(dev, "ack error\n");
> > + cf->data[2] |= (CAN_ERR_PROT_LOC_ACK |
> > + CAN_ERR_PROT_LOC_ACK_DEL);
> > + break;
> > +
> > + case LEC_BIT1_ERROR:
> > + netdev_dbg(dev, "bit1 error\n");
> > + cf->data[2] |= CAN_ERR_PROT_BIT1;
> > + break;
> > +
> > + case LEC_BIT0_ERROR:
> > + netdev_dbg(dev, "bit0 error\n");
> > + cf->data[2] |= CAN_ERR_PROT_BIT0;
> > + break;
> > +
> > + case LEC_CRC_ERROR:
> > + netdev_dbg(dev, "CRC error\n");
> > + cf->data[2] |= (CAN_ERR_PROT_LOC_CRC_SEQ |
> > + CAN_ERR_PROT_LOC_CRC_DEL);
> > + break;
> > + }
>
> From the C_CAN manual:
>
> "The LEC field holds a code which indicates the type of the last error
> to occur on the CAN bus. This field will be cleared to '0' when a
> message has been transferred (reception or transmission) without error.
> The unused code '7' may be written by the CPU to check for updates."
>
> Not sure if it's necessary to reset the lec at init and after an error
> to 0x7 and check it. More below...
Hmm.. The default value of Status Register is 0x0 at INIT so I am not
sure if LEC needs to be reset at init. However using the unused code
0x7 seems necessary to check for updates as per specs.
I will modify the same in V6.
> > + netif_receive_skb(skb);
> > + stats->rx_packets++;
> > + stats->rx_bytes += cf->can_dlc;
> > +
> > + return 1;
> > +}
> > +
> > +static int c_can_poll(struct napi_struct *napi, int quota)
> > +{
> > + u16 irqstatus;
> > + int lec_type = 0;
> > + int work_done = 0;
> > + struct net_device *dev = napi->dev;
> > + struct c_can_priv *priv = netdev_priv(dev);
> > + enum c_can_bus_error_types error_type = C_CAN_NO_ERROR;
> > +
> > + irqstatus = priv->read_reg(priv, &priv->regs->interrupt);
> > + if (!irqstatus)
> > + goto end;
> > +
> > + /* status events have the highest priority */
> > + if (irqstatus == STATUS_INTERRUPT) {
> > + priv->current_status = priv->read_reg(priv,
> > + &priv->regs->status);
> > +
> > + /* handle Tx/Rx events */
> > + if (priv->current_status & STATUS_TXOK)
> > + priv->write_reg(priv, &priv->regs->status,
> > + priv->current_status & ~STATUS_TXOK);
> > +
> > + if (priv->current_status & STATUS_RXOK)
> > + priv->write_reg(priv, &priv->regs->status,
> > + priv->current_status & ~STATUS_RXOK);
> > +
> > + /* handle bus error events */
> > + if (priv->current_status & STATUS_EWARN) {
> > + netdev_dbg(dev,
> > + "entered error warning state\n");
>
> Does fit on one line.
OK.
> > + error_type = C_CAN_ERROR_WARNING;
> > + }
> > + if ((priv->current_status & STATUS_EPASS) &&
> > + (!(priv->last_status & STATUS_EPASS))) {
> > + netdev_dbg(dev,
> > + "entered error passive state\n");
>
> Ditto.
OK.
> > + error_type = C_CAN_ERROR_PASSIVE;
> > + }
> > + if ((priv->current_status & STATUS_BOFF) &&
> > + (!(priv->last_status & STATUS_BOFF))) {
> > + netdev_dbg(dev,
> > + "entered bus off state\n");
>
> Ditto.
OK.
> > + error_type = C_CAN_BUS_OFF;
> > + }
> > +
> > + /* handle bus recovery events */
> > + if ((!(priv->current_status & STATUS_EPASS)) &&
> > + (priv->last_status & STATUS_EPASS)) {
> > + netdev_dbg(dev,
> > + "left error passive state\n");
>
> Ditto.
OK.
> > + priv->can.state = CAN_STATE_ERROR_ACTIVE;
> > + }
> > + if ((!(priv->current_status & STATUS_BOFF)) &&
> > + (priv->last_status & STATUS_BOFF)) {
> > + netdev_dbg(dev,
> > + "left bus off state\n");
> > + priv->can.state = CAN_STATE_ERROR_ACTIVE;
> > + }
> > +
> > + priv->last_status = priv->current_status;
> > +
> > + /* handle error on the bus */
> > + lec_type = c_can_has_and_handle_berr(priv);
> > + if (lec_type && (error_type != C_CAN_NO_ERROR))
> > + work_done += c_can_err(dev, error_type, lec_type);
>
> State changes are only reported if berr_reporting is enabled and a bus
> error occured. This needs to be fixed.
As I mentioned earlier in a response to a review comment, the Bus Error
reporting for C_CAN seems different from sja1000 and flexcan approaches.
Do you think it will be useful to drop CAN_CTRLMODE_BERR_REPORTING from
priv->can.ctrlmode_supported as done by *pch* driver? Or do you have
a better idea..
> Feel free to send the output of "candump any,0:0,#FFFFFFFF" when
> sending
> messages without cable connected and with a bus error provocuted.
OK. I will try to cross-compile candump for my arm-v7 architecture
and will send the output.
> Apart form that the patch looks really good.
:)
> Wolfgang.
Regards,
Bhupesh
^ permalink raw reply
* [PATCH] netfilter: ipvs: fix compiler warnings
From: Changli Gao @ 2011-01-25 4:40 UTC (permalink / raw)
To: Simon Horman
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
netdev, lvs-devel, netfilter-devel, Changli Gao
Fix compiler warnings when IP_VS_DBG() isn't defined.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/netfilter/ipvs/ip_vs_core.c | 4 +---
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index f36a84f..d889f4f 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1894,9 +1894,7 @@ static int __net_init __ip_vs_init(struct net *net)
static void __net_exit __ip_vs_cleanup(struct net *net)
{
- struct netns_ipvs *ipvs = net_ipvs(net);
^ permalink raw reply related
* Re: [PATCH] net: add sysfs entry for device group
From: Stephen Hemminger @ 2011-01-25 4:41 UTC (permalink / raw)
To: Vlad Dogaru; +Cc: netdev
In-Reply-To: <1295876249-15634-1-git-send-email-ddvlad@rosedu.org>
On Mon, 24 Jan 2011 15:37:29 +0200
Vlad Dogaru <ddvlad@rosedu.org> wrote:
> The group of a network device can be queried or changed from userspace
> using sysfs.
>
> For example, considering sysfs mounted in /sys, one can change the group
> that interface lo belongs to:
> echo 1 > /sys/class/net/lo/group
>
> Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Re: [PATCH] netfilter: ipvs: fix compiler warnings
From: Simon Horman @ 2011-01-25 5:05 UTC (permalink / raw)
To: Changli Gao
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy, David S. Miller,
netdev, lvs-devel, netfilter-devel
In-Reply-To: <1295930418-14980-1-git-send-email-xiaosuo@gmail.com>
On Tue, Jan 25, 2011 at 12:40:18PM +0800, Changli Gao wrote:
> Fix compiler warnings when IP_VS_DBG() isn't defined.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Thanks, I will queue this up for when nf-next-2.6 is open again.
^ 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