Le 05/27/18 à 12:18, Gerhard Wiesinger a écrit : > On 27.05.2018 21:01, Gerhard Wiesinger wrote: >> On 24.05.2018 08:22, Gerhard Wiesinger wrote: >>> On 24.05.2018 07:29, Gerhard Wiesinger wrote: >>>> After some analysis with Florian (thnx) we found out that the >>>> current implementation is broken: >>>> >>>> https://patchwork.ozlabs.org/patch/836538/ >>>> https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d >>>> >>>> >>>> Florians comment: >>>> >>>> c499696e7901bda18385ac723b7bd27c3a4af624 ("net: dsa: b53: Stop using >>>> dev->cpu_port incorrectly") since it would result in no longer setting >>>> the CPU port as tagged for a specific VLAN. Easiest way for you right >>>> now is to just revert it, but this needs some more thoughts for a >>>> proper >>>> upstream change. I will think about it some more. >>> >>> Can confirm 4.14.18-200.fc26.armv7hl works, 4.15.x should be broken. >>> >>> # Kernel 4.14.x ok >>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.14.43 >>> >>> # Kernel 4.15.x should be NOT ok >>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.15.18 >>> >> >> > > Forgot to mention: What's also strange is that the VLAN ID is very high: > > # 4.14.18-300.fc27.armv7hl, iproute-4.15.0-1.fc28.armv7hl > ip -d link show eth0.101 | grep "vlan protocol" > vlan protocol 802.1Q id 3069279796 <REORDER_HDR> > ip -d link show eth0.102 | grep "vlan protocol" > vlan protocol 802.1Q id 3068673588 <REORDER_HDR> > > On older kernels this looks ok: 4.12.8-200.fc25.armv7hl, > iproute-4.11.0-1.fc25.armv7hl: > ip -d link show eth0.101 | grep "vlan protocol" > vlan protocol 802.1Q id 101 <REORDER_HDR> > ip -d link show eth0.102 | grep "vlan protocol" > vlan protocol 802.1Q id 102 <REORDER_HDR> > > Ideas? That is quite likely a kernel/iproute2 issue, if you configured the switch through bridge vlan to have the ports in VLAN 101 and VLAN 102 and you do indeed see frames entering eth0 with these VLAN IDs, then clearly the bridge -> switchdev -> dsa -> b53 part is working just fine and what you are seeing is some for of kernel header/netlink incompatibility. -- Florian -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
