All, Intel is pleased to release the 82598 10GbE PCI Express MAC Software Development Manual to the open source community. The document is available from both the www.intel.com website (search for '82598') and our http://e1000.sf.net/ project website. (quick doc link: http://tinyurl.com/4yc5l5 ) 82598 Drivers are currently available in the linux kernel and as a standalone (ixgbe) driver from our project page. This new MAC supports various new technologies that people may find interesting, some ...

Late acking of IRQ events will reduce number of interrupts that needs to be served. Makes the system somewhat responsive during a ping -f -l 10 Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- drivers/net/ucc_geth.c | 36 ++++++++++++++++++++++-------------- drivers/net/ucc_geth.h | 4 ++-- 2 files changed, 24 insertions(+), 16 deletions(-) diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index 28431aa..c6bf4d3 100644 --- a/drivers/net/ucc_geth.c ...

Congratulations. I'm sure it was a lot of work. But could you please quickly expand how useful it is at this state? Is it already far enough that someone could save some data on it and use it without it crashing all the time? It's unclear even from your status report. -Andi --

There are functions to refer to the value of dst->metric[THE_METRIC-1] directly without use of a inline function "dst_metric" defined in net/dst.h. The following patch changes them to use the inline function consistently. Signed-off-by: Satoru SATOH <satoru.satoh@gmail.com> net/decnet/dn_route.c | 4 ++-- net/ipv4/route.c | 2 +- net/ipv4/tcp_input.c | 15 ++++++++------- 3 files changed, 11 insertions(+), 10 deletions(-) diff --git a/net/decnet/dn_route.c b/net/decne...

Thanks very much for catching this, Pavel! --

Patch from Ville Skytt

Украинские экспортно-импортные базы за 2005/2006/2007/2008 года. Более подробная информация в переписке: retrewasder@gmail.com як молоденький чорт, із пекла випущений. Де не повернеться — всюди за ним золоте гілля рос...

From: Pavel Emelyanov <xemul@openvz.org> I gues you're not a real kernel programmer unless you've made this mistake at least once :-) It kind of prove this is a bad interface, since it's so easy to use incorrectly. This was already caught in a tcp_probe fix I applied earlier today, so I removed that part. The rest is applied and I'll queue for -stable, thanks Pavel. --

Please pull from 'upstream-davem' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem to receive the following updates: Documentation/networking/phy.txt | 38 +++- drivers/net/arm/at91_ether.c | 1 + drivers/net/arm/ep93xx_eth.c | 2 + drivers/net/atlx/atl1.c | 138 ++++++++++++ drivers/net/atlx/atlx.c | 177 --------------- drivers/net/ax88796.c | 1 + drivers/net/bfin_mac.c | ...

In commit ba749ae98d5aa9d2ce9a7facde0deed454f92230 ([XFRM]: alg_key_len should be unsigned to avoid integer divides <http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=ba749ae98d5aa9d2ce9a7facde0deed454f92230>) alg_key_len field of struct xfrm_algo was converted to unsigned int to avoid integer divides. Then Herbert in commit 1a6509d991225ad210de54c63314fd9542922095 ([IPSEC]: Add support for combined mode algorithms) added a new structure xfrm_algo_aead, that re...

From: Herbert Xu <herbert@gondor.apana.org.au> Applied, thanks everyone. --

[fixed cc and subject] sendmsg should just be a little smarter on when to block depending on the state of the interface. There is already some minor code for tnat as you'll have noted. Then the bursts would be much less of a problem. We already had this discussion recently together with better behaviour on bounding. The only big problem then would be if there are more submitting threads than packets in the TX queue, but I would consider that unlikely for It doesn't need to be. Unlike a tru...

In that case we might be better off just blocking some of these threads until the TX queue cleared? What good is it to send faster than the network allows? -Andi --

If NIC is interrupt driven, enough data must be queued to span consecutive interrupts. So for instance if a 10G NIC is generating an interrupt every 100us, about 125,000 bytes needs to queued at each interrupt to prevent starvation-- this doesn't translate to a fixed number of packets. Limiting by packets seems somewhat ad hoc; if the limit is to small and the link will be starved, too big and --

Fix the following sparse warning : drivers/net/tg3.c:4025:3: warning: context imbalance in 'tg3_restart_hw' - unexpected unlock Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>

we are happy to announce to that you won the sum of $2,000,000.00 from our monthly FREELOTTO PROMOTION PROGRAM,you are advice to get back to us, to claim your prize.Contact Richard Smith E-mail:contactrichardsmith01@btinternet.com --

Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/net/bfin_mac.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 47 insertions(+), 0 deletions(-) diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c index fdd361c..8762b96 100644 --- a/drivers/net/bfin_mac.c +++ b/drivers/net/bfin_mac.c @@ -27,6 +27,7 @@ #include <linux/phy.h> #include <linux/netdevice.h> #include <linux/etherdevice.h> +#include <linux/ethtool.h> #incl...

net/key/af_key.c: In function

In the ethtool user-space application, tg3 and natsemi over-ride the default implementation of dump_eeprom(). In both tg3_dump_eeprom() and natsemi_dump_eeprom(), there is a magic number check which is not present in the default implementation. Commit b131dd5d snipped the code which copied the ethtool_eeprom structure back to user-space. tg3 and natsemi are over-writing the magic number field and then checking it in user-space. With the ethtool_eeprom copy removed, the check is failing. The fix ...

applied --

Hi. What about sigset there too? -- Evgeniy Polyakov --

Actually I hadn't thought about the sigset at all. Alan -- "I work for a government agency so please forgive me for not having the latest version of the kernel." -- Ryan Clayburn --

From: Ulrich Drepper <drepper@redhat.com> It's perfectly acceptable to change the interface however you like when necessary, and merely fix up all the in-tree users. --

Well, first possible error path: tcp_v6_do_rcv()->tcp_rcv_established(), the latter goes to step5, where eventually skb can be freed via tcp_data_queue() (drop: label), then if check for tcp_defer_accept_check() returns true and thus tcp_rcv_established() returns -1, which forces tcp_v6_do_rcv() to jump to reset: label, which in turn will pass through discard: label and free I will work on this this weekend, thank you. -- Evgeniy Polyakov --

Please revert, the change is wrong as described in my other mail. Maciej --