* Re: [PATCH] DT: net: document Ethernet bindings in one place
From: Sergei Shtylyov @ 2014-02-06 14:06 UTC (permalink / raw)
To: Grant Likely, Florian Fainelli, Rob Herring
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, devicetree@vger.kernel.org, Rob Landley,
linux-doc@vger.kernel.org
In-Reply-To: <20140206094301.03572C40B6A@trevor.secretlab.ca>
Hello.
On 06-02-2014 13:43, Grant Likely wrote:
>>>>>>>>>>> I'm afraid that's too late, it has spread very far, so that
>>>>>>>>>>> of_get_phy_mode() handles that property, not "phy-connection-type".
>>>>>>>>>> Uggg, I guess this is a case of a defacto standard then if the kernel
>>>>>>>>>> doesn't even support it.
>>>>>>>>> Maybe I forgot to CC you on patch sent to Grant only, I sent a patch a
>>>>>>>>> while ago for of_get_phy_mode() to look for both "phy-mode" and
>>>>>>>>> "phy-connection-type" since the former has been a Linux invention, but
>>>>>>>>> the latter is ePAPR specified.
>>>>>>>> Here is a link to the actual patch in question, not sure which tree
>>>>>>>> Grant applied it to though:
>>>>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1311.2/00048.html
>>>>>>> It's not the patch mail, it's Grant's "applied" reply, patch is mangled in
>>>>>>> this reply, and I couldn't follow the thread. Here's the actual patch mail:
>>>>>>> http://marc.info/?l=devicetree&m=138449662807254
>>>>>> Florian, I didn't find this patch in Grant's official tree, so maybe you
>>>>>> should ask him where is the patch already?
>>>>> Sorry, I accidentally dropped it. It will be in the next merge window.
>>>> Already saw it, thanks. Would that it was in 3.14 instead of course, so
>>>> that I could use "phy-connection-type" in my binding...
>>> Is 3.14 broken because of missing the patch? If so I'll get it merged as
>> > a bug fix.
>> No, it's not. I could have used "phy-connection-type" in my binding
>> destined for 3.15 and document it as a preferred property as well.
> You still can. We just need to make sure that your patch is applied on
Patches.
> top of the phy-connection-type patch.
I'm not sure this trick is possible if the patches are merged via the
different trees...
> g.
WBR, Sergei
^ permalink raw reply
* Re: Freescale FEC packet loss
From: Marek Vasut @ 2014-02-06 13:41 UTC (permalink / raw)
To: Christian Gmeiner
Cc: Ben Hutchings, fabio.estevam@freescale.com, Matthew Garrett,
Frank Li, Detlev Zundel, netdev@vger.kernel.org, Eric Nelson,
Hector Palacios, fugang.duan,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAH9NwWeK17kfty-BAA9Y977BGTYBcJLRSRESrfbCvQ_BiVxa0A@mail.gmail.com>
On Thursday, February 06, 2014 at 10:42:00 AM, Christian Gmeiner wrote:
[...]
> Are there still problems with 3.13.1 kernel regarding FEC networking?
They are on 3.13.0 and I don't see any network-related fixes in 3.13.1 .
> Does this only
> affect the SabreLite?
No, this is not board-specific. This affects different boards and different MX6
CPUs.
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v3 5/5] can: sja1000: of: add reg-io-width property for 8, 16 and 32-bit register access
From: Florian Vaussard @ 2014-02-06 14:21 UTC (permalink / raw)
To: Marc Kleine-Budde, Sergei Shtylyov, Wolfgang Grandegger
Cc: Andreas Larsson, linux-can, netdev, sparclinux, linux-kernel
In-Reply-To: <52F36AAA.9000704@pengutronix.de>
Hi,
On 02/06/2014 11:57 AM, Marc Kleine-Budde wrote:
> On 01/31/2014 03:08 PM, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 31-01-2014 17:34, Florian Vaussard wrote:
>>
>>> Add the 'reg-io-width' property for 8, 16 and 32-bit access, like
>>> what is currently done with IORESOURCE_MEM_{8,16,32}BIT for non-OF
>>> boot.
>>
>>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>>> ---
>>> drivers/net/can/sja1000/sja1000_platform.c | 16 ++++++++++++++--
>>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>>> diff --git a/drivers/net/can/sja1000/sja1000_platform.c
>>> b/drivers/net/can/sja1000/sja1000_platform.c
>>> index 50dece8..25122bf 100644
>>> --- a/drivers/net/can/sja1000/sja1000_platform.c
>>> +++ b/drivers/net/can/sja1000/sja1000_platform.c
>>> @@ -102,8 +102,20 @@ static void sp_populate_of(struct sja1000_priv
>>> *priv, struct device_node *of)
>>> int err;
>>> u32 prop;
>>>
>>> - priv->read_reg = sp_read_reg8;
>>> - priv->write_reg = sp_write_reg8;
>>> + err = of_property_read_u32(of, "reg-io-width", &prop);
>>> + if (err)
>>> + prop = 1;
>>> +
>>> + if (prop == 4) {
>>
>> This is asking to be a *switch* statement instead.
>
> Good point, I'll send a v4.
>
Thank you!
Florian
^ permalink raw reply
* Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
From: Dan Williams @ 2014-02-06 14:26 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: Konrad Rzeszutek Wilk, Wei Liu, Francois Romieu,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <942972114.20140206140909@eikelenboom.it>
On Thu, Feb 6, 2014 at 5:09 AM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Hmm ok that last message was false .. sorry for that .. it did happen again without r8169.use_dac=1, it just doesn't seem to happen all the time...
>
> Konrad / Wei, do you happen to know of any xen related change that went into 3.14 merge window that relates to dma / xen networking ?
>
> --
> Sander
>
> complete stacktrace:
>
> [ 342.710738] ------------[ cut here ]------------
> [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x105/0x130()
> [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00
> [ 342.759510] Modules linked in:
> [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1
> [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
> [ 342.807627] 0000000000000009 ffff88005f603828 ffffffff81ad29fc ffffffff822134e0
> [ 342.823430] ffff88005f603878 ffff88005f603868 ffffffff810bdf62 ffff880000000000
> [ 342.839081] 0000000000040b00 00000000ffffffef ffffffff822102e0 ffff8800592b9098
> [ 342.854572] Call Trace:
> [ 342.869748] <IRQ> [<ffffffff81ad29fc>] dump_stack+0x46/0x58
> [ 342.884915] [<ffffffff810bdf62>] warn_slowpath_common+0x82/0xb0
> [ 342.899710] [<ffffffff810be031>] warn_slowpath_fmt+0x41/0x50
> [ 342.914395] [<ffffffff8147853a>] ? active_pfn_read_overlap+0x3a/0x70
> [ 342.929166] [<ffffffff814792c5>] add_dma_entry+0x105/0x130
> [ 342.943733] [<ffffffff814796c6>] debug_dma_map_page+0x126/0x150
> [ 342.957988] [<ffffffff8171c8b6>] rtl8169_start_xmit+0x216/0xa20
> [ 342.972306] [<ffffffff8195f08f>] ? dev_queue_xmit_nit+0x1ef/0x260
> [ 342.986523] [<ffffffff8195eea0>] ? dev_loopback_xmit+0x1e0/0x1e0
> [ 343.000689] [<ffffffff819631e6>] dev_hard_start_xmit+0x2e6/0x4a0
> [ 343.014466] [<ffffffff81980f3e>] sch_direct_xmit+0xfe/0x280
> [ 343.028052] [<ffffffff819635dc>] __dev_queue_xmit+0x23c/0x630
> [ 343.041338] [<ffffffff819633a0>] ? dev_hard_start_xmit+0x4a0/0x4a0
> [ 343.054483] [<ffffffff81a0a334>] ? ip_output+0x54/0xf0
> [ 343.067659] [<ffffffff819639eb>] dev_queue_xmit+0xb/0x10
> [ 343.080804] [<ffffffff81a0890b>] ip_finish_output+0x2cb/0x670
> [ 343.093746] [<ffffffff81a0a334>] ? ip_output+0x54/0xf0
> [ 343.106391] [<ffffffff81a0a334>] ip_output+0x54/0xf0
> [ 343.118683] [<ffffffff81a05791>] ip_forward_finish+0x71/0x1a0
> [ 343.130901] [<ffffffff81a05a63>] ip_forward+0x1a3/0x440
> [ 343.142829] [<ffffffff810ffebb>] ? lock_is_held+0x8b/0xb0
> [ 343.154346] [<ffffffff81a035c0>] ip_rcv_finish+0x150/0x660
> [ 343.165748] [<ffffffff81a0406b>] ip_rcv+0x22b/0x370
> [ 343.176838] [<ffffffff81a60972>] ? packet_rcv_spkt+0x42/0x190
> [ 343.187659] [<ffffffff819609d2>] __netif_receive_skb_core+0x6d2/0x8a0
> [ 343.198209] [<ffffffff81960414>] ? __netif_receive_skb_core+0x114/0x8a0
> [ 343.208819] [<ffffffff81009010>] ? xen_clocksource_read+0x20/0x30
> [ 343.219471] [<ffffffff81116e49>] ? getnstimeofday+0x9/0x30
> [ 343.229862] [<ffffffff81960bbc>] __netif_receive_skb+0x1c/0x70
> [ 343.239953] [<ffffffff81960c2e>] netif_receive_skb_internal+0x1e/0xf0
> [ 343.249908] [<ffffffff81962110>] napi_gro_receive+0x70/0xa0
> [ 343.259509] [<ffffffff817198a3>] rtl8169_poll+0x2d3/0x680
> [ 343.268982] [<ffffffff81adcd2b>] ? _raw_spin_unlock_irq+0x2b/0x50
> [ 343.278091] [<ffffffff819610d1>] net_rx_action+0x161/0x260
> [ 343.287056] [<ffffffff810c28ec>] __do_softirq+0x12c/0x280
> [ 343.295756] [<ffffffff810c2da2>] irq_exit+0xa2/0xd0
> [ 343.304235] [<ffffffff814ffd5f>] xen_evtchn_do_upcall+0x2f/0x40
> [ 343.312387] [<ffffffff81adf15e>] xen_do_hypervisor_callback+0x1e/0x30
> [ 343.320389] <EOI> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [ 343.328171] [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
> [ 343.335738] [<ffffffff81008c70>] ? xen_safe_halt+0x10/0x20
> [ 343.343142] [<ffffffff81018748>] ? default_idle+0x18/0x20
> [ 343.350202] [<ffffffff81018f5e>] ? arch_cpu_idle+0x2e/0x40
> [ 343.356994] [<ffffffff8110b551>] ? cpu_startup_entry+0x91/0x1e0
> [ 343.363658] [<ffffffff81ac7d87>] ? rest_init+0xb7/0xc0
> [ 343.369924] [<ffffffff81ac7cd0>] ? csum_partial_copy_generic+0x170/0x170
> [ 343.376057] [<ffffffff8230ff1c>] ? start_kernel+0x409/0x416
> [ 343.381972] [<ffffffff8230f912>] ? repair_env_string+0x5e/0x5e
> [ 343.387573] [<ffffffff8230f5f8>] ? x86_64_start_reservations+0x2a/0x2c
> [ 343.393152] [<ffffffff82312e28>] ? xen_start_kernel+0x586/0x588
> [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]---
>
>
>
>
>
> Thursday, February 6, 2014, 12:36:31 PM, you wrote:
>
>> Hi Dan / Francois,
>
>> Didn't have time to test it before, but the patch doesn't seem to help.
>> I'm still getting the "DMA-API: exceeded 7 overlapping mappings of pfn 55ebe",
>> but i see now i forgot to mention i use r8169.use_dac=1 ...
>
>> Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1)
If you are still hitting this with the patch:
59f2e7df574c dma-debug: fix overlap detection
...then I'm more inclined to think it is an actual positive report.
If you don't mind I'll send some debug patches to narrow this down.
^ permalink raw reply
* Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
From: Sander Eikelenboom @ 2014-02-06 14:27 UTC (permalink / raw)
To: Dan Williams
Cc: Konrad Rzeszutek Wilk, Wei Liu, Francois Romieu,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAPcyv4g2EnCLFWfLfSDnjtwrid2tCq2k6wh-8sPYY06eJpM83A@mail.gmail.com>
Thursday, February 6, 2014, 3:26:09 PM, you wrote:
> On Thu, Feb 6, 2014 at 5:09 AM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>> Hmm ok that last message was false .. sorry for that .. it did happen again without r8169.use_dac=1, it just doesn't seem to happen all the time...
>>
>> Konrad / Wei, do you happen to know of any xen related change that went into 3.14 merge window that relates to dma / xen networking ?
>>
>> --
>> Sander
>>
>> complete stacktrace:
>>
>> [ 342.710738] ------------[ cut here ]------------
>> [ 342.726890] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:491 add_dma_entry+0x105/0x130()
>> [ 342.743210] DMA-API: exceeded 7 overlapping mappings of pfn 40b00
>> [ 342.759510] Modules linked in:
>> [ 342.775557] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc1-20140206-pcireset-net-btrevert+ #1
>> [ 342.791706] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010
>> [ 342.807627] 0000000000000009 ffff88005f603828 ffffffff81ad29fc ffffffff822134e0
>> [ 342.823430] ffff88005f603878 ffff88005f603868 ffffffff810bdf62 ffff880000000000
>> [ 342.839081] 0000000000040b00 00000000ffffffef ffffffff822102e0 ffff8800592b9098
>> [ 342.854572] Call Trace:
>> [ 342.869748] <IRQ> [<ffffffff81ad29fc>] dump_stack+0x46/0x58
>> [ 342.884915] [<ffffffff810bdf62>] warn_slowpath_common+0x82/0xb0
>> [ 342.899710] [<ffffffff810be031>] warn_slowpath_fmt+0x41/0x50
>> [ 342.914395] [<ffffffff8147853a>] ? active_pfn_read_overlap+0x3a/0x70
>> [ 342.929166] [<ffffffff814792c5>] add_dma_entry+0x105/0x130
>> [ 342.943733] [<ffffffff814796c6>] debug_dma_map_page+0x126/0x150
>> [ 342.957988] [<ffffffff8171c8b6>] rtl8169_start_xmit+0x216/0xa20
>> [ 342.972306] [<ffffffff8195f08f>] ? dev_queue_xmit_nit+0x1ef/0x260
>> [ 342.986523] [<ffffffff8195eea0>] ? dev_loopback_xmit+0x1e0/0x1e0
>> [ 343.000689] [<ffffffff819631e6>] dev_hard_start_xmit+0x2e6/0x4a0
>> [ 343.014466] [<ffffffff81980f3e>] sch_direct_xmit+0xfe/0x280
>> [ 343.028052] [<ffffffff819635dc>] __dev_queue_xmit+0x23c/0x630
>> [ 343.041338] [<ffffffff819633a0>] ? dev_hard_start_xmit+0x4a0/0x4a0
>> [ 343.054483] [<ffffffff81a0a334>] ? ip_output+0x54/0xf0
>> [ 343.067659] [<ffffffff819639eb>] dev_queue_xmit+0xb/0x10
>> [ 343.080804] [<ffffffff81a0890b>] ip_finish_output+0x2cb/0x670
>> [ 343.093746] [<ffffffff81a0a334>] ? ip_output+0x54/0xf0
>> [ 343.106391] [<ffffffff81a0a334>] ip_output+0x54/0xf0
>> [ 343.118683] [<ffffffff81a05791>] ip_forward_finish+0x71/0x1a0
>> [ 343.130901] [<ffffffff81a05a63>] ip_forward+0x1a3/0x440
>> [ 343.142829] [<ffffffff810ffebb>] ? lock_is_held+0x8b/0xb0
>> [ 343.154346] [<ffffffff81a035c0>] ip_rcv_finish+0x150/0x660
>> [ 343.165748] [<ffffffff81a0406b>] ip_rcv+0x22b/0x370
>> [ 343.176838] [<ffffffff81a60972>] ? packet_rcv_spkt+0x42/0x190
>> [ 343.187659] [<ffffffff819609d2>] __netif_receive_skb_core+0x6d2/0x8a0
>> [ 343.198209] [<ffffffff81960414>] ? __netif_receive_skb_core+0x114/0x8a0
>> [ 343.208819] [<ffffffff81009010>] ? xen_clocksource_read+0x20/0x30
>> [ 343.219471] [<ffffffff81116e49>] ? getnstimeofday+0x9/0x30
>> [ 343.229862] [<ffffffff81960bbc>] __netif_receive_skb+0x1c/0x70
>> [ 343.239953] [<ffffffff81960c2e>] netif_receive_skb_internal+0x1e/0xf0
>> [ 343.249908] [<ffffffff81962110>] napi_gro_receive+0x70/0xa0
>> [ 343.259509] [<ffffffff817198a3>] rtl8169_poll+0x2d3/0x680
>> [ 343.268982] [<ffffffff81adcd2b>] ? _raw_spin_unlock_irq+0x2b/0x50
>> [ 343.278091] [<ffffffff819610d1>] net_rx_action+0x161/0x260
>> [ 343.287056] [<ffffffff810c28ec>] __do_softirq+0x12c/0x280
>> [ 343.295756] [<ffffffff810c2da2>] irq_exit+0xa2/0xd0
>> [ 343.304235] [<ffffffff814ffd5f>] xen_evtchn_do_upcall+0x2f/0x40
>> [ 343.312387] [<ffffffff81adf15e>] xen_do_hypervisor_callback+0x1e/0x30
>> [ 343.320389] <EOI> [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>> [ 343.328171] [<ffffffff810013aa>] ? xen_hypercall_sched_op+0xa/0x20
>> [ 343.335738] [<ffffffff81008c70>] ? xen_safe_halt+0x10/0x20
>> [ 343.343142] [<ffffffff81018748>] ? default_idle+0x18/0x20
>> [ 343.350202] [<ffffffff81018f5e>] ? arch_cpu_idle+0x2e/0x40
>> [ 343.356994] [<ffffffff8110b551>] ? cpu_startup_entry+0x91/0x1e0
>> [ 343.363658] [<ffffffff81ac7d87>] ? rest_init+0xb7/0xc0
>> [ 343.369924] [<ffffffff81ac7cd0>] ? csum_partial_copy_generic+0x170/0x170
>> [ 343.376057] [<ffffffff8230ff1c>] ? start_kernel+0x409/0x416
>> [ 343.381972] [<ffffffff8230f912>] ? repair_env_string+0x5e/0x5e
>> [ 343.387573] [<ffffffff8230f5f8>] ? x86_64_start_reservations+0x2a/0x2c
>> [ 343.393152] [<ffffffff82312e28>] ? xen_start_kernel+0x586/0x588
>> [ 343.398628] ---[ end trace 8379b598fb7ef5ee ]---
>>
>>
>>
>>
>>
>> Thursday, February 6, 2014, 12:36:31 PM, you wrote:
>>
>>> Hi Dan / Francois,
>>
>>> Didn't have time to test it before, but the patch doesn't seem to help.
>>> I'm still getting the "DMA-API: exceeded 7 overlapping mappings of pfn 55ebe",
>>> but i see now i forgot to mention i use r8169.use_dac=1 ...
>>
>>> Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1)
> If you are still hitting this with the patch:
> 59f2e7df574c dma-debug: fix overlap detection
> ...then I'm more inclined to think it is an actual positive report.
> If you don't mind I'll send some debug patches to narrow this down.
Please do .. sounds better than bisecting :-)
^ permalink raw reply
* AX88179_178A USB3 ethernet adapter performance issue
From: Daniel J Blueman @ 2014-02-06 14:33 UTC (permalink / raw)
To: Freddy Xin; +Cc: Netdev
Hi Freddy et al,
I'm experiencing poor network performance using an ASIX AX88179_178A
USB3 to ethernet adapter using any recent linux kernel (eg 3.11),
using an Intel XHCI USB3 controller.
Running iperf tests between one host with a gigabit PCIe NIC, via a
gigabit switch to the other host with various interfaces:
PCIe bcm957762: send 818Mb/s, recv 910Mb/s
USB2 smsc75xx: send 341Mb/s, recv 330Mb/s
USB3 ax88179_178a: send 347Mb/s, recv 18.7Mb/s
Are you able to reproduce the same 19Mb/s receive rate there?
Many thanks,
Daniel
--
Daniel J Blueman
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: enable anycast addresses as source addresses in ICMPv6 error messages
From: François-Xavier Le Bail @ 2014-02-06 14:30 UTC (permalink / raw)
To: nicolas.dichtel@6wind.com, netdev@vger.kernel.org
Cc: David Stevens, Bill Fink, Hannes Frederic Sowa, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki Yoshifuji,
Patrick McHardy
In-Reply-To: <52F395BB.2030209@6wind.com>
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> To: François-Xavier Le Bail <fx.lebail@yahoo.com>; "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Cc: David Stevens <dlstevens@us.ibm.com>; Bill Fink <billfink@mindspring.com>; Hannes Frederic Sowa <hannes@stressinduktion.org>; David S. Miller <davem@davemloft.net>; Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>; James Morris <jmorris@namei.org>; Hideaki Yoshifuji <yoshfuji@linux-ipv6.org>; Patrick McHardy <kaber@trash.net>
> Sent: Thursday, February 6, 2014 3:01 PM
> Subject: Re: [PATCH net-next v2] ipv6: enable anycast addresses as source addresses in ICMPv6 error messages
>
> Le 06/02/2014 13:38, François-Xavier Le Bail a écrit :
>>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>
>>
>>> Subject: Re: [PATCH net-next v2] ipv6: enable anycast addresses as
> source addresses in ICMPv6 error messages
>>>
>>> Le 19/01/2014 17:00, Francois-Xavier Le Bail a écrit :
>>>
>>>> - Uses ipv6_anycast_destination() in icmp6_send().
>>>>
>>>> Suggested-by: Bill Fink <billfink@mindspring.com>
>>>> Signed-off-by: Francois-Xavier Le Bail
> <fx.lebail@yahoo.com>
>>> This patch causes an Oops on my target.
>>
>> What is your target ?
> x86 32bits
>
>>
>>> Here is the step to reproduce it:
>>> modprobe sit
>>> ip link add sit1 type sit remote 10.16.0.121 local 10.16.0.249
>>> ip l s sit1 up
>>> ip -6 a a dev sit1 2001:1234::123 remote 2001:1234::121
>>> ping6 2001:1234::121
>>
>> I cannot reproduce this in my target (updated net-next x86_64) and
>> iproute2 from git.
> I use linus tree (3.14-rc1+).
>
>> Can you send me your config file ?
> See attachment.
>
>
>>
>>> The problem is that ipv6_anycast_destination() uses unconditionally
>>> skb_dst(skb), which is NULL in this case.
>>>
>>> Not sure what is the best way to fix this, any suggestions?
>>
>> I will try to reproduce first and see.
> Note that the peer was not set up, hence the ping didn't work.
> ipip6_err() calls ipip6_err_gen_icmpv6_unreach() which will drop the dst
> before calling icmpv6_send().
>
>
> Here is the backtrace:
> [ 387.786155] BUG: unable to handle kernel NULL pointer dereference at 00000096
> [ 387.787291] IP: [<c12f1568>] icmp6_send+0x79/0x596
[...]
> [ 387.790055] [<f85ce03b>] ? tunnel64_err+0x16/0x25 [tunnel4]
Thanks for these informations.
Can you test an alternative replacing:
test on: ipv6_anycast_destination(skb)
by
test on: ipv6_chk_acast_addr_src(net, skb->dev, &hdr->daddr)
Greetings
^ permalink raw reply
* Re: Disabling autoneg and enforcing speed/duplex
From: Rob Herring @ 2014-02-06 14:50 UTC (permalink / raw)
To: Gerlando Falauto
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Grant Likely,
Sebastian Hesselbarth, Brunck, Holger
In-Reply-To: <52F3796B.8050809-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org>
On Thu, Feb 6, 2014 at 6:00 AM, Gerlando Falauto
<gerlando.falauto-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org> wrote:
> Hi,
>
> I'm using the Kirkwood Ethernet controller (mv643xx_eth.c) with a Marvell
> 88E3018 PHY which needs to be set in forced 100Base-TX mode.
>
> Thanks to Sebastian's addition of DT support to the ethernet driver, I can
> easily set speed and duplex within the ethernet's port node, therefore
> leaving the phy unmanaged -- this works fine (I guess this mode is set on
> the phy by the bootloader or by strap settings).
>
> However, this PHY has an erratum whose workaround requires some registers be
> written -- I believe the natural solution would be to start managing the PHY
> (i.e. set "phy-handle") and implement the proper workaround within
> drivers/net/phy/marvell.c. Making the PHY managed does however enable
> autoneg and therefore break everything.
>
> Which brings me to my question: shouldn't there be a way to specify some
> forced settings within the PHY's node for such cases?
>
> Only thing I found vaguely resembling what I'm looking for is Florian's
> patch introducing "max-speed" in the PHY -- not quite the same thing though.
> Which, if I understand it correctly, implements it as a property of the PHY,
> whereas ePAPR specifies it as a property of the ethernet device (which makes
> sense, since you might want to connect a 10/100 MII to a 10/100/1000 PHY and
> therefore have the MII restrict the capabilities of the PHY).
You shouldn't need a property in this case. The driver knows what the
h/w is limited to and can configure the phy based on that. It is when
both sides should support a higher speed and you need to limit it for
some other reason like errata or board level configuration.
> Or perhaps I'm missing some important bits here?
Does this patch help you:
https://lkml.org/lkml/2014/1/15/533
Rob
>
> Thanks!
> Gerlando
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Disabling autoneg and enforcing speed/duplex
From: Gerlando Falauto @ 2014-02-06 15:00 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, netdev@vger.kernel.org, Grant Likely,
Sebastian Hesselbarth, Brunck, Holger
In-Reply-To: <CAL_JsqJ=Me+MKF8DGMsh=0y4VLmekUHD7KgmQDkCpDEuKVOT+w@mail.gmail.com>
Hi Rob,
thanks for your reply.
On 02/06/2014 03:50 PM, Rob Herring wrote:
> On Thu, Feb 6, 2014 at 6:00 AM, Gerlando Falauto
> <gerlando.falauto@keymile.com> wrote:
>> Hi,
>>
>> I'm using the Kirkwood Ethernet controller (mv643xx_eth.c) with a Marvell
>> 88E3018 PHY which needs to be set in forced 100Base-TX mode.
>>
>> Thanks to Sebastian's addition of DT support to the ethernet driver, I can
>> easily set speed and duplex within the ethernet's port node, therefore
>> leaving the phy unmanaged -- this works fine (I guess this mode is set on
>> the phy by the bootloader or by strap settings).
>>
>> However, this PHY has an erratum whose workaround requires some registers be
>> written -- I believe the natural solution would be to start managing the PHY
>> (i.e. set "phy-handle") and implement the proper workaround within
>> drivers/net/phy/marvell.c. Making the PHY managed does however enable
>> autoneg and therefore break everything.
>>
>> Which brings me to my question: shouldn't there be a way to specify some
>> forced settings within the PHY's node for such cases?
>>
>> Only thing I found vaguely resembling what I'm looking for is Florian's
>> patch introducing "max-speed" in the PHY -- not quite the same thing though.
>> Which, if I understand it correctly, implements it as a property of the PHY,
>> whereas ePAPR specifies it as a property of the ethernet device (which makes
>> sense, since you might want to connect a 10/100 MII to a 10/100/1000 PHY and
>> therefore have the MII restrict the capabilities of the PHY).
>
> You shouldn't need a property in this case. The driver knows what the
> h/w is limited to and can configure the phy based on that.
I see, you're right.
> It is when
> both sides should support a higher speed and you need to limit it for
> some other reason like errata or board level configuration.
Which is exactly my case. The phy should be configured to work in
100Base-TX mode, full duplex.
>> Or perhaps I'm missing some important bits here?
>
> Does this patch help you:
>
> https://lkml.org/lkml/2014/1/15/533
I think so... So I guess I should jest set all
phy-mii-advertise-10full = <0>;
...
phy-mii-advertise-100full = <1>;
...
is that right?
I'll test it and let you know.
Thanks!
Gerlando
>
> Rob
>
>>
>> Thanks!
>> Gerlando
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: asix: fix bad header length bug
From: Emil Goode @ 2014-02-06 15:02 UTC (permalink / raw)
To: David Laight
Cc: David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher, Glen Turner,
linux-usb@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6B98CA@AcuExch.aculab.com>
Hello David,
Thank's for the review.
On Thu, Feb 06, 2014 at 01:37:12PM +0000, David Laight wrote:
> From: Emil Goode
> > The AX88772B occasionally send rx packets that cross urb boundaries
> > and the remaining partial packet is sent with no header.
> > When the buffer with a partial packet is of less number of octets
> > than the value of hard_header_len the buffer is discarded by the
> > usbnet module. This is causing dropped packages and error messages
> > in dmesg.
> >
> > This can be reproduced by using ping with a packet size
> > between 1965-1976.
>
> I think this can affect other USB ethernet drivers.
> Probably most of the ones that explicitly set rx_urb_len.
>
> The ax88179_178a driver sets massive 20k receive urb.
The ax88179_178a has it's own bind function, so I believe it's
not affected by this change.
> I've seen over 10k of data in a single urb, dunno if it
> can actually generate more than 20k - possibly if the usb3 link
> is loaded with other traffic.
> It would be much more efficient for it to use an aligned 4k urb
> and then merge the fragment into skbs.
>
> Once you've set:
> + dev->net->hard_header_len = 0; /* Partial packets have no header */
> try setting the mtu to a multiple of 1k.
I tried setting the mtu to 2000 and when using ping with a large enough
packet size to fill the urb to rx_urb_size all packages are dropped.
> There is a very odd check in usbnet_change_mtu() that tries to stop the
> receive urb_length being a multiple of the usb packet size.
This is very odd indeed!
>
> This code looks as though it is hoping that the usb controller will discard
> any full length bulk messages after finding a short buffer.
> I suspect that might be just wishful thinking!
>
> David
>
>
>
^ permalink raw reply
* RE: [PATCH] bnx2x: Update to FW 7.8.19
From: Yuval Mintz @ 2014-02-06 15:26 UTC (permalink / raw)
To: dwmw2@infradead.org, ben@decadent.org.uk
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Ariel Elior
In-Reply-To: <1390921061-22019-1-git-send-email-yuvalmin@broadcom.com>
> This new firmware fixes several bugs:
> 1. HW attention appears and traffic stops when iSCSI firmware tries to
> retransmit iSCSI login command when the iSCSI login is carrying data
> not aligned to 4-bytes.
> 2. FCoE traffic fails to run when running in switch-independent multi-function
> mode and there's more than one interface supporting FCoE on a given port.
> 3. While two ports are running FCoE with at least one of them has a function
> number (>1) on the same engine in a 4-port device a zeroed CQE is given,
> causing FCoE traffic to stop.
Hi, any news about this one?
Thanks,
Yuval
^ permalink raw reply
* RE: [PATCH] net: asix: fix bad header length bug
From: David Laight @ 2014-02-06 15:28 UTC (permalink / raw)
To: 'Igor Gnatenko', Emil Goode
Cc: David S. Miller, Ming Lei, Mark Brown, Jeff Kirsher, Glen Turner,
linux-usb@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1391692768.2843.4.camel@X1Carbon.localdomain>
From: Igor Gnatenko
> On Thu, 2014-02-06 at 13:56 +0100, Emil Goode wrote:
> > The AX88772B occasionally send rx packets that cross urb boundaries
> > and the remaining partial packet is sent with no header.
> > When the buffer with a partial packet is of less number of octets
> > than the value of hard_header_len the buffer is discarded by the
> > usbnet module. This is causing dropped packages and error messages
> > in dmesg.
> >
> > This can be reproduced by using ping with a packet size
> > between 1965-1976.
> >
> > The bug has been reported here:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=29082
> >
> > Signed-off-by: Emil Goode <emilgoode@gmail.com>
> Reported-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
> > ---
> > drivers/net/usb/asix_devices.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
> > index 9765a7d..120bb29 100644
> > --- a/drivers/net/usb/asix_devices.c
> > +++ b/drivers/net/usb/asix_devices.c
> > @@ -455,6 +455,7 @@ static int ax88772_bind(struct usbnet *dev, struct usb_interface *intf)
> > dev->net->ethtool_ops = &ax88772_ethtool_ops;
> > dev->net->needed_headroom = 4; /* cf asix_tx_fixup() */
> > dev->net->needed_tailroom = 4; /* cf asix_tx_fixup() */
> > + dev->net->hard_header_len = 0; /* Partial packets have no header */
That is the wrong place for the fix.
It should only be done when rx_urb_size is set to a multiple of the usb
packet size.
That is only done for some of the supported devices.
In fact, if the rx_urb_size is a multiple of the usb frame size (or 1k)
then maybe the usbnet code should assume that the driver is capable
of processing ethernet frames that cross usb packet boundaries and
not delete short packets at all - regardless of the hard_header_len.
David
^ permalink raw reply
* RE: AX88179_178A USB3 ethernet adapter performance issue
From: David Laight @ 2014-02-06 15:39 UTC (permalink / raw)
To: 'Daniel J Blueman', Freddy Xin, linux-usb@vger.kernel.org,
'Sarah Sharp', Greg Kroah-Hartman
Cc: Netdev
In-Reply-To: <CAMVG2ssoBwk56n-k5VB9yO2LP4wc+gTv4o_17r-WYakwE6h2uQ@mail.gmail.com>
From: Daniel J Blueman
> Hi Freddy et al,
I've copied this to linux-usb.
> I'm experiencing poor network performance using an ASIX AX88179_178A
> USB3 to ethernet adapter using any recent linux kernel (eg 3.11),
> using an Intel XHCI USB3 controller.
There a several problems with the xhci driver that show up when
trying to use the ax88179_178a driver.
Unfortunately some of the fixes have caused regressions on other
host controllers with disk transfers.
The patches may, or may not, be present in your kernel.
The 'scatter-gather' support that is used in order to enable TSO
is particularly good at exercising the buggy code paths.
> Running iperf tests between one host with a gigabit PCIe NIC, via a
> gigabit switch to the other host with various interfaces:
>
> PCIe bcm957762: send 818Mb/s, recv 910Mb/s
> USB2 smsc75xx: send 341Mb/s, recv 330Mb/s
> USB3 ax88179_178a: send 347Mb/s, recv 18.7Mb/s
>
> Are you able to reproduce the same 19Mb/s receive rate there?
It might be that you are only actually running at USB2 speeds
(check with lsusb -t).
I have seem line rate Ge from my ax88179 card, but only with a
patched kernel.
David
>
> Many thanks,
> Daniel
> --
> Daniel J Blueman
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: enable anycast addresses as source addresses in ICMPv6 error messages
From: Nicolas Dichtel @ 2014-02-06 16:29 UTC (permalink / raw)
To: François-Xavier Le Bail, netdev@vger.kernel.org
Cc: David Stevens, Bill Fink, Hannes Frederic Sowa, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki Yoshifuji,
Patrick McHardy
In-Reply-To: <1391697041.6325.YahooMailNeo@web125505.mail.ne1.yahoo.com>
Le 06/02/2014 15:30, François-Xavier Le Bail a écrit :
>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
>> To: François-Xavier Le Bail <fx.lebail@yahoo.com>; "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>> Cc: David Stevens <dlstevens@us.ibm.com>; Bill Fink <billfink@mindspring.com>; Hannes Frederic Sowa <hannes@stressinduktion.org>; David S. Miller <davem@davemloft.net>; Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>; James Morris <jmorris@namei.org>; Hideaki Yoshifuji <yoshfuji@linux-ipv6.org>; Patrick McHardy <kaber@trash.net>
>> Sent: Thursday, February 6, 2014 3:01 PM
>> Subject: Re: [PATCH net-next v2] ipv6: enable anycast addresses as source addresses in ICMPv6 error messages
>>
>> Le 06/02/2014 13:38, François-Xavier Le Bail a écrit :
>>>> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>>>
>>>
>>>> Subject: Re: [PATCH net-next v2] ipv6: enable anycast addresses as
>> source addresses in ICMPv6 error messages
>>>>
>>>> Le 19/01/2014 17:00, Francois-Xavier Le Bail a écrit :
>>>>
>>>>> - Uses ipv6_anycast_destination() in icmp6_send().
>>>>>
>>>>> Suggested-by: Bill Fink <billfink@mindspring.com>
>>>>> Signed-off-by: Francois-Xavier Le Bail
>> <fx.lebail@yahoo.com>
>>>> This patch causes an Oops on my target.
>>>
>>> What is your target ?
>> x86 32bits
>>
>>>
>>>> Here is the step to reproduce it:
>>>> modprobe sit
>>>> ip link add sit1 type sit remote 10.16.0.121 local 10.16.0.249
>>>> ip l s sit1 up
>>>> ip -6 a a dev sit1 2001:1234::123 remote 2001:1234::121
>>>> ping6 2001:1234::121
>>>
>>> I cannot reproduce this in my target (updated net-next x86_64) and
>>> iproute2 from git.
>> I use linus tree (3.14-rc1+).
>>
>>> Can you send me your config file ?
>> See attachment.
>>
>>
>>>
>>>> The problem is that ipv6_anycast_destination() uses unconditionally
>>>> skb_dst(skb), which is NULL in this case.
>>>>
>>>> Not sure what is the best way to fix this, any suggestions?
>>>
>>> I will try to reproduce first and see.
>> Note that the peer was not set up, hence the ping didn't work.
>> ipip6_err() calls ipip6_err_gen_icmpv6_unreach() which will drop the dst
>> before calling icmpv6_send().
>>
>>
>> Here is the backtrace:
>> [ 387.786155] BUG: unable to handle kernel NULL pointer dereference at 00000096
>> [ 387.787291] IP: [<c12f1568>] icmp6_send+0x79/0x596
>
> [...]
>
>> [ 387.790055] [<f85ce03b>] ? tunnel64_err+0x16/0x25 [tunnel4]
>
> Thanks for these informations.
>
> Can you test an alternative replacing:
>
> test on: ipv6_anycast_destination(skb)
> by
> test on: ipv6_chk_acast_addr_src(net, skb->dev, &hdr->daddr)
Ok, I will do it tomorrow.
Thank you,
Nicolas
^ permalink raw reply
* [PATCH-net] drivers/net: fix build warning in ethernet/sfc/tx.c
From: Paul Gortmaker @ 2014-02-06 16:45 UTC (permalink / raw)
To: netdev; +Cc: linux-net-drivers, Paul Gortmaker, Jon Cooper, Ben Hutchings
Commit ee45fd92c739db5b7950163d91dfe5f016af6d24 ("sfc: Use TX PIO
for sufficiently small packets") introduced the following warning:
drivers/net/ethernet/sfc/tx.c: In function 'efx_enqueue_skb':
drivers/net/ethernet/sfc/tx.c:432:1: warning: label 'finish_packet' defined but not used
Stick the label inside the same #ifdef that the code which calls
it uses. Note that this is only seen for arch that do not set
ARCH_HAS_IOREMAP_WC, such as arm, mips, sparc, ..., as the others
enable the write combining code and hence use the label.
Cc: Jon Cooper <jcooper@solarflare.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/ethernet/sfc/tx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
index c49d1fb16965..75d11fa4eb0a 100644
--- a/drivers/net/ethernet/sfc/tx.c
+++ b/drivers/net/ethernet/sfc/tx.c
@@ -429,7 +429,9 @@ netdev_tx_t efx_enqueue_skb(struct efx_tx_queue *tx_queue, struct sk_buff *skb)
}
/* Transfer ownership of the skb to the final buffer */
+#ifdef EFX_USE_PIO
finish_packet:
+#endif
buffer->skb = skb;
buffer->flags = EFX_TX_BUF_SKB | dma_flags;
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH v2 0/5] net: phy: Ethernet PHY powerdown optimization
From: Ezequiel Garcia @ 2014-02-06 16:57 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: David Miller, f.fainelli, mugunthanvnm, netdev, linux-arm-kernel,
linux-kernel, Andrew Lunn
In-Reply-To: <52F141AE.8010402@gmail.com>
Hi Sebastian,
On Tue, Feb 04, 2014 at 08:38:22PM +0100, Sebastian Hesselbarth wrote:
> On 12/17/2013 08:43 PM, David Miller wrote:
> > From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> > Date: Fri, 13 Dec 2013 10:20:24 +0100
> >
> >> This is v2 of the ethernet PHY power optimization patches to reduce
> >> power consumption of network PHYs with link that are either unused or
> >> the corresponding netdev is down.
> >>
> >> Compared to the last version, this patch set drops a patch to disable
> >> unused PHYs after late initcall, as it is not compatible with a modular
> >> mdio bus [1]. I'll investigate different ways to have a modular mdio bus
> >> driver get notified when driver loading is done.
> >>
> >> Again, a branch with v2 applied to v3.13-rc2 can also be found at
> >> https://github.com/shesselba/linux-dove.git topic/ethphy-power-v2
> >>
> >> [1] http://www.spinics.net/lists/arm-kernel/msg293028.html
> >
> > Series applied, thanks.
> >
[..]
>
> as expected the above patches create a Linux to bootloader dependency
> that surfaces dumb bootloaders not initializing PHYs correctly.
>
> Andrew has a Kirkwood based board that does not power-up and restart
> auto-negotiation on the powered down PHY after a warm restart. While
> this specific bootloader allows a soft-workaround by issuing the
> required PHY writes before accessing the interface, others may not.
>
I'm also having this same issue on Kirkwood USI Topkick, running
v3.14-rc1.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH-net] drivers/net: fix build warning in ethernet/sfc/tx.c
From: Shradha Shah @ 2014-02-06 16:59 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: netdev, linux-net-drivers, Jon Cooper, Ben Hutchings
In-Reply-To: <1391705112-27869-1-git-send-email-paul.gortmaker@windriver.com>
On 02/06/2014 04:45 PM, Paul Gortmaker wrote:
> Commit ee45fd92c739db5b7950163d91dfe5f016af6d24 ("sfc: Use TX PIO
> for sufficiently small packets") introduced the following warning:
>
> drivers/net/ethernet/sfc/tx.c: In function 'efx_enqueue_skb':
> drivers/net/ethernet/sfc/tx.c:432:1: warning: label 'finish_packet' defined but not used
>
> Stick the label inside the same #ifdef that the code which calls
> it uses. Note that this is only seen for arch that do not set
> ARCH_HAS_IOREMAP_WC, such as arm, mips, sparc, ..., as the others
> enable the write combining code and hence use the label.
>
> Cc: Jon Cooper <jcooper@solarflare.com>
> Cc: Ben Hutchings <bhutchings@solarflare.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Shradha Shah <sshah@solarflare.com>
> ---
> drivers/net/ethernet/sfc/tx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
> index c49d1fb16965..75d11fa4eb0a 100644
> --- a/drivers/net/ethernet/sfc/tx.c
> +++ b/drivers/net/ethernet/sfc/tx.c
> @@ -429,7 +429,9 @@ netdev_tx_t efx_enqueue_skb(struct efx_tx_queue *tx_queue, struct sk_buff *skb)
> }
>
> /* Transfer ownership of the skb to the final buffer */
> +#ifdef EFX_USE_PIO
> finish_packet:
> +#endif
> buffer->skb = skb;
> buffer->flags = EFX_TX_BUF_SKB | dma_flags;
>
>
^ permalink raw reply
* Re: AX88179_178A USB3 ethernet adapter performance issue
From: Sarah Sharp @ 2014-02-06 17:12 UTC (permalink / raw)
To: David Laight
Cc: 'Daniel J Blueman', Freddy Xin,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman, Netdev
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6B9A21-VkEWCZq2GCInGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
On Thu, Feb 06, 2014 at 03:39:02PM +0000, David Laight wrote:
> From: Daniel J Blueman
> > Hi Freddy et al,
>
> I've copied this to linux-usb.
>
> > I'm experiencing poor network performance using an ASIX AX88179_178A
> > USB3 to ethernet adapter using any recent linux kernel (eg 3.11),
> > using an Intel XHCI USB3 controller.
>
> There a several problems with the xhci driver that show up when
> trying to use the ax88179_178a driver.
> Unfortunately some of the fixes have caused regressions on other
> host controllers with disk transfers.
> The patches may, or may not, be present in your kernel.
> The 'scatter-gather' support that is used in order to enable TSO
> is particularly good at exercising the buggy code paths.
Scatter gather was not added until 3.12. That does not explain the
issues with a 3.11 kernel. (Unless we're hitting the 64-KB boundary
corner case a lot in 3.11.)
> > Running iperf tests between one host with a gigabit PCIe NIC, via a
> > gigabit switch to the other host with various interfaces:
> >
> > PCIe bcm957762: send 818Mb/s, recv 910Mb/s
> > USB2 smsc75xx: send 341Mb/s, recv 330Mb/s
> > USB3 ax88179_178a: send 347Mb/s, recv 18.7Mb/s
> >
> > Are you able to reproduce the same 19Mb/s receive rate there?
Which kernel are these numbers for?
Any chance you can test this adapter on Windows? I would be interested
to see whether the send and recv numbers are also asymmetrical there.
> It might be that you are only actually running at USB2 speeds
> (check with lsusb -t).
>
> I have seem line rate Ge from my ax88179 card, but only with a
> patched kernel.
David, did you mean you have the same line rate as Daniel?
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: AX88179_178A USB3 ethernet adapter performance issue
From: David Laight @ 2014-02-06 17:17 UTC (permalink / raw)
To: 'Sarah Sharp'
Cc: 'Daniel J Blueman', Freddy Xin, linux-usb@vger.kernel.org,
Greg Kroah-Hartman, Netdev
In-Reply-To: <20140206171239.GB16792@xanatos>
From: Sarah Sharp
> > I have seem line rate Ge from my ax88179 card, but only with a
> > patched kernel.
>
> David, did you mean you have the same line rate as Daniel?
No I meant I've seen it saturate a Ge link (with sufficiently large frames).
With very small frames the tx rate gets limited to a nice round number.
Possibly because the usb message rate limit.
It is high enough that it really doesn't matter, the code could put multiple
frames in a single URB, but I'm not sure the NAPI processing loop makes that
easy.
The receive side will run at a higher packet rate.
David
^ permalink raw reply
* [PATCH net] netpoll: fix netconsole IPv6 setup
From: Sabrina Dubroca @ 2014-02-06 17:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Sabrina Dubroca
Currently, to make netconsole start over IPv6, the source address
needs to be specified. Without a source address, netpoll_parse_options
assumes we're setting up over IPv4 and the destination IPv6 address is
rejected.
Check if the IP version has been forced by a source address before
checking for a version mismatch when parsing the destination address.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
---
net/core/netpoll.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index c03f3de..a664f78 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -948,6 +948,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
{
char *cur=opt, *delim;
int ipv6;
+ bool ipversion_set = false;
if (*cur != '@') {
if ((delim = strchr(cur, '@')) == NULL)
@@ -960,6 +961,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
cur++;
if (*cur != '/') {
+ ipversion_set = true;
if ((delim = strchr(cur, '/')) == NULL)
goto parse_failed;
*delim = 0;
@@ -1002,7 +1004,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
ipv6 = netpoll_parse_ip_addr(cur, &np->remote_ip);
if (ipv6 < 0)
goto parse_failed;
- else if (np->ipv6 != (bool)ipv6)
+ else if (ipversion_set && np->ipv6 != (bool)ipv6)
goto parse_failed;
else
np->ipv6 = (bool)ipv6;
--
1.8.5.3
^ permalink raw reply related
* [PATCH] net: use __GFP_NORETRY for high order allocations
From: Eric Dumazet @ 2014-02-06 18:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, David Rientjes, linux-kernel@vger.kernel.org
From: Eric Dumazet <edumazet@google.com>
sock_alloc_send_pskb() & sk_page_frag_refill()
have a loop trying high order allocations to prepare
skb with low number of fragments as this increases performance.
Problem is that under memory pressure/fragmentation, this can
trigger OOM while the intent was only to try the high order
allocations, then fallback to order-0 allocations.
We had various reports from unexpected regressions.
According to David, setting __GFP_NORETRY should be fine,
as the asynchronous compaction is still enabled, and this
will prevent OOM from kicking as in :
CFSClientEventm invoked oom-killer: gfp_mask=0x42d0, order=3, oom_adj=0,
oom_score_adj=0, oom_score_badness=2 (enabled),memcg_scoring=disabled
CFSClientEventm
Call Trace:
[<ffffffff8043766c>] dump_header+0xe1/0x23e
[<ffffffff80437a02>] oom_kill_process+0x6a/0x323
[<ffffffff80438443>] out_of_memory+0x4b3/0x50d
[<ffffffff8043a4a6>] __alloc_pages_may_oom+0xa2/0xc7
[<ffffffff80236f42>] __alloc_pages_nodemask+0x1002/0x17f0
[<ffffffff8024bd23>] alloc_pages_current+0x103/0x2b0
[<ffffffff8028567f>] sk_page_frag_refill+0x8f/0x160
[<ffffffff80295fa0>] tcp_sendmsg+0x560/0xee0
[<ffffffff802a5037>] inet_sendmsg+0x67/0x100
[<ffffffff80283c9c>] __sock_sendmsg_nosec+0x6c/0x90
[<ffffffff80283e85>] sock_sendmsg+0xc5/0xf0
[<ffffffff802847b6>] __sys_sendmsg+0x136/0x430
[<ffffffff80284ec8>] sys_sendmsg+0x88/0x110
[<ffffffff80711472>] system_call_fastpath+0x16/0x1b
Out of Memory: Kill process 2856 (bash) score 9999 or sacrifice child
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: David Rientjes <rientjes@google.com>
---
net/core/sock.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 0c127dcdf6a8..5b6a9431b017 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1775,7 +1775,9 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
while (order) {
if (npages >= 1 << order) {
page = alloc_pages(sk->sk_allocation |
- __GFP_COMP | __GFP_NOWARN,
+ __GFP_COMP |
+ __GFP_NOWARN |
+ __GFP_NORETRY,
order);
if (page)
goto fill_page;
@@ -1845,7 +1847,7 @@ bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio)
gfp_t gfp = prio;
if (order)
- gfp |= __GFP_COMP | __GFP_NOWARN;
+ gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
pfrag->page = alloc_pages(gfp, order);
if (likely(pfrag->page)) {
pfrag->offset = 0;
^ permalink raw reply related
* Re: 3.14-mw regression: rtl8169 WARNING: DMA-API: exceeded 7 overlapping mappings of pfn 55ebe
From: Dan Williams @ 2014-02-06 19:12 UTC (permalink / raw)
To: Sander Eikelenboom
Cc: Konrad Rzeszutek Wilk, Wei Liu, Francois Romieu,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <932118392.20140206152722@eikelenboom.it>
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
On Thu, Feb 6, 2014 at 6:27 AM, Sander Eikelenboom <linux@eikelenboom.it> wrote:
>>>> Not using it seems to prevent the warning, but before 3.14 i have never seen this (with r8169.use_dac=1)
>
>> If you are still hitting this with the patch:
>
>> 59f2e7df574c dma-debug: fix overlap detection
>
>> ...then I'm more inclined to think it is an actual positive report.
>
>> If you don't mind I'll send some debug patches to narrow this down.
>
> Please do .. sounds better than bisecting :-)
>
Hi, attached is a patch that should give some insight whether the
driver is triggering many overlapping mappings. Try it on top of
3.14-rc1.
Thank you for the debug help!
[-- Attachment #2: debug-overlap --]
[-- Type: application/octet-stream, Size: 1965 bytes --]
debug overlap overflow
From: Dan Williams <dan.j.williams@intel.com>
---
drivers/net/ethernet/realtek/r8169.c | 6 ++++++
lib/dma-debug.c | 7 ++++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 91a67ae8f17b..3bb2c1e000be 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5809,6 +5809,9 @@ static void rtl8169_unmap_tx_skb(struct device *d, struct ring_info *tx_skb,
{
unsigned int len = tx_skb->len;
+ trace_printk("%s %s: unmap addr: %#llx len: %u\n",
+ dev_driver_string(d), dev_name(d),
+ (unsigned long long) le64_to_cpu(desc->addr), len);
dma_unmap_single(d, le64_to_cpu(desc->addr), len, DMA_TO_DEVICE);
desc->opts1 = 0x00;
@@ -5999,6 +6002,9 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
len = skb_headlen(skb);
mapping = dma_map_single(d, skb->data, len, DMA_TO_DEVICE);
+ trace_printk("%s %s: map addr: %p dma: %#llx len: %d\n",
+ dev_driver_string(d), dev_name(d),
+ skb->data, (unsigned long long) mapping, len);
if (unlikely(dma_mapping_error(d, mapping))) {
if (net_ratelimit())
netif_err(tp, drv, dev, "Failed to map TX DMA!\n");
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 2defd1308b04..7b22c8f5928e 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -486,9 +486,10 @@ static void active_pfn_inc_overlap(unsigned long pfn)
* debug_dma_assert_idle() as the pfn may be marked idle
* prematurely.
*/
- WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP,
- "DMA-API: exceeded %d overlapping mappings of pfn %lx\n",
- ACTIVE_PFN_MAX_OVERLAP, pfn);
+ if (WARN_ONCE(overlap > ACTIVE_PFN_MAX_OVERLAP,
+ "DMA-API: exceeded %d overlapping mappings of pfn %lx\n",
+ ACTIVE_PFN_MAX_OVERLAP, pfn))
+ ftrace_dump(DUMP_ALL);
}
static int active_pfn_dec_overlap(unsigned long pfn)
^ permalink raw reply related
* [RFC PATCH] udp4: Don't take socket reference in receive path
From: Tom Herbert @ 2014-02-06 19:58 UTC (permalink / raw)
To: davem, netdev, edumazet
The reference counting in the UDP receive path is quite expensive for
a socket that is share amoungst CPUs. This is probably true for normal
sockets, but really is painful when just using the socket for
receive encapsulation.
udp4_lib_lookup always takes a socket reference, and we also put back
the reference after calling udp_queue_rcv_skb in the normal receive
path, so the need for taking the reference seems to be to hold the
socket after doing rcu_read_unlock. This patch modifies udp_lib_lookup
to optionally take a reference and is always called with rcu_read_lock.
In udp4_lib_rcv we call lib_lookup and udp_queue_rcv under the
rcu_read_lock but without having taken the reference.
Requesting comments because I suspect there are nuances to this!
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/udp.c | 90 ++++++++++++++++++++++++++++++++++++++++------------------
1 file changed, 62 insertions(+), 28 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 48d8cb2..6043a2f 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -424,7 +424,8 @@ static unsigned int udp_ehashfn(struct net *net, const __be32 laddr,
static struct sock *udp4_lib_lookup2(struct net *net,
__be32 saddr, __be16 sport,
__be32 daddr, unsigned int hnum, int dif,
- struct udp_hslot *hslot2, unsigned int slot2)
+ struct udp_hslot *hslot2, unsigned int slot2,
+ bool get_ref)
{
struct sock *sk, *result;
struct hlist_nulls_node *node;
@@ -461,12 +462,20 @@ begin:
if (get_nulls_value(node) != slot2)
goto begin;
if (result) {
- if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
- result = NULL;
- else if (unlikely(compute_score2(result, net, saddr, sport,
- daddr, hnum, dif) < badness)) {
- sock_put(result);
- goto begin;
+ if (get_ref) {
+ if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
+ result = NULL;
+ else if (unlikely(compute_score2(result, net, saddr, sport,
+- daddr, hnum, dif) < badness)) {
+ sock_put(result);
+ goto begin;
+ }
+ } else {
+ if (unlikely(atomic_read(&result->sk_refcnt) == 0))
+ result = NULL;
+ else if (unlikely(compute_score2(result, net, saddr, sport,
+- daddr, hnum, dif) < badness))
+ goto begin;
}
}
return result;
@@ -475,9 +484,10 @@ begin:
/* UDP is nearly always wildcards out the wazoo, it makes no sense to try
* harder than this. -DaveM
*/
-struct sock *__udp4_lib_lookup(struct net *net, __be32 saddr,
+/* called with read_rcu_lock() */
+struct sock *___udp4_lib_lookup(struct net *net, __be32 saddr,
__be16 sport, __be32 daddr, __be16 dport,
- int dif, struct udp_table *udptable)
+ int dif, struct udp_table *udptable, bool get_ref)
{
struct sock *sk, *result;
struct hlist_nulls_node *node;
@@ -487,7 +497,6 @@ struct sock *__udp4_lib_lookup(struct net *net, __be32 saddr,
int score, badness, matches = 0, reuseport = 0;
u32 hash = 0;
- rcu_read_lock();
if (hslot->count > 10) {
hash2 = udp4_portaddr_hash(net, daddr, hnum);
slot2 = hash2 & udptable->mask;
@@ -497,7 +506,7 @@ struct sock *__udp4_lib_lookup(struct net *net, __be32 saddr,
result = udp4_lib_lookup2(net, saddr, sport,
daddr, hnum, dif,
- hslot2, slot2);
+ hslot2, slot2, get_ref);
if (!result) {
hash2 = udp4_portaddr_hash(net, htonl(INADDR_ANY), hnum);
slot2 = hash2 & udptable->mask;
@@ -507,9 +516,8 @@ struct sock *__udp4_lib_lookup(struct net *net, __be32 saddr,
result = udp4_lib_lookup2(net, saddr, sport,
htonl(INADDR_ANY), hnum, dif,
- hslot2, slot2);
+ hslot2, slot2, get_ref);
}
- rcu_read_unlock();
return result;
}
begin:
@@ -543,28 +551,50 @@ begin:
goto begin;
if (result) {
- if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
- result = NULL;
- else if (unlikely(compute_score(result, net, saddr, hnum, sport,
- daddr, dport, dif) < badness)) {
- sock_put(result);
- goto begin;
+ if (get_ref) {
+ if (unlikely(!atomic_inc_not_zero_hint(&result->sk_refcnt, 2)))
+ result = NULL;
+ else if (unlikely(compute_score(result, net, saddr, hnum, sport,
+ daddr, dport, dif) < badness)) {
+ sock_put(result);
+ goto begin;
+ }
+ } else {
+ if (unlikely(atomic_read(&result->sk_refcnt) == 0))
+ result = NULL;
+ else if (unlikely(compute_score(result, net, saddr, hnum, sport,
+ daddr, dport, dif) < badness))
+ goto begin;
}
}
+ return result;
+}
+
+struct sock *__udp4_lib_lookup(struct net *net, __be32 saddr,
+ __be16 sport, __be32 daddr, __be16 dport,
+ int dif, struct udp_table *udptable)
+{
+ struct sock *result;
+
+ rcu_read_lock();
+ result = ___udp4_lib_lookup(net, saddr, sport, daddr, dport, dif, udptable, true);
rcu_read_unlock();
+
return result;
}
+
EXPORT_SYMBOL_GPL(__udp4_lib_lookup);
+/* called with read_rcu_lock() */
static inline struct sock *__udp4_lib_lookup_skb(struct sk_buff *skb,
__be16 sport, __be16 dport,
struct udp_table *udptable)
{
const struct iphdr *iph = ip_hdr(skb);
- return __udp4_lib_lookup(dev_net(skb_dst(skb)->dev), iph->saddr, sport,
+ return ___udp4_lib_lookup(dev_net(skb_dst(skb)->dev), iph->saddr, sport,
iph->daddr, dport, inet_iif(skb),
- udptable);
+ udptable, false);
}
struct sock *udp4_lib_lookup(struct net *net, __be32 saddr, __be16 sport,
@@ -1755,19 +1785,21 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
if (ret > 0)
return -ret;
return 0;
- } else {
- if (rt->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST))
- return __udp4_lib_mcast_deliver(net, skb, uh,
- saddr, daddr, udptable);
-
- sk = __udp4_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
}
+
+ if (rt->rt_flags & (RTCF_BROADCAST|RTCF_MULTICAST))
+ return __udp4_lib_mcast_deliver(net, skb, uh,
+ saddr, daddr, udptable);
+
+ rcu_read_lock();
+ sk = __udp4_lib_lookup_skb(skb, uh->source, uh->dest, udptable);
+
if (sk != NULL) {
int ret;
ret = udp_queue_rcv_skb(sk, skb);
- sock_put(sk);
+ rcu_read_unlock();
/* a return value > 0 means to resubmit the input, but
* it wants the return to be -protocol, or 0
@@ -1777,6 +1809,8 @@ int __udp4_lib_rcv(struct sk_buff *skb, struct udp_table *udptable,
return 0;
}
+ rcu_read_unlock();
+
if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb))
goto drop;
nf_reset(skb);
--
1.9.0.rc1.175.g0b1dcb5
^ permalink raw reply related
* Re: [PATCH] net: use __GFP_NORETRY for high order allocations
From: Joe Perches @ 2014-02-06 20:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, David Rientjes,
linux-kernel@vger.kernel.org
In-Reply-To: <1391712162.10160.8.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2014-02-06 at 10:42 -0800, Eric Dumazet wrote:
> sock_alloc_send_pskb() & sk_page_frag_refill()
> have a loop trying high order allocations to prepare
> skb with low number of fragments as this increases performance.
>
> Problem is that under memory pressure/fragmentation, this can
> trigger OOM while the intent was only to try the high order
> allocations, then fallback to order-0 allocations.
[]
> Call Trace:
> [<ffffffff8043766c>] dump_header+0xe1/0x23e
> [<ffffffff80437a02>] oom_kill_process+0x6a/0x323
> [<ffffffff80438443>] out_of_memory+0x4b3/0x50d
> [<ffffffff8043a4a6>] __alloc_pages_may_oom+0xa2/0xc7
> [<ffffffff80236f42>] __alloc_pages_nodemask+0x1002/0x17f0
> [<ffffffff8024bd23>] alloc_pages_current+0x103/0x2b0
> [<ffffffff8028567f>] sk_page_frag_refill+0x8f/0x160
[]
> diff --git a/net/core/sock.c b/net/core/sock.c
[]
> @@ -1775,7 +1775,9 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
> while (order) {
> if (npages >= 1 << order) {
> page = alloc_pages(sk->sk_allocation |
> - __GFP_COMP | __GFP_NOWARN,
> + __GFP_COMP |
> + __GFP_NOWARN |
> + __GFP_NORETRY,
> order);
> if (page)
> goto fill_page;
> @@ -1845,7 +1847,7 @@ bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio)
> gfp_t gfp = prio;
>
> if (order)
> - gfp |= __GFP_COMP | __GFP_NOWARN;
> + gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
Perhaps add __GFP_THISNODE too ?
^ permalink raw reply
* Re: [PATCH net] netpoll: fix netconsole IPv6 setup
From: Cong Wang @ 2014-02-06 20:34 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: David Miller, netdev
In-Reply-To: <1391708052-11188-1-git-send-email-sd@queasysnail.net>
On Thu, Feb 6, 2014 at 9:34 AM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> net/core/netpoll.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index c03f3de..a664f78 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -948,6 +948,7 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
> {
> char *cur=opt, *delim;
> int ipv6;
> + bool ipversion_set = false;
>
Or initialize 'ipv6' to -1 and then check if it is -1?
^ 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