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