* (unknown),
From: UBS International Holdings BV @ 2010-03-29 13:47 UTC (permalink / raw)
UBS International Holdings BV
Herengracht 600
NL-1017 CJ Amsterdam, Netherlands.
www.ubs.com/investmentbank
Greetings,
I am an investment consultant working with UBS International Holdings BV
in the Netherlands. I will be happy to work a transaction of $8.5million
out with you if you have a corporate or personal bank Account. If you are
interested, get back to me via my private email for further informations;
hhbeuker@live.nl
I look forward to hearing from you as soon as possible and thank you for
your time and attention.
Warmest Regards,
Mr. Beuker Hendrik
Investment Consultant.
UBS.
^ permalink raw reply
* Re: Question for iproute
From: Marco @ 2010-03-29 14:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100328133742.2f21e842@nehalam>
On Sun, Mar 28, 2010 at 01:37:42PM -0700, Stephen Hemminger wrote:
> Date: Sun, 28 Mar 2010 13:37:42 -0700
> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Subject: Re: Question for iproute
> To: Marco <ctxspi@gmail.com>
> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.3; x86_64-pc-linux-gnu)
>
> On Sun, 28 Mar 2010 18:52:44 +0200
> Marco <ctxspi@gmail.com> wrote:
>
> > Hello, can I ask you one question?
> >
> > Where is official forum or mailing list for iproute tools?
> >
> > lartc is not manteined
> >
> > Thanks.
> >
>
> netdev@vger.kernel.org mailing list is the best place to discuss iproute
> issues.
>
>
Can you help please?
---fine del testo---
--
Messaggio da Marco
--------------------------------------------------------------------
Meglio coltivare GNU/Linux...... tanto Windows si pianta da solo!!!!
^ permalink raw reply
* Re: [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead
From: Herbert Xu @ 2010-03-29 14:43 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <1269871964-5412-2-git-send-email-timo.teras@iki.fi>
On Mon, Mar 29, 2010 at 05:12:38PM +0300, Timo Teras wrote:
>
> @@ -1132,7 +1119,7 @@ int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
> __xfrm_policy_link(pol, XFRM_POLICY_MAX+dir);
> }
> if (old_pol)
> - __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
> + old_pol = __xfrm_policy_unlink(old_pol, XFRM_POLICY_MAX+dir);
> write_unlock_bh(&xfrm_policy_lock);
>
> if (old_pol) {
So when can this actually fail?
Otherwise this patch looks good to me.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-29 14:50 UTC (permalink / raw)
To: Martin Sustrik; +Cc: Andi Kleen, David Miller, netdev, linux-kernel
In-Reply-To: <4BAE382D.7090903@250bpm.com>
On Sat, 27 Mar 2010, Martin Sustrik wrote:
> Andi Kleen wrote:
>
> > I did a quick read and the manpage/interface seem reasonable to me.
>
> You may also have a look at original PGM implementation by Luigi Rizzo
> (FreeBSD). It's not maintained, but it might give you broader view.
>
> http://info.iet.unipi.it/~luigi/pgm-code/
Interesting. Which files in that directory contain the most current code?
Looks like the tcpdump patch has been merged.
Here is another tcpdump patch that implements decoding PGM via UDP. Anyone
know how to submit something like that?
(Need to specify -Tpgm option to use pgm decoder on UDP traffic)
Index: tcpdump/interface.h
===================================================================
--- tcpdump.orig/interface.h 2010-02-26 18:50:39.411609391 -0600
+++ tcpdump/interface.h 2010-02-26 18:51:04.270350179 -0600
@@ -74,6 +74,7 @@
#define PT_CNFP 7 /* Cisco NetFlow protocol */
#define PT_TFTP 8 /* trivial file transfer protocol */
#define PT_AODV 9 /* Ad-hoc On-demand Distance Vector Protocol */
+#define PT_PGM 10 /* The PGM protocol */
#ifndef min
#define min(a,b) ((a)>(b)?(b):(a))
Index: tcpdump/print-udp.c
===================================================================
--- tcpdump.orig/print-udp.c 2010-02-26 18:51:35.921610552 -0600
+++ tcpdump/print-udp.c 2010-02-26 18:53:54.440349950 -0600
@@ -520,6 +520,11 @@
tftp_print(cp, length);
break;
+ case PT_PGM:
+ udpipaddr_print(ip, sport, dport);
+ pgm_print(cp, length, (const u_char *)ip);
+ break;
+
case PT_AODV:
udpipaddr_print(ip, sport, dport);
aodv_print((const u_char *)(up + 1), length,
Index: tcpdump/tcpdump.c
===================================================================
--- tcpdump.orig/tcpdump.c 2010-02-26 18:37:13.971601597 -0600
+++ tcpdump/tcpdump.c 2010-02-26 18:37:43.290033748 -0600
@@ -854,6 +854,8 @@
packettype = PT_TFTP;
else if (strcasecmp(optarg, "aodv") == 0)
packettype = PT_AODV;
+ else if (strcasecmp(optarg, "pgm") == 0)
+ packettype = PT_PGM;
else
error("unknown packet type `%s'", optarg);
break;
^ permalink raw reply
* Re: Network performance - iperf
From: Michal Simek @ 2010-03-29 14:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: LKML, John Williams, netdev, Grant Likely, John Linn,
Steven J. Magnani, Arnd Bergmann, akpm
In-Reply-To: <1269864994.2164.21.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le lundi 29 mars 2010 à 13:33 +0200, Michal Simek a écrit :
>
>> Do you have any idea howto improve TCP/UDP performance in general?
>> Or tests which can point me on weak places.
>
> Could you post "netstat -s" on your receiver, after fresh boot and your
> iperf session, for 32 MB and 256 MB ram case ?
>
I am not sure if is helpful but look below.
Thanks,
Michal
~ # ./netstat -s
Ip:
0 total packets received
0 forwarded
0 incoming packets discarded
0 incoming packets delivered
0 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
0 active connections openings
0 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
0 segments received
0 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
0 packets sent
RcvbufErrors: 0
SndbufErrors: 0
UdpLite:
InDatagrams: 0
NoPorts: 0
InErrors: 0
OutDatagrams: 0
RcvbufErrors: 0
SndbufErrors: 0
error parsing /proc/net/snmp: Success
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
^ permalink raw reply
* Re: Add PGM protocol support to the IP stack
From: Christoph Lameter @ 2010-03-29 15:00 UTC (permalink / raw)
To: Andi Kleen; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20100327131138.GD20695@one.firstfloor.org>
On Sat, 27 Mar 2010, Andi Kleen wrote:
> On Fri, Mar 26, 2010 at 12:33:07PM -0500, Christoph Lameter wrote:
> > Here is a pgm.7 manpage describing how the socket API could look like for
> > a PGM implementation.
> >
> > I dumped the RM_* based socket options from the other OS since most of the
> > options were unusable.
>
> I did a quick read and the manpage/interface seem reasonable to me.
Thanks. I will then proceed to get a patch out that implements the
network environment. Then we can plug the openpgm logic in there.
> You changed the parameter struct fields to lower case. While
> that looks definitely more Linuxy than before does it mean programs
> have to #ifdef this? It might be good idea to have at least some
> optional compat header that #defines.
The socket API will be completely different. The basic handling of the
sockets is the same (binding, listening, connecting). There is no way of
mapping M$ socket options to Linux socket options with the approach that
I proposed in the manpage. The stats structure is different too since some
key elements were missing.
What users are there of the M$ api? I have seen vendors supplying their
own pgm implementation (guess due to bit rot in the old M$
implementation).
^ permalink raw reply
* Re: [PATCH RFC] inetpeer: Support ipv6 addresses.
From: Herbert Xu @ 2010-03-29 15:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eric Dumazet
In-Reply-To: <20100328143235.GA16694@gondor.apana.org.au>
On Sun, Mar 28, 2010 at 10:32:35PM +0800, Herbert Xu wrote:
>
> Here's a convoluted scheme that I just thought up as a compromise
> between your wish to expel the metrics and maintaining the policy
> routing semantics.
I think the bigger question is are we now ready for a per-cpu
route cache?
The route cache is one of the few remaining global structures
that is standing in the way of full multicore scalability.
Or is there another way of solving this?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] net/wireless/libertas: do not call wiphy_unregister() w/o wiphy_register()
From: Daniel Mack @ 2010-03-29 15:14 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Daniel Mack, Dan Williams, John W. Linville, Holger Schurig,
Bing Zhao, libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
The libertas driver calls wiphy_unregister() without a prior
wiphy_register() when a devices fails initialization. Fix this by
introducing a private flag.
[ 9.310000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[...]
[ 9.330000] [<c0311310>] (wiphy_unregister+0xfc/0x19c) from [<bf00c9ec>] (lbs_cfg_free+0x70/0x9c [libertas])
[ 9.330000] [<bf00c9ec>] (lbs_cfg_free+0x70/0x9c [libertas]) from [<bf014fdc>] (lbs_remove_card+0x180/0x210 [libertas])
[ 9.330000] [<bf014fdc>] (lbs_remove_card+0x180/0x210 [libertas]) from [<bf035394>] (if_sdio_probe+0xdc4/0xef4 [libertas_sdio])
[ 9.330000] [<bf035394>] (if_sdio_probe+0xdc4/0xef4 [libertas_sdio]) from [<c0230d14>] (sdio_bus_probe+0xd4/0xf0)
[ 9.330000] [<c0230d14>] (sdio_bus_probe+0xd4/0xf0) from [<c01a6034>] (driver_probe_device+0xa4/0x174)
[ 9.330000] [<c01a6034>] (driver_probe_device+0xa4/0x174) from [<c01a6164>] (__driver_attach+0x60/0x84)
[ 9.330000] [<c01a6164>] (__driver_attach+0x60/0x84) from [<c01a5854>] (bus_for_each_dev+0x4c/0x8c)
[ 9.330000] [<c01a5854>] (bus_for_each_dev+0x4c/0x8c) from [<c01a50e4>] (bus_add_driver+0xa0/0x228)
[ 9.330000] [<c01a50e4>] (bus_add_driver+0xa0/0x228) from [<c01a6470>] (driver_register+0xc0/0x150)
[ 9.330000] [<c01a6470>] (driver_register+0xc0/0x150) from [<bf03a06c>] (if_sdio_init_module+0x6c/0x108 [libertas_sdio])
[ 9.330000] [<bf03a06c>] (if_sdio_init_module+0x6c/0x108 [libertas_sdio]) from [<c00263ac>] (do_one_initcall+0x5c/0x1bc)
[ 9.330000] [<c00263ac>] (do_one_initcall+0x5c/0x1bc) from [<c0069f80>] (sys_init_module+0xc0/0x1f0)
[ 9.330000] [<c0069f80>] (sys_init_module+0xc0/0x1f0) from [<c0026f00>] (ret_fast_syscall+0x0/0x30)
Signed-off-by: Daniel Mack <daniel-rDUAYElUppE@public.gmane.org>
Cc: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Cc: Holger Schurig <hs4233-x6+DxXLjN1AJvtFkdXX2Hg4jNU5vUVPG@public.gmane.org>
Cc: Bing Zhao <bzhao-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Cc: libertas-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/net/wireless/libertas/cfg.c | 8 ++++++--
drivers/net/wireless/libertas/dev.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 4396dcc..82ebe14 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -172,6 +172,8 @@ int lbs_cfg_register(struct lbs_private *priv)
if (ret < 0)
lbs_pr_err("cannot register wiphy device\n");
+ priv->wiphy_registered = true;
+
ret = register_netdev(priv->dev);
if (ret)
lbs_pr_err("cannot register network device\n");
@@ -190,9 +192,11 @@ void lbs_cfg_free(struct lbs_private *priv)
if (!wdev)
return;
- if (wdev->wiphy) {
+ if (priv->wiphy_registered)
wiphy_unregister(wdev->wiphy);
+
+ if (wdev->wiphy)
wiphy_free(wdev->wiphy);
- }
+
kfree(wdev);
}
diff --git a/drivers/net/wireless/libertas/dev.h b/drivers/net/wireless/libertas/dev.h
index 6977ee8..6875e14 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -36,6 +36,7 @@ struct lbs_private {
/* CFG80211 */
struct wireless_dev *wdev;
+ bool wiphy_registered;
/* Mesh */
struct net_device *mesh_dev; /* Virtual device */
--
1.7.0
--
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 related
* Re: Minimizing TCP latency
From: Ben Hutchings @ 2010-03-29 15:23 UTC (permalink / raw)
To: Ben Hoyt; +Cc: netdev
In-Reply-To: <7c93bf1e1003282024p75e70011j31577b42f29cc153@mail.gmail.com>
On Mon, 2010-03-29 at 16:24 +1300, Ben Hoyt wrote:
> > I'm happy to receive some pointers via this list [...]
>
> Sorry, I should also have posted more about what I've done in terms of
> reducing latency so far:
>
> * We've already got TCP_NODELAY activated.
>
> * We've also turned off interrupt coalescing on the network card (for
> example, see http://www.29west.com/docs/THPM/latency-interrupt-coalescing.html).
>
> * We've modified our process's CPU affinity so it runs on a core by
> itself, reducing interrupt-handling latency slightly further.
>
> * Our code is written in C, and we've tried to keep it as close to the
> kernel's socket calls as possible.
>
> So we're currently looking further into ways to reduce latency, which
> currently looks like it'll mean digging deeper into the kernel's
> networking options and innards.
Choose low-latency NICs. Read the tuning guide, but run your own
benchmarks.
> FYI, we're using RHE release 4 and kernel version 2.6.9 on x86_64 machines.
You're not going to get much help here in working on that kernel.
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] NETLABEL: Fix an RCU warning
From: Paul E. McKenney @ 2010-03-29 15:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Howells, paul.moore, netdev
In-Reply-To: <1269516484.3626.21.camel@edumazet-laptop>
On Thu, Mar 25, 2010 at 12:28:04PM +0100, Eric Dumazet wrote:
> Le jeudi 25 mars 2010 à 11:06 +0000, David Howells a écrit :
> > Fix an RCU warning in the netlabel code due to missing rcu read locking around
> > an rcu_dereference() in netlbl_unlhsh_hash() when called from
> > netlbl_unlhsh_netdev_handler():
> >
> > ===================================================
> > [ INFO: suspicious rcu_dereference_check() usage. ]
> > ---------------------------------------------------
> > net/netlabel/netlabel_unlabeled.c:246 invoked rcu_dereference_check() without protection!
> >
> > other info that might help us debug this:
> >
> >
> > rcu_scheduler_active = 1, debug_locks = 0
> > 2 locks held by ip/5108:
> > #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff812c4a36>] rtnl_lock+0x12/0x14
> > #1: (netlbl_unlhsh_lock){+.+...}, at: [<ffffffff8134daa4>] netlbl_unlhsh_netdev_handler+0x1e/0x86
> >
> > stack backtrace:
> > Pid: 5108, comm: ip Not tainted 2.6.34-rc2-cachefs #114
> > Call Trace:
> > [<ffffffff8105121f>] lockdep_rcu_dereference+0xaa/0xb2
> > [<ffffffff8134d781>] netlbl_unlhsh_hash+0x3e/0x50
> > [<ffffffff8134d7a1>] netlbl_unlhsh_search_iface+0xe/0x84
> > [<ffffffff8134daaf>] netlbl_unlhsh_netdev_handler+0x29/0x86
> > [<ffffffff81048362>] notifier_call_chain+0x32/0x5e
> > [<ffffffff810483fe>] raw_notifier_call_chain+0xf/0x11
> > [<ffffffff812ba924>] call_netdevice_notifiers+0x16/0x18
> > [<ffffffff812bac22>] __dev_notify_flags+0x37/0x5b
> > [<ffffffff812bac8c>] dev_change_flags+0x46/0x52
> > [<ffffffff812c41af>] do_setlink+0x250/0x3cd
> > [<ffffffff812c4ee8>] rtnl_newlink+0x2b6/0x49d
> > [<ffffffff812c4cdd>] ? rtnl_newlink+0xab/0x49d
> > [<ffffffff812c4c17>] rtnetlink_rcv_msg+0x1b7/0x1d2
> > [<ffffffff812c4a60>] ? rtnetlink_rcv_msg+0x0/0x1d2
> > [<ffffffff812cc1dc>] netlink_rcv_skb+0x3e/0x8f
> > [<ffffffff812c4a59>] rtnetlink_rcv+0x21/0x28
> > [<ffffffff812cbefe>] netlink_unicast+0x218/0x28f
> > [<ffffffff812cc76e>] netlink_sendmsg+0x26b/0x27a
> > [<ffffffff812a9f1d>] sock_sendmsg+0xd4/0xf5
> > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > [<ffffffff81096e13>] ? might_fault+0x97/0x9e
> > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > [<ffffffff812b4122>] ? verify_iovec+0x59/0x97
> > [<ffffffff812aa1d9>] sys_sendmsg+0x209/0x273
> > [<ffffffff810976dc>] ? __do_fault+0x395/0x3cd
> > [<ffffffff8109928f>] ? handle_mm_fault+0x324/0x69d
> > [<ffffffff81051e4e>] ? trace_hardirqs_on_caller+0x10c/0x130
> > [<ffffffff81074972>] ? audit_syscall_entry+0x17d/0x1b0
> > [<ffffffff81364154>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
> >
> > Signed-off-by: David Howells <dhowells@redhat.com>
> > ---
> >
> > net/netlabel/netlabel_unlabeled.c | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
> > index 852d9d7..7ea64e4 100644
> > --- a/net/netlabel/netlabel_unlabeled.c
> > +++ b/net/netlabel/netlabel_unlabeled.c
> > @@ -799,6 +799,7 @@ static int netlbl_unlhsh_netdev_handler(struct notifier_block *this,
> >
> > /* XXX - should this be a check for NETDEV_DOWN or _UNREGISTER? */
> > if (event == NETDEV_DOWN) {
> > + rcu_read_lock();
> > spin_lock(&netlbl_unlhsh_lock);
> > iface = netlbl_unlhsh_search_iface(dev->ifindex);
> > if (iface != NULL && iface->valid) {
> > @@ -807,6 +808,7 @@ static int netlbl_unlhsh_netdev_handler(struct notifier_block *this,
> > } else
> > iface = NULL;
> > spin_unlock(&netlbl_unlhsh_lock);
> > + rcu_read_unlock();
> > }
> >
> > if (iface != NULL)
> >
> > --
>
> Sorry this is not the right fix.
>
> Fix is to change the dereference check to take into account the lock
> owned here.
So we need the rcu_dereference() in netlbl_unlhsh_search_iface()
to become someething like the following?
bkt_list = &rcu_dereference_check(netlbl_unlhsh,
rcu_read_lock_held() ||
lockdep_is_held(&netlbl_unlhsh_lock))->tbl[bkt];
Or is this the wrong lock?
Thanx, Paul
^ permalink raw reply
* Re: Network performance - iperf
From: Michal Simek @ 2010-03-29 15:27 UTC (permalink / raw)
Cc: Eric Dumazet, LKML, John Williams, netdev, Grant Likely,
John Linn, Steven J. Magnani, Arnd Bergmann, akpm
In-Reply-To: <4BB0BF28.5090505@petalogix.com>
Michal Simek wrote:
> Eric Dumazet wrote:
>> Le lundi 29 mars 2010 à 13:33 +0200, Michal Simek a écrit :
>>
>>> Do you have any idea howto improve TCP/UDP performance in general?
>>> Or tests which can point me on weak places.
>>
>> Could you post "netstat -s" on your receiver, after fresh boot and your
>> iperf session, for 32 MB and 256 MB ram case ?
>>
>
> I am not sure if is helpful but look below.
>
Sorry I forget to c&p that second part. :-(
Look below.
Michal
32MB
~ # cat /proc/meminfo | head -n 1
MemTotal: 30024 kB
~ # iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 6] local 192.168.0.10 port 5001 connected with 192.168.0.101 port 43577
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-50.0 sec 78.0 MBytes 13.1 Mbits/sec
~ # ./netstat -s
Ip:
56596 total packets received
0 forwarded
0 incoming packets discarded
56596 incoming packets delivered
15752 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
0 active connections openings
1 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
56596 segments received
15752 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
0 packets sent
RcvbufErrors: 0
SndbufErrors: 0
UdpLite:
InDatagrams: 0
NoPorts: 0
InErrors: 0
OutDatagrams: 0
RcvbufErrors: 0
SndbufErrors: 0
error parsing /proc/net/snmp: Success
256MB
~ # cat /proc/meminfo | head -n 1
MemTotal: 257212 kB
~ # iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 6] local 192.168.0.10 port 5001 connected with 192.168.0.101 port 46069
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-50.2 sec 19.5 MBytes 3.26 Mbits/sec
~ # ./netstat -s
Ip:
14163 total packets received
0 forwarded
0 incoming packets discarded
14163 incoming packets delivered
5209 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
0 active connections openings
1 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
14163 segments received
5209 segments send out
0 segments retransmited
0 bad segments received.
0 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
0 packets sent
RcvbufErrors: 0
SndbufErrors: 0
UdpLite:
InDatagrams: 0
NoPorts: 0
InErrors: 0
OutDatagrams: 0
RcvbufErrors: 0
SndbufErrors: 0
error parsing /proc/net/snmp: Success
--
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
^ permalink raw reply
* Re: [PATCH] NETLABEL: Fix an RCU warning
From: Paul Moore @ 2010-03-29 15:30 UTC (permalink / raw)
To: paulmck; +Cc: Eric Dumazet, David Howells, netdev
In-Reply-To: <20100329152453.GC2569@linux.vnet.ibm.com>
On Monday 29 March 2010 11:24:53 am Paul E. McKenney wrote:
> On Thu, Mar 25, 2010 at 12:28:04PM +0100, Eric Dumazet wrote:
> > Le jeudi 25 mars 2010 à 11:06 +0000, David Howells a écrit :
> > > Fix an RCU warning in the netlabel code due to missing rcu read locking
> > > around an rcu_dereference() in netlbl_unlhsh_hash() when called from
> > > netlbl_unlhsh_netdev_handler():
> > >
> > > ===================================================
> > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > ---------------------------------------------------
> > > net/netlabel/netlabel_unlabeled.c:246 invoked rcu_dereference_check()
> > > without protection!
> > >
> > > other info that might help us debug this:
> > >
> > >
> > > rcu_scheduler_active = 1, debug_locks = 0
> > >
> > > 2 locks held by ip/5108:
> > > #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff812c4a36>]
> > > rtnl_lock+0x12/0x14 #1: (netlbl_unlhsh_lock){+.+...}, at:
> > > [<ffffffff8134daa4>] netlbl_unlhsh_netdev_handler+0x1e/0x86
> > >
> > > stack backtrace:
> > > Pid: 5108, comm: ip Not tainted 2.6.34-rc2-cachefs #114
> > >
> > > Call Trace:
> > > [<ffffffff8105121f>] lockdep_rcu_dereference+0xaa/0xb2
> > > [<ffffffff8134d781>] netlbl_unlhsh_hash+0x3e/0x50
> > > [<ffffffff8134d7a1>] netlbl_unlhsh_search_iface+0xe/0x84
> > > [<ffffffff8134daaf>] netlbl_unlhsh_netdev_handler+0x29/0x86
> > > [<ffffffff81048362>] notifier_call_chain+0x32/0x5e
> > > [<ffffffff810483fe>] raw_notifier_call_chain+0xf/0x11
> > > [<ffffffff812ba924>] call_netdevice_notifiers+0x16/0x18
> > > [<ffffffff812bac22>] __dev_notify_flags+0x37/0x5b
> > > [<ffffffff812bac8c>] dev_change_flags+0x46/0x52
> > > [<ffffffff812c41af>] do_setlink+0x250/0x3cd
> > > [<ffffffff812c4ee8>] rtnl_newlink+0x2b6/0x49d
> > > [<ffffffff812c4cdd>] ? rtnl_newlink+0xab/0x49d
> > > [<ffffffff812c4c17>] rtnetlink_rcv_msg+0x1b7/0x1d2
> > > [<ffffffff812c4a60>] ? rtnetlink_rcv_msg+0x0/0x1d2
> > > [<ffffffff812cc1dc>] netlink_rcv_skb+0x3e/0x8f
> > > [<ffffffff812c4a59>] rtnetlink_rcv+0x21/0x28
> > > [<ffffffff812cbefe>] netlink_unicast+0x218/0x28f
> > > [<ffffffff812cc76e>] netlink_sendmsg+0x26b/0x27a
> > > [<ffffffff812a9f1d>] sock_sendmsg+0xd4/0xf5
> > > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > > [<ffffffff81096e13>] ? might_fault+0x97/0x9e
> > > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > > [<ffffffff812b4122>] ? verify_iovec+0x59/0x97
> > > [<ffffffff812aa1d9>] sys_sendmsg+0x209/0x273
> > > [<ffffffff810976dc>] ? __do_fault+0x395/0x3cd
> > > [<ffffffff8109928f>] ? handle_mm_fault+0x324/0x69d
> > > [<ffffffff81051e4e>] ? trace_hardirqs_on_caller+0x10c/0x130
> > > [<ffffffff81074972>] ? audit_syscall_entry+0x17d/0x1b0
> > > [<ffffffff81364154>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > > [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
> > >
> > > Signed-off-by: David Howells <dhowells@redhat.com>
> > > ---
> > >
> > > net/netlabel/netlabel_unlabeled.c | 2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/net/netlabel/netlabel_unlabeled.c
> > > b/net/netlabel/netlabel_unlabeled.c index 852d9d7..7ea64e4 100644
> > > --- a/net/netlabel/netlabel_unlabeled.c
> > > +++ b/net/netlabel/netlabel_unlabeled.c
> > > @@ -799,6 +799,7 @@ static int netlbl_unlhsh_netdev_handler(struct
> > > notifier_block *this,
> > >
> > > /* XXX - should this be a check for NETDEV_DOWN or _UNREGISTER? */
> > > if (event == NETDEV_DOWN) {
> > >
> > > + rcu_read_lock();
> > >
> > > spin_lock(&netlbl_unlhsh_lock);
> > > iface = netlbl_unlhsh_search_iface(dev->ifindex);
> > > if (iface != NULL && iface->valid) {
> > >
> > > @@ -807,6 +808,7 @@ static int netlbl_unlhsh_netdev_handler(struct
> > > notifier_block *this,
> > >
> > > } else
> > >
> > > iface = NULL;
> > >
> > > spin_unlock(&netlbl_unlhsh_lock);
> > >
> > > + rcu_read_unlock();
> > >
> > > }
> > >
> > > if (iface != NULL)
> > >
> > > --
> >
> > Sorry this is not the right fix.
> >
> > Fix is to change the dereference check to take into account the lock
> > owned here.
>
> So we need the rcu_dereference() in netlbl_unlhsh_search_iface()
> to become someething like the following?
>
> bkt_list = &rcu_dereference_check(netlbl_unlhsh,
> rcu_read_lock_held() ||
> lockdep_is_held(&netlbl_unlhsh_lock))->tbl[bkt];
>
> Or is this the wrong lock?
As Eric pointed out in response to the message above, I believe the solution
is to simply remove the rcu_dereference() call in the netlbl_unlhsh_hash()
function.
--
paul moore
linux @ hp
^ permalink raw reply
* eth1: Detected Hardware Unit Hang
From: Paweł Staszewski @ 2010-03-29 15:33 UTC (permalink / raw)
To: Linux Network Development list
After update to kernel from 2.6.29.1 to 2.6.33.1 i have this info in dmesg:
0000:05:00.0: eth1: Detected Hardware Unit Hang:
TDH <1e>
TDT <a>
next_to_use <a>
next_to_clean <1d>
buffer_info[next_to_clean]:
time_stamp <33bae15>
next_to_watch <20>
jiffies <33bafaf>
next_to_watch.status <0>
MAC Status <80080783>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
0000:05:00.0: eth1: Detected Hardware Unit Hang:
TDH <1e>
TDT <a>
next_to_use <a>
next_to_clean <1d>
buffer_info[next_to_clean]:
time_stamp <33bae15>
next_to_watch <20>
jiffies <33bb1a3>
next_to_watch.status <0>
MAC Status <80080783>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
0000:05:00.0: eth1: Detected Hardware Unit Hang:
TDH <1e>
TDT <a>
next_to_use <a>
next_to_clean <1d>
buffer_info[next_to_clean]:
time_stamp <33bae15>
next_to_watch <20>
jiffies <33bb397>
next_to_watch.status <0>
MAC Status <80080783>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x118/0x19c()
Hardware name: X7DCT
NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.33.1 #2
Call Trace:
[<c1024e3d>] ? warn_slowpath_common+0x52/0x71
[<c1024e49>] ? warn_slowpath_common+0x5e/0x71
[<c1024e8e>] ? warn_slowpath_fmt+0x26/0x2a
[<c1261f54>] ? dev_watchdog+0x118/0x19c
[<c102135c>] ? __wake_up+0x29/0x39
[<c10320c6>] ? insert_work+0x40/0x44
[<c1261e3c>] ? dev_watchdog+0x0/0x19c
[<c102cc15>] ? run_timer_softirq+0x11a/0x173
[<c1028e5b>] ? __do_softirq+0x74/0xdf
[<c1028ee9>] ? do_softirq+0x23/0x27
[<c10290be>] ? irq_exit+0x26/0x58
[<c10102d7>] ? smp_apic_timer_interrupt+0x6c/0x76
[<c12c5f9a>] ? apic_timer_interrupt+0x2a/0x30
[<c1007e06>] ? mwait_idle+0x49/0x4e
[<c10017e8>] ? cpu_idle+0x41/0x5a
---[ end trace bcca9926a046332c ]---
With kernel 2.6.29.1 all was ok.
^ permalink raw reply
* [PATCH 6/12] drivers/net: Add missing unlock
From: Julia Lawall @ 2010-03-29 15:35 UTC (permalink / raw)
To: netdev, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Unlock the lock before leaving the function.
A simplified version of the semantic patch that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression E1;
identifier f;
@@
f (...) { <+...
* spin_lock_irqsave (E1,...);
... when != E1
* return ...;
...+> }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/sgiseeq.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c
index ed999d3..37f6a00 100644
--- a/drivers/net/sgiseeq.c
+++ b/drivers/net/sgiseeq.c
@@ -592,8 +592,10 @@ static int sgiseeq_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Setup... */
len = skb->len;
if (len < ETH_ZLEN) {
- if (skb_padto(skb, ETH_ZLEN))
+ if (skb_padto(skb, ETH_ZLEN)) {
+ spin_unlock_irqrestore(&sp->tx_lock, flags);
return NETDEV_TX_OK;
+ }
len = ETH_ZLEN;
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6] ipv6: Use __fls() instead of fls() in __ipv6_addr_diff().
From: YOSHIFUJI Hideaki @ 2010-03-29 15:49 UTC (permalink / raw)
To: davem; +Cc: YOSHIFUJI Hideaki, netdev
In-Reply-To: <201003260801.o2Q8134t023352@94.43.138.210.xn.2iij.net>
Sorry, I withdraw this because this is incorrect;
__fls() returns fls() - 1.
--yoshfuji
(2010/03/26 17:01), YOSHIFUJI Hideaki wrote:
> Because we have ensured that the argument is non-zero,
> it is better to use __fls() and generate better code.
>
> Signed-off-by: YOSHIFUJI Hideaki<yoshfuji@linux-ipv6.org>
> ---
> include/net/ipv6.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index e72fb10..619ab34 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -422,7 +422,7 @@ static inline int __ipv6_addr_diff(const void *token1, const void *token2, int a
> for (i = 0; i< addrlen; i++) {
> __be32 xb = a1[i] ^ a2[i];
> if (xb)
> - return i * 32 + 32 - fls(ntohl(xb));
> + return i * 32 + 32 - __fls(ntohl(xb));
> }
>
> /*
^ permalink raw reply
* Re: [PATCH] NETLABEL: Fix an RCU warning
From: Paul E. McKenney @ 2010-03-29 15:58 UTC (permalink / raw)
To: Paul Moore; +Cc: Eric Dumazet, David Howells, netdev
In-Reply-To: <201003291130.10752.paul.moore@hp.com>
On Mon, Mar 29, 2010 at 11:30:10AM -0400, Paul Moore wrote:
> On Monday 29 March 2010 11:24:53 am Paul E. McKenney wrote:
> > On Thu, Mar 25, 2010 at 12:28:04PM +0100, Eric Dumazet wrote:
> > > Le jeudi 25 mars 2010 à 11:06 +0000, David Howells a écrit :
> > > > Fix an RCU warning in the netlabel code due to missing rcu read locking
> > > > around an rcu_dereference() in netlbl_unlhsh_hash() when called from
> > > > netlbl_unlhsh_netdev_handler():
> > > >
> > > > ===================================================
> > > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > ---------------------------------------------------
> > > > net/netlabel/netlabel_unlabeled.c:246 invoked rcu_dereference_check()
> > > > without protection!
> > > >
> > > > other info that might help us debug this:
> > > >
> > > >
> > > > rcu_scheduler_active = 1, debug_locks = 0
> > > >
> > > > 2 locks held by ip/5108:
> > > > #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff812c4a36>]
> > > > rtnl_lock+0x12/0x14 #1: (netlbl_unlhsh_lock){+.+...}, at:
> > > > [<ffffffff8134daa4>] netlbl_unlhsh_netdev_handler+0x1e/0x86
> > > >
> > > > stack backtrace:
> > > > Pid: 5108, comm: ip Not tainted 2.6.34-rc2-cachefs #114
> > > >
> > > > Call Trace:
> > > > [<ffffffff8105121f>] lockdep_rcu_dereference+0xaa/0xb2
> > > > [<ffffffff8134d781>] netlbl_unlhsh_hash+0x3e/0x50
> > > > [<ffffffff8134d7a1>] netlbl_unlhsh_search_iface+0xe/0x84
> > > > [<ffffffff8134daaf>] netlbl_unlhsh_netdev_handler+0x29/0x86
> > > > [<ffffffff81048362>] notifier_call_chain+0x32/0x5e
> > > > [<ffffffff810483fe>] raw_notifier_call_chain+0xf/0x11
> > > > [<ffffffff812ba924>] call_netdevice_notifiers+0x16/0x18
> > > > [<ffffffff812bac22>] __dev_notify_flags+0x37/0x5b
> > > > [<ffffffff812bac8c>] dev_change_flags+0x46/0x52
> > > > [<ffffffff812c41af>] do_setlink+0x250/0x3cd
> > > > [<ffffffff812c4ee8>] rtnl_newlink+0x2b6/0x49d
> > > > [<ffffffff812c4cdd>] ? rtnl_newlink+0xab/0x49d
> > > > [<ffffffff812c4c17>] rtnetlink_rcv_msg+0x1b7/0x1d2
> > > > [<ffffffff812c4a60>] ? rtnetlink_rcv_msg+0x0/0x1d2
> > > > [<ffffffff812cc1dc>] netlink_rcv_skb+0x3e/0x8f
> > > > [<ffffffff812c4a59>] rtnetlink_rcv+0x21/0x28
> > > > [<ffffffff812cbefe>] netlink_unicast+0x218/0x28f
> > > > [<ffffffff812cc76e>] netlink_sendmsg+0x26b/0x27a
> > > > [<ffffffff812a9f1d>] sock_sendmsg+0xd4/0xf5
> > > > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > > > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > > > [<ffffffff81096e13>] ? might_fault+0x97/0x9e
> > > > [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> > > > [<ffffffff812b4122>] ? verify_iovec+0x59/0x97
> > > > [<ffffffff812aa1d9>] sys_sendmsg+0x209/0x273
> > > > [<ffffffff810976dc>] ? __do_fault+0x395/0x3cd
> > > > [<ffffffff8109928f>] ? handle_mm_fault+0x324/0x69d
> > > > [<ffffffff81051e4e>] ? trace_hardirqs_on_caller+0x10c/0x130
> > > > [<ffffffff81074972>] ? audit_syscall_entry+0x17d/0x1b0
> > > > [<ffffffff81364154>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > > > [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
> > > >
> > > > Signed-off-by: David Howells <dhowells@redhat.com>
> > > > ---
> > > >
> > > > net/netlabel/netlabel_unlabeled.c | 2 ++
> > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/net/netlabel/netlabel_unlabeled.c
> > > > b/net/netlabel/netlabel_unlabeled.c index 852d9d7..7ea64e4 100644
> > > > --- a/net/netlabel/netlabel_unlabeled.c
> > > > +++ b/net/netlabel/netlabel_unlabeled.c
> > > > @@ -799,6 +799,7 @@ static int netlbl_unlhsh_netdev_handler(struct
> > > > notifier_block *this,
> > > >
> > > > /* XXX - should this be a check for NETDEV_DOWN or _UNREGISTER? */
> > > > if (event == NETDEV_DOWN) {
> > > >
> > > > + rcu_read_lock();
> > > >
> > > > spin_lock(&netlbl_unlhsh_lock);
> > > > iface = netlbl_unlhsh_search_iface(dev->ifindex);
> > > > if (iface != NULL && iface->valid) {
> > > >
> > > > @@ -807,6 +808,7 @@ static int netlbl_unlhsh_netdev_handler(struct
> > > > notifier_block *this,
> > > >
> > > > } else
> > > >
> > > > iface = NULL;
> > > >
> > > > spin_unlock(&netlbl_unlhsh_lock);
> > > >
> > > > + rcu_read_unlock();
> > > >
> > > > }
> > > >
> > > > if (iface != NULL)
> > > >
> > > > --
> > >
> > > Sorry this is not the right fix.
> > >
> > > Fix is to change the dereference check to take into account the lock
> > > owned here.
> >
> > So we need the rcu_dereference() in netlbl_unlhsh_search_iface()
> > to become someething like the following?
> >
> > bkt_list = &rcu_dereference_check(netlbl_unlhsh,
> > rcu_read_lock_held() ||
> > lockdep_is_held(&netlbl_unlhsh_lock))->tbl[bkt];
> >
> > Or is this the wrong lock?
>
> As Eric pointed out in response to the message above, I believe the solution
> is to simply remove the rcu_dereference() call in the netlbl_unlhsh_hash()
> function.
It would be at the moment, but this will break once Arnd Bergmann gets
his sparse-based checks done. With these checks, we decorate RCU-protected
pointers, and then sparse yells if you access such a pointer without the
proper rcu_dereference() invocation.
Thanx, Paul
^ permalink raw reply
* [PATCH] r8169: offical fix for CVE-2009-4537 (overlength frame DMAs)
From: Neil Horman @ 2010-03-29 16:03 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: michael.s.gilbert, davem, nhorman, romieu, eric.dumazet
Official patch to fix the r8169 frame length check error.
Based on this initial thread:
http://marc.info/?l=linux-netdev&m=126202972828626&w=1
This is the official patch to fix the frame length problems in the r8169
driver. As noted in the previous thread, while this patch incurs a performance
hit on the driver, its possible to improve performance dynamically by updating
the mtu and rx_copybreak values at runtime to return performance to what it was
for those NICS which are unaffected by the ideosyncracy (if there are any).
Summary:
A while back Eric submitted a patch for r8169 in which the proper
allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too
much data. This was done in commit fdd7b4c3302c93f6833e338903ea77245eb510b4. A
long time prior to that however, Francois posted
126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the MaxSize
setting due to the fact that the hardware behaved in odd ways when overlong
frames were received on NIC's supported by this driver. This was mentioned in a
security conference recently:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html
It seems that if we can't enable frame size filtering, then, as Eric correctly
noticed, we can find ourselves DMA-ing too much data to a buffer, causing
corruption. As a result is seems that we are forced to allocate a frame which
is ready to handle a maximally sized receive.
This obviously has performance issues with it, so to mitigate that issue, this
patch does two things:
1) Raises the copybreak value to the frame allocation size, which should force
appropriately sized packets to get allocated on rx, rather than a full new 16k
buffer.
2) This patch only disables frame filtering initially (i.e., during the NIC
open), changing the MTU results in ring buffer allocation of a size in relation
to the new mtu (along with a warning indicating that this is dangerous).
Because of item (2), individuals who can't cope with the performance hit (or can
otherwise filter frames to prevent the bug), or who have hardware they are sure
is unaffected by this issue, can manually lower the copybreak and reset the mtu
such that performance is restored easily.
Signed-off-by: Neil Horman <nhorman@redhat.com>
r8169.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 964305c..1db95d4 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -187,7 +187,12 @@ static DEFINE_PCI_DEVICE_TABLE(rtl8169_pci_tbl) = {
MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl);
-static int rx_copybreak = 200;
+/*
+ * we set our copybreak very high so that we don't have
+ * to allocate 16k frames all the time (see note in
+ * rtl8169_open()
+ */
+static int rx_copybreak = 16383;
static int use_dac = -1;
static struct {
u32 msg_enable;
@@ -3254,9 +3259,13 @@ static void __devexit rtl8169_remove_one(struct pci_dev *pdev)
}
static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
- struct net_device *dev)
+ unsigned int mtu)
{
- unsigned int max_frame = dev->mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
+ unsigned int max_frame = mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
+
+ if (max_frame != 16383)
+ printk(KERN_WARNING "WARNING! Changing of MTU on this NIC"
+ "May lead to frame reception errors!\n");
tp->rx_buf_sz = (max_frame > RX_BUF_SIZE) ? max_frame : RX_BUF_SIZE;
}
@@ -3269,7 +3278,17 @@ static int rtl8169_open(struct net_device *dev)
pm_runtime_get_sync(&pdev->dev);
- rtl8169_set_rxbufsize(tp, dev);
+ /*
+ * Note that we use a magic value here, its wierd I know
+ * its done because, some subset of rtl8169 hardware suffers from
+ * a problem in which frames received that are longer than
+ * the size set in RxMaxSize register return garbage sizes
+ * when received. To avoid this we need to turn off filtering,
+ * which is done by setting a value of 16383 in the RxMaxSize register
+ * and allocating 16k frames to handle the largest possible rx value
+ * thats what the magic math below does.
+ */
+ rtl8169_set_rxbufsize(tp, 16383 - VLAN_ETH_HLEN - ETH_FCS_LEN);
/*
* Rx and Tx desscriptors needs 256 bytes alignment.
@@ -3929,7 +3948,7 @@ static int rtl8169_change_mtu(struct net_device *dev, int new_mtu)
rtl8169_down(dev);
- rtl8169_set_rxbufsize(tp, dev);
+ rtl8169_set_rxbufsize(tp, dev->mtu);
ret = rtl8169_init_ring(dev);
if (ret < 0)
^ permalink raw reply related
* [PATCH net-next-2.6 (TAKE 2)] ipv6: Use __fls() instead of fls() in __ipv6_addr_diff().
From: YOSHIFUJI Hideaki @ 2010-03-29 16:00 UTC (permalink / raw)
To: davem; +Cc: yoshfuji, netdev
Because we have ensured that the argument is non-zero,
it is better to use __fls() and generate better code.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
include/net/ipv6.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index e72fb10..033ddd4 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -422,7 +422,7 @@ static inline int __ipv6_addr_diff(const void *token1, const void *token2, int a
for (i = 0; i < addrlen; i++) {
__be32 xb = a1[i] ^ a2[i];
if (xb)
- return i * 32 + 32 - fls(ntohl(xb));
+ return i * 32 + 31 - __fls(ntohl(xb));
}
/*
--
1.5.6.5
^ permalink raw reply related
* Re: [patch] iwlwifi: range checking issue
From: reinette chatre @ 2010-03-29 16:13 UTC (permalink / raw)
To: Zhu, Yi
Cc: Dan Carpenter, Intel Linux Wireless, John W. Linville,
Kolekar, Abhijeet, Berg, Johannes, Guy, Wey-Yi W,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <1269828072.4043.247.camel@debian>
On Sun, 2010-03-28 at 19:01 -0700, Zhu, Yi wrote:
> On Sun, 2010-03-28 at 19:55 +0800, Dan Carpenter wrote:
> > IWL_RATE_COUNT is 13 and IWL_RATE_COUNT_LEGACY is 12.
> >
> > IWL_RATE_COUNT_LEGACY is the right one here because iwl3945_rates
> > doesn't support 60M and also that's how "rates" is defined in
> > iwlcore_init_geos() from drivers/net/wireless/iwlwifi/iwl-core.c.
> >
> > rates = kzalloc((sizeof(struct ieee80211_rate) * IWL_RATE_COUNT_LEGACY),
> > GFP_KERNEL);
> >
> > Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> Acked-by: Zhu Yi <yi.zhu@intel.com>
Great catch. Since this is a fix for a buffer overflow ... could you
please pass it on to stable also?
Thank you
Reinette
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Chris Friesen @ 2010-03-29 16:18 UTC (permalink / raw)
To: Brandon Black; +Cc: Arnaldo Carvalho de Melo, linux-kernel, netdev
In-Reply-To: <84621a61003270619p6b4fe81bi24bb1961aba77ffb@mail.gmail.com>
On 03/27/2010 07:19 AM, Brandon Black wrote:
> I've been playing with the timeout argument to recvmmsg as well now,
> and I'm struggling to see how one would ever use it correctly with the
> current implementation.
I'd probably do something like this:
prev = current time
loop forever
cur = current time
timeout = max_latency - (cur - prev)
recvmmsg(timeout)
process all received messages
prev = cur
Basically you determine the max latency you're willing to wait for a
packet to be handled, then subtract the amount of time you spent
processing messages from that and pass it into the recvmmsg() call as
the timeout. That way no messages will be delayed for longer than the
max latency. (Not considering scheduling delays.)
Chris
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/3] bridge br_multicast: Make functions less ipv4 dependent.
From: Stephen Hemminger @ 2010-03-29 16:12 UTC (permalink / raw)
To: YOSHIFUJI Hideaki, davem; +Cc: netdev
In-Reply-To: <201003291101.o2TB1R0W006599@94.43.138.210.xn.2iij.net>
On Mon, 29 Mar 2010 20:01:27 +0900
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:
> Introduce struct br_ip{} to store ip address and protocol
> and make functions more generic so that we can support
> both IPv4 and IPv6 with less pain.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> ---
> net/bridge/br_multicast.c | 181 +++++++++++++++++++++++++++++++--------------
> net/bridge/br_private.h | 12 +++-
> 2 files changed, 135 insertions(+), 58 deletions(-)
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 9f0c4f0..5338574 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -27,48 +27,86 @@
>
> #include "br_private.h"
>
> -static inline int br_ip_hash(struct net_bridge_mdb_htable *mdb, __be32 ip)
> +#define IP4_BRIP(ip) (struct br_ip) { \
> + .u.ip4 = ip, \
> + .proto = htons(ETH_P_IP), \
> + }
> +
Too messy with macros, I will fix.
--
^ permalink raw reply
* Re: eth1: Detected Hardware Unit Hang
From: Allan, Bruce W @ 2010-03-29 16:41 UTC (permalink / raw)
To: Paweł Staszewski, Linux Network Development list
Cc: e1000-devel@lists.sourceforge.net
In-Reply-To: <4BB0C853.2080607@itcare.pl>
[adding e1000-devel]
Please provide more information:
* what NIC/LOM is this on (preferably send full output from lspci -vvv)
* what type of networking workload is running at the time the hang occurred
* a dump of the NIC/LOM statistics might also help (ethtool -S eth1)
Have you tried the latest standalone e1000e driver on e1000.sf.net? Does it reproduce the issue?
If we cannot reproduce the hang in-house, would you be able/willing to run a debug driver to gather more information?
Thanks,
Bruce.
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Pawel Staszewski
Sent: Monday, March 29, 2010 8:34 AM
To: Linux Network Development list
Subject: eth1: Detected Hardware Unit Hang
After update to kernel from 2.6.29.1 to 2.6.33.1 i have this info in dmesg:
0000:05:00.0: eth1: Detected Hardware Unit Hang:
TDH <1e>
TDT <a>
next_to_use <a>
next_to_clean <1d>
buffer_info[next_to_clean]:
time_stamp <33bae15>
next_to_watch <20>
jiffies <33bafaf>
next_to_watch.status <0>
MAC Status <80080783>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
0000:05:00.0: eth1: Detected Hardware Unit Hang:
TDH <1e>
TDT <a>
next_to_use <a>
next_to_clean <1d>
buffer_info[next_to_clean]:
time_stamp <33bae15>
next_to_watch <20>
jiffies <33bb1a3>
next_to_watch.status <0>
MAC Status <80080783>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
0000:05:00.0: eth1: Detected Hardware Unit Hang:
TDH <1e>
TDT <a>
next_to_use <a>
next_to_clean <1d>
buffer_info[next_to_clean]:
time_stamp <33bae15>
next_to_watch <20>
jiffies <33bb397>
next_to_watch.status <0>
MAC Status <80080783>
PHY Status <796d>
PHY 1000BASE-T Status <3800>
PHY Extended Status <3000>
PCI Status <10>
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x118/0x19c()
Hardware name: X7DCT
NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.33.1 #2
Call Trace:
[<c1024e3d>] ? warn_slowpath_common+0x52/0x71
[<c1024e49>] ? warn_slowpath_common+0x5e/0x71
[<c1024e8e>] ? warn_slowpath_fmt+0x26/0x2a
[<c1261f54>] ? dev_watchdog+0x118/0x19c
[<c102135c>] ? __wake_up+0x29/0x39
[<c10320c6>] ? insert_work+0x40/0x44
[<c1261e3c>] ? dev_watchdog+0x0/0x19c
[<c102cc15>] ? run_timer_softirq+0x11a/0x173
[<c1028e5b>] ? __do_softirq+0x74/0xdf
[<c1028ee9>] ? do_softirq+0x23/0x27
[<c10290be>] ? irq_exit+0x26/0x58
[<c10102d7>] ? smp_apic_timer_interrupt+0x6c/0x76
[<c12c5f9a>] ? apic_timer_interrupt+0x2a/0x30
[<c1007e06>] ? mwait_idle+0x49/0x4e
[<c10017e8>] ? cpu_idle+0x41/0x5a
---[ end trace bcca9926a046332c ]---
With kernel 2.6.29.1 all was ok.
--
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
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Network performance - iperf
From: Rick Jones @ 2010-03-29 16:47 UTC (permalink / raw)
To: michal.simek
Cc: LKML, John Williams, netdev, Grant Likely, John Linn,
Steven J. Magnani, Arnd Bergmann, akpm
In-Reply-To: <4BB09021.6020202@petalogix.com>
I don't know how to set fixed socket buffer sizes in iperf, if you were running
netperf though I would suggest fixing the socket buffer sizes with the
test-specific -s (affects local) and -S (affects remote) options:
netperf -t TCP_STREAM -H <remote> -l 30 -- -s 32K -S 32K -m 32K
to test the hypothesis that the autotuning of the socket buffers/window size is
allowing the windows to grow in the larger memory cases beyond what the TLB in
your processor is comfortable with.
Particularly if you didn't see much degredation as RAM is increased on something
like:
netperf -t TCP_RR -H <remote> -l 30 -- -r 1
which is a simple request/response test that will never try to have more than
one packet in flight at a time, regardless of how large the window gets.
happy benchmarking,
rick jones
http://www.netperf.org/
^ permalink raw reply
* Re: Network performance - iperf
From: Rick Jones @ 2010-03-29 16:57 UTC (permalink / raw)
To: michal.simek
Cc: LKML, John Williams, netdev, Grant Likely, John Linn,
Steven J. Magnani, Arnd Bergmann, akpm
In-Reply-To: <4BB0D9A1.3090107@hp.com>
Rick Jones wrote:
> I don't know how to set fixed socket buffer sizes in iperf, if you were
> running netperf though I would suggest fixing the socket buffer sizes
> with the test-specific -s (affects local) and -S (affects remote) options:
>
> netperf -t TCP_STREAM -H <remote> -l 30 -- -s 32K -S 32K -m 32K
>
> to test the hypothesis that the autotuning of the socket buffers/window
> size is allowing the windows to grow in the larger memory cases beyond
> what the TLB in your processor is comfortable with.
BTW, by default, netperf will allocate a "ring" of send buffers - the number
allocated will be one more than the socket buffer size divided by the send size
- so in the example above, there will be two 32KB buffers allocated in netperf's
send ring. A similar calculation may happen on the receive side.
That can be controlled via the global (before the "--") -W option.
-W send,recv Set the number of send,recv buffers
So, you might make the netperf command:
netperf -t TCP_STREAM -H <remote> -l 30 -W 1,1 -- -s 32K -S 32K -m 32K
happy benchmarking,
rick jones
^ permalink raw reply
* [PATCH 0/3] add support for Janz MODULbus devices
From: Ira W. Snyder @ 2010-03-29 16:58 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, sameo-VuQAYsv1563Yd54FQh9/CA
This patch series adds support for the Janz CMOD-IO carrier board, as well
as the Janz VMOD-ICAN3 Intelligent CAN controller and the Janz VMOD-TTL
Digital IO controller. The CMOD-IO carrier board is a PCI to MODULbus
bridge, into which plug MODULbus daughterboards. I only have access to two
types of daughtercards, the VMOD-ICAN3 and VMOD-TTL boards mentioned above.
The CAN driver has been tested under high loads. I am able to generate ~60%
bus utilization. With two VMOD-ICAN3 boards looped back to each other,
neither one loses any packets when only a single board is generating
packets at maximum speed. Once both boards start generating packets, one
board will sometimes loose arbitration, and cause some lost packets.
After much review from the last posting of the series, I believe that this
should be ready for mainline. Many thanks to everyone that helped!
RFCv4 -> RFCv5:
- removed some dev_dbg() statements
- change default MODULbus modules to "none"
- accept both "empty" and "" in the MODULbus modules parameter
- print an error message when no MODULbus modules are specified
- add sysfs support to get/set CAN bus termination
- fix error-active and error-passive state reporting
- add support for netlink bus-error messages
- fixed sparse warnings
- used mfd-core API for multifunction device probing
RFCv3 -> RFCv4:
- addressed many review comments
- switch to NAPI
- add TX flow control
- mark functions with __devinit and __devexit
- add sysfs readout of MODULbus number (hex switch)
- implement GPIO driver for VMOD-TTL
RFCv2 -> RFCv3:
- addressed many review comments
- correct CAN bus error handling
- use struct device to track subdevices
- use structures for register layout
- add lots of #defines for register values
- use better function prefixes
RFCv1 -> RFCv2:
- converted to a multi-driver model
- addressed many review comments
- added CAN bus error handling
- use a work function only instead of work + NAPI
- use SJA1000 bittiming calculation code
Thanks,
Ira
^ 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