[kernel 5.4] dual-core nodes with secondary link to switch still dead

For Developers
1

Just giving

{"kernel":"5.4.43","hostname":"OpenWrt","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13518-c37487a63d","target":"mvebu/cortexa9","description":"OpenWrt SNAPSHOT r13518-c37487a63d"}}

a test run it was noticed that kernel development apparently still has no solution for the secondary link from CPU to switch, in this case eht0, being dead.

To my understanding there is at least one other device in the same target class, if not mistaken one of the Linksys boxes, with a similar setting and suffering the same fate.

Since CZ.NIC development has a patch, which though stalled on the kernel mailing list, it might be worth for development to join forces and review the patch for implementation in OpenWrt then.
__
N.B. Nice new theme though would have preferred something more in the dark trend, maybe a toggle could be implemented to let the user switch (sort of inverting the portion of the white background and the script colour)?

2

Unclear to me what you are getting at, but maybe this.

1 Like
3

Exactly, but I would not concur that it is negligible or should be.

For one it is paid for hardware and preferably should be utilisable as such, but that perspective might be debatable though a lot of folks would probably prefer all features to work.

And secondly without aforementioned patch it caused previously (k 4.19) some grievance when enabling bridge vlan filtering - loss of connectivity on all Lan ports. Have not gotten around testing this matter yet, also seen those kernel patches https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=dc4ffaa5ab6830ba9c5b9d9569db2c2aef26755a

The patch from CZ.NIC dealt with the matter well enough but probably not to the satisfaction of kernel development, likely those dual-CPU with dual switch connectivity are more on the fringe in the scheme of all things considered.

4

A bit strange that that https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/image/cortexa9.mk has not DEVICE-DTS specified for this board, would have expected that it pulls in https://github.com/torvalds/linux/blob/v5.4/arch/arm/boot/dts/armada-385-turris-omnia.dts, similarly to what is done for the other boards.

Anyway, recompiling the DTB file with added

ports@6 {
	reg = <6>;
	label = "cpu";
	ethernet = <&eth0>;
	phy-mode = "rgmii-id";

	fixed-link {
		speed = <1000>;
		full-duplex;
	};

Should restore the port's connectivity that by default connects to Lan4. There could probably be some way to reassign the ports in the DSA switch tree.

5

Fixed in commit dc4ffaa5

6

Well, it would be if

would be pulled into the build toolchain. But since it does not Lan4 connects to the eht1 instead, as do all other Lan ports.

That aside netifd is however failing to bring the port online during boot and if the netdev is brought only with ip l set eth0 up

ubus does not recognise the link status

devstatus eth0 | grep up
        "up": false,

whilst

ip l | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1024

plus the port responds to ping.

7

The issue appeared also on the netdev ML https://lore.kernel.org/netdev/7bab9e25-a0e2-6c51-be01-5bf718afb018@gmx.net/T/#mbb10a4f9d75de29c58e60bb8d76f4c2ae52667e1

and it seems that just patching the DT is insufficient but requires extended patching of kernel code

8

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.