Netdev Archive on lore.kernel.org
 help / color / Atom feed
* loss of connectivity after enabling vlan_filtering
@ 2019-06-29 22:01 vtolkm
  2019-06-29 22:49 ` Andrew Lunn
  0 siblings, 1 reply; 11+ messages in thread
From: vtolkm @ 2019-06-29 22:01 UTC (permalink / raw)
  To: netdev

* DSA MV88E6060
* iproute2 v.5.0.0-2.0
* OpenWRT 19.07 with kernel 4.14.131 armv7l
_______

after

# bridge v a dev {bridge} self vid {n} untagged pvid

or with the device enslaved in the br

# bridge v a dev {device} vid {n} untagged pvid

I am hitting a roadblock when executing

# sysctl -w /sys/class/net/{bridge}/bridge/vlan_filtering=1

there is immediate loss of connectivity with the node until

# sysctl -w /sys/class/net/{bridge}/bridge/vlan_filtering=0

Since writing here I apparently trust that above is unexpected and I
cannot figure out what is (going) wrong.

Tried some variation (enabling VID on the client when appropriate) but
having met the same outcome.

# bridge v a dev {bridge} self vid {n} untagged
# bridge v a dev {bridge} self vid {n} pvid
# bridge v a dev {bridge} self vid {n}

# bridge v s

reflects any such change.

# ip -d l sh type bridge

br-mgt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
    link/ether 1e:8e:c2:3c:b8:35 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bridge forward_delay 200 hello_time 200 max_age 2000 ageing_time
30000 stp_state 0 priority 32767 vlan_filtering 0 vlan_protocol 802.1Q
bridge_id 7fff.1E:8E:C2:3C:B8:35 designated_root 7fff.1E:8E:C2:3C:B8:35
root_port 0 root_path_cost 0 topology_change 0 topology_change_detected
0 hello_timer    0.00 tcn_timer    0.00 topology_change_timer    0.00
gc_timer  168.58 vlan_default_pvid 1 vlan_stats_enabled 0 group_fwd_mask
0 group_address 01:80:c2:00:00:00 mcast_snooping 0 mcast_router 1
mcast_query_use_ifaddr 0 mcast_querier 0 mcast_hash_elasticity 4
mcast_hash_max 512 mcast_last_member_count 2 mcast_startup_query_count 2
mcast_last_member_interval 100 mcast_membership_interval 26000
mcast_querier_interval 25500 mcast_query_interval 12500
mcast_query_response_interval 1000 mcast_startup_query_interval 3125
mcast_stats_enabled 0 mcast_igmp_version 2 mcast_mld_version 1
nf_call_iptables 0 nf_call_ip6tables 0 nf_call_arptables 0 addrgenmode
stable_secret numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535

______________________

* kernel conf
---
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m
CONFIG_NETFILTER_INGRESS=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_FAMILY_BRIDGE=y
CONFIG_NETFILTER_FAMILY_ARP=y
# CONFIG_NETFILTER_NETLINK_ACCT is not set
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_NETFILTER_NETLINK_GLUE_CT is not set
CONFIG_IP_NF_MATCH_RPFILTER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP6_NF_MATCH_RPFILTER=m
CONFIG_IP6_NF_FILTER=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_ATM_BR2684_IPFILTER=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_HAVE_NET_DSA=y
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
# CONFIG_NET_DSA_BCM_SF2 is not set
# CONFIG_NET_DSA_LOOP is not set
# CONFIG_NET_DSA_MT7530 is not set
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
# CONFIG_NET_DSA_QCA8K is not set
# CONFIG_NET_DSA_SMSC_LAN9303_I2C is not set
# CONFIG_NET_DSA_SMSC_LAN9303_MDIO is not set
# CONFIG_HNS_DSAF is not set
CONFIG_PPP_FILTER=y
CONFIG_IPPP_FILTER=y





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-29 22:01 loss of connectivity after enabling vlan_filtering vtolkm
@ 2019-06-29 22:49 ` Andrew Lunn
  2019-06-29 23:04   ` vtolkm
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2019-06-29 22:49 UTC (permalink / raw)
  To: vtolkm; +Cc: netdev

On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
> * DSA MV88E6060
> * iproute2 v.5.0.0-2.0
> * OpenWRT 19.07 with kernel 4.14.131 armv7l

The mv88e6060 driver is very simple. It has no support for VLANs. It
does not even have support for offloading bridging between ports to
the switch.

The data sheet for this device is open. So if you want to hack on the
driver, you could do.

	Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-29 22:49 ` Andrew Lunn
