[PATCH 6/6 revised] bnx2: Update version

Update version to 1.4.37. Add missing flush_scheduled_work() in bnx2_suspend as noted by Jeff Garzik. Signed-off-by: Michael Chan <[EMAIL PROTECTED]> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c index ee9f58f..630281b 100644 --- a/drivers/net/bnx2.c +++ b/drivers/net/bnx2.c @@ -14,8 +14

[PATCH 5/6 revised] bnx2: Support larger rx ring sizes (part 2)

Support bigger rx ring sizes (up to 1020) in the rx fast path. Signed-off-by: Michael Chan <[EMAIL PROTECTED]> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c index fbe7a14..3fbf414 100644 --- a/drivers/net/bnx2.c +++ b/drivers/net/bnx2.c @@ -1687,8 +1687,8 @@ bnx2_reuse_rx_skb(struct bnx2

[PATCH 4/6 revised] bnx2: Support larger rx ring sizes (part 1)

Increase maximum receive ring size from 255 to 1020 by supporting up to 4 linked pages of receive descriptors. To accomodate the higher memory usage, each physical descriptor page is allocated separately and the software ring that keeps track of the SKBs and the DMA addresses is allocated using vma

[PATCH 3/6 revised] bnx2: Fix bug when rx ring is full

Fix the rx code path that does not handle the full rx ring correctly. When the rx ring is set to the max. size (i.e. 255), the consumer and producer indices will be the same when completing an rx packet. Fix the rx code to handle this condition properly. Signed-off-by: Michael Chan <[EMAIL PROTEC

Re: [PATCH 3/4] bnx2: Support larger rx ring sizes

On Thu, 2006-02-02 at 23:29 -0800, David S. Miller wrote: > While I have your attention, I think we should disable TSO > by default on capable chips in the tg3 driver. What's your > take on that? > You mean enable? Yes, I think we should do that (enable TSO). - To unsubscribe from this list: se

Re: [PATCH 3/4] bnx2: Support larger rx ring sizes

From: "Michael Chan" <[EMAIL PROTECTED]> Date: Thu, 02 Feb 2006 21:46:39 -0800 > I'll be re-submitting patches 3 and 4. Patch #3 will be capped at 1020 > descriptors and broken up into 3 smaller patches. Please review. I will, thanks Michael. While I have your attention, I think we should disabl

Re: [PATCH 3/4] bnx2: Support larger rx ring sizes

On Tue, 2006-01-31 at 22:11 -0800, David S. Miller wrote: > From: "Michael Chan" <[EMAIL PROTECTED]> > Date: Tue, 31 Jan 2006 21:58:23 -0800 > > > How about 1024 (actually 1020)? tg3 has a max. of 511 standard plus > > 255 jumbo rx descriptors. bnx2 runs at a higher maximum line speed > > of 2.5Gb

Re: badness in dst_release

From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 2 Feb 2006 19:35:25 -0800 > I triggered this easily to day. will bisect tomorrow. Thanks a lot Stephen. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH] snap: needs hardware checksum fix

From: Herbert Xu <[EMAIL PROTECTED]> Date: Fri, 03 Feb 2006 12:26:32 +1100 > David S. Miller <[EMAIL PROTECTED]> wrote: > > > > This patch made me notice that the length is sort of implicit > > or can be calculated given "start" and the current skb->data > > value. > > > > Someone might want to

Re: [PATCH] add CONFIG_NETDEBUG to suppress bad packet messages

From: Dave Jones <[EMAIL PROTECTED]> Date: Thu, 2 Feb 2006 23:23:03 -0500 > On Thu, Feb 02, 2006 at 04:35:01PM -0800, Stephen Hemminger wrote: > > If you are on a hostile network, or are running protocol tests, you can > > easily get the logged swamped by messages about bad UDP and ICMP packets.

Re: [PATCH] add CONFIG_NETDEBUG to suppress bad packet messages

On Thu, Feb 02, 2006 at 04:47:03PM -0800, David S. Miller wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Thu, 2 Feb 2006 16:35:01 -0800 > > > If you are on a hostile network, or are running protocol tests, you can > > easily get the logged swamped by messages about bad UDP and I

Re: [PATCH] add CONFIG_NETDEBUG to suppress bad packet messages

On Thu, Feb 02, 2006 at 04:35:01PM -0800, Stephen Hemminger wrote: > If you are on a hostile network, or are running protocol tests, you can > easily get the logged swamped by messages about bad UDP and ICMP packets. > This turns those messages off unless a config option is enabled. > > Signe

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

In article <[EMAIL PROTECTED]> (at Thu, 02 Feb 2006 20:09:44 -0800 (PST)), "David S. Miller" <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> > Date: Fri, 03 Feb 2006 11:32:13 +0900 (JST) > > > BTW, David, would you mind sending your addrconf patches to me? > > I'd like to

Re: [e2e] FW: Performance evaluation of high speed TCPs

On Fri, 3 Feb 2006 15:51:02 +1300 Ian McDonald <[EMAIL PROTECTED]> wrote: > > Seriously, where's the value in comparing buggy implementations - isn't > > that just a waste of all our time ? If we are genuine about wanting to > > understand tcp performance then I think we just have to take the hi

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Fri, 03 Feb 2006 11:32:13 +0900 (JST) > BTW, David, would you mind sending your addrconf patches to me? > I'd like to look into it deeply. > I used to have clone, but I happened to remove that tree... I intended to review my patches in small piece

Re: badness in dst_release

On Thu, 2 Feb 2006 20:37:51 -0500 Dave Jones <[EMAIL PROTECTED]> wrote: > On Thu, Feb 02, 2006 at 04:49:29PM -0800, David S. Miller wrote: > > From: Dave Jones <[EMAIL PROTECTED]> > > Date: Thu, 2 Feb 2006 14:30:28 -0500 > > > > > Here's a second flavour. > > > > Can you git bisect to figu

Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated

Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote: > > On Fri, Jan 27, 2006 at 03:01:06PM -0800, Andrew Morton wrote: > > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > If the benchmarks say that we need to. If we cannot observe any > > > > problems > > > > in testing

Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated

On Fri, Jan 27, 2006 at 03:01:06PM -0800, Andrew Morton wrote: > Ravikiran G Thirumalai <[EMAIL PROTECTED]> wrote: > > > > > > > > If the benchmarks say that we need to. If we cannot observe any problems > > > in testing of existing code and if we can't demonstrate any benefit from > > > the pa

Re: [e2e] FW: Performance evaluation of high speed TCPs

> Seriously, where's the value in comparing buggy implementations - isn't > that just a waste of all our time ? If we are genuine about wanting to > understand tcp performance then I think we just have to take the hit from > issues such as this that are outside all of our control. > A real part o

RE: [e2e] FW: Performance evaluation of high speed TCPs

Sure. Your comments about running the buggy implementation are well taken. That is why this type of reporting is helpful and we are committed to keep this effort. Just that it takes time to run the tests, and before we run a new set of tests, we have to do some batch of patches to reduce our effor

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

In article <[EMAIL PROTECTED]> (at Fri, 3 Feb 2006 12:48:49 +1100), Herbert Xu <[EMAIL PROTECTED]> says: > On Fri, Feb 03, 2006 at 10:31:58AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ > wrote: > > > > We SHALL do autoconf when we "up" an ipv6-capable device. > > It is the IPv6. > > I don't think

Re: [e2e] FW: Performance evaluation of high speed TCPs

Doug, Sorry that we are not THAT real time in updating the report :-) Seriously, we can't run the tests for every fix and bug report. But we are aware of your new patch posted last week on the e2e list and indeed applied it to our testing platform for retesting.Now one test case is done (thanks to

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

