Hi @ACwifidude , yes, I'm using the config on kernel5.10-nss-qsdk11.0 branch.
It seems your patches did not cover kernel5.10-nss-qsdk11.0 branch.
I still wonder why not many ea8500 users report this issue, maybe there are 2 types hardware in the market. After applied your patches, the other users will lost LAN connections, please note my ea8500 is Hong Kong version.
mine is not hong kong but I have the same thing
Only people who have done a factory reset will have switch issues. If you upgrade and don't do a reset of settings the switch works fine.
One fact of my hong kong version is, cannot install openwrt from any linksys factory fw, but uart only.
This is new for me, did not know it, unreasonable.
one thing that I have noticed and it is repeated in almost all the compilations. For example, in the current one, you install it, after finding a stable configuration, it lasts me 12 days without restarts, although on day 9 I have to restart Wi-Fi 5ghz because it crashes, on day 12, the device restarts. Well, now on day 5 the wifi fails again, this time both networks, possibly in a couple of days it will suffer a restart. What I mean, that time passes and it seems that the router is corrupting. Greetings.
I don't think the original NSS source is bug free on it's own.
Do you really need NSS? You can achieve about 900Mbit with packet steering and irqbalance in a normal build.
I use irqbalance and I know what it is, but the other doesn't ring a bell. sqm? actually my connection is 300/900, and i use nss because the router seems faster in general.
In LuCi it's under Network -> Interfaces > Global network options
Thanks, I'm investigating something about Wi-Fi, nonsense, but it seems to me that it was the cause of the network block.... let's wait as long as necessary to see what happens
Added g10, “NSS tx to short” log error fix, and small tweaks to the ea8500 in today’s master build.
R7800 has ramoops by default. Will possibly look to add that by default for the ipq8064 devices. Will have to evaluate .dts files to see if it is easy to implement at a high level without breaking anything (maybe in the qcom-ipq8064-v2.0.dtsi)
Ex: qcom-ipq8065-nighthawk.dtsi
ramoops@42100000 {
+ compatible = "ramoops";
+ reg = <0x42100000 0x40000>;
+ record-size = <0x4000>;
+ console-size = <0x4000>;
+ ftrace-size = <0x4000>;
+ pmsg-size = <0x4000>;
+ };
FYI, I've done it on the r7500v2 in its specific dts file in master, works fine.
Bleeding edge, by my standards! Thank you very much @ACwifidude !
Two questions:
The NSS cores are already activated without any modifications? How can someone check the speed improvements?
Is NSS planned to arrive to the R7800 stable ufficial repository? If it's a matter of weeks or months, I can live with your custom build, and then upgrade to the ufficial, simple and noobproof stable build, perhaps.
I'm sorry if these are stupid questions...but running linux on these boxes is very exciting and quite complex at the same time.
May you live long and healthy, Chris.
Self-answer to this (maybe):
root@OpenWrt:/etc/init.d# cat /proc/interrupts
CPU0 CPU1
16: 994162 434867 GIC-0 18 Edge gp_timer
18: 37709 0 GIC-0 51 Edge qcom_rpm_ack
19: 0 0 GIC-0 53 Edge qcom_rpm_err
20: 0 0 GIC-0 54 Edge qcom_rpm_wakeup
26: 49 0 GIC-0 241 Level ahci[29000000.sata]
27: 0 0 GIC-0 210 Edge tsens_interrupt
30: 283376 0 GIC-0 202 Level adm_dma
33: 11199764 0 GIC-0 245 Level nss
34: 0 236313 GIC-0 264 Level nss_queue1
35: 10144467 0 GIC-0 246 Level nss
36: 0 0 GIC-0 265 Level nss_queue1
37: 0 0 GIC-0 130 Level bam_dma
38: 0 0 GIC-0 128 Level bam_dma
40: 0 0 PCI-MSI 0 Edge aerdrv
42: 0 0 PCI-MSI 134217728 Edge aerdrv
43: 16 0 GIC-0 184 Level msm_serial0
44: 2 0 msmgpio 6 Edge keys
45: 2 0 msmgpio 54 Edge keys
46: 2 0 msmgpio 65 Edge keys
47: 0 0 GIC-0 142 Level xhci-hcd:usb1
48: 0 0 GIC-0 237 Level xhci-hcd:usb3
49: 1666121 0 PCI-MSI 524288 Edge ath10k_pci
50: 1805485 0 PCI-MSI 134742016 Edge ath10k_pci
IPI0: 0 0 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 106487 910196 Rescheduling interrupts
IPI3: 101 58 Function call interrupts
IPI4: 0 0 CPU stop interrupts
IPI5: 404946 282895 IRQ work interrupts
IPI6: 0 0 completion interrupts
Err: 0
root@OpenWrt:/etc/init.d#
Credits to @lesandie for this.
NSS is active automatically.
21.02 snapshot is the latest 21.02 (stable) build. Snapshot just means it is the latest in the 21.02 branch (master is the “trunk” of the tree and different, master “snapshot” is the absolute bleeding edge). The developers pick points where they tag 21.02 snapshot as a release, ex: “21.02.2” and release it like that with no further additions. My build captures the latest 21.02 so it will always be a little ahead of the latest stable build but is still in the stable branch of development.
Post #2 has tips and tricks to recreate the build, further optimize it, and install additional packages. Kmods don’t install like normal so in my repository I have all the additional kmods available for install.
Proof of my ingenuity:
root@OpenWrt:/# opkg install https://github.com/ACwifidude/openwrt/blob/openwrt-
21.02-nss-qsdk11.0/bin/targets/ipq806x/generic/packages/kmod-usb-printer_5.4.179
-1_arm_cortex-a15_neon-vfpv4.ipk
Collected errors:
* wfopen: https://github.com/ACwifidude/openwrt/blob/openwrt-21.02-nss-qsdk11.0/bin/targets/ipq806x/generic/packages/kmod-usb-printer_5.4.179-1_arm_cortex-a15_neon-vfpv4.ipk: No such file or directory.
* pkg_init_from_file: Failed to extract control file from https://github.com/ACwifidude/openwrt/blob/openwrt-21.02-nss-qsdk11.0/bin/targets/ipq806x/generic/packages/kmod-usb-printer_5.4.179-1_arm_cortex-a15_neon-vfpv4.ipk.
Use raw rather than blob in the url and it should work. 
Similar behaviour:
root@OpenWrt:/# opkg install https://github.com/ACwifidude/openwrt/raw/openwrt-2
1.02-nss-qsdk11.0/bin/targets/ipq806x/generic/packages/kmod-usb-printer_5.4.179-
1_arm_cortex-a15_neon-vfpv4.ipk.
Unknown package 'https://github.com/ACwifidude/openwrt/raw/openwrt-21.02-nss-qsdk11.0/bin/targets/ipq806x/generic/packages/kmod-usb-printer_5.4.179-1_arm_cortex-a15_neon-vfpv4.ipk.'.
Collected errors:
* opkg_install_cmd: Cannot install package https://github.com/ACwifidude/openwrt/raw/openwrt-21.02-nss-qsdk11.0/bin/targets/ipq806x/generic/packages/kmod-usb-printer_5.4.179-1_arm_cortex-a15_neon-vfpv4.ipk..
I installed package ip-full, as indicated in post no.4 here, but didn't do anything else. Maybe a reboot?
UPDATE:
trying to manually install local kmod packages leads to these results:
root@OpenWrt:~# cd /tmp/
root@OpenWrt:/tmp# opkg install kmod-usb-printer_5.4.179-1_arm_cortex-a15_neon-vfpv4.ipk
Installing kmod-usb-printer (5.4.179-1) to root...
Configuring kmod-usb-printer.
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.4.182-1-339cfd568e66679c36d2cea1452d7468) for kmod-nls-base
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.4.182-1-339cfd568e66679c36d2cea1452d7468) for kmod-usb-core
root@OpenWrt:/tmp# opkg install kmod-nls-base_5.4.179-1_arm_cortex-a15_neon-vfpv4.ipk
Package kmod-nls-base (5.4.179-1) installed in root is up to date.
root@OpenWrt:/tmp# opkg install kmod-usb-core_5.4.179-1_arm_cortex-a15_neon-vfpv4.ipk
Package kmod-usb-core (5.4.179-1) installed in root is up to date.
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.4.182-1-339cfd568e66679c36d2cea1452d7468) for kmod-nls-base
root@OpenWrt:/tmp#
Basically I'm trying to take a shortcut (not building a custom image with my packages), but I must be too much of a simpelsimple even to install "custom" packages from your repo. What a bag.
That is very, very unlikely to happen[0] - and would require massive amounts of development work and commitment.
--
[0] the only safe answer would be 'never', but certainly neither days, weeks nor months.
Interesting. How comes?
I'm not able to measure the privilege, but I understood NSS is quite a big thing, with these cores, and the owrt community is making quantum leaps in development. It seems terrific. It is working, for the little I can inspect.
The fact that such a feature will be offered always in a custom build (with all the complexities of going out of "stable") is unreasonable, for me.
That probably means (for me, the average user) going back to stable, loosing the offloading of NSS, and be happy with my easy packet installation through LuCi. 
Is the stable channel so careful, with implementation of quantum leaps?