Netgear R7800 exploration (IPQ8065, QCA9984)

Will never happen.

You should choose the least crowded channel because you cannot transmit when a node with a different SSID but still on the same channel is transmitting. This will only be fixed with Spatial Frequency Reuse in WiFi 6. This is why mesh / pod systems are popular. By being very bad at receiving wifi signals, the tiny pod does not notice any other networks on the same channel and is always free to transmit.

Why are they bad at it if they are also using WiFi as the backbone?

Surely the backbone signal is the strongest?

1 Like

I started having issues in master when some of wifi (either 5GHz or 2GHz) interfaces would not come up and it now takes several router reboots to get them all going. I have compared the output of wifi status in both cases and noticed that when the interfaces did not come up, the output was missing "ifname". Does anyone else experience something like this?

All it takes is to restart wifi and very often not all interfaces come up. There are some messages related to one of the interfaces.

daemon.notice hostapd: nl80211: Failed to remove interface wifi2 from bridge br-lan: No such device
user.notice root: ip link set dev wifi2 up
daemon.notice hostapd: wifi2: CTRL-EVENT-TERMINATING
daemon.err hostapd: hostapd_free_hapd_data: Interface wifi2 wasn't started

No issues at all here, besides irqs being on cpu0, usually building master every few days (dumb APs with WDS)

I see them on both:

cat /proc/softirqs 
                    CPU0       CPU1       
          HI:          0          0
       TIMER:      52612      46405
      NET_TX:     158422      42507
      NET_RX:    1066312     127217
       BLOCK:          0          0
    IRQ_POLL:          0          0
     TASKLET:     155917      47157
       SCHED:      50577      42227
     HRTIMER:          0          0
         RCU:      51073      42827
~# cat /proc/interrupts 
           CPU0       CPU1       
 16:    5756012    3375965     GIC-0  18 Edge      gp_timer
 18:     100953          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:          0          0     GIC-0 241 Level     ahci[29000000.sata]
 27:          0          0     GIC-0 210 Edge      tsens_interrupt
 30:     267787          0     GIC-0 202 Level     adm_dma
 31:      20799          0     GIC-0 255 Level     eth0
 32:    4776729          0     GIC-0 258 Level     eth1
 33:          0          0     GIC-0 130 Level     bam_dma
 34:          0          0     GIC-0 128 Level     bam_dma
 36:          0          0   PCI-MSI   0 Edge      aerdrv
 38:          0          0   PCI-MSI 134217728 Edge      aerdrv
 39:         14          0     GIC-0 184 Level     msm_serial0
 40:          2          0   msmgpio   6 Edge      keys
 41:          2          0   msmgpio  54 Edge      keys
 42:          2          0   msmgpio  65 Edge      keys
 43:          0          0     GIC-0 142 Level     xhci-hcd:usb1
 44:          0          0     GIC-0 237 Level     xhci-hcd:usb3
 45:   12755722          0   PCI-MSI 524288 Edge      ath10k_pci
 46:    6731031          0   PCI-MSI 134742016 Edge      ath10k_pci
IPI0:          0          0  CPU wakeup interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:     190700    3899812  Rescheduling interrupts
IPI3:         54    3837211  Function call interrupts
IPI4:          0          0  CPU stop interrupts
IPI5:    5124689     936173  IRQ work interrupts
IPI6:          0          0  completion interrupts
Err:          0

Could it be related to the addition of ubus reload? I had a similar issue to you on master when using the 5ghz wifi in client mode and frequently doing wifi reload. In my case a single reboot always fixed it. In the flyspray report, ifup lan always fixes it, so it's not an exact match, but the report mentions that netifd "gives up prematurely" which seems relevant.

Could be; I will keep an eye on that bug. I have for now switched to 19.07 and a non-ct firmware and things seem to be working way better.

R7800 19.07.0 with ath10k-ct-htt and 802.11r AP mode working nicely. The main router a wrt1900acs 18.06.5 with 802.11r working nicely too. The AP failed a couple of times and i prepared to upgrade the firmware as @huaracheguarache pointed out but i'll wait to see if it crashes again. Still 48h without problems.

Thanks for the tips!

Does anyone wants to help me with the k 5.4 ? Pretty stuck with the eth problem...

Where are your k5.4 commits?
And what exactly is the current problem? wired does not work at all?

Will push the commits this night to a repo.
Current problem: wired looks like it works (with ifconfig i can see that packets are actually transmitted) but for some reason they don't get received (or the device can't send data to the router). Problem is that no error is reported and I can't really diagnosticate the cause of this.

Tried with both the dsa driver upstream and the normal driver.
I haven't tried wireless network as i think there is something to fix with pcie (and it looks cause some system lock) so I'm trying a very base build.

I'll take a look if you think its far enough along to try on ipq8064; however, adding another device at this point could be unhelpful.

In any event it will take me at least a few weeks to get going.

Thankyou for working on this.

Well you will have a base to work on... will post here the repo

You could try the newly released beta firmware (I think the correct images are the ones with "full" in the name):

The release notes mention a crash fix: Jan 16, 2020: Fix crash that is probably related to AP rekey problem.

I did try the HTT variant of that beta firmware and the issue was still present. The original ath10k would crash at least once a minute (master). I reverted to 19.07 with the latest ath10k firmware/board files from kvalo and it is unbelievably stable after a few days. Everyone here stopped complaining about wifi. I am gonna run this for now.

1 Like

@hnyman @nmrh here the repo

Some kernel flag still needs to be included...
(also funny thing... i accidentally deleted the patch5.4 in the commit stage so i actually had to rework the patchset AGAIN....)


Any thoughts on starting a new thread?

I'm happy to start one but I'd think it be better if it is not device specific (say "ipq806x: kernel 5.4") and a respectable community member (like you or hnyman) is the op.

I suspect the frequent communication like what was done for 4.19 (which I like) would not be appreciated in this thread.