@ 2019-06-29 23:04   ` vtolkm
  2019-06-29 23:11     ` Andrew Lunn
  0 siblings, 1 reply; 11+ messages in thread
From: vtolkm @ 2019-06-29 23:04 UTC (permalink / raw)
  To: netdev; +Cc: Andrew Lunn


On 30/06/2019 00:49, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>> * DSA MV88E6060
>> * iproute2 v.5.0.0-2.0
>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> The mv88e6060 driver is very simple. It has no support for VLANs. It
> does not even have support for offloading bridging between ports to
> the switch.
>
> The data sheet for this device is open. So if you want to hack on the
> driver, you could do.
>
> 	Andrew

Are you sure? That is a bit confusing after reading
https://lore.kernel.org/patchwork/patch/575746/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-29 23:04   ` vtolkm
@ 2019-06-29 23:11     ` Andrew Lunn
  2019-06-29 23:23       ` vtolkm
  0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2019-06-29 23:11 UTC (permalink / raw)
  To: vtolkm; +Cc: netdev

On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
> 
> On 30/06/2019 00:49, Andrew Lunn wrote:
> > On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
> >> * DSA MV88E6060
> >> * iproute2 v.5.0.0-2.0
> >> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> > The mv88e6060 driver is very simple. It has no support for VLANs. It
> > does not even have support for offloading bridging between ports to
> > the switch.
> >
> > The data sheet for this device is open. So if you want to hack on the
> > driver, you could do.
> >
> > 	Andrew
> 
> Are you sure? That is a bit confusing after reading
> https://lore.kernel.org/patchwork/patch/575746/

Quoting that patch:

	This commit implements the switchdev operations to add, delete
	and dump VLANs for the Marvell 88E6352 and compatible switch
	chips.

Vivien added support for the 6352. That uses the mv88e6xxx driver, not
the mv88e6060. And by compatible switches, he meant those in the 6352
family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.

	Andrew

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-29 23:11     ` Andrew Lunn
@ 2019-06-29 23:23       ` vtolkm
  2019-06-30  0:37         ` vtolkm
  2019-07-05 17:29         ` Vivien Didelot
  0 siblings, 2 replies; 11+ messages in thread
From: vtolkm @ 2019-06-29 23:23 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: netdev

On 30/06/2019 01:11, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>> * DSA MV88E6060
>>>> * iproute2 v.5.0.0-2.0
>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>> does not even have support for offloading bridging between ports to
>>> the switch.
>>>
>>> The data sheet for this device is open. So if you want to hack on the
>>> driver, you could do.
>>>
>>> 	Andrew
>> Are you sure? That is a bit confusing after reading
>> https://lore.kernel.org/patchwork/patch/575746/
> Quoting that patch:
>
> 	This commit implements the switchdev operations to add, delete
> 	and dump VLANs for the Marvell 88E6352 and compatible switch
> 	chips.
>
> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
> the mv88e6060. And by compatible switches, he meant those in the 6352
> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>
> 	Andrew

A simple soul might infer that mv88e6xxx includes MV88E6060, at least
that happened to me apparently (being said simpleton).
That may as it be, and pardon my continued ignorance, how is it
explained then that a command as

# bridge v a dev {bridge} self vid {n} untagged pvid

reflects in

# bridge v s
a/o
# bridge mo

?

If the commands are not implemented one would expect them to fail in the
first place or not reflecting a change at all?





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-29 23:23       ` vtolkm
@ 2019-06-30  0:37         ` vtolkm
  2019-06-30  1:13           ` vtolkm
  2019-07-05 17:29         ` Vivien Didelot
  1 sibling, 1 reply; 11+ messages in thread
