lantiq: Improve gswip, build again #13200

hauke · 2023-07-31T23:12:21Z

This adds multiples patches from this branch: https://github.com/xdarklight/linux/commits/lantiq-gswip-integration-20221022
It also tries to fix the error messages returned in gswip_port_fdb when a mac address is added to the CPU port for the fdb.

Here is a longer discussion about this topic: https://lore.kernel.org/netdev/0e66011d-c3bd-5df2-e81d-5b67e4689330@hauke-m.de/T/

Here is some code to make the selftests works: https://github.com/xdarklight/openwrt-packages/commits/heads/refs/wip-kernel-selftests-net-forwarding-20220727

After these changes we can remove the source only flag.

I plan to backport this after some testing to openwrt 23.05 branch too.

Please test this and report back the results.

hauke · 2023-07-31T23:13:58Z

...et/linux/lantiq/patches-5.15/0747-net-dsa-lantiq_gswip-Update-per-port-flooding-and-le.patch

+bridge).
+
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+[Do not disable flooding on CPU port in setup]


In kernel 5.15 gswip_port_enable() is not called for the CPU port. Always enable flooding for the CPU port.
Is this maybe helping? xdarklight/linux@a595ee7

hauke · 2023-07-31T23:14:24Z

...et/linux/lantiq/patches-5.15/0746-net-dsa-lantiq_gswip-Implement-port-_pre-_bridge_fla.patch

+register.
+
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+[removed BR_PORT_LOCKED support for kernel 5.15]


BR_PORT_LOCKED is not supported in kernel 5.15.

hauke · 2023-07-31T23:17:58Z

...et/linux/lantiq/patches-5.15/0751-net-dsa-lantiq_gswip-allow-adding-fdb-for-individual.patch

