raw sockets ignore IP_HDRINCL data
Hi, I have a multi-homed system like this: eth1: 1.2.3.4 GW: 1.2.3.1 eth2: 2.3.4.5 GW: 2.3.4.1 route ouput snippet is: default 2.3.4.1 0.0.0.0 UG 3 0 0 eth2 default 1.2.3.1 0.0.0.0 UG 4 0 0 eth1 default 2.3.4.1 0.0.0.0 UG 4 0 0 eth2 When I run traceroute -i eth1 5.4.3.2, the UDP packets are routed out eth2. Has anybody seen this behaviour with traceroute?? I have done some debugging, and believe this to be an ipv4 kernel bug. My research came up with the following: By the traceroute source code, it uses raw sockets and relies on IP_HDRINCL (which is defined in the kernel source netinet/in.h) to select the routing interface and does not bind the socket to the source IP address. I hacked the traceroute source code to do a bind if the -i option is used, and the correct GW is used. I am using a 2.4.29 kernel and have traced through the kernel and in .../net/ipv4/raw.c, raw_sendmsg() does not read the data to get the IP header and the source address, which then results in a 0.0.0.0 source address and hence the routing, ip_route_output(), pulls the default gateway with the lowest metric, in this case eth2. I have also used a 2.6.21 kernel and similiar behaviour happens. The 2.6.21 kernel source code does not read the IP header from the data either. Am I reading/interpreting the source code correctly? Any other suggestions/more information would be great. Cheers, Mick -- -- Mick McCreath Sr Engineer Secure Computing® your trusted source for enterprise security™ www.securecomputing.com NASDAQ: SCUR 61 7 3435 2803 (Direct Phone) [EMAIL PROTECTED] Secure Computing Corporation 825 Stanley Street Woolloongabba Queensland 4102 Australia The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any review, dissemination, distribution or copying is strictly prohibited. If you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. - 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/2] ps3: gigabit ethernet driver
Add gigabit ethernet support for PS3.
Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED]
---
drivers/net/Kconfig | 10
drivers/net/Makefile|1
drivers/net/gelic_net.c | 1579
drivers/net/gelic_net.h | 233 +++
4 files changed, 1823 insertions(+)
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2264,6 +2264,16 @@ config TSI108_ETH
To compile this driver as a module, choose M here: the module
will be called tsi108_eth.
+config GELIC_NET
+ tristate PS3 Gigabit Ethernet driver
+ depends on PPC_PS3
+ help
+ This driver supports the Gigabit Ethernet device on the
+ PS3 game console.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gelic_net.
+
config GIANFAR
tristate Gianfar Ethernet
depends on 85xx || 83xx || PPC_86xx
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_TIGON3) += tg3.o
obj-$(CONFIG_BNX2) += bnx2.o
spidernet-y += spider_net.o spider_net_ethtool.o
obj-$(CONFIG_SPIDER_NET) += spidernet.o sungem_phy.o
+obj-$(CONFIG_GELIC_NET) += gelic_net.o
obj-$(CONFIG_TC35815) += tc35815.o
obj-$(CONFIG_SKGE) += skge.o
obj-$(CONFIG_SKY2) += sky2.o
--- /dev/null
+++ b/drivers/net/gelic_net.c
@@ -0,0 +1,1579 @@
+/*
+ * PS3 Platfom gelic network driver.
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corporation
+ *
+ * this file is based on: spider_net.c
+ *
+ * Network device driver for Cell Processor-Based Blade
+ *
+ * (C) Copyright IBM Corp. 2005
+ *
+ * Authors : Utz Bacher [EMAIL PROTECTED]
+ * Jens Osterkamp [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#undef DEBUG
+#undef GELIC_RING_CHAIN
+
+#include linux/kernel.h
+#include linux/module.h
+
+#include linux/etherdevice.h
+#include linux/ethtool.h
+#include linux/if_vlan.h
+
+#include linux/in.h
+#include linux/ip.h
+#include linux/tcp.h
+
+#include linux/dma-mapping.h
+#include net/checksum.h
+#include asm/firmware.h
+#include asm/ps3.h
+#include asm/lv1call.h
+
+#include gelic_net.h
+
+#define GELIC_NET_DRV_NAME Gelic Network Driver
+#define GELIC_NET_DRV_VERSION 1.0
+
+MODULE_AUTHOR(SCE Inc.);
+MODULE_DESCRIPTION(Gelic Network driver);
+MODULE_LICENSE(GPL);
+
+static inline struct device * ctodev(struct gelic_net_card * card)
+{
+ return card-dev-core;
+}
+static inline unsigned int bus_id(struct gelic_net_card *card)
+{
+ return card-dev-did.bus_id;
+}
+static inline unsigned int dev_id(struct gelic_net_card *card)
+{
+ return card-dev-did.dev_id;
+}
+
+/* set irq_mask */
+static int gelic_net_set_irq_mask(struct gelic_net_card *card, u64 mask)
+{
+ int status;
+
+ status = lv1_net_set_interrupt_mask(bus_id(card), dev_id(card),
+ mask, 0);
+ if (status)
+ dev_info(ctodev(card),
+lv1_net_set_interrupt_mask failed %d\n, status);
+ return status;
+}
+static inline void gelic_net_rx_irq_on(struct gelic_net_card *card)
+{
+ gelic_net_set_irq_mask(card, card-ghiintmask | GELIC_NET_RXINT);
+}
+static inline void gelic_net_rx_irq_off(struct gelic_net_card *card)
+{
+ gelic_net_set_irq_mask(card, card-ghiintmask ~GELIC_NET_RXINT);
+}
+/**
+ * gelic_net_get_descr_status -- returns the status of a descriptor
+ * @descr: descriptor to look at
+ *
+ * returns the status as in the dmac_cmd_status field of the descriptor
+ */
+static enum gelic_net_descr_status
+gelic_net_get_descr_status(struct gelic_net_descr *descr)
+{
+ u32 cmd_status;
+
+ cmd_status = descr-dmac_cmd_status;
+ cmd_status = GELIC_NET_DESCR_IND_PROC_SHIFT;
+ return cmd_status;
+}
+
+/**
+ * gelic_net_set_descr_status -- sets the status of a descriptor
+ * @descr: descriptor to change
+ * @status: status to set in the descriptor
+ *
+ * changes the status to the specified value. Doesn't change other bits
+ * in the status
+ */
+static void gelic_net_set_descr_status(struct gelic_net_descr *descr,
+ enum gelic_net_descr_status status)
+{
+ u32 cmd_status;
+
+ /* read the status */
+ cmd_status = descr-dmac_cmd_status;
+ /* clean
[PATCH 0/2] RFC: PS3 network driver
Hi This is the first submission of the PS3 network driver [1] ps3: gigabit ethernet driver for PS3 [2] ps3: add wireless LAN support for PS3 They are submitted for review since some of the underlying infrastructure code hasn't been submitted yet. For reference, you can take a look at Geoff's git tree (git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git). I appreciate your comments. -- Masakazu MOKUNO - 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/2] RFC: PS3 network driver
Hi This is the first submission of the PS3 network driver [1] ps3: gigabit ethernet driver for PS3 [2] ps3: add wireless LAN support for PS3 They are submitted for review since some of the underlying infrastructure code hasn't been submitted yet. For reference, you can take a look at Geoff's git tree (git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git). I appreciate your comments. -- Masakazu MOKUNO - 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/5] NetXen: Bug fixes and updates
Hi All, I will be sending bug fixes and updates to NetXen's 1/10G Ethernet driver in subsequent mails. These patches are wrt netdev#master. Regards, Mithlesh Thukral - 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/5] NetXen: Removal of extra free_irq call
NetXen: Removal of redundant free_irq
This patch removes a redundant free_irq() call from remove() routine.
This will also eliminate a warning during unload of driver.
Signed-by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic_main.c |2 --
1 files changed, 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c
b/drivers/net/netxen/netxen_nic_main.c
index 2c5c6d2..c61181f 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -654,8 +654,6 @@ static void __devexit netxen_nic_remove(
if (adapter-portnum == 0)
netxen_free_adapter_offload(adapter);
- if (adapter-irq)
- free_irq(adapter-irq, adapter);
if(adapter-portnum == 0) {
/* leave the hw in the same state as reboot */
writel(0, NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
-
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 0/2] RFC: PS3 network driver
On Fri, Jun 01, 2007 at 02:31:54PM +0900, MOKUNO Masakazu wrote: Hi This is the first submission of the PS3 network driver [1] ps3: gigabit ethernet driver for PS3 What happened to the idea of incorporating support into spidernet? - 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: [Oops] unix_dgram_connect locking problem?
On Thu, May 31, 2007 at 03:22:27PM -0700, David Miller wrote:
From: Frederik Deweerdt [EMAIL PROTECTED]
Date: Fri, 11 May 2007 17:00:14 +0200
I'm seeing an Oops[1] with a 2.6.19.2 kernel:
Frederik, I finally was able to spend some quality time on
this issue today. Sorry for taking so long.
Thank you for handling this David. I going to be offline for two weeks,
but I'll be able to report tests results after that.
Regards,
Frederik
I came up with a series of two patches, the first one makes
the locking easier to understand by fixing the unix_sock_*()
lock macro names.
The second patch fixes this race conditon by properly holding
both socket locks, being careful to avoid deadlocks, and
checking for possible SOCK_DEAD state.
commit d410b81b4eef2e4409f9c38ef201253fbbcc7d94
Author: David S. Miller [EMAIL PROTECTED]
Date: Thu May 31 13:24:26 2007 -0700
[AF_UNIX]: Make socket locking much less confusing.
The unix_state_*() locking macros imply that there is some
rwlock kind of thing going on, but the implementation is
actually a spinlock which makes the code more confusing than
it needs to be.
So use plain unix_state_lock and unix_state_unlock.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index c0398f5..65f49fd 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -62,13 +62,11 @@ struct unix_skb_parms {
#define UNIXCREDS(skb) (UNIXCB((skb)).creds)
#define UNIXSID(skb) (UNIXCB((skb)).secid)
-#define unix_state_rlock(s) spin_lock(unix_sk(s)-lock)
-#define unix_state_runlock(s)spin_unlock(unix_sk(s)-lock)
-#define unix_state_wlock(s) spin_lock(unix_sk(s)-lock)
-#define unix_state_wlock_nested(s) \
+#define unix_state_lock(s) spin_lock(unix_sk(s)-lock)
+#define unix_state_unlock(s) spin_unlock(unix_sk(s)-lock)
+#define unix_state_lock_nested(s) \
spin_lock_nested(unix_sk(s)-lock, \
SINGLE_DEPTH_NESTING)
-#define unix_state_wunlock(s)spin_unlock(unix_sk(s)-lock)
#ifdef __KERNEL__
/* The AF_UNIX socket */
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index fc12ba5..453ede8 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -174,11 +174,11 @@ static struct sock *unix_peer_get(struct sock *s)
{
struct sock *peer;
- unix_state_rlock(s);
+ unix_state_lock(s);
peer = unix_peer(s);
if (peer)
sock_hold(peer);
- unix_state_runlock(s);
+ unix_state_unlock(s);
return peer;
}
@@ -369,7 +369,7 @@ static int unix_release_sock (struct sock *sk, int
embrion)
unix_remove_socket(sk);
/* Clear state */
- unix_state_wlock(sk);
+ unix_state_lock(sk);
sock_orphan(sk);
sk-sk_shutdown = SHUTDOWN_MASK;
dentry = u-dentry;
@@ -378,7 +378,7 @@ static int unix_release_sock (struct sock *sk, int
embrion)
u-mnt = NULL;
state = sk-sk_state;
sk-sk_state = TCP_CLOSE;
- unix_state_wunlock(sk);
+ unix_state_unlock(sk);
wake_up_interruptible_all(u-peer_wait);
@@ -386,12 +386,12 @@ static int unix_release_sock (struct sock *sk, int
embrion)
if (skpair!=NULL) {
if (sk-sk_type == SOCK_STREAM || sk-sk_type ==
SOCK_SEQPACKET) {
- unix_state_wlock(skpair);
+ unix_state_lock(skpair);
/* No more writes */
skpair-sk_shutdown = SHUTDOWN_MASK;
if (!skb_queue_empty(sk-sk_receive_queue) || embrion)
skpair-sk_err = ECONNRESET;
- unix_state_wunlock(skpair);
+ unix_state_unlock(skpair);
skpair-sk_state_change(skpair);
read_lock(skpair-sk_callback_lock);
sk_wake_async(skpair,1,POLL_HUP);
@@ -448,7 +448,7 @@ static int unix_listen(struct socket *sock, int backlog)
err = -EINVAL;
if (!u-addr)
goto out; /* No listens on an unbound
socket */
- unix_state_wlock(sk);
+ unix_state_lock(sk);
if (sk-sk_state != TCP_CLOSE sk-sk_state != TCP_LISTEN)
goto out_unlock;
if (backlog sk-sk_max_ack_backlog)
@@ -462,7 +462,7 @@ static int unix_listen(struct socket *sock, int backlog)
err = 0;
out_unlock:
- unix_state_wunlock(sk);
+ unix_state_unlock(sk);
out:
return err;
}
@@ -881,7 +881,7 @@ static int unix_dgram_connect(struct socket *sock, struct
sockaddr *addr,
if (!other)
goto out;
- unix_state_wlock(sk);
+ unix_state_lock(sk);
err = -EPERM;
if (!unix_may_send(sk, other))
@@ -896,7
Re: Suspicious fackets_out handling
On Thu, 31 May 2007, David Miller wrote:
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 23 Apr 2007 14:28:21 +0300 (EEST)
There are IMHO two problems in it. First of all, nothing ensures that the
skb TCP is fragmenting is actually below the forwardmost sack block (and
thus is included to the fackets_out)...
...this is so old thing already that I had to refresh my memory,
haven't been expecting any answer for ages... :-)
Good catch, I agree with your analysis completely.
...I later on understood (from a comment I found elsewhere) that
fackets_out is occasionally estimated, rather than exact value (which
could be completely fixed in tcp-2.6 due to presence of highest_sack but
I'm also considering complete removal of it too, like you probably
noticed).
What I'm not sure of though, is how to fix this in net-2.6(.22), it
is due to the fact that there is no pointer/seq which can be used in
testing for it like in tcp-2.6 which has the highest_sack.
We can add highest_sack to 2.6.22 in order to fix a bug like this,
if necessary.
...I think we can leave it as estimate for now, it has been like that
for years and nobody has complained... :-) This problem covers really
marginal number of cases anyway I think (isn't the diff usually
negative: old - new after fragment should be negative unless mss_now
bites).
After I found the comments and analyzed some sacked_out code with NewReno,
I think that usually these estimates are indicated in the code with
tcp_dec_pcount_approx(...) but it wasn't used in this specific case
because it inputs skb instead of int, I'll add clarification of this into
my tcp-2.6 todo list...
Second problem is even more obvious: if adjustment here is being
done and the sacktag code then uses fastpath at the arrival of the
next ACK, the sacktag code will use a stale value from
fastpath_cnt_hint and fails to notice all that math TCP did here
unless we start clearing fastpath_skb_hint.
Let's try not to clear fastpath_skb_hint here if possible :-)
Np, however, whatever we do, it wouldn't really execute that
often... :-)
Is it possible to update fastpath_cnt_hint properly perhaps?
I think that would be valid and even accurate as it can checks skb's
seq against fastpath_skb_hint-seq. I'm in a hurry and will be a week
out of reach of internet connectivity but here's quick attempt to deal
with this cleanly. Compile tested (be extra careful with this one, it's
done i a hurry :-)), consider to net-2.6. Considering the marginality of
this issue, stable might really be an overkill for this one, only a
remotely valid concern comes to my mind in this case: possibility
of fackets_out packet_out might not be dealt that cleanly everywhere
(but I'm sure that you can come to a good decicion about it):
[PATCH] [TCP]: SACK fastpath did override adjusted fackets_out
Do same adjustment to SACK fastpath counters provided that
they're valid.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_output.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 53232dd..f24dd36 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -699,6 +699,15 @@ int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32
len, unsigned int mss
tp-fackets_out -= diff;
if ((int)tp-fackets_out 0)
tp-fackets_out = 0;
+ /* SACK fastpath might overwrite it unless dealt with */
+ if (tp-fastpath_skb_hint != NULL
+ after(TCP_SKB_CB(tp-fastpath_skb_hint)-seq,
+ TCP_SKB_CB(skb)-seq)) {
+ tp-fastpath_cnt_hint -= diff;
+ if ((int)tp-fastpath_cnt_hint 0)
+ tp-fastpath_cnt_hint = 0;
+
+ }
}
}
--
1.5.0.6
Re: [PATCH 2/5] NetXen: Multicast filter for NetXen driver
On Friday 01 June 2007 13:14:35 Mithlesh Thukral wrote:
NetXen: Add multicast filter code
This patch will add manage the multicast filter from driver.
It will add capability to write multicast addresses to hardware.
Signed-by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h | 24 +
drivers/net/netxen/netxen_nic_hdr.h |3
drivers/net/netxen/netxen_nic_hw.c | 115 +-
3 files changed, 139 insertions(+), 3 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index ad6688e..c74402f 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -261,6 +261,27 @@ #define netxen_set_msg_ctxid(config_word
#define netxen_set_msg_opcode(config_word, val) \
((config_word) = ~(0xf28), (config_word) |= (val 0xf) 28)
+#define netxen_set_addr_ctl_id_pool0(config_word, val) \
+ ((config_word) = ~3, (config_word) |= val 0x3)
+#define netxen_set_addr_ctl_enable_xtnd_0(config_word) \
+ ((config_word) |= 1 2)
+#define netxen_set_addr_ctl_id_pool1(config_word, val) \
+ ((config_word) = ~(0x34), (config_word) |= (val 0x3) 4)
+#define netxen_set_addr_ctl_enable_xtnd_1(config_word) \
+ ((config_word) |= 1 6)
+#define netxen_set_addr_ctl_id_pool2(config_word, val) \
+ ((config_word) = ~(0x38), (config_word) |= (val 0x3) 8)
+#define netxen_set_addr_ctl_enable_xtnd_2(config_word) \
+ ((config_word) |= 1 10)
+#define netxen_set_addr_ctl_id_pool3(config_word, val) \
+ ((config_word) = ~(0x312), (config_word) |= (val 0x3) 12)
+#define netxen_set_addr_ctl_enable_xtnd_3(config_word) \
+ ((config_word) |= 1 14)
+#define netxen_set_addr_ctl_mode(config_word, val) \
+ ((config_word) = ~(0x326), (config_word) |= (val 0x3) 26)
+#define netxen_set_addr_ctl_enable_poll(config_word, val)\
+ ((config_word) = ~(0xf30), (config_word) |= (val 0xf) 30)
+
struct netxen_rcv_context {
__le64 rcv_ring_addr;
__le32 rcv_ring_size;
@@ -883,6 +904,9 @@ struct netxen_adapter {
unsigned char mac_addr[ETH_ALEN];
int mtu;
int portnum;
+ u8 promisc;
+ u8 mc_enabled;
+ u8 max_mc_count;
spinlock_t tx_lock;
spinlock_t lock;
diff --git a/drivers/net/netxen/netxen_nic_hdr.h
b/drivers/net/netxen/netxen_nic_hdr.h
index 608e37b..2bfecbc 100644
--- a/drivers/net/netxen/netxen_nic_hdr.h
+++ b/drivers/net/netxen/netxen_nic_hdr.h
@@ -545,6 +545,9 @@ #define NETXEN_MULTICAST_ADDR_HI_1(NETX
#define NETXEN_MULTICAST_ADDR_HI_2 (NETXEN_CRB_NIU + 0x1018)
#define NETXEN_MULTICAST_ADDR_HI_3 (NETXEN_CRB_NIU + 0x101c)
+#define NETXEN_UNICAST_ADDR_BASE (NETXEN_CRB_NIU + 0x1080)
+#define NETXEN_MULTICAST_ADDR_BASE (NETXEN_CRB_NIU + 0x1100)
+
#define NETXEN_NIU_GB_MAC_CONFIG_0(I) \
(NETXEN_CRB_NIU + 0x3 + (I)*0x1)
#define NETXEN_NIU_GB_MAC_CONFIG_1(I) \
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index baff17a..fff3844 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -303,6 +303,93 @@ int netxen_nic_set_mac(struct net_device
return 0;
}
+#define NETXEN_UNICAST_ADDR(port, index) \
+ (NETXEN_UNICAST_ADDR_BASE+(port*32)+(index*8))
+
+int netxen_nic_enable_mcast_filter(struct netxen_adapter *adapter)
+{
+ u32 val = 0;
+ u16 port = physical_port[adapter-portnum];
+
+ if (adapter-mc_enabled)
+ return 0;
+
+ netxen_set_addr_ctl_enable_poll(val, 0xf);
+
+ if (adapter-ahw.board_type == NETXEN_NIC_XGBE)
+ netxen_set_addr_ctl_mode(val, 0x3);
+ else
+ netxen_set_addr_ctl_mode(val, 0x0);
+
+ netxen_set_addr_ctl_id_pool0(val, 0x0);
+ netxen_set_addr_ctl_id_pool1(val, 0x1);
+ netxen_set_addr_ctl_id_pool2(val, 0x2);
+ netxen_set_addr_ctl_id_pool3(val, 0x3);
+
+ netxen_set_addr_ctl_enable_xtnd_0(val);
+ netxen_set_addr_ctl_enable_xtnd_1(val);
+ netxen_set_addr_ctl_enable_xtnd_2(val);
+ netxen_set_addr_ctl_enable_xtnd_3(val);
+
+ netxen_crb_writelit_adapter(adapter, NETXEN_MAC_ADDR_CNTL_REG, val);
+
+ val = 0xff;
+
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,0), val);
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,0)+4,
+ val);
+
+ memcpy(val, adapter-mac_addr, 3);
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,1), val);
+
+ memcpy(val, adapter-mac_addr+3, 3);
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,1) + 4,
+ val);
+
+ adapter-mc_enabled = 1;
+ return 0;
+}
+
+int netxen_nic_disable_mcast_filter(struct
Re: [PATCH] [TCP]: Fix GSO ignorance of pkts_acked arg (cong.cntrl modules)
On Thu, 31 May 2007, David Miller wrote: From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Wed, 30 May 2007 12:10:06 +0300 (EEST) [PATCH] [TCP]: Fix GSO ignorance of pkts_acked arg (cong.cntrl modules) The code used to ignore GSO completely, passing either way too small or zero pkts_acked when GSO skb or part of it got ACKed. In addition, there is no need to calculate the value in the loop but simple arithmetics after the loop is sufficient. There is no need to handle SYN case specially because congestion control modules are not yet initialized when FLAG_SYN_ACKED is set. Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] Patch applied, thanks a lot! ...It's good to be on the alert with this one because it might uncover some hidden bugs from congestion control module code (it changes some behavior so radically), which obviously will have to be then fixed too... -- i.
[PATCH 4/5] NetXen: Fix ping issue
NetXen: Fix initialization and subsequent ping issue
This patch will fix the initialization and ping issues seen on
certain PPC architecture blades.
Signed-off by: Wen Xiong [EMAIL PROTECTED]
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic_main.c |7 +++
drivers/net/netxen/netxen_nic_niu.c |8 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c
b/drivers/net/netxen/netxen_nic_main.c
index c61181f..6167b58 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -542,6 +542,13 @@ #endif
NETXEN_ROMUSB_GLB_PEGTUNE_DONE));
/* Handshake with the card before we register the devices. */
netxen_phantom_init(adapter, NETXEN_NIC_PEG_TUNE);
+
+ /* leave the hw in the same state as reboot */
+ writel(0, NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+ netxen_pinit_from_rom(adapter, 0);
+ udelay(500);
+ netxen_load_firmware(adapter);
+ netxen_phantom_init(adapter, NETXEN_NIC_PEG_TUNE);
}
/*
diff --git a/drivers/net/netxen/netxen_nic_niu.c
b/drivers/net/netxen/netxen_nic_niu.c
index cef90a7..75102d3 100644
--- a/drivers/net/netxen/netxen_nic_niu.c
+++ b/drivers/net/netxen/netxen_nic_niu.c
@@ -454,16 +454,12 @@ int netxen_niu_gbe_init_port(struct netx
int netxen_niu_xg_init_port(struct netxen_adapter *adapter, int port)
{
- u32 reg;
u32 portnum = physical_port[adapter-portnum];
netxen_crb_writelit_adapter(adapter,
- NETXEN_NIU_XGE_CONFIG_0+(0x1*portnum), 0x5);
- netxen_nic_hw_read_wx(adapter,
- NETXEN_NIU_XGE_CONFIG_1+(0x1*portnum), reg, 4);
- reg = (reg ~0x2000UL);
+ NETXEN_NIU_XGE_CONFIG_1+(0x1*portnum), 0x1447);
netxen_crb_writelit_adapter(adapter,
- NETXEN_NIU_XGE_CONFIG_1+(0x1*portnum), reg);
+ NETXEN_NIU_XGE_CONFIG_0+(0x1*portnum), 0x5);
return 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 2/5] NetXen: Multicast filter for NetXen driver
NetXen: Add multicast filter code
This patch will add manage the multicast filter from driver.
It will add capability to write multicast addresses to hardware.
Signed-by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h | 24 +
drivers/net/netxen/netxen_nic_hdr.h |3
drivers/net/netxen/netxen_nic_hw.c | 115 +-
3 files changed, 139 insertions(+), 3 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index ad6688e..c74402f 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -261,6 +261,27 @@ #define netxen_set_msg_ctxid(config_word
#define netxen_set_msg_opcode(config_word, val)\
((config_word) = ~(0xf28), (config_word) |= (val 0xf) 28)
+#define netxen_set_addr_ctl_id_pool0(config_word, val) \
+ ((config_word) = ~3, (config_word) |= val 0x3)
+#define netxen_set_addr_ctl_enable_xtnd_0(config_word) \
+ ((config_word) |= 1 2)
+#define netxen_set_addr_ctl_id_pool1(config_word, val) \
+ ((config_word) = ~(0x34), (config_word) |= (val 0x3) 4)
+#define netxen_set_addr_ctl_enable_xtnd_1(config_word) \
+ ((config_word) |= 1 6)
+#define netxen_set_addr_ctl_id_pool2(config_word, val) \
+ ((config_word) = ~(0x38), (config_word) |= (val 0x3) 8)
+#define netxen_set_addr_ctl_enable_xtnd_2(config_word) \
+ ((config_word) |= 1 10)
+#define netxen_set_addr_ctl_id_pool3(config_word, val) \
+ ((config_word) = ~(0x312), (config_word) |= (val 0x3) 12)
+#define netxen_set_addr_ctl_enable_xtnd_3(config_word) \
+ ((config_word) |= 1 14)
+#define netxen_set_addr_ctl_mode(config_word, val) \
+ ((config_word) = ~(0x326), (config_word) |= (val 0x3) 26)
+#define netxen_set_addr_ctl_enable_poll(config_word, val) \
+ ((config_word) = ~(0xf30), (config_word) |= (val 0xf) 30)
+
struct netxen_rcv_context {
__le64 rcv_ring_addr;
__le32 rcv_ring_size;
@@ -883,6 +904,9 @@ struct netxen_adapter {
unsigned char mac_addr[ETH_ALEN];
int mtu;
int portnum;
+ u8 promisc;
+ u8 mc_enabled;
+ u8 max_mc_count;
spinlock_t tx_lock;
spinlock_t lock;
diff --git a/drivers/net/netxen/netxen_nic_hdr.h
b/drivers/net/netxen/netxen_nic_hdr.h
index 608e37b..2bfecbc 100644
--- a/drivers/net/netxen/netxen_nic_hdr.h
+++ b/drivers/net/netxen/netxen_nic_hdr.h
@@ -545,6 +545,9 @@ #define NETXEN_MULTICAST_ADDR_HI_1 (NETX
#define NETXEN_MULTICAST_ADDR_HI_2 (NETXEN_CRB_NIU + 0x1018)
#define NETXEN_MULTICAST_ADDR_HI_3 (NETXEN_CRB_NIU + 0x101c)
+#define NETXEN_UNICAST_ADDR_BASE (NETXEN_CRB_NIU + 0x1080)
+#define NETXEN_MULTICAST_ADDR_BASE (NETXEN_CRB_NIU + 0x1100)
+
#defineNETXEN_NIU_GB_MAC_CONFIG_0(I) \
(NETXEN_CRB_NIU + 0x3 + (I)*0x1)
#defineNETXEN_NIU_GB_MAC_CONFIG_1(I) \
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index baff17a..fff3844 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -303,6 +303,93 @@ int netxen_nic_set_mac(struct net_device
return 0;
}
+#define NETXEN_UNICAST_ADDR(port, index) \
+ (NETXEN_UNICAST_ADDR_BASE+(port*32)+(index*8))
+
+int netxen_nic_enable_mcast_filter(struct netxen_adapter *adapter)
+{
+ u32 val = 0;
+ u16 port = physical_port[adapter-portnum];
+
+ if (adapter-mc_enabled)
+ return 0;
+
+ netxen_set_addr_ctl_enable_poll(val, 0xf);
+
+ if (adapter-ahw.board_type == NETXEN_NIC_XGBE)
+ netxen_set_addr_ctl_mode(val, 0x3);
+ else
+ netxen_set_addr_ctl_mode(val, 0x0);
+
+ netxen_set_addr_ctl_id_pool0(val, 0x0);
+ netxen_set_addr_ctl_id_pool1(val, 0x1);
+ netxen_set_addr_ctl_id_pool2(val, 0x2);
+ netxen_set_addr_ctl_id_pool3(val, 0x3);
+
+ netxen_set_addr_ctl_enable_xtnd_0(val);
+ netxen_set_addr_ctl_enable_xtnd_1(val);
+ netxen_set_addr_ctl_enable_xtnd_2(val);
+ netxen_set_addr_ctl_enable_xtnd_3(val);
+
+ netxen_crb_writelit_adapter(adapter, NETXEN_MAC_ADDR_CNTL_REG, val);
+
+ val = 0xff;
+
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,0), val);
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,0)+4,
+ val);
+
+ memcpy(val, adapter-mac_addr, 3);
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,1), val);
+
+ memcpy(val, adapter-mac_addr+3, 3);
+ netxen_crb_writelit_adapter(adapter, NETXEN_UNICAST_ADDR(port,1) + 4,
+ val);
+
+ adapter-mc_enabled = 1;
+ return 0;
+}
+
+int netxen_nic_disable_mcast_filter(struct netxen_adapter *adapter)
+{
+ u32 val = 0;
+ u16 port = physical_port[adapter-portnum];
+
+
[PATCH 5/5] NetXen: Fix link status messages
NetXen: Correct link status messages.
This patch will fix the problem of wrong link status messages
that were reported.
Signed-off by: Wen Xiong [EMAIL PROTECTED]
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
drivers/net/netxen/netxen_nic.h |1 +
drivers/net/netxen/netxen_nic_init.c | 21 +
drivers/net/netxen/netxen_nic_isr.c | 23 +++
3 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 6ce6e99..b8a5d51 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -1072,6 +1072,7 @@ int netxen_rom_se(struct netxen_adapter
int netxen_do_rom_se(struct netxen_adapter *adapter, int addr);
/* Functions from netxen_nic_isr.c */
+int netxen_nic_link_ok(struct netxen_adapter *adapter);
void netxen_nic_isr_other(struct netxen_adapter *adapter);
void netxen_indicate_link_status(struct netxen_adapter *adapter, u32 link);
void netxen_handle_port_int(struct netxen_adapter *adapter, u32 enable);
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index ac93987..0d875c0 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -1036,18 +1036,23 @@ void netxen_watchdog_task(struct work_st
if ((adapter-portnum == 0) netxen_nic_check_temp(adapter))
return;
+ if (adapter-handle_phy_intr)
+ adapter-handle_phy_intr(adapter);
+
netdev = adapter-netdev;
- if ((netif_running(netdev)) !netif_carrier_ok(netdev)) {
- printk(KERN_INFO %s port %d, %s carrier is now ok\n,
- netxen_nic_driver_name, adapter-portnum, netdev-name);
+ if ((netdev-flags IFF_UP) !netif_carrier_ok(netdev)
+ netxen_nic_link_ok(adapter) ) {
+ printk(KERN_INFO %s %s (port %d), Link is up\n,
+ netxen_nic_driver_name, netdev-name,
adapter-portnum);
netif_carrier_on(netdev);
- }
-
- if (netif_queue_stopped(netdev))
netif_wake_queue(netdev);
+ } else if(!(netdev-flags IFF_UP) netif_carrier_ok(netdev)) {
+ printk(KERN_ERR %s %s Link is Down\n,
+ netxen_nic_driver_name, netdev-name);
+ netif_carrier_off(netdev);
+ netif_stop_queue(netdev);
+ }
- if (adapter-handle_phy_intr)
- adapter-handle_phy_intr(adapter);
mod_timer(adapter-watchdog_timer, jiffies + 2 * HZ);
}
diff --git a/drivers/net/netxen/netxen_nic_isr.c
b/drivers/net/netxen/netxen_nic_isr.c
index b213b06..3605ce2 100644
--- a/drivers/net/netxen/netxen_nic_isr.c
+++ b/drivers/net/netxen/netxen_nic_isr.c
@@ -169,6 +169,23 @@ void netxen_nic_gbe_handle_phy_intr(stru
netxen_nic_isr_other(adapter);
}
+int netxen_nic_link_ok(struct netxen_adapter *adapter)
+{
+ switch (adapter-ahw.board_type) {
+ case NETXEN_NIC_GBE:
+ return ((adapter-ahw.qg_linksup) 1);
+
+ case NETXEN_NIC_XGBE:
+ return ((adapter-ahw.xg_linkup) 1);
+
+ default:
+ printk(KERN_ERR%s: Function: %s, Unknown board type\n,
+ netxen_nic_driver_name, __FUNCTION__);
+ break;
+ }
+ return 0;
+}
+
void netxen_nic_xgbe_handle_phy_intr(struct netxen_adapter *adapter)
{
struct net_device *netdev = adapter-netdev;
@@ -183,6 +200,10 @@ void netxen_nic_xgbe_handle_phy_intr(str
printk(KERN_INFO %s: %s NIC Link is down\n,
netxen_nic_driver_name, netdev-name);
adapter-ahw.xg_linkup = 0;
+ if (netif_running(netdev)) {
+ netif_carrier_off(netdev);
+ netif_stop_queue(netdev);
+ }
/* read twice to clear sticky bits */
/* WINDOW = 0 */
netxen_nic_read_w0(adapter, NETXEN_NIU_XG_STATUS, val1);
@@ -196,5 +217,7 @@ void netxen_nic_xgbe_handle_phy_intr(str
printk(KERN_INFO %s: %s NIC Link is up\n,
netxen_nic_driver_name, netdev-name);
adapter-ahw.xg_linkup = 1;
+ netif_carrier_on(netdev);
+ netif_wake_queue(netdev);
}
}
-
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: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers are removed
Hi,
On Friday 01 June 2007 01:18, Julian Anastasov wrote:
What about something like this, it even reduces checks
in the fast path. You can post new version if the following change
looks good to you and to other developers. If additional sign line is
needed here it is:
Signed-off-by: Julian Anastasov [EMAIL PROTECTED]
[...]
Or we can go further and to avoid ip_dev_find? For me, this
second variant is preferred because calling ip_dev_find() is useless
for FLOWI_FLAG_ANYSRC.
You're right. Although I don't really like duplicating the ip_dev_find()
call, it's still better than the previous patch.
--
Regards,
Krisztian Kovacs
Loosen source address check on IPv4 output
ip_route_output() contains a check to make sure that no flows with
non-local source IP addresses are routed. This obviously makes using
such addresses impossible.
This patch introduces a flowi flag which makes omitting this check
possible.
Signed-off-by: KOVACS Krisztian [EMAIL PROTECTED]
Signed-off-by: Julian Anastasov [EMAIL PROTECTED]
---
include/net/flow.h |1 +
net/ipv4/route.c | 20 +---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index f3cc1f8..1bfc0dc 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -49,6 +49,7 @@ struct flowi {
__u8proto;
__u8flags;
#define FLOWI_FLAG_MULTIPATHOLDROUTE 0x01
+#define FLOWI_FLAG_ANYSRC 0x02
union {
struct {
__be16 sport;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 8603cfb..4acd3de 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2394,11 +2394,6 @@ static int ip_route_output_slow(struct rtable **rp,
const struct flowi *oldflp)
ZERONET(oldflp-fl4_src))
goto out;
- /* It is equivalent to inet_addr_type(saddr) == RTN_LOCAL */
- dev_out = ip_dev_find(oldflp-fl4_src);
- if (dev_out == NULL)
- goto out;
-
/* I removed check for oif == dev_out-oif here.
It was wrong for two reasons:
1. ip_dev_find(saddr) can return wrong iface, if saddr is
@@ -2409,6 +2404,11 @@ static int ip_route_output_slow(struct rtable **rp,
const struct flowi *oldflp)
if (oldflp-oif == 0
(MULTICAST(oldflp-fl4_dst) || oldflp-fl4_dst ==
htonl(0x))) {
+ /* It is equivalent to inet_addr_type(saddr) ==
RTN_LOCAL */
+ dev_out = ip_dev_find(oldflp-fl4_src);
+ if (dev_out == NULL)
+ goto out;
+
/* Special hack: user can direct multicasts
and limited broadcast via necessary interface
without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
@@ -2427,9 +2427,15 @@ static int ip_route_output_slow(struct rtable **rp,
const struct flowi *oldflp)
fl.oif = dev_out-ifindex;
goto make_route;
}
- if (dev_out)
+
+ if (!(oldflp-flags FLOWI_FLAG_ANYSRC)) {
+ /* It is equivalent to inet_addr_type(saddr) ==
RTN_LOCAL */
+ dev_out = ip_dev_find(oldflp-fl4_src);
+ if (dev_out == NULL)
+ goto out;
dev_put(dev_out);
- dev_out = NULL;
+ dev_out = NULL;
+ }
}
-
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 5/7] CAN: Add virtual CAN netdevice driver
Oliver Hartkopp wrote: Patrick McHardy wrote: Urs Thuermann wrote: +/* tx socket reference pointer: Loopback required if not NULL */ +loop = *(struct sock **)skb-cb != NULL; Qdiscs might change skb-cb. Maybe use skb-sk? due to current projects Urs and me had only a short time today to discuss the use of other skbuff-elements to implement the needed loopback functionality. Urs remembered that the value of skb-sk was not 'stable' in the whole loopback and therefore the use of skb-cb was a reasonable approach - and it was indeed working. Btw. triggered by your remark, we're looking for alternatives. Yes, its working, but only in certain combinations and you're breaking the rules for skb-cb, making it impossible for other layers to use. skb-sk is stable at the output path, the regular loopback device orphans the skb in hard_start_xmit. So you can at least use it there. Another thing is, that i would like to know, if Qdiscs would ever touch skb's containing CAN-frames?!? The MTU is 16 bytes (sizeof(struct can_frame)) and each skb contains exact one CAN-frame. What would a packet scheduler do with these skb's? IMO there is nothing that could be optimized and linked together like in IPv4 / IPv6 data. Qdiscs don't care about the content. If a user attaches one to your device, it will get used. Would therefore skb-cb left unchanged in my skb's? Or is there any flag that can be set in the skb to keep the packet scheduler's hands off? No, and I don't think we want a flag to signal that something is violating the rules for skb-cb, there are other users of this besides qdiscs. - 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
[RFC] [XFRM] SAD only lookup
Folks,
shit happened and my old hard-drive was whipped containing my old
ipsec pktgen patches. I am now trying to recover them.
Luckily, this one patch i sent on email - so it was an easy recovery.
I know James and Herbert had both commented in the past on this patch.
Please look at it again and see if i am missing something we agreed on.
Herbert, I cant see any easier way to do the SAD lookup. If you have
suggestions please shoot. I am shooting for this to go in when 2.6.23
opens up.
cheers,
jamal
commit 707411e190af516cefdc3315183d023fde54d53e
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Fri Jun 1 10:49:43 2007 -0400
[XFRM] Introduce standalone SAD lookup
This allows other in-kernel functions to do SAD lookups.
The only known user at the moment is pktgen.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 39ef925..e89cf7e 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -921,6 +921,10 @@ extern struct xfrm_state *xfrm_state_find(xfrm_address_t
*daddr, xfrm_address_t
struct flowi *fl, struct xfrm_tmpl
*tmpl,
struct xfrm_policy *pol, int *err,
unsigned short family);
+extern struct xfrm_state * xfrm_stateonly_find(xfrm_address_t *daddr,
+ xfrm_address_t *saddr,
+ unsigned short family,
+ u8 mode, u8 proto, u32 reqid);
extern int xfrm_state_check_expire(struct xfrm_state *x);
extern void xfrm_state_insert(struct xfrm_state *x);
extern int xfrm_state_add(struct xfrm_state *x);
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9955ff4..a2d8f64 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -643,6 +643,40 @@ out:
return x;
}
+struct xfrm_state *
+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
+ unsigned short family, u8 mode, u8 proto, u32 reqid)
+{
+ unsigned int h = xfrm_dst_hash(daddr, saddr, reqid, family);
+ struct xfrm_state *rx = NULL, *x = NULL;
+ struct hlist_node *entry;
+
+ spin_lock(xfrm_state_lock);
+ hlist_for_each_entry(x, entry, xfrm_state_bydst+h, bydst) {
+ if (x-props.family == family
+ x-props.reqid == reqid
+ !(x-props.flags XFRM_STATE_WILDRECV)
+ xfrm_state_addr_check(x, daddr, saddr, family)
+ mode == x-props.mode
+ proto == x-id.proto) {
+
+ if (x-km.state != XFRM_STATE_VALID)
+ continue;
+ else {
+ rx = x;
+ break;
+ }
+ }
+ }
+ spin_unlock(xfrm_state_lock);
+
+ if (rx)
+ xfrm_state_hold(rx);
+
+ return rx;
+}
+EXPORT_SYMBOL(xfrm_stateonly_find);
+
static void __xfrm_state_insert(struct xfrm_state *x)
{
unsigned int h;
Re: [PATCH]: sky2: Fix VLAN unregistration
Stephen Hemminger wrote: On Thu, 31 May 2007 19:37:07 +0200 Patrick McHardy [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: On Sun, 27 May 2007 20:44:04 +0200 Patrick McHardy [EMAIL PROTECTED] wrote: Fix sky2 disabling VLAN completely when the first vid is unregistered. For some reason the VLAN code insists on the driver providing a vlan_rx_kill_vid function even if only NETIF_F_HW_VLAN_RX and not NETIF_F_HW_VLAN_FILTER is set, so this patch keeps an empty function. This seems to be a bug though, vlan_rx_add_vid is only required with NETIF_F_HW_VLAN_FILTER. Ben? Reading other drivers, it looks like a better patch would be to handle mode change in both set and kill. The VLAN code tracks registered VIDs and will always call vlan_rx_register(NULL) when the last VID is unregistered, so this is not necessary. Then should others be fixed... tg3, bnx2, r8169, gianfar, s2io, 8139cp, acenic, ... tg3 and r8169 both look fine, they only unregister a single VID within kill_vid and rely on VLAN to call rx_register(NULL) when the group is unregistered (haven't looked at the others). As I wrote in my previous mails, they do have a part that looks unnecessary tg3_full_lock(tp, 0); vlan_group_set_device(tp-vlgrp, vid, NULL); tg3_full_unlock(tp); since the vid is also removed by the VLAN code itself and locking doesn't seem to be necessary because the VLAN hwaccel rx helper deals with removal races itself. - 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
[TCP]: Honour sk_bound_dev_if in tcp_v4_send_ack
[TCP]: Honour sk_bound_dev_if in tcp_v4_send_ack
A time_wait socket inherits sk_bound_dev_if from the original socket,
but it is not used when sending ACK packets using ip_send_reply.
Fix by passing the oif to ip_send_reply in struct ip_reply_arg and
use it for output routing.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 19b6cbad06d246d48168fc6c493a7c3d9db58e1f
tree a355cf3bf552a5fbab5b874f38a964f5f90a68c5
parent 184b812f7da6726d7ea4ca409c7a8762ff6c6df6
author Patrick McHardy [EMAIL PROTECTED] Fri, 01 Jun 2007 17:52:23 +0200
committer Patrick McHardy [EMAIL PROTECTED] Fri, 01 Jun 2007 17:52:23 +0200
include/net/ip.h |1 +
net/ipv4/ip_output.c |4 +++-
net/ipv4/tcp_ipv4.c |1 +
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index bb207db..abf2820 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -143,6 +143,7 @@ struct ip_reply_arg {
__wsum csum;
int csumoffset; /* u16 offset of csum in iov[0].iov_base */
/* -1 if not needed */
+ int bound_dev_if;
};
void ip_send_reply(struct sock *sk, struct sk_buff *skb, struct ip_reply_arg
*arg,
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index d6427d9..34ea454 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1352,7 +1352,8 @@ void ip_send_reply(struct sock *sk, struct sk_buff *skb,
struct ip_reply_arg *ar
}
{
- struct flowi fl = { .nl_u = { .ip4_u =
+ struct flowi fl = { .oif = arg-bound_dev_if,
+ .nl_u = { .ip4_u =
{ .daddr = daddr,
.saddr = rt-rt_spec_dst,
.tos = RT_TOS(ip_hdr(skb)-tos)
} },
@@ -1376,6 +1377,7 @@ void ip_send_reply(struct sock *sk, struct sk_buff *skb,
struct ip_reply_arg *ar
inet-tos = ip_hdr(skb)-tos;
sk-sk_priority = skb-priority;
sk-sk_protocol = ip_hdr(skb)-protocol;
+ sk-sk_bound_dev_if = arg-bound_dev_if;
ip_append_data(sk, ip_reply_glue_bits, arg-iov-iov_base, len, 0,
ipc, rt, MSG_DONTWAIT);
if ((skb = skb_peek(sk-sk_write_queue)) != NULL) {
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5a3e7f8..d3924c7 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -702,6 +702,7 @@ static void tcp_v4_send_ack(struct tcp_timewait_sock *twsk,
ip_hdr(skb)-saddr, /* XXX */
arg.iov[0].iov_len, IPPROTO_TCP, 0);
arg.csumoffset = offsetof(struct tcphdr, check) / 2;
+ arg.bound_dev_if = twsk-tw_sk.tw_bound_dev_if;
ip_send_reply(tcp_socket-sk, skb, arg, arg.iov[0].iov_len);
Re: [PATCH]: sky2: Fix VLAN unregistration
I am working on a multi-driver cleanup patch right now... - 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] NET: add MAINTAINERS entry for ucc_geth driver
On Fri, 25 May 2007 13:54:02 +0800 Li Yang [EMAIL PROTECTED] wrote: Signed-off-by: Li Yang [EMAIL PROTECTED] Acked-by: Kim Phillips [EMAIL PROTECTED] Kim - 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]: bonding: Fix 802.3ad no carrier on no partner found instance
%diff -ru linux-2.6.21.3/drivers/net/bonding/bond_3ad.c
linux-2.6.21.3.new/drivers/net/bonding/bond_3ad.c
--- linux-2.6.21.3/drivers/net/bonding/bond_3ad.c 2007-05-24
14:22:47.0 -0700
+++ linux-2.6.21.3.new/drivers/net/bonding/bond_3ad.c 2007-06-01
09:28:07.0 -0700
@@ -2312,10 +2312,7 @@
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- struct aggregator *agg;
-
- agg = __get_active_agg((SLAVE_AD_INFO(bond-first_slave).aggregator));
- if (agg MAC_ADDRESS_COMPARE(agg-partner_system, null_mac_addr)) {
+ if (__get_active_agg((SLAVE_AD_INFO(bond-first_slave).aggregator))) {
if (!netif_carrier_ok(bond-dev)) {
netif_carrier_on(bond-dev);
return 1;
On 5/31/07, Laurent Chavey [EMAIL PROTECTED] wrote:
if a host configured with 802.3ad bond mode is connected to a switch
that does not support 802.3ad, then an aggregator is selected as the
active aggregator (first link that has carrier in the slave list).
This is perfectly fine, since it lets at least one of the link become active.
(this was the behavior prior to 2.6.18)
In 2.6.18 and above, a new check for the partner mac address was added
before an aggregator's carrier is set on. If a host is configured as
previously
described, then no links will become active.
is that the intended behavior ?
-
in the scenario described here, the partner mac address is always set to NULL.
so the statement is always false.
if (agg MAC_ADDRESS_COMPARE(agg-partner_system, null_mac_addr)) {
if (!netif_carrier_ok(bond-dev)) {
netif_carrier_on(bond-dev);
return 1;
}
return 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
Re: [Cbe-oss-dev] [PATCH 0/2] RFC: PS3 network driver
Christoph Hellwig wrote: On Fri, Jun 01, 2007 at 02:31:54PM +0900, MOKUNO Masakazu wrote: Hi This is the first submission of the PS3 network driver [1] ps3: gigabit ethernet driver for PS3 What happened to the idea of incorporating support into spidernet? That is still our goal, but as a first step we want to at least get some Ethernet support included for end users. -Geoff - 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/5] VLAN driver API fixes
Patrick's fix for sky2 VLAN unregister, started me looking at other drivers. Many drivers had bogus kill_vid hooks, and the whole interface for kill_vid is only useful for devices that do receive filtering, so fix the interface and the drivers. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] VLAN: kill_vid is only useful for VLAN filtering devices
The interface for network device VLAN extension was confusing.
The kill_vid function is only really useful for devices that do
hardware filtering. Devices that only do VLAN receiption without
filtering were being forced to provide the hook, and there were
bugs in those devices.
Many drivers had kill_vid routine that called vlan_group_set_device, with
NULL, but that is done already.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/net/8021q/vlan.c 2007-06-01 08:18:32.0 -0700
+++ b/net/8021q/vlan.c 2007-06-01 08:28:02.0 -0700
@@ -240,10 +240,8 @@ static int unregister_vlan_dev(struct ne
* interlock with HW accelerating devices or SW vlan
* input packet processing.
*/
- if (real_dev-features
- (NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER)) {
+ if (real_dev-features NETIF_F_HW_VLAN_FILTER)
real_dev-vlan_rx_kill_vid(real_dev, vlan_id);
- }
vlan_group_set_device(grp, vlan_id, NULL);
synchronize_net();
@@ -409,16 +407,14 @@ static struct net_device *register_vlan_
}
if ((real_dev-features NETIF_F_HW_VLAN_RX)
- (real_dev-vlan_rx_register == NULL ||
-real_dev-vlan_rx_kill_vid == NULL)) {
+ !real_dev-vlan_rx_register) {
printk(VLAN_DBG %s: Device %s has buggy VLAN hw accel.\n,
__FUNCTION__, real_dev-name);
goto out_put_dev;
}
if ((real_dev-features NETIF_F_HW_VLAN_FILTER)
- (real_dev-vlan_rx_add_vid == NULL ||
-real_dev-vlan_rx_kill_vid == NULL)) {
+ (!real_dev-vlan_rx_add_vid || !real_dev-vlan_rx_kill_vid)) {
printk(VLAN_DBG %s: Device %s has buggy VLAN hw accel.\n,
__FUNCTION__, real_dev-name);
goto out_put_dev;
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] 8139cp: fix VLAN unregistration
The 8139cp driver did VLAN unregistration incorrectly.
It disables VLAN completely when the first VID is unregistered. It
should instead disable VLAN when the group is unregistered by calling
cp_vlan_rx_register with a NULL grp.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/8139cp.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
--- a/drivers/net/8139cp.c 2007-06-01 08:41:22.0 -0700
+++ b/drivers/net/8139cp.c 2007-06-01 08:41:31.0 -0700
@@ -435,20 +435,12 @@ static void cp_vlan_rx_register(struct n
spin_lock_irqsave(cp-lock, flags);
cp-vlgrp = grp;
- cp-cpcmd |= RxVlanOn;
- cpw16(CpCmd, cp-cpcmd);
- spin_unlock_irqrestore(cp-lock, flags);
-}
-
-static void cp_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
-{
- struct cp_private *cp = netdev_priv(dev);
- unsigned long flags;
+ if (grp)
+ cp-cpcmd |= RxVlanOn;
+ else
+ cp-cpcmd = ~RxVlanOn;
- spin_lock_irqsave(cp-lock, flags);
- cp-cpcmd = ~RxVlanOn;
cpw16(CpCmd, cp-cpcmd);
- vlan_group_set_device(cp-vlgrp, vid, NULL);
spin_unlock_irqrestore(cp-lock, flags);
}
#endif /* CP_VLAN_TAG_USED */
@@ -1944,7 +1936,6 @@ static int cp_init_one (struct pci_dev *
#if CP_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev-vlan_rx_register = cp_vlan_rx_register;
- dev-vlan_rx_kill_vid = cp_vlan_rx_kill_vid;
#endif
if (pci_using_dac)
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] network drivers: eliminate unneeded kill_vid code
Many drivers had code that did kill_vid, but they weren't doing vlan
filtering. With new API the stub is unneeded unless device sets
NETIF_F_HW_VLAN_FILTER.
Bad habit: I couldn't resist fixing a couple of nearby style things
in acenic, and forcedeth.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/acenic.c | 21 +++--
drivers/net/acenic.h |1 -
drivers/net/amd8111e.c | 11 +--
drivers/net/bnx2.c | 14 --
drivers/net/chelsio/cxgb2.c| 10 --
drivers/net/cxgb3/cxgb3_main.c |6 --
drivers/net/forcedeth.c|8 +---
drivers/net/gianfar.c | 16
drivers/net/ns83820.c | 12
drivers/net/r8169.c| 11 ---
drivers/net/s2io.c | 12
drivers/net/spider_net.c | 40
drivers/net/tg3.c | 16
drivers/net/typhoon.c | 11 +--
15 files changed, 7 insertions(+), 207 deletions(-)
--- a/drivers/net/acenic.c 2007-06-01 08:41:22.0 -0700
+++ b/drivers/net/acenic.c 2007-06-01 08:41:49.0 -0700
@@ -480,12 +480,10 @@ static int __devinit acenic_probe_one(st
#if ACENIC_DO_VLAN
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev-vlan_rx_register = ace_vlan_rx_register;
- dev-vlan_rx_kill_vid = ace_vlan_rx_kill_vid;
#endif
- if (1) {
- dev-tx_timeout = ace_watchdog;
- dev-watchdog_timeo = 5*HZ;
- }
+
+ dev-tx_timeout = ace_watchdog;
+ dev-watchdog_timeo = 5*HZ;
dev-open = ace_open;
dev-stop = ace_close;
@@ -2283,19 +2281,6 @@ static void ace_vlan_rx_register(struct
ace_unmask_irq(dev);
local_irq_restore(flags);
}
-
-
-static void ace_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
-{
- struct ace_private *ap = netdev_priv(dev);
- unsigned long flags;
-
- local_irq_save(flags);
- ace_mask_irq(dev);
- vlan_group_set_device(ap-vlgrp, vid, NULL);
- ace_unmask_irq(dev);
- local_irq_restore(flags);
-}
#endif /* ACENIC_DO_VLAN */
--- a/drivers/net/amd8111e.c2007-06-01 08:41:22.0 -0700
+++ b/drivers/net/amd8111e.c2007-06-01 09:01:39.0 -0700
@@ -1728,15 +1728,8 @@ static void amd8111e_vlan_rx_register(st
lp-vlgrp = grp;
spin_unlock_irq(lp-lock);
}
-
-static void amd8111e_vlan_rx_kill_vid(struct net_device *dev, unsigned short
vid)
-{
- struct amd8111e_priv *lp = netdev_priv(dev);
- spin_lock_irq(lp-lock);
- vlan_group_set_device(lp-vlgrp, vid, NULL);
- spin_unlock_irq(lp-lock);
-}
#endif
+
static int amd8111e_enable_magicpkt(struct amd8111e_priv* lp)
{
writel( VAL1|MPPLBA, lp-mmio + CMD3);
@@ -1996,7 +1989,6 @@ static int __devinit amd8111e_probe_one(
#if AMD8111E_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX ;
dev-vlan_rx_register =amd8111e_vlan_rx_register;
- dev-vlan_rx_kill_vid = amd8111e_vlan_rx_kill_vid;
#endif
lp = netdev_priv(dev);
@@ -2049,7 +2041,6 @@ static int __devinit amd8111e_probe_one(
#if AMD8111E_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev-vlan_rx_register =amd8111e_vlan_rx_register;
- dev-vlan_rx_kill_vid = amd8111e_vlan_rx_kill_vid;
#endif
/* Probe the external PHY */
amd8111e_probe_ext_phy(dev);
--- a/drivers/net/bnx2.c2007-06-01 08:41:22.0 -0700
+++ b/drivers/net/bnx2.c2007-06-01 08:42:42.0 -0700
@@ -4786,19 +4786,6 @@ bnx2_vlan_rx_register(struct net_device
bnx2_netif_start(bp);
}
-
-/* Called with rtnl_lock */
-static void
-bnx2_vlan_rx_kill_vid(struct net_device *dev, uint16_t vid)
-{
- struct bnx2 *bp = netdev_priv(dev);
-
- bnx2_netif_stop(bp);
- vlan_group_set_device(bp-vlgrp, vid, NULL);
- bnx2_set_rx_mode(dev);
-
- bnx2_netif_start(bp);
-}
#endif
/* Called with netif_tx_lock.
@@ -6453,7 +6440,6 @@ bnx2_init_one(struct pci_dev *pdev, cons
dev-watchdog_timeo = TX_TIMEOUT;
#ifdef BCM_VLAN
dev-vlan_rx_register = bnx2_vlan_rx_register;
- dev-vlan_rx_kill_vid = bnx2_vlan_rx_kill_vid;
#endif
dev-poll = bnx2_poll;
dev-ethtool_ops = bnx2_ethtool_ops;
--- a/drivers/net/forcedeth.c 2007-06-01 08:41:22.0 -0700
+++ b/drivers/net/forcedeth.c 2007-06-01 08:42:47.0 -0700
@@ -4605,12 +4605,7 @@ static void nv_vlan_rx_register(struct n
writel(np-txrxctl_bits, get_hwbase(dev) + NvRegTxRxControl);
spin_unlock_irq(np-lock);
-};
-
-static void nv_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
-{
- /* nothing to do */
-};
+}
/* The mgmt unit and driver use a semaphore to access the phy during init */
static int
[PATCH 2/5] sky2: Fix VLAN unregistration
Fix sky2 disabling VLAN completely when the first vid is unregistered.
sky2 disables VLAN completely when the first VID is unregistered. It
should instead disable VLAN when the group is unregistered by calling
sky2_vlan_rx_register with grp = NULL.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
drivers/net/sky2.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/net/sky2.c2007-06-01 08:20:39.0 -0700
+++ b/drivers/net/sky2.c2007-06-01 08:29:05.0 -0700
@@ -1049,26 +1049,22 @@ static void sky2_vlan_rx_register(struct
u16 port = sky2-port;
netif_tx_lock_bh(dev);
+ netif_poll_disable(sky2-hw-dev[0]);
- sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T), RX_VLAN_STRIP_ON);
- sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T), TX_VLAN_TAG_ON);
sky2-vlgrp = grp;
+ if (grp) {
+ sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T),
+RX_VLAN_STRIP_ON);
+ sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T),
+TX_VLAN_TAG_ON);
+ } else {
+ sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T),
+RX_VLAN_STRIP_OFF);
+ sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T),
+TX_VLAN_TAG_OFF);
+ }
- netif_tx_unlock_bh(dev);
-}
-
-static void sky2_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
-{
- struct sky2_port *sky2 = netdev_priv(dev);
- struct sky2_hw *hw = sky2-hw;
- u16 port = sky2-port;
-
- netif_tx_lock_bh(dev);
-
- sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T), RX_VLAN_STRIP_OFF);
- sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T), TX_VLAN_TAG_OFF);
- vlan_group_set_device(sky2-vlgrp, vid, NULL);
-
+ netif_poll_enable(sky2-hw-dev[0]);
netif_tx_unlock_bh(dev);
}
#endif
@@ -3484,7 +3480,6 @@ static __devinit struct net_device *sky2
#ifdef SKY2_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev-vlan_rx_register = sky2_vlan_rx_register;
- dev-vlan_rx_kill_vid = sky2_vlan_rx_kill_vid;
#endif
/* read the mac address */
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] atl1: eliminate unneeded kill_vid code
This driver has unneeded stubs for VLAN filtering.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c | 25 +
---
drivers/net/atl1/atl1_main.c | 33 +
1 file changed, 1 insertion(+), 32 deletions(-)
--- a/drivers/net/atl1/atl1_main.c 2007-06-01 09:21:53.0 -0700
+++ b/drivers/net/atl1/atl1_main.c 2007-06-01 09:27:53.0 -0700
@@ -1229,39 +1229,9 @@ static void atl1_vlan_rx_register(struct
spin_unlock_irqrestore(adapter-lock, flags);
}
-/* FIXME: justify or remove -- CHS */
-static void atl1_vlan_rx_add_vid(struct net_device *netdev, u16 vid)
-{
- /* We don't do Vlan filtering */
- return;
-}
-
-/* FIXME: this looks wrong too -- CHS */
-static void atl1_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
-{
- struct atl1_adapter *adapter = netdev_priv(netdev);
- unsigned long flags;
-
- spin_lock_irqsave(adapter-lock, flags);
- /* atl1_irq_disable(adapter); */
- vlan_group_set_device(adapter-vlgrp, vid, NULL);
- /* atl1_irq_enable(adapter); */
- spin_unlock_irqrestore(adapter-lock, flags);
- /* We don't do Vlan filtering */
- return;
-}
-
static void atl1_restore_vlan(struct atl1_adapter *adapter)
{
atl1_vlan_rx_register(adapter-netdev, adapter-vlgrp);
- if (adapter-vlgrp) {
- u16 vid;
- for (vid = 0; vid VLAN_GROUP_ARRAY_LEN; vid++) {
- if (!vlan_group_get_device(adapter-vlgrp, vid))
- continue;
- atl1_vlan_rx_add_vid(adapter-netdev, vid);
- }
- }
}
static u16 tpd_avail(struct atl1_tpd_ring *tpd_ring)
@@ -2203,8 +2173,7 @@ static int __devinit atl1_probe(struct p
netdev-poll_controller = atl1_poll_controller;
#endif
netdev-vlan_rx_register = atl1_vlan_rx_register;
- netdev-vlan_rx_add_vid = atl1_vlan_rx_add_vid;
- netdev-vlan_rx_kill_vid = atl1_vlan_rx_kill_vid;
+
netdev-ethtool_ops = atl1_ethtool_ops;
adapter-bd_number = cards_found;
adapter-pci_using_64 = pci_using_64;
--
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 0/5] VLAN driver API fixes
Stephen Hemminger wrote: Patrick's fix for sky2 VLAN unregister, started me looking at other drivers. Many drivers had bogus kill_vid hooks, and the whole interface for kill_vid is only useful for devices that do receive filtering, so fix the interface and the drivers. Looks good too me. - 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] e1000: disable polling before registering netdevice
To assure the symmetry of poll enable/disable in up/down, we should initialize the netdevice to be poll_disabled at load time. Doing this after register_netdevice leaves us open to another race, so lets move all the netif_* calls above register_netdevice so the stack starts out how we expect it to be. Signed-off-by: Auke Kok [EMAIL PROTECTED] Cc: Herbert Xu [EMAIL PROTECTED] Cc: Doug Chapman [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 9ec35b7..cf8af92 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -1142,13 +1142,16 @@ e1000_probe(struct pci_dev *pdev, !e1000_check_mng_mode(adapter-hw)) e1000_get_hw_control(adapter); - strcpy(netdev-name, eth%d); - if ((err = register_netdev(netdev))) - goto err_register; - /* tell the stack to leave us alone until e1000_open() is called */ netif_carrier_off(netdev); netif_stop_queue(netdev); +#ifdef CONFIG_E1000_NAPI + netif_poll_disable(netdev); +#endif + + strcpy(netdev-name, eth%d); + if ((err = register_netdev(netdev))) + goto err_register; DPRINTK(PROBE, INFO, Intel(R) PRO/1000 Network Connection\n); - 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
[ICMP]: Fix icmp_errors_use_inbound_ifaddr sysctl
It seems like you missed this patch in the previous thread discussing
the problem, so here's a resend.
[ICMP]: Fix icmp_errors_use_inbound_ifaddr sysctl
Currently when icmp_errors_use_inbound_ifaddr is set and an ICMP error is
sent after the packet passed through ip_output(), an address from the
outgoing interface is chosen as ICMP source address since skb-dev doesn't
point to the incoming interface anymore.
Fix this by doing an interface lookup on rt-dst.iif and using that device.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit f680f41a1c6b2c358a4725e763132b3c61c1685a
tree 81f9cd86744aca6e7c2bc647639f7868d7ceb1d3
parent 19b6cbad06d246d48168fc6c493a7c3d9db58e1f
author Patrick McHardy [EMAIL PROTECTED] Fri, 01 Jun 2007 19:22:21 +0200
committer Patrick McHardy [EMAIL PROTECTED] Fri, 01 Jun 2007 19:22:21 +0200
net/ipv4/icmp.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index e238b17..02a899b 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -514,12 +514,15 @@ void icmp_send(struct sk_buff *skb_in, int type, int
code, __be32 info)
saddr = iph-daddr;
if (!(rt-rt_flags RTCF_LOCAL)) {
- /* This is broken, skb_in-dev points to the outgoing device
-* after the packet passes through ip_output().
-*/
- if (skb_in-dev sysctl_icmp_errors_use_inbound_ifaddr)
- saddr = inet_select_addr(skb_in-dev, 0, RT_SCOPE_LINK);
- else
+ struct net_device *dev = NULL;
+
+ if (rt-fl.iif sysctl_icmp_errors_use_inbound_ifaddr)
+ dev = dev_get_by_index(rt-fl.iif);
+
+ if (dev) {
+ saddr = inet_select_addr(dev, 0, RT_SCOPE_LINK);
+ dev_put(dev);
+ } else
saddr = 0;
}
Re: [PATCH]: bonding: Fix 802.3ad no carrier on no partner found instance
Laurent Chavey [EMAIL PROTECTED] wrote: On 5/31/07, Laurent Chavey [EMAIL PROTECTED] wrote: if a host configured with 802.3ad bond mode is connected to a switch that does not support 802.3ad, then an aggregator is selected as the active aggregator (first link that has carrier in the slave list). This is perfectly fine, since it lets at least one of the link become active. (this was the behavior prior to 2.6.18) In 2.6.18 and above, a new check for the partner mac address was added before an aggregator's carrier is set on. If a host is configured as previously described, then no links will become active. is that the intended behavior ? Prior to the change in question, the carrier state of the master device was always on, regardless of the state of the slaves (so even if things didn't work, bonding would claim to be up). My concern specifically was more with failures in negotiation with 802.3ad capable peers, not for interoperability with non-802.3ad devices (since bonding can always be run in a non-802.3ad mode). This behavior (don't pass traffic if no 802.3ad setup occurs) also parallels the behavior of the Cisco switches I use to test bonding (they will not pass traffic across ports of a lacp channel-group if the 802.3ad negotation does not occur), so it seemed appropriate. I'm checking the standard to see what it says, but I'm also curious if this has some real-world impact, or is just something you happened across? -J --- -Jay Vosburgh, IBM Linux Technology Center, [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]: bonding: Fix 802.3ad no carrier on no partner found instance
On 6/1/07, Jay Vosburgh [EMAIL PROTECTED] wrote: Laurent Chavey [EMAIL PROTECTED] wrote: On 5/31/07, Laurent Chavey [EMAIL PROTECTED] wrote: if a host configured with 802.3ad bond mode is connected to a switch that does not support 802.3ad, then an aggregator is selected as the active aggregator (first link that has carrier in the slave list). This is perfectly fine, since it lets at least one of the link become active. (this was the behavior prior to 2.6.18) In 2.6.18 and above, a new check for the partner mac address was added before an aggregator's carrier is set on. If a host is configured as previously described, then no links will become active. is that the intended behavior ? Prior to the change in question, the carrier state of the master device was always on, regardless of the state of the slaves (so even if things didn't work, bonding would claim to be up). looking at the code, this will only work if there is an actual active aggregator. If that is not the case, and as you mention there could be an active aggregator before completing all LACP pahses (on all the slaves) then we would need to add a check (not for the mac) but for the churned state. (I added a churned state machine that could be use there, I did not submit the patch yet) My concern specifically was more with failures in negotiation with 802.3ad capable peers, not for interoperability with non-802.3ad devices (since bonding can always be run in a non-802.3ad mode). agree. This re-inforces that we should use the churned state This behavior (don't pass traffic if no 802.3ad setup occurs) also parallels the behavior of the Cisco switches I use to test bonding (they will not pass traffic across ports of a lacp channel-group if the 802.3ad negotation does not occur), so it seemed appropriate. yop, but the switch has to be configured with LACP support. I'm checking the standard to see what it says, but I'm also curious if this has some real-world impact, or is just something you happened across? this is the case when a switch is not configured with LACP support, and a host is attached to it. this is something that happens in a pre release environment where a host is tested (using a switch that has no LACP support). The host is then moved to its real rack (where the switch has LACP). The host is not re-configured between the 2 steps (bonding is always enabled with 802.3ad mode) -J --- -Jay Vosburgh, IBM Linux Technology Center, [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 4/5] atl1: eliminate unneeded kill_vid code
Stephen Hemminger wrote:
This driver has unneeded stubs for VLAN filtering.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c | 25 +
---
drivers/net/atl1/atl1_main.c | 33 +
1 file changed, 1 insertion(+), 32 deletions(-)
--- a/drivers/net/atl1/atl1_main.c 2007-06-01 09:21:53.0 -0700
+++ b/drivers/net/atl1/atl1_main.c 2007-06-01 09:27:53.0 -0700
@@ -1229,39 +1229,9 @@ static void atl1_vlan_rx_register(struct
spin_unlock_irqrestore(adapter-lock, flags);
}
-/* FIXME: justify or remove -- CHS */
-static void atl1_vlan_rx_add_vid(struct net_device *netdev, u16 vid)
-{
- /* We don't do Vlan filtering */
- return;
-}
-
-/* FIXME: this looks wrong too -- CHS */
-static void atl1_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
-{
- struct atl1_adapter *adapter = netdev_priv(netdev);
- unsigned long flags;
-
- spin_lock_irqsave(adapter-lock, flags);
- /* atl1_irq_disable(adapter); */
- vlan_group_set_device(adapter-vlgrp, vid, NULL);
- /* atl1_irq_enable(adapter); */
- spin_unlock_irqrestore(adapter-lock, flags);
- /* We don't do Vlan filtering */
- return;
-}
-
static void atl1_restore_vlan(struct atl1_adapter *adapter)
{
atl1_vlan_rx_register(adapter-netdev, adapter-vlgrp);
- if (adapter-vlgrp) {
- u16 vid;
- for (vid = 0; vid VLAN_GROUP_ARRAY_LEN; vid++) {
- if (!vlan_group_get_device(adapter-vlgrp, vid))
- continue;
- atl1_vlan_rx_add_vid(adapter-netdev, vid);
- }
- }
}
static u16 tpd_avail(struct atl1_tpd_ring *tpd_ring)
@@ -2203,8 +2173,7 @@ static int __devinit atl1_probe(struct p
netdev-poll_controller = atl1_poll_controller;
#endif
netdev-vlan_rx_register = atl1_vlan_rx_register;
- netdev-vlan_rx_add_vid = atl1_vlan_rx_add_vid;
- netdev-vlan_rx_kill_vid = atl1_vlan_rx_kill_vid;
+
netdev-ethtool_ops = atl1_ethtool_ops;
adapter-bd_number = cards_found;
adapter-pci_using_64 = pci_using_64;
As the comments indicate, I was going to get around to doing this in my
Copious Free Time anyway, so:
Acked-By: Chris Snook [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 0/5] NetXen: Bug fixes and updates
On Friday 01 June 2007 4:11:25 am Mithlesh Thukral wrote: Hi All, I will be sending bug fixes and updates to NetXen's 1/10G Ethernet driver in subsequent mails. These patches are wrt netdev#master. These patches seem to work for me on my i386 machine with a dual port card. Acked-by: Vernon Mauery [EMAIL PROTECTED] --Vernon - 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] rfkill: Make rfkill-name const
The rfkill name can be made const safely,
this makes the compiler happy when drivers make
it point to some const string used elsewhere.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
---
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index 7c1ffba..a8a6ea8 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -63,7 +63,7 @@ enum rfkill_state {
* This structure represents a RF switch located on a network device.
*/
struct rfkill {
- char *name;
+ const char *name;
enum rfkill_type type;
enum rfkill_state state;
-
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: [ICMP]: Fix icmp_errors_use_inbound_ifaddr sysctl
From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 01 Jun 2007 19:24:18 +0200 It seems like you missed this patch in the previous thread discussing the problem, so here's a resend. Thanks for resending, applied, thanks Patrick. - 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]: bonding: Fix 802.3ad no carrier on no partner found instance
Laurent Chavey [EMAIL PROTECTED] wrote: On 6/1/07, Jay Vosburgh [EMAIL PROTECTED] wrote: [...] Prior to the change in question, the carrier state of the master device was always on, regardless of the state of the slaves (so even if things didn't work, bonding would claim to be up). looking at the code, this will only work if there is an actual active aggregator. If that is not the case, and as you mention there could be an active aggregator before completing all LACP pahses (on all the slaves) then we would need to add a check (not for the mac) but for the churned state. (I added a churned state machine that could be use there, I did not submit the patch yet) I'm not exactly sure what you mean, but I'm guessing that you're saying that the current code won't work properly when there isn't an active aggregator. That's true, but the only times there isn't an active aggregator is when there are no slaves, and temporarily during 802.3ad negoitation (if there are no 802.3ad responses, an aggregator is chosen from the set after a timeout). During those times, I believe it to be correct for the bonding master to be down, as no transmission or reception is possible. I'm not at all sure what you mean by a churned state, but I don't think any additional state checks are needed here, for the following reason. I checked the 802.3ad standard, and I believe that the switches I'm testing against are not in compliance with the standard, particularly the following: 43.3.9 Attaching a link to an Aggregator Links that are not successful candidates for aggregation (e.g., links that are attached to other devices that cannot perform aggregation or links that have been manually configured to be non-aggregatable) are enabled to operate as individual IEEE 802.3 links. For consistency of modeling, such a link is regarded as being attached to a compatible Aggregator that can only be associated with a single link. That is, from the perspective of Link Aggregation, non-aggregated links are not a special case; they compose an aggregation with a maximum membership of one link. The switches I have (Cisco 2960, 2970) do not appear to enable links that are not successful candidates for aggregation as individual 802.3 links, rather, those links are disabled entirely. Anyway, in light of this, I don't see a problem with your patch, I believe it would produce results in compliance with the standard. It may result in false carrier up for cases of, e.g., negotiation failure with 802.3ad switches such as I test with, but the cause there appears to be due to noncompliance on the switch. Can you update your patch to change the comments above bond_3ad_set_carrier() to remove the word partnered and note that the code is implementing compliance with section 43.3.9 of IEEE 802.3, and then resubmit your patch with the proper Signed-off-by attribution? -J --- -Jay Vosburgh, IBM Linux Technology Center, [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.6.21.3] bonding: Fix 802.3ad no carrier on no partner found instance
Remove the requirement to have at least one configured partner to
enable the operation of links. The later is necessary to have the code
in compliance with section 43.3.9 of IEEE 802.3,
Signed-off-by: Laurent Chavey [EMAIL PROTECTED]
--
diff -ru linux-2.6.21.3/drivers/net/bonding/bond_3ad.c
linux-2.6.21.3.new/drivers/net/bonding/bond_3ad.c
--- linux-2.6.21.3/drivers/net/bonding/bond_3ad.c 2007-05-24
14:22:47.0 -0700
+++ linux-2.6.21.3.new/drivers/net/bonding/bond_3ad.c 2007-06-01
12:41:57.0 -0700
@@ -2303,19 +2303,17 @@
}
/*
- * set link state for bonding master: if we have an active partnered
+ * set link state for bonding master: if we have an active
* aggregator, we're up, if not, we're down. Presumes that we cannot
* have an active aggregator if there are no slaves with link up.
+ * Code is implementing compliance with section 43.3.9 of IEEE 802.3.
*
* Called by bond_set_carrier(). Return zero if carrier state does not
* change, nonzero if it does.
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- struct aggregator *agg;
-
- agg = __get_active_agg((SLAVE_AD_INFO(bond-first_slave).aggregator));
- if (agg MAC_ADDRESS_COMPARE(agg-partner_system, null_mac_addr)) {
+ if (__get_active_agg((SLAVE_AD_INFO(bond-first_slave).aggregator))) {
if (!netif_carrier_ok(bond-dev)) {
netif_carrier_on(bond-dev);
return 1;
@@ -2468,4 +2466,3 @@
return ret;
}
-
-
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 7/7] cxgb3 - Add SW LRO support
Brice Goglin wrote: Steve Wise wrote: You're right. But cxgb3 has it now in the driver (tested and working). Shouldn't it be pulled in? When the network stack design gets done (which could take a few releases to finalize), all the drivers can be updated to use it. It doesn't seem reasonable to allow some drivers to support LRO and others to not support it... I have to agree with Steve here. We have been requesting the inclusion of myri10ge LRO for 5 months now (before 2.6.19). I could understand that duplicating LRO code between s2io and myri10ge was not a good idea at this point. But, I now see that Netxen got merged way later (in 2.6.20) but it got its LRO merged immediately. I guess the LRO is already duplicated between s2io and netxen then. It does not look fair to me at all. It was an error on my part, that should not be compounded. Three wrongs don't make a right, etc., etc. The normal way this stuff works in Linux is that people work together to create common code that everybody uses. I would gladly accept patches to rip out the code from NetXen. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.21.3] bonding: Fix 802.3ad no carrier on no partner found instance
Jeff, please apply wherever seems appropriate. It is a bug fix,
but for a pretty obscure bit of standards compliance.
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
-J
Laurent Chavey [EMAIL PROTECTED] wrote:
Remove the requirement to have at least one configured partner to
enable the operation of links. The later is necessary to have the code
in compliance with section 43.3.9 of IEEE 802.3,
Signed-off-by: Laurent Chavey [EMAIL PROTECTED]
--
diff -ru linux-2.6.21.3/drivers/net/bonding/bond_3ad.c
linux-2.6.21.3.new/drivers/net/bonding/bond_3ad.c
--- linux-2.6.21.3/drivers/net/bonding/bond_3ad.c 2007-05-24
14:22:47.0 -0700
+++ linux-2.6.21.3.new/drivers/net/bonding/bond_3ad.c 2007-06-01
12:41:57.0 -0700
@@ -2303,19 +2303,17 @@
}
/*
- * set link state for bonding master: if we have an active partnered
+ * set link state for bonding master: if we have an active
* aggregator, we're up, if not, we're down. Presumes that we cannot
* have an active aggregator if there are no slaves with link up.
+ * Code is implementing compliance with section 43.3.9 of IEEE 802.3.
*
* Called by bond_set_carrier(). Return zero if carrier state does not
* change, nonzero if it does.
*/
int bond_3ad_set_carrier(struct bonding *bond)
{
- struct aggregator *agg;
-
- agg = __get_active_agg((SLAVE_AD_INFO(bond-first_slave).aggregator));
- if (agg MAC_ADDRESS_COMPARE(agg-partner_system, null_mac_addr)) {
+ if (__get_active_agg((SLAVE_AD_INFO(bond-first_slave).aggregator))) {
if (!netif_carrier_ok(bond-dev)) {
netif_carrier_on(bond-dev);
return 1;
@@ -2468,4 +2466,3 @@
return ret;
}
-
-
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
-
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] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
Milton Miller wrote:
Your logic works, this adds some conditional branching but saves a
pointer, not sure which is better. Mine can be used for initializing
without special casing since it will just calculate rx_to_unmark as
rx[n-2] and rx_to_mark as rx[n-2] != rx[n-2]-prev; unmarking a never
marked still works, where as for yours the was marked must be
explicitly set to something (hmm, rxs = rx[0] might work for that
initial value until we mark -2??)
again, the compare of rx-el instead of rx-rfd-el is to save cache
traffic to the rfd under io. The rx-was_0 is required, so the el flag
is free.
Ok, I took a stab at coding and testing these ideas. Below is a patch against
2.6.22-rc3.
Let me know what you think. Testing shows that we can hit any of the following
scenarios:
Find a buffer not complete with rx-el and rx-s0 set. I read back the status
and see if
the receiver is still running.
Find a buffer not complete with rx-el not set and rx-s0 set. I check the
next buffer
and if it is complete, I free the skb and return 0. If the next buffer is not
complete, I read the receiver's status to see if he is still running.
Find a buffer that is complete with rx-el not set and rx-s0 set. It appears
that hardware
can read the rfd's el-bit, then software can clear the rfd el-bit and set the
rfd size, and
then hardware can come in and read the size. I am reading the status back,
although
I don't think that I have to in this instance.
I am testing a version of this code patched against 2.6.18.4 on my PXA 255 based system. I will let
you all know how it goes.
On the ARM, their is a race condition between software allocating a new receive
buffer and hardware writing into a buffer. The two race on touching the last
Receive Frame Descriptor (RFD). It has its el-bit set and its next link equal
to 0. When hardware encounters this buffer it attempts to write data to it
and then update Status Word bits and Actual Count in the RFD. At the same time
software may try to clear the el-bit and set the link address to a new buffer.
Since the entire RFD is once cache-line, the two write operations can
collide. This can lead to the receive unit stalling or freed receive buffers
getting written to.
The fix is to set the el-bit on and the size to 0 on the next to last buffer
in the chain. When the hardware encounters this buffer it stops and does
not write to it at all. The hardware issues an RNR interrupt with the
receive unit in the No Resources state. When software allocates buffers,
it can update the tail of the list when either it knows the hardware
has stopped or the previous to the new one to mark marked.
Once it has a new next to last buffer prepared, it can clear the el-bit
and set the size on the previous one. The race on this buffer is safe
since the link already points to a valid next buffer. We keep flags
in our software descriptor to note if the el bit is set and if the size
was 0. When we clear the RFD's el bit and set its size, we also clear
the el flag but we leave the size was 0 bit set. This was we can find
this buffer again later.
If the hardware sees the el-bit cleared without the size set, it will
move on to the next buffer and skip this one. If it sees
the size set but the el-bit still set, it will complete that buffer
and then RNR interrupt and wait.
Signed-off-by: David Acker [EMAIL PROTECTED]
---
--- linux-2.6.22-rc3/drivers/net/e100.c.orig2007-06-01 16:13:16.0
-0400
+++ linux-2.6.22-rc3/drivers/net/e100.c 2007-06-01 16:20:36.0 -0400
@@ -281,10 +281,17 @@ struct csr {
};
enum scb_status {
+ rus_no_res = 0x08,
rus_ready= 0x10,
rus_mask = 0x3C,
};
+enum ru_state {
+ ru_suspended = 0,
+ ru_running = 1,
+ ru_uninitialized = -1,
+};
+
enum scb_stat_ack {
stat_ack_not_ours= 0x00,
stat_ack_sw_gen = 0x04,
@@ -395,10 +402,16 @@ struct rfd {
u16 size;
};
+enum rx_flags {
+ rx_el = 0x01,
+ rx_s0 = 0x02,
+};
+
struct rx {
struct rx *next, *prev;
struct sk_buff *skb;
dma_addr_t dma_addr;
+ u8 flags;
};
#if defined(__BIG_ENDIAN_BITFIELD)
@@ -526,6 +539,7 @@ struct nic {
struct rx *rx_to_use;
struct rx *rx_to_clean;
struct rfd blank_rfd;
+ enum ru_state ru_running;
spinlock_t cb_lock cacheline_aligned;
spinlock_t cmd_lock;
@@ -947,7 +961,7 @@ static void e100_get_defaults(struct nic
((nic-mac = mac_82558_D101_A4) ? cb_cid : cb_i));
/* Template for a freshly allocated RFD */
- nic-blank_rfd.command = cpu_to_le16(cb_el cb_s);
+ nic-blank_rfd.command = 0;
nic-blank_rfd.rbd = 0x;
nic-blank_rfd.size = cpu_to_le16(VLAN_ETH_FRAME_LEN);
@@ -1742,11 +1756,55 @@ static int e100_alloc_cbs(struct nic *ni
return 0;
}
-static inline void e100_start_receiver(struct nic
Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
David Acker wrote: Milton Miller wrote: Your logic works, this adds some conditional branching but saves a pointer, not sure which is better. Mine can be used for initializing without special casing since it will just calculate rx_to_unmark as rx[n-2] and rx_to_mark as rx[n-2] != rx[n-2]-prev; unmarking a never marked still works, where as for yours the was marked must be explicitly set to something (hmm, rxs = rx[0] might work for that initial value until we mark -2??) again, the compare of rx-el instead of rx-rfd-el is to save cache traffic to the rfd under io. The rx-was_0 is required, so the el flag is free. Ok, I took a stab at coding and testing these ideas. Below is a patch against 2.6.22-rc3. Let me know what you think. Testing shows that we can hit any of the following scenarios: Find a buffer not complete with rx-el and rx-s0 set. I read back the status and see if the receiver is still running. Find a buffer not complete with rx-el not set and rx-s0 set. I check the next buffer and if it is complete, I free the skb and return 0. If the next buffer is not complete, I read the receiver's status to see if he is still running. Find a buffer that is complete with rx-el not set and rx-s0 set. It appears that hardware can read the rfd's el-bit, then software can clear the rfd el-bit and set the rfd size, and then hardware can come in and read the size. I am reading the status back, although I don't think that I have to in this instance. I am testing a version of this code patched against 2.6.18.4 on my PXA 255 based system. I will let you all know how it goes. On the ARM, their is a race condition between software allocating a new receive buffer and hardware writing into a buffer. The two race on touching the last Receive Frame Descriptor (RFD). It has its el-bit set and its next link equal to 0. When hardware encounters this buffer it attempts to write data to it and then update Status Word bits and Actual Count in the RFD. At the same time software may try to clear the el-bit and set the link address to a new buffer. Since the entire RFD is once cache-line, the two write operations can collide. This can lead to the receive unit stalling or freed receive buffers getting written to. The fix is to set the el-bit on and the size to 0 on the next to last buffer in the chain. When the hardware encounters this buffer it stops and does not write to it at all. The hardware issues an RNR interrupt with the receive unit in the No Resources state. When software allocates buffers, it can update the tail of the list when either it knows the hardware has stopped or the previous to the new one to mark marked. Once it has a new next to last buffer prepared, it can clear the el-bit and set the size on the previous one. The race on this buffer is safe since the link already points to a valid next buffer. We keep flags in our software descriptor to note if the el bit is set and if the size was 0. When we clear the RFD's el bit and set its size, we also clear the el flag but we leave the size was 0 bit set. This was we can find this buffer again later. If the hardware sees the el-bit cleared without the size set, it will move on to the next buffer and skip this one. If it sees the size set but the el-bit still set, it will complete that buffer and then RNR interrupt and wait. Signed-off-by: David Acker [EMAIL PROTECTED] That seems to vaguely match my memory of what eepro100 was doing (or trying to do). I _really_ appreciate you working on this problem. Getting e100 driver stable for the long term, and ditching eepro100, is a big hurdle to cross. Getting this right is really one of the last steps. The patch looks OK at quick glance. Thanks, Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'libertas' branch of wireless-2.6
On Thu, 2007-05-31 at 17:16 -0400, John W. Linville wrote: On Thu, May 31, 2007 at 05:13:17PM -0400, Dan Williams wrote: On Wed, 2007-05-30 at 11:28 -0400, Dan Williams wrote: On Wed, 2007-05-30 at 10:07 -0400, Jeff Garzik wrote: John W. Linville wrote: Lots of stuff here...probably best for 2.6.23... Is this best for Linux users... or just easy for developers? Won't putting off all these fixes until 2.6.23 leave the driver released in 2.6.22 in shoddy shape? If you think all the bits from this should just go to 2.6.22, that's fine with me. But I don't feel comfortable making that call given what I thought were the constraints on pushing changes through during an rc cycle. When the merge window was open, we backported critical bug fixes and necessary merge-requirement cleanups to the code in linville's tree, but avoided changes that didn't impact function. Any response on these points yet? I've got yet more cleanups and a few other things queued in libertas-2.6 but I'd like to see where this discussion goes before sending a pull request for the new bits. As for me, I have no great problem w/ the whole batch going to 2.6.22. The driver is still new and most acknowledge it still has significant defficiencies. Most (but probably not all) of the patches would seem to fit some definition of bug fix anyway. I was just trying to err on the side of caution and follow the normal bugfixes in -rc process. Jeff, the branch in question is based off a vanilla 2.6.22-rc3. So it is safe to pull (from a won't mess-up my tree perspective) if you are so inclined. Ok; if Jeff is so inclined, we'll push further libertas cleanups/bugfixes/etc to you, and then you upstream to Jeff, targetted for inclusion in 2.6.22. Dan - 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] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
Jeff Garzik wrote: David Acker wrote: Milton Miller wrote: snip the el flag but we leave the size was 0 bit set. This was we can find this buffer again later. If the hardware sees the el-bit cleared without the size set, it will move on to the next buffer and skip this one. If it sees the size set but the el-bit still set, it will complete that buffer and then RNR interrupt and wait. Signed-off-by: David Acker [EMAIL PROTECTED] That seems to vaguely match my memory of what eepro100 was doing (or trying to do). I _really_ appreciate you working on this problem. Getting e100 driver stable for the long term, and ditching eepro100, is a big hurdle to cross. Getting this right is really one of the last steps. yes, absolutely agreed. I'm very pleased with the attention and hope that is clear to everyone. The patch looks OK at quick glance. Besides copying the style errors, it looks OK as well. I will attempt to allocate some testing time again early next week on a small library of e100 nics over here. Mostly x86, but still useful to spot obvious mistakes. Auke - 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] e1000: disable polling before registering netdevice
On Fri, Jun 01, 2007 at 10:22:39AM -0700, Auke Kok wrote:
To assure the symmetry of poll enable/disable in up/down, we should
initialize the netdevice to be poll_disabled at load time. Doing
this after register_netdevice leaves us open to another race, so
lets move all the netif_* calls above register_netdevice so the
stack starts out how we expect it to be.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Cc: Herbert Xu [EMAIL PROTECTED]
Cc: Doug Chapman [EMAIL PROTECTED]
Looks good!
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] e1000: disable polling before registering netdevice
On Fri, 2007-06-01 at 10:22 -0700, Auke Kok wrote: To assure the symmetry of poll enable/disable in up/down, we should initialize the netdevice to be poll_disabled at load time. Doing this after register_netdevice leaves us open to another race, so lets move all the netif_* calls above register_netdevice so the stack starts out how we expect it to be. Signed-off-by: Auke Kok [EMAIL PROTECTED] Cc: Herbert Xu [EMAIL PROTECTED] Cc: Doug Chapman [EMAIL PROTECTED] I tested this on my HP Integrity systems and it looks good. thanks, - Doug - 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: ETHTOOL_GSET IOCTL on GigE links
Jeff Haran wrote: With 10/100 Mbps links it wasn't such an issue since the devices tend to support the same forced speeds and duplexities as they are capable of negotiating, but with GigE links that's not always the case, at least not according to what I've read. For instance, the following doc from Sun http://www.sun.com/blueprints/0704/817-7526.pdf says that IEEE 802.3ab says you can't force 1000Base-T over copper media (see page 4), whereas some other physical media allow GigE to run without autonegotiation (there's apparently this serdes interface that allows it, for instance). Seems like there should be another field named something like supported_forced to indicate what can be forced on the interface. Either that or some more SUPPORTED_* bits to indicate supported forced modes. The 'supported' field has nothing at all to do with auto-negotiation. The driver should list all possibilities in that field, even if some are ONLY supported via 'forced' selection. Jeff P.S. [EMAIL PROTECTED] is a far more active list, and is where the network stack/driver developers appear. - 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: ETHTOOL_GSET IOCTL on GigE links
From: Jeff Haran [EMAIL PROTECTED] Date: Fri, 1 Jun 2007 15:51:18 -0700 OK, but my question remains. In the case where a device supports one set of speeds via autonegotiation and another set via forcing, how does one tell which speeds can be forced and which can be autonegotiated? Unfortunately, as you have noted, this information is not given at the moment. I got bit by this the other week when I wanted to try forcing gigabit on a tg3 and the driver wouldn't allow it because it only allows forcing link speeds at 10/100 on copper links. - 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: ETHTOOL_GSET IOCTL on GigE links
-Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Friday, June 01, 2007 3:40 PM To: Jeff Haran Cc: [EMAIL PROTECTED]; netdev Subject: Re: ETHTOOL_GSET IOCTL on GigE links Jeff Haran wrote: With 10/100 Mbps links it wasn't such an issue since the devices tend to support the same forced speeds and duplexities as they are capable of negotiating, but with GigE links that's not always the case, at least not according to what I've read. For instance, the following doc from Sun http://www.sun.com/blueprints/0704/817-7526.pdf says that IEEE 802.3ab says you can't force 1000Base-T over copper media (see page 4), whereas some other physical media allow GigE to run without autonegotiation (there's apparently this serdes interface that allows it, for instance). Seems like there should be another field named something like supported_forced to indicate what can be forced on the interface. Either that or some more SUPPORTED_* bits to indicate supported forced modes. The 'supported' field has nothing at all to do with auto-negotiation. The driver should list all possibilities in that field, even if some are ONLY supported via 'forced' selection. Jeff OK, but my question remains. In the case where a device supports one set of speeds via autonegotiation and another set via forcing, how does one tell which speeds can be forced and which can be autonegotiated? Thanks, Jeff Haran - 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: ETHTOOL_GSET IOCTL on GigE links
Jeff Haran wrote: OK, but my question remains. In the case where a device supports one set of speeds via autonegotiation and another set via forcing, how does one tell which speeds can be forced and which can be autonegotiated? The interface does not currently support such enumeration. You can certainly attempt forcing a speed, and see what happens. The driver will either (a) work, (b) refuse and give you an error message, or (c) present you with a situation that requires filing a driver bug report :) Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spidernet: checksum and ethtool
On Tue, May 29, 2007 at 05:24:36PM -0700, Stephen Hemminger wrote: It doesn't look like spidernet hardware can really checksum all protocols, the code looks like it does IPV4 only. If so, it should use NETIF_F_IP_CSUM instead of NETIF_F_HW_CSUM. The driver doesn't need it's own get/set for ethtool tx csum, and it should use the standard ethtool_op_get_link. NOT TESTED (no CELL hardware). It seems to work. I've been distracted with other spidernet issues; I will forward your patch upstream early next week. --linas - 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: ETHTOOL_GSET IOCTL on GigE links
-Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Friday, June 01, 2007 4:05 PM To: Jeff Haran Cc: [EMAIL PROTECTED]; netdev Subject: Re: ETHTOOL_GSET IOCTL on GigE links Jeff Haran wrote: OK, but my question remains. In the case where a device supports one set of speeds via autonegotiation and another set via forcing, how does one tell which speeds can be forced and which can be autonegotiated? The interface does not currently support such enumeration. You can certainly attempt forcing a speed, and see what happens. The driver will either (a) work, (b) refuse and give you an error message, or (c) present you with a situation that requires filing a driver bug report :) Jeff Are there any plans in the works to modify the interface to provide this information? Thanks, Jeff Haran - 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
[RFC PATCH 0/2] dmaengine: preparation for raid acceleration
Hello David, The following two patches are part of the raid acceleration series I would like to push for 2.6.23 consideration. I am sending these two separately for your review for the following reasons: the 'dmaengine' core initially came in through netdev, patch #2 makes changes to net/dev/core.c, and lastly I have an ack on the raid changes but no ack from the community on the i/oat and dmaengine changes. dmaengine: add base support for the async_tx api dmaengine: move channel management to the client Regards, Dan the full series is available at: git://lost.foo-projects.org/~dwillia2/git/iop md-accel-linus - 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
[RFC PATCH 1/2] dmaengine: add base support for the async_tx api
In preparation for the async_tx (dmaengine client) API this patch:
1/ introduces struct dma_async_tx_descriptor as a common field for all
dmaengine software descriptors. The primary role of this structure
is to enable callbacks at transaction completion time, and support
transaction chains that span multiple channels
2/ converts the device_memcpy_* methods into separate prep, set
src/dest, and submit stages
3/ adds support for capabilities beyond memcpy (xor, memset, xor zero
sum, completion interrupts). place holders for future capabilities
are also included
4/ converts ioatdma to the new semantics
Changelog:
* drop dma mapping methods, suggested by Chris Leech
* fix ioat_dma_dependency_added, also caught by Andrew Morton
* fix dma_sync_wait, change from Andrew Morton
* uninline large functions, change from Andrew Morton
* add tx-callback = NULL to dmaengine calls to interoperate with async_tx
calls
* hookup ioat_tx_submit
* convert channel capabilities to a 'cpumask_t like' bitmap
Cc: Chris Leech [EMAIL PROTECTED]
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 182 +
drivers/dma/ioatdma.c | 248 -
drivers/dma/ioatdma.h |8 +
include/linux/dmaengine.h | 245
4 files changed, 454 insertions(+), 229 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 322ee29..8a49103 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -59,6 +59,7 @@
#include linux/init.h
#include linux/module.h
+#include linux/mm.h
#include linux/device.h
#include linux/dmaengine.h
#include linux/hardirq.h
@@ -66,6 +67,7 @@
#include linux/percpu.h
#include linux/rcupdate.h
#include linux/mutex.h
+#include linux/jiffies.h
static DEFINE_MUTEX(dma_list_mutex);
static LIST_HEAD(dma_device_list);
@@ -165,6 +167,24 @@ static struct dma_chan *dma_client_chan_alloc(struct
dma_client *client)
return NULL;
}
+enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
+{
+ enum dma_status status;
+ unsigned long dma_sync_wait_timeout = jiffies + msecs_to_jiffies(5000);
+
+ dma_async_issue_pending(chan);
+ do {
+ status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
+ if (time_after_eq(jiffies, dma_sync_wait_timeout)) {
+ printk(KERN_ERR dma_sync_wait_timeout!\n);
+ return DMA_ERROR;
+ }
+ } while (status == DMA_IN_PROGRESS);
+
+ return status;
+}
+EXPORT_SYMBOL(dma_sync_wait);
+
/**
* dma_chan_cleanup - release a DMA channel's resources
* @kref: kernel reference structure that contains the DMA channel device
@@ -322,6 +342,28 @@ int dma_async_device_register(struct dma_device *device)
if (!device)
return -ENODEV;
+ /* validate device routines */
+ BUG_ON(dma_has_cap(DMA_MEMCPY, device-cap_mask)
+ !device-device_prep_dma_memcpy);
+ BUG_ON(dma_has_cap(DMA_XOR, device-cap_mask)
+ !device-device_prep_dma_xor);
+ BUG_ON(dma_has_cap(DMA_ZERO_SUM, device-cap_mask)
+ !device-device_prep_dma_zero_sum);
+ BUG_ON(dma_has_cap(DMA_MEMSET, device-cap_mask)
+ !device-device_prep_dma_memset);
+ BUG_ON(dma_has_cap(DMA_ZERO_SUM, device-cap_mask)
+ !device-device_prep_dma_interrupt);
+
+ BUG_ON(!device-device_alloc_chan_resources);
+ BUG_ON(!device-device_free_chan_resources);
+ BUG_ON(!device-device_tx_submit);
+ BUG_ON(!device-device_set_dest);
+ BUG_ON(!device-device_set_src);
+ BUG_ON(!device-device_dependency_added);
+ BUG_ON(!device-device_is_tx_complete);
+ BUG_ON(!device-device_issue_pending);
+ BUG_ON(!device-dev);
+
init_completion(device-done);
kref_init(device-refcount);
device-dev_id = id++;
@@ -397,6 +439,146 @@ void dma_async_device_unregister(struct dma_device
*device)
}
EXPORT_SYMBOL(dma_async_device_unregister);
+/**
+ * dma_async_memcpy_buf_to_buf - offloaded copy between virtual addresses
+ * @chan: DMA channel to offload copy to
+ * @dest: destination address (virtual)
+ * @src: source address (virtual)
+ * @len: length
+ *
+ * Both @dest and @src must be mappable to a bus address according to the
+ * DMA mapping API rules for streaming mappings.
+ * Both @dest and @src must stay memory resident (kernel memory or locked
+ * user space pages).
+ */
+dma_cookie_t dma_async_memcpy_buf_to_buf(struct dma_chan *chan,
+void *dest, void *src, size_t len)
+{
+ struct dma_device *dev = chan-device;
+ struct dma_async_tx_descriptor *tx;
+ dma_addr_t addr;
+ dma_cookie_t cookie;
+ int cpu;
+
+ tx = dev-device_prep_dma_memcpy(chan, len, 0);
+ if (!tx)
+ return -ENOMEM;
+
+
[RFC PATCH 2/2] dmaengine: move channel management to the client
This effectively makes channels a shared resource rather than tying them
to a specific client. dmaengine now assumes that clients will internally
track how many channels they need and dmaengine will learn if the client cares
about
a channel at dma_event_callback time. This also enables a client to ignore
a channel if it does not meet extra client specific constraints beyond
simple base capabilities.
This patch also fixes up the NET_DMA client to use the new mechanism.
Changelog:
* removed DMA_TX_ARRAY_INIT, no longer needed
* dma_client_chan_free - dma_chan_release: switch to global reference
counting only at device unregistration time, before it was also happening
at client unregistration time
* clients now return dma_state_client to dmaengine (ack, dup, nak)
Cc: Chris Leech [EMAIL PROTECTED]
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---
drivers/dma/dmaengine.c | 213 +++--
drivers/dma/ioatdma.c |1
drivers/dma/ioatdma.h |3 -
include/linux/dmaengine.h | 75
net/core/dev.c| 111 ---
5 files changed, 220 insertions(+), 183 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 8a49103..927a8ac 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -37,11 +37,11 @@
* Each device has a channels list, which runs unlocked but is never modified
* once the device is registered, it's just setup by the driver.
*
- * Each client has a channels list, it's only modified under the client-lock
- * and in an RCU callback, so it's safe to read under rcu_read_lock().
+ * Each client is responsible for keeping track of the channels it uses. See
+ * the definition of dma_event_callback in dmaengine.h.
*
* Each device has a kref, which is initialized to 1 when the device is
- * registered. A kref_put is done for each class_device registered. When the
+ * registered. A kref_get is done for each class_device registered. When the
* class_device is released, the coresponding kref_put is done in the release
* method. Every time one of the device's channels is allocated to a client,
* a kref_get occurs. When the channel is freed, the coresponding kref_put
@@ -51,10 +51,12 @@
* references to finish.
*
* Each channel has an open-coded implementation of Rusty Russell's bigref,
- * with a kref and a per_cpu local_t. A single reference is set when on an
- * ADDED event, and removed with a REMOVE event. Net DMA client takes an
- * extra reference per outstanding transaction. The relase function does a
- * kref_put on the device. -ChrisL
+ * with a kref and a per_cpu local_t. A dma_chan_get is called when a client
+ * signals that it wants to use a channel, and dma_chan_put is called when
+ * a channel is removed or a client using it is unregesitered. A client can
+ * take extra references per outstanding transaction, as is the case with
+ * the NET DMA client. The release function does a kref_put on the device.
+ * -ChrisL, DanW
*/
#include linux/init.h
@@ -102,8 +104,18 @@ static ssize_t show_bytes_transferred(struct class_device
*cd, char *buf)
static ssize_t show_in_use(struct class_device *cd, char *buf)
{
struct dma_chan *chan = container_of(cd, struct dma_chan, class_dev);
+ int in_use = 0;
+
+ if (unlikely(chan-slow_ref) atomic_read(chan-refcount.refcount)
1)
+ in_use = 1;
+ else {
+ if (local_read((per_cpu_ptr(chan-local,
+ get_cpu())-refcount)) 0)
+ in_use = 1;
+ put_cpu();
+ }
- return sprintf(buf, %d\n, (chan-client ? 1 : 0));
+ return sprintf(buf, %d\n, in_use);
}
static struct class_device_attribute dma_class_attrs[] = {
@@ -129,42 +141,50 @@ static struct class dma_devclass = {
/* --- client and device registration --- */
+#define dma_async_chan_satisfies_mask(chan, mask)
__dma_async_chan_satisfies_mask((chan), (mask))
+static int __dma_async_chan_satisfies_mask(struct dma_chan *chan,
dma_cap_mask_t *want)
+{
+ dma_cap_mask_t has;
+
+ bitmap_and(has.bits, want-bits, chan-device-cap_mask.bits,
DMA_TX_TYPE_END);
+ return bitmap_equal(want-bits, has.bits, DMA_TX_TYPE_END);
+}
+
/**
- * dma_client_chan_alloc - try to allocate a channel to a client
+ * dma_client_chan_alloc - try to allocate channels to a client
* @client: dma_client
*
* Called with dma_list_mutex held.
*/
-static struct dma_chan *dma_client_chan_alloc(struct dma_client *client)
+static void dma_client_chan_alloc(struct dma_client *client)
{
struct dma_device *device;
struct dma_chan *chan;
- unsigned long flags;
int desc; /* allocated descriptor count */
+ enum dma_state_client ack;
- /* Find a channel, any DMA engine will do */
- list_for_each_entry(device, dma_device_list, global_node) {
+ /* Find a channel */
+
small forcedeth WoL fix
I happened to notice that a system with an NVidia NIC using the
forcedeth driver won't wake-on-LAN if the interface was in promiscuous
mode when you power off. By experiment, it looks like
the hardware needs to have NvRegPacketFilterFlags set to
NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR (i.e., receive unicast packets to my
address) in order for WoL to work. At any rate, the attached patch
fixes the problem for me.
--
Tim Mann work: [EMAIL PROTECTED] home: [EMAIL PROTECTED]
http://www.vmware.com http://tim-mann.org
--- forcedeth-git-netdev.c 2007-06-01 16:43:19.971507000 -0700
+++ forcedeth-git-netdev-fixed.c 2007-06-01 16:46:53.389713000 -0700
@@ -4830,8 +4830,10 @@
drain_ring(dev);
- if (np-wolenabled)
+ if (np-wolenabled) {
+ writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags);
nv_start_rx(dev);
+ }
/* FIXME: power down nic */
Re: Mixing tagged and untagged vlans using via-velocity driver
On Fri, 25 May 2007 09:37:09 +0200
Nicklas Bondesson [EMAIL PROTECTED] wrote:
I am trying to setup two vlans (one tagged and one untagged) using the
native via-velocity driver in kernel 2.6.21.1 on a single nic.
I can set it up tagged or untagged without any problems, but not both at the
same time. Is this even possible with this driver?
To enable vlan5 tagging on the nic I have tried the following:
alias eth1 via_velocity
options eth1 enable_tagging=1 VID_setting=5
At this point I can communicate with vlan5. When I try to bring up a virtual
interface using vconfig it seems to inherit the vlan5 tagging, thus making
it impossible to communicate with an untagged vlan.
I have also tried the other way arround. If I skip enable_tagging=1
VID_setting=5, I can communicate with a non tagged vlan. If I bring up a
new virtual interface (tagged vlan5) using vconfig it does not work.
I'm stuck. If anyone could shed some light on this it would be greatly
appreciated.
The via-velocity is using a non-standard VLAN interface and ought
to be fixed...
Could someone give this a try?
---
drivers/net/via-velocity.c | 71 +++--
drivers/net/via-velocity.h |3 +
2 files changed, 45 insertions(+), 29 deletions(-)
--- a/drivers/net/via-velocity.c2007-06-01 08:18:22.0 -0700
+++ b/drivers/net/via-velocity.c2007-06-01 17:18:14.0 -0700
@@ -72,6 +72,7 @@
#include linux/mii.h
#include linux/in.h
#include linux/if_arp.h
+#include linux/if_vlan.h
#include linux/ip.h
#include linux/tcp.h
#include linux/udp.h
@@ -111,15 +112,6 @@ VELOCITY_PARAM(RxDescriptors, Number of
#define TX_DESC_DEF 64
VELOCITY_PARAM(TxDescriptors, Number of transmit descriptors);
-#define VLAN_ID_MIN 0
-#define VLAN_ID_MAX 4095
-#define VLAN_ID_DEF 0
-/* VID_setting[] is used for setting the VID of NIC.
- 0: default VID.
- 1-4094: other VIDs.
-*/
-VELOCITY_PARAM(VID_setting, 802.1Q VLAN ID);
-
#define RX_THRESH_MIN 0
#define RX_THRESH_MAX 3
#define RX_THRESH_DEF 0
@@ -147,13 +139,6 @@ VELOCITY_PARAM(rx_thresh, Receive fifo
*/
VELOCITY_PARAM(DMA_length, DMA length);
-#define TAGGING_DEF 0
-/* enable_tagging[] is used for enabling 802.1Q VID tagging.
- 0: disable VID seeting(default).
- 1: enable VID setting.
-*/
-VELOCITY_PARAM(enable_tagging, Enable 802.1Q tagging);
-
#define IP_ALIG_DEF 0
/* IP_byte_align[] is used for IP header DWORD byte aligned
0: indicate the IP header won't be DWORD byte aligned.(Default) .
@@ -442,8 +427,7 @@ static void __devinit velocity_get_optio
velocity_set_int_opt(opts-DMA_length, DMA_length[index],
DMA_LENGTH_MIN, DMA_LENGTH_MAX, DMA_LENGTH_DEF, DMA_length, devname);
velocity_set_int_opt(opts-numrx, RxDescriptors[index], RX_DESC_MIN,
RX_DESC_MAX, RX_DESC_DEF, RxDescriptors, devname);
velocity_set_int_opt(opts-numtx, TxDescriptors[index], TX_DESC_MIN,
TX_DESC_MAX, TX_DESC_DEF, TxDescriptors, devname);
- velocity_set_int_opt(opts-vid, VID_setting[index], VLAN_ID_MIN,
VLAN_ID_MAX, VLAN_ID_DEF, VID_setting, devname);
- velocity_set_bool_opt(opts-flags, enable_tagging[index], TAGGING_DEF,
VELOCITY_FLAGS_TAGGING, enable_tagging, devname);
+
velocity_set_bool_opt(opts-flags, txcsum_offload[index], TX_CSUM_DEF,
VELOCITY_FLAGS_TX_CSUM, txcsum_offload, devname);
velocity_set_int_opt(opts-flow_cntl, flow_control[index],
FLOW_CNTL_MIN, FLOW_CNTL_MAX, FLOW_CNTL_DEF, flow_control, devname);
velocity_set_bool_opt(opts-flags, IP_byte_align[index], IP_ALIG_DEF,
VELOCITY_FLAGS_IP_ALIGN, IP_byte_align, devname);
@@ -465,6 +449,7 @@ static void __devinit velocity_get_optio
static void velocity_init_cam_filter(struct velocity_info *vptr)
{
struct mac_regs __iomem * regs = vptr-mac_regs;
+ unsigned short vid;
/* Turn on MCFG_PQEN, turn off MCFG_RTGOPT */
WORD_REG_BITS_SET(MCFG_PQEN, MCFG_RTGOPT, regs-MCFG);
@@ -477,13 +462,19 @@ static void velocity_init_cam_filter(str
mac_set_cam_mask(regs, vptr-mCAMmask, VELOCITY_MULTICAST_CAM);
/* Enable first VCAM */
- if (vptr-flags VELOCITY_FLAGS_TAGGING) {
- /* If Tagging option is enabled and VLAN ID is not zero, then
- turn on MCFG_RTGOPT also */
- if (vptr-options.vid != 0)
- WORD_REG_BITS_ON(MCFG_RTGOPT, regs-MCFG);
+ if (vptr-vlgrp) {
+ for (vid = 0; vid VLAN_VID_MASK; vid++) {
+ if (vlan_group_get_device(vptr-vlgrp, vid)) {
+ /* If Tagging option is enabled and
+ VLAN ID is not zero, then
+ turn on MCFG_RTGOPT also */
+ if (vid != 0)
+ WORD_REG_BITS_ON(MCFG_RTGOPT,
regs-MCFG);
- mac_set_cam(regs, 0, (u8 *) (vptr-options.vid),
[PATCH] since the definition of dst_discard_in and dst_discard_out are the same,
they should merged into one
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
---
net/core/dst.c | 17 -
1 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/net/core/dst.c b/net/core/dst.c
index 764bccb..c6a0587 100644
--- a/net/core/dst.c
+++ b/net/core/dst.c
@@ -111,13 +111,7 @@ out:
spin_unlock(dst_lock);
}
-static int dst_discard_in(struct sk_buff *skb)
-{
- kfree_skb(skb);
- return 0;
-}
-
-static int dst_discard_out(struct sk_buff *skb)
+static int dst_discard(struct sk_buff *skb)
{
kfree_skb(skb);
return 0;
@@ -138,8 +132,7 @@ void * dst_alloc(struct dst_ops * ops)
dst-ops = ops;
dst-lastuse = jiffies;
dst-path = dst;
- dst-input = dst_discard_in;
- dst-output = dst_discard_out;
+ dst-input = dst-output = dst_discard;
#if RT_CACHE_DEBUG = 2
atomic_inc(dst_total);
#endif
@@ -153,8 +146,7 @@ static void ___dst_free(struct dst_entry * dst)
protocol module is unloaded.
*/
if (dst-dev == NULL || !(dst-dev-flagsIFF_UP)) {
- dst-input = dst_discard_in;
- dst-output = dst_discard_out;
+ dst-input = dst-output = dst_discard;
}
dst-obsolete = 2;
}
@@ -242,8 +234,7 @@ static inline void dst_ifdown(struct dst_entry *dst, struct
net_device *dev,
return;
if (!unregister) {
- dst-input = dst_discard_in;
- dst-output = dst_discard_out;
+ dst-input = dst-output = dst_discard;
} else {
dst-dev = loopback_dev;
dev_hold(loopback_dev);
--
1.4.4.2
-
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
