Re: [RFC, PATCH] dont insert sockets/pipes dentries into dentry_hashtable.
David Miller a écrit : From: Eric Dumazet [EMAIL PROTECTED] Date: Tue, 31 Oct 2006 19:48:48 +0100 We currently insert sockets/pipes dentries into the global dentry hashtable. This is *useless* because there is currently no way these entries can be used for a lookup(). (/proc/xxx/fd/xxx uses a different mechanism) It turns out that while procfs uses a different mechanism, those procfs symlinks do point to the real socket dentry, so when you readlink() on it you do d_path() on the real socket dentry. If you unhash these things, I'm pretty sure you'll see an ugly (deleted) at the end of the symlink string for /proc/$pid/fd/$X files that are sockets or something like that. No no, my patch takes care of that. You still see the right link for pipes and sockets on /proc/$pid/fd/XXX And (deleted) is correctly added to deleted files. Al Viro just suggested a way around this to me: 1) Just mark the dentry HASHED by hand in the dentry flags, but don't actually hash it. 2) Create a special dentry-d_deleted method for sockets that returns 0 and clears by hand the HASHED flag bit in the dentry (see what dput() does when this happens). It's an abuse but it will work. Why hack when a proper thing can be done ? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] dont insert sockets/pipes dentries into dentry_hashtable.
From: Eric Dumazet [EMAIL PROTECTED] Date: Wed, 01 Nov 2006 09:21:06 +0100 No no, my patch takes care of that. You still see the right link for pipes and sockets on /proc/$pid/fd/XXX And (deleted) is correctly added to deleted files. I see. Excellent :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] dont insert sockets/pipes dentries into dentry_hashtable.
On Wed, Nov 01, 2006 at 09:21:06AM +0100, Eric Dumazet wrote: And (deleted) is correctly added to deleted files. The hell it will. touch a touch b exec 5a mv b a ls -l /proc/$$/fd/5 With your patch and without it, please. PS: getting rid of socket dentries is a bad idea with the capital Fuck, No. For those who want to see where does that path lead and are attracted to trainwrecks in general I can recommend *BSD socket handling. They have paid quite painfully for lack of proper vnodes. It's simply not worth the resulting trouble. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] dont insert sockets/pipes dentries into dentry_hashtable.
On Wed, Nov 01, 2006 at 08:38:11AM +, Al Viro wrote: On Wed, Nov 01, 2006 at 09:21:06AM +0100, Eric Dumazet wrote: And (deleted) is correctly added to deleted files. The hell it will. touch a touch b exec 5a mv b a ls -l /proc/$$/fd/5 With your patch and without it, please. While we are at it, touch a rm a touch a ls -l /proc/self/fd/0 a With and without your patch. Note that you never remove DCACHE_DELETED after you've set it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, 25 Oct 2006 22:15:23 -0700, Simon Barber wrote: Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) This is something I really want too. However, the biggest problem is bridging. A lot of people bridge their ethernet and wifi interfaces together. We'll need to change the bridging code to make it possible again. I would also like to see: Drivers to use register_netdev - not special ieee80211 register to register themselves I don't see a benefit in this, but well, let's consider it when there is a patch. Drivers to use a normal hard_start_xmit function - need to move 802.11 pre xmit frame processing into the qdisc dequeue function Agreed. It's not a priority, though. Get rid of gunky beacon multicast buffered frame handling - make them into normal queues like everything else (so same hard_start_xmit can be used). I'm not sure about beacons here - don't some drivers need to handle them specially? Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[take22 2/4] kevent: poll/select() notifications.
poll/select() notifications.
This patch includes generic poll/select notifications.
kevent_poll works simialr to epoll and has the same issues (callback
is invoked not from internal state machine of the caller, but through
process awake, a lot of allocations and so on).
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 5baf3a1..f81299f 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -276,6 +276,7 @@ #include linux/prio_tree.h
#include linux/init.h
#include linux/sched.h
#include linux/mutex.h
+#include linux/kevent.h
#include asm/atomic.h
#include asm/semaphore.h
@@ -586,6 +587,10 @@ #ifdef CONFIG_INOTIFY
struct mutexinotify_mutex; /* protects the watches list */
#endif
+#ifdef CONFIG_KEVENT_SOCKET
+ struct kevent_storage st;
+#endif
+
unsigned long i_state;
unsigned long dirtied_when; /* jiffies of first dirtying */
@@ -739,6 +744,9 @@ #ifdef CONFIG_EPOLL
struct list_headf_ep_links;
spinlock_t f_ep_lock;
#endif /* #ifdef CONFIG_EPOLL */
+#ifdef CONFIG_KEVENT_POLL
+ struct kevent_storage st;
+#endif
struct address_space*f_mapping;
};
extern spinlock_t files_lock;
diff --git a/kernel/kevent/kevent_poll.c b/kernel/kevent/kevent_poll.c
new file mode 100644
index 000..94facbb
--- /dev/null
+++ b/kernel/kevent/kevent_poll.c
@@ -0,0 +1,222 @@
+/*
+ * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/timer.h
+#include linux/file.h
+#include linux/kevent.h
+#include linux/poll.h
+#include linux/fs.h
+
+static kmem_cache_t *kevent_poll_container_cache;
+static kmem_cache_t *kevent_poll_priv_cache;
+
+struct kevent_poll_ctl
+{
+ struct poll_table_structpt;
+ struct kevent *k;
+};
+
+struct kevent_poll_wait_container
+{
+ struct list_headcontainer_entry;
+ wait_queue_head_t *whead;
+ wait_queue_twait;
+ struct kevent *k;
+};
+
+struct kevent_poll_private
+{
+ struct list_headcontainer_list;
+ spinlock_t container_lock;
+};
+
+static int kevent_poll_enqueue(struct kevent *k);
+static int kevent_poll_dequeue(struct kevent *k);
+static int kevent_poll_callback(struct kevent *k);
+
+static int kevent_poll_wait_callback(wait_queue_t *wait,
+ unsigned mode, int sync, void *key)
+{
+ struct kevent_poll_wait_container *cont =
+ container_of(wait, struct kevent_poll_wait_container, wait);
+ struct kevent *k = cont-k;
+ struct file *file = k-st-origin;
+ u32 revents;
+
+ revents = file-f_op-poll(file, NULL);
+
+ kevent_storage_ready(k-st, NULL, revents);
+
+ return 0;
+}
+
+static void kevent_poll_qproc(struct file *file, wait_queue_head_t *whead,
+ struct poll_table_struct *poll_table)
+{
+ struct kevent *k =
+ container_of(poll_table, struct kevent_poll_ctl, pt)-k;
+ struct kevent_poll_private *priv = k-priv;
+ struct kevent_poll_wait_container *cont;
+ unsigned long flags;
+
+ cont = kmem_cache_alloc(kevent_poll_container_cache, SLAB_KERNEL);
+ if (!cont) {
+ kevent_break(k);
+ return;
+ }
+
+ cont-k = k;
+ init_waitqueue_func_entry(cont-wait, kevent_poll_wait_callback);
+ cont-whead = whead;
+
+ spin_lock_irqsave(priv-container_lock, flags);
+ list_add_tail(cont-container_entry, priv-container_list);
+ spin_unlock_irqrestore(priv-container_lock, flags);
+
+ add_wait_queue(whead, cont-wait);
+}
+
+static int kevent_poll_enqueue(struct kevent *k)
+{
+ struct file *file;
+ int err, ready = 0;
+ unsigned int revents;
+ struct kevent_poll_ctl ctl;
+ struct kevent_poll_private *priv;
+
+ file = fget(k-event.id.raw[0]);
+ if (!file)
+ return -EBADF;
+
+ err = -EINVAL;
+ if (!file-f_op || !file-f_op-poll)
+ goto err_out_fput;
+
+ err = -ENOMEM;
+ priv = kmem_cache_alloc(kevent_poll_priv_cache, SLAB_KERNEL);
+ if (!priv)
+ goto err_out_fput;
+
+
[take22 0/4] kevent: Generic event handling mechanism.
Generic event handling mechanism. Consider for inclusion. Changes from 'take21' patchset: * minor cleanups (different return values, removed unneded variables, whitespaces and so on) * fixed bug in kevent removal in case when kevent being removed is the same as overflow_kevent (spotted by Eric Dumazet) Changes from 'take20' patchset: * new ring buffer implementation * removed artificial limit on possible number of kevents With this release and fixed userspace web server it was possible to achive 3960+ req/s with client connection rate of 4000 con/s over 100 Mbit lan, data IO over network was about 10582.7 KB/s, which is too close to wire speed if we get into account headers and the like. Changes from 'take19' patchset: * use __init instead of __devinit * removed 'default N' from config for user statistic * removed kevent_user_fini() since kevent can not be unloaded * use KERN_INFO for statistic output Changes from 'take18' patchset: * use __init instead of __devinit * removed 'default N' from config for user statistic * removed kevent_user_fini() since kevent can not be unloaded * use KERN_INFO for statistic output Changes from 'take17' patchset: * Use RB tree instead of hash table. At least for a web sever, frequency of addition/deletion of new kevent is comparable with number of search access, i.e. most of the time events are added, accesed only couple of times and then removed, so it justifies RB tree usage over AVL tree, since the latter does have much slower deletion time (max O(log(N)) compared to 3 ops), although faster search time (1.44*O(log(N)) vs. 2*O(log(N))). So for kevents I use RB tree for now and later, when my AVL tree implementation is ready, it will be possible to compare them. * Changed readiness check for socket notifications. With both above changes it is possible to achieve more than 3380 req/second compared to 2200, sometimes 2500 req/second for epoll() for trivial web-server and httperf client on the same hardware. It is possible that above kevent limit is due to maximum allowed kevents in a time limit, which is 4096 events. Changes from 'take16' patchset: * misc cleanups (__read_mostly, const ...) * created special macro which is used for mmap size (number of pages) calculation * export kevent_socket_notify(), since it is used in network protocols which can be built as modules (IPv6 for example) Changes from 'take15' patchset: * converted kevent_timer to high-resolution timers, this forces timer API update at http://linux-net.osdl.org/index.php/Kevent * use struct ukevent* instead of void * in syscalls (documentation has been updated) * added warning in kevent_add_ukevent() if ring has broken index (for testing) Changes from 'take14' patchset: * added kevent_wait() This syscall waits until either timeout expires or at least one event becomes ready. It also commits that @num events from @start are processed by userspace and thus can be be removed or rearmed (depending on it's flags). It can be used for commit events read by userspace through mmap interface. Example userspace code (evtest.c) can be found on project's homepage. * added socket notifications (send/recv/accept) Changes from 'take13' patchset: * do not get lock aroung user data check in __kevent_search() * fail early if there were no registered callbacks for given type of kevent * trailing whitespace cleanup Changes from 'take12' patchset: * remove non-chardev interface for initialization * use pointer to kevent_mring instead of unsigned longs * use aligned 64bit type in raw user data (can be used by high-res timer if needed) * simplified enqueue/dequeue callbacks and kevent initialization * use nanoseconds for timeout * put number of milliseconds into timer's return data * move some definitions into user-visible header * removed filenames from comments Changes from 'take11' patchset: * include missing headers into patchset * some trivial code cleanups (use goto instead of if/else games and so on) * some whitespace cleanups * check for ready_callback() callback before main loop which should save us some ticks Changes from 'take10' patchset: * removed non-existent prototypes * added helper function for kevent_registered_callbacks * fixed 80 lines comments issues * added shared between userspace and kernelspace header instead of embedd them in one * core restructuring to remove forward declarations * s o m e w h i t e s p a c e c o d y n g s t y l e c l e a n u p * use vm_insert_page() instead of remap_pfn_range() Changes from 'take9' patchset: * fixed -nopage method Changes from 'take8' patchset: * fixed mmap release bug * use module_init() instead of late_initcall() * use better structures for timer notifications Changes from 'take7' patchset: * new mmap interface (not tested, waiting for other changes to be acked) -
[take22 3/4] kevent: Socket notifications.
Socket notifications.
This patch includes socket send/recv/accept notifications.
Using trivial web server based on kevent and this features
instead of epoll it's performance increased more than noticebly.
More details about various benchmarks and server itself
(evserver_kevent.c) can be found on project's homepage.
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/fs/inode.c b/fs/inode.c
index ada7643..ff1b129 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -21,6 +21,7 @@ #include linux/pagemap.h
#include linux/cdev.h
#include linux/bootmem.h
#include linux/inotify.h
+#include linux/kevent.h
#include linux/mount.h
/*
@@ -164,12 +165,18 @@ #endif
}
inode-i_private = 0;
inode-i_mapping = mapping;
+#if defined CONFIG_KEVENT_SOCKET
+ kevent_storage_init(inode, inode-st);
+#endif
}
return inode;
}
void destroy_inode(struct inode *inode)
{
+#if defined CONFIG_KEVENT_SOCKET
+ kevent_storage_fini(inode-st);
+#endif
BUG_ON(inode_has_buffers(inode));
security_inode_free(inode);
if (inode-i_sb-s_op-destroy_inode)
diff --git a/include/net/sock.h b/include/net/sock.h
index edd4d73..d48ded8 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -48,6 +48,7 @@ #include linux/lockdep.h
#include linux/netdevice.h
#include linux/skbuff.h /* struct sk_buff */
#include linux/security.h
+#include linux/kevent.h
#include linux/filter.h
@@ -450,6 +451,21 @@ static inline int sk_stream_memory_free(
extern void sk_stream_rfree(struct sk_buff *skb);
+struct socket_alloc {
+ struct socket socket;
+ struct inode vfs_inode;
+};
+
+static inline struct socket *SOCKET_I(struct inode *inode)
+{
+ return container_of(inode, struct socket_alloc, vfs_inode)-socket;
+}
+
+static inline struct inode *SOCK_INODE(struct socket *socket)
+{
+ return container_of(socket, struct socket_alloc, socket)-vfs_inode;
+}
+
static inline void sk_stream_set_owner_r(struct sk_buff *skb, struct sock *sk)
{
skb-sk = sk;
@@ -477,6 +493,7 @@ static inline void sk_add_backlog(struct
sk-sk_backlog.tail = skb;
}
skb-next = NULL;
+ kevent_socket_notify(sk, KEVENT_SOCKET_RECV);
}
#define sk_wait_event(__sk, __timeo, __condition) \
@@ -679,21 +696,6 @@ static inline struct kiocb *siocb_to_kio
return si-kiocb;
}
-struct socket_alloc {
- struct socket socket;
- struct inode vfs_inode;
-};
-
-static inline struct socket *SOCKET_I(struct inode *inode)
-{
- return container_of(inode, struct socket_alloc, vfs_inode)-socket;
-}
-
-static inline struct inode *SOCK_INODE(struct socket *socket)
-{
- return container_of(socket, struct socket_alloc, socket)-vfs_inode;
-}
-
extern void __sk_stream_mem_reclaim(struct sock *sk);
extern int sk_stream_mem_schedule(struct sock *sk, int size, int kind);
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 7a093d0..69f4ad2 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -857,6 +857,7 @@ static inline int tcp_prequeue(struct so
tp-ucopy.memory = 0;
} else if (skb_queue_len(tp-ucopy.prequeue) == 1) {
wake_up_interruptible(sk-sk_sleep);
+ kevent_socket_notify(sk,
KEVENT_SOCKET_RECV|KEVENT_SOCKET_SEND);
if (!inet_csk_ack_scheduled(sk))
inet_csk_reset_xmit_timer(sk, ICSK_TIME_DACK,
(3 * TCP_RTO_MIN) / 4,
diff --git a/kernel/kevent/kevent_socket.c b/kernel/kevent/kevent_socket.c
new file mode 100644
index 000..5040b4c
--- /dev/null
+++ b/kernel/kevent/kevent_socket.c
@@ -0,0 +1,129 @@
+/*
+ * kevent_socket.c
+ *
+ * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/timer.h
+#include linux/file.h
+#include linux/tcp.h
+#include linux/kevent.h
+
+#include net/sock.h
+#include net/request_sock.h
+#include net/inet_connection_sock.h
+
+static int
[take22 4/4] kevent: Timer notifications.
Timer notifications.
Timer notifications can be used for fine grained per-process time
management, since interval timers are very inconvenient to use,
and they are limited.
This subsystem uses high-resolution timers.
id.raw[0] is used as number of seconds
id.raw[1] is used as number of nanoseconds
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/kernel/kevent/kevent_timer.c b/kernel/kevent/kevent_timer.c
new file mode 100644
index 000..04acc46
--- /dev/null
+++ b/kernel/kevent/kevent_timer.c
@@ -0,0 +1,113 @@
+/*
+ * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/types.h
+#include linux/list.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/hrtimer.h
+#include linux/jiffies.h
+#include linux/kevent.h
+
+struct kevent_timer
+{
+ struct hrtimer ktimer;
+ struct kevent_storage ktimer_storage;
+ struct kevent *ktimer_event;
+};
+
+static int kevent_timer_func(struct hrtimer *timer)
+{
+ struct kevent_timer *t = container_of(timer, struct kevent_timer,
ktimer);
+ struct kevent *k = t-ktimer_event;
+
+ kevent_storage_ready(t-ktimer_storage, NULL, KEVENT_MASK_ALL);
+ hrtimer_forward(timer, timer-base-softirq_time,
+ ktime_set(k-event.id.raw[0], k-event.id.raw[1]));
+ return HRTIMER_RESTART;
+}
+
+static struct lock_class_key kevent_timer_key;
+
+static int kevent_timer_enqueue(struct kevent *k)
+{
+ int err;
+ struct kevent_timer *t;
+
+ t = kmalloc(sizeof(struct kevent_timer), GFP_KERNEL);
+ if (!t)
+ return -ENOMEM;
+
+ hrtimer_init(t-ktimer, CLOCK_MONOTONIC, HRTIMER_REL);
+ t-ktimer.expires = ktime_set(k-event.id.raw[0], k-event.id.raw[1]);
+ t-ktimer.function = kevent_timer_func;
+ t-ktimer_event = k;
+
+ err = kevent_storage_init(t-ktimer, t-ktimer_storage);
+ if (err)
+ goto err_out_free;
+ lockdep_set_class(t-ktimer_storage.lock, kevent_timer_key);
+
+ err = kevent_storage_enqueue(t-ktimer_storage, k);
+ if (err)
+ goto err_out_st_fini;
+
+ printk(%s: jiffies: %lu, timer: %p.\n, __func__, jiffies, t-ktimer);
+ hrtimer_start(t-ktimer, t-ktimer.expires, HRTIMER_REL);
+
+ return 0;
+
+err_out_st_fini:
+ kevent_storage_fini(t-ktimer_storage);
+err_out_free:
+ kfree(t);
+
+ return err;
+}
+
+static int kevent_timer_dequeue(struct kevent *k)
+{
+ struct kevent_storage *st = k-st;
+ struct kevent_timer *t = container_of(st, struct kevent_timer,
ktimer_storage);
+
+ hrtimer_cancel(t-ktimer);
+ kevent_storage_dequeue(st, k);
+ kfree(t);
+
+ return 0;
+}
+
+static int kevent_timer_callback(struct kevent *k)
+{
+ k-event.ret_data[0] = jiffies_to_msecs(jiffies);
+ return 1;
+}
+
+static int __init kevent_init_timer(void)
+{
+ struct kevent_callbacks tc = {
+ .callback = kevent_timer_callback,
+ .enqueue = kevent_timer_enqueue,
+ .dequeue = kevent_timer_dequeue};
+
+ return kevent_add_callbacks(tc, KEVENT_TIMER);
+}
+module_init(kevent_init_timer);
+
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[take22 1/4] kevent: Core files.
Core files.
This patch includes core kevent files:
* userspace controlling
* kernelspace interfaces
* initialization
* notification state machines
Some bits of documentation can be found on project's homepage (and links from
there):
http://tservice.net.ru/~s0mbre/old/?section=projectsitem=kevent
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index 7e639f7..a9560eb 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -318,3 +318,6 @@ ENTRY(sys_call_table)
.long sys_vmsplice
.long sys_move_pages
.long sys_getcpu
+ .long sys_kevent_get_events
+ .long sys_kevent_ctl/* 320 */
+ .long sys_kevent_wait
diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S
index b4aa875..cf18955 100644
--- a/arch/x86_64/ia32/ia32entry.S
+++ b/arch/x86_64/ia32/ia32entry.S
@@ -714,8 +714,11 @@ #endif
.quad compat_sys_get_robust_list
.quad sys_splice
.quad sys_sync_file_range
- .quad sys_tee
+ .quad sys_tee /* 315 */
.quad compat_sys_vmsplice
.quad compat_sys_move_pages
.quad sys_getcpu
+ .quad sys_kevent_get_events
+ .quad sys_kevent_ctl/* 320 */
+ .quad sys_kevent_wait
ia32_syscall_end:
diff --git a/include/asm-i386/unistd.h b/include/asm-i386/unistd.h
index bd99870..f009677 100644
--- a/include/asm-i386/unistd.h
+++ b/include/asm-i386/unistd.h
@@ -324,10 +324,13 @@ #define __NR_tee 315
#define __NR_vmsplice 316
#define __NR_move_pages317
#define __NR_getcpu318
+#define __NR_kevent_get_events 319
+#define __NR_kevent_ctl320
+#define __NR_kevent_wait 321
#ifdef __KERNEL__
-#define NR_syscalls 319
+#define NR_syscalls 322
#include linux/err.h
/*
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index 6137146..c53d156 100644
--- a/include/asm-x86_64/unistd.h
+++ b/include/asm-x86_64/unistd.h
@@ -619,10 +619,16 @@ #define __NR_vmsplice 278
__SYSCALL(__NR_vmsplice, sys_vmsplice)
#define __NR_move_pages279
__SYSCALL(__NR_move_pages, sys_move_pages)
+#define __NR_kevent_get_events 280
+__SYSCALL(__NR_kevent_get_events, sys_kevent_get_events)
+#define __NR_kevent_ctl281
+__SYSCALL(__NR_kevent_ctl, sys_kevent_ctl)
+#define __NR_kevent_wait 282
+__SYSCALL(__NR_kevent_wait, sys_kevent_wait)
#ifdef __KERNEL__
-#define __NR_syscall_max __NR_move_pages
+#define __NR_syscall_max __NR_kevent_wait
#include linux/err.h
#ifndef __NO_STUBS
diff --git a/include/linux/kevent.h b/include/linux/kevent.h
new file mode 100644
index 000..743b328
--- /dev/null
+++ b/include/linux/kevent.h
@@ -0,0 +1,205 @@
+/*
+ * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __KEVENT_H
+#define __KEVENT_H
+#include linux/types.h
+#include linux/list.h
+#include linux/rbtree.h
+#include linux/spinlock.h
+#include linux/mutex.h
+#include linux/wait.h
+#include linux/net.h
+#include linux/rcupdate.h
+#include linux/kevent_storage.h
+#include linux/ukevent.h
+
+#define KEVENT_MIN_BUFFS_ALLOC 3
+
+struct kevent;
+struct kevent_storage;
+typedef int (* kevent_callback_t)(struct kevent *);
+
+/* @callback is called each time new event has been caught. */
+/* @enqueue is called each time new event is queued. */
+/* @dequeue is called each time event is dequeued. */
+
+struct kevent_callbacks {
+ kevent_callback_t callback, enqueue, dequeue;
+};
+
+#define KEVENT_READY 0x1
+#define KEVENT_STORAGE 0x2
+#define KEVENT_USER0x4
+
+struct kevent
+{
+ /* Used for kevent freeing.*/
+ struct rcu_head rcu_head;
+ struct ukevent event;
+ /* This lock protects ukevent manipulations, e.g. ret_flags changes. */
+ spinlock_t ulock;
+
+ /* Entry of user's tree. */
+ struct rb_node kevent_node;
+ /* Entry of origin's queue. */
+ struct list_headstorage_entry;
+ /* Entry of user's ready. */
+ struct
Re: [take22 0/4] kevent: Generic event handling mechanism.
Hi! Generic event handling mechanism. Consider for inclusion. Changes from 'take21' patchset: We are not interrested in how many times you spammed us, nor we want to know what was wrong in previous versions. It would be nice to have short summary of what this is good for, instead. Pavel -- Thanks, Sharp! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 2.6.19-rc4 - netlink messages created with bad flags in soft_irq context
On Tue, Oct 31, 2006 at 10:00:47PM -0800, David Miller wrote: From: Andy Gospodarek [EMAIL PROTECTED] Date: Tue, 31 Oct 2006 17:06:00 -0500 I've got a kernel built where CONFIG_DEBUG_SPINLOCK_SLEEP=y is in the config and I've noticed some interesting behavior when bringing up bonds in balance-alb mode. When I start to enslave devices to a bond I get the following in the ring buffer: BUG: sleeping function called from invalid context at mm/slab.c:3007 in_atomic():1, irqs_disabled():0 As Herbert mentioned, the bonding layer calls into the networking in atomic contexts when that is illegal. - Thanks for the feedback. If it seems the bonding driver is one of the only culprits, I'll investigate a solution that is specific to bonding (maybe a workqueue for such calls...) rather that one that effects the entire stack. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Hi, Even if the total lock time can be reduced, it's possible that interrupt handler is executed while the interrupted code is still holding the semaphore. I think your method only decrease the frequency of this problem. Why does reducing the lock time solve this problem? there are several problems here that need addressing. It's not acceptable for our driver to wait up to 15 seconds, and we can (presumably) reduce it to milliseconds, so that would help a lot. We should in no case at all hold it for any period longer than (give or take) half a second, so working towards that is a very good step in the right direction. Adding the timer task back may also help, as we are no longer trying to aqcuire the sw_fw_semaphore in interrupt context, but we removed it for a reason, and I need to dig up what reason this exactly was before we can revert it. Jesse might know, so I'll talk to him. But this will not fix the fact that the semaphore is held for a long time :) Timer tasks that reschedule themselves are a pain. The watchdog timer task had a couple of race conditions that were thought to be better fixed by removing it all together. Please, let's not go down that road again! I understand that the watchdog_task could cause a race when the timer task and e1000_down runs concurrently, resulting in memory double free. I think this problem occurs because interrupt handler is executed in same CPU as process that acquires semaphore. How about disabling interrupt while the process is holding the semaphore? I think this is possible, if the total lock time has been reduced. -- Kenzi Iwami ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] net/tipc: sprintf/strcpy conversion
From: Florian Westphal [EMAIL PROTECTED]
convert sprintf(a,b) to strcpy(a,b). Make tipc_bclink_name[] const.
Signed-off-by: Florian Westphal [EMAIL PROTECTED]
---
compile tested; diffed against davem/net-2.6.
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -119,7 +119,7 @@ static struct bclink *bclink = NULL;
static struct link *bcl = NULL;
static DEFINE_SPINLOCK(bc_lock);
-char tipc_bclink_name[] = multicast-link;
+const char tipc_bclink_name[] = multicast-link;
static u32 buf_seqno(struct sk_buff *buf)
@@ -790,7 +790,7 @@ int tipc_bclink_init(void)
INIT_LIST_HEAD(bcbearer-bearer.cong_links);
bcbearer-bearer.media = bcbearer-media;
bcbearer-media.send_msg = tipc_bcbearer_send;
- sprintf(bcbearer-media.name, tipc-multicast);
+ strcpy(bcbearer-media.name, tipc-multicast);
bcl = bclink-link;
memset(bclink, 0, sizeof(struct bclink));
@@ -802,7 +802,7 @@ int tipc_bclink_init(void)
tipc_link_set_queue_limits(bcl, BCLINK_WIN_DEFAULT);
bcl-b_ptr = bcbearer-bearer;
bcl-state = WORKING_WORKING;
- sprintf(bcl-name, tipc_bclink_name);
+ strcpy(bcl-name, tipc_bclink_name);
if (BCLINK_LOG_BUF_SIZE) {
char *pb = kmalloc(BCLINK_LOG_BUF_SIZE, GFP_ATOMIC);
diff --git a/net/tipc/bcast.h b/net/tipc/bcast.h
--- a/net/tipc/bcast.h
+++ b/net/tipc/bcast.h
@@ -70,7 +70,7 @@ struct port_list {
struct node;
-extern char tipc_bclink_name[];
+extern const char tipc_bclink_name[];
/**
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -667,7 +667,7 @@ struct sk_buff *tipc_node_get_links(cons
link_info.dest = tipc_own_addr 0xf00;
link_info.dest = htonl(link_info.dest);
link_info.up = htonl(1);
-sprintf(link_info.str, tipc_bclink_name);
+strcpy(link_info.str, tipc_bclink_name);
tipc_cfg_append_tlv(buf, TIPC_TLV_LINK_INFO, link_info,
sizeof(link_info));
/* Add TLVs for any other links in scope */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
On Wed, Nov 01, 2006 at 11:28:05AM +0100, Jiri Benc wrote: On Wed, 25 Oct 2006 22:15:23 -0700, Simon Barber wrote: Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) This is something I really want too. I see Simon's suggestions in the category of making wireless devices 1st class citizens. I mostly agree with his suggestions, and they are on my list. Do we see these as merge requirements? I have them as a lower priority than locking analysis/fixes, cfg80211 migration, fullmac support, and driver porting. Is this agreeable? Or do we think this needs to happen before a merge to -mm? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network virtualization/isolation
On Fri, 2006-27-10 at 11:10 +0200, Daniel Lezcano wrote: No, it uses virtualization at layer 2 and I had already mention it before (see the first email of the thread), but thank you for the email thread pointer. What would be really useful is someone takes the time and creates a matrix of the differences between the implementations. It seems there are quiet a few differences but without such comparison (to which all agree to) it is hard to form an opinion without a document of some form. For one, I am puzzled by the arguements about L2 vs L3 - Is this the host side or inside the VE? If it is a discussion of the host side: To me it seems it involves the classification of some packet header arriving on a physical netdevice on the host side (irrelevant whether they are L2 or L7) and reaching a decision to select some redirected to virtual netdevice. The admin (on the host) decides what packets any VE can see. Once within the VE, standard Linux net stack applies. The same applies on the egress. The admin decides what packets emanating from the VE go where. I dont think this is a simple L2 vs L3. You need to be able to process IP as well as Decnet[1] If it is a discussion on the VE side, then it needs to start at the netdevice for simplicity IMO. Anyways without background material on the different religions it is hard to reach a compromise - so it would be useful for someone to write a simple (not more than 4 pages total) background on the different approaches. For example, you could address the following: - how each treats packets coming in at the host level - what happens on incoming to the VE - what happens on egress of VE - how each treats packets departing from the host - how each treats inter-VE communication Then a matrix of how each requires what modifications in the network code. Of course all players need to agree that the description is accurate. Is there such a document? cheers, jamal [1] Since Linux has the only SMP-capable, firewall-capable Decnet implementation - wouldnt it be fun to have it be virtualized as well? ;- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
radvd 1.0 released
Hi, A new version of radvd has been released. There hasn't been any very major changes, just regular maintenance and a one new experimental feature (RDNSS option). Get it at: http://www.litech.org/radvd/ Changes since 0.9.1: * Fix AdvDefaultLifetime initalization, broken in 0.9.1. * Fix STDERR+syslog logging, don't try STDERR after forking. * Implement RDNSS draft with (non-allocated) ND type code 25. * Redefined IgnoreIfMissing: failed interfaces are now reinitialized by default. IgnoreIfMissing only omits warnings about these. * Unblock SIGALRM at startup. * Implement MAX_INITIAL_RTR_ADVERT_INTERVAL handling. * Perform some dynamic/static code audit, fix some minor bugs and do cleanup as a result. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
On Wed, Nov 01, 2006 at 02:06:14PM +0100, Pavel Machek ([EMAIL PROTECTED]) wrote: Hi! Generic event handling mechanism. Consider for inclusion. Changes from 'take21' patchset: We are not interrested in how many times you spammed us, nor we want to know what was wrong in previous versions. It would be nice to have short summary of what this is good for, instead. Let me guess, short explaination in subsequent emails is not enough... If changelog will be removed, then how people will detect what happend after previous release? Kevent is a generic subsytem which allows to handle event notifications. It supports both level and edge triggered events. It is similar to poll/epoll in some cases, but it is more scalable, it is faster and allows to work with essentially eny kind of events. Events are provided into kernel through control syscall and can be read back through mmaped ring or syscall. Kevent update (i.e. readiness switching) happens directly from internals of the appropriate state machine of the underlying subsytem (like network, filesystem, timer or any other). I will put that text into introduction message. Pavel -- Thanks, Sharp! -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] dont insert sockets/pipes dentries into dentry_hashtable.
David Miller a écrit :
It turns out that while procfs uses a different mechanism, those
procfs symlinks do point to the real socket dentry, so when you
readlink() on it you do d_path() on the real socket dentry.
Al Viro just suggested a way around this to me:
1) Just mark the dentry HASHED by hand in the dentry flags, but don't
actually hash it.
2) Create a special dentry-d_deleted method for sockets that returns
0 and clears by hand the HASHED flag bit in the dentry (see what
dput() does when this happens).
It's an abuse but it will work.
Thank you David and Al for the feedback.
Here is a new version of the patch with your suggestions included.
If necessary, I could split this patch in 3 elementary patches. I chose to
sent it as one patch for ease of discussion.
[RFC, PATCH] dont insert sockets/pipes dentries into dentry_hashtable.
We currently insert sockets/pipes dentries into the global dentry hashtable.
This is *useless* because there is currently no way these entries can be used
for a lookup(). (/proc/xxx/fd/xxx uses a different mechanism)
Machines with a lot of sockets/pipes might suffer from longer chains in dentry
hashtable.
Since dentries an unhashed dentry means __dpath() adds a (deleted), the
trick for socket/pipe dentries is to :
- Right after d_alloc(), pretend they are hashed by clearing the
DCACHE_UNHASHED bit. __dpath() friends work as intended.
- Call d_instantiate() instead of d_add() : dentry is not inserted in hash
table.
- Once dput() must clear the dentry, setting again DCACHE_UNHASHED bit inside
the custom d_delete() function provided by socket/pipe code.
[patch 1/3] Small optimization to bypass RCU freeing in d_free() for dentries
that were never hashed (like sockets and pipes). Such dentries dont have to
wait a RCU grace period.
[patch 2/3] Change socket code to use d_instantiate() instead of d_add()
[patch 3/3] Change pipe code to use d_instantiate() instead of d_add()
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
--- linux-2.6.19-rc4/fs/dcache.c2006-11-01 12:38:23.0 +0100
+++ linux-2.6.19-rc4-ed/fs/dcache.c 2006-11-01 13:22:44.0 +0100
@@ -68,15 +68,19 @@
.age_limit = 45,
};
-static void d_callback(struct rcu_head *head)
+static void __d_free(struct dentry *dentry)
{
- struct dentry * dentry = container_of(head, struct dentry, d_u.d_rcu);
-
if (dname_external(dentry))
kfree(dentry-d_name.name);
kmem_cache_free(dentry_cache, dentry);
}
+static void d_callback(struct rcu_head *head)
+{
+ struct dentry * dentry = container_of(head, struct dentry, d_u.d_rcu);
+ __d_free(dentry);
+}
+
/*
* no dcache_lock, please. The caller must decrement dentry_stat.nr_dentry
* inside dcache_lock.
@@ -85,7 +89,11 @@
{
if (dentry-d_op dentry-d_op-d_release)
dentry-d_op-d_release(dentry);
- call_rcu(dentry-d_u.d_rcu, d_callback);
+ /* if dentry was never inserted into hash, immediate free is OK */
+ if (dentry-d_hash.pprev == NULL)
+ __d_free(dentry);
+ else
+ call_rcu(dentry-d_u.d_rcu, d_callback);
}
/*
--- linux-2.6.19-rc4/net/socket.c 2006-11-01 12:40:27.0 +0100
+++ linux-2.6.19-rc4-ed/net/socket.c2006-11-01 14:33:18.0 +0100
@@ -306,7 +306,14 @@
static int sockfs_delete_dentry(struct dentry *dentry)
{
- return 1;
+ /*
+* At creation time, we pretended this dentry was hashed
+* (by clearing DCACHE_UNHASHED bit in d_flags)
+* At delete time, we restore the truth : not hashed.
+* (so that dput() can proceed correctly)
+*/
+ dentry-d_flags |= DCACHE_UNHASHED;
+ return 0;
}
static struct dentry_operations sockfs_dentry_operations = {
.d_delete = sockfs_delete_dentry,
@@ -354,14 +361,20 @@
this.len = sprintf(name, [%lu], SOCK_INODE(sock)-i_ino);
this.name = name;
- this.hash = SOCK_INODE(sock)-i_ino;
+ this.hash = 0;
file-f_dentry = d_alloc(sock_mnt-mnt_sb-s_root, this);
if (unlikely(!file-f_dentry))
return -ENOMEM;
file-f_dentry-d_op = sockfs_dentry_operations;
- d_add(file-f_dentry, SOCK_INODE(sock));
+ /*
+* We dont want to push this dentry into global dentry hash table.
+* We pretend dentry is already hashed, by unsetting DCACHE_UNHASHED
+* This hack permits a working /proc/$pid/fd/XXX on sockets
+*/
+ file-f_dentry-d_flags = ~DCACHE_UNHASHED;
+ d_instantiate(file-f_dentry, SOCK_INODE(sock));
file-f_vfsmnt = mntget(sock_mnt);
file-f_mapping = file-f_dentry-d_inode-i_mapping;
--- linux-2.6.19-rc4/fs/pipe.c 2006-11-01 12:56:05.0 +0100
+++ linux-2.6.19-rc4-ed/fs/pipe.c 2006-11-01 14:33:18.0 +0100
@@ -830,7 +830,14 @@
static struct vfsmount *pipe_mnt __read_mostly;
static int pipefs_delete_dentry(struct
Re: [PATCH] bcm43xx: fix unexpected LED control values in BCM4303 sprom
On Wednesday 01 November 2006 05:34, Larry Finger wrote:
John,
I had not responded to Michael's comments as I heard from another user with
thousands of these
assertions in his logs, and I have been waiting for his sprom values and
hoped to make a single
patch. It is good, however, that you pushed the patch upstream.
John W. Linville wrote:
On Wed, Oct 18, 2006 at 04:37:08PM +0200, Michael Buesch wrote:
@@ -257,7 +263,11 @@ void bcm43xx_leds_update(struct bcm43xx_
continue;
#endif /* CONFIG_BCM43XX_DEBUG */
default:
- assert(0);
+ if (bcm43xx_max_led_err) {
+ printkl(KERN_INFO PFX Bad value in
leds_update,
+ led-behaviour: 0x%x\n,
led-behaviour);
+ --bcm43xx_max_led_err;
+ }
I'd call this message bloat. ;) This is the first time the assertion
triggers since it was added.
You could instead remove the assert(), remove bcm43xx_max_led_err
and use dprintkl instead of printkl.
I disagree with part of Michael's comments. I think we should have a dprintk,
rather than dprintkl,
An unlimited printk will hang the system on UP.
so that we get printouts from all four of the sprom values.
I don't really think that dprintkl will prevent this.
That way the user will be able to report
the numbers we need. As this would not limit the log entries and potentially
generate thousands,
there should be a variable like bcm43xx_max_led_err to limit the number of
log entries.
I will propose a new patch once I get the data for the second case. In the
meantime, the patch you
have pushed upstream will fix the BCM4303 led assertions.
I still think it's a waste to add a variable, a printk and a long string which
all eat unswappable kernel memory for this cornercase.
I don't think it's really hard to tell somebody to execute iwpriv ethX
read_sprom
when he reports the assert() is triggering.
You must communicate with him anyway to find out how the LEDs are mapped
to the physical descriptions on the device case.
--
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: fix unexpected LED control values in BCM4303 sprom
On Tue, Oct 31, 2006 at 10:34:20PM -0600, Larry Finger wrote:
John W. Linville wrote:
On Wed, Oct 18, 2006 at 04:37:08PM +0200, Michael Buesch wrote:
@@ -257,7 +263,11 @@ void bcm43xx_leds_update(struct bcm43xx_
continue;
#endif /* CONFIG_BCM43XX_DEBUG */
default:
- assert(0);
+ if (bcm43xx_max_led_err) {
+ printkl(KERN_INFO PFX Bad value in
leds_update,
+ led-behaviour: 0x%x\n,
led-behaviour);
+ --bcm43xx_max_led_err;
+ }
I'd call this message bloat. ;) This is the first time the assertion
triggers since it was added.
You could instead remove the assert(), remove bcm43xx_max_led_err
and use dprintkl instead of printkl.
I disagree with part of Michael's comments. I think we should have a
dprintk, rather than dprintkl, so that we get printouts from all four of
the sprom values. That way the user will be able to report the numbers we
need. As this would not limit the log entries and potentially generate
thousands, there should be a variable like bcm43xx_max_led_err to limit the
number of log entries.
I will propose a new patch once I get the data for the second case. In the
meantime, the patch you have pushed upstream will fix the BCM4303 led
assertions.
OK, cool. I'm happy for you to send another patch.
John
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
On Wed, 1 Nov 2006, Pavel Machek wrote: Hi! Generic event handling mechanism. Consider for inclusion. Changes from 'take21' patchset: We are not interrested in how many times you spammed us, nor we want to know what was wrong in previous versions. It would be nice to have short summary of what this is good for, instead. I'm interested in knowing which version the patches belong to and what has changed (geez, it's rare enough that someone actually bothers to do this with an updated patchset, and to complain about it?) - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
Hi! Generic event handling mechanism. Consider for inclusion. Changes from 'take21' patchset: We are not interrested in how many times you spammed us, nor we want to know what was wrong in previous versions. It would be nice to have short summary of what this is good for, instead. Let me guess, short explaination in subsequent emails is not enough... Yes. Kevent is a generic subsytem which allows to handle event notifications. It supports both level and edge triggered events. It is similar to poll/epoll in some cases, but it is more scalable, it is faster and allows to work with essentially eny kind of events. Quantifying how much more scalable would be nice, as would be some example where it is useful. (It makes my webserver twice as fast on monster 64-cpu box). Events are provided into kernel through control syscall and can be read back through mmaped ring or syscall. Kevent update (i.e. readiness switching) happens directly from internals of the appropriate state machine of the underlying subsytem (like network, filesystem, timer or any other). I will put that text into introduction message. Thanks. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network virtualization/isolation
What would be really useful is someone takes the time and creates a matrix of the differences between the implementations. It seems there are quiet a few differences but without such comparison (to which all agree to) it is hard to form an opinion without a document of some form. If Dmitry is agree, we can work on the document. Dmitry, is it ok for you ? -- Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] silence a warning in ebtables
net/bridge/netfilter/ebtables.c: In function 'ebt_dev_check':
net/bridge/netfilter/ebtables.c:89: warning: initialization discards qualifiers
from pointer target type
So make the char* a const char * and the warning is gone.
Signed-off-by: Meelis Roos [EMAIL PROTECTED]
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 3df55b2..9f85666 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -86,7 +86,7 @@ static inline int ebt_do_match (struct e
static inline int ebt_dev_check(char *entry, const struct net_device *device)
{
int i = 0;
- char *devname = device-name;
+ const char *devname = device-name;
if (*entry == '\0')
return 0;
--
Meelis Roos ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
pktgen patch available for perusal.
Ben Greear writes: I've completed the first pass of my changes to pktgen in 2.6.18. Many of these features are probably DOA based on previous conversations, but perhaps this will help someone Thanks. Well sometimes there is a need to capture and drop pkts and various points, so it handy to have code fragments ready and just add the hook when it's needed in driver or rx softirq etc. Changes: * use a nano-second timer based on the scheduler timer (TSC) for relative times, instead of get_time_of_day. Any chance you extract this one so we can compare with get_time_of_day. This pops up in the profiles and TX numbers are not what used to be. Cheers. --ro - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/18] e1000: simplify skb_put call.
Simplify two calls to skb_put by removing one call to it. Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 54e384b..7f3d243 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -3842,12 +3842,11 @@ e1000_clean_rx_irq(struct e1000_adapter /* save the skb in buffer_info as good */ buffer_info-skb = skb; skb = new_skb; - skb_put(skb, length); } - } else - skb_put(skb, length); - + /* else just continue with the old one */ + } /* end copybreak code */ + skb_put(skb, length); /* Receive Checksum Offload */ e1000_rx_checksum(adapter, --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/18] e1000: Enble early receive (ERT) on 82573
Enable early receives on 82573 for jumbo frame performance. Jumbo's are only supported on 82573L with ASPM disabled. Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 1e1198b..194a07d 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -1934,6 +1934,12 @@ e1000_configure_rx(struct e1000_adapter E1000_WRITE_REG(hw, RXCSUM, rxcsum); } + /* enable early receives on 82573, only takes effect if using 2048 +* byte total frame size. for example only for jumbo frames */ +#define E1000_ERT_2048 0x100 + if (hw-mac_type == e1000_82573) + E1000_WRITE_REG(hw, ERT, E1000_ERT_2048); + /* Enable Receives */ E1000_WRITE_REG(hw, RCTL, rctl); } --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/18] e1000: Remove DISABLE_MULR debug code
Remove debugging code disabling MULR (multiple reads). It's not usable
for a wide audience and there are no known problems with MULR right
now.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 7ec2dd5..d3224c8 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -602,9 +602,6 @@ void
e1000_reset(struct e1000_adapter *adapter)
{
uint32_t pba, manc;
-#ifdef DISABLE_MULR
- uint32_t tctl;
-#endif
uint16_t fc_high_water_mark = E1000_FC_HIGH_DIFF;
/* Repartition Pba for greater than 9k mtu
@@ -671,12 +668,7 @@ e1000_reset(struct e1000_adapter *adapte
e1000_reset_hw(adapter-hw);
if (adapter-hw.mac_type = e1000_82544)
E1000_WRITE_REG(adapter-hw, WUC, 0);
-#ifdef DISABLE_MULR
- /* disable Multiple Reads in Transmit Control Register for debugging */
- tctl = E1000_READ_REG(hw, TCTL);
- E1000_WRITE_REG(hw, TCTL, tctl ~E1000_TCTL_MULR);
-#endif
if (e1000_init_hw(adapter-hw))
DPRINTK(PROBE, ERR, Hardware Error\n);
e1000_update_mng_vlan(adapter);
---
Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/18] e1000: whitespace changes, comments, typos
Small whitespace changes, comment changes, typo fixes.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_ethtool.c | 27 +-
drivers/net/e1000/e1000_hw.c |6 +-
drivers/net/e1000/e1000_hw.h |5 +-
drivers/net/e1000/e1000_main.c| 101 +++--
drivers/net/e1000/e1000_osdep.h |1
5 files changed, 72 insertions(+), 68 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index c564adb..82d2c78 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -133,9 +133,7 @@ e1000_get_settings(struct net_device *ne
if (hw-autoneg == 1) {
ecmd-advertising |= ADVERTISED_Autoneg;
-
/* the e1000 autoneg seems to match ethtool nicely */
-
ecmd-advertising |= hw-autoneg_advertised;
}
@@ -285,7 +283,7 @@ e1000_set_pauseparam(struct net_device *
e1000_reset(adapter);
} else
retval = ((hw-media_type == e1000_media_type_fiber) ?
- e1000_setup_link(hw) : e1000_force_mac_fc(hw));
+ e1000_setup_link(hw) : e1000_force_mac_fc(hw));
clear_bit(__E1000_RESETTING, adapter-flags);
return retval;
@@ -774,7 +772,7 @@ e1000_reg_test(struct e1000_adapter *ada
/* The status register is Read Only, so a write should fail.
* Some bits that get toggled are ignored.
*/
-switch (adapter-hw.mac_type) {
+ switch (adapter-hw.mac_type) {
/* there are several bits on newer hardware that are r/w */
case e1000_82571:
case e1000_82572:
@@ -802,12 +800,14 @@ e1000_reg_test(struct e1000_adapter *ada
}
/* restore previous status */
E1000_WRITE_REG(adapter-hw, STATUS, before);
+
if (adapter-hw.mac_type != e1000_ich8lan) {
REG_PATTERN_TEST(FCAL, 0x, 0x);
REG_PATTERN_TEST(FCAH, 0x, 0x);
REG_PATTERN_TEST(FCT, 0x, 0x);
REG_PATTERN_TEST(VET, 0x, 0x);
}
+
REG_PATTERN_TEST(RDTR, 0x, 0x);
REG_PATTERN_TEST(RDBAH, 0x, 0x);
REG_PATTERN_TEST(RDLEN, 0x000FFF80, 0x000F);
@@ -820,8 +820,9 @@ e1000_reg_test(struct e1000_adapter *ada
REG_PATTERN_TEST(TDLEN, 0x000FFF80, 0x000F);
REG_SET_AND_CHECK(RCTL, 0x, 0x);
+
before = (adapter-hw.mac_type == e1000_ich8lan ?
- 0x06C3B33E : 0x06DFB3FE);
+ 0x06C3B33E : 0x06DFB3FE);
REG_SET_AND_CHECK(RCTL, before, 0x003B);
REG_SET_AND_CHECK(TCTL, 0x, 0x);
@@ -834,10 +835,10 @@ e1000_reg_test(struct e1000_adapter *ada
REG_PATTERN_TEST(TDBAL, 0xFFF0, 0x);
REG_PATTERN_TEST(TIDV, 0x, 0x);
value = (adapter-hw.mac_type == e1000_ich8lan ?
- E1000_RAR_ENTRIES_ICH8LAN : E1000_RAR_ENTRIES);
+E1000_RAR_ENTRIES_ICH8LAN : E1000_RAR_ENTRIES);
for (i = 0; i value; i++) {
REG_PATTERN_TEST(RA + (((i 1) + 1) 2), 0x8003,
-0x);
+0x);
}
} else {
@@ -883,8 +884,7 @@ e1000_eeprom_test(struct e1000_adapter *
}
static irqreturn_t
-e1000_test_intr(int irq,
- void *data)
+e1000_test_intr(int irq, void *data)
{
struct net_device *netdev = (struct net_device *) data;
struct e1000_adapter *adapter = netdev_priv(netdev);
@@ -905,11 +905,11 @@ e1000_intr_test(struct e1000_adapter *ad
/* NOTE: we don't test MSI interrupts here, yet */
/* Hook up test interrupt handler just for this test */
- if (!request_irq(irq, e1000_test_intr, IRQF_PROBE_SHARED,
-netdev-name, netdev))
+ if (!request_irq(irq, e1000_test_intr, IRQF_PROBE_SHARED, netdev-name,
+netdev))
shared_int = FALSE;
else if (request_irq(irq, e1000_test_intr, IRQF_SHARED,
- netdev-name, netdev)) {
+netdev-name, netdev)) {
*data = 1;
return -1;
}
@@ -925,6 +925,7 @@ e1000_intr_test(struct e1000_adapter *ad
if (adapter-hw.mac_type == e1000_ich8lan i == 8)
continue;
+
/* Interrupt to test */
mask = 1 i;
@@ -1674,7 +1675,7 @@ e1000_diag_test(struct net_device *netde
if (e1000_link_test(adapter, data[4]))
eth_test-flags |= ETH_TEST_FL_FAILED;
- /* Offline tests aren't run; pass by default */
+
[PATCH 09/18] e1000: Remove unneeded and unwanted memsets
This memsetting was added in a paranoid rage debugging TX hangs, but
are no longer of importance. We can beef up the performance quite a
bit removing them. Make sure to fill in next_to_watch to allow this.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 7f3d243..2cd5009 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1993,10 +1993,13 @@ e1000_unmap_and_free_tx_resource(struct
buffer_info-dma,
buffer_info-length,
PCI_DMA_TODEVICE);
+ buffer_info-dma = 0;
}
- if (buffer_info-skb)
+ if (buffer_info-skb) {
dev_kfree_skb_any(buffer_info-skb);
- memset(buffer_info, 0, sizeof(struct e1000_buffer));
+ buffer_info-skb = NULL;
+ }
+ /* buffer_info must be completely set up in the transmit path */
}
/**
@@ -2661,6 +2664,7 @@ e1000_tso(struct e1000_adapter *adapter,
context_desc-cmd_and_length = cpu_to_le32(cmd_length);
buffer_info-time_stamp = jiffies;
+ buffer_info-next_to_watch = i;
if (++i == tx_ring-count) i = 0;
tx_ring-next_to_use = i;
@@ -2695,6 +2699,7 @@ e1000_tx_csum(struct e1000_adapter *adap
context_desc-cmd_and_length = cpu_to_le32(E1000_TXD_CMD_DEXT);
buffer_info-time_stamp = jiffies;
+ buffer_info-next_to_watch = i;
if (unlikely(++i == tx_ring-count)) i = 0;
tx_ring-next_to_use = i;
@@ -2763,6 +2768,7 @@ e1000_tx_map(struct e1000_adapter *adapt
size,
PCI_DMA_TODEVICE);
buffer_info-time_stamp = jiffies;
+ buffer_info-next_to_watch = i;
len -= size;
offset += size;
@@ -2802,6 +2808,7 @@ e1000_tx_map(struct e1000_adapter *adapt
size,
PCI_DMA_TODEVICE);
buffer_info-time_stamp = jiffies;
+ buffer_info-next_to_watch = i;
len -= size;
offset += size;
@@ -3620,7 +3627,7 @@ e1000_clean_tx_irq(struct e1000_adapter
cleaned = (i == eop);
e1000_unmap_and_free_tx_resource(adapter, buffer_info);
- memset(tx_desc, 0, sizeof(struct e1000_tx_desc));
+ tx_desc-upper.data = 0;
if (unlikely(++i == tx_ring-count)) i = 0;
}
---
Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/18] e1000: fix VR powerdown code
On ich systems during PHY power down to D3, the voltage regulators
were left on.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.c |9 +
drivers/net/e1000/e1000_hw.h |1 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index a0a3c7e..a45685c 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -3942,14 +3942,15 @@ e1000_phy_powerdown_workaround(struct e1
E1000_WRITE_REG(hw, PHY_CTRL, reg | E1000_PHY_CTRL_GBE_DISABLE |
E1000_PHY_CTRL_NOND0A_GBE_DISABLE);
-/* Write VR power-down enable */
+/* Write VR power-down enable - bits 9:8 should be 10b */
e1000_read_phy_reg(hw, IGP3_VR_CTRL, phy_data);
-e1000_write_phy_reg(hw, IGP3_VR_CTRL, phy_data |
-IGP3_VR_CTRL_MODE_SHUT);
+phy_data |= (1 9);
+phy_data = ~(1 8);
+e1000_write_phy_reg(hw, IGP3_VR_CTRL, phy_data);
/* Read it back and test */
e1000_read_phy_reg(hw, IGP3_VR_CTRL, phy_data);
-if ((phy_data IGP3_VR_CTRL_MODE_SHUT) || retry)
+if (((phy_data IGP3_VR_CTRL_MODE_MASK) == IGP3_VR_CTRL_MODE_SHUT) ||
retry)
break;
/* Issue PHY reset and repeat at most one more time */
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index b32a0c3..31bea32 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -3173,6 +3173,7 @@ struct e1000_host_command_info {
#define IGP3_VR_CTRL \
PHY_REG(776, 18) /* Voltage regulator control register */
#define IGP3_VR_CTRL_MODE_SHUT 0x0200 /* Enter powerdown, shutdown VRs */
+#define IGP3_VR_CTRL_MODE_MASK 0x0300 /* Shutdown VR Mask */
#define IGP3_CAPABILITY \
PHY_REG(776, 19) /* IGP3 Capability Register */
---
Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/18] e1000: reorder pci-e infor struct
Order pci-e capability struct according to bus/pci bus width ordering
preserving the hard pci spec numbers.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.h |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index 31bea32..f247f26 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -128,11 +128,13 @@ typedef enum {
/* PCI bus widths */
typedef enum {
e1000_bus_width_unknown = 0,
+/* These PCIe values should literally match the possible return values
+ * from config space */
+e1000_bus_width_pciex_1 = 1,
+e1000_bus_width_pciex_2 = 2,
+e1000_bus_width_pciex_4 = 4,
e1000_bus_width_32,
e1000_bus_width_64,
-e1000_bus_width_pciex_1,
-e1000_bus_width_pciex_2,
-e1000_bus_width_pciex_4,
e1000_bus_width_reserved
} e1000_bus_width;
---
Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/18] e1000: rename ICH8 flash macros
ICH8 will soon be followed by newer chipsets bearing the same acronym,
thus we remove the '8' and make it independent of the version number in
the platform name.
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.c| 119 +++
drivers/net/e1000/e1000_hw.h| 73
drivers/net/e1000/e1000_osdep.h |8 +--
3 files changed, 98 insertions(+), 102 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index fd7d09d..a25a6b1 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -4555,7 +4555,7 @@ e1000_init_eeprom_params(struct e1000_hw
case e1000_ich8lan:
{
int32_t i = 0;
-uint32_t flash_size = E1000_READ_ICH8_REG(hw, ICH8_FLASH_GFPREG);
+uint32_t flash_size = E1000_READ_ICH_FLASH_REG(hw, ICH_FLASH_GFPREG);
eeprom-type = e1000_eeprom_ich8;
eeprom-use_eerd = FALSE;
@@ -4571,12 +4571,14 @@ e1000_init_eeprom_params(struct e1000_hw
}
}
-hw-flash_base_addr = (flash_size ICH8_GFPREG_BASE_MASK) *
- ICH8_FLASH_SECTOR_SIZE;
+hw-flash_base_addr = (flash_size ICH_GFPREG_BASE_MASK) *
+ ICH_FLASH_SECTOR_SIZE;
+
+hw-flash_bank_size = ((flash_size 16) ICH_GFPREG_BASE_MASK) + 1;
+hw-flash_bank_size -= (flash_size ICH_GFPREG_BASE_MASK);
+
+hw-flash_bank_size *= ICH_FLASH_SECTOR_SIZE;
-hw-flash_bank_size = ((flash_size 16) ICH8_GFPREG_BASE_MASK) + 1;
-hw-flash_bank_size -= (flash_size ICH8_GFPREG_BASE_MASK);
-hw-flash_bank_size *= ICH8_FLASH_SECTOR_SIZE;
hw-flash_bank_size /= 2 * sizeof(uint16_t);
break;
@@ -5626,8 +5628,8 @@ e1000_commit_shadow_ram(struct e1000_hw
* signature is valid. We want to do this after the write
* has completed so that we don't mark the segment valid
* while the write is still in progress */
-if (i == E1000_ICH8_NVM_SIG_WORD)
-high_byte = E1000_ICH8_NVM_SIG_MASK | high_byte;
+if (i == E1000_ICH_NVM_SIG_WORD)
+high_byte = E1000_ICH_NVM_SIG_MASK | high_byte;
error = e1000_verify_write_ich8_byte(hw,
(i 1) + new_bank_offset + 1, high_byte);
@@ -5649,18 +5651,18 @@ e1000_commit_shadow_ram(struct e1000_hw
* erase as well since these bits are 11 to start with
* and we need to change bit 14 to 0b */
e1000_read_ich8_byte(hw,
- E1000_ICH8_NVM_SIG_WORD * 2 + 1 +
new_bank_offset,
+ E1000_ICH_NVM_SIG_WORD * 2 + 1 +
new_bank_offset,
high_byte);
high_byte = 0xBF;
error = e1000_verify_write_ich8_byte(hw,
-E1000_ICH8_NVM_SIG_WORD * 2 + 1 + new_bank_offset,
high_byte);
+E1000_ICH_NVM_SIG_WORD * 2 + 1 + new_bank_offset,
high_byte);
/* And invalidate the previously valid segment by setting
* its signature word (0x13) high_byte to 0b. This can be
* done without an erase because flash erase sets all bits
* to 1's. We can write 1's to 0's without an erase */
if (error == E1000_SUCCESS) {
error = e1000_verify_write_ich8_byte(hw,
-E1000_ICH8_NVM_SIG_WORD * 2 + 1 + old_bank_offset,
0);
+E1000_ICH_NVM_SIG_WORD * 2 + 1 + old_bank_offset,
0);
}
/* Clear the now not used entry in the cache */
@@ -8494,7 +8496,7 @@ e1000_ich8_cycle_init(struct e1000_hw *h
DEBUGFUNC(e1000_ich8_cycle_init);
-hsfsts.regval = E1000_READ_ICH8_REG16(hw, ICH8_FLASH_HSFSTS);
+hsfsts.regval = E1000_READ_ICH_FLASH_REG16(hw, ICH_FLASH_HSFSTS);
/* May be check the Flash Des Valid bit in Hw status */
if (hsfsts.hsf_status.fldesvalid == 0) {
@@ -8507,7 +8509,7 @@ e1000_ich8_cycle_init(struct e1000_hw *h
hsfsts.hsf_status.flcerr = 1;
hsfsts.hsf_status.dael = 1;
-E1000_WRITE_ICH8_REG16(hw, ICH8_FLASH_HSFSTS, hsfsts.regval);
+E1000_WRITE_ICH_FLASH_REG16(hw, ICH_FLASH_HSFSTS, hsfsts.regval);
/* Either we should have a hardware SPI cycle in progress bit to check
* against, in order to start a new cycle or FDONE bit should be changed
@@ -8522,13 +8524,13 @@ e1000_ich8_cycle_init(struct e1000_hw *h
/* There is no cycle running at present, so we can start a cycle */
/* Begin by setting Flash Cycle Done. */
hsfsts.hsf_status.flcdone = 1;
-E1000_WRITE_ICH8_REG16(hw, ICH8_FLASH_HSFSTS, hsfsts.regval);
+E1000_WRITE_ICH_FLASH_REG16(hw, ICH_FLASH_HSFSTS, hsfsts.regval);
error =
[PATCH 05/18] e1000: add mmiowb() for IA64 to sync tail writes
IA64 SMP systems were seeing TX issues with multiple cpu's attempting to write tail registers unordered. This mmiowb() fixes the issue. Signed-off-by: Auke Kok [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 194a07d..54e384b 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -2867,6 +2867,9 @@ e1000_tx_queue(struct e1000_adapter *ada tx_ring-next_to_use = i; writel(i, adapter-hw.hw_addr + tx_ring-tdt); + /* we need this if more than one processor can write to our tail +* at a time, it syncronizes IO on IA64/Altix systems */ + mmiowb(); } /** --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/18] e1000: FIX: enable hw TSO for IPV6
Enable TSO for IPV6. All e1000 hardware supports it. This reduces CPU
utilizations by 50% when transmitting IPv6 frames.
Fix symbol naming enabling ipv6 TSO. Turn off TSO6 for 10/100.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000.h |3 +++
drivers/net/e1000/e1000_ethtool.c |7 +++
drivers/net/e1000/e1000_main.c| 19 ++-
3 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 7ecce43..3f0be02 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -59,6 +59,9 @@
#include linux/capability.h
#include linux/in.h
#include linux/ip.h
+#ifdef NETIF_F_TSO6
+#include linux/ipv6.h
+#endif
#include linux/tcp.h
#include linux/udp.h
#include net/pkt_sched.h
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 82d2c78..b9c0927 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -348,6 +348,13 @@ e1000_set_tso(struct net_device *netdev,
else
netdev-features = ~NETIF_F_TSO;
+#ifdef NETIF_F_TSO6
+ if (data)
+ netdev-features |= NETIF_F_TSO6;
+ else
+ netdev-features = ~NETIF_F_TSO6;
+#endif
+
DPRINTK(PROBE, INFO, TSO is %s\n, data ? Enabled : Disabled);
adapter-tso_force = TRUE;
return 0;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index d3224c8..1e1198b 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -844,9 +844,9 @@ e1000_probe(struct pci_dev *pdev,
(adapter-hw.mac_type != e1000_82547))
netdev-features |= NETIF_F_TSO;
-#ifdef NETIF_F_TSO_IPV6
+#ifdef NETIF_F_TSO6
if (adapter-hw.mac_type e1000_82547_rev_2)
- netdev-features |= NETIF_F_TSO_IPV6;
+ netdev-features |= NETIF_F_TSO6;
#endif
#endif
if (pci_using_dac)
@@ -1814,8 +1814,11 @@ e1000_setup_rctl(struct e1000_adapter *a
/* Configure extra packet-split registers */
rfctl = E1000_READ_REG(adapter-hw, RFCTL);
rfctl |= E1000_RFCTL_EXTEN;
- /* disable IPv6 packet split support */
- rfctl |= E1000_RFCTL_IPV6_DIS;
+ /* disable packet split support for IPv6 extension headers,
+* because some malformed IPv6 headers can hang the RX */
+ rfctl |= (E1000_RFCTL_IPV6_EX_DIS |
+ E1000_RFCTL_NEW_IPV6_EXT_DIS);
+
E1000_WRITE_REG(adapter-hw, RFCTL, rfctl);
rctl |= E1000_RCTL_DTYP_PS;
@@ -2473,9 +2476,15 @@ e1000_watchdog(unsigned long data)
DPRINTK(PROBE,INFO,
10/100 speed: disabling TSO\n);
netdev-features = ~NETIF_F_TSO;
+#ifdef NETIF_F_TSO6
+ netdev-features = ~NETIF_F_TSO6;
+#endif
break;
case SPEED_1000:
netdev-features |= NETIF_F_TSO;
+#ifdef NETIF_F_TSO6
+ netdev-features |= NETIF_F_TSO6;
+#endif
break;
default:
/* oops */
@@ -2610,7 +2619,7 @@ e1000_tso(struct e1000_adapter *adapter,
0);
cmd_length = E1000_TXD_CMD_IP;
ipcse = skb-h.raw - skb-data - 1;
-#ifdef NETIF_F_TSO_IPV6
+#ifdef NETIF_F_TSO6
} else if (skb-protocol == htons(ETH_P_IPV6)) {
skb-nh.ipv6h-payload_len = 0;
skb-h.th-check =
---
Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/18] e1000: reorder e1000_param.c
This file needs some cleanups and reordering - logically order it
so that relevant defines and code are together with properly quoted
defaults.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_param.c | 78 ++-
1 files changed, 20 insertions(+), 58 deletions(-)
diff --git a/drivers/net/e1000/e1000_param.c b/drivers/net/e1000/e1000_param.c
index 9c3c1ac..e4f8892 100644
--- a/drivers/net/e1000/e1000_param.c
+++ b/drivers/net/e1000/e1000_param.c
@@ -44,16 +44,6 @@
*/
#define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET }
-/* Module Parameters are always initialized to -1, so that the driver
- * can tell the difference between no user specified value or the
- * user asking for the default value.
- * The true default values are loaded in when e1000_check_options is called.
- *
- * This is a GCC extension to ANSI C.
- * See the item Labeled Elements in Initializers in the section
- * Extensions to the C Language Family of the GCC documentation.
- */
-
#define E1000_PARAM(X, desc) \
static int __devinitdata X[E1000_MAX_NIC+1] = E1000_PARAM_INIT; \
static int num_##X = 0; \
@@ -67,7 +57,6 @@
*
* Default Value: 256
*/
-
E1000_PARAM(TxDescriptors, Number of transmit descriptors);
/* Receive Descriptor Count
@@ -77,7 +66,6 @@ E1000_PARAM(TxDescriptors, Number of tr
*
* Default Value: 256
*/
-
E1000_PARAM(RxDescriptors, Number of receive descriptors);
/* User Specified Speed Override
@@ -90,7 +78,6 @@ E1000_PARAM(RxDescriptors, Number of re
*
* Default Value: 0
*/
-
E1000_PARAM(Speed, Speed setting);
/* User Specified Duplex Override
@@ -102,7 +89,6 @@ E1000_PARAM(Speed, Speed setting);
*
* Default Value: 0
*/
-
E1000_PARAM(Duplex, Duplex setting);
/* Auto-negotiation Advertisement Override
@@ -119,8 +105,9 @@ E1000_PARAM(Duplex, Duplex setting);
*
* Default Value: 0x2F (copper); 0x20 (fiber)
*/
-
E1000_PARAM(AutoNeg, Advertised auto-negotiation setting);
+#define AUTONEG_ADV_DEFAULT 0x2F
+#define AUTONEG_ADV_MASK 0x2F
/* User Specified Flow Control Override
*
@@ -132,8 +119,8 @@ E1000_PARAM(AutoNeg, Advertised auto-ne
*
* Default Value: Read flow control settings from the EEPROM
*/
-
E1000_PARAM(FlowControl, Flow Control setting);
+#define FLOW_CONTROL_DEFAULT FLOW_CONTROL_FULL
/* XsumRX - Receive Checksum Offload Enable/Disable
*
@@ -144,53 +131,54 @@ E1000_PARAM(FlowControl, Flow Control s
*
* Default Value: 1
*/
-
E1000_PARAM(XsumRX, Disable or enable Receive Checksum offload);
/* Transmit Interrupt Delay in units of 1.024 microseconds
+ * Tx interrupt delay needs to typically be set to something non zero
*
* Valid Range: 0-65535
- *
- * Default Value: 64
*/
-
E1000_PARAM(TxIntDelay, Transmit Interrupt Delay);
+#define DEFAULT_TIDV 64
+#define MAX_TXDELAY 0x
+#define MIN_TXDELAY0
/* Transmit Absolute Interrupt Delay in units of 1.024 microseconds
*
* Valid Range: 0-65535
- *
- * Default Value: 0
*/
-
E1000_PARAM(TxAbsIntDelay, Transmit Absolute Interrupt Delay);
+#define DEFAULT_TADV 64
+#define MAX_TXABSDELAY0x
+#define MIN_TXABSDELAY 0
/* Receive Interrupt Delay in units of 1.024 microseconds
+ * hardware will likely hang if you set this to anything but zero.
*
* Valid Range: 0-65535
- *
- * Default Value: 0
*/
-
E1000_PARAM(RxIntDelay, Receive Interrupt Delay);
+#define DEFAULT_RDTR 0
+#define MAX_RXDELAY 0x
+#define MIN_RXDELAY0
/* Receive Absolute Interrupt Delay in units of 1.024 microseconds
*
* Valid Range: 0-65535
- *
- * Default Value: 128
*/
-
E1000_PARAM(RxAbsIntDelay, Receive Absolute Interrupt Delay);
+#define DEFAULT_RADV 128
+#define MAX_RXABSDELAY0x
+#define MIN_RXABSDELAY 0
/* Interrupt Throttle Rate (interrupts/sec)
*
* Valid Range: 100-10 (0=off, 1=dynamic)
- *
- * Default Value: 8000
*/
-
E1000_PARAM(InterruptThrottleRate, Interrupt Throttling Rate);
+#define DEFAULT_ITR 8000
+#define MAX_ITR 10
+#define MIN_ITR 100
/* Enable Smart Power Down of the PHY
*
@@ -198,7 +186,6 @@ E1000_PARAM(InterruptThrottleRate, Inte
*
* Default Value: 0 (disabled)
*/
-
E1000_PARAM(SmartPowerDownEnable, Enable PHY smart power down);
/* Enable Kumeran Lock Loss workaround
@@ -207,33 +194,8 @@ E1000_PARAM(SmartPowerDownEnable, Enabl
*
* Default Value: 1 (enabled)
*/
-
E1000_PARAM(KumeranLockLoss, Enable Kumeran lock loss workaround);
-#define AUTONEG_ADV_DEFAULT 0x2F
-#define AUTONEG_ADV_MASK 0x2F
-#define FLOW_CONTROL_DEFAULT FLOW_CONTROL_FULL
-
-#define DEFAULT_RDTR 0
-#define MAX_RXDELAY 0x
-#define MIN_RXDELAY0
-
-#define DEFAULT_RADV
[PATCH 13/18] e1000: Only set IDE for tx when we are using TIDV/TADV
Spec fix: don't set IDE unless we are actually setting the tx int delay time. Signed-off-by: Auke Kok [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 99dd6b9..db933bf 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -1580,8 +1580,11 @@ e1000_configure_tx(struct e1000_adapter e1000_config_collision_dist(hw); /* Setup Transmit Descriptor Settings for eop descriptor */ - adapter-txd_cmd = E1000_TXD_CMD_IDE | E1000_TXD_CMD_EOP | - E1000_TXD_CMD_IFCS; + adapter-txd_cmd = E1000_TXD_CMD_EOP | E1000_TXD_CMD_IFCS; + + /* only set IDE if we are delaying interrupts using the timers */ + if (adapter-tx_int_delay) + adapter-txd_cmd |= E1000_TXD_CMD_IDE; if (hw-mac_type e1000_82543) adapter-txd_cmd |= E1000_TXD_CMD_RPS; --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/18] e1000: add queue restart counter
Add a netif_wake/start_queue counter to the ethtool statistics to indicated
to the user that their transmit ring could be too small for their workload.
Signed-off-by: Jesse brandeburg [EMAIL PROTECTED]
Cc: Jamal Hadi [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000.h |1 +
drivers/net/e1000/e1000_ethtool.c |1 +
drivers/net/e1000/e1000_main.c|5 -
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 3f0be02..896ea8a 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -265,6 +265,7 @@ struct e1000_adapter {
/* TX */
struct e1000_tx_ring *tx_ring; /* One per active queue */
+ unsigned int restart_queue;
unsigned long tx_queue_len;
uint32_t txd_cmd;
uint32_t tx_int_delay;
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index dbac71b..da459f7 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -85,6 +85,7 @@ static const struct e1000_stats e1000_gs
{ tx_single_coll_ok, E1000_STAT(stats.scc) },
{ tx_multi_coll_ok, E1000_STAT(stats.mcc) },
{ tx_timeout_count, E1000_STAT(tx_timeout_count) },
+ { tx_restart_queue, E1000_STAT(restart_queue) },
{ rx_long_length_errors, E1000_STAT(stats.roc) },
{ rx_short_length_errors, E1000_STAT(stats.ruc) },
{ rx_align_errors, E1000_STAT(stats.algnerrc) },
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index f078f6b..99dd6b9 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2974,6 +2974,7 @@ static int __e1000_maybe_stop_tx(struct
/* A reprieve! */
netif_start_queue(netdev);
+ ++adapter-restart_queue;
return 0;
}
@@ -3654,8 +3655,10 @@ e1000_clean_tx_irq(struct e1000_adapter
* sees the new next_to_clean.
*/
smp_mb();
- if (netif_queue_stopped(netdev))
+ if (netif_queue_stopped(netdev)) {
netif_wake_queue(netdev);
+ ++adapter-restart_queue;
+ }
}
if (adapter-detect_tx_hung) {
---
Auke Kok [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18] e1000: features, updates, documentation
Hi, Here are patches for e1000 for #upstream in netdev-2.6.git. Most of the patches are maintenance and minor fixes only, but a few are significant and more complex: o Patch to enable IPv6 TSO for all e1000 hardware o Add support for 3 newly packaged existing silicon devices o Add a MSI interrupt servicing routine for pci-e hardware o Add dynamic interrupt moderation algorithm favouring low latency but not affecting bulk throughput traffic situations. This improves small packet performance significantly. (Summary below.) These changes are available through git. Jeff, please pull: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream these patches are against netdev-2.6#upstream a01ad6b4b316afb7f9c48bde3590c0d6c063b1b4 Cheers, Auke --- Jesse Brandeburg [EMAIL PROTECTED]: e1000: add mmiowb() for IA64 to sync tail writes e1000: Remove unneeded and unwanted memsets e1000: add queue restart counter e1000: Only set IDE for tx when we are using TIDV/TADV e1000: add dynamic generic MSI interrupt routine e1000: add dynamic itr modes Jeff Kirsher [EMAIL PROTECTED]: e1000: fix VR powerdown code e1000: reorder pci-e infor struct e1000: rename ICH8 flash macros Auke Kok [EMAIL PROTECTED]: e1000: whitespace changes, comments, typos e1000: Remove DISABLE_MULR debug code e1000: FIX: enable hw TSO for IPV6 e1000: Enble early receive (ERT) on 82573 e1000: simplify skb_put call. e1000: New hardware support e1000: reorder e1000_param.c e1000: increment version to 7.3.15-k2 e1000: update README for e1000 --- Documentation/networking/e1000.txt | 451 - drivers/net/e1000/e1000.h | 17 + drivers/net/e1000/e1000_ethtool.c | 36 +- drivers/net/e1000/e1000_hw.c | 137 +- drivers/net/e1000/e1000_hw.h | 90 +++--- drivers/net/e1000/e1000_main.c | 491 + drivers/net/e1000/e1000_osdep.h|9 drivers/net/e1000/e1000_param.c| 106 +++ 8 files changed, 852 insertions(+), 485 deletions(-) --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/18] e1000: add dynamic itr modes
Add a new dynamic itr algorithm, with 2 modes, and make it the default
operation mode. This greatly reduces latency and increases small packet
performance, at the cost of some CPU utilization. Bulk traffic
throughput is unaffected.
The driver can limit the amount of interrupts per second that the
adapter will generate for incoming packets. It does this by writing a
value to the adapter that is based on the maximum amount of interrupts
that the adapter will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100 will
program the adapter to send out a maximum of that many interrupts per
second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load,
but will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate value of 8000, providing a good fallback value
for all traffic types,but lacking in small packet performance and
latency. The hardware can handle many more small packets per second
however, and for this reason an adaptive interrupt moderation algorithm
was implemented.
Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in
which it dynamically adjusts the InterruptThrottleRate value based on
the traffic that it receives. After determining the type of incoming
traffic in the last timeframe, it will adjust the InterruptThrottleRate
to an appropriate value for that traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate
value is adjusted to suit that traffic type the best. There are
three classes defined: Bulk traffic, for large amounts of packets
of normal size; Low latency, for small amounts of traffic and/or
a significant percentage of small packets; and Lowest latency,
for almost completely small packets or minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is
set to 4000 for traffic that falls in class Bulk traffic. If
traffic falls in the Low latency or Lowest latency class, the
InterruptThrottleRate is increased stepwise to 2. This default
mode is suitable for most applications.
For situations where low latency is vital such as cluster or
grid computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased
stepwise to 7 for traffic in class Lowest latency.
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Cc: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000.h | 13 ++
drivers/net/e1000/e1000_main.c | 226 ++-
drivers/net/e1000/e1000_param.c | 28 +++--
3 files changed, 228 insertions(+), 39 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 896ea8a..f091042 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -257,6 +257,17 @@ struct e1000_adapter {
spinlock_t tx_queue_lock;
#endif
atomic_t irq_sem;
+ unsigned int detect_link;
+ unsigned int total_tx_bytes;
+ unsigned int total_tx_packets;
+ unsigned int total_rx_bytes;
+ unsigned int total_rx_packets;
+ /* Interrupt Throttle Rate */
+ uint32_t itr;
+ uint32_t itr_setting;
+ uint16_t tx_itr;
+ uint16_t rx_itr;
+
struct work_struct reset_task;
uint8_t fc_autoneg;
@@ -314,8 +325,6 @@ struct e1000_adapter {
uint64_t gorcl_old;
uint16_t rx_ps_bsize0;
- /* Interrupt Throttle Rate */
- uint32_t itr;
/* OS defined structs */
struct net_device *netdev;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index b05871a..71524b1 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1897,7 +1897,7 @@ e1000_configure_rx(struct e1000_adapter
if (hw-mac_type = e1000_82540) {
E1000_WRITE_REG(hw, RADV, adapter-rx_abs_int_delay);
- if (adapter-itr 1)
+ if (adapter-itr_setting != 0)
E1000_WRITE_REG(hw, ITR,
10 / (adapter-itr * 256));
}
@@ -1907,11 +1907,11 @@ e1000_configure_rx(struct e1000_adapter
/* Reset delay timers after every interrupt */
ctrl_ext |= E1000_CTRL_EXT_INT_TIMER_CLR;
#ifdef CONFIG_E1000_NAPI
- /* Auto-Mask interrupts upon ICR read. */
+ /* Auto-Mask interrupts upon ICR access */
ctrl_ext |= E1000_CTRL_EXT_IAME;
+ E1000_WRITE_REG(hw, IAM, 0x);
#endif
[PATCH 18/18] e1000: update README for e1000
Signed-off-by: Auke Kok [EMAIL PROTECTED] --- Documentation/networking/e1000.txt | 451 +--- 1 files changed, 266 insertions(+), 185 deletions(-) diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 5c0a5cc..61b171c 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt @@ -1,7 +1,7 @@ Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters === -November 15, 2005 +September 26, 2006 Contents @@ -9,6 +9,7 @@ Contents - In This Release - Identifying Your Adapter +- Building and Installation - Command Line Parameters - Speed and Duplex Configuration - Additional Configurations @@ -41,6 +42,9 @@ or later), lspci, and ifconfig to obtain Instructions on updating ethtool can be found in the section Additional Configurations later in this document. +NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100 +support. + Identifying Your Adapter @@ -51,28 +55,27 @@ Driver ID Guide at: http://support.intel.com/support/network/adapter/pro100/21397.htm For the latest Intel network drivers for Linux, refer to the following -website. In the search field, enter your adapter name or type, or use the +website. In the search field, enter your adapter name or type, or use the networking link on the left to search for your adapter: http://downloadfinder.intel.com/scripts-df/support_intel.asp -Command Line Parameters === +Command Line Parameters +=== If the driver is built as a module, the following optional parameters -are used by entering them on the command line with the modprobe or insmod -command using this syntax: +are used by entering them on the command line with the modprobe command +using this syntax: modprobe e1000 [option=VAL1,VAL2,...] - insmod e1000 [option=VAL1,VAL2,...] - For example, with two PRO/1000 PCI adapters, entering: - insmod e1000 TxDescriptors=80,128 + modprobe e1000 TxDescriptors=80,128 -loads the e1000 driver with 80 TX descriptors for the first adapter and 128 -TX descriptors for the second adapter. +loads the e1000 driver with 80 TX descriptors for the first adapter and +128 TX descriptors for the second adapter. The default value for each parameter is generally the recommended setting, unless otherwise noted. @@ -87,7 +90,7 @@ NOTES: For more information about the A http://www.intel.com/design/network/applnots/ap450.htm A descriptor describes a data buffer and attributes related to -the data buffer. This information is accessed by the hardware. +the data buffer. This information is accessed by the hardware. AutoNeg @@ -96,9 +99,9 @@ AutoNeg Valid Range: 0x01-0x0F, 0x20-0x2F Default Value: 0x2F -This parameter is a bit mask that specifies which speed and duplex -settings the board advertises. When this parameter is used, the Speed -and Duplex parameters must not be specified. +This parameter is a bit-mask that specifies the speed and duplex settings +advertised by the adapter. When this parameter is used, the Speed and +Duplex parameters must not be specified. NOTE: Refer to the Speed and Duplex section of this readme for more information on the AutoNeg parameter. @@ -110,14 +113,15 @@ Duplex Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full) Default Value: 0 -Defines the direction in which data is allowed to flow. Can be either -one or two-directional. If both Duplex and the link partner are set to -auto-negotiate, the board auto-detects the correct duplex. If the link -partner is forced (either full or half), Duplex defaults to half-duplex. +This defines the direction in which data is allowed to flow. Can be +either one or two-directional. If both Duplex and the link partner are +set to auto-negotiate, the board auto-detects the correct duplex. If the +link partner is forced (either full or half), Duplex defaults to half- +duplex. FlowControl --- +--- Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=RxTx) Default Value: Reads flow control settings from the EEPROM @@ -127,57 +131,107 @@ to Ethernet PAUSE frames. InterruptThrottleRate - -(not supported on Intel 82542, 82543 or 82544-based adapters) -Valid Range: 100-10 (0=off, 1=dynamic) -Default Value: 8000 - -This value represents the maximum number of interrupts per second the -controller generates. InterruptThrottleRate is another setting used in -interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust -InterruptThrottleRate based on the current traffic load. +(not supported on Intel(R) 82542, 82543 or 82544-based adapters) +Valid Range: 0,1,3,100-10 (0=off, 1=dynamic, 3=dynamic conservative) +Default Value: 3 + +The driver can limit the amount of interrupts per
[PATCH 15/18] e1000: add dynamic generic MSI interrupt routine
Add a generic MSI interrupt routine that is IO read-free, speeding up
MSI interrupt handling.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 90 +++-
1 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index db933bf..b05871a 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -157,6 +157,9 @@ static struct net_device_stats * e1000_g
static int e1000_change_mtu(struct net_device *netdev, int new_mtu);
static int e1000_set_mac(struct net_device *netdev, void *p);
static irqreturn_t e1000_intr(int irq, void *data);
+#ifdef CONFIG_PCI_MSI
+static irqreturn_t e1000_intr_msi(int irq, void *data);
+#endif
static boolean_t e1000_clean_tx_irq(struct e1000_adapter *adapter,
struct e1000_tx_ring *tx_ring);
#ifdef CONFIG_E1000_NAPI
@@ -288,7 +291,7 @@ static int e1000_request_irq(struct e100
flags = IRQF_SHARED;
#ifdef CONFIG_PCI_MSI
- if (adapter-hw.mac_type e1000_82547_rev_2) {
+ if (adapter-hw.mac_type = e1000_82571) {
adapter-have_msi = TRUE;
if ((err = pci_enable_msi(adapter-pdev))) {
DPRINTK(PROBE, ERR,
@@ -296,8 +299,14 @@ static int e1000_request_irq(struct e100
adapter-have_msi = FALSE;
}
}
- if (adapter-have_msi)
+ if (adapter-have_msi) {
flags = ~IRQF_SHARED;
+ err = request_irq(adapter-pdev-irq, e1000_intr_msi, flags,
+ netdev-name, netdev);
+ if (err)
+ DPRINTK(PROBE, ERR,
+ Unable to allocate interrupt Error: %d\n, err);
+ } else
#endif
if ((err = request_irq(adapter-pdev-irq, e1000_intr, flags,
netdev-name, netdev)))
@@ -3466,6 +3475,83 @@ e1000_update_stats(struct e1000_adapter
spin_unlock_irqrestore(adapter-stats_lock, flags);
}
+#ifdef CONFIG_PCI_MSI
+
+/**
+ * e1000_intr_msi - Interrupt Handler
+ * @irq: interrupt number
+ * @data: pointer to a network interface device structure
+ **/
+
+static
+irqreturn_t e1000_intr_msi(int irq, void *data)
+{
+ struct net_device *netdev = data;
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ struct e1000_hw *hw = adapter-hw;
+#ifndef CONFIG_E1000_NAPI
+ int i;
+#endif
+
+ /* this code avoids the read of ICR but has to get 1000 interrupts
+* at every link change event before it will notice the change */
+ if (++adapter-detect_link = 1000) {
+ uint32_t icr = E1000_READ_REG(hw, ICR);
+#ifdef CONFIG_E1000_NAPI
+ /* read ICR disables interrupts using IAM, so keep up with our
+* enable/disable accounting */
+ atomic_inc(adapter-irq_sem);
+#endif
+ adapter-detect_link = 0;
+ if ((icr (E1000_ICR_RXSEQ | E1000_ICR_LSC))
+ (icr E1000_ICR_INT_ASSERTED)) {
+ hw-get_link_status = 1;
+ /* 80003ES2LAN workaround--
+ * For packet buffer work-around on link down event;
+ * disable receives here in the ISR and
+ * reset adapter in watchdog
+ */
+ if (netif_carrier_ok(netdev)
+ (adapter-hw.mac_type == e1000_80003es2lan)) {
+ /* disable receives */
+ uint32_t rctl = E1000_READ_REG(hw, RCTL);
+ E1000_WRITE_REG(hw, RCTL, rctl
~E1000_RCTL_EN);
+ }
+ /* guard against interrupt when we're going down */
+ if (!test_bit(__E1000_DOWN, adapter-flags))
+ mod_timer(adapter-watchdog_timer,
+ jiffies + 1);
+ }
+ } else {
+ E1000_WRITE_REG(hw, ICR, (0x ~(E1000_ICR_RXSEQ |
+E1000_ICR_LSC)));
+ /* bummer we have to flush here, but things break otherwise as
+* some event appears to be lost or delayed and throughput
+* drops. In almost all tests this flush is un-necessary */
+ E1000_WRITE_FLUSH(hw);
+#ifdef CONFIG_E1000_NAPI
+ /* Interrupt Auto-Mask (IAM)...upon writing ICR, interrupts are
+* masked. No need for the IMC write, but it does mean we
+* should account for it ASAP. */
+ atomic_inc(adapter-irq_sem);
+#endif
+ }
+
+#ifdef CONFIG_E1000_NAPI
+ if (likely(netif_rx_schedule_prep(netdev)))
+
[PATCH 17/18] e1000: increment version to 7.3.15-k2
Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 71524b1..276eeb8 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -35,7 +35,7 @@ static char e1000_driver_string[] = Int #else #define DRIVERNAPI -NAPI #endif -#define DRV_VERSION 7.2.9-k4DRIVERNAPI +#define DRV_VERSION 7.3.15-k2DRIVERNAPI char e1000_driver_version[] = DRV_VERSION; static char e1000_copyright[] = Copyright (c) 1999-2006 Intel Corporation.; --- Auke Kok [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
John W. Linville wrote: On Wed, Nov 01, 2006 at 11:28:05AM +0100, Jiri Benc wrote: On Wed, 25 Oct 2006 22:15:23 -0700, Simon Barber wrote: Re: registering as a real protocol - yes this I have been going on about for a while. This needs a few changes in how things work: 1. Register as a real protocol. 2. Change drivers to use netif_rx to receive frames (will also be more efficient) This is something I really want too. I see Simon's suggestions in the category of making wireless devices 1st class citizens. I mostly agree with his suggestions, and they are on my list. Do we see these as merge requirements? The only merge requirement should be that merging d80211 doesn't break existing in-tree wireless drivers. We have that today -- you can have both stacks in the tree and running in parallel. With that, we have the ability to migrate over time. The other 'merge requirements' are functionally irrelevant. We know the d80211 stack is where wireless on Linux is going -- the sooner steps are taken to get that stack out to the masses the faster it can be adopted and improved. The agreement to switch to d80211 was reached back in April -- its been six months and there still doesn't appear to be traction at putting in action the decisions reached at that time. If people have issues with with specific components of d80211 prior to its merging, stand up and state what they are and how not fixing them would negatively impact people that aren't using the d80211 subsystem. Don't take the above as me saying there aren't items that need to be fixed/improved in d80211 -- there is work to be done. But that shouldn't stop it from being merged w/ the EXPERIMENTAL flag set. Is this agreeable? Or do we think this needs to happen before a merge to -mm? We reached the point where we should be in -mm a long time ago as soon as both stacks could exist concurrently. d80211 should have been in Linus' tree a long time ago. James - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
On Wed, Nov 01, 2006 at 05:05:51PM +0100, Pavel Machek ([EMAIL PROTECTED]) wrote: Hi! Hi Pavel. Kevent is a generic subsytem which allows to handle event notifications. It supports both level and edge triggered events. It is similar to poll/epoll in some cases, but it is more scalable, it is faster and allows to work with essentially eny kind of events. Quantifying how much more scalable would be nice, as would be some example where it is useful. (It makes my webserver twice as fast on monster 64-cpu box). Trivial kevent web-server can handle 3960+ req/sec on Xeon 2.4Ghz with 1Gb RAM, epoll based - 2200-2500 req/sec. 100 Mbit wire is filled almost 100% (10582.7 KB/s of data without TCP and below headers). More benchmarks created by me and Johann Borck can be found on project's homepage as long as all my sources used in tests. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
Hallo, Evgeniy Polyakov. On 2006-11-01, you wrote: [] Quantifying how much more scalable would be nice, as would be some example where it is useful. (It makes my webserver twice as fast on monster 64-cpu box). Trivial kevent web-server can handle 3960+ req/sec on Xeon 2.4Ghz with [...] Seriously. I'm seeing that patches also. New, shiny, always ready for inclusion. But considering kernel (linux in this case) as not thing for itself, i want to ask following question. Where's real-life application to do configure make make install? There were some comments about laking much of such programs, answers were was in prev. e-mail, need to update them, something like that. Trivial web server sources url, mentioned in benchmark isn't pointed in patch advertisement. If it was, should i actually try that new *trivial* wheel? Saying that, i want to give you some short examples, i know. *Linux kernel - userspace*: o Alexey Kuznetsov networking - (excellent) iproute set of utilities; o Maxim Krasnyansky tun net driver - vtun daemon application; *Glibc with mister Drepper* has huge set of tests, please search for `tst*' files in the sources. To make a little hint to you, Evgeniy, why don't you find a little animal in the open source zoo to implement little interface to proposed kernel subsystem and then show it to The Big Jury (not me), we have here? And i can not see, how you've managed to implement something like that having almost nothing on the test basket. Very *suspicious* ch. One, that comes in mind is lighthttpd http://www.lighttpd.net/. It had sub-interface for event systems like select,poll,epoll, when i checked its sources last time. And it is mature, btw. Cheers. [ -*- OT -*- ] [ I wouldn't write all this, unless saw your opinion about the ] [ reportbug (part of the Debian Bug Tracking System) this week.] [ While i'm nobody here, imho, the first thing about good programmer ] [ must be, that he is excellent user. ] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.4] bridge netfilter deadlock
A deadlock was found in bridge netfilter code (2.4 only), when a device is removed. The device removal path causes a BPDU to be generated and ends up self deadlocking on the BR lock. Simple fix would be to avoid generating config bpdu's immediately when becoming root bridge, and just let the first hello timer tick do that. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- linux-2.4.33.3.orig/net/bridge/br_stp.c 2006-10-30 12:46:59.0 -0800 +++ linux-2.4.33.3/net/bridge/br_stp.c 2006-10-30 12:53:59.0 -0800 @@ -140,8 +140,8 @@ br-forward_delay = br-bridge_forward_delay; br_topology_change_detection(br); br_timer_clear(br-tcn_timer); - br_config_bpdu_generation(br); - br_timer_set(br-hello_timer, jiffies); + + br_timer_set(br-hello_timer, jiffies - br-hello_time); } /* called under bridge lock */ -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ipw2100: remove _must_check warning
In kernel 2.6.19, there is a configuration option that enables the _must_check logic. This patch adds a check and removes the warning for a pci_enable_device call in the ipw2100 driver. Signed-off-by: Larry Finger [EMAIL PROTECTED] --- Index: wireless-2.6/drivers/net/wireless/ipw2100.c === --- wireless-2.6.orig/drivers/net/wireless/ipw2100.c +++ wireless-2.6/drivers/net/wireless/ipw2100.c @@ -6424,6 +6424,7 @@ static int ipw2100_resume(struct pci_dev struct ipw2100_priv *priv = pci_get_drvdata(pci_dev); struct net_device *dev = priv-net_dev; u32 val; + int err; if (IPW2100_PM_DISABLED) return 0; @@ -6433,7 +6434,9 @@ static int ipw2100_resume(struct pci_dev IPW_DEBUG_INFO(%s: Coming out of suspend...\n, dev-name); pci_set_power_state(pci_dev, PCI_D0); - pci_enable_device(pci_dev); + err = pci_enable_device(pci_dev); + if (err) + return err; pci_restore_state(pci_dev); /* - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 16/18] e1000: add dynamic itr modes
Kok, Auke wrote: Add a new dynamic itr algorithm, with 2 modes, and make it the default operation mode. This greatly reduces latency and increases small packet performance, at the cost of some CPU utilization. Bulk traffic throughput is unaffected. Thanks to the generous testing of Rick Jones from HP, we have some externally published numbers to back up this patch. Please see the updated paper at ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt or http://tinyurl.com/yd2ufj We would also like to thank Robin Humble for his feedback and input on this patch. Testing and comments welcome, particularly from anyone running latency sensitive testing, where they might want to test with the InterruptThrottleRate=1 module parameter. Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 and region #2 not an MMIO resource
Libor Klepáč [EMAIL PROTECTED] : [...] i have build computer with msi MS-7235 motherboard, it has r8169 chip onboard i'm using kernel version 2.6.18 from debian (and i also rebuild kernel without NAPI). When i modprobe module , dmesg says r8169 Gigabit Ethernet driver 2.2LK loaded PCI: Enabling device :03:06.0 ( - 0003) ACPI: PCI Interrupt :03:06.0[A] - GSI 21 (level, low) - IRQ 201 r8169 :03:06.0: region #2 not an MMIO resource, aborting lspci says (there is no region 2? ) Please send lspci -vvx, I need the hexadecimal ID. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 and region #2 not an MMIO resource
Francois Romieu [EMAIL PROTECTED] : [...] Please send lspci -vvx, I need the hexadecimal ID. Actually, no. This is a 8167, 2.6.19-rc4 includes the correct code for it. -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 and region #2 not an MMIO resource
Dne středa 01 listopad 2006 23:00 Francois Romieu napsal(a): Libor Klepáč [EMAIL PROTECTED] : [...] i have build computer with msi MS-7235 motherboard, it has r8169 chip onboard i'm using kernel version 2.6.18 from debian (and i also rebuild kernel without NAPI). When i modprobe module , dmesg says r8169 Gigabit Ethernet driver 2.2LK loaded PCI: Enabling device :03:06.0 ( - 0003) ACPI: PCI Interrupt :03:06.0[A] - GSI 21 (level, low) - IRQ 201 r8169 :03:06.0: region #2 not an MMIO resource, aborting lspci says (there is no region 2? ) Please send lspci -vvx, I need the hexadecimal ID. hello, here it comes :03:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169SC Gigabit Ethernet (rev 10) Subsystem: Micro-Star International Co., Ltd.: Unknown device 235c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (8000ns min, 16000ns max), Cache Line Size: 0x10 (64 bytes) Interrupt: pin A routed to IRQ 201 Region 0: I/O ports at cc00 [size=256] Region 1: Memory at fd7fd000 (32-bit, non-prefetchable) [size=256] Expansion ROM at fde2 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: ec 10 67 81 07 00 b0 02 10 00 00 02 10 20 00 00 10: 01 cc 00 00 00 d0 7f fd 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 62 14 5c 23 30: 00 00 00 00 dc 00 00 00 00 00 00 00 07 01 20 40 libor pgpJ53AxCGBy7.pgp Description: PGP signature
Re: r8169 and region #2 not an MMIO resource
Dne středa 01 listopad 2006 23:13 Francois Romieu napsal(a): Francois Romieu [EMAIL PROTECTED] : [...] Please send lspci -vvx, I need the hexadecimal ID. Actually, no. This is a 8167, 2.6.19-rc4 includes the correct code for it. ok, thanks, i'll try this version libor pgpEJVd7w5u2M.pgp Description: PGP signature
Re: [take22 0/4] kevent: Generic event handling mechanism.
On Wed, Nov 01, 2006 at 06:20:43PM +, Oleg Verych ([EMAIL PROTECTED]) wrote: Hallo, Evgeniy Polyakov. Hello, Oleg. On 2006-11-01, you wrote: [] Quantifying how much more scalable would be nice, as would be some example where it is useful. (It makes my webserver twice as fast on monster 64-cpu box). Trivial kevent web-server can handle 3960+ req/sec on Xeon 2.4Ghz with [...] Seriously. I'm seeing that patches also. New, shiny, always ready for inclusion. But considering kernel (linux in this case) as not thing for itself, i want to ask following question. Where's real-life application to do configure make make install? Your real life or mine as developer? I fortunately do not know anything about your real life, but my real life applications can be found on project's homepage. There is a link to archive there, where you can find plenty of sources. You likely do not know, but it is a bit risky business to patch all existing applications to show that approach is correct, if implementation is not completed. You likely do not know, but after I first time announced kevents in February I changed interfaces 4 times - and it is just interfaces, not including numerous features added/removed by developer's requests. There were some comments about laking much of such programs, answers were was in prev. e-mail, need to update them, something like that. Trivial web server sources url, mentioned in benchmark isn't pointed in patch advertisement. If it was, should i actually try that new *trivial* wheel? Answer is trivial - there is archive where one can find a source code (filenames are posted regulary). Should I create a rpm? For what glibc version? Saying that, i want to give you some short examples, i know. *Linux kernel - userspace*: o Alexey Kuznetsov networking - (excellent) iproute set of utilities; iproute documentation was way too bad when Alexey presented it first time :) o Maxim Krasnyansky tun net driver - vtun daemon application; *Glibc with mister Drepper* has huge set of tests, please search for `tst*' files in the sources. Btw, show me splice() 'shiny' application? Does lighttpd use it? Or move_pages(). To make a little hint to you, Evgeniy, why don't you find a little animal in the open source zoo to implement little interface to proposed kernel subsystem and then show it to The Big Jury (not me), we have here? And i can not see, how you've managed to implement something like that having almost nothing on the test basket. Very *suspicious* ch. There are always people who do not like something, what can I do with it? I present the code, we discuss it, I ask for inclusion (since it is the only way to get feedback), something requires changes, it is changed and so on - it is development process. I created 'little animal in the open source zoo' by myself to show how simple kevents are. One, that comes in mind is lighthttpd http://www.lighttpd.net/. It had sub-interface for event systems like select,poll,epoll, when i checked its sources last time. And it is mature, btw. As I already told several times, I changed only interfaces 4 times already, since no one seems to know what we really want and how interface should look like. You suggest to patch lighttpd? Well, it is doable, but then I will be asked to change apache and nginx. And then someone will suggest to change order of parameters. Will you help me rewrite userspace? No, you will not. You asks for something without providing anything back (not getting into account code, but discussion, ideas, testing time, nothing), and you do it in ultimate manner. Btw, kevent also support AIO notifications - do you suggest to patch reactor/proactor for tests? It supports network AIO - do you suggest to write support for that into apache? What about timers? It is possible to rewrite all POSIX timers users to usem instead. There is feature request for userspace events and singal delivery - what to do with that? I created trivial web servers, which send single static page and use various event handling schemes, and I test new subsystem with new tools, when tests are completed and all requested features are implemented it is time to work on different more complex users. So let's at least complete what we have right now, so no developer's efforts could be wasted writing empty chars in various places. Cheers. [ -*- OT -*- ] [ I wouldn't write all this, unless saw your opinion about the ] [ reportbug (part of the Debian Bug Tracking System) this week.] [ While i'm nobody here, imho, the first thing about good programmer ] [ must be, that he is excellent user. ] -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] [patch] net/tipc: sprintf/strcpy conversion
From: walter harms [EMAIL PROTECTED] Date: Wed, 01 Nov 2006 22:38:26 +0100 These line + strcpy(bcbearer-media.name, tipc-multicast); i gues that means tipc_bclink_name ? Why? The original code used tipc-multicast which is a different string than tipc_bclink_name which is multicast-link. - sprintf(bcbearer-media.name, tipc-multicast); + strcpy(bcbearer-media.name, tipc-multicast); If you are arguing that it should be changed, that's a different changeset to discuss. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc
James Ketrenos wrote: If people have issues with with specific components of d80211 prior to its merging, stand up and state what they are and how not fixing them would negatively impact people that aren't using the d80211 subsystem. Don't take the above as me saying there aren't items that need to be fixed/improved in d80211 -- there is work to be done. But that shouldn't stop it from being merged w/ the EXPERIMENTAL flag set. We reached the point where we should be in -mm a long time ago as soon as both stacks could exist concurrently. d80211 should have been in Linus' tree a long time ago. d80211 merge stoppers: - SMP issues (lack of locking, and overlocking via use of Big Network Lock) - userspace ABI It definitely shouldn't go upstream without that stuff. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Crash in ip_conntrack on shutdown
My desktop machine (Fedora Core 6) crashed on during shutdown when running latest 2.6.19-rc4 kernel. Machine is UP Amd64. It looks like a null dereference in ip_conntrack. See screenshot. http://picasaweb.google.com/stephen.hemminger/LinuxCrashes/photo#4992593950061821970 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.4] bridge netfilter deadlock
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 1 Nov 2006 11:45:50 -0800 A deadlock was found in bridge netfilter code (2.4 only), when a device is removed. The device removal path causes a BPDU to be generated and ends up self deadlocking on the BR lock. Simple fix would be to avoid generating config bpdu's immediately when becoming root bridge, and just let the first hello timer tick do that. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Applied, I'll push this to Willy. Thanks Stephen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
d80211 merge (was Re: [patch] d80211: use pfifo_qdisc_ops rather than d80211-specific qdisc)
Jeff Garzik wrote: James Ketrenos wrote: If people have issues with with specific components of d80211 prior to its merging, stand up and state what they are and how not fixing them would negatively impact people that aren't using the d80211 subsystem. Don't take the above as me saying there aren't items that need to be fixed/improved in d80211 -- there is work to be done. But that shouldn't stop it from being merged w/ the EXPERIMENTAL flag set. We reached the point where we should be in -mm a long time ago as soon as both stacks could exist concurrently. d80211 should have been in Linus' tree a long time ago. d80211 merge stoppers: - SMP issues (lack of locking, and overlocking via use of Big Network Lock) So we can set BROKEN_ON_SMP on it and we're good. The entire description of EXPERIMENTAL in init/Kconfig matches perfectly what we want -- bug reports, wider exposure, and a clear articulation that the feature is unstable. - userspace ABI What's the requirement on the userspace ABI? That the existing wireless extension interface needs to work, or ? We can use the wireless extension currently to match (most of) the existing WE functionality -- at least to get the majority of wireless users up and running (for those that have cards that have d80211 drivers anyway). It definitely shouldn't go upstream without that stuff. How will merging with the existing locking problems or ABI issue negatively impact people that aren't using the d80211 subsystem anyway? If having the code there doesn't hurt anyone, why not get it out for wider adoption, exposure, and contribution? Why is there such a hesitation to merge this stack and help to accelerate the set of functionality available with wireless on Linux? James - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crash in ip_conntrack on shutdown
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 01 Nov 2006 16:56:35 -0800 My desktop machine (Fedora Core 6) crashed on during shutdown when running latest 2.6.19-rc4 kernel. Machine is UP Amd64. It looks like a null dereference in ip_conntrack. See screenshot. http://picasaweb.google.com/stephen.hemminger/LinuxCrashes/photo#4992593950061821970 Can some x86_64 expert decode this? I'm trying to figure out what object is being NULL defer'd, and after taking a quick look at this dump I can't figure it out. I suspect there may also be a OOPS right before this one, I also wonder if this was actually a BUG_ON() trigger. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] silence a warning in ebtables
From: Meelis Roos [EMAIL PROTECTED] Date: Wed, 1 Nov 2006 19:01:14 +0200 (EET) net/bridge/netfilter/ebtables.c: In function 'ebt_dev_check': net/bridge/netfilter/ebtables.c:89: warning: initialization discards qualifiers from pointer target type So make the char* a const char * and the warning is gone. Signed-off-by: Meelis Roos [EMAIL PROTECTED] Applied, thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
On 11/1/06, Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Wed, Nov 01, 2006 at 06:20:43PM +, Oleg Verych ([EMAIL PROTECTED]) wrote: Hallo, Evgeniy Polyakov. Hello, Oleg. On 2006-11-01, you wrote: [] Quantifying how much more scalable would be nice, as would be some example where it is useful. (It makes my webserver twice as fast on monster 64-cpu box). Trivial kevent web-server can handle 3960+ req/sec on Xeon 2.4Ghz with [...] Seriously. I'm seeing that patches also. New, shiny, always ready for inclusion. But considering kernel (linux in this case) as not thing for itself, i want to ask following question. Where's real-life application to do configure make make install? Your real life or mine as developer? I fortunately do not know anything about your real life, but my real life applications can be found on project's homepage. There is a link to archive there, where you can find plenty of sources. You likely do not know, but it is a bit risky business to patch all existing applications to show that approach is correct, if implementation is not completed. You likely do not know, but after I first time announced kevents in February I changed interfaces 4 times - and it is just interfaces, not including numerous features added/removed by developer's requests. There were some comments about laking much of such programs, answers were was in prev. e-mail, need to update them, something like that. Trivial web server sources url, mentioned in benchmark isn't pointed in patch advertisement. If it was, should i actually try that new *trivial* wheel? Answer is trivial - there is archive where one can find a source code (filenames are posted regulary). Should I create a rpm? For what glibc version? Saying that, i want to give you some short examples, i know. *Linux kernel - userspace*: o Alexey Kuznetsov networking - (excellent) iproute set of utilities; iproute documentation was way too bad when Alexey presented it first time :) o Maxim Krasnyansky tun net driver - vtun daemon application; *Glibc with mister Drepper* has huge set of tests, please search for `tst*' files in the sources. Btw, show me splice() 'shiny' application? Does lighttpd use it? Or move_pages(). To make a little hint to you, Evgeniy, why don't you find a little animal in the open source zoo to implement little interface to proposed kernel subsystem and then show it to The Big Jury (not me), we have here? And i can not see, how you've managed to implement something like that having almost nothing on the test basket. Very *suspicious* ch. There are always people who do not like something, what can I do with it? I present the code, we discuss it, I ask for inclusion (since it is the only way to get feedback), something requires changes, it is changed and so on - it is development process. I created 'little animal in the open source zoo' by myself to show how simple kevents are. One, that comes in mind is lighthttpd http://www.lighttpd.net/. It had sub-interface for event systems like select,poll,epoll, when i checked its sources last time. And it is mature, btw. As I already told several times, I changed only interfaces 4 times already, since no one seems to know what we really want and how interface should look like. Indesiciveness has certainly been an issue here, but I remember akpm and Ulrich both giving concrete suggestions. I was particularly interested in Andrew's request to explain and justify the differences between kevent and BSD's kqueue interface. Was there a discussion that I missed? I am very interested to see your work on this mechanism merged, because you've clearly emphasized performance and shown impressive results. But it seems like we lose out on a lot by throwing out all the applications that already use kqueue. NATE - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] networking structure holes
On 10/31/06, Eric Dumazet [EMAIL PROTECTED] wrote: Arnaldo Carvalho de Melo a écrit : Hi, I've been working on some DWARF2 utilities and one of them, pahole (Poke-a-Hole) can be used to find holes due to alignment rules in structs, the full output of: [EMAIL PROTECTED] net-2.6]$ pahole net/ipv4/tcp.o is available at: http://oops.merseine.nu:81/acme/net.ipv4.tcp.o.pahole Just to show what we can find with this tool here is the layout of struct net_device, that barring any cacheline locality optimization has 4 bytes to harvest, David, do you think reordering those fields to get 4 byts back is ok? I just want to bring your attention this net_device structure was re-ordered (by me :)) so that separate cache lines are used on SMP machines. If you select CONFIG_SMP , you'll probably notice far more holes. But it was a feature, not lazyness. Thanks for commenting on this case! We can probably move some fields, but very carefully :) Of course, in time I probably will try to combine valgrind's cachegrind or some new tool using the same principles I used in OSTRA to find out working sets of struct members to do automatic suggestions on how to reorder structs to avoid holes while keeping the relevant struct members close together as to exploit cacheline locality effects, like you do so well manually :-) - Arnaldo PS.: While we don't have tools to check out that the holes are not a problem because we want to exploit cacheline locality effects... what about some comments on the structs to explain that such holes are not a problem? :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[airo.c bug] Couldn't allocate RX FID / Max tries exceeded when issueing command
hardware: ibm thinkpad t30 kernel: 2.6.18 problem: airo(): Probing for PCI adapters ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 ACPI: PCI Interrupt :02:02.0[A] - Link [LNKC] - GSI 11 (level, low) - IRQ 11 airo(eth1): Found an MPI350 card airo(eth1): Max tries exceeded when issueing command airo(eth1): Couldn't allocate RX FID airo(eth1): Could not map memory airo(): Finished probing for PCI adapters Any ideas? 1) Firmware upgrade/downgrade? (How?) 2) Command sequence to better reset the card? Documentation? My complete dmesg log (at loglevel=8) follows. TIA. Linux version 2.6.18 ([EMAIL PROTECTED]) (gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #10 PREEMPT Wed Nov 1 21:15:56 EST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d2000 - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0ff6 (usable) BIOS-e820: 0ff6 - 0ff7a000 (ACPI data) BIOS-e820: 0ff7a000 - 0ff7c000 (ACPI NVS) BIOS-e820: 0ff7c000 - 1000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 255MB LOWMEM available. On node 0 totalpages: 65376 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 61280 pages, LIFO batch:15 DMI present. ACPI: RSDP (v002 IBM ) @ 0x000f7010 ACPI: XSDT (v001 IBMTP-1I0x2010 LTP 0x) @ 0x0ff6f3a8 ACPI: FADT (v001 IBMTP-1I0x2010 IBM 0x0001) @ 0x0ff6f3f4 ACPI: SSDT (v001 IBMTP-1I0x2010 MSFT 0x010d) @ 0x0ff6f4a8 ACPI: ECDT (v001 IBMTP-1I0x2010 IBM 0x0001) @ 0x0ff79f55 ACPI: TCPA (v001 IBMTP-1I0x2010 PTL 0x0001) @ 0x0ff79fa6 ACPI: BOOT (v001 IBMTP-1I0x2010 LTP 0x0001) @ 0x0ff79fd8 ACPI: DSDT (v001 IBMTP-1I0x2010 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 2000 (gap: 1000:ef80) Detected 1794.240 MHz processor. Built 1 zonelists. Total pages: 65376 Kernel command line: root=/dev/hda1 video=radeonfb:1400x1050 resume=/dev/hda2 loglevel=8 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 251508k/261504k available (3644k kernel code, 9564k reserved, 2105k data, 196k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3590.11 BogoMIPS (lpj=1795059) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 3febf9ff CPU: After vendor identify, caps: 3febf9ff CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: 3febf9ff 0080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz stepping 04 Checking 'hlt' instruction... OK. ACPI: Core revision 20060707 ACPI: setting ELCR to 0200 (from 0800) PM: Adding info for No Bus:platform NET: Registered protocol family 16 ACPI: ACPI Dock Station Driver ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfd8fe, last bus=8 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Found ECDT ACPI: Could not use ECDT ACPI Error (evregion-0317): No handler for Region [ECOR] (cff4e72c) [EmbeddedControl] [20060707] ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20060707] ACPI Exception (dswexec-0458): AE_NOT_EXIST, While resolving operands for [OpcodeName unavailable] [20060707] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPC_.FDC_._INI] (Node cff5a888), AE_NOT_EXIST ACPI Error (evregion-0317): No handler for Region [ECOR] (cff4e72c) [EmbeddedControl] [20060707] ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20060707] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPC_.EC__._INI] (Node cff56b6c), AE_NOT_EXIST ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing PM: Adding info for acpi:acpi ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10
[PATCH] bcm43xx: remove badness variable and related routine
When the periodic work function in bcm43xx was converted for voluntary
preemption
to reduce latency, a new function was created to estimate the badness of
each step, and this quantity was used to determine if preemption should be
enabled when periodic work was undertaken. This concept was quite useful
while debugging of periodic work was in progress. Now that this routine
seems to be working correctly, it is time to simplify the code. This
patch keeps the functionality intact, but simplifies the code.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
Please apply this to wireless-2.6 for ultimate inclusion in 2.6.20. There is
no reason for it to appear in 2.6.19 as it is not a bug fix. The change is
purely janitorial.
Larry
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3192,55 +3192,27 @@ static void bcm43xx_periodic_every15sec(
static void do_periodic_work(struct bcm43xx_private *bcm)
{
- unsigned int state;
-
- state = bcm-periodic_state;
- if (state % 8 == 0)
+ if (bcm-periodic_state % 8 == 0)
bcm43xx_periodic_every120sec(bcm);
- if (state % 4 == 0)
+ if (bcm-periodic_state % 4 == 0)
bcm43xx_periodic_every60sec(bcm);
- if (state % 2 == 0)
+ if (bcm-periodic_state % 2 == 0)
bcm43xx_periodic_every30sec(bcm);
- if (state % 1 == 0)
- bcm43xx_periodic_every15sec(bcm);
- bcm-periodic_state = state + 1;
+ bcm43xx_periodic_every15sec(bcm);
schedule_delayed_work(bcm-periodic_work, HZ * 15);
}
-/* Estimate a Badness value based on the periodic work
- * state-machine state. Badness is worse (bigger), if the
- * periodic work will take longer.
- */
-static int estimate_periodic_work_badness(unsigned int state)
-{
- int badness = 0;
-
- if (state % 8 == 0) /* every 120 sec */
- badness += 10;
- if (state % 4 == 0) /* every 60 sec */
- badness += 5;
- if (state % 2 == 0) /* every 30 sec */
- badness += 1;
- if (state % 1 == 0) /* every 15 sec */
- badness += 1;
-
-#define BADNESS_LIMIT 4
- return badness;
-}
-
static void bcm43xx_periodic_work_handler(void *d)
{
struct bcm43xx_private *bcm = d;
struct net_device *net_dev = bcm-net_dev;
unsigned long flags;
u32 savedirqs = 0;
- int badness;
unsigned long orig_trans_start = 0;
mutex_lock(bcm-mutex);
- badness = estimate_periodic_work_badness(bcm-periodic_state);
- if (badness BADNESS_LIMIT) {
+ if (unlikely(bcm-periodic_state % 4 == 0)) {
/* Periodic work will take a long time, so we want it to
* be preemtible.
*/
@@ -3272,7 +3244,7 @@ static void bcm43xx_periodic_work_handle
do_periodic_work(bcm);
- if (badness BADNESS_LIMIT) {
+ if (unlikely(bcm-periodic_state % 4 == 0)) {
spin_lock_irqsave(bcm-irq_lock, flags);
tasklet_enable(bcm-isr_tasklet);
bcm43xx_interrupt_enable(bcm, savedirqs);
@@ -3283,6 +3255,7 @@ static void bcm43xx_periodic_work_handle
net_dev-trans_start = orig_trans_start;
}
mmiowb();
+ bcm-periodic_state++;
spin_unlock_irqrestore(bcm-irq_lock, flags);
mutex_unlock(bcm-mutex);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crash in ip_conntrack on shutdown
On Wed, 1 Nov 2006 18:48:56 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: On Wed, 01 Nov 2006 17:49:31 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 01 Nov 2006 16:56:35 -0800 My desktop machine (Fedora Core 6) crashed on during shutdown when running latest 2.6.19-rc4 kernel. Machine is UP Amd64. It looks like a null dereference in ip_conntrack. See screenshot. http://picasaweb.google.com/stephen.hemminger/LinuxCrashes/photo#4992593950061821970 Can some x86_64 expert decode this? I'm trying to figure out what object is being NULL defer'd, and after taking a quick look at this dump I can't figure it out. I suspect there may also be a OOPS right before this one, I also wonder if this was actually a BUG_ON() trigger. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Instruction decode of ip_conntrack:destroy_conntrack+0xfc = 0x21ce 2177: 75 0a jne2183 destroy_conntrack+0xb1 2179: 0f 0b ud2a 217b: 68 00 00 00 00 pushq $0x0 2180: c2 56 01retq $0x156 2183: 48 8b 41 08 mov0x8(%rcx),%rax 2187: 48 89 42 08 mov%rax,0x8(%rdx) 218b: 48 89 10mov%rdx,(%rax) 218e: 48 c7 41 08 00 02 20movq $0x200200,0x8(%rcx) 2195: 00 2196: 48 c7 83 f8 00 00 00movq $0x100100,0xf8(%rbx) 219d: 00 01 10 00 21a1: ff 05 00 00 00 00 incl 0(%rip)# 21a7 destroy_conntrack+0xd5 21a7: bf 01 00 00 00 mov$0x1,%edi 21ac: e8 00 00 00 00 callq 21b1 destroy_conntrack+0xdf 21b1: e8 00 00 00 00 callq 21b6 destroy_conntrack+0xe4 21b6: 48 8b 53 58 mov0x58(%rbx),%rdx 21ba: 48 85 d2test %rdx,%rdx 21bd: 74 0f je 21ce destroy_conntrack+0xfc 21bf: ff 0a decl (%rdx) 21c1: 0f 94 c0sete %al 21c4: 84 c0 test %al,%al 21c6: 74 06 je 21ce destroy_conntrack+0xfc 21c8: 48 89 d7mov%rdx,%rdi 21cb: ff 52 08callq *0x8(%rdx) 21ce: 48 89 dfmov%rbx,%rdi --- last visible spot in back trace 21d1: 5b pop%rbx 21d2: e9 00 00 00 00 jmpq 21d7 invert_tuplepr It might be in ip_conntrack_netbios? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Big Endian PCI driver
Hi, I am trying to run PCI based Ethernet card (RTL 8139) on a big endian host. The pci controller that I have does not have any mechanism for swapping the Big Endian data to Little Endian. While running the 8139too.c driver I see that the data generated on the line is Endian swapped. In the data sheet of RTL 8139 I could not find any BSWAP bit neither the 8139too.c driver does any swapping of data while transmitting or receiving. However, if I change the driver to swap data before transmitting and after receiving I am able to get it working. Does the RTL 8139 driver in 2.6.10 support Big Endian? Is there any other Ethernet card driver which supports big endian host (with a PCI controller which does not support byte swapping)? Thanks, Shalin Patel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP congestion graphs (2.6.19-rc4)
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 31 Oct 2006 21:58:48 -0800 Some basic stuff is on the parent page http://developer.osdl.org/shemminger/tcp Are you using tcptrace to generate those plots? If so are you using xplot or gnuplot to build those image files? Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] networking structure holes
Arnaldo Carvalho de Melo a écrit : On 10/31/06, Eric Dumazet [EMAIL PROTECTED] wrote: Arnaldo Carvalho de Melo a écrit : Hi, I've been working on some DWARF2 utilities and one of them, pahole (Poke-a-Hole) can be used to find holes due to alignment rules in structs, the full output of: [EMAIL PROTECTED] net-2.6]$ pahole net/ipv4/tcp.o is available at: http://oops.merseine.nu:81/acme/net.ipv4.tcp.o.pahole Just to show what we can find with this tool here is the layout of struct net_device, that barring any cacheline locality optimization has 4 bytes to harvest, David, do you think reordering those fields to get 4 byts back is ok? I just want to bring your attention this net_device structure was re-ordered (by me :)) so that separate cache lines are used on SMP machines. If you select CONFIG_SMP , you'll probably notice far more holes. But it was a feature, not lazyness. Thanks for commenting on this case! We can probably move some fields, but very carefully :) Of course, in time I probably will try to combine valgrind's cachegrind or some new tool using the same principles I used in OSTRA to find out working sets of struct members to do automatic suggestions on how to reorder structs to avoid holes while keeping the relevant struct members close together as to exploit cacheline locality effects, like you do so well manually :-) - Arnaldo PS.: While we don't have tools to check out that the holes are not a problem because we want to exploit cacheline locality effects... what about some comments on the structs to explain that such holes are not a problem? :-) I am all for automatic tools, if they can convince human beings :) For example, I am using an optimization that is quite simple but which was not accepted by netdev community : - Moving the struct flowi directly into struct dst_entry, right after the 'struct dst_entry *next;' pointer. AFAIK all objects that include a 'struct dst_entry' also include a 'struct flowi', so this is just a small violation of layering. This really helps because lookups now touch only one cache line per chained item instead of two/three. On loaded routers with 8 items per chain, thats 8 or 16 cache lines CPU dont have to bring in its cache per IP packet. Eric - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How about current IP100A status? 10/31/2006
Jesse Huang wrote: Dear All: How about current IP100A, sundance.c status? Should it be put into kernel or not? Is there any sentence should I need to modify? It's in my queue. We are in a bug fix-only cycle right now, so it has been a bit lower priority, but I will queue it for 2.6.20. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take22 0/4] kevent: Generic event handling mechanism.
On Wed, Nov 01, 2006 at 06:12:41PM -0800, Nate Diller ([EMAIL PROTECTED]) wrote: Indesiciveness has certainly been an issue here, but I remember akpm and Ulrich both giving concrete suggestions. I was particularly interested in Andrew's request to explain and justify the differences between kevent and BSD's kqueue interface. Was there a discussion that I missed? I am very interested to see your work on this mechanism merged, because you've clearly emphasized performance and shown impressive results. But it seems like we lose out on a lot by throwing out all the applications that already use kqueue. It looks you missed that discussion - freebsd kqueue has fields in the kevent structure which have diffent sizes in 32 and 64 bit environments. NATE -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
On Wed, Oct 25, 2006 at 07:22:08PM -0700, David Brownell wrote: On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote: On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: Instead, usbnet.c should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. I had in mind something simpler -- #ifdeffing the entire functions, as in this patch. It looks more complicated than it is, because diff gets confused by moving two functions earlier in the file. (Thanks for starting this, Randy ... these two patches should be merged before RC4 ships.) Argh, there were just too many different versions of these patches floating around. Can you resend the final versions please? thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] warning in SCTP
CC [M] net/sctp/sm_make_chunk.o net/sctp/sm_make_chunk.c: In function 'sctp_unpack_cookie': net/sctp/sm_make_chunk.c:1358: warning: initialization discards qualifiers from pointer target type The reason is that sctp_unpack_cookie() takes a const struct sctp_endpoint and modifies the digest in it (digest being embedded in the struct, not a pointer). So sctp_unpack_cookie really does not use the argument as const, mark it as such. Signed-off-by: Meelis Roos [EMAIL PROTECTED] diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h index de313de..ef80489 100644 --- a/include/net/sctp/sm.h +++ b/include/net/sctp/sm.h @@ -272,7 +272,7 @@ void sctp_generate_heartbeat_event(unsig void sctp_ootb_pkt_free(struct sctp_packet *); -struct sctp_association *sctp_unpack_cookie(const struct sctp_endpoint *, +struct sctp_association *sctp_unpack_cookie(struct sctp_endpoint *, const struct sctp_association *, struct sctp_chunk *, gfp_t gfp, int *err, diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c index 507dff7..3d41a9c 100644 --- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -1346,7 +1346,7 @@ nodata: /* Unpack the cookie from COOKIE ECHO chunk, recreating the association. */ struct sctp_association *sctp_unpack_cookie( - const struct sctp_endpoint *ep, + struct sctp_endpoint *ep, const struct sctp_association *asoc, struct sctp_chunk *chunk, gfp_t gfp, int *error, struct sctp_chunk **errp) -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] [patch] net/tipc: sprintf/strcpy conversion
David Miller wrote: From: walter harms [EMAIL PROTECTED] Date: Wed, 01 Nov 2006 22:38:26 +0100 These line +strcpy(bcbearer-media.name, tipc-multicast); i gues that means tipc_bclink_name ? mea culpa, i should not write mail when tired. Why? The original code used tipc-multicast which is a different string than tipc_bclink_name which is multicast-link. - sprintf(bcbearer-media.name, tipc-multicast); + strcpy(bcbearer-media.name, tipc-multicast); If you are arguing that it should be changed, that's a different changeset to discuss. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [KJ] [tipc-discussion] [patch] net/tipc: sprintf/strcpy conversion
Florian Westphal wrote: walter harms [EMAIL PROTECTED] wrote: These line + strcpy(bcbearer-media.name, tipc-multicast); i gues that means tipc_bclink_name ? The idea was to change how things are done, not _what_ is being done. an even more secure version could be like this: strncpy(bcbearer-media.name,sizeof(bcbearer-media.name),tipc_bclink_name); Ugh, please, no. The size of src is known in all cases; there is absoluty no point in using str(n|l)cpy here. (in case someone ever changes the size of cbearer-media.name or tipc_bclink_name and the hope that wchat_t will never reach the kernel) In this case 'someone' should be really hurt, don't you think? hi florian, i am on the side of error, the code increase is marginal and the speed penalty also, so why not ? you make sure that an overflow may never happen, and the rest in name gets zeroed. The problem is that when the error occurs it may be later than the actual changeset. NTL it is an hint, and if you feel ok with it and the maintainer has no objects i have no problems either. re, wh - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How about current IP100A status? 10/31/2006
Dear Jeff: Thanks for your help. We are happy to see new version of our driver will be support in the new kernel. Best Regards, Jesse Huang - Original Message - From: Jeff Garzik [EMAIL PROTECTED] To: Jesse Huang [EMAIL PROTECTED] Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; [EMAIL PROTECTED] Sent: Thursday, November 02, 2006 1:21 PM Subject: Re: How about current IP100A status? 10/31/2006 Jesse Huang wrote: Dear All: How about current IP100A, sundance.c status? Should it be put into kernel or not? Is there any sentence should I need to modify? It's in my queue. We are in a bug fix-only cycle right now, so it has been a bit lower priority, but I will queue it for 2.6.20. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Drain TX status before starting IRQs
Michael Buesch wrote: Drain the Microcode TX-status-FIFO before we enable IRQs. This is required, because the FIFO may still have entries left from a previous run. Those would immediately fire after enabling IRQs and would lead to an oops in the DMA TXstatus handling code. Signed-off-by: Michael Buesch [EMAIL PROTECTED] -- Please consider also pushing this into the -stable tree. The bug is not likely to trigger, but at least ben triggered it in the past. Anyway, it can't hurt much to drain the FIFO before running the device. Note that this is diffed against 2.6.18.1 and not 2.6.18 as the diff prolog suggests. I just forgot to rename the directory. ;) Has anyone used this patch, particularly with WPA encryption? When I try it, wpa_supplicant immediately uses 90+% of the cpu and never actually authenticates with my AP. I wonder if it is something with my system. Thanks, Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