+ 		}
+	} else {
+		/* FID of a standalone port (single port bridge) */
+		fid = port + 1;


This patch is better, but it needs some extra features introduced between 5.15 and 6.1:
xdarklight/linux@4aadb97

Unfortunately this is not working. Yes, it silences the warnings that people have been seeing.
But that doesn't meant that it makes the GSWIP driver comply with DSA's expectations.

It's been a while but from memory the issue is that DSA expects that it can add/remove static FDB entries for a port at any time.
Unfortunately this is tricky to implement for the GSWIP driver.
A as long as a port is a standalone port (meaning it's not part of a bridge) the fid = port + 1 logic is correct.
As soon as the port is part of a bridge this is not correct anymore a different fid (the one assigned to the bridge) has to be used.
But there's cases where a static FDB entry is added early before the port is part of a bridge. Then the port is added to the bridge, meaning it's fid changes. This is not reflected in the static FDB entries and so basically what happens is that any per port FDB entries that were added before the port became part of a bridge are not used by the hardware anymore.

I also forgot: this does not honor DSA_DB_PORT yet.
We should move to something like xdarklight/linux@4aadb97 - but again, even that still needs (at lot of) work

DSA_DB_PORT is not available in kernel 5.15. It was added with kernel 5.18, see:
torvalds/linux@c269336

Maybe we can migrate this forwarding rule when we add the port to a bridge?

hauke · 2023-07-31T23:20:42Z

@xdarklight Do you want to send your patches upstream to Linus or should I try it? I would like to get at least the trivial ones into upstream kernel.

hauke · 2023-07-31T23:21:36Z

...et/linux/lantiq/patches-5.15/0734-net-dsa-lantiq_gswip-Don-t-manually-call-gswip_port_.patch

+
+ 	ds->mtu_enforcement_ingress = true;
+
+-	gswip_port_enable(ds, cpu_port, NULL);


I think this is not called by DSA in kernel 5.15.

nicefile · 2023-08-01T17:10:07Z

Tested with FB 7412 . No more nasty errors in dmesg.

 OpenWrt 23.05-SNAPSHOT, r23314-7efec0acca
root@7412:~# dmesg |grep gswip
[    2.350887] gswip 1e108000.switch: configuring for fixed/internal link mode
[    2.357029] gswip 1e108000.switch: Link is Up - 1Gbps/Full - flow control off
[    2.366257] gswip 1e108000.switch lan (uninitialized): PHY [1e108000.switch-mii:11] driver [Intel XWAY PHY22F (xRX v1.2 integrated)] (irq=POLL)
[    2.382180] gswip 1e108000.switch: probed GSWIP version 21 mod 0
[    8.106845] gswip 1e108000.switch lan: configuring for phy/internal link mode
[   41.404185] gswip 1e108000.switch lan: configuring for phy/internal link mode
[   59.066746] gswip 1e108000.switch lan: Link is Up - 100Mbps/Full - flow control off
[   72.655310] gswip 1e108000.switch lan: Link is Down
[   77.855336] gswip 1e108000.switch lan: Link is Up - 100Mbps/Full - flow control rx/tx

Device set in wireless relay operation and I see traffic via ethernet port.

xdarklight · 2023-08-05T21:50:45Z

...et/linux/lantiq/patches-5.15/0746-net-dsa-lantiq_gswip-Implement-port-_pre-_bridge_fla.patch

+{
+	struct gswip_priv *priv = ds->priv;
+
+	if (flags.mask & BR_LEARNING)


Please note that this breaks kernel selftests and I think there are some real world side-effects.
It's been a while, but with Linux 6.1 the following patches should work once you're on Linux 6.1:

xdarklight/openwrt-packages@ffea502

xdarklight/openwrt-packages@27af84d

I can drop this patch for now.

There are a lot of changes in DSA between kernel 5.15 and 6.1. I am fine if the gswip DSA driver has the same bugs and functionality with kernel 5.15 we had with kernel 5.10.

xdarklight · 2023-08-05T22:02:39Z

@xdarklight Do you want to send your patches upstream to Linus or should I try it? I would like to get at least the trivial ones into upstream kernel.

If you have time and motivation for this then please feel free to update the patches as needed and upstream them.
I also commented on two patches that still need work - those were the two topics where I got stuck when I was trying to get the self-tests to pass. It's all nice and good if some warnings disappear from the kernel log, but it's not great if the driver is effectively still broken and just the warnings are gone (no blaming here, I just want to make sure we're on the same page).

In case you have any questions: we can do a session together (online or offline, the latter will be harder to organize due to my current schedule) and walk through the self-tests and some of the code so I can share thoughts from my previous session(s) with @sch-m

hauke · 2023-08-06T13:30:57Z

@xdarklight Do you want to send your patches upstream to Linus or should I try it? I would like to get at least the trivial ones into upstream kernel.

If you have time and motivation for this then please feel free to update the patches as needed and upstream them. I also commented on two patches that still need work - those were the two topics where I got stuck when I was trying to get the self-tests to pass. It's all nice and good if some warnings disappear from the kernel log, but it's not great if the driver is effectively still broken and just the warnings are gone (no blaming here, I just want to make sure we're on the same page).

I would like to get the low hanging fruits upstream first. The we can take care of the harder ones independently.

In case you have any questions: we can do a session together (online or offline, the latter will be harder to organize due to my current schedule) and walk through the self-tests and some of the code so I can share thoughts from my previous session(s) with @sch-m

I am also pretty busy the next few days.

sch-m · 2023-08-07T08:36:37Z

It's been some time now since @xdarklight and I could take some time to have a look at this topic, but as far as I can remember one of the main problems is that the switch does not distribute the unknown/multicast/broadcast packets VLAN or PVID related. Instead, it can only be configured globally to which ports these types of packets should be routed.

As a result, we actually always need to flood the CPU port, which in turn means that we will probably never get all selftests "green".

lantiq-xrx200 is currently marked as source-only in OpenWrt 23.05, as the switch driver does not work correctly on Linux 5.15. Mark as broken in Gluon as well until the issue is fixed. Upstream PR: openwrt/openwrt#13200

Keeper-of-the-Keys · 2023-10-13T14:03:31Z

Is there anything homehub owners can do to help this ticket progress (beta testing or something)?
It's a big pity this ticket was not listed in all the prior release notes, I went looking for ways to help on IRC multiple times with no luck.

aidanmacgregor · 2023-10-13T23:19:29Z

Is there anything homehub owners can do to help this ticket progress (beta testing or something)? It's a big pity this ticket was not listed in all the prior release notes, I went looking for ways to help on IRC multiple times with no luck.

I can test on my HH 5, it's not in service so available to test on :)

EDIT, it I need do build manually and apply patches some help would probably be required :)

Keeper-of-the-Keys · 2023-10-14T17:44:07Z

Same here, I installed HH5s by some of my family members and have a spare unit that I can run tests on (without DSL connectivity since I no longer have DSL)

This reverts commit 0c117e1. Activate the lantiq/xrx200 target again. There are still some problems with the GSWIP, but it is not leaking packets to the wrong bridge in normal operations. It shows some error messages at configuration like these: [ 54.308861] gswip 1e108000.switch: port 5 failed to add ce:9d:84:d1:81:f0 vid 1 to fdb: -22 [ 54.325633] gswip 1e108000.switch: port 5 failed to add e8:de:27:95:c1:b4 vid 0 to fdb: -22 [ 54.351242] gswip 1e108000.switch: port 5 failed to add e8:de:27:95:c1:b4 vid 1 to fdb: -22 [ 54.358311] gswip 1e108000.switch: port 5 failed to delete ce:9d:84:d1:81:f0 vid 1 from fdb: -2 The problems are described in this pull request: openwrt#13200 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

This backports a patch from upstream kernel 5.19 which improves finding the bridge in the gswip_port_fdb() function. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

This backports some patches for the gswip switch driver. which should go into the upstream kernel soon. These patches are fixing some bugs and are adding minor new features. I copied them from this repository: https://github.com/xdarklight/linux/commits/lantiq-gswip-integration-20221022 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Since kernel 5.14 the DSA subsystem will also add the MAC addresses of the interfaces manually to the fdb. This also happens for interfaces which are not part of a bridge. Add support for this case too. This fixes some annoying error messages. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

This reverts commit 0c117e1. Activate the lantiq/xrx200 target again. There are still some problems with the GSWIP, but it is not leaking packets to the wrong bridge in normal operations. It shows some error messages at configuration like these: [ 54.308861] gswip 1e108000.switch: port 5 failed to add ce:9d:84:d1:81:f0 vid 1 to fdb: -22 [ 54.325633] gswip 1e108000.switch: port 5 failed to add e8:de:27:95:c1:b4 vid 0 to fdb: -22 [ 54.351242] gswip 1e108000.switch: port 5 failed to add e8:de:27:95:c1:b4 vid 1 to fdb: -22 [ 54.358311] gswip 1e108000.switch: port 5 failed to delete ce:9d:84:d1:81:f0 vid 1 from fdb: -2 The problems are described in this pull request: #13200 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (cherry picked from commit e1aaa1d)

whiskerp · 2023-10-30T21:42:47Z

I have a spare HH5 and VDSL2 line and am happy ro flash it and test.

mbunal · 2023-10-31T02:42:39Z

I have a spare Zyxel p-2812 and VDSL line and I am happy to test. I use already OpenWrt 22.03.5.

This reverts commit 0c117e1. Activate the lantiq/xrx200 target again. There are still some problems with the GSWIP, but it is not leaking packets to the wrong bridge in normal operations. It shows some error messages at configuration like these: [ 54.308861] gswip 1e108000.switch: port 5 failed to add ce:9d:84:d1:81:f0 vid 1 to fdb: -22 [ 54.325633] gswip 1e108000.switch: port 5 failed to add e8:de:27:95:c1:b4 vid 0 to fdb: -22 [ 54.351242] gswip 1e108000.switch: port 5 failed to add e8:de:27:95:c1:b4 vid 1 to fdb: -22 [ 54.358311] gswip 1e108000.switch: port 5 failed to delete ce:9d:84:d1:81:f0 vid 1 from fdb: -2 The problems are described in this pull request: openwrt#13200 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

OnlineDynamic · 2023-12-03T23:04:11Z

Where have we got to with this? I see lantiq is now being built for v23.05.02 but the wiki for the BT Home Hub 5A still points back to this thread... and in the release notes for 23.05.02 it talks about potentially needing special tweak to U-Boot environment but have been unable to find details

Keeper-of-the-Keys · 2023-12-03T23:26:20Z

I successfully flashed 23.05.2 to a device that I want to install by a family member, they also have a setup with a few vlans so will be interesting to see.

jospezial · 2024-01-12T12:12:02Z

@hauke @xdarklight @sch-m
There are some gwsip commits from @vladimiroltean and others in torvalds/linux.git. Maybe you want to use something of that.
https://github.com/search?q=repo%3Atorvalds%2Flinux+gswip&type=commits&s=committer-date&o=desc

vladimiroltean · 2024-01-13T00:17:48Z

Those improvements are fairly mechanical, I don't think they will help too much here.

Djfe · 2024-01-28T10:31:30Z

Where have we got to with this? I see lantiq is now being built for v23.05.02 but the wiki for the BT Home Hub 5A still points back to this thread...

this is an open source community. not everyone edits the wiki all the time. Therefore documentation is often outdated.
This issue was fixed to the point that they felt comfortable to add support again. Feel free to use 23.05.2 .
For details: e1aaa1d

and in the release notes for 23.05.02 it talks about potentially needing special tweak to U-Boot environment but have been unable to find details

That only(!) affects the 3 Linksys EA6350v3, EA8300 and MR8300 devices.
For details: https://openwrt.org/toh/linksys/mr8300#installation_of_2305_or_snapshot

alexceltare2 · 2024-03-28T21:53:57Z

The newest release https://openwrt.org/releases/23.05/notes-23.05.3 mentions that this issue is still ongoing. Is this still the case? I guess they haven't merged this commit yet.

durdin85 · 2024-05-07T12:01:59Z

The newest release https://openwrt.org/releases/23.05/notes-23.05.3 mentions that this issue is still ongoing. Is this still the case? I guess they haven't merged this commit yet.

I am wondering the same. Especially when openwrt 22.03 is ending support soon so it would be nice to get this merged to 23.05.

hauke · 2024-05-16T10:09:17Z

Most patches went into main in #15233 which was just merged. This is not needed any more.

lantiq-xrx200 is currently marked as source-only in OpenWrt 23.05, as the switch driver does not work correctly on Linux 5.15. Mark as broken in Gluon as well until the issue is fixed. Upstream PR: openwrt/openwrt#13200

roqueeee · 2025-02-21T11:08:14Z

Sorry for necroing this, but I still get gswip fdb kernel errors on 23.05.5 and 24.10.0.

I'm testing on AVM FRITZ!Box 3370 Rev. 2 (Micron NAND), xRX200 rev 1.1

Is xrx200 still known broken for some devices?

[ ... ]
[    2.552310] gswip 1e108000.switch: configuring for fixed/internal link mode
[    2.558343] gswip 1e108000.switch: Link is Up - 1Gbps/Full - flow control off
[    2.567624] gswip 1e108000.switch lan3 (uninitialized): PHY [1e108000.switch-mii:00] driver [Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.3] (irq=POLL)
[    2.586579] gswip 1e108000.switch lan4 (uninitialized): PHY [1e108000.switch-mii:01] driver [Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.3] (irq=POLL)
[    2.604485] gswip 1e108000.switch lan2 (uninitialized): PHY [1e108000.switch-mii:11] driver [Intel XWAY PHY11G (xRX v1.1 integrated)] (irq=POLL)
[    2.622214] gswip 1e108000.switch lan1 (uninitialized): PHY [1e108000.switch-mii:13] driver [Intel XWAY PHY11G (xRX v1.1 integrated)] (irq=POLL)
[    2.636598] lantiq,xrx200-net 1e10b308.eth eth0: entered promiscuous mode
[    2.642146] DSA: tree 0 setup
[    2.644947] gswip 1e108000.switch: probed GSWIP version 0 mod 1
[ ... ]
[   46.517286] gswip 1e108000.switch lan4: configuring for phy/rgmii link mode
[   46.530608] br-dsl: port 1(lan4) entered blocking state
[   46.534501] br-dsl: port 1(lan4) entered disabled state
[   46.540024] gswip 1e108000.switch lan4: entered allmulticast mode
[   46.545913] lantiq,xrx200-net 1e10b308.eth eth0: entered allmulticast mode
[   46.561952] gswip 1e108000.switch lan4: entered promiscuous mode
[   46.568781] gswip 1e108000.switch: port 1 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   46.575998] gswip 1e108000.switch: port 1 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   46.584170] gswip 1e108000.switch: port 1 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   46.592701] gswip 1e108000.switch: port 1 failed to delete xx:xx:xx:xx:xx:xx vid 1 from fdb: -2
[   46.610304] gswip 1e108000.switch: port 1 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   46.622053] gswip 1e108000.switch: port 1 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   46.687570] gswip 1e108000.switch lan1: configuring for phy/internal link mode
[   46.706877] br-lan: port 1(lan1) entered blocking state
[   46.710756] br-lan: port 1(lan1) entered disabled state
[   46.716236] gswip 1e108000.switch lan1: entered allmulticast mode
[   46.732046] gswip 1e108000.switch lan1: entered promiscuous mode
[   46.739346] gswip 1e108000.switch: port 4 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   46.767914] gswip 1e108000.switch: port 4 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   46.774982] gswip 1e108000.switch: port 4 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   46.783613] gswip 1e108000.switch: port 4 failed to delete xx:xx:xx:xx:xx:xx vid 1 from fdb: -2
[   46.950214] gswip 1e108000.switch lan2: configuring for phy/internal link mode
[   46.957863] br-lan: port 2(lan2) entered blocking state
[   46.961689] br-lan: port 2(lan2) entered disabled state
[   46.967222] gswip 1e108000.switch lan2: entered allmulticast mode
[   47.034754] gswip 1e108000.switch lan2: entered promiscuous mode
[   47.052467] gswip 1e108000.switch: port 2 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   47.072653] gswip 1e108000.switch: port 2 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   47.116571] gswip 1e108000.switch lan3: configuring for phy/rgmii link mode
[   47.140439] br-lan: port 3(lan3) entered blocking state
[   47.144288] br-lan: port 3(lan3) entered disabled state
[   47.149875] gswip 1e108000.switch lan3: entered allmulticast mode
[   47.207394] gswip 1e108000.switch: port 0 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   47.214543] gswip 1e108000.switch: port 0 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   47.216272] gswip 1e108000.switch lan3: entered promiscuous mode
[   49.836153] gswip 1e108000.switch lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[   49.842700] br-lan: port 1(lan1) entered blocking state
[   49.847911] br-lan: port 1(lan1) entered forwarding state