On Fri, Feb 03, 2006 at 10:31:58AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > > We SHALL do autoconf when we "up" an ipv6-capable device. > It is the IPv6. I don't think the word "SHALL" stops us from implementing it in user-space... Cheers, -- Visit Openswan at http://www.openswan.org/ Em

Re: Van Jacobson net channels

From: Greg Banks <[EMAIL PROTECTED]> Date: Fri, 03 Feb 2006 12:08:54 +1100 > So, given 2.6.16 on tg3 hardware, would your advice be to > enable TSO by default? Yes. In fact I've been meaning to discuss with Michael Chan enabling it in the driver by default. - To unsubscribe from this list: send

Re: badness in dst_release

On Thu, Feb 02, 2006 at 04:49:29PM -0800, David S. Miller wrote: > From: Dave Jones <[EMAIL PROTECTED]> > Date: Thu, 2 Feb 2006 14:30:28 -0500 > > > Here's a second flavour. > > Can you git bisect to figure out when this problem started > to occur? I'll give it a try sometime soon, though

Re: fib_rules w. RCU lock [PATCH]

From: Robert Olsson <[EMAIL PROTECTED]> Date: Fri, 27 Jan 2006 14:20:39 +0100 > The preempts are removed and an updated version of the patch is enclosed. Applied to net-2.6.17, thanks Robert. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL P

