This is part of a ticket that I raised here: https://github.com/greearb/ath10k-ct/issues/4#issuecomment-314165989
However, this looks like it has a lot broader problem than the ath10k-ct, or even ath10k in general.
We only get these errors:
kern.warn kernel: [ 1482.891420] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon
kern.warn kernel: [ 1487.252602] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon
kern.warn kernel: [ 1487.556625] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beaconwhen 2Ghz is under load (we replicate it doing an iperf test connected to the 2Ghz). Running the CPU up to 100% does not cause this behavior, but when we run certain systems of ours that call heavily into the kernel - anytime the kworker starts to get even the least bit burdened (over 30% CPU), while doing an iperf test connected to the 2Ghz channel, we get the ath10k errors.
Further, the odd thing is that these errors are on the 5Ghz code (ath10k), however, we only replicate this when connected to the 2Ghz band (ath9k). When we connect to the 5Ghz and put load from our systems and the iperf - it handles it fine. However, when we go back to putting load from our system + iperf on the 2Ghz band, we get the below errors.
We have seen this with any system that puts load on kernel calls - not just our systems. When the kworker gets at all burdened - this happens.
We have now confirmed this on the following build combinations:
LEDE 17.01 + ath10k (non-ct)
LEDE 17.01.2 + very latest ath10k-ct
LEDE 17.01.2 + ath10k (non-ct)
many, many other combinations
A couple of questions:
- Where are these calls getting generated from?
- What is the actual problem happening here?
- We are connected to the 2Ghz (ath9k). Why is the code erroring in the the ath10k code?
