[PR] ipq806x: kernel 5.10 bump code propose

Yes I'm still trying to find a cause of random port dropping.
Interesting the uptime period

Looking at the kernel log last night, two observations:

  • lan port numbering on R7800 is reversed compared to labels. "lan1" in log is actually port "4" on the device. That might be fixed in dts. Would be great to have port numbers actually matching the labels. (That reversing was known earlier and was fixed for LuCI display, but now it might be handled directly in DTS just by switching the "label" items)
  • lan1 disabled/enabled times on log during the night match the times of shutting down my PC last night, and turning it on today. (but yesterday the two items were while PC was running idle). Looks like the "switch port as interface" will cause some unnecessary log spam from connected devices.

my vague recollection when i ran DSA on my personal build was that this was the case...i got log messages when the PC connected/disconnected.

@Ansuel Just upgraded my dumb C2600 with your latest commits and it seems to be working ok. My family recently complained about lost connectivity issues after I had upgraded to kernel 5.10+DSA six days ago.

It's not clear to me what caused such lost connectivity issues as I was away from home last week but I will now monitor closely for any issues and will report back.

I still did not upgrade my main router R7800 as it's more critical for family use.

1 Like

I'm still thinking about the MTU... The switch has a proprietary mode (set with dsa) that already set the packet as dsa in the header so in theory we shouldn't need to tweak the switch MTU.

Anyway something doesn't look good in the mtu code. This is from dsa that is mtu + 14 + 4

	/* Include L2 header / FCS length */
	qca8k_write(priv, QCA8K_MAX_FRAME_SIZE, mtu + ETH_HLEN + ETH_FCS_LEN);

But in the original code

	ar8xxx_rmw(priv, AR8327_REG_MAX_FRAME_SIZE,
		   AR8327_MAX_FRAME_SIZE_MTU, 1518 + 8 + 2);

that reflects from datasheet mtu + 8 for double vlan + 2 for atheros header (that dsa use to tag packet in 2byte mode)

Also in the setup code of dsa

	/* Setup our port MTUs to match power on defaults */
	for (i = 0; i < QCA8K_NUM_PORTS; i++)
		priv->port_mtu[i] = ETH_FRAME_LEN + ETH_FCS_LEN;
	qca8k_write(priv, QCA8K_MAX_FRAME_SIZE, ETH_FRAME_LEN + ETH_FCS_LEN);

they don't set the correct max mtu since at this point of code atheros header and vlan are already enabled

@Ansuel: FYI, in my C2600, I had six events like these below in a 10 hour interval. Lan4 is where my main router (R7800) is connected to.

[16777.502668] qca8k 37000000.mdio-mii:10 lan4: Link is Down
[16777.502862] switch0: port 4(lan4) entered disabled state
[16778.537334] br-lan: port 1(switch0.1) entered disabled state
[16780.626568] qca8k 37000000.mdio-mii:10 lan4: Link is Up - 1Gbps/Full - flow control rx/tx
[16780.626650] switch0: port 4(lan4) entered blocking state
[16780.626685] switch0: port 4(lan4) entered forwarding state
[16780.628361] br-lan: port 1(switch0.1) entered blocking state
[16780.628395] br-lan: port 1(switch0.1) entered forwarding state

Hi @Ansuel,

I'm starting to think about testing on my r7500v2 (may be a week or two until i get to it).

This device is currently configed as an AP only and has 2 VLANs so based on @hnyman's comments, I suspect I'll need to make some config changes.

Do you think your 5.10 testing branch is ready for this? Are there any swconfig to DSA migration guides or documentation i should look at before i jump in?

Otherwise I'll dive right in and post questions here if/when I get stuck.

Thank you very much for doing this.

Hopefully the branch first gets rebased on the current master, as right now it reflects the Openwrt master (and generic 5.10 stuff) as of March 1st.

The pr doesn't apply on master?

I meant that if somebody compiles directly from your branch, he misses the other commits of the last two weeks, as the branch is currently based on two-week old code.

2 Likes

as long as the relavent commits are fairly obvious, i'll try to cherry pick them from @ansuel's branch and apply on top of current master. Unless that's not helpful of course...

@hnyman I wanted to try DSA on my R7800 that I am using as Switch and WiFi AP. I tried your build R7800-master-r16173-3d1ea0d77f-20210312-2210-sysupgrade.bin but my R7800 went into boot-loop. I had to revert back to 21.02-SNAPSHOT build from https://downloads.openwrt.org/releases/21.02-SNAPSHOT/targets/ipq806x/generic/ using TFTP recovery method.

Any idea why it went into boot-loop? Also I am not sure if this is something I should post here or in Build for Netgear R7800. Thank you for your builds.

Will Kernel 5.4 in 21.02 (when officially released) support DSA in R7800? I see DSA is one of the release goals for 21.02 but your patches are for Kernel 5.10 in 'master' branch.

Will setting VLAN ID's be supported in Kernel 5.4 DSA in 21.02? Thank you for your work in enabling DSA in R7800.

AFAIK 21.02 has already been branched... so no. 21.02 will still use the swconfig driver.
5.4 qca8k driver doesn't support vlan (it should be in software)
5.10 has support for it.

Can you please elaborate on the above sentence? I am confused. I am not a developer so I am not fully aware of software intricasies.

The switch supports vlan handling but the dsa driver has support for it only in kernel 5.10
I'm not 100% sure about this but I think the kernel can still handle vlan in software using the cpu to process the packet.
(but in any case next openwrt version will use 5.10 as the main kernel... so 5.4 supports dsa just to not complicate things and have the same files across different kernel version)

Oh, so from what I understand, if I use VLAN's with kernel 5.4 DSA, the packets have to be processed by the main CPU. But in kernel 5.10 DSA, VLAN's are handled directly in the switch driver/hardware (is this software/hardware offloading?) and the CPU is not used for processing VLAN packets. Is my explanation correct?

I thought with 21.02 branched, all devices in 21.02 will stick with kernel 5.4 and only 'master' branch moves to kernel 5.10.

No idea what happened for you. I just tested by reflashing that build to my R7800, without settings so that new defaults to be created. Works quite ok.

 OpenWrt SNAPSHOT, r16173-3d1ea0d77f
 -----------------------------------------------------
root@router1:/# uname -a
Linux router1 5.10.20 #0 SMP Fri Mar 12 19:52:01 2021 armv7l GNU/Linux

Note that you can't sysupgrade with settings and you can't restore settings afterwards. (You can manually restore them selectively, but old network settings can brick the router)

(keeping settings doesn't cause bootloop at worst you lose ethernet connection but wifi would still work)

Yes, Ansuel meant the next future release by that "next release". 21.02 will remain with 5.4.

Terminologically 21.02 is currently difficult as it has already branched but there are no formal releases, yet.

1 Like