From: Russell King <hidden> Date: 2016-01-23 10:51:22
Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del
ops"), the Marvell 88E6xxx switch has been unable to pass traffic
between ports - any received traffic is discarded by the switch.
Taking a port out of bridge mode and configuring a vlan on it also the
port to start passing traffic.
With the debugfs files re-instated to allow debug of this issue by
comparing the register settings between the working and non-working
case, the reason becomes clear:
GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6
- 7: 1111 707f 2001 2 2 2 2 2 0 2
+ 7: 1111 707f 2001 1 1 1 1 1 0 1
Register 7 for the ports is the default vlan tag register, and in the
non-working setup, it has been set to 2, despite vlan 2 not being
configured. This causes the switch to drop all packets coming in to
these ports. The working setup has the default vlan tag register set
to 1, which is the default vlan when none is configured.
Inspection of the code reveals why. The code prior to this commit
was:
- for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
- if (!err && vlan->flags & BRIDGE_VLAN_INFO_PVID)
- err = ds->drv->port_pvid_set(ds, p->port, vid);
but the new code is:
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
+ }
...
+ if (pvid)
+ err = _mv88e6xxx_port_pvid_set(ds, port, vid);
This causes the new code to always set the default vlan to one higher
than the old code.
Fix this.
Fixes: 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops")
Cc: <redacted>
Signed-off-by: Russell King <redacted>
---
As this is a regression on 4.4 compared to 4.3, I've added the stable
tag.
drivers/net/dsa/mv88e6xxx.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
@@ -1515,11 +1515,12 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,err=_mv88e6xxx_port_vlan_add(ds,port,vid,untagged);if(err)gotounlock;++/* no PVID with ranges, otherwise it's a bug */+if(pvid)+err=_mv88e6xxx_port_pvid_set(ds,port,vid);}-/* no PVID with ranges, otherwise it's a bug */-if(pvid)-err=_mv88e6xxx_port_pvid_set(ds,port,vid);unlock:mutex_unlock(&ps->smi_mutex);
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-01-23 18:15:35
On Sat, Jan 23, 2016 at 10:51:16AM +0000, Russell King wrote:
Since commit 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del
ops"), the Marvell 88E6xxx switch has been unable to pass traffic
between ports - any received traffic is discarded by the switch.
Taking a port out of bridge mode and configuring a vlan on it also the
port to start passing traffic.
With the debugfs files re-instated to allow debug of this issue by
comparing the register settings between the working and non-working
case, the reason becomes clear:
GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6
- 7: 1111 707f 2001 2 2 2 2 2 0 2
+ 7: 1111 707f 2001 1 1 1 1 1 0 1
Register 7 for the ports is the default vlan tag register, and in the
non-working setup, it has been set to 2, despite vlan 2 not being
configured. This causes the switch to drop all packets coming in to
these ports. The working setup has the default vlan tag register set
to 1, which is the default vlan when none is configured.
Inspection of the code reveals why. The code prior to this commit
was:
- for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
- if (!err && vlan->flags & BRIDGE_VLAN_INFO_PVID)
- err = ds->drv->port_pvid_set(ds, p->port, vid);
but the new code is:
+ for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
...
+ }
...
+ if (pvid)
+ err = _mv88e6xxx_port_pvid_set(ds, port, vid);
This causes the new code to always set the default vlan to one higher
than the old code.
Fix this.
Fixes: 76e398a62712 ("net: dsa: use switchdev obj for VLAN add/del ops")
Cc: <redacted>
Signed-off-by: Russell King <redacted>
Hi Russell
Thanks for digging into this.
I think this is a step towards a solution, but does not solve all the
problems.
e.g. I have a switch interface lan0 with the IP address
192.168.10.2. I can ping this address from another host. I then take
the IP address off the interface, create a br0 device, add lan0 to the
bridge, and put 192.168.10.2 onto the bridge. I should be able to then
ping the address. But it does not work.
Andrew
From: Russell King - ARM Linux <hidden> Date: 2016-01-23 19:06:29
On Sat, Jan 23, 2016 at 07:15:26PM +0100, Andrew Lunn wrote:
Thanks for digging into this.
I hope you saw v2, which is functionally identical.
I think this is a step towards a solution, but does not solve all the
problems.
e.g. I have a switch interface lan0 with the IP address
192.168.10.2. I can ping this address from another host. I then take
the IP address off the interface, create a br0 device, add lan0 to the
bridge, and put 192.168.10.2 onto the bridge. I should be able to then
ping the address. But it does not work.
That works for me. Maybe it's differences in the switch device? I
seem to remember you said your switch was an older generation than
mine (88E6176).
root@clearfog:~# brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.005043020202 no lan1
lan2
lan3
lan4
lan5
lan6
root@clearfog:~# ip addr show|grep 192.168.254
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.648 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.648/0.648/0.648/0.000 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev br0
root@clearfog:~# brctl delif br0 lan1
root@clearfog:~# ip addr add 192.168.254.3/24 dev lan1
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.331 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.331/0.331/0.331/0.000 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev lan1
root@clearfog:~# brctl addif br0 lan1
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.2
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
64 bytes from 192.168.254.2: icmp_seq=1 ttl=255 time=0.630 ms
^C
--- 192.168.254.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.630/0.630/0.630/0.000 ms
I have no other patches for DSA other than the v2 I posted on this
kernel.
I'd suggest adding back the debugfs register dumping so you can get
some diagnostics, and work out what's different in the configuration
between a working kernel and a non-working kernel:
https://github.com/vivien/linux/commit/b23c6568011c84b80a8f5632ac819a5dbdca2dc1.patch
However, what I do notice is that trying to use vlans is a complete
fail - the switch strips _all_ vlan tags off the outgoing packets
no matter how I setup a vlan, whether it's on br0, or on a switch
port:
Packet as observed on a host connected to the switch port with no
vlan capability:
0x0000: ffff ffff ffff 0050 4302 0202 0806 0001
0x0010: 0800 0604 0001 0050 4302 0202 c0a8 fe03 ...
Packet observed on Armada 388's eth interface connected to the 88E6176
switch:
0x0000: ffff ffff ffff 0050 4302 0202 dada 0000
0x0010: 6030 0800 0806 0001 0800 0604 0001 0050 ...
The packet should appear on the wire with the 8100 0800 vlan protocol
ID + tag, but it appears with the vlan protocol and tag stripped. So
there's yet more issues here.
Incoming packets from the interface appear to be dropped as far as I
can tell - the response to those ARP packets doesn't appear, though
I'm not convinced that I've been able to get the only vlan-capable
device on that side of the network to be setup correctly for vlans -
but obviously it's a total loss if vlan transmission isn't working.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-01-23 19:37:10
On Sat, Jan 23, 2016 at 07:06:22PM +0000, Russell King - ARM Linux wrote:
On Sat, Jan 23, 2016 at 07:15:26PM +0100, Andrew Lunn wrote:
quoted
Thanks for digging into this.
I hope you saw v2, which is functionally identical.
No, not yet. I will go look for it.
quoted
I think this is a step towards a solution, but does not solve all the
problems.
e.g. I have a switch interface lan0 with the IP address
192.168.10.2. I can ping this address from another host. I then take
the IP address off the interface, create a br0 device, add lan0 to the
bridge, and put 192.168.10.2 onto the bridge. I should be able to then
ping the address. But it does not work.
That works for me. Maybe it's differences in the switch device? I
seem to remember you said your switch was an older generation than
mine (88E6176).
I'm testing on a 6172. But 6172 and 6176 are both in the same family
6352, and share the same driver.
root@clearfog:~# brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.005043020202 no lan1
lan2
lan3
lan4
lan5
lan6
So you initially have lan1 in an bridge. I don't.
root@370-rd:~# ip link set lan0 up
root@370-rd:~# ip addr add 192.168.10.2/24 dev lan0
root@370-rd:~# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=1.69 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.953 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=64 time=0.926 ms
root@370-rd:~# ip addr del 192.168.10.2/24 dev lan0
root@370-rd:~# brctl addbr br0
root@370-rd:~# brctl addif br0 lan0
root@370-rd:~# ip link set br0 up
root@370-rd:~# ip addr add 192.168.10.2/24 dev br0
root@370-rd:~# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
^C
--- 192.168.10.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2001ms
Andrew
From: Russell King - ARM Linux <hidden> Date: 2016-01-23 19:49:03
On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote:
I'm testing on a 6172. But 6172 and 6176 are both in the same family
6352, and share the same driver.
Hmm, can't be that then.
So you initially have lan1 in an bridge. I don't.
Okay, I've disabled br0 in the debian network/interfaces and rebooted.
This means eth0 (connected to the bridge) is initially down, along with
all the lan interfaces.
root@clearfog:~# brctl show br0
bridge name bridge id STP enabled interfaces
br0 can't get info No such device
root@clearfog:~# ip link set eth0 up
root@clearfog:~# ip link set lan5 up
root@clearfog:~# ip addr add 192.168.254.3/24 dev lan5
root@clearfog:~# ping 192.168.254.254
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
64 bytes from 192.168.254.254: icmp_seq=1 ttl=64 time=1.15 ms
64 bytes from 192.168.254.254: icmp_seq=2 ttl=64 time=0.686 ms
^C
--- 192.168.254.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.686/0.921/1.157/0.237 ms
root@clearfog:~# ip addr del 192.168.254.3/24 dev lan5
root@clearfog:~# brctl addbr br0
root@clearfog:~# brctl addif br0 lan5
root@clearfog:~# ip link set br0 up
root@clearfog:~# ip addr add 192.168.254.3/24 dev br0
root@clearfog:~# ping 192.168.254.254
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
64 bytes from 192.168.254.254: icmp_seq=1 ttl=64 time=1.18 ms
^C
--- 192.168.254.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.189/1.189/1.189/0.000 ms
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Russell King - ARM Linux <hidden> Date: 2016-01-23 20:44:24
On Sat, Jan 23, 2016 at 09:16:47PM +0100, Andrew Lunn wrote:
On Sat, Jan 23, 2016 at 07:48:57PM +0000, Russell King - ARM Linux wrote:
quoted
On Sat, Jan 23, 2016 at 08:37:05PM +0100, Andrew Lunn wrote:
quoted
I'm testing on a 6172. But 6172 and 6176 are both in the same family
6352, and share the same driver.
Hmm, can't be that then.
quoted
So you initially have lan1 in an bridge. I don't.
Running tcpdump on the device i'm trying to ping, there are ARP
requests and replies. But the replies are never received by the
target, arp -a shows <incomplete>.
Looking at the stats counters in debugfs, the packets are counted in
in_unicast, but also sw_in_filtered.
Port 0 is lan0 and port 5 is the cpu port.
root@370-rd:/sys/kernel/debug/dsa0# cat regs
GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6
0: c874 0 1940 1d0f 1d0f 1d0f 1d0f 100f e07 6
1: fa0 0 149 3 3 3 3 3 c03e 3
2: fa0 ffff 141 0 0 0 0 0 0 0
3: 0 ffff ea1 1721 1721 1721 1721 1721 1721 1721
4: 6000 258 1e0 433 433 433 433 433 373f 433
5: 3000 ff 0 0 0 0 0 0 0 0
6: fa0 1f0f 4 7f 7e 7d 7c 7b 7a 79
7: 3331 707f 2001 0 fa1 fa2 fa3 fa4 0 fa6
This shows port 0 is on vlan 0, but it should default to vlan 1 when
no vlans are configured. The patch below should at least allow some
diagnosis of what's being requested, and when.
@@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,u16vid;interr=0;+printk("%s: port %d vid %u-%u flags %x\n",+__func__,port,vlan->vid_begin,vlan->vid_end,vlan->flags);+mutex_lock(&ps->smi_mutex);for(vid=vlan->vid_begin;vid<=vlan->vid_end;++vid){
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-01-23 22:12:38
quoted hunk
This shows port 0 is on vlan 0, but it should default to vlan 1 when
no vlans are configured. The patch below should at least allow some
diagnosis of what's being requested, and when.
@@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,u16vid;interr=0;+printk("%s: port %d vid %u-%u flags %x\n",+__func__,port,vlan->vid_begin,vlan->vid_end,vlan->flags);+
Hi Russell
Never called.
So i guess we have a kernel configuration difference.
I don't have CONFIG_BRIDGE_VLAN_FILTERING.
But DSA should not rely on this option for correct operation.
Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: 2016-01-23 22:23:29
On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote:
quoted
This shows port 0 is on vlan 0, but it should default to vlan 1 when
no vlans are configured. The patch below should at least allow some
diagnosis of what's being requested, and when.
@@ -1511,6 +1511,9 @@ int mv88e6xxx_port_vlan_add(struct dsa_switch *ds, int port,u16vid;interr=0;+printk("%s: port %d vid %u-%u flags %x\n",+__func__,port,vlan->vid_begin,vlan->vid_end,vlan->flags);+
Hi Russell
Never called.
So i guess we have a kernel configuration difference.
I don't have CONFIG_BRIDGE_VLAN_FILTERING.
Yep, confirmed. When i enable this option, and VLAN_8021Q which it
depends on, i then have a working bridge.
Andrew
From: Russell King - ARM Linux <hidden> Date: 2016-01-23 23:31:23
On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote:
On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote:
quoted
Hi Russell
Never called.
So i guess we have a kernel configuration difference.
I don't have CONFIG_BRIDGE_VLAN_FILTERING.
Yep, confirmed. When i enable this option, and VLAN_8021Q which it
depends on, i then have a working bridge.
It sounds like Vivien urgently needs to do some extra work to fix
the patches that created all this broken-ness, or we need to ask
davem to revert back to a known good working state.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
From: Vivien Didelot <hidden> Date: 2016-01-24 06:01:52
Hi Russell,
Russell King - ARM Linux [off-list ref] writes:
On Sat, Jan 23, 2016 at 11:23:26PM +0100, Andrew Lunn wrote:
quoted
On Sat, Jan 23, 2016 at 11:12:32PM +0100, Andrew Lunn wrote:
quoted
Hi Russell
Never called.
So i guess we have a kernel configuration difference.
I don't have CONFIG_BRIDGE_VLAN_FILTERING.
Yep, confirmed. When i enable this option, and VLAN_8021Q which it
depends on, i then have a working bridge.
It sounds like Vivien urgently needs to do some extra work to fix
the patches that created all this broken-ness, or we need to ask
davem to revert back to a known good working state.
Indeed hardware bridging currently relies on 802.1Q and VLAN filtering
enabled. I will work on this asap.
Thanks,
-v