* [RFC] Make TCP prequeue configurable
From: Eric Dumazet @ 2007-09-27 22:08 UTC (permalink / raw)
To: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
Hi all
I am sure some of you are going to tell me that prequeue is not
all black :)
Thank you
[RFC] Make TCP prequeue configurable
The TCP prequeue thing is based on old facts, and has drawbacks.
1) It adds 48 bytes per 'struct tcp_sock'
2) It adds some ugly code in hot paths
3) It has a small hit ratio on typical servers using many sockets
4) It may have a high hit ratio on UP machines running one process,
where the prequeue adds litle gain. (In fact, letting the user
doing the copy after being woke up is better for cache reuse)
5) Doing a copy to user in softirq handler is not good, because of
potential page faults :(
6) Maybe the NET_DMA thing is the only thing that might need prequeue.
This patch introduces a CONFIG_TCP_PREQUEUE, automatically selected if
CONFIG_NET_DMA is on.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: net_prequeue.patch --]
[-- Type: text/plain, Size: 7426 bytes --]
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 8f670da..14e3f01 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -16,6 +16,7 @@ comment "DMA Clients"
config NET_DMA
bool "Network: TCP receive copy offload"
depends on DMA_ENGINE && NET
+ select TCP_PREQUEUE
default y
---help---
This enables the use of DMA engines in the network stack to
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index c6b9f92..844a05e 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -268,11 +268,13 @@ struct tcp_sock {
/* Data for direct copy to user */
struct {
+#ifdef CONFIG_TCP_PREQUEUE
struct sk_buff_head prequeue;
struct task_struct *task;
struct iovec *iov;
int memory;
int len;
+#endif
#ifdef CONFIG_NET_DMA
/* members for async copy */
struct dma_chan *dma_chan;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 185c7ec..3430d8e 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -835,10 +835,12 @@ static inline int tcp_checksum_complete(struct sk_buff *skb)
static inline void tcp_prequeue_init(struct tcp_sock *tp)
{
+#ifdef CONFIG_TCP_PREQUEUE
tp->ucopy.task = NULL;
tp->ucopy.len = 0;
tp->ucopy.memory = 0;
skb_queue_head_init(&tp->ucopy.prequeue);
+#endif
#ifdef CONFIG_NET_DMA
tp->ucopy.dma_chan = NULL;
tp->ucopy.wakeup = 0;
@@ -857,6 +859,7 @@ static inline void tcp_prequeue_init(struct tcp_sock *tp)
*/
static inline int tcp_prequeue(struct sock *sk, struct sk_buff *skb)
{
+#ifdef CONFIG_TCP_PREQUEUE
struct tcp_sock *tp = tcp_sk(sk);
if (!sysctl_tcp_low_latency && tp->ucopy.task) {
@@ -882,6 +885,7 @@ static inline int tcp_prequeue(struct sock *sk, struct sk_buff *skb)
}
return 1;
}
+#endif
return 0;
}
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index fb79097..b770829 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -616,5 +616,20 @@ config TCP_MD5SIG
If unsure, say N.
+config TCP_PREQUEUE
+ bool "Enable TCP prequeue"
+ default n
+ ---help---
+ TCP PREQUEUE is an 'optimization' loosely based on the famous
+ "30 instruction TCP receive" Van Jacobson mail.
+ Van's trick is to deposit buffers into socket queue
+ on a device interrupt, to call tcp_recv function
+ on the receive process context and checksum and copy
+ the buffer to user space. smart...
+
+ Some people believe this 'optimization' is not really needed
+ but for some benchmarks. Also, taking potential pagefaults in
+ softirq handler seems a high price to pay.
+
source "net/ipv4/ipvs/Kconfig"
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 7e74011..8659533 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -994,6 +994,7 @@ void tcp_cleanup_rbuf(struct sock *sk, int copied)
tcp_send_ack(sk);
}
+#ifdef CONFIG_TCP_PREQUEUE
static void tcp_prequeue_process(struct sock *sk)
{
struct sk_buff *skb;
@@ -1011,6 +1012,7 @@ static void tcp_prequeue_process(struct sock *sk)
/* Clear memory counter. */
tp->ucopy.memory = 0;
}
+#endif
static inline struct sk_buff *tcp_recv_skb(struct sock *sk, u32 seq, u32 *off)
{
@@ -1251,6 +1253,7 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
tcp_cleanup_rbuf(sk, copied);
+#ifdef CONFIG_TCP_PREQUEUE
if (!sysctl_tcp_low_latency && tp->ucopy.task == user_recv) {
/* Install new reader */
if (!user_recv && !(flags & (MSG_TRUNC | MSG_PEEK))) {
@@ -1295,7 +1298,7 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
/* __ Set realtime policy in scheduler __ */
}
-
+#endif
if (copied >= target) {
/* Do not sleep, just process backlog. */
release_sock(sk);
@@ -1307,6 +1310,7 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
tp->ucopy.wakeup = 0;
#endif
+#ifdef CONFIG_TCP_PREQUEUE
if (user_recv) {
int chunk;
@@ -1330,6 +1334,7 @@ do_prequeue:
}
}
}
+#endif
if ((flags & MSG_PEEK) && peek_seq != tp->copied_seq) {
if (net_ratelimit())
printk(KERN_DEBUG "TCP(%s:%d): Application bug, race in MSG_PEEK.\n",
@@ -1430,6 +1435,7 @@ skip_copy:
break;
} while (len > 0);
+#ifdef CONFIG_TCP_PREQUEUE
if (user_recv) {
if (!skb_queue_empty(&tp->ucopy.prequeue)) {
int chunk;
@@ -1448,6 +1454,7 @@ skip_copy:
tp->ucopy.task = NULL;
tp->ucopy.len = 0;
}
+#endif
#ifdef CONFIG_NET_DMA
if (tp->ucopy.dma_chan) {
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index bbad2cd..85d3a5c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3467,6 +3467,7 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
goto out_of_window;
/* Ok. In sequence. In window. */
+#ifdef CONFIG_TCP_PREQUEUE
if (tp->ucopy.task == current &&
tp->copied_seq == tp->rcv_nxt && tp->ucopy.len &&
sock_owned_by_user(sk) && !tp->urg_data) {
@@ -3484,7 +3485,7 @@ static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
}
local_bh_disable();
}
-
+#endif
if (eaten <= 0) {
queue_and_out:
if (eaten < 0 &&
@@ -4078,6 +4079,7 @@ static void tcp_urg(struct sock *sk, struct sk_buff *skb, struct tcphdr *th)
}
}
+#ifdef CONFIG_TCP_PREQUEUE
static int tcp_copy_to_iovec(struct sock *sk, struct sk_buff *skb, int hlen)
{
struct tcp_sock *tp = tcp_sk(sk);
@@ -4100,6 +4102,7 @@ static int tcp_copy_to_iovec(struct sock *sk, struct sk_buff *skb, int hlen)
local_bh_disable();
return err;
}
+#endif
static __sum16 __tcp_checksum_complete_user(struct sock *sk, struct sk_buff *skb)
{
@@ -4279,8 +4282,9 @@ int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
}
} else {
int eaten = 0;
- int copied_early = 0;
+#ifdef CONFIG_TCP_PREQUEUE
+ int copied_early = 0;
if (tp->copied_seq == tp->rcv_nxt &&
len - tcp_header_len <= tp->ucopy.len) {
#ifdef CONFIG_NET_DMA
@@ -4315,6 +4319,7 @@ int tcp_rcv_established(struct sock *sk, struct sk_buff *skb,
if (copied_early)
tcp_cleanup_rbuf(sk, skb->len);
}
+#endif
if (!eaten) {
if (tcp_checksum_complete_user(sk, skb))
goto csum_error;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 9c94627..7ac5bc1 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1916,8 +1916,10 @@ int tcp_v4_destroy_sock(struct sock *sk)
__skb_queue_purge(&sk->sk_async_wait_queue);
#endif
+#ifdef CONFIG_TCP_PREQUEUE
/* Clean prequeue, it must be empty really */
__skb_queue_purge(&tp->ucopy.prequeue);
+#endif
/* Clean up a referenced TCP bind bucket. */
if (inet_csk(sk)->icsk_bind_hash)
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index e9b151b..5f3b38c 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -167,7 +167,9 @@ static int tcp_write_timeout(struct sock *sk)
static void tcp_delack_timer(unsigned long data)
{
struct sock *sk = (struct sock*)data;
+#ifdef CONFIG_TCP_PREQUEUE
struct tcp_sock *tp = tcp_sk(sk);
+#endif
struct inet_connection_sock *icsk = inet_csk(sk);
bh_lock_sock(sk);
@@ -190,6 +192,7 @@ static void tcp_delack_timer(unsigned long data)
}
icsk->icsk_ack.pending &= ~ICSK_ACK_TIMER;
+#ifdef CONFIG_TCP_PREQUEUE
if (!skb_queue_empty(&tp->ucopy.prequeue)) {
struct sk_buff *skb;
@@ -200,6 +203,7 @@ static void tcp_delack_timer(unsigned long data)
tp->ucopy.memory = 0;
}
+#endif
if (inet_csk_ack_scheduled(sk)) {
if (!icsk->icsk_ack.pingpong) {
^ permalink raw reply related
* Re: Please pull 'upstream-davem' branch of wireless-2.6 (2007-09-27)
From: Jeff Garzik @ 2007-09-27 22:21 UTC (permalink / raw)
To: John W. Linville
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070927215324.GG7991-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
John W. Linville wrote:
> Dave & Jeff,
>
> Here are some more wireless stack and driver updates for 2.6.24. Please
> pull at your earliest convenience.
ACK (I presume davem will pull)
it looks like this includes my adm feedback, thanks!
^ permalink raw reply
* [PATCH] Bring comments in loopback.c uptodate.
From: Eric W. Biederman @ 2007-09-27 22:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
A hint as to why it is safe to use per cpu variables,
and note that we actually can have multiple instances
of the loopback device now.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
drivers/net/loopback.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 2617320..cba5c76 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -154,6 +154,7 @@ static int loopback_xmit(struct sk_buff *skb, struct net_device *dev)
#endif
dev->last_rx = jiffies;
+ /* it's OK to use per_cpu_ptr() because BHs are off */
pcpu_lstats = netdev_priv(dev);
lb_stats = per_cpu_ptr(pcpu_lstats, smp_processor_id());
lb_stats->bytes += skb->len;
@@ -221,7 +222,8 @@ static void loopback_dev_free(struct net_device *dev)
}
/*
- * The loopback device is special. There is only one instance.
+ * The loopback device is special. There is only one instance
+ * per network namespace.
*/
static void loopback_setup(struct net_device *dev)
{
--
1.5.3.rc6.17.g1911
^ permalink raw reply related
* [PATCH] netns: CLONE_NEWNET don't use the same clone flag as the pid namespace.
From: Eric W. Biederman @ 2007-09-27 22:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Linux Containers
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
include/linux/sched.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e10a0a8..d82c1f7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -27,7 +27,7 @@
#define CLONE_NEWUTS 0x04000000 /* New utsname group? */
#define CLONE_NEWIPC 0x08000000 /* New ipcs */
#define CLONE_NEWUSER 0x10000000 /* New user namespace */
-#define CLONE_NEWNET 0x20000000 /* New network namespace */
+#define CLONE_NEWNET 0x40000000 /* New network namespace */
/*
* Scheduling policies
--
1.5.3.rc6.17.g1911
^ permalink raw reply related
* Re: [RFC] Zero-length write() does not generate a datagram on connected socket
From: Stephen Hemminger @ 2007-09-27 22:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20070927.135334.56943477.davem@davemloft.net>
On Thu, 27 Sep 2007 13:53:34 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Mon, 24 Sep 2007 15:34:35 -0700
>
> > The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
> > describes an issue where write() can't be used to generate a zero-length
> > datagram (but send, and sendto do work).
> >
> > I think the following is needed:
> >
> > --- a/net/socket.c 2007-08-20 09:54:28.000000000 -0700
> > +++ b/net/socket.c 2007-09-24 15:31:25.000000000 -0700
> > @@ -777,8 +777,11 @@ static ssize_t sock_aio_write(struct kio
> > if (pos != 0)
> > return -ESPIPE;
> >
> > - if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> > - return 0;
> > + if (unlikely(iocb->ki_left == 0)) {
> > + struct socket *sock = iocb->ki_filp->private_data;
> > + if (sock->type == SOCK_STREAM)
> > + return 0;
> > + }
> >
> > x = alloc_sock_iocb(iocb, &siocb);
> > if (!x)
>
> We should simply remove the check completely.
>
> There is no need to add special code for different types of protocols
> and sockets.
>
> As is hinted in the bugzilla, the exact same thing can happen with a
> suitably constructed sendto() or sendmsg() call. write() on a socket
> is a sendmsg() with a NULL msg_control and a single entry iovec, plain
> and simple.
>
> It's how BSD and many other systems behave, and I double checked
> Steven's Volume 2 just to make sure.
>
> So I'm going to check in the following to fix this bugzilla. There is
> a similarly ugly test for len==0 in sys_read() on sockets. If someone
> would do some research on the validity of that thing I'd really
> appreciate it :-)
Read of zero length should be a no-op for SOCK_STREAM but
for SOCK_DATAGRAM or SOCK_SEQPACKET it might be useful as a
remote wait for event.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [RFC] Make TCP prequeue configurable
From: Stephen Hemminger @ 2007-09-27 22:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Netdev List
In-Reply-To: <46FC29E1.9010809@cosmosbay.com>
On Fri, 28 Sep 2007 00:08:33 +0200
Eric Dumazet <dada1@cosmosbay.com> wrote:
> Hi all
>
> I am sure some of you are going to tell me that prequeue is not
> all black :)
>
> Thank you
>
> [RFC] Make TCP prequeue configurable
>
> The TCP prequeue thing is based on old facts, and has drawbacks.
>
> 1) It adds 48 bytes per 'struct tcp_sock'
> 2) It adds some ugly code in hot paths
> 3) It has a small hit ratio on typical servers using many sockets
> 4) It may have a high hit ratio on UP machines running one process,
> where the prequeue adds litle gain. (In fact, letting the user
> doing the copy after being woke up is better for cache reuse)
> 5) Doing a copy to user in softirq handler is not good, because of
> potential page faults :(
> 6) Maybe the NET_DMA thing is the only thing that might need prequeue.
>
> This patch introduces a CONFIG_TCP_PREQUEUE, automatically selected if
> CONFIG_NET_DMA is on.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
Rather than having a two more compile cases and test cases to deal
with. If you can prove it is useless, make a case for killing
it completely.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH] net: Add network namespace clone & unshare support.
From: Eric W. Biederman @ 2007-09-27 23:00 UTC (permalink / raw)
To: David Miller; +Cc: containers, netdev, akpm
In-Reply-To: <20070927.124552.69400277.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> Eric, pick an appropriate new non-conflicting number NOW.
Done. My apologies for the confusion. I thought the
way Cedric and the IBM guys were testing someone would have
shouted at me long before now.
> This adds unnecessary extra work for Andrew Morton, which he has
> enough of already.
Cedric made a good point that we will have conflicts of code
being added to the same place in nsproxy.c and the like. So
I copied Andrew to give him a heads up.
I will gladly do what I can, to help. Working against 3 trees
development at the moment is a bit of a development challenge.
Eric
^ permalink raw reply
* Re: [RFC] Make TCP prequeue configurable
From: David Miller @ 2007-09-27 23:09 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <46FC29E1.9010809@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Fri, 28 Sep 2007 00:08:33 +0200
> 1) It adds 48 bytes per 'struct tcp_sock'
> 2) It adds some ugly code in hot paths
> 3) It has a small hit ratio on typical servers using many sockets
> 4) It may have a high hit ratio on UP machines running one process,
> where the prequeue adds litle gain. (In fact, letting the user
> doing the copy after being woke up is better for cache reuse)
> 5) Doing a copy to user in softirq handler is not good, because of
> potential page faults :(
> 6) Maybe the NET_DMA thing is the only thing that might need prequeue.
If you want to make changes at least get your facts straight in your
changelog message :-)
The prequeue doesn't do copies in softirqs, it acquires the user side
socket lock and runs the packet input path directly from there,
copying into userspace along the way.
You are making claims about performance based upon your understanding
of the code and your understanding of typical workloads, rather than
from actual measurements. In scientific communities this would make
you a quack at best :-)
^ permalink raw reply
* Re: Please pull 'upstream-davem' branch of wireless-2.6 (2007-09-27)
From: David Miller @ 2007-09-28 0:08 UTC (permalink / raw)
To: jeff-o2qLIJkoznsdnm+yROfE0A
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <46FC2D02.9000602-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
From: Jeff Garzik <jeff-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
Date: Thu, 27 Sep 2007 18:21:54 -0400
> John W. Linville wrote:
> > Dave & Jeff,
> >
> > Here are some more wireless stack and driver updates for 2.6.24. Please
> > pull at your earliest convenience.
>
> ACK (I presume davem will pull)
>
> it looks like this includes my adm feedback, thanks!
Pulled into net-2.6.24 and pushed back out, thanks!
^ permalink raw reply
* Re: [PATCH] Bring comments in loopback.c uptodate.
From: David Miller @ 2007-09-28 0:09 UTC (permalink / raw)
To: ebiederm; +Cc: netdev
In-Reply-To: <m1lkarhgw6.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 27 Sep 2007 16:39:53 -0600
>
> A hint as to why it is safe to use per cpu variables,
> and note that we actually can have multiple instances
> of the loopback device now.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netns: CLONE_NEWNET don't use the same clone flag as the pid namespace.
From: David Miller @ 2007-09-28 0:10 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, containers
In-Reply-To: <m1hclfhgv4.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 27 Sep 2007 16:40:31 -0600
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Add network namespace clone & unshare support.
From: David Miller @ 2007-09-28 0:10 UTC (permalink / raw)
To: ebiederm; +Cc: containers, netdev, akpm
In-Reply-To: <m18x6rhfy0.fsf@ebiederm.dsl.xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 27 Sep 2007 17:00:23 -0600
> I will gladly do what I can, to help. Working against 3 trees
> development at the moment is a bit of a development challenge.
Andrew has to work against 30 or so, so multiply your pain
by 10 to understand what he has to deal with :-)
^ permalink raw reply
* Re: [PATCH] net: Add network namespace clone & unshare support.
From: Andrew Morton @ 2007-09-28 0:25 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, containers, netdev
In-Reply-To: <20070927.171053.39175054.davem@davemloft.net>
On Thu, 27 Sep 2007 17:10:53 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> > I will gladly do what I can, to help. Working against 3 trees
> > development at the moment is a bit of a development challenge.
>
> Andrew has to work against 30 or so
I wish! A remerge presently involves pulling and merging 73 git trees, 9
quilt trees and maybe 1,500 -mm patches.
^ permalink raw reply
* 2.6.23-rc8 network problem. Mem leak? ip1000a?
From: linux @ 2007-09-28 2:06 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: linux
Uniprocessor Althlon 64, 64-bit kernel, 2G ECC RAM,
2.6.23-rc8 + linuxpps (5.0.0) + ip1000a driver.
(patch from http://marc.info/?l=linux-netdev&m=118980588419882)
After a few hours of operation, ntp loses the ability to send packets.
sendto() returns -EAGAIN to everything, including the 24-byte UDP packet
that is a response to ntpq.
-EAGAIN on a sendto() makes me think of memory problems, so here's
meminfo at the time:
### FAILED state ###
# cat /proc/meminfo
MemTotal: 2059384 kB
MemFree: 15332 kB
Buffers: 665608 kB
Cached: 18212 kB
SwapCached: 0 kB
Active: 380384 kB
Inactive: 355020 kB
SwapTotal: 5855208 kB
SwapFree: 5854552 kB
Dirty: 28504 kB
Writeback: 0 kB
AnonPages: 51608 kB
Mapped: 11852 kB
Slab: 1285348 kB
SReclaimable: 152968 kB
SUnreclaim: 1132380 kB
PageTables: 3888 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 6884900 kB
Committed_AS: 590528 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 265628 kB
VmallocChunk: 34359472059 kB
Killing and restarting ntpd gets it running again for a few hours.
Here's after about two hours of successful operation. (I'll try to
remember to run slabinfo before killing ntpd next time.)
### WORKING state ###
# cat /proc/meminfo
MemTotal: 2059384 kB
MemFree: 20252 kB
Buffers: 242688 kB
Cached: 41556 kB
SwapCached: 200 kB
Active: 285012 kB
Inactive: 147348 kB
SwapTotal: 5855208 kB
SwapFree: 5854212 kB
Dirty: 36 kB
Writeback: 0 kB
AnonPages: 148052 kB
Mapped: 12756 kB
Slab: 1582512 kB
SReclaimable: 134348 kB
SUnreclaim: 1448164 kB
PageTables: 4500 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 6884900 kB
Committed_AS: 689956 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 265628 kB
VmallocChunk: 34359472059 kB
# /usr/src/linux/Documentation/vm/slabinfo
Name Objects Objsize Space Slabs/Part/Cpu O/S O %Fr %Ef Flg
:0000016 1478 16 24.5K 6/3/1 256 0 50 96 *
:0000024 170 24 4.0K 1/0/1 170 0 0 99 *
:0000032 1339 32 45.0K 11/2/1 128 0 18 95 *
:0000040 102 40 4.0K 1/0/1 102 0 0 99 *
:0000064 5937 64 413.6K 101/15/1 64 0 14 91 *
:0000072 56 72 4.0K 1/0/1 56 0 0 98 *
:0000088 6946 88 618.4K 151/0/1 46 0 0 98 *
:0000096 23851 96 2.5M 616/144/1 42 0 23 90 *
:0000128 730 128 114.6K 28/6/1 32 0 21 81 *
:0000136 232 136 36.8K 9/6/1 30 0 66 85 *
:0000192 474 192 98.3K 24/4/1 21 0 16 92 *
:0000256 1385376 256 354.6M 86587/0/1 16 0 0 99 *
:0000320 12 304 4.0K 1/0/1 12 0 0 89 *A
:0000384 359 384 180.2K 44/23/1 10 0 52 76 *A
:0000512 1384316 512 708.7M 173040/1/1 8 0 0 99 *
:0000640 72 616 53.2K 13/5/1 6 0 38 83 *A
:0000704 1870 696 1.3M 170/0/1 11 1 0 93 *A
:0001024 427 1024 454.6K 111/9/1 4 0 8 96 *
:0001472 150 1472 245.7K 30/0/1 5 1 0 89 *
:0002048 158991 2048 325.7M 39759/25/1 4 1 0 99 *
:0004096 51 4096 245.7K 30/9/1 2 1 30 85 *
Acpi-State 51 80 4.0K 1/0/1 51 0 0 99
anon_vma 1032 16 28.6K 7/5/1 170 0 71 57
bdev_cache 43 720 36.8K 9/1/1 5 0 11 83 Aa
blkdev_requests 42 288 12.2K 3/0/1 14 0 0 98
buffer_head 59173 104 11.1M 2734/1690/1 39 0 61 54 a
cfq_io_context 223 152 40.9K 10/6/1 26 0 60 82
dentry 98641 192 19.7M 4813/274/1 21 0 5 96 a
ext3_inode_cache 115690 688 86.3M 10545/77/1 11 1 0 92 a
file_lock_cache 23 168 4.0K 1/0/1 23 0 0 94
idr_layer_cache 118 528 69.6K 17/1/1 7 0 5 89
inode_cache 1365 528 798.7K 195/0/1 7 0 0 90 a
kmalloc-131072 1 131072 131.0K 1/0/1 1 5 0 100
kmalloc-16384 8 16384 131.0K 8/0/1 1 2 0 100
kmalloc-32768 1 32768 32.7K 1/0/1 1 3 0 100
kmalloc-8 1535 8 12.2K 3/1/1 512 0 33 99
kmalloc-8192 10 8192 81.9K 10/0/1 1 1 0 100
mm_struct 54 800 57.3K 7/5/1 9 1 71 75 A
proc_inode_cache 12 560 16.3K 4/3/1 7 0 75 41 a
radix_tree_node 17076 552 13.5M 3319/1675/1 7 0 50 69
raid5-md5 258 1176 352.2K 43/0/1 6 1 0 86
shmem_inode_cache 22 712 20.4K 5/1/1 5 0 20 76
sighand_cache 88 2072 253.9K 31/3/1 3 1 9 71 A
signal_cache 88 720 77.8K 19/6/1 5 0 31 81 A
sigqueue 25 160 4.0K 1/0/1 25 0 0 97
skbuff_fclone_cache 158787 404 72.2M 17644/2/1 9 0 0 88 A
sock_inode_cache 65 600 53.2K 13/5/1 6 0 38 73 Aa
task_struct 145 1808 311.2K 38/6/1 4 1 15 84
uhci_urb_priv 73 56 4.0K 1/0/1 73 0 0 99
vm_area_struct 2947 168 540.6K 132/25/1 24 0 18 91
### WORKING state ###
After quite a few hours (about 15h40m), it failed again. I'm leaving it
in the failed state for now so I can answer questions. ntpd is running and
receiving packets, it just can't send any.
### FAILED state ###
# cat /proc/meminfo
MemTotal: 2059384 kB
MemFree: 98556 kB
Buffers: 3224 kB
Cached: 18888 kB
SwapCached: 3876 kB
Active: 16688 kB
Inactive: 13068 kB
SwapTotal: 5855208 kB
SwapFree: 5822068 kB
Dirty: 32 kB
Writeback: 0 kB
AnonPages: 6960 kB
Mapped: 4752 kB
Slab: 1907828 kB
SReclaimable: 1916 kB
SUnreclaim: 1905912 kB
PageTables: 3888 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 6884900 kB
Committed_AS: 575652 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 265628 kB
VmallocChunk: 34359472059 kB
# /usr/src/linux/Documentation/vm/slabinfo
Name Objects Objsize Space Slabs/Part/Cpu O/S O %Fr %Ef Flg
:0000016 1533 16 32.7K 8/5/1 256 0 62 74 *
:0000024 170 24 4.0K 1/0/1 170 0 0 99 *
:0000032 1339 32 45.0K 11/2/1 128 0 18 95 *
:0000040 102 40 4.0K 1/0/1 102 0 0 99 *
:0000064 3295 64 278.5K 68/24/1 64 0 35 75 *
:0000072 56 72 4.0K 1/0/1 56 0 0 98 *
:0000088 6946 88 618.4K 151/0/1 46 0 0 98 *
:0000096 2110 96 233.4K 57/9/1 42 0 15 86 *
:0000128 726 128 98.3K 24/2/1 32 0 8 94 *
:0000136 255 136 40.9K 10/6/1 30 0 60 84 *
:0000192 457 192 98.3K 24/4/1 21 0 16 89 *
:0000256 1893104 256 484.6M 118319/0/1 16 0 0 100 *
:0000320 12 304 4.0K 1/0/1 12 0 0 89 *A
:0000384 423 384 188.4K 46/14/1 10 0 30 86 *A
:0000512 1892180 512 968.8M 236524/4/1 8 0 0 99 *
:0000640 68 616 49.1K 12/4/1 6 0 33 85 *A
:0000704 2043 696 1.5M 186/1/1 11 1 0 93 *A
:0001024 435 1024 462.8K 113/11/1 4 0 9 96 *
:0001472 240 1472 393.2K 48/0/1 5 1 0 89 *
:0002048 196191 2048 401.8M 49052/14/1 4 1 0 99 *
:0004096 51 4096 237.5K 29/7/1 2 1 24 87 *
Acpi-State 51 80 4.0K 1/0/1 51 0 0 99
anon_vma 796 16 24.5K 6/4/1 170 0 66 51
bdev_cache 43 720 36.8K 9/1/1 5 0 11 83 Aa
blkdev_requests 46 288 16.3K 4/1/1 14 0 25 80
buffer_head 888 104 94.2K 23/2/1 39 0 8 98 a
cfq_io_context 249 152 45.0K 11/6/1 26 0 54 84
dentry 4242 192 831.4K 203/0/1 21 0 0 97 a
ext3_inode_cache 1341 688 1.0M 129/11/1 11 1 8 87 a
file_lock_cache 23 168 4.0K 1/0/1 23 0 0 94
idr_layer_cache 118 528 69.6K 17/1/1 7 0 5 89
inode_cache 959 528 565.2K 138/0/1 7 0 0 89 a
kmalloc-131072 1 131072 131.0K 1/0/1 1 5 0 100
kmalloc-16384 8 16384 131.0K 8/0/1 1 2 0 100
kmalloc-32768 1 32768 32.7K 1/0/1 1 3 0 100
kmalloc-8 1535 8 12.2K 3/1/1 512 0 33 99
kmalloc-8192 10 8192 81.9K 10/0/1 1 1 0 100
mm_struct 54 800 65.5K 8/6/1 9 1 75 65 A
proc_inode_cache 42 560 24.5K 6/0/1 7 0 0 95 a
radix_tree_node 985 552 811.0K 198/73/1 7 0 36 67
raid5-md5 258 1176 352.2K 43/0/1 6 1 0 86
shmem_inode_cache 24 712 20.4K 5/1/1 5 0 20 83
sighand_cache 86 2072 237.5K 29/1/1 3 1 3 75 A
signal_cache 85 720 77.8K 19/8/1 5 0 42 78 A
sigqueue 25 160 4.0K 1/0/1 25 0 0 97
skbuff_fclone_cache 196031 404 89.2M 21782/5/1 9 0 0 88 A
sock_inode_cache 62 600 53.2K 13/6/1 6 0 46 69 Aa
task_struct 140 1808 311.2K 38/9/1 4 1 23 81
uhci_urb_priv 73 56 4.0K 1/0/1 73 0 0 99
vm_area_struct 2666 168 466.9K 114/7/1 24 0 6 95
### FAILED state ###
I'm not sure quite where to point the blame. This hardware used to
run ntpd just fine with a 2.6.22 kernel, but I upgraded the base kernel,
the ip1000a driver, and the linuxpps patches at the same time.
With this time to failure, bisection is a challenge.
I'm not quite sure how it could be the ip1000a driver's fault, in a way
that breaks ntp but leaves ssh and other network services running.
And the linuxpps patches are very localized and only allocate
at initialization time. It's hard to see how they could cause
this effect.
There is a newly recompiled (new linuxpps API) ntpd, but it's hard to
see how it could cause the given symptoms, and the exact same source
code is running on a 32-bit machine (2.6.23-rc6 + linuxpps 5.0) just fine.
But it's also hard to imagine that I've found a new generic networking bug
that nobody else has noticed.
Can anyone offer some diagnosis advice?
This is actually the second (and third) time it's happened. The first
time, I ran strace and saw the same -EBUSY, but assumed I'd misconfigured
ntpd and bounced it. It started working, so I left it, then noticed
that it had stopped again and looked more closely.
FWIW, a "stuck" ntpd still responds to UDP queries from a localhost ntpd.
Here's the .config:
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_X86_PC=y
CONFIG_MK8=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_PREEMPT_NONE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_HPET_TIMER=y
CONFIG_IOMMU=y
CONFIG_SWIOTLB=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_AMD=y
CONFIG_PHYSICAL_START=0x200000
CONFIG_SECCOMP=y
CONFIG_HZ_250=y
CONFIG_HZ=250
CONFIG_K8_NB=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_ISA_DMA_API=y
CONFIG_PM=y
CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_HIBERNATION_UP_POSSIBLE=y
CONFIG_ACPI=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_HT_IRQ=y
CONFIG_BINFMT_ELF=y
CONFIG_IA32_EMULATION=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_NETFILTER=y
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_QUOTA=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_VLAN_8021Q=y
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RR=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_PEDIT=y
CONFIG_NET_ACT_SIMP=y
CONFIG_NET_CLS_POLICE=y
CONFIG_FIB_RULES=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=65536
CONFIG_BLK_DEV_RAM_BLOCKSIZE=4096
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEACPI=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_AMD74XX=m
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_WAIT_SCAN=m
CONFIG_ATA=y
CONFIG_ATA_ACPI=y
CONFIG_SATA_NV=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_VIA=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID10=y
CONFIG_MD_RAID456=y
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_TUN=y
CONFIG_IP1000=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_NET_PCI=y
CONFIG_FORCEDETH=y
CONFIG_NETDEV_1000=y
CONFIG_SKGE=y
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_PRINTER=y
CONFIG_RTC=y
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=y
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_VIAPRO=y
CONFIG_SENSORS_EEPROM=y
CONFIG_PPS=y
CONFIG_PPS_CLIENT_UART=y
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=y
CONFIG_SENSORS_K8TEMP=y
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_W83627HF=m
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_VIA82XX=m
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_USB_HID=y
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP2101=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_EZUSB=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_DMIID=y
CONFIG_EXT2_FS=m
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_DNOTIFY=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_UTF8=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_MEMCPY=y
CONFIG_ASYNC_XOR=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_DEFLATE=y
CONFIG_BITREVERSE=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
^ permalink raw reply
* Re: [RFC] Make TCP prequeue configurable
From: John Heffner @ 2007-09-28 2:26 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Eric Dumazet, Linux Netdev List
In-Reply-To: <20070927154432.6ca3b525@freepuppy.rosehill>
Stephen Hemminger wrote:
> On Fri, 28 Sep 2007 00:08:33 +0200
> Eric Dumazet <dada1@cosmosbay.com> wrote:
>
>> Hi all
>>
>> I am sure some of you are going to tell me that prequeue is not
>> all black :)
>>
>> Thank you
>>
>> [RFC] Make TCP prequeue configurable
>>
>> The TCP prequeue thing is based on old facts, and has drawbacks.
>>
>> 1) It adds 48 bytes per 'struct tcp_sock'
>> 2) It adds some ugly code in hot paths
>> 3) It has a small hit ratio on typical servers using many sockets
>> 4) It may have a high hit ratio on UP machines running one process,
>> where the prequeue adds litle gain. (In fact, letting the user
>> doing the copy after being woke up is better for cache reuse)
>> 5) Doing a copy to user in softirq handler is not good, because of
>> potential page faults :(
>> 6) Maybe the NET_DMA thing is the only thing that might need prequeue.
>>
>> This patch introduces a CONFIG_TCP_PREQUEUE, automatically selected if
>> CONFIG_NET_DMA is on.
>>
>> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>>
>
> Rather than having a two more compile cases and test cases to deal
> with. If you can prove it is useless, make a case for killing
> it completely.
I think it really does help in case (4) with old NICs that don't do rx
checksumming. I'm not sure how many people really care about this
anymore, but probably some...?
OTOH, it would be nice to get rid of sysctl_tcp_low_latency.
-John
^ permalink raw reply
* Re: [PATCH] net: Add network namespace clone & unshare support.
From: Eric W. Biederman @ 2007-09-28 3:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: David Miller, containers, netdev
In-Reply-To: <20070927172533.1dd1db31.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Thu, 27 Sep 2007 17:10:53 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
>> > I will gladly do what I can, to help. Working against 3 trees
>> > development at the moment is a bit of a development challenge.
>>
>> Andrew has to work against 30 or so
>
> I wish! A remerge presently involves pulling and merging 73 git trees, 9
> quilt trees and maybe 1,500 -mm patches.
Yep. There is a lot of chaos and keeping on top of it all is a pain,
and nobody has it easy.
Andrew probably wins award for the biggest challenge.
My todo list pales in comparison. I only have 80+ patches in my
queue that I need to reviewed and then pushed upstream. 50 sysfs
patches to review and get a handle on so hopefully we can out of the
sysfs quagmire.
Plus I don't know how many little gotchas that need to be fixed with
a new patch of their own.
It's coming together but it takes time.
David, Andrew thanks you both are really are good upstream maintainers
to work with.
Eric
^ permalink raw reply
* Re: [PATCH] sky2: sky2 FE+ receive status workaround
From: Jeff Garzik @ 2007-09-28 3:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20070926175847.706025d0@freepuppy.rosehill>
Stephen Hemminger wrote:
> Patch against 2.6.23-rc8, please apply before 2.6.23 release (or it will
> need to go to stable).
Applied. Please always put meta-information such as the above quoted
after the "---" patch description terminator, so that it is not copied
into the permanent kernel changelog. This text must be hand-edited out
of each patch, before application.
^ permalink raw reply
* Re: [PATCH 1/2] sky2: FE+ vlan workaround
From: Jeff Garzik @ 2007-09-28 3:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20070927123244.0257ab86@freepuppy.rosehill>
Stephen Hemminger wrote:
> This patch applies to 2.6.23-rc8 after yesterday's patch:
> sky2 FE+ receive status workaround
Applied. Please always put meta-information such as the above quoted
after the "---" patch description terminator, so that it is not copied
into the permanent kernel changelog. This text must be hand-edited out
of each patch, before application.
See item #14 of Documentation/SubmittingPatches.
^ permalink raw reply
* Re: [PATCH 2/2] sky2: fix transmit state on resume
From: Jeff Garzik @ 2007-09-28 3:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20070927123812.4e2185f3@freepuppy.rosehill>
Stephen Hemminger wrote:
> Patch is against 2.6.23-rc8 after last patch:
> sky2: FE+ vlan workaround
>
> (Should also work on older releases with minor fuzz).
Applied. Please always put meta-information such as the above quoted
after the "---" patch description terminator, so that it is not copied
into the permanent kernel changelog. This text must be hand-edited out
of each patch, before application.
See item #14 of Documentation/SubmittingPatches.
^ permalink raw reply
* Re: [PATCH] Clean up redundant PHY write line for ULi526x Ethernet driver
From: Jeff Garzik @ 2007-09-28 3:36 UTC (permalink / raw)
Cc: Zang Roy-r61911, Andrew Morton, netdev, Kyle McMartin,
Grant Grundler
In-Reply-To: <1190624262.20089.7.camel@localhost.localdomain>
Zang Roy-r61911 wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Clean up redundant PHY write line for ULi526x Ethernet
> Driver.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> drivers/net/tulip/uli526x.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
> index ca2548e..53a8e65 100644
> --- a/drivers/net/tulip/uli526x.c
> +++ b/drivers/net/tulip/uli526x.c
> @@ -1512,7 +1512,6 @@ static void uli526x_process_mode(struct uli526x_board_info *db)
> case ULI526X_100MFD: phy_reg = 0x2100; break;
> }
> phy_write(db->ioaddr, db->phy_addr, 0, phy_reg, db->chip_id);
> - phy_write(db->ioaddr, db->phy_addr, 0, phy_reg, db->chip_id);
Kyle and Grant, I'll queue this up, unless ya'll object...
Jeff
^ permalink raw reply
* Re: [PATCH] e1000: Add device IDs of blade version of the 82571 quad port
From: Jeff Garzik @ 2007-09-28 3:38 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev, john.ronciak
In-Reply-To: <20070830182357.14185.69495.stgit@localhost.localdomain>
Auke Kok wrote:
> This blade-specific board form factor is identical to the 82571EB
> board.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000/e1000_ethtool.c | 1 +
> drivers/net/e1000/e1000_hw.c | 1 +
> drivers/net/e1000/e1000_hw.h | 1 +
> drivers/net/e1000/e1000_main.c | 2 ++
> 4 files changed, 5 insertions(+), 0 deletions(-)
applied
^ permalink raw reply
* [PATCH] Update get_net_ns_by_pid
From: Eric W. Biederman @ 2007-09-28 3:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linux Containers, netdev
In the -mm tree the rules for access an nsproxy have changed,
and in get_net_ns_by_pid we access the nsproxy, so update
it to follow the new rules.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 739fbad..1caba10 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -746,10 +746,10 @@ static struct net *get_net_ns_by_pid(pid_t pid)
rcu_read_lock();
tsk = find_task_by_pid(pid);
if (tsk) {
- task_lock(tsk);
- if (tsk->nsproxy)
- net = get_net(tsk->nsproxy->net_ns);
- task_unlock(tsk);
+ struct nsproxy *nsproxy;
+ nsproxy = task_nsproxy(tsk);
+ if (nsproxy)
+ net = get_net(nsproxy->net_ns);
}
rcu_read_unlock();
return net;
^ permalink raw reply related
* e1000 tcp checksum incorrect, x86 64b
From: Jon Smirl @ 2007-09-28 3:50 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
App is writing seven bytes to the socket. Socket write timeout expires
and the seven bytes are sent. The checksum is not getting inserted
into the packet. It is set to a constant 0x8389 instead of the right
value. App is gmpc 0.15.4.95, Revision: 6794
Attached Wireshark packet trace show the problem. e1000 is 192.168.1.4
64bit, Q6600. Dell Dimension 9200
Checksum is being computed ok for file copy traffic.
Problem was in rc7 too, I upgraded to current git to see if it was
fixed and it isn't
Wireshark is 0.99.4 from Ubuntu in case it is the problem.
--
Jon Smirl
jonsmirl@gmail.com
[-- Attachment #2: checkerr --]
[-- Type: application/octet-stream, Size: 9733 bytes --]
^ permalink raw reply
* Re: e1000 tcp checksum incorrect, x86 64b
From: Herbert Xu @ 2007-09-28 4:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: netdev
In-Reply-To: <9e4733910709272050t65e76312k52fd7493b899071d@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
>
> App is writing seven bytes to the socket. Socket write timeout expires
> and the seven bytes are sent. The checksum is not getting inserted
> into the packet. It is set to a constant 0x8389 instead of the right
> value. App is gmpc 0.15.4.95, Revision: 6794
>
> Attached Wireshark packet trace show the problem. e1000 is 192.168.1.4
> 64bit, Q6600. Dell Dimension 9200
Wireshark is broken. It needs to know TP_STATUS_CSUMNOTREADY
means that the checksum is partial and will only be completed
when the hardware sends the packet out.
Alternatively disable checksum offload with ethtool.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Clean up redundant PHY write line for ULi526x Ethernet driver
From: Grant Grundler @ 2007-09-28 3:57 UTC (permalink / raw)
To: Jeff Garzik
Cc: Zang Roy-r61911, Andrew Morton, netdev, Kyle McMartin,
Grant Grundler
In-Reply-To: <46FC76DA.6030906@garzik.org>
On Thu, Sep 27, 2007 at 11:36:58PM -0400, Jeff Garzik wrote:
> Zang Roy-r61911 wrote:
>> From: Roy Zang <tie-fei.zang@freescale.com>
>> Clean up redundant PHY write line for ULi526x Ethernet
>> Driver.
>> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
>> ---
>> drivers/net/tulip/uli526x.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>> diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
>> index ca2548e..53a8e65 100644
>> --- a/drivers/net/tulip/uli526x.c
>> +++ b/drivers/net/tulip/uli526x.c
>> @@ -1512,7 +1512,6 @@ static void uli526x_process_mode(struct
>> uli526x_board_info *db)
>> case ULI526X_100MFD: phy_reg = 0x2100; break;
>> }
>> phy_write(db->ioaddr, db->phy_addr, 0, phy_reg, db->chip_id);
>> - phy_write(db->ioaddr, db->phy_addr, 0, phy_reg, db->chip_id);
>
> Kyle and Grant, I'll queue this up, unless ya'll object...
please do, I've already Ack'd it for akpm's tree when he sent out the
initial cc.
thanks,
grant
>
> Jeff
>
^ 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