Netgear R7800 exploration (IPQ8065, QCA9984)

[slh]

@hnyman

@slh

I haven’t gotten it to work (last test with v9, which didn’t work at all - although /sys/class/led/ & friends were present)

Sounds similar as my own result with v9 or later.

So far v8 is the best.

The reason for LED support being effectively broken on master was this:

generic: revert broken LED core patch

I now have v8 of the ath10k LED patches working nicely on the nbg6817, but I still can't get the current v12 working at all, which is weird - but the way compat-wireless (respectively backports/ mac80211) mangles config symbols, Makefiles and replaces the LED subsystem with its own stubs might have to do with it (still strange that v8 is working, but…).

[bouwew]

Did anyone succeed in building a firmware with kernel 4.14 now that the IPQ40XX/IPQ806X-split has been implemented in master?

[hnyman]

With the quite newest master builds, yesterday and r6554-eba3b028e4 today, I somehow get double ath10k LED registration for R7800 with the v8 patch and kernel log has "name collision" error:

root@OpenWrt:~# ls -1 /sys/class/leds/
ath10k-phy0
ath10k-phy0_1
ath10k-phy1
ath10k-phy1_1

kernel log:

[   61.600735] ath10k_pci 0000:01:00.0: Led ath10k-phy0 renamed to ath10k-phy0_1 due to name collision
[   61.699576] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   67.702746] ath10k_pci 0001:01:00.0: Led ath10k-phy1 renamed to ath10k-phy1_1 due to name collision

[slh]

I've noticed the same on my nbg6817, but LEDs are still working, so I didn't really dive into it (and I'm more curious why the newer revisions can't be integrated into backports).

ath10k-phy0 -> ../../devices/virtual/leds/ath10k-phy0
ath10k-phy0_1 -> ../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/leds/ath10k-phy0_1
ath10k-phy1 -> ../../devices/virtual/leds/ath10k-phy1
ath10k-phy1_1 -> ../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/leds/ath10k-phy1_1

[   88.019867] ath10k_pci 0000:01:00.0: Led ath10k-phy0 renamed to ath10k-phy0_1 due to name collision
[   94.268164] ath10k_pci 0001:01:00.0: Led ath10k-phy1 renamed to ath10k-phy1_1 due to name collision

[fantom-x]

Hi, does anyone know why the low-latency (preemptive) kernel does not boot on this target? I am using an R7800. The voluntary kernel preemption one boots just fine.

[fantom-x]

@fantom-x

Hi, does anyone know why the low-latency (preemptive) kernel does not boot on this target? I am using an R7800. The voluntary kernel preemption one boots just fine

I started a new thread about the kernel not booting. I would appreciate some advice on what I could be doing wrong. The boot log is in that thread.

[SOLVED] Kernel fails to boot: “BUG: scheduling while atomic” (ipq806x)

Hi I am trying to use a low latency kernel (from master) on Netgear R7800 and it is not booting. The same type of kernel boots fine if built from stable. I also tried a volunteer preemption kernel from both master and stable and the both work fine. The boot log is here. Does anyone have any insight into this? The very first log error in the log is BUG: scheduling while atomic: swapper/0/1/0x00000003 followed by a lot of BUG: scheduling while atomic: kworker/0:1/26/0x00000002. https://drive.go…

[slh]

v13 of the LED support patch, as revised by kvalo and with the fixes raised by brainslayer is now working for me on the nbg6817.

https://patchwork.kernel.org/patch/10327075/

With v13 there doesn't appear to be any duplication of the ath10k-phy sysfs nodes.

[hnyman]

@slh

v13 of the LED support patch, as revised by kvalo and with the fixes raised by brainslayer is now working for me on the nbg6817.

Great. Care to share the exact patch/changes/config changes that work for you? Or was it just the plain v13 applied as it is?

I will test v13 asap.

[hnyman]

@slh

v13 of the LED support patch

Thanks for providing your patch by email. It works ok for R7800.
Once the upstream gets v13 (or v14 or v15...) applied, your work will make it easier to have a clean backport from upstream ath10k and then the needed local modifications for ath10k LEDs.

