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
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
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.6.git
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.
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 mitigation. This
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 --git
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 of
this
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, and
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 I
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
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
-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 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 does that deal with
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 rate (we
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
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 want both NAPI and hw
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
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
-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 your
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
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
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), mainly
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.
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 for a single
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.
Implementation of packetization layer path mtu discovery for TCP, based on the
internet-draft currently found at
http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-05.txt.
Signed-off-by: John Heffner [EMAIL PROTECTED]
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
---
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
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
http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-05.txt.
Fixed to turn off by default (oops).
Signed-off-by: John
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
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
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
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:: first
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':
:
-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, as a
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
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_FOO
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 a few
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? tmp_file before you get a NETDEV WATCHDOG
timeout and before you do
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 before?
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 it? I
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
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 would
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
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
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
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.
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
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
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. percpu
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 of
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 before as to
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 linkwatch_event()
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
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 I'm up
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 the
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/
Email:
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
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 the word SHALL
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
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 of
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 patched code then
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 of existing code and if we
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 figure out when this
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 pieces,
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 hit from
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 look into it
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.
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 ICMP
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.
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
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
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
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
73 matches
Mail list logo
