on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

Hi, Sandeep Gopalpet

I am a developer. Now I confronted an interesting phenomena. When I used 
linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw and 
vlan packets on gfar-enet nic. But with e1000e nic, we can make vlan and 
raw packets work well. I looked into the source code and find that maybe 
it is related with hardware insert and remove vlan head. But I have no 
the specifications of gfar-enet nic. Would you like to give some 
document or some guides?

Thanks a lot.
Zhu Yanjun

The steps are as below.

1. I boot two freescale-p2020 boards with linux kernel 2.6.34.15, then I 
connected 2 gfar-enet nic cards with a direct network line;

2. On board 1, I checked the driver of eth0

ethtool -i eth0

driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A

On board 2, I checked the driver of eth1

ethtool -i eth1

driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A

3. Then I configure the ip address on the above 2 nic cards.

On board 1,

ifconfig eth0 192.168.1.13/24 up

On board 2,

ifconfig eth1 192.168.1.196/24 up

4. We can access the other board on one board.
For example, on board 1, we can ping board 2.

root@p2020rdb:/root> ping 192.168.1.196
PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms

5. We configure vlan on these 2 boards.
On board 1,

modprobe 8021q
vconfig add eth0 4091
ifconfig eth0.4091 10.1.1.13/24 up

On board 2,

modprobe 8021q
vconfig add eth1 4091
ifconfig eth1.4091 10.1.1.196/24 up

6. We can access the other board on one board through vlan.
For example, on board 1, we can ping board 2 through vlan nic.

root@p2020rdb:/root> ping 10.1.1.196
PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms

But we can not access the other board on one board through raw nic.
For example, on board, we can not ping board 2.

root@p2020rdb:/root> ping 192.168.1.196
 From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
 From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
 From 192.168.1.196 icmp_seq=3 Destination Host Unreachable

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

