* Re: v3.5: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
From: Francois Romieu @ 2012-08-01 19:24 UTC (permalink / raw)
To: George Spelvin; +Cc: netdev
In-Reply-To: <20120730190236.30339.qmail@science.horizon.com>
George Spelvin <linux@horizon.com> :
[...]
> There are a few local patches, but only two are anywhere close to the
> network interface, and they are test patches designed to fix this.
> Should I get rid of them?
It's up to you but I suggest that you keep them until there is something
better.
As long as the device recovers, you may try and lower the watchdog timeout
as well as increase the Tx ring size a bit (x2 or x4) to minimize the
annoyances.
--
Ueimor
^ permalink raw reply
* Re: binding UDP port 0 with SO_REUSEADDR
From: Tobias S. Josefowitz @ 2012-08-01 19:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1343847776.21269.797.camel@edumazet-glaptop>
On Wed, Aug 1, 2012 at 9:02 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> And why are you using SO_REUSEADDR on UDP unicast sockets ?
Simple. This happens in a "scripting" language. The wrapper code
assumes that it is better to set SO_REUSEADDR than not (which might be
argued, but backwards-compat can be nice) and at the time the code was
written the author must have assumed that even if the 'user' aka
programmer wants to bind to port 0, SO_REUSEADDR doesn't hurt, because
port 0 implicitly meant "please, a free one".
> I mean, this is exactly saying " By using this REUSEADDR, I am allowing
> this port being used by another process, even from another user"
I know. Still, while binding port 0 means "give me any port", I'm
quite sure most people would assume they get a free one. And maybe,
for whatever reasons, you want to share your random port later and
need SO_REUSEADDR because of that. A usecase where someone wants a
randomly chosen free or used port does not come to my mind, though.
Of course, I'm not relying on the kernel to revert back, I adapted the
wrapper code I mentioned above. I still felt like mentioning that it
was kind of unexpected, that's all.
Best,
Tobi
^ permalink raw reply
* Unable to get link beat with Niagara 2264 (Intel 82571EB) and e1000e driver on 3.4.4 (long)
From: Bradley Chapman @ 2012-08-01 22:20 UTC (permalink / raw)
To: netdev
All,
(please CC me as I am not subscribed to netdev)
I recently acquired an Interface Masters Niagara 2264 quad-port GigE
network card, based on the Intel 82571EB network controller (see
http://www.interfacemasters.com/products/2264.html for details). Prior
to using it in a new system I'm planning to build I decided to try it
out on my desktop system, which uses as Asus M4A89TD/PRO USB3
motherboard with the AMD 890FX chipset and a BIOS dated 03/08/2011,
running Debian 6.0.2.1.
I added the e1000e driver to my Linux 3.4.4 kernel config as a loadable
module and inserted it, and got the following:
e1000e: Intel(R) PRO/1000 Network Driver - 1.9.5-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:06:00.0: Disabling ASPM L1
e1000e 0000:06:00.0: (unregistered net_device): Interrupt Throttling
Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:06:00.0: irq 91 for MSI/MSI-X
e1000e 0000:06:00.0: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8c
e1000e 0000:06:00.0: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:06:00.0: eth1: MAC: 0, PHY: 4, PBA No: C98149-002
e1000e 0000:06:00.1: Disabling ASPM L1
e1000e 0000:06:00.1: (unregistered net_device): Interrupt Throttling
Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:06:00.1: irq 92 for MSI/MSI-X
udev[1123]: renamed network interface eth1 to eth2
e1000e 0000:06:00.1: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8d
e1000e 0000:06:00.1: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:06:00.1: eth1: MAC: 0, PHY: 4, PBA No: C98149-002
e1000e 0000:05:00.0: Disabling ASPM L1
e1000e 0000:05:00.0: (unregistered net_device): Interrupt Throttling
Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:05:00.0: irq 93 for MSI/MSI-X
udev[8376]: renamed network interface eth1 to eth3
e1000e 0000:05:00.0: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8a
e1000e 0000:05:00.0: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:05:00.0: eth1: MAC: 0, PHY: 4, PBA No: C98149-002
e1000e 0000:05:00.1: Disabling ASPM L1
e1000e 0000:05:00.1: (unregistered net_device): Interrupt Throttling
Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:05:00.1: irq 94 for MSI/MSI-X
udev[8400]: renamed network interface eth1 to eth4
e1000e 0000:05:00.1: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8b
e1000e 0000:05:00.1: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:05:00.1: eth1: MAC: 0, PHY: 4, PBA No: C98149-002
udev[8429]: renamed network interface eth1 to eth5
After doing so, though, I was unable to get a link beat on any of the
four RJ45 ports. I tried the Intel-supplied e1000e driver on the same
kernel and got the following:
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0.1-NAPI
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:06:00.0: Disabling ASPM L1
e1000e 0000:06:00.0: irq 91 for MSI/MSI-X
e1000e 0000:06:00.0: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8c
e1000e 0000:06:00.0: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:06:00.0: eth1: MAC: 1, PHY: 4, PBA No: C98149-002
e1000e 0000:06:00.1: Disabling ASPM L1
e1000e 0000:06:00.1: irq 92 for MSI/MSI-X
udev[8455]: renamed network interface eth1 to eth2
e1000e 0000:06:00.1: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8d
e1000e 0000:06:00.1: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:06:00.1: eth1: MAC: 1, PHY: 4, PBA No: C98149-002
e1000e 0000:05:00.0: Disabling ASPM L1
e1000e 0000:05:00.0: irq 93 for MSI/MSI-X
udev[8455]: renamed network interface eth1 to eth3
e1000e 0000:05:00.0: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8a
e1000e 0000:05:00.0: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:05:00.0: eth1: MAC: 1, PHY: 4, PBA No: C98149-002
e1000e 0000:05:00.1: Disabling ASPM L1
e1000e 0000:05:00.1: irq 94 for MSI/MSI-X
udev[8455]: renamed network interface eth1 to eth4
e1000e 0000:05:00.1: eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8b
e1000e 0000:05:00.1: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:05:00.1: eth1: MAC: 1, PHY: 4, PBA No: C98149-002
udev[8455]: renamed network interface eth1 to eth5
ethtool -i and ethtool -d report the following for the Intel-supplied
driver for one of the four interfaces exported to userspace:
ethtool -i
----------
driver: e1000e
version: 2.0.0.1-NAPI
firmware-version: 5.0-2
bus-info: 0000:06:00.0
ethtool -d
----------
MAC Registers
-------------
0x00000: CTRL (Device control register) 0x40480241
Endian mode (buffers): little
Link reset: normal
Set link up: 1
Invert Loss-Of-Signal: no
Receive flow control: disabled
Transmit flow control: disabled
VLAN mode: enabled
Auto speed detect: disabled
Speed select: 1000Mb/s
Force speed: no
Force duplex: no
0x00008: STATUS (Device status register) 0x00080380
Duplex: half
Link up: no link config
TBI mode: disabled
Link speed: 1000Mb/s
Bus type: PCI Express
Port number: 0
0x00100: RCTL (Receive control register) 0x0400801A
Receiver: enabled
Store bad packets: disabled
Unicast promiscuous: enabled
Multicast promiscuous: enabled
Long packet: disabled
Descriptor minimum threshold size: 1/2
Broadcast accept mode: accept
VLAN filter: disabled
Canonical form indicator: disabled
Discard pause frames: filtered
Pass MAC control frames: don't pass
Receive buffer size: 2048
0x02808: RDLEN (Receive desc length) 0x00001000
0x02810: RDH (Receive desc head) 0x00000000
0x02818: RDT (Receive desc tail) 0x000000F0
0x02820: RDTR (Receive delay timer) 0x00000020
0x00400: TCTL (Transmit ctrl register) 0x3003F008
Transmitter: disabled
Pad short packets: enabled
Software XOFF Transmission: disabled
Re-transmit on late collision: disabled
0x03808: TDLEN (Transmit desc length) 0x00001000
0x03810: TDH (Transmit desc head) 0x00000000
0x03818: TDT (Transmit desc tail) 0x00000000
0x03820: TIDV (Transmit delay timer) 0x00000008
PHY type: unknown
mii-diag -a reports the following:
SIOCGMIIREG on eth2 failed: Input/output error
Basic registers of MII PHY #1: 1140 7909 02a8 0380 0de1 0000 0004 ffff.
Basic mode control register 0x1140: Auto-negotiation enabled.
Basic mode status register 0x7909 ... 7909.
Link status: not established.
End of basic transceiver information.
lspci reports the following:
02:00.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
Express Switch (rev ac)
03:00.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
Express Switch (rev ac)
03:01.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
Express Switch (rev ac)
03:02.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
Express Switch (rev ac)
05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (rev 06)
05:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (rev 06)
06:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (rev 06)
06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
Controller (rev 06)
I tried rebooting since switching to the new driver and it hasn't made a
difference. I did a bunch of digging in Google and couldn't find
anything that conclusively suggested a problem - I found lots of stuff
about BIOS bugs when dealing with ASPM, old regressions fixed in
previous kernels, and so on, but nothing that specifically identified my
problem.
Does anyone have any suggestions? I can try Linux 3.5 very easily and if
necessary I can also learn how to fetch a git tree and bisect it. I also
sent an e-mail to the manufacturer asking for assistance with this
device but I haven't received a response yet.
Thanks,
Brad
^ permalink raw reply
* [ANNOUNCE] iproute2 3.5.0
From: Stephen Hemminger @ 2012-08-01 23:05 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Following the trend of releasing before going on vacation, here is the
iproute2 release to go with last weeks 3.5.0 kernel release. The changes
were mainly adding support for the new queuing disciplines (codel etc)
and cleaning up the manual pages.
Source:
http://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-3.5.0.tar.gz
Repository:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
Andreas Henriksson (1):
iproute2: man page and /bin/ip disagree on del vs delete
Ben Hutchings (1):
ss: Report MSS from internal TCP information
Bjarni Ingi Gislason (2):
tc(8): Negative indent and missing "-" after an escape
tc-drr(8): tab unquoted in a argument to a macro
Chris Elston (1):
iproute2: allow IPv6 addresses for l2tp local and remote parameters
Eric Dumazet (3):
tc_codel: Controlled Delay AQM
fq_codel: Fair Queue Codel AQM
ip: speedup ip link
Hiroaki SHIMODA (2):
tc: u32: Fix icmp_code off.
tc: u32: Fix firstfrag filter.
Jan Ceuleers (2):
tc-codel: Fix typos in manpage
Add reference to tc-codel(8) to the SEE ALSO section
Li Wei (6):
tc: man: Fix incorrect parameter format in prio.
tc: prio: Perform more strict check on priomap.
tc: filter: validate filter priority in userspace.
tc: man: add 'delete' command.
tc: man: change man page and comment to confirm to code's behavior.
tc-bfifo: man: Add parameter value range.
Stephen Hemminger (7):
Update headers to 3.5 merge window
Remove derived man pages
Refactor ipaddr_list_or_flush
Remove reference to multipath algorithms in usage
man8: build cleanup
Add bridge command
v3.5.0
Vijay Subramanian (6):
Update tc-netem manpage to add ecn capability
tc-netem: Add support for ECN packet marking
tc-codel: Add manpage
tc-codel: Update usage text
tc-fq_codel: Add manpage
tc: Update manpage
^ permalink raw reply
* Re: v3.5: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
From: George Spelvin @ 2012-08-01 23:29 UTC (permalink / raw)
To: romieu; +Cc: linux, netdev
In-Reply-To: <20120801192455.GA29755@electric-eye.fr.zoreil.com>
Thank you for the response!
> It's up to you but I suggest that you keep them until there is something
> better.
I was going to; I just wondered if they interfered with debugging or
something.
> As long as the device recovers, you may try and lower the watchdog timeout
> as well as increase the Tx ring size a bit (x2 or x4) to minimize the
> annoyances.
Out of curiosity, how does increasing the Tx ring size help?
But okay. Just to make sure I'm doing it right (I'm pretty sure,
but scream if I'm making a mistake), I'm making the following edits to
drivers/net/ethernet/realtek/r8169.c
#define NUM_TX_DESC 64 /* Number of Tx descriptor registers */
I'll double that to 128.
Now, since I am actually running at gigabit speed into a pretty capable
network that I don't expect to ever block me, I should be able to send
one 1500-byte frame in 12.3 microseconds (with all overhead, one 1500-byte
frame is 1538 bytes or 12304 bits), so 128 frames in 1.6 ms.
There is the issue of TSO, so one descriptor might send more than one
frame, but I think it's likely to break at 4K pages, the worst case is
128 * 4096 / 1500 = 350 frames in that Tx ring, which will take 4.3 ms.
Either way, I can drop the Tx timeout a *lot*.
#define TL8169_TX_TIMEOUT (6*HZ)
I want to drop that to HZ/100 or less. Since I'm currently running with
CONFIG_HZ_100, and I'm not sure about the rounding (do I gain or lose
one tick due to ambiguity?) I'll bump HZ to 300 and change that to HZ/100.
That should give me a minimum of 2 ticks = 6.666 ms, which is still more
than it should take to transmit a full
To make this short timeout actually work, I have to remove the "round
to nearest second" round_timer() calls in net/sched/sch_generic.c (there
are two that apply to dev->watchdog_timer), since I do want a sub-second
timeout granularity.
^ permalink raw reply
* Re: [PATCH iproute2] ss: report SK_MEMINFO_BACKLOG
From: Stephen Hemminger @ 2012-08-02 0:06 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: Eric Dumazet, netdev
In-Reply-To: <CAGK4HS-fUp2ZiW9F_ZogOXQo5_2ptcBHT9Y2j25ZaoXrYKnbAQ@mail.gmail.com>
On Thu, 26 Jul 2012 17:29:26 -0700
Vijay Subramanian <subramanian.vijay@gmail.com> wrote:
> On 26 July 2012 02:20, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > linux-3.6-rc1 supports SK_MEMINFO_BACKLOG with commit d594e987c6f54
> > (sock_diag: add SK_MEMINFO_BACKLOG)
> >
> > ss command can display it if provided by the kernel.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Vijay Subramanian <subramanian.vijay@gmail.com>
>
>
> Thanks Eric. I see now how you fixed this.
>
> Tested-by: Vijay Subramanian <subramanian.vijay@gmail.com>
>
> Vijay
Applied (after 3.5.0 release).
^ permalink raw reply
* Re: Bridge extensions to iproute2
From: Stephen Hemminger @ 2012-08-02 0:07 UTC (permalink / raw)
To: Maciej Żenczykowski; +Cc: Linux NetDev, David Miller
In-Reply-To: <CAHo-OozFCrcx4FpsuNzEV4Cp_4hbVw896utpstYL2qcD1EwCyA@mail.gmail.com>
On Tue, 10 Jul 2012 15:01:26 -0700
Maciej Żenczykowski <zenczykowski@gmail.com> wrote:
> > I will get back to these. There wasn't a motivation to go fast because
> > there wasn't a user of these. Now with fdb offload support they are needed.
>
> Do you have some semi-ready patches that could be used for test purposes?
>
> While it looks like the forwarding database capability is there in the kernel,
> I can't currently find an interface to turn learning off.
I cleaned it up an put in 3.5.0 just released version.
^ permalink raw reply
* Re: [PATCH 02/02] iproute2: VTI support for ip link command.
From: Stephen Hemminger @ 2012-08-02 0:08 UTC (permalink / raw)
To: Saurabh; +Cc: netdev
In-Reply-To: <20120628010157.GA4005@debian-saurabh-64.vyatta.com>
On Wed, 27 Jun 2012 18:01:57 -0700
Saurabh <saurabh.mohan@vyatta.com> wrote:
>
>
> Support for VTI via rt netlink.
>
> Signed-off-by: Saurabh Mohan <saurabh.mohan@vyatta.com>
>
Applied for next version.
^ permalink raw reply
* Re: [PATCH V2 05/12] net: Add ndo_set_vif_param operation to serve eIPoIB VIFs
From: Ben Hutchings @ 2012-08-02 0:17 UTC (permalink / raw)
To: Or Gerlitz; +Cc: davem, roland, netdev, ali, sean.hefty, Erez Shitrit
In-Reply-To: <1343840975-3252-6-git-send-email-ogerlitz@mellanox.com>
On Wed, 2012-08-01 at 20:09 +0300, Or Gerlitz wrote:
> From: Erez Shitrit <erezsh@mellanox.co.il>
>
> The Ethernet IPoIB driver enslaves IPoIB devices and uses them as
> VIFs (Virtual Interface) which serve an Ethernet NIC e.g present in a
> guest OS. For each such slave that acts as a VIF, eIPoIB needs to know
> the mac and optionally the vlan uses by that NIC, the new ndo opertaion
> is used to associate the mac/vlan for that slave.
>
> Signed-off-by: Erez Shitrit <erezsh@mellanox.co.il>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> include/linux/netdevice.h | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index eb06e58..2709551 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1013,7 +1013,10 @@ struct net_device_ops {
> netdev_features_t features);
> int (*ndo_neigh_construct)(struct neighbour *n);
> void (*ndo_neigh_destroy)(struct neighbour *n);
> -
> + int (*ndo_set_vif_param) (struct net_device *dev,
> + struct net_device *vif,
> + u16 vlan,
> + u8 *mac);
The semantics of this operation should be documented in the comment
above the structure definition. One detail worth covering is whether
'vlan' is just a VID or can also include priority+CFI bits.
If this is specific to eIPoIB, why not put that in the name of the
operation? If not, this *really* needs explaining because so far I have
no whether it is something I should consider implementing on a real
Ethernet device.
Ben.
> int (*ndo_fdb_add)(struct ndmsg *ndm,
> struct net_device *dev,
> unsigned char *addr,
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: Unable to get link beat with Niagara 2264 (Intel 82571EB) and e1000e driver on 3.4.4 (long)
From: Dave, Tushar N @ 2012-08-02 0:18 UTC (permalink / raw)
To: kakadu08@comcast.net, netdev@vger.kernel.org
In-Reply-To: <5019ABA3.4080506@comcast.net>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Bradley Chapman
>Sent: Wednesday, August 01, 2012 3:20 PM
>To: netdev@vger.kernel.org
>Subject: Unable to get link beat with Niagara 2264 (Intel 82571EB) and
>e1000e driver on 3.4.4 (long)
>
>All,
>
>(please CC me as I am not subscribed to netdev)
>
>I recently acquired an Interface Masters Niagara 2264 quad-port GigE
>network card, based on the Intel 82571EB network controller (see
>http://www.interfacemasters.com/products/2264.html for details). Prior to
>using it in a new system I'm planning to build I decided to try it out on
>my desktop system, which uses as Asus M4A89TD/PRO USB3 motherboard with
>the AMD 890FX chipset and a BIOS dated 03/08/2011, running Debian 6.0.2.1.
>
>I added the e1000e driver to my Linux 3.4.4 kernel config as a loadable
>module and inserted it, and got the following:
>
>e1000e: Intel(R) PRO/1000 Network Driver - 1.9.5-k
>e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
>e1000e 0000:06:00.0: Disabling ASPM L1
>e1000e 0000:06:00.0: (unregistered net_device): Interrupt Throttling Rate
>(ints/sec) set to dynamic conservative mode e1000e 0000:06:00.0: irq 91
>for MSI/MSI-X e1000e 0000:06:00.0: eth1: (PCI Express:2.5GT/s:Width x4)
>00:0c:bd:01:cd:8c e1000e 0000:06:00.0: eth1: Intel(R) PRO/1000 Network
>Connection e1000e 0000:06:00.0: eth1: MAC: 0, PHY: 4, PBA No: C98149-002
>e1000e 0000:06:00.1: Disabling ASPM L1 e1000e 0000:06:00.1: (unregistered
>net_device): Interrupt Throttling Rate (ints/sec) set to dynamic
>conservative mode e1000e 0000:06:00.1: irq 92 for MSI/MSI-X
>udev[1123]: renamed network interface eth1 to eth2 e1000e 0000:06:00.1:
>eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8d e1000e
>0000:06:00.1: eth1: Intel(R) PRO/1000 Network Connection e1000e
>0000:06:00.1: eth1: MAC: 0, PHY: 4, PBA No: C98149-002 e1000e
>0000:05:00.0: Disabling ASPM L1 e1000e 0000:05:00.0: (unregistered
>net_device): Interrupt Throttling Rate (ints/sec) set to dynamic
>conservative mode e1000e 0000:05:00.0: irq 93 for MSI/MSI-X
>udev[8376]: renamed network interface eth1 to eth3 e1000e 0000:05:00.0:
>eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8a e1000e
>0000:05:00.0: eth1: Intel(R) PRO/1000 Network Connection e1000e
>0000:05:00.0: eth1: MAC: 0, PHY: 4, PBA No: C98149-002 e1000e
>0000:05:00.1: Disabling ASPM L1 e1000e 0000:05:00.1: (unregistered
>net_device): Interrupt Throttling Rate (ints/sec) set to dynamic
>conservative mode e1000e 0000:05:00.1: irq 94 for MSI/MSI-X
>udev[8400]: renamed network interface eth1 to eth4 e1000e 0000:05:00.1:
>eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8b e1000e
>0000:05:00.1: eth1: Intel(R) PRO/1000 Network Connection e1000e
>0000:05:00.1: eth1: MAC: 0, PHY: 4, PBA No: C98149-002
>udev[8429]: renamed network interface eth1 to eth5
What is the link partner?
Have you tried connecting device to different link partners?
-Tushar
>
>After doing so, though, I was unable to get a link beat on any of the four
>RJ45 ports. I tried the Intel-supplied e1000e driver on the same kernel
>and got the following:
>
>e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0.1-NAPI
>e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
>e1000e 0000:06:00.0: Disabling ASPM L1
>e1000e 0000:06:00.0: irq 91 for MSI/MSI-X e1000e 0000:06:00.0: eth1: (PCI
>Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8c e1000e 0000:06:00.0: eth1:
>Intel(R) PRO/1000 Network Connection e1000e 0000:06:00.0: eth1: MAC: 1,
>PHY: 4, PBA No: C98149-002 e1000e 0000:06:00.1: Disabling ASPM L1 e1000e
>0000:06:00.1: irq 92 for MSI/MSI-X
>udev[8455]: renamed network interface eth1 to eth2 e1000e 0000:06:00.1:
>eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8d e1000e
>0000:06:00.1: eth1: Intel(R) PRO/1000 Network Connection e1000e
>0000:06:00.1: eth1: MAC: 1, PHY: 4, PBA No: C98149-002 e1000e
>0000:05:00.0: Disabling ASPM L1 e1000e 0000:05:00.0: irq 93 for MSI/MSI-X
>udev[8455]: renamed network interface eth1 to eth3 e1000e 0000:05:00.0:
>eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8a e1000e
>0000:05:00.0: eth1: Intel(R) PRO/1000 Network Connection e1000e
>0000:05:00.0: eth1: MAC: 1, PHY: 4, PBA No: C98149-002 e1000e
>0000:05:00.1: Disabling ASPM L1 e1000e 0000:05:00.1: irq 94 for MSI/MSI-X
>udev[8455]: renamed network interface eth1 to eth4 e1000e 0000:05:00.1:
>eth1: (PCI Express:2.5GT/s:Width x4) 00:0c:bd:01:cd:8b e1000e
>0000:05:00.1: eth1: Intel(R) PRO/1000 Network Connection e1000e
>0000:05:00.1: eth1: MAC: 1, PHY: 4, PBA No: C98149-002
>udev[8455]: renamed network interface eth1 to eth5
>
>ethtool -i and ethtool -d report the following for the Intel-supplied
>driver for one of the four interfaces exported to userspace:
>
>ethtool -i
>----------
>driver: e1000e
>version: 2.0.0.1-NAPI
>firmware-version: 5.0-2
>bus-info: 0000:06:00.0
>
>ethtool -d
>----------
>MAC Registers
>-------------
>0x00000: CTRL (Device control register) 0x40480241
> Endian mode (buffers): little
> Link reset: normal
> Set link up: 1
> Invert Loss-Of-Signal: no
> Receive flow control: disabled
> Transmit flow control: disabled
> VLAN mode: enabled
> Auto speed detect: disabled
> Speed select: 1000Mb/s
> Force speed: no
> Force duplex: no
>0x00008: STATUS (Device status register) 0x00080380
> Duplex: half
> Link up: no link config
> TBI mode: disabled
> Link speed: 1000Mb/s
> Bus type: PCI Express
> Port number: 0
>0x00100: RCTL (Receive control register) 0x0400801A
> Receiver: enabled
> Store bad packets: disabled
> Unicast promiscuous: enabled
> Multicast promiscuous: enabled
> Long packet: disabled
> Descriptor minimum threshold size: 1/2
> Broadcast accept mode: accept
> VLAN filter: disabled
> Canonical form indicator: disabled
> Discard pause frames: filtered
> Pass MAC control frames: don't pass
> Receive buffer size: 2048
>0x02808: RDLEN (Receive desc length) 0x00001000
>0x02810: RDH (Receive desc head) 0x00000000
>0x02818: RDT (Receive desc tail) 0x000000F0
>0x02820: RDTR (Receive delay timer) 0x00000020
>0x00400: TCTL (Transmit ctrl register) 0x3003F008
> Transmitter: disabled
> Pad short packets: enabled
> Software XOFF Transmission: disabled
> Re-transmit on late collision: disabled
>0x03808: TDLEN (Transmit desc length) 0x00001000
>0x03810: TDH (Transmit desc head) 0x00000000
>0x03818: TDT (Transmit desc tail) 0x00000000
>0x03820: TIDV (Transmit delay timer) 0x00000008
>PHY type: unknown
>
>mii-diag -a reports the following:
>
>SIOCGMIIREG on eth2 failed: Input/output error Basic registers of MII PHY
>#1: 1140 7909 02a8 0380 0de1 0000 0004 ffff.
> Basic mode control register 0x1140: Auto-negotiation enabled.
> Basic mode status register 0x7909 ... 7909.
> Link status: not established.
> End of basic transceiver information.
>
>lspci reports the following:
>
>02:00.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
>Express Switch (rev ac)
>03:00.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
>Express Switch (rev ac)
>03:01.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
>Express Switch (rev ac)
>03:02.0 PCI bridge: PLX Technology, Inc. PEX 8517 16-lane, 5-port PCI
>Express Switch (rev ac)
>05:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (rev 06)
>05:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (rev 06)
>06:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (rev 06)
>06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet
>Controller (rev 06)
>
>I tried rebooting since switching to the new driver and it hasn't made a
>difference. I did a bunch of digging in Google and couldn't find anything
>that conclusively suggested a problem - I found lots of stuff about BIOS
>bugs when dealing with ASPM, old regressions fixed in previous kernels,
>and so on, but nothing that specifically identified my problem.
>
>Does anyone have any suggestions? I can try Linux 3.5 very easily and if
>necessary I can also learn how to fetch a git tree and bisect it. I also
>sent an e-mail to the manufacturer asking for assistance with this device
>but I haven't received a response yet.
>
>Thanks,
>
>Brad
>--
>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 V2 06/12] net/core: Add rtnetlink support to vif parameters
From: Ben Hutchings @ 2012-08-02 0:20 UTC (permalink / raw)
To: Or Gerlitz; +Cc: davem, roland, netdev, ali, sean.hefty, Erez Shitrit
In-Reply-To: <1343840975-3252-7-git-send-email-ogerlitz@mellanox.com>
On Wed, 2012-08-01 at 20:09 +0300, Or Gerlitz wrote:
> From: Erez Shitrit <erezsh@mellanox.co.il>
>
> Add IFLA_VIF_INFO which allows user space to configure mac/vlan for a VIF
[...]
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -780,7 +780,8 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
> + rtnl_vfinfo_size(dev, ext_filter_mask) /* IFLA_VFINFO_LIST */
> + rtnl_port_size(dev) /* IFLA_VF_PORTS + IFLA_PORT_SELF */
> + rtnl_link_get_size(dev) /* IFLA_LINKINFO */
> - + rtnl_link_get_af_size(dev); /* IFLA_AF_SPEC */
> + + rtnl_link_get_af_size(dev) /* IFLA_AF_SPEC */
> + + nla_total_size(sizeof(struct ifla_vif_param)); /* IFLA_VIF_INFO */
> }
[...]
if_nlmsg_size() returns the size of a message describing the interface.
But IFLA_VIF_INFO is write-only (why?) and therefore shouldn't be
included.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH V2 08/12] net/eipoib: Add ethtool file support
From: Ben Hutchings @ 2012-08-02 0:22 UTC (permalink / raw)
To: Or Gerlitz; +Cc: davem, roland, netdev, ali, sean.hefty, Erez Shitrit
In-Reply-To: <1343840975-3252-9-git-send-email-ogerlitz@mellanox.com>
On Wed, 2012-08-01 at 20:09 +0300, Or Gerlitz wrote:
> From: Erez Shitrit <erezsh@mellanox.co.il>
>
> Via ethtool the driver describes its version, ABI version, on what PIF
> interface it runs and various statistics.
[...]
> --- /dev/null
> +++ b/drivers/net/eipoib/eth_ipoib_ethtool.c
[...]
> +static void parent_ethtool_get_drvinfo(struct net_device *parent_dev,
> + struct ethtool_drvinfo *drvinfo)
> +{
> + struct parent *parent = netdev_priv(parent_dev);
> +
> + strncpy(drvinfo->driver, DRV_NAME, 32);
> +
> + strncpy(drvinfo->version, DRV_VERSION, 32);
> +
> + strncpy(drvinfo->bus_info, parent->ipoib_main_interface,
> + ETHTOOL_BUSINFO_LEN);
These must be null-terminated; therefore use strlcpy().
> + /* indicates ABI version */
> + snprintf(drvinfo->fw_version, 32, "%d", EIPOIB_ABI_VER);
[...]
This is an abuse of fw_version.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [E1000-devel] [PATCH net-next] igb: add delay to allow igb loopback test to succeed on 8086:10c9
From: Jeff Kirsher @ 2012-08-02 1:06 UTC (permalink / raw)
To: Stefan Assmann; +Cc: netdev, e1000-devel
In-Reply-To: <1343821463-18052-1-git-send-email-sassmann@kpanic.de>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
On Wed, 2012-08-01 at 13:44 +0200, Stefan Assmann wrote:
> Some 8086:10c9 NICs have a problem completing the ethtool loopback
> test.
> The result looks like this:
>
> ethtool -t eth1
> The test result is FAIL
> The test extra info:
> Register test (offline) 0
> Eeprom test (offline) 0
> Interrupt test (offline) 0
> Loopback test (offline) 13
> Link test (on/offline) 0
>
> A bisect clearly points to commit
> a95a07445ee97a2fef65befafbadcc30ca1bd145.
> However that seems to only trigger the bug. While adding some printk
> the
> problem disappeared, so this might be a timing issue. After some trial
> and
> error I discovered that adding a small delay just before
> igb_write_phy_reg()
> in igb_integrated_phy_loopback() allows the loopback test to succeed.
> I was unable to figure out the root cause so far but I expect it to be
> somewhere in the following executing path
> igb_integrated_phy_loopback
> ->igb_write_phy_reg_igp
> ->igb_write_phy_reg_mdic
> ->igb_acquire_phy_82575
> ->igb_acquire_swfw_sync_82575
>
> As this workaround only introduces a minor delay, which is not in the
> hot
> path I hope this is acceptable. The problem could only be oberved on
> 8086:10c9 NICs so far and not all of them show the behaviour. I did
> not
> restrict the workaround to this type of NIC as it should do no harm to
> other igb NICs.
>
> With the patch below the loopback test succeeded 500 times in a row
> using a NIC that would otherwise fail.
>
> Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
> ---
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
Thanks Stefan, I have added the patch to my queue.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-08-02 1:43 UTC (permalink / raw)
To: chetan loke; +Cc: Bjorn Helgaas, linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <CAAsGZS4nhv+s7NVwaaGjQ9fJoHQoaXnUoYw=xTPC-sfen+tj8A@mail.gmail.com>
On Tue, Jul 31, 2012 at 02:02:25PM -0400, chetan loke wrote:
> On Tue, Jul 31, 2012 at 1:27 PM, Jon Mason <jon.mason@intel.com> wrote:
> >
> > I don't see the benefit of having the driver in staging. Any vendors
> > who would notice the ntb driver in staging would be sitting on these
> > mailing lists and hopefully have planety of comments on the design.
> > Stashing the driver in staging while waiting for these comments (which
> > may never come) doesn't seem the best course of action.
> >
>
> I thought that since others are talking about it then may be there is
> some WIP code for foo-NTB. Seems like that's not the case. So no need
> to stage.
>
> Correct me if I'm wrong but wouldn't apps just open a socket and route
> data via ntb_vir_eth_dev? So I don't see an ABI breakage issue and
> hence nothing would prevent us from changing the kernel parts(for
> accommodating some foo-NTB part) in future.
The virtual ethernet device (patch #2) would allow for a generic way
of passing data to the remote side. The only issue would be changing
how it is encoded in the shared buffer.
> It may not be a bad idea to prefix intel-specific(if any)
> ntb_structs/variables/logic with the 'intc'(Intel ticker or pick your
> string) keyword.
The Intel specific things are current pre-pended with "xeon" or "bwd".
Thanks,
Jon
>
> Chetan Loke
^ permalink raw reply
* Re: [RFC v2 1/2] PCI-Express Non-Transparent Bridge Support
From: Jon Mason @ 2012-08-02 1:49 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, netdev, linux-pci, Dave Jiang
In-Reply-To: <20120731222555.GB19134@kroah.com>
On Tue, Jul 31, 2012 at 03:25:55PM -0700, Greg KH wrote:
> On Sun, Jul 29, 2012 at 05:26:33PM -0700, Jon Mason wrote:
> > +struct ntb_transport_qp;
> > +
> > +struct ntb_client {
> > + char *name;
> > + int (*probe) (struct pci_dev *pdev);
> > + void (*remove) (struct pci_dev *pdev);
> > +};
>
> Why isn't this tied into the driver model? That looks like you really
> want to use a 'struct device' here, right?
>
> Then you have drivers that bind to them, and your devices show up in
> sysfs, which is probably a requirement you have, right?
I was trying to do something more light-weight than that and avoid the
complexity, but this is probably the direction it needs to go.
Thanks,
Jon
>
> greg k-h
^ permalink raw reply
* Re: [PATCH iproute2] ss: report SK_MEMINFO_BACKLOG
From: Shan Wei @ 2012-08-02 6:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, Vijay Subramanian, netdev
In-Reply-To: <1343409083.2626.13105.camel@edumazet-glaptop>
Eric Dumazet said, at 2012/7/28 1:11:
>
> By the way, it seems "ss -u" still uses /proc/net/udp , and not
> inet_diag ?
Yes, UDP doesn't use inet_diag.
Can you provide a patch, we are willing to see it?
>
>
>
>
> --
> 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] firmware: Remove obsolete Chelsio cxgb3 firmware
From: David Miller @ 2012-08-02 7:20 UTC (permalink / raw)
To: tim.gardner
Cc: linux-kernel, paul.gortmaker, ben, JBottomley, dan.j.williams,
divy, netdev
In-Reply-To: <1343848670-31504-1-git-send-email-tim.gardner@canonical.com>
From: Tim Gardner <tim.gardner@canonical.com>
Date: Wed, 1 Aug 2012 13:17:50 -0600
> The current firmware version used by the device driver
> is 7.12.0
>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
> Cc: Ben Hutchings <ben@decadent.org.uk>
> Cc: James Bottomley <JBottomley@Parallels.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Divy Le Ray <divy@chelsio.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
"git am" refuses to apply this to current 'net':
Applying: firmware: Remove obsolete Chelsio cxgb3 firmware
error: removal patch leaves file contents
error: firmware/cxgb3/t3fw-7.10.0.bin.ihex: patch does not apply
^ permalink raw reply
* Re: [PATCHv2 net 0/3] Prevent extreme TSO parameters from stalling TX queues
From: David Miller @ 2012-08-02 7:20 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers, greearb, eric.dumazet, shemminger
In-Reply-To: <1343699476.2667.69.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 31 Jul 2012 02:51:16 +0100
> The following changes fix a potential DoS by peers or local users on
> network interfaces using the sfc driver (and possibly others) with TSO
> enabled (as it is by default).
>
> Please apply patches 1 and 2 to the net tree and your stable update
> queue. I'm not sure whether patch 3 is really important.
>
> Ben.
>
> Ben Hutchings (3):
> net: Allow driver to limit number of GSO segments per skb
> sfc: Fix maximum number of TSO segments and minimum TX queue size
> tcp: Apply device TSO segment limit earlier
Series applied, thanks Ben. I think patch #3 does matter, because
anything in TCP that cares about the "limit" now must make both
tests.
^ permalink raw reply
* Re: [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: David Miller @ 2012-08-02 7:21 UTC (permalink / raw)
To: fdu; +Cc: herbert, netdev
In-Reply-To: <1343720634-1176-2-git-send-email-fdu@windriver.com>
From: Fan Du <fdu@windriver.com>
Date: Tue, 31 Jul 2012 15:43:54 +0800
> After SA is setup, one timer is armed to detect soft/hard expiration,
> however the timer handler uses xtime to do the math. This makes hard
> expiration occurs first before soft expiration after setting new date
> with big interval. As a result new child SA is deleted before rekeying
> the new one.
>
> Signed-off-by: Fan Du <fdu@windriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bnx2x: fix mem leak when command is unknown
From: David Miller @ 2012-08-02 7:21 UTC (permalink / raw)
To: jj; +Cc: eilong, netdev, linux-kernel
In-Reply-To: <alpine.LNX.2.00.1207312337590.7100@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Tue, 31 Jul 2012 23:39:37 +0200 (CEST)
> In bnx2x_mcast_enqueue_cmd() we'll leak the memory allocated to
> 'new_cmd' if we hit the deafault case of the 'switch (cmd)'.
> Add a 'kfree(new_cmd)' to that case to avoid the leak.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Applied.
^ permalink raw reply
* Re: [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: David Miller @ 2012-08-02 7:23 UTC (permalink / raw)
To: fdu; +Cc: herbert, netdev
In-Reply-To: <20120802.002100.1997441066753440100.davem@davemloft.net>
You know what Fan Du, I'm extremely irritated about your email
situation.
Every time you post a patch, I reply, and I get this crap:
Diagnostic-Code: smtp; 5.1.0 - Unknown address error 550-'5.2.1 <fdu@windriver.com>... Mailbox disabled for this recipient' (delivery attempts: 0)
I've seen this at least 7 times, and this absolutely has to stop.
Otherwise I'm ignoring every patch you submit, it's as simple as
that.
^ permalink raw reply
* Re: [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: David Miller @ 2012-08-02 7:23 UTC (permalink / raw)
To: fdu; +Cc: herbert, netdev
In-Reply-To: <20120802.002308.367808111426941908.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 02 Aug 2012 00:23:08 -0700 (PDT)
>
> You know what Fan Du, I'm extremely irritated about your email
> situation.
>
> Every time you post a patch, I reply, and I get this crap:
And this email triggered it too, what gives?
^ permalink raw reply
* [PATCH] ipv4: route.c cleanup
From: Eric Dumazet @ 2012-08-02 7:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Remove some unused includes and sysctls after route cache removal.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
This probably can wait net-next
net/ipv4/route.c | 58 ---------------------------------------------
1 file changed, 1 insertion(+), 57 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index c035251..67790ba 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -70,7 +70,6 @@
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/mm.h>
-#include <linux/bootmem.h>
#include <linux/string.h>
#include <linux/socket.h>
#include <linux/sockios.h>
@@ -80,7 +79,6 @@
#include <linux/netdevice.h>
#include <linux/proc_fs.h>
#include <linux/init.h>
-#include <linux/workqueue.h>
#include <linux/skbuff.h>
#include <linux/inetdevice.h>
#include <linux/igmp.h>
@@ -88,11 +86,9 @@
#include <linux/mroute.h>
#include <linux/netfilter_ipv4.h>
#include <linux/random.h>
-#include <linux/jhash.h>
#include <linux/rcupdate.h>
#include <linux/times.h>
#include <linux/slab.h>
-#include <linux/prefetch.h>
#include <net/dst.h>
#include <net/net_namespace.h>
#include <net/protocol.h>
@@ -118,18 +114,11 @@
#define IP_MAX_MTU 0xFFF0
-#define RT_GC_TIMEOUT (300*HZ)
-
-static int ip_rt_max_size;
-static int ip_rt_gc_timeout __read_mostly = RT_GC_TIMEOUT;
-static int ip_rt_gc_interval __read_mostly = 60 * HZ;
-static int ip_rt_gc_min_interval __read_mostly = HZ / 2;
static int ip_rt_redirect_number __read_mostly = 9;
static int ip_rt_redirect_load __read_mostly = HZ / 50;
static int ip_rt_redirect_silence __read_mostly = ((HZ / 50) << (9 + 1));
static int ip_rt_error_cost __read_mostly = HZ;
static int ip_rt_error_burst __read_mostly = 5 * HZ;
-static int ip_rt_gc_elasticity __read_mostly = 8;
static int ip_rt_mtu_expires __read_mostly = 10 * 60 * HZ;
static int ip_rt_min_pmtu __read_mostly = 512 + 20 + 20;
static int ip_rt_min_advmss __read_mostly = 256;
@@ -2382,43 +2371,6 @@ static ctl_table ipv4_route_table[] = {
.proc_handler = proc_dointvec,
},
{
- .procname = "max_size",
- .data = &ip_rt_max_size,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
- /* Deprecated. Use gc_min_interval_ms */
-
- .procname = "gc_min_interval",
- .data = &ip_rt_gc_min_interval,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
- },
- {
- .procname = "gc_min_interval_ms",
- .data = &ip_rt_gc_min_interval,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_ms_jiffies,
- },
- {
- .procname = "gc_timeout",
- .data = &ip_rt_gc_timeout,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
- },
- {
- .procname = "gc_interval",
- .data = &ip_rt_gc_interval,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec_jiffies,
- },
- {
.procname = "redirect_load",
.data = &ip_rt_redirect_load,
.maxlen = sizeof(int),
@@ -2454,13 +2406,6 @@ static ctl_table ipv4_route_table[] = {
.proc_handler = proc_dointvec,
},
{
- .procname = "gc_elasticity",
- .data = &ip_rt_gc_elasticity,
- .maxlen = sizeof(int),
- .mode = 0644,
- .proc_handler = proc_dointvec,
- },
- {
.procname = "mtu_expires",
.data = &ip_rt_mtu_expires,
.maxlen = sizeof(int),
@@ -2599,7 +2544,6 @@ int __init ip_rt_init(void)
panic("IP: failed to allocate ipv4_dst_blackhole_ops counter\n");
ipv4_dst_ops.gc_thresh = ~0;
- ip_rt_max_size = INT_MAX;
devinet_init();
ip_fib_init();
@@ -2608,7 +2552,7 @@ int __init ip_rt_init(void)
pr_err("Unable to create route proc files\n");
#ifdef CONFIG_XFRM
xfrm_init();
- xfrm4_init(ip_rt_max_size);
+ xfrm4_init(INT_MAX);
#endif
rtnl_register(PF_INET, RTM_GETROUTE, inet_rtm_getroute, NULL, NULL);
^ permalink raw reply related
* [PATCH] ipv6: Fix premature timeout for MLDv1 compatibility mode
From: Dragos Ilie @ 2012-08-02 7:51 UTC (permalink / raw)
To: David S. Miller
Cc: Dragos Ilie, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, linux-kernel
The timeout for MLDv1 compatibility mode is now calculated according
to Section 9.2 in RFC 3810.
Signed-off-by: Dragos Ilie <dragos.ilie@gmail.com>
---
net/ipv6/mcast.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 92f8e48..ef824a0 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -109,6 +109,7 @@ static int ip6_mc_leave_src(struct sock *sk, struct ipv6_mc_socklist *iml,
#define IGMP6_UNSOLICITED_IVAL (10*HZ)
#define MLD_QRV_DEFAULT 2
+#define MLD_QIVAL_DEFAULT (125*HZ)
#define MLD_V1_SEEN(idev) (dev_net((idev)->dev)->ipv6.devconf_all->force_mld_version == 1 || \
(idev)->cnf.force_mld_version == 1 || \
@@ -1152,7 +1153,7 @@ int igmp6_event_query(struct sk_buff *skb)
/* Translate milliseconds to jiffies */
max_delay = (ntohs(mld->mld_maxdelay)*HZ)/1000;
- switchback = (idev->mc_qrv + 1) * max_delay;
+ switchback = (idev->mc_qrv * MLD_QIVAL_DEFAULT) + max_delay;
idev->mc_v1_seen = jiffies + switchback;
/* cancel the interface change timer */
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH V2 05/12] net: Add ndo_set_vif_param operation to serve eIPoIB VIFs
From: Erez Shitrit @ 2012-08-02 8:25 UTC (permalink / raw)
To: Ben Hutchings
Cc: Or Gerlitz, davem, roland, netdev, ali, sean.hefty, Erez Shitrit
In-Reply-To: <1343866622.2602.62.camel@bwh-desktop.uk.solarflarecom.com>
On 8/2/2012 3:17 AM, Ben Hutchings wrote:
> On Wed, 2012-08-01 at 20:09 +0300, Or Gerlitz wrote:
>> From: Erez Shitrit <erezsh@mellanox.co.il>
>>
>> The Ethernet IPoIB driver enslaves IPoIB devices and uses them as
>> VIFs (Virtual Interface) which serve an Ethernet NIC e.g present in a
>> guest OS. For each such slave that acts as a VIF, eIPoIB needs to know
>> the mac and optionally the vlan uses by that NIC, the new ndo opertaion
>> is used to associate the mac/vlan for that slave.
>>
>> Signed-off-by: Erez Shitrit <erezsh@mellanox.co.il>
>> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>> ---
>> include/linux/netdevice.h | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index eb06e58..2709551 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -1013,7 +1013,10 @@ struct net_device_ops {
>> netdev_features_t features);
>> int (*ndo_neigh_construct)(struct neighbour *n);
>> void (*ndo_neigh_destroy)(struct neighbour *n);
>> -
>> + int (*ndo_set_vif_param) (struct net_device *dev,
>> + struct net_device *vif,
>> + u16 vlan,
>> + u8 *mac);
> The semantics of this operation should be documented in the comment
> above the structure definition. One detail worth covering is whether
> 'vlan' is just a VID or can also include priority+CFI bits.
We will add more documentation for that.
The idea was just for the VID, (in our driver at least)
>
> If this is specific to eIPoIB, why not put that in the name of the
> operation? If not, this *really* needs explaining because so far I have
> no whether it is something I should consider implementing on a real
> Ethernet device.
>
> Ben.
Will add more documentation here, perhaps other drivers can use it as
well for visualization uses and more.
Thanks.
>> int (*ndo_fdb_add)(struct ndmsg *ndm,
>> struct net_device *dev,
>> unsigned char *addr,
^ 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