From: vtolkm @ 2019-06-30  0:37 UTC (permalink / raw)
  To: netdev; +Cc: Andrew Lunn

On 30/06/2019 01:23, vtolkm@gmail.com wrote:
> On 30/06/2019 01:11, Andrew Lunn wrote:
>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>>> * DSA MV88E6060
>>>>> * iproute2 v.5.0.0-2.0
>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>> does not even have support for offloading bridging between ports to
>>>> the switch.
>>>>
>>>> The data sheet for this device is open. So if you want to hack on the
>>>> driver, you could do.
>>>>
>>>> 	Andrew
>>> Are you sure? That is a bit confusing after reading
>>> https://lore.kernel.org/patchwork/patch/575746/
>> Quoting that patch:
>>
>> 	This commit implements the switchdev operations to add, delete
>> 	and dump VLANs for the Marvell 88E6352 and compatible switch
>> 	chips.
>>
>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>> the mv88e6060. And by compatible switches, he meant those in the 6352
>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>
>> 	Andrew
> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
> that happened to me apparently (being said simpleton).
> That may as it be, and pardon my continued ignorance, how is it
> explained then that a command as
>
> # bridge v a dev {bridge} self vid {n} untagged pvid
>
> reflects in
>
> # bridge v s
> a/o
> # bridge mo
>
> ?
>
> If the commands are not implemented one would expect them to fail in the
> first place or not reflecting a change at all?
>
>

As stated in the initial message - kernel conf

CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y





