Re: Wireless network card capabilities
On Sun, 2007-02-04 at 13:27 +0100, Ulrich Kunitz wrote: On 07-02-04 10:42 James Courtier-Dutton wrote: Hi, Can Wireless network cards receive and transmit on two channels at once? I am thinking of implementing a way for a wireless VoIP phone on Linux being able to hand off from one AP to another without dropping the call. For this to work, the wireless card must be able to chat on two channels during the handover, so as to not loose any voice packets. James The easiest way to achieve this is to use two wireless adapters. I'm not sure, whether there are adapters, which support parallel reception on two channels and manage two independent associations at the same time. Not too sure, but from what I've understood of Channel bonding, maybe you could bind the 2 wifi ifaces using 2 adapters and linux's channel bonding modules ? Ashwin - 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
NAPI quota and budget
Hello! K. Salah writes: I have a question about the quota per poll in NAPI. Any idea how the quota of 64 packets per poll per NIC was selected? Why 64, not any other number? Is there science behind this number. The number comes from experimentation. The science is thats it's possible set any number at all. The first NAPI driver tulip (100 Mps) increased the RX-ringsize from 32 128 descriptors and used 16 pkts per poll. A quota of 64 for GIGE devices (tested with 256 descriptors) seemed to be good compromise in experiments. 16 64 netdev_budget And the same goes for the budget of 300? Was that done based on expermintation? Yes it was the size of central buffer size before NAPI. It's possible the netdev_budget can be increased a bit today as the packet processing speed has increased. 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
Re: [PATCH] HTB O(1) class lookup
On 01-02-2007 12:30, Andi Kleen wrote: Simon Lodal [EMAIL PROTECTED] writes: Memory is generally not an issue, but CPU is, and you can not beat the CPU efficiency of plain array lookup (always faster, and constant time). Probably for some old (or embedded) lean boxes used for small network routers, with memory hungry iptables - memory could be an issue. Actually that's not true when the array doesn't fit in cache. The cost of going out to memory over caches is so large (factor 100 and more) that often algorithms with smaller cache footprint can easily beat algorithms that execute much less instructions if it has less cache misses. That is because not all instructions have the same cost; anything in core is very fast but going out to memory is very slow. That said I think I agree with your analysis that a two level array is probably the right data structure for this and likely not less cache efficient than the hash table. Strange - it seems you gave only arguments against this analysis... And the worst memory consumption case considered by Patrick should be relatively unlikely. Anyway, such approach, that most users do something this (reasonable) way, doesn't look like good programming practice. I wonder, why not try, at least for a while, to do this a compile (menuconfig) option with a comment: recommended for a large number of classes. After hash optimization and some testing, final decisions could be made. Regards, Jarek P. - 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] HTB O(1) class lookup
On Monday 05 February 2007 11:16, Jarek Poplawski wrote: Strange - it seems you gave only arguments against this analysis... For a naturally clustered key space (as is common in this case) the two level structure is likely more cache efficient than a generic hash function. That is because the hash will likely spread out the natural clusters and then require more cache lines to access them because there will be less sharing. Ok in theory a very tuned for this case hash function might have similar properties, but normally people don't put that much care into designing hashes and just use some generic one. And the worst memory consumption case considered by Patrick should be relatively unlikely. Anyway, such approach, that most users do something this (reasonable) way, doesn't look like good programming practice. In the unlikely worst case they will get half a MB of tables. Hardly a show stopper. I wonder, why not try, at least for a while, to do this a compile (menuconfig) option with a comment: recommended for a large number of classes. After hash optimization and some testing, final decisions could be made. There are already far too many obscure CONFIGs. Don't add more. -Andi - 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] HTB O(1) class lookup
Andi Kleen schrieb: On Monday 05 February 2007 11:16, Jarek Poplawski wrote: I wonder, why not try, at least for a while, to do this a compile (menuconfig) option with a comment: recommended for a large number of classes. After hash optimization and some testing, final decisions could be made. There are already far too many obscure CONFIGs. Don't add more. And for people concerned about memory usage: There is always CONFIG_SMALL for such decisions. Maybe one can limit worst case and average memory usage based on this config. The algorithm should stay the same. Regards Ingo Oeser - 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 3/4] skge: WOL support
Hi Stephen,
just a nitpick.
Stephen Hemminger schrieb:
--- skge.orig/drivers/net/skge.c
+++ skge/drivers/net/skge.c
@@ -132,18 +132,93 @@ static void skge_get_regs(struct net_dev
}
/* Wake on Lan only supported on Yukon chips with rev 1 or above */
-static int wol_supported(const struct skge_hw *hw)
+static u32 wol_supported(const struct skge_hw *hw)
{
- return !((hw-chip_id == CHIP_ID_GENESIS ||
- (hw-chip_id == CHIP_ID_YUKON hw-chip_rev == 0)));
+ if (hw-chip_id == CHIP_ID_YUKON hw-chip_rev != 0)
+ return WAKE_MAGIC | WAKE_PHY;
+ else
+ return 0;
+}
You can delete that comment, if you write exactly, what the comment says:
if (hw-chip_id == CHIP_ID_YUKON hw-chip_rev = 1)
return WAKE_MAGIC | WAKE_PHY;
else
return 0;
Regards
Ingo Oeser
-
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
[RESEND PATCH 0/7] [S390]: Introduction of AF_IUCV sockets support
Hello, seems that Patch 1/7 is lost and did not make its way to the mailing list :-( That's the reason why I resend the whole patch set again. Here we go ... The Inter-User Communication Vehicle (IUCV) is a z/VM communication facility that enables a program running in one virtual machine to communicate with another virtual machine, or with a control program, or even with itself. The communication takes place over a predefined linkage called a path. AF_IUCV provides a complete socket interface for socket communication from Linux to Linux (running on z/VM) or Linux on VM to CMS. The AF_IUCV Protocol Support will use IUCV to provide AF_IUCV protocol support for communication with z/VM back-end services. It also can connect socket applications operating in Linux kernels running on different VM user IDs, or to connect a Linux application to another socket application running in a VM guest. AF_IUCV is using a different addressing scheme and therefore there is no chance to use existing drivers like netiucv for such functionality. The patch set consists of following patches: [1/7] [S390]: Rewrite of the IUCV base code, part 1 [2/7] [S390]: Rewrite of the IUCV base code, part 2 [3/7] [S390]: Adapt monreader driver to new IUCV API [4/7] [S390]: Adapt vmlogrdr driver to new IUCV API [5/7] [S390]: Adapt netiucv driver to new IUCV API [6/7] [S390]: Adapt special message interface to new IUCV API [7/7] [S390]: Add AF_IUCV socket support Basically it will remove the old IUCV base code from drivers/s390/net, adds the new rewritten one to net/iucv. Then all iucv based device drivers like monreader, vmlogrdr, netiucv and special message interface will be adapted to the new IUCV API. The last patch then adds the AF_IUCV socket support residing in net/iucv either. I am asking for integration now and of course code review comments and suggestions are very appreciated . Thank you very much Frank - 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 6/7] [S390]: Adapt special message interface to new IUCV API
From: Martin Schwidefsky [EMAIL PROTECTED]
Adapt special message interface to new IUCV API
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/net/smsgiucv.c | 147 ++-
1 files changed, 74 insertions(+), 73 deletions(-)
diff --git a/drivers/s390/net/smsgiucv.c b/drivers/s390/net/smsgiucv.c
index b8179c2..3ccca58 100644
--- a/drivers/s390/net/smsgiucv.c
+++ b/drivers/s390/net/smsgiucv.c
@@ -1,7 +1,7 @@
/*
* IUCV special message driver
*
- * Copyright (C) 2003 IBM Deutschland Entwicklung GmbH, IBM Corporation
+ * Copyright 2003 IBM Deutschland Entwicklung GmbH, IBM Corporation
* Author(s): Martin Schwidefsky ([EMAIL PROTECTED])
*
* This program is free software; you can redistribute it and/or modify
@@ -23,10 +23,10 @@ #include linux/module.h
#include linux/init.h
#include linux/errno.h
#include linux/device.h
+#include net/iucv/iucv.h
#include asm/cpcmd.h
#include asm/ebcdic.h
-
-#include iucv.h
+#include smsgiucv.h
struct smsg_callback {
struct list_head list;
@@ -39,38 +39,46 @@ MODULE_AUTHOR
((C) 2003 IBM Corporation by Martin Schwidefsky ([EMAIL PROTECTED]));
MODULE_DESCRIPTION (Linux for S/390 IUCV special message driver);
-static iucv_handle_t smsg_handle;
-static unsigned short smsg_pathid;
+static struct iucv_path *smsg_path;
+
static DEFINE_SPINLOCK(smsg_list_lock);
static struct list_head smsg_list = LIST_HEAD_INIT(smsg_list);
-static void
-smsg_connection_complete(iucv_ConnectionComplete *eib, void *pgm_data)
+static int smsg_path_pending(struct iucv_path *, u8 ipvmid[8], u8 ipuser[16]);
+static void smsg_message_pending(struct iucv_path *, struct iucv_message *);
+
+static struct iucv_handler smsg_handler = {
+ .path_pending= smsg_path_pending,
+ .message_pending = smsg_message_pending,
+};
+
+static int smsg_path_pending(struct iucv_path *path, u8 ipvmid[8],
+u8 ipuser[16])
{
+ if (strncmp(ipvmid, *MSG, sizeof(ipvmid)) != 0)
+ return -EINVAL;
+ /* Path pending from *MSG. */
+ return iucv_path_accept(path, smsg_handler, SMSGIUCV, NULL);
}
-
-static void
-smsg_message_pending(iucv_MessagePending *eib, void *pgm_data)
+static void smsg_message_pending(struct iucv_path *path,
+struct iucv_message *msg)
{
struct smsg_callback *cb;
- unsigned char *msg;
+ unsigned char *buffer;
unsigned char sender[9];
- unsigned short len;
int rc, i;
- len = eib-ln1msg2.ipbfln1f;
- msg = kmalloc(len + 1, GFP_ATOMIC|GFP_DMA);
- if (!msg) {
- iucv_reject(eib-ippathid, eib-ipmsgid, eib-iptrgcls);
+ buffer = kmalloc(msg-length + 1, GFP_ATOMIC | GFP_DMA);
+ if (!buffer) {
+ iucv_message_reject(path, msg);
return;
}
- rc = iucv_receive(eib-ippathid, eib-ipmsgid, eib-iptrgcls,
- msg, len, NULL, NULL, NULL);
+ rc = iucv_message_receive(path, msg, 0, buffer, msg-length, NULL);
if (rc == 0) {
- msg[len] = 0;
- EBCASC(msg, len);
- memcpy(sender, msg, 8);
+ buffer[msg-length] = 0;
+ EBCASC(buffer, msg-length);
+ memcpy(sender, buffer, 8);
sender[8] = 0;
/* Remove trailing whitespace from the sender name. */
for (i = 7; i = 0; i--) {
@@ -80,27 +88,17 @@ smsg_message_pending(iucv_MessagePending
}
spin_lock(smsg_list_lock);
list_for_each_entry(cb, smsg_list, list)
- if (strncmp(msg + 8, cb-prefix, cb-len) == 0) {
- cb-callback(sender, msg + 8);
+ if (strncmp(buffer + 8, cb-prefix, cb-len) == 0) {
+ cb-callback(sender, buffer + 8);
break;
}
spin_unlock(smsg_list_lock);
}
- kfree(msg);
+ kfree(buffer);
}
-static iucv_interrupt_ops_t smsg_ops = {
- .ConnectionComplete = smsg_connection_complete,
- .MessagePending = smsg_message_pending,
-};
-
-static struct device_driver smsg_driver = {
- .name = SMSGIUCV,
- .bus = iucv_bus,
-};
-
-int
-smsg_register_callback(char *prefix, void (*callback)(char *from, char *str))
+int smsg_register_callback(char *prefix,
+ void (*callback)(char *from, char *str))
{
struct smsg_callback *cb;
@@ -110,18 +108,18 @@ smsg_register_callback(char *prefix, voi
cb-prefix = prefix;
cb-len = strlen(prefix);
cb-callback = callback;
- spin_lock(smsg_list_lock);
+ spin_lock_bh(smsg_list_lock);
list_add_tail(cb-list, smsg_list);
- spin_unlock(smsg_list_lock);
+
[PATCH 3/7] [S390]: Adapt monreader driver to new IUCV API
From: Martin Schwidefsky [EMAIL PROTECTED]
Adapt monreader character device driver to new IUCV API
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/char/monreader.c | 218 +++--
1 files changed, 101 insertions(+), 117 deletions(-)
diff --git a/drivers/s390/char/monreader.c b/drivers/s390/char/monreader.c
index a138b15..3a1a958 100644
--- a/drivers/s390/char/monreader.c
+++ b/drivers/s390/char/monreader.c
@@ -3,7 +3,7 @@
*
* Character device driver for reading z/VM *MONITOR service records.
*
- * Copyright (C) 2004 IBM Corporation, IBM Deutschland Entwicklung GmbH.
+ * Copyright 2004 IBM Corporation, IBM Deutschland Entwicklung GmbH.
*
* Author: Gerald Schaefer [EMAIL PROTECTED]
*/
@@ -22,7 +22,7 @@ #include asm/uaccess.h
#include asm/ebcdic.h
#include asm/extmem.h
#include linux/poll.h
-#include ../net/iucv.h
+#include net/iucv/iucv.h
//#define MON_DEBUG/* Debug messages on/off */
@@ -50,14 +50,13 @@ static char mon_dcss_name[9] = MONDCSS\
struct mon_msg {
u32 pos;
u32 mca_offset;
- iucv_MessagePending local_eib;
+ struct iucv_message msg;
char msglim_reached;
char replied_msglim;
};
struct mon_private {
- u16 pathid;
- iucv_handle_t iucv_handle;
+ struct iucv_path *path;
struct mon_msg *msg_array[MON_MSGLIM];
unsigned int write_index;
unsigned int read_index;
@@ -75,8 +74,6 @@ static unsigned long mon_dcss_end;
static DECLARE_WAIT_QUEUE_HEAD(mon_read_wait_queue);
static DECLARE_WAIT_QUEUE_HEAD(mon_conn_wait_queue);
-static u8 iucv_host[8] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
-
static u8 user_data_connect[16] = {
/* Version code, must be 0x01 for shared mode */
0x01,
@@ -100,8 +97,7 @@ static u8 user_data_sever[16] = {
* Create the 8 bytes EBCDIC DCSS segment name from
* an ASCII name, incl. padding
*/
-static inline void
-dcss_mkname(char *ascii_name, char *ebcdic_name)
+static inline void dcss_mkname(char *ascii_name, char *ebcdic_name)
{
int i;
@@ -119,8 +115,7 @@ dcss_mkname(char *ascii_name, char *ebcd
* print appropriate error message for segment_load()/segment_type()
* return code
*/
-static void
-mon_segment_warn(int rc, char* seg_name)
+static void mon_segment_warn(int rc, char* seg_name)
{
switch (rc) {
case -ENOENT:
@@ -166,44 +161,37 @@ mon_segment_warn(int rc, char* seg_name)
}
}
-static inline unsigned long
-mon_mca_start(struct mon_msg *monmsg)
+static inline unsigned long mon_mca_start(struct mon_msg *monmsg)
{
- return monmsg-local_eib.ln1msg1.iprmmsg1_u32;
+ return *(u32 *) monmsg-msg.rmmsg;
}
-static inline unsigned long
-mon_mca_end(struct mon_msg *monmsg)
+static inline unsigned long mon_mca_end(struct mon_msg *monmsg)
{
- return monmsg-local_eib.ln1msg2.ipbfln1f;
+ return *(u32 *) monmsg-msg.rmmsg[4];
}
-static inline u8
-mon_mca_type(struct mon_msg *monmsg, u8 index)
+static inline u8 mon_mca_type(struct mon_msg *monmsg, u8 index)
{
return *((u8 *) mon_mca_start(monmsg) + monmsg-mca_offset + index);
}
-static inline u32
-mon_mca_size(struct mon_msg *monmsg)
+static inline u32 mon_mca_size(struct mon_msg *monmsg)
{
return mon_mca_end(monmsg) - mon_mca_start(monmsg) + 1;
}
-static inline u32
-mon_rec_start(struct mon_msg *monmsg)
+static inline u32 mon_rec_start(struct mon_msg *monmsg)
{
return *((u32 *) (mon_mca_start(monmsg) + monmsg-mca_offset + 4));
}
-static inline u32
-mon_rec_end(struct mon_msg *monmsg)
+static inline u32 mon_rec_end(struct mon_msg *monmsg)
{
return *((u32 *) (mon_mca_start(monmsg) + monmsg-mca_offset + 8));
}
-static inline int
-mon_check_mca(struct mon_msg *monmsg)
+static inline int mon_check_mca(struct mon_msg *monmsg)
{
if ((mon_rec_end(monmsg) = mon_rec_start(monmsg)) ||
(mon_rec_start(monmsg) mon_dcss_start) ||
@@ -221,20 +209,17 @@ mon_check_mca(struct mon_msg *monmsg)
return 0;
}
-static inline int
-mon_send_reply(struct mon_msg *monmsg, struct mon_private *monpriv)
+static inline int mon_send_reply(struct mon_msg *monmsg,
+struct mon_private *monpriv)
{
- u8 prmmsg[8];
int rc;
P_DEBUG(read, REPLY: pathid = 0x%04X, msgid = 0x%08X, trgcls =
0x%08X\n\n,
- monmsg-local_eib.ippathid, monmsg-local_eib.ipmsgid,
- monmsg-local_eib.iptrgcls);
- rc = iucv_reply_prmmsg(monmsg-local_eib.ippathid,
- monmsg-local_eib.ipmsgid,
- monmsg-local_eib.iptrgcls,
- 0, prmmsg);
+ monpriv-path-pathid, monmsg-msg.id, monmsg-msg.class);
+
+ rc = iucv_message_reply(monpriv-path, monmsg-msg,
+
[PATCH 7/7] [S390]: Add AF_IUCV socket support
From: Jennifer Hunt[EMAIL PROTECTED]
This patch adds AF_IUCV socket support.
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
arch/s390/defconfig|1
include/linux/net.h|2
include/linux/socket.h |4
include/net/iucv/af_iucv.h | 106
net/iucv/Kconfig |8
net/iucv/Makefile |1
net/iucv/af_iucv.c | 1077
7 files changed, 1197 insertions(+), 2 deletions(-)
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index 56fe005..11a8049 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -178,6 +178,7 @@ # CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_NET_KEY=y
CONFIG_IUCV=m
+CONFIG_AFIUCV=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
diff --git a/include/linux/net.h b/include/linux/net.h
index f28d8a2..4db21e6 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -24,7 +24,7 @@ #include asm/socket.h
struct poll_table_struct;
struct inode;
-#define NPROTO 32 /* should be enough for now.. */
+#define NPROTO 33 /* should be enough for now.. */
#define SYS_SOCKET 1 /* sys_socket(2)*/
#define SYS_BIND 2 /* sys_bind(2) */
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 92cd38e..fcd35a2 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -187,7 +187,8 @@ #define AF_WANPIPE 25 /* Wanpipe API Soc
#define AF_LLC 26 /* Linux LLC*/
#define AF_TIPC30 /* TIPC sockets */
#define AF_BLUETOOTH 31 /* Bluetooth sockets*/
-#define AF_MAX 32 /* For now.. */
+#define AF_IUCV32 /* IUCV sockets */
+#define AF_MAX 33 /* For now.. */
/* Protocol families, same as address families. */
#define PF_UNSPEC AF_UNSPEC
@@ -220,6 +221,7 @@ #define PF_WANPIPE AF_WANPIPE
#define PF_LLC AF_LLC
#define PF_TIPCAF_TIPC
#define PF_BLUETOOTH AF_BLUETOOTH
+#define PF_IUCVAF_IUCV
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
diff --git a/include/net/iucv/af_iucv.h b/include/net/iucv/af_iucv.h
new file mode 100644
index 000..04d1abb
--- /dev/null
+++ b/include/net/iucv/af_iucv.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright 2006 IBM Corporation
+ * IUCV protocol stack for Linux on zSeries
+ * Version 1.0
+ * Author(s): Jennifer Hunt [EMAIL PROTECTED]
+ *
+ */
+
+#ifndef __AFIUCV_H
+#define __AFIUCV_H
+
+#include asm/types.h
+#include asm/byteorder.h
+#include linux/list.h
+#include linux/poll.h
+#include linux/socket.h
+
+#ifndef AF_IUCV
+#define AF_IUCV32
+#define PF_IUCVAF_IUCV
+#endif
+
+/* Connection and socket states */
+enum {
+ IUCV_CONNECTED = 1,
+ IUCV_OPEN,
+ IUCV_BOUND,
+ IUCV_LISTEN,
+ IUCV_SEVERED,
+ IUCV_DISCONN,
+ IUCV_CLOSED
+};
+
+#define IUCV_QUEUELEN_DEFAULT 65535
+#define IUCV_CONN_TIMEOUT (HZ * 40)
+#define IUCV_DISCONN_TIMEOUT (HZ * 2)
+#define IUCV_CONN_IDLE_TIMEOUT (HZ * 60)
+#define IUCV_BUFSIZE_DEFAULT 32768
+
+/* IUCV socket address */
+struct sockaddr_iucv {
+ sa_family_t siucv_family;
+ unsigned short siucv_port; /* Reserved */
+ unsigned intsiucv_addr; /* Reserved */
+ charsiucv_nodeid[8];/* Reserved */
+ charsiucv_user_id[8]; /* Guest User Id */
+ charsiucv_name[8]; /* Application Name */
+};
+
+
+/* Common socket structures and functions */
+
+#define iucv_sk(__sk) ((struct iucv_sock *) __sk)
+
+struct iucv_sock {
+ struct sock sk;
+ charsrc_user_id[8];
+ charsrc_name[8];
+ chardst_user_id[8];
+ chardst_name[8];
+ struct list_headaccept_q;
+ struct sock *parent;
+ struct iucv_path*path;
+ struct sk_buff_head send_skb_q;
+ unsigned intsend_tag;
+};
+
+struct iucv_sock_list {
+ struct hlist_head head;
+ rwlock_t lock;
+ atomic_t autobind_name;
+};
+
+static void iucv_sock_destruct(struct sock *sk);
+static void iucv_sock_cleanup_listen(struct sock *parent);
+static void iucv_sock_kill(struct sock *sk);
+static void iucv_sock_close(struct sock *sk);
+static int iucv_sock_create(struct socket *sock, int proto);
+static int iucv_sock_bind(struct socket *sock, struct sockaddr *addr,
+ int addr_len);
+static int iucv_sock_connect(struct socket *sock, struct sockaddr *addr,
+ int alen, int
[PATCH 4/7] [S390]: Adapt vmlogrdr driver to new IUCV API
From: Martin Schwidefsky [EMAIL PROTECTED]
Adapt vmlogrdr character device driver to new IUCV API
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/char/vmlogrdr.c | 284 +++---
1 files changed, 129 insertions(+), 155 deletions(-)
diff --git a/drivers/s390/char/vmlogrdr.c b/drivers/s390/char/vmlogrdr.c
index 6cb2304..8432a76 100644
--- a/drivers/s390/char/vmlogrdr.c
+++ b/drivers/s390/char/vmlogrdr.c
@@ -3,7 +3,7 @@
* character device driver for reading z/VM system service records
*
*
- * Copyright (C) 2004 IBM Corporation
+ * Copyright 2004 IBM Corporation
* character device driver for reading z/VM system service records,
* Version 1.0
* Author(s): Xenia Tkatschow [EMAIL PROTECTED]
@@ -21,7 +21,7 @@ #include asm/uaccess.h
#include asm/cpcmd.h
#include asm/debug.h
#include asm/ebcdic.h
-#include ../net/iucv.h
+#include net/iucv/iucv.h
#include linux/kmod.h
#include linux/cdev.h
#include linux/device.h
@@ -60,12 +60,11 @@ struct vmlogrdr_priv_t {
char system_service[8];
char internal_name[8];
char recording_name[8];
- u16 pathid;
+ struct iucv_path *path;
int connection_established;
int iucv_path_severed;
- iucv_MessagePending local_interrupt_buffer;
+ struct iucv_message local_interrupt_buffer;
atomic_t receive_ready;
- iucv_handle_t iucv_handle;
int minor_num;
char * buffer;
char * current_position;
@@ -97,40 +96,21 @@ static struct file_operations vmlogrdr_f
};
-static u8 iucvMagic[16] = {
- 0xF0, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40,
- 0xF0, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40, 0x40
-};
+static void vmlogrdr_iucv_path_complete(struct iucv_path *, u8 ipuser[16]);
+static void vmlogrdr_iucv_path_severed(struct iucv_path *, u8 ipuser[16]);
+static void vmlogrdr_iucv_message_pending(struct iucv_path *,
+ struct iucv_message *);
-static u8 mask[] = {
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
+static struct iucv_handler vmlogrdr_iucv_handler = {
+ .path_complete = vmlogrdr_iucv_path_complete,
+ .path_severed= vmlogrdr_iucv_path_severed,
+ .message_pending = vmlogrdr_iucv_message_pending,
};
-static u8 iucv_host[8] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
-
-
-static void
-vmlogrdr_iucv_ConnectionComplete(iucv_ConnectionComplete *eib, void *pgm_data);
-static void
-vmlogrdr_iucv_ConnectionSevered(iucv_ConnectionSevered *eib, void *pgm_data);
-static void
-vmlogrdr_iucv_MessagePending(iucv_MessagePending *eib, void *pgm_data);
-
-
-static iucv_interrupt_ops_t vmlogrdr_iucvops = {
- .ConnectionComplete = vmlogrdr_iucv_ConnectionComplete,
- .ConnectionSevered = vmlogrdr_iucv_ConnectionSevered,
- .MessagePending = vmlogrdr_iucv_MessagePending,
-};
-
-
-DECLARE_WAIT_QUEUE_HEAD(conn_wait_queue);
-DECLARE_WAIT_QUEUE_HEAD(read_wait_queue);
+static DECLARE_WAIT_QUEUE_HEAD(conn_wait_queue);
+static DECLARE_WAIT_QUEUE_HEAD(read_wait_queue);
/*
* pointer to system service private structure
@@ -177,28 +157,29 @@ static struct cdev *vmlogrdr_cdev = NUL
static int recording_class_AB;
-static void
-vmlogrdr_iucv_ConnectionComplete (iucv_ConnectionComplete * eib,
- void * pgm_data)
+static void vmlogrdr_iucv_path_complete(struct iucv_path *path, u8 ipuser[16])
{
- struct vmlogrdr_priv_t * logptr = pgm_data;
+ struct vmlogrdr_priv_t * logptr = path-private;
+
spin_lock(logptr-priv_lock);
logptr-connection_established = 1;
spin_unlock(logptr-priv_lock);
wake_up(conn_wait_queue);
- return;
}
-static void
-vmlogrdr_iucv_ConnectionSevered (iucv_ConnectionSevered * eib, void * pgm_data)
+static void vmlogrdr_iucv_path_severed(struct iucv_path *path, u8 ipuser[16])
{
- u8 reason = (u8) eib-ipuser[8];
- struct vmlogrdr_priv_t * logptr = pgm_data;
+ struct vmlogrdr_priv_t * logptr = path-private;
+ u8 reason = (u8) ipuser[8];
printk (KERN_ERR vmlogrdr: connection severed with
reason %i\n, reason);
+ iucv_path_sever(path, NULL);
+ kfree(path);
+ logptr-path = NULL;
+
spin_lock(logptr-priv_lock);
logptr-connection_established = 0;
logptr-iucv_path_severed = 1;
@@ -210,10 +191,10 @@ vmlogrdr_iucv_ConnectionSevered (iucv_Co
}
-static void
-vmlogrdr_iucv_MessagePending (iucv_MessagePending * eib, void * pgm_data)
+static void vmlogrdr_iucv_message_pending(struct iucv_path *path,
+ struct iucv_message *msg)
{
- struct vmlogrdr_priv_t * logptr =
RE: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Vlad Yasevich wrote on 25 January 2007 16:33: Can you try the attached patch and let me know if the problem is fixed. You can try reducing rto_max or path_max_retrans to get the failover to happen a little faster. Sorry for the delay - I've been on vacation for the past week. I've tried applying the patch. However, the failure still seems to happen in the original test system with a patched kernel. A look at the network traffic shows that the receiving side is still returning a gap-ack, the chunks in the gap are never resent and I don't see a FORWARD TSN for them. - Steve Hill Software Engineer Dialogic Fordingbridge, Hampshire, UK +44-1425-651392 [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] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Sat, Feb 03, 2007 at 08:43:49PM -0200, Marcelo Tosatti wrote: On Sat, Jan 27, 2007 at 02:53:07AM +0100, Arnd Bergmann wrote: On Tuesday 16 January 2007 19:55, Marcelo Tosatti wrote: +#define ENTER() dprintk(1, Enter: %s, %s:%i\n, __FUNCTION__, \ + __FILE__, __LINE__) +#define LEAVE() dprintk(1, Leave: %s, %s:%i\n, __FUNCTION__, \ + __FILE__, __LINE__) As mentioned, these should probably just be removed I disagree, entry/exit points have been shown to be useful in practice to identify firmware problems on field. I'm not too fond of the ENTER/LEAVE stuff either. But, I do sympathize that they _can_ be useful in certain circumstances/workflows/whatever. Is there an official party line on this documented somewhere (i.e. CodingStyle or elsewhere)? A quick search doesn't reveal one to me. 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
[PATCH] igmp: check add_grhead() return value
OK, now that we aren't seeing crashes which can be attributed to these NULL dereferences any longer. -- add_grhead() allocates memory with GFP_ATOMIC and in at least two places skb from it passed to skb_put() without checking. Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- net/ipv4/igmp.c |2 ++ net/ipv6/mcast.c |2 ++ 2 files changed, 4 insertions(+) --- a/net/ipv4/igmp.c +++ b/net/ipv4/igmp.c @@ -455,6 +455,8 @@ static struct sk_buff *add_grec(struct s skb = add_grhead(skb, pmc, type, pgr); first = 0; } + if (!skb) + return NULL; psrc = (__be32 *)skb_put(skb, sizeof(__be32)); *psrc = psf-sf_inaddr; scount++; stotal++; --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -1582,6 +1582,8 @@ static struct sk_buff *add_grec(struct s skb = add_grhead(skb, pmc, type, pgr); first = 0; } + if (!skb) + return NULL; psrc = (struct in6_addr *)skb_put(skb, sizeof(*psrc)); *psrc = psf-sf_addr; scount++; stotal++; - 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 1/7] too big ??
Hi, I realized that PATCH 1/7 of the AF_IUCV patch set is more than 100kb . Seems that this is too much for the mailing list. Well since I resent them some minutes ago I am wondering what would be the best way now to get PATCH 1/7 onto netdev . Shall I only send the splitted PATCH 1/7 or really another RESEND of the whole AF_IUCV patch set ? Thanks Frank - 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] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Monday 05 February 2007 15:01, John W. Linville wrote: I disagree, entry/exit points have been shown to be useful in practice to identify firmware problems on field. I'm not too fond of the ENTER/LEAVE stuff either. But, I do sympathize that they _can_ be useful in certain circumstances/workflows/whatever. Is there an official party line on this documented somewhere (i.e. CodingStyle or elsewhere)? A quick search doesn't reveal one to me. I don't think there is a formal rule. My personal opinion is that you should trace events that come from the hardware of from the user, if you trace at all, but never trace function call sequences that can be simply identified by knowing the source code. Arnd - 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 0/3] NetXen: 1G/10G Ethernet Driver updates
Hi All, I will be sending NetXen: 1G/10G Ethernet Driver updates with respect to netdev #master in the subsequent emails. We have incorporated the feedbacks we got for the patch on the ethtool support for user level tools, except for these: Jeff Garzik wrote: is it ok to return without re-locking flash? After flashing, we have to reboot the machine before we can use the newer flash. So re-locking is not necessary. Also its not possible to detect the end of flashing process, so as to lock the flash after that. netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 0); - udelay(100);/* prevent bursting on CRB */ + udelay(70); /* prevent bursting on CRB */ Jeff Garzik wrote: why? This is only to reduce the flashing time. Thanks, --Amit ~ - 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] d80211: respect extra_tx_headroom
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rU3 dscape/net/d80211/ieee80211.c dscape.hdr/net/d80211/ieee80211.c
--- dscape/net/d80211/ieee80211.c 2007-02-05 16:20:04.0 +0100
+++ dscape.hdr/net/d80211/ieee80211.c 2007-02-05 16:24:01.0 +0100
@@ -472,10 +472,9 @@
/* reserve enough extra head and tail room for possible
* encryption */
-#define IEEE80211_ENCRYPT_HEADROOM 8
-#define IEEE80211_ENCRYPT_TAILROOM 12
frag = frags[i] =
- dev_alloc_skb(frag_threshold +
+ dev_alloc_skb(tx-local-hw.extra_tx_headroom +
+ frag_threshold +
IEEE80211_ENCRYPT_HEADROOM +
IEEE80211_ENCRYPT_TAILROOM);
if (!frag)
@@ -483,7 +482,8 @@
/* Make sure that all fragments use the same priority so
* that they end up using the same TX queue */
frag-priority = first-priority;
- skb_reserve(frag, IEEE80211_ENCRYPT_HEADROOM);
+ skb_reserve(frag, tx-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM);
fhdr = (struct ieee80211_hdr *) skb_put(frag, hdrlen);
memcpy(fhdr, first-data, hdrlen);
if (i == num_fragm - 2)
@@ -858,10 +858,13 @@
hdr_len = ieee80211_get_hdrlen(old_hdr-frame_control);
- tx-u.tx.rts_frame = dev_alloc_skb(hdr_len);
+ tx-u.tx.rts_frame = dev_alloc_skb(hdr_len +
+ tx-local-hw.extra_tx_headroom);
if (!tx-u.tx.rts_frame)
return TXRX_DROP;
+ skb_reserve(tx-u.tx.rts_frame, tx-local-hw.extra_tx_headroom);
+
new_hdr = (struct ieee80211_hdr*)skb_put(tx-u.tx.rts_frame, hdr_len);
memcpy(new_hdr, old_hdr, hdr_len);
@@ -1427,6 +1430,7 @@
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *odev = NULL;
struct ieee80211_sub_if_data *osdata;
+ int headroom;
int ret;
/*
@@ -1451,6 +1455,15 @@
}
osdata = IEEE80211_DEV_TO_SUB_IF(odev);
+ headroom = osdata-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM;
+ if (skb_headroom(skb) headroom) {
+ if (pskb_expand_head(skb, headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
control.ifindex = odev-ifindex;
control.type = osdata-type;
if (pkt_data-req_tx_status)
@@ -1680,6 +1693,14 @@
return 0;
}
+ if (skb_headroom(skb) sdata-local-hw.extra_tx_headroom) {
+ if (pskb_expand_head(skb,
+ sdata-local-hw.extra_tx_headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
hdr = (struct ieee80211_hdr *) skb-data;
fc = le16_to_cpu(hdr-frame_control);
@@ -1813,10 +1834,12 @@
bh_len = ap-beacon_head_len;
bt_len = ap-beacon_tail_len;
- skb = dev_alloc_skb(bh_len + bt_len + 256 /* maximum TIM len */);
+ skb = dev_alloc_skb(local-hw.extra_tx_headroom +
+ bh_len + bt_len + 256 /* maximum TIM len */);
if (!skb)
return NULL;
+ skb_reserve(skb, local-hw.extra_tx_headroom);
memcpy(skb_put(skb, bh_len), b_head, bh_len);
if (hw-flags IEEE80211_HW_SOFTWARE_SEQUENCE)
diff -rU3 dscape/net/d80211/ieee80211_i.h dscape.hdr/net/d80211/ieee80211_i.h
--- dscape/net/d80211/ieee80211_i.h 2007-02-05 16:20:01.0 +0100
+++ dscape.hdr/net/d80211/ieee80211_i.h 2007-02-05 16:24:19.0 +0100
@@ -49,6 +49,9 @@
* frame can be up to about 2 kB long. */
#define TOTAL_MAX_TX_BUFFER 512
+/* Required encryption head and tailroom */
+#define IEEE80211_ENCRYPT_HEADROOM 8
+#define IEEE80211_ENCRYPT_TAILROOM 12
/* IEEE 802.11 (Ch. 9.5 Defragmentation) requires support for concurrent
* reception of at least three fragmented frames. This limit can be increased
diff -rU3 dscape/net/d80211/ieee80211_scan.c
dscape.hdr/net/d80211/ieee80211_scan.c
--- dscape/net/d80211/ieee80211_scan.c 2007-02-05 16:18:41.0 +0100
+++ dscape.hdr/net/d80211/ieee80211_scan.c 2007-02-05 16:24:49.0
+0100
@@ -280,7 +280,7 @@
{
struct ieee80211_hdr hdr;
u16 fc;
- int len = 10;
+ int len = 10 + local-hw.extra_tx_headroom;
struct rate_control_extra extra;
/* Only initialize passive scanning if the hardware supports it */
@@ -309,6 +309,7 @@
passive scan\n, local-mdev-name);
[PATCH 1/3] NetXen: Fixes for ppc architecture.
NetXen: Fixes for ppc architecture.
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
---
netxen_nic.h | 98 --
netxen_nic_hw.c | 31 -
netxen_nic_init.c | 16
netxen_nic_main.c |7 ++-
netxen_nic_niu.c |2 -
5 files changed, 89 insertions(+), 65 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 59324b1..d689476 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -246,6 +246,18 @@ #define _netxen_set_bits(config_word, st
(config_word) |= (((value) (start)) mask); \
}
+static inline u32 netxen_set_32bits(u32 config_word, int start,
+ int bits, u32 val)
+{
+ _netxen_set_bits(config_word, start, bits, val);
+ return config_word;
+}
+static inline u16 netxen_set_16bits(u16 config_word, int start,
+ int bits, u16 val)
+{
+ _netxen_set_bits(config_word, start, bits, val);
+ return config_word;
+}
#define netxen_set_msg_peg_id(config_word, val)\
_netxen_set_bits(config_word, 0, 2, val)
#define netxen_set_msg_privid(config_word) \
@@ -305,69 +317,77 @@ #define netxen_set_cmd_desc_port(cmd_des
((cmd_desc)-port_ctxid |= ((var) 0x0F))
#define netxen_set_cmd_desc_flags(cmd_desc, val) \
- _netxen_set_bits((cmd_desc)-flags_opcode, 0, 7, val)
+ (cmd_desc)-flags_opcode = cpu_to_le16( \
+ netxen_set_16bits(le16_to_cpu((cmd_desc)-flags_opcode), 0, 7, val))
+
#define netxen_set_cmd_desc_opcode(cmd_desc, val) \
- _netxen_set_bits((cmd_desc)-flags_opcode, 7, 6, val)
+ (cmd_desc)-flags_opcode = cpu_to_le16( \
+ netxen_set_16bits(le16_to_cpu((cmd_desc)-flags_opcode), 7, 6, val))
#define netxen_set_cmd_desc_num_of_buff(cmd_desc, val) \
- _netxen_set_bits((cmd_desc)-num_of_buffers_total_length, 0, 8, val);
+ (cmd_desc)-num_of_buffers_total_length = cpu_to_le32( \
+ netxen_set_32bits(le32_to_cpu((cmd_desc)-num_of_buffers_total_length),
\
+ 0, 8, val))
+
#define netxen_set_cmd_desc_totallength(cmd_desc, val) \
- _netxen_set_bits((cmd_desc)-num_of_buffers_total_length, 8, 24, val);
+ (cmd_desc)-num_of_buffers_total_length = cpu_to_le32( \
+ netxen_set_32bits(le32_to_cpu((cmd_desc)-num_of_buffers_total_length),
\
+ 8, 24, val))
#define netxen_get_cmd_desc_opcode(cmd_desc) \
- (((cmd_desc)-flags_opcode 7) 0x003F)
+ ((le16_to_cpu((cmd_desc)-flags_opcode) 7) 0x003F)
#define netxen_get_cmd_desc_totallength(cmd_desc) \
- (((cmd_desc)-num_of_buffers_total_length 8) 0x0FF)
+ ((le32_to_cpu((cmd_desc)-num_of_buffers_total_length) 8)
0x0FF)
struct cmd_desc_type0 {
u8 tcp_hdr_offset; /* For LSO only */
u8 ip_hdr_offset; /* For LSO only */
/* Bit pattern: 0-6 flags, 7-12 opcode, 13-15 unused */
- u16 flags_opcode;
+ __le16 flags_opcode;
/* Bit pattern: 0-7 total number of segments,
8-31 Total size of the packet */
- u32 num_of_buffers_total_length;
+ __le32 num_of_buffers_total_length;
union {
struct {
- u32 addr_low_part2;
- u32 addr_high_part2;
+ __le32 addr_low_part2;
+ __le32 addr_high_part2;
};
- u64 addr_buffer2;
+ __le64 addr_buffer2;
};
- u16 reference_handle; /* changed to u16 to add mss */
- u16 mss;/* passed by NDIS_PACKET for LSO */
+ __le16 reference_handle;/* changed to u16 to add mss */
+ __le16 mss; /* passed by NDIS_PACKET for LSO */
/* Bit pattern 0-3 port, 0-3 ctx id */
u8 port_ctxid;
u8 total_hdr_length;/* LSO only : MAC+IP+TCP Hdr size */
- u16 conn_id;/* IPSec offoad only */
+ __le16 conn_id; /* IPSec offoad only */
union {
struct {
- u32 addr_low_part3;
- u32 addr_high_part3;
+ __le32 addr_low_part3;
+ __le32 addr_high_part3;
};
- u64 addr_buffer3;
+ __le64 addr_buffer3;
};
union {
struct {
- u32 addr_low_part1;
- u32 addr_high_part1;
+ __le32 addr_low_part1;
+ __le32 addr_high_part1;
};
- u64 addr_buffer1;
+ __le64 addr_buffer1;
};
- u16 buffer1_length;
- u16 buffer2_length;
- u16 buffer3_length;
- u16 buffer4_length;
+ __le16 buffer1_length;
+ __le16 buffer2_length;
+ __le16
[PATCH 3/3] NetXen: Added ethtool support for user level tools.
NetXen: Added ethtool support for user level firmware management utilities.
Signed-off-by: Amit S. Kale [EMAIL PROTECTED]
---
netxen_nic.h | 17 ++-
netxen_nic_ethtool.c | 96 +++---
netxen_nic_init.c| 267++-
3 files changed, 361 insertions(+), 19 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index d689476..741c64c 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -63,11 +63,14 @@ #include asm/pgtable.h
#include netxen_nic_hw.h
-#define NETXEN_NIC_BUILD_NO 2
#define _NETXEN_NIC_LINUX_MAJOR 3
#define _NETXEN_NIC_LINUX_MINOR 3
#define _NETXEN_NIC_LINUX_SUBVERSION 3
-#define NETXEN_NIC_LINUX_VERSIONID 3.3.3 - NETXEN_NIC_BUILD_NO
+#define NETXEN_NIC_LINUX_VERSIONID 3.3.3
+
+#define NUM_FLASH_SECTORS (64)
+#define FLASH_SECTOR_SIZE (64 * 1024)
+#define FLASH_TOTAL_SIZE (NUM_FLASH_SECTORS * FLASH_SECTOR_SIZE)
#define RCV_DESC_RINGSIZE \
(sizeof(struct rcv_desc) * adapter-max_rx_desc_count)
@@ -85,6 +88,7 @@ #define NETXEN_NETDEV_STATUS 0x1
#define NETXEN_RCV_PRODUCER_OFFSET 0
#define NETXEN_RCV_PEG_DB_ID 2
#define NETXEN_HOST_DUMMY_DMA_SIZE 1024
+#define FLASH_SUCCESS 0
#define ADDR_IN_WINDOW1(off) \
((off NETXEN_CRB_PCIX_HOST2) (off NETXEN_CRB_MAX)) ? 1 : 0
@@ -1054,6 +1058,15 @@ void netxen_phantom_init(struct netxen_a
void netxen_load_firmware(struct netxen_adapter *adapter);
int netxen_pinit_from_rom(struct netxen_adapter *adapter, int verbose);
int netxen_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp);
+int netxen_rom_fast_read_words(struct netxen_adapter *adapter, int addr,
+ u8 *bytes, size_t size);
+int netxen_rom_fast_write_words(struct netxen_adapter *adapter, int addr,
+ u8 *bytes, size_t size);
+int netxen_flash_unlock(struct netxen_adapter *adapter);
+int netxen_backup_crbinit(struct netxen_adapter *adapter);
+int netxen_flash_erase_secondary(struct netxen_adapter *adapter);
+int netxen_flash_erase_primary(struct netxen_adapter *adapter);
+
int netxen_rom_fast_write(struct netxen_adapter *adapter, int addr, int data);
int netxen_rom_se(struct netxen_adapter *adapter, int addr);
int netxen_do_rom_se(struct netxen_adapter *adapter, int addr);
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index 3404461..aa96140 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -32,6 +32,7 @@
*/
#include linux/types.h
+#include linux/delay.h
#include asm/uaccess.h
#include linux/pci.h
#include asm/io.h
@@ -94,17 +95,7 @@ #define NETXEN_MAX_EEPROM_LEN 1024
static int netxen_nic_get_eeprom_len(struct net_device *dev)
{
- struct netxen_port *port = netdev_priv(dev);
- struct netxen_adapter *adapter = port-adapter;
- int n;
-
- if ((netxen_rom_fast_read(adapter, 0, n) == 0)
-(n NETXEN_ROM_ROUNDUP)) {
- n = ~NETXEN_ROM_ROUNDUP;
- if (n NETXEN_MAX_EEPROM_LEN)
- return n;
- }
- return 0;
+ return FLASH_TOTAL_SIZE;
}
static void
@@ -440,18 +431,92 @@ netxen_nic_get_eeprom(struct net_device
struct netxen_port *port = netdev_priv(dev);
struct netxen_adapter *adapter = port-adapter;
int offset;
+ int ret;
if (eeprom-len == 0)
return -EINVAL;
eeprom-magic = (port-pdev)-vendor | ((port-pdev)-device 16);
- for (offset = 0; offset eeprom-len; offset++)
- if (netxen_rom_fast_read
- (adapter, (8 * offset) + 8, (int *)eeprom-data) == -1)
- return -EIO;
+ offset = eeprom-offset;
+
+ ret = netxen_rom_fast_read_words(adapter, offset, bytes,
+ eeprom-len);
+ if (ret 0)
+ return ret;
+
return 0;
}
+static int
+netxen_nic_set_eeprom(struct net_device *dev, struct ethtool_eeprom *eeprom,
+ u8 * bytes)
+{
+ struct netxen_port *port = netdev_priv(dev);
+ struct netxen_adapter *adapter = port-adapter;
+ int offset = eeprom-offset;
+ static int flash_start;
+ static int ready_to_flash;
+ int ret;
+
+ if (flash_start == 0) {
+ ret = netxen_flash_unlock(adapter);
+ if (ret 0) {
+ printk(KERN_ERR %s: Flash unlock failed.\n,
+ netxen_nic_driver_name);
+ return ret;
+ }
+ printk(KERN_INFO %s: flash unlocked. \n,
+ netxen_nic_driver_name);
+ ret = netxen_flash_erase_secondary(adapter);
+ if (ret != FLASH_SUCCESS) {
+
[PATCH 2.6.21-rc1] ehea: Fixed error recovery
Error recovery for QP errors: Reset QPs and dump error information
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c |8 +++-
drivers/net/ehea/ehea_phyp.c | 10 ++
drivers/net/ehea/ehea_phyp.h |3 +++
drivers/net/ehea/ehea_qmr.c | 42 ++
drivers/net/ehea/ehea_qmr.h |5 +
6 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 272e1ec..42295d6 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@ #include asm/abs_addr.h
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0045
+#define DRV_VERSIONEHEA_0046
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9de2d38..1ef3846 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -76,7 +76,7 @@ void ehea_dump(void *adr, int len, char
int x;
unsigned char *deb = adr;
for (x = 0; x len; x += 16) {
- printk(DRV_NAME %s adr=%p ofs=%04x %016lx %016lx\n, msg,
+ printk(DRV_NAME %s adr=%p ofs=%04x %016lx %016lx\n, msg,
deb, x, *((u64*)deb[0]), *((u64*)deb[8]));
deb += 16;
}
@@ -555,6 +555,7 @@ static irqreturn_t ehea_qp_aff_irq_handl
{
struct ehea_port *port = param;
struct ehea_eqe *eqe;
+ struct ehea_qp *qp;
u32 qp_token;
eqe = ehea_poll_eq(port-qp_eq);
@@ -563,9 +564,14 @@ static irqreturn_t ehea_qp_aff_irq_handl
qp_token = EHEA_BMASK_GET(EHEA_EQE_QP_TOKEN, eqe-entry);
ehea_error(QP aff_err: entry=0x%lx, token=0x%x,
eqe-entry, qp_token);
+
+ qp = port-port_res[qp_token].qp;
+ ehea_error_data(port-adapter, qp-fw_handle);
eqe = ehea_poll_eq(port-qp_eq);
}
+ queue_work(port-adapter-ehea_wq, port-reset_task);
+
return IRQ_HANDLED;
}
diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c
index 37716e0..bc3c005 100644
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -612,3 +612,13 @@ u64 ehea_h_reset_events(const u64 adapte
event_mask, /* R6 */
0, 0, 0, 0); /* R7-R12 */
}
+
+u64 ehea_h_error_data(const u64 adapter_handle, const u64 ressource_handle,
+ void *rblock)
+{
+ return ehea_plpar_hcall_norets(H_ERROR_DATA,
+ adapter_handle, /* R4 */
+ ressource_handle,/* R5 */
+ virt_to_abs(rblock), /* R6 */
+ 0, 0, 0, 0); /* R7-R12 */
+}
diff --git a/drivers/net/ehea/ehea_phyp.h b/drivers/net/ehea/ehea_phyp.h
index 919f94b..90acddb 100644
--- a/drivers/net/ehea/ehea_phyp.h
+++ b/drivers/net/ehea/ehea_phyp.h
@@ -454,4 +454,7 @@ u64 ehea_h_reg_dereg_bcmc(const u64 adap
u64 ehea_h_reset_events(const u64 adapter_handle, const u64 neq_handle,
const u64 event_mask);
+u64 ehea_h_error_data(const u64 adapter_handle, const u64 ressource_handle,
+ void *rblock);
+
#endif /* __EHEA_PHYP_H__ */
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index f143e13..96ff3b6 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -486,6 +486,7 @@ int ehea_destroy_qp(struct ehea_qp *qp)
if (!qp)
return 0;
+ ehea_h_disable_and_get_hea(qp-adapter-handle, qp-fw_handle);
hret = ehea_h_free_resource(qp-adapter-handle, qp-fw_handle);
if (hret != H_SUCCESS) {
ehea_error(destroy_qp failed);
@@ -581,4 +582,45 @@ out:
return ret;
}
+void print_error_data(u64 *data)
+{
+ int length;
+ u64 type = EHEA_BMASK_GET(ERROR_DATA_TYPE, data[2]);
+ u64 resource = data[1];
+
+ length = EHEA_BMASK_GET(ERROR_DATA_LENGTH, data[0]);
+
+ if (length EHEA_PAGESIZE)
+ length = EHEA_PAGESIZE;
+
+ if (type == 0x8) /* Queue Pair */
+ ehea_error(QP (resource=%lX) state: AER=0x%lX, AERR=0x%lX,
+ port=%lX, resource, data[6], data[12], data[22]);
+
+ ehea_dump(data, length, error data);
+}
+
+void ehea_error_data(struct ehea_adapter *adapter, u64 res_handle)
+{
+ unsigned long ret;
+ u64 *rblock;
+
+ rblock = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!rblock) {
+ ehea_error(Cannot allocate rblock memory.);
+ return;
+ }
+ ret = ehea_h_error_data(adapter-handle,
+
Re: [take35 0/10] kevent: Generic event handling mechanism.
On Thu, Feb 01, 2007 at 01:12:30PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: Generic event handling mechanism. 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 ring buffer or using usual syscalls. 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). Homepage: http://tservice.net.ru/~s0mbre/old/?section=projectsitem=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent Consider for inclusion. P.S. If you want to be removed from Cc: list just drop me a mail. Changes from 'take34' patchset: * Ported to the 2.6.20-rc7 (9be5b038b1c9d1927c367bf91683458e10d5d4eb) tree. Is there some progress? Some things to be implemented, described or discussed? Thank you. -- 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: when having to acquire an SA, ipsec drops the packet
On Sun, 4 Feb 2007, David Miller wrote: Something like this (untested) on the ipv4 side, for example: Looks like it should work. Will do some testing. -- 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: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Steve Hill wrote: Vlad Yasevich wrote on 25 January 2007 16:33: Can you try the attached patch and let me know if the problem is fixed. You can try reducing rto_max or path_max_retrans to get the failover to happen a little faster. Sorry for the delay - I've been on vacation for the past week. I've tried applying the patch. However, the failure still seems to happen in the original test system with a patched kernel. A look at the network traffic shows that the receiving side is still returning a gap-ack, the chunks in the gap are never resent and I don't see a FORWARD TSN for them. Once you start simulating the network failure, how long do you wait? If you have not changed rto_max and path_max_retrans, you can end up waiting quite a while for the full path switchover. This will also severely slow down your retransmissions... Try reducing /proc/sys/net/sctp/rto_max to say 6000ms (6 seconds). It defaults to (6 ms or 1 minute). That reduction means that the retransmit timeout will max out at 6 seconds. The problem is that you will not see the FORWARD TSN on the alternate path until the original path is marked down. That requires us to exceed the path_max_retrans counter (/proc/sys/net/sctp/path_max_retrans). This means that you will see the gap grow until a time when the rto exceeds the data expiry time. At this pint, you will not see any new data sent, since it will expire before being sent. So, it will look to you like nothing is happening. The gap will be closed once the FWD-TSN is transmitted over the alternate transport. -vlad - Steve Hill Software Engineer Dialogic Fordingbridge, Hampshire, UK +44-1425-651392 [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Lksctp-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lksctp-developers - 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: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Hi Steve Steve Hill wrote: Vlad Yasevich wrote on 05 February 2007 16:39: Once you start simulating the network failure, how long do you wait? If you have not changed rto_max and path_max_retrans, you can end up waiting quite a while for the full path switchover. This will also severely slow down your retransmissions... I'm waiting several minutes, and I'm using setsockopt() to set the timeouts fairly low: srto_initial = 1000ms srto_min = 200ms srto_max = 1400ms spp_pathmaxrxt = 2 spp_hbinterval = 1000ms Ok, thanks for the info. Two more questions: 1. What did you set the sinfo_timetolive to? 2. What specific netfilter rule to do use to simulate network outage? I was using '-t filter -A INPUT -i eth0 -p sctp -j DROP' Just trying to get more info to simulate this. My prior attempts recovered quickly with my patch. Thanks -vlad The network's round trip time (indicated by ping) is on the order of 0.25ms. - Steve Hill Software Engineer Dialogic Fordingbridge, Hampshire, UK +44-1425-651392 [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
Question on IOAT
Hi,
I looked into the IOAT code today as I'm trying to find out how to add support
for it to NFS. I ran into this piece of code, which waits for the DMA
operation to complete:
while (dma_async_memcpy_complete(tp-ucopy.dma_chan,
tp-ucopy.dma_cookie, done,
used) == DMA_IN_PROGRESS) {
/* do partial cleanup of sk_async_wait_queue */
while ((skb = skb_peek(sk-sk_async_wait_queue))
(dma_async_is_complete(skb-dma_cookie, done,
used) == DMA_SUCCESS)) {
__skb_dequeue(sk-sk_async_wait_queue);
kfree_skb(skb);
}
}
Nowhere in the dma_async_*complete functions can I see any code
that would sleep if the DMA is not yet complete. Am I missing something,
or are we really busy-waiting on the DMA engine? Wouldn't this kind of
defeat the purpose of freeing up the CPU from the chores of memcpying?
I also checked the code in ioatdma.c - I would have expected there to
be some kind of interrupt handler that kicks the upper layers when a
DMA operation completes. But the interrupt handler seems to be for
error reporting exclusively...
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
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: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Vlad Yasevich wrote on 05 February 2007 17:08:
1. What did you set the sinfo_timetolive to?
I presume you mean the timetolive parameter of sctp_sendmsg()? - this
was set to 1400ms (as previously mentioned, this was in error but it
does appear to have highlighted a problem with the stack itself).
2. What specific netfilter rule to do use to simulate
network outage?
I was using '-t filter -A INPUT -i eth0 -p sctp -j DROP'
iptables -A INPUT -d 192.168.2.0/24 -p sctp -j DROP
Just trying to get more info to simulate this. My prior attempts
recovered quickly with my patch.
I usually (but not always - sometimes it happens on the first attempt)
have to add and remove the iptables rule a few times while running
traffic over the association in order to reproduce the problem. I'm
running traffic at a rate of around 500 data chunks per second. Each
data chunk has a 44 octet payload.
The script I'm using to toggle the iptables rule is below:
--
#!/bin/sh
net=$1
flush() {
iptables -F
echo Flush
exit
}
trap flush EXIT
while true; do
iptables -A INPUT -d $net -p sctp -j DROP
echo set
sleep 5
iptables -F
echo flushed
sleep 5
done
--
- Steve Hill
Software Engineer
Dialogic
Fordingbridge, Hampshire, UK
+44-1425-651392
[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] sky2: flow control off
Here is what I saw. The transmitter on the Marvell Yukon II (88e8053) hangs when doing transmit flow control under load. There appears to be a bug or race condition that causes the MAC to stop transmitting data. There are two drivers for the Yukon II device on Linux. SysKonnect/Marvell has one called sk98lin it is downloadable from syskonnect.def, and I wrote one called sky2 that is part of the standard Linux kernel. This problem is reproducible with the sky2 driver only; the sk98lin driver has a watchdog routine that resets the hardware perodically, so it masks the problem. When the failure mode occurs only after several minutes of sustained activity and a situation where PAUSE frames would be received. In my testing I used server == 1000mbit === switch --- 100mbit --- client Server was Mac Mini (88E8053) running Linux 2.6.20-rc7 and client was a Sony Vaio (88e8036) laptop. The server was running NFS in kernel and client was doing a large copy. The server was using UDP to cause large amounts of 802 pause frames. The problem is not as reproducible with TCP tests because TCP congestion control avoids over running the switch. When failure occurs: * packets continue to be received and passed up the stack * GMAC status register is the pause state * transmit packets continue transferred by the DMA into the RAM buffer * when the the RAM buffer fills no more packets are DMA'd * when transmit queue in driver fills, it gets a watch dog timeout * switch appears to get confused and other ports hang as well. During development of the sky2 driver a similar problem was observed on receive if the receive DMA buffer was not 8 byte aligned. For performance reasons, Linux drivers usually offset the Rx buffer by 2 bytes so that the TCP/IP headers are aligned for faster CPU access. If the sky2 Rx buffer was offset, then the receiver DMA would occasionally hung. The workaround for receive was to align the receive buffer on a quad word boundary. This problem appears to be flow control related because after disabling flow control, no errors occurred in a 48 hour test run. There probably are other races and hangs that are related. I don't consider all the hangs eliminated yet. -- 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
Re: [PATCH 1/2] d80211: Add software RTS support
On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. 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
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Please, if you think you can find a way for us to do optimistic dad flags as
opt-in, rather than masked out, I'm all for it. Thanks!
This patch should apply on-top of yours, if you want I can send the
whole thing out too. I've only compile-tested it, so don't know if it
behaves the same as your original.
-Brian
Signed-off-by: Brian Haley [EMAIL PROTECTED]
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index c341371..ddac8b0 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -593,13 +593,8 @@ ipv6_add_addr(struct inet6_dev *idev, co
ifa-cstamp = ifa-tstamp = jiffies;
ifa-rt = rt;
-#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
- if (!idev-cnf.optimistic_dad || ipv6_devconf.forwarding ||
- (ifa-rt-rt6i_nexthop == NULL))
+ if (rt-rt6i_nexthop == NULL)
ifa-flags = ~IFA_F_OPTIMISTIC;
-#else
- ifa-flags = ~IFA_F_OPTIMISTIC;
-#endif
ifa-idev = idev;
in6_dev_hold(idev);
/* For caller */
@@ -776,6 +771,7 @@ static int ipv6_create_tempaddr(struct i
int tmp_plen;
int ret = 0;
int max_addresses;
+ u32 addr_flags;
write_lock(idev-lock);
if (ift) {
@@ -833,11 +829,17 @@ retry:
spin_unlock_bh(ifp-lock);
write_unlock(idev-lock);
+
+ addr_flags = IFA_F_TEMPORARY;
+ /* set in addrconf_prefix_rcv() */
+ if (ifp-flags IFA_F_OPTIMISTIC)
+ addr_flags |= IFA_F_OPTIMISTIC;
+
ift = !max_addresses ||
ipv6_count_addresses(idev) max_addresses ?
ipv6_add_addr(idev, addr, tmp_plen,
ipv6_addr_type(addr)IPV6_ADDR_SCOPE_MASK,
- IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL;
+ addr_flags) : NULL;
if (!ift || IS_ERR(ift)) {
in6_ifa_put(ifp);
in6_dev_put(idev);
@@ -1746,6 +1748,13 @@ ok:
if (ifp == NULL valid_lft) {
int max_addresses = in6_dev-cnf.max_addresses;
+ u32 addr_flags = 0;
+
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ if (in6_dev-cnf.optimistic_dad
+ !ipv6_devconf.forwarding)
+addr_flags = IFA_F_OPTIMISTIC;
+#endif
/* Do not allow to create too much of autoconfigured
* addresses; this would be too easy way to crash kernel.
@@ -1753,7 +1762,8 @@ ok:
if (!max_addresses ||
ipv6_count_addresses(in6_dev) max_addresses)
ifp = ipv6_add_addr(in6_dev, addr, pinfo-prefix_len,
- addr_typeIPV6_ADDR_SCOPE_MASK, 0);
+ addr_typeIPV6_ADDR_SCOPE_MASK,
+ addr_flags);
if (!ifp || IS_ERR(ifp)) {
in6_dev_put(in6_dev);
@@ -1762,10 +1772,6 @@ ok:
update_lft = create = 1;
ifp-cstamp = jiffies;
-#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
- if (ifp-idev-cnf.optimistic_dad)
-ifp-flags |= IFA_F_OPTIMISTIC;
-#endif
addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT);
}
@@ -2141,9 +2147,16 @@ static void init_loopback(struct net_dev
static void addrconf_add_linklocal(struct inet6_dev *idev, struct in6_addr *addr)
{
struct inet6_ifaddr * ifp;
+ u32 addr_flags = IFA_F_PERMANENT;
+
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ if (idev-cnf.optimistic_dad
+ !ipv6_devconf.forwarding)
+ addr_flags |= IFA_F_OPTIMISTIC;
+#endif
+
- ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK,
- IFA_F_PERMANENT|IFA_F_OPTIMISTIC);
+ ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, addr_flags);
if (!IS_ERR(ifp)) {
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
Re: [PATCH 2/2] d80211: Add software sequence support
On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote: --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100 +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0 +0100 @@ -405,6 +405,7 @@ int *supp_rates[NUM_IEEE80211_MODES]; int *basic_rates[NUM_IEEE80211_MODES]; + u16 seq_counter; Shouldn't this be per-BSS? 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
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 18:28, Jiri Benc wrote: On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. I sent a patchset that works with most (all?) hardware implementations, as it uses library calls. I also think that sending RTS in software is not going to work, as the timing can not be guaranteed. And timing is why we do it in the first place. If the HW is not capable of sending RTS frames, we should not try to emulate them in SW, as it might make the situation even worse by messing up the NAVs by wrong timing. -- 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 1/2] d80211: Add software RTS support
On Monday 05 February 2007 18:28, Jiri Benc wrote: On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). Well in case of rt2x00 (I am not sure which other drivers also need software RTS) the rts packet is just inserted inside the packet ring and is treated as a regular packet/fragment that has just been inserted by the driver. This patch just adds this additional packet just before the real packet, and in case the real packet could not be send the rts packet is stored in the ieee80211_tx_stored_packet structure to be send later. A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. In case of rt2x00 this would deliver more problems, especially since it will use a ring entry to send the rts frame and in case of rt2500usb and rt73usb it will need a sk_buff structure since it needs to pass it to the device (where the sk_buff will have some free tx_header_room for the descriptor.) Ivo - 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 1/2] d80211: Add software RTS support
On Monday 05 February 2007 18:43, Ivo van Doorn wrote: On Monday 05 February 2007 18:28, Jiri Benc wrote: On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). Well in case of rt2x00 (I am not sure which other drivers also need software RTS) the rts packet is just inserted inside the packet ring and is treated as a regular packet/fragment that has just been inserted by the driver. This patch just adds this additional packet just before the real packet, and in case the real packet could not be send the rts packet is stored in the ieee80211_tx_stored_packet structure to be send later. Ok, I see. But this is not going to work with bcm43xx. I also sent a fix for rt2x00 to work with my patchset. A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. In case of rt2x00 this would deliver more problems, especially since it will use a ring entry to send the rts frame and in case of rt2500usb and rt73usb it will need a sk_buff structure since it needs to pass it to the device (where the sk_buff will have some free tx_header_room for the descriptor.) I don't understand this. You need to put in into the ring either way. See my patch. -- 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 2/2] d80211: Add software sequence support
On Monday 05 February 2007 18:37, Jiri Benc wrote: On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote: --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100 +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0 +0100 @@ -405,6 +405,7 @@ int *supp_rates[NUM_IEEE80211_MODES]; int *basic_rates[NUM_IEEE80211_MODES]; + u16 seq_counter; Shouldn't this be per-BSS? Ok I'll try to get a per-BSS sequence counter working, I'll need some time to figure out how the per-BSS code is working. Ivo - 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 1/2] d80211: Add software RTS support
Hi, Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). Well in case of rt2x00 (I am not sure which other drivers also need software RTS) the rts packet is just inserted inside the packet ring and is treated as a regular packet/fragment that has just been inserted by the driver. This patch just adds this additional packet just before the real packet, and in case the real packet could not be send the rts packet is stored in the ieee80211_tx_stored_packet structure to be send later. Ok, I see. But this is not going to work with bcm43xx. I also sent a fix for rt2x00 to work with my patchset. Did you already send that patchset to the netdev list? Because I haven't seen a patch series about rts for d80211 yet. A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. In case of rt2x00 this would deliver more problems, especially since it will use a ring entry to send the rts frame and in case of rt2500usb and rt73usb it will need a sk_buff structure since it needs to pass it to the device (where the sk_buff will have some free tx_header_room for the descriptor.) I don't understand this. You need to put in into the ring either way. The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer but instead send the sk_buffer-data pointer to the USB layer. The solution as suggested by Jiri could be handled by making sure the rts allocated buffer will also have a tx header room as set in the tx_header_room field. But I am not sure if that would be a better solution than putting the rts packet in a sk_buffer that is being send out just before the real packet... For the timing problem you mentioned, another solution could be implemented, like already mentioned on the d80211 TODO list, the dscape stack should be able to send a signal to the driver that the last fragment was handed over, this signal can be used by the driver to start sending out the queued packets. This would at least work for rt2x00 where especially for PCI devices _no_ packets are being send until the TX ring has been kicked. Ivo - 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 1/2] d80211: Add software RTS support
On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: I also think that sending RTS in software is not going to work, as the timing can not be guaranteed. And timing is why we do it in the first place. If the HW is not capable of sending RTS frames, we should not try to emulate them in SW, as it might make the situation even worse by messing up the NAVs by wrong timing. That's not emulation in the software, it's just similar approach as with sending fragmented frames - you need (more or less) precise timing there as well and many cards still want them enqueued one-by-one. The firmware takes care of the precise timing. The same could apply to RTS frames (i. e. the firmware recognize them and doesn't send them before it has the next frame ready). 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
Re: Extensible hashing and RCU
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote: I noticed in an LCA talk mention that apprently extensible hashing with RCU access is an unsolved problem. Here's an idea for solving it. Yes, I have been playing around with the same idea for doing dynamic resizing of the TCP hashtable. Did a prototype toy implementation, and I have a half-finished patch which resizes the TCP hashtable at runtime. Hmmm, your mail may be the impetus to get me to finally finish this thing -- Arthur - 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 1/2] d80211: Add software RTS support
On Monday 05 February 2007 19:08, Jiri Benc wrote: On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: I also think that sending RTS in software is not going to work, as the timing can not be guaranteed. And timing is why we do it in the first place. If the HW is not capable of sending RTS frames, we should not try to emulate them in SW, as it might make the situation even worse by messing up the NAVs by wrong timing. That's not emulation in the software, it's just similar approach as with sending fragmented frames - you need (more or less) precise timing there as well and many cards still want them enqueued one-by-one. The firmware takes care of the precise timing. The same could apply to RTS frames (i. e. the firmware recognize them and doesn't send them before it has the next frame ready). And even for a dumb device like rt2x00 (no firmware for rt2400pci, rt2500pci or rt2500usb) it still has rts capabilities. It is just not capable of creating the frame, but the descriptor has a special field that should be set in case of a rts frame. So that would suggest that the device will treat the frame a little bit different than a regular frame. Ivo - 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 1/2] d80211: Add software RTS support
On Monday 05 February 2007 19:07, Ivo van Doorn wrote: Hi, Not all hardware are capable of generating their own RTS frames. This patch will add support for creating the RTS frame in software, when the driver requests this through the flag IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). Well in case of rt2x00 (I am not sure which other drivers also need software RTS) the rts packet is just inserted inside the packet ring and is treated as a regular packet/fragment that has just been inserted by the driver. This patch just adds this additional packet just before the real packet, and in case the real packet could not be send the rts packet is stored in the ieee80211_tx_stored_packet structure to be send later. Ok, I see. But this is not going to work with bcm43xx. I also sent a fix for rt2x00 to work with my patchset. Did you already send that patchset to the netdev list? Because I haven't seen a patch series about rts for d80211 yet. No, [EMAIL PROTECTED] The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer but instead send the sk_buffer-data pointer to the USB layer. The solution as suggested by Jiri could be handled by making sure the rts allocated buffer will also have a tx header room as set in the tx_header_room field. But I am not sure if that would be a better solution than putting the rts packet in a sk_buffer that is being send out just before the real packet... In my patchset you can put it into anything you like. I put it into an skb. -- 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: Question on IOAT
On 2/5/07, Olaf Kirch [EMAIL PROTECTED] wrote: Nowhere in the dma_async_*complete functions can I see any code that would sleep if the DMA is not yet complete. Am I missing something, or are we really busy-waiting on the DMA engine? Wouldn't this kind of defeat the purpose of freeing up the CPU from the chores of memcpying? It is busy waiting, but only because the TCP socket use initiates the DMA copies from the softirq and they have time to complete during the switch back to application context. Going back to sleep and creating more context switching made things worse. I'm working on seeing if completion interrupts could be used with a better thought out implementation, the performance implications aren't fully clear to me yet. For other uses, interrupts are probably desired. I also checked the code in ioatdma.c - I would have expected there to be some kind of interrupt handler that kicks the upper layers when a DMA operation completes. But the interrupt handler seems to be for error reporting exclusively... It's just not there now, but it can be added easily, it's one bit in the descriptor and a register read in the interrupt handler to see which channel(s) need attention. - Chris - 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 1/2] d80211: Add software RTS support
On Monday 05 February 2007 19:08, Jiri Benc wrote: On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: I also think that sending RTS in software is not going to work, as the timing can not be guaranteed. And timing is why we do it in the first place. If the HW is not capable of sending RTS frames, we should not try to emulate them in SW, as it might make the situation even worse by messing up the NAVs by wrong timing. That's not emulation in the software, it's just similar approach as with sending fragmented frames - you need (more or less) precise timing there as well and many cards still want them enqueued one-by-one. The firmware takes care of the precise timing. The same could apply to RTS frames (i. e. the firmware recognize them and doesn't send them before it has the next frame ready). Yeah, ok. I got the point. But still, this does not work with bcm43xx. :) -- 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] sky2: flow control off
Hi Stephen, First, thanks for this detailed explanation. On Mon, Feb 05, 2007 at 09:22:53AM -0800, Stephen Hemminger wrote: Here is what I saw. The transmitter on the Marvell Yukon II (88e8053) hangs when doing transmit flow control under load. There appears to be a bug or race condition that causes the MAC to stop transmitting data. There are two drivers for the Yukon II device on Linux. SysKonnect/Marvell has one called sk98lin it is downloadable from syskonnect.def, and I wrote one called sky2 that is part of the standard Linux kernel. This problem is reproducible with the sky2 driver only; the sk98lin driver has a watchdog routine that resets the hardware perodically, so it masks the problem. When the failure mode occurs only after several minutes of sustained activity and a situation where PAUSE frames would be received. In my testing I used server == 1000mbit === switch --- 100mbit --- client Server was Mac Mini (88E8053) running Linux 2.6.20-rc7 and client was a Sony Vaio (88e8036) laptop. The server was running NFS in kernel and client was doing a large copy. The server was using UDP to cause large amounts of 802 pause frames. The problem is not as reproducible with TCP tests because TCP congestion control avoids over running the switch. I encountered *exactly* this problem with a one-leg firewall equipped with a 88E8053 attached to a 1000 Mbps switch, itself hosting 100 Mbps stations, but with sk98lin (2.4). Running tcpdump on the firewall, I noticed duplicated and corrupted frames. I could only reproduce the duplicated and corrupted frames on a lab setup, not the Tx hangs, by sending high UDP traffic on the port to a 100 Mbps host. Sending to 1000 Mbps hosts never triggered the problem, hence my conclusions about flow control too. What I found interesting is that using a very old version of the sky2 driver which I had with me (sky2 v0.5), I could not trigger the problem anymore. But right now, I realize that this version of the driver did not support flow control yet, which might converge with your observations : # ethtool -i eth0 driver: sky2 version: 0.5 firmware-version: N/A bus-info: 01:00.0 # ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: off TX: off When failure occurs: * packets continue to be received and passed up the stack * GMAC status register is the pause state * transmit packets continue transferred by the DMA into the RAM buffer * when the the RAM buffer fills no more packets are DMA'd * when transmit queue in driver fills, it gets a watch dog timeout * switch appears to get confused and other ports hang as well. During development of the sky2 driver a similar problem was observed on receive if the receive DMA buffer was not 8 byte aligned. For performance reasons, Linux drivers usually offset the Rx buffer by 2 bytes so that the TCP/IP headers are aligned for faster CPU access. If the sky2 Rx buffer was offset, then the receiver DMA would occasionally hung. The workaround for receive was to align the receive buffer on a quad word boundary. This problem appears to be flow control related because after disabling flow control, no errors occurred in a 48 hour test run. No problem here with the old driver without flow control either. I can try to disable it right here on my setup with sk98lin, and test again. I did not know that the sk98lin had a watchdog, it could explain why sometimes the system entered a strange state (packets taking *seconds* to be forwarded). Anyway, I'm more and more convinced that there are hardware bugs. It is not normal at all that both the original syskonnect driver and your fresh new code show such similar problems ! There probably are other races and hangs that are related. I don't consider all the hangs eliminated yet. Well, at least you have a more maintainable driver than what was the previous one, so you will eventually manage to fix all problems ;-) Best regards, Willy - 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 1/2] d80211: Add software RTS support
Hi, Did you already send that patchset to the netdev list? Because I haven't seen a patch series about rts for d80211 yet. No, [EMAIL PROTECTED] Hmm, wasn't subscribed to that list yet. :( But now I am. :) The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer but instead send the sk_buffer-data pointer to the USB layer. The solution as suggested by Jiri could be handled by making sure the rts allocated buffer will also have a tx header room as set in the tx_header_room field. But I am not sure if that would be a better solution than putting the rts packet in a sk_buffer that is being send out just before the real packet... In my patchset you can put it into anything you like. I put it into an skb. Sounds good, I'll look that patchset up in the mailarchive. Ivo - 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] phy devices: use same arg types
From: Randy Dunlap [EMAIL PROTECTED]
sparse complains about differing types from prototype to
definition, so change the u32 to phy_interface_t:
drivers/net/phy/phy_device.c:140:19: error: symbol 'phy_connect' redeclared
with different type (originally declared at include/linux/phy.h:362) -
incompatible argument 5 (different signedness)
drivers/net/phy/phy_device.c:190:19: error: symbol 'phy_attach' redeclared with
different type (originally declared at include/linux/phy.h:360) - incompatible
argument 4 (different signedness)
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/net/phy/phy_device.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2620-pv.orig/drivers/net/phy/phy_device.c
+++ linux-2620-pv/drivers/net/phy/phy_device.c
@@ -139,7 +139,7 @@ void phy_prepare_link(struct phy_device
*/
struct phy_device * phy_connect(struct net_device *dev, const char *phy_id,
void (*handler)(struct net_device *), u32 flags,
- u32 interface)
+ phy_interface_t interface)
{
struct phy_device *phydev;
@@ -188,7 +188,7 @@ static int phy_compare_id(struct device
}
struct phy_device *phy_attach(struct net_device *dev,
- const char *phy_id, u32 flags, u32 interface)
+ const char *phy_id, u32 flags, phy_interface_t interface)
{
struct bus_type *bus = mdio_bus_type;
struct phy_device *phydev;
-
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/TOY]Extensible hashing and RCU
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
I'm assuming the table is a power of 2 in size with open chaining
for collisions. When the chains get too long, the table is doubled.
When the chains get too short, the table size is halved.
.
For purposes of discussion, I've attached a toy implementation
for doing dynamic resizing of a hashtable. It is useless, except
as a proof of concept.
I think this is very similar to what you are describing, no?
--
Arthur
#include linux/init.h
#include linux/module.h
#include linux/kernel.h
#include linux/vmalloc.h
#include linux/seqlock.h
#include linux/rcupdate.h
#include linux/netdevice.h
#include linux/proc_fs.h
#include linux/seq_file.h
#include asm/uaccess.h
#define _NETHASH_BUFSZ_ 16
#define MODULE_NAME nethash
#define _DEBUG_IT_
#ifdef _DEBUG_IT_
#define nprintk(x...) printk(KERN_ALERT x);
#else /* !_DEBUG_IT_ */
#define nprintk(x)
#endif /* _DEBUG_IT_ */
static struct proc_dir_entry *nh_proc_dir;
enum nh_type { NH_ENTRY, NH_HEAD };
struct nh_item {
/* the list head must be first followed by nh_type */
struct list_headnh_list;
enum nh_typenh_type;
};
struct nh_entry {
/* the list head must be first followed by nh_type */
struct list_headnh_list;
enum nh_typenh_type;
unsigned long data;
struct rcu_head rcu_head;
};
struct nh_head {
/* the list head must be first followed by nh_type */
struct list_headlist;
enum nh_typenh_type;
spinlock_t lock;
};
struct nh {
unsigned long nentries;
struct nh_head* hash;
struct rcu_head rcu_head;
};
static struct nh * __nh;
static DEFINE_SEQLOCK(nethash_seq);
static DEFINE_MUTEX(nethash_resize_mutex);
extern void * system_hash_alloc(unsigned long sz);
extern void system_hash_free(void * v, unsigned long sz);
/* XXX nh_dump() is for for debug only
* it must be called under rcu_read_lock() */
static int nh_dump(struct nh * nh, const char * debug_str);
static struct nh * get_nh(void);
static unsigned long nh_hashval(unsigned long data)
{
return data;
}
static void nh_entry_free(struct rcu_head * head)
{
struct nh_entry * entry = container_of(head, struct nh_entry, rcu_head);
nprintk(%s: freeing entry with data %lu\n, __FUNCTION__, entry-data);
kfree(entry);
}
static void nh_free(struct rcu_head * head)
{
struct nh * nh = container_of(head, struct nh, rcu_head);
unsigned long nentries = nh-nentries;
unsigned long size = sizeof (struct nh_head) * nentries;
nprintk(%s: freeing nh of size %lu\n, __FUNCTION__, size);
system_hash_free((void *)nh-hash, size);
nprintk(%s: freeing nh\n, __FUNCTION__);
kfree(nh);
}
/* called with head's spin_lock held */
static int __nh_insert(struct nh_entry * entry,
struct nh_head * head,
unsigned long nentries)
{
struct list_head * prev; /* insert entry after prev */
struct list_head * list;
nprintk(%s: linking entry with data %lu\n, __FUNCTION__,
entry-data);
/* find the appropriate spot to place entry */
prev = head-list;
if ( nh_hashval(entry-data) nentries ) {
list_for_each_rcu(list, head-list) {
struct nh_entry * tmp;
struct nh_item * item = (struct nh_item *)list;
if (item-nh_type != NH_ENTRY)
continue;
tmp = list_entry(list, struct nh_entry, nh_list);
prev = tmp-nh_list;
if (nh_hashval(tmp-data) nentries) {
/* put entry after nh */
break;
}
}
}
list_add_rcu(entry-nh_list, prev);
return 0;
}
/* called with head's lock held */
static void __nh_sort_chain(struct nh_head * head, unsigned long nentries)
{
struct list_head tmp, *list = head-list;
struct nh_entry* entry;
INIT_LIST_HEAD(tmp);
list_splice_init(list, tmp);
while ( !list_empty(tmp) ) {
struct list_head * first = tmp.next;
list_del(first);
entry = (struct nh_entry*)first;
__nh_insert(entry, head, nentries);
}
}
static void nh_fixup_grow(struct rcu_head * head)
{
struct nh * nh;
struct nh * oh = container_of(head, struct nh, rcu_head);
unsigned long i, oentries = oh-nentries;
rcu_read_lock();
nh = get_nh();
/* this is an rcu_callback - only the new nh is
* visible elsewhere
Re: [PATCH 1/3] d80211: Add control structure for beacontemplates
On Sat, 3 Feb 2007 17:25:18 +0100, Ivo van Doorn wrote: When rt2500usb and rt73usb will start using beacontemplates, they would also need a control structure to be passed along to correctly set the tx parameters. Good catch, thanks. This patch will add the allocation an initialization of a ieee80211_tx_control especially for the beacontemplate. This does require drivers that have the BEACON_TEMPLATE flag set to also free the control structure. (bcm43xx and p54 will be fixed in the next 2 patches) I would prefer using local variable for tx_control. Driver will be responsible for copying it somewhere if it needs to. I believe most drivers won't need to do that and it will prevent potential memory leaks as it's easy to forget to free the structure. 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
Re: when having to acquire an SA, ipsec drops the packet
On Mon, 5 Feb 2007, James Morris wrote: On Sun, 4 Feb 2007, David Miller wrote: Something like this (untested) on the ipv4 side, for example: Looks like it should work. Will do some testing. Appears to work well, with a slight delay on the first packet as expected. Tested with tcp, udp icmp. - 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: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Hi Steve
would you mind terribly, changing the -d $net to the
-i $net, and run the script with the interface name instead?
The reason is, that I see 2 different behaviors between blocking
by interface and blocking by IP and would like to find out if
you see it too.
When I block at the interface ( -i eth1 in my case), I see
the path failover happen and flow if resumed.
When I block at the ip address, I see the path failover
in an odd state. It looks like it happened, but the flow is
not resumed. Receive still doesn't get traffic. I think I might
be running a buggy receiver, but I am not 100% sure. In my
case, the sender if running 2.6.10-rc7 and receiver is running
Ubuntu 2.6.17-10.
I'll try running against a different receiver as well.
-vlad
Steve Hill wrote:
Vlad Yasevich wrote on 05 February 2007 17:08:
1. What did you set the sinfo_timetolive to?
I presume you mean the timetolive parameter of sctp_sendmsg()? - this
was set to 1400ms (as previously mentioned, this was in error but it
does appear to have highlighted a problem with the stack itself).
2. What specific netfilter rule to do use to simulate
network outage?
I was using '-t filter -A INPUT -i eth0 -p sctp -j DROP'
iptables -A INPUT -d 192.168.2.0/24 -p sctp -j DROP
Just trying to get more info to simulate this. My prior attempts
recovered quickly with my patch.
I usually (but not always - sometimes it happens on the first attempt)
have to add and remove the iptables rule a few times while running
traffic over the association in order to reproduce the problem. I'm
running traffic at a rate of around 500 data chunks per second. Each
data chunk has a 44 octet payload.
The script I'm using to toggle the iptables rule is below:
--
#!/bin/sh
net=$1
flush() {
iptables -F
echo Flush
exit
}
trap flush EXIT
while true; do
iptables -A INPUT -d $net -p sctp -j DROP
echo set
sleep 5
iptables -F
echo flushed
sleep 5
done
--
- Steve Hill
Software Engineer
Dialogic
Fordingbridge, Hampshire, UK
+44-1425-651392
[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: when having to acquire an SA, ipsec drops the packet
Something like this (untested) on the ipv4 side, for example:
diff --git a/include/net/route.h b/include/net/route.h
index 486e37a..a8af632 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
static inline int ip_route_connect(struct rtable **rp, __be32 dst,
__be32 src, u32 tos, int
oif, u8 protocol,
-__be16 sport, __be16 dport,
struct sock *sk)
+__be16 sport, __be16 dport,
struct sock *sk,
+int flags)
{
struct flowi fl = { .oif = oif,
.nl_u = { .ip4_u = { .daddr = dst,
@@ -168,7 +169,7 @@ static inline int ip_route_connect(struct
rtable **rp, __be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, fl);
- return ip_route_output_flow(rp, fl, sk, 0);
+ return ip_route_output_flow(rp, fl, sk, 1);
I guess you meant to pass the new flags param to ip_route_output_flow here?
}
-
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: when having to acquire an SA, ipsec drops the packet
On Thu, 2007-02-01 at 18:44 -0500, James Morris wrote: On Thu, 1 Feb 2007, Joy Latten wrote: IPsec returns EAGAIN when it needs to acquire an SA. There have been a thread or two about this... Has there been any info or progress in how best to fix this? James Morris presented some work/ideas, http://vger.kernel.org/jmorris_ipsec_sa_resolution_netconf2006.pdf The status of this is that I started refactoring some core IPv6 code (to bring it in line with the IPv4 code, e.g. create an ip6_route_connect() to match ip_route_connect(), and manage the packet queuing from there) and ran into some IPv6 bugs, and fixed those, but then ran out of time on the IPsec stuff. AFAIK, no other progress has been made. Generally, the problem is only seen when using the BSD userland, which does not proactively maintain SAs. Openswan does, and general IPsec users running it never see the problem, so it's not clear how high the priority is for fixing this really is in the general case. It's quite a lot of surgery on core networking to fix a problem which doesn't occur with the Linux tools, which seemingly most people use when they're not using proprietary and/or userland IPsec stacks. Non-kernel options include moving to Openswan (which I would hope is getting labeled networking support at some stage in any case), or have the BSD code proactively maintain SAs. Also, applications using TCP, and UDP applications with their own session management, will resend packets while the SA is being negotiated, which I've observed as typically completing before the first resend. I think one of the practical problems with this is that the apps are not expecting an EAGAIN and thus decide to crash. A quick dirty solution, which is what I think the BSD kernels do, is to still drop the packet but just not return an error to the app. The app then just sees a slight delay on the initial connection, as if a DNS lookup took a bit longer than usual. When using labeled xfrms (xfrms that contain a security context), there is potential for a greater amount of SAs to be created than when using regular xfrms. An SA may be created every time a different security context is encountered in a particular traffic stream. This could be many if each networking app has its own security context, making current behavior problematic. Do you have any examples of how many SAs would need to be created on a typical system? No, but I have to admit, just playing around with it gives me a scary idea. We have s0-s15 levels, each with c0-c1023 categories. Then I have noticed, each mapped selinux user is a different context... thus just an ssh session by a sysadm and a regular user (who is mapped to an selinux user) can cause 8 SAs to be generated, whereas with regular ipsec, we only need one... :-( Regards, Joy - 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: when having to acquire an SA, ipsec drops the packet
From: James Morris [EMAIL PROTECTED]
Date: Mon, 5 Feb 2007 15:34:39 -0500 (EST)
On Mon, 5 Feb 2007, James Morris wrote:
On Sun, 4 Feb 2007, David Miller wrote:
Something like this (untested) on the ipv4 side, for example:
Looks like it should work. Will do some testing.
Appears to work well, with a slight delay on the first packet as expected.
Tested with tcp, udp icmp.
Thanks for testing James.
Last night I put an updated version of my patch into the net-2.6.21
tree, taking care of the ipv6 bits as well. I attach it below
for completeness.
commit cbc77956da98305f0525c0b40257608f0c02a357
Author: David S. Miller [EMAIL PROTECTED]
Date: Sun Feb 4 21:21:59 2007 -0800
[IPV4/IPV6]: Always wait for IPSEC SA resolution in socket contexts.
Do this even for non-blocking sockets. This avoids the silly -EAGAIN
that applications can see now, even for non-blocking sockets in some
cases (f.e. connect()).
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/include/net/route.h b/include/net/route.h
index 486e37a..a8af632 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
static inline int ip_route_connect(struct rtable **rp, __be32 dst,
__be32 src, u32 tos, int oif, u8 protocol,
- __be16 sport, __be16 dport, struct sock *sk)
+ __be16 sport, __be16 dport, struct sock *sk,
+ int flags)
{
struct flowi fl = { .oif = oif,
.nl_u = { .ip4_u = { .daddr = dst,
@@ -168,7 +169,7 @@ static inline int ip_route_connect(struct rtable **rp,
__be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, fl);
- return ip_route_output_flow(rp, fl, sk, 0);
+ return ip_route_output_flow(rp, fl, sk, 1);
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 90c74b4..fa2c982 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -72,7 +72,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr,
int addr_len)
tmp = ip_route_connect(rt, nexthop, inet-saddr,
RT_CONN_FLAGS(sk), sk-sk_bound_dev_if,
IPPROTO_DCCP,
- inet-sport, usin-sin_port, sk);
+ inet-sport, usin-sin_port, sk, 1);
if (tmp 0)
return tmp;
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 6b91a9d..79140b3 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -1041,7 +1041,7 @@ static int dccp_v6_connect(struct sock *sk, struct
sockaddr *uaddr,
if (final_p)
ipv6_addr_copy(fl.fl6_dst, final_p);
- err = xfrm_lookup(dst, fl, sk, 0);
+ err = xfrm_lookup(dst, fl, sk, 1);
if (err 0)
goto failure;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 8640096..5750a2b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1007,7 +1007,7 @@ static int inet_sk_reselect_saddr(struct sock *sk)
RT_CONN_FLAGS(sk),
sk-sk_bound_dev_if,
sk-sk_protocol,
- inet-sport, inet-dport, sk);
+ inet-sport, inet-dport, sk, 0);
if (err)
return err;
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index 7b068a8..0072d79 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -49,7 +49,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
err = ip_route_connect(rt, usin-sin_addr.s_addr, saddr,
RT_CONN_FLAGS(sk), oif,
sk-sk_protocol,
- inet-sport, usin-sin_port, sk);
+ inet-sport, usin-sin_port, sk, 1);
if (err)
return err;
if ((rt-rt_flags RTCF_BROADCAST) !sock_flag(sk, SOCK_BROADCAST)) {
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index a6c63bb..fed6a1e 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -489,7 +489,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
}
security_sk_classify_flow(sk, fl);
- err = ip_route_output_flow(rt, fl, sk,
!(msg-msg_flagsMSG_DONTWAIT));
+ err = ip_route_output_flow(rt, fl, sk, 1);
}
if (err)
goto done;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f061ec5..383e4b5 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -191,7 +191,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr,
int addr_len)
tmp = ip_route_connect(rt, nexthop, inet-saddr,
Re: when having to acquire an SA, ipsec drops the packet
I can run some tests with this patch and report any results...
Regards,
Joy
On Sun, 2007-02-04 at 20:53 -0800, David Miller wrote:
From: James Morris [EMAIL PROTECTED]
Date: Thu, 1 Feb 2007 18:44:48 -0500 (EST)
A quick dirty solution, which is what I think the BSD kernels do, is to
still drop the packet but just not return an error to the app. The app
then just sees a slight delay on the initial connection, as if a DNS
lookup took a bit longer than usual.
I have another idea.
Why don't we just flat-out ignore MSG_DONTWAIT for the socket
visible cases, and handle connect() similarly?
I think this is (just barely) legal, will be simple to implement, and
will leave us with semantics that look like:
1) Sockets never see -EAGAIN due to SA resolution. They'll just
pause until the route is resolved, even with O_NONBLOCK or
MSG_DONTWAIT.
2) Asynchronous contexts such as ICMP replies and firewalling
will still see the -EAGAIN and simply drop packets.
These sleeps are legal because all of the socket paths involved
have to be able to do lock_socket() (at a minimum) anyways.
Something like this (untested) on the ipv4 side, for example:
diff --git a/include/net/route.h b/include/net/route.h
index 486e37a..a8af632 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
static inline int ip_route_connect(struct rtable **rp, __be32 dst,
__be32 src, u32 tos, int oif, u8 protocol,
-__be16 sport, __be16 dport, struct sock *sk)
+__be16 sport, __be16 dport, struct sock *sk,
+int flags)
{
struct flowi fl = { .oif = oif,
.nl_u = { .ip4_u = { .daddr = dst,
@@ -168,7 +169,7 @@ static inline int ip_route_connect(struct rtable **rp,
__be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, fl);
- return ip_route_output_flow(rp, fl, sk, 0);
+ return ip_route_output_flow(rp, fl, sk, 1);
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 90c74b4..fa2c982 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -72,7 +72,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
tmp = ip_route_connect(rt, nexthop, inet-saddr,
RT_CONN_FLAGS(sk), sk-sk_bound_dev_if,
IPPROTO_DCCP,
-inet-sport, usin-sin_port, sk);
+inet-sport, usin-sin_port, sk, 1);
if (tmp 0)
return tmp;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 8640096..5750a2b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1007,7 +1007,7 @@ static int inet_sk_reselect_saddr(struct sock *sk)
RT_CONN_FLAGS(sk),
sk-sk_bound_dev_if,
sk-sk_protocol,
-inet-sport, inet-dport, sk);
+inet-sport, inet-dport, sk, 0);
if (err)
return err;
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index 7b068a8..0072d79 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -49,7 +49,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
err = ip_route_connect(rt, usin-sin_addr.s_addr, saddr,
RT_CONN_FLAGS(sk), oif,
sk-sk_protocol,
-inet-sport, usin-sin_port, sk);
+inet-sport, usin-sin_port, sk, 1);
if (err)
return err;
if ((rt-rt_flags RTCF_BROADCAST) !sock_flag(sk, SOCK_BROADCAST)) {
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index a6c63bb..fed6a1e 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -489,7 +489,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock
*sk, struct msghdr *msg,
}
security_sk_classify_flow(sk, fl);
- err = ip_route_output_flow(rt, fl, sk,
!(msg-msg_flagsMSG_DONTWAIT));
+ err = ip_route_output_flow(rt, fl, sk, 1);
}
if (err)
goto done;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f061ec5..383e4b5 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -191,7 +191,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
tmp = ip_route_connect(rt, nexthop, inet-saddr,
RT_CONN_FLAGS(sk), sk-sk_bound_dev_if,
IPPROTO_TCP,
-inet-sport, usin-sin_port, sk);
+inet-sport, usin-sin_port, sk, 1);
if (tmp 0)
Re: when having to acquire an SA, ipsec drops the packet
From: Venkat Yekkirala [EMAIL PROTECTED]
Date: Mon, 5 Feb 2007 14:49:17 -0600
Something like this (untested) on the ipv4 side, for example:
diff --git a/include/net/route.h b/include/net/route.h
index 486e37a..a8af632 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
static inline int ip_route_connect(struct rtable **rp, __be32 dst,
__be32 src, u32 tos, int
oif, u8 protocol,
- __be16 sport, __be16 dport,
struct sock *sk)
+ __be16 sport, __be16 dport,
struct sock *sk,
+ int flags)
{
struct flowi fl = { .oif = oif,
.nl_u = { .ip4_u = { .daddr = dst,
@@ -168,7 +169,7 @@ static inline int ip_route_connect(struct
rtable **rp, __be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, fl);
- return ip_route_output_flow(rp, fl, sk, 0);
+ return ip_route_output_flow(rp, fl, sk, 1);
I guess you meant to pass the new flags param to ip_route_output_flow here?
Yes I did, thanks for catching that.
commit a6886040ae6b8c9bfc811bd0dbdb47cfa3f2db29
Author: David S. Miller [EMAIL PROTECTED]
Date: Mon Feb 5 13:11:42 2007 -0800
[IPV4]: Fix thinko in ip_route_connect().
The idea was the pass in the new flags parameter down
to ip_route_output_flow().
Noticed by Venkat Tekkirala.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/include/net/route.h b/include/net/route.h
index a8af632..1440bdb 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -169,7 +169,7 @@ static inline int ip_route_connect(struct rtable **rp,
__be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, fl);
- return ip_route_output_flow(rp, fl, sk, 1);
+ return ip_route_output_flow(rp, fl, sk, flags);
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
-
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: when having to acquire an SA, ipsec drops the packet
From: Joy Latten [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 14:53:39 -0600 I can run some tests with this patch and report any results... Please check out the two most recent patches I posted: 1) Updated core patch with ipv6 side added. 2) Fix for thinko noticed by Venkat. 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
netdev-2.6 rebased
I just rebased all branches of netdev-2.6.git, against current Linus TOT (v2.6.20). New maintainers (hi Jay) for example will want to re-clone rather than pulling the remote branch 'foo' into local branch 'foo'. 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
[PATCH] apply cwnd rules to FIN packets with data
This is especially important with TSO enabled. Currently, it will send a burst of up to 64k at the end of a connection, even when cwnd is much smaller than 64k. This patch still lets out empty FIN packets, but does not apply the special case to FINs carrying data. -John Apply cwnd rules to FIN packets that contain data. --- commit af319609eee705e0791a1a58c33b216e8d0254bf tree 5a1afcc506e09f5adfd74efb7e0cbbc82ec4d5b0 parent c0d4d573feed199b16094c072e7cb07afb01c598 author John Heffner [EMAIL PROTECTED] Mon, 05 Feb 2007 16:25:46 -0500 committer John Heffner [EMAIL PROTECTED] Mon, 05 Feb 2007 16:25:46 -0500 net/ipv4/tcp_output.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 975f447..215c99d 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -965,7 +965,7 @@ static inline unsigned int tcp_cwnd_test u32 in_flight, cwnd; /* Don't be strict about the congestion window for the final FIN. */ - if (TCP_SKB_CB(skb)-flags TCPCB_FLAG_FIN) + if ((TCP_SKB_CB(skb)-flags TCPCB_FLAG_FIN) skb-len == 0) return 1; in_flight = tcp_packets_in_flight(tp); @@ -1034,7 +1034,7 @@ static inline int tcp_nagle_test(struct /* Don't use the nagle rule for urgent data (or for the final FIN). */ if (tp-urg_mode || - (TCP_SKB_CB(skb)-flags TCPCB_FLAG_FIN)) + ((TCP_SKB_CB(skb)-flags TCPCB_FLAG_FIN) skb-len == 0)) return 1; if (!tcp_nagle_check(tp, skb, cur_mss, nonagle)) @@ -1156,9 +1156,6 @@ static int tcp_tso_should_defer(struct s const struct inet_connection_sock *icsk = inet_csk(sk); u32 send_win, cong_win, limit, in_flight; - if (TCP_SKB_CB(skb)-flags TCPCB_FLAG_FIN) - goto send_now; - if (icsk-icsk_ca_state != TCP_CA_Open) goto send_now;
Re: [PATCH] apply cwnd rules to FIN packets with data
From: John Heffner [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:58:18 -0500 This is especially important with TSO enabled. Currently, it will send a burst of up to 64k at the end of a connection, even when cwnd is much smaller than 64k. This patch still lets out empty FIN packets, but does not apply the special case to FINs carrying data. Good catch John. But I think the correct test on skb-len would be to just make sure that it is = REAL_MSS. What do you think about that? This would match the original intention of the logic in the pre-TSO days. - 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] apply cwnd rules to FIN packets with data
From: John Heffner [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 18:02:19 -0500 David Miller wrote: From: John Heffner [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:58:18 -0500 This is especially important with TSO enabled. Currently, it will send a burst of up to 64k at the end of a connection, even when cwnd is much smaller than 64k. This patch still lets out empty FIN packets, but does not apply the special case to FINs carrying data. Good catch John. But I think the correct test on skb-len would be to just make sure that it is = REAL_MSS. What do you think about that? This would match the original intention of the logic in the pre-TSO days. What was the intention of that logic? Because a packet is a packet is a packet. If we let a FIN out it's basically equivalent to a FIN+data as far as the routers are concerned. Either they will drop the packet or they won't. And they will do this regardless of whether data is attached to the FIN. Getting FINs out fast is important for another reason, the faster the session closes the faster smart intermediate routers can teardown cached routing or firewall tracking entries for the flow. Actually, I think it would be better to leave the Nagle test as it was (which is implicitly real_mss), because there is obviously no point in doing the nagle test when you know there is no more data that will be sent. True. However, I can't think of any reason why the cwnd test should not apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) - 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] apply cwnd rules to FIN packets with data
David Miller wrote: From: John Heffner [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:58:18 -0500 This is especially important with TSO enabled. Currently, it will send a burst of up to 64k at the end of a connection, even when cwnd is much smaller than 64k. This patch still lets out empty FIN packets, but does not apply the special case to FINs carrying data. Good catch John. But I think the correct test on skb-len would be to just make sure that it is = REAL_MSS. What do you think about that? This would match the original intention of the logic in the pre-TSO days. What was the intention of that logic? Actually, I think it would be better to leave the Nagle test as it was (which is implicitly real_mss), because there is obviously no point in doing the nagle test when you know there is no more data that will be sent. However, I can't think of any reason why the cwnd test should not apply. -John - 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: respect extra_tx_headroom
On Monday 05 February 2007 22:37, Jiri Benc wrote:
On Mon, 5 Feb 2007 16:32:24 +0100, Ivo van Doorn wrote:
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
[...]
--- dscape/net/d80211/ieee80211_sta.c 2007-02-05 16:18:41.0
+0100
[...]
@@ -2007,6 +2017,8 @@
if (!skb)
break;
+ skb_reserve(skb, local-hw.extra_tx_headroom);
+
mgmt = (struct ieee80211_mgmt *)
skb_put(skb, 24 + sizeof(mgmt-u.beacon));
memset(mgmt, 0, 24 + sizeof(mgmt-u.beacon));
Please enlarge that dev_alloc_skb(400) few lines above by
extra_tx_headroom as well.
Ok.
Btw, it would be nice if you could use -p option for diff as it makes
reviewing easier for me.
Not a problem, I'll try to remember it for future patches.
Here is the updated patch.
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
Besides the additional bytes for the beacon template, this patch
is no longer depends on the rts patch to be applied.
Signed-off-by Ivo van Doorn [EMAIL PROTECTED]
---
diff -rpU3 dscape.control/net/d80211/ieee80211.c
dscape.skb/net/d80211/ieee80211.c
--- dscape.control/net/d80211/ieee80211.c 2007-02-06 00:25:26.0
+0100
+++ dscape.skb/net/d80211/ieee80211.c 2007-02-06 00:39:07.0 +0100
@@ -470,10 +470,9 @@ ieee80211_tx_h_fragment(struct ieee80211
/* reserve enough extra head and tail room for possible
* encryption */
-#define IEEE80211_ENCRYPT_HEADROOM 8
-#define IEEE80211_ENCRYPT_TAILROOM 12
frag = frags[i] =
- dev_alloc_skb(frag_threshold +
+ dev_alloc_skb(tx-local-hw.extra_tx_headroom +
+ frag_threshold +
IEEE80211_ENCRYPT_HEADROOM +
IEEE80211_ENCRYPT_TAILROOM);
if (!frag)
@@ -481,7 +480,8 @@ ieee80211_tx_h_fragment(struct ieee80211
/* Make sure that all fragments use the same priority so
* that they end up using the same TX queue */
frag-priority = first-priority;
- skb_reserve(frag, IEEE80211_ENCRYPT_HEADROOM);
+ skb_reserve(frag, tx-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM);
fhdr = (struct ieee80211_hdr *) skb_put(frag, hdrlen);
memcpy(fhdr, first-data, hdrlen);
if (i == num_fragm - 2)
@@ -1362,6 +1362,7 @@ static int ieee80211_master_start_xmit(s
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *odev = NULL;
struct ieee80211_sub_if_data *osdata;
+ int headroom;
int ret;
/*
@@ -1386,6 +1387,15 @@ static int ieee80211_master_start_xmit(s
}
osdata = IEEE80211_DEV_TO_SUB_IF(odev);
+ headroom = osdata-local-hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM;
+ if (skb_headroom(skb) headroom) {
+ if (pskb_expand_head(skb, headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
control.ifindex = odev-ifindex;
control.type = osdata-type;
if (pkt_data-req_tx_status)
@@ -1615,6 +1625,14 @@ ieee80211_mgmt_start_xmit(struct sk_buff
return 0;
}
+ if (skb_headroom(skb) sdata-local-hw.extra_tx_headroom) {
+ if (pskb_expand_head(skb,
+ sdata-local-hw.extra_tx_headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
hdr = (struct ieee80211_hdr *) skb-data;
fc = le16_to_cpu(hdr-frame_control);
@@ -1748,10 +1766,12 @@ struct sk_buff * ieee80211_beacon_get(st
bh_len = ap-beacon_head_len;
bt_len = ap-beacon_tail_len;
- skb = dev_alloc_skb(bh_len + bt_len + 256 /* maximum TIM len */);
+ skb = dev_alloc_skb(local-hw.extra_tx_headroom +
+ bh_len + bt_len + 256 /* maximum TIM len */);
if (!skb)
return NULL;
+ skb_reserve(skb, local-hw.extra_tx_headroom);
memcpy(skb_put(skb, bh_len), b_head, bh_len);
ieee80211_beacon_add_tim(local, ap, skb);
diff -rpU3 dscape.control/net/d80211/ieee80211_i.h
dscape.skb/net/d80211/ieee80211_i.h
--- dscape.control/net/d80211/ieee80211_i.h 2007-02-06 00:19:38.0
+0100
+++ dscape.skb/net/d80211/ieee80211_i.h 2007-02-06 00:39:28.0 +0100
@@ -49,6 +49,9 @@ struct
Re: [PATCH] HTB O(1) class lookup
On Monday 05 February 2007 11:16, Jarek Poplawski wrote: On 01-02-2007 12:30, Andi Kleen wrote: Simon Lodal [EMAIL PROTECTED] writes: Memory is generally not an issue, but CPU is, and you can not beat the CPU efficiency of plain array lookup (always faster, and constant time). Probably for some old (or embedded) lean boxes used for small network routers, with memory hungry iptables - memory could be an issue. Sure, but if they are that constrained they probably do not run HTB in the first place. We are talking about 4k initially, up to 256k worst case (or 512k if your router is 64bit, unlikely if small is a priority). And the worst memory consumption case considered by Patrick should be relatively unlikely. Anyway, such approach, that most users do something this (reasonable) way, doesn't look like good programming practice. The current hash algorithm also assumes certain usage patterns, namely that you choose classids that generate different hash keys (= distribute uniformly across the buckets), or scalability will suffer very quickly. Even at 64 classes you would probably see htb_find() near the top of a profiling analysis. But I would say that it is just as unlikely as choosing 64 classids that cause my patch to allocate all 256k. In these unlikely cases, my patch only wastes passive memory, while the current htb wastes cpu to a point where it can severely limit routing performance. I wonder, why not try, at least for a while, to do this a compile (menuconfig) option with a comment: recommended for a large number of classes. After hash optimization and some testing, final decisions could be made. I decided not to do it because it would mean too many ifdefs (ugly+unmaintanable code). Regards Simon - 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] HTB O(1) class lookup
On Thursday 01 February 2007 12:30, Andi Kleen wrote: Simon Lodal [EMAIL PROTECTED] writes: Memory is generally not an issue, but CPU is, and you can not beat the CPU efficiency of plain array lookup (always faster, and constant time). Actually that's not true when the array doesn't fit in cache. The cost of going out to memory over caches is so large (factor 100 and more) that often algorithms with smaller cache footprint can easily beat algorithms that execute much less instructions if it has less cache misses. That is because not all instructions have the same cost; anything in core is very fast but going out to memory is very slow. That said I think I agree with your analysis that a two level array is probably the right data structure for this and likely not less cache efficient than the hash table. Good point. The 2-level lookup generates 3 memory accesses (including getting at the htb_class struct). List traversal will generate many more memory accesses, unless the lists have 3 or fewer entries (currently that only holds true for up to 48 classes, uniformly distributed). It is difficult to judge if the tables will be in cache or not. The tables are clearly extra baggage for the cachelines, compared to only having the htb_class structs (they are going to be fetched anyway). On the other hand, if you have 10k classes, they are usually (real world) allocated for individual users, of which at most half are active at any time. With hashing, all 10k classes are fetched into cachelines all the time, only in order to traverse lists. That is 150k wasted cache (5000 x 32 bytes); plenty for 10k pointers in lookup tables. Regards Simon - 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] apply cwnd rules to FIN packets with data
David Miller wrote: However, I can't think of any reason why the cwnd test should not apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) True, it's not going to melt the internet, but why stop at one when two would finish the connection even faster? Not sure I buy this argument. Was there some benchmarking data that was a justification for this in the first place? My first patch was broken anyway (should not have pulled the test from tso_should_defer), and the change is not needed to the nagle test since it's implicit. This patch just restores the old behavior from before TSO, sending the FIN when it's the last true segment. We can debate the merits of applying congestion control to the FIN separately. :) -John Don't apply FIN exception to full TSO segments. Signed-off-by: John Heffner [EMAIL PROTECTED] --- commit 89de0d8cb75958b0315c076b31a597143e30f7a4 tree 7e9c321e62729c6ef76e3886fe9edf2ac78a680c parent c0d4d573feed199b16094c072e7cb07afb01c598 author John Heffner [EMAIL PROTECTED] Mon, 05 Feb 2007 18:42:31 -0500 committer John Heffner [EMAIL PROTECTED] Mon, 05 Feb 2007 18:42:31 -0500 net/ipv4/tcp_output.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 975f447..58b7111 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -965,7 +965,8 @@ static inline unsigned int tcp_cwnd_test u32 in_flight, cwnd; /* Don't be strict about the congestion window for the final FIN. */ - if (TCP_SKB_CB(skb)-flags TCPCB_FLAG_FIN) + if ((TCP_SKB_CB(skb)-flags TCPCB_FLAG_FIN) + tcp_skb_pcount(skb) == 1) return 1; in_flight = tcp_packets_in_flight(tp);
Re: [PATCH] apply cwnd rules to FIN packets with data
John Heffner wrote: David Miller wrote: However, I can't think of any reason why the cwnd test should not apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) True, it's not going to melt the internet, but why stop at one when two would finish the connection even faster? Not sure I buy this argument. Was there some benchmarking data that was a justification for this in the first place? Is the cwnd in the stack byte based, or packet based? While all the RFCs tend to discuss things in terms of byte-based cwnds and assumptions based on MSSes and such, the underlying principle was/is a conservation of packets. As David said, a packet is a packet, and if one were going to be sending a FIN segment, it might as well carry data. And if one isn't comfortable sending that one last data segment with the FIN because cwnd wasn't large enough at the time, should the FIN be sent at that point, even if it is waffer thin? rick jones 2 cents tossed-in from the peanut gallery - 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] apply cwnd rules to FIN packets with data
Rick Jones wrote: John Heffner wrote: David Miller wrote: However, I can't think of any reason why the cwnd test should not apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) True, it's not going to melt the internet, but why stop at one when two would finish the connection even faster? Not sure I buy this argument. Was there some benchmarking data that was a justification for this in the first place? Is the cwnd in the stack byte based, or packet based? While all the RFCs tend to discuss things in terms of byte-based cwnds and assumptions based on MSSes and such, the underlying principle was/is a conservation of packets. As David said, a packet is a packet, and if one were going to be sending a FIN segment, it might as well carry data. And if one isn't comfortable sending that one last data segment with the FIN because cwnd wasn't large enough at the time, should the FIN be sent at that point, even if it is waffer thin? The most conservative thing is to apply congestion control exactly as you would to any other segment, that is, just take the special case out entirely. An empty FIN is not too likely to cause problems, a full-MSS FIN somewhat more so, 2-MSS, yet more, a 64k TSO segment even more. :) I don't have hard data to argue for or against any particular optimization, but it seems there should be some if we're ignoring the standard cwnd rules. -John - 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/11] user of the jiffies rounding code: Networking
From: Arjan van de Ven [EMAIL PROTECTED]
This patch introduces users of the round_jiffies() function in the networking
code.
These timers all were of the about once a second or about once every X
seconds variety and several showed up in the what wakes the cpu up profiles
that the tickless patches provide. Some timers are highly dynamic based on
network load; but even on low activity systems they still show up so the
rounding is done only in cases of low activity, allowing higher frequency
timers in the high activity case.
The various hardware watchdogs are an obvious case; they run every 2 seconds
but aren't otherwise specific of exactly when they need to run.
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c |6 +++---
net/core/dst.c |9 -
net/core/neighbour.c |5 -
net/sched/sch_generic.c|2 +-
4 files changed, 16 insertions(+), 6 deletions(-)
diff -puN
drivers/net/e1000/e1000_main.c~user-of-the-jiffies-rounding-code-networking
drivers/net/e1000/e1000_main.c
---
a/drivers/net/e1000/e1000_main.c~user-of-the-jiffies-rounding-code-networking
+++ a/drivers/net/e1000/e1000_main.c
@@ -2652,7 +2652,7 @@ e1000_watchdog(unsigned long data)
netif_carrier_on(netdev);
netif_wake_queue(netdev);
- mod_timer(adapter-phy_info_timer, jiffies + 2 * HZ);
+ mod_timer(adapter-phy_info_timer,
round_jiffies(jiffies + 2 * HZ));
adapter-smartspeed = 0;
} else {
/* make sure the receive unit is started */
@@ -2669,7 +2669,7 @@ e1000_watchdog(unsigned long data)
DPRINTK(LINK, INFO, NIC Link is Down\n);
netif_carrier_off(netdev);
netif_stop_queue(netdev);
- mod_timer(adapter-phy_info_timer, jiffies + 2 * HZ);
+ mod_timer(adapter-phy_info_timer,
round_jiffies(jiffies + 2 * HZ));
/* 80003ES2LAN workaround--
* For packet buffer work-around on link down event;
@@ -2721,7 +2721,7 @@ e1000_watchdog(unsigned long data)
e1000_rar_set(adapter-hw, adapter-hw.mac_addr, 0);
/* Reset the timer */
- mod_timer(adapter-watchdog_timer, jiffies + 2 * HZ);
+ mod_timer(adapter-watchdog_timer, round_jiffies(jiffies + 2 * HZ));
}
enum latency_range {
diff -puN net/core/dst.c~user-of-the-jiffies-rounding-code-networking
net/core/dst.c
--- a/net/core/dst.c~user-of-the-jiffies-rounding-code-networking
+++ a/net/core/dst.c
@@ -99,7 +99,14 @@ static void dst_run_gc(unsigned long dum
printk(dst_total: %d/%d %ld\n,
atomic_read(dst_total), delayed, dst_gc_timer_expires);
#endif
- mod_timer(dst_gc_timer, jiffies + dst_gc_timer_expires);
+ /* if the next desired timer is more than 4 seconds in the future
+* then round the timer to whole seconds
+*/
+ if (dst_gc_timer_expires 4*HZ)
+ mod_timer(dst_gc_timer,
+ round_jiffies(jiffies + dst_gc_timer_expires));
+ else
+ mod_timer(dst_gc_timer, jiffies + dst_gc_timer_expires);
out:
spin_unlock(dst_lock);
diff -puN net/core/neighbour.c~user-of-the-jiffies-rounding-code-networking
net/core/neighbour.c
--- a/net/core/neighbour.c~user-of-the-jiffies-rounding-code-networking
+++ a/net/core/neighbour.c
@@ -696,7 +696,10 @@ next_elt:
if (!expire)
expire = 1;
- mod_timer(tbl-gc_timer, now + expire);
+ if (expireHZ)
+ mod_timer(tbl-gc_timer, round_jiffies(now + expire));
+ else
+ mod_timer(tbl-gc_timer, now + expire);
write_unlock(tbl-lock);
}
diff -puN net/sched/sch_generic.c~user-of-the-jiffies-rounding-code-networking
net/sched/sch_generic.c
--- a/net/sched/sch_generic.c~user-of-the-jiffies-rounding-code-networking
+++ a/net/sched/sch_generic.c
@@ -209,7 +209,7 @@ static void dev_watchdog(unsigned long a
dev-name);
dev-tx_timeout(dev);
}
- if (!mod_timer(dev-watchdog_timer, jiffies +
dev-watchdog_timeo))
+ if (!mod_timer(dev-watchdog_timer,
round_jiffies(jiffies + dev-watchdog_timeo)))
dev_hold(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
[patch 05/11] bonding: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: Joe Jin [EMAIL PROTECTED]
Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in
the bonding driver.
Signed-off-by: Joe Jin [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/bonding/bond_alb.c |4 +---
drivers/net/bonding/bond_main.c |4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff -puN
drivers/net/bonding/bond_alb.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
drivers/net/bonding/bond_alb.c
---
a/drivers/net/bonding/bond_alb.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
+++ a/drivers/net/bonding/bond_alb.c
@@ -184,7 +184,7 @@ static int tlb_initialize(struct bonding
spin_lock_init((bond_info-tx_hashtbl_lock));
- new_hashtbl = kmalloc(size, GFP_KERNEL);
+ new_hashtbl = kzalloc(size, GFP_KERNEL);
if (!new_hashtbl) {
printk(KERN_ERR DRV_NAME
: %s: Error: Failed to allocate TLB hash table\n,
@@ -195,8 +195,6 @@ static int tlb_initialize(struct bonding
bond_info-tx_hashtbl = new_hashtbl;
- memset(bond_info-tx_hashtbl, 0, size);
-
for (i = 0; i TLB_HASH_TABLE_SIZE; i++) {
tlb_init_table_entry(bond_info-tx_hashtbl[i], 1);
}
diff -puN
drivers/net/bonding/bond_main.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
drivers/net/bonding/bond_main.c
---
a/drivers/net/bonding/bond_main.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
+++ a/drivers/net/bonding/bond_main.c
@@ -1343,14 +1343,12 @@ int bond_enslave(struct net_device *bond
inaccurate.\n, bond_dev-name, slave_dev-name);
}
- new_slave = kmalloc(sizeof(struct slave), GFP_KERNEL);
+ new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL);
if (!new_slave) {
res = -ENOMEM;
goto err_undo_flags;
}
- memset(new_slave, 0, sizeof(struct slave));
-
/* save slave's original flags before calling
* netdev_set_master and dev_open
*/
_
-
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/11] slip: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: joe jin [EMAIL PROTECTED]
This patch replace kmalloc() + memset() pairs with the appropriate
kzalloc().
Signed-off-by: Joe Jin [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/slip.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff -puN drivers/net/slip.c~slip-replace-kmalloc-memset-pairs-with-the
drivers/net/slip.c
--- a/drivers/net/slip.c~slip-replace-kmalloc-memset-pairs-with-the
+++ a/drivers/net/slip.c
@@ -1343,15 +1343,12 @@ static int __init slip_init(void)
printk(KERN_INFO SLIP linefill/keepalive option.\n);
#endif
- slip_devs = kmalloc(sizeof(struct net_device *)*slip_maxdev,
GFP_KERNEL);
+ slip_devs = kzalloc(sizeof(struct net_device *)*slip_maxdev,
GFP_KERNEL);
if (!slip_devs) {
printk(KERN_ERR SLIP: Can't allocate slip devices array!
Uaargh! (- No SLIP available)\n);
return -ENOMEM;
}
- /* Clear the pointer array, we allocate devices when we need them */
- memset(slip_devs, 0, sizeof(struct net_device *)*slip_maxdev);
-
/* Fill in our line protocol discipline, and register it */
if ((status = tty_register_ldisc(N_SLIP, sl_ldisc)) != 0) {
printk(KERN_ERR SLIP: can't register line discipline (err =
%d)\n, status);
_
-
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/11] z85230: spinlock logic
From: Alan Cox [EMAIL PROTECTED]
At some point someone added a spin_lock(dev-lock) to the IRQ handler for
the Z85230 driver. This actually correctly fixes a bug but the necessary
changes to remove the chan-lock calls in the event handlers were not made
(c-lock is the same lock).
Simona Dascenzo reported the problem with the driver and this patch should
fix the problem he found.
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/wan/z85230.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff -puN drivers/net/wan/z85230.c~z85230-spinlock-logic
drivers/net/wan/z85230.c
--- a/drivers/net/wan/z85230.c~z85230-spinlock-logic
+++ a/drivers/net/wan/z85230.c
@@ -331,8 +331,7 @@ static void z8530_rtsdtr(struct z8530_ch
static void z8530_rx(struct z8530_channel *c)
{
u8 ch,stat;
- spin_lock(c-lock);
-
+
while(1)
{
/* FIFO empty ? */
@@ -390,7 +389,6 @@ static void z8530_rx(struct z8530_channe
*/
write_zsctrl(c, ERR_RES);
write_zsctrl(c, RES_H_IUS);
- spin_unlock(c-lock);
}
@@ -406,7 +404,6 @@ static void z8530_rx(struct z8530_channe
static void z8530_tx(struct z8530_channel *c)
{
- spin_lock(c-lock);
while(c-txcount) {
/* FIFO full ? */
if(!(read_zsreg(c, R0)4))
@@ -434,7 +431,6 @@ static void z8530_tx(struct z8530_channe
z8530_tx_done(c);
write_zsctrl(c, RES_H_IUS);
- spin_unlock(c-lock);
}
/**
@@ -452,7 +448,6 @@ static void z8530_status(struct z8530_ch
{
u8 status, altered;
- spin_lock(chan-lock);
status=read_zsreg(chan, R0);
altered=chan-status^status;
@@ -487,7 +482,6 @@ static void z8530_status(struct z8530_ch
}
write_zsctrl(chan, RES_EXT_INT);
write_zsctrl(chan, RES_H_IUS);
- spin_unlock(chan-lock);
}
struct z8530_irqhandler z8530_sync=
@@ -511,7 +505,6 @@ EXPORT_SYMBOL(z8530_sync);
static void z8530_dma_rx(struct z8530_channel *chan)
{
- spin_lock(chan-lock);
if(chan-rxdma_on)
{
/* Special condition check only */
@@ -534,7 +527,6 @@ static void z8530_dma_rx(struct z8530_ch
/* DMA is off right now, drain the slow way */
z8530_rx(chan);
}
- spin_unlock(chan-lock);
}
/**
@@ -547,7 +539,6 @@ static void z8530_dma_rx(struct z8530_ch
static void z8530_dma_tx(struct z8530_channel *chan)
{
- spin_lock(chan-lock);
if(!chan-dma_tx)
{
printk(KERN_WARNING Hey who turned the DMA off?\n);
@@ -557,7 +548,6 @@ static void z8530_dma_tx(struct z8530_ch
/* This shouldnt occur in DMA mode */
printk(KERN_ERR DMA tx - bogus event!\n);
z8530_tx(chan);
- spin_unlock(chan-lock);
}
/**
@@ -596,7 +586,6 @@ static void z8530_dma_status(struct z853
}
}
- spin_lock(chan-lock);
if(alteredchan-dcdcheck)
{
if(statuschan-dcdcheck)
@@ -618,7 +607,6 @@ static void z8530_dma_status(struct z853
write_zsctrl(chan, RES_EXT_INT);
write_zsctrl(chan, RES_H_IUS);
- spin_unlock(chan-lock);
}
struct z8530_irqhandler z8530_dma_sync=
_
-
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 09/11] Remove unused kernel config option DLCI_COUNT
From: Robert P. J. Day [EMAIL PROTECTED] Remove the unused kernel config option DLCI_COUNT. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Cc: Krzysztof Halasa [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/wan/Kconfig | 11 --- 1 file changed, 11 deletions(-) diff -puN drivers/net/wan/Kconfig~remove-unused-kernel-config-option-dlci_count drivers/net/wan/Kconfig --- a/drivers/net/wan/Kconfig~remove-unused-kernel-config-option-dlci_count +++ a/drivers/net/wan/Kconfig @@ -357,17 +357,6 @@ config DLCI To compile this driver as a module, choose M here: the module will be called dlci. -config DLCI_COUNT - int Max open DLCI - depends on DLCI - default 24 - help - Maximal number of logical point-to-point frame relay connections - (the identifiers of which are called DCLIs) that the driver can - handle. - - The default is probably fine. - config DLCI_MAX int Max DLCI per device depends on DLCI _ - 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/11] netfilter warning fix
From: Andrew Morton [EMAIL PROTECTED]
using smp_processor_id() in preemptible code
Cc: Patrick McHardy [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/net/netfilter/nf_conntrack.h |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -puN include/net/netfilter/nf_conntrack.h~netfilter-warning-fix
include/net/netfilter/nf_conntrack.h
--- a/include/net/netfilter/nf_conntrack.h~netfilter-warning-fix
+++ a/include/net/netfilter/nf_conntrack.h
@@ -254,7 +254,12 @@ extern atomic_t nf_conntrack_count;
extern int nf_conntrack_max;
DECLARE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat);
-#define NF_CT_STAT_INC(count) (__get_cpu_var(nf_conntrack_stat).count++)
+#define NF_CT_STAT_INC(count) \
+ do {\
+ preempt_disable(); \
+ __get_cpu_var(nf_conntrack_stat).count++; \
+ preempt_enable(); \
+ } while (0);
/* no helper, no nat */
#defineNF_CT_F_BASIC 0
_
-
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/11] net/irda/: proper prototypes
From: Adrian Bunk [EMAIL PROTECTED]
Add proper prototypes for some functions in include/net/irda/irda.h
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Samuel Ortiz [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/net/irda/irda.h | 15 +++
net/irda/irmod.c| 13 -
2 files changed, 15 insertions(+), 13 deletions(-)
diff -puN include/net/irda/irda.h~net-irda-proper-prototypes
include/net/irda/irda.h
--- a/include/net/irda/irda.h~net-irda-proper-prototypes
+++ a/include/net/irda/irda.h
@@ -113,4 +113,19 @@ do { if(!(expr)) { \
#define IAS_IRCOMM_ID 0x2343
#define IAS_IRLPT_ID 0x9876
+struct net_device;
+struct packet_type;
+
+void irda_proc_register(void);
+void irda_proc_unregister(void);
+
+int irda_sysctl_register(void);
+void irda_sysctl_unregister(void);
+
+int irsock_init(void);
+void irsock_cleanup(void);
+
+int irlap_driver_rcv(struct sk_buff *skb, struct net_device *dev,
+struct packet_type *ptype, struct net_device *orig_dev);
+
#endif /* NET_IRDA_H */
diff -puN net/irda/irmod.c~net-irda-proper-prototypes net/irda/irmod.c
--- a/net/irda/irmod.c~net-irda-proper-prototypes
+++ a/net/irda/irmod.c
@@ -42,19 +42,6 @@
#include net/irda/irttp.h/* irttp_init */
#include net/irda/irda_device.h /* irda_device_init */
-/* irproc.c */
-extern void irda_proc_register(void);
-extern void irda_proc_unregister(void);
-/* irsysctl.c */
-extern int irda_sysctl_register(void);
-extern void irda_sysctl_unregister(void);
-/* af_irda.c */
-extern int irsock_init(void);
-extern void irsock_cleanup(void);
-/* irlap_frame.c */
-extern int irlap_driver_rcv(struct sk_buff *, struct net_device *,
-struct packet_type *, struct net_device *);
-
/*
* Module parameters
*/
_
-
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 10/11] dccp-warning-fixes
From: Andrew Morton [EMAIL PROTECTED] sparc64: net/dccp/ccids/ccid3.c: In function `ccid3_hc_tx_packet_recv': net/dccp/ccids/ccid3.c:480: warning: long long unsigned int format, __u64 arg (arg 6) net/dccp/ccids/ccid3.c: In function `ccid3_hc_rx_packet_recv': net/dccp/ccids/ccid3.c:1007: warning: long int format, different type arg (arg 3) net/dccp/ccids/ccid3.c:1007: warning: long int format, different type arg (arg 4) opaque types must be suitably cast for printing. Cc: Arnaldo Carvalho de Melo [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- net/dccp/ccids/ccid3.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff -puN net/dccp/ccids/ccid3.c~dccp-warning-fixes net/dccp/ccids/ccid3.c --- a/net/dccp/ccids/ccid3.c~dccp-warning-fixes +++ a/net/dccp/ccids/ccid3.c @@ -479,7 +479,8 @@ static void ccid3_hc_tx_packet_recv(stru ccid3_pr_debug(%s(%p), s=%u, w_init=%llu, R_sample=%dus, X=%u\n, dccp_role(sk), - sk, hctx-ccid3hctx_s, w_init, + sk, hctx-ccid3hctx_s, + (unsigned long long)w_init, (int)r_sample, (unsigned)(hctx-ccid3hctx_x 6)); @@ -1005,7 +1006,7 @@ static void ccid3_hc_rx_packet_recv(stru DCCP_BUG_ON(r_sample 0); if (unlikely(r_sample = t_elapsed)) DCCP_WARN(r_sample=%ldus, t_elapsed=%ldus\n, - r_sample, t_elapsed); + (long)r_sample, (long)t_elapsed); else r_sample -= t_elapsed; CCID3_RTT_SANITY_CHECK(r_sample); _ - 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/11] fix for crash in adummy_init()
From: Daniel Walker [EMAIL PROTECTED] This was reported by Ingo Molnar here, http://lkml.org/lkml/2006/12/18/119 The problem is that adummy_init() depends on atm_init() , but adummy_init() is called first. So I put atm_init() into subsys_initcall which seems appropriate, and it will still get module_init() if it becomes a module. Interesting to note that you could crash your system here if you just load the modules in the wrong order. Signed-off-by: Daniel Walker [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: chas williams [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- net/atm/common.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN net/atm/common.c~fix-for-crash-in-adummy_init net/atm/common.c --- a/net/atm/common.c~fix-for-crash-in-adummy_init +++ a/net/atm/common.c @@ -816,7 +816,8 @@ static void __exit atm_exit(void) proto_unregister(vcc_proto); } -module_init(atm_init); +subsys_initcall(atm_init); + module_exit(atm_exit); MODULE_LICENSE(GPL); _ - 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/11] net/wanrouter/wanmain.c: cleanups
From: Adrian Bunk [EMAIL PROTECTED]
This patch contains the following cleanups:
- make the following needlessly global functions static:
- lock_adapter_irq()
- unlock_adapter_irq()
- #if 0 the following unused global functions:
- wanrouter_encapsulate()
- wanrouter_type_trans()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/linux/wanrouter.h |8
net/wanrouter/wanmain.c | 17 -
2 files changed, 8 insertions(+), 17 deletions(-)
diff -puN include/linux/wanrouter.h~net-wanrouter-wanmainc-cleanups
include/linux/wanrouter.h
--- a/include/linux/wanrouter.h~net-wanrouter-wanmainc-cleanups
+++ a/include/linux/wanrouter.h
@@ -516,9 +516,6 @@ struct wan_device {
/* Public functions available for device drivers */
extern int register_wan_device(struct wan_device *wandev);
extern int unregister_wan_device(char *name);
-__be16 wanrouter_type_trans(struct sk_buff *skb, struct net_device *dev);
-int wanrouter_encapsulate(struct sk_buff *skb, struct net_device *dev,
- unsigned short type);
/* Proc interface functions. These must not be called by the drivers! */
extern int wanrouter_proc_init(void);
@@ -527,11 +524,6 @@ extern int wanrouter_proc_add(struct wan
extern int wanrouter_proc_delete(struct wan_device *wandev);
extern int wanrouter_ioctl( struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg);
-extern void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-extern void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-
-
-
/* Public Data */
/* list of registered devices */
extern struct wan_device *wanrouter_router_devlist;
diff -puN net/wanrouter/wanmain.c~net-wanrouter-wanmainc-cleanups
net/wanrouter/wanmain.c
--- a/net/wanrouter/wanmain.c~net-wanrouter-wanmainc-cleanups
+++ a/net/wanrouter/wanmain.c
@@ -86,8 +86,8 @@ static int wanrouter_device_del_if(struc
static struct wan_device *wanrouter_find_device(char *name);
static int wanrouter_delete_interface(struct wan_device *wandev, char *name);
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
@@ -104,8 +104,8 @@ struct wan_device* wanrouter_router_devl
* Organize Unique Identifiers for encapsulation/decapsulation
*/
-static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
#if 0
+static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
static unsigned char wanrouter_oui_802_2[] = { 0x00, 0x80, 0xC2 };
#endif
@@ -246,6 +246,8 @@ int unregister_wan_device(char *name)
return 0;
}
+#if 0
+
/*
* Encapsulate packet.
*
@@ -341,6 +343,7 @@ __be16 wanrouter_type_trans(struct sk_bu
return ethertype;
}
+#endif /* 0 */
/*
* WAN device IOCTL.
@@ -799,23 +802,19 @@ static int wanrouter_delete_interface(st
return 0;
}
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_lock_irqsave(lock, *smp_flags);
}
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_unlock_irqrestore(lock, *smp_flags);
}
EXPORT_SYMBOL(register_wan_device);
EXPORT_SYMBOL(unregister_wan_device);
-EXPORT_SYMBOL(wanrouter_encapsulate);
-EXPORT_SYMBOL(wanrouter_type_trans);
-EXPORT_SYMBOL(lock_adapter_irq);
-EXPORT_SYMBOL(unlock_adapter_irq);
MODULE_LICENSE(GPL);
_
-
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 0/3] e1000: update to 7.3.20
Willy, Please pull: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.4 e1000 to receive an update for the e1000 driver. This updates the e1000 driver in the 2.4 kernel to version 7.3.20-k4, roughly the equivalent of what is in 2.6.20 and the latest of our out-of-tree driver. This adds new hardware support and many fixes. Many customers are asking us for these updates and the current 2.4 kernel ships a very outdated version of the e1000 adapter. This patch includes small compatibility headers and code to minimize the changes we need to make to our driver and keep it in sync easier with the 2.6 kernel version so we can possibly continue to ship updates and fixes to this driver with more ease. Cheers, Auke --- These patches apply against commit 99405c24cd80afa8f002574f65700296c838260d --- Summary: Jesse Brandeburg [EMAIL PROTECTED]: e1000: integrate latest 2.4 linux driver [MAINTAINERS]: update e1000 maintainers e1000: update README --- Documentation/networking/e1000.txt | 785 +++- MAINTAINERS| 18 drivers/net/e1000/Makefile |2 drivers/net/e1000/e1000.h | 205 + drivers/net/e1000/e1000_ethtool.c | 1202 --- drivers/net/e1000/e1000_hw.c | 5830 + drivers/net/e1000/e1000_hw.h | 1420 - drivers/net/e1000/e1000_main.c | 3897 ++-- drivers/net/e1000/e1000_osdep.h| 91 drivers/net/e1000/e1000_param.c| 406 +- drivers/net/e1000/kcompat.c| 69 drivers/net/e1000/kcompat.h| 403 ++ 16 files changed, 11305 insertions(+), 3052 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 2/3] [MAINTAINERS]: update e1000 maintainers
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- MAINTAINERS | 18 ++ 1 files changed, 14 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 13759e9..c001147 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -951,9 +951,14 @@ S: Maintained INTEL PRO/100 ETHERNET SUPPORT P: John Ronciak M: [EMAIL PROTECTED] -P: Ganesh Venkatesan -M: [EMAIL PROTECTED] +P: Jesse Brandeburg +M: [EMAIL PROTECTED] +P: Jeff Kirsher +M: [EMAIL PROTECTED] +P: Auke Kok +M: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ +L: [EMAIL PROTECTED] S: Supported INTEL PRO/1000 GIGABIT ETHERNET SUPPORT @@ -961,9 +966,14 @@ P: Jeb Cramer M: [EMAIL PROTECTED] P: John Ronciak M: [EMAIL PROTECTED] -P: Ganesh Venkatesan -M: [EMAIL PROTECTED] +P: Jesse Brandeburg +M: [EMAIL PROTECTED] +P: Jeff Kirsher +M: [EMAIL PROTECTED] +P: Auke Kok +M: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ +L: [EMAIL PROTECTED] S: Supported INTERMEZZO FILE SYSTEM --- 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 3/3] e1000: update README
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- Documentation/networking/e1000.txt | 785 +--- 1 files changed, 542 insertions(+), 243 deletions(-) diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 39fba39..517e42d 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 17, 2004 +November 11, 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 @@ -20,256 +21,398 @@ In This Release === This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family -of Adapters, version 5.x.x. +of Adapters. This driver supports kernel versions 2.4.x. This driver includes +support for Itanium(R)2-based systems. -For questions related to hardware requirements, refer to the documentation -supplied with your Intel PRO/1000 adapter. All hardware requirements listed +For questions related to hardware requirements, refer to the documentation +supplied with your Intel PRO/1000 adapter. All hardware requirements listed apply to use with Linux. -Native VLANs are now available with supported kernels. +This release includes support for Intel(R) I/O Acceleration Technology, +Intel(R) I/OAT. This is supported on systems using the Intel(R) 5000 Series +Chipsets Integrated Device - 1A38. You can find additional information +on Intel I/OAT at http://www.intel.com/technology/ioacceleration/index.htm. + +The following features are now available in supported kernels: + - Native VLANs + - Channel Bonding (teaming) + - SNMP + +Channel Bonding documentation can be found in the Linux kernel source: +/Documentation/networking/bonding.txt + +The driver information previously displayed in the /proc filesystem is not +supported in this release. Alternatively, you can use ethtool (version 1.6 +or later), lspci, and ifconfig to obtain the same information. + +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 -For more information on how to identify your adapter, go to the Adapter +For more information on how to identify your adapter, go to the Adapter 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 +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 networking link on the left to search for your adapter: http://downloadfinder.intel.com/scripts-df/support_intel.asp + +Building and Installation += + +This driver is part of the kernel archive you just extracted, be sure to enable +the e1000 driver (and probably NAPI in the: +Network Device Support +-- Ethernet Drivers (1000 Mbit) +-- Intel PRO/1000 Gigabit Ethernet Support + 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 +If the driver is built as a module, the following optional parameters +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. Also, if the driver is statically built into the -kernel, the driver is loaded with the default values for all the parameters. -Ethtool can be used to change some of the parameters at runtime. +unless otherwise noted. -NOTES: For more information about the AutoNeg, Duplex, and Speed - parameters, see the Speed and Duplex Configuration section in - this document. +NOTES: For more information about the AutoNeg, Duplex, and Speed +parameters, see the Speed and Duplex Configuration section in +this document. -
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Hello.
In article [EMAIL PROTECTED] (at Mon, 5 Feb 2007 15:56:51 -0500), Neil Horman
[EMAIL PROTECTED] says:
if (ifp == NULL valid_lft) {
int max_addresses = in6_dev-cnf.max_addresses;
+ u32 addr_flags = 0;
+
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ if (in6_dev-cnf.optimistic_dad
+ !ipv6_devconf.forwarding)
+ addr_flags = IFA_F_OPTIMISTIC;
+#endif
/* Do not allow to create too much of autoconfigured
* addresses; this would be too easy way to crash
kernel.
@@ -1742,7 +1762,8 @@ ok:
if (!max_addresses ||
ipv6_count_addresses(in6_dev) max_addresses)
ifp = ipv6_add_addr(in6_dev, addr,
pinfo-prefix_len,
-
addr_typeIPV6_ADDR_SCOPE_MASK, 0);
+
addr_typeIPV6_ADDR_SCOPE_MASK,
+ addr_flags);
if (!ifp || IS_ERR(ifp)) {
in6_dev_put(in6_dev);
@@ -1945,7 +1966,11 @@ static int inet6_addr_add(int ifindex, struct in6_addr
*pfx, int plen,
ifp-prefered_lft = prefered_lft;
ifp-tstamp = jiffies;
spin_unlock_bh(ifp-lock);
-
+ /*
+ * Note that section 3.1 of RFC 4429 indicates
+ * That the Optimistic flag should not be set for
+ * manually configured addresses
+ */
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
addrconf_verify(0);
@@ -2122,8 +2147,16 @@ static void init_loopback(struct net_device *dev)
static void addrconf_add_linklocal(struct inet6_dev *idev, struct in6_addr
*addr)
{
struct inet6_ifaddr * ifp;
+ u32 addr_flags = IFA_F_PERMANENT;
+
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ if (idev-cnf.optimistic_dad
+ !ipv6_devconf.forwarding)
+ addr_flags |= IFA_F_OPTIMISTIC;
+#endif
+
- ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, IFA_F_PERMANENT);
+ ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, addr_flags);
if (!IS_ERR(ifp)) {
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
@@ -2190,7 +2223,7 @@ ipv6_inherit_linklocal(struct inet6_dev *idev, struct
net_device *link_dev)
{
struct in6_addr lladdr;
- if (!ipv6_get_lladdr(link_dev, lladdr)) {
+ if (!ipv6_get_lladdr(link_dev, lladdr, IFA_F_TENTATIVE)) {
addrconf_add_linklocal(idev, lladdr);
return 0;
}
@@ -2527,7 +2560,11 @@ static void addrconf_dad_kick(struct inet6_ifaddr *ifp)
unsigned long rand_num;
struct inet6_dev *idev = ifp-idev;
- rand_num = net_random() % (idev-cnf.rtr_solicit_delay ? : 1);
+ if (ifp-flags IFA_F_OPTIMISTIC)
+ rand_num = 0;
+ else
+ rand_num = net_random() % (idev-cnf.rtr_solicit_delay ? : 1);
+
ifp-probes = idev-cnf.dad_transmits;
addrconf_mod_timer(ifp, AC_DAD, rand_num);
}
@@ -2553,7 +2590,7 @@ static void addrconf_dad_start(struct inet6_ifaddr
*ifp, u32 flags)
if (dev-flags(IFF_NOARP|IFF_LOOPBACK) ||
!(ifp-flagsIFA_F_TENTATIVE) ||
ifp-flags IFA_F_NODAD) {
- ifp-flags = ~IFA_F_TENTATIVE;
+ ifp-flags = ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
spin_unlock_bh(ifp-lock);
read_unlock_bh(idev-lock);
@@ -2573,6 +2610,14 @@ static void addrconf_dad_start(struct inet6_ifaddr
*ifp, u32 flags)
addrconf_dad_stop(ifp);
return;
}
+
+ /*
+ * Optimistic nodes need to join the anycast address
+ * right away
+ */
+ if (ifp-flags IFA_F_OPTIMISTIC)
+ addrconf_join_anycast(ifp);
+
addrconf_dad_kick(ifp);
spin_unlock_bh(ifp-lock);
out:
@@ -2597,7 +2642,7 @@ static void addrconf_dad_timer(unsigned long data)
* DAD was successful
*/
- ifp-flags = ~IFA_F_TENTATIVE;
+ ifp-flags = ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
spin_unlock_bh(ifp-lock);
read_unlock_bh(idev-lock);
@@ -2627,6 +2672,9 @@ static void addrconf_dad_completed(struct inet6_ifaddr
*ifp)
* Configure the address for reception. Now it is valid.
*/
+ if (ifp-flags IFA_F_OPTIMISTIC)
+ addrconf_leave_anycast(ifp);
+
ipv6_ifa_notify(RTM_NEWADDR, ifp);
/* If added prefix is link local and forwarding is off,
@@ -3398,6 +3446,9 @@ static void inline ipv6_store_devconf(struct
ipv6_devconf *cnf,
#endif
#endif
array[DEVCONF_PROXY_NDP] = cnf-proxy_ndp;
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST) @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev, struct neighbour *neigh, msg-icmph.icmp6_unused = 0; msg-icmph.icmp6_router= router; msg-icmph.icmp6_solicited = solicited; -msg-icmph.icmp6_override = override; + msg-icmph.icmp6_override = override; + /* Set the target address. */ ipv6_addr_copy(msg-target, solicited_addr); Why do you change this? He edited it, but then reverted his change but in the process added proper tab characters :-) It is easy to miss things like this. This whole file has a lot of lines lacking proper tab characters. - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
In article [EMAIL PROTECTED] (at Mon, 05 Feb 2007 17:32:58 -0800 (PST)), David Miller [EMAIL PROTECTED] says: From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST) @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev, struct neighbour *neigh, msg-icmph.icmp6_unused = 0; msg-icmph.icmp6_router= router; msg-icmph.icmp6_solicited = solicited; -msg-icmph.icmp6_override = override; + msg-icmph.icmp6_override = override; + /* Set the target address. */ ipv6_addr_copy(msg-target, solicited_addr); Why do you change this? He edited it, but then reverted his change but in the process added proper tab characters :-) It is easy to miss things like this. I know, you know. :-) This whole file has a lot of lines lacking proper tab characters. Yes, I agree, but I think it is different issue, and maybe, we should check and change other places as well, in separate patch(es). --yoshfuji - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Tue, 06 Feb 2007 10:44:08 +0900 (JST) Yes, I agree, but I think it is different issue, and maybe, we should check and change other places as well, in separate patch(es). I agree. - 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] apply cwnd rules to FIN packets with data
From: John Heffner [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 19:11:09 -0500 My first patch was broken anyway (should not have pulled the test from tso_should_defer), and the change is not needed to the nagle test since it's implicit. This patch just restores the old behavior from before TSO, sending the FIN when it's the last true segment. We can debate the merits of applying congestion control to the FIN separately. :) Yes, let's split one hair at a time :-) Patch applied, thanks John. I'll push this to the 2.6.x -stable branch too. - 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 01/11] user of the jiffies rounding code: Networking
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:30:52 -0800 From: Arjan van de Ven [EMAIL PROTECTED] This patch introduces users of the round_jiffies() function in the networking code. These timers all were of the about once a second or about once every X seconds variety and several showed up in the what wakes the cpu up profiles that the tickless patches provide. Some timers are highly dynamic based on network load; but even on low activity systems they still show up so the rounding is done only in cases of low activity, allowing higher frequency timers in the high activity case. The various hardware watchdogs are an obvious case; they run every 2 seconds but aren't otherwise specific of exactly when they need to run. Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] I pulled in everything except the e1000 driver change, Jeff please suck that in, thanks. Arjan, btw: + if (dst_gc_timer_expires 4*HZ) + mod_timer(dst_gc_timer, + round_jiffies(jiffies + dst_gc_timer_expires)); + else + mod_timer(dst_gc_timer, jiffies + dst_gc_timer_expires); ^ That line begins TAB SPACE TAB, and lo' and behold GIT catch this when I applied it :-) I fixed it up by hand and reapplied, so don't worry about this instance. - 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 02/11] net/irda/: proper prototypes
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:30:53 -0800 From: Adrian Bunk [EMAIL PROTECTED] Add proper prototypes for some functions in include/net/irda/irda.h Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Samuel Ortiz [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] I NAK'd this so that Adrian would go add extern to the function declarations in the header file. Please drop this, Adrian will resend once he fixes it up. - 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 03/11] fix for crash in adummy_init()
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:30:56 -0800 From: Daniel Walker [EMAIL PROTECTED] This was reported by Ingo Molnar here, http://lkml.org/lkml/2006/12/18/119 The problem is that adummy_init() depends on atm_init() , but adummy_init() is called first. So I put atm_init() into subsys_initcall which seems appropriate, and it will still get module_init() if it becomes a module. Interesting to note that you could crash your system here if you just load the modules in the wrong order. Signed-off-by: Daniel Walker [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: chas williams [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Applied, and I'll queue this one up for -stable too. 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: [patch 05/11] bonding: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:04 -0800 From: Joe Jin [EMAIL PROTECTED] Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in the bonding driver. Signed-off-by: Joe Jin [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Jeff, you got this one? - 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 06/11] net/wanrouter/wanmain.c: cleanups
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:05 -0800 From: Adrian Bunk [EMAIL PROTECTED] This patch contains the following cleanups: - make the following needlessly global functions static: - lock_adapter_irq() - unlock_adapter_irq() - #if 0 the following unused global functions: - wanrouter_encapsulate() - wanrouter_type_trans() Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Applied, 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: [patch 08/11] slip: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:06 -0800 From: joe jin [EMAIL PROTECTED] This patch replace kmalloc() + memset() pairs with the appropriate kzalloc(). Signed-off-by: Joe Jin [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Applied, 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: [patch 11/11] netfilter warning fix
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:11 -0800 From: Andrew Morton [EMAIL PROTECTED] using smp_processor_id() in preemptible code Cc: Patrick McHardy [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] We NAK'd this because every patch in the lockdep trace should have preemption disabled because software interrupts ought to be disabled in those code paths. Someone needs to track down why this is really happening. - 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 11/11] netfilter warning fix
On Mon, 05 Feb 2007 18:10:26 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:11 -0800 From: Andrew Morton [EMAIL PROTECTED] using smp_processor_id() in preemptible code Cc: Patrick McHardy [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] We NAK'd this because every patch in the lockdep trace should have preemption disabled because software interrupts ought to be disabled in those code paths. Someone needs to track down why this is really happening. I think the finger was pointed at preemptible rcu, in -mm. iirc, the net stats code is assuming that rcu_read_lock() disables preemption as a side-effect, which rcu-preempt makes no-longer-true. Not sure what to do there. Perhaps add a new rcu_read_lock_with_preempt_disable() thing which will dtrt with either config. - 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 11/11] netfilter warning fix
From: Andrew Morton [EMAIL PROTECTED]
Date: Mon, 5 Feb 2007 18:18:10 -0800
I think the finger was pointed at preemptible rcu, in -mm. iirc,
the net stats code is assuming that rcu_read_lock() disables
preemption as a side-effect, which rcu-preempt makes no-longer-true.
Not sure what to do there. Perhaps add a new
rcu_read_lock_with_preempt_disable() thing which will dtrt with
either config.
Hmmm, really?
Let's audit NF_CT_STAT_INC() usage to make sure :-)
net/netfilter/nf_conntrack_core.c:
destroy_conntrack: Inside write_{lock,unlock}_bh().
death_by_timeout: Ditto.
__nf_conntrack_find: Inside read_{lock,unlock}_bh() via callers.
__nf_conntrack_confirm: Inside write_{lock,unlock}_bh().
early_drop: This one looks like it could be unprotected.
init_conntrack: Inside of write_{lock,unlock}_bh().
nf_conntrack_in: Packet receive path, softints disabled.
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:
ipv6_prepare: Packet input path, BH's disabled.
net/netfilter/nf_conntrack_expect.c:
nf_ct_unlink_expect: Inside if write_{lock,unlock}_bh() via callers.
nf_conntrack_expect_insert: Ditto.
So that leaves early_drop() as the only suspicious case that might
not run inside of disabled BH's.
And in fact that case is a bug regardless of the preemptible rcu
changes because this allows the counter bump to be corrupted by
software interrupt context.
And OK, I see in the lockdep trace that it's the packet transmit
path... In fact, this assumption of preemption being disabled
by the netfilter top-level dispatch is very deep.
For example, several bits besides the NF_CT_STATIC_INC of
nf_conntrack_in() (where the lockdep trigger backtrace hits) assume
that preemption is enabled by that rcu_read_lock() in the top-level
netfilter dispatch.
The __nf_ct_l{3,4}proto_find() calls there are just two examples.
I imagine this assumption is quite pervasive throughout the
netfilter code, so just patching up this NF_CT_STAT_INC() case
will merely shut up lockdep and paper over the issue.
I bet this rcu_read_lock()-implies-preempt_disable() assumption has
spread into other areas of the tree 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
Re: [patch 05/11] bonding: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
David Miller wrote: From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:04 -0800 From: Joe Jin [EMAIL PROTECTED] Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in the bonding driver. Signed-off-by: Joe Jin [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Jeff, you got this one? nope, didn't see 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 11/11] netfilter warning fix
On Mon, 05 Feb 2007 18:44:08 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: I bet this rcu_read_lock()-implies-preempt_disable() assumption has spread into other areas of the tree as well. Me too. Although one expects that other holes will cause might_sleep or lockdep warnings pretty easily. Still, life is hard enough as it is. I think I'll shelve rcu-preempt pending resolution of this. - 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] A series of patches to use ARRAY_SIZE in `net' drivers
Hi all, Follows is a sereis of patches to use ARRAY_SIZE macro in drivers/net. Patches are sent separately according to their maintaners as replies to this thread. apne.c |2 +- arm/am79c961a.c|2 +- atarilance.c |2 +- cs89x0.c |6 +++--- e1000/e1000_ethtool.c |2 +- fec_8xx/fec_mii.c |4 ++-- ibm_emac/ibm_emac_debug.c |8 irda/actisys-sir.c |3 ++- ixgb/ixgb_param.c |2 +- lp486e.c |2 +- ne-h8300.c |2 +- ne.c |2 +- ne2.c |2 +- ne2k-pci.c |2 +- netxen/netxen_nic_hw.c |2 +- pcmcia/axnet_cs.c |2 +- pcmcia/pcnet_cs.c |2 +- sk98lin/skgemib.c |4 +++- sk98lin/skgesirq.c |3 ++- skfp/smt.c |3 ++- skfp/srf.c |6 -- wireless/airo.c|4 ++-- wireless/hostap/hostap.h |3 ++- wireless/ipw2100.c | 14 ++ wireless/prism54/oid_mgt.c |4 +++- wireless/wavelan.p.h |2 +- zorro8390.c|2 +- 27 files changed, 50 insertions(+), 42 deletions(-) Thanks, -- Ahmed S. Darwish http://darwish-07.blogspot.com - 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.6.20] e1000: Use ARRAY_SIZE macro when appropriate
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
---
Patch is compile tested.
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index fb96c87..d21706e 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -746,7 +746,7 @@ err_setup:
uint32_t pat, value; \
uint32_t test[] = \
{0x5A5A5A5A, 0xA5A5A5A5, 0x, 0x}; \
- for (pat = 0; pat sizeof(test)/sizeof(test[0]); pat++) {
\
+ for (pat = 0; pat ARRAY_SIZE(test); pat++) { \
E1000_WRITE_REG(adapter-hw, R, (test[pat] W)); \
value = E1000_READ_REG(adapter-hw, R); \
if (value != (test[pat] W M)) {
\
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
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/02] misc-net-drivers: Use ARRAY_SIZE macro when appropriate
Hi,
A 2.6.20 patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous network drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
---
[PATCH 01/02] is compile tested.
[PATCH 02/02] isn't compile tested cause of missing hardware.
diff --git a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
index 4612f71..d48196c 100644
--- a/drivers/net/cs89x0.c
+++ b/drivers/net/cs89x0.c
@@ -806,7 +806,7 @@ cs89x0_probe1(struct net_device *dev, int ioaddr, int
modular)
i = cs8900_irq_map[0];
#else
/* Translate the IRQ using the IRQ mapping table. */
- if (i =
sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0]))
+ if (i = ARRAY_SIZE(cs8900_irq_map))
printk(\ncs89x0: invalid ISA interrupt number
%d\n, i);
else
i = cs8900_irq_map[i];
@@ -1248,11 +1248,11 @@ write_irq(struct net_device *dev, int chip_type, int
irq)
if (chip_type == CS8900) {
/* Search the mapping table for the corresponding IRQ pin. */
- for (i = 0; i !=
sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0]); i++)
+ for (i = 0; i != ARRAY_SIZE(cs8900_irq_map); i++)
if (cs8900_irq_map[i] == irq)
break;
/* Not found */
- if (i == sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0]))
+ if (i == ARRAY_SIZE(cs8900_irq_map))
i = 3;
writereg(dev, PP_CS8900_ISAINT, i);
} else {
diff --git a/drivers/net/irda/actisys-sir.c b/drivers/net/irda/actisys-sir.c
index 9715ab5..84d7bb0 100644
--- a/drivers/net/irda/actisys-sir.c
+++ b/drivers/net/irda/actisys-sir.c
@@ -43,6 +43,7 @@
#include linux/module.h
#include linux/delay.h
#include linux/init.h
+#include linux/kernel.h
#include net/irda/irda.h
@@ -67,7 +68,7 @@ static int actisys_reset(struct sir_dev *);
/* Note : the 220L doesn't support 38400, but we will fix that below */
static unsigned baud_rates[] = { 9600, 19200, 57600, 115200, 38400 };
-#define MAX_SPEEDS (sizeof(baud_rates)/sizeof(baud_rates[0]))
+#define MAX_SPEEDS ARRAY_SIZE(baud_rates)
static struct dongle_driver act220l = {
.owner = THIS_MODULE,
diff --git a/drivers/net/lp486e.c b/drivers/net/lp486e.c
index 177c502..4b016aa 100644
--- a/drivers/net/lp486e.c
+++ b/drivers/net/lp486e.c
@@ -515,7 +515,7 @@ CLEAR_INT(void) {
outb(0, IOADDR+8);
}
-#define SIZE(x)(sizeof(x)/sizeof((x)[0]))
+#define SIZE(x)ARRAY_SIZE(x)
#if 0
/* selftest or dump */
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index a5c4199..7081d08 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -379,7 +379,7 @@ static int __init ne_probe1(struct net_device *dev, int
ioaddr)
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i ARRAY_SIZE(program_seq); i++)
outb_p(program_seq[i].value, ioaddr +
program_seq[i].offset);
}
diff --git a/drivers/net/ne2.c b/drivers/net/ne2.c
index 089b5bb..c6c2a91 100644
--- a/drivers/net/ne2.c
+++ b/drivers/net/ne2.c
@@ -432,7 +432,7 @@ static int __init ne2_probe1(struct net_device *dev, int
slot)
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i ARRAY_SIZE(program_seq); i++)
outb_p(program_seq[i].value, base_addr +
program_seq[i].offset);
diff --git a/drivers/net/ne2k-pci.c b/drivers/net/ne2k-pci.c
index 589785d..6bafdda 100644
--- a/drivers/net/ne2k-pci.c
+++ b/drivers/net/ne2k-pci.c
@@ -309,7 +309,7 @@ static int __devinit ne2k_pci_init_one (struct pci_dev
*pdev,
{0x00, EN0_RSARHI},
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i ARRAY_SIZE(program_seq); i++)
outb(program_seq[i].value, ioaddr +
program_seq[i].offset);
}
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index f263232..7f93c08 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -395,7 +395,7 @@ int netxen_is_flash_supported(struct netxen_adapter
*adapter)
/* if the flash size less than 4Mb, make huge war cry and die */
for (j = 1; j 4; j++) {
addr = j * NETXEN_NIC_WINDOW_MARGIN;
- for (i = 0; i (sizeof(locs) / sizeof(locs[0])); i++) {
+ for (i = 0; i ARRAY_SIZE(locs); i++) {
[PATCH 2.6.20] ipw2100: Use ARRAY_SIZE macro when appropriate
Hi all,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
---
Patch is compile tested.
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index b85857a..a9d944a 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -2888,7 +2888,7 @@ static int __ipw2100_tx_process(struct ipw2100_priv *priv)
#ifdef CONFIG_IPW2100_DEBUG
if (packet-info.c_struct.cmd-host_command_reg
- sizeof(command_types) / sizeof(*command_types))
+ ARRAY_SIZE(command_types))
IPW_DEBUG_TX(Command '%s (%d)' processed: %d.\n,
command_types[packet-info.c_struct.cmd-
host_command_reg],
@@ -3736,7 +3736,7 @@ static ssize_t show_registers(struct device *d, struct
device_attribute *attr,
out += sprintf(out, %30s [Address ] : Hex\n, Register);
- for (i = 0; i (sizeof(hw_data) / sizeof(*hw_data)); i++) {
+ for (i = 0; i ARRAY_SIZE(hw_data); i++) {
read_register(dev, hw_data[i].addr, val);
out += sprintf(out, %30s [%08X] : %08X\n,
hw_data[i].name, hw_data[i].addr, val);
@@ -3757,7 +3757,7 @@ static ssize_t show_hardware(struct device *d, struct
device_attribute *attr,
out += sprintf(out, %30s [Address ] : Hex\n, NIC entry);
- for (i = 0; i (sizeof(nic_data) / sizeof(*nic_data)); i++) {
+ for (i = 0; i ARRAY_SIZE(nic_data); i++) {
u8 tmp8;
u16 tmp16;
u32 tmp32;
@@ -3894,13 +3894,11 @@ static ssize_t show_ordinals(struct device *d, struct
device_attribute *attr,
if (priv-status STATUS_RF_KILL_MASK)
return 0;
- if (loop = sizeof(ord_data) / sizeof(*ord_data))
+ if (loop = ARRAY_SIZE(ord_data))
loop = 0;
/* sysfs provides us PAGE_SIZE buffer */
- while (len PAGE_SIZE - 128
- loop (sizeof(ord_data) / sizeof(*ord_data))) {
-
+ while (len PAGE_SIZE - 128 loop ARRAY_SIZE(ord_data)) {
val_len = sizeof(u32);
if (ipw2100_get_ordinal(priv, ord_data[loop].index, val,
@@ -6589,7 +6587,7 @@ static const long ipw2100_rates_11b[] = {
1100
};
-#define RATE_COUNT (sizeof(ipw2100_rates_11b) / sizeof(ipw2100_rates_11b[0]))
+#define RATE_COUNT ARRAY_SIZE(ipw2100_rates_11b)
static int ipw2100_wx_get_name(struct net_device *dev,
struct iw_request_info *info,
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
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/02] misc-net-drivers: Use ARRAY_SIZE macro when appropriate
Hi,
A 2.6.20 patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous network drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
---
Patch isn't compile-tested due to missing hardware.
diff --git a/drivers/net/apne.c b/drivers/net/apne.c
index 9541911..8806151 100644
--- a/drivers/net/apne.c
+++ b/drivers/net/apne.c
@@ -247,7 +247,7 @@ static int __init apne_probe1(struct net_device *dev, int
ioaddr)
{0x00, NE_EN0_RSARHI},
{E8390_RREAD+E8390_START, NE_CMD},
};
- for (i = 0; i sizeof(program_seq)/sizeof(program_seq[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(program_seq); i++) {
outb(program_seq[i].value, ioaddr + program_seq[i].offset);
}
diff --git a/drivers/net/arm/am79c961a.c b/drivers/net/arm/am79c961a.c
index ddd12d4..200cbc0 100644
--- a/drivers/net/arm/am79c961a.c
+++ b/drivers/net/arm/am79c961a.c
@@ -414,7 +414,7 @@ static void am79c961_setmulticastlist (struct net_device
*dev)
/*
* Update the multicast hash table
*/
- for (i = 0; i sizeof(multi_hash) / sizeof(multi_hash[0]); i++)
+ for (i = 0; i ARRAY_SIZE(multi_hash); i++)
write_rreg(dev-base_addr, i + LADRL, multi_hash[i]);
/*
diff --git a/drivers/net/atarilance.c b/drivers/net/atarilance.c
index 7e37ac8..ef18428 100644
--- a/drivers/net/atarilance.c
+++ b/drivers/net/atarilance.c
@@ -263,7 +263,7 @@ struct lance_addr {
(highest byte stripped) */
};
-#defineN_LANCE_ADDR
(sizeof(lance_addr_list)/sizeof(*lance_addr_list))
+#defineN_LANCE_ADDRARRAY_SIZE(lance_addr_list)
/* Definitions for the Lance */
diff --git a/drivers/net/fec_8xx/fec_mii.c b/drivers/net/fec_8xx/fec_mii.c
index d3c16b8..1fc2b43 100644
--- a/drivers/net/fec_8xx/fec_mii.c
+++ b/drivers/net/fec_8xx/fec_mii.c
@@ -310,12 +310,12 @@ int fec_mii_phy_id_detect(struct net_device *dev)
return -1;
}
- for (i = 0, phy = phy_info; i sizeof(phy_info) / sizeof(phy_info[0]);
+ for (i = 0, phy = phy_info; i ARRAY_SIZE(phy_info));
i++, phy++)
if (phy-id == (phy_hwid 4) || phy-id == 0)
break;
- if (i = sizeof(phy_info) / sizeof(phy_info[0])) {
+ if (i = ARRAY_SIZE(phy_info)) {
printk(KERN_ERR DRV_MODULE_NAME
: %s PHY id 0x%08x is not supported!\n,
dev-name, phy_hwid);
diff --git a/drivers/net/ne-h8300.c b/drivers/net/ne-h8300.c
index 38fd525..7599d77 100644
--- a/drivers/net/ne-h8300.c
+++ b/drivers/net/ne-h8300.c
@@ -259,7 +259,7 @@ static int __init ne_probe1(struct net_device *dev, int
ioaddr)
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i ARRAY_SIZE(program_seq); i++)
outb_p(program_seq[i].value, ioaddr +
program_seq[i].offset);
}
diff --git a/drivers/net/zorro8390.c b/drivers/net/zorro8390.c
index d85e2ea..29f9750 100644
--- a/drivers/net/zorro8390.c
+++ b/drivers/net/zorro8390.c
@@ -191,7 +191,7 @@ static int __devinit zorro8390_init(struct net_device *dev,
{0x00, NE_EN0_RSARHI},
{E8390_RREAD+E8390_START, NE_CMD},
};
- for (i = 0; i sizeof(program_seq)/sizeof(program_seq[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(program_seq); i++) {
z_writeb(program_seq[i].value, ioaddr + program_seq[i].offset);
}
}
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
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
