* Re: [PATCH v2] ssb: Fix Sparse error in main
From: Michael Büsch @ 2014-10-28 17:40 UTC (permalink / raw)
To: Pramod Gurav; +Cc: Pramod Gurav, linux-kernel@vger.kernel.org, netdev
In-Reply-To: <CAMf-jSk4GH=8+Cpk4dCzUhbwoKxMOsJPPrURP5-ktAvqXfhsjw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
On Tue, 28 Oct 2014 22:03:02 +0530
Pramod Gurav <pramod.gurav.etc@gmail.com> wrote:
> Michael had suggested to do away with this function if not being used.
> Good to go?
>
> Michale can you provide acked-by?
Yes, this looks good.
Acked-by: Michael Büsch <m@bues.ch>
> On Wed, Oct 1, 2014 at 10:58 PM, Pramod Gurav
> <pramod.gurav@smartplayin.com> wrote:
> > This change fixes below sparse error:
> > drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
> > was not declared. Should it be static?
> >
> > Cc: Michael Buesch <m@bues.ch>
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
> > ---
> > Changes since v1:
> > Removed the function as it is not called anywhere in the kernel
> > as per suggestion from Michael Buesch.
> >
> > drivers/ssb/main.c | 19 -------------------
> > 1 file changed, 19 deletions(-)
> >
> > diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> > index 2fead38..1e180c4 100644
> > --- a/drivers/ssb/main.c
> > +++ b/drivers/ssb/main.c
> > @@ -90,25 +90,6 @@ found:
> > }
> > #endif /* CONFIG_SSB_PCMCIAHOST */
> >
> > -#ifdef CONFIG_SSB_SDIOHOST
> > -struct ssb_bus *ssb_sdio_func_to_bus(struct sdio_func *func)
> > -{
> > - struct ssb_bus *bus;
> > -
> > - ssb_buses_lock();
> > - list_for_each_entry(bus, &buses, list) {
> > - if (bus->bustype == SSB_BUSTYPE_SDIO &&
> > - bus->host_sdio == func)
> > - goto found;
> > - }
> > - bus = NULL;
> > -found:
> > - ssb_buses_unlock();
> > -
> > - return bus;
> > -}
> > -#endif /* CONFIG_SSB_SDIOHOST */
> > -
> > int ssb_for_each_bus_call(unsigned long data,
> > int (*func)(struct ssb_bus *bus, unsigned long data))
> > {
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: Reset flow table for flows over unconnected sockets
From: Eric Dumazet @ 2014-10-28 17:38 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx9=xTyqTXrZODi9dyN1H0W51uqvHR4YT3DhFXpdc4FMbw@mail.gmail.com>
On Tue, 2014-10-28 at 08:18 -0700, Tom Herbert wrote:
> UDP tunnels are becoming increasingly common. VXLAN, FOU, GUE, geneve,
> l2tp, esp/UDP, GRE/UDP, nvgre, etc. all rely on steering based on the
> outer header without deep inspection. When the source port is set to
> inner hash RFS works as is and steering is effectively done based
> inner TCP connections. If aRFS supports UDP, then this should just
> work also for UDP tunnels (another instance where we don't need
> protocol specific support in devices for tunneling).
If you really wanted to solve this, you would need to change RFS to be
aware of the tunnel and find L4 information, instead of current
implementation stopping at first UDP layer.
But as get_rps_cpu() / __skb_flow_dissect() have no way to find this,
you instead chose to invalidate RFS and maybe rely on RPS, because it
might help your workload.
Just to be clear : I tested the patch and saw a regression in my tests,
sending as little as one million UDP packets per second on the target.
Not only UDP rx processing was slower, but TCP flows were impacted.
With a table of 65536 slots, each slot was written 16 times per second
in average.
Google kernels have RFS_Hit/FRS_Miss snmp counters to catch this kind of
problems. Maybe I should upstream this part.
^ permalink raw reply
* fec: suspend/resume broken on 3.18-rc2
From: Fabio Estevam @ 2014-10-28 17:18 UTC (permalink / raw)
To: Duan Fugang-B38611, Frank Li
Cc: Russell King, Shawn Guo, netdev@vger.kernel.org
Hi,
I am running 3.18-rc2 on a mx6sx sdb board and noticed that fec
suspend/resume is broken (works fine on 3.17 though):
root@freescale /$ echo enabled > /sys/class/tty/ttymxc0/power/wakeup
root@freescale /$ echo mem > /sys/power/state
[ 12.383292] PM: Syncing filesystems ... done.
[ 12.423555] Freezing user space processes ... (elapsed 0.003 seconds) done.
[ 12.434382] Freezing remaining freezable tasks ... (elapsed 0.003
seconds) done.
[ 12.510232] PM: suspend of devices complete after 58.151 msecs
[ 12.516258] PM: suspend devices took 0.080 seconds
[ 12.530579] PM: late suspend of devices complete after 9.454 msecs
[ 12.546818] PM: noirq suspend of devices complete after 9.806 msecs
[ 12.553328] Disabling non-boot CPUs ...
[ 12.568077] PM: noirq resume of devices complete after 9.212 msecs
[ 12.582440] PM: early resume of devices complete after 6.426 msecs
[ 12.593831] fec 2188000.ethernet eth0: rcv is not +last
[ 12.599237] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[ 12.607438] pgd = 80004000
[ 12.610187] [00000000] *pgd=00000000
[ 12.613834] Internal error: Oops: 17 [#1] SMP ARM
[ 12.618583] Modules linked in:
[ 12.621706] CPU: 0 PID: 2 Comm: kthreadd Not tainted
3.18.0-rc2-00043-gf7e87a4-dirty #178
[ 12.629943] task: be0789c0 ti: be088000 task.ti: be088000
[ 12.635398] PC is at memcpy+0x80/0x330
[ 12.639197] LR is at gro_pull_from_frag0+0x34/0xa8
[ 12.644034] pc : [<802a6b60>] lr : [<80539b8c>] psr: 00000153
[ 12.644034] sp : be089b34 ip : 00000010 fp : be089b6c
[ 12.655577] r10: 00000000 r9 : 0000000e r8 : 8094d9c0
[ 12.660842] r7 : 8094d9c0 r6 : 00000012 r5 : bd9e5040 r4 : bd89d9c0
[ 12.667412] r3 : 00000804 r2 : fffffff2 r1 : 00000000 r0 : bd9e483c
[ 12.673987] Flags: nzcv IRQs on FIQs off Mode SVC_32 ISA ARM
Segment kernel
[ 12.681432] Control: 10c5387d Table: bd99804a DAC: 00000015
[ 12.687228] Process kthreadd (pid: 2, stack limit = 0xbe088240)
[ 12.693197] Stack: (0xbe089b34 to 0xbe08a000)
[ 12.697601] 9b20:
bd9e5040 00000012 8094d9c0
[ 12.705850] 9b40: 8094d9c0 bd9e483c bd89d9c0 80539b8c 00000000
bd89d9c0 be338710 00000003
[ 12.714097] 9b60: be089bc4 be089b70 8053b0f4 80539b64 00000000
00000000 8053b1b4 811a0f80
[ 12.722344] 9b80: 000007c1 befa4c80 be338000 00000002 be089bcc
8094d9c0 00000000 bd89d9c0
[ 12.730588] 9ba0: be338710 00000000 bf084000 bd89d9c0 be338000
00000001 be089bdc be089bc8
[ 12.738833] 9bc0: 8053b8e0 8053b08c bf084000 00000080 be089c5c
be089be0 80414f14 8053b8c4
[ 12.747077] 9be0: 00000000 00000000 be338710 be338600 00000040
be338694 00000000 00000000
[ 12.755320] 9c00: 80984c74 bd0c0900 00000000 00000000 00000000
be33a000 be33807c be338074
[ 12.763565] 9c20: 00000040 00000001 80060d50 80060c18 0000012c
0000012c be7c41c0 80946100
[ 12.771810] 9c40: be7c41c8 00000040 00000003 be338710 be089c94
be089c60 8053b628 80414ad8
[ 12.780053] 9c60: 80060d50 ffff8fbc 00000008 00000000 8094608c
be088000 00000003 00000100
[ 12.788297] 9c80: 00000003 80946080 be089cdc be089c98 8002d008
8053b568 be089cbc be089ca8
[ 12.796542] 9ca0: 00000001 00208040 ffff8fbb 0000000a be089cdc
be088000 8094cd78 80940e6c
[ 12.804786] 9cc0: be088000 00000000 be00a400 00000001 be089cf4
be089ce0 8002d448 8002cef4
[ 12.813032] 9ce0: 00000180 00000000 be089d24 be089cf8 80069e40
8002d3a4 be089d50 c080e10c
[ 12.821277] 9d00: 00000086 be089d50 8094cef0 c080e100 bd02e180
00000000 be089d4c be089d28
[ 12.829521] 9d20: 8000875c 80069dd8 be0789c0 800b3f20 80000153
ffffffff be089d84 809aa580
[ 12.837766] 9d40: be089e54 be089d50 80012b64 80008740 00000000
00000001 809a8940 00000000
[ 12.846009] 9d60: 002000d0 809a8940 00000000 00000000 809aa580
bd02e180 00000000 be089e54
[ 12.854254] 9d80: 00200010 be089d98 00080008 800b3f20 80000153
ffffffff 00000000 81157f4c
[ 12.862498] 9da0: be0789c0 8096a990 80ad76a0 0000000c be088000
be7c3b50 be089e5c be089dc8
[ 12.870744] 9dc0: 8005e760 8005dd08 be0789c0 00000000 00000458
802c749c 00000000 be7c3ba8
[ 12.878988] 9de0: 00000002 00000000 00000458 00000000 be089e0c
be089e00 80ad8360 be078e18
[ 12.887232] 9e00: 0000000c 00000000 806a02e8 00000001 00002edb
00000000 be001880 00000010
[ 12.895476] 9e20: be089e64 be089e30 800e78ac 00800711 be088000
be0789c0 00000000 809aa580
[ 12.903722] 9e40: bd02e180 ffffffff be089e64 be089e58 800b48a8
800b3ee8 be089ef4 be089e68
[ 12.911967] 9e60: 80027a50 800b4894 80ad76a0 0000005c be088000
8095c8c0 be089f1c be089e88
[ 12.920210] 9e80: 8005e760 8005dd08 be089ecc be089e98 80047bdc
806a02f8 00000000 00000000
[ 12.928453] 9ea0: 80047b98 00000000 00000000 be3fef80 800433d8
00000000 80add860 be078e18
[ 12.936696] 9ec0: 0000005c 00000000 8069aec0 00800711 be3fef80
00000000 00000000 00000000
[ 12.944942] 9ee0: 00000001 be088000 be089f64 be089ef8 80028f1c
8002798c 00000000 00000000
[ 12.953186] 9f00: 00000001 00000000 00000001 be088000 be089f54
be089f20 8006049c 8005e3b8
[ 12.961429] 9f20: 00000001 00000000 be0789c0 8095c8b0 bd1a5c40
8095c8b0 8095c8d0 be3fef94
[ 12.969677] 9f40: be3fef80 8095c8b0 8095c8d0 00000000 00000001
be088000 be089f7c be089f68
[ 12.977921] 9f60: 8002925c 80028e80 00000000 be3fef94 be089fac
be089f80 80043d24 80029238
[ 12.986165] 9f80: ffffffff 00000000 80043c48 00000000 00000000
00000000 00000000 00000000
[ 12.994411] 9fa0: 00000000 be089fb0 8000ece8 80043c54 00000000
00000000 00000000 00000000
[ 13.002653] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
[ 13.010897] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 beff3ab1 beff3c11
[ 13.019129] Backtrace:
[ 13.021659] [<80539b58>] (gro_pull_from_frag0) from [<8053b0f4>]
(dev_gro_receive+0x74/0x3e8)
[ 13.030245] r6:00000003 r5:be338710 r4:bd89d9c0 r3:00000000
[ 13.036069] [<8053b080>] (dev_gro_receive) from [<8053b8e0>]
(napi_gro_receive+0x28/0xa8)
[ 13.044303] r10:00000001 r9:be338000 r8:bd89d9c0 r7:bf084000
r6:00000000 r5:be338710
[ 13.052314] r4:bd89d9c0
[ 13.054927] [<8053b8b8>] (napi_gro_receive) from [<80414f14>]
(fec_enet_rx_napi+0x448/0xadc)
[ 13.063423] r5:00000080 r4:bf084000
[ 13.067099] [<80414acc>] (fec_enet_rx_napi) from [<8053b628>]
(net_rx_action+0xcc/0x1b4)
[ 13.075246] r10:be338710 r9:00000003 r8:00000040 r7:be7c41c8
r6:80946100 r5:be7c41c0
[ 13.083257] r4:0000012c
[ 13.085865] [<8053b55c>] (net_rx_action) from [<8002d008>]
(__do_softirq+0x120/0x268)
[ 13.093754] r10:80946080 r9:00000003 r8:00000100 r7:00000003
r6:be088000 r5:8094608c
[ 13.101766] r4:00000000
[ 13.104368] [<8002cee8>] (__do_softirq) from [<8002d448>]
(irq_exit+0xb0/0x104)
[ 13.111731] r10:00000001 r9:be00a400 r8:00000000 r7:be088000
r6:80940e6c r5:8094cd78
[ 13.119738] r4:be088000
[ 13.122345] [<8002d398>] (irq_exit) from [<80069e40>]
(__handle_domain_irq+0x74/0xc8)
[ 13.130233] r4:00000000 r3:00000180
[ 13.133907] [<80069dcc>] (__handle_domain_irq) from [<8000875c>]
(gic_handle_irq+0x28/0x68)
[ 13.142317] r10:00000000 r9:bd02e180 r8:c080e100 r7:8094cef0
r6:be089d50 r5:00000086
[ 13.150328] r4:c080e10c r3:be089d50
[ 13.153997] [<80008734>] (gic_handle_irq) from [<80012b64>]
(__irq_svc+0x44/0x5c)
[ 13.161539] Exception stack(0xbe089d50 to 0xbe089d98)
[ 13.166638] 9d40: 00000000
00000001 809a8940 00000000
[ 13.174884] 9d60: 002000d0 809a8940 00000000 00000000 809aa580
bd02e180 00000000 be089e54
[ 13.183126] 9d80: 00200010 be089d98 00080008 800b3f20 80000153 ffffffff
[ 13.189785] r8:809aa580 r7:be089d84 r6:ffffffff r5:80000153
r4:800b3f20 r3:be0789c0
[ 13.197725] [<800b3edc>] (__alloc_pages_nodemask) from [<800b48a8>]
(alloc_kmem_pages_node+0x20/0x28)
[ 13.207008] r10:ffffffff r9:bd02e180 r8:809aa580 r7:00000000
r6:be0789c0 r5:be088000
[ 13.215018] r4:00800711
[ 13.217635] [<800b4888>] (alloc_kmem_pages_node) from [<80027a50>]
(copy_process.part.52+0xd0/0x1440)
[ 13.226938] [<80027980>] (copy_process.part.52) from [<80028f1c>]
(do_fork+0xa8/0x3b8)
[ 13.234913] r10:be088000 r9:00000001 r8:00000000 r7:00000000
r6:00000000 r5:be3fef80
[ 13.242922] r4:00800711
[ 13.245528] [<80028e74>] (do_fork) from [<8002925c>]
(kernel_thread+0x30/0x38)
[ 13.252803] r10:be088000 r9:00000001 r8:00000000 r7:8095c8d0
r6:8095c8b0 r5:be3fef80
[ 13.260813] r4:be3fef94
[ 13.263419] [<8002922c>] (kernel_thread) from [<80043d24>]
(kthreadd+0xdc/0x14c)
[ 13.270889] [<80043c48>] (kthreadd) from [<8000ece8>]
(ret_from_fork+0x14/0x2c)
[ 13.278254] r10:00000000 r9:00000000 r8:00000000 r7:00000000
r6:00000000 r5:80043c48
[ 13.286263] r4:00000000 r3:ffffffff
[ 13.289930] Code: e320f000 e4913004 e4914004 e4915004 (e4916004)
[ 13.296165] ---[ end trace bc69878b7a8d6f78 ]---
[ 13.300839] Kernel panic - not syncing: Fatal exception in interrupt
[ 13.307258] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Haven't started debugging this yet, but just wanted to report in case
this sounds familiar to someone.
Regards,
Fabio Estevam
^ permalink raw reply
* Mistake in commit 0d961b3b52f566f823070ce2366511a7f64b928c breaks cpsw non dual_emac mode.
From: Lennart Sorensen @ 2014-10-28 17:02 UTC (permalink / raw)
To: linux-kernel
Cc: Heiko Schocher, Len Sorensen, Mugunthan V N, David S. Miller,
netdev
I believe commit 0d961b3b52f566f823070ce2366511a7f64b928c made a mistake
while correcting a bug.
It was correct to fix (which applies only in dual_emac mode):
@@ -554,7 +554,7 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
* common for both the interface as the interface shares
* the same hardware resource.
*/
- for (i = 0; i <= priv->data.slaves; i++)
+ for (i = 0; i < priv->data.slaves; i++)
if (priv->slaves[i].ndev->flags & IFF_PROMISC)
flag = true;
since there i is used as an index into priv->slaves which is a 0 based array.
However the other two changes (which are only in non dual_emac mode):
@@ -578,7 +578,7 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
unsigned long timeout = jiffies + HZ;
/* Disable Learn for all ports */
- for (i = 0; i <= priv->data.slaves; i++) {
+ for (i = 0; i < priv->data.slaves; i++) {
cpsw_ale_control_set(ale, i,
ALE_PORT_NOLEARN, 1);
cpsw_ale_control_set(ale, i,
@@ -606,7 +606,7 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
cpsw_ale_control_set(ale, 0, ALE_P0_UNI_FLOOD, 0);
/* Enable Learn for all ports */
- for (i = 0; i <= priv->data.slaves; i++) {
+ for (i = 0; i < priv->data.slaves; i++) {
cpsw_ale_control_set(ale, i,
ALE_PORT_NOLEARN, 0);
cpsw_ale_control_set(ale, i,
are wrong since there i is actually the ALE port number, and port 0 is
the host port, while port 1 and up are the slave ports.
This should correct it back to working in non dual_emac mode.
Also make the comment point this out clearly to avoid future confusion
and fix a comment that was missing a "Don't".
Signed-off-by: lsorense@csclub.uwaterloo.ca
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 952e1e4..4683196 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -591,8 +591,8 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
if (enable) {
unsigned long timeout = jiffies + HZ;
- /* Disable Learn for all ports */
- for (i = 0; i < priv->data.slaves; i++) {
+ /* Disable Learn for all ports (host is port 0 and slaves are port 1 and up */
+ for (i = 0; i <= priv->data.slaves; i++) {
cpsw_ale_control_set(ale, i,
ALE_PORT_NOLEARN, 1);
cpsw_ale_control_set(ale, i,
@@ -616,11 +616,11 @@ static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
cpsw_ale_control_set(ale, 0, ALE_P0_UNI_FLOOD, 1);
dev_dbg(&ndev->dev, "promiscuity enabled\n");
} else {
- /* Flood All Unicast Packets to Host port */
+ /* Don't Flood All Unicast Packets to Host port */
cpsw_ale_control_set(ale, 0, ALE_P0_UNI_FLOOD, 0);
- /* Enable Learn for all ports */
- for (i = 0; i < priv->data.slaves; i++) {
+ /* Enable Learn for all ports (host is port 0 and slaves are port 1 and up */
+ for (i = 0; i <= priv->data.slaves; i++) {
cpsw_ale_control_set(ale, i,
ALE_PORT_NOLEARN, 0);
cpsw_ale_control_set(ale, i,
--
Len Sorensen
^ permalink raw reply related
* [PATCH v3 10/15] dsa: Add new optional devicetree property to describe EEPROM size
From: Guenter Roeck @ 2014-10-28 16:50 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Florian Fainelli, Andrew Lunn, linux-kernel,
devicetree, Ian Campbell, Ku
In-Reply-To: <1414342365-27191-11-git-send-email-linux@roeck-us.net>
The dsa core now supports reading from and writing to a switch EEPROM
if connected. Describe optional devicetree property indicating that
an EEPROM is present and its size.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v3:
- eeprom-length property is attached to switch devicetree node,
not to dsa node.
v2:
- Added patch
Documentation/devicetree/bindings/net/dsa/dsa.txt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.txt b/Documentation/devicetree/bindings/net/dsa/dsa.txt
index a62c889..e124847 100644
--- a/Documentation/devicetree/bindings/net/dsa/dsa.txt
+++ b/Documentation/devicetree/bindings/net/dsa/dsa.txt
@@ -10,7 +10,7 @@ Required properties:
- dsa,ethernet : Should be a phandle to a valid Ethernet device node
- dsa,mii-bus : Should be a phandle to a valid MDIO bus device node
-Optionnal properties:
+Optional properties:
- interrupts : property with a value describing the switch
interrupt number (not supported by the driver)
@@ -23,6 +23,13 @@ Each of these switch child nodes should have the following required properties:
- #address-cells : Must be 1
- #size-cells : Must be 0
+A switch child node has the following optional property:
+
+- eeprom-length : Set to the length of an EEPROM connected to the
+ switch. Must be set if the switch can not detect
+ the presence and/or size of a connected EEPROM,
+ otherwise optional.
+
A switch may have multiple "port" children nodes
Each port children node must have the following mandatory properties:
--
1.9.1
^ permalink raw reply related
* [PATCH v3 09/15] net: dsa: Add support for switch EEPROM access
From: Guenter Roeck @ 2014-10-28 16:49 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Florian Fainelli, Andrew Lunn, linux-kernel
In-Reply-To: <1414342365-27191-10-git-send-email-linux@roeck-us.net>
On some chips it is possible to access the switch eeprom.
Add infrastructure support for it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
v3:
- Fix bug seen if devicetree is enabled; eeprom-length property is
attached to switch devicetree node, not to dsa node.
v2:
- Add support for configuring switch EEPROM size through platform data
or devicetree data
- Do not compare new pointers against NULL
- Check if get_eeprom pointer is set before calling it
include/net/dsa.h | 10 ++++++++++
net/dsa/dsa.c | 4 ++++
net/dsa/slave.c | 41 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 55e75e7..37856a2 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -38,6 +38,9 @@ struct dsa_chip_data {
struct device *host_dev;
int sw_addr;
+ /* set to size of eeprom if supported by the switch */
+ int eeprom_len;
+
/* Device tree node pointer for this specific switch chip
* used during switch setup in case additional properties
* and resources needs to be used
@@ -258,6 +261,13 @@ struct dsa_switch_driver {
int (*set_temp_limit)(struct dsa_switch *ds, int temp);
int (*get_temp_alarm)(struct dsa_switch *ds, bool *alarm);
#endif
+
+ /* EEPROM access */
+ int (*get_eeprom_len)(struct dsa_switch *ds);
+ int (*get_eeprom)(struct dsa_switch *ds,
+ struct ethtool_eeprom *eeprom, u8 *data);
+ int (*set_eeprom)(struct dsa_switch *ds,
+ struct ethtool_eeprom *eeprom, u8 *data);
};
void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 5edbbca..b51ef592 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -575,6 +575,7 @@ static int dsa_of_probe(struct platform_device *pdev)
const char *port_name;
int chip_index, port_index;
const unsigned int *sw_addr, *port_reg;
+ u32 eeprom_len;
int ret;
mdio = of_parse_phandle(np, "dsa,mii-bus", 0);
@@ -626,6 +627,9 @@ static int dsa_of_probe(struct platform_device *pdev)
if (cd->sw_addr > PHY_MAX_ADDR)
continue;
+ if (!of_property_read_u32(np, "eeprom-length", &eeprom_len))
+ cd->eeprom_len = eeprom_len;
+
for_each_available_child_of_node(child, port) {
port_reg = of_get_property(port, "reg", NULL);
if (!port_reg)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 6d18174..ff2fbe7 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -271,6 +271,44 @@ static u32 dsa_slave_get_link(struct net_device *dev)
return -EOPNOTSUPP;
}
+static int dsa_slave_get_eeprom_len(struct net_device *dev)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+
+ if (ds->pd->eeprom_len)
+ return ds->pd->eeprom_len;
+
+ if (ds->drv->get_eeprom_len)
+ return ds->drv->get_eeprom_len(ds);
+
+ return 0;
+}
+
+static int dsa_slave_get_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *data)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+
+ if (ds->drv->get_eeprom)
+ return ds->drv->get_eeprom(ds, eeprom, data);
+
+ return -EOPNOTSUPP;
+}
+
+static int dsa_slave_set_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *data)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_switch *ds = p->parent;
+
+ if (ds->drv->set_eeprom)
+ return ds->drv->set_eeprom(ds, eeprom, data);
+
+ return -EOPNOTSUPP;
+}
+
static void dsa_slave_get_strings(struct net_device *dev,
uint32_t stringset, uint8_t *data)
{
@@ -387,6 +425,9 @@ static const struct ethtool_ops dsa_slave_ethtool_ops = {
.get_drvinfo = dsa_slave_get_drvinfo,
.nway_reset = dsa_slave_nway_reset,
.get_link = dsa_slave_get_link,
+ .get_eeprom_len = dsa_slave_get_eeprom_len,
+ .get_eeprom = dsa_slave_get_eeprom,
+ .set_eeprom = dsa_slave_set_eeprom,
.get_strings = dsa_slave_get_strings,
.get_ethtool_stats = dsa_slave_get_ethtool_stats,
.get_sset_count = dsa_slave_get_sset_count,
--
1.9.1
^ permalink raw reply related
* ipv6 mld: packets are not looped back to/from kernel/querier
From: Pierre Pfister @ 2014-10-28 16:32 UTC (permalink / raw)
To: netdev
Hello,
I’m implementing a dual-stack multicast querier (IGMPv3 and MLDv2) along with the PIM protocol.
So I’ve got two multicast sockets, one for each protocol.
I open the two sockets like this:
——————————————————
fd = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP);
val = 1;
setsockopt(fd, IPPROTO_IP, MRT_INIT, &val, sizeof(val));
setsockopt(fd, IPPROTO_IP, IP_PKTINFO, &val, sizeof(val));
setsockopt(fd, IPPROTO_IP, IP_MULTICAST_TTL, &val, sizeof(val));
val = 0xc0;
setsockopt(fd, IPPROTO_IP, IP_TOS, &val, sizeof(val));
setsockopt(fd, IPPROTO_IP, IP_OPTIONS, &ipv4_rtr_alert, sizeof(ipv4_rtr_alert))
fd = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
val = 1;
setsockopt(fd, IPPROTO_IPV6, MRT6_INIT, &val, sizeof(val));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &val, sizeof(val));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &val, sizeof(val));
setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &val, sizeof(val));
val = 2;
setsockopt(fd, IPPROTO_RAW, IPV6_CHECKSUM, &val, sizeof(val));
setsockopt(fd, IPPROTO_IPV6, IPV6_HOPOPTS, &ipv6_rtr_alert, sizeof(ipv6_rtr_alert));
struct icmp6_filter flt;
ICMP6_FILTER_SETBLOCKALL(&flt);
ICMP6_FILTER_SETPASS(ICMPV6_MGM_QUERY, &flt);
ICMP6_FILTER_SETPASS(ICMPV6_MGM_REPORT, &flt);
ICMP6_FILTER_SETPASS(ICMPV6_MGM_REDUCTION, &flt);
ICMP6_FILTER_SETPASS(ICMPV6_MLD2_REPORT, &flt);
setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &flt, sizeof(flt));
——————————————————————
I’ve got two issues with the IPv6 socket.
When I send an MLD query, it is sent on the wire, but the kernel doesn’t interpret it (It doesn’t send MLD Reports as reply).
Similarly, when the kernel sends a Report, my MLD Querier socket doesn’t receive the message.
The resulting problem is that everything works fine as long as the router doesn’t want to join a group. When it does, my Querier can’t know it, and the kernel doesn’t reply to Querier’s requests.
It works well in IPv4.
I tried removing the ICMPV6 filter as well as using IPV6_MULTICAST_LOOP.
Am I doing something wrong or is it an actual bug ?
If you need more information, please ask.
Thanks,
Pierre
^ permalink raw reply
* Re: [PATCH v2] ssb: Fix Sparse error in main
From: Pramod Gurav @ 2014-10-28 16:33 UTC (permalink / raw)
To: Pramod Gurav; +Cc: linux-kernel@vger.kernel.org, Michael Buesch, netdev
In-Reply-To: <1412184482-2603-1-git-send-email-pramod.gurav@smartplayin.com>
Michael had suggested to do away with this function if not being used.
Good to go?
Michale can you provide acked-by?
On Wed, Oct 1, 2014 at 10:58 PM, Pramod Gurav
<pramod.gurav@smartplayin.com> wrote:
> This change fixes below sparse error:
> drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
> was not declared. Should it be static?
>
> Cc: Michael Buesch <m@bues.ch>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Pramod Gurav <pramod.gurav@smartplayin.com>
> ---
> Changes since v1:
> Removed the function as it is not called anywhere in the kernel
> as per suggestion from Michael Buesch.
>
> drivers/ssb/main.c | 19 -------------------
> 1 file changed, 19 deletions(-)
>
> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> index 2fead38..1e180c4 100644
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -90,25 +90,6 @@ found:
> }
> #endif /* CONFIG_SSB_PCMCIAHOST */
>
> -#ifdef CONFIG_SSB_SDIOHOST
> -struct ssb_bus *ssb_sdio_func_to_bus(struct sdio_func *func)
> -{
> - struct ssb_bus *bus;
> -
> - ssb_buses_lock();
> - list_for_each_entry(bus, &buses, list) {
> - if (bus->bustype == SSB_BUSTYPE_SDIO &&
> - bus->host_sdio == func)
> - goto found;
> - }
> - bus = NULL;
> -found:
> - ssb_buses_unlock();
> -
> - return bus;
> -}
> -#endif /* CONFIG_SSB_SDIOHOST */
> -
> int ssb_for_each_bus_call(unsigned long data,
> int (*func)(struct ssb_bus *bus, unsigned long data))
> {
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Thanks and Regards
Pramod
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Paul E. McKenney @ 2014-10-28 16:15 UTC (permalink / raw)
To: Kevin Fenzi
Cc: Yanko Kaneti, Jay Vosburgh, Josh Boyer, Eric W. Biederman,
Cong Wang, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj
In-Reply-To: <20141028095428.15cadd01@voldemort.scrye.com>
On Tue, Oct 28, 2014 at 09:54:28AM -0600, Kevin Fenzi wrote:
> Just FYI, this solves the orig issue for me as well. ;)
>
> Thanks for all the work in tracking it down...
>
> Tested-by: Kevin Fenzi <kevin@scrye.com>
And thank you for testing as well!
Thanx, Paul
^ permalink raw reply
* Re: localed stuck in recent 3.18 git in copy_net_ns?
From: Kevin Fenzi @ 2014-10-28 15:54 UTC (permalink / raw)
To: Yanko Kaneti
Cc: Paul E. McKenney, Jay Vosburgh, Josh Boyer, Eric W. Biederman,
Cong Wang, netdev, Linux-Kernel@Vger. Kernel. Org, mroos, tj
In-Reply-To: <20141028130002.GA1682@declera.com>
[-- Attachment #1: Type: text/plain, Size: 166 bytes --]
Just FYI, this solves the orig issue for me as well. ;)
Thanks for all the work in tracking it down...
Tested-by: Kevin Fenzi <kevin@scrye.com>
kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/7] seq_printf cleanups
From: Joe Perches @ 2014-10-28 15:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, linux-doc,
linux-kernel, linux-mtd, netdev, cluster-devel, linux-fsdevel,
netfilter-devel, coreteam
In-Reply-To: <20141028113240.74dbe5c5@gandalf.local.home>
On Tue, 2014-10-28 at 11:32 -0400, Steven Rostedt wrote:
> If you haven't already done so, can you update checkpatch.pl to
> complain if someone checks the return value of seq_printf(),
> seq_puts(), or seq_putc().
I'm not sure that matters much as a rule because I
hope soon the compiler will bleat when that happens.
There are several more too:
seq_vprintf
seq_escape
seq_write
seq_bitmap
seq_cpumask/seq_nodemask (and _list variants),
seq_put_decimal_xxx
^ permalink raw reply
* [PATCH] wireless: rt2x00: add new rt2800usb device
From: Cyril Brulebois @ 2014-10-28 15:42 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, John W. Linville
Cc: linux-wireless, users, netdev, linux-kernel, Cyril Brulebois,
stable
0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
References: https://bugs.debian.org/766802
Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Cyril Brulebois <kibi@debian.org>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 573897b..8444313 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1111,6 +1111,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
/* Ovislink */
{ USB_DEVICE(0x1b75, 0x3071) },
{ USB_DEVICE(0x1b75, 0x3072) },
+ { USB_DEVICE(0x1b75, 0xa200) },
/* Para */
{ USB_DEVICE(0x20b8, 0x8888) },
/* Pegatron */
--
1.7.10.4
^ permalink raw reply related
* Re: some failures with vxlan offloads..
From: Tom Herbert @ 2014-10-28 15:36 UTC (permalink / raw)
To: Or Gerlitz; +Cc: netdev@vger.kernel.org, John Fastabend, Jeff Kirsher
In-Reply-To: <544FB5CA.2060003@mellanox.com>
On Tue, Oct 28, 2014 at 8:27 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 10/27/2014 3:23 AM, Tom Herbert wrote:
>>
>> On Sun, Oct 26, 2014 at 3:23 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>>
>>> On Sun, Oct 26, 2014 at 5:29 PM, Tom Herbert <therbert@google.com> wrote:
>>>>
>>>> Can you determine what the TSO HW engine is setting in UDP checksum
>>>> field? tcpdump -vv might be able to show this. The symptoms seem to
>>>> indicate that it may not be zero.
>>>
>>> Thanks for the quick response. I'll check what is placed in the UDP
>>> checksum field for packets that went through the offloading HW and let
>>> you know.
>>>
>>> BTW, if following the direction you proposed, I wonder why this works
>>> (e.g the kernel doesn't drops the encapsulated TCP packets) when both
>>> sides are offloaded?
>>>
>> I'm just speculating, but the device may be returning checksum unnecessary
>> for the UDP checksum without actually checking it. Technically, VXLAN
>> RFC7348 allows an implementation to ignore the UDP checksum, although this
>> clearly violates RFC1122 UDP checksum
>> requirements. In the stack we now checksum all non-zero checksums
>> including UDP checksum in VXLAN if it's not marked checksum-unnecessary.
>
>
> OK, I found something (it's always bad habit to try and potentially blame
> someone else for your bugs...) -- as I wrote here earlier, the current HW
> doesn't support checksum generation for both the inner (say TCP) and outer
> (UDP) packet (and indeed we don't advertize SKB_GSO_UDP_TUNNEL_CSUM).
>
> So if we tell them to offload the inner TCP checksum we must **not** tell
> them to attempt and offload the outer checksum too, and I wrongly did
> that... once I stopped doing so, I get mixed configurations (one side
> offloaded the peer not offloaded) to work. I will submit mlx4 fix for that.
>
> I wonder if we have another bug somewhere... when both sides were offloaded,
> it works even with the mlx4 bug, canyou explain that?is it possible that the
> GRO stack somehow covers on the bug when both sides are offloaded and
> GRO/VXLAN comes into play?
>
Look at the receive side. As I mentioned, if the device is returning
checksum-unnecessary and setting csum_level to 1 (inner checksum was
validated) then stack won't try to verify the outer checksum. So in
this case if outer checksum is incorrect nobody complains about it.
> Or.
>
> after the fix, packets sent by the offloaded side (192.168.31.17) carry zero
> udpchecksum
>
> 17:20:44.445866 IP (tos 0x0, ttl 64, id 61275, offset 0, flags [DF], proto
> UDP (17), length 1500)
> 192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 05dc ef5b 4000 4011 8641 c0a8 1f11 c0a8
> 0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 05aa bb84 4000 4006 9055 c0a8 3411
> 0x0050: c0a8 3412 e479 9116 553a e008 f28e 6268
> 0x0060: 5010 0038 88e3 0000 6600 6e65 7470 6572
> 0x0070: 6600 6e65 7470 6572 6600
> 17:20:44.445871 IP (tos 0x0, ttl 64, id 61276, offset 0, flags [DF], proto
> UDP (17), length 1500)
> 192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 05dc ef5c 4000 4011 8640 c0a8 1f11 c0a8
> 0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 05aa bb85 4000 4006 9054 c0a8 3411
> 0x0050: c0a8 3412 e479 9116 553a e58a f28e 6268
> 0x0060: 5010 0038 7afc 0000 6e65 7470 6572 6600
> 0x0070: 6e65 7470 6572 6600 6e65
>
>
> before the fix, packets sent by the offloaded side (192.168.31.17) carry
> junkudpchecksum
>
> Also note that on one of the packets sent by the offloaded part, we don't
> see the "bad udp cksum" scream from tcpdump, which is weird...
>
> 17:03:08.765845 IP (tos 0x0, ttl 64, id 52396, offset 0, flags [DF], proto
> UDP (17), length 746)
> 192.168.31.17.56686 > 192.168.31.18.4789: UDP, length 718
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 02ea ccac 4000 4011 abe2 c0a8 1f11 c0a8
> 0x0020: 1f12 dd6e 12b5 02d6 0c1b 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 02b8 6357 4000 4006 eb74 c0a8 3411
> 0x0050: c0a8 3412 86f2 3241 d67e f47d e5a9 d041
> 0x0060: 5018 0038 871c 0000 0000 0258 ffff ffff
> 0x0070: 0000 0000 0000 0000 0000
> 17:03:09.336285 IP (tos 0x0, ttl 64, id 52536, offset 0, flags [DF], proto
> UDP (17), length 90)
> 192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!] UDP,
> length 62
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 005a cd38 4000 4011 ade6 c0a8 1f11 c0a8
> 0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 0028 6358 4000 4006 ee03 c0a8 3411
> 0x0050: c0a8 3412 86f2 3241 d67e f70d e5a9 d041
> 0x0060: 5011 0038 897b 0000
> 17:03:10.335074 IP (tos 0x0, ttl 64, id 40045, offset 0, flags [DF], proto
> UDP (17), length 98)
> 192.168.31.18.48861 > 192.168.31.17.4789: [no cksum] UDP, length 70
> 0x0000: 0002 c9e9 bf32 f452 1401 da82 0800 4500
> 0x0010: 0062 9c6d 4000 4011 dea9 c0a8 1f12 c0a8
> 0x0020: 1f11 bedd 12b5 004e 0000 0800 0000 0000
> 0x0030: 6300 7a83 2ecb 8c68 b2c7 81db e850 0800
> 0x0040: 4500 0030 0000 4000 4006 5154 c0a8 3412
> 0x0050: c0a8 3411 3241 86f2 e5a9 d040 d67e f47d
> 0x0060: 7012 6e28 f282 0000 0204 0582 0103 0307
> 17:03:10.335110 IP (tos 0x0, ttl 64, id 52764, offset 0, flags [DF], proto
> UDP (17), length 90)
> 192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!] UDP,
> length 62
> 0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
> 0x0010: 005a ce1c 4000 4011 ad02 c0a8 1f11 c0a8
> 0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
> 0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
> 0x0040: 4500 0028 6359 4000 4006 ee02 c0a8 3411
> 0x0050: c0a8 3412 86f2 3241 d67e f70e e5a9 d041
> 0x0060: 5010 0038 897b 0000
>
>
^ permalink raw reply
* Re: [PATCH 0/7] seq_printf cleanups
From: Steven Rostedt @ 2014-10-28 15:32 UTC (permalink / raw)
To: Joe Perches
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, linux-doc,
linux-kernel, linux-mtd, netdev, cluster-devel, linux-fsdevel,
netfilter-devel, coreteam
In-Reply-To: <cover.1412031505.git.joe@perches.com>
Joe,
If you haven't already done so, can you update checkpatch.pl to
complain if someone checks the return value of seq_printf(),
seq_puts(), or seq_putc().
It should state that those functions will soon be returning void.
Thanks!
-- Steve
^ permalink raw reply
* [PATCH 1/2] xen-netback: Disable NAPI after disabling interrupts
From: David Vrabel @ 2014-10-28 15:29 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu, Zoltan Kiss
In-Reply-To: <1414510171-12853-1-git-send-email-david.vrabel@citrix.com>
From: Zoltan Kiss <zoltan.kiss@linaro.org>
Otherwise the interrupt handler still calls napi_complete. Although it
won't schedule NAPI again as either NAPI_STATE_DISABLE or
NAPI_STATE_SCHED is set, it is just unnecessary, and it makes more
sense to do this way.
Signed-off-by: Zoltan Kiss <zoltan.kiss@linaro.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/net/xen-netback/interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 895fe84..a6a32d3 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -235,10 +235,10 @@ static void xenvif_down(struct xenvif *vif)
for (queue_index = 0; queue_index < num_queues; ++queue_index) {
queue = &vif->queues[queue_index];
- napi_disable(&queue->napi);
disable_irq(queue->tx_irq);
if (queue->tx_irq != queue->rx_irq)
disable_irq(queue->rx_irq);
+ napi_disable(&queue->napi);
del_timer_sync(&queue->credit_timeout);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] xen-netback: Remove __GFP_COLD
From: David Vrabel @ 2014-10-28 15:29 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu, Zoltan Kiss
In-Reply-To: <1414510171-12853-1-git-send-email-david.vrabel@citrix.com>
From: Zoltan Kiss <zoltan.kiss@linaro.org>
This flag is unnecessary, it came from some old code.
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Zoltan Kiss <zoltan.kiss@linaro.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
drivers/net/xen-netback/netback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 25f4c06..730252c 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1550,7 +1550,7 @@ static int xenvif_handle_frag_list(struct xenvif_queue *queue, struct sk_buff *s
unsigned int len;
BUG_ON(i >= MAX_SKB_FRAGS);
- page = alloc_page(GFP_ATOMIC|__GFP_COLD);
+ page = alloc_page(GFP_ATOMIC);
if (!page) {
int j;
skb->truesize += skb->data_len;
--
1.7.10.4
^ permalink raw reply related
* [PATCHv1 0/2 net-next] xen-netback: minor cleanups
From: David Vrabel @ 2014-10-28 15:29 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu
Two minor xen-netback cleanups originally from Zoltan.
David
^ permalink raw reply
* Re: some failures with vxlan offloads..
From: Or Gerlitz @ 2014-10-28 15:27 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev@vger.kernel.org, John Fastabend, Jeff Kirsher
In-Reply-To: <CA+mtBx9g6MYpFv83av1YdRpZRBcBKvsqzSnhs5C7iV+kP8cWDA@mail.gmail.com>
On 10/27/2014 3:23 AM, Tom Herbert wrote:
> On Sun, Oct 26, 2014 at 3:23 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Sun, Oct 26, 2014 at 5:29 PM, Tom Herbert <therbert@google.com> wrote:
>>> Can you determine what the TSO HW engine is setting in UDP checksum
>>> field? tcpdump -vv might be able to show this. The symptoms seem to
>>> indicate that it may not be zero.
>> Thanks for the quick response. I'll check what is placed in the UDP
>> checksum field for packets that went through the offloading HW and let
>> you know.
>>
>> BTW, if following the direction you proposed, I wonder why this works
>> (e.g the kernel doesn't drops the encapsulated TCP packets) when both
>> sides are offloaded?
>>
> I'm just speculating, but the device may be returning checksum unnecessary for the UDP checksum without actually checking it. Technically, VXLAN RFC7348 allows an implementation to ignore the UDP checksum, although this clearly violates RFC1122 UDP checksum
> requirements. In the stack we now checksum all non-zero checksums including UDP checksum in VXLAN if it's not marked checksum-unnecessary.
OK, I found something (it's always bad habit to try and potentially
blame someone else for your bugs...) -- as I wrote here earlier, the
current HW doesn't support checksum generation for both the inner (say
TCP) and outer (UDP) packet (and indeed we don't advertize
SKB_GSO_UDP_TUNNEL_CSUM).
So if we tell them to offload the inner TCP checksum we must **not**
tell them to attempt and offload the outer checksum too, and I wrongly
did that... once I stopped doing so, I get mixed configurations (one
side offloaded the peer not offloaded) to work. I will submit mlx4 fix
for that.
I wonder if we have another bug somewhere... when both sides were
offloaded, it works even with the mlx4 bug, canyou explain that?is it
possible that the GRO stack somehow covers on the bug when both sides
are offloaded and GRO/VXLAN comes into play?
Or.
after the fix, packets sent by the offloaded side (192.168.31.17) carry
zero udpchecksum
17:20:44.445866 IP (tos 0x0, ttl 64, id 61275, offset 0, flags [DF],
proto UDP (17), length 1500)
192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 05dc ef5b 4000 4011 8641 c0a8 1f11 c0a8
0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 05aa bb84 4000 4006 9055 c0a8 3411
0x0050: c0a8 3412 e479 9116 553a e008 f28e 6268
0x0060: 5010 0038 88e3 0000 6600 6e65 7470 6572
0x0070: 6600 6e65 7470 6572 6600
17:20:44.445871 IP (tos 0x0, ttl 64, id 61276, offset 0, flags [DF],
proto UDP (17), length 1500)
192.168.31.17.45387 > 192.168.31.18.4789: [no cksum] UDP, length 1472
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 05dc ef5c 4000 4011 8640 c0a8 1f11 c0a8
0x0020: 1f12 b14b 12b5 05c8 0000 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 05aa bb85 4000 4006 9054 c0a8 3411
0x0050: c0a8 3412 e479 9116 553a e58a f28e 6268
0x0060: 5010 0038 7afc 0000 6e65 7470 6572 6600
0x0070: 6e65 7470 6572 6600 6e65
before the fix, packets sent by the offloaded side (192.168.31.17) carry
junkudpchecksum
Also note that on one of the packets sent by the offloaded part, we
don't see the "bad udp cksum" scream from tcpdump, which is weird...
17:03:08.765845 IP (tos 0x0, ttl 64, id 52396, offset 0, flags [DF],
proto UDP (17), length 746)
192.168.31.17.56686 > 192.168.31.18.4789: UDP, length 718
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 02ea ccac 4000 4011 abe2 c0a8 1f11 c0a8
0x0020: 1f12 dd6e 12b5 02d6 0c1b 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 02b8 6357 4000 4006 eb74 c0a8 3411
0x0050: c0a8 3412 86f2 3241 d67e f47d e5a9 d041
0x0060: 5018 0038 871c 0000 0000 0258 ffff ffff
0x0070: 0000 0000 0000 0000 0000
17:03:09.336285 IP (tos 0x0, ttl 64, id 52536, offset 0, flags [DF],
proto UDP (17), length 90)
192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!]
UDP, length 62
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 005a cd38 4000 4011 ade6 c0a8 1f11 c0a8
0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 0028 6358 4000 4006 ee03 c0a8 3411
0x0050: c0a8 3412 86f2 3241 d67e f70d e5a9 d041
0x0060: 5011 0038 897b 0000
17:03:10.335074 IP (tos 0x0, ttl 64, id 40045, offset 0, flags [DF],
proto UDP (17), length 98)
192.168.31.18.48861 > 192.168.31.17.4789: [no cksum] UDP, length 70
0x0000: 0002 c9e9 bf32 f452 1401 da82 0800 4500
0x0010: 0062 9c6d 4000 4011 dea9 c0a8 1f12 c0a8
0x0020: 1f11 bedd 12b5 004e 0000 0800 0000 0000
0x0030: 6300 7a83 2ecb 8c68 b2c7 81db e850 0800
0x0040: 4500 0030 0000 4000 4006 5154 c0a8 3412
0x0050: c0a8 3411 3241 86f2 e5a9 d040 d67e f47d
0x0060: 7012 6e28 f282 0000 0204 0582 0103 0307
17:03:10.335110 IP (tos 0x0, ttl 64, id 52764, offset 0, flags [DF],
proto UDP (17), length 90)
192.168.31.17.56686 > 192.168.31.18.4789: [bad udp cksum 1360!]
UDP, length 62
0x0000: f452 1401 da82 0002 c9e9 bf32 0800 4500
0x0010: 005a ce1c 4000 4011 ad02 c0a8 1f11 c0a8
0x0020: 1f12 dd6e 12b5 0046 139a 0800 0000 0000
0x0030: 6300 b2c7 81db e850 7a83 2ecb 8c68 0800
0x0040: 4500 0028 6359 4000 4006 ee02 c0a8 3411
0x0050: c0a8 3412 86f2 3241 d67e f70e e5a9 d041
0x0060: 5010 0038 897b 0000
^ permalink raw reply
* Re: [PATCH net-next 2/2] udp: Reset flow table for flows over unconnected sockets
From: Tom Herbert @ 2014-10-28 15:18 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Linux Netdev List
In-Reply-To: <20141028.005121.1715627351754245965.davem@davemloft.net>
On Mon, Oct 27, 2014 at 9:51 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Mon, 27 Oct 2014 18:09:25 -0700
>
>> This indicates nothing about the merits of this patch. Nevertheless,
>> in order to avoid further rat-holing and since this patch does change
>> a long standing behavior I'll will respin to make it enabled only by
>> sysctl.
>
> Kind of disappointed on my end that you haven't addressed Eric's
> main point, which is that:
>
> 1) A hash table shared between protocols will perform poorly for
> mixed workloads which are becomming increasingly common.
>
The major design point of RFS is that it steers L4 flows based on a
hash for the each flow. Preferably, this hash is based on the 5-tuple
of the (innermost) UDP, TCP, SCTP, etc. packet. It is a probabilistic
algorithm whose effectiveness depends on hit rate in the table, hence
the table should be sized to the working set. In RFS, the working set
is defined by the number of simultaneously active flows not by the
number of established flows which could be much greater. We've known
from the beginning that for some servers with large amounts of
non-flow based traffic (particularly DNS servers) RFS may not be
useful. If it's not feasible to size the table to the working set,
then RFS shouldn't be used.
> 2) UDP is fundamentally different from TCP in that the issue of
> 'flow' vs. 'non-flow' packets
>
We are seeing many instances where UDP packets carry flows, and
conversely there are important cases where TCP packets do not
correspond to flows.
UDP tunnels are becoming increasingly common. VXLAN, FOU, GUE, geneve,
l2tp, esp/UDP, GRE/UDP, nvgre, etc. all rely on steering based on the
outer header without deep inspection. When the source port is set to
inner hash RFS works as is and steering is effectively done based
inner TCP connections. If aRFS supports UDP, then this should just
work also for UDP tunnels (another instance where we don't need
protocol specific support in devices for tunneling).
QUIC itself is flow based. It is a transport protocol about as
sophisticated as TCP that is encapsulated in UDP to facilitate
transport. The fact that QUIC might have millions of simultaneously
active connections is a problem of scale, not of the algorithm. If we
have a server with millions of active TCP connections we'd have the
exact same scaling problem.
Under several DOS attacks TCP packets are not flow based. For instance
in a SYN attack once we get into syn cookies, SYNs are steered based
on whatever is in the table and the table is not updated for these
packets. This case exhibits the same characteristics as non-flow UDP.
In fact makes me think we should also be clearing the flow table in
this case.
> I personally do not see you avoiding this conversation by simply
> hiding the new behavior behind a sysctl, I still want you to address
> it before I apply anything.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: ipv6: Add a sysctl to make optimistic addresses useful candidates
From: Lorenzo Colitti @ 2014-10-28 15:15 UTC (permalink / raw)
To: Erik Kline
Cc: netdev@vger.kernel.org, David Miller, Ben Hutchings,
Hannes Frederic Sowa
In-Reply-To: <1414487474-18201-1-git-send-email-ek@google.com>
On Tue, Oct 28, 2014 at 6:11 PM, Erik Kline <ek@google.com> wrote:
> Add a sysctl that causes an interface's optimistic addresses
> to be considered equivalent to other non-deprecated addresses
> for source address selection purposes. Preferred addresses
> will still take precedence over optimistic addresses, subject
> to other ranking in the source address selection algorithm.
> ...
> Signed-off-by: Erik Kline <ek@google.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
^ permalink raw reply
* Re: [PATCH] [trivial] treewide: Fix company name in module descriptions
From: Linus Walleij @ 2014-10-28 14:44 UTC (permalink / raw)
To: Masanari Iida
Cc: linux-kernel@vger.kernel.org, Mike Turquette, Jiri Kosina,
Alexandre Courbot, jcliburn, chris.snook, Viresh Kumar, inki.dae,
leedonghwa, Kukjin Kim, Randy Dunlap, netdev@vger.kernel.org
In-Reply-To: <1413472164-22366-1-git-send-email-standby24x7@gmail.com>
On Thu, Oct 16, 2014 at 5:09 PM, Masanari Iida <standby24x7@gmail.com> wrote:
> This patch fix company name's spelling typo in module descriptions
> and a Kconfig.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/7] fs: Convert show_fdinfo functions to void
From: Steven Rostedt @ 2014-10-28 14:43 UTC (permalink / raw)
To: Joe Perches
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, Jiri Kosina,
Thomas Gleixner, Jeff Layton, J. Bruce Fields, linux-doc,
linux-kernel, netdev, linux-fsdevel
In-Reply-To: <1414506692.6643.2.camel@perches.com>
On Tue, 28 Oct 2014 07:31:32 -0700
Joe Perches <joe@perches.com> wrote:
> > I wouldn't change logic on this. There's no reason to call this
> > function if it isn't doing anything.
> >
> > I'll change this to just do the update and not change logic like this.
>
> Fewer #ifdefs
>
And there's other ways to fix it (like using an #else), but that is
off-topic to the current change set. In other words, that change should
be separate, as I don't want discussions on what's the best use of
#ifdefs distracting from getting in the "void seq_printf()" changes.
-- Steve
^ permalink raw reply
* Re: [PATCH 5/7] fs: Convert show_fdinfo functions to void
From: Joe Perches @ 2014-10-28 14:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, Jiri Kosina,
Thomas Gleixner, Jeff Layton, J. Bruce Fields, linux-doc,
linux-kernel, netdev, linux-fsdevel
In-Reply-To: <20141028101158.3dde9880@gandalf.local.home>
On Tue, 2014-10-28 at 10:11 -0400, Steven Rostedt wrote:
> On Mon, 29 Sep 2014 16:08:25 -0700
> Joe Perches <joe@perches.com> wrote:
>
> > seq_printf functions shouldn't really check the return value.
> > Checking seq_is_full occasionally is used instead.
> >
> > Update vfs documentation.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
>
> >
> > -#ifdef CONFIG_PROC_FS
> > -static int eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> > +static void eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> > {
> > +#ifdef CONFIG_PROC_FS
> > struct eventfd_ctx *ctx = f->private_data;
> > - int ret;
> >
> > spin_lock_irq(&ctx->wqh.lock);
> > - ret = seq_printf(m, "eventfd-count: %16llx\n",
> > - (unsigned long long)ctx->count);
> > + seq_printf(m, "eventfd-count: %16llx\n",
> > + (unsigned long long)ctx->count);
> > spin_unlock_irq(&ctx->wqh.lock);
> > -
> > - return ret;
> > -}
> > #endif
> > +}
> >
> > static const struct file_operations eventfd_fops = {
> > -#ifdef CONFIG_PROC_FS
> > .show_fdinfo = eventfd_show_fdinfo,
> > -#endif
>
> I wouldn't change logic on this. There's no reason to call this
> function if it isn't doing anything.
>
> I'll change this to just do the update and not change logic like this.
Fewer #ifdefs
^ permalink raw reply
* Re: [PATCH 5/7] fs: Convert show_fdinfo functions to void
From: Steven Rostedt @ 2014-10-28 14:11 UTC (permalink / raw)
To: Joe Perches
Cc: Al Viro, Petr Mladek, Andrew Morton, Linus Torvalds, Jiri Kosina,
Thomas Gleixner, Jeff Layton, J. Bruce Fields, linux-doc,
linux-kernel, netdev, linux-fsdevel
In-Reply-To: <e37e6e7b76acbdcc3bb4ab2a57c8f8ca1ae11b9a.1412031505.git.joe@perches.com>
On Mon, 29 Sep 2014 16:08:25 -0700
Joe Perches <joe@perches.com> wrote:
> seq_printf functions shouldn't really check the return value.
> Checking seq_is_full occasionally is used instead.
>
> Update vfs documentation.
>
> Signed-off-by: Joe Perches <joe@perches.com>
>
> -#ifdef CONFIG_PROC_FS
> -static int eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> +static void eventfd_show_fdinfo(struct seq_file *m, struct file *f)
> {
> +#ifdef CONFIG_PROC_FS
> struct eventfd_ctx *ctx = f->private_data;
> - int ret;
>
> spin_lock_irq(&ctx->wqh.lock);
> - ret = seq_printf(m, "eventfd-count: %16llx\n",
> - (unsigned long long)ctx->count);
> + seq_printf(m, "eventfd-count: %16llx\n",
> + (unsigned long long)ctx->count);
> spin_unlock_irq(&ctx->wqh.lock);
> -
> - return ret;
> -}
> #endif
> +}
>
> static const struct file_operations eventfd_fops = {
> -#ifdef CONFIG_PROC_FS
> .show_fdinfo = eventfd_show_fdinfo,
> -#endif
I wouldn't change logic on this. There's no reason to call this
function if it isn't doing anything.
I'll change this to just do the update and not change logic like this.
-- Steve
> .release = eventfd_release,
> .poll = eventfd_poll,
> .read = eventfd_read,
> diff --git a/fs/proc/fd.c b/fs/proc/fd.c
> index e11d7c5..4c3c253 100644
> --- a/fs/proc/fd.c
> +++ b/fs/proc/fd.c
> @@ -53,7 +53,7 @@ static int seq_show(struct seq_file *m, void *v)
> (long long)file->f_pos, f_flags,
> real_mount(file->f_path.mnt)->mnt_id);
> if (file->f_op->show_fdinfo)
> - ret = file->f_op->show_fdinfo(m, file);
> + file->f_op->show_fdinfo(m, file);
> fput(file);
> }
>
^ permalink raw reply
* Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx 10/20-Gigabit Ethernet Driver
From: Stefan Bottelier | Ocius.nl @ 2014-10-28 14:07 UTC (permalink / raw)
To: netdev@vger.kernel.org >> netdev
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63B87612@avmb3.qlogic.org>
Hello,
We have fix some problems, but now i get the interface firmware not
working, are the some tips of tricks for this ? Its for a Blade Servers,
and this working the best with the kernel 3.2.0 branch. So i hope
somebody can help me whit this.
[ 76.803495] bnx2x: [bnx2x_init_firmware:10573(eth0)]Can't load
firmware file bnx2x/bnx2x-e2-7.0.29.0.fw
[ 76.803508] bnx2x: [bnx2x_func_hw_init:5382(eth0)]Error loading firmware
[ 76.803523] bnx2x: [bnx2x_nic_load:1847(eth0)]HW init failed, aborting
> You can try netdev again, or you should try with the distro bugzillas
> [I'm not sure if request_firmware() is contained entirely in kernel or is dependent on some tools in the filesystem provided by the distro]
>
>> -----Original Message-----
>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>> Sent: Tuesday, October 28, 2014 2:40 PM
>> To: Yuval Mintz
>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx 10/20-
>> Gigabit Ethernet Driver
>>
>> Are the some places where i get drop this question ? I hope so that i get it
>> working on this Dell Server.
>>
>>> Sounds like a small technicality, but sadly I cannot help you from afar.
>>>
>>>> -----Original Message-----
>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>> Sent: Tuesday, October 28, 2014 2:29 PM
>>>> To: Yuval Mintz
>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx
>>>> 10/20- Gigabit Ethernet Driver
>>>>
>>>> Any ideas?
>>>>
>>>> why this message will be coming up.
>>>>
>>>> [ 76.074999] bnx2x: [bnx2x_init_firmware:10573(eth0)]Can't load
>>>> firmware file bnx2x/bnx2x-e2-7.0.29.0.fw
>>>> [ 76.075011] bnx2x: [bnx2x_func_hw_init:5382(eth0)]Error loading firmware
>>>> [ 76.075032] bnx2x: [bnx2x_nic_load:1847(eth0)]HW init failed, aborting
>>>>
>>>> I have change the firmware in
>>>>
>>>> bnx2x_main.c and i have set the firmware images in
>>>> /lib/firmware/bnx2x
>>>>
>>>>
>>>>> You can get it from by cloning the linux-firmware git repository at
>>>>> - git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.
>>>>> git
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>> Sent: Tuesday, October 28, 2014 1:17 PM
>>>>>> To: Yuval Mintz
>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II 5771x/578xx
>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>
>>>>>> Hello Yuval,
>>>>>>
>>>>>> Now i get no erro's only the follwing imforation
>>>>>> [ 18.340531] bnx2x 0000:01:00.0: Bad FW version:6.2.9.0. Should be
>>>>>> 7.0.29.0
>>>>>> [ 18.340542] bnx2x: [bnx2x_init_firmware:10579(eth0)]Corrupt firmware
>>>>>> file bnx2x/bnx2x-e2-6.2.9.0.fw
>>>>>> [ 18.340550] bnx2x: [bnx2x_func_hw_init:5382(eth0)]Error loading
>> firmware
>>>>>> [ 18.340562] bnx2x: [bnx2x_nic_load:1847(eth0)]HW init failed, aborting
>>>>>>
>>>>>> If are a location where i can download the 7.0.29.0 firmware, i
>>>>>> change to the kernel firmware but this don't work. So i a searching
>>>>>> for the
>>>>>> 7.0.29.0 firmware.
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The change might affect you - you're using a new board.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Yuval
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>>>> Sent: Tuesday, October 28, 2014 12:15 PM
>>>>>>>> To: Yuval Mintz
>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>> 5771x/578xx
>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>
>>>>>>>> Hello Yuval,
>>>>>>>>
>>>>>>>> Whithout code change i see.
>>>>>>>>
>>>>>>>> bash-4.3# ethtool -i eth0
>>>>>>>> driver: bnx2x
>>>>>>>> version: 1.70.30-0
>>>>>>>> firmware-version: bc 7.10.11
>>>>>>>> bus-info: 0000:01:00.0
>>>>>>>>
>>>>>>>>> Btw,
>>>>>>>>>
>>>>>>>>> You can supply `ethtool -i' output on one of the interfaces to
>>>>>>>>> see whether the
>>>>>>>> warning would actually apply.
>>>>>>>>> Thanks,
>>>>>>>>> Yuval
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Yuval Mintz
>>>>>>>>>> Sent: Tuesday, October 28, 2014 12:07 PM
>>>>>>>>>> To: 'Stefan Bottelier | Ocius.nl'
>>>>>>>>>> Subject: RE: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>> 5771x/578xx
>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>
>>>>>>>>>> Well,
>>>>>>>>>>
>>>>>>>>>> There is actually a WARN_ON in line 8886, and that warning was
>>>>>>>>>> later removed for newer boards.
>>>>>>>>>>
>>>>>>>>>> Please try removing it and changing to the code in
>>>>>>>>>> bnx2x_get_igu_cam_info() from upstream kernel, and see what's
>> next.
>>>>>>>>>> Cheers,
>>>>>>>>>> Yuval
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>>>>>>> Sent: Tuesday, October 28, 2014 11:59 AM
>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>> 5771x/578xx
>>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>>
>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>
>>>>>>>>>>> I have change this in the
>>>>>>>>>>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
>>>>>>>>>>>
>>>>>>>>>>> With new code from the 3.10 kernel
>>>>>>>>>>>
>>>>>>>>>>> static void bnx2x_set_mac_buf(u8 *mac_buf, u32 mac_lo, u16
>>>>>>>>>>> mac_hi)
>>>> {
>>>>>>>>>>> __be16 mac_hi_be = cpu_to_be16(mac_hi);
>>>>>>>>>>> __be32 mac_lo_be = cpu_to_be32(mac_lo);
>>>>>>>>>>> memcpy(mac_buf, &mac_hi_be, sizeof(mac_hi_be));
>>>>>>>>>>> memcpy(mac_buf + sizeof(mac_hi_be), &mac_lo_be,
>>>>>>>>>>> sizeof(mac_lo_be)); }
>>>>>>>>>>>
>>>>>>>>>>> Now i get the following message back
>>>>>>>>>>>
>>>>>>>>>>> [ 5.748765] WARNING: at
>>>>>>>>>>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:8886
>>>>>>>>>>> bnx2x_init_one+0xd04/0x2786()
>>>>>>>>>>> [ 5.748767] Hardware name: PowerEdge M620
>>>>>>>>>>> [ 5.748769] Modules linked in:
>>>>>>>>>>> [ 5.748773] Pid: 1, comm: swapper/0 Tainted: G W 3.2.63 #1
>>>>>>>>>>>
>>>>>>>>>>> Are this correct my change in this code ?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>
>>>>>>>>>>>> Are you using a Big-Endian machine?
>>>>>>>>>>>>
>>>>>>>>>>>> Regardless, I don't really have anything 'good' to tell you -
>>>>>>>>>>>> the code you've given me is the same as the one I've looked
>>>>>>>>>>>> at, and line
>>>>>>>>>>>> 9410 doesn't
>>>>>>>>>>> really include anything that should produce a warn [at most, a
>>>>>>>>>>> NULL pointer dereference].
>>>>>>>>>>>> Regardless, if you can - you can try to replace the
>>>>>>>>>>>> implementation of
>>>>>>>>>>>> bnx2x_set_mac_buf() in your kernel in bnx2x_main.c with the
>>>>>>>>>>>> one from more
>>>>>>>>>>> modern kernels; [It doesn't pass address of parameters to the
>>>>>>>>>>> function] and see if it solves your issue.
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Yuval
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl [mailto:stefan@ocius.nl]
>>>>>>>>>>>>> Sent: Tuesday, October 28, 2014 10:31 AM
>>>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>> 5771x/578xx
>>>>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Correct i use 32bits machine
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3.2.63 #1 SMP Mon Oct 27 11:22:59 CET 2014 i686 i686 i386
>>>>>>>>>>>>> GNU/Linux
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have added new files. objdump i have run this command in
>>>>>>>>>>>>> the bnx2x dir from the kernel source, i hope thats is oke ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Stefan
>>>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2 things:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. For some reason the source files I'm looking at don't
>>>>>>>>>>>>>> look the same as
>>>>>>>>>>>>> yours.
>>>>>>>>>>>>>> If you can, please tarball me the bnx2x directory from the
>>>>>>>>>>>>>> kernel sources
>>>>>>>>>>>>> you've compile and send it to me.
>>>>>>>>>>>>>> 2. objdump doesn't contain the source code; Are you sure
>>>>>>>>>>>>>> you've used
>>>>>>>>>>>>> `objdump -S' as opposed to simple `objdump' when generating it?
>>>>>>>>>>>>>> 3. Just to be certain, you're using a 32-bit machine, right?
>>>>>>>>>>>>>> [Don't know if it's related, but it's rare enough that I
>>>>>>>>>>>>>> should consider it when I look at the issue]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Yuval
>>>>>>>>>>>>>> ________________________________________
>>>>>>>>>>>>>> From: Yuval Mintz
>>>>>>>>>>>>>> Sent: Monday, October 27, 2014 8:38 AM
>>>>>>>>>>>>>> To: Stefan Bottelier | Ocius.nl
>>>>>>>>>>>>>> Subject: RE: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>>> 5771x/578xx 10/20-Gigabit Ethernet Driver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Stefan - I have, but I still haven't been able to look into it.
>>>>>>>>>>>>>> ________________________________________
>>>>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl [stefan@ocius.nl]
>>>>>>>>>>>>>> Sent: Monday, October 27, 2014 8:32 AM
>>>>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>>> 5771x/578xx 10/20-Gigabit Ethernet Driver
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you have received my file's good ? I am not sure..
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just looked into 3.2.63 [Saber-toothed Squirrel] sources,
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> bnx2x_main:9410 doesn't look as if it contains any code
>>>>>>>>>>>>>>> that can throw a
>>>>>>>>>>>>> stack trace, Nor is it a [direct] part of bnx2x_init_one.
>>>>>>>>>>>>>>> Perhaps you can send the output of `objdump -S bnx2x.ko',
>>>>>>>>>>>>>>> so I could take a
>>>>>>>>>>>>> look at the place the stack trace points as the source of the issue?
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Yuval
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: Stefan Bottelier | Ocius.nl
>>>>>>>>>>>>>>>> [mailto:stefan@ocius.nl]
>>>>>>>>>>>>>>>> Sent: Monday, October 27, 2014 10:43 AM
>>>>>>>>>>>>>>>> To: Yuval Mintz
>>>>>>>>>>>>>>>> Cc: netdev
>>>>>>>>>>>>>>>> Subject: Re: Problem with 10Gbit Broadcom NetXtreme II
>>>>>>>>>>>>>>>> 5771x/578xx
>>>>>>>>>>>>>>>> 10/20- Gigabit Ethernet Driver
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Yuval,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for this messages.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We use now the kernel 3.10.57 and then the interface
>>>>>>>>>>>>>>>> working, only we must back to the kernel we always use
>>>>>>>>>>>>>>>> 3.2.63 , its work better with use
>>>>>>>>>>>>> systems.
>>>>>>>>>>>>>>>> I have compiler the kernel by my self on a Suse system.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I hope we can fix it, that this working with the kernel 3.2.63.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We are using Dell Blade Centers, but we get a error on
>>>>>>>>>>>>>>>>>> the 10Gbit Broadcom adapter bnx2x bnx2x 0000:01:00.0:
>>>>>>>>>>>>>>>>>> part number
>>>>>>>>>>>>>>>>>> 394D4342-31383735-30315430-473030
>>>>>>>>>>>>>>>>>> WARNING: at
>>>>>>>>>>>>>>>>>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:9410
>>>>>>>>>>>>>>>>> Hi Stefan,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which distro & linux kernel are you using?
>>>>>>>>>>>>>>>>> [Obviously not net-next]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Yuval
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This message and any attached documents contain
>>>>>>>>>>>>>>>>> information from the
>>>>>>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>>>>>>> divisions or branch offices that may be confidential. If
>>>>>>>>>>>>>>>> you are not the intended recipient, you may not read,
>>>>>>>>>>>>>>>> copy, distribute, or use this information. If you have
>>>>>>>>>>>>>>>> received this transmission in error, please notify the
>>>>>>>>>>>>>>>> sender immediately by reply e-mail and then delete this
>>>>>>>>>>> message.
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This message and any attached documents contain
>>>>>>>>>>>>>>> information from the
>>>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>>>> divisions or branch offices that may be confidential. If you
>>>>>>>>>>>>> are not the intended recipient, you may not read, copy,
>>>>>>>>>>>>> distribute, or use this information. If you have received
>>>>>>>>>>>>> this transmission in error, please notify the sender
>>>>>>>>>>>>> immediately by reply e-mail and then delete this
>>>>>>>>>> message.
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This message and any attached documents contain information
>>>>>>>>>>>>>> from the
>>>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>>>> divisions or branch offices that may be confidential. If you
>>>>>>>>>>>>> are not the intended recipient, you may not read, copy,
>>>>>>>>>>>>> distribute, or use this information. If you have received
>>>>>>>>>>>>> this transmission in error, please notify the sender
>>>>>>>>>>>>> immediately by reply e-mail and then delete this
>>>>>>>>>> message.
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>>>
>>>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>>>>> ________________________________
>>>>>>>>>>>>
>>>>>>>>>>>> This message and any attached documents contain information
>>>>>>>>>>>> from the
>>>>>>>>>>> sending company or its parent company(s), subsidiaries,
>>>>>>>>>>> divisions or branch offices that may be confidential. If you
>>>>>>>>>>> are not the intended recipient, you may not read, copy,
>>>>>>>>>>> distribute, or use this information. If you have received this
>>>>>>>>>>> transmission in error, please notify the sender immediately by
>>>>>>>>>>> reply e-mail and then delete this
>>>>>> message.
>>>>>>>>>>> --
>>>>>>>>>>> Met vriendelijke groet,
>>>>>>>>>>>
>>>>>>>>>>> Stefan Bottelier
>>>>>>>>>>> Ocius Internet Services
>>>>>>>>>>>
>>>>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>>>>> W: http://www.ocius.nl
>>>>>>>>> ________________________________
>>>>>>>>>
>>>>>>>>> This message and any attached documents contain information from
>>>>>>>>> the
>>>>>>>> sending company or its parent company(s), subsidiaries, divisions
>>>>>>>> or branch offices that may be confidential. If you are not the
>>>>>>>> intended recipient, you may not read, copy, distribute, or use
>>>>>>>> this information. If you have received this transmission in
>>>>>>>> error, please notify the sender immediately by reply e-mail and
>>>>>>>> then delete this
>>>> message.
>>>>>>>> --
>>>>>>>> Met vriendelijke groet,
>>>>>>>>
>>>>>>>> Stefan Bottelier
>>>>>>>> Ocius Internet Services
>>>>>>>>
>>>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>>>> T: +31 (0)20 716 39 09
>>>>>>>> W: http://www.ocius.nl
>>>>>>> ________________________________
>>>>>>>
>>>>>>> This message and any attached documents contain information from
>>>>>>> the
>>>>>> sending company or its parent company(s), subsidiaries, divisions
>>>>>> or branch offices that may be confidential. If you are not the
>>>>>> intended recipient, you may not read, copy, distribute, or use this
>>>>>> information. If you have received this transmission in error,
>>>>>> please notify the sender immediately by reply e-mail and then delete this
>> message.
>>>>>>
>>>>>> --
>>>>>> Met vriendelijke groet,
>>>>>>
>>>>>> Stefan Bottelier
>>>>>> Ocius Internet Services
>>>>>>
>>>>>> E: Stefan.Bottelier@ocius.nl
>>>>>> T: +31 (0)20 716 39 09
>>>>>> W: http://www.ocius.nl
>>>>> ________________________________
>>>>>
>>>>> This message and any attached documents contain information from the
>>>> sending company or its parent company(s), subsidiaries, divisions or
>>>> branch offices that may be confidential. If you are not the intended
>>>> recipient, you may not read, copy, distribute, or use this
>>>> information. If you have received this transmission in error, please
>>>> notify the sender immediately by reply e-mail and then delete this message.
>>>>
>>>>
>>>> --
>>>> Met vriendelijke groet,
>>>>
>>>> Stefan Bottelier
>>>> Ocius Internet Services
>>>>
>>>> E: Stefan.Bottelier@ocius.nl
>>>> T: +31 (0)20 716 39 09
>>>> W: http://www.ocius.nl
>>> ________________________________
>>>
>>> This message and any attached documents contain information from the
>> sending company or its parent company(s), subsidiaries, divisions or branch
>> offices that may be confidential. If you are not the intended recipient, you may
>> not read, copy, distribute, or use this information. If you have received this
>> transmission in error, please notify the sender immediately by reply e-mail and
>> then delete this message.
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Stefan Bottelier
>> Ocius Internet Services
>>
>> E: Stefan.Bottelier@ocius.nl
>> T: +31 (0)20 716 39 09
>> W: http://www.ocius.nl
>
> ________________________________
>
> This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
--
Met vriendelijke groet,
Stefan Bottelier
Ocius Internet Services
E: Stefan.Bottelier@ocius.nl
T: +31 (0)20 716 39 09
W: http://www.ocius.nl
^ 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