^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-30  0:37         ` vtolkm
@ 2019-06-30  1:13           ` vtolkm
  2019-06-30  7:46             ` vtolkm
  0 siblings, 1 reply; 11+ messages in thread
From: vtolkm @ 2019-06-30  1:13 UTC (permalink / raw)
  To: netdev; +Cc: Andrew Lunn


On 30/06/2019 02:37, vtolkm@gmail.com wrote:
> On 30/06/2019 01:23, vtolkm@gmail.com wrote:
>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>>>> * DSA MV88E6060
>>>>>> * iproute2 v.5.0.0-2.0
>>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>>> does not even have support for offloading bridging between ports to
>>>>> the switch.
>>>>>
>>>>> The data sheet for this device is open. So if you want to hack on the
>>>>> driver, you could do.
>>>>>
>>>>> 	Andrew
>>>> Are you sure? That is a bit confusing after reading
>>>> https://lore.kernel.org/patchwork/patch/575746/
>>> Quoting that patch:
>>>
>>> 	This commit implements the switchdev operations to add, delete
>>> 	and dump VLANs for the Marvell 88E6352 and compatible switch
>>> 	chips.
>>>
>>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>>> the mv88e6060. And by compatible switches, he meant those in the 6352
>>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>>
>>> 	Andrew
>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>> that happened to me apparently (being said simpleton).
>> That may as it be, and pardon my continued ignorance, how is it
>> explained then that a command as
>>
>> # bridge v a dev {bridge} self vid {n} untagged pvid
>>
>> reflects in
>>
>> # bridge v s
>> a/o
>> # bridge mo
>>
>> ?
>>
>> If the commands are not implemented one would expect them to fail in the
>> first place or not reflecting a change at all?
>>
>>
> As stated in the initial message - kernel conf
>
> CONFIG_NET_DSA_MV88E6060=y
> CONFIG_NET_DSA_MV88E6XXX=y
> CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
>

Just figured that it is a  Marvell 88E6176-TFJ2. Thus that cannot be the
cause, also considering the that the commands are executing and changes
being reflected.

However, the loss of access to the node is a mystery.

Apparently the filter is doing its job as in isolating access to the
bridge if connecting though an enslaved device.
And yet the bridge is still fully accessible from other devices that or
not enslaved by that bridge. As if the filter is inverted.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-30  1:13           ` vtolkm
@ 2019-06-30  7:46             ` vtolkm
  0 siblings, 0 replies; 11+ messages in thread
From: vtolkm @ 2019-06-30  7:46 UTC (permalink / raw)
  To: netdev; +Cc: Andrew Lunn


On 30/06/2019 03:13, vtolkm@gmail.com wrote:
> On 30/06/2019 02:37, vtolkm@gmail.com wrote:
>> On 30/06/2019 01:23, vtolkm@gmail.com wrote:
>>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>>>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>>>>> * DSA MV88E6060
>>>>>>> * iproute2 v.5.0.0-2.0
>>>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>>>> does not even have support for offloading bridging between ports to
>>>>>> the switch.
>>>>>>
>>>>>> The data sheet for this device is open. So if you want to hack on the
>>>>>> driver, you could do.
>>>>>>
>>>>>> 	Andrew
>>>>> Are you sure? That is a bit confusing after reading
>>>>> https://lore.kernel.org/patchwork/patch/575746/
>>>> Quoting that patch:
>>>>
>>>> 	This commit implements the switchdev operations to add, delete
>>>> 	and dump VLANs for the Marvell 88E6352 and compatible switch
>>>> 	chips.
>>>>
>>>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>>>> the mv88e6060. And by compatible switches, he meant those in the 6352
>>>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>>>
>>>> 	Andrew
>>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>>> that happened to me apparently (being said simpleton).
>>> That may as it be, and pardon my continued ignorance, how is it
>>> explained then that a command as
>>>
>>> # bridge v a dev {bridge} self vid {n} untagged pvid
>>>
>>> reflects in
>>>
>>> # bridge v s
>>> a/o
>>> # bridge mo
>>>
>>> ?
>>>
>>> If the commands are not implemented one would expect them to fail in the
>>> first place or not reflecting a change at all?
>>>
>>>
>> As stated in the initial message - kernel conf
>>
>> CONFIG_NET_DSA_MV88E6060=y
>> CONFIG_NET_DSA_MV88E6XXX=y
>> CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
>>
> Just figured that it is a  Marvell 88E6176-TFJ2. Thus that cannot be the
> cause, also considering the that the commands are executing and changes
> being reflected.
>
> However, the loss of access to the node is a mystery.
>
> Apparently the filter is doing its job as in isolating access to the
> bridge if connecting though an enslaved device.
> And yet the bridge is still fully accessible from other devices that or
> not enslaved by that bridge. As if the filter is inverted.
>

The node's kernel log is showing during boot time repeated entries:

mv88e6085 f1072004.mdio-mii:10 lan{n}: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already used by br-{n}

Could there be a correlation with the described issue?

Is there way to debug the issue otherwise?






^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-06-29 23:23       ` vtolkm
  2019-06-30  0:37         ` vtolkm
@ 2019-07-05 17:29         ` Vivien Didelot
  2020-01-14 21:33           ` ™֟☻̭҇ Ѽ ҉ ®
  1 sibling, 1 reply; 11+ messages in thread
From: Vivien Didelot @ 2019-07-05 17:29 UTC (permalink / raw)
  To: vtolkm; +Cc: Andrew Lunn, netdev

On Sun, 30 Jun 2019 01:23:02 +0200, vtolkm@googlemail.com wrote:
> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
> that happened to me apparently (being said simpleton).

I agree that is confusing, that is why I don't like the 'xxx' naming
convention in general, found in many drivers. I'd prefer to stick with a
reference model, or product category, like soho in this case. But it was
initially written like this, so no reason to change its name now. I still
plan to merge mv88e6060 into mv88e6xxx, but it is unfortunately low priority
because I still don't have a platform with a 88E6060 on it.

Thanks,

	Vivien

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2019-07-05 17:29         ` Vivien Didelot
@ 2020-01-14 21:33           ` ™֟☻̭҇ Ѽ ҉ ®
  2020-01-15 12:56             ` ™֟☻̭҇ Ѽ ҉ ®
  0 siblings, 1 reply; 11+ messages in thread
From: ™֟☻̭҇ Ѽ ҉ ® @ 2020-01-14 21:33 UTC (permalink / raw)
  To: netdev; +Cc: Vivien Didelot, Andrew Lunn

