I posted it again with the usual stuff a day or two after I posted the test patch; I'll append it to the end of this email. Note that the below patch has a minor cosmetic change from the test patch. I believe this fix should go to -stable for 2.6.26 and 2.6.27, but it'll need the change Jesper added to pick up a macro that was added to mainline: diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h index fb730ec..b1315e4 100644 --- ...

I must be tired, I should had this idea before you :) I post a new patch after some rest, I definitly should not be still awake ! --

From: Eric Dumazet <dada1@cosmosbay.com> I don't understand why you need the mutual exclusion in the first place. The function pointer always has the same value. And this locking isn't protecting the list insertion either, as that isn't even necessary. You're using this in UDP so... make the rule that you can't use Why? You run this from softirq safe context, nothing can run other softirqs on this cpu and corrupt the list, therefore. --

From: Sascha Hlusiak <mail@saschahlusiak.de> Let's ask the ISATAP author the intent of the situation. CC:'d Fred? --

From: Roel Kluin <roel.kluin@gmail.com> Applied, thanks. --

From: gabriele.paoloni@intel.com Looks good, applied. --

From: Neil Horman <nhorman@tuxdriver.com> Applied. --

From: Neil Horman <nhorman@tuxdriver.com> Applied. --

From: Steve Glendinning <steve.glendinning@smsc.com> Applied to net-next-2.6 --

From: Grant Grundler <grundler@parisc-linux.org> Applied to net-next-2.6, thanks everyone. --

From: Patrick McHardy <kaber@trash.net> Applied to net-next-2.6 --

From: Jean Delvare <khali@linux-fr.org> Applied, thanks. --

Dave, Thanks for the reply. Yes, it is very stable and will submit it against net 2.6. Thanks, --

Can you apply the attached patch and see if it fixes any of these problems ? Tim, could you give it a try too ? It applies with "patch -p1" from the kernel tree directory. -- Ueimor

From: Lennert Buytenhek <buytenh@wantstofly.org> Applied, thanks Lennert! --

From: Andy Fleming <afleming@freescale.com> Applied. --

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Ok, since you asked nicely :-) --

Christian <cjs@dhp.com> : Can you reproduce the bug when nvidia's module is not loaded after boot ? -- Ueimor --

Ok, thanks, so you have a place to store user space images. This thread got me wondering what you were going to do long term about user space. I was starting to think as a space saving measure, that you were building your app into the kernel or something. FWIW, I think Uboot has a pretty robust mtd infrastructure that would allow you to store a initramfs image there for use if you were interested in exploring that route. Neil --

Sure, you'll find my mkduprd script in the kexec-tools package for fedora, you're welcome to tear it up to suit your needs. By way of precaution, I'll tell you that the script is much larger than it needs to be, since its purpose is to copy a vmcore to several various locations. In short summary, all you need to make an initramfs is: 1) create a rootfs directory tree somewhere, call it $INITRD_ROOT 2) populate the initrd with any applications you need for your purpose 3) create an ...

That's maybe the right solution for big machines, but for small embedded systems it's absolutely overkill. We have used Linux on several ten ARM and PowerPC boards, and the only reason we ever needed an initrd was on an IXP425 who needed a strange firmware which had a license. Embedded boxes are often short on RAM, so wasting megabytes of space on a box that maybe has 8...16 MB RAM just because of a mac address doesn't sound like a good solution. rsc -- Pengutronix e.K. ...

From: Tom Herbert <therbert@google.com> I never understood this. If you don't let the APIC move the interrupt around, the individual MSI-X interrupts will steer packets to individual specific CPUS and as a result the scheduler will migrate tasks over to those cpus since the wakeup events keep occuring there. --

We are trying to follow the decisions scheduler as opposed to leading it. This works on very loaded systems, with applications binding to cpusets, with threads that are receiving on multiple sockets. I suppose it might be compelling if a NIC could steer packets per flow, instead of by a hash... --

