* Re: [PATCH v3] net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)
From: David Miller @ 2013-08-30 19:54 UTC (permalink / raw)
To: arvid.brodin; +Cc: netdev, shemminger, joe, jboticario, balferreira
In-Reply-To: <521504E1.5060309@xdin.com>
From: Arvid Brodin <arvid.brodin@xdin.com>
Date: Wed, 21 Aug 2013 20:20:17 +0200
> This is a patch against net-next (2013-08-21).
First of all, your email client corrupted the patch, chopping up long lines
and making whitespace changes to the content of the patch. Please fix this
before resubmitting, and do so by first sending a test patch to yourself
and making sure you can apply the patch you receive in that email. Do not
use attachments to deal with this issue.
> + if (dev->operstate != transition) {
> + write_lock_bh(&dev_base_lock);
> + dev->operstate = transition;
> + write_unlock_bh(&dev_base_lock);
> + netdev_state_change(dev);
> + }
This is racy. And it appears that set_operstate() in net/core/rtnetlink.c
has the same bug, I guess that's what you used as a guide.
Any "test and set" sequence must be guarded completely by the lock, it
doesn't make any sense to only guard the change of the value.
^ permalink raw reply
* 1f324e3 ipv6: Don't depend on per socket memory for neighbour discovery messages
From: Stephen Warren @ 2013-08-30 19:46 UTC (permalink / raw)
To: Thomas Graf, Eric Dumazet, Hannes Frederic Sowa, David S. Miller
Cc: linux-next@vger.kernel.org, netdev@vger.kernel.org
Commit 1f324e3 "ipv6: Don't depend on per socket memory for neighbour
discovery messages" appears to cause issues for me. If I run
next-20130830, I see the issue, but if I then just revert that one
patch, I don't see any problem, and can use the network without issue.
The problem is: with a network device enabled (in my case, a USB
Ethernet dongle, although I don't know if the type is relevant), then
the system appears to hang soon after enabling the interface; neither
the serial console nor the framebuffer echo my typing, and the cursor on
the framebuffer stops flashing. After a short delay, I see the following
kernel spew:
> localhost login: [ 14.390206] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 14.409459] asix 1-1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
> [ 43.172240] INFO: rcu_preempt self-detected stall on CPU
> [ 43.172256] INFO: rcu_preempt self-detected stall on CPU { 0} (t=2100 jiffies g=262 c=261 q=1)
> [ 43.172265] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.11.0-rc7-next-20130830-00020-gf47ee2e #152
> [ 43.172305] [<c00165bc>] (unwind_backtrace+0x0/0x138) from [<c00122cc>] (show_stack+0x10/0x14)
> [ 43.172329] [<c00122cc>] (show_stack+0x10/0x14) from [<c0569af8>] (dump_stack+0x80/0xc4)
> [ 43.172350] [<c0569af8>] (dump_stack+0x80/0xc4) from [<c008997c>] (rcu_check_callbacks+0x35c/0x818)
> [ 43.172367] [<c008997c>] (rcu_check_callbacks+0x35c/0x818) from [<c002fc20>] (update_process_times+0x38/0x64)
> [ 43.172378] [<c002fc20>] (update_process_times+0x38/0x64) from [<c006bcc4>] (tick_sched_timer+0x44/0x74)
> [ 43.172397] [<c006bcc4>] (tick_sched_timer+0x44/0x74) from [<c0042978>] (__run_hrtimer.isra.15+0x58/0x114)
> [ 43.172409] [<c0042978>] (__run_hrtimer.isra.15+0x58/0x114) from [<c00432d0>] (hrtimer_interrupt+0x108/0x2c4)
> [ 43.172420] [<c00432d0>] (hrtimer_interrupt+0x108/0x2c4) from [<c0015934>] (twd_handler+0x2c/0x40)
> [ 43.172429] [<c0015934>] (twd_handler+0x2c/0x40) from [<c0084488>] (handle_percpu_devid_irq+0x68/0x84)
> [ 43.172447] [<c0084488>] (handle_percpu_devid_irq+0x68/0x84) from [<c0080db8>] (generic_handle_irq+0x20/0x30)
> [ 43.172460] [<c0080db8>] (generic_handle_irq+0x20/0x30) from [<c000f914>] (handle_IRQ+0x38/0x94)
> [ 43.172470] [<c000f914>] (handle_IRQ+0x38/0x94) from [<c00086d8>] (gic_handle_irq+0x28/0x5c)
> [ 43.172481] [<c00086d8>] (gic_handle_irq+0x28/0x5c) from [<c0012de0>] (__irq_svc+0x40/0x70)
> [ 43.172485] Exception stack(0xc07c5d20 to 0xc07c5d68)
> [ 43.172492] 5d20: eeb070c8 ee465838 00000303 80000001 eeb070c8 00000000 ee465828 eeb070c8
> [ 43.172500] 5d40: ee465838 00000001 eeb07000 eeb7b480 ee465820 c07c5d68 c056fe34 c056fe5c
> [ 43.172503] 5d60: 80000113 ffffffff
> [ 43.172518] [<c0012de0>] (__irq_svc+0x40/0x70) from [<c056fe5c>] (_raw_read_lock_bh+0x34/0x44)
> [ 43.172539] [<c056fe5c>] (_raw_read_lock_bh+0x34/0x44) from [<c04aa2f4>] (ipv6_chk_mcast_addr+0x2c/0x1b0)
> [ 43.172555] [<c04aa2f4>] (ipv6_chk_mcast_addr+0x2c/0x1b0) from [<c048b130>] (ip6_finish_output2+0x240/0x4fc)
> [ 43.172566] [<c048b130>] (ip6_finish_output2+0x240/0x4fc) from [<c049d724>] (ndisc_send_skb+0x1c8/0x2d8)
> [ 43.172578] [<c049d724>] (ndisc_send_skb+0x1c8/0x2d8) from [<c0490f68>] (addrconf_rs_timer+0x108/0x134)
> [ 43.172589] [<c0490f68>] (addrconf_rs_timer+0x108/0x134) from [<c002f0d4>] (call_timer_fn.isra.20+0x24/0x84)
> [ 43.172598] [<c002f0d4>] (call_timer_fn.isra.20+0x24/0x84) from [<c002f2c8>] (run_timer_softirq+0x194/0x244)
> [ 43.172616] [<c002f2c8>] (run_timer_softirq+0x194/0x244) from [<c0029818>] (__do_softirq+0xe8/0x1d0)
> [ 43.172627] [<c0029818>] (__do_softirq+0xe8/0x1d0) from [<c0029c38>] (irq_exit+0x98/0xe4)
> [ 43.172637] [<c0029c38>] (irq_exit+0x98/0xe4) from [<c000f918>] (handle_IRQ+0x3c/0x94)
> [ 43.172646] [<c000f918>] (handle_IRQ+0x3c/0x94) from [<c00086d8>] (gic_handle_irq+0x28/0x5c)
> [ 43.172655] [<c00086d8>] (gic_handle_irq+0x28/0x5c) from [<c0012de0>] (__irq_svc+0x40/0x70)
> [ 43.172658] Exception stack(0xc07c5f28 to 0xc07c5f70)
> [ 43.172664] 5f20: c07c5f70 3b9aca00 b665e400 00000004 b63d5530 00000004
> [ 43.172671] 5f40: c10880e0 00000000 00000000 c07cc3d4 c0573354 00000000 00000015 c07c5f70
> [ 43.172676] 5f60: c0063658 c038edac 60000113 ffffffff
> [ 43.172696] [<c0012de0>] (__irq_svc+0x40/0x70) from [<c038edac>] (cpuidle_enter_state+0x50/0xe8)
> [ 43.172709] [<c038edac>] (cpuidle_enter_state+0x50/0xe8) from [<c038eefc>] (cpuidle_idle_call+0xb8/0x168)
> [ 43.172719] [<c038eefc>] (cpuidle_idle_call+0xb8/0x168) from [<c000fc60>] (arch_cpu_idle+0x8/0x38)
> [ 43.172730] [<c000fc60>] (arch_cpu_idle+0x8/0x38) from [<c0062924>] (cpu_startup_entry+0x60/0x134)
> [ 43.172750] [<c0062924>] (cpu_startup_entry+0x60/0x134) from [<c0789a28>] (start_kernel+0x2b8/0x30c)
> [ 43.765722] { 1} (t=2159 jiffies g=262 c=261 q=1)
> [ 43.778002] CPU: 1 PID: 539 Comm: NetworkManager Not tainted 3.11.0-rc7-next-20130830-00020-gf47ee2e #152
> [ 43.795156] [<c00165bc>] (unwind_backtrace+0x0/0x138) from [<c00122cc>] (show_stack+0x10/0x14)
> [ 43.811442] [<c00122cc>] (show_stack+0x10/0x14) from [<c0569af8>] (dump_stack+0x80/0xc4)
> [ 43.827204] [<c0569af8>] (dump_stack+0x80/0xc4) from [<c008997c>] (rcu_check_callbacks+0x35c/0x818)
> [ 43.843896] [<c008997c>] (rcu_check_callbacks+0x35c/0x818) from [<c002fc20>] (update_process_times+0x38/0x64)
> [ 43.861541] [<c002fc20>] (update_process_times+0x38/0x64) from [<c006bcc4>] (tick_sched_timer+0x44/0x74)
> [ 43.878779] [<c006bcc4>] (tick_sched_timer+0x44/0x74) from [<c0042978>] (__run_hrtimer.isra.15+0x58/0x114)
> [ 43.896302] [<c0042978>] (__run_hrtimer.isra.15+0x58/0x114) from [<c00432d0>] (hrtimer_interrupt+0x108/0x2c4)
> [ 43.914085] [<c00432d0>] (hrtimer_interrupt+0x108/0x2c4) from [<c0015934>] (twd_handler+0x2c/0x40)
> [ 43.930903] [<c0015934>] (twd_handler+0x2c/0x40) from [<c0084488>] (handle_percpu_devid_irq+0x68/0x84)
> [ 43.948107] [<c0084488>] (handle_percpu_devid_irq+0x68/0x84) from [<c0080db8>] (generic_handle_irq+0x20/0x30)
> [ 43.966008] [<c0080db8>] (generic_handle_irq+0x20/0x30) from [<c000f914>] (handle_IRQ+0x38/0x94)
> [ 43.982745] [<c000f914>] (handle_IRQ+0x38/0x94) from [<c00086d8>] (gic_handle_irq+0x28/0x5c)
> [ 43.999123] [<c00086d8>] (gic_handle_irq+0x28/0x5c) from [<c0012de0>] (__irq_svc+0x40/0x70)
> [ 44.015380] Exception stack(0xedc35be8 to 0xedc35c30)
> [ 44.028267] 5be0: eeb070c8 00000000 00000201 80000001 eeb070c8 eeb070c8
> [ 44.044329] 5c00: eeb07000 eeb071b4 ee4336c0 00000000 edc80a38 00000000 edc80b90 edc35c30
> [ 44.060321] 5c20: c056fe34 c056fe5c 800f0013 ffffffff
> [ 44.073089] [<c0012de0>] (__irq_svc+0x40/0x70) from [<c056fe5c>] (_raw_read_lock_bh+0x34/0x44)
> [ 44.089495] [<c056fe5c>] (_raw_read_lock_bh+0x34/0x44) from [<c049037c>] (inet6_fill_ifla6_attrs+0x300/0x358)
> [ 44.107263] [<c049037c>] (inet6_fill_ifla6_attrs+0x300/0x358) from [<c0490578>] (inet6_fill_ifinfo+0x178/0x1a0)
> [ 44.125244] [<c0490578>] (inet6_fill_ifinfo+0x178/0x1a0) from [<c0490628>] (inet6_dump_ifinfo+0x88/0xe0)
> [ 44.142605] [<c0490628>] (inet6_dump_ifinfo+0x88/0xe0) from [<c042f318>] (netlink_dump+0xa0/0x1d8)
> [ 44.159411] [<c042f318>] (netlink_dump+0xa0/0x1d8) from [<c04300b4>] (__netlink_dump_start+0x100/0x158)
> [ 44.176711] [<c04300b4>] (__netlink_dump_start+0x100/0x158) from [<c0425b90>] (rtnetlink_rcv_msg+0x110/0x1f4)
> [ 44.194593] [<c0425b90>] (rtnetlink_rcv_msg+0x110/0x1f4) from [<c04318c4>] (netlink_rcv_skb+0xac/0xc0)
> [ 44.211854] [<c04318c4>] (netlink_rcv_skb+0xac/0xc0) from [<c04248b8>] (rtnetlink_rcv+0x1c/0x24)
> [ 44.228576] [<c04248b8>] (rtnetlink_rcv+0x1c/0x24) from [<c04312bc>] (netlink_unicast+0x158/0x1b8)
> [ 44.245451] [<c04312bc>] (netlink_unicast+0x158/0x1b8) from [<c0431668>] (netlink_sendmsg+0x2ac/0x360)
> [ 44.262719] [<c0431668>] (netlink_sendmsg+0x2ac/0x360) from [<c04018b4>] (sock_sendmsg+0x88/0xa8)
> [ 44.279477] [<c04018b4>] (sock_sendmsg+0x88/0xa8) from [<c0401c7c>] (___sys_sendmsg+0x2a8/0x2c0)
> [ 44.296134] [<c0401c7c>] (___sys_sendmsg+0x2a8/0x2c0) from [<c0403840>] (__sys_sendmsg+0x3c/0x68)
> [ 44.312870] [<c0403840>] (__sys_sendmsg+0x3c/0x68) from [<c000f060>] (ret_fast_syscall+0x0/0x30)
This repeats every minute.
^ permalink raw reply
* Re: [PATCH 0/7] Drop support for Renesys H8/300 architecture
From: Guenter Roeck @ 2013-08-30 19:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Wim Van Sebroeck, Linux Kernel Mailing List, IDE-ML,
Network Development, Linux Watchdog Mailing List, David S. Miller,
Al Viro, Eric Paris, Greg Kroah-Hartman, Jiang Liu, David Howells,
Thomas Gleixner, Stephen Rothwell
In-Reply-To: <CA+55aFyxHsKhtqqz9jTDYo89bCNqCWhjHGJ4HzFrHnJ0yxLXjQ@mail.gmail.com>
On Fri, Aug 30, 2013 at 12:14:20PM -0700, Linus Torvalds wrote:
> On Fri, Aug 30, 2013 at 12:11 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > I would not mind if Linus would agree to pull it right away for 3.12,
> > but that seems to be a bit on the fast side.
>
> I'm ok with code deletion patches, I don't think that would be a
> problem. I didn't check them, but I assume this is all literally just
> removing code that is conditional on h8/300 config options?
>
Yes.
I found a couple more since I sent the series, but nothing significant.
What is your preference - keep it until 3.13, or prepare it now and send you
a pull request for 3.12 ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCHv2] bridge: separate querier and query timer into IGMP/IPv4 and MLD/IPv6 ones
From: David Miller @ 2013-08-30 19:29 UTC (permalink / raw)
To: linus.luessing
Cc: amwang, netdev, bridge, linux-kernel, linux, stephen, herbert
In-Reply-To: <1377876497-6185-1-git-send-email-linus.luessing@web.de>
From: Linus Lüssing <linus.luessing@web.de>
Date: Fri, 30 Aug 2013 17:28:17 +0200
> Currently we would still potentially suffer multicast packet loss if there
> is just either an IGMP or an MLD querier: For the former case, we would
> possibly drop IPv6 multicast packets, for the latter IPv4 ones. This is
> because we are currently assuming that if either an IGMP or MLD querier
> is present that the other one is present, too.
>
> This patch makes the behaviour and fix added in
> "bridge: disable snooping if there is no querier" (b00589af3b04)
> to also work if there is either just an IGMP or an MLD querier on the
> link: It refines the deactivation of the snooping to be protocol
> specific by using separate timers for the snooped IGMP and MLD queries
> as well as separate timers for our internal IGMP and MLD queriers.
>
> Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Looks great, applied, thanks.
^ permalink raw reply
* Re: [PATCH nf 0/5] IPVS fixes for v3.11
From: Pablo Neira Ayuso @ 2013-08-30 19:26 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1377854068-22340-1-git-send-email-horms@verge.net.au>
Hi Simon,
On Fri, Aug 30, 2013 at 06:14:23PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> I'm not sure if it is too late in the cycle but
> if not could you please consider these fixes for v3.11?
>
> In my opinion these all seem to be -stable candidates.
> I would appreciate your opinion on that.
We're fairly late in the -rc cycle. I prefer to ask David to take
these once 3.11 is released, then ask for -stable inclusion.
Regards.
^ permalink raw reply
* RE: [PATCH 4/4] qlcnic: use standard NAPI weights
From: Himanshu Madhani @ 2013-08-30 19:21 UTC (permalink / raw)
To: Michal Schmidt
Cc: David Miller, netdev, Eric Dumazet, Rajesh Borundia,
Shahed Shaikh, Jitendra Kalsaria, Sony Chacko,
Sucheta Chakraborty, Dept-Eng Linux Driver
In-Reply-To: <5217676D.6000608@redhat.com>
> -----Original Message-----
> From: Michal Schmidt [mailto:mschmidt@redhat.com]
> Sent: Friday, August 23, 2013 6:45 AM
> To: Himanshu Madhani
> Cc: David Miller; netdev; Eric Dumazet; Rajesh Borundia; Shahed Shaikh;
> Jitendra Kalsaria; Sony Chacko; Sucheta Chakraborty; Dept-Eng Linux Driver
> Subject: Re: [PATCH 4/4] qlcnic: use standard NAPI weights
>
> On 08/22/2013 08:51 AM, Himanshu Madhani wrote:
> > We are in process of running performance numbers with these changes.
> > I will respond once I have the performance data with the proposed
> > changes.
>
> OK. I will post a rebased patch 4/4 later if you find no performance loss.
>
> Thanks,
> Michal
The changes are okay. Please resubmit your rebased patch
Acked-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Thanks,
Himanshu
^ permalink raw reply
* Re: [PATCH] net: usbnet: update addr_assign_type if appropriate
From: Bjørn Mork @ 2013-08-30 19:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-usb, oneukum
In-Reply-To: <20130830.151400.1400969856580136990.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> I was hoping to get this fix, via the series. When we have multiple instances
> of the same bug it makes no sense to just fix one, especially now that you're
> done the work to do all of them already.
I see. Sorry for not catching that earlier.
Bjørn
^ permalink raw reply
* Re: [net-next v3 1/8] i40e: main driver core
From: Joe Perches @ 2013-08-30 19:19 UTC (permalink / raw)
To: David Miller
Cc: stephen, jeffrey.t.kirsher, jesse.brandeburg, netdev, gospo,
sassmann, shannon.nelson, peter.p.waskiewicz.jr, e1000-devel
In-Reply-To: <20130830.144000.1005297116915822361.davem@davemloft.net>
On Fri, 2013-08-30 at 14:40 -0400, David Miller wrote:
> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Fri, 30 Aug 2013 11:10:29 -0700
>
> > On Fri, 30 Aug 2013 09:32:48 -0700
> > Joe Perches <joe@perches.com> wrote:
> >
> >> > +static int debug = -1;
> >> > +module_param(debug, int, 0);
> >> > +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
> >>
> >> Maybe make debug a bitfield instead?
> >
> > No Joe, this is the standard mapping of debug to msglevel used
> > by most network devices.
OK, I didn't really know how it was being used here.
There's no real standard for that use btw.
(longish list and another comment below)
$ git grep -E "MODULE_PARM_DESC.*\bdebug\b" drivers/net/ethernet
drivers/net/ethernet/3com/3c509.c:MODULE_PARM_DESC(debug, "debug level (0-6)");
drivers/net/ethernet/3com/3c515.c:MODULE_PARM_DESC(debug, "3c515 debug level (0-6)");
drivers/net/ethernet/3com/3c59x.c:MODULE_PARM_DESC(debug, "3c59x debug level (0-6)");
drivers/net/ethernet/8390/ne2k-pci.c:MODULE_PARM_DESC(debug, "debug level (1-2)");
drivers/net/ethernet/adaptec/starfire.c:MODULE_PARM_DESC(debug, "Debug level (0-6)");
drivers/net/ethernet/amd/atarilance.c:MODULE_PARM_DESC(lance_debug, "atarilance debug level (0-3)");
drivers/net/ethernet/amd/lance.c:MODULE_PARM_DESC(lance_debug, "LANCE/PCnet debug level (0-7)");
drivers/net/ethernet/amd/pcnet32.c:MODULE_PARM_DESC(debug, DRV_NAME " debug level");
drivers/net/ethernet/amd/sun3lance.c:MODULE_PARM_DESC(lance_debug, "SUN3 Lance debug level (0-3)");
drivers/net/ethernet/atheros/atlx/atl1.c:MODULE_PARM_DESC(debug, "Message level (0=none,...,16=all)");
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:MODULE_PARM_DESC(mrrs, " Force Max Read Req Size (0..3) (for debug)");
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:MODULE_PARM_DESC(debug, " Default debug msglevel");
drivers/net/ethernet/broadcom/sb1250-mac.c:MODULE_PARM_DESC(debug, "Debug messages");
drivers/net/ethernet/cirrus/cs89x0.c:MODULE_PARM_DESC(debug, "cs89x0 debug level (0-6)");
drivers/net/ethernet/cirrus/cs89x0.c:MODULE_PARM_DESC(debug, "(ignored)");
drivers/net/ethernet/cirrus/mac89x0.c:MODULE_PARM_DESC(debug, "CS89[02]0 debug level (0-5)");
drivers/net/ethernet/davicom/dm9000.c:MODULE_PARM_DESC(debug, "dm9000 debug level (0-4)");
drivers/net/ethernet/dec/tulip/de2104x.c:MODULE_PARM_DESC (debug, "de2104x bitmapped message enable number");
drivers/net/ethernet/dec/tulip/de4x5.c:MODULE_PARM_DESC(de4x5_debug, "de4x5 debug mask");
drivers/net/ethernet/dec/tulip/dmfe.c:MODULE_PARM_DESC(debug, "Davicom DM9xxx enable debugging (0-1)");
drivers/net/ethernet/dec/tulip/uli526x.c:MODULE_PARM_DESC(debug, "ULi M5261/M5263 enable debugging (0-1)");
drivers/net/ethernet/dec/tulip/winbond-840.c:MODULE_PARM_DESC(debug, "winbond-840 debug level (0-6)");
drivers/net/ethernet/dlink/sundance.c:MODULE_PARM_DESC(debug, "Sundance Alta debug level (0-5)");
drivers/net/ethernet/fealnx.c:MODULE_PARM_DESC(debug, "fealnx enable debugging (0-1)");
drivers/net/ethernet/freescale/fec_mpc52xx.c:MODULE_PARM_DESC(debug, "debugging messages level");
drivers/net/ethernet/freescale/ucc_geth.c:MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 0xffff=all)");
drivers/net/ethernet/i825xx/82596.c:MODULE_PARM_DESC(i596_debug, "i82596 debug mask");
drivers/net/ethernet/i825xx/82596.c:MODULE_PARM_DESC(debug, "i82596 debug mask");
drivers/net/ethernet/i825xx/lasi_82596.c:MODULE_PARM_DESC(i596_debug, "lasi_82596 debug mask");
drivers/net/ethernet/i825xx/sni_82596.c:MODULE_PARM_DESC(i596_debug, "82596 debug mask");
drivers/net/ethernet/intel/e100.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/e1000/e1000_main.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/e1000e/netdev.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/i40e/i40e_main.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/igb/igb_main.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/igbvf/netdev.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/ixgb/ixgb_main.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/marvell/skge.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/marvell/sky2.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/mellanox/mlx4/main.c:MODULE_PARM_DESC(debug_level, "Enable debug tracing if > 0");
drivers/net/ethernet/mellanox/mlx5/core/main.c:MODULE_PARM_DESC(debug_mask, "debug mask: 1 = dump cmd data, 2 = dump cmd exec time, 3 = both. Default=0");
drivers/net/ethernet/microchip/enc28j60.c:MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., ffff=all)");
drivers/net/ethernet/natsemi/jazzsonic.c:MODULE_PARM_DESC(sonic_debug, "jazzsonic debug level (1-4)");
drivers/net/ethernet/natsemi/macsonic.c:MODULE_PARM_DESC(sonic_debug, "macsonic debug level (1-4)");
drivers/net/ethernet/natsemi/natsemi.c:MODULE_PARM_DESC(debug, "DP8381x default debug level");
drivers/net/ethernet/natsemi/xtsonic.c:MODULE_PARM_DESC(sonic_debug, "xtsonic debug level (1-4)");
drivers/net/ethernet/packetengines/hamachi.c:MODULE_PARM_DESC(debug, "GNIC-II debug level (0-7)");
drivers/net/ethernet/packetengines/yellowfin.c:MODULE_PARM_DESC(debug, "G-NIC debug level (0-7)");
drivers/net/ethernet/pasemi/pasemi_mac.c:MODULE_PARM_DESC(debug, "PA Semi MAC bitmapped debugging message enable value");
drivers/net/ethernet/qlogic/qla3xxx.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/qlogic/qlge/qlge_main.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/realtek/8139cp.c:MODULE_PARM_DESC (debug, "8139cp: bitmapped message enable number");
drivers/net/ethernet/realtek/8139too.c:MODULE_PARM_DESC (debug, "8139too bitmapped message enable number");
drivers/net/ethernet/realtek/atp.c:MODULE_PARM_DESC(debug, "ATP debug level (0-7)");
drivers/net/ethernet/realtek/r8169.c:MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
drivers/net/ethernet/sfc/efx.c:MODULE_PARM_DESC(debug, "Bitmapped debugging message enable value");
drivers/net/ethernet/sis/sis190.c:MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 16=all)");
drivers/net/ethernet/smsc/epic100.c:MODULE_PARM_DESC(debug, "EPIC/100 debug level (0-5)");
drivers/net/ethernet/smsc/smsc911x.c:MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
drivers/net/ethernet/smsc/smsc9420.c:MODULE_PARM_DESC(debug, "debug level");
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:MODULE_PARM_DESC(debug, "Message Level (-1: default, 0: no output, 16: all)");
drivers/net/ethernet/sun/niu.c:MODULE_PARM_DESC(debug, "NIU debug level");
drivers/net/ethernet/ti/cpsw.c:MODULE_PARM_DESC(debug_level, "cpsw debug level (NETIF_MSG bits)");
drivers/net/ethernet/ti/davinci_emac.c:MODULE_PARM_DESC(debug_level, "DaVinci EMAC debug level (NETIF_MSG bits)");
drivers/net/ethernet/ti/tlan.c:MODULE_PARM_DESC(debug, "ThunderLAN debug mask");
drivers/net/ethernet/via/via-rhine.c:MODULE_PARM_DESC(debug, "VIA Rhine debug message flags");
> > The debug parameter is converted
> > to mask by netif_msg_init.
>
> Correct.
Swell, I think the module parm description is misleading.
I think it'd be better to reference "(NETIF_MSG bits)" like
the TI drivers do.
^ permalink raw reply
* Re: [PATCH net-next] tcp: do not use cached RTT for RTT estimation
From: David Miller @ 2013-08-30 19:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ycheng, edumazet
In-Reply-To: <1377876953.7360.10.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 30 Aug 2013 08:35:53 -0700
> From: Yuchung Cheng <ycheng@google.com>
>
> RTT cached in the TCP metrics are valuable for the initial timeout
> because SYN RTT usually does not account for serialization delays
> on low BW path.
>
> However using it to seed the RTT estimator maybe disruptive because
> other components (e.g., pacing) require the smooth RTT to be obtained
> from actual connection.
>
> The solution is to use the higher cached RTT to set the first RTO
> conservatively like tcp_rtt_estimator(), but avoid seeding the other
> RTT estimator variables such as srtt. It is also a good idea to
> keep RTO conservative to obtain the first RTT sample, and the
> performance is insured by TCP loss probe if SYN RTT is available.
>
> To keep the seeding formula consistent across SYN RTT and cached RTT,
> the rttvar is twice the cached RTT instead of cached RTTVAR value. The
> reason is because cached variation may be too small (near min RTO)
> which defeats the purpose of being conservative on first RTO. However
> the metrics still keep the RTT variations as they might be useful for
> user applications (through ip).
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Eric Dumazet <edumazet@google.com>
Applied, but in one aspect I am disappointed.
You removed Alexey Kuznetsov's detailed comment about what is going
on here, but did not replace it with a new comment explaining in
detail the new logic.
In particular we need a comment showing exactly what happens as we
get the initial RTT measurement for the SYN/SYN-ACK, and then an
explanation the transition which now occurs when we move into the
RTT measurements after the handshake.
Could you write something up?
Thank you.
^ permalink raw reply
* Re: [PATCH 0/7] Drop support for Renesys H8/300 architecture
From: Linus Torvalds @ 2013-08-30 19:14 UTC (permalink / raw)
To: Guenter Roeck
Cc: Wim Van Sebroeck, Linux Kernel Mailing List, IDE-ML,
Network Development, Linux Watchdog Mailing List, David S. Miller,
Al Viro, Eric Paris, Greg Kroah-Hartman, Jiang Liu, David Howells,
Thomas Gleixner, Stephen Rothwell
In-Reply-To: <20130830191146.GA12090@roeck-us.net>
On Fri, Aug 30, 2013 at 12:11 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> I would not mind if Linus would agree to pull it right away for 3.12,
> but that seems to be a bit on the fast side.
I'm ok with code deletion patches, I don't think that would be a
problem. I didn't check them, but I assume this is all literally just
removing code that is conditional on h8/300 config options?
Linus
^ permalink raw reply
* Re: [PATCH] net: usbnet: update addr_assign_type if appropriate
From: David Miller @ 2013-08-30 19:14 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
oneukum-l3A5Bk7waGM
In-Reply-To: <8761unxb1s.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Fri, 30 Aug 2013 20:56:15 +0200
> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
>> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>> Date: Fri, 30 Aug 2013 20:18:58 +0200
>>
>>> Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> writes:
>>>
>>>> This module generates a common default address on init,
>>>> using eth_random_addr. Set addr_assign_type to let
>>>> userspace know the address is random unless it was
>>>> overridden by the minidriver.
>>>>
>>>> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>>>
>>> David,
>>>
>>> I see that this patch is marked "Changes Requested" in patchworks:
>>> http://patchwork.ozlabs.org/patch/269030/
>>>
>>> But I haven't seen any request for changes, only Olivers ack. And that's
>>> all patchworks has recorded as well. Did I miss something?
>>
>> Your v2 of this series is all marked as Under Review.
>>
>> You have to understand, wrt. your initial submission, when someone
>> asks for changes in one of the patches in a series I mark the whole
>> series as changes requested.
>>
>> This gives a second level of reminder that when one patch needs changes
>> I expect the entire series to be resubmitted.
>
> Huh? This patch was never part of any series. There are no references
> or numbering in it. I sent it as a standalone patch because the fix was
> different and not depending on the other addr_assign_type changes.
I was hoping to get this fix, via the series. When we have multiple instances
of the same bug it makes no sense to just fix one, especially now that you're
done the work to do all of them already.
--
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: [PATCH 0/7] Drop support for Renesys H8/300 architecture
From: Guenter Roeck @ 2013-08-30 19:11 UTC (permalink / raw)
To: Wim Van Sebroeck
Cc: linux-kernel, linux-ide, netdev, linux-watchdog, David S. Miller,
Al Viro, Eric Paris, Greg Kroah-Hartman, Jiang Liu, David Howells,
Thomas Gleixner, Stephen Rothwell, Linus Torvalds
In-Reply-To: <20130830184611.GA27455@spo001.leaseweb.com>
On Fri, Aug 30, 2013 at 08:46:11PM +0200, Wim Van Sebroeck wrote:
> Hi Guenter,
>
> > H8/300 has been dead for several years, the kernel for it has
> > not compiled for ages, and recent versions of gcc for it are broken.
> > It is time to drop support for it.
> >
> > Yes, I understand it is not that simple to drop an architecture,
> > and it may need some discussion, but someone has to put a stake
> > into the ground. Keeping a virtually dead architecture on life support
> > takes resources which are better spent elsewhere.
>
> Agree. You may add my Acked-by.
> How do you plan to get this upstream? Do I need to take the watchdog in my tree or do you plan to keep the set of patches together in one tree?
>
My plan is create a branch on my repository on kernel.org, ask Stephen
to add it to linux-next, and then ask Linus to pull it after one
release cycle (ie for 3.13). This should give people enough time
to find out about it and complain, and give everyone else enough time
to find any missing pieces.
I would not mind if Linus would agree to pull it right away for 3.12,
but that seems to be a bit on the fast side.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] net: usbnet: update addr_assign_type if appropriate
From: Bjørn Mork @ 2013-08-30 18:56 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
oneukum-l3A5Bk7waGM
In-Reply-To: <20130830.144118.1671225313340653567.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Date: Fri, 30 Aug 2013 20:18:58 +0200
>
>> Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org> writes:
>>
>>> This module generates a common default address on init,
>>> using eth_random_addr. Set addr_assign_type to let
>>> userspace know the address is random unless it was
>>> overridden by the minidriver.
>>>
>>> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>>
>> David,
>>
>> I see that this patch is marked "Changes Requested" in patchworks:
>> http://patchwork.ozlabs.org/patch/269030/
>>
>> But I haven't seen any request for changes, only Olivers ack. And that's
>> all patchworks has recorded as well. Did I miss something?
>
> Your v2 of this series is all marked as Under Review.
>
> You have to understand, wrt. your initial submission, when someone
> asks for changes in one of the patches in a series I mark the whole
> series as changes requested.
>
> This gives a second level of reminder that when one patch needs changes
> I expect the entire series to be resubmitted.
Huh? This patch was never part of any series. There are no references
or numbering in it. I sent it as a standalone patch because the fix was
different and not depending on the other addr_assign_type changes.
Bjørn
--
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: [PATCH net-next] pkt_sched: fq: prefetch() fix
From: David Miller @ 2013-08-30 18:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1377881203.7360.15.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 30 Aug 2013 09:46:43 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> kbuild bot reported following m68k build error :
>
> net/sched/sch_fq.c: In function 'fq_dequeue':
>>> net/sched/sch_fq.c:491:2: error: implicit declaration of function
> 'prefetch' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
>
>
> While we are fixing this, move this prefetch() call a bit earlier.
>
> Reported-by: Wu Fengguang <fengguang.wu@intel.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2] ipv6:introduce function to find route for redirect
From: David Miller @ 2013-08-30 18:50 UTC (permalink / raw)
To: duanj.fnst; +Cc: netdev, hannes
In-Reply-To: <52204876.3090803@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Fri, 30 Aug 2013 15:23:34 +0800
> + /*
> + * Get the "current" route for this destination and
> + * check if the redirect has come from approriate router.
> + *
> + * RFC 4861 specifies that redirects should only be
> + * accepted if they come from the nexthop to the target.
> + * Due to the way the routes are chosen, this notion
> + * is a bit fuzzy and one might need to check all possible
> + * routes.
> + */
Comments in the networking code should be formatted:
/* Like
* this.
*/
^ permalink raw reply
* Re: [PATCH 0/7] Drop support for Renesys H8/300 architecture
From: Wim Van Sebroeck @ 2013-08-30 18:46 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, linux-ide, netdev, linux-watchdog, David S. Miller,
Al Viro, Eric Paris, Greg Kroah-Hartman, Jiang Liu, David Howells,
Thomas Gleixner, Stephen Rothwell, Linus Torvalds
In-Reply-To: <1377880842-6835-1-git-send-email-linux@roeck-us.net>
Hi Guenter,
> H8/300 has been dead for several years, the kernel for it has
> not compiled for ages, and recent versions of gcc for it are broken.
> It is time to drop support for it.
>
> Yes, I understand it is not that simple to drop an architecture,
> and it may need some discussion, but someone has to put a stake
> into the ground. Keeping a virtually dead architecture on life support
> takes resources which are better spent elsewhere.
Agree. You may add my Acked-by.
How do you plan to get this upstream? Do I need to take the watchdog in my tree or do you plan to keep the set of patches together in one tree?
Kind regards,
Wim.
^ permalink raw reply
* Re: [PATCH] openvswitch: fix sw_flow_key alignment
From: David Miller @ 2013-08-30 18:42 UTC (permalink / raw)
To: jesse; +Cc: azhou, dev, netdev
In-Reply-To: <CAEP_g=9y-HeG0vHS2v-dk7eDp=T0denddykDO3TJtk4UJ062Mg@mail.gmail.com>
From: Jesse Gross <jesse@nicira.com>
Date: Fri, 30 Aug 2013 11:22:11 -0700
> The suggestion that Geert made was to just drop this entirely and
> rely on the natural alignment from these values.
Indeed, Geert's patch was 1,000 times superior to this one.
^ permalink raw reply
* Re: [PATCH] net: usbnet: update addr_assign_type if appropriate
From: David Miller @ 2013-08-30 18:41 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb, oneukum
In-Reply-To: <87d2ovxcrx.fsf@nemi.mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Fri, 30 Aug 2013 20:18:58 +0200
> Bjørn Mork <bjorn@mork.no> writes:
>
>> This module generates a common default address on init,
>> using eth_random_addr. Set addr_assign_type to let
>> userspace know the address is random unless it was
>> overridden by the minidriver.
>>
>> Signed-off-by: Bjørn Mork <bjorn@mork.no>
>
> David,
>
> I see that this patch is marked "Changes Requested" in patchworks:
> http://patchwork.ozlabs.org/patch/269030/
>
> But I haven't seen any request for changes, only Olivers ack. And that's
> all patchworks has recorded as well. Did I miss something?
Your v2 of this series is all marked as Under Review.
You have to understand, wrt. your initial submission, when someone
asks for changes in one of the patches in a series I mark the whole
series as changes requested.
This gives a second level of reminder that when one patch needs changes
I expect the entire series to be resubmitted.
^ permalink raw reply
* Re: [net-next v3 1/8] i40e: main driver core
From: David Miller @ 2013-08-30 18:40 UTC (permalink / raw)
To: stephen
Cc: joe, jeffrey.t.kirsher, jesse.brandeburg, netdev, gospo, sassmann,
shannon.nelson, peter.p.waskiewicz.jr, e1000-devel
In-Reply-To: <20130830111029.25d6d753@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 30 Aug 2013 11:10:29 -0700
> On Fri, 30 Aug 2013 09:32:48 -0700
> Joe Perches <joe@perches.com> wrote:
>
>> > +static int debug = -1;
>> > +module_param(debug, int, 0);
>> > +MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
>>
>> Maybe make debug a bitfield instead?
>
> No Joe, this is the standard mapping of debug to msglevel used
> by most network devices. The debug parameter is converted
> to mask by netif_msg_init.
Correct.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7] IPv6 MLD updates
From: David Miller @ 2013-08-30 18:38 UTC (permalink / raw)
To: dborkman; +Cc: netdev
In-Reply-To: <1377881908-8022-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Fri, 30 Aug 2013 18:58:21 +0200
> If there are no further objections, I'll send out the non-RFC version on
> Monday after some more testing. That's just a heads up. This set includes
> my improved fix from yesterday as well besides other things.
>
> Thanks!
>From a coding style and general correctness perspective these changes
look fine to me.
I'll let IPV6 MLD experts comment on the semantic part.
^ permalink raw reply
* Re: [PATCH V2 4/6] vhost_net: determine whether or not to use zerocopy at one time
From: Sergei Shtylyov @ 2013-08-30 18:35 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1377836962-49780-5-git-send-email-jasowang@redhat.com>
Hello.
On 08/30/2013 08:29 AM, Jason Wang wrote:
> Currently, even if the packet length is smaller than VHOST_GOODCOPY_LEN, if
> upend_idx != done_idx we still set zcopy_used to true and rollback this choice
> later. This could be avoided by determine zerocopy once by checking all
> conditions at one time before.
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/net.c | 46 +++++++++++++++++++---------------------------
> 1 files changed, 19 insertions(+), 27 deletions(-)
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 8a6dd0d..ff60c2a 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -404,43 +404,35 @@ static void handle_tx(struct vhost_net *net)
> iov_length(nvq->hdr, s), hdr_size);
> break;
> }
> - zcopy_used = zcopy && (len >= VHOST_GOODCOPY_LEN ||
> - nvq->upend_idx != nvq->done_idx);
> +
> + zcopy_used = zcopy && len >= VHOST_GOODCOPY_LEN
> + && (nvq->upend_idx + 1) % UIO_MAXIOV != nvq->done_idx
> + && vhost_net_tx_select_zcopy(net);
Could you leave && on a first of two lines, matching the previous style?
>
> /* use msg_control to pass vhost zerocopy ubuf info to skb */
> if (zcopy_used) {
> + struct ubuf_info *ubuf;
> + ubuf = nvq->ubuf_info + nvq->upend_idx;
> +
> vq->heads[nvq->upend_idx].id = head;
[...]
> + vq->heads[nvq->upend_idx].len = VHOST_DMA_IN_PROGRESS;
> + ubuf->callback = vhost_zerocopy_callback;
> + ubuf->ctx = nvq->ubufs;
> + ubuf->desc = nvq->upend_idx;
> + msg.msg_control = ubuf;
> + msg.msg_controllen = sizeof(ubuf);
'sizeof(ubuf)' where 'ubuf' is a pointer? Are you sure it shouldn't be
'sizeof(*ubuf)'?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/7] Drop support for Renesys H8/300 architecture
From: David Miller @ 2013-08-30 18:30 UTC (permalink / raw)
To: gregkh
Cc: linux, linux-kernel, linux-ide, netdev, linux-watchdog, wim, viro,
eparis, jiang.liu, dhowells, tglx, sfr, torvalds
In-Reply-To: <20130830165550.GA8151@kroah.com>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 30 Aug 2013 09:55:50 -0700
> On Fri, Aug 30, 2013 at 09:40:35AM -0700, Guenter Roeck wrote:
>> H8/300 has been dead for several years, the kernel for it has
>> not compiled for ages, and recent versions of gcc for it are broken.
>> It is time to drop support for it.
>>
>> Yes, I understand it is not that simple to drop an architecture,
>> and it may need some discussion, but someone has to put a stake
>> into the ground. Keeping a virtually dead architecture on life support
>> takes resources which are better spent elsewhere.
>
> If this doesn't build, and no one is using it anymore, I agree, it
> should be removed. If someone wants to revive it, 'git revert' works
> just fine.
>
> You can put my:
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> on these patches, unless someone steps up to be the active maintainer of
> the arch and gets it building/working again.
I completely agree with Greg, and for the IDE and networking bits:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH net] net: fec: fix time stamping logic after napi conversion
From: Richard Cochran @ 2013-08-30 18:28 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Frank Li
Commit dc975382 "net: fec: add napi support to improve proformance"
converted the fec driver to the napi model. However, that commit
forgot to remove the call to skb_defer_rx_timestamp which is only
needed in non-napi drivers.
(The function napi_gro_receive eventually calls netif_receive_skb,
which in turn calls skb_defer_rx_timestamp.)
This patch should also be applied to the 3.9 and 3.10 kernels.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/freescale/fec_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 77ea0db..c610a27 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -971,8 +971,7 @@ fec_enet_rx(struct net_device *ndev, int budget)
htons(ETH_P_8021Q),
vlan_tag);
- if (!skb_defer_rx_timestamp(skb))
- napi_gro_receive(&fep->napi, skb);
+ napi_gro_receive(&fep->napi, skb);
}
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, data,
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] openvswitch: fix sw_flow_key alignment
From: Jesse Gross @ 2013-08-30 18:22 UTC (permalink / raw)
To: Andy Zhou; +Cc: David Miller, dev@openvswitch.org, netdev
In-Reply-To: <1377883940-8995-1-git-send-email-azhou@nicira.com>
On Fri, Aug 30, 2013 at 10:32 AM, Andy Zhou <azhou@nicira.com> wrote:
> diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
> index ad1aeeb..fe7524c4 100644
> --- a/net/openvswitch/flow.c
> +++ b/net/openvswitch/flow.c
> int ovs_flow_init(void)
> {
> BUILD_BUG_ON(sizeof(struct sw_flow_key) % sizeof(long));
> + BUILD_BUG_ON(sizeof(struct sw_flow_key) % __alignof__(long));
Should this be checking alignof struct sw_flow_key instead of the size?
> flow_cache = kmem_cache_create("sw_flow", sizeof(struct sw_flow), 0,
> 0, NULL);
> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
> index b65f885..202c4c4 100644
> --- a/net/openvswitch/flow.h
> +++ b/net/openvswitch/flow.h
> @@ -125,7 +125,7 @@ struct sw_flow_key {
> } nd;
> } ipv6;
> };
> -} __aligned(__alignof__(long));
> +} __aligned(sizeof(long));
This is going to result in the alignment issue discussed yesterday
where on 32-bit machines the 64 bit members potentially become
misaligned. The suggestion that Geert made was to just drop this
entirely and rely on the natural alignment from these values.
^ permalink raw reply
* [PATCH net-next 8/9] qlcnic: Add support for per port eswitch configuration
From: Shahed Shaikh @ 2013-08-30 17:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Dept-HSGLinuxNICDev, Sony Chacko
In-Reply-To: <1377885084-6441-1-git-send-email-shahed.shaikh@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
There is an embedded switch per physical port on the adapter.
Add support for enabling and disabling the embedded switch
on per port basis.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 2 +
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c | 2 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h | 2 +
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 67 ++++++-------------
.../net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c | 40 +++++++++++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 41 +++++++++++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c | 19 +++++-
7 files changed, 120 insertions(+), 53 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 0cd993f..0c223ca 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -837,6 +837,7 @@ struct qlcnic_mac_list_s {
#define QLCNIC_FW_CAP2_HW_LRO_IPV6 BIT_3
#define QLCNIC_FW_CAPABILITY_SET_DRV_VER BIT_5
#define QLCNIC_FW_CAPABILITY_2_BEACON BIT_7
+#define QLCNIC_FW_CAPABILITY_2_PER_PORT_ESWITCH_CFG BIT_8
/* module types */
#define LINKEVENT_MODULE_NOT_PRESENT 1
@@ -1184,6 +1185,7 @@ struct qlcnic_pci_info {
};
struct qlcnic_npar_info {
+ bool eswitch_status;
u16 pvid;
u16 min_bw;
u16 max_bw;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
index 3ef5437..a1818da 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c
@@ -2331,7 +2331,7 @@ int qlcnic_83xx_get_pci_info(struct qlcnic_adapter *adapter,
pci_info->tx_max_bw, pci_info->mac);
}
if (ahw->op_mode == QLCNIC_MGMT_FUNC)
- dev_info(dev, "Max vNIC functions = %d, active vNIC functions = %d\n",
+ dev_info(dev, "Max functions = %d, active functions = %d\n",
ahw->max_pci_func, ahw->act_pci_func);
} else {
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h
index 2a2ab6b..533e150 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h
@@ -411,6 +411,7 @@ enum qlcnic_83xx_states {
#define QLC_83XX_GET_HW_LRO_CAPABILITY(val) (val & 0x400)
#define QLC_83XX_GET_VLAN_ALIGN_CAPABILITY(val) (val & 0x4000)
#define QLC_83XX_GET_FW_LRO_MSS_CAPABILITY(val) (val & 0x20000)
+#define QLC_83XX_ESWITCH_CAPABILITY BIT_23
#define QLC_83XX_VIRTUAL_NIC_MODE 0xFF
#define QLC_83XX_DEFAULT_MODE 0x0
#define QLC_83XX_SRIOV_MODE 0x1
@@ -625,6 +626,7 @@ int qlcnic_83xx_config_vnic_opmode(struct qlcnic_adapter *);
int qlcnic_83xx_get_vnic_vport_info(struct qlcnic_adapter *,
struct qlcnic_info *, u8);
int qlcnic_83xx_get_vnic_pf_info(struct qlcnic_adapter *, struct qlcnic_info *);
+int qlcnic_83xx_enable_port_eswitch(struct qlcnic_adapter *, int);
void qlcnic_83xx_get_minidump_template(struct qlcnic_adapter *);
void qlcnic_83xx_get_stats(struct qlcnic_adapter *adapter, u64 *data);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
index c24c2a4..f09e787 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c
@@ -2003,36 +2003,6 @@ static int qlcnic_83xx_restart_hw(struct qlcnic_adapter *adapter)
return 0;
}
-/**
-* qlcnic_83xx_config_default_opmode
-*
-* @adapter: adapter structure
-*
-* Configure default driver operating mode
-*
-* Returns: Error code or Success(0)
-* */
-int qlcnic_83xx_config_default_opmode(struct qlcnic_adapter *adapter)
-{
- u32 op_mode;
- struct qlcnic_hardware_context *ahw = adapter->ahw;
-
- qlcnic_get_func_no(adapter);
- op_mode = QLCRDX(ahw, QLC_83XX_DRV_OP_MODE);
-
- if (test_bit(__QLCNIC_SRIOV_CAPABLE, &adapter->state))
- op_mode = QLC_83XX_DEFAULT_OPMODE;
-
- if (op_mode == QLC_83XX_DEFAULT_OPMODE) {
- adapter->nic_ops->init_driver = qlcnic_83xx_init_default_driver;
- ahw->idc.state_entry = qlcnic_83xx_idc_ready_state_entry;
- } else {
- return -EIO;
- }
-
- return 0;
-}
-
int qlcnic_83xx_get_nic_configuration(struct qlcnic_adapter *adapter)
{
int err;
@@ -2052,26 +2022,26 @@ int qlcnic_83xx_get_nic_configuration(struct qlcnic_adapter *adapter)
ahw->max_mac_filters = nic_info.max_mac_filters;
ahw->max_mtu = nic_info.max_mtu;
- /* VNIC mode is detected by BIT_23 in capabilities. This bit is also
- * set in case device is SRIOV capable. VNIC and SRIOV are mutually
- * exclusive. So in case of sriov capable device load driver in
- * default mode
+ /* eSwitch capability indicates vNIC mode.
+ * vNIC and SRIOV are mutually exclusive operational modes.
+ * If SR-IOV capability is detected, SR-IOV physical function
+ * will get initialized in default mode.
+ * SR-IOV virtual function initialization follows a
+ * different code path and opmode.
+ * SRIOV mode has precedence over vNIC mode.
*/
- if (test_bit(__QLCNIC_SRIOV_CAPABLE, &adapter->state)) {
- ahw->nic_mode = QLC_83XX_DEFAULT_MODE;
- return ahw->nic_mode;
- }
+ if (test_bit(__QLCNIC_SRIOV_CAPABLE, &adapter->state))
+ return QLC_83XX_DEFAULT_OPMODE;
- if (ahw->capabilities & BIT_23)
- ahw->nic_mode = QLC_83XX_VIRTUAL_NIC_MODE;
- else
- ahw->nic_mode = QLC_83XX_DEFAULT_MODE;
+ if (ahw->capabilities & QLC_83XX_ESWITCH_CAPABILITY)
+ return QLC_83XX_VIRTUAL_NIC_MODE;
- return ahw->nic_mode;
+ return QLC_83XX_DEFAULT_OPMODE;
}
int qlcnic_83xx_configure_opmode(struct qlcnic_adapter *adapter)
{
+ struct qlcnic_hardware_context *ahw = adapter->ahw;
int ret;
ret = qlcnic_83xx_get_nic_configuration(adapter);
@@ -2079,11 +2049,16 @@ int qlcnic_83xx_configure_opmode(struct qlcnic_adapter *adapter)
return -EIO;
if (ret == QLC_83XX_VIRTUAL_NIC_MODE) {
+ ahw->nic_mode = QLC_83XX_VIRTUAL_NIC_MODE;
if (qlcnic_83xx_config_vnic_opmode(adapter))
return -EIO;
- } else if (ret == QLC_83XX_DEFAULT_MODE) {
- if (qlcnic_83xx_config_default_opmode(adapter))
- return -EIO;
+
+ } else if (ret == QLC_83XX_DEFAULT_OPMODE) {
+ ahw->nic_mode = QLC_83XX_DEFAULT_MODE;
+ adapter->nic_ops->init_driver = qlcnic_83xx_init_default_driver;
+ ahw->idc.state_entry = qlcnic_83xx_idc_ready_state_entry;
+ } else {
+ return -EIO;
}
return 0;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
index 599d1fd..0248a4c 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
@@ -208,7 +208,7 @@ int qlcnic_83xx_config_vnic_opmode(struct qlcnic_adapter *adapter)
return -EIO;
}
- if (ahw->capabilities & BIT_23)
+ if (ahw->capabilities & QLC_83XX_ESWITCH_CAPABILITY)
adapter->flags |= QLCNIC_ESWITCH_ENABLED;
else
adapter->flags &= ~QLCNIC_ESWITCH_ENABLED;
@@ -239,3 +239,41 @@ int qlcnic_83xx_check_vnic_state(struct qlcnic_adapter *adapter)
return 0;
}
+
+static int qlcnic_83xx_get_eswitch_port_info(struct qlcnic_adapter *adapter,
+ int func, int *port_id)
+{
+ struct qlcnic_info nic_info;
+ int err = 0;
+
+ memset(&nic_info, 0, sizeof(struct qlcnic_info));
+
+ err = qlcnic_get_nic_info(adapter, &nic_info, func);
+ if (err)
+ return err;
+
+ if (nic_info.capabilities & QLC_83XX_ESWITCH_CAPABILITY)
+ *port_id = nic_info.phys_port;
+ else
+ err = -EIO;
+
+ return err;
+}
+
+int qlcnic_83xx_enable_port_eswitch(struct qlcnic_adapter *adapter, int func)
+{
+ int id, err = 0;
+
+ err = qlcnic_83xx_get_eswitch_port_info(adapter, func, &id);
+ if (err)
+ return err;
+
+ if (!(adapter->eswitch[id].flags & QLCNIC_SWITCH_ENABLE)) {
+ if (!qlcnic_enable_eswitch(adapter, id, 1))
+ adapter->eswitch[id].flags |= QLCNIC_SWITCH_ENABLE;
+ else
+ err = -EIO;
+ }
+
+ return err;
+}
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 98d6a9d..bc47694 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -796,6 +796,23 @@ static int qlcnic_get_act_pci_func(struct qlcnic_adapter *adapter)
return ret;
}
+static bool qlcnic_port_eswitch_cfg_capability(struct qlcnic_adapter *adapter)
+{
+ bool ret = false;
+
+ if (qlcnic_84xx_check(adapter)) {
+ ret = true;
+ } else if (qlcnic_83xx_check(adapter)) {
+ if (adapter->ahw->extra_capability[0] &
+ QLCNIC_FW_CAPABILITY_2_PER_PORT_ESWITCH_CFG)
+ ret = true;
+ else
+ ret = false;
+ }
+
+ return ret;
+}
+
int qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
{
struct qlcnic_pci_info *pci_info;
@@ -839,18 +856,30 @@ int qlcnic_init_pci_info(struct qlcnic_adapter *adapter)
(pci_info[i].type != QLCNIC_TYPE_NIC))
continue;
+ if (qlcnic_port_eswitch_cfg_capability(adapter)) {
+ if (!qlcnic_83xx_enable_port_eswitch(adapter, pfn))
+ adapter->npars[j].eswitch_status = true;
+ else
+ continue;
+ } else {
+ adapter->npars[j].eswitch_status = true;
+ }
+
adapter->npars[j].pci_func = pfn;
adapter->npars[j].active = (u8)pci_info[i].active;
adapter->npars[j].type = (u8)pci_info[i].type;
adapter->npars[j].phy_port = (u8)pci_info[i].default_port;
adapter->npars[j].min_bw = pci_info[i].tx_min_bw;
adapter->npars[j].max_bw = pci_info[i].tx_max_bw;
+
j++;
}
- for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++) {
- adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
- if (qlcnic_83xx_check(adapter))
+ if (qlcnic_82xx_check(adapter)) {
+ for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
+ adapter->eswitch[i].flags |= QLCNIC_SWITCH_ENABLE;
+ } else if (!qlcnic_port_eswitch_cfg_capability(adapter)) {
+ for (i = 0; i < QLCNIC_NIU_MAX_XG_PORTS; i++)
qlcnic_enable_eswitch(adapter, i, 1);
}
@@ -1275,6 +1304,9 @@ int qlcnic_set_default_offload_settings(struct qlcnic_adapter *adapter)
return 0;
for (i = 0; i < adapter->ahw->act_pci_func; i++) {
+ if (!adapter->npars[i].eswitch_status)
+ continue;
+
memset(&esw_cfg, 0, sizeof(struct qlcnic_esw_func_cfg));
esw_cfg.pci_func = adapter->npars[i].pci_func;
esw_cfg.mac_override = BIT_0;
@@ -1337,6 +1369,9 @@ int qlcnic_reset_npar_config(struct qlcnic_adapter *adapter)
for (i = 0; i < adapter->ahw->act_pci_func; i++) {
npar = &adapter->npars[i];
pci_func = npar->pci_func;
+ if (!adapter->npars[i].eswitch_status)
+ continue;
+
memset(&nic_info, 0, sizeof(struct qlcnic_info));
err = qlcnic_get_nic_info(adapter, &nic_info, pci_func);
if (err)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
index 660c3f5..c6165d0 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c
@@ -465,8 +465,14 @@ static ssize_t qlcnic_sysfs_read_pm_config(struct file *filp,
memset(&pm_cfg, 0,
sizeof(struct qlcnic_pm_func_cfg) * QLCNIC_MAX_PCI_FUNC);
- for (i = 0; i < adapter->ahw->act_pci_func; i++) {
+ for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++) {
pci_func = adapter->npars[i].pci_func;
+ if (!adapter->npars[i].active)
+ continue;
+
+ if (!adapter->npars[i].eswitch_status)
+ continue;
+
pm_cfg[pci_func].action = adapter->npars[i].enable_pm;
pm_cfg[pci_func].dest_npar = 0;
pm_cfg[pci_func].pci_func = i;
@@ -632,8 +638,14 @@ static ssize_t qlcnic_sysfs_read_esw_config(struct file *file,
memset(&esw_cfg, 0,
sizeof(struct qlcnic_esw_func_cfg) * QLCNIC_MAX_PCI_FUNC);
- for (i = 0; i < adapter->ahw->act_pci_func; i++) {
+ for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++) {
pci_func = adapter->npars[i].pci_func;
+ if (!adapter->npars[i].active)
+ continue;
+
+ if (!adapter->npars[i].eswitch_status)
+ continue;
+
esw_cfg[pci_func].pci_func = pci_func;
if (qlcnic_get_eswitch_port_config(adapter, &esw_cfg[pci_func]))
return QL_STATUS_INVALID_PARAM;
@@ -732,6 +744,9 @@ static ssize_t qlcnic_sysfs_read_npar_config(struct file *file,
if (ret)
return ret;
+ if (!adapter->npars[i].eswitch_status)
+ continue;
+
np_cfg[i].pci_func = i;
np_cfg[i].op_mode = (u8)nic_info.op_mode;
np_cfg[i].port_num = nic_info.phys_port;
--
1.5.6
^ permalink raw reply related
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