[PATCH] bcm43xx: Ignore ampdu status reports
From: Michael Buesch <[EMAIL PROTECTED]>
iIf bcm43xx were to process an afterburner (ampdu) status response, Linux would
oops. The
ampdu and intermediate status bits are properly named.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1453,12 +1453,10 @@ static void handle_irq_transmit_status(s
bcm43xx_debugfs_log_txstat(bcm, &stat);
- if (stat.flags & BCM43xx_TXSTAT_FLAG_IGNORE)
+ if (stat.flags & BCM43xx_TXSTAT_FLAG_AMPDU)
+ continue;
+ if (stat.flags & BCM43xx_TXSTAT_FLAG_INTER)
continue;
- if (!(stat.flags & BCM43xx_TXSTAT_FLAG_ACK)) {
- //TODO: packet was not acked (was lost)
- }
- //TODO: There are more (unknown) flags to test. see
bcm43xx_main.h
if (bcm43xx_using_pio(bcm))
bcm43xx_pio_handle_xmitstatus(bcm, &stat);
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
@@ -137,14 +137,8 @@ struct bcm43xx_xmitstatus {
u16 unknown; //FIXME
};
-#define BCM43xx_TXSTAT_FLAG_ACK0x01
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x02
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x04
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x08
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x10
-#define BCM43xx_TXSTAT_FLAG_IGNORE 0x20
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x40
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x80
+#define BCM43xx_TXSTAT_FLAG_AMPDU 0x10
+#define BCM43xx_TXSTAT_FLAG_INTER 0x20
u8 bcm43xx_plcp_get_ratecode_cck(const u8 bitrate);
u8 bcm43xx_plcp_get_ratecode_ofdm(const u8 bitrate);
-
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: [take35 0/10] kevent: Generic event handling mechanism.
On Thu, 2007-02-01 at 13:12 +0300, Evgeniy Polyakov wrote: > Generic event handling mechanism. The patch applied cleanly to 2.6.20 final, but I got a build error: CC kernel/kevent/kevent.o CC kernel/kevent/kevent_user.o CC kernel/kevent/kevent_timer.o CC kernel/kevent/kevent_poll.o make[2]: *** No rule to make target `kernel/kevent/epoll.o', needed by `kernel/kevent/built-in.o'. Stop. make[1]: *** [kernel/kevent] Error 2 make: *** [kernel] Error 2 - DML - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 11/11] netfilter warning fix
On Mon, 05 Feb 2007 18:44:08 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > I bet this rcu_read_lock()-implies-preempt_disable() assumption has > spread into other areas of the tree as well. Me too. Although one expects that other holes will cause might_sleep or lockdep warnings pretty easily. Still, life is hard enough as it is. I think I'll shelve rcu-preempt pending resolution of this. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 05/11] bonding: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
David Miller wrote: From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:04 -0800 From: "Joe Jin" <[EMAIL PROTECTED]> Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in the bonding driver. Signed-off-by: Joe Jin <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Jeff, you got this one? nope, didn't see it - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 11/11] netfilter warning fix
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 5 Feb 2007 18:18:10 -0800
> I think the finger was pointed at preemptible rcu, in -mm. iirc,
> the net stats code is assuming that rcu_read_lock() disables
> preemption as a side-effect, which rcu-preempt makes no-longer-true.
>
> Not sure what to do there. Perhaps add a new
> rcu_read_lock_with_preempt_disable() thing which will dtrt with
> either config.
Hmmm, really?
Let's audit NF_CT_STAT_INC() usage to make sure :-)
net/netfilter/nf_conntrack_core.c:
destroy_conntrack: Inside write_{lock,unlock}_bh().
death_by_timeout: Ditto.
__nf_conntrack_find: Inside read_{lock,unlock}_bh() via callers.
__nf_conntrack_confirm: Inside write_{lock,unlock}_bh().
early_drop: This one looks like it could be unprotected.
init_conntrack: Inside of write_{lock,unlock}_bh().
nf_conntrack_in: Packet receive path, softints disabled.
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:
ipv6_prepare: Packet input path, BH's disabled.
net/netfilter/nf_conntrack_expect.c:
nf_ct_unlink_expect: Inside if write_{lock,unlock}_bh() via callers.
nf_conntrack_expect_insert: Ditto.
So that leaves early_drop() as the only suspicious case that might
not run inside of disabled BH's.
And in fact that case is a bug regardless of the preemptible rcu
changes because this allows the counter bump to be corrupted by
software interrupt context.
And OK, I see in the lockdep trace that it's the packet transmit
path... In fact, this assumption of preemption being disabled
by the netfilter top-level dispatch is very deep.
For example, several bits besides the NF_CT_STATIC_INC of
nf_conntrack_in() (where the lockdep trigger backtrace hits) assume
that preemption is enabled by that rcu_read_lock() in the top-level
netfilter dispatch.
The __nf_ct_l{3,4}proto_find() calls there are just two examples.
I imagine this assumption is quite pervasive throughout the
netfilter code, so just patching up this NF_CT_STAT_INC() case
will merely shut up lockdep and paper over the issue.
I bet this rcu_read_lock()-implies-preempt_disable() assumption has
spread into other areas of the tree as well.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 11/11] netfilter warning fix
On Mon, 05 Feb 2007 18:10:26 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: [EMAIL PROTECTED] > Date: Mon, 05 Feb 2007 16:31:11 -0800 > > > From: Andrew Morton <[EMAIL PROTECTED]> > > > > "using smp_processor_id() in preemptible code" > > > > Cc: Patrick McHardy <[EMAIL PROTECTED]> > > Cc: "David S. Miller" <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > We NAK'd this because every patch in the lockdep trace should > have preemption disabled because software interrupts ought > to be disabled in those code paths. > > Someone needs to track down why this is really happening. I think the finger was pointed at preemptible rcu, in -mm. iirc, the net stats code is assuming that rcu_read_lock() disables preemption as a side-effect, which rcu-preempt makes no-longer-true. Not sure what to do there. Perhaps add a new rcu_read_lock_with_preempt_disable() thing which will dtrt with either config. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 10/11] dccp-warning-fixes
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:09 -0800 > From: Andrew Morton <[EMAIL PROTECTED]> > > sparc64: > > net/dccp/ccids/ccid3.c: In function `ccid3_hc_tx_packet_recv': > net/dccp/ccids/ccid3.c:480: warning: long long unsigned int format, __u64 arg > (arg 6) > net/dccp/ccids/ccid3.c: In function `ccid3_hc_rx_packet_recv': > net/dccp/ccids/ccid3.c:1007: warning: long int format, different type arg > (arg 3) > net/dccp/ccids/ccid3.c:1007: warning: long int format, different type arg > (arg 4) > > opaque types must be suitably cast for printing. > > Cc: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> > Cc: "David S. Miller" <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 11/11] netfilter warning fix
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:11 -0800 > From: Andrew Morton <[EMAIL PROTECTED]> > > "using smp_processor_id() in preemptible code" > > Cc: Patrick McHardy <[EMAIL PROTECTED]> > Cc: "David S. Miller" <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> We NAK'd this because every patch in the lockdep trace should have preemption disabled because software interrupts ought to be disabled in those code paths. Someone needs to track down why this is really happening. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 09/11] Remove unused kernel config option DLCI_COUNT
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:06 -0800 > From: "Robert P. J. Day" <[EMAIL PROTECTED]> > > Remove the unused kernel config option DLCI_COUNT. > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > Cc: "David S. Miller" <[EMAIL PROTECTED]> > Cc: Jeff Garzik <[EMAIL PROTECTED]> > Cc: Krzysztof Halasa [EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 08/11] slip: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:06 -0800 > From: joe jin <[EMAIL PROTECTED]> > > This patch replace kmalloc() + memset() pairs with the appropriate > kzalloc(). > > Signed-off-by: Joe Jin <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 07/11] remove tcp header from tcp_v4_check
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:05 -0800 > From: Frederik Deweerdt <[EMAIL PROTECTED]> > > The tcphdr struct passed to tcp_v4_check is not used, the following > patch removes it from the parameter list. > > Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> This one is already in my tree, but thanks for resubmitting. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 06/11] net/wanrouter/wanmain.c: cleanups
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:05 -0800 > From: Adrian Bunk <[EMAIL PROTECTED]> > > This patch contains the following cleanups: > - make the following needlessly global functions static: > - lock_adapter_irq() > - unlock_adapter_irq() > - #if 0 the following unused global functions: > - wanrouter_encapsulate() > - wanrouter_type_trans() > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 05/11] bonding: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:31:04 -0800 > From: "Joe Jin" <[EMAIL PROTECTED]> > > Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in > the bonding driver. > > Signed-off-by: Joe Jin <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Jeff, you got this one? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 03/11] fix for crash in adummy_init()
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:30:56 -0800 > From: Daniel Walker <[EMAIL PROTECTED]> > > This was reported by Ingo Molnar here, > > http://lkml.org/lkml/2006/12/18/119 > > The problem is that adummy_init() depends on atm_init() , but adummy_init() > is called first. > > So I put atm_init() into subsys_initcall which seems appropriate, and it > will still get module_init() if it becomes a module. > > Interesting to note that you could crash your system here if you just load > the modules in the wrong order. > > Signed-off-by: Daniel Walker <[EMAIL PROTECTED]> > Cc: Ingo Molnar <[EMAIL PROTECTED]> > Cc: chas williams <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Applied, and I'll queue this one up for -stable too. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 02/11] net/irda/: proper prototypes
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:30:53 -0800 > From: Adrian Bunk <[EMAIL PROTECTED]> > > Add proper prototypes for some functions in include/net/irda/irda.h > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Acked-by: Samuel Ortiz <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> I NAK'd this so that Adrian would go add "extern" to the function declarations in the header file. Please drop this, Adrian will resend once he fixes it up. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 01/11] user of the jiffies rounding code: Networking
From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:30:52 -0800 > From: Arjan van de Ven <[EMAIL PROTECTED]> > > This patch introduces users of the round_jiffies() function in the networking > code. > > These timers all were of the "about once a second" or "about once every X > seconds" variety and several showed up in the "what wakes the cpu up" profiles > that the tickless patches provide. Some timers are highly dynamic based on > network load; but even on low activity systems they still show up so the > rounding is done only in cases of low activity, allowing higher frequency > timers in the high activity case. > > The various hardware watchdogs are an obvious case; they run every 2 seconds > but aren't otherwise specific of exactly when they need to run. > > Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> I pulled in everything except the e1000 driver change, Jeff please suck that in, thanks. Arjan, btw: > + if (dst_gc_timer_expires > 4*HZ) > + mod_timer(&dst_gc_timer, > + round_jiffies(jiffies + dst_gc_timer_expires)); > + else > + mod_timer(&dst_gc_timer, jiffies + dst_gc_timer_expires); ^ That line begins "TAB SPACE TAB", and lo' and behold GIT catch this when I applied it :-) I fixed it up by hand and reapplied, so don't worry about this instance. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] apply cwnd rules to FIN packets with data
From: John Heffner <[EMAIL PROTECTED]> Date: Mon, 05 Feb 2007 19:11:09 -0500 > My first patch was broken anyway (should not have pulled the test from > tso_should_defer), and the change is not needed to the nagle test since > it's implicit. This patch just restores the old behavior from before > TSO, sending the FIN when it's the last true segment. We can debate the > merits of applying congestion control to the FIN separately. :) Yes, let's split one hair at a time :-) Patch applied, thanks John. I'll push this to the 2.6.x -stable branch too. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Tue, 06 Feb 2007 10:44:08 +0900 (JST) > Yes, I agree, but I think it is different issue, and > maybe, we should check and change other places as well, > in separate patch(es). I agree. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
In article <[EMAIL PROTECTED]> (at Mon, 05 Feb 2007 17:32:58 -0800 (PST)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> > Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST) > > > > @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev, > > > struct neighbour *neigh, > > > msg->icmph.icmp6_unused = 0; > > > msg->icmph.icmp6_router= router; > > > msg->icmph.icmp6_solicited = solicited; > > > -msg->icmph.icmp6_override = override; > > > + msg->icmph.icmp6_override = override; > > > + > > > > > > /* Set the target address. */ > > > ipv6_addr_copy(&msg->target, solicited_addr); > > > > Why do you "change" this? > > He edited it, but then reverted his change but in the > process added proper tab characters :-) It is easy > to miss things like this. I know, you know. :-) > This whole file has a lot of lines lacking proper tab > characters. Yes, I agree, but I think it is different issue, and maybe, we should check and change other places as well, in separate patch(es). --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Tue, 06 Feb 2007 10:24:05 +0900 (JST) > > @@ -498,7 +500,8 @@ static void ndisc_send_na(struct net_device *dev, > > struct neighbour *neigh, > > msg->icmph.icmp6_unused = 0; > > msg->icmph.icmp6_router= router; > > msg->icmph.icmp6_solicited = solicited; > > -msg->icmph.icmp6_override = override; > > + msg->icmph.icmp6_override = override; > > + > > > > /* Set the target address. */ > > ipv6_addr_copy(&msg->target, solicited_addr); > > Why do you "change" this? He edited it, but then reverted his change but in the process added proper tab characters :-) It is easy to miss things like this. This whole file has a lot of lines lacking proper tab characters. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Hello.
In article <[EMAIL PROTECTED]> (at Mon, 5 Feb 2007 15:56:51 -0500), Neil Horman
<[EMAIL PROTECTED]> says:
> if (ifp == NULL && valid_lft) {
> int max_addresses = in6_dev->cnf.max_addresses;
> + u32 addr_flags = 0;
> +
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + if (in6_dev->cnf.optimistic_dad &&
> + !ipv6_devconf.forwarding)
> + addr_flags = IFA_F_OPTIMISTIC;
> +#endif
>
> /* Do not allow to create too much of autoconfigured
>* addresses; this would be too easy way to crash
> kernel.
> @@ -1742,7 +1762,8 @@ ok:
> if (!max_addresses ||
> ipv6_count_addresses(in6_dev) < max_addresses)
> ifp = ipv6_add_addr(in6_dev, &addr,
> pinfo->prefix_len,
> -
> addr_type&IPV6_ADDR_SCOPE_MASK, 0);
> +
> addr_type&IPV6_ADDR_SCOPE_MASK,
> + addr_flags);
>
> if (!ifp || IS_ERR(ifp)) {
> in6_dev_put(in6_dev);
> @@ -1945,7 +1966,11 @@ static int inet6_addr_add(int ifindex, struct in6_addr
> *pfx, int plen,
> ifp->prefered_lft = prefered_lft;
> ifp->tstamp = jiffies;
> spin_unlock_bh(&ifp->lock);
> -
> + /*
> + * Note that section 3.1 of RFC 4429 indicates
> + * That the Optimistic flag should not be set for
> + * manually configured addresses
> + */
> addrconf_dad_start(ifp, 0);
> in6_ifa_put(ifp);
> addrconf_verify(0);
> @@ -2122,8 +2147,16 @@ static void init_loopback(struct net_device *dev)
> static void addrconf_add_linklocal(struct inet6_dev *idev, struct in6_addr
> *addr)
> {
> struct inet6_ifaddr * ifp;
> + u32 addr_flags = IFA_F_PERMANENT;
> +
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + if (idev->cnf.optimistic_dad &&
> + !ipv6_devconf.forwarding)
> + addr_flags |= IFA_F_OPTIMISTIC;
> +#endif
> +
>
> - ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, IFA_F_PERMANENT);
> + ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, addr_flags);
> if (!IS_ERR(ifp)) {
> addrconf_dad_start(ifp, 0);
> in6_ifa_put(ifp);
> @@ -2190,7 +2223,7 @@ ipv6_inherit_linklocal(struct inet6_dev *idev, struct
> net_device *link_dev)
> {
> struct in6_addr lladdr;
>
> - if (!ipv6_get_lladdr(link_dev, &lladdr)) {
> + if (!ipv6_get_lladdr(link_dev, &lladdr, IFA_F_TENTATIVE)) {
> addrconf_add_linklocal(idev, &lladdr);
> return 0;
> }
> @@ -2527,7 +2560,11 @@ static void addrconf_dad_kick(struct inet6_ifaddr *ifp)
> unsigned long rand_num;
> struct inet6_dev *idev = ifp->idev;
>
> - rand_num = net_random() % (idev->cnf.rtr_solicit_delay ? : 1);
> + if (ifp->flags & IFA_F_OPTIMISTIC)
> + rand_num = 0;
> + else
> + rand_num = net_random() % (idev->cnf.rtr_solicit_delay ? : 1);
> +
> ifp->probes = idev->cnf.dad_transmits;
> addrconf_mod_timer(ifp, AC_DAD, rand_num);
> }
> @@ -2553,7 +2590,7 @@ static void addrconf_dad_start(struct inet6_ifaddr
> *ifp, u32 flags)
> if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
> !(ifp->flags&IFA_F_TENTATIVE) ||
> ifp->flags & IFA_F_NODAD) {
> - ifp->flags &= ~IFA_F_TENTATIVE;
> + ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
> spin_unlock_bh(&ifp->lock);
> read_unlock_bh(&idev->lock);
>
> @@ -2573,6 +2610,14 @@ static void addrconf_dad_start(struct inet6_ifaddr
> *ifp, u32 flags)
> addrconf_dad_stop(ifp);
> return;
> }
> +
> + /*
> + * Optimistic nodes need to join the anycast address
> + * right away
> + */
> + if (ifp->flags & IFA_F_OPTIMISTIC)
> + addrconf_join_anycast(ifp);
> +
> addrconf_dad_kick(ifp);
> spin_unlock_bh(&ifp->lock);
> out:
> @@ -2597,7 +2642,7 @@ static void addrconf_dad_timer(unsigned long data)
>* DAD was successful
>*/
>
> - ifp->flags &= ~IFA_F_TENTATIVE;
> + ifp->flags &= ~(IFA_F_TENTATIVE|IFA_F_OPTIMISTIC);
> spin_unlock_bh(&ifp->lock);
> read_unlock_bh(&idev->lock);
>
> @@ -2627,6 +2672,9 @@ static void addrconf_dad_completed(struct inet6_ifaddr
> *ifp)
>* Configure the address for reception. Now it is valid.
>*/
>
> + if (ifp->flags & IFA_F_OPTIMISTIC)
> + addrconf_leave_anycast(ifp);
> +
> ipv6_ifa_notify(RTM_NEWADDR, ifp);
>
> /* If added prefix is link local and forwarding is off,
> @@ -3398,6 +3446,9 @@ st
Re: forcedeth problems on 2.6.20-rc6-mm3
On Mon, 05 Feb 2007 18:35:06 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote: > Daniel Barkalow wrote: > > On Sun, 4 Feb 2007, Robert Hancock wrote: > > > >> Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to > >> 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get > >> received and so the machine can't get an IP address. I tried reverting all > >> the > >> -mm changes to drivers/net/forcedeth.c, which didn't help. The network > >> controller shares an IRQ with the USB OHCI controller which is receiving > >> interrupts, so it doesn't seem like an interrupt routing problem, though I > >> suppose something wierd could be happening there. > > > > IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using > > it, but the kernel thinks enabling it didn't work? I think there's a > > module option for forcedeth to disable MSI, which might be worth a try to > > see if it has any effect. > > I must have messed something up when testing before - reverting to > forcedeth.c from 2.6.20-rc6 does indeed fix the problem. And it doesn't > seem like no packets at all are received with the -mm3 version (driver > version 0.60), either - if I do a tcpdump I can get Ethernet packets > showing up, but I can't ping my router so it seems like something isn't > getting through properly. With the 2.6.20-rc6 version (driver version > 0.59) it works fine. I switched back and forth between versions and this > seems repeatable. > > I don't think it's MSI related, the CK804 version of these controllers > doesn't support MSI and the driver shouldn't be trying to use it. I > tried the MSI and MSI-X disable options on the 0.60 driver, but that > didn't help. > OK, thanks. Jeff, please note that the forcedeth changes in git-netdev-all have a problem. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] e1000: update README
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- Documentation/networking/e1000.txt | 785 +--- 1 files changed, 542 insertions(+), 243 deletions(-) diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 39fba39..517e42d 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt @@ -1,7 +1,7 @@ Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters === -November 17, 2004 +November 11, 2006 Contents @@ -9,6 +9,7 @@ Contents - In This Release - Identifying Your Adapter +- Building and Installation - Command Line Parameters - Speed and Duplex Configuration - Additional Configurations @@ -20,256 +21,398 @@ In This Release === This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family -of Adapters, version 5.x.x. +of Adapters. This driver supports kernel versions 2.4.x. This driver includes +support for Itanium(R)2-based systems. -For questions related to hardware requirements, refer to the documentation -supplied with your Intel PRO/1000 adapter. All hardware requirements listed +For questions related to hardware requirements, refer to the documentation +supplied with your Intel PRO/1000 adapter. All hardware requirements listed apply to use with Linux. -Native VLANs are now available with supported kernels. +This release includes support for Intel(R) I/O Acceleration Technology, +Intel(R) I/OAT. This is supported on systems using the Intel(R) 5000 Series +Chipsets Integrated Device - 1A38. You can find additional information +on Intel I/OAT at http://www.intel.com/technology/ioacceleration/index.htm. + +The following features are now available in supported kernels: + - Native VLANs + - Channel Bonding (teaming) + - SNMP + +Channel Bonding documentation can be found in the Linux kernel source: +/Documentation/networking/bonding.txt + +The driver information previously displayed in the /proc filesystem is not +supported in this release. Alternatively, you can use ethtool (version 1.6 +or later), lspci, and ifconfig to obtain the same information. + +Instructions on updating ethtool can be found in the section "Additional +Configurations" later in this document. + +NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100 +support. + Identifying Your Adapter -For more information on how to identify your adapter, go to the Adapter & +For more information on how to identify your adapter, go to the Adapter & Driver ID Guide at: http://support.intel.com/support/network/adapter/pro100/21397.htm -For the latest Intel network drivers for Linux, refer to the following -website. In the search field, enter your adapter name or type, or use the +For the latest Intel network drivers for Linux, refer to the following +website. In the search field, enter your adapter name or type, or use the networking link on the left to search for your adapter: http://downloadfinder.intel.com/scripts-df/support_intel.asp + +Building and Installation += + +This driver is part of the kernel archive you just extracted, be sure to enable +the e1000 driver (and probably NAPI in the: +Network Device Support +--> Ethernet Drivers (1000 Mbit) +--> Intel PRO/1000 Gigabit Ethernet Support + Command Line Parameters === -If the driver is built as a module, the following optional parameters are -used by entering them on the command line with the modprobe or insmod command +If the driver is built as a module, the following optional parameters +are used by entering them on the command line with the modprobe command using this syntax: modprobe e1000 [=,,...] - insmod e1000 [=,,...] - For example, with two PRO/1000 PCI adapters, entering: - insmod e1000 TxDescriptors=80,128 + modprobe e1000 TxDescriptors=80,128 -loads the e1000 driver with 80 TX descriptors for the first adapter and 128 TX -descriptors for the second adapter. +loads the e1000 driver with 80 TX descriptors for the first adapter and +128 TX descriptors for the second adapter. The default value for each parameter is generally the recommended setting, -unless otherwise noted. Also, if the driver is statically built into the -kernel, the driver is loaded with the default values for all the parameters. -Ethtool can be used to change some of the parameters at runtime. +unless otherwise noted. -NOTES: For more information about the AutoNeg, Duplex, and Speed - parameters, see the "Speed and Duplex Configuration" section in - this document. +NOTES: For more information about the AutoNeg, Duplex, and Speed +parameters, see the "Speed and Duplex Configuration" section in +this document. - For more inf
[PATCH 2/3] [MAINTAINERS]: update e1000 maintainers
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- MAINTAINERS | 18 ++ 1 files changed, 14 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 13759e9..c001147 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -951,9 +951,14 @@ S: Maintained INTEL PRO/100 ETHERNET SUPPORT P: John Ronciak M: [EMAIL PROTECTED] -P: Ganesh Venkatesan -M: [EMAIL PROTECTED] +P: Jesse Brandeburg +M: [EMAIL PROTECTED] +P: Jeff Kirsher +M: [EMAIL PROTECTED] +P: Auke Kok +M: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ +L: [EMAIL PROTECTED] S: Supported INTEL PRO/1000 GIGABIT ETHERNET SUPPORT @@ -961,9 +966,14 @@ P: Jeb Cramer M: [EMAIL PROTECTED] P: John Ronciak M: [EMAIL PROTECTED] -P: Ganesh Venkatesan -M: [EMAIL PROTECTED] +P: Jesse Brandeburg +M: [EMAIL PROTECTED] +P: Jeff Kirsher +M: [EMAIL PROTECTED] +P: Auke Kok +M: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ +L: [EMAIL PROTECTED] S: Supported INTERMEZZO FILE SYSTEM --- Auke Kok <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.4 0/3] e1000: update to 7.3.20
Willy, Please pull: git-pull git://lost.foo-projects.org/~ahkok/git/linux-2.4 e1000 to receive an update for the e1000 driver. This updates the e1000 driver in the 2.4 kernel to version 7.3.20-k4, roughly the equivalent of what is in 2.6.20 and the latest of our out-of-tree driver. This adds new hardware support and many fixes. Many customers are asking us for these updates and the current 2.4 kernel ships a very outdated version of the e1000 adapter. This patch includes small compatibility headers and code to minimize the changes we need to make to our driver and keep it in sync easier with the 2.6 kernel version so we can possibly continue to ship updates and fixes to this driver with more ease. Cheers, Auke --- These patches apply against commit 99405c24cd80afa8f002574f65700296c838260d --- Summary: Jesse Brandeburg <[EMAIL PROTECTED]>: e1000: integrate latest 2.4 linux driver [MAINTAINERS]: update e1000 maintainers e1000: update README --- Documentation/networking/e1000.txt | 785 +++- MAINTAINERS| 18 drivers/net/e1000/Makefile |2 drivers/net/e1000/e1000.h | 205 + drivers/net/e1000/e1000_ethtool.c | 1202 --- drivers/net/e1000/e1000_hw.c | 5830 + drivers/net/e1000/e1000_hw.h | 1420 - drivers/net/e1000/e1000_main.c | 3897 ++-- drivers/net/e1000/e1000_osdep.h| 91 drivers/net/e1000/e1000_param.c| 406 +- drivers/net/e1000/kcompat.c| 69 drivers/net/e1000/kcompat.h| 403 ++ 16 files changed, 11305 insertions(+), 3052 deletions(-) --- Auke Kok <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: forcedeth problems on 2.6.20-rc6-mm3
Daniel Barkalow wrote: On Sun, 4 Feb 2007, Robert Hancock wrote: Something's busted with forcedeth in 2.6.20-rc6-mm3 for me relative to 2.6.20-rc6. There's no errors in dmesg, but it seems no packets ever get received and so the machine can't get an IP address. I tried reverting all the -mm changes to drivers/net/forcedeth.c, which didn't help. The network controller shares an IRQ with the USB OHCI controller which is receiving interrupts, so it doesn't seem like an interrupt routing problem, though I suppose something wierd could be happening there. IIRC, forcedeth tries to use MSI by default. Perhaps the hardware is using it, but the kernel thinks enabling it didn't work? I think there's a module option for forcedeth to disable MSI, which might be worth a try to see if it has any effect. I must have messed something up when testing before - reverting to forcedeth.c from 2.6.20-rc6 does indeed fix the problem. And it doesn't seem like no packets at all are received with the -mm3 version (driver version 0.60), either - if I do a tcpdump I can get Ethernet packets showing up, but I can't ping my router so it seems like something isn't getting through properly. With the 2.6.20-rc6 version (driver version 0.59) it works fine. I switched back and forth between versions and this seems repeatable. I don't think it's MSI related, the CK804 version of these controllers doesn't support MSI and the driver shouldn't be trying to use it. I tried the MSI and MSI-X disable options on the 0.60 driver, but that didn't help. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 06/11] net/wanrouter/wanmain.c: cleanups
From: Adrian Bunk <[EMAIL PROTECTED]>
This patch contains the following cleanups:
- make the following needlessly global functions static:
- lock_adapter_irq()
- unlock_adapter_irq()
- #if 0 the following unused global functions:
- wanrouter_encapsulate()
- wanrouter_type_trans()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/linux/wanrouter.h |8
net/wanrouter/wanmain.c | 17 -
2 files changed, 8 insertions(+), 17 deletions(-)
diff -puN include/linux/wanrouter.h~net-wanrouter-wanmainc-cleanups
include/linux/wanrouter.h
--- a/include/linux/wanrouter.h~net-wanrouter-wanmainc-cleanups
+++ a/include/linux/wanrouter.h
@@ -516,9 +516,6 @@ struct wan_device {
/* Public functions available for device drivers */
extern int register_wan_device(struct wan_device *wandev);
extern int unregister_wan_device(char *name);
-__be16 wanrouter_type_trans(struct sk_buff *skb, struct net_device *dev);
-int wanrouter_encapsulate(struct sk_buff *skb, struct net_device *dev,
- unsigned short type);
/* Proc interface functions. These must not be called by the drivers! */
extern int wanrouter_proc_init(void);
@@ -527,11 +524,6 @@ extern int wanrouter_proc_add(struct wan
extern int wanrouter_proc_delete(struct wan_device *wandev);
extern int wanrouter_ioctl( struct inode *inode, struct file *file, unsigned
int cmd, unsigned long arg);
-extern void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-extern void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-
-
-
/* Public Data */
/* list of registered devices */
extern struct wan_device *wanrouter_router_devlist;
diff -puN net/wanrouter/wanmain.c~net-wanrouter-wanmainc-cleanups
net/wanrouter/wanmain.c
--- a/net/wanrouter/wanmain.c~net-wanrouter-wanmainc-cleanups
+++ a/net/wanrouter/wanmain.c
@@ -86,8 +86,8 @@ static int wanrouter_device_del_if(struc
static struct wan_device *wanrouter_find_device(char *name);
static int wanrouter_delete_interface(struct wan_device *wandev, char *name);
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags);
@@ -104,8 +104,8 @@ struct wan_device* wanrouter_router_devl
* Organize Unique Identifiers for encapsulation/decapsulation
*/
-static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
#if 0
+static unsigned char wanrouter_oui_ether[] = { 0x00, 0x00, 0x00 };
static unsigned char wanrouter_oui_802_2[] = { 0x00, 0x80, 0xC2 };
#endif
@@ -246,6 +246,8 @@ int unregister_wan_device(char *name)
return 0;
}
+#if 0
+
/*
* Encapsulate packet.
*
@@ -341,6 +343,7 @@ __be16 wanrouter_type_trans(struct sk_bu
return ethertype;
}
+#endif /* 0 */
/*
* WAN device IOCTL.
@@ -799,23 +802,19 @@ static int wanrouter_delete_interface(st
return 0;
}
-void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void lock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_lock_irqsave(lock, *smp_flags);
}
-void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
+static void unlock_adapter_irq(spinlock_t *lock, unsigned long *smp_flags)
{
spin_unlock_irqrestore(lock, *smp_flags);
}
EXPORT_SYMBOL(register_wan_device);
EXPORT_SYMBOL(unregister_wan_device);
-EXPORT_SYMBOL(wanrouter_encapsulate);
-EXPORT_SYMBOL(wanrouter_type_trans);
-EXPORT_SYMBOL(lock_adapter_irq);
-EXPORT_SYMBOL(unlock_adapter_irq);
MODULE_LICENSE("GPL");
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 03/11] fix for crash in adummy_init()
From: Daniel Walker <[EMAIL PROTECTED]>
This was reported by Ingo Molnar here,
http://lkml.org/lkml/2006/12/18/119
The problem is that adummy_init() depends on atm_init() , but adummy_init()
is called first.
So I put atm_init() into subsys_initcall which seems appropriate, and it
will still get module_init() if it becomes a module.
Interesting to note that you could crash your system here if you just load
the modules in the wrong order.
Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: chas williams <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
net/atm/common.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN net/atm/common.c~fix-for-crash-in-adummy_init net/atm/common.c
--- a/net/atm/common.c~fix-for-crash-in-adummy_init
+++ a/net/atm/common.c
@@ -816,7 +816,8 @@ static void __exit atm_exit(void)
proto_unregister(&vcc_proto);
}
-module_init(atm_init);
+subsys_initcall(atm_init);
+
module_exit(atm_exit);
MODULE_LICENSE("GPL");
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 10/11] dccp-warning-fixes
From: Andrew Morton <[EMAIL PROTECTED]>
sparc64:
net/dccp/ccids/ccid3.c: In function `ccid3_hc_tx_packet_recv':
net/dccp/ccids/ccid3.c:480: warning: long long unsigned int format, __u64 arg
(arg 6)
net/dccp/ccids/ccid3.c: In function `ccid3_hc_rx_packet_recv':
net/dccp/ccids/ccid3.c:1007: warning: long int format, different type arg (arg
3)
net/dccp/ccids/ccid3.c:1007: warning: long int format, different type arg (arg
4)
opaque types must be suitably cast for printing.
Cc: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
net/dccp/ccids/ccid3.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff -puN net/dccp/ccids/ccid3.c~dccp-warning-fixes net/dccp/ccids/ccid3.c
--- a/net/dccp/ccids/ccid3.c~dccp-warning-fixes
+++ a/net/dccp/ccids/ccid3.c
@@ -479,7 +479,8 @@ static void ccid3_hc_tx_packet_recv(stru
ccid3_pr_debug("%s(%p), s=%u, w_init=%llu, "
"R_sample=%dus, X=%u\n", dccp_role(sk),
- sk, hctx->ccid3hctx_s, w_init,
+ sk, hctx->ccid3hctx_s,
+ (unsigned long long)w_init,
(int)r_sample,
(unsigned)(hctx->ccid3hctx_x >> 6));
@@ -1005,7 +1006,7 @@ static void ccid3_hc_rx_packet_recv(stru
DCCP_BUG_ON(r_sample < 0);
if (unlikely(r_sample <= t_elapsed))
DCCP_WARN("r_sample=%ldus, t_elapsed=%ldus\n",
- r_sample, t_elapsed);
+ (long)r_sample, (long)t_elapsed);
else
r_sample -= t_elapsed;
CCID3_RTT_SANITY_CHECK(r_sample);
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 02/11] net/irda/: proper prototypes
From: Adrian Bunk <[EMAIL PROTECTED]>
Add proper prototypes for some functions in include/net/irda/irda.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Samuel Ortiz <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/irda/irda.h | 15 +++
net/irda/irmod.c| 13 -
2 files changed, 15 insertions(+), 13 deletions(-)
diff -puN include/net/irda/irda.h~net-irda-proper-prototypes
include/net/irda/irda.h
--- a/include/net/irda/irda.h~net-irda-proper-prototypes
+++ a/include/net/irda/irda.h
@@ -113,4 +113,19 @@ do { if(!(expr)) { \
#define IAS_IRCOMM_ID 0x2343
#define IAS_IRLPT_ID 0x9876
+struct net_device;
+struct packet_type;
+
+void irda_proc_register(void);
+void irda_proc_unregister(void);
+
+int irda_sysctl_register(void);
+void irda_sysctl_unregister(void);
+
+int irsock_init(void);
+void irsock_cleanup(void);
+
+int irlap_driver_rcv(struct sk_buff *skb, struct net_device *dev,
+struct packet_type *ptype, struct net_device *orig_dev);
+
#endif /* NET_IRDA_H */
diff -puN net/irda/irmod.c~net-irda-proper-prototypes net/irda/irmod.c
--- a/net/irda/irmod.c~net-irda-proper-prototypes
+++ a/net/irda/irmod.c
@@ -42,19 +42,6 @@
#include /* irttp_init */
#include /* irda_device_init */
-/* irproc.c */
-extern void irda_proc_register(void);
-extern void irda_proc_unregister(void);
-/* irsysctl.c */
-extern int irda_sysctl_register(void);
-extern void irda_sysctl_unregister(void);
-/* af_irda.c */
-extern int irsock_init(void);
-extern void irsock_cleanup(void);
-/* irlap_frame.c */
-extern int irlap_driver_rcv(struct sk_buff *, struct net_device *,
-struct packet_type *, struct net_device *);
-
/*
* Module parameters
*/
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 11/11] netfilter warning fix
From: Andrew Morton <[EMAIL PROTECTED]>
"using smp_processor_id() in preemptible code"
Cc: Patrick McHardy <[EMAIL PROTECTED]>
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/netfilter/nf_conntrack.h |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -puN include/net/netfilter/nf_conntrack.h~netfilter-warning-fix
include/net/netfilter/nf_conntrack.h
--- a/include/net/netfilter/nf_conntrack.h~netfilter-warning-fix
+++ a/include/net/netfilter/nf_conntrack.h
@@ -254,7 +254,12 @@ extern atomic_t nf_conntrack_count;
extern int nf_conntrack_max;
DECLARE_PER_CPU(struct ip_conntrack_stat, nf_conntrack_stat);
-#define NF_CT_STAT_INC(count) (__get_cpu_var(nf_conntrack_stat).count++)
+#define NF_CT_STAT_INC(count) \
+ do {\
+ preempt_disable(); \
+ __get_cpu_var(nf_conntrack_stat).count++; \
+ preempt_enable(); \
+ } while (0);
/* no helper, no nat */
#defineNF_CT_F_BASIC 0
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 09/11] Remove unused kernel config option DLCI_COUNT
From: "Robert P. J. Day" <[EMAIL PROTECTED]> Remove the unused kernel config option DLCI_COUNT. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> Cc: "David S. Miller" <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Cc: Krzysztof Halasa [EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/wan/Kconfig | 11 --- 1 file changed, 11 deletions(-) diff -puN drivers/net/wan/Kconfig~remove-unused-kernel-config-option-dlci_count drivers/net/wan/Kconfig --- a/drivers/net/wan/Kconfig~remove-unused-kernel-config-option-dlci_count +++ a/drivers/net/wan/Kconfig @@ -357,17 +357,6 @@ config DLCI To compile this driver as a module, choose M here: the module will be called dlci. -config DLCI_COUNT - int "Max open DLCI" - depends on DLCI - default "24" - help - Maximal number of logical point-to-point frame relay connections - (the identifiers of which are called DCLIs) that the driver can - handle. - - The default is probably fine. - config DLCI_MAX int "Max DLCI per device" depends on DLCI _ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 08/11] slip: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: joe jin <[EMAIL PROTECTED]>
This patch replace kmalloc() + memset() pairs with the appropriate
kzalloc().
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/slip.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff -puN drivers/net/slip.c~slip-replace-kmalloc-memset-pairs-with-the
drivers/net/slip.c
--- a/drivers/net/slip.c~slip-replace-kmalloc-memset-pairs-with-the
+++ a/drivers/net/slip.c
@@ -1343,15 +1343,12 @@ static int __init slip_init(void)
printk(KERN_INFO "SLIP linefill/keepalive option.\n");
#endif
- slip_devs = kmalloc(sizeof(struct net_device *)*slip_maxdev,
GFP_KERNEL);
+ slip_devs = kzalloc(sizeof(struct net_device *)*slip_maxdev,
GFP_KERNEL);
if (!slip_devs) {
printk(KERN_ERR "SLIP: Can't allocate slip devices array!
Uaargh! (-> No SLIP available)\n");
return -ENOMEM;
}
- /* Clear the pointer array, we allocate devices when we need them */
- memset(slip_devs, 0, sizeof(struct net_device *)*slip_maxdev);
-
/* Fill in our line protocol discipline, and register it */
if ((status = tty_register_ldisc(N_SLIP, &sl_ldisc)) != 0) {
printk(KERN_ERR "SLIP: can't register line discipline (err =
%d)\n", status);
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 04/11] z85230: spinlock logic
From: Alan Cox <[EMAIL PROTECTED]>
At some point someone added a spin_lock(&dev->lock) to the IRQ handler for
the Z85230 driver. This actually correctly fixes a bug but the necessary
changes to remove the chan->lock calls in the event handlers were not made
(c->lock is the same lock).
Simona Dascenzo reported the problem with the driver and this patch should
fix the problem he found.
Cc: "David S. Miller" <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/wan/z85230.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff -puN drivers/net/wan/z85230.c~z85230-spinlock-logic
drivers/net/wan/z85230.c
--- a/drivers/net/wan/z85230.c~z85230-spinlock-logic
+++ a/drivers/net/wan/z85230.c
@@ -331,8 +331,7 @@ static void z8530_rtsdtr(struct z8530_ch
static void z8530_rx(struct z8530_channel *c)
{
u8 ch,stat;
- spin_lock(c->lock);
-
+
while(1)
{
/* FIFO empty ? */
@@ -390,7 +389,6 @@ static void z8530_rx(struct z8530_channe
*/
write_zsctrl(c, ERR_RES);
write_zsctrl(c, RES_H_IUS);
- spin_unlock(c->lock);
}
@@ -406,7 +404,6 @@ static void z8530_rx(struct z8530_channe
static void z8530_tx(struct z8530_channel *c)
{
- spin_lock(c->lock);
while(c->txcount) {
/* FIFO full ? */
if(!(read_zsreg(c, R0)&4))
@@ -434,7 +431,6 @@ static void z8530_tx(struct z8530_channe
z8530_tx_done(c);
write_zsctrl(c, RES_H_IUS);
- spin_unlock(c->lock);
}
/**
@@ -452,7 +448,6 @@ static void z8530_status(struct z8530_ch
{
u8 status, altered;
- spin_lock(chan->lock);
status=read_zsreg(chan, R0);
altered=chan->status^status;
@@ -487,7 +482,6 @@ static void z8530_status(struct z8530_ch
}
write_zsctrl(chan, RES_EXT_INT);
write_zsctrl(chan, RES_H_IUS);
- spin_unlock(chan->lock);
}
struct z8530_irqhandler z8530_sync=
@@ -511,7 +505,6 @@ EXPORT_SYMBOL(z8530_sync);
static void z8530_dma_rx(struct z8530_channel *chan)
{
- spin_lock(chan->lock);
if(chan->rxdma_on)
{
/* Special condition check only */
@@ -534,7 +527,6 @@ static void z8530_dma_rx(struct z8530_ch
/* DMA is off right now, drain the slow way */
z8530_rx(chan);
}
- spin_unlock(chan->lock);
}
/**
@@ -547,7 +539,6 @@ static void z8530_dma_rx(struct z8530_ch
static void z8530_dma_tx(struct z8530_channel *chan)
{
- spin_lock(chan->lock);
if(!chan->dma_tx)
{
printk(KERN_WARNING "Hey who turned the DMA off?\n");
@@ -557,7 +548,6 @@ static void z8530_dma_tx(struct z8530_ch
/* This shouldnt occur in DMA mode */
printk(KERN_ERR "DMA tx - bogus event!\n");
z8530_tx(chan);
- spin_unlock(chan->lock);
}
/**
@@ -596,7 +586,6 @@ static void z8530_dma_status(struct z853
}
}
- spin_lock(chan->lock);
if(altered&chan->dcdcheck)
{
if(status&chan->dcdcheck)
@@ -618,7 +607,6 @@ static void z8530_dma_status(struct z853
write_zsctrl(chan, RES_EXT_INT);
write_zsctrl(chan, RES_H_IUS);
- spin_unlock(chan->lock);
}
struct z8530_irqhandler z8530_dma_sync=
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 07/11] remove tcp header from tcp_v4_check
From: Frederik Deweerdt <[EMAIL PROTECTED]>
The tcphdr struct passed to tcp_v4_check is not used, the following
patch removes it from the parameter list.
Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/net/tcp.h |5 ++---
net/ipv4/netfilter/ip_nat_helper.c |2 +-
net/ipv4/netfilter/ipt_REJECT.c|2 +-
net/ipv4/netfilter/nf_nat_helper.c |2 +-
net/ipv4/tcp_ipv4.c| 12 ++--
5 files changed, 11 insertions(+), 12 deletions(-)
diff -puN include/net/tcp.h~remove-tcp-header-from-tcp_v4_check-take-2
include/net/tcp.h
--- a/include/net/tcp.h~remove-tcp-header-from-tcp_v4_check-take-2
+++ a/include/net/tcp.h
@@ -802,9 +802,8 @@ static inline void tcp_update_wl(struct
/*
* Calculate(/check) TCP checksum
*/
-static inline __sum16 tcp_v4_check(struct tcphdr *th, int len,
- __be32 saddr, __be32 daddr,
- __wsum base)
+static inline __sum16 tcp_v4_check(int len, __be32 saddr,
+ __be32 daddr, __wsum base)
{
return csum_tcpudp_magic(saddr,daddr,len,IPPROTO_TCP,base);
}
diff -puN
net/ipv4/netfilter/ip_nat_helper.c~remove-tcp-header-from-tcp_v4_check-take-2
net/ipv4/netfilter/ip_nat_helper.c
---
a/net/ipv4/netfilter/ip_nat_helper.c~remove-tcp-header-from-tcp_v4_check-take-2
+++ a/net/ipv4/netfilter/ip_nat_helper.c
@@ -183,7 +183,7 @@ ip_nat_mangle_tcp_packet(struct sk_buff
datalen = (*pskb)->len - iph->ihl*4;
if ((*pskb)->ip_summed != CHECKSUM_PARTIAL) {
tcph->check = 0;
- tcph->check = tcp_v4_check(tcph, datalen,
+ tcph->check = tcp_v4_check(datalen,
iph->saddr, iph->daddr,
csum_partial((char *)tcph,
datalen, 0));
diff -puN
net/ipv4/netfilter/ipt_REJECT.c~remove-tcp-header-from-tcp_v4_check-take-2
net/ipv4/netfilter/ipt_REJECT.c
--- a/net/ipv4/netfilter/ipt_REJECT.c~remove-tcp-header-from-tcp_v4_check-take-2
+++ a/net/ipv4/netfilter/ipt_REJECT.c
@@ -116,7 +116,7 @@ static void send_reset(struct sk_buff *o
/* Adjust TCP checksum */
tcph->check = 0;
- tcph->check = tcp_v4_check(tcph, sizeof(struct tcphdr),
+ tcph->check = tcp_v4_check(sizeof(struct tcphdr),
nskb->nh.iph->saddr,
nskb->nh.iph->daddr,
csum_partial((char *)tcph,
diff -puN
net/ipv4/netfilter/nf_nat_helper.c~remove-tcp-header-from-tcp_v4_check-take-2
net/ipv4/netfilter/nf_nat_helper.c
---
a/net/ipv4/netfilter/nf_nat_helper.c~remove-tcp-header-from-tcp_v4_check-take-2
+++ a/net/ipv4/netfilter/nf_nat_helper.c
@@ -176,7 +176,7 @@ nf_nat_mangle_tcp_packet(struct sk_buff
datalen = (*pskb)->len - iph->ihl*4;
if ((*pskb)->ip_summed != CHECKSUM_PARTIAL) {
tcph->check = 0;
- tcph->check = tcp_v4_check(tcph, datalen,
+ tcph->check = tcp_v4_check(datalen,
iph->saddr, iph->daddr,
csum_partial((char *)tcph,
datalen, 0));
diff -puN net/ipv4/tcp_ipv4.c~remove-tcp-header-from-tcp_v4_check-take-2
net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c~remove-tcp-header-from-tcp_v4_check-take-2
+++ a/net/ipv4/tcp_ipv4.c
@@ -502,11 +502,11 @@ void tcp_v4_send_check(struct sock *sk,
struct tcphdr *th = skb->h.th;
if (skb->ip_summed == CHECKSUM_PARTIAL) {
- th->check = ~tcp_v4_check(th, len,
- inet->saddr, inet->daddr, 0);
+ th->check = ~tcp_v4_check(len, inet->saddr,
+ inet->daddr, 0);
skb->csum_offset = offsetof(struct tcphdr, check);
} else {
- th->check = tcp_v4_check(th, len, inet->saddr, inet->daddr,
+ th->check = tcp_v4_check(len, inet->saddr, inet->daddr,
csum_partial((char *)th,
th->doff << 2,
skb->csum));
@@ -525,7 +525,7 @@ int tcp_v4_gso_send_check(struct sk_buff
th = skb->h.th;
th->check = 0;
- th->check = ~tcp_v4_check(th, skb->len, iph->saddr, iph->daddr, 0);
+ th->check = ~tcp_v4_check(skb->len, iph->saddr, iph->daddr, 0);
skb->csum_offset = offsetof(struct tcphdr, check);
skb->ip_summed = CHECKSUM_PARTIAL;
return 0;
@@ -747,7 +747,7 @@ static int tcp_v4_send_synack(struct soc
if (skb) {
struct tcphdr *th = skb->h.th;
- th->check = tcp_v4_check(th, skb->len,
+ th->check = tcp_v
[patch 01/11] user of the jiffies rounding code: Networking
From: Arjan van de Ven <[EMAIL PROTECTED]>
This patch introduces users of the round_jiffies() function in the networking
code.
These timers all were of the "about once a second" or "about once every X
seconds" variety and several showed up in the "what wakes the cpu up" profiles
that the tickless patches provide. Some timers are highly dynamic based on
network load; but even on low activity systems they still show up so the
rounding is done only in cases of low activity, allowing higher frequency
timers in the high activity case.
The various hardware watchdogs are an obvious case; they run every 2 seconds
but aren't otherwise specific of exactly when they need to run.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |6 +++---
net/core/dst.c |9 -
net/core/neighbour.c |5 -
net/sched/sch_generic.c|2 +-
4 files changed, 16 insertions(+), 6 deletions(-)
diff -puN
drivers/net/e1000/e1000_main.c~user-of-the-jiffies-rounding-code-networking
drivers/net/e1000/e1000_main.c
---
a/drivers/net/e1000/e1000_main.c~user-of-the-jiffies-rounding-code-networking
+++ a/drivers/net/e1000/e1000_main.c
@@ -2652,7 +2652,7 @@ e1000_watchdog(unsigned long data)
netif_carrier_on(netdev);
netif_wake_queue(netdev);
- mod_timer(&adapter->phy_info_timer, jiffies + 2 * HZ);
+ mod_timer(&adapter->phy_info_timer,
round_jiffies(jiffies + 2 * HZ));
adapter->smartspeed = 0;
} else {
/* make sure the receive unit is started */
@@ -2669,7 +2669,7 @@ e1000_watchdog(unsigned long data)
DPRINTK(LINK, INFO, "NIC Link is Down\n");
netif_carrier_off(netdev);
netif_stop_queue(netdev);
- mod_timer(&adapter->phy_info_timer, jiffies + 2 * HZ);
+ mod_timer(&adapter->phy_info_timer,
round_jiffies(jiffies + 2 * HZ));
/* 80003ES2LAN workaround--
* For packet buffer work-around on link down event;
@@ -2721,7 +2721,7 @@ e1000_watchdog(unsigned long data)
e1000_rar_set(&adapter->hw, adapter->hw.mac_addr, 0);
/* Reset the timer */
- mod_timer(&adapter->watchdog_timer, jiffies + 2 * HZ);
+ mod_timer(&adapter->watchdog_timer, round_jiffies(jiffies + 2 * HZ));
}
enum latency_range {
diff -puN net/core/dst.c~user-of-the-jiffies-rounding-code-networking
net/core/dst.c
--- a/net/core/dst.c~user-of-the-jiffies-rounding-code-networking
+++ a/net/core/dst.c
@@ -99,7 +99,14 @@ static void dst_run_gc(unsigned long dum
printk("dst_total: %d/%d %ld\n",
atomic_read(&dst_total), delayed, dst_gc_timer_expires);
#endif
- mod_timer(&dst_gc_timer, jiffies + dst_gc_timer_expires);
+ /* if the next desired timer is more than 4 seconds in the future
+* then round the timer to whole seconds
+*/
+ if (dst_gc_timer_expires > 4*HZ)
+ mod_timer(&dst_gc_timer,
+ round_jiffies(jiffies + dst_gc_timer_expires));
+ else
+ mod_timer(&dst_gc_timer, jiffies + dst_gc_timer_expires);
out:
spin_unlock(&dst_lock);
diff -puN net/core/neighbour.c~user-of-the-jiffies-rounding-code-networking
net/core/neighbour.c
--- a/net/core/neighbour.c~user-of-the-jiffies-rounding-code-networking
+++ a/net/core/neighbour.c
@@ -696,7 +696,10 @@ next_elt:
if (!expire)
expire = 1;
- mod_timer(&tbl->gc_timer, now + expire);
+ if (expire>HZ)
+ mod_timer(&tbl->gc_timer, round_jiffies(now + expire));
+ else
+ mod_timer(&tbl->gc_timer, now + expire);
write_unlock(&tbl->lock);
}
diff -puN net/sched/sch_generic.c~user-of-the-jiffies-rounding-code-networking
net/sched/sch_generic.c
--- a/net/sched/sch_generic.c~user-of-the-jiffies-rounding-code-networking
+++ a/net/sched/sch_generic.c
@@ -209,7 +209,7 @@ static void dev_watchdog(unsigned long a
dev->name);
dev->tx_timeout(dev);
}
- if (!mod_timer(&dev->watchdog_timer, jiffies +
dev->watchdog_timeo))
+ if (!mod_timer(&dev->watchdog_timer,
round_jiffies(jiffies + dev->watchdog_timeo)))
dev_hold(dev);
}
}
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 05/11] bonding: Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls
From: "Joe Jin" <[EMAIL PROTECTED]>
Replace kmalloc() + memset() pairs with the appropriate kzalloc() calls in
the bonding driver.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_alb.c |4 +---
drivers/net/bonding/bond_main.c |4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff -puN
drivers/net/bonding/bond_alb.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
drivers/net/bonding/bond_alb.c
---
a/drivers/net/bonding/bond_alb.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
+++ a/drivers/net/bonding/bond_alb.c
@@ -184,7 +184,7 @@ static int tlb_initialize(struct bonding
spin_lock_init(&(bond_info->tx_hashtbl_lock));
- new_hashtbl = kmalloc(size, GFP_KERNEL);
+ new_hashtbl = kzalloc(size, GFP_KERNEL);
if (!new_hashtbl) {
printk(KERN_ERR DRV_NAME
": %s: Error: Failed to allocate TLB hash table\n",
@@ -195,8 +195,6 @@ static int tlb_initialize(struct bonding
bond_info->tx_hashtbl = new_hashtbl;
- memset(bond_info->tx_hashtbl, 0, size);
-
for (i = 0; i < TLB_HASH_TABLE_SIZE; i++) {
tlb_init_table_entry(&bond_info->tx_hashtbl[i], 1);
}
diff -puN
drivers/net/bonding/bond_main.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
drivers/net/bonding/bond_main.c
---
a/drivers/net/bonding/bond_main.c~bonding-replace-kmalloc-memset-pairs-with-the-appropriate-kzalloc-calls
+++ a/drivers/net/bonding/bond_main.c
@@ -1343,14 +1343,12 @@ int bond_enslave(struct net_device *bond
"inaccurate.\n", bond_dev->name, slave_dev->name);
}
- new_slave = kmalloc(sizeof(struct slave), GFP_KERNEL);
+ new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL);
if (!new_slave) {
res = -ENOMEM;
goto err_undo_flags;
}
- memset(new_slave, 0, sizeof(struct slave));
-
/* save slave's original flags before calling
* netdev_set_master and dev_open
*/
_
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] apply cwnd rules to FIN packets with data
Rick Jones wrote: John Heffner wrote: David Miller wrote: However, I can't think of any reason why the cwnd test should not apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) True, it's not going to melt the internet, but why stop at one when two would finish the connection even faster? Not sure I buy this argument. Was there some benchmarking data that was a justification for this in the first place? Is the cwnd in the stack byte based, or packet based? While "all" the RFCs tend to discuss things in terms of byte-based cwnds and assumptions based on MSSes and such, the underlying principle was/is a conservation of packets. As David said, a packet is a packet, and if one were going to be sending a FIN segment, it might as well carry data. And if one isn't comfortable sending that one last data segment with the FIN because cwnd wasn't large enough at the time, should the FIN be sent at that point, even if it is waffer thin? The most conservative thing is to apply congestion control exactly as you would to any other segment, that is, just take the special case out entirely. An empty FIN is not too likely to cause problems, a full-MSS FIN somewhat more so, 2-MSS, yet more, a 64k TSO segment even more. :) I don't have hard data to argue for or against any particular optimization, but it seems there should be some if we're ignoring the standard cwnd rules. -John - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] apply cwnd rules to FIN packets with data
John Heffner wrote: David Miller wrote: However, I can't think of any reason why the cwnd test should not apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) True, it's not going to melt the internet, but why stop at one when two would finish the connection even faster? Not sure I buy this argument. Was there some benchmarking data that was a justification for this in the first place? Is the cwnd in the stack byte based, or packet based? While "all" the RFCs tend to discuss things in terms of byte-based cwnds and assumptions based on MSSes and such, the underlying principle was/is a conservation of packets. As David said, a packet is a packet, and if one were going to be sending a FIN segment, it might as well carry data. And if one isn't comfortable sending that one last data segment with the FIN because cwnd wasn't large enough at the time, should the FIN be sent at that point, even if it is waffer thin? rick jones 2 cents tossed-in from the peanut gallery - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] apply cwnd rules to FIN packets with data
David Miller wrote: However, I can't think of any reason why the cwnd test should not apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) True, it's not going to melt the internet, but why stop at one when two would finish the connection even faster? Not sure I buy this argument. Was there some benchmarking data that was a justification for this in the first place? My first patch was broken anyway (should not have pulled the test from tso_should_defer), and the change is not needed to the nagle test since it's implicit. This patch just restores the old behavior from before TSO, sending the FIN when it's the last true segment. We can debate the merits of applying congestion control to the FIN separately. :) -John Don't apply FIN exception to full TSO segments. Signed-off-by: John Heffner <[EMAIL PROTECTED]> --- commit 89de0d8cb75958b0315c076b31a597143e30f7a4 tree 7e9c321e62729c6ef76e3886fe9edf2ac78a680c parent c0d4d573feed199b16094c072e7cb07afb01c598 author John Heffner <[EMAIL PROTECTED]> Mon, 05 Feb 2007 18:42:31 -0500 committer John Heffner <[EMAIL PROTECTED]> Mon, 05 Feb 2007 18:42:31 -0500 net/ipv4/tcp_output.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 975f447..58b7111 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -965,7 +965,8 @@ static inline unsigned int tcp_cwnd_test u32 in_flight, cwnd; /* Don't be strict about the congestion window for the final FIN. */ - if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) + if ((TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && + tcp_skb_pcount(skb) == 1) return 1; in_flight = tcp_packets_in_flight(tp);
Re: [PATCH] d80211: respect extra_tx_headroom
On Monday 05 February 2007 22:37, Jiri Benc wrote:
> On Mon, 5 Feb 2007 16:32:24 +0100, Ivo van Doorn wrote:
> > When a driver requested additional header room
> > through the extra_tx_headroom field, the stack
> > should respect that and make sure that all frames
> > that are being send to the stack actually have
> > that extra header room.
> >
> > [...]
> > --- dscape/net/d80211/ieee80211_sta.c 2007-02-05 16:18:41.0
> > +0100
> > [...]
> > @@ -2007,6 +2017,8 @@
> > if (!skb)
> > break;
> >
> > + skb_reserve(skb, local->hw.extra_tx_headroom);
> > +
> > mgmt = (struct ieee80211_mgmt *)
> > skb_put(skb, 24 + sizeof(mgmt->u.beacon));
> > memset(mgmt, 0, 24 + sizeof(mgmt->u.beacon));
>
> Please enlarge that dev_alloc_skb(400) few lines above by
> extra_tx_headroom as well.
Ok.
> Btw, it would be nice if you could use -p option for diff as it makes
> reviewing easier for me.
Not a problem, I'll try to remember it for future patches.
Here is the updated patch.
When a driver requested additional header room
through the extra_tx_headroom field, the stack
should respect that and make sure that all frames
that are being send to the stack actually have
that extra header room.
Besides the additional bytes for the beacon template, this patch
is no longer depends on the rts patch to be applied.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rpU3 dscape.control/net/d80211/ieee80211.c
dscape.skb/net/d80211/ieee80211.c
--- dscape.control/net/d80211/ieee80211.c 2007-02-06 00:25:26.0
+0100
+++ dscape.skb/net/d80211/ieee80211.c 2007-02-06 00:39:07.0 +0100
@@ -470,10 +470,9 @@ ieee80211_tx_h_fragment(struct ieee80211
/* reserve enough extra head and tail room for possible
* encryption */
-#define IEEE80211_ENCRYPT_HEADROOM 8
-#define IEEE80211_ENCRYPT_TAILROOM 12
frag = frags[i] =
- dev_alloc_skb(frag_threshold +
+ dev_alloc_skb(tx->local->hw.extra_tx_headroom +
+ frag_threshold +
IEEE80211_ENCRYPT_HEADROOM +
IEEE80211_ENCRYPT_TAILROOM);
if (!frag)
@@ -481,7 +480,8 @@ ieee80211_tx_h_fragment(struct ieee80211
/* Make sure that all fragments use the same priority so
* that they end up using the same TX queue */
frag->priority = first->priority;
- skb_reserve(frag, IEEE80211_ENCRYPT_HEADROOM);
+ skb_reserve(frag, tx->local->hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM);
fhdr = (struct ieee80211_hdr *) skb_put(frag, hdrlen);
memcpy(fhdr, first->data, hdrlen);
if (i == num_fragm - 2)
@@ -1362,6 +1362,7 @@ static int ieee80211_master_start_xmit(s
struct ieee80211_tx_packet_data *pkt_data;
struct net_device *odev = NULL;
struct ieee80211_sub_if_data *osdata;
+ int headroom;
int ret;
/*
@@ -1386,6 +1387,15 @@ static int ieee80211_master_start_xmit(s
}
osdata = IEEE80211_DEV_TO_SUB_IF(odev);
+ headroom = osdata->local->hw.extra_tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM;
+ if (skb_headroom(skb) < headroom) {
+ if (pskb_expand_head(skb, headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
control.ifindex = odev->ifindex;
control.type = osdata->type;
if (pkt_data->req_tx_status)
@@ -1615,6 +1625,14 @@ ieee80211_mgmt_start_xmit(struct sk_buff
return 0;
}
+ if (skb_headroom(skb) < sdata->local->hw.extra_tx_headroom) {
+ if (pskb_expand_head(skb,
+ sdata->local->hw.extra_tx_headroom, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
+ }
+
hdr = (struct ieee80211_hdr *) skb->data;
fc = le16_to_cpu(hdr->frame_control);
@@ -1748,10 +1766,12 @@ struct sk_buff * ieee80211_beacon_get(st
bh_len = ap->beacon_head_len;
bt_len = ap->beacon_tail_len;
- skb = dev_alloc_skb(bh_len + bt_len + 256 /* maximum TIM len */);
+ skb = dev_alloc_skb(local->hw.extra_tx_headroom +
+ bh_len + bt_len + 256 /* maximum TIM len */);
if (!skb)
return NULL;
+ skb_reserve(skb, local->hw.extra_tx_headroom);
memcpy(skb_put(skb, bh_len), b_head, bh_len);
ieee80211_beacon_add_tim(local, ap, skb);
diff -rpU3 dscape.control/net/d80211/ieee80211_i.h
dscape.skb/net/d80211/ieee80211_i.h
--- dscape.control/net/d80211/ieee80211_i.h 2007-02-06 00:19:38.0
+0100
+++ dscape.skb/net/d80211/ieee80211_i.h 2
Re: [PATCH 1/3] d80211: Add control structure for beacontemplates
On Monday 05 February 2007 21:28, Jiri Benc wrote:
> On Sat, 3 Feb 2007 17:25:18 +0100, Ivo van Doorn wrote:
> > When rt2500usb and rt73usb will start using beacontemplates,
> > they would also need a control structure to be passed along to
> > correctly set the tx parameters.
>
> Good catch, thanks.
>
> > This patch will add the allocation an initialization of a
> > ieee80211_tx_control especially for the beacontemplate.
> >
> > This does require drivers that have the BEACON_TEMPLATE flag
> > set to also free the control structure. (bcm43xx and p54 will be
> > fixed in the next 2 patches)
>
> I would prefer using local variable for tx_control. Driver will be
> responsible for copying it somewhere if it needs to. I believe most
> drivers won't need to do that and it will prevent potential memory
> leaks as it's easy to forget to free the structure.
Sounds good to me, that would absolute the fix for bcm43xx I had send,
but the updated patch for p54 would still be required to make sure p54
no longer requests the beacon without ever using (or freeing it).
This is the updated patch to add the control structure to the beacontemplate.
This time no seperately allocated control structure, but a local variable
inside the ieee80211_if_conf structure.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rpU3 dscape/include/net/d80211.h dscape.control/include/net/d80211.h
--- dscape/include/net/d80211.h 2007-02-06 00:19:37.0 +0100
+++ dscape.control/include/net/d80211.h 2007-02-06 00:23:45.0 +0100
@@ -374,6 +374,8 @@ struct ieee80211_if_init_conf {
* @beacon: beacon template. Valid only if @host_gen_beacon_template in
* &struct ieee80211_hw is set. The driver is responsible of freeing
* the sk_buff.
+ * @beacon_control: tx_control for the beacon template, this field is only
+ * valid when the @beacon field was set.
*
* This structure is passed to the config_interface() callback of
* &struct ieee80211_hw.
@@ -386,6 +388,7 @@ struct ieee80211_if_conf {
u8 *generic_elem;
size_t generic_elem_len;
struct sk_buff *beacon;
+ struct ieee80211_tx_control beacon_control;
};
typedef enum { ALG_NONE, ALG_WEP, ALG_TKIP, ALG_CCMP, ALG_NULL }
diff -rpU3 dscape/net/d80211/ieee80211.c dscape.control/net/d80211/ieee80211.c
--- dscape/net/d80211/ieee80211.c 2007-02-06 00:19:38.0 +0100
+++ dscape.control/net/d80211/ieee80211.c 2007-02-06 00:25:26.0
+0100
@@ -1857,7 +1857,8 @@ ieee80211_get_buffered_bc(struct ieee802
EXPORT_SYMBOL(ieee80211_get_buffered_bc);
static int __ieee80211_if_config(struct net_device *dev,
-struct sk_buff *beacon)
+struct sk_buff *beacon,
+struct ieee80211_tx_control *control)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_local *local = dev->ieee80211_ptr;
@@ -1881,6 +1882,7 @@ static int __ieee80211_if_config(struct
conf.generic_elem = sdata->u.ap.generic_elem;
conf.generic_elem_len = sdata->u.ap.generic_elem_len;
conf.beacon = beacon;
+ memcpy(&conf.beacon_control, control, sizeof(*control));
}
return local->ops->config_interface(local_to_hw(local),
dev->ifindex, &conf);
@@ -1888,20 +1890,21 @@ static int __ieee80211_if_config(struct
int ieee80211_if_config(struct net_device *dev)
{
- return __ieee80211_if_config(dev, NULL);
+ return __ieee80211_if_config(dev, NULL, NULL);
}
int ieee80211_if_config_beacon(struct net_device *dev)
{
struct ieee80211_local *local = dev->ieee80211_ptr;
+ struct ieee80211_tx_control control;
struct sk_buff *skb;
if (!(local->hw.flags & IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE))
return 0;
- skb = ieee80211_beacon_get(local_to_hw(local), dev->ifindex, NULL);
+ skb = ieee80211_beacon_get(local_to_hw(local), dev->ifindex, &control);
if (!skb)
return -ENOMEM;
- return __ieee80211_if_config(dev, skb);
+ return __ieee80211_if_config(dev, skb, &control);
}
int ieee80211_hw_config(struct ieee80211_local *local)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] apply cwnd rules to FIN packets with data
David Miller wrote: From: John Heffner <[EMAIL PROTECTED]> Date: Mon, 05 Feb 2007 16:58:18 -0500 This is especially important with TSO enabled. Currently, it will send a burst of up to 64k at the end of a connection, even when cwnd is much smaller than 64k. This patch still lets out empty FIN packets, but does not apply the special case to FINs carrying data. Good catch John. But I think the correct test on skb->len would be to just make sure that it is <= REAL_MSS. What do you think about that? This would match the original intention of the logic in the pre-TSO days. What was the intention of that logic? Actually, I think it would be better to leave the Nagle test as it was (which is implicitly < real_mss), because there is obviously no point in doing the nagle test when you know there is no more data that will be sent. However, I can't think of any reason why the cwnd test should not apply. -John - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] apply cwnd rules to FIN packets with data
From: John Heffner <[EMAIL PROTECTED]> Date: Mon, 05 Feb 2007 18:02:19 -0500 > David Miller wrote: > > From: John Heffner <[EMAIL PROTECTED]> > > Date: Mon, 05 Feb 2007 16:58:18 -0500 > > > >> This is especially important with TSO enabled. Currently, it will send > >> a burst of up to 64k at the end of a connection, even when cwnd is much > >> smaller than 64k. This patch still lets out empty FIN packets, but does > >> not apply the special case to FINs carrying data. > > > > Good catch John. > > > > But I think the correct test on skb->len would be to just make > > sure that it is <= REAL_MSS. > > > > What do you think about that? This would match the original intention > > of the logic in the pre-TSO days. > > What was the intention of that logic? Because a packet is a packet is a packet. If we let a FIN out it's basically equivalent to a FIN+data as far as the routers are concerned. Either they will drop the packet or they won't. And they will do this regardless of whether data is attached to the FIN. Getting FINs out fast is important for another reason, the faster the session closes the faster "smart" intermediate routers can teardown cached routing or firewall tracking entries for the flow. > Actually, I think it would be better to leave the Nagle test as it was > (which is implicitly < real_mss), because there is obviously no point in > doing the nagle test when you know there is no more data that will be > sent. True. > However, I can't think of any reason why the cwnd test should not > apply. Care to elaborate here? You can view the FIN special case as an off by one error in the CWND test, it's not going to melt the internet. :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] apply cwnd rules to FIN packets with data
From: John Heffner <[EMAIL PROTECTED]> Date: Mon, 05 Feb 2007 16:58:18 -0500 > This is especially important with TSO enabled. Currently, it will send > a burst of up to 64k at the end of a connection, even when cwnd is much > smaller than 64k. This patch still lets out empty FIN packets, but does > not apply the special case to FINs carrying data. Good catch John. But I think the correct test on skb->len would be to just make sure that it is <= REAL_MSS. What do you think about that? This would match the original intention of the logic in the pre-TSO days. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] apply cwnd rules to FIN packets with data
This is especially important with TSO enabled. Currently, it will send a burst of up to 64k at the end of a connection, even when cwnd is much smaller than 64k. This patch still lets out empty FIN packets, but does not apply the special case to FINs carrying data. -John Apply cwnd rules to FIN packets that contain data. --- commit af319609eee705e0791a1a58c33b216e8d0254bf tree 5a1afcc506e09f5adfd74efb7e0cbbc82ec4d5b0 parent c0d4d573feed199b16094c072e7cb07afb01c598 author John Heffner <[EMAIL PROTECTED]> Mon, 05 Feb 2007 16:25:46 -0500 committer John Heffner <[EMAIL PROTECTED]> Mon, 05 Feb 2007 16:25:46 -0500 net/ipv4/tcp_output.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 975f447..215c99d 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -965,7 +965,7 @@ static inline unsigned int tcp_cwnd_test u32 in_flight, cwnd; /* Don't be strict about the congestion window for the final FIN. */ - if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) + if ((TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && skb->len == 0) return 1; in_flight = tcp_packets_in_flight(tp); @@ -1034,7 +1034,7 @@ static inline int tcp_nagle_test(struct /* Don't use the nagle rule for urgent data (or for the final FIN). */ if (tp->urg_mode || - (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN)) + ((TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) && skb->len == 0)) return 1; if (!tcp_nagle_check(tp, skb, cur_mss, nonagle)) @@ -1156,9 +1156,6 @@ static int tcp_tso_should_defer(struct s const struct inet_connection_sock *icsk = inet_csk(sk); u32 send_win, cong_win, limit, in_flight; - if (TCP_SKB_CB(skb)->flags & TCPCB_FLAG_FIN) - goto send_now; - if (icsk->icsk_ca_state != TCP_CA_Open) goto send_now;
netdev-2.6 rebased
I just rebased all branches of netdev-2.6.git, against current Linus TOT (v2.6.20). New maintainers (hi Jay) for example will want to re-clone rather than pulling the remote branch 'foo' into local branch 'foo'. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
From: Joy Latten <[EMAIL PROTECTED]> Date: Mon, 05 Feb 2007 14:53:39 -0600 > I can run some tests with this patch and report any results... Please check out the two most recent patches I posted: 1) Updated core patch with ipv6 side added. 2) Fix for thinko noticed by Venkat. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
From: "Venkat Yekkirala" <[EMAIL PROTECTED]>
Date: Mon, 5 Feb 2007 14:49:17 -0600
> > Something like this (untested) on the ipv4 side, for example:
> >
> > diff --git a/include/net/route.h b/include/net/route.h
> > index 486e37a..a8af632 100644
> > --- a/include/net/route.h
> > +++ b/include/net/route.h
> > @@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
> >
> > static inline int ip_route_connect(struct rtable **rp, __be32 dst,
> >__be32 src, u32 tos, int
> > oif, u8 protocol,
> > - __be16 sport, __be16 dport,
> > struct sock *sk)
> > + __be16 sport, __be16 dport,
> > struct sock *sk,
> > + int flags)
> > {
> > struct flowi fl = { .oif = oif,
> > .nl_u = { .ip4_u = { .daddr = dst,
> > @@ -168,7 +169,7 @@ static inline int ip_route_connect(struct
> > rtable **rp, __be32 dst,
> > *rp = NULL;
> > }
> > security_sk_classify_flow(sk, &fl);
> > - return ip_route_output_flow(rp, &fl, sk, 0);
> > + return ip_route_output_flow(rp, &fl, sk, 1);
>
> I guess you meant to pass the new flags param to ip_route_output_flow here?
Yes I did, thanks for catching that.
commit a6886040ae6b8c9bfc811bd0dbdb47cfa3f2db29
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Mon Feb 5 13:11:42 2007 -0800
[IPV4]: Fix thinko in ip_route_connect().
The idea was the pass in the new "flags" parameter down
to ip_route_output_flow().
Noticed by Venkat Tekkirala.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/net/route.h b/include/net/route.h
index a8af632..1440bdb 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -169,7 +169,7 @@ static inline int ip_route_connect(struct rtable **rp,
__be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, &fl);
- return ip_route_output_flow(rp, &fl, sk, 1);
+ return ip_route_output_flow(rp, &fl, sk, flags);
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
I can run some tests with this patch and report any results...
Regards,
Joy
On Sun, 2007-02-04 at 20:53 -0800, David Miller wrote:
> From: James Morris <[EMAIL PROTECTED]>
> Date: Thu, 1 Feb 2007 18:44:48 -0500 (EST)
>
> > A quick & dirty solution, which is what I think the BSD kernels do, is to
> > still drop the packet but just not return an error to the app. The app
> > then just sees a slight delay on the initial connection, as if a DNS
> > lookup took a bit longer than usual.
>
> I have another idea.
>
> Why don't we just flat-out ignore MSG_DONTWAIT for the socket
> visible cases, and handle connect() similarly?
>
> I think this is (just barely) legal, will be simple to implement, and
> will leave us with semantics that look like:
>
> 1) Sockets never see -EAGAIN due to SA resolution. They'll just
>pause until the route is resolved, even with O_NONBLOCK or
>MSG_DONTWAIT.
>
> 2) Asynchronous contexts such as ICMP replies and firewalling
>will still see the -EAGAIN and simply drop packets.
>
> These sleeps are legal because all of the socket paths involved
> have to be able to do lock_socket() (at a minimum) anyways.
>
> Something like this (untested) on the ipv4 side, for example:
>
> diff --git a/include/net/route.h b/include/net/route.h
> index 486e37a..a8af632 100644
> --- a/include/net/route.h
> +++ b/include/net/route.h
> @@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
>
> static inline int ip_route_connect(struct rtable **rp, __be32 dst,
> __be32 src, u32 tos, int oif, u8 protocol,
> -__be16 sport, __be16 dport, struct sock *sk)
> +__be16 sport, __be16 dport, struct sock *sk,
> +int flags)
> {
> struct flowi fl = { .oif = oif,
> .nl_u = { .ip4_u = { .daddr = dst,
> @@ -168,7 +169,7 @@ static inline int ip_route_connect(struct rtable **rp,
> __be32 dst,
> *rp = NULL;
> }
> security_sk_classify_flow(sk, &fl);
> - return ip_route_output_flow(rp, &fl, sk, 0);
> + return ip_route_output_flow(rp, &fl, sk, 1);
> }
>
> static inline int ip_route_newports(struct rtable **rp, u8 protocol,
> diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
> index 90c74b4..fa2c982 100644
> --- a/net/dccp/ipv4.c
> +++ b/net/dccp/ipv4.c
> @@ -72,7 +72,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr
> *uaddr, int addr_len)
> tmp = ip_route_connect(&rt, nexthop, inet->saddr,
> RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
> IPPROTO_DCCP,
> -inet->sport, usin->sin_port, sk);
> +inet->sport, usin->sin_port, sk, 1);
> if (tmp < 0)
> return tmp;
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 8640096..5750a2b 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1007,7 +1007,7 @@ static int inet_sk_reselect_saddr(struct sock *sk)
> RT_CONN_FLAGS(sk),
> sk->sk_bound_dev_if,
> sk->sk_protocol,
> -inet->sport, inet->dport, sk);
> +inet->sport, inet->dport, sk, 0);
> if (err)
> return err;
>
> diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
> index 7b068a8..0072d79 100644
> --- a/net/ipv4/datagram.c
> +++ b/net/ipv4/datagram.c
> @@ -49,7 +49,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr
> *uaddr, int addr_len)
> err = ip_route_connect(&rt, usin->sin_addr.s_addr, saddr,
> RT_CONN_FLAGS(sk), oif,
> sk->sk_protocol,
> -inet->sport, usin->sin_port, sk);
> +inet->sport, usin->sin_port, sk, 1);
> if (err)
> return err;
> if ((rt->rt_flags & RTCF_BROADCAST) && !sock_flag(sk, SOCK_BROADCAST)) {
> diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
> index a6c63bb..fed6a1e 100644
> --- a/net/ipv4/raw.c
> +++ b/net/ipv4/raw.c
> @@ -489,7 +489,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock
> *sk, struct msghdr *msg,
> }
>
> security_sk_classify_flow(sk, &fl);
> - err = ip_route_output_flow(&rt, &fl, sk,
> !(msg->msg_flags&MSG_DONTWAIT));
> + err = ip_route_output_flow(&rt, &fl, sk, 1);
> }
> if (err)
> goto done;
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index f061ec5..383e4b5 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -191,7 +191,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr
> *uaddr, int addr_len)
> tmp = ip_route_connect(&rt, nexthop, inet->saddr,
> RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
> IPPRO
Re: when having to acquire an SA, ipsec drops the packet
From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 5 Feb 2007 15:34:39 -0500 (EST)
> On Mon, 5 Feb 2007, James Morris wrote:
>
> > On Sun, 4 Feb 2007, David Miller wrote:
> >
> > > Something like this (untested) on the ipv4 side, for example:
> >
> > Looks like it should work. Will do some testing.
>
> Appears to work well, with a slight delay on the first packet as expected.
> Tested with tcp, udp & icmp.
Thanks for testing James.
Last night I put an updated version of my patch into the net-2.6.21
tree, taking care of the ipv6 bits as well. I attach it below
for completeness.
commit cbc77956da98305f0525c0b40257608f0c02a357
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Sun Feb 4 21:21:59 2007 -0800
[IPV4/IPV6]: Always wait for IPSEC SA resolution in socket contexts.
Do this even for non-blocking sockets. This avoids the silly -EAGAIN
that applications can see now, even for non-blocking sockets in some
cases (f.e. connect()).
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/net/route.h b/include/net/route.h
index 486e37a..a8af632 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
static inline int ip_route_connect(struct rtable **rp, __be32 dst,
__be32 src, u32 tos, int oif, u8 protocol,
- __be16 sport, __be16 dport, struct sock *sk)
+ __be16 sport, __be16 dport, struct sock *sk,
+ int flags)
{
struct flowi fl = { .oif = oif,
.nl_u = { .ip4_u = { .daddr = dst,
@@ -168,7 +169,7 @@ static inline int ip_route_connect(struct rtable **rp,
__be32 dst,
*rp = NULL;
}
security_sk_classify_flow(sk, &fl);
- return ip_route_output_flow(rp, &fl, sk, 0);
+ return ip_route_output_flow(rp, &fl, sk, 1);
}
static inline int ip_route_newports(struct rtable **rp, u8 protocol,
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 90c74b4..fa2c982 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -72,7 +72,7 @@ int dccp_v4_connect(struct sock *sk, struct sockaddr *uaddr,
int addr_len)
tmp = ip_route_connect(&rt, nexthop, inet->saddr,
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_DCCP,
- inet->sport, usin->sin_port, sk);
+ inet->sport, usin->sin_port, sk, 1);
if (tmp < 0)
return tmp;
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 6b91a9d..79140b3 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -1041,7 +1041,7 @@ static int dccp_v6_connect(struct sock *sk, struct
sockaddr *uaddr,
if (final_p)
ipv6_addr_copy(&fl.fl6_dst, final_p);
- err = xfrm_lookup(&dst, &fl, sk, 0);
+ err = xfrm_lookup(&dst, &fl, sk, 1);
if (err < 0)
goto failure;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 8640096..5750a2b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1007,7 +1007,7 @@ static int inet_sk_reselect_saddr(struct sock *sk)
RT_CONN_FLAGS(sk),
sk->sk_bound_dev_if,
sk->sk_protocol,
- inet->sport, inet->dport, sk);
+ inet->sport, inet->dport, sk, 0);
if (err)
return err;
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index 7b068a8..0072d79 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -49,7 +49,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
err = ip_route_connect(&rt, usin->sin_addr.s_addr, saddr,
RT_CONN_FLAGS(sk), oif,
sk->sk_protocol,
- inet->sport, usin->sin_port, sk);
+ inet->sport, usin->sin_port, sk, 1);
if (err)
return err;
if ((rt->rt_flags & RTCF_BROADCAST) && !sock_flag(sk, SOCK_BROADCAST)) {
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index a6c63bb..fed6a1e 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -489,7 +489,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock *sk,
struct msghdr *msg,
}
security_sk_classify_flow(sk, &fl);
- err = ip_route_output_flow(&rt, &fl, sk,
!(msg->msg_flags&MSG_DONTWAIT));
+ err = ip_route_output_flow(&rt, &fl, sk, 1);
}
if (err)
goto done;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index f061ec5..383e4b5 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -191,7 +191,7 @@ int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr,
int addr_len)
tmp = ip_rout
Re: when having to acquire an SA, ipsec drops the packet
On Thu, 2007-02-01 at 18:44 -0500, James Morris wrote: > On Thu, 1 Feb 2007, Joy Latten wrote: > > > IPsec returns EAGAIN when it needs to acquire an SA. > > There have been a thread or two about this... > > Has there been any info or progress in how best to fix this? > > > > James Morris presented some work/ideas, > > http://vger.kernel.org/jmorris_ipsec_sa_resolution_netconf2006.pdf > > The status of this is that I started refactoring some core IPv6 code (to > bring it in line with the IPv4 code, e.g. create an ip6_route_connect() to > match ip_route_connect(), and manage the packet queuing from there) and > ran into some IPv6 bugs, and fixed those, but then ran out of time on the > IPsec stuff. AFAIK, no other progress has been made. > > Generally, the problem is only seen when using the BSD userland, which > does not proactively maintain SAs. Openswan does, and general IPsec users > running it never see the problem, so it's not clear how high the priority > is for fixing this really is in the general case. It's quite a lot of > surgery on core networking to fix a problem which doesn't occur with the > Linux tools, which seemingly most people use when they're not using > proprietary and/or userland IPsec stacks. > > Non-kernel options include moving to Openswan (which I would hope is > getting labeled networking support at some stage in any case), or have the > BSD code proactively maintain SAs. > > Also, applications using TCP, and UDP applications with their own session > management, will resend packets while the SA is being negotiated, which > I've observed as typically completing before the first resend. I think > one of the practical problems with this is that the apps are not expecting > an EAGAIN and thus decide to crash. > > A quick & dirty solution, which is what I think the BSD kernels do, is to > still drop the packet but just not return an error to the app. The app > then just sees a slight delay on the initial connection, as if a DNS > lookup took a bit longer than usual. > > > When using labeled xfrms (xfrms that contain a security context), there > > is potential for a greater amount of SAs to be created than when using > > regular xfrms. An SA may be created every time a different security > > context is encountered in a particular traffic stream. This could be > > many if each networking app has its own security context, making current > > behavior problematic. > > Do you have any examples of how many SAs would need to be created on a > typical system? > No, but I have to admit, just playing around with it gives me a scary idea. We have s0-s15 levels, each with c0-c1023 categories. Then I have noticed, each mapped selinux user is a different context... thus just an ssh session by a sysadm and a regular user (who is mapped to an selinux user) can cause 8 SAs to be generated, whereas with regular ipsec, we only need one... :-( Regards, Joy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: when having to acquire an SA, ipsec drops the packet
> Something like this (untested) on the ipv4 side, for example:
>
> diff --git a/include/net/route.h b/include/net/route.h
> index 486e37a..a8af632 100644
> --- a/include/net/route.h
> +++ b/include/net/route.h
> @@ -146,7 +146,8 @@ static inline char rt_tos2priority(u8 tos)
>
> static inline int ip_route_connect(struct rtable **rp, __be32 dst,
> __be32 src, u32 tos, int
> oif, u8 protocol,
> -__be16 sport, __be16 dport,
> struct sock *sk)
> +__be16 sport, __be16 dport,
> struct sock *sk,
> +int flags)
> {
> struct flowi fl = { .oif = oif,
> .nl_u = { .ip4_u = { .daddr = dst,
> @@ -168,7 +169,7 @@ static inline int ip_route_connect(struct
> rtable **rp, __be32 dst,
> *rp = NULL;
> }
> security_sk_classify_flow(sk, &fl);
> - return ip_route_output_flow(rp, &fl, sk, 0);
> + return ip_route_output_flow(rp, &fl, sk, 1);
I guess you meant to pass the new flags param to ip_route_output_flow here?
> }
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Hi Steve
would you mind terribly, changing the -d "$net" to the
-i "$net", and run the script with the interface name instead?
The reason is, that I see 2 different behaviors between blocking
by interface and blocking by IP and would like to find out if
you see it too.
When I block at the interface ( -i eth1 in my case), I see
the path failover happen and flow if resumed.
When I block at the ip address, I see the path failover
in an odd state. It looks like it happened, but the flow is
not resumed. Receive still doesn't get traffic. I think I might
be running a buggy receiver, but I am not 100% sure. In my
case, the sender if running 2.6.10-rc7 and receiver is running
Ubuntu 2.6.17-10.
I'll try running against a different receiver as well.
-vlad
Steve Hill wrote:
> Vlad Yasevich wrote on 05 February 2007 17:08:
>
>> 1. What did you set the sinfo_timetolive to?
>
> I presume you mean the timetolive parameter of sctp_sendmsg()? - this
> was set to 1400ms (as previously mentioned, this was in error but it
> does appear to have highlighted a problem with the stack itself).
>
>> 2. What specific netfilter rule to do use to simulate
>> network outage?
>> I was using '-t filter -A INPUT -i eth0 -p sctp -j DROP'
>
> iptables -A INPUT -d 192.168.2.0/24 -p sctp -j DROP
>
>> Just trying to get more info to simulate this. My prior attempts
>> recovered quickly with my patch.
>
> I usually (but not always - sometimes it happens on the first attempt)
> have to add and remove the iptables rule a few times while running
> traffic over the association in order to reproduce the problem. I'm
> running traffic at a rate of around 500 data chunks per second. Each
> data chunk has a 44 octet payload.
>
> The script I'm using to toggle the iptables rule is below:
>
> --
> #!/bin/sh
>
> net="$1"
>
> flush() {
> iptables -F
> echo "Flush"
> exit
> }
>
> trap flush EXIT
>
> while true; do
> iptables -A INPUT -d "$net" -p sctp -j DROP
> echo "set"
> sleep 5
> iptables -F
> echo "flushed"
> sleep 5
> done
> --
>
> - Steve Hill
>Software Engineer
>Dialogic
>Fordingbridge, Hampshire, UK
>+44-1425-651392
>[EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
On Mon, 5 Feb 2007, James Morris wrote: > On Sun, 4 Feb 2007, David Miller wrote: > > > Something like this (untested) on the ipv4 side, for example: > > Looks like it should work. Will do some testing. Appears to work well, with a slight delay on the first packet as expected. Tested with tcp, udp & icmp. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
yes, well spotted. Please change line 338 in this file to read:
.arg = { .l = { .nr = ARRAY_SIZE(fc_list),
instead, so you can remove the LIST_LEN macro completely.
Thanks,
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 1/3] d80211: Add control structure for beacontemplates
On Sat, 3 Feb 2007 17:25:18 +0100, Ivo van Doorn wrote: > When rt2500usb and rt73usb will start using beacontemplates, > they would also need a control structure to be passed along to > correctly set the tx parameters. Good catch, thanks. > This patch will add the allocation an initialization of a > ieee80211_tx_control especially for the beacontemplate. > > This does require drivers that have the BEACON_TEMPLATE flag > set to also free the control structure. (bcm43xx and p54 will be > fixed in the next 2 patches) I would prefer using local variable for tx_control. Driver will be responsible for copying it somewhere if it needs to. I believe most drivers won't need to do that and it will prevent potential memory leaks as it's easy to forget to free the structure. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate
On Mon, Feb 05, 2007 at 06:59:16PM +0200, Ahmed S. Darwish wrote:
> A patch to use ARRAY_SIZE macro already defined in kernel.h.
OK, but checks you're changing are strange. idx there is signed so
BUG_ON(idx < 0 || idx > ARRAY_SIZE());
should be more appropriate.
> --- a/drivers/net/ibm_emac/ibm_emac_debug.c
> +++ b/drivers/net/ibm_emac/ibm_emac_debug.c
> @@ -132,7 +132,7 @@ void emac_dbg_register(int idx, struct ocp_enet_private
> *dev)
> {
> unsigned long flags;
>
> - if (idx >= sizeof(__emacs) / sizeof(__emacs[0])) {
> + if (idx >= ARRAY_SIZE(__emacs)) {
no __vi, no cookie. :)
> printk(KERN_WARNING
> "invalid index %d when registering EMAC for debugging\n",
> idx);
> @@ -148,7 +148,7 @@ void mal_dbg_register(int idx, struct ibm_ocp_mal *mal)
> {
> unsigned long flags;
>
> - if (idx >= sizeof(__mals) / sizeof(__mals[0])) {
> + if (idx >= ARRAY_SIZE(__mals)) {
> printk(KERN_WARNING
> "invalid index %d when registering MAL for debugging\n",
> idx);
-
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.20] ixgb: Use ARRAY_SIZE macro when appropriate
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote: > A patch to use ARRAY_SIZE macro already defined in kernel.h. Remove it and use ARRAY_SIZE instead. > --- a/drivers/net/ixgb/ixgb_param.c > +++ b/drivers/net/ixgb/ixgb_param.c > @@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option *opt) > return -1; > } > > -#define LIST_LEN(l) (sizeof(l) / sizeof(l[0])) > +#define LIST_LEN(l) ARRAY_SIZE(l) - 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.20] wavelan: Use ARRAY_SIZE macro when appropriate
On Mon, Feb 05, 2007 at 07:00:44PM +0200, Ahmed S. Darwish wrote: > A trivial patch to use ARRAY_SIZE macro. You're supposed to remove it ans use ARRAY_SIZE where old macro is used. > --- a/drivers/net/wireless/wavelan.p.h > +++ b/drivers/net/wireless/wavelan.p.h > @@ -450,7 +450,7 @@ static const char *version= "wavelan.c : v24 (SMP > + wireless extensions) 11/12/ > #define WATCHDOG_JIFFIES(512*HZ/100) > > /* Macro to get the number of elements in an array */ > -#define NELS(a) (sizeof(a) / sizeof(a[0])) > +#define NELS(a) ARRAY_SIZE(a) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on IOAT
On Monday 05 February 2007 19:24, Chris Leech wrote: > It is busy waiting, but only because the TCP socket use initiates the > DMA copies from the softirq and they have time to complete during the > switch back to application context. But to me it looks as if the code in tcp_recvmsg will also initiate DMA copies when the user calls recvmsg and there is data queued on the socket. So in that case, what you end up doing in the same process context is queue DMA ops -> issue pending -> busy wait. In that case, sleeping would sound like the right approach, wouldn't it? > Going back to sleep and creating > more context switching made things worse. I'm working on seeing if > completion interrupts could be used with a better thought out > implementation, the performance implications aren't fully clear to me > yet. > > For other uses, interrupts are probably desired. The NFS client's RPC code hooks into the data_ready callback, tries to find the task that the reply is going to, and copies the data. So per your argument above, for the NFS client it should be okay to busy wait after switching to the task. This would leave the NFS server, which basically uses some kind of poll/recvmsg scheme. In essence, it doesn't call recvmsg until the data has been queued. I guess this kind of code would benefit from using async IO - then the stack can DMA directly into the buffer and then wake up the process. > It's just not there now, but it can be added easily, it's one bit in > the descriptor and a register read in the interrupt handler to see > which channel(s) need attention. Hm, okay. Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/TOY]Extensible hashing and RCU
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
I'm assuming the table is a power of 2 in size with open chaining
for collisions. When the chains get too long, the table is doubled.
When the chains get too short, the table size is halved.
.
For purposes of discussion, I've attached a "toy" implementation
for doing dynamic resizing of a hashtable. It is useless, except
as a proof of concept.
I think this is very similar to what you are describing, no?
--
Arthur
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define _NETHASH_BUFSZ_ 16
#define MODULE_NAME "nethash"
#define _DEBUG_IT_
#ifdef _DEBUG_IT_
#define nprintk(x...) printk(KERN_ALERT x);
#else /* !_DEBUG_IT_ */
#define nprintk(x)
#endif /* _DEBUG_IT_ */
static struct proc_dir_entry *nh_proc_dir;
enum nh_type { NH_ENTRY, NH_HEAD };
struct nh_item {
/* the list head must be first followed by nh_type */
struct list_headnh_list;
enum nh_typenh_type;
};
struct nh_entry {
/* the list head must be first followed by nh_type */
struct list_headnh_list;
enum nh_typenh_type;
unsigned long data;
struct rcu_head rcu_head;
};
struct nh_head {
/* the list head must be first followed by nh_type */
struct list_headlist;
enum nh_typenh_type;
spinlock_t lock;
};
struct nh {
unsigned long nentries;
struct nh_head* hash;
struct rcu_head rcu_head;
};
static struct nh * __nh;
static DEFINE_SEQLOCK(nethash_seq);
static DEFINE_MUTEX(nethash_resize_mutex);
extern void * system_hash_alloc(unsigned long sz);
extern void system_hash_free(void * v, unsigned long sz);
/* XXX nh_dump() is for for debug only
* it must be called under rcu_read_lock() */
static int nh_dump(struct nh * nh, const char * debug_str);
static struct nh * get_nh(void);
static unsigned long nh_hashval(unsigned long data)
{
return data;
}
static void nh_entry_free(struct rcu_head * head)
{
struct nh_entry * entry = container_of(head, struct nh_entry, rcu_head);
nprintk("%s: freeing entry with data %lu\n", __FUNCTION__, entry->data);
kfree(entry);
}
static void nh_free(struct rcu_head * head)
{
struct nh * nh = container_of(head, struct nh, rcu_head);
unsigned long nentries = nh->nentries;
unsigned long size = sizeof (struct nh_head) * nentries;
nprintk("%s: freeing nh of size %lu\n", __FUNCTION__, size);
system_hash_free((void *)nh->hash, size);
nprintk("%s: freeing nh\n", __FUNCTION__);
kfree(nh);
}
/* called with head's spin_lock held */
static int __nh_insert(struct nh_entry * entry,
struct nh_head * head,
unsigned long nentries)
{
struct list_head * prev; /* insert entry after prev */
struct list_head * list;
nprintk("%s: linking entry with data %lu\n", __FUNCTION__,
entry->data);
/* find the appropriate spot to place entry */
prev = &head->list;
if ( nh_hashval(entry->data) & nentries ) {
list_for_each_rcu(list, &head->list) {
struct nh_entry * tmp;
struct nh_item * item = (struct nh_item *)list;
if (item->nh_type != NH_ENTRY)
continue;
tmp = list_entry(list, struct nh_entry, nh_list);
prev = &tmp->nh_list;
if (nh_hashval(tmp->data) & nentries) {
/* put entry after nh */
break;
}
}
}
list_add_rcu(&entry->nh_list, prev);
return 0;
}
/* called with head's lock held */
static void __nh_sort_chain(struct nh_head * head, unsigned long nentries)
{
struct list_head tmp, *list = &head->list;
struct nh_entry* entry;
INIT_LIST_HEAD(&tmp);
list_splice_init(list, &tmp);
while ( !list_empty(&tmp) ) {
struct list_head * first = tmp.next;
list_del(first);
entry = (struct nh_entry*)first;
__nh_insert(entry, head, nentries);
}
}
static void nh_fixup_grow(struct rcu_head * head)
{
struct nh * nh;
struct nh * oh = container_of(head, struct nh, rcu_head);
unsigned long i, oentries = oh->nentries;
rcu_read_lock();
nh = get_nh();
/* this is an rcu_callback - only the "new" nh is
* visible elsewhere now, so make sure to access
* the hashtable using the proper (new) locks,... */
for (i = 0; i <
[PATCH] phy devices: use same arg types
From: Randy Dunlap <[EMAIL PROTECTED]>
sparse complains about differing types from prototype to
definition, so change the u32 to phy_interface_t:
drivers/net/phy/phy_device.c:140:19: error: symbol 'phy_connect' redeclared
with different type (originally declared at include/linux/phy.h:362) -
incompatible argument 5 (different signedness)
drivers/net/phy/phy_device.c:190:19: error: symbol 'phy_attach' redeclared with
different type (originally declared at include/linux/phy.h:360) - incompatible
argument 4 (different signedness)
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/phy/phy_device.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2620-pv.orig/drivers/net/phy/phy_device.c
+++ linux-2620-pv/drivers/net/phy/phy_device.c
@@ -139,7 +139,7 @@ void phy_prepare_link(struct phy_device
*/
struct phy_device * phy_connect(struct net_device *dev, const char *phy_id,
void (*handler)(struct net_device *), u32 flags,
- u32 interface)
+ phy_interface_t interface)
{
struct phy_device *phydev;
@@ -188,7 +188,7 @@ static int phy_compare_id(struct device
}
struct phy_device *phy_attach(struct net_device *dev,
- const char *phy_id, u32 flags, u32 interface)
+ const char *phy_id, u32 flags, phy_interface_t interface)
{
struct bus_type *bus = &mdio_bus_type;
struct phy_device *phydev;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
On Mon, Feb 05, 2007 at 12:33:55PM -0500, Brian Haley wrote:
> >Please, if you think you can find a way for us to do optimistic dad flags
> >as
> >opt-in, rather than masked out, I'm all for it. Thanks!
>
> This patch should apply on-top of yours, if you want I can send the
> whole thing out too. I've only compile-tested it, so don't know if it
> behaves the same as your original.
>
> -Brian
>
Thank you brian, I'll look over and incorporate this into my new tree as I'm
fixing up the anycast hole Vlad brought up
Thanks & Regards
Neil
>
> Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index c341371..ddac8b0 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -593,13 +593,8 @@ ipv6_add_addr(struct inet6_dev *idev, co
> ifa->cstamp = ifa->tstamp = jiffies;
>
> ifa->rt = rt;
> -#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> - if (!idev->cnf.optimistic_dad || ipv6_devconf.forwarding ||
> -(ifa->rt->rt6i_nexthop == NULL))
> + if (rt->rt6i_nexthop == NULL)
> ifa->flags &= ~IFA_F_OPTIMISTIC;
> -#else
> - ifa->flags &= ~IFA_F_OPTIMISTIC;
> -#endif
> ifa->idev = idev;
> in6_dev_hold(idev);
> /* For caller */
> @@ -776,6 +771,7 @@ static int ipv6_create_tempaddr(struct i
> int tmp_plen;
> int ret = 0;
> int max_addresses;
> + u32 addr_flags;
>
> write_lock(&idev->lock);
> if (ift) {
> @@ -833,11 +829,17 @@ retry:
> spin_unlock_bh(&ifp->lock);
>
> write_unlock(&idev->lock);
> +
> + addr_flags = IFA_F_TEMPORARY;
> + /* set in addrconf_prefix_rcv() */
> + if (ifp->flags & IFA_F_OPTIMISTIC)
> + addr_flags |= IFA_F_OPTIMISTIC;
> +
> ift = !max_addresses ||
> ipv6_count_addresses(idev) < max_addresses ?
> ipv6_add_addr(idev, &addr, tmp_plen,
> ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
> - IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL;
> + addr_flags) : NULL;
> if (!ift || IS_ERR(ift)) {
> in6_ifa_put(ifp);
> in6_dev_put(idev);
> @@ -1746,6 +1748,13 @@ ok:
>
> if (ifp == NULL && valid_lft) {
> int max_addresses = in6_dev->cnf.max_addresses;
> + u32 addr_flags = 0;
> +
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + if (in6_dev->cnf.optimistic_dad &&
> + !ipv6_devconf.forwarding)
> + addr_flags = IFA_F_OPTIMISTIC;
> +#endif
>
> /* Do not allow to create too much of autoconfigured
>* addresses; this would be too easy way to crash
> kernel.
> @@ -1753,7 +1762,8 @@ ok:
> if (!max_addresses ||
> ipv6_count_addresses(in6_dev) < max_addresses)
> ifp = ipv6_add_addr(in6_dev, &addr,
> pinfo->prefix_len,
> -
> addr_type&IPV6_ADDR_SCOPE_MASK, 0);
> +
> addr_type&IPV6_ADDR_SCOPE_MASK,
> + addr_flags);
>
> if (!ifp || IS_ERR(ifp)) {
> in6_dev_put(in6_dev);
> @@ -1762,10 +1772,6 @@ ok:
>
> update_lft = create = 1;
> ifp->cstamp = jiffies;
> -#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> - if (ifp->idev->cnf.optimistic_dad)
> - ifp->flags |= IFA_F_OPTIMISTIC;
> -#endif
> addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT);
> }
>
> @@ -2141,9 +2147,16 @@ static void init_loopback(struct net_dev
> static void addrconf_add_linklocal(struct inet6_dev *idev, struct in6_addr
> *addr)
> {
> struct inet6_ifaddr * ifp;
> + u32 addr_flags = IFA_F_PERMANENT;
> +
> +#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
> + if (idev->cnf.optimistic_dad &&
> + !ipv6_devconf.forwarding)
> + addr_flags |= IFA_F_OPTIMISTIC;
> +#endif
> +
>
> - ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK,
> - IFA_F_PERMANENT|IFA_F_OPTIMISTIC);
> + ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, addr_flags);
> if (!IS_ERR(ifp)) {
> addrconf_dad_start(ifp, 0);
> in6_ifa_put(ifp);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
Hi, > > Did you already send that patchset to the netdev list? > > Because I haven't seen a patch series about rts for d80211 yet. > > No, [EMAIL PROTECTED] Hmm, wasn't subscribed to that list yet. :( But now I am. :) > > The new rt2500usb and rt73usb packet ring handling no longer use a DMA > > buffer > > but instead send the sk_buffer->data pointer to the USB layer. > > The solution as suggested by Jiri could be handled by making sure the rts > > allocated > > buffer will also have a tx header room as set in the tx_header_room field. > > But I am not > > sure if that would be a better solution than putting the rts packet in a > > sk_buffer that is being > > send out just before the real packet... > > In my patchset you can put it into anything you like. > I put it into an skb. Sounds good, I'll look that patchset up in the mailarchive. Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: flow control off
Hi Stephen, First, thanks for this detailed explanation. On Mon, Feb 05, 2007 at 09:22:53AM -0800, Stephen Hemminger wrote: > Here is what I saw. > > The transmitter on the Marvell Yukon II (88e8053) hangs when doing transmit > flow > control under load. There appears to be a bug or race condition that > causes the MAC to stop transmitting data. > > There are two drivers for the Yukon II device on Linux. SysKonnect/Marvell > has one called sk98lin it is downloadable from syskonnect.def, and I wrote > one called sky2 that is part of the standard Linux kernel. This problem > is reproducible with the sky2 driver only; the sk98lin driver has a watchdog > routine that resets the hardware perodically, so it masks the problem. > > When the failure mode occurs only after several minutes of sustained activity > and a situation where PAUSE frames would be received. In my testing I used > > server == 1000mbit ===> switch --- 100mbit ---> client > > Server was Mac Mini (88E8053) running Linux 2.6.20-rc7 and client was a > Sony Vaio (88e8036) laptop. The server was running NFS in kernel > and client was doing a large copy. The server was using UDP to cause > large amounts of 802 pause frames. The problem is not as reproducible with > TCP tests because TCP congestion control avoids over running the switch. I encountered *exactly* this problem with a one-leg firewall equipped with a 88E8053 attached to a 1000 Mbps switch, itself hosting 100 Mbps stations, but with sk98lin (2.4). Running tcpdump on the firewall, I noticed duplicated and corrupted frames. I could only reproduce the duplicated and corrupted frames on a lab setup, not the Tx hangs, by sending high UDP traffic on the port to a 100 Mbps host. Sending to 1000 Mbps hosts never triggered the problem, hence my conclusions about flow control too. What I found interesting is that using a very old version of the sky2 driver which I had with me (sky2 v0.5), I could not trigger the problem anymore. But right now, I realize that this version of the driver did not support flow control yet, which might converge with your observations : # ethtool -i eth0 driver: sky2 version: 0.5 firmware-version: N/A bus-info: 01:00.0 # ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: off TX: off > When failure occurs: > * packets continue to be received and passed up the stack > > * GMAC status register is the pause state > * transmit packets continue transferred by the DMA into the RAM buffer > * when the the RAM buffer fills no more packets are DMA'd > * when transmit queue in driver fills, it gets a watch dog timeout > > * switch appears to get confused and other ports hang as well. > > During development of the sky2 driver a similar problem was observed on > receive if the receive DMA buffer was not 8 byte aligned. For performance > reasons, Linux drivers usually offset the Rx buffer by 2 bytes so that > the TCP/IP headers are aligned for faster CPU access. If the sky2 Rx > buffer was offset, then the receiver DMA would occasionally hung. The > workaround for receive was to align the receive buffer on a quad word > boundary. > > This problem appears to be flow control related because after disabling > flow control, no errors occurred in a 48 hour test run. No problem here with the old driver without flow control either. I can try to disable it right here on my setup with sk98lin, and test again. I did not know that the sk98lin had a watchdog, it could explain why sometimes the system entered a strange state (packets taking *seconds* to be forwarded). Anyway, I'm more and more convinced that there are hardware bugs. It is not normal at all that both the original syskonnect driver and your fresh new code show such similar problems ! > There probably are other races and hangs that are related. I don't > consider all the hangs eliminated yet. Well, at least you have a more maintainable driver than what was the previous one, so you will eventually manage to fix all problems ;-) Best regards, Willy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 19:08, Jiri Benc wrote: > On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: > > I also think that sending RTS in software is not going to work, > > as the timing can not be guaranteed. And timing is why we do it in > > the first place. If the HW is not capable of sending RTS frames, we > > should not try to emulate them in SW, as it might make the situation > > even worse by messing up the NAVs by wrong timing. > > That's not emulation in the software, it's just similar approach as > with sending fragmented frames - you need (more or less) precise timing > there as well and many cards still want them enqueued one-by-one. The > firmware takes care of the precise timing. The same could apply to RTS > frames (i. e. the firmware recognize them and doesn't send them before > it has the next frame ready). Yeah, ok. I got the point. But still, this does not work with bcm43xx. :) -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on IOAT
On 2/5/07, Olaf Kirch <[EMAIL PROTECTED]> wrote: Nowhere in the dma_async_*complete functions can I see any code that would sleep if the DMA is not yet complete. Am I missing something, or are we really busy-waiting on the DMA engine? Wouldn't this kind of defeat the purpose of freeing up the CPU from the chores of memcpying? It is busy waiting, but only because the TCP socket use initiates the DMA copies from the softirq and they have time to complete during the switch back to application context. Going back to sleep and creating more context switching made things worse. I'm working on seeing if completion interrupts could be used with a better thought out implementation, the performance implications aren't fully clear to me yet. For other uses, interrupts are probably desired. I also checked the code in ioatdma.c - I would have expected there to be some kind of interrupt handler that kicks the upper layers when a DMA operation completes. But the interrupt handler seems to be for error reporting exclusively... It's just not there now, but it can be added easily, it's one bit in the descriptor and a register read in the interrupt handler to see which channel(s) need attention. - Chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 19:07, Ivo van Doorn wrote: > Hi, > > > > > > Not all hardware are capable of generating their own RTS frames. > > > > > This patch will add support for creating the RTS frame in software, > > > > > when the driver requests this through the flag > > > > > IEEE80211_HW_SOFTWARE_RTS > > > > > > > > It seems this is not the ideal solution. Most of drivers needing > > > > software RTS would need to remember the RTS frame somewhere (as they > > > > need to pass it together with the actual frame). > > > > > > Well in case of rt2x00 (I am not sure which other drivers also need > > > software RTS) > > > the rts packet is just inserted inside the packet ring and is treated as > > > a regular > > > packet/fragment that has just been inserted by the driver. > > > > > > This patch just adds this additional packet just before the real packet, > > > and in case > > > the real packet could not be send the rts packet is stored in the > > > ieee80211_tx_stored_packet structure to be send later. > > > > Ok, I see. But this is not going to work with bcm43xx. > > > > I also sent a fix for rt2x00 to work with my patchset. > > Did you already send that patchset to the netdev list? > Because I haven't seen a patch series about rts for d80211 yet. No, [EMAIL PROTECTED] > The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer > but instead send the sk_buffer->data pointer to the USB layer. > The solution as suggested by Jiri could be handled by making sure the rts > allocated > buffer will also have a tx header room as set in the tx_header_room field. > But I am not > sure if that would be a better solution than putting the rts packet in a > sk_buffer that is being > send out just before the real packet... In my patchset you can put it into anything you like. I put it into an skb. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HTB O(1) class lookup
On Thursday 01 February 2007 12:30, Andi Kleen wrote: > Simon Lodal <[EMAIL PROTECTED]> writes: > > Memory is generally not an issue, but CPU is, and you can not beat the > > CPU efficiency of plain array lookup (always faster, and constant time). > > Actually that's not true when the array doesn't fit in cache. > > The cost of going out to memory over caches is so large (factor 100 and > more) that often algorithms with smaller cache footprint can easily beat > algorithms that execute much less instructions if it has less cache misses. > That is because not all instructions have the same cost; anything > in core is very fast but going out to memory is very slow. > > That said I think I agree with your analysis that a two level > array is probably the right data structure for this and likely > not less cache efficient than the hash table. Good point. The 2-level lookup generates 3 memory accesses (including getting at the htb_class struct). List traversal will generate many more memory accesses, unless the lists have 3 or fewer entries (currently that only holds true for up to 48 classes, uniformly distributed). It is difficult to judge if the tables will be in cache or not. The tables are clearly extra baggage for the cachelines, compared to only having the htb_class structs (they are going to be fetched anyway). On the other hand, if you have 10k classes, they are usually (real world) allocated for individual users, of which at most half are active at any time. With hashing, all 10k classes are fetched into cachelines all the time, only in order to traverse lists. That is >150k wasted cache (5000 x 32 bytes); plenty for 10k pointers in lookup tables. Regards Simon - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 19:08, Jiri Benc wrote: > On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: > > I also think that sending RTS in software is not going to work, > > as the timing can not be guaranteed. And timing is why we do it in > > the first place. If the HW is not capable of sending RTS frames, we > > should not try to emulate them in SW, as it might make the situation > > even worse by messing up the NAVs by wrong timing. > > That's not emulation in the software, it's just similar approach as > with sending fragmented frames - you need (more or less) precise timing > there as well and many cards still want them enqueued one-by-one. The > firmware takes care of the precise timing. The same could apply to RTS > frames (i. e. the firmware recognize them and doesn't send them before > it has the next frame ready). And even for a "dumb" device like rt2x00 (no firmware for rt2400pci, rt2500pci or rt2500usb) it still has rts capabilities. It is just not capable of creating the frame, but the descriptor has a special field that should be set in case of a rts frame. So that would suggest that the device will treat the frame a little bit different than a regular frame. Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Extensible hashing and RCU
On Sat, 4 Feb 2007 [EMAIL PROTECTED] wrote: I noticed in an LCA talk mention that apprently extensible hashing with RCU access is an unsolved problem. Here's an idea for solving it. Yes, I have been playing around with the same idea for doing dynamic resizing of the TCP hashtable. Did a prototype "toy" implementation, and I have a "half-finished" patch which resizes the TCP hashtable at runtime. Hmmm, your mail may be the impetus to get me to finally finish this thing -- Arthur - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Mon, 5 Feb 2007 18:43:06 +0100, Michael Buesch wrote: > I also think that sending RTS in software is not going to work, > as the timing can not be guaranteed. And timing is why we do it in > the first place. If the HW is not capable of sending RTS frames, we > should not try to emulate them in SW, as it might make the situation > even worse by messing up the NAVs by wrong timing. That's not emulation in the software, it's just similar approach as with sending fragmented frames - you need (more or less) precise timing there as well and many cards still want them enqueued one-by-one. The firmware takes care of the precise timing. The same could apply to RTS frames (i. e. the firmware recognize them and doesn't send them before it has the next frame ready). Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
Hi, > > > > Not all hardware are capable of generating their own RTS frames. > > > > This patch will add support for creating the RTS frame in software, > > > > when the driver requests this through the flag > > > > IEEE80211_HW_SOFTWARE_RTS > > > > > > It seems this is not the ideal solution. Most of drivers needing > > > software RTS would need to remember the RTS frame somewhere (as they > > > need to pass it together with the actual frame). > > > > Well in case of rt2x00 (I am not sure which other drivers also need > > software RTS) > > the rts packet is just inserted inside the packet ring and is treated as a > > regular > > packet/fragment that has just been inserted by the driver. > > > > This patch just adds this additional packet just before the real packet, > > and in case > > the real packet could not be send the rts packet is stored in the > > ieee80211_tx_stored_packet structure to be send later. > > Ok, I see. But this is not going to work with bcm43xx. > > I also sent a fix for rt2x00 to work with my patchset. Did you already send that patchset to the netdev list? Because I haven't seen a patch series about rts for d80211 yet. > > > A better solution would be either to pass a pointer to RTS frame data > > > in tx_control or to create a function returning RTS frame. > > > > In case of rt2x00 this would deliver more problems, especially since it > > will use > > a ring entry to send the rts frame and in case of rt2500usb and rt73usb it > > will > > need a sk_buff structure since it needs to pass it to the device (where the > > sk_buff > > will have some free tx_header_room for the descriptor.) > > I don't understand this. > You need to put in into the ring either way. The new rt2500usb and rt73usb packet ring handling no longer use a DMA buffer but instead send the sk_buffer->data pointer to the USB layer. The solution as suggested by Jiri could be handled by making sure the rts allocated buffer will also have a tx header room as set in the tx_header_room field. But I am not sure if that would be a better solution than putting the rts packet in a sk_buffer that is being send out just before the real packet... For the timing problem you mentioned, another solution could be implemented, like already mentioned on the d80211 TODO list, the dscape stack should be able to send a signal to the driver that the last fragment was handed over, this signal can be used by the driver to start sending out the queued packets. This would at least work for rt2x00 where especially for PCI devices _no_ packets are being send until the TX ring has been kicked. Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] d80211: Add software sequence support
On Monday 05 February 2007 18:37, Jiri Benc wrote: > On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote: > > --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100 > > +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0 > > +0100 > > @@ -405,6 +405,7 @@ > > int *supp_rates[NUM_IEEE80211_MODES]; > > int *basic_rates[NUM_IEEE80211_MODES]; > > > > + u16 seq_counter; > > Shouldn't this be per-BSS? Ok I'll try to get a per-BSS sequence counter working, I'll need some time to figure out how the per-BSS code is working. Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take35 0/10] kevent: Generic event handling mechanism.
On Mon, Feb 05, 2007 at 11:28:05AM -0600, David M. Lloyd ([EMAIL PROTECTED]) wrote: > On Thu, 2007-02-01 at 13:12 +0300, Evgeniy Polyakov wrote: > > Generic event handling mechanism. > > The patch applied cleanly to 2.6.20 final, but I got a build error: > > CC kernel/kevent/kevent.o > CC kernel/kevent/kevent_user.o > CC kernel/kevent/kevent_timer.o > CC kernel/kevent/kevent_poll.o > make[2]: *** No rule to make target `kernel/kevent/epoll.o', needed by > `kernel/kevent/built-in.o'. Stop. > make[1]: *** [kernel/kevent] Error 2 > make: *** [kernel] Error 2 It looks like I generated wrong diff from my tree - it compiles just fine. This patch should fix it. That hunk is about epoll rewrite over keent I posted couple of weeks ago. Thanks for testing. > - DML diff --git a/kernel/kevent/Makefile b/kernel/kevent/Makefile index a179bea..dc7f8b2 100644 --- a/kernel/kevent/Makefile +++ b/kernel/kevent/Makefile @@ -1,6 +1,6 @@ obj-y := kevent.o kevent_user.o obj-$(CONFIG_KEVENT_TIMER) += kevent_timer.o -obj-$(CONFIG_KEVENT_POLL) += kevent_poll.o epoll.o +obj-$(CONFIG_KEVENT_POLL) += kevent_poll.o obj-$(CONFIG_KEVENT_SOCKET) += kevent_socket.o obj-$(CONFIG_KEVENT_PIPE) += kevent_pipe.o obj-$(CONFIG_KEVENT_SIGNAL) += kevent_signal.o -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 18:43, Ivo van Doorn wrote: > On Monday 05 February 2007 18:28, Jiri Benc wrote: > > On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: > > > Not all hardware are capable of generating their own RTS frames. > > > This patch will add support for creating the RTS frame in software, > > > when the driver requests this through the flag > > > IEEE80211_HW_SOFTWARE_RTS > > > > It seems this is not the ideal solution. Most of drivers needing > > software RTS would need to remember the RTS frame somewhere (as they > > need to pass it together with the actual frame). > > Well in case of rt2x00 (I am not sure which other drivers also need software > RTS) > the rts packet is just inserted inside the packet ring and is treated as a > regular > packet/fragment that has just been inserted by the driver. > > This patch just adds this additional packet just before the real packet, and > in case > the real packet could not be send the rts packet is stored in the > ieee80211_tx_stored_packet structure to be send later. Ok, I see. But this is not going to work with bcm43xx. I also sent a fix for rt2x00 to work with my patchset. > > A better solution would be either to pass a pointer to RTS frame data > > in tx_control or to create a function returning RTS frame. > > In case of rt2x00 this would deliver more problems, especially since it will > use > a ring entry to send the rts frame and in case of rt2500usb and rt73usb it > will > need a sk_buff structure since it needs to pass it to the device (where the > sk_buff > will have some free tx_header_room for the descriptor.) I don't understand this. You need to put in into the ring either way. See my patch. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 18:28, Jiri Benc wrote: > On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: > > Not all hardware are capable of generating their own RTS frames. > > This patch will add support for creating the RTS frame in software, > > when the driver requests this through the flag > > IEEE80211_HW_SOFTWARE_RTS > > It seems this is not the ideal solution. Most of drivers needing > software RTS would need to remember the RTS frame somewhere (as they > need to pass it together with the actual frame). > > A better solution would be either to pass a pointer to RTS frame data > in tx_control or to create a function returning RTS frame. I sent a patchset that works with most (all?) hardware implementations, as it uses library calls. I also think that sending RTS in software is not going to work, as the timing can not be guaranteed. And timing is why we do it in the first place. If the HW is not capable of sending RTS frames, we should not try to emulate them in SW, as it might make the situation even worse by messing up the NAVs by wrong timing. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] d80211: Add software RTS support
On Monday 05 February 2007 18:28, Jiri Benc wrote: > On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: > > Not all hardware are capable of generating their own RTS frames. > > This patch will add support for creating the RTS frame in software, > > when the driver requests this through the flag > > IEEE80211_HW_SOFTWARE_RTS > > It seems this is not the ideal solution. Most of drivers needing > software RTS would need to remember the RTS frame somewhere (as they > need to pass it together with the actual frame). Well in case of rt2x00 (I am not sure which other drivers also need software RTS) the rts packet is just inserted inside the packet ring and is treated as a regular packet/fragment that has just been inserted by the driver. This patch just adds this additional packet just before the real packet, and in case the real packet could not be send the rts packet is stored in the ieee80211_tx_stored_packet structure to be send later. > A better solution would be either to pass a pointer to RTS frame data > in tx_control or to create a function returning RTS frame. In case of rt2x00 this would deliver more problems, especially since it will use a ring entry to send the rts frame and in case of rt2500usb and rt73usb it will need a sk_buff structure since it needs to pass it to the device (where the sk_buff will have some free tx_header_room for the descriptor.) Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] d80211: Add software sequence support
On Sat, 3 Feb 2007 12:45:26 +0100, Ivo van Doorn wrote: > --- dscape/net/d80211/ieee80211_i.h 2007-01-31 19:41:53.0 +0100 > +++ dscape_seq/net/d80211/ieee80211_i.h 2007-01-31 20:06:26.0 > +0100 > @@ -405,6 +405,7 @@ > int *supp_rates[NUM_IEEE80211_MODES]; > int *basic_rates[NUM_IEEE80211_MODES]; > > + u16 seq_counter; Shouldn't this be per-BSS? Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Please, if you think you can find a way for us to do optimistic dad flags as
opt-in, rather than masked out, I'm all for it. Thanks!
This patch should apply on-top of yours, if you want I can send the
whole thing out too. I've only compile-tested it, so don't know if it
behaves the same as your original.
-Brian
Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index c341371..ddac8b0 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -593,13 +593,8 @@ ipv6_add_addr(struct inet6_dev *idev, co
ifa->cstamp = ifa->tstamp = jiffies;
ifa->rt = rt;
-#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
- if (!idev->cnf.optimistic_dad || ipv6_devconf.forwarding ||
- (ifa->rt->rt6i_nexthop == NULL))
+ if (rt->rt6i_nexthop == NULL)
ifa->flags &= ~IFA_F_OPTIMISTIC;
-#else
- ifa->flags &= ~IFA_F_OPTIMISTIC;
-#endif
ifa->idev = idev;
in6_dev_hold(idev);
/* For caller */
@@ -776,6 +771,7 @@ static int ipv6_create_tempaddr(struct i
int tmp_plen;
int ret = 0;
int max_addresses;
+ u32 addr_flags;
write_lock(&idev->lock);
if (ift) {
@@ -833,11 +829,17 @@ retry:
spin_unlock_bh(&ifp->lock);
write_unlock(&idev->lock);
+
+ addr_flags = IFA_F_TEMPORARY;
+ /* set in addrconf_prefix_rcv() */
+ if (ifp->flags & IFA_F_OPTIMISTIC)
+ addr_flags |= IFA_F_OPTIMISTIC;
+
ift = !max_addresses ||
ipv6_count_addresses(idev) < max_addresses ?
ipv6_add_addr(idev, &addr, tmp_plen,
ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
- IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL;
+ addr_flags) : NULL;
if (!ift || IS_ERR(ift)) {
in6_ifa_put(ifp);
in6_dev_put(idev);
@@ -1746,6 +1748,13 @@ ok:
if (ifp == NULL && valid_lft) {
int max_addresses = in6_dev->cnf.max_addresses;
+ u32 addr_flags = 0;
+
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ if (in6_dev->cnf.optimistic_dad &&
+ !ipv6_devconf.forwarding)
+addr_flags = IFA_F_OPTIMISTIC;
+#endif
/* Do not allow to create too much of autoconfigured
* addresses; this would be too easy way to crash kernel.
@@ -1753,7 +1762,8 @@ ok:
if (!max_addresses ||
ipv6_count_addresses(in6_dev) < max_addresses)
ifp = ipv6_add_addr(in6_dev, &addr, pinfo->prefix_len,
- addr_type&IPV6_ADDR_SCOPE_MASK, 0);
+ addr_type&IPV6_ADDR_SCOPE_MASK,
+ addr_flags);
if (!ifp || IS_ERR(ifp)) {
in6_dev_put(in6_dev);
@@ -1762,10 +1772,6 @@ ok:
update_lft = create = 1;
ifp->cstamp = jiffies;
-#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
- if (ifp->idev->cnf.optimistic_dad)
-ifp->flags |= IFA_F_OPTIMISTIC;
-#endif
addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT);
}
@@ -2141,9 +2147,16 @@ static void init_loopback(struct net_dev
static void addrconf_add_linklocal(struct inet6_dev *idev, struct in6_addr *addr)
{
struct inet6_ifaddr * ifp;
+ u32 addr_flags = IFA_F_PERMANENT;
+
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ if (idev->cnf.optimistic_dad &&
+ !ipv6_devconf.forwarding)
+ addr_flags |= IFA_F_OPTIMISTIC;
+#endif
+
- ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK,
- IFA_F_PERMANENT|IFA_F_OPTIMISTIC);
+ ifp = ipv6_add_addr(idev, addr, 64, IFA_LINK, addr_flags);
if (!IS_ERR(ifp)) {
addrconf_dad_start(ifp, 0);
in6_ifa_put(ifp);
Re: [PATCH 1/2] d80211: Add software RTS support
On Wed, 31 Jan 2007 20:16:50 +0100, Ivo van Doorn wrote: > Not all hardware are capable of generating their own RTS frames. > This patch will add support for creating the RTS frame in software, > when the driver requests this through the flag > IEEE80211_HW_SOFTWARE_RTS It seems this is not the ideal solution. Most of drivers needing software RTS would need to remember the RTS frame somewhere (as they need to pass it together with the actual frame). A better solution would be either to pass a pointer to RTS frame data in tx_control or to create a function returning RTS frame. Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: flow control off
Here is what I saw. The transmitter on the Marvell Yukon II (88e8053) hangs when doing transmit flow control under load. There appears to be a bug or race condition that causes the MAC to stop transmitting data. There are two drivers for the Yukon II device on Linux. SysKonnect/Marvell has one called sk98lin it is downloadable from syskonnect.def, and I wrote one called sky2 that is part of the standard Linux kernel. This problem is reproducible with the sky2 driver only; the sk98lin driver has a watchdog routine that resets the hardware perodically, so it masks the problem. When the failure mode occurs only after several minutes of sustained activity and a situation where PAUSE frames would be received. In my testing I used server == 1000mbit ===> switch --- 100mbit ---> client Server was Mac Mini (88E8053) running Linux 2.6.20-rc7 and client was a Sony Vaio (88e8036) laptop. The server was running NFS in kernel and client was doing a large copy. The server was using UDP to cause large amounts of 802 pause frames. The problem is not as reproducible with TCP tests because TCP congestion control avoids over running the switch. When failure occurs: * packets continue to be received and passed up the stack * GMAC status register is the pause state * transmit packets continue transferred by the DMA into the RAM buffer * when the the RAM buffer fills no more packets are DMA'd * when transmit queue in driver fills, it gets a watch dog timeout * switch appears to get confused and other ports hang as well. During development of the sky2 driver a similar problem was observed on receive if the receive DMA buffer was not 8 byte aligned. For performance reasons, Linux drivers usually offset the Rx buffer by 2 bytes so that the TCP/IP headers are aligned for faster CPU access. If the sky2 Rx buffer was offset, then the receiver DMA would occasionally hung. The workaround for receive was to align the receive buffer on a quad word boundary. This problem appears to be flow control related because after disabling flow control, no errors occurred in a 48 hour test run. There probably are other races and hangs that are related. I don't consider all the hangs eliminated yet. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Vlad Yasevich wrote on 05 February 2007 17:08:
> 1. What did you set the sinfo_timetolive to?
I presume you mean the timetolive parameter of sctp_sendmsg()? - this
was set to 1400ms (as previously mentioned, this was in error but it
does appear to have highlighted a problem with the stack itself).
> 2. What specific netfilter rule to do use to simulate
> network outage?
> I was using '-t filter -A INPUT -i eth0 -p sctp -j DROP'
iptables -A INPUT -d 192.168.2.0/24 -p sctp -j DROP
> Just trying to get more info to simulate this. My prior attempts
> recovered quickly with my patch.
I usually (but not always - sometimes it happens on the first attempt)
have to add and remove the iptables rule a few times while running
traffic over the association in order to reproduce the problem. I'm
running traffic at a rate of around 500 data chunks per second. Each
data chunk has a 44 octet payload.
The script I'm using to toggle the iptables rule is below:
--
#!/bin/sh
net="$1"
flush() {
iptables -F
echo "Flush"
exit
}
trap flush EXIT
while true; do
iptables -A INPUT -d "$net" -p sctp -j DROP
echo "set"
sleep 5
iptables -F
echo "flushed"
sleep 5
done
--
- Steve Hill
Software Engineer
Dialogic
Fordingbridge, Hampshire, UK
+44-1425-651392
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Question on IOAT
Hi,
I looked into the IOAT code today as I'm trying to find out how to add support
for it to NFS. I ran into this piece of code, which waits for the DMA
operation to complete:
while (dma_async_memcpy_complete(tp->ucopy.dma_chan,
tp->ucopy.dma_cookie, &done,
&used) == DMA_IN_PROGRESS) {
/* do partial cleanup of sk_async_wait_queue */
while ((skb = skb_peek(&sk->sk_async_wait_queue)) &&
(dma_async_is_complete(skb->dma_cookie, done,
used) == DMA_SUCCESS)) {
__skb_dequeue(&sk->sk_async_wait_queue);
kfree_skb(skb);
}
}
Nowhere in the dma_async_*complete functions can I see any code
that would sleep if the DMA is not yet complete. Am I missing something,
or are we really busy-waiting on the DMA engine? Wouldn't this kind of
defeat the purpose of freeing up the CPU from the chores of memcpying?
I also checked the code in ioatdma.c - I would have expected there to
be some kind of interrupt handler that kicks the upper layers when a
DMA operation completes. But the interrupt handler seems to be for
error reporting exclusively...
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] HTB O(1) class lookup
On Monday 05 February 2007 11:16, Jarek Poplawski wrote: > On 01-02-2007 12:30, Andi Kleen wrote: > > Simon Lodal <[EMAIL PROTECTED]> writes: > >> Memory is generally not an issue, but CPU is, and you can not beat the > >> CPU efficiency of plain array lookup (always faster, and constant time). > > Probably for some old (or embedded) lean boxes used for > small network routers, with memory hungry iptables - > memory could be an issue. Sure, but if they are that constrained they probably do not run HTB in the first place. We are talking about 4k initially, up to 256k worst case (or 512k if your router is 64bit, unlikely if "small" is a priority). > > And the worst memory consumption case considered by Patrick should > > be relatively unlikely. > > Anyway, such approach, that most users do something > this (reasonable) way, doesn't look like good > programming practice. The current hash algorithm also assumes certain usage patterns, namely that you choose classids that generate different hash keys (= distribute uniformly across the buckets), or scalability will suffer very quickly. Even at 64 classes you would probably see htb_find() near the top of a profiling analysis. But I would say that it is just as unlikely as choosing 64 classids that cause my patch to allocate all 256k. In these unlikely cases, my patch only wastes passive memory, while the current htb wastes cpu to a point where it can severely limit routing performance. > I wonder, why not try, at least for a while, to do this > a compile (menuconfig) option with a comment: > recommended for a large number of classes. After hash > optimization and some testing, final decisions could be > made. I decided not to do it because it would mean too many ifdefs (ugly+unmaintanable code). Regards Simon - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Hi Steve Steve Hill wrote: Vlad Yasevich wrote on 05 February 2007 16:39: Once you start simulating the network failure, how long do you wait? If you have not changed rto_max and path_max_retrans, you can end up waiting quite a while for the full path switchover. This will also severely slow down your retransmissions... I'm waiting several minutes, and I'm using setsockopt() to set the timeouts fairly low: srto_initial = 1000ms srto_min = 200ms srto_max = 1400ms spp_pathmaxrxt = 2 spp_hbinterval = 1000ms Ok, thanks for the info. Two more questions: 1. What did you set the sinfo_timetolive to? 2. What specific netfilter rule to do use to simulate network outage? I was using '-t filter -A INPUT -i eth0 -p sctp -j DROP' Just trying to get more info to simulate this. My prior attempts recovered quickly with my patch. Thanks -vlad The network's round trip time (indicated by ping) is on the order of <0.25ms. - Steve Hill Software Engineer Dialogic Fordingbridge, Hampshire, UK +44-1425-651392 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20] wavelan: Use ARRAY_SIZE macro when appropriate
Hi, A trivial patch to use ARRAY_SIZE macro. Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> --- diff --git a/drivers/net/wireless/wavelan.p.h b/drivers/net/wireless/wavelan.p.h index 72b646c..fe12c77 100644 --- a/drivers/net/wireless/wavelan.p.h +++ b/drivers/net/wireless/wavelan.p.h @@ -450,7 +450,7 @@ static const char *version= "wavelan.c : v24 (SMP + wireless extensions) 11/12/ #defineWATCHDOG_JIFFIES(512*HZ/100) /* Macro to get the number of elements in an array */ -#defineNELS(a) (sizeof(a) / sizeof(a[0])) +#defineNELS(a) ARRAY_SIZE(a) /* PRIVATE IOCTL */ -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Hi, A patch to use ARRAY_SIZE macro already defined in kernel.h. Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> --- diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c index b27442a..26031fe 100644 --- a/drivers/net/ixgb/ixgb_param.c +++ b/drivers/net/ixgb/ixgb_param.c @@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option *opt) return -1; } -#define LIST_LEN(l) (sizeof(l) / sizeof(l[0])) +#define LIST_LEN(l) ARRAY_SIZE(l) /** * ixgb_check_options - Range Checking for Command Line Parameters -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20] hostap: Use ARRAY_SIZE macro when appropriate
Hi,
A patch to use ARRAY_SIZE macro in the Host AP wireless driver.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/wireless/hostap/hostap.h
b/drivers/net/wireless/hostap/hostap.h
index e89c890..ef37a75 100644
--- a/drivers/net/wireless/hostap/hostap.h
+++ b/drivers/net/wireless/hostap/hostap.h
@@ -2,13 +2,14 @@
#define HOSTAP_H
#include
+#include
#include "hostap_wlan.h"
#include "hostap_ap.h"
static const long freq_list[] = { 2412, 2417, 2422, 2427, 2432, 2437, 2442,
2447, 2452, 2457, 2462, 2467, 2472, 2484 };
-#define FREQ_COUNT (sizeof(freq_list) / sizeof(freq_list[0]))
+#define FREQ_COUNT ARRAY_SIZE(freq_list)
/* hostap.c */
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20] ibm_emac: Use ARRAY_SIZE macro when appropriate
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile-tested cause I don't have the needed hardware.
diff --git a/drivers/net/ibm_emac/ibm_emac_debug.c
b/drivers/net/ibm_emac/ibm_emac_debug.c
index 92f970d..1f70906 100644
--- a/drivers/net/ibm_emac/ibm_emac_debug.c
+++ b/drivers/net/ibm_emac/ibm_emac_debug.c
@@ -132,7 +132,7 @@ void emac_dbg_register(int idx, struct ocp_enet_private
*dev)
{
unsigned long flags;
- if (idx >= sizeof(__emacs) / sizeof(__emacs[0])) {
+ if (idx >= ARRAY_SIZE(__emacs)) {
printk(KERN_WARNING
"invalid index %d when registering EMAC for debugging\n",
idx);
@@ -148,7 +148,7 @@ void mal_dbg_register(int idx, struct ibm_ocp_mal *mal)
{
unsigned long flags;
- if (idx >= sizeof(__mals) / sizeof(__mals[0])) {
+ if (idx >= ARRAY_SIZE(__mals)) {
printk(KERN_WARNING
"invalid index %d when registering MAL for debugging\n",
idx);
@@ -167,11 +167,11 @@ void emac_dbg_dump_all(void)
local_irq_save(flags);
- for (i = 0; i < sizeof(__mals) / sizeof(__mals[0]); ++i)
+ for (i = 0; i < ARRAY_SIZE(__mals); ++i)
if (__mals[i])
emac_mal_dump(__mals[i]);
- for (i = 0; i < sizeof(__emacs) / sizeof(__emacs[0]); ++i)
+ for (i = 0; i < ARRAY_SIZE(__emacs); ++i)
if (__emacs[i])
emac_mac_dump(i, __emacs[i]);
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20] misc-wireless: Use ARRAY_SIZE macro when appropriate
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous wireless drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 44a2270..4ad910b 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -1623,7 +1623,7 @@ static void emmh32_setseed(emmh32_context *context, u8
*pkey, int keylen,
crypto_cipher_setkey(tfm, pkey, 16);
counter = 0;
- for (i = 0; i < (sizeof(context->coeff)/sizeof(context->coeff[0])); ) {
+ for (i = 0; i < ARRAY_SIZE(context->coeff); ) {
aes_counter[15] = (u8)(counter >> 0);
aes_counter[14] = (u8)(counter >> 8);
aes_counter[13] = (u8)(counter >> 16);
@@ -1632,7 +1632,7 @@ static void emmh32_setseed(emmh32_context *context, u8
*pkey, int keylen,
memcpy (plain, aes_counter, 16);
crypto_cipher_encrypt_one(tfm, plain, plain);
cipher = plain;
- for (j=0; (j<16) && (i<
(sizeof(context->coeff)/sizeof(context->coeff[0]))); ) {
+ for (j = 0; (j < 16) && (i < ARRAY_SIZE(context->coeff)); ) {
context->coeff[i++] = ntohl(*(u32 *)&cipher[j]);
j += 4;
}
diff --git a/drivers/net/wireless/prism54/oid_mgt.c
b/drivers/net/wireless/prism54/oid_mgt.c
index e6cf9df..4278032 100644
--- a/drivers/net/wireless/prism54/oid_mgt.c
+++ b/drivers/net/wireless/prism54/oid_mgt.c
@@ -16,6 +16,8 @@
*
*/
+#include
+
#include "prismcompat.h"
#include "islpci_dev.h"
#include "islpci_mgt.h"
@@ -692,7 +694,7 @@ mgt_update_addr(islpci_private *priv)
return ret;
}
-#define VEC_SIZE(a) (sizeof(a)/sizeof(a[0]))
+#define VEC_SIZE(a) ARRAY_SIZE(a)
int
mgt_commit(islpci_private *priv)
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/02] misc-net-drivers: Use ARRAY_SIZE macro when appropriate
Hi,
A 2.6.20 patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous network drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch isn't compile-tested due to missing hardware.
diff --git a/drivers/net/apne.c b/drivers/net/apne.c
index 9541911..8806151 100644
--- a/drivers/net/apne.c
+++ b/drivers/net/apne.c
@@ -247,7 +247,7 @@ static int __init apne_probe1(struct net_device *dev, int
ioaddr)
{0x00, NE_EN0_RSARHI},
{E8390_RREAD+E8390_START, NE_CMD},
};
- for (i = 0; i < sizeof(program_seq)/sizeof(program_seq[0]); i++) {
+ for (i = 0; i < ARRAY_SIZE(program_seq); i++) {
outb(program_seq[i].value, ioaddr + program_seq[i].offset);
}
diff --git a/drivers/net/arm/am79c961a.c b/drivers/net/arm/am79c961a.c
index ddd12d4..200cbc0 100644
--- a/drivers/net/arm/am79c961a.c
+++ b/drivers/net/arm/am79c961a.c
@@ -414,7 +414,7 @@ static void am79c961_setmulticastlist (struct net_device
*dev)
/*
* Update the multicast hash table
*/
- for (i = 0; i < sizeof(multi_hash) / sizeof(multi_hash[0]); i++)
+ for (i = 0; i < ARRAY_SIZE(multi_hash); i++)
write_rreg(dev->base_addr, i + LADRL, multi_hash[i]);
/*
diff --git a/drivers/net/atarilance.c b/drivers/net/atarilance.c
index 7e37ac8..ef18428 100644
--- a/drivers/net/atarilance.c
+++ b/drivers/net/atarilance.c
@@ -263,7 +263,7 @@ struct lance_addr {
(highest byte stripped) */
};
-#defineN_LANCE_ADDR
(sizeof(lance_addr_list)/sizeof(*lance_addr_list))
+#defineN_LANCE_ADDRARRAY_SIZE(lance_addr_list)
/* Definitions for the Lance */
diff --git a/drivers/net/fec_8xx/fec_mii.c b/drivers/net/fec_8xx/fec_mii.c
index d3c16b8..1fc2b43 100644
--- a/drivers/net/fec_8xx/fec_mii.c
+++ b/drivers/net/fec_8xx/fec_mii.c
@@ -310,12 +310,12 @@ int fec_mii_phy_id_detect(struct net_device *dev)
return -1;
}
- for (i = 0, phy = phy_info; i < sizeof(phy_info) / sizeof(phy_info[0]);
+ for (i = 0, phy = phy_info; i < ARRAY_SIZE(phy_info));
i++, phy++)
if (phy->id == (phy_hwid >> 4) || phy->id == 0)
break;
- if (i >= sizeof(phy_info) / sizeof(phy_info[0])) {
+ if (i >= ARRAY_SIZE(phy_info)) {
printk(KERN_ERR DRV_MODULE_NAME
": %s PHY id 0x%08x is not supported!\n",
dev->name, phy_hwid);
diff --git a/drivers/net/ne-h8300.c b/drivers/net/ne-h8300.c
index 38fd525..7599d77 100644
--- a/drivers/net/ne-h8300.c
+++ b/drivers/net/ne-h8300.c
@@ -259,7 +259,7 @@ static int __init ne_probe1(struct net_device *dev, int
ioaddr)
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i < sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i < ARRAY_SIZE(program_seq); i++)
outb_p(program_seq[i].value, ioaddr +
program_seq[i].offset);
}
diff --git a/drivers/net/zorro8390.c b/drivers/net/zorro8390.c
index d85e2ea..29f9750 100644
--- a/drivers/net/zorro8390.c
+++ b/drivers/net/zorro8390.c
@@ -191,7 +191,7 @@ static int __devinit zorro8390_init(struct net_device *dev,
{0x00, NE_EN0_RSARHI},
{E8390_RREAD+E8390_START, NE_CMD},
};
- for (i = 0; i < sizeof(program_seq)/sizeof(program_seq[0]); i++) {
+ for (i = 0; i < ARRAY_SIZE(program_seq); i++) {
z_writeb(program_seq[i].value, ioaddr + program_seq[i].offset);
}
}
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20] ipw2100: Use ARRAY_SIZE macro when appropriate
Hi all,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index b85857a..a9d944a 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -2888,7 +2888,7 @@ static int __ipw2100_tx_process(struct ipw2100_priv *priv)
#ifdef CONFIG_IPW2100_DEBUG
if (packet->info.c_struct.cmd->host_command_reg <
- sizeof(command_types) / sizeof(*command_types))
+ ARRAY_SIZE(command_types))
IPW_DEBUG_TX("Command '%s (%d)' processed: %d.\n",
command_types[packet->info.c_struct.cmd->
host_command_reg],
@@ -3736,7 +3736,7 @@ static ssize_t show_registers(struct device *d, struct
device_attribute *attr,
out += sprintf(out, "%30s [Address ] : Hex\n", "Register");
- for (i = 0; i < (sizeof(hw_data) / sizeof(*hw_data)); i++) {
+ for (i = 0; i < ARRAY_SIZE(hw_data); i++) {
read_register(dev, hw_data[i].addr, &val);
out += sprintf(out, "%30s [%08X] : %08X\n",
hw_data[i].name, hw_data[i].addr, val);
@@ -3757,7 +3757,7 @@ static ssize_t show_hardware(struct device *d, struct
device_attribute *attr,
out += sprintf(out, "%30s [Address ] : Hex\n", "NIC entry");
- for (i = 0; i < (sizeof(nic_data) / sizeof(*nic_data)); i++) {
+ for (i = 0; i < ARRAY_SIZE(nic_data); i++) {
u8 tmp8;
u16 tmp16;
u32 tmp32;
@@ -3894,13 +3894,11 @@ static ssize_t show_ordinals(struct device *d, struct
device_attribute *attr,
if (priv->status & STATUS_RF_KILL_MASK)
return 0;
- if (loop >= sizeof(ord_data) / sizeof(*ord_data))
+ if (loop >= ARRAY_SIZE(ord_data))
loop = 0;
/* sysfs provides us PAGE_SIZE buffer */
- while (len < PAGE_SIZE - 128 &&
- loop < (sizeof(ord_data) / sizeof(*ord_data))) {
-
+ while (len < PAGE_SIZE - 128 && loop < ARRAY_SIZE(ord_data)) {
val_len = sizeof(u32);
if (ipw2100_get_ordinal(priv, ord_data[loop].index, &val,
@@ -6589,7 +6587,7 @@ static const long ipw2100_rates_11b[] = {
1100
};
-#define RATE_COUNT (sizeof(ipw2100_rates_11b) / sizeof(ipw2100_rates_11b[0]))
+#define RATE_COUNT ARRAY_SIZE(ipw2100_rates_11b)
static int ipw2100_wx_get_name(struct net_device *dev,
struct iw_request_info *info,
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/02] misc-net-drivers: Use ARRAY_SIZE macro when appropriate
Hi,
A 2.6.20 patch to use ARRAY_SIZE macro already defined in kernel.h for some
miscellaneous network drivers with no specific maintaners.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
[PATCH 01/02] is compile tested.
[PATCH 02/02] isn't compile tested cause of missing hardware.
diff --git a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
index 4612f71..d48196c 100644
--- a/drivers/net/cs89x0.c
+++ b/drivers/net/cs89x0.c
@@ -806,7 +806,7 @@ cs89x0_probe1(struct net_device *dev, int ioaddr, int
modular)
i = cs8900_irq_map[0];
#else
/* Translate the IRQ using the IRQ mapping table. */
- if (i >=
sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0]))
+ if (i >= ARRAY_SIZE(cs8900_irq_map))
printk("\ncs89x0: invalid ISA interrupt number
%d\n", i);
else
i = cs8900_irq_map[i];
@@ -1248,11 +1248,11 @@ write_irq(struct net_device *dev, int chip_type, int
irq)
if (chip_type == CS8900) {
/* Search the mapping table for the corresponding IRQ pin. */
- for (i = 0; i !=
sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0]); i++)
+ for (i = 0; i != ARRAY_SIZE(cs8900_irq_map); i++)
if (cs8900_irq_map[i] == irq)
break;
/* Not found */
- if (i == sizeof(cs8900_irq_map)/sizeof(cs8900_irq_map[0]))
+ if (i == ARRAY_SIZE(cs8900_irq_map))
i = 3;
writereg(dev, PP_CS8900_ISAINT, i);
} else {
diff --git a/drivers/net/irda/actisys-sir.c b/drivers/net/irda/actisys-sir.c
index 9715ab5..84d7bb0 100644
--- a/drivers/net/irda/actisys-sir.c
+++ b/drivers/net/irda/actisys-sir.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
@@ -67,7 +68,7 @@ static int actisys_reset(struct sir_dev *);
/* Note : the 220L doesn't support 38400, but we will fix that below */
static unsigned baud_rates[] = { 9600, 19200, 57600, 115200, 38400 };
-#define MAX_SPEEDS (sizeof(baud_rates)/sizeof(baud_rates[0]))
+#define MAX_SPEEDS ARRAY_SIZE(baud_rates)
static struct dongle_driver act220l = {
.owner = THIS_MODULE,
diff --git a/drivers/net/lp486e.c b/drivers/net/lp486e.c
index 177c502..4b016aa 100644
--- a/drivers/net/lp486e.c
+++ b/drivers/net/lp486e.c
@@ -515,7 +515,7 @@ CLEAR_INT(void) {
outb(0, IOADDR+8);
}
-#define SIZE(x)(sizeof(x)/sizeof((x)[0]))
+#define SIZE(x)ARRAY_SIZE(x)
#if 0
/* selftest or dump */
diff --git a/drivers/net/ne.c b/drivers/net/ne.c
index a5c4199..7081d08 100644
--- a/drivers/net/ne.c
+++ b/drivers/net/ne.c
@@ -379,7 +379,7 @@ static int __init ne_probe1(struct net_device *dev, int
ioaddr)
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i < sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i < ARRAY_SIZE(program_seq); i++)
outb_p(program_seq[i].value, ioaddr +
program_seq[i].offset);
}
diff --git a/drivers/net/ne2.c b/drivers/net/ne2.c
index 089b5bb..c6c2a91 100644
--- a/drivers/net/ne2.c
+++ b/drivers/net/ne2.c
@@ -432,7 +432,7 @@ static int __init ne2_probe1(struct net_device *dev, int
slot)
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i < sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i < ARRAY_SIZE(program_seq); i++)
outb_p(program_seq[i].value, base_addr +
program_seq[i].offset);
diff --git a/drivers/net/ne2k-pci.c b/drivers/net/ne2k-pci.c
index 589785d..6bafdda 100644
--- a/drivers/net/ne2k-pci.c
+++ b/drivers/net/ne2k-pci.c
@@ -309,7 +309,7 @@ static int __devinit ne2k_pci_init_one (struct pci_dev
*pdev,
{0x00, EN0_RSARHI},
{E8390_RREAD+E8390_START, E8390_CMD},
};
- for (i = 0; i < sizeof(program_seq)/sizeof(program_seq[0]); i++)
+ for (i = 0; i < ARRAY_SIZE(program_seq); i++)
outb(program_seq[i].value, ioaddr +
program_seq[i].offset);
}
diff --git a/drivers/net/netxen/netxen_nic_hw.c
b/drivers/net/netxen/netxen_nic_hw.c
index f263232..7f93c08 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -395,7 +395,7 @@ int netxen_is_flash_supported(struct netxen_adapter
*adapter)
/* if the flash size less than 4Mb, make huge war cry and die */
for (j = 1; j < 4; j++) {
addr = j * NETXEN_NIC_WINDOW_MARGIN;
- for (i = 0; i < (sizeof(locs) / sizeof(locs[0])); i++) {
+ for (i = 0; i < ARRAY_SIZE(locs); i++) {
if (netxen_rom_fast_read(adapter, locs[i], &val
[PATCH 2.6.20] e1000: Use ARRAY_SIZE macro when appropriate
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]>
---
Patch is compile tested.
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index fb96c87..d21706e 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -746,7 +746,7 @@ err_setup:
uint32_t pat, value; \
uint32_t test[] = \
{0x5A5A5A5A, 0xA5A5A5A5, 0x, 0x}; \
- for (pat = 0; pat < sizeof(test)/sizeof(test[0]); pat++) {
\
+ for (pat = 0; pat < ARRAY_SIZE(test); pat++) { \
E1000_WRITE_REG(&adapter->hw, R, (test[pat] & W)); \
value = E1000_READ_REG(&adapter->hw, R); \
if (value != (test[pat] & W & M)) {
\
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00] A series of patches to use ARRAY_SIZE in `net' drivers
Hi all, Follows is a sereis of patches to use ARRAY_SIZE macro in drivers/net. Patches are sent separately according to their maintaners as replies to this thread. apne.c |2 +- arm/am79c961a.c|2 +- atarilance.c |2 +- cs89x0.c |6 +++--- e1000/e1000_ethtool.c |2 +- fec_8xx/fec_mii.c |4 ++-- ibm_emac/ibm_emac_debug.c |8 irda/actisys-sir.c |3 ++- ixgb/ixgb_param.c |2 +- lp486e.c |2 +- ne-h8300.c |2 +- ne.c |2 +- ne2.c |2 +- ne2k-pci.c |2 +- netxen/netxen_nic_hw.c |2 +- pcmcia/axnet_cs.c |2 +- pcmcia/pcnet_cs.c |2 +- sk98lin/skgemib.c |4 +++- sk98lin/skgesirq.c |3 ++- skfp/smt.c |3 ++- skfp/srf.c |6 -- wireless/airo.c|4 ++-- wireless/hostap/hostap.h |3 ++- wireless/ipw2100.c | 14 ++ wireless/prism54/oid_mgt.c |4 +++- wireless/wavelan.p.h |2 +- zorro8390.c|2 +- 27 files changed, 50 insertions(+), 42 deletions(-) Thanks, -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Vlad Yasevich wrote on 05 February 2007 16:39: > Once you start simulating the network failure, how long do you wait? > > If you have not changed rto_max and path_max_retrans, you can end up > waiting quite a while for the full path switchover. This will also > severely slow down your retransmissions... I'm waiting several minutes, and I'm using setsockopt() to set the timeouts fairly low: srto_initial = 1000ms srto_min = 200ms srto_max = 1400ms spp_pathmaxrxt = 2 spp_hbinterval = 1000ms The network's round trip time (indicated by ping) is on the order of <0.25ms. - Steve Hill Software Engineer Dialogic Fordingbridge, Hampshire, UK +44-1425-651392 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage
Steve Hill wrote: Vlad Yasevich wrote on 25 January 2007 16:33: Can you try the attached patch and let me know if the problem is fixed. You can try reducing rto_max or path_max_retrans to get the failover to happen a little faster. Sorry for the delay - I've been on vacation for the past week. I've tried applying the patch. However, the failure still seems to happen in the original test system with a patched kernel. A look at the network traffic shows that the receiving side is still returning a gap-ack, the chunks in the gap are never resent and I don't see a FORWARD TSN for them. Once you start simulating the network failure, how long do you wait? If you have not changed rto_max and path_max_retrans, you can end up waiting quite a while for the full path switchover. This will also severely slow down your retransmissions... Try reducing /proc/sys/net/sctp/rto_max to say 6000ms (6 seconds). It defaults to (6 ms or 1 minute). That reduction means that the retransmit timeout will max out at 6 seconds. The problem is that you will not see the FORWARD TSN on the alternate path until the original path is marked down. That requires us to exceed the path_max_retrans counter (/proc/sys/net/sctp/path_max_retrans). This means that you will see the gap grow until a time when the rto exceeds the data expiry time. At this pint, you will not see any new data sent, since it will expire before being sent. So, it will look to you like nothing is happening. The gap will be closed once the FWD-TSN is transmitted over the alternate transport. -vlad - Steve Hill Software Engineer Dialogic Fordingbridge, Hampshire, UK +44-1425-651392 [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Lksctp-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lksctp-developers - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: when having to acquire an SA, ipsec drops the packet
On Sun, 4 Feb 2007, David Miller wrote: > Something like this (untested) on the ipv4 side, for example: Looks like it should work. Will do some testing. -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