On Fri, 13 Mar 2009 22:10:59 +0000 The problem is that without hardware support, handing off the packet may take more effort than processing it. Especially when cache line has to bounce to other CPU and trying to keep up with DoS attacks. It all depends how much processing is required, and the architecture of the system. The tradeoff would change over time based on processing speed and optimizing the receive/firewall code. --

Oh, I didn't know the background. I need study more about network. I agree. I double checked the latest codes of tree net-next-2.6 and function skb_tx_hash Yes when NIC is free mostly. When NIC is busy, it wouldn't enter power-saving mode. I guess NIC might allocate resources evenly for all queues, at least by default. If considering packet sending burst with the same SRC/DST, a specific queue might be full quickly. I instrumented driver and kernel to print out packet receiving and forwarding. As ...

From: Pavel Roskin <proski@gnu.org> Applied. Please provide a proper "Signed-off-by: xxx" line in future patch submissions or else I will just toss the patch back to you. Thanks. --

From: Francois Romieu <romieu@fr.zoreil.com> Sure. --

From: Eric Dumazet <dada1@cosmosbay.com> Right, I'll add Dave's patch, but using max_t() here. Thanks everyone. --

Whilst looking for other instances of the bug that was in velocity, I noticed a few possible cleanups in a2065. I don't have this hardware, so extra review appreciated. Dave --- Remove unnecessary check (skb_padto does the same check) Remove unnecessary duplicate variable Remove unnecessary clearing of padded part of skb. Signed-off-by: Dave Jones <davej@redhat.com> diff --git a/drivers/net/a2065.c b/drivers/net/a2065.c index 7a60bdd..d0d0c2f 100644 --- a/drivers/net/a2065.c +++ ...

From: Rusty Russell <rusty@rustcorp.com.au> You can set netif_carrier_on() until you are blue in the face, but until you hook up the ethtool link indication operation NetworkManager won't see it. I don't understand what all of this hob-knobbing is about, Pantelis's patch was perfect, appropriate, and should have gone straight in to net-2.6 and probably -stable too. Is this some kind of control issue Rusty? It's the only explanation I can come up with :-)) --

From: "Jan-Bernd Themann" <ossthema@de.ibm.com> Applied, thanks. --

Great, thanks for taking a look. -- paul moore linux @ hp --

From: Jiri Pirko <jpirko@redhat.com> Applied to net-next-2.6 --

The existing code is correct, and works. How about just leaving it alone? You can grep around and see other drivers doing this when necessary, too. Jeff --

--

Hi Alexander, ... Thanks, I'll fix these up and re-submit... Arthur --

The sum of £750,000,00 GBP has been Awarded to your E-MAIL ID,Get back to us with your info via (siemens11@btinternet.com) Names : Address: Conntry : Occupation : Age : Mrs Mercy Bill (Information Officer) --

The sum of £750,000,00 GBP has been Awarded to your E-MAIL ID,Get back to us with your info via (siemens11@btinternet.com) Names : Address: Conntry : Occupation : Age : Mrs Mercy Bill (Information Officer) --

From: Divy Le Ray <divy@chelsio.com> update driver version to 1.1.1-ko Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/version.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h index 6f6c30c..7bf963e 100644 --- a/drivers/net/cxgb3/version.h +++ b/drivers/net/cxgb3/version.h @@ -35,7 +35,7 @@ #define DRV_DESC "Chelsio T3 Network Driver" #define DRV_NAME "cxgb3" /* Driver version ...

From: Divy Le Ray <divy@chelsio.com> Update skb truesize correctly for the 2nd buffer from a Jumbo frame Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/sge.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c index 808b8af..90f6f82 100644 --- a/drivers/net/cxgb3/sge.c +++ b/drivers/net/cxgb3/sge.c @@ -830,14 +830,15 @@ recycle: len - SGE_RX_PULL_LEN); newskb->len = len; ...

