No connectivity after "ath10k_pci 0000:02:00.0: device successfully recovered"

For some months now I’ve seen a repeated problem where my connectivity dies, and although the devices remain connected to the wireless, they have no connectivity to the network unless they are forcefully re-connected.

Log messages found when this happens:

Jul 30 09:21:36 turris kernel: [486097.267028] ath10k_warn: 94 callbacks suppressed
Jul 30 09:21:36 turris kernel: [486097.267036] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 2, skipped old beacon
Jul 30 09:21:36 turris kernel: [486097.301236] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.335304] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 1, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.369541] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 2, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.403686] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.437760] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 1, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.471818] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 2, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.505951] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.540088] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 1, skipped old beacon
Jul 30 09:21:37 turris kernel: [486097.574296] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 2, skipped old beacon
Jul 30 09:21:41 turris kernel: [486102.004745] ath10k_pci 0000:02:00.0: device successfully recovered

ath10k firmware and driver

ath10k-firmware-qca988x - 2019-10-03-d622d160-1
kmod-ath10k - 4.14.236+4.19.193-1-1-67f70e2f39f8e8859c56d42cced0b0b3

ToS version

root@turris:/var/log# cat /etc/turris-version
5.2.3

There are some other threads about this same problem that have no answers, but they have all been stale since 2020.

I’ve migrated to the -ct driver and firmware to see if this behavior goes away.

UPDATE: confirmed -ct driver/module and firmware has solved this.

1 Like

Yesterday I had exactly same problem for the first time after many years.

Omnia 2020
TOS 6.2.2