Re: tg3 bug noticed

From: "Michael Chan" <[EMAIL PROTECTED]> Date: Fri, 27 Jan 2006 09:32:09 -0800 > [TG3]: Flush tg3_reset_task() > > Make sure tg3_reset_task() is flushed in the close and suspend paths > as noted by Jeff Garzik. > > In the close path, calling flush_scheduled_work() may cause deadlock > if linkwat

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

In article <[EMAIL PROTECTED]> (at Thu, 2 Feb 2006 23:42:25 +1100), Herbert Xu <[EMAIL PROTECTED]> says: > On Thu, Feb 02, 2006 at 05:37:22AM -0700, Eric W. Biederman wrote: > > > > > Yes you are right. The locking/refcounting in addrconf.c is such > > > a mess. I've asked a number of times bef

Re: [PATCH] snap: needs hardware checksum fix

David S. Miller <[EMAIL PROTECTED]> wrote: > > This patch made me notice that the length is sort of implicit > or can be calculated given "start" and the current skb->data > value. > > Someone might want to look into making that simplification > at some point. Or we could simply merge skb_pull a

Re: [TEXTSEARCH] Fix broken good shift array calculation in Boyer-Moore

From: Pablo Neira Ayuso <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 00:21:30 +0100 > This patch fixes a problem in the Boyer-Moore textsearch strategy. > Please apply. Applied, thanks Pablo. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROT

RE: Van Jacobson net channels

On Fri, 2006-02-03 at 01:41, Leonid Grossman wrote: > > As I mentioned earlier, it would be cool to get these moderation > tresholds from NAPI, since it can make a better guess about the overall > system utilization than the driver can. Agreed. > But even at the driver level, > this works reas

Re: [PATCH]ip_options_fragment() has no effect on fragmentation

From: Wei Yongjun <[EMAIL PROTECTED]> Date: Wed, 01 Feb 2006 14:21:41 -0500 > Resend Patch: > --- linux-2.6.15.1/net/ipv4/ip_options.c.orig 2006-01-27 > 09:14:33.463612696 +0900 > +++ linux-2.6.15.1/net/ipv4/ip_options.c 2006-01-27 09:12:21.857619848 > +0900 > @@ -207,7 +207,7 @@ > > void

Re: Van Jacobson net channels

On Thu, 2006-02-02 at 18:51, David S. Miller wrote: > From: Greg Banks <[EMAIL PROTECTED]> > Date: Thu, 02 Feb 2006 18:31:49 +1100 > > > On Thu, 2006-02-02 at 17:45, Andi Kleen wrote: > > > Normally TSO was supposed to fix that. > > > > Sure, except that the last time SGI looked at TSO it was >

Re: Van Jacobson net channels

On Thu, 2006-02-02 at 18:48, Andi Kleen wrote: > On Thursday 02 February 2006 08:31, Greg Banks wrote: > > > [...]SGI's solution is do is ship a script that uses ethtool > > at boot to tune rx-usecs, rx-frames, rx-usecs-irq, rx-frames-irq > > up from the defaults. > > All user tuning like this is

Re: [PATCH] 1/1 net/core: use USEC_PER_SEC and line spacing

From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 02 Feb 2006 09:06:34 +1100 > Ian McDonald <[EMAIL PROTECTED]> wrote: > > On 2/1/06, Herbert Xu <[EMAIL PROTECTED]> wrote: > >> Ian McDonald <[EMAIL PROTECTED]> wrote: > >> > > >> > --- a/net/core/sock.c > >> > +++ b/net/core/sock.c > >> > @@ -162,7 +