On 05/07/2019 17:29, Vivien Didelot wrote:
> On Sun, 30 Jun 2019 01:23:02 +0200, vtolkm@googlemail.com wrote:
>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>> that happened to me apparently (being said simpleton).
> I agree that is confusing, that is why I don't like the 'xxx' naming
> convention in general, found in many drivers. I'd prefer to stick with a
> reference model, or product category, like soho in this case. But it was
> initially written like this, so no reason to change its name now. I still
> plan to merge mv88e6060 into mv88e6xxx, but it is unfortunately low priority
> because I still don't have a platform with a 88E6060 on it.
>
> Thanks,
>
> 	Vivien

At long last discovered (accidentality) what causes the loss of 
connectivity when enabling vlan_filtering, the node being dual-core and 
each core providing a port facing the switchdev:

cpu0 - eht0 [RGMII] <--- > switchdev port 6
cpu1 - eth1 [RGMII] <--- > switchdev port 5

If only one of the CPU ports is connected to the respective switchdev 
port connectivity to the node gets severed when enabling vlan_filtering.
With both CPU ports connected to the respective switchdev ports 
connectivity remains uninterrupted to the node when enabling 
vlan_filtering.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: loss of connectivity after enabling vlan_filtering
  2020-01-14 21:33           ` ™֟☻̭҇ Ѽ ҉ ®
@ 2020-01-15 12:56             ` ™֟☻̭҇ Ѽ ҉ ®
  0 siblings, 0 replies; 11+ messages in thread
From: ™֟☻̭҇ Ѽ ҉ ® @ 2020-01-15 12:56 UTC (permalink / raw)
  To: netdev; +Cc: Vivien Didelot, Andrew Lunn

On 14/01/2020 21:33, ™֟☻̭҇ Ѽ ҉ ® wrote:
> On 05/07/2019 17:29, Vivien Didelot wrote:
>> On Sun, 30 Jun 2019 01:23:02 +0200, vtolkm@googlemail.com wrote:
>>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>>> that happened to me apparently (being said simpleton).
>> I agree that is confusing, that is why I don't like the 'xxx' naming
>> convention in general, found in many drivers. I'd prefer to stick with a
>> reference model, or product category, like soho in this case. But it was
>> initially written like this, so no reason to change its name now. I 
>> still
>> plan to merge mv88e6060 into mv88e6xxx, but it is unfortunately low 
>> priority
>> because I still don't have a platform with a 88E6060 on it.
>>
>> Thanks,
>>
>>     Vivien
>
> At long last discovered (accidentality) what causes the loss of 
> connectivity when enabling vlan_filtering, the node being dual-core 
> and each core providing a port facing the switchdev:
>
> cpu0 - eht0 [RGMII] <--- > switchdev port 6
> cpu1 - eth1 [RGMII] <--- > switchdev port 5
>
> If only one of the CPU ports is connected to the respective switchdev 
> port connectivity to the node gets severed when enabling vlan_filtering.
> With both CPU ports connected to the respective switchdev ports 
> connectivity remains uninterrupted to the node when enabling 
> vlan_filtering.

The WIP patch at the downstream distro that remedies the issue for the 
particular device (dsa-multi-cpu) is accessible here:

https://gitlab.labs.nic.cz/turris/turris-build/commit/b440de75ba0f4a8dbfb530fcae2a821f26cde2a8


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-29 22:01 loss of connectivity after enabling vlan_filtering vtolkm
2019-06-29 22:49 ` Andrew Lunn
2019-06-29 23:04   ` vtolkm
2019-06-29 23:11     ` Andrew Lunn
2019-06-29 23:23       ` vtolkm
2019-06-30  0:37         ` vtolkm
2019-06-30  1:13           ` vtolkm
2019-06-30  7:46             ` vtolkm
2019-07-05 17:29         ` Vivien Didelot
2020-01-14 21:33           ` ™֟☻̭҇ Ѽ ҉ ®
2020-01-15 12:56             ` ™֟☻̭҇ Ѽ ҉ ®

Netdev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netdev/0 netdev/git/0.git
	git clone --mirror https://lore.kernel.org/netdev/1 netdev/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netdev netdev/ https://lore.kernel.org/netdev \
		netdev@vger.kernel.org
	public-inbox-index netdev

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netdev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git