* Re: tcp bw in 2.6
From: John Heffner @ 2007-10-02 18:29 UTC (permalink / raw)
To: lm, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002150935.GC17418@bitmover.com>
Larry McVoy wrote:
> On Tue, Oct 02, 2007 at 06:52:54PM +0800, Herbert Xu wrote:
>>> One of my clients also has gigabit so I played around with just that
>>> one and it (itanium running hpux w/ broadcom gigabit) can push the load
>>> as well. One weird thing is that it is dependent on the direction the
>>> data is flowing. If the hp is sending then I get 46MB/sec, if linux is
>>> sending then I get 18MB/sec. Weird. Linux is debian, running
>> First of all check the CPU load on both sides to see if either
>> of them is saturating. If the CPU's fine then look at the tcpdump
>> output to see if both receivers are using the same window settings.
>
> tcpdump is a good idea, take a look at this. The window starts out
> at 46 and never opens up in my test case, but in the rsh case it
> starts out the same but does open up. Ideas?
(Binary tcpdumps are always better than ascii.)
The window on the sender (linux box) starts at 46. It doesn't open up,
but it's not receiving data so it doesn't matter, and you don't expect
it to. The HP box always announces a window of 32768.
Looks like you have TSO enabled. Does it behave differently if it's
disabled? I think Rick Jones is on to something with the HP ack
avoidance. Looks like a pretty low ack ratio, and it might not be
interacting well with TSO, especially at such a small window size.
-John
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 18:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Larry McVoy, Ben Greear, Herbert Xu, torvalds, davem, wscott,
netdev
In-Reply-To: <20071002105423.5d61a727@freepuppy.rosehill>
> Make sure you don't have slab debugging turned on. It kills performance.
It's a stock debian kernel, so unless they turn it on it's off.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 18:40 UTC (permalink / raw)
To: Rick Jones; +Cc: Larry McVoy, Linus Torvalds, davem, wscott, netdev
In-Reply-To: <4702878B.4040102@hp.com>
On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
> has anyone already asked whether link-layer flow-control is enabled?
I doubt it, the same test works fine in one direction and poorly in the other.
Wouldn't the flow control squelch either way?
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* RE: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24
From: Sean Hefty @ 2007-10-02 18:50 UTC (permalink / raw)
To: 'Roland Dreier'; +Cc: netdev, linux-kernel, general
In-Reply-To: <adaprzxgyoi.fsf@cisco.com>
>Umm... this is a difficult situation for me to merge the changes then.
>We're changing the CM retry behavior blind here. How do we know that
>the MRA changes don't make the scalability issue worse?
What's currently upstream doesn't work for Intel MPI on our larger clusters.
The connection requests time out on the active side before the passive side can
respond.
The OFED release works because it provides a kernel patch to make the timeout a
module parameter. I'm trying to avoid adding a module parameter, and the MRA is
designed for this situation.
I tested this by simulating a slow passive side responder, and it worked as
expected for those tests. Using an MRA does add another MAD to the CM exchange,
which is why it is sent only after seeing a duplicate request. Alternatively,
we can take the OFED module parameter patch.
- Sean
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 19:07 UTC (permalink / raw)
To: John Heffner; +Cc: lm, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <47028DEF.5070009@psc.edu>
> Looks like you have TSO enabled. Does it behave differently if it's
> disabled?
It cranks the interrupts/sec up to 8K instead of 5K. No difference in
performance other than that.
> I think Rick Jones is on to something with the HP ack avoidance.
I sincerely doubt it. I'm only using the HP box because it has gigabit
so it's a single connection. I can produce almost identical results by
doing the same sorts of tests with several linux clients. One direction
goes fast and the other goes slow.
3x performance difference depending on the direction of data flow:
# Server is receiving, goes fast
$ for i in 22 24 25 26; do rsh -n glibc$i dd if=/dev/zero|dd of=/dev/null & done
load free cach swap pgin pgou dk0 dk1 dk2 dk3 ipkt opkt int ctx usr sys idl
0.98 0 0 0 0 0 0 0 0 0 30K 15K 8.1K 68K 12 66 22
0.98 0 0 0 0 0 0 0 0 0 29K 15K 8.2K 67K 11 64 25
0.98 0 0 0 0 0 0 0 0 0 29K 15K 8.2K 67K 12 66 22
# Server is sending, goes slow
$ for i in 22 24 25 26; do dd if=/dev/zero|rsh glibc$i dd of=/dev/null & done
load free cach swap pgin pgou dk0 dk1 dk2 dk3 ipkt opkt int ctx usr sys idl
1.06 0 0 0 0 0 0 0 0 0 5.0K 10K 4.4K 8.4K 21 17 62
0.97 0 0 0 0 0 0 0 0 0 5.1K 10K 4.4K 8.9K 2 15 83
0.97 0 0 0 0 0 0 0 0 0 5.0K 10K 4.4K 8.6K 21 26 53
$ for i in 22 24 25 26; do rsh glibc$i cat /etc/motd; done | grep Welcome
Welcome to redhat71.bitmover.com, a 2Ghz Athlon running Red Hat 7.1.
Welcome to glibc24.bitmover.com, a 1.2Ghz Athlon running SUSE 10.1.
Welcome to glibc25.bitmover.com, a 2Ghz Athlon running Fedora Core 6
Welcome to glibc26.bitmover.com, a 2Ghz Athlon running Fedora Core 7
$ for i in 22 24 25 26; do rsh glibc$i uname -r; done
2.4.2-2
2.6.16.13-4-default
2.6.18-1.2798.fc6
2.6.22.4-65.fc7
No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it
has everything to do with the direction the data is flowing.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* [IPv6] Fix ICMPv6 redirect handling with target multicast address
From: Brian Haley @ 2007-10-02 19:18 UTC (permalink / raw)
To: David Miller, YOSHIFUJI Hideaki; +Cc: netdev@vger.kernel.org, David Stevens
In-Reply-To: <46FD2B37.6040502@hp.com>
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
When the ICMPv6 Target address is multicast, Linux processes the
redirect instead of dropping it. The problem is in this code in
ndisc_redirect_rcv():
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
} else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
ND_PRINTK2(KERN_WARNING
"ICMPv6 Redirect: target address is not
link-local.\n");
return;
}
This second check will succeed if the Target address is, for example,
FF02::1 because it has link-local scope. Instead, it should be checking
if it's a unicast link-local address, as stated in RFC 2461/4861 Section
8.1:
- The ICMP Target Address is either a link-local address (when
redirected to a router) or the same as the ICMP Destination
Address (when redirected to the on-link destination).
I know this doesn't explicitly say unicast link-local address, but it's
implied.
This bug is preventing Linux kernels from achieving IPv6 Logo Phase II
certification because of a recent error that was found in the TAHI test
suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the
multicast address in the Destination field instead of Target field, so
we were passing the test. This won't be the case anymore.
The patch below fixes this problem, and also fixes ndisc_send_redirect()
to not send an invalid redirect with a multicast address in the Target
field. I re-ran the TAHI Neighbor Discovery section to make sure Linux
passes all 245 tests now.
-Brian
Signed-off-by: Brian Haley <brian.haley@hp.com>
[-- Attachment #2: ipv6.redirect.patch --]
[-- Type: text/x-patch, Size: 897 bytes --]
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 74c4d8d..a0a6406 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -1267,7 +1267,8 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
if (ipv6_addr_equal(dest, target)) {
on_link = 1;
- } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
+ } else if (ipv6_addr_type(target) !=
+ (IPV6_ADDR_UNICAST|IPV6_ADDR_LINKLOCAL)) {
ND_PRINTK2(KERN_WARNING
"ICMPv6 Redirect: target address is not link-local.\n");
return;
@@ -1343,7 +1344,7 @@ void ndisc_send_redirect(struct sk_buff *skb, struct neighbour *neigh,
}
if (!ipv6_addr_equal(&ipv6_hdr(skb)->daddr, target) &&
- !(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
+ ipv6_addr_type(target) != (IPV6_ADDR_UNICAST|IPV6_ADDR_LINKLOCAL)) {
ND_PRINTK2(KERN_WARNING
"ICMPv6 Redirect: target address is not link-local.\n");
return;
^ permalink raw reply related
* Re: tcp bw in 2.6
From: Linus Torvalds @ 2007-10-02 19:27 UTC (permalink / raw)
To: Larry McVoy; +Cc: Herbert Xu, davem, wscott, netdev
In-Reply-To: <20071002150935.GC17418@bitmover.com>
On Tue, 2 Oct 2007, Larry McVoy wrote:
>
> tcpdump is a good idea, take a look at this. The window starts out
> at 46 and never opens up in my test case, but in the rsh case it
> starts out the same but does open up. Ideas?
I don't think that's an issue, since you only send one way. The window
opening up only matters for the receiver. Also, you missed the "wscale=7"
at the beginning, so the window of "46" looks like it actually is 5888 (ie
fits four segments - and it's not grown because it never gets any data).
However, I think this is some strange TSO artifact:
...
> 08:08:18.843942 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 48181:64241(16060) ack 0 win 46
> 08:08:18.844681 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 48181 win 32768
> 08:08:18.844690 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: P 64241:80301(16060) ack 0 win 46
> 08:08:18.845556 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 64241 win 32768
> 08:08:18.845566 IP work-cluster.bitmover.com.31235 > hp-ia64.bitmover.com.49614: . 80301:96361(16060) ack 0 win 46
> 08:08:18.846304 IP hp-ia64.bitmover.com.49614 > work-cluster.bitmover.com.31235: . ack 80301 win 32768
...
We see a single packet containing 16060 bytes, which seems to be because
of TSO on the sending side (you did your tcpdump on the sender, no?), so
it will actually be broken up into 11 1460-byte regular frames by the
network card, since they started out agreeing on a standard 1460-byte MSS.
So the above is not a jumbo frame, it just kind of looks like one when you
capture it on the sender side.
And maybe a 32kB window is not big enough when it causes the networking
code to basically just have a single packet outstanding.
I also would have expected more ACK's from the HP box. It's been a long
time since I did TCP, but I thought the rule was still that you were
supposed to ACK at least every other full frame - but the HP box is acking
roughly every 16K (and it's *not* always at TSO boundaries: the earlier
ACK's in the sequence are at 1460-byte packet boundaries, but it does seem
to end up getting into that pattern later on).
So I'm wondering if we get into some bad pattern with the networking code
trying to make big TSO packets for e1000, but because they are *so* big
that there's only room for two such packets per window, you don't get into
any smooth pattern with lots of outstanding packets, but it starts
stuttering.
Larry, try turning off TSO. Or rather, make the kernel use a smaller limit
for the large packets. The easiest way to do that should be to just change
the value in /proc/sys/net/ipv4/tcp_tso_win_divisor. It defaults to 3, try
doing
echo 6 > /proc/sys/net/ipv4/tcp_tso_win_divisor
and see if that changes anything.
And maybe I'm just whistling in the dark. In fact, it looks like for you
it's not 3, but 2 (window of 32768, but the TSO frames are half the size).
So maybe I'm just totally confused and I'm not reading that tcp dump
correctly at all!
Linus
^ permalink raw reply
* Re: tcp bw in 2.6
From: Linus Torvalds @ 2007-10-02 19:29 UTC (permalink / raw)
To: Larry McVoy; +Cc: John Heffner, Herbert Xu, davem, wscott, netdev
In-Reply-To: <20071002190742.GC29944@bitmover.com>
On Tue, 2 Oct 2007, Larry McVoy wrote:
>
> No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it
> has everything to do with the direction the data is flowing.
Can you tcpdump both cases and send snippets (both of steady-state, and
the initial connect)?
Linus
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 19:33 UTC (permalink / raw)
To: Larry McVoy, John Heffner, Herbert Xu, torvalds, davem, wscott,
netd
In-Reply-To: <20071002190742.GC29944@bitmover.com>
More data, we've conclusively eliminated the card / cpu from the mix.
We've got 2 ia64 boxes with e1000 interfaces. One box is running
linux 2.6.12 and the other is running hpux 11.
I made sure the linux one was running at gigabit and reran the tests
from the linux/ia64 <=> hp/ia64. Same results, when linux sends
it is slow, when it receives it is fast.
And note carefully: we've removed hpux from the equation, we can do
the same tests from linux to multiple linux clients and see the same
thing, sending from the server is slow, receiving on the server is
fast.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* Re: tcp bw in 2.6
From: Rick Jones @ 2007-10-02 19:47 UTC (permalink / raw)
To: Larry McVoy; +Cc: Linus Torvalds, davem, wscott, netdev
In-Reply-To: <20071002184032.GB29944@bitmover.com>
Larry McVoy wrote:
> On Tue, Oct 02, 2007 at 11:01:47AM -0700, Rick Jones wrote:
>
>>has anyone already asked whether link-layer flow-control is enabled?
>
>
> I doubt it, the same test works fine in one direction and poorly in the other.
> Wouldn't the flow control squelch either way?
While I am often guilty of it, a wise old engineer tried to teach me that the
proper spelling is ass-u-me :) I wouldn't count on it hitting in both
directions, depends on the specifics of the situation.
WRT the HP-UX ACK avoidance heuristic, the default HP-UX socket buffer/window is
32768, and tcp_deferred_ack_max defaults to 22. That isn't really all that good
a combination - with a window of 32768 11 for the deferred ack would be better.
You could also go ahead and try it with a value of 2. Or, bump the window
size defaults - tcp_recv_hiwater_def and tcp_xmit_hiwater_def - to say 65535 or
128K or something - or use the setsockopt() calls to effect that.
rick jones
^ permalink raw reply
* Re: tcp bw in 2.6
From: Rick Jones @ 2007-10-02 19:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Larry McVoy, Herbert Xu, davem, wscott, netdev
In-Reply-To: <alpine.LFD.0.999.0710021146580.3579@woody.linux-foundation.org>
> I also would have expected more ACK's from the HP box. It's been a long
> time since I did TCP, but I thought the rule was still that you were
> supposed to ACK at least every other full frame - but the HP box is acking
> roughly every 16K (and it's *not* always at TSO boundaries: the earlier
> ACK's in the sequence are at 1460-byte packet boundaries, but it does seem
> to end up getting into that pattern later on).
Drift...
The RFC's say "SHOULD" (emphasis theirs) rather than "MUST."
Both HP-UX and Solaris have rather robust ACK avoidance heuristics to cut-down
on the CPU overhead of bulk transfers. (That they both have them stems from
their being cousins, sharing a common TCP stack ancestor long ago - both of
course have been diverging since then).
rick jones
^ permalink raw reply
* Re: tcp bw in 2.6
From: John Heffner @ 2007-10-02 19:53 UTC (permalink / raw)
To: lm, John Heffner, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002193304.GA31611@bitmover.com>
Larry McVoy wrote:
> More data, we've conclusively eliminated the card / cpu from the mix.
> We've got 2 ia64 boxes with e1000 interfaces. One box is running
> linux 2.6.12 and the other is running hpux 11.
>
> I made sure the linux one was running at gigabit and reran the tests
> from the linux/ia64 <=> hp/ia64. Same results, when linux sends
> it is slow, when it receives it is fast.
>
> And note carefully: we've removed hpux from the equation, we can do
> the same tests from linux to multiple linux clients and see the same
> thing, sending from the server is slow, receiving on the server is
> fast.
I think I'm still missing some basic data here (probably because this
thread did not originate on netdev). Let me try to nail down some of
the basics. You have a linux ia64 box (running 2.6.12 or 2.6.18?) that
sends slowly, and receives faster, but not quite a 1 Gbps? And this is
true regardless of which peer it sends or receives from? And the
behavior is different depending on which kernel? How, and which kernel
versions? Do you have other hardware running the same kernel that
behaves the same or differently?
Have you done ethernet cable tests? Have you tried measuring the udp
sending rate? (Iperf can do this.) Are there any error counters on the
interface?
-John
^ permalink raw reply
* [PATCH] - trivial - Correct printk with PFX before KERN_ in drivers/net/wireless/bcm43xx/bcm43xx_wx.c
From: Joe Perches @ 2007-10-02 19:57 UTC (permalink / raw)
To: Larry Finger, Stefano Brivio
Cc: Andrew Morton, Jeff Garzik, linux-wireless, netdev
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index d6d9413..6acfdc4 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -444,7 +444,7 @@ static int bcm43xx_wx_set_xmitpower(struct net_device *net_dev,
u16 maxpower;
if ((data->txpower.flags & IW_TXPOW_TYPE) != IW_TXPOW_DBM) {
- printk(PFX KERN_ERR "TX power not in dBm.\n");
+ printk(KERN_ERR PFX "TX power not in dBm.\n");
return -EOPNOTSUPP;
}
^ permalink raw reply related
* Re: 2.6.23-rc8-mm2 - tcp_fastretrans_alert() WARNING
From: Ilpo Järvinen @ 2007-10-02 20:06 UTC (permalink / raw)
To: Cedric Le Goater; +Cc: Andrew Morton, LKML, Netdev, David Miller
In-Reply-To: <Pine.LNX.4.64.0710021310530.27745@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 9192 bytes --]
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
> I'm currently out of ideas where it could come from... so lets try
> brute-force checking as your test case is not very high-speed... This
> could hide it though... :-(
>
> Please put the patch below on top of clean rc8-mm2 (it includes the patch
> I gave you last time) and try to reproduce.... These counter bugs can
> survive for sometime until !sacked_out condition occurs, so the patch
> below tries to find that out when inconsisteny occurs for the first time
> regardless of sacked_out (I also removed some statics which hopefully
> reduces compiler inlining for easier reading of the output). I tried this
> myself (except for verify()s in frto funcs and minor printout
> modifications), didn't trigger for me.
In case you haven't yet get started (or it's easy enough to replace),
please use the one below instead (I forgot one counter from printout
in the last patch, which might turn out useful...).
--
i.
---
include/net/tcp.h | 3 +
net/ipv4/tcp_input.c | 23 +++++++++--
net/ipv4/tcp_ipv4.c | 103 +++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv4/tcp_output.c | 6 ++-
4 files changed, 129 insertions(+), 6 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 991ccdc..54a0d91 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -43,6 +43,9 @@
#include <linux/seq_file.h>
+extern void tcp_verify_fackets(struct sock *sk);
+extern void tcp_print_queue(struct sock *sk);
+
extern struct inet_hashinfo tcp_hashinfo;
extern atomic_t tcp_orphan_count;
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e22ffe7..1d7367d 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1140,7 +1140,7 @@ static int tcp_check_dsack(struct tcp_sock *tp, struct sk_buff *ack_skb,
return dup_sack;
}
-static int
+int
tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_una)
{
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -1160,6 +1160,8 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
int first_sack_index;
if (!tp->sacked_out) {
+ if (WARN_ON(tp->fackets_out))
+ tcp_print_queue(sk);
tp->fackets_out = 0;
tp->highest_sack = tp->snd_una;
}
@@ -1420,6 +1422,7 @@ tcp_sacktag_write_queue(struct sock *sk, struct sk_buff *ack_skb, u32 prior_snd_
}
}
}
+ tcp_verify_fackets(sk);
/* Check for lost retransmit. This superb idea is
* borrowed from "ratehalving". Event "C".
@@ -1632,13 +1635,14 @@ void tcp_enter_frto(struct sock *sk)
tcp_set_ca_state(sk, TCP_CA_Disorder);
tp->high_seq = tp->snd_nxt;
tp->frto_counter = 1;
+ tcp_verify_fackets(sk);
}
/* Enter Loss state after F-RTO was applied. Dupack arrived after RTO,
* which indicates that we should follow the traditional RTO recovery,
* i.e. mark everything lost and do go-back-N retransmission.
*/
-static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
+void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
@@ -1675,6 +1679,7 @@ static void tcp_enter_frto_loss(struct sock *sk, int allowed_segments, int flag)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->snd_cwnd = tcp_packets_in_flight(tp) + allowed_segments;
tp->snd_cwnd_cnt = 0;
@@ -1753,6 +1758,7 @@ void tcp_enter_loss(struct sock *sk, int how)
}
}
tcp_verify_left_out(tp);
+ tcp_verify_fackets(sk);
tp->reordering = min_t(unsigned int, tp->reordering,
sysctl_tcp_reordering);
@@ -2308,7 +2314,7 @@ static void tcp_mtup_probe_success(struct sock *sk, struct sk_buff *skb)
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void
+void
tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2322,8 +2328,11 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
if (!tp->packets_out)
tp->sacked_out = 0;
- if (WARN_ON(!tp->sacked_out && tp->fackets_out))
+ if (WARN_ON(!tp->sacked_out && tp->fackets_out)) {
+ printk(KERN_ERR "TCP %d\n", tcp_is_reno(tp));
+ tcp_print_queue(sk);
tp->fackets_out = 0;
+ }
/* Now state machine starts.
* A. ECE, hence prohibit cwnd undoing, the reduction is required. */
@@ -2333,6 +2342,8 @@ tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
/* B. In all the states check for reneging SACKs. */
if (tp->sacked_out && tcp_check_sack_reneging(sk))
return;
+
+ tcp_verify_fackets(sk);
/* C. Process data loss notification, provided it is valid. */
if ((flag&FLAG_DATA_LOST) &&
@@ -2572,7 +2583,7 @@ static u32 tcp_tso_acked(struct sock *sk, struct sk_buff *skb)
* is before the ack sequence we can discard it as it's confirmed to have
* arrived at the other end.
*/
-static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p)
+int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p)
{
struct tcp_sock *tp = tcp_sk(sk);
const struct inet_connection_sock *icsk = inet_csk(sk);
@@ -2694,6 +2705,8 @@ static int tcp_clean_rtx_queue(struct sock *sk, s32 *seq_rtt_p)
ca_ops->pkts_acked(sk, pkts_acked, rtt_us);
}
}
+ tcp_verify_fackets(sk);
+
#if FASTRETRANS_DEBUG > 0
BUG_TRAP((int)tp->sacked_out >= 0);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 7fed0a6..c38acc1 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -108,6 +108,109 @@ struct inet_hashinfo __cacheline_aligned tcp_hashinfo = {
.lhash_wait = __WAIT_QUEUE_HEAD_INITIALIZER(tcp_hashinfo.lhash_wait),
};
+void tcp_print_queue(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct sk_buff *skb;
+ char s[50+1];
+ char i[50+1];
+ int idx = 0;
+ u32 hs = tp->highest_sack;
+
+ if (!tp->sacked_out)
+ hs = tp->snd_una;
+
+ tcp_for_write_queue(skb, sk) {
+ if (skb == tcp_send_head(sk))
+ break;
+
+ if (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED) {
+ if (skb->len < tp->mss_cache)
+ s[idx] = 's';
+ else
+ s[idx] = 'S';
+ } else {
+ s[idx] = '-';
+ }
+ if ((TCP_SKB_CB(skb)->seq == hs) && (tp->fastpath_skb_hint == skb))
+ i[idx] = 'x';
+ else if (tp->fastpath_skb_hint == skb)
+ i[idx] = 'f';
+ else if (TCP_SKB_CB(skb)->seq == hs)
+ i[idx] = 'h';
+ else
+ i[idx] = ' ';
+
+ if (++idx >= 50) {
+ s[idx] = 0;
+ i[idx] = 0;
+ printk(KERN_ERR "TCP wq(s) %s\n", s);
+ printk(KERN_ERR "TCP wq(i) %s\n", i);
+ idx = 0;
+ }
+ }
+ if (idx) {
+ s[idx] = '<';
+ s[idx+1] = 0;
+ i[idx] = '<';
+ i[idx+1] = 0;
+ printk(KERN_ERR "TCP wq(s) %s\n", s);
+ printk(KERN_ERR "TCP wq(i) %s\n", i);
+ }
+ printk(KERN_ERR "s%u f%u (%u) p%u seq: su%u hs%u sn%u (%u)\n",
+ tp->sacked_out, tp->fackets_out, tp->packets_out,
+ tp->fastpath_cnt_hint,
+ tp->snd_una, tp->highest_sack, tp->snd_nxt,
+ ((tp->fastpath_skb_hint == NULL) ? 0 :
+ TCP_SKB_CB(tp->fastpath_skb_hint)->seq));
+}
+
+void tcp_verify_fackets(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct sk_buff *skb;
+ u32 fackets = 0;
+ int hisack_valid = 0;
+ int err = 0;
+
+ if (tcp_is_reno(tp))
+ return;
+
+ if (!tp->sacked_out) {
+ if (WARN_ON(tp->fackets_out))
+ err = 1;
+ else if (tp->fastpath_skb_hint == NULL)
+ return;
+ }
+
+ /* ...expensive processing here... */
+ tcp_for_write_queue(skb, sk) {
+ if (skb == tcp_send_head(sk))
+ break;
+
+ if (tp->sacked_out && (TCP_SKB_CB(skb)->seq == tp->highest_sack)) {
+ hisack_valid = 1;
+ if (WARN_ON(tp->fackets_out != fackets + tcp_skb_pcount(skb)))
+ err = 1;
+ }
+
+ if (skb == tp->fastpath_skb_hint)
+ if (WARN_ON(fackets != tp->fastpath_cnt_hint))
+ err = 1;
+
+ if (WARN_ON((fackets > tp->fackets_out) && (TCP_SKB_CB(skb)->sacked & TCPCB_SACKED_ACKED)))
+ err = 1;
+
+ fackets += tcp_skb_pcount(skb);
+ }
+
+ if (WARN_ON(tp->sacked_out && !hisack_valid))
+ err = 1;
+
+ if (err)
+ tcp_print_queue(sk);
+}
+
static int tcp_v4_get_port(struct sock *sk, unsigned short snum)
{
return inet_csk_get_port(&tcp_hashinfo, sk, snum,
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 6199abe..4c70caf 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -773,6 +773,8 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len, unsigned int mss
tcp_verify_left_out(tp);
}
tcp_adjust_fackets_out(tp, skb, diff);
+
+ tcp_verify_fackets(sk);
}
/* Link BUFF into the send queue. */
@@ -1688,7 +1690,7 @@ u32 __tcp_select_window(struct sock *sk)
}
/* Attempt to collapse two adjacent SKB's during retransmission. */
-static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *skb, int mss_now)
+void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *skb, int mss_now)
{
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *next_skb = tcp_write_queue_next(sk, skb);
@@ -1764,6 +1766,8 @@ static void tcp_retrans_try_collapse(struct sock *sk, struct sk_buff *skb, int m
if (tp->fastpath_skb_hint == next_skb)
tp->fastpath_skb_hint = skb;
+ tcp_verify_fackets(sk);
+
sk_stream_free_skb(sk, next_skb);
}
}
--
1.5.0.6
^ permalink raw reply related
* Re: MSI interrupts and disable_irq
From: Manfred Spraul @ 2007-10-02 19:03 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Jeff Garzik, nedev, linux-kernel
In-Reply-To: <46FC15A9.1070803@nvidia.com>
Ayaz Abdulla wrote:
> I am trying to track down a forcedeth driver issue described by bug
> 9047 in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy
> load). I added a patch to synchronize the timer handlers so that one
> handler doesn't accidently enable the IRQ while another timer handler
> is running (see attachment 'Add timer lock' in bug report) and for
> other processing protection.
>
> However, the system still had an Oops. So I added a lock around the
> nv_rx_process_optimized() and the Oops has not happened (see
> attachment 'New patch for locking' in bug report). This would imply a
> synchronization issue. However, the only callers of that function are
> the IRQ handler and the timer handlers (in non-NAPI case). The timer
> handlers use disable_irq so that the IRQ handler does not contend
> with them. It looks as if disable_irq is not working properly.
Either disable_irq() is not working properly or interrupts are nested,
i.e. the irq handler is called again while running.
Which timer handler do you mean? I only see disable_irq() in the
configuration paths (set mtu, change ring size, ...) and in the tx
timeout case.
Neither one should happen during normal operation.
--
Manfred
^ permalink raw reply
* Re: tcp bw in 2.6
From: Larry McVoy @ 2007-10-02 20:14 UTC (permalink / raw)
To: John Heffner; +Cc: lm, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <4702A1B6.5020505@psc.edu>
> I think I'm still missing some basic data here (probably because this
> thread did not originate on netdev). Let me try to nail down some of
> the basics. You have a linux ia64 box (running 2.6.12 or 2.6.18?) that
> sends slowly, and receives faster, but not quite a 1 Gbps? And this is
> true regardless of which peer it sends or receives from? And the
> behavior is different depending on which kernel? How, and which kernel
> versions? Do you have other hardware running the same kernel that
> behaves the same or differently?
just got off the phone with Linus and he thinks it is the side that does
the accept is the problem side, i.e., if you are the server, you do the
accept, and you send the data, you'll go slow. But as I'm writing this
I realize he's wrong, because it is the combination of accept & send.
accept & recv goes fast.
A trivial way to see the problem is to take two linux boxes, on each
apt-get install rsh-client rsh-server
set up your .rhosts,
and then do
dd if=/dev/zero count=100000 | rsh OTHER_BOX dd of=/dev/null
rsh OTHER_BOX dd if=/dev/zero count=100000 | dd of=/dev/null
See if you get balanced results. For me, I get 45MB/sec one way, and
15-19MB/sec the other way.
I've tried the same test linux - linux and linux - hpux. Same results.
The test setup I have is
work: 2ghz x 2 Athlons, e1000, 2.6.18
ia64: 900mhz Itanium, e1000, 2.6.12
hp-ia64:900mhz Itanium, e1000, hpux 11
glibc*: 1-2ghz athlons running various linux releases
all connected through a netgear 724T 10/100/1000 switch (a linksys showed
identical results).
I tested
work <-> hp-ia64
work <-> ia64
ia64 <-> hp-ia64
and in all cases, one direction worked fast and the other didn't.
It would be good if people tried the same simple test. You have to
use rsh, ssh will slow things down way too much.
Alternatively, take your favorite test programs, such as John's,
and make a second pair that reverses the direction the data is
sent. So one pair is server sends, the other is server receives,
try both. That's where we started, BitKeeper, my stripped down test,
and John's test all exhibit the same behavior. And the rsh test
is just a really simple way to demonstrate it.
Wayne, Linus asked for tcp dumps from just one side, with the first 100
packets and then wait 10 seconds or so for the window to open up, and then
a snap shot of the another 100 packets. Do that for both directions
and send them to the list. Can you do that? I want to get lunch, I'm
starving.
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com
^ permalink raw reply
* [PATCH 2.6.24] tg3: fix ethtool autonegotiate flags
From: Andy Gospodarek @ 2007-10-02 20:16 UTC (permalink / raw)
To: mchan, davem, jeff, netdev
I recently noticed that when calling:
# ethtool -s eth0 autoneg on
on a 5722 (though I'm sure it's not specific to that card) that
subsequent checks of the cards status looked like this:
# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: No <---- This seems odd?!?
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes
I noticed that the following commit:
commit 3600d918d870456ea8e7bb9d47f327de5c20f3d6
Author: Michael Chan <mchan@broadcom.com>
Date: Thu Dec 7 00:21:48 2006 -0800
[TG3]: Allow partial speed advertisement.
Honor the advertisement bitmask from ethtool. We used to always
advertise the full capability when autoneg was set to on.
changed things around so that ethtool speed settings were strictly
followed. Unfortunately ethtool doesn't seem to set ADVERTISED_Autoneg
in the advertising field (and maybe it shouldn't have to). I'd vote
that it should be fixed there, but it should also be added here just in
case someone using ethtool ioctls in their own application gets what
they want.
Adding that flag in tg3_set_settings seemed like the most logical place
since the driver works fine on boot. This is just an issue when
re-enabling autonegotiation, so we should probably nip it there.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
tg3.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index d4ac6e9..0a414be 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -8070,7 +8070,8 @@ static int tg3_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
tp->link_config.autoneg = cmd->autoneg;
if (cmd->autoneg == AUTONEG_ENABLE) {
- tp->link_config.advertising = cmd->advertising;
+ tp->link_config.advertising = (cmd->advertising |
+ ADVERTISED_Autoneg);
tp->link_config.speed = SPEED_INVALID;
tp->link_config.duplex = DUPLEX_INVALID;
} else {
^ permalink raw reply related
* Re: tcp bw in 2.6
From: David Miller @ 2007-10-02 20:31 UTC (permalink / raw)
To: torvalds; +Cc: lm, jheffner, herbert, wscott, netdev
In-Reply-To: <alpine.LFD.0.999.0710021228540.3579@woody.linux-foundation.org>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 2 Oct 2007 12:29:50 -0700 (PDT)
> On Tue, 2 Oct 2007, Larry McVoy wrote:
> >
> > No HP in the mix. It's got nothing to do with hp, nor to do with rsh, it
> > has everything to do with the direction the data is flowing.
>
> Can you tcpdump both cases and send snippets (both of steady-state, and
> the initial connect)?
Another thing I'd like to see is if something more recent than 2.6.18
also reproduces the problem.
It could be just some bug we've fixed in the past year :)
^ permalink raw reply
* Re: tcp bw in 2.6
From: David Miller @ 2007-10-02 20:33 UTC (permalink / raw)
To: torvalds; +Cc: lm, herbert, wscott, netdev
In-Reply-To: <alpine.LFD.0.999.0710021146580.3579@woody.linux-foundation.org>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, 2 Oct 2007 12:27:53 -0700 (PDT)
> We see a single packet containing 16060 bytes, which seems to be because
> of TSO on the sending side (you did your tcpdump on the sender, no?), so
> it will actually be broken up into 11 1460-byte regular frames by the
> network card, since they started out agreeing on a standard 1460-byte MSS.
> So the above is not a jumbo frame, it just kind of looks like one when you
> capture it on the sender side.
>
> And maybe a 32kB window is not big enough when it causes the networking
> code to basically just have a single packet outstanding.
We fixed a lot of bugs in TSO last year.
It would be really great to see numbers with a more recent kernel
than 2.6.18
^ permalink raw reply
* Re: [IPv6] Fix ICMPv6 redirect handling with target multicast address
From: David Stevens @ 2007-10-02 20:39 UTC (permalink / raw)
To: Brian Haley
Cc: David Miller, netdev@vger.kernel.org, netdev-owner,
YOSHIFUJI Hideaki
In-Reply-To: <4702997D.6020208@hp.com>
Brian,
ipv6_addr_type() returns a mask, so checking for equality will
fail to
match if any other (irrelevant) attributes are set. How about using
bitwise
operators for that? Also, the error message is no longer descriptive of
the
failure if it's a link-local multicast, but you could make it "target
address is not
link-local unicast.\n" (in both places).
+-DLS
^ permalink raw reply
* Re: tcp bw in 2.6
From: Rick Jones @ 2007-10-02 20:40 UTC (permalink / raw)
To: Larry McVoy; +Cc: John Heffner, Herbert Xu, torvalds, davem, wscott, netdev
In-Reply-To: <20071002201420.GE29944@bitmover.com>
[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]
> Alternatively, take your favorite test programs, such as John's,
> and make a second pair that reverses the direction the data is
> sent. So one pair is server sends, the other is server receives,
> try both. That's where we started, BitKeeper, my stripped down test,
> and John's test all exhibit the same behavior. And the rsh test
> is just a really simple way to demonstrate it.
Netperf TCP_STREAM - server receives. TCP_MAERTS (STREAM backwards) - server sends:
[root@hpcpc106 ~]# netperf -H 192.168.2.107
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.107
(192.168.2.107) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 87380 87380 10.17 941.46
[root@hpcpc106 ~]# netperf -H 192.168.2.107 -t TCP_MAERTS
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.107
(192.168.2.107) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 87380 87380 10.15 941.35
The above took all the defaults for socket buffers and such.
[root@hpcpc106 ~]# uname -a
Linux hpcpc106.cup.hp.com 2.6.18-8.el5 #1 SMP Fri Jan 26 14:16:09 EST 2007 ia64
ia64 ia64 GNU/Linux
[root@hpcpc106 ~]# ethtool -i eth2
driver: e1000
version: 7.2.7-k2-NAPI
firmware-version: N/A
bus-info: 0000:06:01.0
between a pair of 1.6 GHz itanium2 montecito rx2660's with a dual-port HP A9900A
(Intel 82546GB) in slot 3 of the io cage on each. Connection is actually
back-to-back rather than through a switch. I'm afraid I've nothing older installed.
sysctl settings attached
Where I do have things connected via a switch (HP ProCurve 3500 IIRC, perhaps a
2724) is through the core BCM5704:
[root@hpcpc106 netperf2_work]# netperf -H hpcpc107
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to hpcpc107.cup.hp.com
(16.89.84.107) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 87380 87380 10.03 941.41
[root@hpcpc106 netperf2_work]# netperf -H hpcpc107 -t TCP_MAERTS
TCP MAERTS TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to hpcpc107.cup.hp.com
(16.89.84.107) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 87380 87380 10.03 941.37
[root@hpcpc106 netperf2_work]# ethtool -i eth0
driver: tg3
version: 3.65-rh
firmware-version: 5704-v3.27
bus-info: 0000:01:02.0
rick jones
[-- Attachment #2: sysctl.net.txt --]
[-- Type: text/plain, Size: 17816 bytes --]
net.ipv6.conf.eth2.router_probe_interval = 60
net.ipv6.conf.eth2.accept_ra_rtr_pref = 1
net.ipv6.conf.eth2.accept_ra_pinfo = 1
net.ipv6.conf.eth2.accept_ra_defrtr = 1
net.ipv6.conf.eth2.max_addresses = 16
net.ipv6.conf.eth2.max_desync_factor = 600
net.ipv6.conf.eth2.regen_max_retry = 5
net.ipv6.conf.eth2.temp_prefered_lft = 86400
net.ipv6.conf.eth2.temp_valid_lft = 604800
net.ipv6.conf.eth2.use_tempaddr = 0
net.ipv6.conf.eth2.force_mld_version = 0
net.ipv6.conf.eth2.router_solicitation_delay = 1
net.ipv6.conf.eth2.router_solicitation_interval = 4
net.ipv6.conf.eth2.router_solicitations = 3
net.ipv6.conf.eth2.dad_transmits = 1
net.ipv6.conf.eth2.autoconf = 1
net.ipv6.conf.eth2.accept_redirects = 1
net.ipv6.conf.eth2.accept_ra = 1
net.ipv6.conf.eth2.mtu = 1500
net.ipv6.conf.eth2.hop_limit = 64
net.ipv6.conf.eth2.forwarding = 0
net.ipv6.conf.eth0.router_probe_interval = 60
net.ipv6.conf.eth0.accept_ra_rtr_pref = 1
net.ipv6.conf.eth0.accept_ra_pinfo = 1
net.ipv6.conf.eth0.accept_ra_defrtr = 1
net.ipv6.conf.eth0.max_addresses = 16
net.ipv6.conf.eth0.max_desync_factor = 600
net.ipv6.conf.eth0.regen_max_retry = 5
net.ipv6.conf.eth0.temp_prefered_lft = 86400
net.ipv6.conf.eth0.temp_valid_lft = 604800
net.ipv6.conf.eth0.use_tempaddr = 0
net.ipv6.conf.eth0.force_mld_version = 0
net.ipv6.conf.eth0.router_solicitation_delay = 1
net.ipv6.conf.eth0.router_solicitation_interval = 4
net.ipv6.conf.eth0.router_solicitations = 3
net.ipv6.conf.eth0.dad_transmits = 1
net.ipv6.conf.eth0.autoconf = 1
net.ipv6.conf.eth0.accept_redirects = 1
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth0.mtu = 1500
net.ipv6.conf.eth0.hop_limit = 64
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.default.router_probe_interval = 60
net.ipv6.conf.default.accept_ra_rtr_pref = 1
net.ipv6.conf.default.accept_ra_pinfo = 1
net.ipv6.conf.default.accept_ra_defrtr = 1
net.ipv6.conf.default.max_addresses = 16
net.ipv6.conf.default.max_desync_factor = 600
net.ipv6.conf.default.regen_max_retry = 5
net.ipv6.conf.default.temp_prefered_lft = 86400
net.ipv6.conf.default.temp_valid_lft = 604800
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.default.force_mld_version = 0
net.ipv6.conf.default.router_solicitation_delay = 1
net.ipv6.conf.default.router_solicitation_interval = 4
net.ipv6.conf.default.router_solicitations = 3
net.ipv6.conf.default.dad_transmits = 1
net.ipv6.conf.default.autoconf = 1
net.ipv6.conf.default.accept_redirects = 1
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.default.mtu = 1280
net.ipv6.conf.default.hop_limit = 64
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.all.router_probe_interval = 60
net.ipv6.conf.all.accept_ra_rtr_pref = 1
net.ipv6.conf.all.accept_ra_pinfo = 1
net.ipv6.conf.all.accept_ra_defrtr = 1
net.ipv6.conf.all.max_addresses = 16
net.ipv6.conf.all.max_desync_factor = 600
net.ipv6.conf.all.regen_max_retry = 5
net.ipv6.conf.all.temp_prefered_lft = 86400
net.ipv6.conf.all.temp_valid_lft = 604800
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.all.force_mld_version = 0
net.ipv6.conf.all.router_solicitation_delay = 1
net.ipv6.conf.all.router_solicitation_interval = 4
net.ipv6.conf.all.router_solicitations = 3
net.ipv6.conf.all.dad_transmits = 1
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.all.mtu = 1280
net.ipv6.conf.all.hop_limit = 64
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.lo.router_probe_interval = 60
net.ipv6.conf.lo.accept_ra_rtr_pref = 1
net.ipv6.conf.lo.accept_ra_pinfo = 1
net.ipv6.conf.lo.accept_ra_defrtr = 1
net.ipv6.conf.lo.max_addresses = 16
net.ipv6.conf.lo.max_desync_factor = 600
net.ipv6.conf.lo.regen_max_retry = 5
net.ipv6.conf.lo.temp_prefered_lft = 86400
net.ipv6.conf.lo.temp_valid_lft = 604800
net.ipv6.conf.lo.use_tempaddr = -1
net.ipv6.conf.lo.force_mld_version = 0
net.ipv6.conf.lo.router_solicitation_delay = 1
net.ipv6.conf.lo.router_solicitation_interval = 4
net.ipv6.conf.lo.router_solicitations = 3
net.ipv6.conf.lo.dad_transmits = 1
net.ipv6.conf.lo.autoconf = 1
net.ipv6.conf.lo.accept_redirects = 1
net.ipv6.conf.lo.accept_ra = 1
net.ipv6.conf.lo.mtu = 16436
net.ipv6.conf.lo.hop_limit = 64
net.ipv6.conf.lo.forwarding = 0
net.ipv6.neigh.eth2.base_reachable_time_ms = 30000
net.ipv6.neigh.eth2.retrans_time_ms = 1000
net.ipv6.neigh.eth2.locktime = 0
net.ipv6.neigh.eth2.proxy_delay = 800
net.ipv6.neigh.eth2.anycast_delay = 1000
net.ipv6.neigh.eth2.proxy_qlen = 64
net.ipv6.neigh.eth2.unres_qlen = 3
net.ipv6.neigh.eth2.gc_stale_time = 60
net.ipv6.neigh.eth2.delay_first_probe_time = 5
net.ipv6.neigh.eth2.retrans_time = 1000
net.ipv6.neigh.eth2.app_solicit = 0
net.ipv6.neigh.eth2.ucast_solicit = 3
net.ipv6.neigh.eth2.mcast_solicit = 3
net.ipv6.neigh.eth0.base_reachable_time_ms = 30000
net.ipv6.neigh.eth0.retrans_time_ms = 1000
net.ipv6.neigh.eth0.locktime = 0
net.ipv6.neigh.eth0.proxy_delay = 800
net.ipv6.neigh.eth0.anycast_delay = 1000
net.ipv6.neigh.eth0.proxy_qlen = 64
net.ipv6.neigh.eth0.unres_qlen = 3
net.ipv6.neigh.eth0.gc_stale_time = 60
net.ipv6.neigh.eth0.delay_first_probe_time = 5
net.ipv6.neigh.eth0.retrans_time = 1000
net.ipv6.neigh.eth0.app_solicit = 0
net.ipv6.neigh.eth0.ucast_solicit = 3
net.ipv6.neigh.eth0.mcast_solicit = 3
net.ipv6.neigh.lo.base_reachable_time_ms = 30000
net.ipv6.neigh.lo.retrans_time_ms = 1000
net.ipv6.neigh.lo.locktime = 0
net.ipv6.neigh.lo.proxy_delay = 800
net.ipv6.neigh.lo.anycast_delay = 1000
net.ipv6.neigh.lo.proxy_qlen = 64
net.ipv6.neigh.lo.unres_qlen = 3
net.ipv6.neigh.lo.gc_stale_time = 60
net.ipv6.neigh.lo.delay_first_probe_time = 5
net.ipv6.neigh.lo.retrans_time = 1000
net.ipv6.neigh.lo.app_solicit = 0
net.ipv6.neigh.lo.ucast_solicit = 3
net.ipv6.neigh.lo.mcast_solicit = 3
net.ipv6.neigh.default.base_reachable_time_ms = 30000
net.ipv6.neigh.default.retrans_time_ms = 1000
net.ipv6.neigh.default.gc_thresh3 = 1024
net.ipv6.neigh.default.gc_thresh2 = 512
net.ipv6.neigh.default.gc_thresh1 = 128
net.ipv6.neigh.default.gc_interval = 30
net.ipv6.neigh.default.locktime = 0
net.ipv6.neigh.default.proxy_delay = 800
net.ipv6.neigh.default.anycast_delay = 1000
net.ipv6.neigh.default.proxy_qlen = 64
net.ipv6.neigh.default.unres_qlen = 3
net.ipv6.neigh.default.gc_stale_time = 60
net.ipv6.neigh.default.delay_first_probe_time = 5
net.ipv6.neigh.default.retrans_time = 1000
net.ipv6.neigh.default.app_solicit = 0
net.ipv6.neigh.default.ucast_solicit = 3
net.ipv6.neigh.default.mcast_solicit = 3
net.ipv6.mld_max_msf = 64
net.ipv6.ip6frag_secret_interval = 600
net.ipv6.ip6frag_time = 60
net.ipv6.ip6frag_low_thresh = 196608
net.ipv6.ip6frag_high_thresh = 262144
net.ipv6.bindv6only = 0
net.ipv6.icmp.ratelimit = 1000
net.ipv6.route.gc_min_interval_ms = 500
net.ipv6.route.min_adv_mss = 1
net.ipv6.route.mtu_expires = 600
net.ipv6.route.gc_elasticity = 0
net.ipv6.route.gc_interval = 30
net.ipv6.route.gc_timeout = 60
net.ipv6.route.gc_min_interval = 0
net.ipv6.route.max_size = 4096
net.ipv6.route.gc_thresh = 1024
net.unix.max_dgram_qlen = 10
net.token-ring.rif_timeout = 600000
net.ipv4.conf.eth3.promote_secondaries = 0
net.ipv4.conf.eth3.force_igmp_version = 0
net.ipv4.conf.eth3.disable_policy = 0
net.ipv4.conf.eth3.disable_xfrm = 0
net.ipv4.conf.eth3.arp_accept = 0
net.ipv4.conf.eth3.arp_ignore = 1
net.ipv4.conf.eth3.arp_announce = 0
net.ipv4.conf.eth3.arp_filter = 1
net.ipv4.conf.eth3.tag = 0
net.ipv4.conf.eth3.log_martians = 0
net.ipv4.conf.eth3.bootp_relay = 0
net.ipv4.conf.eth3.medium_id = 0
net.ipv4.conf.eth3.proxy_arp = 0
net.ipv4.conf.eth3.accept_source_route = 0
net.ipv4.conf.eth3.send_redirects = 1
net.ipv4.conf.eth3.rp_filter = 1
net.ipv4.conf.eth3.shared_media = 1
net.ipv4.conf.eth3.secure_redirects = 1
net.ipv4.conf.eth3.accept_redirects = 1
net.ipv4.conf.eth3.mc_forwarding = 0
net.ipv4.conf.eth3.forwarding = 0
net.ipv4.conf.eth2.promote_secondaries = 0
net.ipv4.conf.eth2.force_igmp_version = 0
net.ipv4.conf.eth2.disable_policy = 0
net.ipv4.conf.eth2.disable_xfrm = 0
net.ipv4.conf.eth2.arp_accept = 0
net.ipv4.conf.eth2.arp_ignore = 1
net.ipv4.conf.eth2.arp_announce = 0
net.ipv4.conf.eth2.arp_filter = 1
net.ipv4.conf.eth2.tag = 0
net.ipv4.conf.eth2.log_martians = 0
net.ipv4.conf.eth2.bootp_relay = 0
net.ipv4.conf.eth2.medium_id = 0
net.ipv4.conf.eth2.proxy_arp = 0
net.ipv4.conf.eth2.accept_source_route = 0
net.ipv4.conf.eth2.send_redirects = 1
net.ipv4.conf.eth2.rp_filter = 1
net.ipv4.conf.eth2.shared_media = 1
net.ipv4.conf.eth2.secure_redirects = 1
net.ipv4.conf.eth2.accept_redirects = 1
net.ipv4.conf.eth2.mc_forwarding = 0
net.ipv4.conf.eth2.forwarding = 0
net.ipv4.conf.eth0.promote_secondaries = 0
net.ipv4.conf.eth0.force_igmp_version = 0
net.ipv4.conf.eth0.disable_policy = 0
net.ipv4.conf.eth0.disable_xfrm = 0
net.ipv4.conf.eth0.arp_accept = 0
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 0
net.ipv4.conf.eth0.arp_filter = 1
net.ipv4.conf.eth0.tag = 0
net.ipv4.conf.eth0.log_martians = 0
net.ipv4.conf.eth0.bootp_relay = 0
net.ipv4.conf.eth0.medium_id = 0
net.ipv4.conf.eth0.proxy_arp = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth0.send_redirects = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth0.shared_media = 1
net.ipv4.conf.eth0.secure_redirects = 1
net.ipv4.conf.eth0.accept_redirects = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 0
net.ipv4.conf.lo.promote_secondaries = 0
net.ipv4.conf.lo.force_igmp_version = 0
net.ipv4.conf.lo.disable_policy = 1
net.ipv4.conf.lo.disable_xfrm = 1
net.ipv4.conf.lo.arp_accept = 0
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.lo.arp_announce = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.tag = 0
net.ipv4.conf.lo.log_martians = 0
net.ipv4.conf.lo.bootp_relay = 0
net.ipv4.conf.lo.medium_id = 0
net.ipv4.conf.lo.proxy_arp = 0
net.ipv4.conf.lo.accept_source_route = 1
net.ipv4.conf.lo.send_redirects = 1
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.lo.shared_media = 1
net.ipv4.conf.lo.secure_redirects = 1
net.ipv4.conf.lo.accept_redirects = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 0
net.ipv4.conf.default.promote_secondaries = 0
net.ipv4.conf.default.force_igmp_version = 0
net.ipv4.conf.default.disable_policy = 0
net.ipv4.conf.default.disable_xfrm = 0
net.ipv4.conf.default.arp_accept = 0
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.default.arp_filter = 1
net.ipv4.conf.default.tag = 0
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.default.bootp_relay = 0
net.ipv4.conf.default.medium_id = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.shared_media = 1
net.ipv4.conf.default.secure_redirects = 1
net.ipv4.conf.default.accept_redirects = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.all.promote_secondaries = 0
net.ipv4.conf.all.force_igmp_version = 0
net.ipv4.conf.all.disable_policy = 0
net.ipv4.conf.all.disable_xfrm = 0
net.ipv4.conf.all.arp_accept = 0
net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.tag = 0
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.all.bootp_relay = 0
net.ipv4.conf.all.medium_id = 0
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.shared_media = 1
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.accept_redirects = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.all.forwarding = 0
net.ipv4.neigh.eth3.base_reachable_time_ms = 30000
net.ipv4.neigh.eth3.retrans_time_ms = 1000
net.ipv4.neigh.eth3.locktime = 1000
net.ipv4.neigh.eth3.proxy_delay = 800
net.ipv4.neigh.eth3.anycast_delay = 1000
net.ipv4.neigh.eth3.proxy_qlen = 64
net.ipv4.neigh.eth3.unres_qlen = 3
net.ipv4.neigh.eth3.gc_stale_time = 60
net.ipv4.neigh.eth3.delay_first_probe_time = 5
net.ipv4.neigh.eth3.base_reachable_time = 30
net.ipv4.neigh.eth3.retrans_time = 1000
net.ipv4.neigh.eth3.app_solicit = 0
net.ipv4.neigh.eth3.ucast_solicit = 3
net.ipv4.neigh.eth3.mcast_solicit = 3
net.ipv4.neigh.eth2.base_reachable_time_ms = 30000
net.ipv4.neigh.eth2.retrans_time_ms = 1000
net.ipv4.neigh.eth2.locktime = 1000
net.ipv4.neigh.eth2.proxy_delay = 800
net.ipv4.neigh.eth2.anycast_delay = 1000
net.ipv4.neigh.eth2.proxy_qlen = 64
net.ipv4.neigh.eth2.unres_qlen = 3
net.ipv4.neigh.eth2.gc_stale_time = 60
net.ipv4.neigh.eth2.delay_first_probe_time = 5
net.ipv4.neigh.eth2.base_reachable_time = 30
net.ipv4.neigh.eth2.retrans_time = 1000
net.ipv4.neigh.eth2.app_solicit = 0
net.ipv4.neigh.eth2.ucast_solicit = 3
net.ipv4.neigh.eth2.mcast_solicit = 3
net.ipv4.neigh.eth0.base_reachable_time_ms = 30000
net.ipv4.neigh.eth0.retrans_time_ms = 1000
net.ipv4.neigh.eth0.locktime = 1000
net.ipv4.neigh.eth0.proxy_delay = 800
net.ipv4.neigh.eth0.anycast_delay = 1000
net.ipv4.neigh.eth0.proxy_qlen = 64
net.ipv4.neigh.eth0.unres_qlen = 3
net.ipv4.neigh.eth0.gc_stale_time = 60
net.ipv4.neigh.eth0.delay_first_probe_time = 5
net.ipv4.neigh.eth0.base_reachable_time = 30
net.ipv4.neigh.eth0.retrans_time = 1000
net.ipv4.neigh.eth0.app_solicit = 0
net.ipv4.neigh.eth0.ucast_solicit = 3
net.ipv4.neigh.eth0.mcast_solicit = 3
net.ipv4.neigh.lo.base_reachable_time_ms = 30000
net.ipv4.neigh.lo.retrans_time_ms = 1000
net.ipv4.neigh.lo.locktime = 1000
net.ipv4.neigh.lo.proxy_delay = 800
net.ipv4.neigh.lo.anycast_delay = 1000
net.ipv4.neigh.lo.proxy_qlen = 64
net.ipv4.neigh.lo.unres_qlen = 3
net.ipv4.neigh.lo.gc_stale_time = 60
net.ipv4.neigh.lo.delay_first_probe_time = 5
net.ipv4.neigh.lo.base_reachable_time = 30
net.ipv4.neigh.lo.retrans_time = 1000
net.ipv4.neigh.lo.app_solicit = 0
net.ipv4.neigh.lo.ucast_solicit = 3
net.ipv4.neigh.lo.mcast_solicit = 3
net.ipv4.neigh.default.base_reachable_time_ms = 30000
net.ipv4.neigh.default.retrans_time_ms = 1000
net.ipv4.neigh.default.gc_thresh3 = 1024
net.ipv4.neigh.default.gc_thresh2 = 512
net.ipv4.neigh.default.gc_thresh1 = 128
net.ipv4.neigh.default.gc_interval = 30
net.ipv4.neigh.default.locktime = 1000
net.ipv4.neigh.default.proxy_delay = 800
net.ipv4.neigh.default.anycast_delay = 1000
net.ipv4.neigh.default.proxy_qlen = 64
net.ipv4.neigh.default.unres_qlen = 3
net.ipv4.neigh.default.gc_stale_time = 60
net.ipv4.neigh.default.delay_first_probe_time = 5
net.ipv4.neigh.default.base_reachable_time = 30
net.ipv4.neigh.default.retrans_time = 1000
net.ipv4.neigh.default.app_solicit = 0
net.ipv4.neigh.default.ucast_solicit = 3
net.ipv4.neigh.default.mcast_solicit = 3
net.ipv4.cipso_rbm_strictvalid = 1
net.ipv4.cipso_rbm_optfmt = 0
net.ipv4.cipso_cache_bucket_size = 10
net.ipv4.cipso_cache_enable = 1
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_abc = 0
net.ipv4.tcp_congestion_control = bic
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.ipfrag_max_dist = 64
net.ipv4.ipfrag_secret_interval = 600
net.ipv4.tcp_low_latency = 0
net.ipv4.tcp_frto = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.icmp_ratemask = 6168
net.ipv4.icmp_ratelimit = 1000
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_rmem = 4096 87380 20971520
net.ipv4.tcp_wmem = 4096 87380 20971520
net.ipv4.tcp_mem = 49152 65536 98304
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_fack = 1
net.ipv4.tcp_orphan_retries = 0
net.ipv4.inet_peer_gc_maxtime = 120
net.ipv4.inet_peer_gc_mintime = 10
net.ipv4.inet_peer_maxttl = 600
net.ipv4.inet_peer_minttl = 120
net.ipv4.inet_peer_threshold = 65664
net.ipv4.igmp_max_msf = 10
net.ipv4.igmp_max_memberships = 20
net.ipv4.route.secret_interval = 600
net.ipv4.route.min_adv_mss = 256
net.ipv4.route.min_pmtu = 552
net.ipv4.route.mtu_expires = 600
net.ipv4.route.gc_elasticity = 8
net.ipv4.route.error_burst = 5000
net.ipv4.route.error_cost = 1000
net.ipv4.route.redirect_silence = 20480
net.ipv4.route.redirect_number = 9
net.ipv4.route.redirect_load = 20
net.ipv4.route.gc_interval = 60
net.ipv4.route.gc_timeout = 300
net.ipv4.route.gc_min_interval_ms = 500
net.ipv4.route.gc_min_interval = 0
net.ipv4.route.max_size = 8388608
net.ipv4.route.gc_thresh = 524288
net.ipv4.route.max_delay = 10
net.ipv4.route.min_delay = 2
net.ipv4.icmp_errors_use_inbound_ifaddr = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_echo_ignore_all = 0
net.ipv4.ip_local_port_range = 32768 61000
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.ipfrag_time = 30
net.ipv4.ip_dynaddr = 0
net.ipv4.ipfrag_low_thresh = 196608
net.ipv4.ipfrag_high_thresh = 262144
net.ipv4.tcp_max_tw_buckets = 180000
net.ipv4.tcp_max_orphans = 16384
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syn_retries = 5
net.ipv4.ip_nonlocal_bind = 0
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.ip_default_ttl = 64
net.ipv4.ip_forward = 0
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.core.netdev_budget = 300
net.core.somaxconn = 128
net.core.xfrm_aevent_rseqth = 2
net.core.xfrm_aevent_etime = 10
net.core.optmem_max = 20480
net.core.message_burst = 10
net.core.message_cost = 5
net.core.netdev_max_backlog = 10000
net.core.dev_weight = 64
net.core.rmem_default = 126976
net.core.wmem_default = 126976
net.core.rmem_max = 20971520
net.core.wmem_max = 20971520
^ permalink raw reply
* Re: tcp bw in 2.6
From: Roland Dreier @ 2007-10-02 20:44 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, lm, herbert, wscott, netdev
In-Reply-To: <20071002.133322.52193802.davem@davemloft.net>
> It would be really great to see numbers with a more recent kernel
> than 2.6.18
FWIW Debian has binaries for 2.6.21 in testing and for 2.6.22 in
unstable so it should be very easy for Larry to try at least those.
- R.
^ permalink raw reply
* Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
From: Oliver Hartkopp @ 2007-10-02 21:02 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Urs Thuermann, netdev, David Miller, Patrick McHardy,
Thomas Gleixner, YOSHIFUJI Hideaki, Eric W. Biederman,
Oliver Hartkopp, Oliver Hartkopp, Urs Thuermann
In-Reply-To: <20071002142016.GE7881@ghostprotocols.net>
Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 02, 2007 at 03:10:11PM +0200, Urs Thuermann escreveu:
>
>> +
>> +#ifdef CONFIG_CAN_DEBUG_DEVICES
>> +static int debug;
>> +module_param(debug, int, S_IRUGO);
>> +#endif
>>
>
> Can debug be a boolean? Like its counterpart on DCCP:
>
> net/dccp/proto.c:
>
> module_param(dccp_debug, bool, 0444);
>
'debug' should remain an integer to be able to specifiy debug-levels or
bit-fields for different Debug outputs.
> Where we also use a namespace prefix, for those of us who use ctags or
> cscope.
>
Even if i don't have any general objections to rename this 'debug' to
'vcan_debug', it looks like an 'overnamed' module parameter for me. Is
this a genereal naming scheme recommendation for debug module_params?
>
>> +/*
>> + * CAN test feature:
>> + * Enable the echo on driver level for testing the CAN core echo modes.
>> + * See Documentation/networking/can.txt for details.
>> + */
>> +
>> +static int echo; /* echo testing. Default: 0 (Off) */
>> +module_param(echo, int, S_IRUGO);
>> +MODULE_PARM_DESC(echo, "Echo sent frames (for testing). Default: 0 (Off)");
>>
>
> echo also seems to be a boolean
>
>
Yes. This is definitely a boolean candidate. We'll change that.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH 2.6.24] tg3: fix ethtool autonegotiate flags
From: Michael Chan @ 2007-10-02 22:02 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: David Miller, jeff, netdev
In-Reply-To: <20071002201634.GE9140@gospo.rdu.redhat.com>
On Tue, 2007-10-02 at 16:16 -0400, Andy Gospodarek wrote:
> Adding that flag in tg3_set_settings seemed like the most logical
> place
> since the driver works fine on boot. This is just an issue when
> re-enabling autonegotiation, so we should probably nip it there.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
We also noticed this issue recently, but didn't pay too much attention
to it since it was more of a "cosmetic" issue. The driver behaves the
same since we rely on cmd->autoneg to decide whether to enable autoneg
or not. Your fix seems reasonable to me. Thanks.
Acked-by: Michael Chan <mchan@broadcom.com>
^ permalink raw reply
* [patch 1/3] git-net: make it compile (not for applying?)
From: akpm @ 2007-10-02 21:04 UTC (permalink / raw)
To: davem; +Cc: netdev, akpm, shemminger
From: Andrew Morton <akpm@linux-foundation.org>
drivers/net/hamradio/baycom_epp.c: In function 'baycom_probe':
drivers/net/hamradio/baycom_epp.c:1162: error: 'struct net_device' has no member named 'hard_header'
drivers/net/hamradio/baycom_epp.c:1163: error: 'struct net_device' has no member named 'rebuild_header'
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/net/hamradio/baycom_epp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/net/hamradio/baycom_epp.c~git-net-more-bustage drivers/net/hamradio/baycom_epp.c
--- a/drivers/net/hamradio/baycom_epp.c~git-net-more-bustage
+++ a/drivers/net/hamradio/baycom_epp.c
@@ -1159,8 +1159,8 @@ static void baycom_probe(struct net_devi
/* Fill in the fields of the device structure */
bc->skb = NULL;
- dev->hard_header = ax25_hard_header;
- dev->rebuild_header = ax25_rebuild_header;
+// dev->hard_header = ax25_hard_header;
+// dev->rebuild_header = ax25_rebuild_header;
dev->set_mac_address = baycom_set_mac_address;
dev->type = ARPHRD_AX25; /* AF_AX25 device */
_
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox