I've just got this device and using the official image (vanilla, no sqm, no nothing) I was getting a lot of connection issues in the WAN, it would drop for about 2-15 secs every 2-5 minutes.
I've installed this build (stable 19.07) and the issue is gone, not sure what caused it though
Thanks!
master-r13951-6c57fb7aa9-20200726
I built a new master build, but it crashed pretty soon (in 15 minutes or so).
Not yet sure if that was an one-time mishap, or if something has got buggy in the last few weeks.
(Note that the uptime of the previous build master-r13881-bae4204e34-20200718 was 8 days, so that build is hopefully stable...)
r13938-15f585afc5 (with ldir's kernel bump from the mailing list) has been running fine on my nbg6817 for the last ~12 hours.
i'm running r13929-98b60b3efa on a dumb ap for the last 1.5 days without issues.
r13951-6c57fb7aa9-20200726 up for 10 hours now, no issues as far as I can tell. Before that I was on r13768-f632747704-20200709 for 14 days.
For what it's worth I've been running r13951-6c57fb7aa9 for 1d 2h 24m 42s so far without any issue.
The only entries in kernel log since finishing the boot are:
[ 3014.040548] ath10k_pci 0001:01:00.0: htt tx: fixing invalid VHT TX rate code 0xff
[68074.426634] ath10k_pci 0001:01:00.0: Invalid VHT mcs 15 peer stats
though no functionality seems to be affected.
master-r13978-d15b6e4895-20200730 with firmware-5.bin_10.4-3.10-00047 seems to run well for me. There's a new version of mac80211 that appears to have fixed a bunch of messages in dmesg/logread.
Spoke too soon. mac80211 crashed, same trace as reported before. Didn't take the device down, it recovered from it.
[60521.528498] ------------[ cut here ]------------
[60521.528604] WARNING: CPU: 0 PID: 767 at backports-5.8-rc2-1/net/mac80211/sta_info.c:1929 ieee80211_sta_update_pending_airtime+0x1f8/0x1fc [mac80211]
[60521.532185] STA xxxx AC 2 txq pending airtime underflow: 4294967248, 48
...
googling on the error shows that non-openwrt devices (general linux systems) also suffer from the same issue. I think it's something that will need to be fixed upstream, not something that Felix can repair himself.
Indeed. I was just hoping an update of mac80211 to 5.8 would have a fix for it, but it did not.
Just upgraded from hnyman 19.07 to latest trunk build...all good!
thxs for your hard work
I have added "irqbalance" at the topmost portion of the /etc/rc.common file, as the first command, right under the "# Copyright (C) 2006-2012 OpenWrt.org"
Is this ideal? Sorry, I'm also a noob as well.
You do not need that, just make sure the irqbalance service is enabled on system/startup page in the web interface. But in the past I suspected irqbalance to cause issues, personally I keep it disabled and just manually move a couple of IRQs in /etc/rc.local
# Manual IRQ affinity (cat /proc/interrupts)
# IRQ31=eth0, IRQ32=eth1
# 1=CPU0, 2=CPU1
echo 2 > /proc/irq/31/smp_affinity
echo 2 > /proc/irq/32/smp_affinity
hostpad/80211 seems to have issues with the inactivity timer. I see disconnects in the log from devices that are clearly active:
Sun Aug 2 08:49:39 2020 daemon.info hostapd: wlan0: STA 10:xxx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Aug 2 10:15:09 2020 daemon.info hostapd: wlan0-1: STA 38:xxx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
I know there's some option to disable it, just saying I didn't have to in the past.
The recent mac80211 and hostapd updates seem to be causing some wifi instability 
How is this load balancing if you are moving both to the same cpu? I only moved one and left the other as is...is that not right?
thxs
**edit..oh wait, forgot about wireless....so moving wan to cpu1 and that leaves wlan on eth0?
You can cat /proc/interrupts and see how the IRQs are distributed. Unfortunately we can't move IRQs 45 and 46 ath10k_pci.
Yes I know that....but just trying to understand, should I move both eth over to same cpu or like I previously said, move just one eth over?
These might be better threads for these types of questions:
https://forum.openwrt.org/t/r7800-performance/15780
https://forum.openwrt.org/t/netgear-r7800-exploration-ipq8065-qca9984/285
When upgrading to build 14023 the R7800 power LED started flashing orange and it didn't come back up after flashing like it normally does when upgrading to a new build. Powering off and back on manually got it going.
I've seen cases too when I reboot it from the command line it doesn't come back up, it restarts but can't connect to it. I have to pull the power.