From: Divy Le Ray <divy@chelsio.com> Update the heurstics workaround unlocking a hung mac: - reduce Tx mac toggling by enabling Tx drain before resetting the mac - Take Tx (lack of) activity in account only - Update the monitoring counter range to 64 bits Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/xgmac.c | 72 +++++++++++++++++++++------------------------ 1 files changed, 33 insertions(+), 39 deletions(-) diff --git a/drivers/net/cxgb3/xgmac.c ...

From: Divy Le Ray <divy@chelsio.com> The driver currently ignores the local or remote link faults raised at the mac layer. This patch fixes it. Our mac however only advertizes link events, so wait for the phy to stabilize the link, then enable mac link events interrupts. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/adapter.h | 5 + drivers/net/cxgb3/common.h | 6 ++ drivers/net/cxgb3/cxgb3_main.c | 123 ++++++++++++++++++++++++++++++++++++- ...

From: Divy Le Ray <divy@chelsio.com> Update FW to 7.1 Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/version.h | 2 firmware/Makefile | 2 firmware/WHENCE | 2 firmware/cxgb3/t3fw-7.0.0.bin.ihex | 1881 ------------------------------------ firmware/cxgb3/t3fw-7.1.0.bin.ihex | 1885 ++++++++++++++++++++++++++++++++++++ 5 files changed, 1888 insertions(+), 1884 deletions(-) diff --git ...

From: Divy Le Ray <divy@chelsio.com> All applied, thanks Divy.

I found the Bug. There was no rule for my chain <lan-in> and <lan-out>, because i inserted the rule at the wrong place ! ########################################################### iptables -I lan-in 2 -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT iptables -I lan-out 2 -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT ########################################################### It should be inserted at line 1. Regards Markus --

Next Bug, but this one should refer to the kernel i think: This one works not. --> <http://nopaste.debianforum.de/19665> But this one works not --> <http://nopaste.debianforum.de/19664> I worked out the syslog messages and the differences: In the not working configuration i used <NOARP> for eth0. I don't know why, but i think it come from ppp0 which uses it: ######################################################################## iface dsl-provider inet ppp pre-up /sbin/ifconfig eth0 up ...

From: "Tantilov, Emil S" <emil.s.tantilov@intel.com> Thanks for testing. Herbert, want me to toss this into net-2.6 now? --

No, the bug only exists in net-next-2.6 :) 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 --

Aha... you probably want to add a post-down /sbin/ifconfig eth0 arp So that the next time you configure eth0, it will be able to arps again. --

skb->dev can be NULL on ip_frag_reasm for skb's coming from RAW sockets. Quagga's OSPFD sends fragmented packets on a RAW socket, when netfilter conntrack reassembles them on the OUTPUT path you hit this code path. Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net> --- net/ipv4/ip_fragment.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c index 6659ac0..8f150d5 100644 --- ...

dev can be NULL on ip_frag_reasm for skb's coming from RAW sockets. Quagga's OSPFD sends fragmented packets on a RAW socket, when netfilter conntrack reassembles them on the OUTPUT path you hit this code path. Changes from v1: - Fixed description Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net> --- net/ipv4/ip_fragment.c | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c index 6659ac0..8f150d5 ...

From: Jiri Pirko <jpirko@redhat.com> Also applied, thanks. --

I have selected build-firmware-into-kernel but it seems e100 is still unhappy in 2.6.29-rc7. e100 0000:02:01.0: firmware: requesting e100/d102e_ucode.bin e100: eth4: e100_request_firmware: Failed to load firmware "e100/d102e_ucode.bin": -2 Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com --

From: Tom Herbert <therbert@google.com> ^^^^^^^^ Do these NICs at least support multiqueue? --

I appreciate this philosophy, but unfortunately I don't have the luxury of working with a NIC that solves these problems. The reality may be that we're trying to squeeze performance out of crappy hardware to scale on multi-core. Left alone we couldn't get the stack to scale, but with these "destable hacks" we've gotten 3X or so improvement in packets per second across both our dumb 1G and 10G NICs. These gains have translated into tangible application performance gains, so we'll probably ...

Applied, thanks. --