* Re: Please pull 'upstream-davem' branch of wireless-2.6
From: David Miller @ 2008-01-09 7:36 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080108192914.GA3086-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 8 Jan 2008 14:29:14 -0500
> Here are a few more for 2.6.25. The are mostly clean-ups for the new
> PID rate control algorithm, and some A-MPDU bits related to supporting
> 802.11n.
Pulled and pushed back out to net-2.6.25, thanks John.
^ permalink raw reply
* Re: [XFRM]: xfrm_algo_clone() allocates too much memory
From: David Miller @ 2008-01-09 7:40 UTC (permalink / raw)
To: dada1; +Cc: herbert, netdev
In-Reply-To: <478477C7.9030004@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Wed, 09 Jan 2008 08:29:11 +0100
Thanks for catching this.
Applied to net-2.6
> +static inline int xfrm_alg_len(struct xfrm_algo *alg)
> +{
> + return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
> +}
That gets emitted as a divide doesn't it :-))))
^ permalink raw reply
* [NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
From: Eric Dumazet @ 2008-01-09 7:38 UTC (permalink / raw)
To: Herbert Xu, Paul E. McKenney; +Cc: davem, dipankar, netdev
In-Reply-To: <E1JCU1E-00076z-00@gondolin.me.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]
Herbert Xu a écrit :
> Eric Dumazet <dada1@cosmosbay.com> wrote:
>> Very good question, but honestly I really dont see why it was there at the
>> first place :
>
> It was there because someone went through this file and robotically
> replaced all conditional read barriers with rcu_dereference, even when
> it made zero sense.
>
> Basically you can add a conditional barrier either at the point where
> the pointer gets read, or where it gets derferenced. Previously we
> did the latter (except that the show function didn't have a barrier
> at all which is technically a bug though harmless in pratice). This
> patch moves it to the spot where it gets read which is also OK.
>
>> static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
>> {
>> - struct rt_cache_iter_state *st = rcu_dereference(seq->private);
>> + struct rt_cache_iter_state *st = seq->private;
>>
>> - r = r->u.dst.rt_next;
>> + r = rcu_dereference(r->u.dst.rt_next);
>> while (!r) {
>> rcu_read_unlock_bh();
>> if (--st->bucket < 0)
>> break;
>> rcu_read_lock_bh();
>> - r = rt_hash_table[st->bucket].chain;
>> + r = rcu_dereference(rt_hash_table[st->bucket].chain);
>> }
>> return r;
>
> Slight optimisation: please move both barriers onto the return statement,
> i.e.,
>
> return rcu_dereference(r);
I am not sure this is valid, since it will do this :
r = rt_hash_table[st->bucket].chain;
if (r)
return rcu_dereference(r);
So compiler might be dumb enough do dereference
&rt_hash_table[st->bucket].chain two times.
It seems Dipankar is busy at this moment, so I will post again the patch and
ask a comment from Paul :)
Thank you
[NET] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
In rt_cache_get_next(), no need to guard seq->private by a rcu_dereference()
since seq is private to the thread running this function. Reading seq.private
once (as guaranted bu rcu_dereference()) or several time if compiler really is
dumb enough wont change the result.
But we miss real spots where rcu_dereference() are needed, both in
rt_cache_get_first() and rt_cache_get_next()
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: route_rcu.patch --]
[-- Type: text/plain, Size: 1011 bytes --]
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d337706..3b7562f 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -278,7 +278,7 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
for (st->bucket = rt_hash_mask; st->bucket >= 0; --st->bucket) {
rcu_read_lock_bh();
- r = rt_hash_table[st->bucket].chain;
+ r = rcu_dereference(rt_hash_table[st->bucket].chain);
if (r)
break;
rcu_read_unlock_bh();
@@ -288,15 +288,15 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
static struct rtable *rt_cache_get_next(struct seq_file *seq, struct rtable *r)
{
- struct rt_cache_iter_state *st = rcu_dereference(seq->private);
+ struct rt_cache_iter_state *st = seq->private;
- r = r->u.dst.rt_next;
+ r = rcu_dereference(r->u.dst.rt_next);
while (!r) {
rcu_read_unlock_bh();
if (--st->bucket < 0)
break;
rcu_read_lock_bh();
- r = rt_hash_table[st->bucket].chain;
+ r = rcu_dereference(rt_hash_table[st->bucket].chain);
}
return r;
}
^ permalink raw reply related
* Re: [SOCK]: Adds a rcu_dereference() in sk_filter
From: David Miller @ 2008-01-09 7:41 UTC (permalink / raw)
To: herbert; +Cc: dada1, netdev, dim, kuznet
In-Reply-To: <E1JCUFO-00079j-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 09 Jan 2008 17:17:06 +1100
> Eric Dumazet <dada1@cosmosbay.com> wrote:
> >
> > It seems commit fda9ef5d679b07c9d9097aaf6ef7f069d794a8f9 introduced a RCU
> > protection for sk_filter(), without a rcu_dereference()
> >
> > Either we need a rcu_dereference(), either a comment should explain why we
> > dont need it. I vote for the former.
> >
> > Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [XFRM]: xfrm_algo_clone() allocates too much memory
From: Eric Dumazet @ 2008-01-09 7:51 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev
In-Reply-To: <20080108.234012.181072357.davem@davemloft.net>
David Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Wed, 09 Jan 2008 08:29:11 +0100
>
> Thanks for catching this.
>
> Applied to net-2.6
>
>> +static inline int xfrm_alg_len(struct xfrm_algo *alg)
>> +{
>> + return sizeof(*alg) + ((alg->alg_key_len + 7) / 8);
>> +}
>
> That gets emitted as a divide doesn't it :-))))
>
>
Yes I have a patch for these divides, but will apply on 2.6.25 once this one
hits it. (this saves 192 bytes of kernel text BTW)
^ permalink raw reply
* Re: [PATCH] [IPv6]: IPV6_MULTICAST_IF setting is ignored on link-local connect()
From: David Miller @ 2008-01-09 7:53 UTC (permalink / raw)
To: dlstevens; +Cc: brian.haley, netdev, netdev-owner, yoshfuji
In-Reply-To: <OF3393858D.9874E03A-ON882573CA.00071BC8-882573CA.000738ED@us.ibm.com>
From: David Stevens <dlstevens@us.ibm.com>
Date: Mon, 7 Jan 2008 17:18:56 -0800
> Acked-by: David L Stevens <dlstevens@us.ibm.com>
Patch applied, thanks everyone.
^ permalink raw reply
* Re: [XFRM]: xfrm_algo_clone() allocates too much memory
From: David Miller @ 2008-01-09 7:53 UTC (permalink / raw)
To: dada1; +Cc: herbert, netdev
In-Reply-To: <47847D0B.3050003@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Wed, 09 Jan 2008 08:51:39 +0100
> Yes I have a patch for these divides, but will apply on 2.6.25 once this one
> hits it. (this saves 192 bytes of kernel text BTW)
I never doubted you for a second.
^ permalink raw reply
* Re: [VLAN]: Avoid expensive divides
From: David Miller @ 2008-01-09 7:54 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <47835E74.4040900@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 08 Jan 2008 12:28:52 +0100
> We can avoid divides (as seen with CONFIG_CC_OPTIMIZE_FOR_SIZE=y on x86)
> changing vlan_group_get_device()/vlan_group_set_device() id parameter
> from signed to
> unsigned.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: SACK scoreboard
From: David Miller @ 2008-01-09 7:58 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: lachlan.andrew, netdev, quetchen
In-Reply-To: <Pine.LNX.4.64.0801081258050.12911@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 8 Jan 2008 14:12:47 +0200 (EET)
> If I'd hint my boss that I'm involved in something like this I'd
> bet that he also would get quite crazy... ;-) I'm partially paid
> for making TCP more RFCish :-), or at least that the places where
> thing diverge are known and controllable for research purposes.
RFCs are great guides by which to implement things, but they have been
often completely wrong or not practicle to follow strictly.
The handling of out of order ACKs with timestamps is my favorite
example. Nobody performs an RFC compliant timestamp check on ACK
packets, or else their performance would go into the toilet during
packet reordering.
The URG bit setting is another one.
Especially when, practically speaking, we can in fact make changes
like I believe we can here I think we should.
^ permalink raw reply
* Re: [PATCH 0/3] bonding: 3 fixes for 2.6.24
From: Jay Vosburgh @ 2008-01-09 7:58 UTC (permalink / raw)
To: Krzysztof Oledzki
Cc: netdev, Jeff Garzik, David Miller, Andy Gospodarek, Herbert Xu
In-Reply-To: <Pine.LNX.4.64.0801090732490.1135@bizon.gios.gov.pl>
Krzysztof Oledzki <olel@ans.pl> wrote:
>Fine. Just let you know that someone test your patches and everything
>works, except mentioned problem.
And I appreciate it; I just wanted to make sure our many fans
following along at home didn't misunderstand.
Could you let me know if the patch below make the lockdep
warning go away? This applies on top of the previous three, although it
should be trivial to do by hand.
I'm still checking to make sure this is safe with regard to
mutexing the bonding structures, but it would be good to know if it
eliminates the warning.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 77d004d..1baaadc 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3937,8 +3937,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
struct bonding *bond = bond_dev->priv;
struct dev_mc_list *dmi;
- write_lock_bh(&bond->lock);
-
/*
* Do promisc before checking multicast_mode
*/
@@ -3978,8 +3976,6 @@ static void bond_set_multicast_list(struct net_device *bond_dev)
/* save master's multicast list */
bond_mc_list_destroy(bond);
bond_mc_list_copy(bond_dev->mc_list, bond, GFP_ATOMIC);
-
- write_unlock_bh(&bond->lock);
}
/*
^ permalink raw reply related
* Re: [PATCH][VLAN] Merge tree equal tails in vlan_skb_recv
From: Pavel Emelyanov @ 2008-01-09 8:15 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List
In-Reply-To: <47591F9F.1020607@trash.net>
Hi, Patrick.
> Pavel Emelyanov wrote:
>> There are tree paths in it, that set the skb->proto and then
>> perform common receive manipulations (basically call netif_rx()).
>>
>> I think, that we can make this code flow easier to understand
>> by introducing the vlan_set_encap_proto() function (I hope the
>> name is good) to setup the skb proto and merge the paths calling
>> netif_rx() together.
>>
>> Surprisingly, but gcc detects this thing and merges these paths
>> by itself, so this patch doesn't make the vlan module smaller.
>
>
> I already have something similar queued, but your patch is a nice
> cleanup on top. I'll merge it into my tree and send it out after
> some testing, hopefully today.
>
What are your plans about this patch? Should I resubmit this one?
Thanks,
Pavel
^ permalink raw reply
* Re: [PATCH net-2.6.25] [IPV4] Remove unsupported DNAT (RTCF_NAT and RTCF_NAT) in IPV4
From: David Miller @ 2008-01-09 8:19 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801021331w63637142sd39b6605bd6f8be4@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Wed, 2 Jan 2008 23:31:37 +0200
> - The DNAT (Destination NAT) is not implemented in IPV4.
>
> - This patch remove the code which checks these flags
> in net/ipv4/arp.c and net/ipv4/route.c.
>
> The RTCF_NAT and RTCF_NAT should stay in the header (linux/in_route.h)
> because they are used in DECnet.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks Rami.
If someone has the stamina, it's very likely that the partial
NAT support in the decnet code can simply be removed. If
successful, then the in_route.h macros can be removed.
^ permalink raw reply
* Re: [patch 5/9][NETNS][IPV6] make bindv6only sysctl per namespace
From: David Miller @ 2008-01-09 8:25 UTC (permalink / raw)
To: dlezcano; +Cc: benjamin.thery, netdev, dada1
In-Reply-To: <47825513.50100@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Mon, 07 Jan 2008 17:36:35 +0100
> Thanks Benjamin to catch this.
>
> I think I have to apologize to Eric, I thought I tested with this option
> off but it wasn't and Eric was right. I will wait a little for feedbacks
> and send a V3.
I would have preferred if you just reposted a fixed version of patch 5
instead of waiting for the feedback that realistically isn't going to
come at all after this much time has passed.
I was about to apply this series, then looked through my mailbox for
reported regressions and hit this.
That makes me not start applying your patch series. I want the whole
thing with known bug fixes available by the time I get around to
reviewing it.
Thanks.
^ permalink raw reply
* Re: make ipv6_sysctl_register to return a value
From: David Miller @ 2008-01-09 8:26 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <47828DEB.9070301@fr.ibm.com>
Why did you post this again? It's identical to patch 1/9
from the previous series you sent out.
This is confusing, since it makes me think you wanted me to
perhaps do something different or update an already
submitted patch.
^ permalink raw reply
* Re: [PATCH net-2.6.25 1/6][NET] Simple ctl_table to ctl_path conversions.
From: David Miller @ 2008-01-09 8:30 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47839CD1.4080505@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 08 Jan 2008 18:54:57 +0300
> This patch includes many places, that only required
> replacing the ctl_table-s with appropriate ctl_paths
> and call register_sysctl_paths().
>
> Nothing special was done with them.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 2/6][IPVS] Switch to using ctl_paths.
From: David Miller @ 2008-01-09 8:30 UTC (permalink / raw)
To: horms; +Cc: xemul, netdev, devel
In-Reply-To: <20080109024914.GG3403@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Wed, 9 Jan 2008 11:49:16 +0900
> On Tue, Jan 08, 2008 at 06:58:11PM +0300, Pavel Emelyanov wrote:
> > The feature of ipvs ctls is that the net/ipv4/vs path
> > is common for core ipvs ctls and for two schedulers,
> > so I make it exported and re-use it in modules.
> >
> > Two other .c files required linux/sysctl.h to make the
> > extern declaration of this path compile well.
> >
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Thanks, this looks good to me and I've confirmed that
> the same entires with the same permissions exist under
> /proc/sys/net/ipv4/vs before and after the change.
>
> Acked-by: Simon Horman <horms@verge.net.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-2.6.25 3/6][DECNET] Switch to using ctl_paths.
From: David Miller @ 2008-01-09 8:31 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47839E88.2040604@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 08 Jan 2008 19:02:16 +0300
> The decnet includes two places to patch. The first one is
> the net/decnet table itself, and it is patched just like
> other subsystems in the first patch in this series.
>
> The second place is a bit more complex - it is the
> net/decnet/conf/xxx entries,. similar to those in
> ipv4/devinet.c and ipv6/addrconf.c. This code is made similar
> to those in ipv[46].
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 4/6][AX25] Switch to using ctl_paths.
From: David Miller @ 2008-01-09 8:32 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47839F3E.5080109@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Tue, 08 Jan 2008 19:05:18 +0300
> This one is almost the same as the hunks in the
> first patch, but ax25 tables are created dynamically.
>
> So this patch differs a bit to handle this case.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 5/6][NETFILTER] Switch to using ctl_paths in nf_queue and conntrack modules
From: David Miller @ 2008-01-09 8:33 UTC (permalink / raw)
To: kaber; +Cc: xemul, netdev, devel
In-Reply-To: <4783A092.1040605@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 08 Jan 2008 17:10:58 +0100
> Pavel Emelyanov wrote:
> > This includes the most simple cases for netfilter.
> >
> > The first part is tne queue modules for ipv4 and ipv6,
> > on which the net/ipv4/ and net/ipv6/ paths are reused
> > from the appropriate ipv4 and ipv6 code.
> >
> > The conntrack module is also patched, but this hunk is
> > very small and simple.
> >
> > Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Looks good to me.
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6.25 6/6][NETFILTER] Use the ctl paths instead of hand-made analogue
From: David Miller @ 2008-01-09 8:34 UTC (permalink / raw)
To: kaber; +Cc: xemul, netdev, devel
In-Reply-To: <4783A12A.3060207@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 08 Jan 2008 17:13:30 +0100
> Pavel Emelyanov wrote:
> > The conntracks subsystem has a similar infrastructure
> > to maintain ctl_paths, but since we already have it
> > on the generic level, I think it's OK to switch to
> > using it.
> >
> > So, basically, this patch just replaces the ctl_table-s
> > with ctl_path-s, nf_register_sysctl_table with
> > register_sysctl_paths() and removes no longer needed code.
>
> Also looks good, thanks.
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25] [BRIDGE] Remove unused macros from ebt_vlan.c
From: David Miller @ 2008-01-09 8:35 UTC (permalink / raw)
To: ramirose; +Cc: netdev
In-Reply-To: <eb3ff54b0801080638j48b51978j9beb11b310ef2b8@mail.gmail.com>
From: "Rami Rosen" <ramirose@gmail.com>
Date: Tue, 8 Jan 2008 16:38:15 +0200
> Remove two unused macros, INV_FLAG and SET_BITMASK
> from net/bridge/netfilter/ebt_vlan.c.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC 1/2] [XFRM] remove ifdef crypto
From: David Miller @ 2008-01-09 8:36 UTC (permalink / raw)
To: sebastian; +Cc: netdev
In-Reply-To: <E1JCLys-0000RU-2G@Chamillionaire.breakpoint.cc>
From: Sebastian Siewior <sebastian@breakpoint.cc>
Date: Sat, 8 Jan 2008 22:26:37 +0100
> and select the crypto subsystem if neccessary
>
> Signed-off-by: Sebastian Siewior <sebastian@breakpoint.cc>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/3] drivers/net/ipg.c: Fix skbuff leak
From: David Miller @ 2008-01-09 8:39 UTC (permalink / raw)
To: linux; +Cc: romieu, akpm, netdev
In-Reply-To: <20080109003840.22917.qmail@science.horizon.com>
From: linux@horizon.com
Date: 8 Jan 2008 19:38:40 -0500
> That doesn't seem to do it. Not entirely, at least. After downloading
> and partially re-uploading an 800M file, slabtop reports:
Ok, I'll let you and Francois work out how to fix this for
good.
Please submit just the outright leak bug fixes once this is
all resolved. All of that code cleanup stuff needs to wait
until later, let's fix bugs before adding new ones. :-)
Thanks.
^ permalink raw reply
* Re: 2.6.24-rc6-mm1
From: Jarek Poplawski @ 2008-01-09 9:04 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: mingo, akpm, just.for.lkml, tomof, herbert, linux-kernel, neilb,
bfields, netdev, tom
In-Reply-To: <20080109085753O.fujita.tomonori@lab.ntt.co.jp>
On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
...
> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> new file mode 100644
> index 0000000..495575a
> --- /dev/null
> +++ b/lib/iommu-helper.c
> @@ -0,0 +1,80 @@
> +/*
> + * IOMMU helper functions for the free area management
> + */
> +
> +#include <linux/module.h>
> +#include <linux/bitops.h>
> +
> +static unsigned long find_next_zero_area(unsigned long *map,
> + unsigned long size,
> + unsigned long start,
> + unsigned int nr,
> + unsigned long align_mask)
> +{
> + unsigned long index, end, i;
> +again:
> + index = find_next_zero_bit(map, size, start);
> +
> + /* Align allocation */
> + index = (index + align_mask) & ~align_mask;
> +
> + end = index + nr;
> + if (end >= size)
> + return -1;
This '>=' looks doubtful to me, e.g.:
map points to 0s only, size = 64, nr = 64,
we get: index = 0; end = 64;
and: return -1 ?!
Regards,
Jarek P.
^ permalink raw reply
* Bonding : Monitoring of 4965 wireless card
From: patnel972-linux @ 2008-01-09 9:00 UTC (permalink / raw)
To: netdev
Hi,
I want to make a bond with my wireless card. The ipw driver create two
interfaces (wlan0 and wmaster0). When i switch the rf_kill button,
ifplug detect wlan0 unplugged but not wmaster0. If i down wlan0 (while
rf_kil ), bonding detect the inactivity when i up the interface.
Have you some idea where is the problem? the driver or the miimon of
the module?
my module parameters mode=1 miimon=100 primary eth0
Thanks
_____________________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox