* [PATCH net-next 0/2] sunvnet: Reduce LDC message overhead.
From: Sowmini Varadhan @ 2014-08-29 20:16 UTC (permalink / raw)
To: davem, sowmini.varadhan, raghuram.kothakota; +Cc: netdev
This patch series has 2 sets of changes to reduce the overhead
from LDC messages.
- the current linux sunvnet driver sends out many more LDC start and stop
triggers than it needs to: when we are sending a burst of packets across
multiple descriptor rings, we only need to send the "start" trigger for
the first dring (we currently send one for every dring). And we only need
to send the "STOPPED" trigger for the last dring (and if that fails, hold
off and send the trigger later).
- When reading the descriptor rings, don't give up as soon as a dring
that is not VIO_DESC_READY is found- especially when the peer is sending
a burst of packets, it is worthwhile to recheck the descriptor status
after a small microsecond delay, as the likelihood of finding this
descriptor READY is high, and it is cheaper to just retry with a delay
than to return from the current context, read another LDC message,
and then come back to read this descriptor.
Sowmini Varadhan (2):
Avoid sending superfluous LDC messages.
Re-check for a VIO_DESC_READY data descriptor after short udelay()
drivers/net/ethernet/sun/sunvnet.c | 87 ++++++++++++++++++++++++++++++++++----
drivers/net/ethernet/sun/sunvnet.h | 4 ++
2 files changed, 83 insertions(+), 8 deletions(-)
--
1.8.4.2
^ permalink raw reply
* Re: [PATCH net-next 5/5] sched: replace bare printks
From: Michael Heimpold @ 2014-08-29 20:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20140829071035.547171617@networkplumber.org>
Am Freitag, 29. August 2014, 00:09:23 schrieb Stephen Hemminger:
> Don't use bare printk for error messages.
> Make GRED error an info level message rather than debug which
> is likely to be suppressed.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
>
> --- a/net/sched/act_ipt.c 2014-03-28 11:40:43.000000000 -0700
> +++ b/net/sched/act_ipt.c 2014-08-22 16:53:33.676030680 -0700
> @@ -290,10 +290,10 @@ static int __init ipt_init_module(void)
>
> ret1 = tcf_register_action(&act_xt_ops, IPT_TAB_MASK);
> if (ret1 < 0)
> - printk("Failed to load xt action\n");
> + pr_err("Failed to load xt action\n");
> ret2 = tcf_register_action(&act_ipt_ops, IPT_TAB_MASK);
> if (ret2 < 0)
> - printk("Failed to load ipt action\n");
> + pr_err("Failed to load ipt action\n");
>
> if (ret1 < 0 && ret2 < 0) {
> return ret1;
> --- a/net/sched/act_mirred.c 2014-08-12 13:07:42.000000000 -0700
> +++ b/net/sched/act_mirred.c 2014-08-22 16:54:07.244031579 -0700
> @@ -140,7 +140,7 @@ static int tcf_mirred(struct sk_buff *sk
>
> dev = m->tcfm_dev;
> if (!dev) {
> - printk_once(KERN_NOTICE "tc mirred: target device is gone\n");
> + netdev_notice(dev, "tc mirred: target device is gone\n");
> goto out;
> }
At my first look, I was wondering whether this could work as 'dev' is not
a valid pointer inside the if statement body. But after trying to trace to call
down, I found that it ends up as
printk("%s(NULL net_device): %pV" ...
within __netdev_printk.
Is this the desired output in this case?
Or did I miss anything?
>
> --- a/net/sched/sch_gred.c 2014-03-28 11:40:43.000000000 -0700
> +++ b/net/sched/sch_gred.c 2014-08-22 16:54:47.720032663 -0700
> @@ -456,8 +456,8 @@ static int gred_change(struct Qdisc *sch
> if (table->tab[table->def])
> def_prio = table->tab[table->def]->prio;
>
> - printk(KERN_DEBUG "GRED: DP %u does not have a prio "
> - "setting default to %d\n", ctl->DP, def_prio);
> + pr_info("GRED: DP %u does not have a prio "
> + "setting default to %d\n", ctl->DP, def_prio);
>
> prio = def_prio;
> } else
>
Best regards,
Michael
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Sabrina Dubroca @ 2014-08-29 19:53 UTC (permalink / raw)
To: Cong Wang
Cc: Tommi Rantala, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Hannes Frederic Sowa, netdev,
LKML, trinity, Dave Jones
In-Reply-To: <CAHA+R7MZCDGRhSf=UuVCGQvNo03wVziZQB_X30rwNf6hmHipQA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]
2014-08-29, 11:14:48 -0700, Cong Wang wrote:
> On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala <tt.rantala@gmail.com> wrote:
> > [ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
> > [ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+ #30
> > [ 77.299039] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > [ 77.299789] ffff88003d76a618 ffff880026133c50 ffffffff8238ba79
> > ffff880037c84520
> > [ 77.300829] ffff880026133c90 ffffffff820bd52b 0000000000000000
> > ffffffff82d86c40
> > [ 77.301869] 0000000000000000 00000000f76fd1e1 ffff8800382d8000
> > ffff8800382d8220
> > [ 77.302906] Call Trace:
> > [ 77.303246] [<ffffffff8238ba79>] dump_stack+0x4d/0x66
> > [ 77.303928] [<ffffffff820bd52b>] addrconf_join_solict+0x4b/0xb0
> > [ 77.304731] [<ffffffff820b031b>] ipv6_dev_ac_inc+0x2bb/0x330
> > [ 77.305498] [<ffffffff820b0060>] ? ac6_seq_start+0x260/0x260
> > [ 77.306257] [<ffffffff820b05fe>] ipv6_sock_ac_join+0x26e/0x360
> > [ 77.307046] [<ffffffff820b0429>] ? ipv6_sock_ac_join+0x99/0x360
> > [ 77.307798] [<ffffffff820cdd60>] do_ipv6_setsockopt.isra.5+0xa70/0xf20
>
>
> I think we should just use rtnl_lock() instead of rcu_read_lock() there,
> it is not a hot path worth optimization.
>
> Please try the attached patch.
note: it doesn't build as it is now, it needs:
-EXPORT_SYMBOL(dev_get_by_flags_rcu);
+EXPORT_SYMBOL(dev_get_by_flags);
I just tried your patch with a basic test program (open
socket/join/leave/close and open socket/join/close).
I think you need to modify ipv6_sock_ac_close as well, or you can still
trigger the assertion when closing the socket without leaving first.
Modified patch attached.
--
Sabrina
[-- Attachment #2: ipv6-anycast_v2.diff --]
[-- Type: text/plain, Size: 4333 bytes --]
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 429801370d0c..1ae0e745b1b1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2077,8 +2077,8 @@ void __dev_remove_pack(struct packet_type *pt);
void dev_add_offload(struct packet_offload *po);
void dev_remove_offload(struct packet_offload *po);
-struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short flags,
- unsigned short mask);
+struct net_device *dev_get_by_flags(struct net *net, unsigned short flags,
+ unsigned short mask);
struct net_device *dev_get_by_name(struct net *net, const char *name);
struct net_device *dev_get_by_name_rcu(struct net *net, const char *name);
struct net_device *__dev_get_by_name(struct net *net, const char *name);
diff --git a/net/core/dev.c b/net/core/dev.c
index 443b814db05b..8fede6ef4a39 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -897,23 +897,24 @@ struct net_device *dev_getfirstbyhwtype(struct net *net, unsigned short type)
EXPORT_SYMBOL(dev_getfirstbyhwtype);
/**
- * dev_get_by_flags_rcu - find any device with given flags
+ * dev_get_by_flags - find any device with given flags
* @net: the applicable net namespace
* @if_flags: IFF_* values
* @mask: bitmask of bits in if_flags to check
*
* Search for any interface with the given flags. Returns NULL if a device
* is not found or a pointer to the device. Must be called inside
- * rcu_read_lock(), and result refcount is unchanged.
+ * rtnl_lock(), and result refcount is unchanged.
*/
-struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short if_flags,
+struct net_device *dev_get_by_flags(struct net *net, unsigned short if_flags,
unsigned short mask)
{
struct net_device *dev, *ret;
+ ASSERT_RTNL();
ret = NULL;
- for_each_netdev_rcu(net, dev) {
+ for_each_netdev(net, dev) {
if (((dev->flags ^ if_flags) & mask) == 0) {
ret = dev;
break;
@@ -921,7 +922,7 @@ struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short if_flags
}
return ret;
}
-EXPORT_SYMBOL(dev_get_by_flags_rcu);
+EXPORT_SYMBOL(dev_get_by_flags);
/**
* dev_valid_name - check if name is okay for network device
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 210183244689..6de5caa26ea4 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -77,7 +77,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
pac->acl_next = NULL;
pac->acl_addr = *addr;
- rcu_read_lock();
+ rtnl_lock();
if (ifindex == 0) {
struct rt6_info *rt;
@@ -90,11 +90,11 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
goto error;
} else {
/* router, no matching interface: just pick one */
- dev = dev_get_by_flags_rcu(net, IFF_UP,
+ dev = dev_get_by_flags(net, IFF_UP,
IFF_UP | IFF_LOOPBACK);
}
} else
- dev = dev_get_by_index_rcu(net, ifindex);
+ dev = __dev_get_by_index(net, ifindex);
if (dev == NULL) {
err = -ENODEV;
@@ -136,7 +136,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
}
error:
- rcu_read_unlock();
+ rtnl_unlock();
if (pac)
sock_kfree_s(sk, pac, sizeof(*pac));
return err;
@@ -171,13 +171,15 @@ int ipv6_sock_ac_drop(struct sock *sk, int ifindex, const struct in6_addr *addr)
spin_unlock_bh(&ipv6_sk_ac_lock);
- rcu_read_lock();
- dev = dev_get_by_index_rcu(net, pac->acl_ifindex);
+ rtnl_lock();
+ dev = __dev_get_by_index(net, pac->acl_ifindex);
if (dev)
ipv6_dev_ac_dec(dev, &pac->acl_addr);
- rcu_read_unlock();
+ rtnl_unlock();
sock_kfree_s(sk, pac, sizeof(*pac));
+ if (!dev)
+ return -ENODEV;
return 0;
}
@@ -198,12 +200,12 @@ void ipv6_sock_ac_close(struct sock *sk)
spin_unlock_bh(&ipv6_sk_ac_lock);
prev_index = 0;
- rcu_read_lock();
+ rtnl_lock();
while (pac) {
struct ipv6_ac_socklist *next = pac->acl_next;
if (pac->acl_ifindex != prev_index) {
- dev = dev_get_by_index_rcu(net, pac->acl_ifindex);
+ dev = __dev_get_by_index(net, pac->acl_ifindex);
prev_index = pac->acl_ifindex;
}
if (dev)
@@ -211,7 +213,7 @@ void ipv6_sock_ac_close(struct sock *sk)
sock_kfree_s(sk, pac, sizeof(*pac));
pac = next;
}
- rcu_read_unlock();
+ rtnl_unlock();
}
static void aca_put(struct ifacaddr6 *ac)
^ permalink raw reply related
* Re: [hyperv] BUG: unable to handle kernel paging request at ffff8801f5bc7cbb (netvsc_select_queue)
From: Sitsofe Wheeler @ 2014-08-29 19:49 UTC (permalink / raw)
To: KY Srinivasan
Cc: Greg Kroah-Hartman, Haiyang Zhang, linux-kernel@vger.kernel.org,
Daniel Borkmann, netdev@vger.kernel.org,
devel@linuxdriverproject.org, David Miller
In-Reply-To: <9b92bf4b20ea4fe7a6be0072e738da3c@BY2PR0301MB0711.namprd03.prod.outlook.com>
On Fri, Aug 29, 2014 at 05:18:51PM +0000, KY Srinivasan wrote:
>
> > -----Original Message-----
> > From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> > Sent: Friday, August 29, 2014 2:32 AM
> > To: Dexuan Cui
> > Cc: KY Srinivasan; Greg Kroah-Hartman; Haiyang Zhang;
> > devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> > netdev@vger.kernel.org; David Miller; Daniel Borkmann
> > Subject: [hyperv] BUG: unable to handle kernel paging request at
> > ffff8801f5bc7cbb (netvsc_select_queue)
> >
> > While booting a 10 vcpu system with a post v3.17-rc2 kernel with the
> > "Drivers: hv: vmbus: Eliminate calls to BUG_ON()", "Drivers: hv: vmbus:
> > Miscellaneous cleanup" patches and debugging/verification config options on
> > I'm seeing the following:
>
> Could you please try the following patch:
>
> >From c8a6a5570f9a7f8b9a2b47f165848e5533091e79 Mon Sep 17 00:00:00 2001
> From: K. Y. Srinivasan <kys@microsoft.com>
> Date: Fri, 29 Aug 2014 11:18:18 -0700
> Subject: [PATCH 1/1] Drivers: net: hyperv: Cleanup netvsc_change_mtu ()
With this issue I'm just booting but one interface has been configured
to have an MTU of 9000. The guest has three interfaces - one for each of
the two real network cards and one private interface.
Here's what I see with your previous patches and the patch from your
email:
[ 28.340343] psmouse serio1: trackpoint: IBM TrackPoint firmware: 0x01, buttons: 0/0
[ 28.393371] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/input/input4
[ 29.511276] EXT4-fs (sda1): re-mounted. Opts: (null)
[ 29.555201] systemd-udevd[362]: starting version 208
[ 30.498472] md: bind<sdc>
[ 30.563501] md: personality for level -1 is not loaded!
[ 30.673633] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[ 30.915000] systemd-journald[366]: Received request to flush runtime journal from PID 1
[ 32.050485] hv_utils: KVP: user-mode registering done.
[ 33.574365] BUG: unable to handle kernel paging request at ffff8801f39ba503
[ 33.574588] IP: [<ffffffff814e701d>] netvsc_select_queue+0x3d/0x150
[ 33.574588] PGD 2db0067 PUD 207dc0067 PMD 207c23067 PTE 80000001f39ba060
[ 33.574588] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 33.574588] CPU: 3 PID: 543 Comm: dhclient Not tainted 3.17.0-rc2.x86_64-00096-g9c6196f-dirty #138
[ 33.574588] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
[ 33.574588] task: ffff8800ecfce090 ti: ffff8801f9850000 task.ti: ffff8801f9850000
[ 33.574588] RIP: 0010:[<ffffffff814e701d>] [<ffffffff814e701d>] netvsc_select_queue+0x3d/0x150
[ 33.574588] RSP: 0018:ffff8801f9853cd8 EFLAGS: 00010206
[ 33.574588] RAX: 0000000000000000 RBX: ffff8801f7dfc520 RCX: 000000000000ffff
[ 33.574588] RDX: ffff8801f39aa4f8 RSI: ffff8801f366d200 RDI: ffff8801f7dfc520
[ 33.574588] RBP: ffff8801f9853d00 R08: 0000000000000156 R09: 0000000000000000
[ 33.574588] R10: ffff8801f7dfb3d8 R11: 000000000000000a R12: ffff8801f366d200
[ 33.574588] R13: 0000000000000000 R14: ffff8801f37eb7b0 R15: ffff8801f366d200
[ 33.574588] FS: 00007f19e6182880(0000) GS:ffff880206c60000(0000) knlGS:0000000000000000
[ 33.574588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 33.574588] CR2: ffff8801f39ba503 CR3: 00000001f3671000 CR4: 00000000000406e0
[ 33.574588] Stack:
[ 33.574588] ffffffff8167f651 ffff8801f7dfc520 0000000000000156 0000000000000000
[ 33.574588] ffff8801f37eb7b0 ffff8801f9853dc0 ffffffff816833bc ffffffff00000000
[ 33.574588] 00000000ffffffff ffff8801f9853d58 ffff8801f9f224c0 0000000000000156
[ 33.574588] Call Trace:
[ 33.574588] [<ffffffff8167f651>] ? packet_pick_tx_queue+0x31/0xa0
[ 33.574588] [<ffffffff816833bc>] packet_sendmsg+0xc1c/0xdd0
[ 33.574588] [<ffffffff815b357b>] sock_aio_write+0xfb/0x120
[ 33.574588] [<ffffffff811c262a>] do_sync_write+0x5a/0x80
[ 33.574588] [<ffffffff811c2925>] vfs_write+0xe5/0x1d0
[ 33.574588] [<ffffffff811c2b09>] SyS_write+0x49/0xb0
[ 33.574588] [<ffffffff816a32a9>] system_call_fastpath+0x16/0x1b
[ 33.574588] Code: 00 4d 85 d2 0f 84 1c 01 00 00 44 8b 9f 8c 03 00 00 31 c0 41 83 fb 01 0f 86 1b 01 00 00 0f b7 8e b4 00 00 00 48 8b 96 c0 00 00 00 <66> 83 7c 0a 0c 08 0f 85 01 01 00 00 55 48 89 e5 41 55 41 54 53
[ 33.574588] RIP [<ffffffff814e701d>] netvsc_select_queue+0x3d/0x150
[ 33.574588] RSP <ffff8801f9853cd8>
[ 33.574588] CR2: ffff8801f39ba503
[ 33.574588] ---[ end trace 760148d3316306ec ]---
[ 33.574588] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
[ 33.574588] in_atomic(): 0, irqs_disabled(): 1, pid: 543, name: dhclient
[ 33.574588] INFO: lockdep is turned off.
[ 33.574588] irq event stamp: 95826
[ 33.574588] hardirqs last enabled at (95825): [<ffffffff81698cb4>] __slab_alloc+0x50b/0x576
[ 33.574588] hardirqs last disabled at (95826): [<ffffffff816a5326>] error_sti+0x5/0x6
[ 33.574588] softirqs last enabled at (95758): [<ffffffff815ba278>] release_sock+0x1b8/0x210
[ 33.574588] softirqs last disabled at (95756): [<ffffffff815ba0f4>] release_sock+0x34/0x210
[ 35.698953] CPU: 3 PID: 543 Comm: dhclient Tainted: G D 3.17.0-rc2.x86_64-00096-g9c6196f-dirty #138
[ 35.698953] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
[ 35.698953] 0000000000000046 ffff8801f9853950 ffffffff8169a70b ffff8800ecfce090
[ 35.698953] ffff8801f9853968 ffffffff8109ec65 ffff8800eced62d8 ffff8801f9853988
[ 35.698953] ffffffff816a0d44 ffffffff81090f38 ffff8800ecfce090 ffff8801f98539a8
[ 35.698953] Call Trace:
[ 35.698953] [<ffffffff8169a70b>] dump_stack+0x4d/0x66
[ 35.698953] [<ffffffff8109ec65>] __might_sleep+0x115/0x120
[ 35.698953] [<ffffffff816a0d44>] down_read+0x24/0x70
[ 35.698953] [<ffffffff81090f38>] ? __validate_process_creds+0xd8/0xf0
[ 35.698953] [<ffffffff8107f9d4>] exit_signals+0x24/0x140
[ 35.698953] [<ffffffff810737d9>] do_exit+0x129/0xa20
[ 35.698953] [<ffffffff810c4bcc>] ? kmsg_dump+0xfc/0x110
[ 35.698953] [<ffffffff810c4af5>] ? kmsg_dump+0x25/0x110
[ 35.698953] [<ffffffff81006348>] oops_end+0xa8/0xc0
[ 35.698953] [<ffffffff81695288>] no_context+0x322/0x36b
[ 35.698953] [<ffffffff810b97fd>] ? trace_hardirqs_on_caller+0x17d/0x210
[ 35.698953] [<ffffffff8169549c>] __bad_area_nosemaphore+0x1cb/0x1e8
[ 35.698953] [<ffffffff816954cc>] bad_area_nosemaphore+0x13/0x15
[ 35.698953] [<ffffffff8104040e>] __do_page_fault+0x1ee/0x4f0
[ 35.698953] [<ffffffff8109c9db>] ? try_to_wake_up+0x3eb/0x400
[ 35.698953] [<ffffffff810bd106>] ? lock_release_non_nested+0xc6/0x330
[ 35.698953] [<ffffffff8139c0dd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 35.698953] [<ffffffff81040762>] do_page_fault+0x22/0x30
[ 35.698953] [<ffffffff816a5108>] page_fault+0x28/0x30
[ 35.698953] [<ffffffff814e701d>] ? netvsc_select_queue+0x3d/0x150
[ 35.698953] [<ffffffff8167f651>] ? packet_pick_tx_queue+0x31/0xa0
[ 35.698953] [<ffffffff816833bc>] packet_sendmsg+0xc1c/0xdd0
[ 35.698953] [<ffffffff815b357b>] sock_aio_write+0xfb/0x120
[ 35.698953] [<ffffffff811c262a>] do_sync_write+0x5a/0x80
[ 35.698953] [<ffffffff811c2925>] vfs_write+0xe5/0x1d0
[ 35.698953] [<ffffffff811c2b09>] SyS_write+0x49/0xb0
[ 35.698953] [<ffffffff816a32a9>] system_call_fastpath+0x16/0x1b
[ 35.698953] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
[ 35.698953] in_atomic(): 0, irqs_disabled(): 1, pid: 543, name: dhclient
[ 35.698953] INFO: lockdep is turned off.
[ 35.698953] irq event stamp: 95826
[ 35.698953] hardirqs last enabled at (95825): [<ffffffff81698cb4>] __slab_alloc+0x50b/0x576
[ 35.698953] hardirqs last disabled at (95826): [<ffffffff816a5326>] error_sti+0x5/0x6
[ 35.698953] softirqs last enabled at (95758): [<ffffffff815ba278>] release_sock+0x1b8/0x210
[ 35.698953] softirqs last disabled at (95756): [<ffffffff815ba0f4>] release_sock+0x34/0x210
[ 35.698953] CPU: 3 PID: 543 Comm: dhclient Tainted: G D 3.17.0-rc2.x86_64-00096-g9c6196f-dirty #138
[ 37.503488] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012
[ 37.503488] ffff8800ecfce090 ffff8801f9853940 ffffffff8169a70b ffff8800ecfce090
[ 37.503488] ffff8801f9853958 ffffffff8109ec65 ffff8801f3473a18 ffff8801f9853978
[ 37.503488] ffffffff816a0d44 ffffffff810d5cb1 ffff8800eced5e80 ffff8801f98539a8
[ 37.503488] Call Trace:
[ 37.503488] [<ffffffff8169a70b>] dump_stack+0x4d/0x66
[ 37.503488] [<ffffffff8109ec65>] __might_sleep+0x115/0x120
[ 37.503488] [<ffffffff816a0d44>] down_read+0x24/0x70
[ 37.503488] [<ffffffff810d5cb1>] ? hrtimer_try_to_cancel+0xf1/0x100
[ 37.503488] [<ffffffff810ec612>] acct_collect+0x52/0x1c0
[ 37.503488] [<ffffffff81074082>] do_exit+0x9d2/0xa20
[ 37.503488] [<ffffffff810c4bcc>] ? kmsg_dump+0xfc/0x110
[ 37.503488] [<ffffffff810c4af5>] ? kmsg_dump+0x25/0x110
[ 37.503488] [<ffffffff81006348>] oops_end+0xa8/0xc0
[ 37.503488] [<ffffffff81695288>] no_context+0x322/0x36b
[ 37.503488] [<ffffffff810b97fd>] ? trace_hardirqs_on_caller+0x17d/0x210
[ 37.503488] [<ffffffff8169549c>] __bad_area_nosemaphore+0x1cb/0x1e8
[ 37.503488] [<ffffffff816954cc>] bad_area_nosemaphore+0x13/0x15
[ 37.503488] [<ffffffff8104040e>] __do_page_fault+0x1ee/0x4f0
[ 37.503488] [<ffffffff8109c9db>] ? try_to_wake_up+0x3eb/0x400
[ 37.503488] [<ffffffff810bd106>] ? lock_release_non_nested+0xc6/0x330
[ 37.503488] [<ffffffff8139c0dd>] ? trace_hardirqs_off_thunk+0x3a/0x3c
[ 37.503488] [<ffffffff81040762>] do_page_fault+0x22/0x30
[ 37.503488] [<ffffffff816a5108>] page_fault+0x28/0x30
[ 37.503488] [<ffffffff814e701d>] ? netvsc_select_queue+0x3d/0x150
[ 37.503488] [<ffffffff8167f651>] ? packet_pick_tx_queue+0x31/0xa0
[ 37.503488] [<ffffffff816833bc>] packet_sendmsg+0xc1c/0xdd0
[ 37.503488] [<ffffffff815b357b>] sock_aio_write+0xfb/0x120
[ 37.503488] [<ffffffff811c262a>] do_sync_write+0x5a/0x80
[ 37.503488] [<ffffffff811c2925>] vfs_write+0xe5/0x1d0
[ 37.503488] [<ffffffff811c2b09>] SyS_write+0x49/0xb0
[ 37.503488] [<ffffffff816a32a9>] system_call_fastpath+0x16/0x1b
[ 37.504231] [sched_delayed] sched: RT throttling activated
[ 39.104323] hv_netvsc vmbus_0_15: net device safe to remove
[ 39.149816] hv_netvsc: hv_netvsc channel opened successfully
[ 40.899617] hv_netvsc vmbus_0_15: Send section size: 6144, Section count:2560
[ 40.947265] hv_netvsc vmbus_0_15: Device MAC 00:15:5d:6f:02:a5 link state up
The network interface that stopped working after the above was not the
one set to have an MTU of 9000...
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply
* [PATCH net-next] net: phy: mdio-bcm-unimac: NULL-terminate unimac_mdio_ids
From: Florian Fainelli @ 2014-08-29 19:43 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli, Fengguang Wu
drivers/net/phy/mdio-bcm-unimac.c:195:37-38: unimac_mdio_ids is not NULL
terminated at line 195
Make sure of_device_id tables are NULL terminated
Generated by: scripts/coccinelle/misc/of_table.cocci
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/mdio-bcm-unimac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/mdio-bcm-unimac.c b/drivers/net/phy/mdio-bcm-unimac.c
index e6b08ceb9c37..5b643e588e8f 100644
--- a/drivers/net/phy/mdio-bcm-unimac.c
+++ b/drivers/net/phy/mdio-bcm-unimac.c
@@ -193,6 +193,7 @@ static struct of_device_id unimac_mdio_ids[] = {
{ .compatible = "brcm,genet-mdio-v2", },
{ .compatible = "brcm,genet-mdio-v1", },
{ .compatible = "brcm,unimac-mdio", },
+ { /* sentinel */ },
};
static struct platform_driver unimac_mdio_driver = {
--
1.9.1
^ permalink raw reply related
* [PATCH net-next] net: dsa: make dsa_pack_type static
From: Florian Fainelli @ 2014-08-29 19:42 UTC (permalink / raw)
To: netdev; +Cc: davem, Florian Fainelli, Fengguang Wu
net/dsa/dsa.c:624:20: sparse: symbol 'dsa_pack_type' was not declared.
Should it be static?
Fixes: 3e8a72d1dae374 ("net: dsa: reduce number of protocol hooks")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
net/dsa/dsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 484f695351a7..61f145c44555 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -629,7 +629,7 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct net_device *dev,
return dst->ops->rcv(skb, dev, pt, orig_dev);
}
-struct packet_type dsa_pack_type __read_mostly = {
+static struct packet_type dsa_pack_type __read_mostly = {
.type = cpu_to_be16(ETH_P_XDSA),
.func = dsa_switch_rcv,
};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] brcmfmac: BRCMFMAC should depend on HAS_DMA
From: Geert Uytterhoeven @ 2014-08-29 19:24 UTC (permalink / raw)
To: Franky Lin
Cc: Brett Rudley, John W. Linville, David S. Miller, linux-wireless,
brcm80211-dev-list, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdXahUGQ1-4SvkCnt=BrAn6_Xge7RzieR2K8gDmj_pC-kw@mail.gmail.com>
On Fri, Aug 29, 2014 at 9:23 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> but then it still failed to link. Hence I restored to the main BRCMFMAC.
s/restored/resorted/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] brcmfmac: BRCMFMAC should depend on HAS_DMA
From: Geert Uytterhoeven @ 2014-08-29 19:23 UTC (permalink / raw)
To: Franky Lin
Cc: Brett Rudley, John W. Linville, David S. Miller, linux-wireless,
brcm80211-dev-list, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5400C3E8.9040500@broadcom.com>
Hi Franky,
On Fri, Aug 29, 2014 at 8:18 PM, Franky Lin <frankyl@broadcom.com> wrote:
>> config BRCMFMAC
>> tristate "Broadcom IEEE802.11n embedded FullMAC WLAN driver"
>> - depends on CFG80211
>> + depends on CFG80211A && HAS_DMA
>> select BRCMUTIL
>> ---help---
>> This module adds support for embedded wireless adapters based on
>
> Thanks for reporting this. All complaints are from msgbuf code. So the
> dependency should belong to BRCMFMAC_PCIE not BRCMFMAC.
I have PCI=n, hence BRCMFMAC_PCIE=n.
IIRC, I did try adding the HAS_DMA dependencies to the suboptions,
but then it still failed to link. Hence I restored to the main BRCMFMAC.
Besides, msgbuf.o is part of the core.
I've just tried moving it to brcmfmac-$(CONFIG_BRCMFMAC_PCIE),
but that doesn't help. Other parts use msgbuf, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [net-next PATCH] pktgen: add flag NO_TIMESTAMP to disable timestamping
From: Jesper Dangaard Brouer @ 2014-08-29 19:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev, Ben Greear, Robert Olsson, brouer
In-Reply-To: <1409329026.3173.93.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, 29 Aug 2014 09:17:06 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-08-28 at 18:14 +0200, Jesper Dangaard Brouer wrote:
> > Then testing the TX limits of the stack, then it is useful to
> > be-able to disable the do_gettimeofday() timetamping on every packet.
> >
> > This implements a pktgen flag NO_TIMESTAMP which will disable this
> > call to do_gettimeofday().
> >
> > The performance change on (my system E5-2695) with skb_clone=0, goes
> > from TX 2,423,751 pps to 2,567,165 pps with flag NO_TIMESTAMP. Thus,
> > the cost of do_gettimeofday() or saving is approx 23 nanosec.
>
> I guess using local_clock() would provide an accurate and less expensive
> timestamp, if a timestamp is needed.
Sure, but I don't need this timestamp, thus I added an option to disable it.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] brcmfmac: BRCMFMAC should depend on HAS_DMA
From: Franky Lin @ 2014-08-29 18:18 UTC (permalink / raw)
To: Geert Uytterhoeven, Brett Rudley, John W. Linville,
David S. Miller
Cc: linux-wireless, brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <1409329464-768-1-git-send-email-geert@linux-m68k.org>
Hi Geert,
On 8/29/2014 9:24 AM, Geert Uytterhoeven wrote:
> If NO_DMA=y:
>
> drivers/built-in.o: In function `brcmf_msgbuf_release_array':
> msgbuf.c:(.text+0x34dbbe): undefined reference to `dma_unmap_single'
> drivers/built-in.o: In function `brcmf_proto_msgbuf_detach':
> (.text+0x34dca4): undefined reference to `dma_free_coherent'
> drivers/built-in.o: In function `brcmf_msgbuf_get_pktid':
> msgbuf.c:(.text+0x34dd2a): undefined reference to `dma_unmap_single'
> drivers/built-in.o: In function `brcmf_msgbuf_alloc_pktid':
> msgbuf.c:(.text+0x34de12): undefined reference to `dma_map_single'
> msgbuf.c:(.text+0x34de20): undefined reference to `dma_mapping_error'
> drivers/built-in.o: In function `brcmf_msgbuf_remove_flowring':
> msgbuf.c:(.text+0x34e3d6): undefined reference to `dma_free_coherent'
> drivers/built-in.o: In function `brcmf_msgbuf_flowring_create':
> msgbuf.c:(.text+0x34e4f8): undefined reference to `dma_alloc_coherent'
> drivers/built-in.o: In function `brcmf_proto_msgbuf_attach':
> (.text+0x34f5fe): undefined reference to `dma_alloc_coherent'
> drivers/built-in.o: In function `brcmf_proto_msgbuf_attach':
> (.text+0x34f798): undefined reference to `dma_free_coherent'
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
> drivers/net/wireless/brcm80211/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/brcm80211/Kconfig b/drivers/net/wireless/brcm80211/Kconfig
> index b8e2561ea645..2e0da8925834 100644
> --- a/drivers/net/wireless/brcm80211/Kconfig
> +++ b/drivers/net/wireless/brcm80211/Kconfig
> @@ -19,7 +19,7 @@ config BRCMSMAC
>
> config BRCMFMAC
> tristate "Broadcom IEEE802.11n embedded FullMAC WLAN driver"
> - depends on CFG80211
> + depends on CFG80211A && HAS_DMA
> select BRCMUTIL
> ---help---
> This module adds support for embedded wireless adapters based on
Thanks for reporting this. All complaints are from msgbuf code. So the
dependency should belong to BRCMFMAC_PCIE not BRCMFMAC.
Thanks,
Franky
^ permalink raw reply
* [PATCH net v1 2/4] amd-xgbe: Reported fifo size from hardware is not correct
From: Tom Lendacky @ 2014-08-29 18:16 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20140829181643.3257.28011.stgit@tlendack-t1.amdoffice.net>
The fifo size reported by the hardware is not correct. Add support
to limit the reported size to what is actually present. Also, fix
the argument types used in the fifo size calculation function.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 8 ++++++--
drivers/net/ethernet/amd/xgbe/xgbe.h | 1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
index e43747a..acde00c 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
@@ -1706,8 +1706,8 @@ static void xgbe_config_mtl_mode(struct xgbe_prv_data *pdata)
XGMAC_IOWRITE_BITS(pdata, MTL_OMR, RAA, MTL_RAA_SP);
}
-static unsigned int xgbe_calculate_per_queue_fifo(unsigned long fifo_size,
- unsigned char queue_count)
+static unsigned int xgbe_calculate_per_queue_fifo(unsigned int fifo_size,
+ unsigned int queue_count)
{
unsigned int q_fifo_size = 0;
enum xgbe_mtl_fifo_size p_fifo = XGMAC_MTL_FIFO_SIZE_256;
@@ -1751,6 +1751,10 @@ static unsigned int xgbe_calculate_per_queue_fifo(unsigned long fifo_size,
q_fifo_size = XGBE_FIFO_SIZE_KB(256);
break;
}
+
+ /* The configured value is not the actual amount of fifo RAM */
+ q_fifo_size = min_t(unsigned int, XGBE_FIFO_MAX, q_fifo_size);
+
q_fifo_size = q_fifo_size / queue_count;
/* Set the queue fifo size programmable value */
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe.h b/drivers/net/ethernet/amd/xgbe/xgbe.h
index 5af5c38..e9fe6e6 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe.h
+++ b/drivers/net/ethernet/amd/xgbe/xgbe.h
@@ -183,6 +183,7 @@
#define XGMAC_DRIVER_CONTEXT 1
#define XGMAC_IOCTL_CONTEXT 2
+#define XGBE_FIFO_MAX 81920
#define XGBE_FIFO_SIZE_B(x) (x)
#define XGBE_FIFO_SIZE_KB(x) (x * 1024)
^ permalink raw reply related
* [PATCH net v1 4/4] amd-xgbe: Use the Tx queue count for Tx flow control support
From: Tom Lendacky @ 2014-08-29 18:17 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20140829181643.3257.28011.stgit@tlendack-t1.amdoffice.net>
When configuring Tx flow control the Rx queue count was used instead of
the Tx queue count for looping through the Tx hardware queues. Fix the
code to use the Tx queue count.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
index acde00c..6d0207e 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
@@ -348,7 +348,7 @@ static int xgbe_disable_tx_flow_control(struct xgbe_prv_data *pdata)
/* Clear MAC flow control */
max_q_count = XGMAC_MAX_FLOW_CONTROL_QUEUES;
- q_count = min_t(unsigned int, pdata->rx_q_count, max_q_count);
+ q_count = min_t(unsigned int, pdata->tx_q_count, max_q_count);
reg = MAC_Q0TFCR;
for (i = 0; i < q_count; i++) {
reg_val = XGMAC_IOREAD(pdata, reg);
@@ -373,7 +373,7 @@ static int xgbe_enable_tx_flow_control(struct xgbe_prv_data *pdata)
/* Set MAC flow control */
max_q_count = XGMAC_MAX_FLOW_CONTROL_QUEUES;
- q_count = min_t(unsigned int, pdata->rx_q_count, max_q_count);
+ q_count = min_t(unsigned int, pdata->tx_q_count, max_q_count);
reg = MAC_Q0TFCR;
for (i = 0; i < q_count; i++) {
reg_val = XGMAC_IOREAD(pdata, reg);
^ permalink raw reply related
* [PATCH net v1 3/4] amd-xgbe: Fix the xpcs mmd debugfs support
From: Tom Lendacky @ 2014-08-29 18:17 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20140829181643.3257.28011.stgit@tlendack-t1.amdoffice.net>
The debugfs support for the xpcs registers did not properly use the
specified mmd (xpcs_mmd entry) which resulted in the default mmd
value always being used. Update the debugfs support to generate the
proper mmd register value.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c b/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c
index 346592d..a3c1135 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c
@@ -272,8 +272,8 @@ static ssize_t xpcs_reg_value_read(struct file *filp, char __user *buffer,
struct xgbe_prv_data *pdata = filp->private_data;
unsigned int value;
- value = pdata->hw_if.read_mmd_regs(pdata, pdata->debugfs_xpcs_mmd,
- pdata->debugfs_xpcs_reg);
+ value = XMDIO_READ(pdata, pdata->debugfs_xpcs_mmd,
+ pdata->debugfs_xpcs_reg);
return xgbe_common_read(buffer, count, ppos, value);
}
@@ -290,8 +290,8 @@ static ssize_t xpcs_reg_value_write(struct file *filp,
if (len < 0)
return len;
- pdata->hw_if.write_mmd_regs(pdata, pdata->debugfs_xpcs_mmd,
- pdata->debugfs_xpcs_reg, value);
+ XMDIO_WRITE(pdata, pdata->debugfs_xpcs_mmd, pdata->debugfs_xpcs_reg,
+ value);
return len;
}
^ permalink raw reply related
* [PATCH net v1 1/4] amd-xgbe: Check for Tx hardware queue flushing support
From: Tom Lendacky @ 2014-08-29 18:16 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20140829181643.3257.28011.stgit@tlendack-t1.amdoffice.net>
The flushing of the Tx hardware queues is only supported at a certain
level of the hardware. Retrieve the current version of the hardware
and use that to determine if flushing is supported.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 3 +++
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 ++
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 7 ++++---
drivers/net/ethernet/amd/xgbe/xgbe.h | 3 +++
4 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
index edaca44..e43747a 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
@@ -1633,6 +1633,9 @@ static int xgbe_flush_tx_queues(struct xgbe_prv_data *pdata)
{
unsigned int i, count;
+ if (XGMAC_GET_BITS(pdata->hw_feat.version, MAC_VR, SNPSVER) < 0x21)
+ return 0;
+
for (i = 0; i < pdata->tx_q_count; i++)
XGMAC_MTL_IOWRITE_BITS(pdata, i, MTL_Q_TQOMR, FTQ, 1);
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index dc84f71..b26d758 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -361,6 +361,8 @@ void xgbe_get_all_hw_features(struct xgbe_prv_data *pdata)
memset(hw_feat, 0, sizeof(*hw_feat));
+ hw_feat->version = XGMAC_IOREAD(pdata, MAC_VR);
+
/* Hardware feature register 0 */
hw_feat->gmii = XGMAC_GET_BITS(mac_hfr0, MAC_HWF0R, GMIISEL);
hw_feat->vlhash = XGMAC_GET_BITS(mac_hfr0, MAC_HWF0R, VLHASH);
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c b/drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c
index a076aca..46f6130 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c
@@ -361,15 +361,16 @@ static void xgbe_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
struct xgbe_prv_data *pdata = netdev_priv(netdev);
+ struct xgbe_hw_features *hw_feat = &pdata->hw_feat;
strlcpy(drvinfo->driver, XGBE_DRV_NAME, sizeof(drvinfo->driver));
strlcpy(drvinfo->version, XGBE_DRV_VERSION, sizeof(drvinfo->version));
strlcpy(drvinfo->bus_info, dev_name(pdata->dev),
sizeof(drvinfo->bus_info));
snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "%d.%d.%d",
- XGMAC_IOREAD_BITS(pdata, MAC_VR, USERVER),
- XGMAC_IOREAD_BITS(pdata, MAC_VR, DEVID),
- XGMAC_IOREAD_BITS(pdata, MAC_VR, SNPSVER));
+ XGMAC_GET_BITS(hw_feat->version, MAC_VR, USERVER),
+ XGMAC_GET_BITS(hw_feat->version, MAC_VR, DEVID),
+ XGMAC_GET_BITS(hw_feat->version, MAC_VR, SNPSVER));
drvinfo->n_stats = XGBE_STATS_COUNT;
}
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe.h b/drivers/net/ethernet/amd/xgbe/xgbe.h
index 07bf70a..5af5c38 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe.h
+++ b/drivers/net/ethernet/amd/xgbe/xgbe.h
@@ -526,6 +526,9 @@ struct xgbe_desc_if {
* or configurations are present in the device.
*/
struct xgbe_hw_features {
+ /* HW Version */
+ unsigned int version;
+
/* HW Feature Register0 */
unsigned int gmii; /* 1000 Mbps support */
unsigned int vlhash; /* VLAN Hash Filter */
^ permalink raw reply related
* [PATCH net v1 0/4] amd-xgbe: AMD XGBE driver fixes 2014-08-29
From: Tom Lendacky @ 2014-08-29 18:16 UTC (permalink / raw)
To: netdev; +Cc: davem
The following series of patches includes fixes to the driver.
- Tx hardware queue flushing support dependent on hardware version
- Incorrect reported fifo size
- Proper mmd select in XPCS debugfs support
- Proper queue count for configuring Tx flow control
This patch series is based on net.
---
Tom Lendacky (4):
amd-xgbe: Check for Tx hardware queue flushing support
amd-xgbe: Reported fifo size from hardware is not correct
amd-xgbe: Fix the xpcs mmd debugfs support
amd-xgbe: Use the Tx queue count for Tx flow control support
drivers/net/ethernet/amd/xgbe/xgbe-debugfs.c | 8 ++++----
drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 15 +++++++++++----
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 ++
drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c | 7 ++++---
drivers/net/ethernet/amd/xgbe/xgbe.h | 4 ++++
5 files changed, 25 insertions(+), 11 deletions(-)
--
Tom Lendacky
^ permalink raw reply
* Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)
From: Cong Wang @ 2014-08-29 18:14 UTC (permalink / raw)
To: Tommi Rantala
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Hannes Frederic Sowa, netdev,
LKML, trinity, Dave Jones
In-Reply-To: <CA+ydwtoDwQVg_BWrxxdpUyJ7Up60GtxTCLYe_5vFdV2td_kGhQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]
On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala <tt.rantala@gmail.com> wrote:
> [ 77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
> [ 77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+ #30
> [ 77.299039] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 77.299789] ffff88003d76a618 ffff880026133c50 ffffffff8238ba79
> ffff880037c84520
> [ 77.300829] ffff880026133c90 ffffffff820bd52b 0000000000000000
> ffffffff82d86c40
> [ 77.301869] 0000000000000000 00000000f76fd1e1 ffff8800382d8000
> ffff8800382d8220
> [ 77.302906] Call Trace:
> [ 77.303246] [<ffffffff8238ba79>] dump_stack+0x4d/0x66
> [ 77.303928] [<ffffffff820bd52b>] addrconf_join_solict+0x4b/0xb0
> [ 77.304731] [<ffffffff820b031b>] ipv6_dev_ac_inc+0x2bb/0x330
> [ 77.305498] [<ffffffff820b0060>] ? ac6_seq_start+0x260/0x260
> [ 77.306257] [<ffffffff820b05fe>] ipv6_sock_ac_join+0x26e/0x360
> [ 77.307046] [<ffffffff820b0429>] ? ipv6_sock_ac_join+0x99/0x360
> [ 77.307798] [<ffffffff820cdd60>] do_ipv6_setsockopt.isra.5+0xa70/0xf20
I think we should just use rtnl_lock() instead of rcu_read_lock() there,
it is not a hot path worth optimization.
Please try the attached patch.
[-- Attachment #2: ipv6-anycast.diff --]
[-- Type: text/plain, Size: 3664 bytes --]
commit 31d83db0b417f705cbb31b2159603b8b53b81ab6
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri Aug 29 11:02:15 2014 -0700
ipv6: fix rtnl lock assertion in ipv6_sock_ac_join()
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4298013..1ae0e74 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2077,8 +2077,8 @@ void __dev_remove_pack(struct packet_type *pt);
void dev_add_offload(struct packet_offload *po);
void dev_remove_offload(struct packet_offload *po);
-struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short flags,
- unsigned short mask);
+struct net_device *dev_get_by_flags(struct net *net, unsigned short flags,
+ unsigned short mask);
struct net_device *dev_get_by_name(struct net *net, const char *name);
struct net_device *dev_get_by_name_rcu(struct net *net, const char *name);
struct net_device *__dev_get_by_name(struct net *net, const char *name);
diff --git a/net/core/dev.c b/net/core/dev.c
index 26d296c..73cdb03 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -897,23 +897,24 @@ struct net_device *dev_getfirstbyhwtype(struct net *net, unsigned short type)
EXPORT_SYMBOL(dev_getfirstbyhwtype);
/**
- * dev_get_by_flags_rcu - find any device with given flags
+ * dev_get_by_flags - find any device with given flags
* @net: the applicable net namespace
* @if_flags: IFF_* values
* @mask: bitmask of bits in if_flags to check
*
* Search for any interface with the given flags. Returns NULL if a device
* is not found or a pointer to the device. Must be called inside
- * rcu_read_lock(), and result refcount is unchanged.
+ * rtnl_lock(), and result refcount is unchanged.
*/
-struct net_device *dev_get_by_flags_rcu(struct net *net, unsigned short if_flags,
+struct net_device *dev_get_by_flags(struct net *net, unsigned short if_flags,
unsigned short mask)
{
struct net_device *dev, *ret;
+ ASSERT_RTNL();
ret = NULL;
- for_each_netdev_rcu(net, dev) {
+ for_each_netdev(net, dev) {
if (((dev->flags ^ if_flags) & mask) == 0) {
ret = dev;
break;
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 2101832..c523c1a 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -77,7 +77,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
pac->acl_next = NULL;
pac->acl_addr = *addr;
- rcu_read_lock();
+ rtnl_lock();
if (ifindex == 0) {
struct rt6_info *rt;
@@ -90,11 +90,11 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
goto error;
} else {
/* router, no matching interface: just pick one */
- dev = dev_get_by_flags_rcu(net, IFF_UP,
+ dev = dev_get_by_flags(net, IFF_UP,
IFF_UP | IFF_LOOPBACK);
}
} else
- dev = dev_get_by_index_rcu(net, ifindex);
+ dev = __dev_get_by_index(net, ifindex);
if (dev == NULL) {
err = -ENODEV;
@@ -136,7 +136,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const struct in6_addr *addr)
}
error:
- rcu_read_unlock();
+ rtnl_unlock();
if (pac)
sock_kfree_s(sk, pac, sizeof(*pac));
return err;
@@ -171,13 +171,15 @@ int ipv6_sock_ac_drop(struct sock *sk, int ifindex, const struct in6_addr *addr)
spin_unlock_bh(&ipv6_sk_ac_lock);
- rcu_read_lock();
- dev = dev_get_by_index_rcu(net, pac->acl_ifindex);
+ rtnl_lock();
+ dev = __dev_get_by_index(net, pac->acl_ifindex);
if (dev)
ipv6_dev_ac_dec(dev, &pac->acl_addr);
- rcu_read_unlock();
+ rtnl_unlock();
sock_kfree_s(sk, pac, sizeof(*pac));
+ if (!dev)
+ return -ENODEV;
return 0;
}
^ permalink raw reply related
* Re: [PATCH v8 net-next 2/2] net: filter: split filter.h and expose eBPF to user space
From: Alexei Starovoitov @ 2014-08-29 18:02 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, David S. Miller, Ingo Molnar, Linus Torvalds,
Andy Lutomirski, Steven Rostedt, Chema Gonzalez, Eric Dumazet,
Peter Zijlstra, Brendan Gregg, Namhyung Kim, H. Peter Anvin,
Andrew Morton, Kees Cook, Linux API,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <5400BAB7.80001-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, Aug 29, 2014 at 10:39 AM, Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On 08/27/2014 10:37 PM, Alexei Starovoitov wrote:
>>
>> allow user space to generate eBPF programs
>>
>> uapi/linux/bpf.h: eBPF instruction set definition
>>
>> linux/filter.h: the rest
>
>
> Very sorry for being late, but just a thought since we're touching user
> space headers anyway ...
>
> Wouldn't it be more consistent to have it organized as follows ...
>
> - uapi/linux/bpf.h : classic BPF instruction set parts only
> - uapi/linux/ebpf.h : eBPF instruction set definition (which also
> includes uapi/linux/bpf.h though)
> ... and have ...
>
> - uapi/linux/filter.h : just include uapi/linux/bpf.h but rest is empty
>
> That way, it would be more consistent ...
>
> Old legacy application can stay with linux/filter.h; new applications
> based on their needs can choose between linux/{e,}bpf.h and in the kernel,
> we can just include linux/ebpf.h.
>
> Right now, it seems, an eBPF user space program would need to include
> 2 header files in user space (linux/filter.h, linux/bpf.h) which I find
> a bit confusing.
It's been bugging me as well, but I suspect having it the way you
described won't work. Mainly because we cannot do include <uapi/..>
inside uapi/*.h, so we would need to do include <linux/bpf.h>
inside uapi/linux/filter.h, but that will cause serious include path
confusion. That was the reason I didn't simply do include <linux/filter.h>
inside uapi/linux/bpf.h
Also I really dislike 'ebpf' name in all lower case. If we make such header
file name, we would need to rename all macros and function names
to EBPF_... which I find very ugly looking. I think all good abbreviations are
three letters :)
So I very much prefer bpf.h as a main file name.
Later we can move some of old classic BPF defines into
uapi/linux/bpf_common.h and then include it in both uapi/linux/bpf.h
and in uapi/linux/filter.h, then the nuisance of two include files for
user space will go away. Classic users will keep using linux/filter.h
and new apps will include linux/bpf.h only.
I think we should probably do such header optimization later and very carefully.
I'm a bit afraid to touch uapi/linux/filter.h since it's used in so
many user apps.
^ permalink raw reply
* Re: [PATCH v8 net-next 2/2] net: filter: split filter.h and expose eBPF to user space
From: Daniel Borkmann @ 2014-08-29 17:39 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Ingo Molnar, Linus Torvalds, Andy Lutomirski,
Steven Rostedt, Chema Gonzalez, Eric Dumazet, Peter Zijlstra,
Brendan Gregg, Namhyung Kim, H. Peter Anvin, Andrew Morton,
Kees Cook, linux-api, netdev, linux-kernel
In-Reply-To: <1409171833-6979-3-git-send-email-ast@plumgrid.com>
On 08/27/2014 10:37 PM, Alexei Starovoitov wrote:
> allow user space to generate eBPF programs
>
> uapi/linux/bpf.h: eBPF instruction set definition
>
> linux/filter.h: the rest
Very sorry for being late, but just a thought since we're touching user
space headers anyway ...
Wouldn't it be more consistent to have it organized as follows ...
- uapi/linux/bpf.h : classic BPF instruction set parts only
- uapi/linux/ebpf.h : eBPF instruction set definition (which also
includes uapi/linux/bpf.h though)
... and have ...
- uapi/linux/filter.h : just include uapi/linux/bpf.h but rest is empty
That way, it would be more consistent ...
Old legacy application can stay with linux/filter.h; new applications
based on their needs can choose between linux/{e,}bpf.h and in the kernel,
we can just include linux/ebpf.h.
Right now, it seems, an eBPF user space program would need to include
2 header files in user space (linux/filter.h, linux/bpf.h) which I find
a bit confusing.
If you want, I could also take care of that later, but just thinking out
loudly ...
> This patch only moves macro definitions, but practically it freezes existing
> eBPF instruction set, though new instructions can still be added in the future.
>
> These eBPF definitions cannot go into uapi/linux/filter.h, since the names
> may conflict with existing applications.
>
> Full eBPF ISA description is in Documentation/networking/filter.txt
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
^ permalink raw reply
* Re: [net-next 05/15] i40e: Tell OS link is going down when calling set_phy_config
From: Sergei Shtylyov @ 2014-08-29 17:37 UTC (permalink / raw)
To: Jeff Kirsher, davem; +Cc: Catherine Sullivan, netdev, nhorman, sassmann
In-Reply-To: <1409304620-23251-6-git-send-email-jeffrey.t.kirsher@intel.com>
On 08/29/2014 01:30 PM, Jeff Kirsher wrote:
> From: Catherine Sullivan <catherine.sullivan@intel.com>
> Since we don't seem to be getting an LSE telling us link is going down
> during set_phy_config (but we do get an LSE telling us we are coming
> back up), fake one for the OS and tell them link is going down. Also
> do an atomic restart no matter what because there are times the user
> may want to end with link up even if they started with link down (like
> if they accidentally set it to a speed that can't link and are trying to
> fix it).
> Change-ID: I0a642af9c1d0feb67bce741aba1a9c33bd349ed6
> Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
> Tested-by: Jim Young <jamesx.m.young@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> index de4ce0e..101be2f 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
> @@ -559,9 +559,17 @@ static int i40e_set_settings(struct net_device *netdev,
> config.eeer = abilities.eeer_val;
> config.low_power_ctrl = abilities.d3_lpan;
>
> - /* If link is up set link and an so changes take effect */
> - if (hw->phy.link_info.link_info & I40E_AQ_LINK_UP)
> - config.abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK;
> + /* set link and an so changes take effect */
Can't parse this comment, probably a word is missing?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net v4 4/4] tg3: Fix tx_pending checks for tg3_tso_bug
From: Benjamin Poirier @ 2014-08-29 17:20 UTC (permalink / raw)
To: Prashant Sreedharan; +Cc: Michael Chan, netdev, linux-kernel
In-Reply-To: <1409282668.12635.21.camel@prashant>
On 2014/08/28 20:24, Prashant Sreedharan wrote:
> >
> > - for (i = 0; i < tp->irq_max; i++)
> > - tp->napi[i].tx_pending = ering->tx_pending;
> > + dev->gso_max_segs = TG3_TX_SEG_PER_DESC(ering->tx_pending - 1);
> > + for (i = 0; i < tp->irq_max; i++) {
> > + struct tg3_napi *tnapi = &tp->napi[i];
> > +
> > + tnapi->tx_pending = ering->tx_pending;
> > + if (netif_tx_queue_stopped(netdev_get_tx_queue(dev, i)) &&
>
> Need to limit the number of TX queues to tp->txq_cnt instead of
> tp->irq_max as txq_cnt can be less than irq_max.
>
> netif_set_real_num_tx_queues(tp->dev, tp->txq_cnt);
Thanks for your careful review, I'll resubmit shortly.
>
> > + tnapi->wakeup_thresh >= ering->tx_pending)
> > + tnapi->wakeup_thresh = MAX_SKB_FRAGS + 1;
> > + }
> >
>
>
>
^ permalink raw reply
* RE: [hyperv] BUG: unable to handle kernel paging request at ffff8801f5bc7cbb (netvsc_select_queue)
From: KY Srinivasan @ 2014-08-29 17:18 UTC (permalink / raw)
To: Sitsofe Wheeler, Dexuan Cui
Cc: Greg Kroah-Hartman, Haiyang Zhang, devel@linuxdriverproject.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David Miller, Daniel Borkmann
In-Reply-To: <20140829093141.GC11445@sucs.org>
> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Friday, August 29, 2014 2:32 AM
> To: Dexuan Cui
> Cc: KY Srinivasan; Greg Kroah-Hartman; Haiyang Zhang;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; David Miller; Daniel Borkmann
> Subject: [hyperv] BUG: unable to handle kernel paging request at
> ffff8801f5bc7cbb (netvsc_select_queue)
>
> While booting a 10 vcpu system with a post v3.17-rc2 kernel with the
> "Drivers: hv: vmbus: Eliminate calls to BUG_ON()", "Drivers: hv: vmbus:
> Miscellaneous cleanup" patches and debugging/verification config options on
> I'm seeing the following:
Sitsofe,
Could you please try the following patch:
>From c8a6a5570f9a7f8b9a2b47f165848e5533091e79 Mon Sep 17 00:00:00 2001
From: K. Y. Srinivasan <kys@microsoft.com>
Date: Fri, 29 Aug 2014 11:18:18 -0700
Subject: [PATCH 1/1] Drivers: net: hyperv: Cleanup netvsc_change_mtu ()
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/net/hyperv/netvsc_drv.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index a9c5eaa..485f5b7 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -696,6 +696,7 @@ static int netvsc_change_mtu(struct net_device *ndev, int mtu)
struct netvsc_device *nvdev = hv_get_drvdata(hdev);
struct netvsc_device_info device_info;
int limit = ETH_DATA_LEN;
+ int ret;
if (nvdev == NULL || nvdev->destroy)
return -ENODEV;
@@ -716,7 +717,9 @@ static int netvsc_change_mtu(struct net_device *ndev, int mtu)
ndevctx->device_ctx = hdev;
hv_set_drvdata(hdev, ndev);
device_info.ring_size = ring_size;
- rndis_filter_device_add(hdev, &device_info);
+ ret = rndis_filter_device_add(hdev, &device_info);
+ if (ret)
+ return ret;
netif_tx_wake_all_queues(ndev);
return 0;
--
1.7.4.1
^ permalink raw reply related
* RE: [hyperv] BUG: unable to handle kernel paging request at ffff8801f5bc7cbb (netvsc_select_queue)
From: KY Srinivasan @ 2014-08-29 17:13 UTC (permalink / raw)
To: Sitsofe Wheeler, Dexuan Cui
Cc: Greg Kroah-Hartman, Haiyang Zhang, linux-kernel@vger.kernel.org,
Daniel Borkmann, netdev@vger.kernel.org,
devel@linuxdriverproject.org, David Miller
In-Reply-To: <20140829093141.GC11445@sucs.org>
> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Friday, August 29, 2014 2:32 AM
> To: Dexuan Cui
> Cc: KY Srinivasan; Greg Kroah-Hartman; Haiyang Zhang;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org;
> netdev@vger.kernel.org; David Miller; Daniel Borkmann
> Subject: [hyperv] BUG: unable to handle kernel paging request at
> ffff8801f5bc7cbb (netvsc_select_queue)
>
> While booting a 10 vcpu system with a post v3.17-rc2 kernel with the
> "Drivers: hv: vmbus: Eliminate calls to BUG_ON()", "Drivers: hv: vmbus:
> Miscellaneous cleanup" patches and debugging/verification config options on
> I'm seeing the following:
Were you changing the MTU when this occurred?
Regards,
K. Y
^ permalink raw reply
* Re: [net-next 08/15] i40e: fix panic due to too-early Tx queue enable
From: Sergei Shtylyov @ 2014-08-29 17:08 UTC (permalink / raw)
To: Jeff Kirsher, davem
Cc: Jesse Brandeburg, netdev, nhorman, sassmann, Mitch Williams
In-Reply-To: <1409304620-23251-9-git-send-email-jeffrey.t.kirsher@intel.com>
Hello.
On 08/29/2014 01:30 PM, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
> This fixes the panic under traffic load when resetting. This issue
> could also show up if/whenever there is a Tx-timeout.
> Change-ID: Ie393a1f17fd5d962e56fc3bfe784899ef25402f5
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> Tested-by: Jim Young <jamesx.m.young@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 64b8683..d37dea1 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -5289,7 +5289,7 @@ static void i40e_fdir_reinit_subtask(struct i40e_pf *pf)
> **/
> static void i40e_vsi_link_event(struct i40e_vsi *vsi, bool link_up)
> {
> - if (!vsi)
> + if (!vsi || (test_bit(__I40E_DOWN, &vsi->state)))
Enclosing function call into parens is totally pointless.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/5] ARM: Berlin: Ethernet support
From: Sebastian Hesselbarth @ 2014-08-29 16:47 UTC (permalink / raw)
To: Antoine Tenart, thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, jszhang-eYqpPyKDWXRBDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1409320263-10295-1-git-send-email-antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On 08/29/2014 03:50 PM, Antoine Tenart wrote:
> This series introduce the Marvell Berlin Ethernet driver, allowing to
> handle the fast Ethernet port. This driver is based on the mv643xx_eth
> driver and reuse some of its functions. While I wanted to make these
> functions common to the two drivers at first, I finally do think this
> is not a great idea:
> - Registers are very different.
> - The mv643xx_eth supports up to 1000Mbps interfaces and performance
> issues may occur, whereas the mvberlin_eth is only for fast Ethernet.
> - The mvberlin_eth driver uses a hash table to filter incoming packets.
> - A few other differences.
>
> I tried to stay close to the mv643xx_eth implementation, so that the
> discussion is still open, but I still ended up with lots of tiny
> differences that can be hard to manage for both cases. In the end I do
> think having two separate drivers is a good choice.
Antoine,
first of all, thanks a lot for providing this driver! I checked the
usual Marvell datasheets to see where the ethernet IP in Berlin comes
from and I hate to say it but it very much looks like PXA168, see [1]
A.22. Also, there is already a driver for pxa168_eth available.
I'll test and review you current driver on BG2 asap, but I guess it
should be merged with pxa168_eth _if_ the registers are really
compatible.
Sebastian
[1]
http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf
> That being said, I tested the Ethernet communication with ICMP pings,
> netcat, tried to use some network related softwares (such as ssh). Here
> is an iperf output:
>
> ------------------------------------------------------------
> Client connecting to 192.168.0.11, TCP port 5001
> TCP window size: 85.0 KByte (default)
> ------------------------------------------------------------
> [ 3] local 192.168.0.20 port 44183 connected with 192.168.0.11 port 5001
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.0 sec 113 MBytes 94.8 Mbits/sec
>
> Tests were done on a BG2Q DMP, and this series currently does not add
> other device tree nodes than the ones for this board.
>
> Thanks!
>
> Antoine
>
>
> Antoine Tenart (5):
> net: mvberlin_eth: add an Ethernet driver for Marvell Berlin
> Documentation: bindings: net: add the Marvell Berlin Ethernet
> controller
> Documentation: devicetree: net: mention Marvell Berlin
> ARM: dts: berlin: add ethernet and mdio nodes
> ARM: dts: berlin: enable the Ethernet port on the BG2Q DMP
>
> .../devicetree/bindings/net/marvell-berlin.txt | 23 +
> .../devicetree/bindings/net/marvell-orion-mdio.txt | 6 +-
> arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 13 +
> arch/arm/boot/dts/berlin2q.dtsi | 19 +
> drivers/net/ethernet/marvell/Kconfig | 9 +
> drivers/net/ethernet/marvell/Makefile | 1 +
> drivers/net/ethernet/marvell/mvberlin_eth.c | 2081 ++++++++++++++++++++
> 7 files changed, 2149 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/marvell-berlin.txt
> create mode 100644 drivers/net/ethernet/marvell/mvberlin_eth.c
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* Business Proposal.
From: Edward Lampl @ 2014-08-29 12:04 UTC (permalink / raw)
Good Day,
My name is Edward Lampl, i have gone through your profile and found out
that you are capable of
handling this project, I work with an INTESTATE & HEIR ESTATE BENEFICIARY
TRACING company in united states.
I have an important business proposal that would be of mutual benefit to
us, all I need is your TRUST and CONFIDENCE. It is risk free as long as
you would follow every instruction.
If interested, contact me on: edward@admin.in.th
Regards,
Ed Lampl
^ 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