* Re: [PATCH] bnx2: cancel timer on device removal
From: David Miller @ 2011-04-29 19:33 UTC (permalink / raw)
To: mchan; +Cc: nhorman, netdev
In-Reply-To: <1304104851.12355.125.camel@nseg_linux_HP1.broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Fri, 29 Apr 2011 12:20:51 -0700
>
> On Tue, 2011-04-26 at 13:30 -0700, Neil Horman wrote:
>> Fix the problem by ensuring that the timer is stopped when
>> pci_device_unregister
>> is called.
>>
>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>> Reported-by: Hushan Jia <hjia@redhat.com>
>> CC: Michael Chan <mchan@broadcom.com>
>> CC: "David S. Miller" <davem@davemloft.net>
>
> Thanks Neil.
>
> Acked-by: Michael Chan <mchan@broadcom.com>
Applied, thanks everyone.
^ permalink raw reply
* RE: [RFC PATCH] netlink: Increase netlink dump skb message size
From: Rose, Gregory V @ 2011-04-29 19:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, bhutchings@solarflare.com
In-Reply-To: <20110429.122940.179938280.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, April 29, 2011 12:30 PM
> To: Rose, Gregory V
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com
> Subject: Re: [RFC PATCH] netlink: Increase netlink dump skb message size
>
> From: Greg Rose <gregory.v.rose@intel.com>
> Date: Mon, 25 Apr 2011 15:01:57 -0700
>
> > The message size allocated for rtnl info dumps was limited to a single
> page.
> > This is not enough for additional interface info available with devices
> > that support SR-IOV. Check that the amount of data allocated is
> sufficient
> > for the amount of data requested.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>
> Actually, thinking about this problem some more I think your approach
> is close to what we should actually do.
>
> The only problem is that you've specialized netlink_dump() too much,
> hide the issue in the rtnetlink device dumping code and provide
> the necessary information via the control block.
>
> 1) Add some information to struct netlink_callback.
>
> "u16 min_dump_alloc;"
>
> I think you can change "int family;" there to "u16 family;"
> so that there is no new space required to add this functionality.
>
> 2) In netlink_dump().
>
> int alloc_size;
>
> mutex_lock(nlk->cb_mutex);
> cb = nlk->cb;
> if (cb == NULL) {
> ...
> }
> alloc_size = max_t(int, cb->min_dump_alloc, NLMSG_GOODSIZE);
> skb = sock_rmalloc(sk, alloc_size, 0, GFP_KERNEL);
> if (!skb) {
> ...
>
> 3) In net/core/rtnetlink.c add a new method pointer to struct rtnl_link,
> "u16 (*calc_min_dump_alloc)(struct sk_buff *);"
> Add an implementation for the RTM_GETLINK slot.
>
> This function does the logic to compute the maximum space needed
> for the devices currently configured, as you hacked directly into
> the netlink_dump() logic in your match.
>
> 4) Make netlink_dump_start() take a new argument, this is where you
> pass the new min_dump_alloc value that will get stored in the
> newly allocated callback object.
>
> calcit = rtnl_get_calcit(family, type);
>
> min_dump_alloc = 0;
> if (calcit)
> min_dump_alloc = calcit(skb);
> err = netlink_dump_start(rtnl, skb, nlh, dumpit, min_dump_alloc,
> NULL);
>
> Anyways, something like that.
[Greg Rose]
I'll look into this and try to get a revised patch done by early next week.
The feedback and suggestions are much appreciated.
- Greg
^ permalink raw reply
* Re: [PATCH] usbnet: add support for some Huawei modems with cdc-ether ports
From: David Miller @ 2011-04-29 19:40 UTC (permalink / raw)
To: oneukum; +Cc: dcbw, netdev, linux-usb
In-Reply-To: <201104281046.47224.oneukum@suse.de>
From: Oliver Neukum <oneukum@suse.de>
Date: Thu, 28 Apr 2011 10:46:46 +0200
> Am Mittwoch, 27. April 2011, 21:54:28 schrieb Dan Williams:
>> Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether
>> compatible ports, so recognize and expose them.
>>
>> Signed-off-by: Dan Williams <dcbw@redhat.com>
>
> Acked-by: Oliver Neukum <oneukum@suse.de>
Applied.
^ permalink raw reply
* Re: [PATCH] usbnet: Transfer of maintainership
From: David Miller @ 2011-04-29 19:40 UTC (permalink / raw)
To: oneukum; +Cc: netdev, linux-usb
In-Reply-To: <201104291419.04498.oneukum@suse.de>
From: Oliver Neukum <oneukum@suse.de>
Date: Fri, 29 Apr 2011 14:19:04 +0200
> From 8786db859938a1be111b5b3a86161d38da5ac8db Mon Sep 17 00:00:00 2001
> From: Oliver Neukum <oliver@neukum.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@suse.de>
Applied, thanks Oliver.
^ permalink raw reply
* Re: [PATCH v2] net: ftmac100: fix scheduling while atomic during PHY link status change
From: David Miller @ 2011-04-29 19:42 UTC (permalink / raw)
To: adam.jaremko; +Cc: ratbert.chuang, ratbert, netdev, eric.dumazet
In-Reply-To: <1304012478.3715.5.camel@localhost.localdomain>
From: Adam Jaremko <adam.jaremko@gmail.com>
Date: Thu, 28 Apr 2011 13:41:18 -0400
> I think I've sorted my mail client preferences and all should be well now.
>
> Signed-off-by: Adam Jaremko <adam.jaremko@gmail.com>
> Acked-by: Po-Yu Chuang <ratbert@faraday-tech.com>
This is better, yes, applied.
^ permalink raw reply
* Destroying alive neighbour
From: Sergey Senozhatsky @ 2011-04-29 19:44 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
Hello,
.39-rc5-git2
Not sure whether I can reproduce this easily:
[ 845.225899] Destroying alive neighbour ffff88015736b400
[ 845.225910] Pid: 0, comm: kworker/0:1 Not tainted 2.6.39-rc5-dbg-git2-00495-g48c9216-dirty #543
[ 845.225917] Call Trace:
[ 845.225922] <IRQ> [<ffffffff813dee2f>] neigh_destroy+0x3c/0x115
[ 845.225950] [<ffffffff81400326>] ipv4_dst_check+0xae/0x158
[ 845.225963] [<ffffffff813c6f67>] __sk_dst_check+0xa5/0xd4
[ 845.225975] [<ffffffff8142e772>] inet_sk_rebuild_header+0x15/0x2b7
[ 845.225989] [<ffffffff8141c762>] ? tcp_write_timer+0x19/0x1a4
[ 845.225999] [<ffffffff8141ac3b>] tcp_retransmit_skb+0x8f/0x522
[ 845.226010] [<ffffffff81241579>] ? do_raw_spin_lock+0x6b/0x122
[ 845.226020] [<ffffffff8141c598>] tcp_retransmit_timer+0x4d5/0x686
[ 845.226030] [<ffffffff8141c7e7>] tcp_write_timer+0x9e/0x1a4
[ 845.226043] [<ffffffff8104c1f6>] run_timer_softirq+0x319/0x4f5
[ 845.226053] [<ffffffff8104c0c4>] ? run_timer_softirq+0x1e7/0x4f5
[ 845.226065] [<ffffffff8105fcf2>] ? __run_hrtimer+0x2ac/0x357
[ 845.226076] [<ffffffff8141c749>] ? tcp_retransmit_timer+0x686/0x686
[ 845.226091] [<ffffffff81044e73>] __do_softirq+0x170/0x301
[ 845.226104] [<ffffffff8106a257>] ? tick_dev_program_event+0x37/0xf6
[ 845.226115] [<ffffffff8106a330>] ? tick_program_event+0x1a/0x1c
[ 845.226127] [<ffffffff814791dc>] call_softirq+0x1c/0x30
[ 845.226140] [<ffffffff810031d7>] do_softirq+0x46/0x9f
[ 845.226151] [<ffffffff8104525a>] irq_exit+0x4e/0xa0
[ 845.226166] [<ffffffff8101954c>] smp_apic_timer_interrupt+0x87/0x95
[ 845.226212] [<ffffffff81478d13>] apic_timer_interrupt+0x13/0x20
[ 845.226216] <EOI> [<ffffffff8126d3b7>] ? intel_idle+0xe0/0x105
[ 845.226232] [<ffffffff8126d3b0>] ? intel_idle+0xd9/0x105
[ 845.226242] [<ffffffff813b93d4>] cpuidle_idle_call+0x157/0x288
[ 845.226250] [<ffffffff810007aa>] cpu_idle+0xa2/0xf3
[ 845.226259] [<ffffffff8146244b>] start_secondary+0x1ee/0x1f7
Sergey
[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipv4,ipv6,bonding: Restore control over number of peer notifications
From: David Miller @ 2011-04-29 19:44 UTC (permalink / raw)
To: bhutchings; +Cc: fubar, andy, kaber, netdev, brian.haley
In-Reply-To: <1303867552.2850.39.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Apr 2011 02:25:52 +0100
> For backward compatibility, we should retain the module parameters and
> sysfs attributes to control the number of peer notifications
> (gratuitous ARPs and unsolicited NAs) sent after bonding failover.
> Also, it is possible for failover to take place even though the new
> active slave does not have link up, and in that case the peer
> notification should be deferred until it does.
>
> Change ipv4 and ipv6 so they do not automatically send peer
> notifications on bonding failover.
>
> Change the bonding driver to send separate NETDEV_NOTIFY_PEERS
> notifications when the link is up, as many times as requested. Since
> it does not directly control which protocols send notifications, make
> num_grat_arp and num_unsol_na aliases for a single parameter. Bump
> the bonding version number and update its documentation.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv3 NEXT 0/2]qlcnic: updates
From: David Miller @ 2011-04-29 20:00 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1304027299-1960-1-git-send-email-amit.salecha@qlogic.com>
From: amit.salecha@qlogic.com
Date: Thu, 28 Apr 2011 14:48:17 -0700
> Hi,
> Please discard series 2 as sendmail fail to send mail to netdev list.
> This is v3 to remove any ambiguity.
Both applied, thanks.
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: Add multiqueue support
From: Anthony Liguori @ 2011-04-29 20:07 UTC (permalink / raw)
To: Jason Wang; +Cc: krkumar2, kvm, mst, netdev, rusty, qemu-devel
In-Reply-To: <20110420083318.32157.63955.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On 04/20/2011 03:33 AM, Jason Wang wrote:
> This patch adds the multiqueues support for emulated nics. Each VLANClientState
> pairs are now abstract as a queue instead of a nic, and multiple VLANClientState
> pointers were stored in the NICState and treated as the multiple queues of a
> single nic. The netdev options of qdev were now expanded to accept more than one
> netdev ids. A queue_index were also introduced to let the emulated nics know
> which queue the packet were came from or sent out. Virtio-net would be the first
> user.
>
> The legacy single queue nics can still run happily without modification as the
> the compatibility were kept.
>
> Signed-off-by: Jason Wang<jasowang@redhat.com>
> ---
> hw/qdev-properties.c | 37 ++++++++++++++++++++++++++++++-------
> hw/qdev.h | 3 ++-
> net.c | 34 ++++++++++++++++++++++++++--------
> net.h | 15 +++++++++++----
> 4 files changed, 69 insertions(+), 20 deletions(-)
>
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index 1088a26..dd371e1 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -384,14 +384,37 @@ PropertyInfo qdev_prop_chr = {
>
> static int parse_netdev(DeviceState *dev, Property *prop, const char *str)
> {
> - VLANClientState **ptr = qdev_get_prop_ptr(dev, prop);
> + VLANClientState ***nc = qdev_get_prop_ptr(dev, prop);
> + const char *ptr = str;
> + int i = 0;
> + size_t len = strlen(str);
> + *nc = qemu_malloc(MAX_QUEUE_NUM * sizeof(VLANClientState *));
> +
> + while (i< MAX_QUEUE_NUM&& ptr< str + len) {
> + char *name = NULL;
> + char *this = strchr(ptr, '#');
However this is being used is not going to be right. Is this taking
netdev=a#b#c#d?
I sort of agree with Michael about using multiple netdevs for this but I
don't yet understand how this gets sets up from userspace.
Can you give an example of usage that involves the full tap device setup?
Ideally, a user/management tool would never need to know about any of this.
In a perfect world, we could just dup() the tap fd a few times to create
multiple queues.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH 0/2] Multiqueue support for qemu(virtio-net)
From: Anthony Liguori @ 2011-04-29 20:10 UTC (permalink / raw)
To: Jason Wang; +Cc: Krishna Kumar2, kvm, mst, netdev, rusty, qemu-devel
In-Reply-To: <19887.42381.34145.956833@gargle.gargle.HOWL>
On 04/20/2011 10:33 PM, Jason Wang wrote:
> Krishna Kumar2 writes:
> > Thanks Jason!
> >
> > So I can use my virtio-net guest driver and test with this patch?
> > Please provide the script you use to start MQ guest.
> >
>
> Yes and thanks. Following is a simple script may help you start macvtap mq
> guest.
>
> qemu_path=./qemu-system-x86_64
> img_path=/home/kvm_autotest_root/images/mq.qcow2
> vtap_dev=/dev/tap104
> mac=96:88:12:1C:27:83
> smp=2
> mq=4
>
> for i in `seq $mq`
> do
> vtap+=" -netdev tap,id=hn$i,fd=$((i+100)) $((i+100))<>$vtap_dev"
So you are basically dup()'ing the tap device.
Does this actually improve performance at all?
Regards,
Anthony Liguori
> netdev+="hn$i#"
> done
>
> eval "$qemu_path $img_path $vtap -device virtio-net-pci,queues=$mq,netdev=$netdev,mac=$mac,vectors=32 -enable-kvm -smp $smp"
>
>
> > Regards,
> >
> > - KK
> >
> > Jason Wang<jasowang@redhat.com> wrote on 04/20/2011 02:03:07 PM:
> >
> > > Jason Wang<jasowang@redhat.com>
> > > 04/20/2011 02:03 PM
> > >
> > > To
> > >
> > > Krishna Kumar2/India/IBM@IBMIN, kvm@vger.kernel.org, mst@redhat.com,
> > > netdev@vger.kernel.org, rusty@rustcorp.com.au, qemu-
> > > devel@nongnu.org, anthony@codemonkey.ws
> > >
> > > cc
> > >
> > > Subject
> > >
> > > [RFC PATCH 0/2] Multiqueue support for qemu(virtio-net)
> > >
> > > Inspired by Krishna's patch
> > (http://www.spinics.net/lists/kvm/msg52098.html
> > > ) and
> > > Michael's suggestions. The following series adds the multiqueue support
> > for
> > > qemu and enable it for virtio-net (both userspace and vhost).
> > >
> > > The aim for this series is to simplified the management and achieve the
> > same
> > > performacne with less codes.
> > >
> > > Follows are the differences between this series and Krishna's:
> > >
> > > - Add the multiqueue support for qemu and also for userspace virtio-net
> > > - Instead of hacking the vhost module to manipulate kthreads, this patch
> > just
> > > implement the userspace based multiqueues and thus can re-use the
> > > existed vhost kernel-side codes without any modification.
> > > - Use 1:1 mapping between TX/RX pairs and vhost kthread because the
> > > implementation is based on usersapce.
> > > - The cli is also changed to make the mgmt easier, the -netdev option of
> > qdev
> > > can now accpet more than one ids. You can start a multiqueue virtio-net
> > device
> > > through:
> > > ./qemu-system-x86_64 -netdev tap,id=hn0,vhost=on,fd=X -netdev
> > > tap,id=hn0,vhost=on,fd=Y -device
> > virtio-net-pci,netdev=hn0#hn1,queues=2 ...
> > >
> > > The series is very primitive and still need polished.
> > >
> > > Suggestions are welcomed.
> > > ---
> > >
> > > Jason Wang (2):
> > > net: Add multiqueue support
> > > virtio-net: add multiqueue support
> > >
> > >
> > > hw/qdev-properties.c | 37 ++++-
> > > hw/qdev.h | 3
> > > hw/vhost.c | 26 ++-
> > > hw/vhost.h | 1
> > > hw/vhost_net.c | 7 +
> > > hw/vhost_net.h | 2
> > > hw/virtio-net.c | 409 +++++++++++++++++++++++++++++++
> > > +------------------
> > > hw/virtio-net.h | 2
> > > hw/virtio-pci.c | 1
> > > hw/virtio.h | 1
> > > net.c | 34 +++-
> > > net.h | 15 +-
> > > 12 files changed, 353 insertions(+), 185 deletions(-)
> > >
> > > --
> > > Jason Wang
> >
>
^ permalink raw reply
* Re: linux-next: manual merge of the suspend tree with the net tree
From: Rafael J. Wysocki @ 2011-04-29 20:36 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Eric Dumazet, David Miller, netdev
In-Reply-To: <20110429120541.c27998c2.sfr@canb.auug.org.au>
On Friday, April 29, 2011, Stephen Rothwell wrote:
> Hi Rafael,
>
> Today's linux-next merge of the suspend tree got a conflict in
> arch/x86/Kconfig between commit 0a14842f5a3c ("net: filter: Just In Time
> compiler for x86-64") from the tree and commit d9f1ce017fcf ("PM: Remove
> sysdev suspend, resume and shutdown operations") from the suspend tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Please do, thanks a lot!
Rafael
^ permalink raw reply
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: David Miller @ 2011-04-29 20:45 UTC (permalink / raw)
To: jgmyers; +Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <201104272312.p3RNCcl6002068@jgmyers-vm1.eng.proofpoint.com>
From: John Myers <jgmyers@proofpoint.com>
Date: Wed, 27 Apr 2011 16:12:38 -0700
> When the last ip address is deleted, the kernel disables IPv6 on the
> interface. (Not sure why, but that's beside the point.) The call that
> does this is over-aggressive--it indicates the interface is about to
> be removed even though that isn't necessarily so.
>
> This causes IPv6 to, among other things, unregister its sysctl
> parameters for the interface. Thus, the "accept_ra" and "addrconf"
> settings can't be set on the interface until after the interface has
> been brought back up, which is too late.
>
> Signed-off-by: John Gardiner Myers <jgmyers@proofpoint.com>
> Cc: stable@kernel.org
I'm not applying this, at least without some more discussion.
I can't see what you gain from this change.
First of all, when the machine boots up, you already have the problem
that you cannot set the accept_ra and addrconf sysctl settings before
the first ipv6 address is added to the interface.
So by definition you already cannot make the settings before it is
"too late" and the device is already engaging in ipv6 activity.
Giving you the capability to handle this across full ipv6 address
deletions on the device later on doesn't add anything, and at best it
gives people a false sense of security about being able to preserve
these settings across an ipv6 disable on the device.
If people are going to use this new behavior to do some trick like:
1) Let device come up and assign ipv6 addresses so that sysctls appear
2) Set ipv6 sysctls how actually desired
3) Delete all ipv6 addresses
4) Add them all back
Then I doubly do not want to set a precedent for this kind of usage
by applying this patch. Fix the real problem.
This behavior has been here, and intentionally so, since Alexey added
the "how" parameter to addrconf_ifdown() back in 1997.
Furthermore, there are other side effects to changing the 'how' parameter
to zero in this case and I haven't seen any analysis that those won't
cause any other undesirable side effects either.
So again, I'm not applying this patch, sorry.
^ permalink raw reply
* Re: [PATCH] net: fix rtnl even race in register_netdevice()
From: David Miller @ 2011-04-29 20:53 UTC (permalink / raw)
To: kvalo-BkwN83ws05HQT0dZR+AlfA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110429172634.27130.25375.stgit@x201>
From: Kalle Valo <kvalo-BkwN83ws05HQT0dZR+AlfA@public.gmane.org>
Date: Fri, 29 Apr 2011 20:26:34 +0300
> From: Kalle Valo <kalle.valo-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
>
> There's a race in register_netdevice so that the rtnl event is sent before
> the device is actually ready. This was visible with flimflam, chrome os
> connection manager:
>
> 00:21:35 roska flimflamd[2598]: src/udev.c:add_net_device()
> 00:21:35 roska flimflamd[2598]: connman_inet_ifname: SIOCGIFNAME(index
> 4): No such device
> 00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message() buf
> 0xbfefda3c len 1004
> 00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message()
> NEWLINK len 1004 type 16 flags 0x0000 seq 0
>
> So the kobject is visible in udev before the device is ready.
>
> (ignore the 10 s delay, I added that to reproduce the issue easily)
>
> The issue is reported here:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=15606
>
> The fix is to call netdev_register_kobject() after the device is added
> to the list.
>
> Signed-off-by: Kalle Valo <kalle.valo-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
This is not correct.
If you move the kobject registry around, you have to change the
error handling cleanup to match.
This change will leave the netdevice on all sorts of lists, it will
also leak a reference to the device.
I also think this points a fundamental problem with this change, in
that you can't register the kobject after the device is added to
the various lists in list_netdevice().
Once it's in those lists, any thread of control can find the device
and those threads of control may try to get at the data backed by
the kobject and therefore they really expect it to be there by
then.
What you can do instead is try to delay the NETREG_REGISTERED
setting, and block the problematic notifications by testing
reg_state or similar.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [PATCH rfc] atm/iphase : removal of PCI space dereferences.
From: David Miller @ 2011-04-29 20:54 UTC (permalink / raw)
To: romieu; +Cc: netdev, chas
In-Reply-To: <20110427203805.GI19708@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 27 Apr 2011 22:38:05 +0200
> Mostly PHY access and a few (ugly) debug statements for DMA control.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> ---
>
> Really RFCish. I ought to be able to give it some trivial crash testing.
I like this change, please give it some testing and submit formally.
Thanks!
^ permalink raw reply
* Re: [PATCH 2.6.38.4] mii: add support of pause frames in mii_get_an
From: David Miller @ 2011-04-29 20:57 UTC (permalink / raw)
To: artpol84; +Cc: linux-kernel, bhutchings, netdev
In-Reply-To: <1303962554.15395.1.camel@artpol-thinkpad>
From: artpol <artpol84@gmail.com>
Date: Thu, 28 Apr 2011 10:49:14 +0700
> Add support of pause frames advertise in mii_get_an. This provides all drivers
> that use mii_ethtool_gset to represent their own and Link partner flow control
> abilities in ethtool.
>
> Signed-off-by: Artem Polyakov <artpol84@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv3 0/7] ethtool: generalize use of ethtool_cmd_speed API
From: David Miller @ 2011-04-29 21:12 UTC (permalink / raw)
To: decot
Cc: sgruszka, grundler, e1000-devel, linux-kernel, eilong, mirq-linux,
netdev, bhutchings
In-Reply-To: <1303954043-17440-1-git-send-email-decot@google.com>
From: David Decotigny <decot@google.com>
Date: Wed, 27 Apr 2011 18:27:16 -0700
> Third version of the patch series ensuring ethtool_cmd::speed/_hi
> fields are accessed using ethtool_cmd_speed/_set API. Thanks to Ben
> and Stephen for their feedbacks that have been integrated here,
> including some from Ben suggested in PATCHv1 and added here (intel GbE
> drivers: last patch in the series).
Great work David, all applied to net-next-2.6
Thanks!
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: John Gardiner Myers @ 2011-04-29 21:58 UTC (permalink / raw)
To: David Miller
Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <20110429.134524.116375005.davem@davemloft.net>
On 4/29/2011 1:45 PM, David Miller wrote:
> First of all, when the machine boots up, you already have the problem
> that you cannot set the accept_ra and addrconf sysctl settings before
> the first ipv6 address is added to the interface.
What do you mean? I see no problem.
One does not need to set the accept_ra and addrconf sysctl settings
before the first ipv6 address is added to the interface, one needs to
set them before the interface is brought up. DAD (and thus router
solicitation) does not happen on down interfaces.
When the machine boots up and the interface is discovered, it starts in
the down state but with the sysctls registered. There is no problem
adjusting the settings before bringing the interface up.
> So by definition you already cannot make the settings before it is
> "too late" and the device is already engaging in ipv6 activity.
>
> Giving you the capability to handle this across full ipv6 address
> deletions on the device later on doesn't add anything, and at best it
> gives people a false sense of security about being able to preserve
> these settings across an ipv6 disable on the device.
>
> If people are going to use this new behavior to do some trick like:
>
> 1) Let device come up and assign ipv6 addresses so that sysctls appear
> 2) Set ipv6 sysctls how actually desired
> 3) Delete all ipv6 addresses
> 4) Add them all back
>
> Then I doubly do not want to set a precedent for this kind of usage
> by applying this patch. Fix the real problem.
This is all nonsense.
> This behavior has been here, and intentionally so, since Alexey added
> the "how" parameter to addrconf_ifdown() back in 1997.
The "how" parameter indicates the device is being deleted. In this case,
the device is not being deleted.
This does bring up the issue that the call to addrconf_ifdown() when the
MTU goes below IPV6_MIN_MTU probably also needs to be fixed.
Furthermore, there are other side effects to changing the 'how' parameter
> to zero in this case and I haven't seen any analysis that those won't
> cause any other undesirable side effects either.
If the device isn't going away, then the ip6_ptr shouldn't be zeroed,
the /proc/net/dev_snmp6 entry shouldn't be deregistered, the stateless
addrconf flags should be cleared, the regen timer shouldn't be deleted,
ipv6 multicast shouldn't mark the device down instead of being
destroyed, and the nd_parms shouldn't be freed.
^ permalink raw reply
* Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: David Woodhouse @ 2011-04-29 23:09 UTC (permalink / raw)
To: Philip Prindeville; +Cc: David Miller, bhutchings, netdev, linux-atm-general
In-Reply-To: <4D86FD63.1090405@redfish-solutions.com>
On Mon, 2011-03-21 at 00:25 -0700, Philip Prindeville wrote:
> On 3/20/11 11:04 PM, David Miller wrote:
> > From: Philip Prindeville<philipp_subx@redfish-solutions.com>
> > Date: Sun, 20 Mar 2011 22:56:43 -0700
> >
> >> It's not clear that dropping all VCs abruptly when carrier flapped was
> >> ever the right thing to do.
> > So you've tested your change with the older firmware present?
>
> I haven't, no: back-revving firmware has been known to brick cards.
>
> I'm waiting to hear back from Guy and Nathan, they have old cards on hand that they can test.
I have JTAG on one of mine and can test, but there's no real need in
this case. If you want to simulate the absence of the 'state changed'
notification, just *ignore* it when it does arrive.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: Alexey Kuznetsov @ 2011-04-30 0:07 UTC (permalink / raw)
To: John Gardiner Myers
Cc: David Miller, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <4DBB3480.9020708@proofpoint.com>
On Fri, Apr 29, 2011 at 02:58:24PM -0700, John Gardiner Myers wrote:
> If the device isn't going away, then the ip6_ptr shouldn't be zeroed,
> the /proc/net/dev_snmp6 entry shouldn't be deregistered,
Actually, you are right. Tuned interface parameters and disabling/enabling IPv6
(or IP, or whatever) should be different things. We just did not have an interface
to disable protocol, but leave in*_dev, so that they were merged.
When doing this just keep in mind that addrconf_ifdown(how = 0) did _not_ mean
disabling IPv6. (Probably, it does now in fact, I do not know. But it definitely
did not mean this in the past).
Look, addrconf_ifdown(how = 0) was executed only when the physical device is down, so that we could
neither receive nor send over this interface. If the device is UP, addrconf_ifdown(how = 0)
did not prohibit sending/receiving IPv6. Actually, logically, addrconf_ifdown(how = 0)
on UP interface must be followed by immediate restart of autoconfiguration,
because interface is still actually UP. See?
So, to implement this you should verify that IPv6 packets are not sent/received over
disabled interface (at least over interface with illegal mtu :-)). And add some flag in in6_dev
meaning that IPv6 is actually disabled. So that f.e. after occasional
ifconfig eth0 down; ifconfig eth0 up autoconfiguration would not resume IPv6
(the thing which we could not even implement with destroying in6_dev, but definitely wanted).
Alexey
^ permalink raw reply
* CONGRATULATIONS
From: mcrosft06 @ 2011-04-30 0:27 UTC (permalink / raw)
Dear Recipient,
We are pleased to inform you that you won the sum of 1,000,000.00 Euros on the
Microsoft Promo Commission.your e-mail address attached to:Ticket Number:03-02-1,
Reference Number:SL/07/4009,Please acknowledge the receipt of this mail to
Pastor Alan Jonathan With the details below:
EMAIL: mcrawrdprtmnt@aol.com
1.) Name...
2.) Address..
3.) Phone...
4.) Sex...
5.) Occupation....
6.) Age...
7.) Country Of Origin....
Sir Ivan Smith
Mircosoft © Promo Cordinator
^ permalink raw reply
* [PATCHv2 2/2] tg3: Add code to allow ethtool to enable/disable loopback.
From: Mahesh Bandewar @ 2011-04-30 1:03 UTC (permalink / raw)
To: David Miller, Matt Carlson
Cc: netdev, Michael Chan, Ben Hutchings, Michał Mirosław,
Mahesh Bandewar
In-Reply-To: <1304033599-8395-3-git-send-email-maheshb@google.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
Changes since v1:
Implemented Matt's suggestions.
(a) Enable this capability on the devices which are capable of MAC-loopback
mode.
(b) check if the device is running before making changes.
(c) check bits before making changes.
drivers/net/tg3.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index fa57e3d..f6e4c10 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6319,6 +6319,51 @@ static u32 tg3_fix_features(struct net_device *dev, u32 features)
return features;
}
+static int tg3_set_features(struct net_device *dev, u32 features)
+{
+ struct tg3 *tp = netdev_priv(dev);
+ u32 cur_mode = 0;
+ int err = 0;
+
+ if (!netif_running(dev)) {
+ err = -EAGAIN;
+ goto sfeatures_out;
+ }
+
+ spin_lock_bh(&tp->lock);
+ cur_mode = tr32(MAC_MODE);
+
+ if (features & NETIF_F_LOOPBACK) {
+ if (cur_mode & MAC_MODE_PORT_INT_LPBACK)
+ goto sfeatures_unlock;
+
+ /*
+ * Clear MAC_MODE_HALF_DUPLEX or you won't get packets back in
+ * loopback mode if Half-Duplex mode was negotiated earlier.
+ */
+ cur_mode &= ~MAC_MODE_HALF_DUPLEX;
+
+ /* Enable internal MAC loopback mode */
+ tw32(MAC_MODE, cur_mode | MAC_MODE_PORT_INT_LPBACK);
+ netif_carrier_on(tp->dev);
+ netdev_info(dev, "Internal MAC loopback mode enabled.\n");
+ } else {
+ if (!(cur_mode & MAC_MODE_PORT_INT_LPBACK))
+ goto sfeatures_unlock;
+
+ /* Disable internal MAC loopback mode */
+ tw32(MAC_MODE, cur_mode & ~MAC_MODE_PORT_INT_LPBACK);
+ /* Force link status check */
+ tg3_setup_phy(tp, 1);
+ netdev_info(dev, "Internal MAC loopback mode disabled.\n");
+ }
+sfeatures_unlock:
+ spin_unlock_bh(&tp->lock);
+
+sfeatures_out:
+ return err;
+}
+
static inline void tg3_set_mtu(struct net_device *dev, struct tg3 *tp,
int new_mtu)
{
@@ -15028,6 +15073,7 @@ static const struct net_device_ops tg3_netdev_ops = {
.ndo_tx_timeout = tg3_tx_timeout,
.ndo_change_mtu = tg3_change_mtu,
.ndo_fix_features = tg3_fix_features,
+ .ndo_set_features = tg3_set_features,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = tg3_poll_controller,
#endif
@@ -15044,6 +15090,7 @@ static const struct net_device_ops tg3_netdev_ops_dma_bug = {
.ndo_do_ioctl = tg3_ioctl,
.ndo_tx_timeout = tg3_tx_timeout,
.ndo_change_mtu = tg3_change_mtu,
+ .ndo_set_features = tg3_set_features,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = tg3_poll_controller,
#endif
@@ -15241,6 +15288,16 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
dev->features |= hw_features;
dev->vlan_features |= hw_features;
+ /*
+ * Add loopback capability only for a subset of devices that support
+ * MAC-LOOPBACK. Eventually this need to be enhanced to allow INT-PHY
+ * loopback for the remaining devices.
+ */
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5780 ||
+ !tg3_flag(tp, CPMU_PRESENT))
+ /* Add the loopback capability */
+ dev->hw_features |= NETIF_F_LOOPBACK;
+
if (tp->pci_chip_rev_id == CHIPREV_ID_5705_A1 &&
!tg3_flag(tp, TSO_CAPABLE) &&
!(tr32(TG3PCI_PCISTATE) & PCISTATE_BUS_SPEED_HIGH)) {
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] ipv6: fix incorrect unregistration of sysctl when last ip deleted
From: David Miller @ 2011-04-30 3:47 UTC (permalink / raw)
To: jgmyers; +Cc: kuznet, pekkas, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <4DBB3480.9020708@proofpoint.com>
From: John Gardiner Myers <jgmyers@proofpoint.com>
Date: Fri, 29 Apr 2011 14:58:24 -0700
> The "how" parameter indicates the device is being deleted. In this
> case, the device is not being deleted.
It means that ipv6 is being disabled on the device.
Which is what happens when one of the following happens:
1) the MTU is too small to support ipv6 properly
2) no configured ipv6 addresses remain on the device
3) the device is being unregistered
^ permalink raw reply
* WoL stopped working after power off with 2.6.38 (e1000e specific?)
From: Kamil Iskra @ 2011-04-30 5:45 UTC (permalink / raw)
To: netdev, e1000-devel
[ Note: I'm not on these mailing lists, so be sure to Cc: me if you want
more info from me ]
After upgrading from kernel 2.6.37 to 2.6.38, Wake on LAN after shutdown
stopped working for me on both of my Thinkpad laptops. Both systems use
the e1000e driver. One (a T61) has an 82566MM NIC, the other (an X201) an
82577LM. I'm running 64-bit Gentoo Linux with a custom compiled kernel.
The network driver is built into the kernel.
Wake on LAN still works after suspend (S3), but not after a complete
shutdown (with power supply connected).
I figured the updated e1000e driver in 2.6.38 was probably to blame,
however, after I copied the whole drivers/net/e1000e directory from the
2.6.37 over to the 2.6.38 tree and recompiled, the problem persisted, so I
don't know anymore.
I modified the system shutdown sequence to invoke ifconfig and ethtool
right before the final halt. According to ifconfig, eth0 is down at that
point. According to ethtool, WoL is configured correctly ("Wake-on: g").
There is, however, a difference in the output of ethtool between the two
kernel versions. "Link detected:" shows "yes" with 2.6.37, but "no" with
2.6.38.
A workaround that I found to work was to invoke "ifconfig eth0 up" right
before the halt.
Any suggestions? Is this new behavior expected or is it a bug?
Kamil
--
Kamil Iskra kamil@iskra.name
^ permalink raw reply
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: Jiri Pirko @ 2011-04-30 9:02 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, davem, xemul
In-Reply-To: <BANLkTi=x8xi7-g3SZdva7Ndg0a4EY1NK8g@mail.gmail.com>
Fri, Apr 22, 2011 at 11:43:10AM CEST, mirqus@gmail.com wrote:
>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.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
>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
interesting, on net-next I get following with or without this patch
applied:
[root@f14 ~]# ip link add type veth peer veth1
Error: either "dev" is duplicate, or "veth1" is a garbage.
Trying original F14 ip and currect git one gives the same
>
>Best Regards,
>Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: Jiri Pirko @ 2011-04-30 10:16 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, davem, xemul
In-Reply-To: <BANLkTikUAGWhNnCrebQpVttorqVxfD6KWw@mail.gmail.com>
Fri, Apr 22, 2011 at 11:49:40AM CEST, mirqus@gmail.com wrote:
>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.
I gusee you should do:
ip link add type veth peer name veth1
>
>Best Regards,
>Michał Mirosław
^ 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