* [PATCH 04/73] netfilter: don't use module_init/exit in core IPV4 code
From: Paul Gortmaker @ 2014-01-21 21:22 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, Paul Gortmaker, Pablo Neira Ayuso, Patrick McHardy,
Jozsef Kadlecsik, David S. Miller, netfilter-devel, netdev
In-Reply-To: <1390339396-3479-1-git-send-email-paul.gortmaker@windriver.com>
The file net/ipv4/netfilter.o is created based on whether
CONFIG_NETFILTER is set. However that is defined as a bool, and
hence this file with the core netfilter hooks will never be
modular. So using module_init as an alias for __initcall can be
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing. Also add an inclusion of init.h, as
that was previously implicit here in the netfilter.c file.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of subsys_initcall (which
seems to make sense for netfilter code) will thus change this
registration from level 6-device to level 4-subsys (i.e. slightly
earlier). However no observable impact of that small difference
has been observed during testing, or is expected. (i.e. the
location of the netfilter messages in dmesg remains unchanged
with respect to all the other surrounding messages.)
As for the module_exit, rather than replace it with __exitcall,
we simply remove it, since it appears only UML does anything
with those, and even for UML, there is no relevant cleanup
to be done here.
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netfilter-devel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/ipv4/netfilter.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index c3e0ade..31abf96 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -197,11 +197,4 @@ static int __init ipv4_netfilter_init(void)
{
return nf_register_afinfo(&nf_ip_afinfo);
}
-
-static void __exit ipv4_netfilter_fini(void)
-{
- nf_unregister_afinfo(&nf_ip_afinfo);
-}
-
-module_init(ipv4_netfilter_init);
-module_exit(ipv4_netfilter_fini);
+device_initcall(ipv4_netfilter_init);
--
1.8.4.1
^ permalink raw reply related
* Re: issues with vxlan RX checksum offload under OVS datapath
From: Joseph Gasparakis @ 2014-01-21 21:47 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Pravin Shelar, Or Gerlitz, Joseph Gasparakis, netdev
In-Reply-To: <CAJZOPZJ6xj=fOAY9rkXZZs99ONkHwcW8RMXb+H2FjJzV3eoAPg@mail.gmail.com>
On Tue, 21 Jan 2014, Or Gerlitz wrote:
> On Tue, Jan 21, 2014 at 7:30 PM, Pravin Shelar <pshelar@nicira.com> wrote:
> > On Sun, Jan 19, 2014 at 2:05 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>
> >> While testing the gro udp patches over a setup with openvswitch I noted that
> >> the RX checksum offload support introduced by Joseph's commit 0afb166
> >> "vxlan: Add capability of Rx checksum offload for inner packet" works fine
> >> when you use a setup made of
> >> NIC --> IP stack --> vxlan device --> bridge --> tap
> >> but not when its
> >> NIC --> IP stack --> ovs vxlan port --> OVS DP --> tap
> >> I narrowed it down to the fact the when going the OVS pathskb->encapsulation
> >> remains true also after the decap is done. Basically, this is the original hunk
> [...]
> >>> + skb->encapsulation = 0;
> [...]
>
> >> Moving this to shared code (while removing the check for
> >> vxlan->dev->features) made things to work on my setup, but this misses one
> >> of the original conditions, ideas?
>
> > I kept csum check in vxlan-device recv path for same reason. As of now
> > there is no efficient way to get ovs-dev features.
> > May be we can cache device features in struct datapath from datapath-netdev.
>
> To be a bit more precise/concrete here, do we agree that the both paths must do
>
> skb->encapsulation = 0;
>
> which is done now only by the non-ovs path
Originally skb->encapsulation had (and still has) the meaning of "does
this skb have outer *and* (valid) inner headers? If so, it is an
encapsulated packet".
So based on this skb->encapsulation should be set as soon an (inner)
packet gets encapsulated and unset when decapsulation takes place, and
ideally this should happen in the ovs path too. Together with
skb->encapsulation the inner headers should be correctly set.
>
> Or.
>
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] bonding: add netlink attributes to slave link dev
From: Scott Feldman @ 2014-01-21 21:36 UTC (permalink / raw)
To: Jiri Pirko
Cc: Veaceslav Falico, Jay Vosburgh, Andy Gospodarek, Netdev,
Roopa Prabhu, Shrijeet Mukherjee, Ding Tianhong
In-Reply-To: <20140121133426.GC3015@minipsycho.orion>
On Jan 21, 2014, at 5:34 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> + if (rtnl_bond_slave_fill(skb, dev))
>> + goto nla_put_failure;
>> +
>
> I must say I do not like this at all. This should be done in a generic
> way. By a callback registered by bonding and possibly other master-slave
> device types.
The bond was registered with the ndo_get_slave op. ndo_get_slave could be used for other master-slave device types. I’ll agree that rtnl_bond_slave_fill() could have been written more generically. Is that the objection?
> I have something in mind, will try to prepare patch soon.
^ permalink raw reply
* Re: issues with vxlan RX checksum offload under OVS datapath
From: Or Gerlitz @ 2014-01-21 21:43 UTC (permalink / raw)
To: Joseph Gasparakis; +Cc: Pravin Shelar, Or Gerlitz, netdev
In-Reply-To: <alpine.LFD.2.03.1401211336550.16080@intel.com>
On Tue, Jan 21, 2014, Joseph Gasparakis <joseph.gasparakis@intel.com> wrote:
> On Tue, 21 Jan 2014, Or Gerlitz wrote:
>> To be a bit more precise/concrete here, do we agree that the both paths must >> skb->encapsulation = 0;
>> which is done now only by the non-ovs path
> Originally skb->encapsulation had (and still has) the meaning of "does
> this skb have outer *and* (valid) inner headers? If so, it is an
> encapsulated packet".
> So based on this skb->encapsulation should be set as soon an (inner)
> packet gets encapsulated and unset when decapsulation takes place, and
> ideally this should happen in the ovs path too.
I would say critically not ideally... e.g when the packet is
destinat-ed to a VM and goes through tap netdevice plugged to OVS --
without this de-assignment weird things happen after the point in time
where the ovs TX path calls dev_queue_xmit() in
net/openvswitch/vport-netdev.c
> Together with skb->encapsulation the inner headers should be correctly set.
That's interesting point, what might break if this isn't done?
^ permalink raw reply
* Re: [PATCH net-next 00/25] bonding: introduce new option API
From: Scott Feldman @ 2014-01-21 21:51 UTC (permalink / raw)
To: Dan Williams
Cc: Nikolay Aleksandrov, Netdev, Andy Gospodarek, Jay Vosburgh,
Veaceslav Falico, David S. Miller
In-Reply-To: <1390319983.26902.4.camel@dcbw.local>
On Jan 21, 2014, at 7:59 AM, Dan Williams <dcbw@redhat.com> wrote:
> On Tue, 2014-01-21 at 15:54 +0100, Nikolay Aleksandrov wrote:
>> Hi,
>> This patchset's goal is to introduce a new option API which should be used
>> to properly describe the bonding options with their mode dependcies and
>> requirements. With this patchset applied we get centralized option
>> manipulation, automatic RTNL acquire per option setting, automatic option
>> range checking, mode dependcy checking and other various flags which are
>> described in detail in patch 01's commit message and comments.
>> Also the parameter passing is changed to use a specialized structure which
>> is initialized to a value depending on the needs.
>
> Currently userspace has to encode a lot of the same logic the kernel has
> for option validation, for example when creating a user interface for
> this stuff, you have to know that miimon and arp are incompatible, and
> that certain options are only relevant with certain bond modes, and it's
> a mess. And this also sometimes changes when new kernel options or
> capabilities are added.
Note that if using the new netlink support for bonding via an updated ip link command, incompatible options will be caught and the command will fail. For example, if you try to create a new bond and set both miimon and arp, the bond create will fail (and err msg logged). Once the bond is created, again trying to set incompatible options with one command will fail in the same way. If options are set one at a time on existing bond, then last set option takes precedence and may override earlier settings.
None of this is true if using sysfs. So user-space tools should move to ip link (or netlink directly) rather than using sysfs for bond config.
>
> So, is there any good way to describe the valid value ranges or
> capabilities for userspace? One idea is to send a package of bond
> options to the kernel and see if they validate before actually applying
> them, though this only works when actually configuring the interface.
> An additional idea would be to somehow describe the available options
> (eg, value ranges for numeric values, list-of-strings for bond modes,
> etc) that the kernel supports before any bonds are even created (thus
> probably through netlink, not sysfs).
>
> Thoughts?
^ permalink raw reply
* [PATCH] checkpatch: Prefer ether_addr_copy to memcpy(foo, bar, ETH_ALEN)
From: Joe Perches @ 2014-01-21 21:51 UTC (permalink / raw)
To: Andrew Morton, Andy Whitcroft; +Cc: David Miller, netdev, LKML
ether_addr_copy was added for kernel version 3.14.
It's slightly smaller/faster for some arches.
Encourage its use.
Signed-off-by: Joe Perches <joe@perches.com>
---
scripts/checkpatch.pl | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index be53ba7..0ea2a1e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4096,6 +4096,16 @@ sub process {
}
}
+# Check for memcpy(foo, bar, ETH_ALEN) that could be ether_addr_copy(foo, bar)
+ if ($^V && $^V ge 5.10.0 &&
+ $line =~ /^\+(?:.*?)\bmemcpy\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/s) {
+ if (WARN("PREFER_ETHER_ADDR_COPY",
+ "Prefer ether_addr_copy() over memcpy() if the Ethernet addresses are __aligned(2)\n" . $herecurr) &&
+ $fix) {
+ $fixed[$linenr - 1] =~ s/\bmemcpy\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\,\s*ETH_ALEN\s*\)/ether_addr_copy($2, $7)/;
+ }
+ }
+
# typecasts on min/max could be min_t/max_t
if ($^V && $^V ge 5.10.0 &&
defined $stat &&
^ permalink raw reply related
* Re: [PATCH net-next v2 2/2] bonding: add netlink attributes to slave link dev
From: Jiri Pirko @ 2014-01-21 22:00 UTC (permalink / raw)
To: Scott Feldman
Cc: Veaceslav Falico, Jay Vosburgh, Andy Gospodarek, Netdev,
Roopa Prabhu, Shrijeet Mukherjee, Ding Tianhong
In-Reply-To: <0A99CC69-DBFF-46DF-9300-D2C6DF10A965@cumulusnetworks.com>
Tue, Jan 21, 2014 at 10:36:58PM CET, sfeldma@cumulusnetworks.com wrote:
>
>On Jan 21, 2014, at 5:34 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>
>>> + if (rtnl_bond_slave_fill(skb, dev))
>>> + goto nla_put_failure;
>>> +
>>
>> I must say I do not like this at all. This should be done in a generic
>> way. By a callback registered by bonding and possibly other master-slave
>> device types.
>
>The bond was registered with the ndo_get_slave op. ndo_get_slave could be used for other master-slave device types. I’ll agree that rtnl_bond_slave_fill() could have been written more generically. Is that the objection?
I think is should be done rather in rtnl_link_ops. It's the natural point
for this ops. I have patchset prepared. Will send it very soon.
>
>> I have something in mind, will try to prepare patch soon.
>
>
^ permalink raw reply
* Re: issues with vxlan RX checksum offload under OVS datapath
From: Joseph Gasparakis @ 2014-01-21 22:35 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Joseph Gasparakis, Pravin Shelar, Or Gerlitz, netdev
In-Reply-To: <CAJZOPZKdSmuEQv6dcuLb8E8CqBuTvpywQXZypFTp+j3Xnw2E0w@mail.gmail.com>
On Tue, 21 Jan 2014, Or Gerlitz wrote:
> On Tue, Jan 21, 2014, Joseph Gasparakis <joseph.gasparakis@intel.com> wrote:
> > On Tue, 21 Jan 2014, Or Gerlitz wrote:
>
> >> To be a bit more precise/concrete here, do we agree that the both paths must >> skb->encapsulation = 0;
> >> which is done now only by the non-ovs path
>
> > Originally skb->encapsulation had (and still has) the meaning of "does
> > this skb have outer *and* (valid) inner headers? If so, it is an
> > encapsulated packet".
> > So based on this skb->encapsulation should be set as soon an (inner)
> > packet gets encapsulated and unset when decapsulation takes place, and
> > ideally this should happen in the ovs path too.
>
> I would say critically not ideally... e.g when the packet is
> destinat-ed to a VM and goes through tap netdevice plugged to OVS --
> without this de-assignment weird things happen after the point in time
> where the ovs TX path calls dev_queue_xmit() in
> net/openvswitch/vport-netdev.c
>
> > Together with skb->encapsulation the inner headers should be correctly set.
>
> That's interesting point, what might break if this isn't done?
Well, the inner headers, same as the generic (outer) headers are pointers
or offsets that are going to be added to the packet data pointer. If for
any reason we try to access these pointers when they are invalid anything
can go wrong... The way to indicate if they are valid or not should be
skb->encapsulation.
>
^ permalink raw reply
* Re: [PATCH 53/73] drivers/isdn: delete non-required instances of include <linux/init.h>
From: David Miller @ 2014-01-21 22:35 UTC (permalink / raw)
To: paul.gortmaker; +Cc: linux-kernel, linux-arch, isdn, mac, netdev
In-Reply-To: <1390339396-3479-54-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Tue, 21 Jan 2014 16:22:56 -0500
> None of these files are actually using any __init type directives
> and hence don't need to include <linux/init.h>. Most are just a
> left over from __devinit and __cpuinit removal, or simply due to
> code getting copied from one driver to the next.
>
> Cc: Karsten Keil <isdn@linux-pingi.de>
> Cc: Armin Schindler <mac@melware.de> (maintainer:ISDN SUBSYSTEM
> Cc: netdev@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer
From: David Miller @ 2014-01-21 22:36 UTC (permalink / raw)
To: matija.glavinic-pecotic.ext; +Cc: linux-sctp, alexander.sverdlin, netdev
In-Reply-To: <52D8D544.5050501@nsn.com>
From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Date: Fri, 17 Jan 2014 08:01:24 +0100
> Implementation of (a)rwnd calculation might lead to severe performance issues
> and associations completely stalling. These problems are described and solution
> is proposed which improves lksctp's robustness in congestion state.
It would be fantastic if an SCTP expert would review this patch, it's
been rotting in patchwork for 4 days.
Thanks.
^ permalink raw reply
* Re: [PATCH v3] sch_htb: let skb->priority refer to non-leaf class
From: David Miller @ 2014-01-21 22:36 UTC (permalink / raw)
To: harry.mason; +Cc: sergei.shtylyov, hadi, eric.dumazet, netdev
In-Reply-To: <1389964952.4698.20.camel@azathoth.dev.smoothwall.net>
From: Harry Mason <harry.mason@smoothwall.net>
Date: Fri, 17 Jan 2014 13:22:32 +0000
> If the class in skb->priority is not a leaf, apply filters from the
> selected class, not the qdisc. This lets netfilter or user space
> partially classify the packet.
>
> Signed-off-by: Harry Mason <harry.mason@smoothwall.net>
Can I please get some reviews of this patch?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] bonding: add netlink attributes to slave link dev
From: Scott Feldman @ 2014-01-21 22:42 UTC (permalink / raw)
To: Jiri Pirko
Cc: Veaceslav Falico, Jay Vosburgh, Andy Gospodarek, Netdev,
Roopa Prabhu, Shrijeet Mukherjee, Ding Tianhong
In-Reply-To: <20140121220016.GF3015@minipsycho.orion>
On Jan 21, 2014, at 2:00 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Jan 21, 2014 at 10:36:58PM CET, sfeldma@cumulusnetworks.com wrote:
>>
>> On Jan 21, 2014, at 5:34 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>
>>>> + if (rtnl_bond_slave_fill(skb, dev))
>>>> + goto nla_put_failure;
>>>> +
>>>
>>> I must say I do not like this at all. This should be done in a generic
>>> way. By a callback registered by bonding and possibly other master-slave
>>> device types.
>>
>> The bond was registered with the ndo_get_slave op. ndo_get_slave could be used for other master-slave device types. I’ll agree that rtnl_bond_slave_fill() could have been written more generically. Is that the objection?
>
> I think is should be done rather in rtnl_link_ops. It's the natural point
> for this ops. I have patchset prepared. Will send it very soon.
Ok, cool.
Also, right now I have IFLA_SLAVE as a nest for IFLA_SLAVE_xxx attrs. Do you think we should have a two-layer nest so we can capture other master-slave devices rather than just bond slaves? I.e.:
IFLA_SLAVE
IFLA_BOND_SLAVE
IFLA_BOND_SLAVE_xxx
IFLA_BOND_SLAVE_yyy
IFLA_BOND_SLAVE_zzz
IFLA_FOO_SLAVE // FOO is some other non-bond master
IFLA_FOO_SLAVE_xxx
IFLA_FOO_SLAVE_yyy
IFLA_FOO_SLAVE_zzz
(Of course, slave wouldn’t be bond and foo slave at same time).
-scott
^ permalink raw reply
* Re: [Patch net-next 1/6] net_sched: act: fetch hinfo from a->ops->hinfo
From: David Miller @ 2014-01-21 22:43 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jhs
In-Reply-To: <1389987427-14085-2-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 17 Jan 2014 11:37:02 -0800
> Every action ops has a pointer to hash info, so we don't need to
> hard-code it in each module.
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [Patch net-next 2/6] net_sched: act: export tcf_hash_search() instead of tcf_hash_lookup()
From: David Miller @ 2014-01-21 22:44 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jhs
In-Reply-To: <1389987427-14085-3-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Fri, 17 Jan 2014 11:37:03 -0800
> So that we will not expose struct tcf_common to modules.
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Bug Fixes for SFC driver
From: David Miller @ 2014-01-21 22:47 UTC (permalink / raw)
To: sshah; +Cc: netdev, linux-net-drivers
In-Reply-To: <52D98860.4020402@solarflare.com>
From: Shradha Shah <sshah@solarflare.com>
Date: Fri, 17 Jan 2014 19:45:36 +0000
> I am taking over the upstream patch submission work for the
> sfc driver from Ben Hutchings.
>
> These patches are bug fixes to the sfc driver involving
> replacement of the PORT RESET MC command and fixing transposed
> ptp_{under,over}size_sync_window_statistics
>
> The PORT_RESET bug fix is needed for all versions supporting EF10
> i.e all versions including and after 3.12.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Correctly sync addresses from multiple sources to single device
From: David Miller @ 2014-01-21 22:53 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, andrey.dmitrov
In-Reply-To: <1389988332-22472-1-git-send-email-vyasevic@redhat.com>
From: Vlad Yasevich <vyasevic@redhat.com>
Date: Fri, 17 Jan 2014 14:52:12 -0500
> When we have multiple devices attempting to sync the same address
> to a single destination, each device should be permitted to sync
> it once. To accomplish this, pass the sync count of the source
> address to __hw_addr_add_ex(). 'sync_cnt' tracks how many time
> a given address has been successfully synced. If the address
> is found in the destination list, but the 'sync_cnt' of the source
> is 0, then this address has not been synced from this interface
> and we need to allow the sync operation to succeed thus incrementing
> reference counts.
>
> Reported-by: Andrey Dmitrov <andrey.dmitrov@oktetlabs.ru>
> CC: Andrey Dmitrov <andrey.dmitrov@oktetlabs.ru>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
I applied this to net-next since 3.13 just got released, and it doesn't
compile.
net/core/dev_addr_lists.c: In function ‘__hw_addr_sync_one’:
net/core/dev_addr_lists.c:144:26: error: ‘struct netdev_hw_addr’ has no member named ‘sync_count’
^ permalink raw reply
* Re: [PATCH] [trivial] ixgbe: Fix format string in ixgbe_fcoe.c
From: Brown, Aaron F @ 2014-01-21 23:04 UTC (permalink / raw)
To: standby24x7@gmail.com
Cc: Kirsher, Jeffrey T, Brandeburg, Jesse, Allan, Bruce W,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, trivial@kernel.org
In-Reply-To: <1389716082-23395-1-git-send-email-standby24x7@gmail.com>
On Wed, 2014-01-15 at 01:14 +0900, Masanari Iida wrote:
> cppcheck detected following warning in ixgbe_fcoe.c
> (warning) %d in format string (no. 1) requires 'int' but the
> argument type is 'unsigned int'.
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Tested-By: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Aaron Brown <aaron.f.brown@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> index f58db45..0872617 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
> @@ -585,7 +585,7 @@ static int ixgbe_fcoe_dma_pool_alloc(struct ixgbe_fcoe *fcoe,
> struct dma_pool *pool;
> char pool_name[32];
>
> - snprintf(pool_name, 32, "ixgbe_fcoe_ddp_%d", cpu);
> + snprintf(pool_name, 32, "ixgbe_fcoe_ddp_%u", cpu);
>
> pool = dma_pool_create(pool_name, dev, IXGBE_FCPTR_MAX,
> IXGBE_FCPTR_ALIGN, PAGE_SIZE);
^ permalink raw reply
* Re: r8169 won't transmit with 3.12
From: Francois Romieu @ 2014-01-21 23:36 UTC (permalink / raw)
To: Craig Small; +Cc: Realtek linux nic maintainers, netdev
In-Reply-To: <20140121000615.GA30495@enc.com.au>
Craig Small <csmall@enc.com.au> :
[...]
> It's a new setup so it might of never worked. It's not likely to be a
> hardware problem as its three different devices.
You may check that the onboard nic device does not even work when the
extra PCI-e card aren't plugged.
> I've sent what I think you might need for starters, but if there
> is extra stuff you'd like to see, let me know.
A complete dmesg including the XID lines that the r8169 driver prints
would be welcome.
> The problem shows up the same, the TX dropped counter increments.
> I'm not sure why 42 packets made it out (or even if they really did)
> Receive works fine, I can even start up wireshark and see packets
> pass by.
>
> eth0 Link encap:Ethernet HWaddr 00:e0:4c:80:66:57
> inet addr:192.168.1.222 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::2e0:4cff:fe80:6657/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:8252 errors:0 dropped:0 overruns:0 frame:0
> TX packets:42 errors:0 dropped:8029 overruns:0 carrier:0
There are very few places where the r8169 driver modifies tx_dropped.
Please increase the driver verbosity with the 'msglvl' option of ethtool.
[...]
> ethtool -S shows a similar story, not sure if the rx_missed counter
> is another problem:
It seems safe to ignore as long as it does not change after startup.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer
From: Vlad Yasevich @ 2014-01-22 0:08 UTC (permalink / raw)
To: David Miller, matija.glavinic-pecotic.ext
Cc: linux-sctp, alexander.sverdlin, netdev
In-Reply-To: <20140121.143620.1777441472756091252.davem@davemloft.net>
On 01/21/2014 05:36 PM, David Miller wrote:
> From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
> Date: Fri, 17 Jan 2014 08:01:24 +0100
>
>> Implementation of (a)rwnd calculation might lead to severe performance issues
>> and associations completely stalling. These problems are described and solution
>> is proposed which improves lksctp's robustness in congestion state.
>
> It would be fantastic if an SCTP expert would review this patch, it's
> been rotting in patchwork for 4 days.
>
Apologies. It's been on my to do list.
-vlad
^ permalink raw reply
* Re: [PATCH net-next v2] ipv6: enable anycast addresses as source addresses for datagrams
From: Hannes Frederic Sowa @ 2014-01-22 0:16 UTC (permalink / raw)
To: Francois-Xavier Le Bail; +Cc: netdev, David Stevens, David Miller
In-Reply-To: <1390320070-12735-1-git-send-email-fx.lebail@yahoo.com>
On Tue, Jan 21, 2014 at 05:01:10PM +0100, Francois-Xavier Le Bail wrote:
> diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
> index 5a80f15..d3a6e2d 100644
> --- a/net/ipv6/anycast.c
> +++ b/net/ipv6/anycast.c
> @@ -383,6 +383,17 @@ bool ipv6_chk_acast_addr(struct net *net, struct net_device *dev,
> return found;
> }
>
> +/* check if this anycast address is link-local on given interface or
> + * is global
> + */
> +bool ipv6_chk_acast_addr_src(struct net *net, struct net_device *dev,
> + const struct in6_addr *addr)
> +{
> + if (ipv6_addr_type(addr) & IPV6_ADDR_LINKLOCAL)
> + return ipv6_chk_acast_dev(dev, addr);
> + else
> + return ipv6_chk_acast_addr(net, NULL, addr);
> +}
You need to do the check with ipv6_chk_acast_addr in both cases, as only
ipv6_chk_acast_addr does a rcu_read_lock and it is needed for the dereference
of inet6_dev (__in6_dev_get is not safe in ipv6_chk_acast_dev without
rcu_read_lock).
Otherwise I am fine with this patch, thanks!
^ permalink raw reply
* Re: [PATCH net-next 1/5] bonding: The fail_over_mac should be set only in ACTIVE_BACKUP mode
From: Jay Vosburgh @ 2014-01-22 0:25 UTC (permalink / raw)
To: Ding Tianhong; +Cc: Veaceslav Falico, David S. Miller, Netdev, Andy Gospodarek
In-Reply-To: <52DE4161.3050801@huawei.com>
Ding Tianhong <dingtianhong@huawei.com> wrote:
>According the bonding.txt, the option fail_over_mac only affect for
>AB mode, but in currect code, the parameter could be set to active
>or follow in every mode, this will cause bonding could not set all
>slaves of an RR or XOR mode to the same MAC address at enslavement
>time, so reset fail_over_mac to 0 if the mode is not ACTIVE_BACKUP.
The correct way to fix this in general is to permit setting an
option at any time, but only have it take effect in active-backup mode.
This minimizes ordering requirements when setting options.
I would instead modify the bond enslave and removal processing
to check the mode in addition to fail_over_mac when setting a slave's
MAC during enslavement. The change active slave processing already only
calls the fail_over_mac function when in active-backup mode. This
should also be a simpler change set.
>Fix the wrong variables for pr_err().
>
>Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>---
> drivers/net/bonding/bond_main.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 3220b48..ecff04e 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -4307,12 +4307,14 @@ static int bond_check_params(struct bond_params *params)
> fail_over_mac_tbl);
> if (fail_over_mac_value == -1) {
> pr_err("Error: invalid fail_over_mac \"%s\"\n",
>- arp_validate == NULL ? "NULL" : arp_validate);
>+ fail_over_mac == NULL ? "NULL" : fail_over_mac);
This part is ok.
> return -EINVAL;
> }
>
>- if (bond_mode != BOND_MODE_ACTIVEBACKUP)
>- pr_warning("Warning: fail_over_mac only affects active-backup mode.\n");
>+ if (bond_mode != BOND_MODE_ACTIVEBACKUP) {
>+ pr_warning("Warning: fail_over_mac only affects active-backup mode, set it to 0.\n");
>+ fail_over_mac_value = BOND_FOM_NONE;
>+ }
This part is not.
I would additionally NAK patches 2, 3, and 4 (noting that 4
inhibits the change to fail_over_mac, but not the warning message that
we're changing it).
Patch 5 is ok, although it really has nothing to do with
fail_over_mac.
-J
> } else {
> fail_over_mac_value = BOND_FOM_NONE;
> }
>--
>1.8.0
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH net-next] net: add vxlan description
From: David Miller @ 2014-01-22 0:28 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: netdev, stephen
In-Reply-To: <1389985233-8097-1-git-send-email-jesse.brandeburg@intel.com>
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Fri, 17 Jan 2014 11:00:33 -0800
> Add a description to the vxlan module, helping save the world
> from the minions of destruction and confusion.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Applied, thanks Jesse.
^ permalink raw reply
* [PATCH net-next] bridge: Remove unnecessary vlan_put_tag in br_handle_vlan
From: Toshiaki Makita @ 2014-01-22 0:29 UTC (permalink / raw)
To: David S . Miller, Stephen Hemminger, Vlad Yasevich, netdev
Cc: Toshiaki Makita
br_handle_vlan() pushes HW accelerated vlan tag into skbuff when outgoing
port is the bridge device.
This is unnecessary because __netif_receive_skb_core() can handle skbs
with HW accelerated vlan tag. In current implementation,
__netif_receive_skb_core() needs to extract the vlan tag embedded in skb
data. This could cause low network performance especially when receiving
frames at a high frame rate on the bridge device.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
---
net/bridge/br_vlan.c | 21 ---------------------
1 file changed, 21 deletions(-)
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 7ffc801..4ca4d0a 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -151,27 +151,6 @@ struct sk_buff *br_handle_vlan(struct net_bridge *br,
br_vlan_get_tag(skb, &vid);
if (test_bit(vid, pv->untagged_bitmap))
skb = br_vlan_untag(skb);
- else {
- /* Egress policy says "send tagged". If output device
- * is the bridge, we need to add the VLAN header
- * ourselves since we'll be going through the RX path.
- * Sending to ports puts the frame on the TX path and
- * we let dev_hard_start_xmit() add the header.
- */
- if (skb->protocol != htons(ETH_P_8021Q) &&
- pv->port_idx == 0) {
- /* vlan_put_tag expects skb->data to point to
- * mac header.
- */
- skb_push(skb, ETH_HLEN);
- skb = __vlan_put_tag(skb, skb->vlan_proto, skb->vlan_tci);
- if (!skb)
- goto out;
- /* put skb->data back to where it was */
- skb_pull(skb, ETH_HLEN);
- skb->vlan_tci = 0;
- }
- }
out:
return skb;
--
1.8.1.2
^ permalink raw reply related
* Re: r8169 won't transmit with 3.12
From: Craig Small @ 2014-01-22 0:41 UTC (permalink / raw)
To: Francois Romieu; +Cc: Realtek linux nic maintainers, netdev
In-Reply-To: <20140121233630.GA3214@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]
Hi,
Thanks for looking into this.
On Wed, Jan 22, 2014 at 12:36:30AM +0100, Francois Romieu wrote:
> You may check that the onboard nic device does not even work when the
> extra PCI-e card aren't plugged.
It definitely doesn't. I've tried with only the onboard device
and no other NIC device (r8169 or not) installed and its the same
problem.
> A complete dmesg including the XID lines that the r8169 driver prints
> would be welcome.
See attached text file. I'm not sure why I get so many interface up
messages. This is for the two NIC cards. I can pull them out and go back
to the onboard one if you like.
I don't see that transmit queue timeout message that often. It looks
like it might happen once per boot and then giveup.
> Please increase the driver verbosity with the 'msglvl' option of ethtool.
I set it at 65535 but it didn't seem to make much difference.
If I:
* rmmod r8169
* modprobe r8169 debug=1
* ifconfig eth0 ....
* ethtool -s eth0 msglvl 65535
* ping -I eth0 ...
I get the following:
[1256123.142885] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[1256123.142905] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[1256123.143182] r8169 0000:03:00.0: irq 73 for MSI/MSI-X
[1256123.154873] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[1256123.154896] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
[1256123.155148] r8169 0000:06:00.0: irq 74 for MSI/MSI-X
[1256182.169596] r8169 0000:03:00.0 eth0: link down
[1256182.169618] r8169 0000:03:00.0 eth0: link down
[1256185.546908] r8169 0000:03:00.0 eth0: link up
[1256228.041490] r8169 0000:03:00.0 eth0: link up
- Craig
--
Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
[-- Attachment #2: r8169dmesg.txt --]
[-- Type: text/plain, Size: 28914 bytes --]
Jan 7 21:13:52 elmo kernel: [ 0.924084] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:13:52 elmo kernel: [ 0.924100] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:13:52 elmo kernel: [ 0.924315] r8169 0000:03:00.0: irq 72 for MSI/MSI-X
Jan 7 21:13:52 elmo kernel: [ 0.924474] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001820000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 72
Jan 7 21:13:52 elmo kernel: [ 0.924477] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:13:52 elmo kernel: [ 0.925663] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:13:52 elmo kernel: [ 0.925678] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:13:52 elmo kernel: [ 0.925983] r8169 0000:06:00.0: irq 74 for MSI/MSI-X
Jan 7 21:13:52 elmo kernel: [ 0.926424] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc90001870000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 74
Jan 7 21:13:52 elmo kernel: [ 0.926427] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:13:54 elmo kernel: [ 22.478851] r8169 0000:03:00.0 eth2: link down
Jan 7 21:13:54 elmo kernel: [ 22.498863] r8169 0000:06:00.0 eth3: link down
Jan 7 21:21:57 elmo kernel: [ 0.921374] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:21:57 elmo kernel: [ 0.921385] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:21:57 elmo kernel: [ 0.921559] r8169 0000:03:00.0: irq 73 for MSI/MSI-X
Jan 7 21:21:57 elmo kernel: [ 0.921724] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001824000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 73
Jan 7 21:21:57 elmo kernel: [ 0.921730] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:21:57 elmo kernel: [ 0.924400] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:21:57 elmo kernel: [ 0.924411] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:21:57 elmo kernel: [ 0.924593] r8169 0000:06:00.0: irq 74 for MSI/MSI-X
Jan 7 21:21:57 elmo kernel: [ 0.924745] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc9000187c000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 74
Jan 7 21:21:57 elmo kernel: [ 0.924747] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:21:57 elmo kernel: [ 20.188523] r8169 0000:06:00.0 eth1: link down
Jan 7 21:21:58 elmo kernel: [ 43.722301] r8169 0000:03:00.0 eth0: link down
Jan 7 21:31:36 elmo kernel: [ 0.920953] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:31:36 elmo kernel: [ 0.920965] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:31:36 elmo kernel: [ 0.921184] r8169 0000:03:00.0: irq 72 for MSI/MSI-X
Jan 7 21:31:36 elmo kernel: [ 0.921329] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001820000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 72
Jan 7 21:31:36 elmo kernel: [ 0.921332] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:31:36 elmo kernel: [ 0.921407] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:31:36 elmo kernel: [ 0.921414] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:31:36 elmo kernel: [ 0.921586] r8169 0000:06:00.0: irq 73 for MSI/MSI-X
Jan 7 21:31:36 elmo kernel: [ 0.921719] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc90001824000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 73
Jan 7 21:31:36 elmo kernel: [ 0.921722] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:31:36 elmo kernel: [ 20.712240] r8169 0000:03:00.0 eth0: link down
Jan 7 21:31:36 elmo kernel: [ 20.712321] r8169 0000:03:00.0 eth0: link down
Jan 7 21:31:36 elmo kernel: [ 23.934160] r8169 0000:03:00.0 eth0: link up
Jan 7 21:31:36 elmo kernel: [ 51.528553] r8169 0000:06:00.0 eth1: link down
Jan 7 21:31:36 elmo kernel: [ 51.528628] r8169 0000:06:00.0 eth1: link down
Jan 7 21:31:36 elmo kernel: [ 53.825413] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out
Jan 7 21:31:36 elmo kernel: [ 53.825416] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipt_REJECT xt_tcpudp xt_LOG xt_mac nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables fuse it87 hwmon_vid loop tda18271 tda10048 joydev hid_generic snd_hda_codec_hdmi usbhid hid evdev kvm_amd kvm crc32_pclmul crc32c_intel ghash_clmulni_intel raid1 aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper md_mod psmouse sp5100_tco pcspkr fam15h_power serio_raw edac_mce_amd edac_core k10temp i2c_piix4 nouveau snd_hda_codec_via mxm_wmi wmi saa7164 video ttm drm_kms_helper tveeprom dvb_core snd_hda_intel v4l2_common drm snd_hda_codec videodev snd_hwdep media snd_pcm i2c_algo_bit snd_page_alloc acpi_cpufreq i2c_core snd_timer snd button processor soundcore thermal_sys ext4 crc16 mbcache jbd2 dm_mod sg sd_mod sr_mod cdrom crc_t10dif crct10dif_common ahci libahci ehci_pci libata ohci_pci ohci_hcd ehci_hcd xhci_hcd scsi_mod r8169 mii usbcore usb_common
Jan 7 21:31:36 elmo kernel: [ 53.857677] r8169 0000:03:00.0 eth0: link up
Jan 7 21:31:36 elmo kernel: [ 54.324015] r8169 0000:06:00.0 eth1: link up
Jan 7 21:31:37 elmo kernel: [ 83.826545] r8169 0000:03:00.0 eth0: link up
Jan 7 21:31:44 elmo kernel: [ 90.822740] r8169 0000:06:00.0 eth1: link up
Jan 7 21:31:49 elmo kernel: [ 95.822969] r8169 0000:03:00.0 eth0: link up
Jan 7 21:32:01 elmo kernel: [ 107.832103] r8169 0000:03:00.0 eth0: link up
Jan 7 21:32:02 elmo kernel: [ 108.807299] r8169 0000:06:00.0 eth1: link up
Jan 7 21:32:13 elmo kernel: [ 119.816649] r8169 0000:03:00.0 eth0: link up
Jan 7 21:32:25 elmo kernel: [ 131.813620] r8169 0000:03:00.0 eth0: link up
Jan 7 21:32:55 elmo kernel: [ 161.774516] r8169 0000:03:00.0 eth0: link up
Jan 7 21:33:13 elmo kernel: [ 179.768739] r8169 0000:03:00.0 eth0: link up
Jan 7 21:33:37 elmo kernel: [ 203.758175] r8169 0000:03:00.0 eth0: link up
Jan 7 21:34:19 elmo kernel: [ 245.709869] r8169 0000:03:00.0 eth0: link up
Jan 7 21:35:01 elmo kernel: [ 287.693507] r8169 0000:03:00.0 eth0: link up
Jan 7 21:35:31 elmo kernel: [ 317.654398] r8169 0000:03:00.0 eth0: link up
Jan 7 21:36:01 elmo kernel: [ 347.647293] r8169 0000:03:00.0 eth0: link up
Jan 7 21:36:37 elmo kernel: [ 383.606973] r8169 0000:03:00.0 eth0: link up
Jan 7 21:37:01 elmo kernel: [ 407.633061] r8169 0000:03:00.0 eth0: link up
Jan 7 21:37:19 elmo kernel: [ 425.571252] r8169 0000:03:00.0 eth0: link up
Jan 7 21:38:47 elmo kernel: [ 513.921118] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:38:47 elmo kernel: [ 513.921136] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:38:47 elmo kernel: [ 513.921421] r8169 0000:03:00.0: irq 72 for MSI/MSI-X
Jan 7 21:38:47 elmo kernel: [ 513.921795] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001820000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 72
Jan 7 21:38:47 elmo kernel: [ 513.921802] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:38:47 elmo kernel: [ 513.927502] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:38:47 elmo kernel: [ 513.927525] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:38:47 elmo kernel: [ 513.927767] r8169 0000:06:00.0: irq 73 for MSI/MSI-X
Jan 7 21:38:47 elmo kernel: [ 513.928204] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc90001824000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 73
Jan 7 21:38:47 elmo kernel: [ 513.928211] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:39:08 elmo kernel: [ 534.217262] r8169 0000:03:00.0 eth0: link down
Jan 7 21:39:08 elmo kernel: [ 534.217274] r8169 0000:03:00.0 eth0: link down
Jan 7 21:39:11 elmo kernel: [ 537.473818] r8169 0000:03:00.0 eth0: link up
Jan 7 21:39:23 elmo kernel: [ 549.508735] r8169 0000:03:00.0 eth0: link up
Jan 7 21:39:35 elmo kernel: [ 561.479471] r8169 0000:03:00.0 eth0: link up
Jan 7 21:39:53 elmo kernel: [ 579.541748] r8169 0000:03:00.0 eth0: link up
Jan 7 21:40:29 elmo kernel: [ 615.580750] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:40:29 elmo kernel: [ 615.580771] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:40:29 elmo kernel: [ 615.581034] r8169 0000:03:00.0: irq 72 for MSI/MSI-X
Jan 7 21:40:29 elmo kernel: [ 615.586376] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:40:29 elmo kernel: [ 615.586395] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:40:29 elmo kernel: [ 615.586632] r8169 0000:06:00.0: irq 73 for MSI/MSI-X
Jan 7 21:45:36 elmo kernel: [ 0.924701] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:45:36 elmo kernel: [ 0.924807] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:45:36 elmo kernel: [ 0.925414] r8169 0000:03:00.0: irq 72 for MSI/MSI-X
Jan 7 21:45:36 elmo kernel: [ 0.925768] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001820000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 72
Jan 7 21:45:36 elmo kernel: [ 0.925771] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:45:36 elmo kernel: [ 0.925797] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 7 21:45:36 elmo kernel: [ 0.925804] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 7 21:45:36 elmo kernel: [ 0.925981] r8169 0000:06:00.0: irq 73 for MSI/MSI-X
Jan 7 21:45:36 elmo kernel: [ 0.926099] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc90001824000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 73
Jan 7 21:45:36 elmo kernel: [ 0.926101] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 7 21:45:36 elmo kernel: [ 21.831549] r8169 0000:03:00.0 eth0: link down
Jan 7 21:45:44 elmo kernel: [ 42.735362] r8169 0000:06:00.0 eth1: link down
Jan 7 21:45:44 elmo kernel: [ 42.735371] r8169 0000:06:00.0 eth1: link down
Jan 7 21:45:47 elmo kernel: [ 45.491721] r8169 0000:06:00.0 eth1: link up
Jan 7 21:47:59 elmo kernel: [ 177.794729] NETDEV WATCHDOG: eth1 (r8169): transmit queue 0 timed out
Jan 7 21:47:59 elmo kernel: [ 177.794732] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 bnep rfcomm bluetooth rfkill vhost_net vhost macvtap macvlan tun ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc xt_multiport ip6table_filter ip6_tables ebtable_nat ebtables parport_pc ppdev lp parport binfmt_misc ipt_REJECT xt_tcpudp xt_LOG xt_mac nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables fuse it87 hwmon_vid loop tda18271 tda10048 joydev hid_generic snd_hda_codec_hdmi usbhid hid evdev raid1 md_mod kvm_amd kvm crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper psmouse pcspkr serio_raw k10temp edac_mce_amd fam15h_power sp5100_tco edac_core nouveau snd_hda_codec_via i2c_piix4 mxm_wmi saa7164 wmi video ttm tveeprom drm_kms_helper dvb_core v4l2_common drm videodev media i2c_algo_bit snd_hda_intel i2c_core snd_hda_codec acpi_cpufreq snd_hwdep processor button snd_pcm snd_page_alloc snd_timer thermal_sys snd soundcore ext4 crc16 mbcache jbd2 dm_mod sg sd_mod sr_mod cdrom crc_t10dif crct10dif_common 8139too ehci_pci ahci ohci_pci ohci_hcd ehci_hcd libahci xhci_hcd r8169 mii usbcore libata usb_common scsi_mod
Jan 7 21:47:59 elmo kernel: [ 177.803038] r8169 0000:06:00.0 eth1: link up
Jan 7 21:55:13 elmo kernel: [ 611.228156] Modules linked in: r8168(O) ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 bnep rfcomm bluetooth rfkill vhost_net vhost macvtap macvlan tun ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc xt_multiport ip6table_filter ip6_tables ebtable_nat ebtables parport_pc ppdev lp parport binfmt_misc ipt_REJECT xt_tcpudp xt_LOG xt_mac nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables x_tables fuse it87 hwmon_vid loop tda18271 tda10048 joydev hid_generic snd_hda_codec_hdmi usbhid hid evdev raid1 md_mod kvm_amd kvm crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper psmouse pcspkr serio_raw k10temp edac_mce_amd fam15h_power sp5100_tco edac_core nouveau snd_hda_codec_via i2c_piix4 mxm_wmi saa7164 wmi video ttm tveeprom drm_kms_helper dvb_core v4l2_common drm videodev media i2c_algo_bit snd_hda_intel i2c_core snd_hda_codec acpi_cpufreq snd_hwdep processor button snd_pcm snd_page_alloc snd_timer thermal_sys snd soundcore ext4 crc16 mbcache jbd2 dm_mod sg sd_mod sr_mod cdrom crc_t10dif crct10dif_common 8139too ehci_pci ahci ohci_pci ohci_hcd ehci_hcd libahci xhci_hcd mii usbcore libata usb_common scsi_mod [last unloaded: r8169]
Jan 9 08:52:26 elmo kernel: [124556.014238] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 9 08:52:26 elmo kernel: [124556.014257] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 08:52:26 elmo kernel: [124556.014508] r8169 0000:03:00.0: irq 73 for MSI/MSI-X
Jan 9 08:52:26 elmo kernel: [124556.014791] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001870000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 73
Jan 9 08:52:26 elmo kernel: [124556.014799] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 08:52:26 elmo kernel: [124556.014984] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 9 08:52:26 elmo kernel: [124556.015001] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 08:52:26 elmo kernel: [124556.015248] r8169 0000:06:00.0: irq 74 for MSI/MSI-X
Jan 9 08:52:26 elmo kernel: [124556.015509] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc9000187e000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 74
Jan 9 08:52:26 elmo kernel: [124556.015515] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 08:52:26 elmo kernel: [124556.056527] r8169 0000:03:00.0 eth0: link down
Jan 9 08:52:27 elmo kernel: [124557.661174] r8169 0000:03:00.0 eth0: link up
Jan 9 08:52:52 elmo kernel: [124582.349643] r8169 0000:03:00.0 eth0: link up
Jan 9 08:53:46 elmo kernel: [124636.305529] r8169 0000:03:00.0 eth0: link up
Jan 9 08:54:36 elmo kernel: [124686.536235] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 9 08:54:36 elmo kernel: [124686.536260] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 08:54:36 elmo kernel: [124686.536512] r8169 0000:03:00.0: irq 73 for MSI/MSI-X
Jan 9 08:54:36 elmo kernel: [124686.536805] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001870000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 73
Jan 9 08:54:36 elmo kernel: [124686.536812] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 08:54:36 elmo kernel: [124686.547745] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Jan 9 08:54:36 elmo kernel: [124686.547769] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 08:54:36 elmo kernel: [124686.548024] r8169 0000:06:00.0: irq 74 for MSI/MSI-X
Jan 9 08:54:36 elmo kernel: [124686.555383] r8169 0000:03:00.0 eth0: link down
Jan 9 08:54:36 elmo kernel: [124686.555396] r8169 0000:03:00.0 eth0: link down
Jan 9 08:54:36 elmo kernel: [124686.555635] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc9000187e000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 74
Jan 9 08:54:36 elmo kernel: [124686.555640] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 08:54:40 elmo kernel: [124690.143434] r8169 0000:03:00.0 eth0: link up
Jan 9 08:55:40 elmo kernel: [124750.245190] r8169 0000:03:00.0 eth0: link up
Jan 9 08:56:28 elmo kernel: [124798.267925] r8169 0000:03:00.0 eth0: link up
Jan 9 08:58:16 elmo kernel: [124906.124315] r8169 0000:03:00.0 eth0: link up
Jan 9 09:00:34 elmo kernel: [125043.447578] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 09:00:34 elmo kernel: [125043.447833] r8169 0000:03:00.0: irq 73 for MSI/MSI-X
Jan 9 09:00:34 elmo kernel: [125043.448156] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001870000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 73
Jan 9 09:00:34 elmo kernel: [125043.448162] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 09:00:34 elmo kernel: [125043.460502] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 09:00:34 elmo kernel: [125043.460705] r8169 0000:06:00.0: irq 74 for MSI/MSI-X
Jan 9 09:00:34 elmo kernel: [125043.467175] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc9000187e000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 74
Jan 9 09:00:34 elmo kernel: [125043.467181] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 09:09:00 elmo kernel: [125549.128197] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 09:09:00 elmo kernel: [125549.128457] r8169 0000:03:00.0: irq 73 for MSI/MSI-X
Jan 9 09:09:00 elmo kernel: [125549.128748] r8169 0000:03:00.0 eth0: RTL8168c/8111c at 0xffffc90001870000, 00:e0:4c:80:66:57, XID 1c4000c0 IRQ 73
Jan 9 09:09:00 elmo kernel: [125549.128755] r8169 0000:03:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 09:09:00 elmo kernel: [125549.145664] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
Jan 9 09:09:00 elmo kernel: [125549.145934] r8169 0000:06:00.0: irq 74 for MSI/MSI-X
Jan 9 09:09:00 elmo kernel: [125549.146934] r8169 0000:03:00.0 eth0: link down
Jan 9 09:09:00 elmo kernel: [125549.147189] r8169 0000:06:00.0 eth1: RTL8168c/8111c at 0xffffc9000187e000, 00:e0:4c:80:70:08, XID 1c4000c0 IRQ 74
Jan 9 09:09:00 elmo kernel: [125549.147193] r8169 0000:06:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko]
Jan 9 09:09:00 elmo kernel: [125549.147234] r8169 0000:03:00.0 eth0: link down
Jan 9 09:09:03 elmo kernel: [125552.943570] r8169 0000:03:00.0 eth0: link up
Jan 9 09:09:28 elmo kernel: [125577.579875] r8169 0000:03:00.0 eth0: link up
Jan 9 09:10:34 elmo kernel: [125643.518729] r8169 0000:03:00.0 eth0: link up
Jan 9 09:11:04 elmo kernel: [125673.505548] r8169 0000:03:00.0 eth0: link up
Jan 9 09:11:52 elmo kernel: [125721.462613] r8169 0000:03:00.0 eth0: link up
Jan 9 09:12:22 elmo kernel: [125751.445129] r8169 0000:03:00.0 eth0: link up
Jan 9 09:13:31 elmo kernel: [125820.588517] r8169 0000:03:00.0 eth0: link down
Jan 9 09:13:31 elmo kernel: [125820.588524] r8169 0000:03:00.0 eth0: link down
Jan 9 09:13:34 elmo kernel: [125823.765570] r8169 0000:03:00.0 eth0: link up
Jan 9 09:13:59 elmo kernel: [125848.409967] r8169 0000:03:00.0 eth0: link up
Jan 9 10:56:59 elmo kernel: [132023.485940] r8169 0000:03:00.0 eth0: link down
Jan 9 11:02:14 elmo kernel: [132338.259437] r8169 0000:03:00.0 eth0: link up
Jan 9 11:02:15 elmo kernel: [132338.888600] r8169 0000:03:00.0 eth0: link down
Jan 9 11:02:17 elmo kernel: [132340.899557] r8169 0000:03:00.0 eth0: link up
Jan 9 12:21:59 elmo kernel: [137119.706747] r8169 0000:03:00.0 eth0: link up
Jan 9 13:46:58 elmo kernel: [142215.007812] r8169 0000:03:00.0 eth0: link down
Jan 9 13:51:11 elmo kernel: [142467.021851] r8169 0000:03:00.0 eth0: link up
Jan 9 13:51:12 elmo kernel: [142468.036445] r8169 0000:03:00.0 eth0: link down
Jan 9 13:51:13 elmo kernel: [142469.683089] r8169 0000:03:00.0 eth0: link up
Jan 9 14:22:01 elmo kernel: [144316.058860] r8169 0000:03:00.0 eth0: link up
Jan 10 00:15:01 elmo kernel: [179868.506724] r8169 0000:03:00.0 eth0: link up
Jan 10 01:34:07 elmo kernel: [184610.809173] r8169 0000:03:00.0 eth0: link up
Jan 10 06:27:19 elmo kernel: [202189.245589] r8169 0000:03:00.0 eth0: link up
Jan 10 10:25:17 elmo kernel: [216458.170910] r8169 0000:03:00.0 eth0: link up
Jan 10 10:50:23 elmo kernel: [217963.001075] r8169 0000:03:00.0 eth0: link up
Jan 10 11:04:29 elmo kernel: [218808.352269] r8169 0000:03:00.0 eth0: link up
Jan 10 11:27:35 elmo kernel: [220193.304666] r8169 0000:03:00.0 eth0: link up
Jan 10 11:50:23 elmo kernel: [221560.241410] r8169 0000:03:00.0 eth0: link up
Jan 10 12:05:59 elmo kernel: [222495.539781] r8169 0000:03:00.0 eth0: link up
Jan 10 12:29:41 elmo kernel: [223916.436973] r8169 0000:03:00.0 eth0: link up
Jan 10 12:51:23 elmo kernel: [225217.437479] r8169 0000:03:00.0 eth0: link up
Jan 10 13:04:53 elmo kernel: [226026.817632] r8169 0000:03:00.0 eth0: link up
Jan 10 13:28:47 elmo kernel: [227459.718466] r8169 0000:03:00.0 eth0: link up
Jan 10 13:51:35 elmo kernel: [228826.681757] r8169 0000:03:00.0 eth0: link up
Jan 10 14:03:41 elmo kernel: [229552.123700] r8169 0000:03:00.0 eth0: link up
Jan 10 14:26:23 elmo kernel: [230913.072252] r8169 0000:03:00.0 eth0: link up
Jan 10 14:47:11 elmo kernel: [232160.105546] r8169 0000:03:00.0 eth0: link up
Jan 10 15:12:11 elmo kernel: [233658.974021] r8169 0000:03:00.0 eth0: link up
Jan 10 15:29:29 elmo kernel: [234696.177510] r8169 0000:03:00.0 eth0: link up
Jan 10 15:50:23 elmo kernel: [235949.197834] r8169 0000:03:00.0 eth0: link up
Jan 10 16:13:17 elmo kernel: [237322.147870] r8169 0000:03:00.0 eth0: link up
Jan 10 16:34:17 elmo kernel: [238581.179914] r8169 0000:03:00.0 eth0: link up
Jan 10 16:59:23 elmo kernel: [240086.040262] r8169 0000:03:00.0 eth0: link up
Jan 10 17:14:59 elmo kernel: [241021.338493] r8169 0000:03:00.0 eth0: link up
Jan 10 17:36:29 elmo kernel: [242310.318221] r8169 0000:03:00.0 eth0: link up
Jan 10 18:00:29 elmo kernel: [243749.209619] r8169 0000:03:00.0 eth0: link up
Jan 10 18:24:17 elmo kernel: [245176.117274] r8169 0000:03:00.0 eth0: link up
Jan 10 18:47:11 elmo kernel: [246549.108048] r8169 0000:03:00.0 eth0: link up
Jan 10 19:02:35 elmo kernel: [247472.355174] r8169 0000:03:00.0 eth0: link up
Jan 10 19:26:47 elmo kernel: [248923.303384] r8169 0000:03:00.0 eth0: link up
Jan 10 19:50:47 elmo kernel: [250362.144802] r8169 0000:03:00.0 eth0: link up
Jan 10 20:13:29 elmo kernel: [251723.101783] r8169 0000:03:00.0 eth0: link up
Jan 10 20:35:29 elmo kernel: [253042.081251] r8169 0000:03:00.0 eth0: link up
Jan 10 20:59:29 elmo kernel: [254480.981747] r8169 0000:03:00.0 eth0: link up
Jan 10 21:22:17 elmo kernel: [255847.927367] r8169 0000:03:00.0 eth0: link up
Jan 10 21:46:11 elmo kernel: [257280.835154] r8169 0000:03:00.0 eth0: link up
Jan 10 22:10:35 elmo kernel: [258743.709869] r8169 0000:03:00.0 eth0: link up
Jan 10 22:25:23 elmo kernel: [259631.016371] r8169 0000:03:00.0 eth0: link up
Jan 10 22:49:47 elmo kernel: [261093.912822] r8169 0000:03:00.0 eth0: link up
Jan 10 23:14:29 elmo kernel: [262574.775599] r8169 0000:03:00.0 eth0: link up
Jan 10 23:41:05 elmo kernel: [264169.532821] r8169 0000:03:00.0 eth0: link up
Jan 11 00:20:29 elmo kernel: [266531.713878] r8169 0000:03:00.0 eth0: link up
Jan 11 01:08:29 elmo kernel: [269409.500032] r8169 0000:03:00.0 eth0: link up
Jan 11 01:22:35 elmo kernel: [270254.861202] r8169 0000:03:00.0 eth0: link up
Jan 11 01:45:53 elmo kernel: [271651.779561] r8169 0000:03:00.0 eth0: link up
Jan 11 02:09:29 elmo kernel: [273066.706131] r8169 0000:03:00.0 eth0: link up
Jan 11 02:25:11 elmo kernel: [274008.016185] r8169 0000:03:00.0 eth0: link up
Jan 11 02:48:53 elmo kernel: [275428.884591] r8169 0000:03:00.0 eth0: link up
Jan 11 03:14:05 elmo kernel: [276939.735485] r8169 0000:03:00.0 eth0: link up
Jan 11 03:55:29 elmo kernel: [279421.824429] r8169 0000:03:00.0 eth0: link up
Jan 11 04:42:29 elmo kernel: [282239.665715] r8169 0000:03:00.0 eth0: link up
Jan 11 05:26:05 elmo kernel: [284853.658781] r8169 0000:03:00.0 eth0: link up
Jan 11 06:14:05 elmo kernel: [287731.454199] r8169 0000:03:00.0 eth0: link up
Jan 11 06:25:11 elmo kernel: [288396.950192] r8169 0000:03:00.0 eth0: link up
Jan 11 06:41:23 elmo kernel: [289368.205492] r8169 0000:03:00.0 eth0: link up
Jan 11 07:05:29 elmo kernel: [290813.090764] r8169 0000:03:00.0 eth0: link up
Jan 11 07:28:11 elmo kernel: [292174.044720] r8169 0000:03:00.0 eth0: link up
Jan 11 07:52:23 elmo kernel: [293624.947008] r8169 0000:03:00.0 eth0: link up
Jan 11 08:16:17 elmo kernel: [295057.821023] r8169 0000:03:00.0 eth0: link up
Jan 11 08:30:35 elmo kernel: [295915.174546] r8169 0000:03:00.0 eth0: link up
Jan 11 08:56:41 elmo kernel: [297479.953856] r8169 0000:03:00.0 eth0: link up
Jan 11 09:20:41 elmo kernel: [298918.875097] r8169 0000:03:00.0 eth0: link up
Jan 11 09:42:29 elmo kernel: [300225.856036] r8169 0000:03:00.0 eth0: link up
Jan 11 10:05:17 elmo kernel: [301592.816385] r8169 0000:03:00.0 eth0: link up
Jan 11 10:22:47 elmo kernel: [302642.021483] r8169 0000:03:00.0 eth0: link up
Jan 11 10:46:41 elmo kernel: [304074.915787] r8169 0000:03:00.0 eth0: link up
Jan 11 11:12:47 elmo kernel: [305639.727570] r8169 0000:03:00.0 eth0: link up
Jan 11 11:43:17 elmo kernel: [307468.308263] r8169 0000:03:00.0 eth0: link up
Jan 11 11:56:53 elmo kernel: [308283.696450] r8169 0000:03:00.0 eth0: link up
Jan 11 12:19:47 elmo kernel: [309656.641788] r8169 0000:03:00.0 eth0: link up
Jan 11 12:43:05 elmo kernel: [311053.560314] r8169 0000:03:00.0 eth0: link up
Jan 11 13:07:47 elmo kernel: [312534.418463] r8169 0000:03:00.0 eth0: link up
Jan 11 13:30:41 elmo kernel: [313907.365171] r8169 0000:03:00.0 eth0: link up
Jan 11 13:54:17 elmo kernel: [315322.276762] r8169 0000:03:00.0 eth0: link up
Jan 11 14:18:47 elmo kernel: [316791.163514] r8169 0000:03:00.0 eth0: link up
Jan 11 14:42:29 elmo kernel: [318212.066921] r8169 0000:03:00.0 eth0: link up
Jan 11 15:07:47 elmo kernel: [319728.890740] r8169 0000:03:00.0 eth0: link up
Jan 11 15:22:47 elmo kernel: [320628.199976] r8169 0000:03:00.0 eth0: link up
Jan 11 15:46:41 elmo kernel: [322061.101203] r8169 0000:03:00.0 eth0: link up
Jan 11 16:09:59 elmo kernel: [323458.047578] r8169 0000:03:00.0 eth0: link up
Jan 11 16:32:29 elmo kernel: [324807.000015] r8169 0000:03:00.0 eth0: link up
Jan 11 16:56:17 elmo kernel: [326233.897558] r8169 0000:03:00.0 eth0: link up
Jan 11 17:19:23 elmo kernel: [327618.832116] r8169 0000:03:00.0 eth0: link up
Jan 11 17:42:17 elmo kernel: [328991.781805] r8169 0000:03:00.0 eth0: link up
Jan 11 17:58:29 elmo kernel: [329963.040468] r8169 0000:03:00.0 eth0: link up
Jan 11 18:19:29 elmo kernel: [331222.061017] r8169 0000:03:00.0 eth0: link up
Jan 11 18:43:17 elmo kernel: [332648.954572] r8169 0000:03:00.0 eth0: link up
Jan 11 19:12:53 elmo kernel: [334423.600928] r8169 0000:03:00.0 eth0: link up
Jan 11 19:54:23 elmo kernel: [336911.694736] r8169 0000:03:00.0 eth0: link up
Jan 11 20:08:29 elmo kernel: [337757.063044] r8169 0000:03:00.0 eth0: link up
Jan 11 20:32:17 elmo kernel: [339183.947065] r8169 0000:03:00.0 eth0: link up
Jan 11 20:56:41 elmo kernel: [340646.830012] r8169 0000:03:00.0 eth0: link up
Jan 11 21:12:35 elmo kernel: [341600.106319] r8169 0000:03:00.0 eth0: link up
Jan 11 21:34:59 elmo kernel: [342943.072953] r8169 0000:03:00.0 eth0: link up
Jan 11 21:58:23 elmo kernel: [344346.010377] r8169 0000:03:00.0 eth0: link up
Jan 11 22:27:29 elmo kernel: [346090.650653] r8169 0000:03:00.0 eth0: link up
Jan 11 22:39:29 elmo kernel: [346810.097681] r8169 0000:03:00.0 eth0: link up
Jan 11 23:03:05 elmo kernel: [348225.015098] r8169 0000:03:00.0 eth0: link up
Jan 11 23:26:29 elmo kernel: [349627.946117] r8169 0000:03:00.0 eth0: link up
Jan 11 23:41:41 elmo kernel: [350539.240694] r8169 0000:03:00.0 eth0: link up
Jan 12 00:05:41 elmo kernel: [351978.133377] r8169 0000:03:00.0 eth0: link up
Jan 12 00:28:05 elmo kernel: [353321.087554] r8169 0000:03:00.0 eth0: link up
Jan 12 01:12:17 elmo kernel: [355971.080348] r8169 0000:03:00.0 eth0: link up
Jan 12 01:58:17 elmo kernel: [358728.956382] r8169 0000:03:00.0 eth0: link up
Jan 12 02:44:11 elmo kernel: [361480.834141] r8169 0000:03:00.0 eth0: link up
Jan 12 03:33:35 elmo kernel: [364442.572951] r8169 0000:03:00.0 eth0: link up
Jan 12 03:44:29 elmo kernel: [365096.063835] r8169 0000:03:00.0 eth0: link up
Jan 12 04:10:41 elmo kernel: [366666.862665] r8169 0000:03:00.0 eth0: link up
Jan 12 04:35:17 elmo kernel: [368141.719614] r8169 0000:03:00.0 eth0: link up
Jan 12 04:50:59 elmo kernel: [369083.003813] r8169 0000:03:00.0 eth0: link up
Jan 12 05:14:53 elmo kernel: [370515.900323] r8169 0000:03:00.0 eth0: link up
Jan 12 05:37:53 elmo kernel: [371894.857820] r8169 0000:03:00.0 eth0: link up
Jan 12 05:53:05 elmo kernel: [372806.157333] r8169 0000:03:00.0 eth0: link up
Jan 12 06:15:59 elmo kernel: [374179.086690] r8169 0000:03:00.0 eth0: link up
^ permalink raw reply
* Re: [PATCH net-next v2] net: remove unnecessary initializations in net_dev_init
From: David Miller @ 2014-01-22 0:45 UTC (permalink / raw)
To: sd; +Cc: netdev
In-Reply-To: <1390069167-14080-1-git-send-email-sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Sat, 18 Jan 2014 19:19:27 +0100
> softnet_data is already set to 0, no need to use memset or initialize
> specific fields to 0 or NULL afterwards.
>
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied, thanks.
^ 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