2.6.37 regression: adding main interface to a bridge breaks vlan interface RX

[    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
[    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3

I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.

If I remove eth0 from the bridge, eth0.3840 starts working again. It
still works if eth0.3840 is part of a bridge but eth0 isn't (the device
is in promiscuous mode). I've only tested with broadcast traffic.

This works with 2.6.36.

git bisect produces 3701e51382a026cba10c60b03efabe534fba4ca4 as the
first bad commit.

The behaviour of drivers/net/forcedeth.c nv_rx_process_optimized looks
ok - vlan_gro_receive and napi_gro_receive are called correctly. (The
likely(!np->vlangrp) looks odd as it'll always be false if vlans are in
use).

-- 
Simon Arlott

On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:

[    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
[    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3

I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.

[...]

This means the behaviour is now consistent, whether or not hardware VLAN
tag stripping is enabled.  (I previously pointed out the inconsistent
behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
would consider this an improvement.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

On 17/01/11 16:00, Ben Hutchings wrote:

On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:

quoted

[    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
[    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3

I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.

[...]

This means the behaviour is now consistent, whether or not hardware VLAN
tag stripping is enabled.  (I previously pointed out the inconsistent
behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
would consider this an improvement.

Shouldn't the kernel also prevent a device from being both part of a
bridge and having VLANs? Instead everything appears to work except
incoming traffic.

-- 
Simon Arlott

On Mon, Jan 17, 2011 at 10:17 AM, Simon Arlott [off-list ref] wrote:

On 17/01/11 16:00, Ben Hutchings wrote:

quoted

On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:

quoted

[    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec
[    1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3

I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.

[...]

This means the behaviour is now consistent, whether or not hardware VLAN
tag stripping is enabled.  (I previously pointed out the inconsistent
behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.)  I
would consider this an improvement.

Shouldn't the kernel also prevent a device from being both part of a
bridge and having VLANs? Instead everything appears to work except
incoming traffic.

It might make sense, although you have similar effects with non-vlan
traffic to the device as well.  You could make the same argument that
we shouldn't allow IP addresses, etc. to be assigned to bridged
devices.  There are also other components that use the bridge hooks
that would need to be checked.  All this starts to get a bit messy.

I created a Bugzilla entry at 
https://bugzilla.kernel.org/show_bug.cgi?id=27432
for your bug report, please add your address to the CC list in there, thanks!

On niedziela, 16 stycznia 2011 o 15:09:32 Simon Arlott wrote:

[    1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16,
addr 00:e0:81:4d:2b:ec [    1.666767] forcedeth 0000:00:08.0: highdma csum
vlan pwrctl mgmt gbit lnktim msi desc-v3

I have eth0 and eth0.3840 which works until I add eth0 to a bridge.
While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable
to receive packets. Using tcpdump on eth0 shows the packets being
received with a VLAN tag but they don't appear on eth0.3840. They appear
with the VLAN tag on the bridge interface.

If I remove eth0 from the bridge, eth0.3840 starts working again. It
still works if eth0.3840 is part of a bridge but eth0 isn't (the device
is in promiscuous mode). I've only tested with broadcast traffic.

This works with 2.6.36.

git bisect produces 3701e51382a026cba10c60b03efabe534fba4ca4 as the
first bad commit.

The behaviour of drivers/net/forcedeth.c nv_rx_process_optimized looks
ok - vlan_gro_receive and napi_gro_receive are called correctly. (The
likely(!np->vlangrp) looks odd as it'll always be false if vlans are in
use).

-- 
Maciej Rutecki
http://www.maciek.unixy.pl

On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki
[off-list ref] wrote:

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=27432
for your bug report, please add your address to the CC list in there, thanks!

This isn't a bug - the change resolved behavior that varied depending
on what NIC was in use.

On niedziela, 23 stycznia 2011 o 22:29:02 Jesse Gross wrote:

On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki

[off-list ref] wrote:

quoted

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=27432
for your bug report, please add your address to the CC list in there,
thanks!

This isn't a bug - the change resolved behavior that varied depending
on what NIC was in use.

Thanks for the update. Closing.

Regards
-- 
Maciej Rutecki
http://www.maciek.unixy.pl

Maciej Rutecki <maciej.rutecki <at> gmail.com> writes:

On niedziela, 23 stycznia 2011 o 22:29:02 Jesse Gross wrote:

quoted

On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki

<maciej.rutecki <at> gmail.com> wrote:

quoted

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=27432
for your bug report, please add your address to the CC list in there,
thanks!

This isn't a bug - the change resolved behavior that varied depending
on what NIC was in use.

Thanks for the update. Closing.

Regards

Hi

How am i supposed to put my eth to a bridge and have a seprate vlan besides that
bridge?

regards

On Sat, Feb 5, 2011 at 7:34 AM, chriss [off-list ref] wrote:

Maciej Rutecki <maciej.rutecki <at> gmail.com> writes:

quoted

On niedziela, 23 stycznia 2011 o 22:29:02 Jesse Gross wrote:

quoted

On Sun, Jan 23, 2011 at 9:45 AM, Maciej Rutecki

<maciej.rutecki <at> gmail.com> wrote:

quoted

I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=27432
for your bug report, please add your address to the CC list in there,
thanks!

This isn't a bug - the change resolved behavior that varied depending
on what NIC was in use.

Thanks for the update. Closing.

Regards

Hi

How am i supposed to put my eth to a bridge and have a seprate vlan besides that
bridge?

You should either attached a bridge to a vlan device or stack a vlan
device on the bridge port depending on what you are trying to achieve.

The bridge handler takes all packets of the device that it is attached
to, so having a vlan also attached to the same device will not work.
You may get different results on older kernels depending on what NIC
you were using but that was a bug.

Jesse Gross <jesse <at> nicira.com> writes:

You should either attached a bridge to a vlan device or stack a vlan
device on the bridge port depending on what you are trying to achieve.

The bridge handler takes all packets of the device that it is attached
to, so having a vlan also attached to the same device will not work.
You may get different results on older kernels depending on what NIC
you were using but that was a bug.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi and thanks for your reply

I tried that.

I had under 2.6.36.3 following combination:

eth1 in br0 -> all traffic without vlan id
eth1.3 -> traffic with vlan 3

with 2.6.37 i should do the following
eth1 in br0 -> traffic w/o vlans
and br0.3 -> traffic with vlan id 3

But still there is no rx for vlan 3.
Any suggestions? Or am i missing something?


regards

Le 06/02/2011 20:37, chriss a écrit :

Jesse Gross<jesse<at>  nicira.com>  writes:

quoted

You should either attached a bridge to a vlan device or stack a vlan
device on the bridge port depending on what you are trying to achieve.

The bridge handler takes all packets of the device that it is attached
to, so having a vlan also attached to the same device will not work.
You may get different results on older kernels depending on what NIC
you were using but that was a bug.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo<at>  vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi and thanks for your reply

I tried that.

I had under 2.6.36.3 following combination:

eth1 in br0 ->  all traffic without vlan id
eth1.3 ->  traffic with vlan 3

with 2.6.37 i should do the following
eth1 in br0 ->  traffic w/o vlans
and br0.3 ->  traffic with vlan id 3

But still there is no rx for vlan 3.
Any suggestions? Or am i missing something?

I think you should have a look at ebtables command, in particular, the BROUTING chain of broute table. If this chain ask the packet to be dropped, then bridge will ignore it and give a chance to the upper layer to use it. Upper layer might be IP, or in your particular setup, VLAN.

HTH,

	Nicolas.



In order for eth1.3 to receive the traffic with VLANID=3, while having the bridge get everything else, you should add an entry to the

On Sun, Feb 6, 2011 at 11:37 AM, chriss [off-list ref] wrote:

Jesse Gross <jesse <at> nicira.com> writes:

quoted

You should either attached a bridge to a vlan device or stack a vlan
device on the bridge port depending on what you are trying to achieve.

The bridge handler takes all packets of the device that it is attached
to, so having a vlan also attached to the same device will not work.
You may get different results on older kernels depending on what NIC
you were using but that was a bug.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi and thanks for your reply

I tried that.

I had under 2.6.36.3 following combination:

eth1 in br0 -> all traffic without vlan id
eth1.3 -> traffic with vlan 3

with 2.6.37 i should do the following
eth1 in br0 -> traffic w/o vlans
and br0.3 -> traffic with vlan id 3

But still there is no rx for vlan 3.
Any suggestions? Or am i missing something?

That configuration should work (and I've tested it in the past).  I
would try running tcpdump on the various interfaces in the path (eth1,
br0, br0.3) to see where traffic is flowing or not.

Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:

I think you should have a look at ebtables command, in particular, the

BROUTING chain of broute 

table. If this chain ask the packet to be dropped, then bridge will ignore it

and give a chance to 

the upper layer to use it. Upper layer might be IP, or in your particular

setup, VLAN.

HTH,

	Nicolas.

Thank you very much for the ebtables hint.

I also tried to add the vlan to my bridge device but only droping the vlan
tagged paket with ebtables got it working.

I'm not sure if this is the wanted behavior for bridging vlan actions.
..or my network setup is just to ..f%%%'ed up?!

Thanks nicolas

regards//chriss

On Mon, Feb 14, 2011 at 5:22 AM, chriss [off-list ref] wrote:

Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:

quoted

I think you should have a look at ebtables command, in particular, the

BROUTING chain of broute

quoted

table. If this chain ask the packet to be dropped, then bridge will ignore it

and give a chance to

quoted

the upper layer to use it. Upper layer might be IP, or in your particular

setup, VLAN.

quoted

HTH,

      Nicolas.

Thank you very much for the ebtables hint.

I also tried to add the vlan to my bridge device but only droping the vlan
tagged paket with ebtables got it working.

I'm not sure if this is the wanted behavior for bridging vlan actions.
..or my network setup is just to ..f%%%'ed up?!

It should work even without ebtables (running vlan on top of bridge,
not side by side).  I'll try to look at this in the next couple of
days.

On Mon, Feb 14, 2011 at 5:22 AM, chriss [off-list ref] wrote:

Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:

quoted

I think you should have a look at ebtables command, in particular, the

BROUTING chain of broute

quoted

table. If this chain ask the packet to be dropped, then bridge will ignore it

and give a chance to

quoted

the upper layer to use it. Upper layer might be IP, or in your particular

setup, VLAN.

quoted

HTH,

      Nicolas.

Thank you very much for the ebtables hint.

I also tried to add the vlan to my bridge device but only droping the vlan
tagged paket with ebtables got it working.

I'm not sure if this is the wanted behavior for bridging vlan actions.
..or my network setup is just to ..f%%%'ed up?!

What driver is in use with the NIC you are seeing this on?

Jesse Gross <jesse <at> nicira.com> writes:

What driver is in use with the NIC you are seeing this on?

He there

the device in question is (as lspci told)
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit
Ethernet (rev 10)

handled by kernel module r8169.

I also tried to set up the vlan on the bridge. like br0.3. but that did not work.

regards//chriss

On Fri, Feb 25, 2011 at 4:16 PM, chriss [off-list ref] wrote:

Jesse Gross <jesse <at> nicira.com> writes:

quoted

What driver is in use with the NIC you are seeing this on?

He there

the device in question is (as lspci told)
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit
Ethernet (rev 10)

handled by kernel module r8169.

I'm guessing that you're hitting the special case in this code in
r8169.c:rtl8169_vlan_rx_register():

         /*
          * Do not disable RxVlan on 8110SCd.
          */
         if (tp->vlgrp || (tp->mac_version == RTL_GIGA_MAC_VER_05))
                 tp->cp_cmd |= RxVlan;
         else
                 tp->cp_cmd &= ~RxVlan;

Since before you were getting the vlans directly off the device there
was a vlan group configured.  However, now that the packets are going
through the bridge, the group is not being configured on the device
and the tag gets dropped.  Assuming that this is the case, the
solution is to convert the driver to use the new vlan model, which
does not require knowledge of the vlan group.

Can you confirm this by running tcpdump -eni br0?  I would expect that
you see the correct packets but without vlan tags.

Jesse Gross <jesse <at> nicira.com> writes:

Can you confirm this by running tcpdump -eni br0?  I would expect that
you see the correct packets but without vlan tags.

Thats correct. i see the packets in br0 without tags and tagged in eth1. thats
why i added the brouting rule in ebtables to drop it at eth1 and the it apears
in eth1.3 (untagged)...

On Sat, Feb 26, 2011 at 3:51 AM, chriss [off-list ref] wrote:

Jesse Gross <jesse <at> nicira.com> writes:

quoted

Can you confirm this by running tcpdump -eni br0?  I would expect that
you see the correct packets but without vlan tags.

Thats correct. i see the packets in br0 without tags and tagged in eth1. thats
why i added the brouting rule in ebtables to drop it at eth1 and the it apears
in eth1.3 (untagged)...

Putting a vlan device on eth1 actually affects the behavior of the
driver, which is why that works.  I suspect that if you put the vlan
device on both the physical interface and the bridge you would see
packets with tags on the bridge.

Regardless, the solution is to remove the dependency on vlan devices
by converting over to the new vlan model.  Francois, any chance that
you might have some time to look at this?

Jesse Gross [off-list ref] :
[...]

Putting a vlan device on eth1 actually affects the behavior of the
driver, which is why that works.  I suspect that if you put the vlan
device on both the physical interface and the bridge you would see
packets with tags on the bridge.

Regardless, the solution is to remove the dependency on vlan devices
by converting over to the new vlan model.  Francois, any chance that
you might have some time to look at this?

The completely untested patch below is available for the (really) desperate
souls.

I should do a -next testing session this afternoon for this patch + 
Oliver's Neukum advertisement control + Hayes 8105e stuff (in reverse order).

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0382332..8e7da78 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig

@@ -2235,15 +2235,6 @@ config R8169
 	  To compile this driver as a module, choose M here: the module
 	  will be called r8169.  This is recommended.
 
-config R8169_VLAN
-	bool "VLAN support"
-	depends on R8169 && VLAN_8021Q
-	---help---
-	  Say Y here for the r8169 driver to support the functions required
-	  by the kernel 802.1Q code.
-
-	  If in doubt, say Y.
-
 config SB1250_MAC
 	tristate "SB1250 Gigabit Ethernet support"
 	depends on SIBYTE_SB1xxx_SOC

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index bde7d61..5c4f03d 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c

@@ -526,9 +526,6 @@ struct rtl8169_private {
 	u16 napi_event;
 	u16 intr_mask;
 	int phy_1000_ctrl_reg;
-#ifdef CONFIG_R8169_VLAN
-	struct vlan_group *vlgrp;
-#endif
 
 	struct mdio_ops {
 		void (*write)(void __iomem *, int, int);

@@ -1254,8 +1251,6 @@ static int rtl8169_set_rx_csum(struct net_device *dev, u32 data)
 	return 0;
 }
 
-#ifdef CONFIG_R8169_VLAN
-
 static inline u32 rtl8169_tx_vlan_tag(struct rtl8169_private *tp,
 				      struct sk_buff *skb)
 {

@@ -1263,64 +1258,37 @@ static inline u32 rtl8169_tx_vlan_tag(struct rtl8169_private *tp,
 		TxVlanTag | swab16(vlan_tx_tag_get(skb)) : 0x00;
 }
 
-static void rtl8169_vlan_rx_register(struct net_device *dev,
-				     struct vlan_group *grp)
+#define NETIF_F_HW_VLAN_TX_RX	(NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX)
+
+static void rtl8169_vlan_mode(struct net_device *dev)
 {
 	struct rtl8169_private *tp = netdev_priv(dev);
 	void __iomem *ioaddr = tp->mmio_addr;
 	unsigned long flags;
 
 	spin_lock_irqsave(&tp->lock, flags);
-	tp->vlgrp = grp;
-	/*
-	 * Do not disable RxVlan on 8110SCd.
-	 */
-	if (tp->vlgrp || (tp->mac_version == RTL_GIGA_MAC_VER_05))
+	if (dev->features & NETIF_F_HW_VLAN_RX)
 		tp->cp_cmd |= RxVlan;
 	else
 		tp->cp_cmd &= ~RxVlan;
 	RTL_W16(CPlusCmd, tp->cp_cmd);
+	/* PCI commit */
 	RTL_R16(CPlusCmd);
 	spin_unlock_irqrestore(&tp->lock, flags);
+
+	dev->vlan_features = dev->features &~ NETIF_F_HW_VLAN_TX_RX;
 }
 
-static int rtl8169_rx_vlan_skb(struct rtl8169_private *tp, struct RxDesc *desc,
-			       struct sk_buff *skb, int polling)
+static void rtl8169_rx_vlan_tag(struct RxDesc *desc, struct sk_buff *skb)
 {
 	u32 opts2 = le32_to_cpu(desc->opts2);
-	struct vlan_group *vlgrp = tp->vlgrp;
-	int ret;
 
-	if (vlgrp && (opts2 & RxVlanTag)) {
-		u16 vtag = swab16(opts2 & 0xffff);
+	if (opts2 & RxVlanTag)
+		__vlan_hwaccel_put_tag(skb, swab16(opts2 & 0xffff));
 
-		if (likely(polling))
-			vlan_gro_receive(&tp->napi, vlgrp, vtag, skb);
-		else
-			__vlan_hwaccel_rx(skb, vlgrp, vtag, polling);
-		ret = 0;
-	} else
-		ret = -1;
 	desc->opts2 = 0;
-	return ret;
-}
-
-#else /* !CONFIG_R8169_VLAN */
-
-static inline u32 rtl8169_tx_vlan_tag(struct rtl8169_private *tp,
-				      struct sk_buff *skb)
-{
-	return 0;
-}
-
-static int rtl8169_rx_vlan_skb(struct rtl8169_private *tp, struct RxDesc *desc,
-			       struct sk_buff *skb, int polling)
-{
-	return -1;
 }
 
-#endif
-
 static int rtl8169_gset_tbi(struct net_device *dev, struct ethtool_cmd *cmd)
 {
 	struct rtl8169_private *tp = netdev_priv(dev);

@@ -1491,6 +1459,28 @@ static void rtl8169_get_strings(struct net_device *dev, u32 stringset, u8 *data)
 	}
 }
 
+static int rtl8169_set_flags(struct net_device *dev, u32 data)
+{
+	struct rtl8169_private *tp = netdev_priv(dev);
+	unsigned long old_feat = dev->features;
+	int rc;
+
+	if ((tp->mac_version == RTL_GIGA_MAC_VER_05) &&
+	    !(data & ETH_FLAG_RXVLAN)) {
+		netif_info(tp, drv, dev, "8110SCd requires hardware Rx VLAN\n");
+		return -EINVAL;
+	}
+
+	rc = ethtool_op_set_flags(dev, data, ETH_FLAG_TXVLAN | ETH_FLAG_RXVLAN);
+	if (rc)
+		return rc;
+
+	if ((old_feat ^ dev->features) & NETIF_F_HW_VLAN_RX)
+		rtl8169_vlan_mode(dev);
+
+	return 0;
+}
+
 static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.get_drvinfo		= rtl8169_get_drvinfo,
 	.get_regs_len		= rtl8169_get_regs_len,

@@ -1510,6 +1500,8 @@ static const struct ethtool_ops rtl8169_ethtool_ops = {
 	.get_strings		= rtl8169_get_strings,
 	.get_sset_count		= rtl8169_get_sset_count,
 	.get_ethtool_stats	= rtl8169_get_ethtool_stats,
+	.set_flags		= rtl8169_set_flags,
+	.get_flags		= ethtool_op_get_flags,
 };
 
 static void rtl8169_get_mac_version(struct rtl8169_private *tp,

@@ -2792,9 +2784,6 @@ static const struct net_device_ops rtl8169_netdev_ops = {
 	.ndo_set_mac_address	= rtl_set_mac_address,
 	.ndo_do_ioctl		= rtl8169_ioctl,
 	.ndo_set_multicast_list	= rtl_set_rx_mode,
-#ifdef CONFIG_R8169_VLAN
-	.ndo_vlan_rx_register	= rtl8169_vlan_rx_register,
-#endif
 #ifdef CONFIG_NET_POLL_CONTROLLER
 	.ndo_poll_controller	= rtl8169_netpoll,
 #endif

@@ -3086,6 +3075,13 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	/* Identify chip attached to board */
 	rtl8169_get_mac_version(tp, ioaddr);
 
+	/*
+	 * Pretend we are using VLANs; This bypasses a nasty bug where
+	 * Interrupts stop flowing on high load on 8110SCd controllers.
+	 */
+	if (tp->mac_version == RTL_GIGA_MAC_VER_05)
+		tp->cp_cmd |= RxVlan;
+
 	rtl_init_mdio_ops(tp);
 	rtl_init_pll_power_ops(tp);
 

@@ -3154,10 +3150,7 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 	netif_napi_add(dev, &tp->napi, rtl8169_poll, R8169_NAPI_WEIGHT);
 
-#ifdef CONFIG_R8169_VLAN
-	dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
-#endif
-	dev->features |= NETIF_F_GRO;
+	dev->features |= NETIF_F_HW_VLAN_TX_RX | NETIF_F_GRO;
 
 	tp->intr_mask = 0xffff;
 	tp->hw_start = cfg->hw_start;

@@ -3273,12 +3266,7 @@ static int rtl8169_open(struct net_device *dev)
 
 	rtl8169_init_phy(dev, tp);
 
-	/*
-	 * Pretend we are using VLANs; This bypasses a nasty bug where
-	 * Interrupts stop flowing on high load on 8110SCd controllers.
-	 */
-	if (tp->mac_version == RTL_GIGA_MAC_VER_05)
-		RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) | RxVlan);
+	rtl8169_vlan_mode(dev);
 
 	rtl_pll_power_up(tp);
 

@@ -4589,12 +4577,12 @@ static int rtl8169_rx_interrupt(struct net_device *dev,
 			skb_put(skb, pkt_size);
 			skb->protocol = eth_type_trans(skb, dev);
 
-			if (rtl8169_rx_vlan_skb(tp, desc, skb, polling) < 0) {
-				if (likely(polling))
-					napi_gro_receive(&tp->napi, skb);
-				else
-					netif_rx(skb);
-			}
+			rtl8169_rx_vlan_tag(desc, skb);
+
+			if (likely(polling))
+				napi_gro_receive(&tp->napi, skb);
+			else
+				netif_rx(skb);
 
 			dev->stats.rx_bytes += pkt_size;
 			dev->stats.rx_packets++;

On Tue, Mar 1, 2011 at 2:16 AM, Francois Romieu [off-list ref] wrote:

Jesse Gross [off-list ref] :
[...]

quoted

Putting a vlan device on eth1 actually affects the behavior of the
driver, which is why that works.  I suspect that if you put the vlan
device on both the physical interface and the bridge you would see
packets with tags on the bridge.

Regardless, the solution is to remove the dependency on vlan devices
by converting over to the new vlan model.  Francois, any chance that
you might have some time to look at this?

The completely untested patch below is available for the (really) desperate
souls.

I should do a -next testing session this afternoon for this patch +
Oliver's Neukum advertisement control + Hayes 8105e stuff (in reverse order).

Thanks Francois.  When you are ready this looks good to me.

Reviewed-by: Jesse Gross <redacted>

Francois Romieu [off-list ref] :

Jesse Gross [off-list ref] :
[...]

quoted

Regardless, the solution is to remove the dependency on vlan devices
by converting over to the new vlan model.  Francois, any chance that
you might have some time to look at this?

The completely untested patch below is available for the (really) desperate
souls.

I should do a -next testing session this afternoon for this patch + 
Oliver's Neukum advertisement control + Hayes 8105e stuff (in reverse order).

It took a bit longer than expected but the patch seems to work.

Chriss, can you give it a try against current -rc / -git and see if it makes
a difference ?

-- 
Ueimor

Francois Romieu <romieu <at> fr.zoreil.com> writes:

Chriss, can you give it a try against current -rc / -git and see if it makes
a difference ?

I hope i'm doing it right. i checked out the
'git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git'

and will try to apply the patch you provided. please correct me if i'm wrong.
I will report back.

regards//chriss

chriss [off-list ref] :
[...]

I hope i'm doing it right. i checked out the
'git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git'

and will try to apply the patch you provided. please correct me if i'm wrong.
I will report back.

I have tested it against davem's -next somewhere along -rc5 but it should be
fine as well.

-- 
Ueimor

Francois Romieu <romieu <at> fr.zoreil.com> writes:

chriss <mail_to_chriss <at> gmx.net> :
[...]

quoted

I hope i'm doing it right. i checked out the
'git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git'

and will try to apply the patch you provided. please correct me if i'm wrong.
I will report back.

I have tested it against davem's -next somewhere along -rc5 but it should be
fine as well.

My hat gows of to you kindly sir! Everything works as expected. im looking
forward to see this patch in the stable releases.

thank you very much
//chriss