* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Neil Horman @ 2009-08-26 11:00 UTC (permalink / raw)
To: Bill Fink; +Cc: Linux Network Developers, brice, gallatin
In-Reply-To: <20090826031057.375303c9.billfink@mindspring.com>
On Wed, Aug 26, 2009 at 03:10:57AM -0400, Bill Fink wrote:
> On Fri, 21 Aug 2009, Neil Horman wrote:
>
> > On Fri, Aug 21, 2009 at 12:14:21AM -0400, Bill Fink wrote:
> > > On Thu, 20 Aug 2009, Neil Horman wrote:
> > >
> > > > On Thu, Aug 20, 2009 at 03:50:44AM -0400, Bill Fink wrote:
> > > >
> > > > > When I tried an actual nuttcp performance test, even when rate limiting
> > > > > to just 1 Mbps, I immediately got a kernel oops. I tried to get a
> > > > > crashdump via kexec/kdump, but the kexec kernel, instead of just
> > > > > generating a crashdump, fully booted the new kernel, which was
> > > > > extremely sluggish until I rebooted it through a BIOS re-init,
> > > > > and never produced a crashdump. I tried this several times and
> > > > > an immediate kernel oops was always the result (with either a TCP
> > > > > or UDP test). A ping test of 1000 9000-byte packets with an interval
> > > > > of 0.001 seconds (which is 72 Mbps for 1 second) on the other hand
> > > > > worked just fine.
> > > >
> > > > The sluggishness is expected, since the kdump kernel operates out of such
> > > > limited memory. don't know why you booted to a full system rather than did a
> > > > crash recovery. Don't suppose you got a backtrace did you?
> > >
> > > There was a backtrace on the screen but I didn't have a chance to
> > > record it. BTW did anyone ever think to print the backtrace in
> > > reverse (first to some reserved memory and then output to the display)
> > > so the more interesting parts wouldn't have scrolled off the top of
> > > the screen?
> > >
> > The real solution is to use a console to which the output doesn't scroll off the
> > screen. Normally people use a serial console they can log, or a RAC card that
> > they can record. Even on a regular vga monitor in text mode, you can set up the
> > vt iirc to allow for scrolling.
>
> None of our Asus P6T6 systems have serial consoles. I don't know of
> any RAC cards for them either, nor are there spare PCI slots available
> in many cases. I wouldn't think the Shift-PageUp trick would work
> with a crashed kernel, but I admit I didn't try it. I haven't checked
> out netconsole yet either, but I'm not sure it would help either in a
> case like this that was a network related kernel crash.
>
Any USB ports that you can attach a serial dongle to? That would work as well,
or, as previously mentioned, netconsole also does the trick.
> In any case, a simple kernel command line that would provide a reversed
> backtrace would be a simple thing to facilitate Linux users providing
> useful info to Linux kernel developers in helping to debug kernel
> problems. The most useful info would still be on the screen, so it
> could be transcribed or a photo image of the screen could be taken.
>
I understand what your saying, I'm just saying there are currently several
options for you that have already solved this problem in differnt ways.
> Fortunately, in this specific case, the SuperMicro X8DAH+-F system
> does have a serial console, and after a fair amount of effort I was
> able to get it to work as desired, and was able to finally capture
> a backtrace of the kernel oops. BTW I believe the reason the
> kexec/kdump didn't work was probably because it couldn't find
> a /proc/vmcore file, although I don't know why that would be,
> and the Fedora 10 /etc/init.d/kdump script will then just boot
> up normally if it fails to find the /proc/vmcore file (or it's
> zero size).
>
I take care of kdump for fedora and RHEL. If you file a bug on this, I'd be
happy to look into it further.
> The following shows a simple ping test usage of the skb_sources
> tracing feature:
>
> [root@xeontest1 tracing]# numactl --membind=1 taskset -c 4 ping -c 5 -s 1472 192.168.1.10
> PING 192.168.1.10 (192.168.1.10) 1472(1500) bytes of data.
> 1480 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.139 ms
> 1480 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.182 ms
> 1480 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=0.178 ms
> 1480 bytes from 192.168.1.10: icmp_seq=4 ttl=64 time=0.188 ms
> 1480 bytes from 192.168.1.10: icmp_seq=5 ttl=64 time=0.178 ms
>
> --- 192.168.1.10 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 3999ms
> rtt min/avg/max/mdev = 0.139/0.173/0.188/0.017 ms
>
> [root@xeontest1 tracing]# cat trace
> # tracer: skb_sources
> #
> # PID ANID CNID IFC RXQ CCPU LEN
> # | | | | | | |
> 4217 1 1 eth2 0 4 1500
> 4217 1 1 eth2 0 4 1500
> 4217 1 1 eth2 0 4 1500
> 4217 1 1 eth2 0 4 1500
> 4217 1 1 eth2 0 4 1500
>
> All is as was expected.
>
> But if I try an actual nuttcp performance test (even rate limited
> to 1 Mbps), I get the following kernel oops:
>
thank you, I think I see the problem, I'll have a patch for you in just a bit
Thanks
Neil
> [root@xeontest1 tracing]# numactl --membind=1 nuttcp -In2 -Ri1m -xc4/0 192.168.1.10
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
> IP: [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x152
> PGD 337d12067 PUD 337d11067 PMD 0
> Oops: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:80/0000:80:07.0/0000:8b:00.0/0000:8c:04.0e
> CPU 4
> Modules linked in: w83627ehf hwmon_vid coretemp hwmon ipv6 dm_multipath uinput ]
> Pid: 4222, comm: nuttcp Not tainted 2.6.31-rc6-bf #3 X8DAH
> RIP: 0010:[<ffffffff810b01ab>] [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x12
> RSP: 0018:ffff8801a5811a88 EFLAGS: 00010213
> RAX: 0000000000000000 RBX: ffff88033906d154 RCX: 000000000000000d
> RDX: 000000000000f88c RSI: 000000000000000b RDI: ffff8803383d3044
> RBP: ffff8801a5811ab8 R08: 0000000000000001 R09: ffff8801ab311a00
> R10: 0000000000000005 R11: ffffc9000080e2b0 R12: ffff880337c45400
> R13: ffff88033906d150 R14: 0000000000000014 R15: ffffffff818bb890
> FS: 00007fa976d326f0(0000) GS:ffffc90000800000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000038 CR3: 000000033801e000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process nuttcp (pid: 4222, threadinfo ffff8801a5810000, task ffff8801ab2e5d00)
> Stack:
> ffff8801a5811ab8 ffff8801b35d4ab0 0000000000000014 0000000000000000
> <0> 0000000000000014 0000000000000014 ffff8801a5811b18 ffffffff81366ae8
> <0> ffff8801a5811ed8 0000001439084000 ffff880337c45400 00000001001416ef
> Call Trace:
> [<ffffffff81366ae8>] skb_copy_datagram_iovec+0x50/0x1f5
> [<ffffffff813ac875>] tcp_rcv_established+0x278/0x6db
> [<ffffffff813b3ef5>] tcp_v4_do_rcv+0x1b8/0x366
> [<ffffffff8135f99e>] ? release_sock+0xab/0xb4
> [<ffffffff8136004d>] ? sk_wait_data+0xc8/0xd6
> [<ffffffff813a32d6>] tcp_prequeue_process+0x79/0x8f
> [<ffffffff813a455d>] tcp_recvmsg+0x4e8/0xaa0
> [<ffffffff8135ec90>] sock_common_recvmsg+0x37/0x4c
> [<ffffffff8135cb06>] __sock_recvmsg+0x72/0x7f
> [<ffffffff8135cbdd>] sock_aio_read+0xca/0xda
> [<ffffffff810d9536>] ? vma_merge+0x2a0/0x318
> [<ffffffff810f6d4f>] do_sync_read+0xec/0x132
> [<ffffffff81067ddc>] ? autoremove_wake_function+0x0/0x3d
> [<ffffffff811b646c>] ? security_file_permission+0x16/0x18
> [<ffffffff810f785c>] vfs_read+0xc0/0x107
> [<ffffffff810f7971>] sys_read+0x4c/0x75
> [<ffffffff81011c82>] system_call_fastpath+0x16/0x1b
> Code: 44 89 73 30 89 43 14 41 0f b7 84 24 ac 00 00 00 89 43 28 65 8b 04 25 98 e
> RIP [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x152
> RSP <ffff8801a5811a88>
> CR2: 0000000000000038
>
> -Thanks
>
> -Bill
>
^ permalink raw reply
* [PATCH 3/3] Revert Backoff [v3]: Calculate TCP's connection close threshold as a time value.
From: Damian Lukowski @ 2009-08-26 10:16 UTC (permalink / raw)
To: Netdev
RFC 1122 specifies two threshold values R1 and R2 for connection timeouts,
which may represent a number of allowed retransmissions or a timeout value.
Currently linux uses sysctl_tcp_retries{1,2} to specify the thresholds
in number of allowed retransmissions.
For any desired threshold R2 (by means of time) one can specify tcp_retries2
(by means of number of retransmissions) such that TCP will not time out
earlier than R2. This is the case, because the RTO schedule follows a fixed
pattern, namely exponential backoff.
However, the RTO behaviour is not predictable any more if RTO backoffs can be
reverted, as it is the case in the draft
"Make TCP more Robust to Long Connectivity Disruptions"
(http://tools.ietf.org/html/draft-zimmermann-tcp-lcd).
In the worst case TCP would time out a connection after 3.2 seconds, if the
initial RTO equaled MIN_RTO and each backoff has been reverted.
This patch introduces a function retransmits_timed_out(N),
which calculates the timeout of a TCP connection, assuming an initial
RTO of MIN_RTO and N unsuccessful, exponentially backed-off retransmissions.
Whenever timeout decisions are made by comparing the retransmission counter
to some value N, this function can be used, instead.
The meaning of tcp_retries2 will be changed, as many more RTO retransmissions
can occur than the value indicates. However, it yields a timeout which is
similar to the one of an unpatched, exponentially backing off TCP in the same
scenario. As no application could rely on an RTO greater than MIN_RTO, there
should be no risk of a regression.
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
---
include/net/tcp.h | 18 ++++++++++++++++++
net/ipv4/tcp_timer.c | 11 +++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c35b329..17d1a88 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1247,6 +1247,24 @@ static inline struct sk_buff *tcp_write_queue_prev(struct sock *sk, struct sk_bu
#define tcp_for_write_queue_from_safe(skb, tmp, sk) \
skb_queue_walk_from_safe(&(sk)->sk_write_queue, skb, tmp)
+static inline bool retransmits_timed_out(const struct sock *sk,
+ unsigned int boundary)
+{
+ int limit, K;
+ if (!inet_csk(sk)->icsk_retransmits)
+ return false;
+
+ K = ilog2(TCP_RTO_MAX/TCP_RTO_MIN);
+
+ if (boundary <= K)
+ limit = ((2 << boundary) - 1) * TCP_RTO_MIN;
+ else
+ limit = ((2 << K) - 1) * TCP_RTO_MIN +
+ (boundary - K) * TCP_RTO_MAX;
+
+ return (tcp_time_stamp - tcp_sk(sk)->retrans_stamp) >= limit;
+}
+
static inline struct sk_buff *tcp_send_head(struct sock *sk)
{
return sk->sk_send_head;
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index a3ba494..2972d7b 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -137,13 +137,14 @@ static int tcp_write_timeout(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
int retry_until;
+ bool do_reset;
if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
if (icsk->icsk_retransmits)
dst_negative_advice(&sk->sk_dst_cache);
retry_until = icsk->icsk_syn_retries ? : sysctl_tcp_syn_retries;
} else {
- if (icsk->icsk_retransmits >= sysctl_tcp_retries1) {
+ if (retransmits_timed_out(sk, sysctl_tcp_retries1)) {
/* Black hole detection */
tcp_mtu_probing(icsk, sk);
@@ -155,13 +156,15 @@ static int tcp_write_timeout(struct sock *sk)
const int alive = (icsk->icsk_rto < TCP_RTO_MAX);
retry_until = tcp_orphan_retries(sk, alive);
+ do_reset = alive ||
+ !retransmits_timed_out(sk, retry_until);
- if (tcp_out_of_resources(sk, alive || icsk->icsk_retransmits < retry_until))
+ if (tcp_out_of_resources(sk, do_reset))
return 1;
}
}
- if (icsk->icsk_retransmits >= retry_until) {
+ if (retransmits_timed_out(sk, retry_until)) {
/* Has it gone just too far? */
tcp_write_err(sk);
return 1;
@@ -385,7 +388,7 @@ void tcp_retransmit_timer(struct sock *sk)
out_reset_timer:
icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, icsk->icsk_rto, TCP_RTO_MAX);
- if (icsk->icsk_retransmits > sysctl_tcp_retries1)
+ if (retransmits_timed_out(sk, sysctl_tcp_retries1 + 1))
__sk_dst_reset(sk);
out:;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/3] Revert Backoff [v3]: Revert RTO on ICMP destination unreachable
From: Damian Lukowski @ 2009-08-26 10:16 UTC (permalink / raw)
To: Netdev
Here, an ICMP host/network unreachable message, whose payload fits to
TCP's SND.UNA, is taken as an indication that the RTO retransmission has
not been lost due to congestion, but because of a route failure
somewhere along the path.
With true congestion, a router won't trigger such a message and the
patched TCP will operate as standard TCP.
This patch reverts one RTO backoff, if an ICMP host/network unreachable
message, whose payload fits to TCP's SND.UNA, arrives.
Based on the new RTO, the retransmission timer is reset to reflect the
remaining time, or - if the revert clocked out the timer - a retransmission
is sent out immediately.
Backoffs are only reverted, if TCP is in RTO loss recovery, i.e. if
there have been retransmissions and reversible backoffs, already.
Changes from v2:
1) Renaming of skb in tcp_v4_err() moved to another patch.
2) Reintroduced tcp_bound_rto() and __tcp_set_rto().
3) Fixed code comments.
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
---
include/net/tcp.h | 12 ++++++++++++
net/ipv4/tcp_input.c | 5 ++---
net/ipv4/tcp_ipv4.c | 37 +++++++++++++++++++++++++++++++++++++
net/ipv4/tcp_timer.c | 2 +-
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 88af843..c35b329 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -469,6 +469,7 @@ extern void __tcp_push_pending_frames(struct sock *sk, unsigned int cur_mss,
int nonagle);
extern int tcp_may_send_now(struct sock *sk);
extern int tcp_retransmit_skb(struct sock *, struct sk_buff *);
+extern void tcp_retransmit_timer(struct sock *sk);
extern void tcp_xmit_retransmit_queue(struct sock *);
extern void tcp_simple_retransmit(struct sock *);
extern int tcp_trim_head(struct sock *, struct sk_buff *, u32);
@@ -521,6 +522,17 @@ extern int tcp_mtu_to_mss(struct sock *sk, int pmtu);
extern int tcp_mss_to_mtu(struct sock *sk, int mss);
extern void tcp_mtup_init(struct sock *sk);
+static inline void tcp_bound_rto(const struct sock *sk)
+{
+ if (inet_csk(sk)->icsk_rto > TCP_RTO_MAX)
+ inet_csk(sk)->icsk_rto = TCP_RTO_MAX;
+}
+
+static inline u32 __tcp_set_rto(const struct tcp_sock *tp)
+{
+ return (tp->srtt >> 3) + tp->rttvar;
+}
+
static inline void __tcp_fast_path_on(struct tcp_sock *tp, u32 snd_wnd)
{
tp->pred_flags = htonl((tp->tcp_header_len << 26) |
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2bdb0da..af6d6fa 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -685,7 +685,7 @@ static inline void tcp_set_rto(struct sock *sk)
* is invisible. Actually, Linux-2.4 also generates erratic
* ACKs in some circumstances.
*/
- inet_csk(sk)->icsk_rto = (tp->srtt >> 3) + tp->rttvar;
+ inet_csk(sk)->icsk_rto = __tcp_set_rto(tp);
/* 2. Fixups made earlier cannot be right.
* If we do not estimate RTO correctly without them,
@@ -696,8 +696,7 @@ static inline void tcp_set_rto(struct sock *sk)
/* NOTE: clamping at TCP_RTO_MIN is not required, current algo
* guarantees that rto is higher.
*/
- if (inet_csk(sk)->icsk_rto > TCP_RTO_MAX)
- inet_csk(sk)->icsk_rto = TCP_RTO_MAX;
+ tcp_bound_rto(sk);
}
/* Save metrics learned by this TCP session.
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 6ca1bc8..6755e29 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -332,12 +332,15 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
{
struct iphdr *iph = (struct iphdr *)icmp_skb->data;
struct tcphdr *th = (struct tcphdr *)(icmp_skb->data + (iph->ihl << 2));
+ struct inet_connection_sock *icsk;
struct tcp_sock *tp;
struct inet_sock *inet;
const int type = icmp_hdr(icmp_skb)->type;
const int code = icmp_hdr(icmp_skb)->code;
struct sock *sk;
+ struct sk_buff *skb;
__u32 seq;
+ __u32 remaining;
int err;
struct net *net = dev_net(icmp_skb->dev);
@@ -367,6 +370,7 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
if (sk->sk_state == TCP_CLOSE)
goto out;
+ icsk = inet_csk(sk);
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -393,6 +397,39 @@ void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
}
err = icmp_err_convert[code].errno;
+ /* check if icmp_skb allows revert of backoff
+ * (see draft-zimmermann-tcp-lcd) */
+ if (code != ICMP_NET_UNREACH && code != ICMP_HOST_UNREACH)
+ break;
+ if (seq != tp->snd_una || !icsk->icsk_retransmits ||
+ !icsk->icsk_backoff)
+ break;
+
+ icsk->icsk_backoff--;
+ inet_csk(sk)->icsk_rto = __tcp_set_rto(tp) <<
+ icsk->icsk_backoff;
+ tcp_bound_rto(sk);
+
+ skb = tcp_write_queue_head(sk);
+ BUG_ON(!skb);
+
+ remaining = icsk->icsk_rto - min(icsk->icsk_rto,
+ tcp_time_stamp - TCP_SKB_CB(skb)->when);
+
+ if (remaining) {
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
+ remaining, TCP_RTO_MAX);
+ } else if (sock_owned_by_user(sk)) {
+ /* RTO revert clocked out retransmission,
+ * but socket is locked. Will defer. */
+ inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
+ HZ/20, TCP_RTO_MAX);
+ } else {
+ /* RTO revert clocked out retransmission.
+ * Will retransmit now */
+ tcp_retransmit_timer(sk);
+ }
+
break;
case ICMP_TIME_EXCEEDED:
err = EHOSTUNREACH;
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index b144a26..a3ba494 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -279,7 +279,7 @@ static void tcp_probe_timer(struct sock *sk)
* The TCP retransmit timer.
*/
-static void tcp_retransmit_timer(struct sock *sk)
+void tcp_retransmit_timer(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
struct inet_connection_sock *icsk = inet_csk(sk);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/3] Revert Backoff [v3]: Rename skb to icmp_skb in tcp_v4_err()
From: Damian Lukowski @ 2009-08-26 10:16 UTC (permalink / raw)
To: Netdev
This supplementary patch renames skb to icmp_skb in tcp_v4_err() in order to
disambiguate from another sk_buff variable, which will be introduced
in a separate patch.
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
---
net/ipv4/tcp_ipv4.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 6d88219..6ca1bc8 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -328,26 +328,26 @@ static void do_pmtu_discovery(struct sock *sk, struct iphdr *iph, u32 mtu)
*
*/
-void tcp_v4_err(struct sk_buff *skb, u32 info)
+void tcp_v4_err(struct sk_buff *icmp_skb, u32 info)
{
- struct iphdr *iph = (struct iphdr *)skb->data;
- struct tcphdr *th = (struct tcphdr *)(skb->data + (iph->ihl << 2));
+ struct iphdr *iph = (struct iphdr *)icmp_skb->data;
+ struct tcphdr *th = (struct tcphdr *)(icmp_skb->data + (iph->ihl << 2));
struct tcp_sock *tp;
struct inet_sock *inet;
- const int type = icmp_hdr(skb)->type;
- const int code = icmp_hdr(skb)->code;
+ const int type = icmp_hdr(icmp_skb)->type;
+ const int code = icmp_hdr(icmp_skb)->code;
struct sock *sk;
__u32 seq;
int err;
- struct net *net = dev_net(skb->dev);
+ struct net *net = dev_net(icmp_skb->dev);
- if (skb->len < (iph->ihl << 2) + 8) {
+ if (icmp_skb->len < (iph->ihl << 2) + 8) {
ICMP_INC_STATS_BH(net, ICMP_MIB_INERRORS);
return;
}
sk = inet_lookup(net, &tcp_hashinfo, iph->daddr, th->dest,
- iph->saddr, th->source, inet_iif(skb));
+ iph->saddr, th->source, inet_iif(icmp_skb));
if (!sk) {
ICMP_INC_STATS_BH(net, ICMP_MIB_INERRORS);
return;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/3] [v3] Revert Backoff on ICMP destination unreachable
From: Damian Lukowski @ 2009-08-26 10:16 UTC (permalink / raw)
To: Netdev
This series of patches implements the TCP improvement of the Internet Draft
"Make TCP more Robust to Long Connectivity Disruptions"
(http://tools.ietf.org/html/draft-zimmermann-tcp-lcd).
Exponential backoff is TCP's standard behaviour during long connectivity
disruptions, which is a countermeasure against network congestion.
If congestion can be excluded as the reason for RTO retransmission loss,
backoff is not desirable, as it yields longer TCP recovery times, when
the communication path is repaired shortly after an unsuccessful
retransmission probe.
1) This patch renames the skb in tcp_v4_err() in preparation for patch 2.
2) Contains the main reversion logic.
Reintroduces tcp_bound_rto() and __tcp_set_rto()
3) This patch modifies the interpretation of the tcp_retries{1,2} sysctls.
It became necessary because with patch2 the assumption that the number
of retransmits corresponds to an specific timeout value is not accurate
anymore. With this patch tcp_retries{1,2} specifies a timeout value,
equivalent to the time a connection with an rto value of MIN_RTO (200ms)
would need to retransmit N segments. IOW: The meaning (in sense of time)
is mostly preserved, but the actual connection timeout does not depend
on the calculated rto of the connection, anymore.
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
---
^ permalink raw reply
* Re: AlacrityVM benchmark numbers updated
From: Avi Kivity @ 2009-08-26 10:16 UTC (permalink / raw)
To: Gregory Haskins
Cc: alacrityvm-devel, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Michael S. Tsirkin, netdev
In-Reply-To: <4A948962.7090909@gmail.com>
On 08/26/2009 04:01 AM, Gregory Haskins wrote:
> We are pleased to announce the availability of the latest networking
> benchmark numbers for AlacrityVM. We've made several tweaks to the
> original v0.1 release to improve performance. The most notable is a
> switch from get_user_pages to switch_mm+copy_[to/from]_user thanks to a
> review suggestion from Michael Tsirkin (as well as his patch to
> implement it).
>
> This change alone accounted for freeing up an additional 1.2Gbps, which
> is over 25% improvement from v0.1. The previous numbers were 4560Gbps
> before the change, and 5708Gbps after (for 1500mtu over 10GE). This
> moves us ever closer to the goal of native performance under virtualization.
>
Interesting, it's good to see that copy_*_user() works so well. Note
that there's a possible optimization that goes in the opposite direction
- keep using get_user_pages(), but use the dma engine API to perform the
actual copy. I expect that it will only be a win when using tso to
transfer full pages. Large pages may also help.
Copyless tx also wants get_user_pages(). It makes sense to check if
switch_mm() + get_user_pages_fast() gives better performance than
get_user_pages().
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Johannes Weiner @ 2009-08-26 9:51 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, Andrew Morton,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg
In-Reply-To: <20090826082741.GA25955-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
On Wed, Aug 26, 2009 at 10:27:41AM +0200, Johannes Weiner wrote:
> 64 pages, presumably 256k, for fw->boot_size while current ipw
> firmware images have ~188k. I don't know jack squat about this
> driver, but given the field name and the struct:
>
> struct ipw_fw {
> __le32 ver;
> __le32 boot_size;
> __le32 ucode_size;
> __le32 fw_size;
> u8 data[0];
> };
>
> fw->boot_size alone being that big sounds a bit fishy to me.
Scrap that, I just noticed the second call to ipw_load_firmware() a
few lines later... :)
Hannes 'when logic and proportion have fallen sloppy dead...'
^ permalink raw reply
* [RFC] atm/br2684 netif_*_queue, packet loss or performance loss.
From: Karl Hiramoto @ 2009-08-26 9:45 UTC (permalink / raw)
To: netdev
Hi,
With a br2684/ IPoE bridge, I was seeing more than 50% packet loss
under heavy load without this patch in a vanilla 2.6.28.9 and 2.6.30
kernel. With this patch, I have less then 5% packet loss now,
measured by doing a ping, while having HTTP downloads with other
connections. Without this patch it seems one TCP connection monopolies
the line, because the packet loss does not allow the other TCP
connections to ramp up.
The problem this patch, is that my max throughput on a 24Mbps down/
1Mbps up line drops by about 30% so I have about 15mbps utilization,
looking at traffic on the line i see there are gaps when nothing is
being transmitted..
How much latency should netif_wake_queue() introduce?
It seems that i call netif_wake_queue() but the upper layers in
net/core/ sometimes take a while to restart sending packets to
atm/br2684.c and i see these gaps in data transmission. Note if i
change the ADSL2+ line speed to 4Mbps down/ 320Kbps up this patch seems
to work perfectly, I have very low packet loss, and maximum utilization
of the line. I tried playing with the internal buffering that the
hardware driver does in the high speed 24Mbps down/ 1Mbps up case but it
did not seem to make any difference. The TX seemed to be starved of
data because the upper layers were not calling hard_start_xmit()
I see the atm/clip driver calling netif_wake_queue() and
netif_stop_queue() so i was trying to do the same in br2684. I don't
have any hardware at the moment though to test CLIP at high speed.
My setup is:
test client pc eth0 <---> eth0 <--> arm ixp425 cpu <-- br2684 --> atm
driver & device <--> ADSL2+ DSLAM <---> Test server eth0
You can see in my patch that i remove a line that has
"dev_kfree_skb(skb);" that causes the packet loss. Then i added code
to call netif_stop_queue() and netif_wake_queue()
--- linux-2.6.28.9.orig/net/atm/br2684.c 2009-03-23 22:55:52.000000000 +0100
+++ linux-2.6.28.9/net/atm/br2684.c 2009-08-26 11:03:34.000000000 +0200
@@ -69,7 +69,7 @@ struct br2684_vcc {
struct net_device *device;
/* keep old push, pop functions for chaining */
void (*old_push) (struct atm_vcc * vcc, struct sk_buff * skb);
- /* void (*old_pop)(struct atm_vcc *vcc, struct sk_buff *skb); */
+ void (*old_pop)(struct atm_vcc *vcc, struct sk_buff *skb);
enum br2684_encaps encaps;
struct list_head brvccs;
#ifdef CONFIG_ATM_BR2684_IPFILTER
@@ -143,6 +143,26 @@ static struct net_device *br2684_find_de
return NULL;
}
+/* chained vcc->pop function. Check if we should wake the netif_queue */
+static void br2684_pop(struct atm_vcc *vcc, struct sk_buff *skb)
+{
+ struct br2684_vcc *brvcc = BR2684_VCC(vcc);
+ struct net_device *net_dev = skb->dev;
+
+ pr_debug("br2684_pop(vcc %p ; net_dev %p )\n", vcc, net_dev);
+ brvcc->old_pop(vcc, skb);
+
+ if (!net_dev)
+ return;
+
+ if (atm_may_send(vcc, 0)) {
+ if (netif_queue_stopped(net_dev)) {
+ netif_wake_queue(net_dev);
+ }
+ }
+
+}
+
/*
* Send a packet out a particular vcc. Not to useful right now, but paves
* the way for multiple vcc's per itf. Returns true if we can send,
@@ -200,20 +220,20 @@ static int br2684_xmit_vcc(struct sk_buf
ATM_SKB(skb)->vcc = atmvcc = brvcc->atmvcc;
pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n", skb, atmvcc, atmvcc->dev);
- if (!atm_may_send(atmvcc, skb->truesize)) {
- /*
- * We free this here for now, because we cannot know in a higher
- * layer whether the skb pointer it supplied wasn't freed yet.
- * Now, it always is.
- */
- dev_kfree_skb(skb);
- return 0;
- }
+
atomic_add(skb->truesize, &sk_atm(atmvcc)->sk_wmem_alloc);
ATM_SKB(skb)->atm_options = atmvcc->atm_options;
brdev->stats.tx_packets++;
brdev->stats.tx_bytes += skb->len;
+
atmvcc->send(atmvcc, skb);
+
+ if (!atm_may_send(atmvcc, 0)) {
+ /* the queue is now full so stop it
+ * Restart the queue in br2684_pop */
+ netif_stop_queue(brvcc->device);
+ }
+
return 1;
}
@@ -240,6 +260,8 @@ static int br2684_start_xmit(struct sk_b
read_unlock(&devs_lock);
return 0;
}
+ netif_tx_lock_bh(brdev->net_dev);
+
if (!br2684_xmit_vcc(skb, brdev, brvcc)) {
/*
* We should probably use netif_*_queue() here, but that
@@ -251,6 +273,7 @@ static int br2684_start_xmit(struct sk_b
brdev->stats.tx_errors++;
brdev->stats.tx_fifo_errors++;
}
+ netif_tx_unlock_bh(brdev->net_dev);
read_unlock(&devs_lock);
return 0;
}
@@ -509,8 +532,10 @@ static int br2684_regvcc(struct atm_vcc
atmvcc->user_back = brvcc;
brvcc->encaps = (enum br2684_encaps)be.encaps;
brvcc->old_push = atmvcc->push;
+ brvcc->old_pop = atmvcc->pop;
barrier();
atmvcc->push = br2684_push;
+ atmvcc->pop = br2684_pop;
rq = &sk_atm(atmvcc)->sk_receive_queue;
@@ -621,6 +646,8 @@ static int br2684_create(void __user * a
write_lock_irq(&devs_lock);
brdev->payload = payload;
+ netif_start_queue(netdev);
+
brdev->number = list_empty(&br2684_devs) ? 1 :
BRPRIV(list_entry_brdev(br2684_devs.prev))->number + 1;
list_add_tail(&brdev->br2684_devs, &br2684_devs);
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Mel Gorman @ 2009-08-26 9:37 UTC (permalink / raw)
To: Johannes Weiner
Cc: Pekka Enberg, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Bartlomiej Zolnierkiewicz, Mel Gorman,
Andrew Morton, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg
In-Reply-To: <20090826082741.GA25955-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
On Wed, Aug 26, 2009 at 10:27:41AM +0200, Johannes Weiner wrote:
> [Cc netdev]
>
> On Wed, Aug 26, 2009 at 09:09:44AM +0300, Pekka Enberg wrote:
> > On Tue, Aug 25, 2009 at 11:34 PM, Rafael J. Wysocki<rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.30. Please verify if it still should be listed and let me know
> > > (either way).
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14016
> > > Subject : mm/ipw2200 regression
> > > Submitter : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > > Date : 2009-08-15 16:56 (11 days old)
> > > References : http://marc.info/?l=linux-kernel&m=125036437221408&w=4
> >
> > If am reading the page allocator dump correctly, there's plenty of
> > pages left but we're unable to satisfy an order 6 allocation. There's
> > no slab allocator involved so the page allocator changes that went
> > into 2.6.31 seem likely. Mel, ideas?
>
> It's an atomic order-6 allocation, the chances for this to succeed
> after some uptime become infinitesimal. The chunks > order-2 are
> pretty much exhausted on this dump.
>
> 64 pages, presumably 256k, for fw->boot_size while current ipw
> firmware images have ~188k. I don't know jack squat about this
> driver, but given the field name and the struct:
>
> struct ipw_fw {
> __le32 ver;
> __le32 boot_size;
> __le32 ucode_size;
> __le32 fw_size;
> u8 data[0];
> };
>
> fw->boot_size alone being that big sounds a bit fishy to me.
>
Agreed. While there are a low number of order-6 pages free in the page
allocation failure dump, there are not enough for watermarks to be
satisified. As it's atomic, there is little that can be done from a VM
perspective and it's the responsibility of the driver. I'm no driver expert
but I'll have a go at fixing it anyway.
My reading of this is that the firmware is being loaded from a workqueue and
I am failing to see any restriction on sleeping in the path. It would appear
that the driver just used the most convenient *_alloc_coherent function
available forgetting that it assumes GFP_ATOMIC. Can someone who does know
which way is up with a driver tell me why the patch below might not
work?
Bartlomiej, any chance you could give this a spin? Preferably, you'd
have preempt enabled and CONFIG_DEBUG_SPINLOCK_SLEEP on as well because
that combination will complain loudly if we really can't sleep in this
path.
=====
ipw2200: Avoid large GFP_ATOMIC allocation during firmware loading
ipw2200 uses pci_alloc_consistent() to allocate a large coherent buffer for
the loading of firmware which is an order-6 allocation of GFP_ATOMIC. At
system start-up time, this is not a problem. However, the firmware on the
card can get confused and the corrective action taken is to reload the
firmware and reinit the card. High-order GFP_ATOMIC allocations of this
type can and will fail when the system is already up and running.
As the firmware is loaded from a workqueue, it should be possible for
the driver to go to sleep. This patch converts the call of
pci_alloc_consistent() which assumes GFP_ATOMIC to dma_alloc_coherent()
which can specify its own flags.
The big downside with this patch is that it uses GFP_REPEAT to avoid the
driver unloading. There is potential that this will cause a reclaim
storm as the machine tries to find a free order-6 buffer. A suggested
alternative for the driver owner is in the comments.
Signed-off-by: Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
---
drivers/net/wireless/ipw2x00/ipw2200.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 44c29b3..f2e251e 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -3167,7 +3167,19 @@ static int ipw_load_firmware(struct ipw_priv *priv, u8 * data, size_t len)
u8 *shared_virt;
IPW_DEBUG_TRACE("<< : \n");
- shared_virt = pci_alloc_consistent(priv->pci_dev, len, &shared_phys);
+
+ /*
+ * This is a whopping large allocation, in or around order-6 so
+ * dma_alloc_coherent is used to specify the GFP_KERNEL|__GFP_REPEAT
+ * flags. Note that this action means the system could go into a
+ * reclaim loop until it cannot reclaim any more trying to satisfy
+ * the allocation. It would be preferable if one buffer is allocated
+ * at driver initialisation and reused when the firmware needs to
+ * be reloaded, overwriting the existing firmware each time
+ */
+ shared_virt = dma_alloc_coherent(
+ priv->pci_dev == NULL ? NULL : &priv->pci_dev->dev,
+ len, &shared_phys, GFP_KERNEL|__GFP_REPEAT);
if (!shared_virt)
return -ENOMEM;
^ permalink raw reply related
* Re: [PATCH] smc91x: fix compilation on SMP
From: DDD @ 2009-08-26 9:39 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: davem, netdev
In-Reply-To: <20090826085526.GA3209@x200.localdomain>
Hi Alexey,
Thanks for you correct me. :-)
For "smc91x", I just compile it on an old linux version, and merge the
changes to the latest linux for creating a patch.
I think it must be OK, so I didn't compile the patch on the latest
linux.
I'm so sorry for my careless.
Dongdong
On Wed, 2009-08-26 at 12:55 +0400, Alexey Dobriyan wrote:
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
>
> drivers/net/smc91x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/net/smc91x.c
> +++ b/drivers/net/smc91x.c
> @@ -531,7 +531,7 @@ static inline void smc_rcv(struct net_device *dev)
> local_irq_restore(flags); \
> __ret; \
> })
> -#define smc_special_lock(lock, flags) spin_lock_irq(lock, flags)
> +#define smc_special_lock(lock, flags) spin_lock_irqsave(lock, flags)
> #define smc_special_unlock(lock, flags) spin_unlock_irqrestore(lock, flags)
> #else
> #define smc_special_trylock(lock, flags) (1)
^ permalink raw reply
* [PATCH] smc91x: fix compilation on SMP
From: Alexey Dobriyan @ 2009-08-26 8:55 UTC (permalink / raw)
To: davem; +Cc: netdev, dongdong.deng
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/smc91x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/smc91x.c
+++ b/drivers/net/smc91x.c
@@ -531,7 +531,7 @@ static inline void smc_rcv(struct net_device *dev)
local_irq_restore(flags); \
__ret; \
})
-#define smc_special_lock(lock, flags) spin_lock_irq(lock, flags)
+#define smc_special_lock(lock, flags) spin_lock_irqsave(lock, flags)
#define smc_special_unlock(lock, flags) spin_unlock_irqrestore(lock, flags)
#else
#define smc_special_trylock(lock, flags) (1)
^ permalink raw reply
* Re: [kmemcheck] WARNING: kmemcheck: Caught 32-bit read from uninitialized memory, in sock_init_data()
From: Ingo Molnar @ 2009-08-26 8:47 UTC (permalink / raw)
To: Vegard Nossum; +Cc: Eric Dumazet, Pekka Enberg, linux-kernel, Linux Netdev List
In-Reply-To: <19f34abd0908260144n6a5ebf7ft18f48e44f04082ad@mail.gmail.com>
* Vegard Nossum <vegard.nossum@gmail.com> wrote:
> 2009/8/26 Ingo Molnar <mingo@elte.hu>:
> >
> > * Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> >> Vegard Nossum a ??crit :
> >> > 2009/8/26 Ingo Molnar <mingo@elte.hu>:
> >> >> -tip testing found another kmemcheck warning:
> >> >>
> >> >> calling ??netlink_proto_init+0x0/0x1b0 @ 1
> >> >> NET: Registered protocol family 16
> >> >> initcall netlink_proto_init+0x0/0x1b0 returned 0 after 39062 usecs
> >> >> calling ??olpc_init+0x0/0x110 @ 1
> >> >> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
> >> >> 0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
> >> >> ??i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
> >> >> ?? ?? ?? ?? ^
> >> >>
> >> >> Pid: 1, comm: swapper Not tainted (2.6.31-rc7-tip-01170-gaaea9cf-dirty #24) P4DC6
> >> >> EIP: 0060:[<c15c8ab1>] EFLAGS: 00010286 CPU: 0
> >> >> EIP is at sock_init_data+0xe1/0x220
> >> >> EAX: 0001b000 EBX: f606196c ECX: 00000000 EDX: c1a148d2
> >> >> ESI: f6061800 EDI: f5c38300 EBP: f606ef0c ESP: c1ceb9ac
> >> >> ??DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> >> >> CR0: 8005003b CR2: f60a8108 CR3: 01a61000 CR4: 000006f0
> >> >> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> >> >> DR6: ffff4ff0 DR7: 00000400
> >> >> ??[<c15fac15>] __netlink_create+0x35/0xa0
> >> >> ??[<c15fd01a>] netlink_kernel_create+0x5a/0x180
> >> >> ??[<c15df55e>] rtnetlink_net_init+0x1e/0x50
> >> >> ??[<c15d130a>] register_pernet_operations+0x6a/0xf0
> >> >> ??[<c15d14fe>] register_pernet_subsys+0x1e/0x30
> >> >> ??[<c1b3d84c>] rtnetlink_init+0x4c/0x100
> >> >> ??[<c1b3e105>] netlink_proto_init+0x105/0x1b0
> >> >> ??[<c1001037>] do_one_initcall+0x27/0x170
> >> >> ??[<c1afea97>] kernel_init+0x157/0x210
> >> >> ??[<c10039a7>] kernel_thread_helper+0x7/0x10
> >> >> ??[<ffffffff>] 0xffffffff
> >> >> initcall olpc_init+0x0/0x110 returned 0 after 0 usecs
> >> >> calling ??bdi_class_init+0x0/0x40 @ 1
> >> >>
> >> >> config attached.
> >> >
> >> > Thanks. AFAICT, it's this one:
> >> >
> >> > 1816 void sock_init_data(struct socket *sock, struct sock *sk)
> >> > 1817 {
> >> > ...
> >> > 1835 ?? ?? ?? ?? sock_set_flag(sk, SOCK_ZAPPED);
> >>
> >> Are you sure it is not the 16 bit padding in 'struct sock', after 'type' field ?
> >>
> >> struct socket {
> >> ?? ?? ?? socket_state ?? ?? ?? ??state;
> >> ?? ?? ?? short ?? ?? ?? ?? ?? type;
> >> // here, a 16 bits hole
> >> ?? ?? ?? unsigned long ?? ?? ?? flags;
> >>
> >> the warning is strange since I suspect it happens here :
> >>
> >> ?? ?? if (sock) {
> >> <<>> ??sk->sk_type = ?? sock->type; // here, kmemcheck warning while reading sock->type
> >> ?? ?? ?? sk->sk_sleep ?? ??= ?? &sock->wait;
> >> ?? ?? ?? sock->sk ?? ??= ?? sk;
> >>
> >> and sock->type is a 16 bit field, correctly initialized (with value = 2)
> >> (Yes the hole, right after, is not initialized)
> >>
>
> Ah, right, makes sense. There are just two uninitialized bytes, too,
> we can see it in the shadow dump:
>
> >> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
> >> 0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
> >> ??i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
> >
> > if so then we could perhaps annotate that by initializing it to zero
> > on kmemcheck only. (or initialize it unconditionally if possible -
> > that's generally the cleanest, 16-bit accesses arent cheap on all
> > platforms)
>
> We should have eliminated these padding-related false-positives by
> droppnig the -Os / CONFIG_CC_OPTIMIZE_FOR_SIZE, which should emit
> a movzwl instruction or so instead of movl, but it's admittedly
> somewhat dependent on gcc anyway. I'm wondering whether it would
> be worth it to (try to) patch gcc not to emit these
> "bigger-than-necessary" loads with a new -fsomething flag.
The latency of even the smallest enhancements to GCC is so huge that
we cannot rely on it. There's really just a few places in the kernel
that are that tightly/trickily packed - the signal code (which we
annotated IIRC?) and the networking code. Lets annotate it so that
we can have a 'no warnings' baseline.
Ingo
^ permalink raw reply
* Re: 2.6.31-rc7-git2: Reported regressions 2.6.29 -> 2.6.30
From: Rafał Miłecki @ 2009-08-26 8:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, DRI, Linux SCSI List,
Network Development, Linux Wireless List, Natalie Protasevich,
Linux ACPI, Andrew Morton, Kernel Testers List, Linus Torvalds,
Linux PM List
In-Reply-To: <JuOd1ZASH0B.A.YGB.0zGlKB@chimera>
2009/8/25 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514
> Subject : acer_wmi causes stack corruption
> Submitter : Rus <harbour-K87ZgELTUEPsG83rWm+8vg@public.gmane.org>
> Date : 2009-06-12 08:13 (75 days old)
It has patch, just Len doesn't seem to... don't know, read the topic?
http://patchwork.kernel.org/patch/29082/
Can we ping Len somehow to push this patch directly to Linus's tree?
--
Rafał Miłecki
^ permalink raw reply
* Re: [kmemcheck] WARNING: kmemcheck: Caught 32-bit read from uninitialized memory, in sock_init_data()
From: Vegard Nossum @ 2009-08-26 8:44 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Eric Dumazet, Pekka Enberg, linux-kernel, Linux Netdev List
In-Reply-To: <20090826082709.GA11057@elte.hu>
2009/8/26 Ingo Molnar <mingo@elte.hu>:
>
> * Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Vegard Nossum a ??crit :
>> > 2009/8/26 Ingo Molnar <mingo@elte.hu>:
>> >> -tip testing found another kmemcheck warning:
>> >>
>> >> calling netlink_proto_init+0x0/0x1b0 @ 1
>> >> NET: Registered protocol family 16
>> >> initcall netlink_proto_init+0x0/0x1b0 returned 0 after 39062 usecs
>> >> calling olpc_init+0x0/0x110 @ 1
>> >> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
>> >> 0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
>> >> i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
>> >> ^
>> >>
>> >> Pid: 1, comm: swapper Not tainted (2.6.31-rc7-tip-01170-gaaea9cf-dirty #24) P4DC6
>> >> EIP: 0060:[<c15c8ab1>] EFLAGS: 00010286 CPU: 0
>> >> EIP is at sock_init_data+0xe1/0x220
>> >> EAX: 0001b000 EBX: f606196c ECX: 00000000 EDX: c1a148d2
>> >> ESI: f6061800 EDI: f5c38300 EBP: f606ef0c ESP: c1ceb9ac
>> >> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
>> >> CR0: 8005003b CR2: f60a8108 CR3: 01a61000 CR4: 000006f0
>> >> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> >> DR6: ffff4ff0 DR7: 00000400
>> >> [<c15fac15>] __netlink_create+0x35/0xa0
>> >> [<c15fd01a>] netlink_kernel_create+0x5a/0x180
>> >> [<c15df55e>] rtnetlink_net_init+0x1e/0x50
>> >> [<c15d130a>] register_pernet_operations+0x6a/0xf0
>> >> [<c15d14fe>] register_pernet_subsys+0x1e/0x30
>> >> [<c1b3d84c>] rtnetlink_init+0x4c/0x100
>> >> [<c1b3e105>] netlink_proto_init+0x105/0x1b0
>> >> [<c1001037>] do_one_initcall+0x27/0x170
>> >> [<c1afea97>] kernel_init+0x157/0x210
>> >> [<c10039a7>] kernel_thread_helper+0x7/0x10
>> >> [<ffffffff>] 0xffffffff
>> >> initcall olpc_init+0x0/0x110 returned 0 after 0 usecs
>> >> calling bdi_class_init+0x0/0x40 @ 1
>> >>
>> >> config attached.
>> >
>> > Thanks. AFAICT, it's this one:
>> >
>> > 1816 void sock_init_data(struct socket *sock, struct sock *sk)
>> > 1817 {
>> > ...
>> > 1835 sock_set_flag(sk, SOCK_ZAPPED);
>>
>> Are you sure it is not the 16 bit padding in 'struct sock', after 'type' field ?
>>
>> struct socket {
>> socket_state state;
>> short type;
>> // here, a 16 bits hole
>> unsigned long flags;
>>
>> the warning is strange since I suspect it happens here :
>>
>> if (sock) {
>> <<>> sk->sk_type = sock->type; // here, kmemcheck warning while reading sock->type
>> sk->sk_sleep = &sock->wait;
>> sock->sk = sk;
>>
>> and sock->type is a 16 bit field, correctly initialized (with value = 2)
>> (Yes the hole, right after, is not initialized)
>>
Ah, right, makes sense. There are just two uninitialized bytes, too,
we can see it in the shadow dump:
>> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
>> 0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
>> i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
>
> if so then we could perhaps annotate that by initializing it to zero
> on kmemcheck only. (or initialize it unconditionally if possible -
> that's generally the cleanest, 16-bit accesses arent cheap on all
> platforms)
>
We should have eliminated these padding-related false-positives by
droppnig the -Os / CONFIG_CC_OPTIMIZE_FOR_SIZE, which should emit a
movzwl instruction or so instead of movl, but it's admittedly somewhat
dependent on gcc anyway. I'm wondering whether it would be worth it to
(try to) patch gcc not to emit these "bigger-than-necessary" loads
with a new -fsomething flag.
Vegard
^ permalink raw reply
* [BUG bisected] 2.6.30.4: NET: active FTP doesn't work
From: Vitezslav Samel @ 2009-08-26 8:33 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Krzysztof Piotr Oledzki, Greg Kroah-Hartman, netdev
Hi!
When testing 2.6.30.4+ kernel, I discovered active ftp does not work
anymore (2.6.30.3 is OK).
LAN internet
machine1 ------- router1 ------- machine2
Active ftp from machine1 to machine2 connects, transfers some files and
then hangs. Passive ftp works OK. The faulty box (router1)
is router/firewall and is doing NAT.
I bisected it down to commit 7500f93f415a2fc07e0031d99fa3964bf8981cfc
in linux-2.6.30.y tree ("netfilter: tcp conntrack: fix unacknowledged
data detection with NAT").
Could you, please, take look at it?
I'm open to do any tests.
Thanks,
Vita Samel
^ permalink raw reply
* Re: [Bug #14016] mm/ipw2200 regression
From: Johannes Weiner @ 2009-08-26 8:27 UTC (permalink / raw)
To: Pekka Enberg
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Bartlomiej Zolnierkiewicz, Mel Gorman, Andrew Morton, netdev,
linux-mm
In-Reply-To: <84144f020908252309u5cff8afdh2214577ca4db9b5d@mail.gmail.com>
[Cc netdev]
On Wed, Aug 26, 2009 at 09:09:44AM +0300, Pekka Enberg wrote:
> On Tue, Aug 25, 2009 at 11:34 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.30. Please verify if it still should be listed and let me know
> > (either way).
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14016
> > Subject : mm/ipw2200 regression
> > Submitter : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > Date : 2009-08-15 16:56 (11 days old)
> > References : http://marc.info/?l=linux-kernel&m=125036437221408&w=4
>
> If am reading the page allocator dump correctly, there's plenty of
> pages left but we're unable to satisfy an order 6 allocation. There's
> no slab allocator involved so the page allocator changes that went
> into 2.6.31 seem likely. Mel, ideas?
It's an atomic order-6 allocation, the chances for this to succeed
after some uptime become infinitesimal. The chunks > order-2 are
pretty much exhausted on this dump.
64 pages, presumably 256k, for fw->boot_size while current ipw
firmware images have ~188k. I don't know jack squat about this
driver, but given the field name and the struct:
struct ipw_fw {
__le32 ver;
__le32 boot_size;
__le32 ucode_size;
__le32 fw_size;
u8 data[0];
};
fw->boot_size alone being that big sounds a bit fishy to me.
Hannes
^ permalink raw reply
* Re: [kmemcheck] WARNING: kmemcheck: Caught 32-bit read from uninitialized memory, in sock_init_data()
From: Ingo Molnar @ 2009-08-26 8:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vegard Nossum, Pekka Enberg, linux-kernel, Linux Netdev List
In-Reply-To: <4A94ED74.6000200@gmail.com>
* Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Vegard Nossum a ??crit :
> > 2009/8/26 Ingo Molnar <mingo@elte.hu>:
> >> -tip testing found another kmemcheck warning:
> >>
> >> calling netlink_proto_init+0x0/0x1b0 @ 1
> >> NET: Registered protocol family 16
> >> initcall netlink_proto_init+0x0/0x1b0 returned 0 after 39062 usecs
> >> calling olpc_init+0x0/0x110 @ 1
> >> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
> >> 0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
> >> i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
> >> ^
> >>
> >> Pid: 1, comm: swapper Not tainted (2.6.31-rc7-tip-01170-gaaea9cf-dirty #24) P4DC6
> >> EIP: 0060:[<c15c8ab1>] EFLAGS: 00010286 CPU: 0
> >> EIP is at sock_init_data+0xe1/0x220
> >> EAX: 0001b000 EBX: f606196c ECX: 00000000 EDX: c1a148d2
> >> ESI: f6061800 EDI: f5c38300 EBP: f606ef0c ESP: c1ceb9ac
> >> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> >> CR0: 8005003b CR2: f60a8108 CR3: 01a61000 CR4: 000006f0
> >> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> >> DR6: ffff4ff0 DR7: 00000400
> >> [<c15fac15>] __netlink_create+0x35/0xa0
> >> [<c15fd01a>] netlink_kernel_create+0x5a/0x180
> >> [<c15df55e>] rtnetlink_net_init+0x1e/0x50
> >> [<c15d130a>] register_pernet_operations+0x6a/0xf0
> >> [<c15d14fe>] register_pernet_subsys+0x1e/0x30
> >> [<c1b3d84c>] rtnetlink_init+0x4c/0x100
> >> [<c1b3e105>] netlink_proto_init+0x105/0x1b0
> >> [<c1001037>] do_one_initcall+0x27/0x170
> >> [<c1afea97>] kernel_init+0x157/0x210
> >> [<c10039a7>] kernel_thread_helper+0x7/0x10
> >> [<ffffffff>] 0xffffffff
> >> initcall olpc_init+0x0/0x110 returned 0 after 0 usecs
> >> calling bdi_class_init+0x0/0x40 @ 1
> >>
> >> config attached.
> >
> > Thanks. AFAICT, it's this one:
> >
> > 1816 void sock_init_data(struct socket *sock, struct sock *sk)
> > 1817 {
> > ...
> > 1835 sock_set_flag(sk, SOCK_ZAPPED);
>
> Are you sure it is not the 16 bit padding in 'struct sock', after 'type' field ?
>
> struct socket {
> socket_state state;
> short type;
> // here, a 16 bits hole
> unsigned long flags;
>
> the warning is strange since I suspect it happens here :
>
> if (sock) {
> <<>> sk->sk_type = sock->type; // here, kmemcheck warning while reading sock->type
> sk->sk_sleep = &sock->wait;
> sock->sk = sk;
>
> and sock->type is a 16 bit field, correctly initialized (with value = 2)
> (Yes the hole, right after, is not initialized)
>
> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
> 0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
> i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
if so then we could perhaps annotate that by initializing it to zero
on kmemcheck only. (or initialize it unconditionally if possible -
that's generally the cleanest, 16-bit accesses arent cheap on all
platforms)
Ingo
^ permalink raw reply
* Re: [kmemcheck] WARNING: kmemcheck: Caught 32-bit read from uninitialized memory, in sock_init_data()
From: Eric Dumazet @ 2009-08-26 8:08 UTC (permalink / raw)
To: Vegard Nossum; +Cc: Ingo Molnar, Pekka Enberg, linux-kernel, Linux Netdev List
In-Reply-To: <19f34abd0908260013n4e701796j90fb2b1ab74495de@mail.gmail.com>
Vegard Nossum a écrit :
> 2009/8/26 Ingo Molnar <mingo@elte.hu>:
>> -tip testing found another kmemcheck warning:
>>
>> calling netlink_proto_init+0x0/0x1b0 @ 1
>> NET: Registered protocol family 16
>> initcall netlink_proto_init+0x0/0x1b0 returned 0 after 39062 usecs
>> calling olpc_init+0x0/0x110 @ 1
>> WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
>> 0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
>> i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
>> ^
>>
>> Pid: 1, comm: swapper Not tainted (2.6.31-rc7-tip-01170-gaaea9cf-dirty #24) P4DC6
>> EIP: 0060:[<c15c8ab1>] EFLAGS: 00010286 CPU: 0
>> EIP is at sock_init_data+0xe1/0x220
>> EAX: 0001b000 EBX: f606196c ECX: 00000000 EDX: c1a148d2
>> ESI: f6061800 EDI: f5c38300 EBP: f606ef0c ESP: c1ceb9ac
>> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
>> CR0: 8005003b CR2: f60a8108 CR3: 01a61000 CR4: 000006f0
>> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> DR6: ffff4ff0 DR7: 00000400
>> [<c15fac15>] __netlink_create+0x35/0xa0
>> [<c15fd01a>] netlink_kernel_create+0x5a/0x180
>> [<c15df55e>] rtnetlink_net_init+0x1e/0x50
>> [<c15d130a>] register_pernet_operations+0x6a/0xf0
>> [<c15d14fe>] register_pernet_subsys+0x1e/0x30
>> [<c1b3d84c>] rtnetlink_init+0x4c/0x100
>> [<c1b3e105>] netlink_proto_init+0x105/0x1b0
>> [<c1001037>] do_one_initcall+0x27/0x170
>> [<c1afea97>] kernel_init+0x157/0x210
>> [<c10039a7>] kernel_thread_helper+0x7/0x10
>> [<ffffffff>] 0xffffffff
>> initcall olpc_init+0x0/0x110 returned 0 after 0 usecs
>> calling bdi_class_init+0x0/0x40 @ 1
>>
>> config attached.
>
> Thanks. AFAICT, it's this one:
>
> 1816 void sock_init_data(struct socket *sock, struct sock *sk)
> 1817 {
> ...
> 1835 sock_set_flag(sk, SOCK_ZAPPED);
Are you sure it is not the 16 bit padding in 'struct sock', after 'type' field ?
struct socket {
socket_state state;
short type;
// here, a 16 bits hole
unsigned long flags;
the warning is strange since I suspect it happens here :
if (sock) {
<<>> sk->sk_type = sock->type; // here, kmemcheck warning while reading sock->type
sk->sk_sleep = &sock->wait;
sock->sk = sk;
and sock->type is a 16 bit field, correctly initialized (with value = 2)
(Yes the hole, right after, is not initialized)
WARNING: kmemcheck: Caught 32-bit read from uninitialized memory (f5c38304)
0100000002000000000000000000000000000000ad4eaddeffffffffffffffff
i i i i i i u u i i i i i i i i i i i i i i i i i i i i i i i i
>
> Which sort of makes sense, given all the trouble we've had with bitfields/flags.
>
> Is it possible that struct sock's sk_flags is (partially)
> uninitialized at this point?
>
> I'll investigate more later, lecture of statistics is about to begin.
>
>
> Vegard
>
^ permalink raw reply
* [PATCH] r8169: Reduce looping in the interrupt handler.
From: Eric W. Biederman @ 2009-08-26 7:58 UTC (permalink / raw)
To: Francois Romieu
Cc: David Dillow, Michael Riepe, Michael Buesch, Rui Santos,
Michael B??ker, linux-kernel, netdev
In-Reply-To: <20090825221903.GA13630@electric-eye.fr.zoreil.com>
As of 2.6.30 I have been observing soft lockups and netdev watchdog
timeouts caused by looping in the r8169 interrupt handler.
- Introduce a hard limit to the maximum number of times we will loop in
the interrupt handler, and print a message when we hit it.
- Break out of the loop if after looking none of the events in status
are events we expect to be delivered by an interrupt.
With just the hard limit and message bits of my patch in my test case
I get hit my limit of 10 loops 12 times. After filtering by intr_mask
and intr_event I don't get any warnings.
Any complaints from those who know the driver better than I?
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
drivers/net/r8169.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 3b19e0c..2214945 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -61,6 +61,8 @@ static const int multicast_filter_limit = 32;
/* MAC address length */
#define MAC_ADDR_LEN 6
+#define MAX_INTR_LOOPS 10 /* Limit the msi acking loop from going crazy */
+
#define MAX_READ_REQUEST_SHIFT 12
#define RX_FIFO_THRESH 7 /* 7 means NO threshold, Rx buffer level before first PCI xfer. */
#define RX_DMA_BURST 6 /* Maximum PCI burst, '6' is 1024 */
@@ -3552,6 +3554,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
void __iomem *ioaddr = tp->mmio_addr;
int handled = 0;
int status;
+ int count = 0;
/* loop handling interrupts until we have no new ones or
* we hit a invalid/hotplug case.
@@ -3560,6 +3563,17 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
while (status && status != 0xffff) {
handled = 1;
+ if (count++ >= MAX_INTR_LOOPS) {
+ if (netif_msg_intr(tp) && net_ratelimit()) {
+ printk(KERN_INFO " %s Screaming irq "
+ "status %08x mask %08x event %08x "
+ "napi %08x\n",
+ dev->name, status, tp->intr_mask,
+ tp->intr_event, tp->napi_event);
+ }
+ break;
+ }
+
/* Handle all of the error cases first. These will reset
* the chip, so just exit the loop.
*/
@@ -3609,6 +3623,13 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
RTL_W16(IntrStatus,
(status & RxFIFOOver) ? (status | RxOverflow) : status);
status = RTL_R16(IntrStatus);
+
+ /* Ignore the parts of status that reflect more than
+ * the enabled interrupts.
+ */
+ smp_rmb();
+ if (!(status & tp->intr_mask & tp->intr_event))
+ break;
}
return IRQ_RETVAL(handled);
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 1/1] iwmc3200: add more SDIO device ids
From: Holger Schurig @ 2009-08-26 7:25 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Tomas Winkler, Luis R. Rodriguez, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Greg KH
In-Reply-To: <1251156118.2950.82.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Tuesday 25 August 2009 01:21:58 Marcel Holtmann wrote:
> My personal vote is for keeping all IDs inside the drivers.
> And I also prefer to keep the plain hex values and just put a
> comment above them which device this is. Something like this:
>
> static struct usb_device_id btusb_table[] = {
> /* Generic Bluetooth USB device */
> { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+1
When I have an unknown device (and not compiled all modules) it's
so much easier to do an
grep -ri 057c drivers/usb
then to do the same on include/ and then again to find the driver
that uses this id. For the same reason, I prefer 0x057c in the
source and not 0x57c.
--
http://www.holgerschurig.de
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Bill Fink @ 2009-08-26 7:10 UTC (permalink / raw)
To: Neil Horman; +Cc: Linux Network Developers, brice, gallatin
In-Reply-To: <20090821152341.GA2998@localhost.localdomain>
On Fri, 21 Aug 2009, Neil Horman wrote:
> On Fri, Aug 21, 2009 at 12:14:21AM -0400, Bill Fink wrote:
> > On Thu, 20 Aug 2009, Neil Horman wrote:
> >
> > > On Thu, Aug 20, 2009 at 03:50:44AM -0400, Bill Fink wrote:
> > >
> > > > When I tried an actual nuttcp performance test, even when rate limiting
> > > > to just 1 Mbps, I immediately got a kernel oops. I tried to get a
> > > > crashdump via kexec/kdump, but the kexec kernel, instead of just
> > > > generating a crashdump, fully booted the new kernel, which was
> > > > extremely sluggish until I rebooted it through a BIOS re-init,
> > > > and never produced a crashdump. I tried this several times and
> > > > an immediate kernel oops was always the result (with either a TCP
> > > > or UDP test). A ping test of 1000 9000-byte packets with an interval
> > > > of 0.001 seconds (which is 72 Mbps for 1 second) on the other hand
> > > > worked just fine.
> > >
> > > The sluggishness is expected, since the kdump kernel operates out of such
> > > limited memory. don't know why you booted to a full system rather than did a
> > > crash recovery. Don't suppose you got a backtrace did you?
> >
> > There was a backtrace on the screen but I didn't have a chance to
> > record it. BTW did anyone ever think to print the backtrace in
> > reverse (first to some reserved memory and then output to the display)
> > so the more interesting parts wouldn't have scrolled off the top of
> > the screen?
> >
> The real solution is to use a console to which the output doesn't scroll off the
> screen. Normally people use a serial console they can log, or a RAC card that
> they can record. Even on a regular vga monitor in text mode, you can set up the
> vt iirc to allow for scrolling.
None of our Asus P6T6 systems have serial consoles. I don't know of
any RAC cards for them either, nor are there spare PCI slots available
in many cases. I wouldn't think the Shift-PageUp trick would work
with a crashed kernel, but I admit I didn't try it. I haven't checked
out netconsole yet either, but I'm not sure it would help either in a
case like this that was a network related kernel crash.
In any case, a simple kernel command line that would provide a reversed
backtrace would be a simple thing to facilitate Linux users providing
useful info to Linux kernel developers in helping to debug kernel
problems. The most useful info would still be on the screen, so it
could be transcribed or a photo image of the screen could be taken.
Fortunately, in this specific case, the SuperMicro X8DAH+-F system
does have a serial console, and after a fair amount of effort I was
able to get it to work as desired, and was able to finally capture
a backtrace of the kernel oops. BTW I believe the reason the
kexec/kdump didn't work was probably because it couldn't find
a /proc/vmcore file, although I don't know why that would be,
and the Fedora 10 /etc/init.d/kdump script will then just boot
up normally if it fails to find the /proc/vmcore file (or it's
zero size).
The following shows a simple ping test usage of the skb_sources
tracing feature:
[root@xeontest1 tracing]# numactl --membind=1 taskset -c 4 ping -c 5 -s 1472 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 1472(1500) bytes of data.
1480 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.139 ms
1480 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.182 ms
1480 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=0.178 ms
1480 bytes from 192.168.1.10: icmp_seq=4 ttl=64 time=0.188 ms
1480 bytes from 192.168.1.10: icmp_seq=5 ttl=64 time=0.178 ms
--- 192.168.1.10 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.139/0.173/0.188/0.017 ms
[root@xeontest1 tracing]# cat trace
# tracer: skb_sources
#
# PID ANID CNID IFC RXQ CCPU LEN
# | | | | | | |
4217 1 1 eth2 0 4 1500
4217 1 1 eth2 0 4 1500
4217 1 1 eth2 0 4 1500
4217 1 1 eth2 0 4 1500
4217 1 1 eth2 0 4 1500
All is as was expected.
But if I try an actual nuttcp performance test (even rate limited
to 1 Mbps), I get the following kernel oops:
[root@xeontest1 tracing]# numactl --membind=1 nuttcp -In2 -Ri1m -xc4/0 192.168.1.10
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
IP: [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x152
PGD 337d12067 PUD 337d11067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:80/0000:80:07.0/0000:8b:00.0/0000:8c:04.0e
CPU 4
Modules linked in: w83627ehf hwmon_vid coretemp hwmon ipv6 dm_multipath uinput ]
Pid: 4222, comm: nuttcp Not tainted 2.6.31-rc6-bf #3 X8DAH
RIP: 0010:[<ffffffff810b01ab>] [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x12
RSP: 0018:ffff8801a5811a88 EFLAGS: 00010213
RAX: 0000000000000000 RBX: ffff88033906d154 RCX: 000000000000000d
RDX: 000000000000f88c RSI: 000000000000000b RDI: ffff8803383d3044
RBP: ffff8801a5811ab8 R08: 0000000000000001 R09: ffff8801ab311a00
R10: 0000000000000005 R11: ffffc9000080e2b0 R12: ffff880337c45400
R13: ffff88033906d150 R14: 0000000000000014 R15: ffffffff818bb890
FS: 00007fa976d326f0(0000) GS:ffffc90000800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000038 CR3: 000000033801e000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process nuttcp (pid: 4222, threadinfo ffff8801a5810000, task ffff8801ab2e5d00)
Stack:
ffff8801a5811ab8 ffff8801b35d4ab0 0000000000000014 0000000000000000
<0> 0000000000000014 0000000000000014 ffff8801a5811b18 ffffffff81366ae8
<0> ffff8801a5811ed8 0000001439084000 ffff880337c45400 00000001001416ef
Call Trace:
[<ffffffff81366ae8>] skb_copy_datagram_iovec+0x50/0x1f5
[<ffffffff813ac875>] tcp_rcv_established+0x278/0x6db
[<ffffffff813b3ef5>] tcp_v4_do_rcv+0x1b8/0x366
[<ffffffff8135f99e>] ? release_sock+0xab/0xb4
[<ffffffff8136004d>] ? sk_wait_data+0xc8/0xd6
[<ffffffff813a32d6>] tcp_prequeue_process+0x79/0x8f
[<ffffffff813a455d>] tcp_recvmsg+0x4e8/0xaa0
[<ffffffff8135ec90>] sock_common_recvmsg+0x37/0x4c
[<ffffffff8135cb06>] __sock_recvmsg+0x72/0x7f
[<ffffffff8135cbdd>] sock_aio_read+0xca/0xda
[<ffffffff810d9536>] ? vma_merge+0x2a0/0x318
[<ffffffff810f6d4f>] do_sync_read+0xec/0x132
[<ffffffff81067ddc>] ? autoremove_wake_function+0x0/0x3d
[<ffffffff811b646c>] ? security_file_permission+0x16/0x18
[<ffffffff810f785c>] vfs_read+0xc0/0x107
[<ffffffff810f7971>] sys_read+0x4c/0x75
[<ffffffff81011c82>] system_call_fastpath+0x16/0x1b
Code: 44 89 73 30 89 43 14 41 0f b7 84 24 ac 00 00 00 89 43 28 65 8b 04 25 98 e
RIP [<ffffffff810b01ab>] probe_skb_dequeue+0xf7/0x152
RSP <ffff8801a5811a88>
CR2: 0000000000000038
-Thanks
-Bill
^ permalink raw reply
* Re: [Bridge] VLANs and bridge
From: Joakim Tjernlund @ 2009-08-26 6:56 UTC (permalink / raw)
To: Patrick McHardy; +Cc: bridge, netdev, Simon Barber
In-Reply-To: <4A93EE8C.6040008@trash.net>
Patrick McHardy <kaber@trash.net> wrote on 25/08/2009 16:00:44:
>
> Joakim Tjernlund wrote:
> > Simon Barber <simon@superduper.net> wrote on 22/08/2009 19:12:10:
> >> Looking through B.1.3 it looks like the patch would need some
> >> enhancement. It provides a good basis - handling tagging/untagging and
> >> filtering, but would need a way to specify the untagged vlan separately
> >> for in and out.
> >
> > I see. Perhaps the VLAN maintainer(CC:ed) can comment too. Especially about extending
> > the VLAN code to allowed several VLANs in one interface?
>
> Just accepting additional VIDs on one VLAN device should be
> a relatively trivial change, all you need to do is call
> vlan_group_set_device() with the additional VIDs.
>
> I'd suggest to add something similar to the QoS-mapping lists
> in vlan_netlink.c for the additional VIDs.
Yes, this seems to be the easy part. There are a few bride issues though:
How would the bridge be able to filter pks based on VID?
How to control which VID to use at pkg TX?
Can you have the same VID on multiple VLAN interfaces?
Jocke
^ permalink raw reply
* Re: [RFC 0/4] pktgen patches
From: Eric Dumazet @ 2009-08-26 6:54 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Robert Olsson, netdev, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20090826061513.755294685@vyatta.com>
Stephen Hemminger a écrit :
> These are some experimental (not ready yet), patches to try and
> improve the pktgen timer code. Need some review by the hrtimer folks
> as well.
>
>
I'll try these in a couple of hours thanks.
As a followup on our other pktgen thread, if I switch my 3GHz cpu to 2GHz (powersave cpufreq),
then I get litle bit better pktgen throughput from my 1Gb/s tg3 link.
So getting pktgen looping faster (spending less time in kernel time services)
might actually slow down the trafic.
We might try to avoid any memory ops while waiting txq to become available,
and cpu_relax()/ndelay(500)/udelay(1) as much as possible, to free bus bandwidth ?
^ permalink raw reply
* [RFC 4/4] pktgen: minor cleanup
From: Stephen Hemminger @ 2009-08-26 6:15 UTC (permalink / raw)
To: David Miller, Robert Olsson; +Cc: netdev, Thomas Gleixner, Ingo Molnar
In-Reply-To: <20090826061513.755294685@vyatta.com>
[-- Attachment #1: pktgen-fseen.patch --]
[-- Type: text/plain, Size: 1853 bytes --]
A couple of minor functions can be written more compactly.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/core/pktgen.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/net/core/pktgen.c 2009-08-25 22:51:21.162461840 -0700
+++ b/net/core/pktgen.c 2009-08-25 22:56:01.282586584 -0700
@@ -507,7 +507,7 @@ static const struct file_operations pktg
static int pktgen_if_show(struct seq_file *seq, void *v)
{
- struct pktgen_dev *pkt_dev = seq->private;
+ const struct pktgen_dev *pkt_dev = seq->private;
ktime_t stopped;
struct timeval trun, idle;
@@ -1666,7 +1666,7 @@ static const struct file_operations pktg
static int pktgen_thread_show(struct seq_file *seq, void *v)
{
struct pktgen_thread *t = seq->private;
- struct pktgen_dev *pkt_dev;
+ const struct pktgen_dev *pkt_dev;
BUG_ON(!t);
@@ -2121,13 +2121,9 @@ static inline void set_pkt_overhead(stru
pkt_dev->pkt_overhead += SVLAN_TAG_SIZE(pkt_dev);
}
-static inline int f_seen(struct pktgen_dev *pkt_dev, int flow)
+static inline int f_seen(const struct pktgen_dev *pkt_dev, int flow)
{
-
- if (pkt_dev->flows[flow].flags & F_INIT)
- return 1;
- else
- return 0;
+ return !!(pkt_dev->flows[flow].flags & F_INIT);
}
static inline int f_pick(struct pktgen_dev *pkt_dev)
@@ -3102,17 +3098,14 @@ static void pktgen_stop_all_threads_ifs(
mutex_unlock(&pktgen_thread_lock);
}
-static int thread_is_running(struct pktgen_thread *t)
+static int thread_is_running(const struct pktgen_thread *t)
{
- struct pktgen_dev *pkt_dev;
- int res = 0;
+ const struct pktgen_dev *pkt_dev;
list_for_each_entry(pkt_dev, &t->if_list, list)
- if (pkt_dev->running) {
- res = 1;
- break;
- }
- return res;
+ if (pkt_dev->running)
+ return 1;
+ return 0;
}
static int pktgen_wait_thread_run(struct pktgen_thread *t)
--
^ permalink raw reply
* [RFC 0/4] pktgen patches
From: Stephen Hemminger @ 2009-08-26 6:15 UTC (permalink / raw)
To: David Miller, Robert Olsson; +Cc: netdev, Thomas Gleixner, Ingo Molnar
These are some experimental (not ready yet), patches to try and
improve the pktgen timer code. Need some review by the hrtimer folks
as well.
--
^ 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