* Re: [patch net-next RFC 4/6] Introduce sample tc action
From: Roopa Prabhu @ 2016-10-18 5:07 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Jiri Pirko, netdev, davem, yotamg, idosch, eladr, nogahf,
ogerlitz, geert+renesas, stephen, xiyou.wangcong, linux,
Shrijeet Mukherjee, Peter Phaal
In-Reply-To: <58056A08.5070809@cumulusnetworks.com>
On 10/17/16, 5:17 PM, Roopa Prabhu wrote:
> On 10/17/16, 3:10 AM, Jamal Hadi Salim wrote:
[snip]
inline below more data/context..
>>>> +
>>>> +struct sample_packet_metadata {
>>>> + int sample_size;
>>>> + int orig_size;
>>>> + int ifindex;
>>>> +};
>>>> +
>>> This metadata does not look extensible.. can it be made to ?
>>>
>> Sure it can...
more sflow context here... [1]
An extensible metadata scheme is highly desirable when passing data from the dataplane to
the sampling agent in userspace. Looking forward, advanced instrumentation is being
added to data planes and keeping the api future proof will help.
>>
>>> With sflow in context, you need a pair of ifindex numbers to encode ingress and egress ports.
>> What is the use case for both?
> I have heard that most monitoring tools have moved to ingress only sampling because of operational
> complexity (use case is sflow). I think hardware also supports ingress and egress only sampling.
> better to have an option to reflect that in the api.
The reason for having two ifindex numbers is to record the ingress and egress ports (i.e. the path that the packet takes through the datapath/ASIC). You may actually have three ifindex numbers associated with a sample:
1. The data source that made the measurement (on a linux system each bridge has its own ifindex)
2. The ifindex associated with the ingress switch port
3. The ifindex associated with the egress switch port.
All three apply irrespective of sampling direction.
thanks,
Roopa
[1] Additional extended flow attributes have been defined to further extend sFlow packet samples:
http://sflow.org/sflow_tunnels.txt <http://sflow.org/sflow_tunnels.txt>
http://sflow.org/sflow_openflow.txt <http://sflow.org/sflow_openflow.txt>
^ permalink raw reply
* Re: [PATCH 00/28] Reenable maybe-uninitialized warnings
From: Christoph Hellwig @ 2016-10-18 5:08 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Torvalds, linux-kernel, x86, linux-media,
Mauro Carvalho Chehab, Martin Schwidefsky, linux-s390,
Ilya Dryomov, dri-devel, linux-mtd, Herbert Xu, linux-crypto,
David S. Miller, netdev, Greg Kroah-Hartman, ceph-devel,
linux-f2fs-devel, linux-ext4, netfilter-devel
In-Reply-To: <20161017220342.1627073-1-arnd@arndb.de>
On Tue, Oct 18, 2016 at 12:03:28AM +0200, Arnd Bergmann wrote:
> This is a set of patches that I hope to get into v4.9 in some form
> in order to turn on the -Wmaybe-uninitialized warnings again.
Hi Arnd,
I jsut complained to Geert that I was introducing way to many
bugs or pointless warnings for some compilers lately, but gcc didn't
warn me about them. From a little research the lack of
-Wmaybe-uninitialized seems to be the reason for it, so I'm all
for re-enabling it.
^ permalink raw reply
* [PATCH net v2] bnx2: fix locking when netconsole is used
From: Ivan Vecera @ 2016-10-18 6:16 UTC (permalink / raw)
To: netdev; +Cc: Sony Chacko, Dept-HSGLinuxNICDev
Functions bnx2_reg_rd_ind(), bnx2_reg_wr_ind() and bnx2_ctx_wr()
can be called with IRQs disabled when netconsole is enabled. So they
should use spin_{,un}lock_irq{save,restore} instead of _bh variants.
Example call flow:
bnx2_poll()
->bnx2_poll_link()
->bnx2_phy_int()
->bnx2_set_remote_link()
->bnx2_shmem_rd()
->bnx2_reg_rd_ind()
-> spin_lock_bh(&bp->indirect_lock);
spin_unlock_bh(&bp->indirect_lock);
...
-> __local_bh_enable_ip
static inline void __local_bh_enable_ip(unsigned long ip)
WARN_ON_ONCE(in_irq() || irqs_disabled()); <<<<<< WARN
Cc: Sony Chacko <sony.chacko@qlogic.com>
Cc: Dept-HSGLinuxNICDev@qlogic.com
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 27f11a5..b3791b3 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -271,22 +271,25 @@ static inline u32 bnx2_tx_avail(struct bnx2 *bp, struct bnx2_tx_ring_info *txr)
static u32
bnx2_reg_rd_ind(struct bnx2 *bp, u32 offset)
{
+ unsigned long flags;
u32 val;
- spin_lock_bh(&bp->indirect_lock);
+ spin_lock_irqsave(&bp->indirect_lock, flags);
BNX2_WR(bp, BNX2_PCICFG_REG_WINDOW_ADDRESS, offset);
val = BNX2_RD(bp, BNX2_PCICFG_REG_WINDOW);
- spin_unlock_bh(&bp->indirect_lock);
+ spin_unlock_irqrestore(&bp->indirect_lock, flags);
return val;
}
static void
bnx2_reg_wr_ind(struct bnx2 *bp, u32 offset, u32 val)
{
- spin_lock_bh(&bp->indirect_lock);
+ unsigned long flags;
+
+ spin_lock_irqsave(&bp->indirect_lock, flags);
BNX2_WR(bp, BNX2_PCICFG_REG_WINDOW_ADDRESS, offset);
BNX2_WR(bp, BNX2_PCICFG_REG_WINDOW, val);
- spin_unlock_bh(&bp->indirect_lock);
+ spin_unlock_irqrestore(&bp->indirect_lock, flags);
}
static void
@@ -304,8 +307,10 @@ bnx2_shmem_rd(struct bnx2 *bp, u32 offset)
static void
bnx2_ctx_wr(struct bnx2 *bp, u32 cid_addr, u32 offset, u32 val)
{
+ unsigned long flags;
+
offset += cid_addr;
- spin_lock_bh(&bp->indirect_lock);
+ spin_lock_irqsave(&bp->indirect_lock, flags);
if (BNX2_CHIP(bp) == BNX2_CHIP_5709) {
int i;
@@ -322,7 +327,7 @@ bnx2_ctx_wr(struct bnx2 *bp, u32 cid_addr, u32 offset, u32 val)
BNX2_WR(bp, BNX2_CTX_DATA_ADR, offset);
BNX2_WR(bp, BNX2_CTX_DATA, val);
}
- spin_unlock_bh(&bp->indirect_lock);
+ spin_unlock_irqrestore(&bp->indirect_lock, flags);
}
#ifdef BCM_CNIC
--
2.7.3
^ permalink raw reply related
* Re: [PATCH net] bnx2: fix locking when netconsole is used
From: Ivan Vecera @ 2016-10-18 6:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sony.chacko, Dept-HSGLinuxNICDev
In-Reply-To: <20161017.132142.526817621160813690.davem@davemloft.net>
Dne 17.10.2016 v 19:21 David Miller napsal(a):
> From: Ivan Vecera <ivecera@redhat.com>
> Date: Mon, 17 Oct 2016 18:20:31 +0200
>
>> diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
>> index 27f11a5..9c408413 100644
>> --- a/drivers/net/ethernet/broadcom/bnx2.c
>> +++ b/drivers/net/ethernet/broadcom/bnx2.c
>> @@ -272,21 +272,24 @@ static u32
>> bnx2_reg_rd_ind(struct bnx2 *bp, u32 offset)
>> {
>> u32 val;
>> + unsigned long flags;
>>
>
> Please order local variable declarations from longest to shortest
> line.
Sure Dave, done.
Ivan
^ permalink raw reply
* [PATCH] vlan: Remove unnecessary comparison of unsigned against 0
From: Tobias Klauser @ 2016-10-18 6:44 UTC (permalink / raw)
To: Patrick McHardy, David S. Miller; +Cc: netdev
args.u.name_type is of type unsigned int and is always >= 0.
This fixes the following GCC warning:
net/8021q/vlan.c: In function ‘vlan_ioctl_handler’:
net/8021q/vlan.c:574:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/8021q/vlan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 8de138d3306b..f8903c1e1010 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -571,8 +571,7 @@ static int vlan_ioctl_handler(struct net *net, void __user *arg)
err = -EPERM;
if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
break;
- if ((args.u.name_type >= 0) &&
- (args.u.name_type < VLAN_NAME_TYPE_HIGHEST)) {
+ if (args.u.name_type < VLAN_NAME_TYPE_HIGHEST) {
struct vlan_net *vn;
vn = net_generic(net, vlan_net_id);
--
2.9.0
^ permalink raw reply related
* Re: Funding Approved In Minutes!
From: ottow @ 2016-10-18 6:33 UTC (permalink / raw)
To: Recipients
Good Day,
Financing shouldn't be a mystery for you, contact us for help today. Easy Funding Service is here to help you solve out all your outstanding debts and be free for good..We have come to conclusion that its high time a person can buy his own house, good cars, established good business, and also pay his/her accounts off... All this can be done by cash and this finance company will offer you any leaser and Lump amount from R1,000.00 to R2,000,000.00. Email us today and you will be attended to immediately...
Regards,
Lionel Griffin
^ permalink raw reply
* pull-request: mac80211 2016-10-18
From: Johannes Berg @ 2016-10-18 7:00 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
As I mention in the tag message, the most urgent fix here is for
the VMAP_STACK vs. software crypto usage. I ended up applying Ard's
fix that dynamically allocates everything in one go, perhaps we'll
find a better solution in the future, but in the meantime this will
get things working again (rather than crashing or getting BUG_ON),
and normally it's a rarely used code path since hardware crypto is
used for almost all devices.
Please pull, or let me know if there's any problem.
Thanks,
johannes
The following changes since commit 6b25e21fa6f26d0f0d45f161d169029411c84286:
Merge tag 'drm-for-v4.9' of git://people.freedesktop.org/~airlied/linux (2016-10-11 18:12:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-10-18
for you to fetch changes up to f4a067f9ffca603b45f7e82ddd2ba50e5904cea3:
mac80211: move struct aead_req off the stack (2016-10-17 16:14:04 +0200)
----------------------------------------------------------------
This is relatively small, mostly to get the SG/crypto
from stack removal fix that crashes things when VMAP
stack is used in conjunction with software crypto.
Aside from that, we have:
* a fix for AP_VLAN usage with the nl80211 frame command
* two fixes (and two preparation patches) for A-MSDU, one
to discard group-addressed (multicast) and unexpected
4-address A-MSDUs, the other to validate A-MSDU inner
MAC addresses properly to prevent controlled port bypass
----------------------------------------------------------------
Ard Biesheuvel (1):
mac80211: move struct aead_req off the stack
Johannes Berg (4):
mac80211: discard multicast and 4-addr A-MSDUs
cfg80211: let ieee80211_amsdu_to_8023s() take only header-less SKB
cfg80211: add ability to check DA/SA in A-MSDU decapsulation
mac80211: validate DA/SA during A-MSDU decapsulation
Michael Braun (1):
mac80211: fix CMD_FRAME for AP_VLAN
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 2 +-
include/net/cfg80211.h | 32 ++++++++++----
net/mac80211/aes_ccm.c | 46 ++++++++++++-------
net/mac80211/aes_ccm.h | 8 ++--
net/mac80211/aes_gcm.c | 43 +++++++++++-------
net/mac80211/aes_gcm.h | 6 ++-
net/mac80211/aes_gmac.c | 26 +++++------
net/mac80211/aes_gmac.h | 4 ++
net/mac80211/offchannel.c | 2 +-
net/mac80211/rx.c | 51 +++++++++++++++++-----
net/mac80211/wpa.c | 22 ++++------
net/wireless/util.c | 34 +++++++--------
12 files changed, 175 insertions(+), 101 deletions(-)
^ permalink raw reply
* [PATCH] net/hsr: Remove unused but set variable
From: Tobias Klauser @ 2016-10-18 7:07 UTC (permalink / raw)
To: Arvid Brodin, David S. Miller; +Cc: netdev
Remove the unused but set variable master_dev in check_local_dest to fix
the following GCC warning when building with 'W=1':
net/hsr/hsr_forward.c: In function ‘check_local_dest’:
net/hsr/hsr_forward.c:303:21: warning: variable ‘master_dev’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/hsr/hsr_forward.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
index 5ee1d43f1310..4ebe2aa3e7d3 100644
--- a/net/hsr/hsr_forward.c
+++ b/net/hsr/hsr_forward.c
@@ -300,10 +300,6 @@ static void hsr_forward_do(struct hsr_frame_info *frame)
static void check_local_dest(struct hsr_priv *hsr, struct sk_buff *skb,
struct hsr_frame_info *frame)
{
- struct net_device *master_dev;
-
- master_dev = hsr_port_get_hsr(hsr, HSR_PT_MASTER)->dev;
-
if (hsr_addr_is_self(hsr, eth_hdr(skb)->h_dest)) {
frame->is_local_exclusive = true;
skb->pkt_type = PACKET_HOST;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH v5 4/4] net: phy: leds: add support for led triggers on phy link state change
From: Andrew Lunn @ 2016-10-18 7:13 UTC (permalink / raw)
To: Zach Brown
Cc: devel, florian.c.schilhabel, f.fainelli, netdev, linux-kernel,
rpurdie, gregkh, Larry.Finger, j.anaszewski, linux-leds, mlindner
In-Reply-To: <1476719395-28273-5-git-send-email-zach.brown@ni.com>
On Mon, Oct 17, 2016 at 10:49:55AM -0500, Zach Brown wrote:
> Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a
> set of led triggers for each instantiated PHY device. There is one LED
> trigger per link-speed, per-phy.
> The triggers are registered during phy_attach and unregistered during
> phy_detach.
>
> This allows for a user to configure their system to allow a set of LEDs
> not controlled by the phy to represent link state changes on the phy.
> LEDS controlled by the phy are unaffected.
>
> For example, we have a board where some of the leds in the
> RJ45 socket are controlled by the phy, but others are not. Using the
> triggers provided by this patch the leds not controlled by the phy can
> be configured to show the current speed of the ethernet connection. The
> leds controlled by the phy are unaffected.
Is there a clear path how we generalise this, so it could also be used
to control PHY LEDs?
The idea i had a while ago was that the PHY LEDS would also have a
list of triggers which mapped to what the PHY controller could do. So
to enable the PHY LED to show RxTx activity, you would enable the RxTx
trigger on the PHY LED.
This needs an extension to the PHY code, in that these triggers are
specific to the LED, not general across all LEDs. But this is not too
big an issue.
We could end up that if a PHY LED can be used as a generic LED, your
'manual' trigger could be used on it. But it could also support the
PHY driven 'automatic' link status indication trigger. Do we want two
triggers for the same or similar information?
Andrew
^ permalink raw reply
* [PATCH v2 1/2] dwc_eth_qos: do not clear pause flags from phy_device->supported
From: Niklas Cassel @ 2016-10-18 7:20 UTC (permalink / raw)
To: larper, netdev; +Cc: linux-kernel, Niklas Cassel, Jesper Nilsson
From: Niklas Cassel <niklas.cassel@axis.com>
phy_device->supported is originally set by the PHY driver.
The ethernet driver should filter phy_device->supported to only contain
flags supported by the IP.
The IP supports setting rx and tx flow control independently,
therefore SUPPORTED_Pause and SUPPORTED_Asym_Pause should not be cleared.
If the flags are cleared, pause frames cannot be enabled (even if they
are supported by the PHY).
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Jesper Nilsson <jespern@axis.com>
Acked-by: Lars Persson <larper@axis.com>
---
drivers/net/ethernet/synopsys/dwc_eth_qos.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
index 0d0053128542..d775729648ef 100644
--- a/drivers/net/ethernet/synopsys/dwc_eth_qos.c
+++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
@@ -982,7 +982,8 @@ static int dwceqos_mii_probe(struct net_device *ndev)
if (netif_msg_probe(lp))
phy_attached_info(phydev);
- phydev->supported &= PHY_GBIT_FEATURES;
+ phydev->supported &= PHY_GBIT_FEATURES | SUPPORTED_Pause |
+ SUPPORTED_Asym_Pause;
lp->link = 0;
lp->speed = 0;
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/2] dwc_eth_qos: enable flow control by default
From: Niklas Cassel @ 2016-10-18 7:20 UTC (permalink / raw)
To: larper, netdev; +Cc: linux-kernel, Niklas Cassel, Jesper Nilsson
From: Niklas Cassel <niklas.cassel@axis.com>
Allow autoneg to enable flow control by default.
The behavior when autoneg is off has not changed.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Jesper Nilsson <jespern@axis.com>
Acked-by: Lars Persson <larper@axis.com>
---
drivers/net/ethernet/synopsys/dwc_eth_qos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/synopsys/dwc_eth_qos.c b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
index d775729648ef..5eedac495077 100644
--- a/drivers/net/ethernet/synopsys/dwc_eth_qos.c
+++ b/drivers/net/ethernet/synopsys/dwc_eth_qos.c
@@ -988,6 +988,7 @@ static int dwceqos_mii_probe(struct net_device *ndev)
lp->link = 0;
lp->speed = 0;
lp->duplex = DUPLEX_UNKNOWN;
+ lp->flowcontrol.autoneg = AUTONEG_ENABLE;
return 0;
}
--
2.1.4
^ permalink raw reply related
* [PATCH] ipv4: Remove unused but set variable
From: Tobias Klauser @ 2016-10-18 7:40 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Remove the unused but set variable dev in ip_do_fragment to fix the
following GCC warning when building with 'W=1':
net/ipv4/ip_output.c: In function ‘ip_do_fragment’:
net/ipv4/ip_output.c:541:21: warning: variable ‘dev’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/ipv4/ip_output.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 05d105832bdb..03e7f7310423 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -538,7 +538,6 @@ int ip_do_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
{
struct iphdr *iph;
int ptr;
- struct net_device *dev;
struct sk_buff *skb2;
unsigned int mtu, hlen, left, len, ll_rs;
int offset;
@@ -546,8 +545,6 @@ int ip_do_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
struct rtable *rt = skb_rtable(skb);
int err = 0;
- dev = rt->dst.dev;
-
/* for offloaded checksums cleanup checksum before fragmentation */
if (skb->ip_summed == CHECKSUM_PARTIAL &&
(err = skb_checksum_help(skb)))
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 18/19] stmmac: dwmac-sti: Remove obsolete STi platforms
From: Patrice Chotard @ 2016-10-18 8:05 UTC (permalink / raw)
To: Rob Herring, Peter Griffin
Cc: linux-arm-kernel, linux-kernel, kernel, devicetree, lee.jones,
peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <20160923151142.GG9176@rob-hp-laptop>
On 09/23/2016 05:11 PM, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 02:27:56PM +0100, Peter Griffin wrote:
>> This patch removes support for STiH415/6 SoC's from the
>> dwmac-sti driver and dt binding doc, as support for these
>> platforms is being removed from the kernel. It also removes
>> STiD127 related code, which has never actually been supported
>> upstream.
>>
>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>> Cc: <peppe.cavallaro@st.com>
>> Cc: <alexandre.torgue@st.com>
>> Cc: <netdev@vger.kernel.org>
>> ---
>> .../devicetree/bindings/net/sti-dwmac.txt | 3 +-
>
> Acked-by: Rob Herring <robh@kernel.org>
Applied on sti-dt-for-4.10 branch
Thanks
>
>> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 37 ----------------------
>> 2 files changed, 1 insertion(+), 39 deletions(-)
^ permalink raw reply
* PowerEdge R530 show rx dropped packet with BCM5720
From: Roberto Fichera @ 2016-10-18 8:03 UTC (permalink / raw)
To: linux-netdev, For users of Fedora
Hi All,
I'm having a problem with a Dell PowerEdge R530 running a Fedora 24 with kernel 4.7.7-200.fc24.x86_64
that is showing RX dropped packet on all the onboard BCM5720 4x1Gbits interfaces.
I've done several tests replacing cables and switches as well as disabling all rx offload
features but the problem still there.
Can anyone help here?
Thanks in advance,
Roberto Fichera.
[root@server ~]# ifconfig eno1
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.1.11 netmask 255.255.255.0 broadcast 10.10.1.255
inet6 fe80::931b:276f:74db:943 prefixlen 64 scopeid 0x20<link>
ether 18:66:da:5c:e9:81 txqueuelen 3000 (Ethernet)
RX packets 566596 bytes 84798649 (80.8 MiB)
RX errors 0 dropped 9274 overruns 0 frame 0
TX packets 518318 bytes 208948763 (199.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
root@server ~]# ethtool -i eno1
driver: tg3
version: 3.137
firmware-version: FFV20.2.17 bc 5720-v1.39
expansion-rom-version:
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
[root@server ~]# ethtool eno1
Settings for eno1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
02:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe
Subsystem: Dell Device 0639
Flags: bus master, fast devsel, latency 0, IRQ 18, NUMA node 0
Memory at 91a30000 (64-bit, prefetchable) [size=64K]
Memory at 91a40000 (64-bit, prefetchable) [size=64K]
Memory at 91a50000 (64-bit, prefetchable) [size=64K]
Expansion ROM at 91f00000 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number 00-00-18-66-da-5c-e9-81
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Kernel driver in use: tg3
Kernel modules: tg3
02:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe
Subsystem: Dell Device 0639
Flags: bus master, fast devsel, latency 0, IRQ 19, NUMA node 0
Memory at 91a00000 (64-bit, prefetchable) [size=64K]
Memory at 91a10000 (64-bit, prefetchable) [size=64K]
Memory at 91a20000 (64-bit, prefetchable) [size=64K]
Expansion ROM at 91f40000 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number 00-00-18-66-da-5c-e9-82
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Kernel driver in use: tg3
Kernel modules: tg3
03:00.0 Ethernet controller: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe
Subsystem: Dell Device 0639
Flags: bus master, fast devsel, latency 0, IRQ 19, NUMA node 0
Memory at 91b30000 (64-bit, prefetchable) [size=64K]
Memory at 91b40000 (64-bit, prefetchable) [size=64K]
Memory at 91b50000 (64-bit, prefetchable) [size=64K]
Expansion ROM at 92000000 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number 00-00-18-66-da-5c-e9-83
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Kernel driver in use: tg3
Kernel modules: tg3
03:00.1 Ethernet controller: Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet PCIe
Subsystem: Dell Device 0639
Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0
Memory at 91b00000 (64-bit, prefetchable) [size=64K]
Memory at 91b10000 (64-bit, prefetchable) [size=64K]
Memory at 91b20000 (64-bit, prefetchable) [size=64K]
Expansion ROM at 92040000 [disabled] [size=256K]
Capabilities: [48] Power Management version 3
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [a0] MSI-X: Enable+ Count=17 Masked-
Capabilities: [ac] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [13c] Device Serial Number 00-00-18-66-da-5c-e9-84
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Virtual Channel
Kernel driver in use: tg3
Kernel modules: tg3
[root@server ~]# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8
CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15
0: 150 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-IO-APIC 2-edge timer
8: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-IO-APIC 8-edge rtc0
9: 52 0 0 0 0 0 0 0 67
0 0 0 0 0 0 0 IR-IO-APIC 9-fasteoi acpi
10: 246 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-IO-APIC 10-edge ipmi_si
18: 34 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-IO-APIC 18-fasteoi ehci_hcd:usb1, ehci_hcd:usb2
25: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 16384-edge PCIe PME
26: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 32768-edge PCIe PME
27: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 36864-edge PCIe PME
28: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 49152-edge PCIe PME
29: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 458752-edge PCIe PME
30: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 460800-edge PCIe PME
31: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 462848-edge PCIe PME
32: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 464896-edge PCIe PME
33: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 466944-edge PCIe PME
34: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 286720-edge ahci[0000:00:11.4]
35: 73 0 0 7744 0 4555 0 0 0
0 0 2510 7578 0 825 0 IR-PCI-MSI 512000-edge ahci[0000:00:1f.2]
36: 3663 0 0 0 0 2883 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 327680-edge xhci_hcd
38: 2842 0 0 0 3964 1082 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 524288-edge megasas
39: 0 1191 0 84886 22401 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 524289-edge megasas
40: 0 0 21035 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 524290-edge megasas
41: 0 103285 0 3229 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 524291-edge megasas
42: 0 0 0 7870 2855 1772 0 0 4877
0 0 4426 2373 18702 0 0 IR-PCI-MSI 524292-edge megasas
43: 0 0 0 0 0 2602 0 0 0
0 0 0 0 0 0 34475 IR-PCI-MSI 524293-edge megasas
44: 0 0 0 0 0 0 2475 0 0
0 0 0 0 0 84085 0 IR-PCI-MSI 524294-edge megasas
45: 0 0 0 6712 1227 0 0 2600 0
0 0 978 8650 26936 0 0 IR-PCI-MSI 524295-edge megasas
46: 0 0 0 2051 0 0 0 0 287
0 0 140 15289 157 0 0 IR-PCI-MSI 524296-edge megasas
47: 0 0 0 0 0 0 0 0 0
321 0 96926 0 0 0 0 IR-PCI-MSI 524297-edge megasas
48: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 DMAR-MSI 0-edge dmar0
49: 0 0 0 0 0 0 0 0 0
0 633 0 0 0 0 0 IR-PCI-MSI 524298-edge megasas
50: 0 0 0 0 0 0 0 0 0
116952 0 139 0 0 0 0 IR-PCI-MSI 524299-edge megasas
51: 0 0 0 0 0 0 0 0 4479
0 0 0 9880 0 0 0 IR-PCI-MSI 524300-edge megasas
52: 0 0 0 0 0 0 0 20108 0
0 0 0 0 127 0 0 IR-PCI-MSI 524301-edge megasas
53: 0 0 0 0 0 0 84765 0 0
0 0 0 0 0 280 0 IR-PCI-MSI 524302-edge megasas
54: 0 0 0 12840 722 51632 0 0 0
0 0 16374 625 0 0 84 IR-PCI-MSI 524303-edge megasas
56: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 65536-edge ioat-msix
58: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 67584-edge ioat-msix
59: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 69632-edge ioat-msix
60: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 71680-edge ioat-msix
61: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 73728-edge ioat-msix
62: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 75776-edge ioat-msix
63: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 77824-edge ioat-msix
64: 2 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 79872-edge ioat-msix
65: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1574912-edge eno4-tx-0
66: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1574913-edge eno4-rx-1
67: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1574914-edge eno4-rx-2
68: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1574915-edge eno4-rx-3
69: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1574916-edge eno4-rx-4
70: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1572864-edge eno3-tx-0
71: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1572865-edge eno3-rx-1
72: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1572866-edge eno3-rx-2
73: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1572867-edge eno3-rx-3
74: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1572868-edge eno3-rx-4
75: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1050624-edge eno2-tx-0
76: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1050625-edge eno2-rx-1
77: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1050626-edge eno2-rx-2
78: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1050627-edge eno2-rx-3
79: 1 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1050628-edge eno2-rx-4
80: 27 0 0 237076 152591 0 0 0 0
0 0 0 0 0 0 0 IR-PCI-MSI 1048576-edge eno1-tx-0
81: 27 0 0 4412 17854 60369 0 0 0
0 0 0 0 0 5260 0 IR-PCI-MSI 1048577-edge eno1-rx-1
82: 13 0 147 0 0 0 0 0 0
0 0 0 0 281274 0 0 IR-PCI-MSI 1048578-edge eno1-rx-2
83: 1 30 0 0 3997 0 0 0 0
0 0 15092 24149 0 0 0 IR-PCI-MSI 1048579-edge eno1-rx-3
84: 12 0 0 0 0 0 0 0 62250
0 0 0 0 0 0 0 IR-PCI-MSI 1048580-edge eno1-rx-4
NMI: 1131 1088 1038 1235 1079 1110 1047 1168 132
419 182 423 181 157 296 268 Non-maskable interrupts
LOC: 6159157 9652456 7667907 12679976 8318814 9250168 9793903 8433998 855179 11849165
560772 11980808 3036730 2068369 7644596 6501494 Local timer interrupts
SPU: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 Spurious interrupts
PMI: 1131 1088 1038 1235 1079 1110 1047 1168 132
419 182 423 181 157 296 268 Performance monitoring interrupts
IWI: 1134 1088 1038 1236 1079 1110 1047 1168 132
419 182 423 181 157 296 268 IRQ work interrupts
RTR: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 APIC ICR read retries
RES: 2627838 898345 1648111 1092940 1643644 1664029 1207350 1499096 22322 28230
32662 23121 20965 14704 37382 19706 Rescheduling interrupts
CAL: 80329 77363 73116 76848 85910 85560 83319 81882 2341
2533 2592 2622 2535 2534 2451 2178 Function call interrupts
TLB: 245 114 368 120 104 373 1615 2165 51
2118 292 80 35 22 51 35 TLB shootdowns
TRM: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 Thermal event interrupts
THR: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 Threshold APIC interrupts
DFR: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 Deferred Error APIC interrupts
MCE: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 Machine check exceptions
MCP: 159 159 159 159 159 159 159 159 159
159 159 159 159 159 159 159 Machine check polls
ERR: 139
MIS: 0
PIN: 300005 295650 348415 290934 274430 260562 232418 294068 7160 3286
40264 1178 11093 5205 8358 3100 Posted-interrupt notification event
PIW: 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 Posted-interrupt wakeup event
^ permalink raw reply
* [PATCH net] conntrack: perform a full scan in gc
From: Nicolas Dichtel @ 2016-10-18 8:30 UTC (permalink / raw)
To: pablo, fw; +Cc: davem, netdev, netfilter-devel, Nicolas Dichtel
In-Reply-To: <20161014105327.GA8655@salvia>
After commit b87a2f9199ea ("netfilter: conntrack: add gc worker to remove
timed-out entries"), netlink conntrack deletion events may be sent with a
huge delay (5 minutes).
There is two ways to evict conntrack:
- during a conntrack lookup;
- during a conntrack dump.
Let's do a full scan of conntrack entries after a period of inactivity
(no conntrack lookup).
CC: Florian Westphal <fw@strlen.de>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
Here is another proposal to try to fix the problem.
Comments are welcomed,
Nicolas
net/netfilter/nf_conntrack_core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index ba6a1d421222..3dbb27bd9582 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -87,6 +87,7 @@ static __read_mostly bool nf_conntrack_locks_all;
#define GC_MAX_BUCKETS 8192u
#define GC_INTERVAL (5 * HZ)
#define GC_MAX_EVICTS 256u
+static bool gc_full_scan = true;
static struct conntrack_gc_work conntrack_gc_work;
@@ -511,6 +512,7 @@ ____nf_conntrack_find(struct net *net, const struct nf_conntrack_zone *zone,
unsigned int bucket, hsize;
begin:
+ gc_full_scan = false;
nf_conntrack_get_ht(&ct_hash, &hsize);
bucket = reciprocal_scale(hash, hsize);
@@ -942,7 +944,11 @@ static void gc_worker(struct work_struct *work)
gc_work = container_of(work, struct conntrack_gc_work, dwork.work);
- goal = min(nf_conntrack_htable_size / GC_MAX_BUCKETS_DIV, GC_MAX_BUCKETS);
+ if (gc_full_scan)
+ goal = nf_conntrack_htable_size;
+ else
+ goal = min(nf_conntrack_htable_size / GC_MAX_BUCKETS_DIV,
+ GC_MAX_BUCKETS);
i = gc_work->last_bucket;
do {
@@ -977,7 +983,8 @@ static void gc_worker(struct work_struct *work)
rcu_read_unlock();
cond_resched_rcu_qs();
} while (++buckets < goal &&
- expired_count < GC_MAX_EVICTS);
+ (gc_full_scan || expired_count < GC_MAX_EVICTS));
+ gc_full_scan = true;
if (gc_work->exiting)
return;
--
2.8.1
^ permalink raw reply related
* RE: Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest
From: Koehrer Mathias (ETAS/ESW5) @ 2016-10-18 8:43 UTC (permalink / raw)
To: Julia Cartwright, Alexander Duyck
Cc: Bjorn Helgaas, linux-rt-users@vger.kernel.org,
Sebastian Andrzej Siewior, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, Matthew Garrett, Bjorn Helgaas,
Greg, linux-pci@vger.kernel.org
In-Reply-To: <20161017183209.GA18465@jcartwri.amer.corp.natinst.com>
[-- Attachment #1: Type: text/plain, Size: 6018 bytes --]
Hi all,
> > >>
> > >> Can you continue your bisection using 'git bisect'? You've already
> > >> narrowed it down between 4.0 and 4.1, so you're well on your way.
> > >>
> > >
> > > OK - done.
> > > And finally I was successful!
> > > The following git commit is the one that is causing the trouble!
> > > (The full commit is in the attachment).
> > > +++++++++++++++++++++ BEGIN +++++++++++++++++++++++++++
> > > commit 387d37577fdd05e9472c20885464c2a53b3c945f
> > > Author: Matthew Garrett <mjg59@coreos.com>
> > > Date: Tue Apr 7 11:07:00 2015 -0700
> > >
> > > PCI: Don't clear ASPM bits when the FADT declares it's
> > > unsupported
> > >
> > > Communications with a hardware vendor confirm that the expected
> behaviour
> > > on systems that set the FADT ASPM disable bit but which still grant full
> > > PCIe control is for the OS to leave any BIOS configuration intact and
> > > refuse to touch the ASPM bits. This mimics the behaviour of Windows.
> > >
> > > Signed-off-by: Matthew Garrett <mjg59@coreos.com>
> > > Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> > > +++++++++++++++++++++ HEADER +++++++++++++++++++++++++++
> > >
> > > The only files that are modified by this commit are
> > > drivers/acpi/pci_root.c drivers/pci/pcie/aspm.c
> > > include/linux/pci-aspm.h
> > >
> > > This is all generic PCIe stuff - however I do not really understand
> > > what the changes of the commit are...
> > >
> > > In my setup I am using a dual port igb Ethernet adapter.
> > > This has an onboard PCIe switch and it might be that the
> > > configuration of this PCIe switch on the Intel board is causing the trouble.
> > >
> > > Please see also the output of "lspci -v" in the attachment.
> > > The relevant PCI address of the NIC is 04:00.0 / 04:00.1
> > >
> > Hi Mathias,
> >
> > If you could set the output of lspci -vvv it might be more useful as
> > most of the configuration data isn't present in the lspci dump you had
> > attached. Specifically if you could do this for the working case and
> > the non-working case we could verify if this issue is actually due to
> > the ASPM configuration on the device.
> >
> > Also one thing you might try is booting your kernel with the kernel
> > parameter "pcie_aspm=off". It sounds like the extra latency is likely
> > due to your platform enabling ASPM on the device and this in turn will
> > add latency if the PCIe link is disabled when you attempt to perform a
> > read as it takes some time to bring the PCIe link up when in L1 state.
>
> So if we assume it's this commit causing the regression, then it's safe to assume that
> this system's BIOS is claiming to not support ASPM in the FADT, but the BIOS is
> leaving ASPM configured in some way on the relevant devices.
>
> Also, unfortunately, taking a look at the code which handles "pcie_aspm=off", it
> won't be sufficient to disable ASPM on these this system, as disabling these states is
> skipped when the FADT doesn't advertise ASPM support.
>
> What would be needed is an option like "force", but which force _disables_ ASPM.
> "force-disable", maybe.
>
OK, I have now built a "good" kernel
(using commit 37a9c502c0af013aaae094556830100c2bb133ac) and
a "bad" kernel
(using commit 387d37577fdd05e9472c20885464c2a53b3c945f).
Please find attached the outputs of "lspci -vvv" for both cases.
As assumed, in the "bad" case, the PCIe switch on the NIC board and the
two Ethernet controllers show "ASPM L1 Enabled" in "LnkCtl".
In the "good" case this is "ASPM disabled".
I tried also the kernel option "pcie_aspm=off" in the "bad" case.
However this had no impact, the issue still occurred!
Switching to kernel 4.8 I set the configuration for
"Default ASPM policy" to CONFIG_PCIEASPM_PERFORMANCE
however this did not show any effect.
This in contrast to the help text provided in the kernel configuration:
"Disable PCI Express ASPM L0s and L1, even if the BIOS enabled them."
For me the first step should be to make the CONFIG_PCIEASPM_PERFORMANCE
work as expected: It this is set, the ASPM should be forced to be disabled.
This is currently not the case.
During the boot phase I see in dmesg:
"ACPI FADT declares the system doesn't support PCIe ASPM, so disable it"
This leads to a call of pcie_no_aspm() and this sets the aspm_policy to POLICY_DEFAULT
instead to the value that has been selected in the kernel configuration.
The following patch fixes the issue for me on kernel 4.8.
The config value CONFIG_PCIEASPM_PERFORMANCE is considered correctly.
+++++++++++++++++++++++ BEGIN +++++++++++++++++++
Consider the CONFIG_PCIEASPM_* values within pcie_no_aspm().
Signed-off-by: Mathias Koehrer <mathias.koehrer@etas.com>
---
drivers/pci/pcie/aspm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-4.8/drivers/pci/pcie/aspm.c
===================================================================
--- linux-4.8.orig/drivers/pci/pcie/aspm.c
+++ linux-4.8/drivers/pci/pcie/aspm.c
@@ -79,10 +79,13 @@ static LIST_HEAD(link_list);
#ifdef CONFIG_PCIEASPM_PERFORMANCE
static int aspm_policy = POLICY_PERFORMANCE;
+static int aspm_default_config_policy = POLICY_PERFORMANCE;
#elif defined CONFIG_PCIEASPM_POWERSAVE
static int aspm_policy = POLICY_POWERSAVE;
+static int aspm_default_config_policy = POLICY_POWERSAFE;
#else
static int aspm_policy;
+static int aspm_default_config_policy;
#endif
static const char *policy_str[] = {
@@ -946,7 +949,7 @@ void pcie_no_aspm(void)
* (b) prevent userspace from changing policy
*/
if (!aspm_force) {
- aspm_policy = POLICY_DEFAULT;
+ aspm_policy = aspm_default_config_policy;
aspm_disabled = 1;
}
}
+++++++++++++++++++++++ END +++++++++++++++++++
Apart from that a kernel parameter - as proposed by Julia - like
"pcie_aspm=force-disable" would be helpful as well.
Any feedback is welcome!
Regards
Mathias
[-- Attachment #2: lspci.bad.gz --]
[-- Type: application/x-gzip, Size: 5127 bytes --]
[-- Attachment #3: lspci.good.gz --]
[-- Type: application/x-gzip, Size: 5123 bytes --]
^ permalink raw reply
* Re: [PATCH net] conntrack: perform a full scan in gc
From: Florian Westphal @ 2016-10-18 8:47 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: pablo, fw, davem, netdev, netfilter-devel
In-Reply-To: <1476779435-30503-1-git-send-email-nicolas.dichtel@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> After commit b87a2f9199ea ("netfilter: conntrack: add gc worker to remove
> timed-out entries"), netlink conntrack deletion events may be sent with a
> huge delay (5 minutes).
>
> There is two ways to evict conntrack:
> - during a conntrack lookup;
> - during a conntrack dump.
> Let's do a full scan of conntrack entries after a period of inactivity
> (no conntrack lookup).
>
> CC: Florian Westphal <fw@strlen.de>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
>
> Here is another proposal to try to fix the problem.
> Comments are welcomed,
> Nicolas
Hmm, I don't think its good idea in practice.
If goal is to avoid starving arbitrary 'dead' ct for too long,
then simple ping will defeat the logic here, because...
> net/netfilter/nf_conntrack_core.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> index ba6a1d421222..3dbb27bd9582 100644
> --- a/net/netfilter/nf_conntrack_core.c
> +++ b/net/netfilter/nf_conntrack_core.c
> @@ -87,6 +87,7 @@ static __read_mostly bool nf_conntrack_locks_all;
> #define GC_MAX_BUCKETS 8192u
> #define GC_INTERVAL (5 * HZ)
> #define GC_MAX_EVICTS 256u
> +static bool gc_full_scan = true;
>
> static struct conntrack_gc_work conntrack_gc_work;
>
> @@ -511,6 +512,7 @@ ____nf_conntrack_find(struct net *net, const struct nf_conntrack_zone *zone,
> unsigned int bucket, hsize;
>
> begin:
> + gc_full_scan = false;
... we do periodic lookup (but always in same slot), so no full scan is
triggered.
If you think its useful, consider sending patch that rescheds worker
instantly in case budget expired, otherwise I will do this later this
week.
[ I am aware doing instant restart might be too late, but at least we
would then reap more entries once we stumble upon large number of
expired ones ].
^ permalink raw reply
* [PATCH] cxgb4: Fix number of queue sets corssing the limit
From: Ganesh Goudar @ 2016-10-18 8:51 UTC (permalink / raw)
To: davem; +Cc: netdev, linteam, hariprasad, nirranjan, Ganesh Goudar
Do not let number of offload queue sets to go more than
MAX_OFLD_QSETS, which would otherwise crash the driver
on machines with cores more than MAX_OFLD_QSETS.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index f320497..57eb4e1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4057,7 +4057,7 @@ static void cfg_queues(struct adapter *adap)
* capped by the number of available cores.
*/
if (n10g) {
- i = num_online_cpus();
+ i = min_t(int, MAX_OFLD_QSETS, num_online_cpus());
s->ofldqsets = roundup(i, adap->params.nports);
} else {
s->ofldqsets = adap->params.nports;
--
2.1.0
^ permalink raw reply related
* Re: [STLinux Kernel] [PATCH 18/19] stmmac: dwmac-sti: Remove obsolete STi platforms
From: Patrice Chotard @ 2016-10-18 8:59 UTC (permalink / raw)
To: Rob Herring, Peter Griffin, Alexandre TORGUE, Peppe CAVALLARO
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, kernel-F5mvAk5X5gdBDgjK7y7TUQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <dcbb8065-b272-0a2f-8efb-c55217712caf-qxv4g6HH51o@public.gmane.org>
On 10/18/2016 10:05 AM, Patrice Chotard wrote:
>
>
> On 09/23/2016 05:11 PM, Rob Herring wrote:
>> On Wed, Sep 14, 2016 at 02:27:56PM +0100, Peter Griffin wrote:
>>> This patch removes support for STiH415/6 SoC's from the
>>> dwmac-sti driver and dt binding doc, as support for these
>>> platforms is being removed from the kernel. It also removes
>>> STiD127 related code, which has never actually been supported
>>> upstream.
>>>
>>> Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> Cc: <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
>>> Cc: <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>>> Cc: <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/net/sti-dwmac.txt | 3 +-
>>
>> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
>
> Applied on sti-dt-for-4.10 branch
Sorry, i did a mistake, these patch should go in stmmac tree.
Peppe or Alexandre will you take care of it ?
Thanks
>
> Thanks
>
>>
>>> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 37 ----------------------
>>> 2 files changed, 1 insertion(+), 39 deletions(-)
>
> _______________________________________________
> Kernel mailing list
> Kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org
> http://www.stlinux.com/mailman/listinfo/kernel
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] tcp: Remove unused but set variable
From: Tobias Klauser @ 2016-10-18 9:22 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Remove the unused but set variable icsk in listening_get_next to fix the
following GCC warning when building with 'W=1':
net/ipv4/tcp_ipv4.c: In function ‘listening_get_next’:
net/ipv4/tcp_ipv4.c:1890:31: warning: variable ‘icsk’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/ipv4/tcp_ipv4.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index bd5e8d10893f..79d55eb3ec3f 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1887,7 +1887,6 @@ static void *listening_get_next(struct seq_file *seq, void *cur)
struct tcp_iter_state *st = seq->private;
struct net *net = seq_file_net(seq);
struct inet_listen_hashbucket *ilb;
- struct inet_connection_sock *icsk;
struct sock *sk = cur;
if (!sk) {
@@ -1909,7 +1908,6 @@ static void *listening_get_next(struct seq_file *seq, void *cur)
continue;
if (sk->sk_family == st->family)
return sk;
- icsk = inet_csk(sk);
}
spin_unlock_bh(&ilb->lock);
st->offset = 0;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH net] conntrack: perform a full scan in gc
From: Nicolas Dichtel @ 2016-10-18 10:06 UTC (permalink / raw)
To: Florian Westphal; +Cc: pablo, davem, netdev, netfilter-devel
In-Reply-To: <20161018084718.GB29405@breakpoint.cc>
Le 18/10/2016 à 10:47, Florian Westphal a écrit :
> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
>> After commit b87a2f9199ea ("netfilter: conntrack: add gc worker to remove
>> timed-out entries"), netlink conntrack deletion events may be sent with a
>> huge delay (5 minutes).
>>
>> There is two ways to evict conntrack:
>> - during a conntrack lookup;
>> - during a conntrack dump.
>> Let's do a full scan of conntrack entries after a period of inactivity
>> (no conntrack lookup).
>>
>> CC: Florian Westphal <fw@strlen.de>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> ---
>>
>> Here is another proposal to try to fix the problem.
>> Comments are welcomed,
>> Nicolas
>
> Hmm, I don't think its good idea in practice.
> If goal is to avoid starving arbitrary 'dead' ct for too long,
> then simple ping will defeat the logic here, because...
>
>> net/netfilter/nf_conntrack_core.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
>> index ba6a1d421222..3dbb27bd9582 100644
>> --- a/net/netfilter/nf_conntrack_core.c
>> +++ b/net/netfilter/nf_conntrack_core.c
>> @@ -87,6 +87,7 @@ static __read_mostly bool nf_conntrack_locks_all;
>> #define GC_MAX_BUCKETS 8192u
>> #define GC_INTERVAL (5 * HZ)
>> #define GC_MAX_EVICTS 256u
>> +static bool gc_full_scan = true;
>>
>> static struct conntrack_gc_work conntrack_gc_work;
>>
>> @@ -511,6 +512,7 @@ ____nf_conntrack_find(struct net *net, const struct nf_conntrack_zone *zone,
>> unsigned int bucket, hsize;
>>
>> begin:
>> + gc_full_scan = false;
>
> ... we do periodic lookup (but always in same slot), so no full scan is
> triggered.
Yes, I was wondering about that. My first idea was to have that bool per bucket
and force a scan of the bucket instead of the whole table.
>
> If you think its useful, consider sending patch that rescheds worker
> instantly in case budget expired, otherwise I will do this later this
> week.
Ok, I will send it, but it does not address the "inactivity" problem.
>
> [ I am aware doing instant restart might be too late, but at least we
> would then reap more entries once we stumble upon large number of
> expired ones ].
>
^ permalink raw reply
* utilisateur salut
From: Zimbra @ 2016-10-18 10:10 UTC (permalink / raw)
utilisateur salut
Votre compte Zimbra doit être vérifié pour éviter De-activation.
00:28:50 -0500 Octobre 2016
Vous avez moins de 24 heures.
Cliquez sur le lien ci-dessous pour continuer le bouton en utilisant ce service
http://frenchunivgrade-001-dept-nakjsak.tripod.com/
Continuer avec vérification: http://frenchunivgrade-001-dept-nakjsak.tripod.com/
Merci,
L'équipe compte Zimbra
^ permalink raw reply
* Re: Need help with mdiobus_register and phy
From: Zefir Kurtisi @ 2016-10-18 10:31 UTC (permalink / raw)
To: Timur Tabi, Andrew Lunn; +Cc: Florian Fainelli, netdev
In-Reply-To: <58053A33.4030108@codeaurora.org>
On 10/17/2016 10:53 PM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> Anyway, since the SGMII reset is required, instead of reverting the patch in full
>> I suggest to move the SGMII power down from at803x_suspend() and do a SerDes power
>> cycle in at803x_resume(). Could you please test if the patch below fixes the
>> problem?
>
> I have never seen the original problem that you noticed. When I use the generic
> phy driver instead of the at803x driver, everything works great for me. Perhaps
> the problem that you noticed only occurs with the Gianfar NIC?
>
You mean it works for you in SGMII mode without glitches? Then it might in fact be
an unfortunate rare or unique combination that we chose.
> Anyway, I tested the change you suggested, and it fixes the problem for me. I
> moved the power-down code to before the power-up code. But like I said, since I
> never experienced the original problem, I don't know if that works for you.
>
> I suggest you make the changes in the driver yourself and test it, and then I will
> test whether that patch also works for me.
>
I'd need some time to get that tested, and since our device might be the only one
requiring the fix, I am fine with keeping the patch private. Feel free to revert
it, if required, I'll provide a revised one.
Thanks
Zefir
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: Add Fast Link Failure - 2 set driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-18 10:34 UTC (permalink / raw)
To: Florian Fainelli
Cc: Andrew Lunn, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
Allan.Nielsen-dzo6w/eZyo2tG0bUXCXiUA
In-Reply-To: <838C6202-9B7D-4AFA-B163-55515044FA4F-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Florian,
Thank you for review comments.
On Mon, Oct 17, 2016 at 05:51:11AM -0700, Florian Fainelli wrote:
> EXTERNAL EMAIL
>
>
> On October 17, 2016 1:13:14 AM PDT, Raju Lakkaraju <Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org> wrote:
> >Hi Andrew,
> >
> >Thank you for code review and comments.
> >
> >On Fri, Oct 14, 2016 at 02:02:28PM +0200, Andrew Lunn wrote:
> >> EXTERNAL EMAIL
> >>
> >>
> >> > On Fri, Oct 14, 2016 at 05:10:33PM +0530, Raju Lakkaraju wrote:
> >> > From: Raju Lakkaraju <Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>
> >> >
> >> > VSC8531 Fast Link Failure 2 feature enables the PHY to indicate the
> >> > onset of a potential link failure in < 100 usec for 100BASE-TX
> >> > operation. FLF2 is supported through the MDINT (active low) pin.
> >>
> >> Is the MDINT pin specific to this feature, or a general interrupt
> >pin?
> >>
> >
> >MDINT pin is general interrupt. MDINT pin share the interrupt with
> >FLF2 along with another 13 interrupts.
> >
> >> Device tree is used to describe the hardware. It should not really
> >> describe software or configuration. But the borders are a bit
> >> fluffly. Signal edge rates is near to hardware. This is a lot more
> >> towards configuration. So i'm not sure a device tree property is the
> >> correct way to describe this.
> >>
> >> This is also a feature i know other PHYs support. The Marvell PHY has
> >> a "Metro Ethernet" extension which allows it to report link failures
> >> for 1000BASE-T in 10, 20 or 40ms, instead of the usual 750ms. So we
> >> need a generic solution other PHYs can implement.
> >>
> >> As with cable testing, i think it should be an ethtool option.
> >
> >I agree with you.
> >I thought this is one time initialization either enable or disable.
> >if customer need this feature, they can enable in DT.
> >Do you want me to implement through IOCTL instead of Device tree?
> >Do you have any other suggestions?
>
> As indicated in the other email about speed downshift, we may want to utilize ethtool's ability to modify tunable parameters (small integer, boolean, values) and extend it to cover features offered by PHYs in a way that an user can dynamically turn these features on or off.
>
> In fact, this looks a lot like netdev features (e.g: checksum offload), and there seems to be some commonality here between at least Marvell and Microsemi (for the faster link down reporting), so maybe we should start adding PHY features similar to netdev features?
>
Sure.
I would like add one flag in phy_device structure:
u64 phy_features;
In phy_driver structure, i would like to add 2 function pointer as
int (*phy_featues_set)(struct phy_device *phydev);
int (*phy_featues_get)(struct phy_device *phydev);
All the PHY specific features i.e. Fast link failure -2, Downshift, Loopback etc
are the case in feature_set/feature_get functions.
Is it ok?
> --
> Florian
---
Thanks,
Raju.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC 3/6] net: phy: Threaded interrupts allow some simplification
From: Sergei Shtylyov @ 2016-10-18 10:37 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: Vivien Didelot, netdev
In-Reply-To: <06bdfcb4-8bb6-28e6-00e5-2518f79f729d@gmail.com>
Hello!
On 9/28/2016 8:14 PM, Florian Fainelli wrote:
>>>>>> The PHY interrupts are now handled in a threaded interrupt handler,
>>>>>> which can sleep. The work queue is no longer needed, phy_change() can
>>>>>> be called directly. Additionally, none of the callers of
>>>>>> phy_mac_interrupt() did so in interrupt context, so fully remove the
>>>>>
>>>>> I did intend to call it from interrupt context (from the ravb
>>>>> driver).
>>>>>
>>>>>> work queue, and document that phy_mac_interrupt() should not be called
>>>>>> in interrupt context.
>>>>>
>>>>> It was intentionally made callable from the interrupt context, I'd
>>>>> prefer
>>>>> if you wouldn't change that.
>>>>
>>>> OTOH, it's still not very handy to call because of the 'new_link'
>>>> parameter which I'm not sure I can provide...
>>>
>>> Hi Sergei
>>>
>>> If there is a need for it, i will leave the work queue and keep this
>>> code unchanged.
>>
>> Let's hear what Florian says...
>
> The intent is really to have phy_mac_interrupt() callable from hard IRQ
> context, not that this matters really too much because link events
> already occur in the slow path, but it's nice to have that property
> retained IMHO.
Actually, I still don't know how to call phy_mac_interrupt() from the ravb
driver because of the 'new_link' parameter -- I won't always have that signal
connected to the MAC...
MBR, Sergei
^ 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