[-- Attachment #1: Type: text/plain, Size: 4932 bytes --]

Hi, Claudiu

Please help to review this patch. This patch is for kernel 2.6.x. Thanks 
a lot.

Hi, Willy

Please help to merge this patch to longterm: 2.6.32.61 since this 
problem also occurs on this kernel. Thanks a lot.

Based on kernel 2.6.x, gianfar nic driver can not work well. The root 
cause is that tx vlan of gianfar can not handle VLAN tag 0. So on kernel 
3.0+, this tx vlan feature is disabled. But on kernel 2.6.x, this 
feature is still enabled. This patch will disable this feature of 
gianfar nic driver. If this feature is enabled, gianfar nic can not 
support vlan packets and non-vlan packets at the same time. The 
following steps will reproduce this problem.

The steps are as below.

1. boot two freescale-p2020 boards with linux kernel 2.6.x, then 
connected 2 gfar-enet nic cards with a direct network line;

2. On board 1, checked the driver of eth0

ethtool -i eth0

driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A

On board 2, I checked the driver of eth1

ethtool -i eth1

driver: gfar-enet
version: 1.3
firmware-version: N/A
bus-info: N/A

3. Then configure the ip address on the above 2 nic cards.

On board 1,

ifconfig eth0 192.168.1.13/24 up

On board 2,

ifconfig eth1 192.168.1.196/24 up

4. We can access the other board on one board.
For example, on board 1, we can ping board 2.

root@p2020rdb:/root> ping 192.168.1.196
PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms

5. We configure vlan on these 2 boards. VLAN tag 0
On board 1,

modprobe 8021q
vconfig add eth0 4091
ifconfig eth0.4091 10.1.1.13/24 up

On board 2,

modprobe 8021q
vconfig add eth1 4091
ifconfig eth1.4091 10.1.1.196/24 up

6. We can access the other board on one board through vlan.
For example, on board 1, we can ping board 2 through vlan nic.

root@p2020rdb:/root> ping 10.1.1.196
PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms

But we can not access the other board on one board through raw nic.
For example, on board, we can not ping board 2.

root@p2020rdb:/root> ping 192.168.1.196
 From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
 From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
 From 192.168.1.196 icmp_seq=3 Destination Host Unreachable

Best Regards!
Zhu Yanjun

On 03/25/2014 01:08 PM, zhuyj wrote:
> Hi, Sandeep Gopalpet
>
> I am a developer. Now I confronted an interesting phenomena. When I 
> used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw 
> and vlan packets on gfar-enet nic. But with e1000e nic, we can make 
> vlan and raw packets work well. I looked into the source code and find 
> that maybe it is related with hardware insert and remove vlan head. 
> But I have no the specifications of gfar-enet nic. Would you like to 
> give some document or some guides?
>
> Thanks a lot.
> Zhu Yanjun
>
> The steps are as below.
>
> 1. I boot two freescale-p2020 boards with linux kernel 2.6.34.15, then 
> I connected 2 gfar-enet nic cards with a direct network line;
>
> 2. On board 1, I checked the driver of eth0
>
> ethtool -i eth0
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> On board 2, I checked the driver of eth1
>
> ethtool -i eth1
>
> driver: gfar-enet
> version: 1.3
> firmware-version: N/A
> bus-info: N/A
>
> 3. Then I configure the ip address on the above 2 nic cards.
>
> On board 1,
>
> ifconfig eth0 192.168.1.13/24 up
>
> On board 2,
>
> ifconfig eth1 192.168.1.196/24 up
>
> 4. We can access the other board on one board.
> For example, on board 1, we can ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> PING 192.168.1.196 (192.168.1.196) 56(84) bytes of data.
> 64 bytes from 192.168.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 192.168.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> 5. We configure vlan on these 2 boards. VLAN tag 0
> On board 1,
>
> modprobe 8021q
> vconfig add eth0 4091
> ifconfig eth0.4091 10.1.1.13/24 up
>
> On board 2,
>
> modprobe 8021q
> vconfig add eth1 4091
> ifconfig eth1.4091 10.1.1.196/24 up
>
> 6. We can access the other board on one board through vlan.
> For example, on board 1, we can ping board 2 through vlan nic.
>
> root@p2020rdb:/root> ping 10.1.1.196
> PING 10.1.1.196 (10.1.1.196) 56(84) bytes of data.
> 64 bytes from 10.1.1.196: icmp_req=1 ttl=64 time=2.92 ms
> 64 bytes from 10.1.1.196: icmp_req=2 ttl=64 time=0.096 ms
>
> But we can not access the other board on one board through raw nic.
> For example, on board, we can not ping board 2.
>
> root@p2020rdb:/root> ping 192.168.1.196
> From 192.168.1.196 icmp_seq=1 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=2 Destination Host Unreachable
> From 192.168.1.196 icmp_seq=3 Destination Host Unreachable
>
>


[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1491 bytes --]

>From afd48fa3ad5b15d519adeb19b2a9c00051327c68 Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x

Since there is something wrong with tx vlan of gianfar nic driver,
on kernel(3.0+), tx vlan is disabled. But on kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets.

Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
 drivers/net/gianfar.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
 	priv->vlgrp = NULL;
 
 	if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
-		dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+		dev->features |= NETIF_F_HW_VLAN_RX;
 
 	if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
 		priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
 	priv->vlgrp = grp;
 
 	if (grp) {
-		/* Enable VLAN tag insertion */
-		tempval = gfar_read(&priv->regs->tctrl);
-		tempval |= TCTRL_VLINS;
-
-		gfar_write(&priv->regs->tctrl, tempval);
-
 		/* Enable VLAN tag extraction */
 		tempval = gfar_read(&priv->regs->rctrl);
 		tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
-- 
1.7.9.5

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[Willy Tarreau]

Hi Zhu,

On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
> Hi, Claudiu
> 
> Please help to review this patch. This patch is for kernel 2.6.x. Thanks 
> a lot.
> 
> Hi, Willy
> 
> Please help to merge this patch to longterm: 2.6.32.61 since this 
> problem also occurs on this kernel. Thanks a lot.

Could you please send the reference to the equivalent mainline commit (the one
which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
2.6.32.62.

Thanks,
Willy

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy

I reference the following 2 mainline commits. These 2 commits are based 
on the current kernel 3.x and ethtool.
If we only backport these 2 commits on kernel 2.6.x, this problem will 
not be fixed yet.

Best Regards!
Zhu Yanjun

1. commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
Author: Jiri Pirko <jpirko@redhat.com>
Date:   Wed Jul 20 04:54:19 2011 +0000

     gianfar: do vlan cleanup

     - unify vlan and nonvlan rx path
     - kill priv->vlgrp and gfar_vlan_rx_register
     - allow to turn on/off rx/tx vlan accel via ethtool

     Signed-off-by: Jiri Pirko <jpirko@redhat.com>
     Signed-off-by: David S. Miller <davem@davemloft.net>

  drivers/net/gianfar.c |   55 
++++++++++++++++++++++++++-----------------------
  1 file changed, 29 insertions(+), 26 deletions(-)

2.commit b852b720877e6b8e12b95a7cb4e00ea351b8cbfc
Author: Sebastian Pöhn <sebastian.belden@googlemail.com>
Date:   Tue Jul 26 00:03:13 2011 +0000

     gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e

     commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e "gianfar: do vlan 
cleanup" has two issues:
     # permutation of rx and tx flags
     # enabling vlan tag insertion by default (this leads to unusable 
connections on some configurations)

     If VLAN insertion is requested (via ethtool) it will be set at an 
other point ...

     Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
     Signed-off-by: David S. Miller <davem@davemloft.net>

  drivers/net/gianfar.c |    6 +-----
  1 file changed, 1 insertion(+), 5 deletions(-)

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[Willy Tarreau]

Hi Zhu,

On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
> I reference the following 2 mainline commits. These 2 commits are based 
> on the current kernel 3.x and ethtool.
> If we only backport these 2 commits on kernel 2.6.x, this problem will 
> not be fixed yet.

OK fine, I just wanted that we keep the reference of these equivalent
patches in the commit message so that if later a newer patch changes
anything they did, at least we have some indications that the commit
might also have to be revisited.

I'll merge your patch and put these references there.

Thanks,
Willy

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On 04/03/2014 05:27 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
>> Hi, Claudiu
>>
>> Please help to review this patch. This patch is for kernel 2.6.x. Thanks
>> a lot.
>>
>> Hi, Willy
>>
>> Please help to merge this patch to longterm: 2.6.32.61 since this
>> problem also occurs on this kernel. Thanks a lot.
> Could you please send the reference to the equivalent mainline commit (the one
> which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
> 2.6.32.62.
>
> Thanks,
> Willy
>
>
Hi, Willy

I made a new patch. In long commit message, I inserted the equivalent 
mainline commit
about this feature. Maybe it is better. Now this patch is in the 
attachment. Please check
and merge it into kernel 2.6.32.62.

Thanks a lot.
Zhu Yanjun


[-- Attachment #2: 0001-gianfar-disable-TX-vlan-based-on-kernel-2.6.x.patch --]
[-- Type: text/x-patch, Size: 1688 bytes --]

>From 3b74ad6134f8eccce9ee391fb02ff15863630c1b Mon Sep 17 00:00:00 2001
From: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x

2.6.x kernels require a similar logic change as commit e1653c3e
[gianfar: do vlan cleanup] and commit 51b8cbfc
[gianfar: fix bug caused by e1653c3e] introduces for newer kernels.

Since there is something wrong with tx vlan of gianfar nic driver,
in kernel(3.1+), tx vlan is disabled. But in kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets at the same time.

Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
---
 drivers/net/gianfar.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
 	priv->vlgrp = NULL;
 
 	if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
-		dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+		dev->features |= NETIF_F_HW_VLAN_RX;
 
 	if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
 		priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
 	priv->vlgrp = grp;
 
 	if (grp) {
-		/* Enable VLAN tag insertion */
-		tempval = gfar_read(&priv->regs->tctrl);
-		tempval |= TCTRL_VLINS;
-
-		gfar_write(&priv->regs->tctrl, tempval);
-
 		/* Enable VLAN tag extraction */
 		tempval = gfar_read(&priv->regs->rctrl);
 		tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
-- 
1.7.9.5

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

On 04/03/2014 06:01 PM, Willy Tarreau wrote:
> Hi Zhu,
>
> On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
>> I reference the following 2 mainline commits. These 2 commits are based
>> on the current kernel 3.x and ethtool.
>> If we only backport these 2 commits on kernel 2.6.x, this problem will
>> not be fixed yet.
> OK fine, I just wanted that we keep the reference of these equivalent
> patches in the commit message so that if later a newer patch changes
> anything they did, at least we have some indications that the commit
> might also have to be revisited.
>
> I'll merge your patch and put these references there.
>
> Thanks,
> Willy
OK. Thanks a lot.

Zhu Yanjun
> .
>

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[Willy Tarreau]

On Thu, Apr 03, 2014 at 06:15:25PM +0800, zhuyj wrote:
> Hi, Willy
> 
> I made a new patch. In long commit message, I inserted the equivalent 
> mainline commit
> about this feature. Maybe it is better. Now this patch is in the 
> attachment. Please check
> and merge it into kernel 2.6.32.62.

Sure, it's much better this way.

Thanks!
Willy