Build for Netgear R7800

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!

1 Like

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...)

1 Like

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
...

https://bugs.openwrt.org/index.php?do=details&task_id=3204

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

1 Like

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
1 Like

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 :frowning:

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?

1 Like

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.

1 Like