* Re: [PATCH net-next-2.6 1/2] be2net: cleanup and refactor stats code
From: David Miller @ 2011-08-01 8:54 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1311657015-23465-2-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Tue, 26 Jul 2011 10:40:14 +0530
> In preparation for 64-bit stats interface, the following cleanups help
> streamline the code:
> 1) made some more rx/tx stats stored by driver 64 bit
> 2) made some HW stas (err/drop counters) stored in be_drv_stats 32 bit to
> keep the code simple as BE provides 32-bit counters only.
> 3) removed duplication of netdev stats in ethtool
> 4) removed some un-necessary stats and fixed some names
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] be2net: use stats-sync to read/write 64-bit stats
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1311657015-23465-3-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Tue, 26 Jul 2011 10:40:15 +0530
> 64-bit stats in be2net are written/read as follows using the stats-sync
> interface for safe access in 32-bit archs:
>
> 64-bit sync writer reader
> stats
> ------------------------------------------------------------------------------
> tx_stats tx_stats->sync be_xmit be_get_stats64,
> ethtool
> tx-compl tx_stats->sync_compl tx-compl-processing ethtool
> rx-stats rx_stats->sync rx-compl-processing be_get_stats64,
> ethtool,
> eqd-update
>
> This patch is based on Stephen Hemminger's earlier patch on the same issue...
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: some RCU conversions
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311837183.2697.37.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 09:13:03 +0200
> ICMP and ND are not fast path, but still we can avoid changing idev
> refcount, using RCU.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: use RCU in inet6_csk_xmit()
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311860627.2346.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 15:43:47 +0200
> Use RCU to avoid changing dst_entry refcount in fast path.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: avoid a dst_entry refcount change in ipv6_destopt_rcv()
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311861635.2346.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 16:00:35 +0200
> ipv6_destopt_rcv() runs with rcu_read_lock(), so there is no need to
> take a temporay reference on dst_entry, even if skb is freed by
> ip6_parse_tlv()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ip6tnl: avoid touching dst refcount in ip6_tnl_xmit2()
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311863545.2346.21.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 16:32:25 +0200
> Even using percpu stats, we still hit tunnel dst_entry refcount in
> ip6_tnl_xmit2()
>
> Since we are in RCU locked section, we can use skb_dst_set_noref() and
> avoid these atomic operations, leaving dst shared on cpus.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH net-next 0/5] qlcnic: Fixes and debug support
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1311982230-10543-6-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 29 Jul 2011 16:30:30 -0700
> Please apply the series to net-next. Thanks.
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 14:49:26 -0700
> Change details:
> - ioc->cna is always set to 1 for eth functions, remove the check that
> asserts IOC is in CNA mode in bfa_ioc_firmware_lock() and
> bfa_ioc_firmware_unlock() in bfa_ioc_ct.c.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 1/2] ipg: Use current logging styles
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, netdev, linux-kernel
In-Reply-To: <2ee87bfccbbb5cf1776df6751b65e4a3110019f4.1311993468.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 29 Jul 2011 19:38:14 -0700
> Add and use pr_fmt, pr_<level> and netdev_<level>.
> Convert printks with %[n].[n]x to %nx to be shorter
> and clearer.
> Consolidate printks to use a single printk rather
> than continued printks without KERN_CONT.
> Removed unnecessary trailing periods.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 2/2] bna: HW Interface Init Update
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-2-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 14:49:27 -0700
> Change details:
> - Split the hw interface into common and asic specific to support new asic
> in the future.
> - Fix bfa_ioc_ct_isr_mode_set() to also include the case that we are already
> in the desired msix mode.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 2/2] ipg: Use const
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, netdev, linux-kernel
In-Reply-To: <5311ff3fa329c4551cfdec5960162d3d490509f1.1311993468.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 29 Jul 2011 19:38:15 -0700
> Make a couple of declarations const to save some data space.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Queued up for net-next
^ permalink raw reply
* Re: PROBLEM: BUG (NULL ptr dereference in ipv4_dst_check)
From: synapse @ 2011-08-01 8:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1312002053.2873.41.camel@edumazet-laptop>
Hello
Sorry, I wasn't home on the weekend. Exactly to which tree should I
apply this?
It doesn't apply cleanly to 3.0.0. Am I missing something?
Gergely Kalman
On 07/30/11 07:00, Eric Dumazet wrote:
> Le vendredi 29 juillet 2011 à 17:43 +0200, Eric Dumazet a écrit :
>
>> Oh well, we already use RCU in neigh_destroy(), so adding rcu would need
>> to change all dst_get_neighbour() callers to be in one rcu_read_lock()
>> section.
>>
>> I'll take a look, I suspect its mostly already done.
>>
>>
> Here is the patch I finally cooked and tested.
>
> Could you please test it as well Gergely ?
>
> Thanks !
>
> [PATCH] net: fix NULL dereferences in check_peer_redir()
>
> Gergely Kalman reported crashes in check_peer_redir().
>
> It appears commit f39925dbde778 (ipv4: Cache learned redirect
> information in inetpeer.) added a race, leading to possible NULL ptr
> dereference.
>
> Since we can now change dst neighbour, we should make sure a reader can
> safely use a neighbour.
>
> Add RCU protection to dst neighbour, and make sure check_peer_redir()
> can be called safely by different cpus in parallel.
>
> As neighbours are already freed after one RCU grace period, this patch
> should not add typical RCU penalty (cache cold effects)
>
> Many thanks to Gergely for providing a pretty report pointing to the
> bug.
>
> Reported-by: Gergely Kalman<synapse@hippy.csoma.elte.hu>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> ---
> include/net/dst.h | 17 +++++++++++++----
> net/ipv4/ip_output.c | 10 ++++++++--
> net/ipv4/route.c | 14 ++++++++------
> net/ipv6/addrconf.c | 2 +-
> net/ipv6/ip6_fib.c | 2 +-
> net/ipv6/ip6_output.c | 13 +++++++++++--
> net/ipv6/route.c | 35 +++++++++++++++++++++++++----------
> 7 files changed, 67 insertions(+), 26 deletions(-)
>
> diff --git a/include/net/dst.h b/include/net/dst.h
> index 29e2557..13d507d 100644
> --- a/include/net/dst.h
> +++ b/include/net/dst.h
> @@ -37,7 +37,7 @@ struct dst_entry {
> unsigned long _metrics;
> unsigned long expires;
> struct dst_entry *path;
> - struct neighbour *_neighbour;
> + struct neighbour __rcu *_neighbour;
> #ifdef CONFIG_XFRM
> struct xfrm_state *xfrm;
> #else
> @@ -88,12 +88,17 @@ struct dst_entry {
>
> static inline struct neighbour *dst_get_neighbour(struct dst_entry *dst)
> {
> - return dst->_neighbour;
> + return rcu_dereference(dst->_neighbour);
> +}
> +
> +static inline struct neighbour *dst_get_neighbour_raw(struct dst_entry *dst)
> +{
> + return rcu_dereference_raw(dst->_neighbour);
> }
>
> static inline void dst_set_neighbour(struct dst_entry *dst, struct neighbour *neigh)
> {
> - dst->_neighbour = neigh;
> + rcu_assign_pointer(dst->_neighbour, neigh);
> }
>
> extern u32 *dst_cow_metrics_generic(struct dst_entry *dst, unsigned long old);
> @@ -382,8 +387,12 @@ static inline void dst_rcu_free(struct rcu_head *head)
> static inline void dst_confirm(struct dst_entry *dst)
> {
> if (dst) {
> - struct neighbour *n = dst_get_neighbour(dst);
> + struct neighbour *n;
> +
> + rcu_read_lock();
> + n = dst_get_neighbour(dst);
> neigh_confirm(n);
> + rcu_read_unlock();
> }
> }
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index ccaaa85..77d3ede 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -204,9 +204,15 @@ static inline int ip_finish_output2(struct sk_buff *skb)
> skb = skb2;
> }
>
> + rcu_read_lock();
> neigh = dst_get_neighbour(dst);
> - if (neigh)
> - return neigh_output(neigh, skb);
> + if (neigh) {
> + int res = neigh_output(neigh, skb);
> +
> + rcu_read_unlock();
> + return res;
> + }
> + rcu_read_unlock();
>
> if (net_ratelimit())
> printk(KERN_DEBUG "ip_finish_output2: No header cache and no neighbour!\n");
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 1730689..6afc4eb 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1628,16 +1628,18 @@ static int check_peer_redir(struct dst_entry *dst, struct inet_peer *peer)
> {
> struct rtable *rt = (struct rtable *) dst;
> __be32 orig_gw = rt->rt_gateway;
> - struct neighbour *n;
> + struct neighbour *n, *old_n;
>
> dst_confirm(&rt->dst);
>
> - neigh_release(dst_get_neighbour(&rt->dst));
> - dst_set_neighbour(&rt->dst, NULL);
> -
> rt->rt_gateway = peer->redirect_learned.a4;
> - rt_bind_neighbour(rt);
> - n = dst_get_neighbour(&rt->dst);
> +
> + n = ipv4_neigh_lookup(&rt->dst,&rt->rt_gateway);
> + if (IS_ERR(n))
> + return PTR_ERR(n);
> + old_n = xchg(&rt->dst._neighbour, n);
> + if (old_n)
> + neigh_release(old_n);
> if (!n || !(n->nud_state& NUD_VALID)) {
> if (n)
> neigh_event_send(n, NULL);
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index a55500c..f012ebd 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -656,7 +656,7 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr, int pfxlen,
> * layer address of our nexhop router
> */
>
> - if (dst_get_neighbour(&rt->dst) == NULL)
> + if (dst_get_neighbour_raw(&rt->dst) == NULL)
> ifa->flags&= ~IFA_F_OPTIMISTIC;
>
> ifa->idev = idev;
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index 54a4678..320d91d 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -1455,7 +1455,7 @@ static int fib6_age(struct rt6_info *rt, void *arg)
> RT6_TRACE("aging clone %p\n", rt);
> return -1;
> } else if ((rt->rt6i_flags& RTF_GATEWAY)&&
> - (!(dst_get_neighbour(&rt->dst)->flags& NTF_ROUTER))) {
> + (!(dst_get_neighbour_raw(&rt->dst)->flags& NTF_ROUTER))) {
> RT6_TRACE("purging route %p via non-router but gateway\n",
> rt);
> return -1;
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 32e5339..4c882cf 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -135,10 +135,15 @@ static int ip6_finish_output2(struct sk_buff *skb)
> skb->len);
> }
>
> + rcu_read_lock();
> neigh = dst_get_neighbour(dst);
> - if (neigh)
> - return neigh_output(neigh, skb);
> + if (neigh) {
> + int res = neigh_output(neigh, skb);
>
> + rcu_read_unlock();
> + return res;
> + }
> + rcu_read_unlock();
> IP6_INC_STATS_BH(dev_net(dst->dev),
> ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
> kfree_skb(skb);
> @@ -975,12 +980,14 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> * dst entry and replace it instead with the
> * dst entry of the nexthop router
> */
> + rcu_read_lock();
> n = dst_get_neighbour(*dst);
> if (n&& !(n->nud_state& NUD_VALID)) {
> struct inet6_ifaddr *ifp;
> struct flowi6 fl_gw6;
> int redirect;
>
> + rcu_read_unlock();
> ifp = ipv6_get_ifaddr(net,&fl6->saddr,
> (*dst)->dev, 1);
>
> @@ -1000,6 +1007,8 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> if ((err = (*dst)->error))
> goto out_err_release;
> }
> + } else {
> + rcu_read_unlock();
> }
> #endif
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index e8987da..9e69eb0 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -364,7 +364,7 @@ out:
> #ifdef CONFIG_IPV6_ROUTER_PREF
> static void rt6_probe(struct rt6_info *rt)
> {
> - struct neighbour *neigh = rt ? dst_get_neighbour(&rt->dst) : NULL;
> + struct neighbour *neigh;
> /*
> * Okay, this does not seem to be appropriate
> * for now, however, we need to check if it
> @@ -373,8 +373,10 @@ static void rt6_probe(struct rt6_info *rt)
> * Router Reachability Probe MUST be rate-limited
> * to no more than one per minute.
> */
> + rcu_read_lock();
> + neigh = rt ? dst_get_neighbour(&rt->dst) : NULL;
> if (!neigh || (neigh->nud_state& NUD_VALID))
> - return;
> + goto out;
> read_lock_bh(&neigh->lock);
> if (!(neigh->nud_state& NUD_VALID)&&
> time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
> @@ -387,8 +389,11 @@ static void rt6_probe(struct rt6_info *rt)
> target = (struct in6_addr *)&neigh->primary_key;
> addrconf_addr_solict_mult(target,&mcaddr);
> ndisc_send_ns(rt->rt6i_dev, NULL, target,&mcaddr, NULL);
> - } else
> + } else {
> read_unlock_bh(&neigh->lock);
> + }
> +out:
> + rcu_read_unlock();
> }
> #else
> static inline void rt6_probe(struct rt6_info *rt)
> @@ -412,8 +417,11 @@ static inline int rt6_check_dev(struct rt6_info *rt, int oif)
>
> static inline int rt6_check_neigh(struct rt6_info *rt)
> {
> - struct neighbour *neigh = dst_get_neighbour(&rt->dst);
> + struct neighbour *neigh;
> int m;
> +
> + rcu_read_lock();
> + neigh = dst_get_neighbour(&rt->dst);
> if (rt->rt6i_flags& RTF_NONEXTHOP ||
> !(rt->rt6i_flags& RTF_GATEWAY))
> m = 1;
> @@ -430,6 +438,7 @@ static inline int rt6_check_neigh(struct rt6_info *rt)
> read_unlock_bh(&neigh->lock);
> } else
> m = 0;
> + rcu_read_unlock();
> return m;
> }
>
> @@ -769,7 +778,7 @@ static struct rt6_info *rt6_alloc_clone(struct rt6_info *ort,
> rt->rt6i_dst.plen = 128;
> rt->rt6i_flags |= RTF_CACHE;
> rt->dst.flags |= DST_HOST;
> - dst_set_neighbour(&rt->dst, neigh_clone(dst_get_neighbour(&ort->dst)));
> + dst_set_neighbour(&rt->dst, neigh_clone(dst_get_neighbour_raw(&ort->dst)));
> }
> return rt;
> }
> @@ -803,7 +812,7 @@ restart:
> dst_hold(&rt->dst);
> read_unlock_bh(&table->tb6_lock);
>
> - if (!dst_get_neighbour(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> + if (!dst_get_neighbour_raw(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> nrt = rt6_alloc_cow(rt,&fl6->daddr,&fl6->saddr);
> else if (!(rt->dst.flags& DST_HOST))
> nrt = rt6_alloc_clone(rt,&fl6->daddr);
> @@ -1587,7 +1596,7 @@ void rt6_redirect(const struct in6_addr *dest, const struct in6_addr *src,
> dst_confirm(&rt->dst);
>
> /* Duplicate redirect: silently ignore. */
> - if (neigh == dst_get_neighbour(&rt->dst))
> + if (neigh == dst_get_neighbour_raw(&rt->dst))
> goto out;
>
> nrt = ip6_rt_copy(rt, dest);
> @@ -1682,7 +1691,7 @@ again:
> 1. It is connected route. Action: COW
> 2. It is gatewayed route or NONEXTHOP route. Action: clone it.
> */
> - if (!dst_get_neighbour(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> + if (!dst_get_neighbour_raw(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> nrt = rt6_alloc_cow(rt, daddr, saddr);
> else
> nrt = rt6_alloc_clone(rt, daddr);
> @@ -2326,6 +2335,7 @@ static int rt6_fill_node(struct net *net,
> struct nlmsghdr *nlh;
> long expires;
> u32 table;
> + struct neighbour *n;
>
> if (prefix) { /* user wants prefix routes only */
> if (!(rt->rt6i_flags& RTF_PREFIX_RT)) {
> @@ -2414,8 +2424,11 @@ static int rt6_fill_node(struct net *net,
> if (rtnetlink_put_metrics(skb, dst_metrics_ptr(&rt->dst))< 0)
> goto nla_put_failure;
>
> - if (dst_get_neighbour(&rt->dst))
> - NLA_PUT(skb, RTA_GATEWAY, 16,&dst_get_neighbour(&rt->dst)->primary_key);
> + rcu_read_lock();
> + n = dst_get_neighbour(&rt->dst);
> + if (n)
> + NLA_PUT(skb, RTA_GATEWAY, 16,&n->primary_key);
> + rcu_read_unlock();
>
> if (rt->dst.dev)
> NLA_PUT_U32(skb, RTA_OIF, rt->rt6i_dev->ifindex);
> @@ -2608,12 +2621,14 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
> #else
> seq_puts(m, "00000000000000000000000000000000 00 ");
> #endif
> + rcu_read_lock();
> n = dst_get_neighbour(&rt->dst);
> if (n) {
> seq_printf(m, "%pi6", n->primary_key);
> } else {
> seq_puts(m, "00000000000000000000000000000000");
> }
> + rcu_read_unlock();
> seq_printf(m, " %08x %08x %08x %08x %8s\n",
> rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
> rt->dst.__use, rt->rt6i_flags,
>
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: Alan Cox @ 2011-08-01 9:03 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Philip Blundell, Steffen Klassert,
David Dillow, Jes Sorensen, Donald Becker, Craig Southeren,
David Hinds
In-Reply-To: <1312082850-24914-3-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 30 Jul 2011 20:26:21 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> Moves the 3Com drivers into drivers/net/ethernet/3com/ and the
> necessary Kconfig and Makefile changes.
This still seems crazy
The 3c503 is not being moved (as its 8390 based)
But the 3c505/3c523/3c527/3c507 by that logic also shouldn't be moved
as really they all belong with the rest of the Intel devices they are
basically variants of (the 3c527 is weirder, in fact you can probably
run CP/M 86 on it if you were mad enough)
> drivers/net/{pcmcia => ethernet/3com}/3c574_cs.c | 0
> drivers/net/{pcmcia => ethernet/3com}/3c589_cs.c | 0
These are currently sensibly where they belong - with the pcmcia
adapters.
> drivers/net/{ => ethernet/3com}/3c59x.c | 0
> drivers/net/ethernet/3com/Kconfig | 200
> ++++++++++++++++++++++
> drivers/net/ethernet/3com/Makefile | 16 ++
> drivers/net/{ => ethernet/3com}/acenic.c | 0
> drivers/net/{ => ethernet/3com}/acenic.h | 0
And most Acenic devices are probably branded Netgear not 3COM and may
also claim to be from Farallon, SGI, Alteon or DEC. Again not a 3Com
originated part.
So I still think this patch is utter nonsense and just noise.
There isn't any sense in trying to line the network drivers up by
whatever is written on the box that was thrown away years before. The
reality is that most cards do not bear anything relevant to the chipset
vendors name, even by the early 1990s.
Architectually it makes more sense to keep tidy by bus type and by
chipset, not by vendor name
NAK
And even if you wanted to make Kconfig simpler - you don't need to move
files around.
Alan
^ permalink raw reply
* Re: PROBLEM: BUG (NULL ptr dereference in ipv4_dst_check)
From: Eric Dumazet @ 2011-08-01 9:15 UTC (permalink / raw)
To: synapse; +Cc: David Miller, netdev
In-Reply-To: <4E366A8F.201@hippy.csoma.elte.hu>
Le lundi 01 août 2011 à 10:57 +0200, synapse a écrit :
> Hello
>
> Sorry, I wasn't home on the weekend. Exactly to which tree should I
> apply this?
> It doesn't apply cleanly to 3.0.0. Am I missing something?
>
Could you try latest linux tree ?
We first validate patches on current tree, then backport them if needed
to previous kernels.
Thanks
^ permalink raw reply
* PLEASE REPLY, ITS A BUSINESS PROPOSAL
From: Weixin.Zheng.15 @ 2011-08-01 8:46 UTC (permalink / raw)
This is a business proposal for you, it is an oil exportation proposition
contract for you and this is a highly prospective crude oil sales
venture; This
involves the shipment of over 2.5 Million barrels of Light Crude Oil from Iraq
to Turkey, this project is genuine, legal and highly lucrative. For more
details, please reply to this email address: bahhahfeaz@hotmail.com
Sincerely
Bahhah Faez Saleh
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: David Miller @ 2011-08-01 9:21 UTC (permalink / raw)
To: alan
Cc: jeffrey.t.kirsher, netdev, gospo, sassmann, philb, klassert, dave,
jes, becker, craigs, dahinds
In-Reply-To: <20110801100303.48ed75f7@bob.linux.org.uk>
From: Alan Cox <alan@linux.intel.com>
Date: Mon, 1 Aug 2011 10:03:03 +0100
> And even if you wanted to make Kconfig simpler - you don't need to move
> files around.
The point is to move the files around, so that drivers/net/ isn't
a turd pond.
I agree with some of your feedback, but I disagree with a wholesale
rejecting the idea of untangling the mess under drivers/net/ as that's
the main reason why I want Jeff's work to be done
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove Pekka Savola from ipv6.
From: David Miller @ 2011-08-01 9:23 UTC (permalink / raw)
To: netdev; +Cc: pekkas
Signed-off-by: David S. Miller <davem@davemloft.net>
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a99fed1..5d4ceba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4443,7 +4443,6 @@ F: include/linux/netdevice.h
NETWORKING [IPv4/IPv6]
M: "David S. Miller" <davem@davemloft.net>
M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
-M: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
M: James Morris <jmorris@namei.org>
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
M: Patrick McHardy <kaber@trash.net>
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 3/6] drivers/net/niu.c: adjust array index
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: julia-dAYI7NvHqcQ
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA
In-Reply-To: <1311857165-14780-4-git-send-email-julia-dAYI7NvHqcQ@public.gmane.org>
From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Date: Thu, 28 Jul 2011 14:46:03 +0200
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> Convert array index from the loop bound to the loop index.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e1,e2,ar;
> @@
>
> for(e1 = 0; e1 < e2; e1++) { <...
> ar[
> - e2
> + e1
> ]
> ...> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: eric.dumazet
Cc: kaber, soltys, akpm, netdev, bugme-daemon, hadi, lucas.bocchi,
631945, 00bormoj, fdelawarde
In-Reply-To: <1312003362.2873.54.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 30 Jul 2011 07:22:42 +0200
> [PATCH] sch_sfq: fix sfq_enqueue()
>
> commit 8efa88540635 (sch_sfq: avoid giving spurious NET_XMIT_CN signals)
> forgot to call qdisc_tree_decrease_qlen() to signal upper levels that a
> packet (from another flow) was dropped, leading to various problems.
>
> With help from Michal Soltys and Michal Pokrywka, who did a bisection.
>
> Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=39372
> Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945
>
> Reported-by: Lucas Bocchi <lucas.bocchi@gmail.com>
> Reported-and-bisected-by: Michal Pokrywka <wolfmoon@o2.pl>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Michal Soltys <soltys@ziu.info>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/6] net: adjust array index
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: julia
Cc: kernel-janitors, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <1311857165-14780-2-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Thu, 28 Jul 2011 14:46:01 +0200
> From: Julia Lawall <julia@diku.dk>
>
> Convert array index from the loop bound to the loop index.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e1,e2,ar;
> @@
>
> for(e1 = 0; e1 < e2; e1++) { <...
> ar[
> - e2
> + e1
> ]
> ...> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: Alan Cox @ 2011-08-01 9:42 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, netdev, gospo, sassmann, philb, klassert, dave,
jes, becker, craigs, dahinds
In-Reply-To: <20110801.022107.740149515523315115.davem@davemloft.net>
On Mon, 01 Aug 2011 02:21:07 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Alan Cox <alan@linux.intel.com>
> Date: Mon, 1 Aug 2011 10:03:03 +0100
>
> > And even if you wanted to make Kconfig simpler - you don't need to
> > move files around.
>
> The point is to move the files around, so that drivers/net/ isn't
> a turd pond.
>
> I agree with some of your feedback, but I disagree with a wholesale
> rejecting the idea of untangling the mess under drivers/net/ as that's
> the main reason why I want Jeff's work to be done
In which case I think I'd sort by chipset for the non bus distinct
ones. That also has the added advantage that all the annoying weird
crap disappears into its own subdirectories for ancient chipsets !
So my suggestion would be :
Create an i82586 directory
Stick the following into it
3c505 3c507 3c523 3c527 eepro eexpress ni52 sun3_82586 znet
Create an i82596 directory
Stick the following into it
82596 lasi_82596 lib82596 lp486e sni_82596
Create an ns8390 directory
Stick the following into it
3c503 8390 8390p ac3200 apne aax88796 e2100 es3210 hp hp-plus
hydra lib8390 lne390 mac8390 ne ne2 ne2k-pci ne3210 ne-h8300
smc-mca smc-ultra32 smc-ultra stnic wd zorro8390
Create a sonic directory (sadly nobody ever produced a screwdriver card)
Stick the following into it
jazzsonic macsonic sonic xtsonic
Create a lance directory (actually this is 7990 + lance32 etc)
Stick the following into it
7990.c a2065 ariadne atarilance declance hplance lance mvme147
ni65 pcnet32 sun3lance sunlance
Some bits are then sort of bustypeish
Create a parallel directory
Stick the following into it
atp de600 de620 plip
Create a ppp directory
Stick all the ppp bits in
Given x25_asy is in WAN perhaps slip should be there too ?
^ permalink raw reply
* Re: [PATCH] cxgb3i: ref count cdev access to prevent modification while in use
From: Neil Horman @ 2011-08-01 11:18 UTC (permalink / raw)
To: netdev; +Cc: Divy Le Ray, Steve Wise, David S. Miller
In-Reply-To: <1311623817-6417-1-git-send-email-nhorman@tuxdriver.com>
On Mon, Jul 25, 2011 at 03:56:57PM -0400, Neil Horman wrote:
> This oops was reported recently:
> d:mon> e
> cpu 0xd: Vector: 300 (Data Access) at [c0000000fd4c7120]
> pc: d00000000076f194: .t3_l2t_get+0x44/0x524 [cxgb3]
> lr: d000000000b02108: .init_act_open+0x150/0x3d4 [cxgb3i]
> sp: c0000000fd4c73a0
> msr: 8000000000009032
> dar: 0
> dsisr: 40000000
> current = 0xc0000000fd640d40
> paca = 0xc00000000054ff80
> pid = 5085, comm = iscsid
> d:mon> t
> [c0000000fd4c7450] d000000000b02108 .init_act_open+0x150/0x3d4 [cxgb3i]
> [c0000000fd4c7500] d000000000e45378 .cxgbi_ep_connect+0x784/0x8e8 [libcxgbi]
> [c0000000fd4c7650] d000000000db33f0 .iscsi_if_rx+0x71c/0xb18
> [scsi_transport_iscsi2]
> [c0000000fd4c7740] c000000000370c9c .netlink_data_ready+0x40/0xa4
> [c0000000fd4c77c0] c00000000036f010 .netlink_sendskb+0x4c/0x9c
> [c0000000fd4c7850] c000000000370c18 .netlink_sendmsg+0x358/0x39c
> [c0000000fd4c7950] c00000000033be24 .sock_sendmsg+0x114/0x1b8
> [c0000000fd4c7b50] c00000000033d208 .sys_sendmsg+0x218/0x2ac
> [c0000000fd4c7d70] c00000000033f55c .sys_socketcall+0x228/0x27c
> [c0000000fd4c7e30] c0000000000086a4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 00000080da560cfc
>
> The root cause was an EEH error, which sent us down the offload_close path in
> the cxgb3 driver, which in turn sets cdev->lldev to NULL, without regard for
> upper layer driver (like the cxgbi drivers) which might have execution contexts
> in the middle of its use. The result is the oops above, when t3_l2t_get attempts
> to dereference cdev->lldev right after the EEH error handler sets it to NULL.
>
> The fix is to reference count the cdev structure. When an EEH error occurs, the
> shutdown path:
> t3_adapter_error->offload_close->cxgb3i_remove_clients->cxgb3i_dev_close
> will now block until such time as the cdev pointer has a use count of zero.
> This coupled with the fact that lookups will now skip finding any registered
> cdev's in cxgbi_device_find_by_[lldev|netdev] with the CXGBI_FLAG_ADAPTER_RESET
> bit set ensures that on an EEH, the setting of lldev to NULL in offload_close
> will only happen after there are no longer any active users of the data
> structure.
>
> This has been tested by the reporter and shown to fix the reproted oops
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Divy Le Ray <divy@chelsio.com>
> CC: Steve Wise <swise@chelsio.com>
> CC: "David S. Miller" <davem@davemloft.net>
Divy, Steve, I think Dave is waiting for an ACK from one of you to, since you're
the listed maintainers.
Neil
^ permalink raw reply
* Re: [Bugme-new] [Bug 39742] New: 2.6.39.3 crash and hangs in 1-2 minutes. Still have traps.
From: Rustam Afanasyev @ 2011-08-01 11:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon, Patrick McHardy
In-Reply-To: <20110722144214.577718f0.akpm@linux-foundation.org>
With applied patch from xeb
(http://www.spinics.net/lists/netdev/msg170766.html)
there isn't hangs any more. Panics is still occurs. They only occur much
less frequently. And seems it's different place.
Here it is.
1 was like:
[ 1582.319303] ------------[ cut here ]------------
[ 1582.323205] kernel BUG at include/linux/skbuff.h:1189!
[ 1582.323205] invalid opcode: 0000 [#1] SMP
[ 1582.323205] last sysfs file: /sys/devices/virtual/net/ppp168/uevent
[ 1582.323205] CPU 0
[ 1582.323205] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe
act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2d
[ 1582.323205]
[ 1582.598100] Pid: 0, comm: swapper Not tainted 2.6.39-std-def-alt3 #1
ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 1582.616208] RIP: 0010:[<ffffffff8134a94b>] [<ffffffff8134a94b>]
skb_pull+0x2b/0x30
[ 1582.616208] RSP: 0018:ffff88011fc03b20 EFLAGS: 00010293
[ 1582.616208] RAX: 0000000000000247 RBX: ffff880117ac2880 RCX:
0000000000000027
[ 1582.616208] RDX: 0000000000000027 RSI: 0000000000000002 RDI:
ffff880117ac2880
[ 1582.698595] RBP: ffff88011fc03b20 R08: 0000000000000228 R09:
000000000000000c
[ 1582.698595] R10: 0000000000000240 R11: 0000000000000001 R12:
ffff880118f00800
[ 1582.698595] R13: ffff8801176a086e R14: 000000000000002f R15:
ffff880115346000
[ 1582.698595] FS: 0000000000000000(0000) GS:ffff88011fc00000(0000)
knlGS:0000000000000000
[ 1582.698595] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1582.808009] CR2: 0000000000645f4c CR3: 000000011760b000 CR4:
00000000000006f0
[ 1582.808009] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 1582.808009] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 1582.808009] Process swapper (pid: 0, threadinfo ffffffff81800000,
task ffffffff8180b020)
[ 1582.808009] Stack:
[ 1582.808009] ffff88011fc03b50 ffffffffa034663a ffff88011fc03b80
ffff880118f00800
[ 1582.808009] ffff880117ac2880 0000000000000000 ffff88011fc03b90
ffffffff81346ecc
[ 1582.808009] ffff88011fc03bb0 ffffffff8134b4e9 0000000000000001
ffff880117ac2880
[ 1582.808009] Call Trace:
[ 1582.808009] <IRQ>
[ 1582.808009] [<ffffffffa034663a>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 1582.808009] [<ffffffff81346ecc>] sk_receive_skb+0x10c/0x140
[ 1582.808009] [<ffffffff8134b4e9>] ? __pskb_pull_tail+0x59/0x3e0
[ 1582.808009] [<ffffffffa0346783>] pptp_rcv+0x143/0x190 [pptp]
[ 1582.808009] [<ffffffffa03250ad>] gre_rcv+0x5d/0x80 [gre]
[ 1582.808009] [<ffffffff8138946d>] ip_local_deliver_finish+0xdd/0x2a0
[ 1582.808009] [<ffffffff813897f0>] ip_local_deliver+0x80/0x90
[ 1582.808009] [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 1582.808009] [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 1582.808009] [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 1582.808009] [<ffffffff8100cf01>] ? do_IRQ+0x61/0xe0
[ 1582.808009] [<ffffffff8140a593>] ? common_interrupt+0x13/0x13
[ 1582.808009] [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 1582.808009] [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 1582.808009] [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 1582.808009] [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 1582.808009] [<ffffffffa01b229b>] igb_poll+0x6fb/0xae0 [igb]
[ 1582.808009] [<ffffffff81356f5a>] ? __netif_receive_skb+0x52a/0x690
[ 1582.808009] [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 1582.808009] [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 1582.808009] [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 1582.808009] [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 1582.808009] [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 1582.808009] [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 1582.808009] [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 1582.808009] <EOI>
[ 1582.808009] [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 1582.808009] [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 1582.808009] [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 1582.808009] [<ffffffff813f396d>] rest_init+0x6d/0x80
[ 1582.808009] [<ffffffff8187fbe6>] start_kernel+0x392/0x39d
[ 1582.808009] [<ffffffff8187f347>] x86_64_start_reservations+0x132/0x136
[ 1582.808009] [<ffffffff8187f44c>] x86_64_start_kernel+0x101/0x110
[ 1582.808009] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89
47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e
[ 1582.808009] RIP [<ffffffff8134a94b>] skb_pull+0x2b/0x30
[ 1582.808009] RSP <ffff88011fc03b20>
[ 1583.628015] ---[ end trace 6c39f3d0e04ed229 ]---
[ 1583.641960] Kernel panic - not syncing: Fatal exception in interrupt
[ 1583.661088] Pid: 0, comm: swapper Tainted: G D
2.6.39-std-def-alt3 #1
[ 1583.682846] Call Trace:
[ 1583.690254] <IRQ> [<ffffffff81407284>] panic+0x8c/0x197
[ 1583.706576] [<ffffffff8140b4d2>] oops_end+0xe2/0xf0
[ 1583.721540] [<ffffffff8100e876>] die+0x56/0x90
[ 1583.735215] [<ffffffff8140abf4>] do_trap+0xc4/0x170
[ 1583.750191] [<ffffffff8100bf00>] do_invalid_op+0x90/0xb0
[ 1583.766466] [<ffffffff8134a94b>] ? skb_pull+0x2b/0x30
[ 1583.781965] [<ffffffffa01f31d6>] ? ipt_do_table+0x256/0x670 [ip_tables]
other was:
[ 245.268856] ------------[ cut here ]------------
[ 245.272797] kernel BUG at include/linux/skbuff.h:1189!
[ 245.272797] invalid opcode: 0000 [#1] SMP
[ 245.272797] last sysfs file: /sys/devices/virtual/net/ppp100/uevent
[ 245.272797] CPU 3
[ 245.272797] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe
act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2d
[ 245.272797]
[ 245.272797] Pid: 0, comm: kworker/0:1 Not tainted 2.6.39-std-def-alt3
#1 ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 245.272797] RIP: 0010:[<ffffffff8134a94b>] [<ffffffff8134a94b>]
skb_pull+0x2b/0x30
[ 245.272797] RSP: 0018:ffff88011fd83b20 EFLAGS: 00010297
[ 245.272797] RAX: 0000000000000518 RBX: ffff880116a0e0c0 RCX:
0000000000000444
[ 245.272797] RDX: 0000000000000444 RSI: 0000000000000010 RDI:
ffff880116a0e0c0
[ 245.272797] RBP: ffff88011fd83b20 R08: 0000000000000500 R09:
000000000000000c
[ 245.272797] R10: 0000000000000240 R11: 0000000000000001 R12:
ffff8801171fb400
[ 245.272797] R13: ffff880116a0cc72 R14: 000000000000002f R15:
ffff8801168de000
[ 245.272797] FS: 0000000000000000(0000) GS:ffff88011fd80000(0000)
knlGS:0000000000000000
[ 245.272797] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 245.272797] CR2: 00000000008faa2c CR3: 00000001151c2000 CR4:
00000000000006e0
[ 245.272797] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 245.272797] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 245.272797] Process kworker/0:1 (pid: 0, threadinfo ffff880118f46000,
task ffff880118f444c0)
[ 245.272797] Stack:
[ 245.272797] ffff88011fd83b50 ffffffffa03374e2 ffff88011fd83b80
ffff8801171fb400
[ 245.272797] ffff880116a0e0c0 0000000000000000 ffff88011fd83b90
ffffffff81346ecc
[ 245.892667] ffff88011fd83bb0 ffffffff8134b4e9 0000000000000001
ffff880116a0e0c0
[ 245.892667] Call Trace:
[ 245.892667] <IRQ>
[ 245.892667] [<ffffffffa03374e2>] pptp_rcv_core+0xc2/0x220 [pptp]
[ 245.892667] [<ffffffff81346ecc>] sk_receive_skb+0x10c/0x140
[ 245.892667] [<ffffffff8134b4e9>] ? __pskb_pull_tail+0x59/0x3e0
[ 245.892667] [<ffffffffa0337783>] pptp_rcv+0x143/0x190 [pptp]
[ 245.892667] [<ffffffffa03160ad>] gre_rcv+0x5d/0x80 [gre]
[ 245.892667] [<ffffffff8138946d>] ip_local_deliver_finish+0xdd/0x2a0
[ 245.892667] [<ffffffff813897f0>] ip_local_deliver+0x80/0x90
[ 245.892667] [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 245.892667] [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 245.892667] [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 245.892667] [<ffffffff81137985>] ? __kmalloc_node_track_caller+0x55/0x60
[ 245.892667] [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 245.892667] [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 245.892667] [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 245.892667] [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 245.892667] [<ffffffffa01ea29b>] igb_poll+0x6fb/0xae0 [igb]
[ 245.892667] [<ffffffff81356f5a>] ? __netif_receive_skb+0x52a/0x690
[ 245.892667] [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 245.892667] [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 245.892667] [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 245.892667] [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 245.892667] [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 245.892667] [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 245.892667] [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 245.892667] <EOI>
[ 245.892667] [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 245.892667] [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 245.892667] [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 245.892667] [<ffffffff81403729>] start_secondary+0x197/0x19c
[ 245.892667] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89
47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e
[ 245.892667] RIP [<ffffffff8134a94b>] skb_pull+0x2b/0x30
[ 245.892667] RSP <ffff88011fd83b20>
[ 246.520989] ---[ end trace ad4c118e9d8ac857 ]---
[ 246.534912] Kernel panic - not syncing: Fatal exception in interrupt
[ 246.534916] Pid: 0, comm: kworker/0:1 Tainted: G D
2.6.39-std-def-alt3 #1
^ permalink raw reply
* Re: [net-next v2 16/71] mlx4: Move the Mellanox driver
From: Roland Dreier @ 2011-08-01 13:10 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann
In-Reply-To: <1312082850-24914-17-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 8:26 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Moves the Mellanox driver into drivers/net/ethernet/mellanox/ and
> make the necessary Kconfig and Makefile changes.
Hi,
no objection to this, but if we're going to move this code around,
maybe it makes sense to split the mlx4_core and mlx4_en code
into separate directories at the same time?
- R.
^ permalink raw reply
* [Bug?] Machine hangs, rtl8192se possible cause
From: Jaroslaw Fedewicz @ 2011-08-01 13:26 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
Hello,
I own a Thinkpad Edge 13 (AMD, machine type 0197) laptop, which is
shipped with a Realtek 8192 SE WLAN card.
The WLAN support with this particular card was never brilliant under
Linux, first with (very) flakey drivers from Realtek which would stop
transmitting packets every so often or panic after a few hours of
usage. The in-tree drivers are better in this respect, but I'm
experiencing mysterious hangups every once in a while. The machine is
effectively dead and has to be power-cycled — no oops, no kernel
panic, no nothing, it just hangs and that's it.
I'm sure this is not a regression because the hangups were right there
from the start.
The last meaningful message which might be helpful was: "wait for
BIT(6) return value X" (I don't remember what X was, it was a while
ago and only once).
I don't know if there are other means to debug (netconsole over eth0?)
those hangs. The only other thing I know for sure that I can get a
week long uptime if I blacklist rtl8192se.ko from loading.
If I can provide any additional information to track the bug (or a
faulty piece of hardware?) down, please tell me. Google tells me
nobody reported this before, or it was just me feeding incorrect
keywords.
Thanks for your kind attention.
P. S. Tried netconsole before, got nothing to pinpoint the error. The
only recurring pattern I could see in it was that almost every time
the machine hanged was after ip6tables initialized, at least it was
the last message in the log.
P. P. S. I don't track netdev@ and linux-wireless@ lists, so please Cc: me.
--
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
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