> This fixes the error handling in the function bnxc2x_dbcx_params for both
> calls
> to bnx2x_dcbnl_update_applist by checking if they failed by returning a error
> code and if so return immediately to this function's caller due to this
> nonrecoverable internal failure.
Hi Nicholas,
Even assum
From: Joe Perches
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 they report the is
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 c
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 lead
From: Scott Feldman
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 skb->offlaod_fwd_mark.
For rocke
From: Scott Feldman
Signed-off-by: Scott Feldman
Acked-by: Jiri Pirko
---
Documentation/networking/switchdev.txt | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/switchdev.txt
b/Documentation/networking/switchdev.txt
index c5d7ade.
From: Scott Feldman
Signed-off-by: Scott Feldman
Acked-by: Jiri Pirko
---
include/linux/netdevice.h |7 +++
net/switchdev/switchdev.c |8 ++--
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8364f29..607
From: Scott Feldman
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 wrt fwd_mark
- re
From: Scott Feldman
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 has already been
From: Scott Feldman
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. group_ifindex would t
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 \
>flow
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 do
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,
On Fri, 2015-07-17 at 18:18 -0700, David Miller wrote:
> From: Joe Perches 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 messages, so re
Julian Anastasov 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 appears to
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 gatherin
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 fro
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 wrote:
>
> Thx for your looking into this!
>
>>
>> Thank you for the report, I will try to reproduce this locally
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 avail
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
>
> 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 et
Signed-off-by: Jakub Wilk
---
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 xfrm_add_pol_expi
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 wrote:
>>>
>>>
Changes to be committed:
modified: drivers/net/ethernet/realtek/r8169.c
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/
Changes to be committed:
modified: drivers/net/ethernet/realtek/r8169.c
Signed-off-by: Corcodel Marian
---
drivers/net/ethernet/realtek/r8169.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/
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 wrote:
>>
>> On Fri, 2015-07-17 at 21:18 +, 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 wrote:
>
> On Fri, 2015-07-17 at 21:18 +, Johan Schuijt wrote:
>> Hey guys,
>>
>>
>> We’re currently running into a repro
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 o
On Fri, 2015-07-17 at 17:27 -0700, Alex Gartrell wrote:
> On Fri, Jul 17, 2015 at 5:10 PM, Cong Wang 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;
> >
30 matches
Mail list logo
