Anyone here that can give me a honest comparison between the normal ath10k and the ath10k-ct drivers? i'm currently holding off on the -ct ones and wondering if they are good enough already to be used as a daily driver?
ath10k-ct problem with frequent disconnection with some device (s8 for example )
There's an issue with the default ath10k-ct firmware for qca9984 that leads to miserable speeds when 802.11w is enabled. However, I'm running a beta firmware that fixes this issue.
Default firmware:
http://candelatech.com/downloads/ath10k-9984-10-4/firmware-5-ct-full-htt-mgt-community-11.bin-lede.001
Beta firmware:
http://candelatech.com/downloads/ath10k-9984-10-4b/ath10k-fw-beta/firmware-5-ct-full-htt-mgt-community.bin
EDIT: added link to newer beta firmware.
Also watching this. And seems ath10k-ct has some issues. Anyone know why using ath10k-ct as default?
I believe the reason behind the change to ath10k-ct as default is that the developer/maintainer is far more responsive when it comes bug reports and feedback in general than qca has ever been.
Hi there. I had it running LEDE 17.01.2 and it was rock solid, but after upgrading to 18.06.1 the device is no longer stable. wifi is not stable and I've even had the device itself needing a reboot (and blinking light). For the most part, it is stable at least a few days until it just requires a reboot. I've read through the thread and it seems there are some problems, but just to be clear: Do you all have the same experience with 18.06.1? Is there any nightlies that are (more) stable? I don't want to go back to 17.x since I like the repartioned space.
I am also having stability problems with 18.06.1 compared to v17, although my issues are slightly different to what I've seen described by others. At random intervals (2-7 days), I will lose access to the LAN and WAN connections but wireless access (ssh and luci) is fine. Rebooting corrects the issue. I've configured watchcat to reboot if this happens when I am not at home. Unfortunately nothing's logged to indicate what the problem might be. If there is a way to capture more useful debugging information I'd be happy to do that.
Interesting. I've randomly lost access to the Web UI after approx. 48h of uptime, but I can still access the internet and LAN. Can't access it via WiFi. Reboot didn't help though; I guess it's softbricked. I suspect a configuration issue though. I'm gonna TFTP flash tonight, start from scratch and see, if it happens again.
//Edit: I think it was a configuration error on my end. 3d uptime, everything smooth after configuration from scratch. Wireless is stable, Web UI is stable, performance is great as expected. Using 18.06.1.
WiFi is rock-solid here (German region). By any chance, did you set 160MHz width? As it used to be the culprit quite often. Also, are you using irqbalance? I had stability issues in the past using irqbalance; stopped using it ever since.
Just checked a few days ago. It was set on 80mhz and manually set to channel 36. Not using irqbalance.
A couple of things I observed:
The channel has to be set manually. Automatically does not work. I changed it from 36 to 44 and now it has been stable a few days. 160mhz does not work either, and channels above 44 (didn't test every channel though) didn't work either.
Note that I have rolled my own 18.06.1 release from the imagebuilder.
Hi folks, I am trying to run a sysupgrade to version 18.06.1 on my R7800, but the device has been flashing (power led blinking for the last 30 minutes), is it possible to roll it back or is there any mechanism that auto rolls back an ongoing upgrade after a certain timeout?
If you're coming from the OEM firmware or OpenWrt/ LEDE <18.06.1, you need to use tftp for installing OpenWrt due to a changed partition layout, please see the wiki or earlier parts of this thread for details.
Thanks for pointing that out, I wasn't aware of those changes 
Can I safely interrupt the flashing? Isn't turning it off and on during this long-running flashing going to brick it?
I have just digged deeper into tftp, I will work with it to debrick it, thanks 
I just noticed the same errors happening again in the log using the latest build:
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.363456] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.363487] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.370683] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.378836] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.386940] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.395151] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.403299] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.411484] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.419636] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
Mon Oct 29 18:30:42 2018 kern.warn kernel: [52395.427727] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push modeSeems like there's a new firmware file from 2 days ago
Changing channel seemed to make it a little more stable. But eventually it crashed. Both wireless and ethernet stopped working and I had to reboot.
How exactly do you build with this updated firmware? Do you simply unroll kvalo's ath10k git repo into a separate folder and the copy the files over to build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/root-ipq806x/lib/firmware/ath10k/QCA9984 and then run make ? What is the best practice I wonder?
I did some manual editing this time and copied the firmware-5.bin file to the firmware directory.
I'm sure someone with more git/patch knowlege than me can tell you a better way.
This patch might help you a bit.
Also this one should be helpful, but they are both for old sources. This is where I manually edited instead.
You also need to configure the kernel of course.