On Mon, 20 Mar 2006 19:30:17 -0800
"Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
>
> in Documentation/networking/TODO, the Jamal netdev Rx polling API change
> is done, right? (NAPI)
>
> Are any of the others done?
> Should this TODO file be removed or updated or reference
> http://vger.kernel.or
Having given someone the answer of "2.6.14 has a 'full fixed' TSO" (from
the standpoint of slow start and remaining on for a connection after
retransmission they have shot back with "Do you know the fix ID's so I
can see if distro foo has incorporated them?"
Could someone give me a gentle tap
hello,
the attached patch fixes a problem I had when running 2 different
Au15xx-based boards (Au1500 and Au1550) in bridging mode under high load.
au1000_tx_timeout() would reset the device for which it was called, but
promiscuous mode was not re-established.
tested under 2.6.14, 2.6.16-rc6 and
From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 20 Mar 2006 19:37:51 -0500 (EST)
> I believe Catherine is away this week, so it's probably best to drop the
> code and wait till she gets back and we can get it 100% right.
Ok, agreed.
> Sorry, this is my fault, I should have caught this problem
On Mon, 20 Mar 2006, David S. Miller wrote:
> I'm seriously considering backing out Catherine's AF_UNIX patch from
> the net-2.6.17 tree before submitting it to Linus later today so that
> none of this crap goes in right now.
I believe Catherine is away this week, so it's probably best to drop th
This patch decodes state and revovers from any races in the transmit
timeout and NAPI logic. It should never trigger, but if it does then
do the right thing.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-20 14:33:26.0 -0800
+++ sky2-
New version of sky2 for 2.6.17. The big change is using
IRQ control registers properly to avoid races in NAPI. This
also means MSI now works.
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
Remove wake on lan support for now. It doesn't work right, and I
don't have a machine with working suspend/resume to test or fix it.
It will be re-enabled later.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-14 09:39:38.0 -0800
+++ s
Set version to 1.1
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-14 09:39:38.0 -0800
+++ sky2-2.6.17/drivers/net/sky2.c 2006-03-20 11:05:57.0 -0800
@@ -51,7 +51,7 @@
#include "sky2.h"
#define DRV_NAME "
Redo the interupt handling of sky2 driver based on the IRQ mangement
documentation. All interrupts are handled by the device0 NAPI poll
routine.
Don't need to adjust interrupt mask in IRQ context, done only when
changing device under RTNL. Therefore don't need hwlock anymore.
Signed-off-by: Steph
Small whitespace fixes.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-07 14:05:53.0 -0800
+++ sky2-2.6.17/drivers/net/sky2.c 2006-03-07 14:21:17.0 -0800
@@ -852,7 +852,7 @@
if (!netif_running(dev))
Add MSI support to sky2 driver.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-03-20 14:32:43.0 -0800
+++ sky2-2.6.17/drivers/net/sky2.c 2006-03-20 14:33:07.0 -0800
@@ -92,6 +92,10 @@
module_param(copybreak, int, 0);
MODUL
The Yukon EC/rev0 (A1) chipset requires a bunch of workarounds. I copied these
from sk98lin. But since they never got tested and add more cruft to the code;
any attempt at using driver as is on this version will probably fail.
It looks like this was a early engineering sample chip revision, if it
The hardware has additional error trap interrupt bits. I have never seen
them trigger, but if they do, it looks like this might be useful.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Index: sky2-2.6.17/drivers/net/sky2.c
=
* David S. Miller ([EMAIL PROTECTED]) wrote:
> From: Chris Wright <[EMAIL PROTECTED]>
> Date: Mon, 20 Mar 2006 13:36:36 -0800
>
> > The point of Catherine's original patch was to make sure there's always
> > a security identifier associated with AF_UNIX messages. So receiver
> > can always check
On Mon, 2006-03-20 at 10:00 -0500, jamal wrote:
> I have to say i am scratching my head - now that i was forced to run the
> tests - to see if there is infact a scenario where you could show 2.4 to
> be better...
So that is the underlying reason you are resisting -
you just can't see that it coul
From: Chris Wright <[EMAIL PROTECTED]>
Date: Mon, 20 Mar 2006 13:36:36 -0800
> The point of Catherine's original patch was to make sure there's always
> a security identifier associated with AF_UNIX messages. So receiver
> can always check it (same as having credentials even w/out sender
> contro
Boards with multiple PHYs were not being handled properly by the pcnet32
driver. This patch by Thomas Bogendoerfer with changes by me will allow
Allied Telesyn 2700FTX and 2701FTX boards to use either the copper or
the fiber interfaces. It has been tested on ia32 and ppc64 hardware.
Philippe Seew
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> Chris Wright <[EMAIL PROTECTED]> wrote:
> > Catherine, the security_sid_to_context() is a raw SELinux function which
> > crept into core code and should not have been there. The fallout fixes
> > included conditionally exporting security_sid_to_context,
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Mon, 20 Mar 2006 10:09:42 -0500
> Wouldn't it make sense to strech the ACK when the previous ACK is still in
> the TX queue of the device? I know that sort of behaviour was always an
> issue on modem links where you don't want to send out redunda
Chris Wright <[EMAIL PROTECTED]> wrote:
>
> * Chris Wright ([EMAIL PROTECTED]) wrote:
> > * Ingo Oeser ([EMAIL PROTECTED]) wrote:
> > > Hi Chris,
> > >
> > > Andrew Morton wrote:
> > > > Ingo Oeser <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > -int scm_send(struct socket *sock, struct msghdr *ms
On Mon, 20 Mar 2006 11:56:32 -0800
Skunk Worx <[EMAIL PROTECTED]> wrote:
> Rick Jones wrote:
> >
> > It _would_ be very interesting to see if disabling tcp_abc does
> > workaround the problem.
> >
>
> Yes it does, we tried that first. Then we reenabled tcp_abc and
> increased the toolkit keep_
* Chris Wright ([EMAIL PROTECTED]) wrote:
> * Ingo Oeser ([EMAIL PROTECTED]) wrote:
> > Hi Chris,
> >
> > Andrew Morton wrote:
> > > Ingo Oeser <[EMAIL PROTECTED]> wrote:
> > > >
> > > > -int scm_send(struct socket *sock, struct msghdr *msg, struct
> > > > scm_cookie *scm)
> > > > -{
> > > > -
On Mon, 20 Mar 2006 11:07:34 -0800
"Ron Mercer" <[EMAIL PROTECTED]> wrote:
> Stephen,
>
> Thank you for taking the time to review my driver. The feedback was
> great. I will endeavor to bring it up to an A+. Please see my comments
> below.
>
> > * Do nvram via ethtool
> I am not sure what yo
* Ingo Oeser ([EMAIL PROTECTED]) wrote:
> Hi Chris,
>
> Andrew Morton wrote:
> > Ingo Oeser <[EMAIL PROTECTED]> wrote:
> > >
> > > -int scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie
> > > *scm)
> > > -{
> > > -struct task_struct *p = current;
> > > -scm->
Rick Jones wrote:
It _would_ be very interesting to see if disabling tcp_abc does
workaround the problem.
Yes it does, we tried that first. Then we reenabled tcp_abc and
increased the toolkit keep_alive. Either method works around the issue
from our point of view.
---
John
-
To unsubscr
Stephen,
Thank you for taking the time to review my driver. The feedback was
great. I will endeavor to bring it up to an A+. Please see my comments
below.
> -Original Message-
> From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 17, 2006 1:35 PM
> To: Ron Mercer
>
And there you have it - four separate sends for logically associated
data, when there should have been just the one sendmsg or writev call.
Given the sizes involved, that is roughly three to four times as much
CPU consumed to send that data is should have been - for "small"
packets you can hand
Wouldn't it make sense to strech the ACK when the previous ACK is still in
the TX queue of the device? I know that sort of behaviour was always an
issue on modem links where you don't want to send out redundant ACKs.
Perhaps, but it isn't clear that it would be worth the cycles to check.
I
Hi Rick,
On Mon, Mar 20, 2006 at 10:27:07AM -0800, Rick Jones wrote:
> Anand Kumria wrote:
> >Hi,
> >
> >I'm writing a program which receives ARP packets and have noticed that
> >broadcast ARP packets seem to come in with the destination hardware
> >address set as all zeros.
>
> long, Long, LONG
The XFRM code base looks like it needs a relatively intrusive change to
support protocols like SCTP correctly. The problem is that security
policies are cached on the socket level, where SCTP not only uses
multiple addresses per association, but multiple associations per socket.
I believe t
Anand Kumria wrote:
Hi,
I'm writing a program which receives ARP packets and have noticed that
broadcast ARP packets seem to come in with the destination hardware
address set as all zeros.
long, Long, LONG ago, all-zeros was considered broadcast. however,
long, Long ago, that was switched to
All accessor's different methods are now selected with C code and unused
ones statically optimized away at compile time instead of being selected
with #if's and #ifdef's. This has many advantages such as allowing the
compiler to validate the syntax of the whole code, making it cleaner and
easier
On Mon, Mar 20, 2006 at 02:04:07PM +0200, Michael S. Tsirkin wrote:
> does not stretch ACKs anymore. RFC 2581 does mention that it might be OK to
> stretch ACKs "after careful consideration", and we are seeing that it helps
> IP over InfiniBand, so recent Linux kernels perform worse in that respect
On Mon, 2006-20-03 at 14:46 +1000, Russell Stuart wrote:
> On Sun, 2006-03-19 at 11:32 -0500, jamal wrote:
> From what I can see, you are not testing a "real" data
> set here. Is that the case?
Its a worst case scenario test setup - You lookup at all possible data
values.
Normally it is the b
Quoting Arjan van de Ven <[EMAIL PROTECTED]>:
> > I read it as if he was proposing to have a sysctl knob to turn off
> > TCP congestion control completely (which has so many issues it's not
> > even funny.)
>
> owww that's so bad I didn't even consider that
No, I think that comment was taken out
Quoting r. Lennert Buytenhek <[EMAIL PROTECTED]>:
> > > > I disagree with Linux changing it's behavior. It would be great to
> > > > turn off congestion control completely over local gigabit networks,
> > > > but that isn't determinable in any way, so we don't do that.
> > >
> > > Interesting. Wo
On Mon, 2006-03-20 at 12:49 +0100, Lennert Buytenhek wrote:
> On Mon, Mar 20, 2006 at 12:47:03PM +0100, Arjan van de Ven wrote:
>
> > > > I disagree with Linux changing it's behavior. It would be great to
> > > > turn off congestion control completely over local gigabit networks,
> > > > but that
On Mon, Mar 20, 2006 at 12:47:03PM +0100, Arjan van de Ven wrote:
> > > I disagree with Linux changing it's behavior. It would be great to
> > > turn off congestion control completely over local gigabit networks,
> > > but that isn't determinable in any way, so we don't do that.
> >
> > Interest
On Mon, 2006-03-20 at 13:27 +0200, Michael S. Tsirkin wrote:
> Quoting David S. Miller <[EMAIL PROTECTED]>:
> > I disagree with Linux changing it's behavior. It would be great to
> > turn off congestion control completely over local gigabit networks,
> > but that isn't determinable in any way, so
Hi Chris,
Andrew Morton wrote:
> Ingo Oeser <[EMAIL PROTECTED]> wrote:
> >
> > -int scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie
> > *scm)
> > -{
> > - struct task_struct *p = current;
> > - scm->creds = (struct ucred) {
> > - .uid = p->uid,
> > -
Quoting David S. Miller <[EMAIL PROTECTED]>:
> I disagree with Linux changing it's behavior. It would be great to
> turn off congestion control completely over local gigabit networks,
> but that isn't determinable in any way, so we don't do that.
Interesting. Would it make sense to make it anothe
[just sent upstream; patch snipped due to size]
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
Documentation/DocBook/sis900.tmpl | 585 --
Documentation/networking/sis900.txt
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Mon, 20 Mar 2006 12:22:34 +0200
> Quoting r. David S. Miller <[EMAIL PROTECTED]>:
> > The path an SKB can take is opaque and unknown until the very last
> > moment it is actually given to the device transmit function.
>
> Why, I was proposing l
I discovered that there is problem with 2.6.15 and 2.6.16 kernels -
network interface (e100) comes up without link-local address. Both e100
and IPv6 are compiled into kernel. From dmesg:
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
There
Quoting r. David S. Miller <[EMAIL PROTECTED]>:
> The path an SKB can take is opaque and unknown until the very last
> moment it is actually given to the device transmit function.
Why, I was proposing looking at dst cache. If that's NULL, well,
we won't stretch ACKs. Worst case we apply the wrong
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
Date: Mon, 20 Mar 2006 11:06:29 +0200
> Is it the case then that this requirement is less essential on
> networks such as IP over InfiniBand, which are very low latency
> and essencially lossless (with explicit congestion contifications
> in hardware)
John W. Linville wrote:
The following changes since commit dd288e7d75b9041f79fecae77d61cfa345da7266:
John W. Linville:
Merge branch 'upstream-fixes'
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
pulled
-
To
Quoting r. David S. Miller <[EMAIL PROTECTED]>:
> > well, there are stacks which do "stretch acks" (after a fashion) that
> > make sure when they see packet loss to "do the right thing" wrt sending
> > enough acks to allow cwnds to open again in a timely fashion.
>
> Once a loss happens, it's to
49 matches
Mail list logo
