On Tue, 26 Sep 2006, Stephen Hemminger wrote:
The mii-tool utility seems to be abandoned and unmaintained?
Here is a version that does standard 1000baseT support.
http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
cool that's bugged me for a while...
there's an off-by-1
On Tue, 26 Sep 2006, Jeff Garzik wrote:
Stephen Hemminger wrote:
The mii-tool utility seems to be abandoned and unmaintained?
Here is a version that does standard 1000baseT support.
http://developer.osdl.org/shemminger/prototypes/mii-tool.tar.bz2
Not really. I would rather leave
On Wed, 27 Sep 2006, Auke Kok wrote:
dean gaudet wrote:
On Tue, 26 Sep 2006, Jeff Garzik wrote:
Stephen Hemminger wrote:
The mii-tool utility seems to be abandoned and unmaintained?
Here is a version that does standard 1000baseT support.
http://developer.osdl.org
it seems that ifb counts packets twice... both at xmit time and also in
the tasklet. i'm not sure which one of the two to drop, but here's a
patch for dropping the counting at xmit time.
patch against 2.6.20-rc1.
-dean
Signed-off-by: dean gaudet [EMAIL PROTECTED]
Index: linux/drivers/net
On Sat, 23 Dec 2006, jamal wrote:
On Sat, 2006-23-12 at 02:35 -0800, dean gaudet wrote:
it seems that ifb counts packets twice... both at xmit time and also in
the tasklet. i'm not sure which one of the two to drop, but here's a
patch for dropping the counting at xmit time.
Good
hi... i'm having troubles matching up the tcp(7) man page description of
TCP_DEFER_ACCEPT versus some comments in the kernel (2.6.20-rc2) versus
how the kernel actually acts.
the man page says this:
TCP_DEFER_ACCEPT
Allows a listener to be awakened only when data arrives on
in the test program below the getsockname result on a TCP socket changes
across a write which produces EPIPE... here's a fragment of the strace:
getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
sin_addr=inet_addr(127.0.0.1)}, [17863593746633850896]) = 0
...
write(3, hi!\n, 4)
On Tue, 23 Jan 2007, Rick Jones wrote:
Herbert Xu wrote:
Prior to the last write, the socket entered the CLOSED state meaning
that the old port is no longer allocated to it. As a result, the
last write operates on an unconnected socket which causes a new local
port to be allocated as an
On Tue, 23 Jan 2007, David Miller wrote:
From: dean gaudet [EMAIL PROTECTED]
Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST)
libnss-ldap has some code which attempts to determine if its private
socket has been trampled on in between calls to the library... and to do
this it caches
ping. i received no response on this one..
thanks
-dean
On Sat, 30 Dec 2006, dean gaudet wrote:
hi... i'm having troubles matching up the tcp(7) man page description of
TCP_DEFER_ACCEPT versus some comments in the kernel (2.6.20-rc2) versus
how the kernel actually acts.
the man page
hi...
i ran into some problems recently which would have been avoided if my box
did a gratuitous arp as it brought up all interfaces (the router took
forever to timeout the ARP entries for interface aliases). so i set about
looking to see why that wasn't happening.
i either missed it, or
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
dean gaudet wrote:
hi...
i ran into some problems recently which would have been avoided if my box
did a gratuitous arp as it brought up all interfaces (the router took
forever to timeout the ARP entries for interface aliases). so i
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
dean gaudet wrote:
On Sun, 26 Nov 2006, James Courtier-Dutton wrote:
dean gaudet wrote:
hi...
i ran into some problems recently which would have been avoided if my
box
did a gratuitous arp as it brought up all
fwiw i also brought the TCP_DEFER_ACCEPT problems up the end of last year:
http://www.mail-archive.com/netdev@vger.kernel.org/msg28916.html
it's possible the final message in that thread is how we should define the
behaviour, i haven't tried the TCP_SYNCNT idea though.
-dean
-
To unsubscribe
14 matches
Mail list logo
