.
NETIF_F_HW_VLAN_STAG_RX check was added and the strip action is now
dependent on the correct combination of features and the detected vlan tag.
NETIF_F_HW_VLAN_STAG_RX feature was added to be in line with the driver
actual abilities.
Signed-off-by: Elad Nachman
---
drivers/net/ethernet/stmicro/stmmac
.
NETIF_F_HW_VLAN_CTAG_RX check was removed and instead the strip action
is dependent upon a preprocessor define which is defined when 802.1Q
support is selected in the kernel config.
NETIF_F_HW_VLAN_STAG_RX feature was added to be in line with the driver
actual abilities.
Signed-off-by: Elad Nachman
kicks in only once you enable 802.1Q support in the
kernel .config .
Thanks,
Elad.
On 30/05/18 09:08, Toshiaki Makita wrote:
> On 2018/05/30 14:48, Elad Nachman wrote:
>> stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
>> calling napi_gro_receive().
>
.
NETIF_F_HW_VLAN_CTAG_RX check was removed and NETIF_F_HW_VLAN_STAG_RX feature
was added to be in line with the driver actual abilities.
Signed-off-by: Elad Nachman
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers
.
NETIF_F_HW_VLAN_CTAG_RX check was removed to be in line with the driver actual
abilities.
Signed-off-by: Elad Nachman <el...@gilat.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/
.
NETIF_F_HW_VLAN_STAG_RX was added to the net device features to reflect this
new support.
Signed-off-by: Elad Nachman <el...@gilat.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/
Jose,
I am not sure which drivers you have checked. I guess most non-networking
embedded drivers never use 802.1AD
so they stay broken unknowingly.
Specifically, I have tested Intel e1000e based card which works correctly
versus stmmac which works incorrectly.
If you check netdev.c in e1000e
by skb_vlan_untag() .
Signed-off-by: Elad Nachman <el...@gilat.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/
5/18 09:43, Toshiaki Makita wrote:
> On 2018/05/08 15:01, Elad Nachman wrote:
>> stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
>> calling napi_gro_receive().
>>
>> The function assumes VLAN tagged frames are always tagged with 802.1Q
>> prot
-by: Elad Nachman <el...@gilat.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b65e2d1..ced2d34
-by: Elad Nachman <el...@gilat.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index b65e2d1..ced2d34
-by: Elad Nachman <el...@gilat.com>
---
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:04:00.586057300 +0300
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:05:33.601992400 +0300
@@ -3293,17 +3293,19 @@ dma_map_err:
static void stmmac_rx_vlan(
-off-by: Elad Nachman <el...@gilat.com>
---
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:04:00.586057300 +0300
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 2018-04-11
17:05:33.601992400 +0300
@@ -3293,17 +3293,19 @@ dma_map_err:
stati
-by: Elad Nachman <el...@gilat.com>
---
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11
17:04:00.586057300 +0300
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11
17:05:33.601992400 +0300
@@ -3293,17 +3293,19 @@ dma_map_err:
static void stmmac_rx_vlan(
2017 21:06
To: Elad Nachman <el...@gilat.com>
Cc: netdev@vger.kernel.org
Subject: Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus
syscall endless loop
From: Elad Nachman <el...@gilat.com>
Date: Tue, 17 Jan 2017 18:15:19 +
> Any thought about limiting the
...@davemloft.net]
Sent: יום ג 17 ינואר 2017 19:58
To: Elad Nachman <el...@gilat.com>
Cc: netdev@vger.kernel.org
Subject: Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus
syscall endless loop
From: Elad Nachman <el...@gilat.com>
Date: Tue, 17 Jan 2017 17:39:03 +
>
Hi,
I am experiencing sporadic work queue lockups on kernel 4.6.7-rt14
(mach-socfpga).
Using a HW debugger I got the following information:
A process containing a network namespace is terminating itself (SIGKILL), which
causes cleanup_net() to be scheduled to kworker/u4:2 to clean up the
17 matches
Mail list logo
