Yes, we already found these and are included in our kernel, but even with these
patches we still receive the panic.
- Johan
On 18 Jul 2015, at 10:56, Eric Dumazet eric.duma...@gmail.com wrote:
On Fri, 2015-07-17 at 21:18 +, Johan Schuijt wrote:
Hey guys,
We’re currently running
On Fri, 2015-07-17 at 21:18 +, Johan Schuijt wrote:
Hey guys,
We’re currently running into a reproducible panic in the eviction work
queue code when we pin al our eth* IRQ to different CPU cores (in
order to scale our networking performance for our virtual servers).
This only occurs
On Fri, 2015-07-17 at 17:27 -0700, Alex Gartrell wrote:
On Fri, Jul 17, 2015 at 5:10 PM, Cong Wang cw...@twopensource.com wrote:
Hmm, but in htb_delete() we do reset the leaf qdisc before removing the
class from ha
if (!cl-level) {
qlen = cl-un.leaf.q-q.qlen;
On 07/18/2015 12:02 PM, Nikolay Aleksandrov wrote:
On 07/18/2015 11:01 AM, Johan Schuijt wrote:
Yes, we already found these and are included in our kernel, but even with
these patches we still receive the panic.
- Johan
On 18 Jul 2015, at 10:56, Eric Dumazet eric.duma...@gmail.com wrote:
Hi all,
- On Jul 18, 2015, at 10:58 AM, Andrew Lunn and...@lunn.ch wrote:
Good point. The timeout is most definitely quite large and for sure on
the safe side. It might make sense to add some statistics gathering to
see how long the maximum observed delay actually is.
Hi All
On 07/18/2015 05:28 PM, Johan Schuijt wrote:
Thx for your looking into this!
Thank you for the report, I will try to reproduce this locally
Could you please post the full crash log ?
Of course, please see attached file.
Also could you test
with a clean current kernel from Linus' tree
Signed-off-by: Jakub Wilk jw...@jwilk.net
---
net/xfrm/xfrm_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index bd16c6c..0cebf1f 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2048,7 +2048,7 @@ static int
With attachment this time, also not sure wether this is what you were referring
to, so let me know if anything else needed!
- Johan
On 18 Jul 2015, at 17:28, Johan Schuijt-Li jo...@transip.nl wrote:
Thx for your looking into this!
Thank you for the report, I will try to reproduce this
Thx for your looking into this!
Thank you for the report, I will try to reproduce this locally
Could you please post the full crash log ?
Of course, please see attached file.
Also could you test
with a clean current kernel from Linus' tree or Dave's -net ?
Will do.
These are available
On Sat, Jul 18, 2015 at 11:23:19AM -0400, Vivien Didelot wrote:
Hi all,
- On Jul 18, 2015, at 10:58 AM, Andrew Lunn and...@lunn.ch wrote:
Good point. The timeout is most definitely quite large and for sure on
the safe side. It might make sense to add some statistics gathering to
Changes to be committed:
modified: drivers/net/ethernet/realtek/r8169.c
Signed-off-by: Corcodel Marian a...@192-168-0-3.rdsnet.ro
---
drivers/net/ethernet/realtek/r8169.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git
Changes to be committed:
modified: drivers/net/ethernet/realtek/r8169.c
Signed-off-by: Corcodel Marian a...@192-168-0-3.rdsnet.ro
---
drivers/net/ethernet/realtek/r8169.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git
On 07/18/2015 11:01 AM, Johan Schuijt wrote:
Yes, we already found these and are included in our kernel, but even with
these patches we still receive the panic.
- Johan
On 18 Jul 2015, at 10:56, Eric Dumazet eric.duma...@gmail.com wrote:
On Fri, 2015-07-17 at 21:18 +, Johan
Good point. The timeout is most definitely quite large and for sure on
the safe side. It might make sense to add some statistics gathering to
see how long the maximum observed delay actually is.
Hi All
Statistics are something which can be used a lot, i bursts and
interactivily. ATU, VTU etc,
18.07.2015 05:29, Florian Fainelli пишет:
Le 07/17/15 16:53, Stas Sergeev a écrit :
18.07.2015 02:35, Florian Fainelli пишет:
On 17/07/15 16:24, Stas Sergeev wrote:
18.07.2015 01:01, Florian Fainelli пишет:
On 17/07/15 13:03, Stas Sergeev wrote:
17.07.2015 21:50, Florian Fainelli пишет:
On
Fri, Jul 17, 2015 at 10:38:44PM CEST, dan...@iogearbox.net wrote:
The following test case causes a NULL pointer dereference in cls_flower:
tc filter add dev foo parent 1: flower eth_type ipv4 action ok flowid 1:1
tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
flower
On Fri, 2015-07-17 at 18:18 -0700, David Miller wrote:
From: Joe Perches j...@perches.com Date: Fri, 17 Jul 2015 16:07:02 -0700
On Fri, 2015-07-17 at 22:00 +0200, Sowmini Varadhan wrote:
__vxlan_find_mac invokes ether_addr_equal on the eth_addr field,
which triggers unaligned access
Hi Rami and Thomas,
I try to run vanilla kernel 4.2.0 on custom Armada-370 board, based on
DB-88F6710-BP.
The problem is that the board shuts down after writing to
MVNETA_TXQ_UPDATE_REG in this code:
static void mvneta_txq_pend_desc_add(struct mvneta_port *pp,
Julian Anastasov j...@ssi.bg wrote:
[ Dave, please toss my patch, its either v3 or something else entirely ]
In fact, TOS should be matched just like in
fib_table_lookup but it is not.
This changes fib_select_default to not change the FIB chosen result EXCEPT
if this nexthop
Constantine,
On Sat, 18 Jul 2015 21:48:59 +0300, Constantine Shulyupin wrote:
I try to run vanilla kernel 4.2.0 on custom Armada-370 board, based on
DB-88F6710-BP.
The problem is that the board shuts down after writing to
MVNETA_TXQ_UPDATE_REG in this code:
What do you mean by shut down?
This is still ver far from acceptable. You aren't even talking to us when
we ask you questions and ask you to make changes, you just make another
improperly formatted submission of a bad patch all over again.
Your entire description is in your Subject line, and it insufficiently
describes your
I am seeing an issue with the reference count of time wait sockets which
leads to freeing of active timer object. This occurs in some data stress
test setups, so I am unable to determine the exact step when it occured.
However, I logged the refcount and was able to find out the code path
which
From: Joe Perches j...@perches.com
Date: Sat, 18 Jul 2015 11:06:26 -0700
As it's not fatal, naybe the sparc64 message should be
KERN_DEBUG/pr_debug.
It's not fatal insofar as it doesn't crash the system.
But performance wise is _IS_ fatal, and I want the kernel to bark
at the user so that
From: Scott Feldman sfel...@gmail.com
v3:
- Per Nicolas Dichtel review: remove errant empty union.
v2:
- Per davem review: in sk_buff, union fwd_mark with secmark to save space
since features appear to be mutually exclusive.
- Per Simon Horman review:
- fix grammar in switchdev.txt
From: Scott Feldman sfel...@gmail.com
Just before queuing skb for xmit on port, check if skb has been marked by
switchdev port driver as already fordwarded by device. If so, drop skb. A
non-zero skb-offload_fwd_mark field is set by the switchdev port
driver/device on ingress to indicate the skb
From: Scott Feldman sfel...@gmail.com
If device flags ingress packet as fwd offload, mark the
skb-offlaod_fwd_mark using the ingress port's dev-offlaod_fwd_mark. This
will be the hint to the kernel that this packet has already been forwarded
by device to egress ports matching
From: Scott Feldman sfel...@gmail.com
Signed-off-by: Scott Feldman sfel...@gmail.com
Acked-by: Jiri Pirko j...@resnulli.us
---
Documentation/networking/switchdev.txt | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/switchdev.txt
From: Scott Feldman sfel...@gmail.com
skb-offload_fwd_mark and dev-offload_fwd_mark are 32-bit and should be
unique for device and may even be unique for a sub-set of ports within
device, so add switchdev helper function to generate unique marks based on
port's switch ID and group_ifindex.
From: Scott Feldman sfel...@gmail.com
Signed-off-by: Scott Feldman sfel...@gmail.com
Acked-by: Jiri Pirko j...@resnulli.us
---
include/linux/netdevice.h |7 +++
net/switchdev/switchdev.c |8 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git
29 matches
Mail list logo