Re: [PATCH] Remove suprious use of goto out: in icmp_reply

From: Horms <[EMAIL PROTECTED]> Date: Wed, 1 Feb 2006 13:33:48 +0900 > This seems to be an artifact of the follwoing commit in February '02. > http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=history;h=e7e173af42dbf37b1d946f9ee00219cb3b2bea6a;f=net/ipv4/icmp.c > > In a nutshell, g

Re: [lock validator] inet6_destroy_sock(): soft-safe -> soft-unsafe lock dependency

From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 1 Feb 2006 21:42:14 +1100 > OK this is definitely broken. We should never touch the dst lock in > softirq context. Since inet6_destroy_sock may be called from that > context due to the asynchronous nature of sockets, we can't take the > lock there.

Re: [PATCH] [IPV4] Document icmp_errors_use_inbound_ifaddr sysctl

From: Horms <[EMAIL PROTECTED]> Date: Wed, 1 Feb 2006 17:32:18 +0900 > Taken largely from the commit of the patch that added this feature > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c2fb7f93cb20621772bf304f3dba0849942e5db > > I'm not sure about the ordering

Re: [PATCH][SCTP]: Fix 'fast retransmit' to send a TSN only once.

From: Sridhar Samudrala <[EMAIL PROTECTED]> Date: Wed, 01 Feb 2006 14:29:22 -0800 > SCTP used to "fast retransmit" a TSN every time we hit the number > of missing reports for the TSN. However the Implementers Guide > specifies that we should only "fast retransmit" a given TSN once. > Subsequent r

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 2 Feb 2006 22:25:54 +1100 > [IPV6]: Don't hold extra ref count in ipv6_ifa_notify > > Currently the logic in ipv6_ifa_notify is to hold an extra reference > count for addrconf dst's that get added to the routing table. Thus, > when addrconf dst ent

Re: [PATCH] add CONFIG_NETDEBUG to suppress bad packet messages

On Thu, 02 Feb 2006 16:47:03 -0800 (PST) "David S. Miller" <[EMAIL PROTECTED]> wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Thu, 2 Feb 2006 16:35:01 -0800 > > > If you are on a hostile network, or are running protocol tests, you can > > easily get the logged swamped by messages ab

Re: [PATCH] snap: needs hardware checksum fix

From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 2 Feb 2006 16:32:31 -0800 > The SNAP code pops off it's 5 byte header, but doesn't adjust > the checksum. This would cause problems when using device that > does IP over SNAP and hardware receive checksums. > > Signed-off-by: Stephen Hemminge

Re: badness in dst_release

From: Dave Jones <[EMAIL PROTECTED]> Date: Thu, 2 Feb 2006 14:30:28 -0500 > Here's a second flavour. Can you git bisect to figure out when this problem started to occur? Thanks a lot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED

Re: [PATCH] add CONFIG_NETDEBUG to suppress bad packet messages

From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 2 Feb 2006 16:35:01 -0800 > If you are on a hostile network, or are running protocol tests, you can > easily get the logged swamped by messages about bad UDP and ICMP packets. > This turns those messages off unless a config option is enabled.

Re: [Bugme-new] [Bug 5999] New: Iptables modules fail to load on Alpha arch

From: Andrew Morton <[EMAIL PROTECTED]> Date: Thu, 2 Feb 2006 16:34:54 -0800 > Odd. Not sure what the "Could not allocate 60 bytes percpu data" is > due to, either. As the user indicates this problem goes all the way back to 2.6.9, I really think it's likely some Alpha specific problem wrt. perc

[PATCH] add CONFIG_NETDEBUG to suppress bad packet messages

If you are on a hostile network, or are running protocol tests, you can easily get the logged swamped by messages about bad UDP and ICMP packets. This turns those messages off unless a config option is enabled. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- br-2.6.orig/include/net/sock

[PATCH] snap: needs hardware checksum fix

The SNAP code pops off it's 5 byte header, but doesn't adjust the checksum. This would cause problems when using device that does IP over SNAP and hardware receive checksums. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- br-2.6.orig/net/802/psnap.c +++ br-2.6/net/802/psnap.c @@ -59,8

Fw: [Bugme-new] [Bug 5999] New: Iptables modules fail to load on Alpha arch