vladimiroltean · 2025-02-21T11:18:16Z

Does the OpenWrt code look like upstream here?

static int gswip_port_fdb(struct dsa_switch *ds, int port,
			  const unsigned char *addr, u16 vid, bool add)
{
	struct net_device *bridge = dsa_port_bridge_dev_get(dsa_to_port(ds, port));
	struct gswip_priv *priv = ds->priv;
	struct gswip_pce_table_entry mac_bridge = {0,};
	unsigned int max_ports = priv->hw_info->max_ports;
	int fid = -1;
	int i;
	int err;

	if (!bridge)
		return -EINVAL;

From the logs, port 1 (lan4) is under br-dsl. I've no idea why dsa_port_bridge_dev_get() would fail to see that.

roqueeee · 2025-02-21T12:06:40Z

The above output is from my own config, where lan4 and the dsl modem are on br-dsl. That way I can use the modem in bridged mode using lan4.

For reference, these are relevant log entries from a default configuration on 24.10.0:

[ ... ]
[    2.543301] gswip 1e108000.switch: configuring for fixed/internal link mode
[    2.549355] gswip 1e108000.switch: Link is Up - 1Gbps/Full - flow control off
[    2.558685] gswip 1e108000.switch lan3 (uninitialized): PHY [1e108000.switch-mii:00] driver [Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.3] (irq=POLL)
[    2.577363] gswip 1e108000.switch lan4 (uninitialized): PHY [1e108000.switch-mii:01] driver [Intel XWAY PHY11G (PEF 7071/PEF 7072) v1.3] (irq=POLL)
[    2.595727] gswip 1e108000.switch lan2 (uninitialized): PHY [1e108000.switch-mii:11] driver [Intel XWAY PHY11G (xRX v1.1 integrated)] (irq=POLL)
[    2.613409] gswip 1e108000.switch lan1 (uninitialized): PHY [1e108000.switch-mii:13] driver [Intel XWAY PHY11G (xRX v1.1 integrated)] (irq=POLL)
[    2.628232] lantiq,xrx200-net 1e10b308.eth eth0: entered promiscuous mode
[    2.633781] DSA: tree 0 setup
[    2.636655] gswip 1e108000.switch: probed GSWIP version 0 mod 1
[ ... ]
[   68.698672] gswip 1e108000.switch lan1: configuring for phy/internal link mode
[   68.718100] br-lan: port 1(lan1) entered blocking state
[   68.721990] br-lan: port 1(lan1) entered disabled state
[   68.727397] gswip 1e108000.switch lan1: entered allmulticast mode
[   68.733269] lantiq,xrx200-net 1e10b308.eth eth0: entered allmulticast mode
[   68.742175] gswip 1e108000.switch: port 4 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   68.757078] gswip 1e108000.switch lan1: entered promiscuous mode
[   68.766554] gswip 1e108000.switch: port 4 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   68.773583] gswip 1e108000.switch: port 4 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   68.796543] gswip 1e108000.switch: port 4 failed to delete xx:xx:xx:xx:xx:xx vid 1 from fdb: -2
[   68.882279] gswip 1e108000.switch lan2: configuring for phy/internal link mode
[   68.901022] br-lan: port 2(lan2) entered blocking state
[   68.904918] br-lan: port 2(lan2) entered disabled state
[   68.910408] gswip 1e108000.switch lan2: entered allmulticast mode
[   68.919614] gswip 1e108000.switch: port 2 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   68.932391] gswip 1e108000.switch: port 2 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   68.939685] gswip 1e108000.switch lan2: entered promiscuous mode
[   68.994539] gswip 1e108000.switch lan3: configuring for phy/rgmii link mode
[   69.003836] br-lan: port 3(lan3) entered blocking state
[   69.008029] br-lan: port 3(lan3) entered disabled state
[   69.012980] gswip 1e108000.switch lan3: entered allmulticast mode
[   69.046912] gswip 1e108000.switch: port 0 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   69.053985] gswip 1e108000.switch: port 0 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   69.065384] gswip 1e108000.switch lan3: entered promiscuous mode
[   69.139187] gswip 1e108000.switch lan4: configuring for phy/rgmii link mode
[   69.157482] br-lan: port 4(lan4) entered blocking state
[   69.161364] br-lan: port 4(lan4) entered disabled state
[   69.166862] gswip 1e108000.switch lan4: entered allmulticast mode
[   69.185753] gswip 1e108000.switch: port 1 failed to add xx:xx:xx:xx:xx:xx vid 1 to fdb: -22
[   69.201330] gswip 1e108000.switch lan4: entered promiscuous mode
[   69.208783] gswip 1e108000.switch: port 1 failed to add xx:xx:xx:xx:xx:xx vid 0 to fdb: -22
[   76.121214] gswip 1e108000.switch lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[   76.127989] br-lan: port 1(lan1) entered blocking state
[   76.132830] br-lan: port 1(lan1) entered forwarding state

