Netgear R7800 exploration (IPQ8065, QCA9984)

I have a question about your forays into sqm. I have a c2600, so pretty close to your hardware, and sqm seems to work fine, except one glitch. Youtube goes absolutely stupid haywire - it will always drop down to 360p and will refuse to stream in any speed that resembles fast. Disabling sqm fixes it immiediately, and no, doesn't matter if i use fq_codel, or cake, or any of the shipped presets. What's even stupider is that transfers and benchmarks work perfectly fine. Can you replicate this in any way on your end?

[quote="npr, post:15, topic:285"]
Youtube goes absolutely stupid haywire - it will always drop down to 360p and will refuse to stream in any speed that resembles fast
[/quote]I have not noticed anything like that. With R7800 and SQM (simple/fq_codel) I can watch 1080p videos from youtube just fine. Works ok with Firefox, IE11 and Edge.

I've found a frequency table in qsdk repository that differs from ours.
https://source.codeaurora.org/quic/qsdk/system/openwrt/tree/arch/arm/boot/dts/qcom-ipq8064-v3.0.dtsi?h=korg/linux-3.4.y/release/arugula_bb_cs

With upstream kernel driver device seems to choose pvs bin 4, parsed from efuses (kind of nvmem) that is absent in that table. But according to driver in that qsdk repo for ipq8065 default is pvs bin 0.

So for testing purposes I've adjusted pvs bin 4 in lede to reflect pvs bin 0 in qsdk.


I'm running it right now, but I dont use qos to test it's behavior if it's fixed. This is the last difference from ipq8064 devices that may affect performance. In ipq8064 pvs bin 0 is chosen in lede automatically.

Please test this.
The point is that ipq8064 units do not suffer from that qos problem and I'm trying to figure out what can cause it by comparing differences between device trees.
Ipq8064 devices use those voltage values with correction to 1.4ghz top freq instead of 1.7ghz.
I've ran it for 3 days without issues and that should be safe as it's within accepted for ipq8065 range.

I'm running the latest lede snapshot on an r7800 now. Seems a formidable device.
only thing i'm seeing in the logs currently is this:

[62665.535785] ath10k_pci 0001:01:00.0: received unexpected tx_fetch_ind event: in push mode
[62665.535858] ath10k_pci 0001:01:00.0: received unexpected tx_fetch_ind event: in push mode
[62665.543055] ath10k_pci 0001:01:00.0: received unexpected tx_fetch_ind event: in push mode
[62665.551125] ath10k_pci 0001:01:00.0: received unexpected tx_fetch_ind event: in push mode
[67835.085170] ath10k_pci 0001:01:00.0: received unexpected tx_fetch_ind event: in push mode

quick google shows me: http://lists.infradead.org/pipermail/ath10k/2016-September/008448.html
and:
http://svn.dd-wrt.com/ticket/5666

But if i check my firmware build, the system seems already be using this firmware version, so the issue is not yet properly resolved?

anyone any ideas?

To answer the question by @Tusc in Build for Netgear R7800 I ran the OpenSSL benchmarks with my LEDE 17.01 release branch build:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               7653.87k    28352.66k    79638.44k   142638.42k   185739.95k
sha1              8427.71k    33833.88k    97973.85k   188711.90k   258015.12k
des cbc          23428.22k    24085.74k    24288.17k    24244.22k    24199.17k
des ede3          8499.86k     8619.03k     8676.17k     8640.17k     8634.37k
aes-128 cbc      51520.66k    58131.61k    60423.08k    60828.33k    60738.22k
aes-192 cbc      46107.37k    48218.67k    52193.02k    52509.70k    52532.57k
aes-256 cbc      43055.24k    46332.63k    47803.65k    47899.31k    47934.12k
sha256           19601.95k    51452.35k    99644.33k   130418.35k   143253.50k
sha512            7794.49k    31499.69k    47606.87k    66959.70k    76054.53k
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.007564s 0.000168s    132.2   5944.7
                  sign    verify    sign/s verify/s
dsa 2048 bits 0.001635s 0.001682s    611.7    594.7

Wiki format:

| r3006 | ARMv7 Processor rev 0 (v7l) | 6.00 | ARMv7 Processor rev 0 (v7l) | 56.15 | Qualcomm (Flattened Device Tree) | 1.0.2j | 142638420 | 188711900 | 130418350 | 66959700 | 24244220 | 8640170 | 60828330 | 52509700 | 47899310 | 132.2 | 5944.7 611.7 | 594.7 |