Odd. Not sure what the "Could not allocate 60 bytes percpu data" is due to, either. Begin forwarded message: Date: Thu, 2 Feb 2006 15:13:29 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 5999] New: Iptables modules fail to load on Alpha arch http://bugzilla.ker

[patch 2/2] natsemi: NAPI and a bugfix

As documented in National application note 1287 the RX state machine on the natsemi chip can lock up under some conditions (mostly related to heavy load). When this happens a series of bogus packets are reported by the chip including some oversized frames prior to the final lockup. This patch imp

[patch 1/2] natsemi: NAPI and a bugfix

This patch converts the natsemi driver to use NAPI. It was originally based on one written by Harald Welte, though it has since been modified quite a bit, most extensively in order to remove the ability to disable NAPI since none of the other drivers seem to provide that functionality any more. S

[patch 0/2] natsemi: NAPI and a bugfix

These patches provide a series of updates to the natsemi driver: the NAPI patch I've submitted before and a workaround for an issue with the hardware that is easier to provoke at higher data rates. 1/2: Convert the driver to NAPI 2/2: Fix hardware issue with RX state machine lock up -- "You g

Re: [wireless-2.6] d80211/ieee80211 symbol clash

On Thu, Feb 02, 2006 at 02:55:43PM -0800, shemminger wrote: > But then the module autoloader is going to work correctly, and what > about people using drivers that use conflicting stacks? Get the > namespace issues sorted out before you consider getting it into the > mainline. I thought that only

Re: [wireless-2.6] d80211/ieee80211 symbol clash

On Thu, Feb 02, 2006 at 06:01:45PM -0500, Jeff Garzik wrote: > Avoiding namespace clashes means that you avoid confusing all manner of > common developer tools. In particular, 'make allyesconfig' is a > valuable developer tool that should not be broken. I agree with this completely; I just wou

Re: [wireless-2.6] d80211/ieee80211 symbol clash

Jouni Malinen wrote: On Thu, Feb 02, 2006 at 08:36:26PM +0100, Michael Buesch wrote: net/ieee80211/built-in.o: In function `ieee80211_rx': : multiple definition of `ieee80211_rx' net/d80211/built-in.o:: first defined here But how to solve it? I suggest to change all dscape function prefixe

Re: [wireless-2.6] d80211/ieee80211 symbol clash

On Thu, 2006-02-02 at 13:56 -0800, Jouni Malinen wrote: > On Thu, Feb 02, 2006 at 08:36:26PM +0100, Michael Buesch wrote: > > > net/ieee80211/built-in.o: In function `ieee80211_rx': > > : multiple definition of `ieee80211_rx' > > net/d80211/built-in.o:: first defined here > > > But how to solve i

Re: Kernel BUG at drivers/net/tg3.c:2914 on SMP amd64

On Thu, 2006-02-02 at 22:05 +, Mike Crowe wrote: >> Perhaps this new problem is unrelated. I shall try and reproduce >> it. Is there anything I should try when the interface is locked up to >> help? On Thu, Feb 02, 2006 at 12:49:53PM -0800, Michael Chan wrote: > Did this setup use to work bef

Re: Kernel BUG at drivers/net/tg3.c:2914 on SMP amd64

On Thu, 2006-02-02 at 22:05 +, Mike Crowe wrote: > Perhaps this new problem is unrelated. I shall try and reproduce > it. Is there anything I should try when the interface is locked up to > help? > 1. Run ethtool -d eth? > before you get a NETDEV WATCHDOG timeout and before you do ifdown. P

Re: Kernel BUG at drivers/net/tg3.c:2914 on SMP amd64

On Thu, 2006-02-02 at 13:37 +, I wrote: >> I'm running the Debian 2.6.15 kernel from backports.org on a machine >> with two Opteron 275s. I am getting a BUG in tg3.c quite reliably if I >> ping flood the machine from a few others and cause a bit of other >> network activity. Sometimes it takes

Re: [wireless-2.6] d80211/ieee80211 symbol clash

On Thu, Feb 02, 2006 at 08:36:26PM +0100, Michael Buesch wrote: > net/ieee80211/built-in.o: In function `ieee80211_rx': > : multiple definition of `ieee80211_rx' > net/d80211/built-in.o:: first defined here > But how to solve it? I suggest to change all dscape function prefixes > from ieee80211_F

