* [PATCH net-next 3/3] qlcnic: Fix protcol type in case of inband vlan.
From: Anirban Chakraborty @ 2012-06-06 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Rajesh Borundia
In-Reply-To: <1339004108-7356-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Rajesh Borundia <rajesh.borundia@qlogic.com>
o Use correct l3 (ETH_IP or ETH_IPV6)protcol in case
of inband vlan. Because of incorrect protcol type driver
was setting incorrect opcode. This resulted in adapter calculating
checksum incorrectly.
o Updated driver version to 5.0.29
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 4 ++--
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index df4552f..eaa1db9 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -36,8 +36,8 @@
#define _QLCNIC_LINUX_MAJOR 5
#define _QLCNIC_LINUX_MINOR 0
-#define _QLCNIC_LINUX_SUBVERSION 28
-#define QLCNIC_LINUX_VERSIONID "5.0.28"
+#define _QLCNIC_LINUX_SUBVERSION 29
+#define QLCNIC_LINUX_VERSIONID "5.0.29"
#define QLCNIC_DRV_IDC_VER 0x01
#define QLCNIC_DRIVER_VERSION ((_QLCNIC_LINUX_MAJOR << 16) |\
(_QLCNIC_LINUX_MINOR << 8) | (_QLCNIC_LINUX_SUBVERSION))
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 707b5ca..33c3e46 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -2033,6 +2033,7 @@ qlcnic_tx_pkt(struct qlcnic_adapter *adapter,
vh = (struct vlan_ethhdr *)skb->data;
flags = FLAGS_VLAN_TAGGED;
vlan_tci = vh->h_vlan_TCI;
+ protocol = ntohs(vh->h_vlan_encapsulated_proto);
} else if (vlan_tx_tag_present(skb)) {
flags = FLAGS_VLAN_OOB;
vlan_tci = vlan_tx_tag_get(skb);
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 2/3] qlcnic: fix unsupported CDRP command error message.
From: Anirban Chakraborty @ 2012-06-06 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Jitendra Kalsaria
In-Reply-To: <1339004108-7356-1-git-send-email-anirban.chakraborty@qlogic.com>
From: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Add debug messages for FW CDRP command failure.
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 4 +++
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 34 +++++++++++++++++++---
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 520ff03..df4552f 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -612,7 +612,11 @@ struct qlcnic_recv_context {
#define QLCNIC_CDRP_CMD_GET_MAC_STATS 0x00000037
#define QLCNIC_RCODE_SUCCESS 0
+#define QLCNIC_RCODE_INVALID_ARGS 6
#define QLCNIC_RCODE_NOT_SUPPORTED 9
+#define QLCNIC_RCODE_NOT_PERMITTED 10
+#define QLCNIC_RCODE_NOT_IMPL 15
+#define QLCNIC_RCODE_INVALID 16
#define QLCNIC_RCODE_TIMEOUT 17
#define QLCNIC_DESTROY_CTX_RESET 0
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index cfa174d..b8ead69 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -53,12 +53,39 @@ qlcnic_issue_cmd(struct qlcnic_adapter *adapter, struct qlcnic_cmd_args *cmd)
rsp = qlcnic_poll_rsp(adapter);
if (rsp == QLCNIC_CDRP_RSP_TIMEOUT) {
- dev_err(&pdev->dev, "card response timeout.\n");
+ dev_err(&pdev->dev, "CDRP response timeout.\n");
cmd->rsp.cmd = QLCNIC_RCODE_TIMEOUT;
} else if (rsp == QLCNIC_CDRP_RSP_FAIL) {
cmd->rsp.cmd = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- dev_err(&pdev->dev, "failed card response code:0x%x\n",
+ switch (cmd->rsp.cmd) {
+ case QLCNIC_RCODE_INVALID_ARGS:
+ dev_err(&pdev->dev, "CDRP invalid args: 0x%x.\n",
cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_SUPPORTED:
+ case QLCNIC_RCODE_NOT_IMPL:
+ dev_err(&pdev->dev,
+ "CDRP command not supported: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_NOT_PERMITTED:
+ dev_err(&pdev->dev,
+ "CDRP requested action not permitted: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_INVALID:
+ dev_err(&pdev->dev,
+ "CDRP invalid or unknown cmd received: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ case QLCNIC_RCODE_TIMEOUT:
+ dev_err(&pdev->dev, "CDRP command timeout: 0x%x.\n",
+ cmd->rsp.cmd);
+ break;
+ default:
+ dev_err(&pdev->dev, "CDRP command failed: 0x%x.\n",
+ cmd->rsp.cmd);
+ }
} else if (rsp == QLCNIC_CDRP_RSP_OK) {
cmd->rsp.cmd = QLCNIC_RCODE_SUCCESS;
if (cmd->rsp.arg2)
@@ -957,9 +984,6 @@ int qlcnic_get_mac_stats(struct qlcnic_adapter *adapter,
mac_stats->mac_rx_jabber = le64_to_cpu(stats->mac_rx_jabber);
mac_stats->mac_rx_dropped = le64_to_cpu(stats->mac_rx_dropped);
mac_stats->mac_rx_crc_error = le64_to_cpu(stats->mac_rx_crc_error);
- } else {
- dev_info(&adapter->pdev->dev,
- "%s: Get mac stats failed =%d.\n", __func__, err);
}
dma_free_coherent(&adapter->pdev->dev, stats_size, stats_addr,
--
1.7.4.1
^ permalink raw reply related
* [PATCH net-next 0/3] qlcnic: Bug fixes
From: Anirban Chakraborty @ 2012-06-06 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept_NX_Linux_NIC_Driver
Please apply.
Thanks,
Anirban
^ permalink raw reply
* Re: [PATCH] macvtap: use set_curren_state to ensure mb
From: David Miller @ 2012-06-06 17:48 UTC (permalink / raw)
To: honkiko; +Cc: eric.dumazet, netdev, arnd, zhiguo.hong, vikifang
In-Reply-To: <CAA7+ByUH8LsSrbetHngEZmaHkvK5aUO5v7-F=+wbveo6q68f-g@mail.gmail.com>
From: Hong zhi guo <honkiko@gmail.com>
Date: Tue, 5 Jun 2012 20:05:34 +0800
> On Tue, Jun 5, 2012 at 7:05 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> Why not using the more standard :
>>
>> prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
>>
>> and
>>
>> finish_wait(sk_sleep(sk), &wait);
>>
>
> Thanks for your comments. The difference is that prepare_to_wait
> inside loop introduces extra "list_empty" judgement than original
> patch. But personally I prefer the newer version too:
>
> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
Please don't submit patches like this:
1) When submitting new versions of a patch, make a fresh
new mailing list posting with just the patch and it's
commit message.
Do not post new versions by replying to other conversations.
2) Your email client has severely corrupted the patch, breaking
up long lines etc. Please read Documentation/email-clients.txt
to learn how to fix this.
^ permalink raw reply
* Re: [PATCH v2] inetpeer: fix a race in inetpeer_gc_worker()
From: David Miller @ 2012-06-06 17:45 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, netdev
In-Reply-To: <20120605130953.GG27795@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 5 Jun 2012 15:09:54 +0200
> On Tue, Jun 05, 2012 at 03:00:18PM +0200, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> commit 5faa5df1fa2024 (inetpeer: Invalidate the inetpeer tree along with
>> the routing cache) added a race :
>>
>> Before freeing an inetpeer, we must respect a RCU grace period, and make
>> sure no user will attempt to increase refcnt.
>>
>> inetpeer_invalidate_tree() waits for a RCU grace period before inserting
>> inetpeer tree into gc_list and waking the worker. At that time, no
>> concurrent lookup can find a inetpeer in this tree.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Cc: Steffen Klassert <steffen.klassert@secunet.com>
>
> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
I'll apply this and queue it up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] inetpeer: add namespace support for inetpeer
From: David Miller @ 2012-06-06 17:43 UTC (permalink / raw)
To: gaofeng
Cc: serge.hallyn, ebiederm, herbert, steffen.klassert, eric.dumazet,
netdev, containers
In-Reply-To: <1338882737-11914-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Tue, 5 Jun 2012 15:52:17 +0800
> now inetpeer doesn't support namespace,the information will
> be leaking across namespace.
>
> this patch move the global vars v4_peers and v6_peers to
> netns_ipv4 and netns_ipv6 as a field peers.
>
> add struct pernet_operations inetpeer_ops to initial pernet
> inetpeer data.
>
> and change family_to_base and inet_getpeer to support namespace.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
As stated yesterday we have to move the inetpeer tree roots into
the FIB rule entries to fix other bugs, and that as a result will
transparently fix this problem too.
So I'm dropping these two patches and will work on the mentioned
approach to this fix.
Thanks.
^ permalink raw reply
* RE: [net-next PATCH v2 1/3] Added kernel support in EEE Ethtool commands
From: Ben Hutchings @ 2012-06-06 17:41 UTC (permalink / raw)
To: Yuval Mintz
Cc: davem@davemloft.net, netdev@vger.kernel.org, Eilon Greenstein,
peppe.cavallaro@st.com
In-Reply-To: <979A8436335E3744ADCD3A9F2A2B68A50268AA@SJEXCHMB10.corp.ad.broadcom.com>
On Wed, 2012-06-06 at 16:40 +0000, Yuval Mintz wrote:
> > > + * @supported: Link speeds for which there is eee support.
> > > + * @advertised: Link speeds the interface advertises (AN) as eee capable.
> > > + * @lp_advertised: Link speeds the link partner advertised as eee capable.
> >
> > And these are bitmasks of SUPPORTED_* & ADVERTISED_* flags, right?
>
> Right.
>
> > Maybe 'link modes' not 'link speeds'?
>
> Not that it matters greatly, but there are SUPPORTED & ADVERTISED flags for
> things other than link speeds, such as connection type and flow control,
> so using exactly the same semantic in description might confuse someone.
What I'm getting at is that we don't have flags for speeds; we have
flags for modes (speed/duplex combination). I think EEE only works with
full-duplex modes but clients and drivers will still have to specify
that explicitly in flag names.
I can see that 'link modes' might be slightly ambiguous, so how about:
@supported: Mask of %SUPPORTED_* flags for the speed/duplex
combinations for which there is EEE support.
and similarly for the other fields.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v9] tilegx network driver: initial support
From: Eric Dumazet @ 2012-06-06 17:40 UTC (permalink / raw)
To: Chris Metcalf; +Cc: bhutchings, arnd, David Miller, linux-kernel, netdev
In-Reply-To: <201206042023.q54KNEZp003834@farm-0002.internal.tilera.com>
On Mon, 2012-06-04 at 16:12 -0400, Chris Metcalf wrote:
> +/* Allocate and push a buffer. */
> +static bool tile_net_provide_buffer(bool small)
> +{
> + int stack = small ? small_buffer_stack : large_buffer_stack;
> + const unsigned long buffer_alignment = 128;
> + struct sk_buff *skb;
> + int len;
> +
> + len = sizeof(struct sk_buff **) + buffer_alignment;
> + len += (small ? 128 : 1664);
1664 is a magic number, it should be a nice define
#define ..... ( ETH_DATA_LEN + .... )
> + skb = dev_alloc_skb(len);
> + if (skb == NULL)
> + return false;
> +
> + /* Make room for a back-pointer to 'skb' and guarantee alignment. */
> + skb_reserve(skb, sizeof(struct sk_buff **));
> + skb_reserve(skb, -(long)skb->data & (buffer_alignment - 1));
> +
> + /* Save a back-pointer to 'skb'. */
> + *(struct sk_buff **)(skb->data - sizeof(struct sk_buff **)) = skb;
> +
> + /* Make sure "skb" and the back-pointer have been flushed. */
> + wmb();
Interesting, have you considered using build_skb() instead of this
convoluted thing ?
This could save some cache misses...
^ permalink raw reply
* Re: [PATCH] net: sierra_net: device IDs for Aircard 320U++
From: David Miller @ 2012-06-06 17:40 UTC (permalink / raw)
To: gregkh
Cc: bjorn, netdev, linux-usb, dcbw, linux, autif.mlist, tomas.cassidy,
stable
In-Reply-To: <20120606121633.GB8535@kroah.com>
From: Greg KH <gregkh@linuxfoundation.org>
Date: Wed, 6 Jun 2012 21:16:33 +0900
> Ok, thanks for clearing that up, I'll take the serial patch, and I'm
> sure that David will take this one.
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I'll apply this, thanks.
Greg, could you not put that TAB at the beginning of your
signoffs? It causes patchwork not to pick them up so I have
to add it manually.
Thanks.
^ permalink raw reply
* Re: [PATCH] Net: mv643xx_eth: Fix compile error for architectures without clk.
From: David Miller @ 2012-06-06 17:38 UTC (permalink / raw)
To: andrew; +Cc: jwboyer, buytenh, olof, netdev, ben
In-Reply-To: <1339000843-26078-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 6 Jun 2012 18:40:43 +0200
> Commit 452503ebc (ARM: Orion: Eth: Add clk/clkdev support.) broke
> the building of the driver on architectures which don't have clk
> support. In particular PPC32 Pegasos which uses this driver.
>
> Add #ifdef around the clk API usage.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fec: Add support for Coldfire M5441x enet-mac.
From: Jan Ceuleers @ 2012-06-06 17:34 UTC (permalink / raw)
To: Steven King; +Cc: netdev, uClinux development list, Greg Ungerer
In-Reply-To: <201206061006.21288.sfking@fdwdc.com>
On 06/06/2012 07:06 PM, Steven King wrote:
> Add support for the Freescale Coldfire M5441x; as these parts have an
> enet-mac, add a quirk to distinguish them from the other Coldfire parts so we
> can use the existing enet-mac support.
Stephen,
You are activating certain functionality based on whether M5441x is
defined. But where is this being defined? Should this not be added in a
Kconfig somewhere as a platform option?
Thanks, Jan
^ permalink raw reply
* Re: [PATCH v9] tilegx network driver: initial support
From: Eric Dumazet @ 2012-06-06 17:31 UTC (permalink / raw)
To: Chris Metcalf; +Cc: bhutchings, arnd, David Miller, linux-kernel, netdev
In-Reply-To: <201206042023.q54KNEZp003834@farm-0002.internal.tilera.com>
On Mon, 2012-06-04 at 16:12 -0400, Chris Metcalf wrote:
> This change adds support for the tilegx network driver based on the
> GXIO IORPC support in the tilegx software stack, using the on-chip
> mPIPE packet processing engine.
> +static void tile_net_setup(struct net_device *dev)
> +{
> + ether_setup(dev);
> + dev->netdev_ops = &tile_net_ops;
> + dev->watchdog_timeo = TILE_NET_TIMEOUT;
> + dev->features |= NETIF_F_LLTX;
> + dev->features |= NETIF_F_HW_CSUM;
> + dev->features |= NETIF_F_SG;
> + dev->features |= NETIF_F_TSO;
> + dev->tx_queue_len = 0;
> + dev->mtu = 1500;
> +}
Why is tx_queue_len set to 0 ?
^ permalink raw reply
* [PATCH] sparc bpf_jit: support BPF_S_ANC_ALU_XOR_X instruction
From: David Miller @ 2012-06-06 17:31 UTC (permalink / raw)
To: netdev; +Cc: sparclinux
Signed-off-by: David S. Miller <davem@davemloft.net>
---
Committed to net-next
arch/sparc/net/bpf_jit_comp.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/sparc/net/bpf_jit_comp.c b/arch/sparc/net/bpf_jit_comp.c
index 1a69244..e9073e9 100644
--- a/arch/sparc/net/bpf_jit_comp.c
+++ b/arch/sparc/net/bpf_jit_comp.c
@@ -96,6 +96,7 @@ static void bpf_flush_icache(void *start_, void *end_)
#define AND F3(2, 0x01)
#define ANDCC F3(2, 0x11)
#define OR F3(2, 0x02)
+#define XOR F3(2, 0x03)
#define SUB F3(2, 0x04)
#define SUBCC F3(2, 0x14)
#define MUL F3(2, 0x0a) /* umul */
@@ -462,6 +463,9 @@ void bpf_jit_compile(struct sk_filter *fp)
case BPF_S_ALU_OR_K: /* A |= K */
emit_alu_K(OR, K);
break;
+ case BPF_S_ANC_ALU_XOR_X: /* A ^= X; */
+ emit_alu_X(XOR);
+ break;
case BPF_S_ALU_LSH_X: /* A <<= X */
emit_alu_X(SLL);
break;
--
1.7.6.5
^ permalink raw reply related
* sky2: BUG_ON(sky2->hw->flags & SKY2_HW_NEW_LE) in sky2_rx_checksum triggers
From: Kirill Smelkov @ 2012-06-06 17:20 UTC (permalink / raw)
To: Mirko Lindner, Stephen Hemminger; +Cc: netdev
Hello up there,
I was playing with `ethtool -K rx on|off` on today's net-next (cbfc6071)
and got BUG_ON in sky2_rx_checksum. Steps to reproduce:
# (cable connected to net)
$ ethtool -K eth0 rx off
$ ethtool -K eth0 rx on
then it bugs:
------------[ cut here ]------------
kernel BUG at drivers/net/ethernet/marvell/sky2.c:2684!
invalid opcode: 0000 [#1] PREEMPT SMP
Modules linked in: sky2
Pid: 0, comm: swapper/1 Not tainted 3.5.0-rc1-netmini+ #75 Hewlett-Packard HP Mini 5103/1608
EIP: 0060:[<efe7a18f>] EFLAGS: 00010202 CPU: 1
EIP is at sky2_poll+0x725/0x8cc [sky2]
EAX: ed52e540 EBX: edfd6800 ECX: 00040000 EDX: 00041004
ESI: 631e631e EDI: 000000e6 EBP: 00000400 ESP: edc7ff1c
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 8005003b CR2: a76110c4 CR3: 01545000 CR4: 000007d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process swapper/1 (pid: 0, ti=edc7e000 task=edc614a0 task.ti=edc74000)
Stack:
edc02400 ed51c080 edc7ff7c b1340f90 8020001f ed51c700 8020001e edc7ff6c
ed52e540 ed51de00 001e006c ed6cbd40 00000000 00000046 edfd6bc0 00000000
ed52e548 000007ad 00000040 00000040 00000282 ed51c700 edc02400 b14b8200
Call Trace:
[<b1340f90>] ? __slab_free.isra.49+0xac/0x157
[<b10256b7>] ? rcu_read_unlock_sched_notrace+0x19/0x19
[<b12e3add>] ? net_rx_action+0x8f/0x182
[<b10256b7>] ? rcu_read_unlock_sched_notrace+0x19/0x19
[<b1025747>] ? __do_softirq+0x90/0x165
[<b10256b7>] ? rcu_read_unlock_sched_notrace+0x19/0x19
<IRQ>
[<b10259c3>] ? irq_exit+0x32/0x8a
[<b10034f8>] ? do_IRQ+0x74/0x89
[<b104d1e7>] ? tick_program_event+0x1f/0x22
[<b1349ce9>] ? common_interrupt+0x29/0x30
[<b102007b>] ? do_oops_enter_exit.part.3+0x8d/0xac
[<b1184327>] ? intel_idle+0xc6/0xe9
[<b12a8e7a>] ? cpuidle_enter+0xb/0xe
[<b12a92d0>] ? cpuidle_idle_call+0xb5/0x167
[<b10075fc>] ? cpu_idle+0x43/0x7b
Code: ff e9 19 01 00 00 0f b7 d5 8b 44 24 38 e8 f4 b7 ff ff f6 83 8f 00 00 00
20 0f 84 00 01 00 00 8b 83 c0 03 00 00 f6 40 44 20 74 02 <0f> 0b 89 f2 c1 ea 10
66 39 f2 75 29 0f b7 83 5c 04 00 00 c1 e0
EIP: [<efe7a18f>] sky2_poll+0x725/0x8cc [sky2] SS:ESP 0068:edc7ff1c
Kernel panic - not syncing: Fatal exception in interrupt
panic occured, switching back to text console
---- 8< ----
(not sure I've ocr'ed it correctly. If in doubt, there is this bug
screenshot here:
https://github.com/navytux/navytux.github.com/raw/master/~kirr/misc/sky2_rx_checksum_BUGON_hwflags.jpg)
My hardware is
02:00.0 0200: 11ab:4381 (rev 11)
i.e.
02:00.0 Ethernet controller: Marvell Technology Group Ltd. Yukon
Optima 88E8059 [PCIe Gigabit Ethernet Controller with AVB] (rev 11)
and dmesg when sky2 driver loads:
[ 8.090421] sky2: driver version 1.30
[ 8.094079] sky2 0000:02:00.0: Yukon-2 Optima chip revision 1
[ 8.098148] sky2 0000:02:00.0: irq 43 for MSI/MSI-X
[ 8.099524] sky2 0000:02:00.0: eth0: addr 1c:c1:de:ae:73:8a
[ 18.134971] sky2 0000:02:00.0: eth0: enabling interface
[ 75.544140] sky2 0000:02:00.0: eth0: Link is up at 1000 Mbps, full duplex, flow control rx
Thanks beforehand,
Kirill
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: David Miller @ 2012-06-06 17:26 UTC (permalink / raw)
To: eric.dumazet
Cc: jesse.brandeburg, shimoda.hiroaki, therbert, denys, netdev,
e1000-devel, jeffrey.t.kirsher
In-Reply-To: <1339002304.26966.16.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Jun 2012 19:05:04 +0200
> You cant hold a TX completion indefinitely, this breaks BQL but also
> other stuff.
True.
^ permalink raw reply
* RE: [PATCH 1/2] Ethtool: Add EEE support
From: Ben Hutchings @ 2012-06-06 17:21 UTC (permalink / raw)
To: Yuval Mintz
Cc: netdev@vger.kernel.org, Eilon Greenstein, peppe.cavallaro@st.com
In-Reply-To: <979A8436335E3744ADCD3A9F2A2B68A502687E@SJEXCHMB10.corp.ad.broadcom.com>
On Wed, 2012-06-06 at 16:27 +0000, Yuval Mintz wrote:
> Hi Ben,
>
> I stand corrected; I'll supply a new version shortly.
>
> I've got 2 questions though:
>
> > For now, use int for booleans. At some point I would like to see a
> > thorough cleanup of ethtool to use bool where appropriate - but that's
> > independent of this
>
> I've noticed that the 'do_generic_set' function assumes all fields are ints.
Yes, but that can and should be fixed.
> Is this a convention we should stick to (using __u32 in the ethtool structs)?
Yes. It is generally preferable to use explicitly fixed-size types in
kernel-userland ABI, even though I wouldn't expect the size of int to
change for many decades to come.
> I'm asking because I'm "wasting" fields in the ethtool_eee struct as I use
> __u32 for boolean fields, simply because what seems to be the conventional
> method won't work with smaller fields (corrupts the following fields).
It's slightly wasteful but not worth worrying about.
> The seconds question - is there a dependency between your acceptance of
> this patch series and Dave's acceptance of the kernel's ethtool modification?
> I'm asking because changes in the ethtool header there should be applied in
> this patch series as well (in ethtool-copy.h).
There is a dependency, yes. However I generally update ethtool-copy.h
as a separate commit myself (as you can see in the git commit log for
it) so I won't demand that you refresh the version in your patch.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Hiroaki SHIMODA @ 2012-06-06 17:19 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Eric Dumazet, Tom Herbert, Denys Fedoryshchenko, netdev,
e1000-devel, jeffrey.t.kirsher, davem
In-Reply-To: <20120606092635.00003b61@unknown>
On Wed, 6 Jun 2012 09:26:35 -0700
Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> On Wed, 6 Jun 2012 Hiroaki SHIMODA <shimoda.hiroaki@gmail.com> wrote:
> > Sorry for long delay. I'll post.
> > (I have no idea how to fix this problem as keeping TXDCTL.WTHRESH to 5)
>
> I don't like changing WTHRESH wholesale because making the global change
> to WTHRESH on e1000e just to fix this one bug (likely specific to a
> particular chip/hardware) will adversely effect performance on many
> models supported by e1000e not demonstrating any problem. We could
> possibly check something in for just ESB2LAN (S5000 chipset).
>
> Other people (tom herbert) with this same chipset have been unable to
> reproduce this issue right?
I understand your performance concern.
The affected chip would be e1000_82571, e1000_82572, e1000_82574
and e1000_80003es2lan which have FLAG2_DMA_BURST bit in
adapter->flags2.
Anyway, I have no objection intel guys NACK to my patch and
provide right fix. But in that case please consider 82574L chip too
which I observed similar behaviour.
Thanks.
^ permalink raw reply
* Re: [patch] net/ethernet: ks8851_mll unregister_netdev() before freeing
From: Raffaele Recalcati @ 2012-06-06 17:03 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, netdev, kernel-janitors
In-Reply-To: <20120606063129.GA26829@elgon.mountain>
On 09:31 Wed 06 Jun , Dan Carpenter wrote:
> We added another error condition here, but if we were to hit it then
> we need to unregister_netdev() before doing the free_netdev().
> Otherwise we would hit the BUG_ON() in free_netdev():
>
> BUG_ON(dev->reg_state != NETREG_UNREGISTERED);
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> Static checker stuff. I don't have this hardware.
>
> diff --git a/drivers/net/ethernet/micrel/ks8851_mll.c b/drivers/net/ethernet/micrel/ks8851_mll.c
> index 70bd329..875dd5e 100644
> --- a/drivers/net/ethernet/micrel/ks8851_mll.c
> +++ b/drivers/net/ethernet/micrel/ks8851_mll.c
> @@ -1606,7 +1606,7 @@ static int __devinit ks8851_probe(struct platform_device *pdev)
> if (!pdata) {
> netdev_err(netdev, "No platform data\n");
> err = -ENODEV;
> - goto err_register;
> + goto err_pdata;
> }
> memcpy(ks->mac_addr, pdata->mac_addr, 6);
> if (!is_valid_ether_addr(ks->mac_addr)) {
> @@ -1626,6 +1626,8 @@ static int __devinit ks8851_probe(struct platform_device *pdev)
> (id >> 8) & 0xff, (id >> 4) & 0xf, (id >> 1) & 0x7);
> return 0;
>
> +err_pdata:
> + unregister_netdev(netdev);
> err_register:
> err_get_irq:
> iounmap(ks->hw_addr_cmd);
Tested-by: Raffaele Recalcati <raffaele.recalcati@bticino.it>
[ 2.274993] ks8851_mll ks8851_mll: (unregistered net_device): message enable is 0
[ 2.282897] ks8851_mll ks8851_mll: (unregistered net_device): the selftest passes
[ 2.302246] ks8851_mll ks8851_mll: eth0: No platform data
^ permalink raw reply
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: Eric Dumazet @ 2012-06-06 17:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, netdev, rusty, linux-kernel, virtualization,
Stephen Hemminger
In-Reply-To: <20120606161715.GA17575@redhat.com>
On Wed, 2012-06-06 at 19:17 +0300, Michael S. Tsirkin wrote:
> But why do you say at most 1 packet?
>
> Consider get_stats doing:
> u64_stats_update_begin(&stats->syncp);
> stats->tx_bytes += skb->len;
>
> on 64 bit at this point
> tx_packets might get incremented any number of times, no?
>
> stats->tx_packets++;
> u64_stats_update_end(&stats->syncp);
>
> now tx_bytes and tx_packets are out of sync by more than 1.
You lost me there.
No idea of what you are thinking about.
There is no atomicity guarantee in SNMP counters. (Ie fetching tx_bytes
and tx_packets in a transaction is not mandatory in any RFC)
As long as there is no cumulative error, its OK.
^ permalink raw reply
* [PATCH net-next] fec: Add support for Coldfire M5441x enet-mac.
From: Steven King @ 2012-06-06 17:06 UTC (permalink / raw)
To: netdev; +Cc: uClinux development list, Greg Ungerer
Add support for the Freescale Coldfire M5441x; as these parts have an
enet-mac, add a quirk to distinguish them from the other Coldfire parts so we
can use the existing enet-mac support.
Signed-off-by: Steven king <sfking@fdwdc.com>
---
drivers/net/ethernet/freescale/Kconfig | 5 ++---
drivers/net/ethernet/freescale/fec.c | 6 +++++-
drivers/net/ethernet/freescale/fec.h | 3 ++-
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 3574e14..f9aa244 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -7,7 +7,7 @@ config NET_VENDOR_FREESCALE
default y
depends on FSL_SOC || QUICC_ENGINE || CPM1 || CPM2 || PPC_MPC512x || \
M523x || M527x || M5272 || M528x || M520x || M532x || \
- ARCH_MXC || ARCH_MXS || (PPC_MPC52xx && PPC_BESTCOMM)
+ M5441x || ARCH_MXC || ARCH_MXS || (PPC_MPC52xx && PPC_BESTCOMM)
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -22,8 +22,7 @@ if NET_VENDOR_FREESCALE
config FEC
tristate "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
- depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
- ARCH_MXC || SOC_IMX28)
+ depends on (M523x || M527x || M5272 || M528x || M520x || M532x || M5441x || ARCH_MXC || SOC_IMX28)
default ARCH_MXC || SOC_IMX28 if ARM
select PHYLIB
---help---
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index ff7f4c5..9567667 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -94,6 +94,9 @@ static struct platform_device_id fec_devtype[] = {
.name = "imx6q-fec",
.driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT,
}, {
+ .name = "enet-fec",
+ .driver_data = FEC_QUIRK_ENET_MAC,
+ }, {
/* sentinel */
}
};
@@ -187,7 +190,8 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
* account when setting it.
*/
#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
- defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM)
+ defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
+ defined(CONFIG_M5441x)
#define OPT_FRAME_SIZE (PKT_MAXBUF_SIZE << 16)
#else
#define OPT_FRAME_SIZE 0
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 8408c62..298cfb7 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -15,7 +15,8 @@
#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
defined(CONFIG_M520x) || defined(CONFIG_M532x) || \
- defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28)
+ defined(CONFIG_ARCH_MXC) || defined(CONFIG_SOC_IMX28) || \
+ defined(CONFIG_M5441x)
/*
* Just figures, Motorola would have to change the offsets for
* registers in the same peripheral device on different models
^ permalink raw reply related
* Re: Strange latency spikes/TX network stalls on Sun Fire X4150(x86) and e1000e
From: Eric Dumazet @ 2012-06-06 17:05 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Hiroaki SHIMODA, Tom Herbert, Denys Fedoryshchenko, netdev,
e1000-devel, jeffrey.t.kirsher, davem
In-Reply-To: <20120606092635.00003b61@unknown>
On Wed, 2012-06-06 at 09:26 -0700, Jesse Brandeburg wrote:
> On Wed, 6 Jun 2012 Hiroaki SHIMODA <shimoda.hiroaki@gmail.com> wrote:
> > Sorry for long delay. I'll post.
> > (I have no idea how to fix this problem as keeping TXDCTL.WTHRESH to 5)
>
> I don't like changing WTHRESH wholesale because making the global change
> to WTHRESH on e1000e just to fix this one bug (likely specific to a
> particular chip/hardware) will adversely effect performance on many
> models supported by e1000e not demonstrating any problem. We could
> possibly check something in for just ESB2LAN (S5000 chipset).
>
> Other people (tom herbert) with this same chipset have been unable to
> reproduce this issue right?
Thats because Tom Herbert (and me on my T420s laptop)
dont have FLAG2_DMA_BURST in adapter->flags2
So it depends on some e1000e, not all...
You cant hold a TX completion indefinitely, this breaks BQL but also
other stuff.
^ permalink raw reply
* Re: Possible deadlock in ipv6?
From: Eric Dumazet @ 2012-06-06 17:02 UTC (permalink / raw)
To: Vladimir Davydov; +Cc: netdev@vger.kernel.org
In-Reply-To: <D0983DA9-2545-4007-8A69-31DDCB9B7CCF@parallels.com>
On Wed, 2012-06-06 at 20:01 +0400, Vladimir Davydov wrote:
> On Jun 6, 2012, at 7:58 PM, Eric Dumazet wrote:
>
> > On Wed, 2012-06-06 at 17:53 +0200, Eric Dumazet wrote:
> >> On Wed, 2012-06-06 at 18:49 +0400, Vladimir Davydov wrote:
> >>> I'm not familiar with the linux net subsystem, so I would appreciate if
> >>> someone could clarify if the following call chain is possible:
> >>>
> >>> addrconf_ifdown() calls neigh_ifdown(nd_tbl) which locks nd_tbl.lock for
> >>> writing and calls
> >>>
> >>> pneigh_ifdown
> >>> pndisc_destructor
> >>> ipv6_dev_mc_dec
> >>> __ipv6_dev_mc_dec
> >>> igmp6_group_dropped
> >>> igmp6_leave_group
> >>> igmp6_send
> >>> icmp6_dst_alloc
> >>> ip6_neigh_lookup
> >>> neigh_create
> >>>
> >>> and neigh_create() locks nd_tbl.lock for writing again resulting in a
> >>> deadlock.
> >>
> >> It seems a deadlock is possible indeed, good catch !
> >>
> >>
> >
> > And it seems this neigh_down() can be removed, its called later
> > (after dev->ip6_ptr is cleared)
> >
>
> BTW, commit d1ed113f1669390da9898da3beddcc058d938587 did exactly the same, but it was reverted along with a bundle of other commits by 73a8bd74e2618990dbb218c3d82f53e60acd9af0.
Yes, but the revert was a 'revert a serie', while this particular patch
seems fine, especially if fixing a deadlock ;)
^ permalink raw reply
* Re: [PATCH] virtio-net: fix a race on 32bit arches
From: Michael S. Tsirkin @ 2012-06-06 16:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-kernel, virtualization, Stephen Hemminger
In-Reply-To: <1338995944.26966.6.camel@edumazet-glaptop>
On Wed, Jun 06, 2012 at 05:19:04PM +0200, Eric Dumazet wrote:
> On Wed, 2012-06-06 at 17:49 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 06, 2012 at 03:10:10PM +0200, Eric Dumazet wrote:
> > > On Wed, 2012-06-06 at 14:13 +0300, Michael S. Tsirkin wrote:
> > >
> > > > We currently do all stats either on napi callback or from
> > > > start_xmit callback.
> > > > This makes them safe, yes?
> > >
> > > Hmm, then _bh() variant is needed in virtnet_stats(), as explained in
> > > include/linux/u64_stats_sync.h section 6)
> > >
> > > * 6) If counter might be written by an interrupt, readers should block interrupts.
> > > * (On UP, there is no seqcount_t protection, a reader allowing interrupts could
> > > * read partial values)
> > >
> > > Yes, its tricky...
> >
> > Sounds good, but I have a question: this realies on counters
> > being atomic on 64 bit.
> > Would not it be better to always use a seqlock even on 64 bit?
> > This way counters would actually be correct and in sync.
> > As it is if we want e.g. average packet size,
> > we can not rely e.g. on it being bytes/packets.
>
> When this stuff was discussed, we chose to have a nop on 64bits.
>
> Your point has little to do with 64bit stats, it was already like that
> with 'long int' counters.
>
> Consider average driver doing :
>
> dev->stats.rx_bytes += skb->len;
> dev->stats.rx_packets++;
>
> A concurrent reader can read an updated rx_bytes and a 'previous'
> rx_packets one.
>
> 'fixing' this requires a lot of work and memory barriers (in all
> drivers), for a very litle gain (at most one packet error)
>
> u64_stats_sync was really meant to be 0-cost on 64bit arches.
>
So for virtio since all counters get incremented from bh we can
ensure they are read atomically, simply but reading them
from the correct CPU with bh disabled.
And then we don't need u64_stats_sync at all.
--
MST
^ permalink raw reply
* Re: [PATCH net-next] x86 bpf_jit: support BPF_S_ANC_ALU_XOR_X instruction
From: David Miller @ 2012-06-06 16:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jpirko, mgherzan, matt
In-Reply-To: <1338881190.2760.1992.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Jun 2012 09:26:30 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> commit ffe06c17afbb (filter: add XOR operation) added generic support
> for XOR operation.
>
> This patch implements the XOR instruction in x86 jit.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Jiri Pirko <jpirko@redhat.com>
Applied, thanks Eric. I'll take care of Sparc.
ARM and POWERPC folks, this is just a reminder for you guys
to do this too. Adding support for XOR to your JITs ought to
be quite trivial.
Thanks.
^ permalink raw reply
* Re: [PATCH v9] tilegx network driver: initial support
From: David Miller @ 2012-06-06 16:41 UTC (permalink / raw)
To: cmetcalf; +Cc: bhutchings, arnd, linux-kernel, netdev
In-Reply-To: <201206042023.q54KNEZp003834@farm-0002.internal.tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Mon, 4 Jun 2012 16:12:03 -0400
> This change adds support for the tilegx network driver based on the
> GXIO IORPC support in the tilegx software stack, using the on-chip
> mPIPE packet processing engine.
>
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> ---
> This change fixes some bugs that were discovered during additional
> testing of the TSO refactoring. In addition, I added a comment
> explaining why we provide TSO support as essentially driver-side GSO.
>
> The previous v8 version of the patch (from 10 days ago) received no
> feedback; if anyone would care to provide feedback on this version of
> the driver, it would be much appreciated. Thanks!
Someone other than me please review this driver.
^ 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