I have a gut feeling that there will be a v14 with the feedback from Sebastian Gottschall taken into account, as kvalo has apparently simplified things a bit too much. So, hopefully the final upstream version minimises the need for local modifications here.

[shelterx]

Anyone know if this will help against bufferbloat?
I get a C on the dslreports bufferbloat test on a 100/100mbit connection. I also noticed that tcp segmentation offload seems to be off by default now.

[lesandie]

I would use SQM cake for dealing with Bufferbloat

[fantom-x]

@lesandie

I would use SQM cake for dealing with Bufferbloat

It is using 100% of a single core on my 50/10M connection, so I am not sure how that will help with 100/100M connection...

[lesandie]

1 core 100% usage?. That is aggressive.
I have a wrt1900acs/17.01 with SQM piece of cake for a 50/50mbit and the router never "sweats". Also with the R7800/17.01 no problems at all. I have more or less 10 devices connected at peak time streaming, browsing, gaming and no big deal!.

BTW in both routers tcp-segmentation-offload is on. So i get that in master tcp-segmentation-offload is off by default?

[fantom-x]

@lesandie

1 core 100% usage?. That is aggressive.

It is what it is.

@lesandie

BTW in both routers tcp-segmentation-offload is on. So i get that in master tcp-segmentation-offload is off by default?

I would want to know that too, but in R7800 it is all off by default.

[lesandie]

Well i can say that it is on in my r7800 build.

root@OpenWrt:~# ethtool -k br-lan
Features for br-lan:
rx-checksumming: off [fixed]
tx-checksumming: on
	tx-checksum-ipv4: off [fixed]
	tx-checksum-ip-generic: on
	tx-checksum-ipv6: off [fixed]
	tx-checksum-fcoe-crc: off [fixed]
	tx-checksum-sctp: off [fixed]
scatter-gather: on
	tx-scatter-gather: on
	tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
	tx-tcp-segmentation: on
	tx-tcp-ecn-segmentation: on
	tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: on [fixed]
tx-gso-robust: off [requested on]
tx-fcoe-segmentation: off [requested on]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: on
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: off [fixed]

But i'm using @quarky build

IPQ806x NSS Drivers

I'm starting a new thread to discuss the IPQ806x NSS subsystem drivers found on the CodeAurora's Git repository (https://source.codeaurora.org.) Over the past weeks, I managed to cobbled together a build for my Netgear R7800 that successfully activated both NSS CPU cores of the IPQ8065 SOCs. So far, my R7800 is running the following Qualcomm's drivers: qca-nss-gmac qca-nss-drv The changes I made to the lede-17.01 branch can be easily applied to IPQ8064 builds as well. It would be great if …

the build includes qcom-nss-gmac and qcom-nss-drv modules instead of the standard stmmac

[fantom-x]

@lesandie

But i’m using @quarky build

Is it running reliably?

[lesandie]

Yep i find it very stable, and the ping spikes are lower. But i guess your network is more "heavy duty" that mine so it is advisable that you test it more thoroughly.

Still we need to include the qcom-nss-ecm (enhanced connection manager) that will unlock the nss cores full potential, for example qdisk acceleration.

IPQ806x-Hardware-acceleration_v2.pdf

I've just needed to reboot it once in 26d due to a wifi crash. The rest of the time .. smooth operation.

[Ansuel]

sorry bug as far as i can see they didn't manage to make the nss core work... am i wrong?

[quarky]

@Ansuel

sorry bug as far as i can see they didn’t manage to make the nss core work… am i wrong?

Unfortunately, you’re correct. Still trying to figure out how the ARM CPU communicate with the NSS cores. Missing some driver, which I’m still trying to figure out.

Although the NSS driver is loaded, it looks to me that the apps fabric bus/clock is not initialised. So the NSS core CPU is not running the NSS firmware code. Kind of stuck at the moment.

[slh]

Take a look at the bootloader modifications by QCA, which might provide some insight, as NSS firmware is apparently already loaded from there (and cmdline).