Re: [RFC] Poor Network Performance with e1000 on 2.6.14.3

Rick Jones wrote: I haven't been able to get a TCP connection to saturate a 1Gbps link in both directions simultaneously. I *have* been able to fully saturate 2 pro/1000 NICs on the same machine using pktgen, so the NIC/driver can support it if only TCP can run fast enough... It isn't quite s

RE: Van Jacobson net channels and NIC channels

> -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > Why are you saying it can't be used by the host? The stack > should be fully ready for it. Sorry, I should have said "it can't be used by the host to the full potential of the feature" :-). It does work for us now, a

Re: [wireless-2.6] d80211/ieee80211 symbol clash

On Thursday 02 February 2006 21:04, John W. Linville wrote: > On Thu, Feb 02, 2006 at 08:36:26PM +0100, Michael Buesch wrote: > > Not sure, if I am the first one compiling the domesday branch, > > but the ieee80211_rx symbol clashes: > > > > net/ieee80211/built-in.o: In function `ieee80211_rx': >

Re: [wireless-2.6] d80211/ieee80211 symbol clash

On Thu, Feb 02, 2006 at 08:36:26PM +0100, Michael Buesch wrote: > Not sure, if I am the first one compiling the domesday branch, > but the ieee80211_rx symbol clashes: > > net/ieee80211/built-in.o: In function `ieee80211_rx': > : multiple definition of `ieee80211_rx' > net/d80211/built-in.o:: firs

[wireless-2.6] d80211/ieee80211 symbol clash

Not sure, if I am the first one compiling the domesday branch, but the ieee80211_rx symbol clashes: net/ieee80211/built-in.o: In function `ieee80211_rx': : multiple definition of `ieee80211_rx' net/d80211/built-in.o:: first defined here Maybe people always compile the stacks as modules, so this d

Re: badness in dst_release