seeing another issue with the ath10k driver. Anyone else seen this as well?:
(or know where to properly let the maintainers know?)

[432063.937009] ath10k_pci 0001:01:00.0: received unexpected tx_fetch_ind event: in push mode
[444459.011125] ath10k_pci 0000:01:00.0: firmware crashed! (uuid 3ba8fc67-fd2a-48dd-99a7-78ee3bab0a54)
[444459.011238] ath10k_pci 0000:01:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
[444459.019025] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[444459.035241] ath10k_pci 0000:01:00.0: firmware ver 10.4-3.3-00102 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param crc32 6120b2da
[444459.037475] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 5f733fb2
[444459.049410] ath10k_pci 0000:01:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal file max-sta 512 raw 0 hwcrypto 1
[444459.058989] ath10k_pci 0000:01:00.0: firmware register dump:
[444459.066443] ath10k_pci 0000:01:00.0: [00]: 0x0000000A 0x00000000 0x0099F301 0x00000000
[444459.072143] ath10k_pci 0000:01:00.0: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.079955] ath10k_pci 0000:01:00.0: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.087941] ath10k_pci 0000:01:00.0: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.095928] ath10k_pci 0000:01:00.0: [16]: 0x00000000 0x00000000 0x00000000 0x0099F301
[444459.103933] ath10k_pci 0000:01:00.0: [20]: 0x00000000 0x00401B40 0x00000000 0x00000000
[444459.111901] ath10k_pci 0000:01:00.0: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.119887] ath10k_pci 0000:01:00.0: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.127871] ath10k_pci 0000:01:00.0: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.135859] ath10k_pci 0000:01:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.143845] ath10k_pci 0000:01:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.151829] ath10k_pci 0000:01:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.159817] ath10k_pci 0000:01:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.167802] ath10k_pci 0000:01:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.175788] ath10k_pci 0000:01:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
[444459.287312] ieee80211 phy0: Hardware restart was requested
[444461.763924] ath10k_pci 0000:01:00.0: device successfully recovered

[quote="johnnysl, post:21, topic:285"]
seeing another issue with the ath10k driver. Anyone else seen this as well?:(or know where to properly let the maintainers know?)
[/quote]Haven't seen it on my device.

The correct place to report it is in
https://bugs.lede-project.org/

Try this https://github.com/dissent1/r7800/commit/9edae9438b5bf7792434fa8ade24307aa7637ea5

Thanks, will have a look

ehm.i thought this would be an ath10k issue, requiring feedback directly to the blob developers.

will test the new blob that dissent1 pointed out first, if that fixes it, we can do a simple pull request.

You may also look at this: https://github.com/paul-chambers/netgear-r7800/tree/eeac2e10190f6f45e32e4c7012c4babc351898d8/package/qca-ssdk if you are interested in Hardware NAT

1 Like

Ok, replaced the ath10k Makefile with yours, but the new ath10k firmware failed to load on boot. Have currently swapped back to default Lede build again.

Weird stuff, I'm testing this new firmware for 3-4 days already without issues. dd-wrt has also switched to this one, because it has 80+80 mode fixed.

Quite strange, dmesg showed that the driver failed to load the firmware, as if it was the wrong type or something.
only thing i did was a rm Makefile and a wget Makefile from your github and recompile.

What are your wireless settings?

That doesn't matter as it already fails during the boot phase when the driver gets loaded.

but european country,
2.4ghz: channel 6, 17dbm, 20mhz
5ghz: channel 120, 20dbm, 80mhz AC

Will try to test some more later this week.

On working router try to manually replace latest firmware-5.bin (3.4-00068) and board-2.bin in /lib/firmware/ath10k/... folder and reboot

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/tree/ath10k/QCA9984/hw1.0

Have you tried other channels, country? Maybe it has smth to do with dfs feature failing during firmware initialisation?

Think i found the issue. a wget of the makefile gives me a file with 2400 lines somehow, where i should get 302 lines.
so i've now manually cut and paste the differences, and recompiled. Lets see how that works.

You can also download any Github commit by just adding ".patch" at the end:

wget https://github.com/dissent1/r7800/commit/9edae9438b5bf7792434fa8ade24307aa7637ea5.patch

You can apply that patch easily. No need for manual editing...

1 Like