This gist has the dmesg (burried in the "logcat" file), regulator_summary (at the end of the "logcat" file), /etc/config/network, and excerpt from /etc/config/system that i'm using.
Note the dmesg and other info in logcat is out of sync with /etc/config/network config file as stp and igmp snooping are currently enabled. I've done a few reboots just to test some things and for now I leave eee disabled.
HTH
No issues after just under 24 hrs up on 5.10.26 with dsa. I did re-enable eee for all ifs for about half of the latter part of that and did not experience issues; hence its not clear to me that eee was/is my issue.
Due to my family's need for reliable service on weekdays, I've gone back to 5.4 for now but I'll see if I can't test again next weekend.
could be that half an hours is not enough time to trigger any eee problem. So you confirm that with eee disabled, the syslog was empty of random port dropped?
I see no random port drops in syslog during the most recent 22 hr continuous uptime test (with or without eee enabled).
Thinking about the network loss I experienced initially, I recall that it started after I moved two of the physical ethernet cables (exchanged lan1 and lan4 - my trunk extension line to a downstream AP). After that, wireless and wired devices on the r7500v2 lost internet (i.e. the r7500v2 seem to lose connection on the trunk line wan port going to the router).
It would be nice to know if there is something one can do to initiate the issue so I'll try this again in about a week.
Sure take your time. Kernel 5.10 is no longer tied to dsa so we have more time to test this.
Anyone else seeing high drop in temperature reporting after 5.10 ?
Judging by the system load if anything it is slightly higher after 5.10 buld activation.
For whatever reason my box is not reporting earlier processor usage after 5.10 activation.
Understand there's new tsens patch involved but not sure whether this is because of that and which one is reporting correctly, before or after...
Could be the tsens patch or the fact that the voltage is scaled with 5.10 and less heat is generated?
I actually don't know...
@Ansuel there's a problem when I try to do a rebase.
First, rewinding head to replay your work on top of it...
Applying: ipq806x: copy kernel 5.4 patches to 5.10
Applying: ipq806x: use newer tsens patch
Applying: ipq806x: fix missing clk and reset
Applying: ipq806x: backport mtd adm and smem driver
Using index info to reconstruct a base tree...
M target/linux/ipq806x/patches-5.4/0031-mtd-add-SMEM-parser-for-QCOM-platforms.patch
.git/rebase-apply/patch:1430: space before tab in indent.
tristate "QCOM BAM DMA support"
.git/rebase-apply/patch:1431: space before tab in indent.
depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
.git/rebase-apply/patch:2351: trailing whitespace.
--
.git/rebase-apply/patch:2384: space before tab in indent.
'FIS directory' images, enable this option.
.git/rebase-apply/patch:2385: trailing whitespace.
warning: squelched 27 whitespace errors
warning: 32 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Removing target/linux/ipq806x/patches-5.4/0061-mtd-rootfs-conflicts-with-OpenWrt-auto-mounting.patch
CONFLICT (modify/delete): target/linux/ipq806x/patches-5.4/0031-mtd-add-SMEM-parser-for-QCOM-platforms.patch deleted in ipq806x: backport mtd adm and smem driver and modified in HEAD. Version HEAD of target/linux/ipq806x/patches-5.4/0031-mtd-add-SMEM-parser-for-QCOM-platforms.patch left in tree.
Removing target/linux/ipq806x/patches-5.10/0031-mtd-add-SMEM-parser-for-QCOM-platforms.patch
error: Failed to merge in the changes.
Patch failed at 0004 ipq806x: backport mtd adm and smem driver
Interesting and highly appreciated if that is the case.
problem is that it can also be the sensor not calibrated... i don't have a thermal probe so I tried to write the driver with the new implementation in a way that is very similar to the old.
Can you observe the temperatures with and without the voltage scaling changes to see if the voltage scaling has an affect? I think it would be interesting to know.
Could someone with an ASRock G10 or an Edgecore ECW5410 post cat /proc/mtd with a plain master or older release image - and then with the pending kernel v5.10 PR (and actually using kernel v5.10)?
I'm mostly interested in (potentially-) confirming that the qcom-smem derived partition labels are displayed as lower case with kernel v5.10 (while they were upper case before).
Just as an info... I cleared the dsa draft pr. From some low uptime (15+ hours on 2 router) the problem related to port dropping seems to be fixed. (as always I need more testing for this)
Also in this pr there are patches to enable second cpu port and to mimic the swconfig configuration.
U am wondering if anyone has successfully rebased the nss-qsdk10.0 patch set into the 5.10 kernel for R7800? I look at your github, @Ansuel but did not find a branch.
I'm still working on stabilizing the dsa driver... anyway as I already said in another post 5.10 has lots of changes to the offload api and the nss patch require major changes to be adapted. The porting won't be easy 
OK, thanks for the reply and for all the work you do, sir!
Now when this PR nearing to be included to master at least I can vouch for stability.
root@R7800:~# uname -a && uptime
Linux R7800 5.10.26 #0 SMP Fri Apr 2 08:32:03 2021 armv7l GNU/Linux
21:09:58 up 33 days, 22:58, load average: 0.12, 0.21, 0.18
Standard usage: web, daily Teams/whatsapp/messenger calls, torrenting up to 450Mbps down with 10k connections etc.
eth0.2 Link encap:Ethernet HWaddr DC:EF:AA:BB:CC:DD
inet addr:aaa.bbb.ccc.ddd Bcast:aaa.bbb.ccc.ddd Mask:255.255.192.0
inet6 addr: fe80::deef:9ff:aabb:abcd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2527820070 errors:0 dropped:0 overruns:0 frame:0
TX packets:208323950 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:850553413624 (792.1 GiB) TX bytes:129159236458 (120.2 GiB)
Haven't got this kind of uptimes for ages and logs are clean.
Excellent work @Ansuel , thanks!
wow 33 days... that's a lot AHHAHA
Looks like the pull request has been merged into master branch. Does it mean future MASTER SNAPSHOT builds at https://downloads.openwrt.org/snapshots/targets/ipq806x/generic/ will have kernel-5.10 instead of kernel-5.4?
@Ansuel Thanks for your great work.
I need to check but in theory nope... it's still as a testing kernel
So merged to master but it's still required to compile own image to use the new kernel. But let me check