On Wed, Feb 01, 2006 at 01:08:33PM -0500, Dave Jones wrote: > I managed to get a box running 2.6.16rc1-git4 to spit this out.. > > Dave > > UDP: bad checksum. From 192.168.79.115:43047 to 192.168.76.106:61494 ulen > 1083 > Badness in dst_release at include/net/dst.h:154 (Not

slab corruption in 2.6.16rc1-git4

I've had a box being tortured with random junk packets (created with isic) for a few days, and it spat this out last night.. Feb 1 04:28:09 trogdor kernel: Slab corruption: (Not tainted) start=cefc8a9c, len=244 Feb 1 04:28:09 trogdor kernel: Redzone: 0x5a2cf071/0x5a2cf071. Feb 1 04:28:09 trogd

Re: [PATCH] TCP MTU probing

On Thursday 02 February 2006 13:23, John Heffner wrote: > Implementation of packetization layer path mtu discovery for TCP, based on > the internet-draft currently found at > . Fixed to turn off by default (oops). Signed-off-by:

instrumentation for TCP MTU probing

This is a patch which adds instruments to the TCP MTU probing. It breaks netstat -s because it extends the line length of /proc/net/netstat past 1024 characters, so it is not safe to apply. I'm sending it for reference only at this point. -John diff --git a/include/linux/snmp.h b/include/l

Re: Van Jacobson net channels

Andi Kleen wrote: On Thursday 02 February 2006 08:31, Greg Banks wrote: The tg3 driver uses small hardcoded values for the RXCOL_TICKS and RXMAX_FRAMES registers, and allows "ethtool -C" to change them. SGI's solution is do is ship a script that uses ethtool at boot to tune rx-usecs, rx-frame

[PATCH] TCP MTU probing

Implementation of packetization layer path mtu discovery for TCP, based on the internet-draft currently found at . Signed-off-by: John Heffner <[EMAIL PROTECTED]> diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h ---

RE: Van Jacobson net channels

Leonid Grossman writes: > Right. Interrupt moderation is done on per channel basis. > The only addition to the current NAPI mechanism I'd like to see is to > have NAPI setting desired interrupt rate (once interrupts are ON), > rather than use an interrupt per packet or a driver default. Argu

Re: Van Jacobson net channels

Oh you have TSO disabled? That explains a lot. Yes, it's been a bumpy road, and there are still some e1000 lockups, but in general things should be smooth these days. I suspect that "these days" in kernel.org terms differs somewhat from "these days" RH/SuSE/etc terms, hence TSO being disabled

Re: Van Jacobson net channels

On Wed, 01 Feb 2006 16:29:11 -0800 (PST) "David S. Miller" <[EMAIL PROTECTED]> wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Wed, 1 Feb 2006 16:12:14 -0800 > > > The bigger problem I see is scalability. All those mmap rings have to > > be pinned in memory to be useful. It's fine f

Re: Van Jacobson net channels and NIC channels

On Thursday 02 February 2006 17:27, Leonid Grossman wrote: > By now we have submitted UFO, MSI-X and LRO patches. The one item on > the TODO list that we did not submit a full driver patch for is the > "support for distributing receive processing across multiple CPUs (using > NIC hw queues)", mai

Re: Kernel BUG at drivers/net/tg3.c:2914 on SMP amd64

On Thu, 2006-02-02 at 13:37 +, Mike Crowe wrote: > I'm running the Debian 2.6.15 kernel from backports.org on a machine > with two Opteron 275s. I am getting a BUG in tg3.c quite reliably if I > ping flood the machine from a few others and cause a bit of other > network activity. Sometimes it t

[PATCH 2/2] wireless/atmel: fix setting TX key only in ENCODEEXT

The previous patch that added ENCODEEXT and AUTH support to the atmel driver contained a slight error which would cause just setting the TX key index to also set the encryption key again. Signed-off-by: Dan Williams <[EMAIL PROTECTED]> --- a/drivers/net/wireless/atmel.c 2006-02-02 00:58:44.

RE: Van Jacobson net channels

> -Original Message- > From: Eric W. Biederman [mailto:[EMAIL PROTECTED] > How do you classify channels? Multiple rx steering criterias are available, for example tcp tuple (or subset) hash, direct tcp tuple (or subset) match, MAC address, pkt size, vlan tag, QOS bits, etc. > > If

[PATCH 1/2] wireless/atmel: fix authentication process bugs

This patch fixes a number of bugs in the authentication process: 1) When falling back to Shared Key authentication mode from Open System, a missing 'return' would cause the auth request to be sent, but would drop the card into Management Error state. When falling back, the driver should also indi

[PATCH 0/2] wireless/atmel: WEXT and authentication fixes

These two patches fix bugs in the Atmel driver's handing of WEXT and authentication. The first fixes setting of the TX key only for the ENCODEEXT functionality I added last week. The second fixes some bugs in the authentication process for both WEP and non-WEP configurations. Summary: [PATCH 1/

Van Jacobson net channels and NIC channels

Thanks to Andi, Dave, Jeff and everyone who responded to the original query; I've got enough pointers to presentations, blogs and ideas to keep me busy for a while :-) VJ channels indeed seem to compliment and take to a different level some sw and hw ideas on Dave's TODO list. By now we have subm

Re: Van Jacobson net channels

On Thu, 02 Feb 2006 08:35:28 -0700 [EMAIL PROTECTED] (Eric W. Biederman) wrote: > "Christopher Friesen" <[EMAIL PROTECTED]> writes: > > > Eric W. Biederman wrote: > >> Jeff Garzik <[EMAIL PROTECTED]> writes: > > > >>> This was discussed on the netdev list, and the conclusion was that > >>> you wa

Re: Van Jacobson net channels

"Leonid Grossman" <[EMAIL PROTECTED]> writes: > There two facilities (at least, in our ASIC, but there is no reason this > can't be part of the generic multi-channel driver interface that I will > get to shortly) to deal with it. > > - hardware supports more than one utilization-based interrupt ra

Re: Van Jacobson net channels

"Christopher Friesen" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Jeff Garzik <[EMAIL PROTECTED]> writes: > >>> This was discussed on the netdev list, and the conclusion was that >>> you want both NAPI and hw mitigation. This was implemented in a >>> few drivers, at least. > >> How

RE: Van Jacobson net channels

> -Original Message- > From: Andi Kleen [mailto:[EMAIL PROTECTED] > > You just need to make sure that you don't leak data from > other peoples > > sockets. > > There are three basic ways I can see to do this: > > - You have really advanced hardware which can potentially > manage

Re: Van Jacobson net channels

Eric W. Biederman wrote: Jeff Garzik <[EMAIL PROTECTED]> writes: This was discussed on the netdev list, and the conclusion was that you want both NAPI and hw mitigation. This was implemented in a few drivers, at least. How does that deal with the latency that hw mitigation introduces. When

RE: Van Jacobson net channels

> -Original Message- > From: Eric W. Biederman [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 02, 2006 4:29 AM > To: Jeff Garzik > Cc: Andi Kleen; Greg Banks; David S. Miller; Leonid Grossman; > [EMAIL PROTECTED]; Linux Network Development list > Subject: Re: Van Jacobson net cha

Kernel BUG at drivers/net/tg3.c:2914 on SMP amd64

I'm running the Debian 2.6.15 kernel from backports.org on a machine with two Opteron 275s. I am getting a BUG in tg3.c quite reliably if I ping flood the machine from a few others and cause a bit of other network activity. Sometimes it takes a few minutes, sometimes half an hour. The BUG also fire

Re: How can I get local copy of your git tree?

On Thu, Feb 02, 2006 at 12:16:03PM +0100, Jochen Friedrich wrote: > Hi Denis, > > >Hi John, > ># cg-clone > >rsync://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > >wireless-2.6.git > > > > > > the branch softmac has been renamed to softmac-all. > > # cg-clone > "rsync:

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

On Thu, Feb 02, 2006 at 05:37:22AM -0700, Eric W. Biederman wrote: > > > Yes you are right. The locking/refcounting in addrconf.c is such > > a mess. I've asked a number of times before as to why most of > > this can't be done in user-space instead. There is nothing performance > > critical here

Re: [PATCH 0/0] AES-XCBC-MAC

On Fri, Jan 27, 2006 at 09:17:24PM +0900, Kazunori Miyazawa wrote: > > I resend following patches to the kernel support AES-XCBC-MAC. > These patches can probably support another XCBC algorithms > but I only tested with AES on the test vectors of RFC3566. Thanks for the patch. It turns out that

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

Herbert Xu <[EMAIL PROTECTED]> writes: > On Fri, Jan 27, 2006 at 01:00:49AM -0700, Eric W. Biederman wrote: >> >> However I do know I have correctly found the leak. > > Yes you are right. The locking/refcounting in addrconf.c is such > a mess. I've asked a number of times before as to why most

Re: Van Jacobson net channels

Jeff Garzik <[EMAIL PROTECTED]> writes: > Andi Kleen wrote: >> There was already talk some time ago to make NAPI drivers use >> the hardware mitigation again. The reason is when you have > > > This was discussed on the netdev list, and the conclusion was that you want > both > NAPI and hw mitigat

[PATCH] Docs: documentation for new arp_accept sysctl variable

As John pointed out, I had not added documentation to describe the arp_accpet sysctl that I posted in my last patch. This patch adds that documentation. Thanks & Regards Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> ip-sysctl.txt |5 + 1 files changed, 5 insertions(+) diff --gi

Re: [PATCH] ipv6: addrconf_ifdown fix dst refcounting.

On Fri, Jan 27, 2006 at 01:00:49AM -0700, Eric W. Biederman wrote: > > However I do know I have correctly found the leak. Yes you are right. The locking/refcounting in addrconf.c is such a mess. I've asked a number of times before as to why most of this can't be done in user-space instead. The

Re: How can I get local copy of your git tree?

Hi Denis, >Hi John, ># cg-clone >rsync://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git >wireless-2.6.git > > the branch softmac has been renamed to softmac-all. # cg-clone "rsync://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git#softmac-all" wireless-2

Re: How can I get local copy of your git tree?

Denis Vlasenko <[EMAIL PROTECTED]> : [...] git clone git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git some_dest_directory Say I have some reference tree: $ ls linux/linux-2.6-ref/.git branches FETCH_HEADHEAD info ORIG_HEAD remotes description git-

How can I get local copy of your git tree?

Hi John, I want to work with your git tree, specifically, softmac branch. After reading thru git and codito docs, I did: # cg-clone rsync://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git wireless-2.6.git defaulting to local storage area WARNING: The rsync access method is DE