I have not, unless it's in the latest snapshot.
It's included in latest snapshot.
btw i no longer use the ax3600, have not for quite some time.
i use 2x qnap 301w (IPQ8072A) and 1x nbg7815 (IPQ8074A).
even on these devices, i still see:
ath11k c000000.wifi: failed to flush transmit queue, data pkts pending X
in my logs. its pretty clear when it happens : when a device disconnects due to signal loss... eg: when i walk away from my home... or if i run between floors etc.
but the main issue i was having is not present on these devices (301w + nbg7815). even though i do see these messages in my log files, i do not experience the high ping loss until reboot issue i was most concerned with.
i do see a new qca firmware was released 2 weeks ago which might be a worthwhile upgrade.
Today I installed my AX3600 with OpenWrt SNAPSHOT, r25861-d997477775.
Setup as a wifi repeater, WDS-STA + AP. Uptime 10 hours.
Still getting the same - "ath11k c000000.wifi: failed to flush transmit queue, data pkts pending"
root@AX3600:~# logread -e flush
Wed Apr 10 13:00:08 2024 kern.warn kernel: [30980.942120] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 20
Wed Apr 10 13:00:39 2024 kern.warn kernel: [31011.262061] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 8
Wed Apr 10 13:01:40 2024 kern.warn kernel: [31071.981928] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 5
Wed Apr 10 13:01:47 2024 kern.warn kernel: [31079.261907] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 87
Wed Apr 10 13:05:55 2024 kern.warn kernel: [31327.581539] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 3
Wed Apr 10 13:06:00 2024 kern.warn kernel: [31332.701528] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 100
Wed Apr 10 13:06:05 2024 kern.warn kernel: [31337.821530] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 48
Wed Apr 10 13:06:10 2024 kern.warn kernel: [31342.941519] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 4
Wed Apr 10 13:06:16 2024 kern.warn kernel: [31348.061518] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 2
Wed Apr 10 13:06:21 2024 kern.warn kernel: [31353.181510] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 5
Wed Apr 10 13:09:43 2024 kern.warn kernel: [31555.021236] ath11k c000000.wifi: failed to flush transmit queue, data pkts pending 44
It has been a bit since I've been able to test...today I was able to determine that there is a pause on all wifi data when this error occurs. Noticable (1-3 second pause) when on a video call via wifi.
It would be indeed interesting how the wifi setup is looking and what clients (ac<->ax, ax<->ax) are here in play. I recognized this error in the past too (no WDS or sth. like that enabled). The error is also there if I run my devices with default wifi settings.
The issue disappears adding explicit:
he_su_beamformee='1'
he_bss_color='128'
for each radio.
I figured this out after tinkering around in the past. I cannot remember what brought me to this conclusion exactly. But I think I remember that during the development everyone enabled bss coloring with setting it to '8' explict and it was not enabled by default (even after release). Suddenly it became standard and it was set to the same value for all devices. Which does not make sense for me from a logical standpoint if you have other devices running the same channel and chipset around (it may be that I'm wrong here).
I just can wild guess here why this is an issue.
As this technology is meant to reduce crosstalk I can image this is a process adjusting constantly (which beam cannot be used due to crosstalk). So the driver is realizing that there is another device interfering and want to change the coloring.
I'm able to kind a force this issue just starting up a 2nd ipq807x based router. In most cases the client drops out from the 1st device with the message above.
just another fyi, since i last posted here i upgraded to the latest nss build ( IPQ807X NSS Build ).
i never see these messages anymore nor do i have any pauses etc.
if you are apt enough to compile your own build i highly recommend the nss build by qosimo ( https://github.com/qosmio/openwrt-ipq ).
its very stable and much more performant.
caveat : i use this on slightly higher end ipq807x devices, the 301w and nbg7815.... so i am unsure how this will perform on a lower end device like the ax3600 with 512 ram etc. mine all have 1gb.
3 Likes
absolutely @anom3 ...
Well, my comment was just meant as a possible workaround. I am aware that NSS build does not have certain bugs compared to vanilla. I am aware also that there will be propably never a fix for this bug. But not everbody can/wants to load a fork on its devices (for several reasons).
i did not mean to offend... just giving my insight.
of course load whatever you think is best.
its also possible that whatever made it stop is actually part of the ath11k driver and nothing to do with the nss build. so maybe it will roll into the next stable release.
1 Like
Don't worry. Personally I'm not offended that fast. I'm aware that for most ppl. english is not the native language. I just wanted to say that loading a fork is not a solution for the problem. Making sure it sounds less offending like this comment now. 
Hi, I saw this, may you please explain how you disabled SMPS?
That shit is killing my network, I desperately need to disable it in all my APs.
Tks!
its killing mine too, I found something maybe, will edit this post and re paste it here
interesting thread re: failed to flush error:
which cites this patch :
In my network I have two APs on the same SSID so I have clients that move around the house re-associating a lot with whichever one is closest, and this is calling flush a lot. And this seems to be contingent in the wifi issues with ath11k ?
Edit: wait, is this the patch anom3 already tried removing at the top and whilst it had some success it wasn't successful ? in which case, the next thing to try is the NSS build ? Or this bss coloring config (was that for every client, or on the router/AP ?) ? Or ... drop the router/AP in a bin and buy another one with different chipset .....