* Re: Is 802.3ad mode in bonding useful ?
From: Jay Vosburgh @ 2011-04-29 17:01 UTC (permalink / raw)
To: Neil Horman; +Cc: WeipingPan, netdev
In-Reply-To: <20110429104342.GA22387@hmsreliant.think-freely.org>
Neil Horman <nhorman@tuxdriver.com> wrote:
>On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
>> On 04/28/2011 08:21 PM, Neil Horman wrote:
>> >On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
>> >>Hi, all,
>> >>
>> >>802.3ad mode in bonding implements 802.3ad standard.
>> >>
>> >>I am just wondering 802.3ad mode is useful,
>> >>since bonding has many modes like balance-rr, active-backup, etc.
>> >>
>> >Yes, of course its usefull. For switches which support 802.3ad, this mode
>> >allows for both peers to understand that the links in the bond are acting as an
>> >aggregate, which makes it easier to prevent things like inadvertently looped
>> >back frames, for which the other modes have to have all sorts of hacks to
>> >prevent.
>> What is looped back frames here ?
>In this case they are frames that get received by the bond, which the bond
>itself sent. In modes where more than one slave is active, and in which the
>switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
>bond can send a frame on one slave, which the switch may broadcast to all ports,
>causing the frame just sent by the bond to then get received on another slave.
Actually, the round-robin (balance-rr) and balance-xor modes
were originally meant to interoperate with a switch configured for
traditional Etherchannel (old versions of Sun Trunking, etc) the common
term in use now seems to be "static link aggregation" to distinguish it
from 802.3ad dynamic link aggregation. When the switch is set up that
way, there are no loopback problems, because the switch knows that all
of the ports are really one big aggregate, and it won't send broadcast
or multicast packets to more than one port of the aggregation, and knows
that a bcast/mcast originating from one of those ports should not loop
back to another port of the aggregation.
What Neil is talking about is running -rr or -xor against,
basically, a hub or unmanaged switch, in which the switch (a) doesn't
have any link aggregation capabilities, and (b) won't complain when it
sees the same MAC address coming in from multiple ports more or less
simultaneously. Managed switches (that have link aggregation
capabilities) will generally complain about "flapping" if they see the
same source MAC address arrive on multiple switch ports in a short
period of time.
The special hacks now in bond_handle_frame aren't really about
preventing loopbacks, but rather to suppress duplicates, particularly
for the short periods of time that a switch is flooding traffic to all
ports because its mac table is not up to date. This is an issue in,
e.g., active-backup mode, in which the switch has no special
configuration. This code has moved around a lot lately, so older
kernels will have a substantially different layout, although the logic
is still pretty much the same.
I don't recall that there's anything specifically to suppress
loopbacks for -rr or -xor mode, although there is transmit logic to keep
things like IGMP messages on the same slave all the time to keep the
switches happier.
>> I didn't see any special code to handle looped back frames in other
>> modes in bonding,
>> can you take an example ?
>>
>See bond_handle_frame.
The actual testing logic is in bond_should_deliver_exact_match.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: linux-next: Tree for April 29 (bpf_jit)
From: Randy Dunlap @ 2011-04-29 16:26 UTC (permalink / raw)
To: Stephen Rothwell, netdev; +Cc: linux-next, LKML
In-Reply-To: <20110429131940.4f4c938f.sfr@canb.auug.org.au>
On Fri, 29 Apr 2011 13:19:40 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20110428:
when CONFIG_MODULES is not enabled:
bpf_jit_comp.c:(.text+0x43cc2): undefined reference to `module_free'
(.text+0x4521a): undefined reference to `module_alloc'
(.text+0x453af): undefined reference to `module_free'
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jon Masters @ 2011-04-29 16:05 UTC (permalink / raw)
To: Michal Marek
Cc: Jan Beulich, David Miller, shemminger, bridge, jeffm, netdev,
Jon Masters
In-Reply-To: <4DBA9C23.2000408@suse.cz>
On Fri, 2011-04-29 at 13:08 +0200, Michal Marek wrote:
> On 29.4.2011 11:09, Jan Beulich wrote:
> >>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
> >> Nothing on the system should be hitting modules with unload requests
> >> unless the user explicitly asked for that specific module to be
> >> unloaded. At least not by default.
> >>
> >> So the me the problem is perhaps that "modprobe -r" does this auto
> >> dependency unloading thing by default.
> >>
> >> When we first fixed network device drivers so that they now properly
> >> always run with no module refcount at all, people complained because
> >> there were some distributions that ran some daemon that periodically
> >> looked for "unreferenced" modules and "helped" the user by
> >> automatically unloaded them.
> >>
> >> We killed that foolish daemon, and we can fix "modprobe -r" too.
> >
> > Michal - aren't you the modutils maintainer?
>
> That would be Jon (CC added).
Thanks. So the specific feature you mention was added precisely because
some folks wanted to clean up ununsed modules by removing all of their
dependencies. Since I've not been on this thread until now, can you let
me know what precisely you need, and why? We can make the unloading of
unused modules configurable, but it sounds like you're saying even that
isn't good enough. What actually happens, what's the bug experience?
I realize there isn't a general fondness of module removing, and I for
one don't really mind having a few extra modules loaded in my kernel.
Jon.
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jon Masters @ 2011-04-29 16:20 UTC (permalink / raw)
To: Jan Beulich
Cc: David Miller, Jon Masters, shemminger, bridge, jeffm,
Michal Marek, netdev
In-Reply-To: <4DBAFE45020000780003EEE6@vpn.id2.novell.com>
On Fri, 2011-04-29 at 17:07 +0100, Jan Beulich wrote:
> >>> On 29.04.11 at 18:05, Jon Masters <jonathan@jonmasters.org> wrote:
> > On Fri, 2011-04-29 at 13:08 +0200, Michal Marek wrote:
> >> On 29.4.2011 11:09, Jan Beulich wrote:
> >> >>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
> >
> >> >> Nothing on the system should be hitting modules with unload requests
> >> >> unless the user explicitly asked for that specific module to be
> >> >> unloaded. At least not by default.
> >> >>
> >> >> So the me the problem is perhaps that "modprobe -r" does this auto
> >> >> dependency unloading thing by default.
> >> >>
> >> >> When we first fixed network device drivers so that they now properly
> >> >> always run with no module refcount at all, people complained because
> >> >> there were some distributions that ran some daemon that periodically
> >> >> looked for "unreferenced" modules and "helped" the user by
> >> >> automatically unloaded them.
> >> >>
> >> >> We killed that foolish daemon, and we can fix "modprobe -r" too.
> >> >
> >> > Michal - aren't you the modutils maintainer?
> >>
> >> That would be Jon (CC added).
> >
> > Thanks. So the specific feature you mention was added precisely because
> > some folks wanted to clean up ununsed modules by removing all of their
> > dependencies. Since I've not been on this thread until now, can you let
> > me know what precisely you need, and why? We can make the unloading of
> > unused modules configurable, but it sounds like you're saying even that
> > isn't good enough. What actually happens, what's the bug experience?
>
> The problem observed was that unloading (via modprobe -r)
> ebtable_broute.ko, bridge.ko was also unloaded, causing all
> bridged networking to stop functioning on a machine.
Ah, right...ouch. That would be a "little" problem. Short of having an
exclusion list and all that nonsense, probably best to start with either
removing the unload logic or making it globally configurable. Thanks.
Jon.
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jan Beulich @ 2011-04-29 16:07 UTC (permalink / raw)
To: Jon Masters
Cc: David Miller, Jon Masters, shemminger, bridge, jeffm,
Michal Marek, netdev
In-Reply-To: <1304093116.11627.386.camel@constitution.bos.jonmasters.org>
>>> On 29.04.11 at 18:05, Jon Masters <jonathan@jonmasters.org> wrote:
> On Fri, 2011-04-29 at 13:08 +0200, Michal Marek wrote:
>> On 29.4.2011 11:09, Jan Beulich wrote:
>> >>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
>
>> >> Nothing on the system should be hitting modules with unload requests
>> >> unless the user explicitly asked for that specific module to be
>> >> unloaded. At least not by default.
>> >>
>> >> So the me the problem is perhaps that "modprobe -r" does this auto
>> >> dependency unloading thing by default.
>> >>
>> >> When we first fixed network device drivers so that they now properly
>> >> always run with no module refcount at all, people complained because
>> >> there were some distributions that ran some daemon that periodically
>> >> looked for "unreferenced" modules and "helped" the user by
>> >> automatically unloaded them.
>> >>
>> >> We killed that foolish daemon, and we can fix "modprobe -r" too.
>> >
>> > Michal - aren't you the modutils maintainer?
>>
>> That would be Jon (CC added).
>
> Thanks. So the specific feature you mention was added precisely because
> some folks wanted to clean up ununsed modules by removing all of their
> dependencies. Since I've not been on this thread until now, can you let
> me know what precisely you need, and why? We can make the unloading of
> unused modules configurable, but it sounds like you're saying even that
> isn't good enough. What actually happens, what's the bug experience?
The problem observed was that unloading (via modprobe -r)
ebtable_broute.ko, bridge.ko was also unloaded, causing all
bridged networking to stop functioning on a machine.
Jan
^ permalink raw reply
* Re: same application has different performance with kernel 2.6.32/34/36
From: Stephen Hemminger @ 2011-04-29 15:48 UTC (permalink / raw)
To: zhou rui; +Cc: netdev, jon.zhou
In-Reply-To: <BANLkTinF8Mfs+pqfGV0bLqm_3VyKCMn0LA@mail.gmail.com>
On Fri, 29 Apr 2011 22:46:04 +0800
zhou rui <zhourui.cn@gmail.com> wrote:
> hi
> my test application add a packet hook via dev_add_pack(&prot_hook);
> then copy the packet to a shared memory between userspace and kernel
>
> tests wereperformed at same machine(DL380 G7, 12cores, intel X520 10G
> nic),same traffic,same nic driver(ixgbe 3.3.9)
>
> kernel 2.6.32.12 (SUSE SLES11,SP1)
> APPlication cpu usage: 5-6%
>
>
> kernel updated to 2.6.34.7
> APPlication cpu usage: 19-25%
>
> kernel 2.6.36.4 (enable/disable RPS)
> APPlication cpu usage 35-40%
>
>
> before I installing profile tool to find the root cause, any idea about it?
> 'top' result is not accurate in older kernel? or any kernel
> module/feature impact this?
The report is appreciated, but since your application is not part of the main
kernel, developers are going to be unable to provide much direct help.
If it is closed source, go away we won't help with closed kernel components.
If it is open source, post a link where people can download it.
This is the kind of problem that requires effort and running multiple
times and using kernel bisection can show which change had the most impact.
It could be driver, scheduling or the change to packet steering.
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Stephen Hemminger @ 2011-04-29 15:34 UTC (permalink / raw)
To: David Miller; +Cc: JBeulich, bridge, jeffm, netdev
In-Reply-To: <20110429.002530.112581952.davem@davemloft.net>
On Fri, 29 Apr 2011 00:25:30 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: "Jan Beulich" <JBeulich@novell.com>
> Date: Fri, 29 Apr 2011 08:21:14 +0100
>
> > Otherwise 'modprobe -r' on a module having a dependency on bridge will
> > implicitly unload bridge, bringing down all connectivity that was using
> > bridges.
> >
> > Signed-off-by: Jan Beulich <jbeulich@novell.com>
> > Cc: Jeff Mahoney <jeffm@suse.com>
>
> All network device drivers behave exactly the same way, when you rmmod
> the thing we unconfigure all the routes, addresses, etc. going through
> that device and let you unload it.
>
> And this behavior is very much intentional.
>
> Don't add an exception here.
Agreed.
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: Rick Jones @ 2011-04-29 15:21 UTC (permalink / raw)
To: John Lumby; +Cc: Neil Horman, WeipingPan, netdev
In-Reply-To: <4DBAC552.507@hotmail.com>
> >> What is looped back frames here ?
> > In this case they are frames that get received by the bond, which the bond
> > itself sent. In modes where more than one slave is active, and in which the
> > switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
> > bond can send a frame on one slave, which the switch may broadcast to all ports,
>
>
> Isn't this (broadcasting or repeating on all ports other than incoming)
> more associated with simple hubs rather than switches? I would think
> any switch with layer 2 capability does not do that (does it?)
Perhaps when a frame is sent via the bond to a destination MAC not yet
learned by the switch?
Until a switch sees a MAC as a src, it does not know to which port the
frame(s) should be forwarded, so it must send the frame out all ports
but the ingress port.
rick jones
^ permalink raw reply
* same application has different performance with kernel 2.6.32/34/36
From: zhou rui @ 2011-04-29 14:46 UTC (permalink / raw)
To: netdev; +Cc: jon.zhou
hi
my test application add a packet hook via dev_add_pack(&prot_hook);
then copy the packet to a shared memory between userspace and kernel
tests wereperformed at same machine(DL380 G7, 12cores, intel X520 10G
nic),same traffic,same nic driver(ixgbe 3.3.9)
kernel 2.6.32.12 (SUSE SLES11,SP1)
APPlication cpu usage: 5-6%
kernel updated to 2.6.34.7
APPlication cpu usage: 19-25%
kernel 2.6.36.4 (enable/disable RPS)
APPlication cpu usage 35-40%
before I installing profile tool to find the root cause, any idea about it?
'top' result is not accurate in older kernel? or any kernel
module/feature impact this?
^ permalink raw reply
* Re: oops during unregister_netdevice interface enslaved to bond - regression
From: Einar EL Lueck @ 2011-04-29 14:45 UTC (permalink / raw)
To: opurdila, netdev, linux-s390, davem; +Cc: Frank Blaschka
Hi Octavian,
On 04/15/2011 10:53 AM, Frank Blaschka wrote:
> Hi Octavian,
>
> your commit 443457242beb6716b43db4d62fe148eab5515505 introduced this
regression.
> I have reviewed the net device unregister code but did not understand it
very well.
> I have seen the problem only in combination with bonding. Can you give me
some help
> how to go on with this problem. I can reproduced it very easy on a single
CPU
> machine.
>
In this case rollback_registered_many iterates over the list of devs that
initially has just one device in it. In a loop it calls
call_netdevice_notifiers(NETDEV_UNREGISTER, dev) which triggers the bonding
driver to call dev_close_many for the same device. That call to
dev_close_many leads to the addition of the same device to the list over
which rollback_registered_many is iterating. Consequently,
netdev_unregister_kobject(dev) is called twice for the same device. Frank
captured the result in his mail.
Do you agree with my debugging results?
Regards,
Einar.
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: John Lumby @ 2011-04-29 14:04 UTC (permalink / raw)
To: Neil Horman; +Cc: WeipingPan, netdev
In-Reply-To: <20110429104342.GA22387@hmsreliant.think-freely.org>
On 04/29/11 06:43, Neil Horman wrote:
> On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
>> On 04/28/2011 08:21 PM, Neil Horman wrote:
>>> On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
>>>> Hi, all,
>>>>
>>>> 802.3ad mode in bonding implements 802.3ad standard.
>>>>
>>>> I am just wondering 802.3ad mode is useful,
>>>> since bonding has many modes like balance-rr, active-backup, etc.
>>>>
>>> Yes, of course its usefull. For switches which support 802.3ad, this mode
>>> allows for both peers to understand that the links in the bond are acting as an
>>> aggregate, which makes it easier to prevent things like inadvertently looped
>>> back frames, for which the other modes have to have all sorts of hacks to
>>> prevent.
I believe another use for 802.3ad is to monitor the aggregation
"actively" (by sending special LACP packets) and to detect any kind of
failure of the other end of one of the slaves more rapidly (than if
relying on something like carrier detect). This may improve
availability, although that depends on the specific network topology
and capabilities in the switch(es). There is information on this in
Documentation/networking/bonding.txt.
>> What is looped back frames here ?
> In this case they are frames that get received by the bond, which the bond
> itself sent. In modes where more than one slave is active, and in which the
> switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
> bond can send a frame on one slave, which the switch may broadcast to all ports,
Isn't this (broadcasting or repeating on all ports other than incoming)
more associated with simple hubs rather than switches? I would think
any switch with layer 2 capability does not do that (does it?)
> causing the frame just sent by the bond to then get received on another slave.
>
>
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: WeipingPan @ 2011-04-29 13:59 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev
In-Reply-To: <20110429104342.GA22387@hmsreliant.think-freely.org>
On 04/29/2011 06:43 PM, Neil Horman wrote:
> On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
>> On 04/28/2011 08:21 PM, Neil Horman wrote:
>>> On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
>>>> Hi, all,
>>>>
>>>> 802.3ad mode in bonding implements 802.3ad standard.
>>>>
>>>> I am just wondering 802.3ad mode is useful,
>>>> since bonding has many modes like balance-rr, active-backup, etc.
>>>>
>>> Yes, of course its usefull. For switches which support 802.3ad, this mode
>>> allows for both peers to understand that the links in the bond are acting as an
>>> aggregate, which makes it easier to prevent things like inadvertently looped
>>> back frames, for which the other modes have to have all sorts of hacks to
>>> prevent.
>> What is looped back frames here ?
> In this case they are frames that get received by the bond, which the bond
> itself sent. In modes where more than one slave is active, and in which the
> switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
> bond can send a frame on one slave, which the switch may broadcast to all ports,
> causing the frame just sent by the bond to then get received on another slave.
>
>> I didn't see any special code to handle looped back frames in other
>> modes in bonding,
>> can you take an example ?
>>
> See bond_handle_frame.
>
> Neil
>
Oh, I got it.
Thanks for your clear explanation !
Weiping Pan
^ permalink raw reply
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: Jiri Pirko @ 2011-04-29 13:51 UTC (permalink / raw)
To: David Miller; +Cc: mirqus, netdev, xemul
In-Reply-To: <20110428.132724.48500963.davem@davemloft.net>
Thu, Apr 28, 2011 at 10:27:24PM CEST, davem@davemloft.net wrote:
>From: Michał Mirosław <mirqus@gmail.com>
>Date: Fri, 22 Apr 2011 11:49:40 +0200
>
>> W dniu 22 kwietnia 2011 11:43 użytkownik Michał Mirosław
>> <mirqus@gmail.com> napisał:
>>> 2011/1/24 Jiri Pirko <jpirko@redhat.com>:
>>>> The code is not needed because tb[IFLA_IFNAME] is already
>>>> processed in rtnl_newlink(). Remove this redundancy.
>>> Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
>>>
>>> Symptoms:
>>>
>>> icybox:~# ip link add type veth
>>> RTNETLINK answers: File exists
>>> icybox:~# ip link add type veth peer veth1
>>> icybox:~# ip addr
>>> [...]
>>> 56: D: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>> link/ether e6:57:58:52:03:50 brd ff:ff:ff:ff:ff:ff
>>> 57: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>> link/ether c2:c2:a2:d5:d5:3a brd ff:ff:ff:ff:ff:ff
>>
>> Hmm. I was too quick. Reverting it fixes only first problem - "ip link
>> add type veth" adds new veth pair now, but "ip link add type veth peer
>> veth1" gives the same result as above.
>
>Jiri please look into this regression.
Working on this. Will post patch soon.
Jirka
^ permalink raw reply
* [PATCH] usbnet: Transfer of maintainership
From: Oliver Neukum @ 2011-04-29 12:19 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
USB list
>From 8786db859938a1be111b5b3a86161d38da5ac8db Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Fri, 29 Apr 2011 14:15:53 +0200
Subject: [PATCH] usbnet: Transfer of maintainership
Somebody has to do it, however unfortunate be the cause.
Signed-off-by: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
---
MAINTAINERS | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2199ba1..16a5c5f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6556,7 +6556,7 @@ S: Maintained
F: drivers/usb/host/uhci*
USB "USBNET" DRIVER FRAMEWORK
-M: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
+M: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
L: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
W: http://www.linux-usb.org/usbnet
S: Maintained
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Michal Marek @ 2011-04-29 11:08 UTC (permalink / raw)
To: Jan Beulich; +Cc: David Miller, shemminger, bridge, jeffm, netdev, Jon Masters
In-Reply-To: <4DBA9C71020000780003EDBE@vpn.id2.novell.com>
On 29.4.2011 11:09, Jan Beulich wrote:
>>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
>> From: "Jan Beulich"<JBeulich@novell.com>
>> Date: Fri, 29 Apr 2011 09:31:27 +0100
>>
>>>>>> On 29.04.11 at 10:10, David Miller<davem@davemloft.net> wrote:
>>>> From: "Jan Beulich"<JBeulich@novell.com>
>>>> Date: Fri, 29 Apr 2011 08:41:10 +0100
>>>>
>>>>> You talk of rmmod on the very module, but the issue is about
>>>>> modprobe -r on a dependent module. I cannot believe you consider
>>>>> it correct that *implicit* unloading of bridge.ko should happen when
>>>>> bridges are configured.
>>>>
>>>> Which module in particular depends upon bridge and causes the
>>>> problem?
>>>
>>> The problem was observed (a long time ago) with ebtable_broute,
>>> and I cannot see how this would have changed meanwhile.
>>
>> Well your change makes it so that someone who actually _wants_ to
>> unload the bridge module, regardless of configuration, cannot do so.
>>
>> I think that's a worse problem than this ebtables thing.
>>
>> Nothing on the system should be hitting modules with unload requests
>> unless the user explicitly asked for that specific module to be
>> unloaded. At least not by default.
>>
>> So the me the problem is perhaps that "modprobe -r" does this auto
>> dependency unloading thing by default.
>>
>> When we first fixed network device drivers so that they now properly
>> always run with no module refcount at all, people complained because
>> there were some distributions that ran some daemon that periodically
>> looked for "unreferenced" modules and "helped" the user by
>> automatically unloaded them.
>>
>> We killed that foolish daemon, and we can fix "modprobe -r" too.
>
> Michal - aren't you the modutils maintainer?
That would be Jon (CC added).
> What are your thoughts
> here? (The original report we got is
> https://bugzilla.novell.com/show_bug.cgi?id=267651.)
I think that defaulting to not removing dependencies would be a good
idea. But do not expect that it will help with those artificial tests,
they will just proceed a few steps further until they hit the module
with broken unloading ;-).
Michal
>
>> Does "rmmod" have this behavior too? If not, and it does the right
>> thing by only unloaded what the user asked for, then people should
>> use that.
>
> No, it doesn't. Other than modprobe, rmmod deals only with the
> module specified.
>
>> I really don't in any way want to block people from being able to
>> cleanly unload the bridge module, regardless of configuration, if
>> that's what they want so your patch as written is not going to be
>> considered for inclusion.
>
> I understood that meanwhile, yet fail to see an alternative solution
> (imo this auto-unloading is quite desirable in other cases).
>
> Jan
>
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: Neil Horman @ 2011-04-29 10:43 UTC (permalink / raw)
To: WeipingPan; +Cc: netdev
In-Reply-To: <4DBA2DDC.80502@gmail.com>
On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
> On 04/28/2011 08:21 PM, Neil Horman wrote:
> >On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
> >>Hi, all,
> >>
> >>802.3ad mode in bonding implements 802.3ad standard.
> >>
> >>I am just wondering 802.3ad mode is useful,
> >>since bonding has many modes like balance-rr, active-backup, etc.
> >>
> >Yes, of course its usefull. For switches which support 802.3ad, this mode
> >allows for both peers to understand that the links in the bond are acting as an
> >aggregate, which makes it easier to prevent things like inadvertently looped
> >back frames, for which the other modes have to have all sorts of hacks to
> >prevent.
> What is looped back frames here ?
In this case they are frames that get received by the bond, which the bond
itself sent. In modes where more than one slave is active, and in which the
switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
bond can send a frame on one slave, which the switch may broadcast to all ports,
causing the frame just sent by the bond to then get received on another slave.
> I didn't see any special code to handle looped back frames in other
> modes in bonding,
> can you take an example ?
>
See bond_handle_frame.
Neil
> thanks
> Weiping Pan
>
> >Neil
> >
>
>
^ permalink raw reply
* Re: [PATCH] s390, net: convert into new cpumask api
From: Ursula Braun @ 2011-04-29 10:01 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: LKML, Martin Schwidefsky, Heiko Carstens, Ursula Braun,
David S. Miller, linux390, linux-s390, netdev
In-Reply-To: <20110429000104.3D5D.A69D9226@jp.fujitsu.com>
On Thu, 2011-04-28 at 23:59 +0900, KOSAKI Motohiro wrote:
> Adapt new api.
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Ursula Braun <ursula.braun@de.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux390@de.ibm.com
> Cc: linux-s390@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> net/iucv/iucv.c | 70 +++++++++++++++++++++++++++---------------------------
> 1 files changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/net/iucv/iucv.c b/net/iucv/iucv.c
> index 8f156bd..79f2caf 100644
> --- a/net/iucv/iucv.c
> +++ b/net/iucv/iucv.c
> @@ -128,8 +128,8 @@ struct iucv_irq_list {
> };
>
> static struct iucv_irq_data *iucv_irq_data[NR_CPUS];
> -static cpumask_t iucv_buffer_cpumask = CPU_MASK_NONE;
> -static cpumask_t iucv_irq_cpumask = CPU_MASK_NONE;
> +static cpumask_t iucv_buffer_cpumask = { CPU_BITS_NONE };
> +static cpumask_t iucv_irq_cpumask = { CPU_BITS_NONE };
...
Applied and merged to our tree.
Thanks!
^ permalink raw reply
* RE: [v2 PATCH 0/6] IPVS: init and cleanup.
From: Hans Schillström @ 2011-04-29 9:48 UTC (permalink / raw)
To: Simon Horman, Hans Schillstrom
Cc: ja@ssi.bg, ebiederm@xmission.com, lvs-devel@vger.kernel.org,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
In-Reply-To: <20110429064225.GA23958@verge.net.au>
>Subject: Re: [v2 PATCH 0/6] IPVS: init and cleanup.
>
>On Fri, Apr 29, 2011 at 08:25:28AM +0200, Hans Schillstrom wrote:
> This patch series handles exit from a network name space.
>
>Hi Hans,
>
>thanks for your work on this.
>I've looked over the patches and nothing catches my eye -
>thanks for fixing up the things that I commented on previously.
>
>I think that patches 1 and 2 should be targeted at 2.6.39,
>while the remainder look like 2.6.40 material. Does that
>sound reasonable to you?
I do prefer to keep them together,
but if you want it in that way it's OK for me.
We are doing a lot of tests right now with this patch set.
If we found any issues I'll let you know.
Regards
Hans
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jan Beulich @ 2011-04-29 9:09 UTC (permalink / raw)
To: David Miller, Michal Marek; +Cc: shemminger, bridge, jeffm, netdev
In-Reply-To: <20110429.014445.39196872.davem@davemloft.net>
>>> On 29.04.11 at 10:44, David Miller <davem@davemloft.net> wrote:
> From: "Jan Beulich" <JBeulich@novell.com>
> Date: Fri, 29 Apr 2011 09:31:27 +0100
>
>>>>> On 29.04.11 at 10:10, David Miller <davem@davemloft.net> wrote:
>>> From: "Jan Beulich" <JBeulich@novell.com>
>>> Date: Fri, 29 Apr 2011 08:41:10 +0100
>>>
>>>> You talk of rmmod on the very module, but the issue is about
>>>> modprobe -r on a dependent module. I cannot believe you consider
>>>> it correct that *implicit* unloading of bridge.ko should happen when
>>>> bridges are configured.
>>>
>>> Which module in particular depends upon bridge and causes the
>>> problem?
>>
>> The problem was observed (a long time ago) with ebtable_broute,
>> and I cannot see how this would have changed meanwhile.
>
> Well your change makes it so that someone who actually _wants_ to
> unload the bridge module, regardless of configuration, cannot do so.
>
> I think that's a worse problem than this ebtables thing.
>
> Nothing on the system should be hitting modules with unload requests
> unless the user explicitly asked for that specific module to be
> unloaded. At least not by default.
>
> So the me the problem is perhaps that "modprobe -r" does this auto
> dependency unloading thing by default.
>
> When we first fixed network device drivers so that they now properly
> always run with no module refcount at all, people complained because
> there were some distributions that ran some daemon that periodically
> looked for "unreferenced" modules and "helped" the user by
> automatically unloaded them.
>
> We killed that foolish daemon, and we can fix "modprobe -r" too.
Michal - aren't you the modutils maintainer? What are your thoughts
here? (The original report we got is
https://bugzilla.novell.com/show_bug.cgi?id=267651.)
> Does "rmmod" have this behavior too? If not, and it does the right
> thing by only unloaded what the user asked for, then people should
> use that.
No, it doesn't. Other than modprobe, rmmod deals only with the
module specified.
> I really don't in any way want to block people from being able to
> cleanly unload the bridge module, regardless of configuration, if
> that's what they want so your patch as written is not going to be
> considered for inclusion.
I understood that meanwhile, yet fail to see an alternative solution
(imo this auto-unloading is quite desirable in other cases).
Jan
^ permalink raw reply
* Re: Maximum no of bytes Ethernet can transfer at a time ??
From: Ajit @ 2011-04-29 8:53 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110428110634.GA4165@hmsreliant.think-freely.org>
Neil Horman <nhorman <at> tuxdriver.com> writes:
I forgot to mention one more thing,
In the sender code you need to edit the mac of the target machine.
you will find it at the start of the code.
Also take care of eth0 to eth1 in the receiver code as per the need.
Thank you.
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: David Miller @ 2011-04-29 8:44 UTC (permalink / raw)
To: JBeulich; +Cc: shemminger, bridge, jeffm, netdev
In-Reply-To: <4DBA937F020000780003ED96@vpn.id2.novell.com>
From: "Jan Beulich" <JBeulich@novell.com>
Date: Fri, 29 Apr 2011 09:31:27 +0100
>>>> On 29.04.11 at 10:10, David Miller <davem@davemloft.net> wrote:
>> From: "Jan Beulich" <JBeulich@novell.com>
>> Date: Fri, 29 Apr 2011 08:41:10 +0100
>>
>>> You talk of rmmod on the very module, but the issue is about
>>> modprobe -r on a dependent module. I cannot believe you consider
>>> it correct that *implicit* unloading of bridge.ko should happen when
>>> bridges are configured.
>>
>> Which module in particular depends upon bridge and causes the
>> problem?
>
> The problem was observed (a long time ago) with ebtable_broute,
> and I cannot see how this would have changed meanwhile.
Well your change makes it so that someone who actually _wants_ to
unload the bridge module, regardless of configuration, cannot do so.
I think that's a worse problem than this ebtables thing.
Nothing on the system should be hitting modules with unload requests
unless the user explicitly asked for that specific module to be
unloaded. At least not by default.
So the me the problem is perhaps that "modprobe -r" does this auto
dependency unloading thing by default.
When we first fixed network device drivers so that they now properly
always run with no module refcount at all, people complained because
there were some distributions that ran some daemon that periodically
looked for "unreferenced" modules and "helped" the user by
automatically unloaded them.
We killed that foolish daemon, and we can fix "modprobe -r" too.
Does "rmmod" have this behavior too? If not, and it does the right
thing by only unloaded what the user asked for, then people should
use that.
I really don't in any way want to block people from being able to
cleanly unload the bridge module, regardless of configuration, if
that's what they want so your patch as written is not going to be
considered for inclusion.
^ permalink raw reply
* Re: Maximum no of bytes Ethernet can transfer at a time ??
From: Ajit @ 2011-04-29 8:39 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110428110634.GA4165@hmsreliant.think-freely.org>
Neil Horman <nhorman <at> tuxdriver.com> writes:
> >
> Can you just post a link to the code?
> Neil
>
> > Thank you.
> >
> >
here are the links to the code..
sender code : http://pastebin.com/se17Xn96
The command line arguments are like ./pgm_name eth0 /root/abc
where abc is the file name.
receiver code : http://pastebin.com/AKiUWzwR
just run it.
In the receiver code I have assigned offset to buffer[15], it was just for
debugging purpose. Actually offset must have 16 bits of buffer[15] and
buffer[16], but for files of around 100kb-200kb it will easily work..no need to
modify.
Thank you.
^ permalink raw reply
* [PATCH] usbnet: runtime pm: fix out of memory
From: tom.leiming-Re5JQEeQqe8AvxtiuMwx3w @ 2011-04-29 8:37 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: Ming Lei
From: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This patch makes use of the EVENT_DEV_OPEN flag introduced recently to
fix one out of memory issue, which can be reproduced on omap3/4 based
pandaboard/beagle XM easily with steps below:
- enable runtime pm
echo auto > /sys/devices/platform/usbhs-omap.0/ehci-omap.0/usb1/1-1/1-1.1/power/control
- ifconfig eth0 up
- then out of memroy happened, see [1] for kernel message.
Follows my analysis:
- 'ifconfig eth0 up' brings eth0 out of suspend, and usbnet_resume
is called to schedule dev->bh, then rx urbs are submited to prepare for
recieving data;
- some usbnet devices will produce garbage rx packets flood if
info->reset is not called in usbnet_open.
- so there is no enough chances for usbnet_bh to handle and release
recieved skb buffers since many rx interrupts consumes cpu, so out of memory
for atomic allocation in rx_submit happened.
This patch fixes the issue by simply not allowing schedule of usbnet_bh until device
is opened.
[1], dmesg
[ 234.712005] smsc95xx 1-1.1:1.0: rpm_resume flags 0x4
[ 234.712066] usb 1-1.1: rpm_resume flags 0x0
[ 234.712066] usb 1-1: rpm_resume flags 0x0
[ 234.712097] usb usb1: rpm_resume flags 0x0
[ 234.712127] usb usb1: usb auto-resume
[ 234.712158] ehci-omap ehci-omap.0: resume root hub
[ 234.754028] hub 1-0:1.0: hub_resume
[ 234.754821] hub 1-0:1.0: port 1: status 0507 change 0000
[ 234.756011] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
[ 234.756042] hub 1-0:1.0: rpm_resume flags 0x4
[ 234.756072] usb usb1: rpm_resume flags 0x0
[ 234.756164] usb usb1: rpm_resume returns 1
[ 234.756195] hub 1-0:1.0: rpm_resume returns 0
[ 234.756195] hub 1-0:1.0: rpm_suspend flags 0x4
[ 234.756225] hub 1-0:1.0: rpm_suspend returns 0
[ 234.756256] usb usb1: rpm_resume returns 0
[ 234.757141] usb 1-1: usb auto-resume
[ 234.793151] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0 ACK POWER sig=se0 PE CONNECT
[ 234.816558] usb 1-1: finish resume
[ 234.817871] hub 1-1:1.0: hub_resume
[ 234.818420] hub 1-1:1.0: port 1: status 0507 change 0000
[ 234.820495] ehci-omap ehci-omap.0: reused qh eec50220 schedule
[ 234.820495] usb 1-1: link qh256-0001/eec50220 start 1 [1/0 us]
[ 234.820587] usb 1-1: rpm_resume returns 0
[ 234.820800] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0000
[ 234.820800] hub 1-1:1.0: rpm_resume flags 0x4
[ 234.820831] hub 1-1:1.0: rpm_resume returns 0
[ 234.820861] hub 1-1:1.0: rpm_suspend flags 0x4
[ 234.820861] hub 1-1:1.0: rpm_suspend returns 0
[ 234.821777] usb 1-1.1: usb auto-resume
[ 234.868591] hub 1-1:1.0: state 7 ports 5 chg 0000 evt 0002
[ 234.868591] hub 1-1:1.0: rpm_resume flags 0x4
[ 234.868621] hub 1-1:1.0: rpm_resume returns 0
[ 234.868652] hub 1-1:1.0: rpm_suspend flags 0x4
[ 234.868652] hub 1-1:1.0: rpm_suspend returns 0
[ 234.879486] usb 1-1.1: finish resume
[ 234.880279] usb 1-1.1: rpm_resume returns 0
[ 234.880310] smsc95xx 1-1.1:1.0: rpm_resume returns 0
[ 238.880187] ksoftirqd/0: page allocation failure. order:0, mode:0x20
[ 238.880218] Backtrace:
[ 238.880249] [<c01b9800>] (dump_backtrace+0x0/0xf8) from [<c065e1dc>] (dump_stack+0x18/0x1c)
[ 238.880249] r6:00000000 r5:00000000 r4:00000020 r3:00000002
[ 238.880310] [<c065e1c4>] (dump_stack+0x0/0x1c) from [<c026ece4>] (__alloc_pages_nodemask+0x620/0x724)
[ 238.880340] [<c026e6c4>] (__alloc_pages_nodemask+0x0/0x724) from [<c02986d4>] (kmem_getpages.clone.34+0x34/0xc8)
[ 238.880371] [<c02986a0>] (kmem_getpages.clone.34+0x0/0xc8) from [<c02988f8>] (cache_grow.clone.42+0x84/0x154)
[ 238.880371] r6:ef871aa4 r5:ef871a80 r4:ef81fd40 r3:00000020
[ 238.880401] [<c0298874>] (cache_grow.clone.42+0x0/0x154) from [<c0298b64>] (cache_alloc_refill+0x19c/0x1f0)
[ 238.880432] [<c02989c8>] (cache_alloc_refill+0x0/0x1f0) from [<c0299804>] (kmem_cache_alloc+0x90/0x190)
[ 238.880462] [<c0299774>] (kmem_cache_alloc+0x0/0x190) from [<c052e260>] (__alloc_skb+0x34/0xe8)
[ 238.880493] [<c052e22c>] (__alloc_skb+0x0/0xe8) from [<bf0509f4>] (rx_submit+0x2c/0x1d4 [usbnet])
[ 238.880523] [<bf0509c8>] (rx_submit+0x0/0x1d4 [usbnet]) from [<bf050d38>] (rx_complete+0x19c/0x1b0 [usbnet])
[ 238.880737] [<bf050b9c>] (rx_complete+0x0/0x1b0 [usbnet]) from [<bf006fd0>] (usb_hcd_giveback_urb+0xa8/0xf4 [usbcore])
[ 238.880737] r8:eeeced34 r7:eeecec00 r6:eeecec00 r5:00000000 r4:eec2dd20
[ 238.880767] r3:bf050b9c
[ 238.880859] [<bf006f28>] (usb_hcd_giveback_urb+0x0/0xf4 [usbcore]) from [<bf03c8f8>] (ehci_urb_done+0xb0/0xbc [ehci_hcd])
[ 238.880859] r6:00000000 r5:eec2dd20 r4:eeeced44 r3:eec2dd34
[ 238.880920] [<bf03c848>] (ehci_urb_done+0x0/0xbc [ehci_hcd]) from [<bf040204>] (qh_completions+0x308/0x3bc [ehci_hcd])
[ 238.880920] r7:00000000 r6:eeda21a0 r5:ffdfe3c0 r4:eeda21ac
[ 238.880981] [<bf03fefc>] (qh_completions+0x0/0x3bc [ehci_hcd]) from [<bf040ef8>] (scan_async+0xb0/0x16c [ehci_hcd])
[ 238.881011] [<bf040e48>] (scan_async+0x0/0x16c [ehci_hcd]) from [<bf040fec>] (ehci_work+0x38/0x90 [ehci_hcd])
[ 238.881042] [<bf040fb4>] (ehci_work+0x0/0x90 [ehci_hcd]) from [<bf042940>] (ehci_irq+0x300/0x34c [ehci_hcd])
[ 238.881072] r4:eeeced34 r3:00000001
[ 238.881134] [<bf042640>] (ehci_irq+0x0/0x34c [ehci_hcd]) from [<bf006828>] (usb_hcd_irq+0x40/0xac [usbcore])
[ 238.881195] [<bf0067e8>] (usb_hcd_irq+0x0/0xac [usbcore]) from [<c0239764>] (handle_irq_event_percpu+0xb8/0x240)
[ 238.881225] r6:eec504e0 r5:0000006d r4:eec504e0 r3:bf0067e8
[ 238.881256] [<c02396ac>] (handle_irq_event_percpu+0x0/0x240) from [<c0239930>] (handle_irq_event+0x44/0x64)
[ 238.881256] [<c02398ec>] (handle_irq_event+0x0/0x64) from [<c023bbd0>] (handle_level_irq+0xe0/0x114)
[ 238.881286] r6:0000006d r5:c080c14c r4:c080c100 r3:00020000
[ 238.881317] [<c023baf0>] (handle_level_irq+0x0/0x114) from [<c01ab090>] (asm_do_IRQ+0x90/0xd0)
[ 238.881317] r5:00000000 r4:0000006d
[ 238.881347] [<c01ab000>] (asm_do_IRQ+0x0/0xd0) from [<c06624d0>] (__irq_svc+0x50/0x134)
[ 238.881378] Exception stack(0xef837e20 to 0xef837e68)
[ 238.881378] 7e20: 00000001 00185610 016cc000 c00490c0 eb380000 ef800540 00000020 00004ae0
[ 238.881408] 7e40: 00000020 bf0509f4 60000013 ef837e9c ef837e40 ef837e68 c0226f0c c0298ca0
[ 238.881408] 7e60: 20000013 ffffffff
[ 238.881408] r5:fa240100 r4:ffffffff
[ 238.881439] [<c0298bb8>] (__kmalloc_track_caller+0x0/0x1d0) from [<c052e284>] (__alloc_skb+0x58/0xe8)
[ 238.881469] [<c052e22c>] (__alloc_skb+0x0/0xe8) from [<bf0509f4>] (rx_submit+0x2c/0x1d4 [usbnet])
[ 238.881500] [<bf0509c8>] (rx_submit+0x0/0x1d4 [usbnet]) from [<bf0513d8>] (usbnet_bh+0x1b4/0x250 [usbnet])
[ 238.881530] [<bf051224>] (usbnet_bh+0x0/0x250 [usbnet]) from [<c01f912c>] (tasklet_action+0xb0/0x1f8)
[ 238.881530] r6:00000000 r5:ef9757f0 r4:ef9757ec r3:bf051224
[ 238.881561] [<c01f907c>] (tasklet_action+0x0/0x1f8) from [<c01f97ac>] (__do_softirq+0x140/0x290)
[ 238.881561] r8:00000006 r7:00000101 r6:00000000 r5:c0806098 r4:00000001
[ 238.881591] r3:c01f907c
[ 238.881622] [<c01f966c>] (__do_softirq+0x0/0x290) from [<c01f99cc>] (run_ksoftirqd+0xd0/0x1f4)
[ 238.881622] [<c01f98fc>] (run_ksoftirqd+0x0/0x1f4) from [<c02113b0>] (kthread+0x90/0x98)
[ 238.881652] r7:00000013 r6:c01f98fc r5:00000000 r4:ef831efc
[ 238.881683] [<c0211320>] (kthread+0x0/0x98) from [<c01f62f4>] (do_exit+0x0/0x374)
[ 238.881713] r6:c01f62f4 r5:c0211320 r4:ef831efc
[ 238.881713] Mem-info:
[ 238.881744] Normal per-cpu:
[ 238.881744] CPU 0: hi: 186, btch: 31 usd: 38
[ 238.881744] CPU 1: hi: 186, btch: 31 usd: 169
[ 238.881774] HighMem per-cpu:
[ 238.881774] CPU 0: hi: 90, btch: 15 usd: 66
[ 238.881774] CPU 1: hi: 90, btch: 15 usd: 86
[ 238.881805] active_anon:544 inactive_anon:71 isolated_anon:0
[ 238.881805] active_file:926 inactive_file:2538 isolated_file:0
[ 238.881805] unevictable:0 dirty:10 writeback:0 unstable:0
[ 238.881805] free:57782 slab_reclaimable:864 slab_unreclaimable:186898
[ 238.881805] mapped:632 shmem:144 pagetables:50 bounce:0
[ 238.881835] Normal free:1328kB min:3532kB low:4412kB high:5296kB active_anon:0kB inactive_anon:0kB active_file:880kB inactive_file:848kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:780288kB mlocked:0kB dirty:36kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:3456kB slab_unreclaimable:747592kB kernel_stack:392kB pagetables:200kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 238.881866] lowmem_reserve[]: 0 1904 1904
[ 238.881896] HighMem free:229800kB min:236kB low:508kB high:784kB active_anon:2176kB inactive_anon:284kB active_file:2824kB inactive_file:9304kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:243712kB mlocked:0kB dirty:4kB writeback:0kB mapped:2528kB shmem:576kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 238.881927] lowmem_reserve[]: 0 0 0
[ 238.881958] Normal: 0*4kB 4*8kB 6*16kB 0*32kB 1*64kB 1*128kB 0*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 1344kB
[ 238.882019] HighMem: 6*4kB 2*8kB 4*16kB 4*32kB 1*64kB 1*128kB 0*256kB 2*512kB 3*1024kB 0*2048kB 55*4096kB = 229800kB
[ 238.882080] 3610 total pagecache pages
[ 238.882080] 0 pages in swap cache
[ 238.882080] Swap cache stats: add 0, delete 0, find 0/0
[ 238.882110] Free swap = 0kB
[ 238.882110] Total swap = 0kB
[ 238.933776] 262144 pages of RAM
[ 238.933776] 58240 free pages
[ 238.933776] 10503 reserved pages
[ 238.933776] 187773 slab pages
[ 238.933807] 2475 pages shared
[ 238.933807] 0 pages swap cached
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/usbnet.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 009bba3..9ab439d 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -645,6 +645,7 @@ int usbnet_stop (struct net_device *net)
struct driver_info *info = dev->driver_info;
int retval;
+ clear_bit(EVENT_DEV_OPEN, &dev->flags);
netif_stop_queue (net);
netif_info(dev, ifdown, dev->net,
@@ -1524,9 +1525,12 @@ int usbnet_resume (struct usb_interface *intf)
smp_mb();
clear_bit(EVENT_DEV_ASLEEP, &dev->flags);
spin_unlock_irq(&dev->txq.lock);
- if (!(dev->txq.qlen >= TX_QLEN(dev)))
- netif_start_queue(dev->net);
- tasklet_schedule (&dev->bh);
+
+ if (test_bit(EVENT_DEV_OPEN, &dev->flags)) {
+ if (!(dev->txq.qlen >= TX_QLEN(dev)))
+ netif_start_queue(dev->net);
+ tasklet_schedule (&dev->bh);
+ }
}
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jan Beulich @ 2011-04-29 8:31 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, bridge, jeffm, netdev
In-Reply-To: <20110429.011051.183061494.davem@davemloft.net>
>>> On 29.04.11 at 10:10, David Miller <davem@davemloft.net> wrote:
> From: "Jan Beulich" <JBeulich@novell.com>
> Date: Fri, 29 Apr 2011 08:41:10 +0100
>
>> You talk of rmmod on the very module, but the issue is about
>> modprobe -r on a dependent module. I cannot believe you consider
>> it correct that *implicit* unloading of bridge.ko should happen when
>> bridges are configured.
>
> Which module in particular depends upon bridge and causes the
> problem?
The problem was observed (a long time ago) with ebtable_broute,
and I cannot see how this would have changed meanwhile.
Jan
^ permalink raw reply
* Re: Re: [v2 PATCH 0/6] IPVS: init and cleanup.
From: Hans Schillstrom @ 2011-04-29 8:17 UTC (permalink / raw)
To: Julian Anastasov
Cc: horms, ebiederm, lvs-devel, netdev, netfilter-devel,
hans.schillstrom
Hello
>
>Hello,
>
>On Fri, 29 Apr 2011, Hans Schillstrom wrote:
>
>> This patch series handles exit from a network name space.
>>
>> REVISION
>>
>> This is version 3
>
> Great! Only one missing lock:
Ooops..
>
>Patch 3:
> Missing write_[un]lock_bh(&__ip_vs_svc_lock) in ip_vs_flush,
> now we use ip_vs_unlink_service_nolock.
>
>As you are going to create new version you can look also at these:
>
>Patch 5:
> Can you rename 'goto exit;' to 'goto cleanup;' or
> 'goto out;'
>
>Patch 6:
> Add at least one comma after 'enabled' here:
> netns(%d) enabled first service added
>
I'll send a new set.
Thanks
Hans
^ 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