nicefile · 2025-02-21T14:08:33Z

I see no real scenarios issues . I have 2 vlans and 2 bridges.
fb7362sl 24.10 see this only on boot (i have fixed LAN setup)
my previous build from snapshot 05/2023 with kernel 5.10.179 had no fdb error and worked exactly the same

hauke changed the title ~~lantiq: Improve gswip~~ lantiq: Improve gswip, build again Jul 31, 2023

github-actions bot added the target/lantiq pull request/issue for lantiq target label Jul 31, 2023

hauke commented Jul 31, 2023

View reviewed changes

xdarklight reviewed Aug 5, 2023

View reviewed changes

hauke force-pushed the lantiq-gswip branch from 2c25047 to efe629b Compare August 15, 2023 19:32

smavridis mentioned this pull request Aug 26, 2023

lantiq: Missing kmod folder and core packages? #13354

Closed

1 task

hauke self-assigned this Sep 1, 2023

hauke force-pushed the lantiq-gswip branch from efe629b to 265a22a Compare October 9, 2023 22:29

hauke mentioned this pull request Oct 9, 2023

lantiq: Revert "lantiq: xrx200: mark subtarget as source-only" #13638

Merged

neocturne mentioned this pull request Oct 12, 2023

lantiq-xrx200: mark target as broken freifunk-gluon/gluon#3016

Merged

hauke added 3 commits October 23, 2023 01:42

lantiq: gswip: backport patch to improve gswip_port_fdb()

a1d375c

This backports a patch from upstream kernel 5.19 which improves finding the bridge in the gswip_port_fdb() function. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

hauke force-pushed the lantiq-gswip branch from 265a22a to 613bd68 Compare October 22, 2023 23:43

sch-m mentioned this pull request May 1, 2024

lantiq: add 6.1 testing support #15233

Merged

hauke closed this May 16, 2024


		ds->mtu_enforcement_ingress = true;

		- gswip_port_enable(ds, cpu_port, NULL);

Uh oh!

lantiq: Improve gswip, build again #13200

lantiq: Improve gswip, build again #13200

Uh oh!

Conversation

hauke commented Jul 31, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hauke commented Jul 31, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nicefile commented Aug 1, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xdarklight commented Aug 5, 2023

Uh oh!

hauke commented Aug 6, 2023

Uh oh!

sch-m commented Aug 7, 2023

Uh oh!

Keeper-of-the-Keys commented Oct 13, 2023

Uh oh!

aidanmacgregor commented Oct 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Keeper-of-the-Keys commented Oct 14, 2023

Uh oh!

whiskerp commented Oct 30, 2023

Uh oh!

mbunal commented Oct 31, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

OnlineDynamic commented Dec 3, 2023

Uh oh!

Keeper-of-the-Keys commented Dec 3, 2023

Uh oh!

jospezial commented Jan 12, 2024

Uh oh!

vladimiroltean commented Jan 13, 2024

Uh oh!

Djfe commented Jan 28, 2024

Uh oh!

alexceltare2 commented Mar 28, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

durdin85 commented May 7, 2024

Uh oh!

hauke commented May 16, 2024

Uh oh!

roqueeee commented Feb 21, 2025

Uh oh!

vladimiroltean commented Feb 21, 2025

Uh oh!

roqueeee commented Feb 21, 2025

Uh oh!

nicefile commented Feb 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

hauke commented Jul 31, 2023 •

edited

Loading

aidanmacgregor commented Oct 13, 2023 •

edited

Loading

mbunal commented Oct 31, 2023 •

edited

Loading

alexceltare2 commented Mar 28, 2024 •

edited

Loading