Warnings/errors in use with a QCA989x card

Warnings/errors in use with a QCA989x card

[Matthew Robbetts]

Hi all,

I’m sorry if the answer to this question is well known; my Google-fu is failing me in that case. My situation is as follows:

----------------------------------------------------------------------------------------------------------------

I recently bought a Doodle Labs ACE-DB-3 miniPCIe card for use as a wireless access point in my linux router (A HP microserver, running Gentoo Linux, with a 4.0.4-hardened kernel. No PaX/GrSecurity features are enabled in my build of this kernel).

Everything is set up and appears to work as expected. However, after a day or two of hostapd uptime, I see the below sorts of stuff in my dmesg. If left, this will happen a number of times, and eventually no wifi devices will be able to connect anymore.

Restarting hostapd appears to reinitialize everything satisfactorily — but of course this happens again within another day or so.

As I said, I am running the 4.0.4 kernel, along with 10.2.4.48 from kvalo’s GitHub repo.

Am I doing something stupid with this card?


Thanks!
Matt

----------------------------------------------------------------------------------------------------------------

[Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:06 2015] ------------[ cut here ]------------
[Thu Jun  4 11:07:06 2015] WARNING: CPU: 1 PID: 3517 at net/mac80211/sta_info.c:917 __sta_info_destroy_part2+0xd6/0x13f()
[Thu Jun  4 11:07:06 2015] Modules linked in: zfs(PO) zunicode(PO) zcommon(PO) znvpair(PO) spl(O) zavl(PO)
[Thu Jun  4 11:07:06 2015] CPU: 1 PID: 3517 Comm: hostapd Tainted: P           O    4.0.4-hardened-r1 #6
[Thu Jun  4 11:07:06 2015] Hardware name: HP ProLiant MicroServer, BIOS O41     07/29/2011
[Thu Jun  4 11:07:06 2015]  0000000000000009 ffff8803f878f578 ffffffff8177ab11 000000000000003c
[Thu Jun  4 11:07:06 2015]  0000000000000000 ffff8803f878f5b8 ffffffff8103cd21 0000000000000001
[Thu Jun  4 11:07:06 2015]  ffffffff81732b5c ffff880344f0b000 ffff88040cb9c680 ffff88040c1928c0
[Thu Jun  4 11:07:06 2015] Call Trace:
[Thu Jun  4 11:07:06 2015]  [<ffffffff8177ab11>] dump_stack+0x45/0x57
[Thu Jun  4 11:07:06 2015]  [<ffffffff8103cd21>] warn_slowpath_common+0x9c/0xb6
[Thu Jun  4 11:07:06 2015]  [<ffffffff81732b5c>] ? __sta_info_destroy_part2+0xd6/0x13f
[Thu Jun  4 11:07:06 2015]  [<ffffffff8103cdcf>] warn_slowpath_null+0x15/0x17
[Thu Jun  4 11:07:06 2015]  [<ffffffff81732b5c>] __sta_info_destroy_part2+0xd6/0x13f
[Thu Jun  4 11:07:06 2015]  [<ffffffff81732bea>] __sta_info_destroy+0x25/0x2f
[Thu Jun  4 11:07:06 2015]  [<ffffffff81732c82>] sta_info_destroy_addr_bss+0x37/0x57
[Thu Jun  4 11:07:06 2015]  [<ffffffff817424dc>] ieee80211_del_station+0x18/0x25
[Thu Jun  4 11:07:06 2015]  [<ffffffff8170de39>] nl80211_del_station+0xd7/0x11f
[Thu Jun  4 11:07:06 2015]  [<ffffffff81626c7e>] genl_family_rcv_msg+0x246/0x2b8
[Thu Jun  4 11:07:06 2015]  [<ffffffff81626d2d>] genl_rcv_msg+0x3d/0x60
[Thu Jun  4 11:07:06 2015]  [<ffffffff81626cf0>] ? genl_family_rcv_msg+0x2b8/0x2b8
[Thu Jun  4 11:07:06 2015]  [<ffffffff8162634a>] netlink_rcv_skb+0x45/0x88
[Thu Jun  4 11:07:06 2015]  [<ffffffff81626945>] genl_rcv+0x24/0x34
[Thu Jun  4 11:07:06 2015]  [<ffffffff81625e88>] netlink_unicast+0x104/0x18b
[Thu Jun  4 11:07:06 2015]  [<ffffffff8162620a>] netlink_sendmsg+0x2fb/0x319
[Thu Jun  4 11:07:06 2015]  [<ffffffff8110e232>] ? copy_from_user+0xba/0xe2
[Thu Jun  4 11:07:06 2015]  [<ffffffff815cfb32>] __sock_sendmsg+0x42/0x4d
[Thu Jun  4 11:07:06 2015]  [<ffffffff815d1490>] sock_sendmsg+0x37/0x49
[Thu Jun  4 11:07:06 2015]  [<ffffffff815d1ca5>] ___sys_sendmsg+0x1d9/0x268
[Thu Jun  4 11:07:06 2015]  [<ffffffff815d0de9>] ? move_addr_to_user+0x51/0x67
[Thu Jun  4 11:07:06 2015]  [<ffffffff815d1e7f>] ? ___sys_recvmsg+0x14b/0x1be
[Thu Jun  4 11:07:06 2015]  [<ffffffff815cefb9>] ? sock_destroy_inode+0x2b/0x2f
[Thu Jun  4 11:07:06 2015]  [<ffffffff815cef8e>] ? sockfs_dname+0x1c/0x1c
[Thu Jun  4 11:07:06 2015]  [<ffffffff81123823>] ? destroy_inode+0x36/0x4f
[Thu Jun  4 11:07:06 2015]  [<ffffffff81104f21>] ? kmem_cache_free+0x49/0xd5
[Thu Jun  4 11:07:06 2015]  [<ffffffff81125579>] ? __fget_light+0x27/0x48
[Thu Jun  4 11:07:06 2015]  [<ffffffff815d1fed>] __sys_sendmsg+0x3d/0x5b
[Thu Jun  4 11:07:06 2015]  [<ffffffff815d2018>] SyS_sendmsg+0xd/0x17
[Thu Jun  4 11:07:06 2015]  [<ffffffff8178201e>] system_call_fastpath+0x12/0x17
[Thu Jun  4 11:07:06 2015] ---[ end trace e4f43c81ea50a3f3 ]---
[Thu Jun  4 11:07:08 2015] ath10k_warn: 40 callbacks suppressed
[Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
[Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
[Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
[Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode
[Thu Jun  4 12:55:54 2015] br0: port 2(wlp2s0) entered disabled state
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:54 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:55:55 2015] ath10k_pci 0000:02:00.0: could not get mac80211 beacon
[Thu Jun  4 12:56:00 2015] ath10k_warn: 22 callbacks suppressed
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: failed to remove peer for AP vdev 0: -110
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: removing stale peer 04:db:56:e1:65:2f from vdev_id 0
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: removing stale peer 00:30:1a:4e:01:85 from vdev_id 0
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: received addba event for invalid peer_id: 148
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: received addba event for invalid peer_id: 148
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: peer-unmap-event: unknown peer id 148
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: peer-unmap-event: unknown peer id 9
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: peer-unmap-event: unknown peer id 25
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: peer-unmap-event: unknown peer id 57
[Thu Jun  4 12:56:00 2015] ath10k_pci 0000:02:00.0: peer-unmap-event: unknown peer id 89
[Thu Jun  4 12:57:52 2015] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[Thu Jun  4 12:57:52 2015] device wlp2s0 entered promiscuous mode
[Thu Jun  4 12:58:05 2015] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
[Thu Jun  4 12:58:05 2015] br0: port 2(wlp2s0) entered forwarding state
[Thu Jun  4 12:58:05 2015] br0: port 2(wlp2s0) entered forwarding state
[Thu Jun  4 12:58:20 2015] br0: port 2(wlp2s0) entered forwarding state
[Thu Jun  4 15:14:29 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:30 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_warn: 41 callbacks suppressed
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 15:14:35 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[Thu Jun  4 16:12:55 2015] ath10k_warn: 18 callbacks suppressed
[Thu Jun  4 16:12:55 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Michal Kazior]

On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera@gmail.com> wrote:
> Hi all,
>
> I’m sorry if the answer to this question is well known; my Google-fu is failing me in that case. My situation is as follows:
>
> ----------------------------------------------------------------------------------------------------------------
>
> I recently bought a Doodle Labs ACE-DB-3 miniPCIe card for use as a wireless access point in my linux router (A HP microserver, running Gentoo Linux, with a 4.0.4-hardened kernel. No PaX/GrSecurity features are enabled in my build of this kernel).
>
> Everything is set up and appears to work as expected. However, after a day or two of hostapd uptime, I see the below sorts of stuff in my dmesg. If left, this will happen a number of times, and eventually no wifi devices will be able to connect anymore.
>
> Restarting hostapd appears to reinitialize everything satisfactorily — but of course this happens again within another day or so.
>
> As I said, I am running the 4.0.4 kernel, along with 10.2.4.48 from kvalo’s GitHub repo.
>
> Am I doing something stupid with this card?
>
>
> Thanks!
> Matt
>
> ----------------------------------------------------------------------------------------------------------------
>
> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:06 2015] ------------[ cut here ]------------
> [Thu Jun  4 11:07:06 2015] WARNING: CPU: 1 PID: 3517 at net/mac80211/sta_info.c:917 __sta_info_destroy_part2+0xd6/0x13f()
> [Thu Jun  4 11:07:06 2015] Modules linked in: zfs(PO) zunicode(PO) zcommon(PO) znvpair(PO) spl(O) zavl(PO)
> [Thu Jun  4 11:07:06 2015] CPU: 1 PID: 3517 Comm: hostapd Tainted: P           O    4.0.4-hardened-r1 #6
> [Thu Jun  4 11:07:06 2015] Hardware name: HP ProLiant MicroServer, BIOS O41     07/29/2011
> [Thu Jun  4 11:07:06 2015]  0000000000000009 ffff8803f878f578 ffffffff8177ab11 000000000000003c
> [Thu Jun  4 11:07:06 2015]  0000000000000000 ffff8803f878f5b8 ffffffff8103cd21 0000000000000001
> [Thu Jun  4 11:07:06 2015]  ffffffff81732b5c ffff880344f0b000 ffff88040cb9c680 ffff88040c1928c0
> [Thu Jun  4 11:07:06 2015] Call Trace:
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8177ab11>] dump_stack+0x45/0x57
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8103cd21>] warn_slowpath_common+0x9c/0xb6
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732b5c>] ? __sta_info_destroy_part2+0xd6/0x13f
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8103cdcf>] warn_slowpath_null+0x15/0x17
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732b5c>] __sta_info_destroy_part2+0xd6/0x13f
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732bea>] __sta_info_destroy+0x25/0x2f
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732c82>] sta_info_destroy_addr_bss+0x37/0x57
> [Thu Jun  4 11:07:06 2015]  [<ffffffff817424dc>] ieee80211_del_station+0x18/0x25
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8170de39>] nl80211_del_station+0xd7/0x11f
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626c7e>] genl_family_rcv_msg+0x246/0x2b8
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626d2d>] genl_rcv_msg+0x3d/0x60
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626cf0>] ? genl_family_rcv_msg+0x2b8/0x2b8
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8162634a>] netlink_rcv_skb+0x45/0x88
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626945>] genl_rcv+0x24/0x34
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81625e88>] netlink_unicast+0x104/0x18b
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8162620a>] netlink_sendmsg+0x2fb/0x319
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8110e232>] ? copy_from_user+0xba/0xe2
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815cfb32>] __sock_sendmsg+0x42/0x4d
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1490>] sock_sendmsg+0x37/0x49
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1ca5>] ___sys_sendmsg+0x1d9/0x268
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d0de9>] ? move_addr_to_user+0x51/0x67
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1e7f>] ? ___sys_recvmsg+0x14b/0x1be
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815cefb9>] ? sock_destroy_inode+0x2b/0x2f
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815cef8e>] ? sockfs_dname+0x1c/0x1c
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81123823>] ? destroy_inode+0x36/0x4f
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81104f21>] ? kmem_cache_free+0x49/0xd5
> [Thu Jun  4 11:07:06 2015]  [<ffffffff81125579>] ? __fget_light+0x27/0x48
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1fed>] __sys_sendmsg+0x3d/0x5b
> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d2018>] SyS_sendmsg+0xd/0x17
> [Thu Jun  4 11:07:06 2015]  [<ffffffff8178201e>] system_call_fastpath+0x12/0x17
> [Thu Jun  4 11:07:06 2015] ---[ end trace e4f43c81ea50a3f3 ]---
> [Thu Jun  4 11:07:08 2015] ath10k_warn: 40 callbacks suppressed
> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
> [Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
> [Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
> [Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode

This is the dreaded tx credit starvation.

In some cases if disassoc+deauth is sent and target station is asleep
and unresponsive it'll cause firmware to stall causing ath10k timeouts
during sta_state station removal. Due to insufficient credits beacons
can't be sent for ~10 seconds, sta_state station removal fails causing
mac80211 call trace splat and later spurious kickout events because
peer was never removed from firmware.

There's no easy/sane fix for that, yet.

You can read more on the subject:

 http://thread.gmane.org/gmane.linux.kernel.wireless.general/121954
http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/638


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Ben Greear]

On 06/04/2015 10:17 PM, Michal Kazior wrote:
> On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera@gmail.com> wrote:

>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
>> [Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
>> [Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
>> [Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode
> 
> This is the dreaded tx credit starvation.

I have some fixes and work-arounds related to this issue in my kernels and CT firmware.

Possibly it would work better for you:

http://www.candelatech.com/ath10k.php

The beta-14 firmware is probably best at this point..I'll promote it to official
release soon.

> In some cases if disassoc+deauth is sent and target station is asleep
> and unresponsive it'll cause firmware to stall causing ath10k timeouts
> during sta_state station removal. Due to insufficient credits beacons
> can't be sent for ~10 seconds, sta_state station removal fails causing
> mac80211 call trace splat and later spurious kickout events because
> peer was never removed from firmware.
> 
> There's no easy/sane fix for that, yet.

I thought the newer upstream firmware had
support for mgt frames over normal packet transport instead of over
the WMI management interface?  Wouldn't that fix things?

Thanks,
Ben

> 
> You can read more on the subject:
> 
>  http://thread.gmane.org/gmane.linux.kernel.wireless.general/121954
> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/638
> 
> 
> Michał
> 
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Matthew Robbetts]

Hi Michal,

Thanks for your reply!

> On Jun 4, 2015, at 22:17, Michal Kazior <michal.kazior@tieto.com> wrote:
> 
> On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera@gmail.com> wrote:
>> Hi all,
>> 
>> I’m sorry if the answer to this question is well known; my Google-fu is failing me in that case. My situation is as follows:
>> 
>> ----------------------------------------------------------------------------------------------------------------
>> 
>> I recently bought a Doodle Labs ACE-DB-3 miniPCIe card for use as a wireless access point in my linux router (A HP microserver, running Gentoo Linux, with a 4.0.4-hardened kernel. No PaX/GrSecurity features are enabled in my build of this kernel).
>> 
>> Everything is set up and appears to work as expected. However, after a day or two of hostapd uptime, I see the below sorts of stuff in my dmesg. If left, this will happen a number of times, and eventually no wifi devices will be able to connect anymore.
>> 
>> Restarting hostapd appears to reinitialize everything satisfactorily — but of course this happens again within another day or so.
>> 
>> As I said, I am running the 4.0.4 kernel, along with 10.2.4.48 from kvalo’s GitHub repo.
>> 
>> Am I doing something stupid with this card?
>> 
>> 
>> Thanks!
>> Matt
>> 
>> ----------------------------------------------------------------------------------------------------------------
>> 
>> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:03 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:04 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:06 2015] ------------[ cut here ]------------
>> [Thu Jun  4 11:07:06 2015] WARNING: CPU: 1 PID: 3517 at net/mac80211/sta_info.c:917 __sta_info_destroy_part2+0xd6/0x13f()
>> [Thu Jun  4 11:07:06 2015] Modules linked in: zfs(PO) zunicode(PO) zcommon(PO) znvpair(PO) spl(O) zavl(PO)
>> [Thu Jun  4 11:07:06 2015] CPU: 1 PID: 3517 Comm: hostapd Tainted: P           O    4.0.4-hardened-r1 #6
>> [Thu Jun  4 11:07:06 2015] Hardware name: HP ProLiant MicroServer, BIOS O41     07/29/2011
>> [Thu Jun  4 11:07:06 2015]  0000000000000009 ffff8803f878f578 ffffffff8177ab11 000000000000003c
>> [Thu Jun  4 11:07:06 2015]  0000000000000000 ffff8803f878f5b8 ffffffff8103cd21 0000000000000001
>> [Thu Jun  4 11:07:06 2015]  ffffffff81732b5c ffff880344f0b000 ffff88040cb9c680 ffff88040c1928c0
>> [Thu Jun  4 11:07:06 2015] Call Trace:
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8177ab11>] dump_stack+0x45/0x57
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8103cd21>] warn_slowpath_common+0x9c/0xb6
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732b5c>] ? __sta_info_destroy_part2+0xd6/0x13f
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8103cdcf>] warn_slowpath_null+0x15/0x17
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732b5c>] __sta_info_destroy_part2+0xd6/0x13f
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732bea>] __sta_info_destroy+0x25/0x2f
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81732c82>] sta_info_destroy_addr_bss+0x37/0x57
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff817424dc>] ieee80211_del_station+0x18/0x25
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8170de39>] nl80211_del_station+0xd7/0x11f
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626c7e>] genl_family_rcv_msg+0x246/0x2b8
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626d2d>] genl_rcv_msg+0x3d/0x60
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626cf0>] ? genl_family_rcv_msg+0x2b8/0x2b8
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8162634a>] netlink_rcv_skb+0x45/0x88
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81626945>] genl_rcv+0x24/0x34
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81625e88>] netlink_unicast+0x104/0x18b
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8162620a>] netlink_sendmsg+0x2fb/0x319
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8110e232>] ? copy_from_user+0xba/0xe2
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815cfb32>] __sock_sendmsg+0x42/0x4d
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1490>] sock_sendmsg+0x37/0x49
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1ca5>] ___sys_sendmsg+0x1d9/0x268
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d0de9>] ? move_addr_to_user+0x51/0x67
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1e7f>] ? ___sys_recvmsg+0x14b/0x1be
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815cefb9>] ? sock_destroy_inode+0x2b/0x2f
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815cef8e>] ? sockfs_dname+0x1c/0x1c
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81123823>] ? destroy_inode+0x36/0x4f
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81104f21>] ? kmem_cache_free+0x49/0xd5
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff81125579>] ? __fget_light+0x27/0x48
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d1fed>] __sys_sendmsg+0x3d/0x5b
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff815d2018>] SyS_sendmsg+0xd/0x17
>> [Thu Jun  4 11:07:06 2015]  [<ffffffff8178201e>] system_call_fastpath+0x12/0x17
>> [Thu Jun  4 11:07:06 2015] ---[ end trace e4f43c81ea50a3f3 ]---
>> [Thu Jun  4 11:07:08 2015] ath10k_warn: 40 callbacks suppressed
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
>> [Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
>> [Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
>> [Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode
> 
> This is the dreaded tx credit starvation.
> 
> In some cases if disassoc+deauth is sent and target station is asleep
> and unresponsive it'll cause firmware to stall causing ath10k timeouts
> during sta_state station removal. Due to insufficient credits beacons
> can't be sent for ~10 seconds, sta_state station removal fails causing
> mac80211 call trace splat and later spurious kickout events because
> peer was never removed from firmware.
> 
> There's no easy/sane fix for that, yet.

Ouch! I’m a little surprised though, I must say — aren't substantially all access points (ath10k/QCA989x and otherwise) subjected to stations which sometimes go away while asleep? How come this is not a showstopping problem for basically everyone?


> You can read more on the subject:
> 
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/121954
> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/638
> 
> 
> Michał


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Matthew Robbetts]

Hi Ben,


> On Jun 5, 2015, at 08:52, Ben Greear <greearb@candelatech.com> wrote:
> 
> On 06/04/2015 10:17 PM, Michal Kazior wrote:
>> On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera@gmail.com> wrote:
> 
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
>>> [Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
>>> [Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
>>> [Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode
>> 
>> This is the dreaded tx credit starvation.
> 
> I have some fixes and work-arounds related to this issue in my kernels and CT firmware.
> 
> Possibly it would work better for you:
> 
> http://www.candelatech.com/ath10k.php
> 
> The beta-14 firmware is probably best at this point..I'll promote it to official
> release soon.

Oh, that’s interesting. I’m not familiar with the structure of the development for this driver/hardware — is your work intended for upstream, or are you in the business of supporting custom hardware and such?

I might give this a try when I get some spare time. Thanks for your work!




>> In some cases if disassoc+deauth is sent and target station is asleep
>> and unresponsive it'll cause firmware to stall causing ath10k timeouts
>> during sta_state station removal. Due to insufficient credits beacons
>> can't be sent for ~10 seconds, sta_state station removal fails causing
>> mac80211 call trace splat and later spurious kickout events because
>> peer was never removed from firmware.
>> 
>> There's no easy/sane fix for that, yet.
> 
> I thought the newer upstream firmware had
> support for mgt frames over normal packet transport instead of over
> the WMI management interface?  Wouldn't that fix things?
> 
> Thanks,
> Ben
> 
>> 
>> You can read more on the subject:
>> 
>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/121954
>> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/638
>> 
>> 
>> Michał
>> 
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>> 
> 
> 
> -- 
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Ben Greear]

On 06/05/2015 01:23 PM, Matthew Robbetts wrote:
> Hi Ben,
> 
> 
>> On Jun 5, 2015, at 08:52, Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 06/04/2015 10:17 PM, Michal Kazior wrote:
>>> On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera@gmail.com> wrote:

>>> This is the dreaded tx credit starvation.
>>
>> I have some fixes and work-arounds related to this issue in my kernels and CT firmware.
>>
>> Possibly it would work better for you:
>>
>> http://www.candelatech.com/ath10k.php
>>
>> The beta-14 firmware is probably best at this point..I'll promote it to official
>> release soon.
> 
> Oh, that’s interesting. I’m not familiar with the structure of the development for this driver/hardware — is your work intended for upstream, or are you in the business of supporting custom hardware and such?
> 
> I might give this a try when I get some spare time. Thanks for your work!

I'm in the business, but I give the community version away for free.

I have no way to get my firmware changes upstream, nor any linux driver changes
that are only supported by firmware.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Kalle Valo]

Michal Kazior <michal.kazior@tieto.com> writes:

> This is the dreaded tx credit starvation.
>
> In some cases if disassoc+deauth is sent and target station is asleep
> and unresponsive it'll cause firmware to stall causing ath10k timeouts
> during sta_state station removal. Due to insufficient credits beacons
> can't be sent for ~10 seconds, sta_state station removal fails causing
> mac80211 call trace splat and later spurious kickout events because
> peer was never removed from firmware.
>
> There's no easy/sane fix for that, yet.
>
> You can read more on the subject:
>
>  http://thread.gmane.org/gmane.linux.kernel.wireless.general/121954
> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/638

Should we write an entry to the FAQ about this?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Matthew Robbetts]

> On Jun 6, 2015, at 06:50, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> 
> Michal Kazior <michal.kazior@tieto.com> writes:
> 
>> This is the dreaded tx credit starvation.
>> 
>> In some cases if disassoc+deauth is sent and target station is asleep
>> and unresponsive it'll cause firmware to stall causing ath10k timeouts
>> during sta_state station removal. Due to insufficient credits beacons
>> can't be sent for ~10 seconds, sta_state station removal fails causing
>> mac80211 call trace splat and later spurious kickout events because
>> peer was never removed from firmware.
>> 
>> There's no easy/sane fix for that, yet.
>> 
>> You can read more on the subject:
>> 
>> http://thread.gmane.org/gmane.linux.kernel.wireless.general/121954
>> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/638
> 
> Should we write an entry to the FAQ about this?

From my perspective as a user, this would have been very useful. To my understanding, and translated bluntly, AP mode on this hardware is not supported; I would have been happy to know that before buying this rather expensive card :)

Are you able (or willing!) to comment any further how — from a high level — this problem can exist? If "no solution is known" right now, it implies that there is a difficulty at the architectural level. And the conversations Michal linked me to are over a year old, so there must be some real difficulty here. But, this problem seems to prevent an entire generation of hardware from performing in what is surely one of its main intended use-cases!

How does other, functioning, 802.11ac hardware handle this same circumstance of disappearing, sleeping stations?

Regards,
Matt

> -- 
> Kalle Valo


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Michal Kazior]

On 5 June 2015 at 17:52, Ben Greear <greearb@candelatech.com> wrote:
> On 06/04/2015 10:17 PM, Michal Kazior wrote:
>> On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera@gmail.com> wrote:
>
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
>>> [Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
>>> [Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
>>> [Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode
>>
>> This is the dreaded tx credit starvation.
>
> I have some fixes and work-arounds related to this issue in my kernels and CT firmware.
>
> Possibly it would work better for you:
>
> http://www.candelatech.com/ath10k.php
>
> The beta-14 firmware is probably best at this point..I'll promote it to official
> release soon.
>
>> In some cases if disassoc+deauth is sent and target station is asleep
>> and unresponsive it'll cause firmware to stall causing ath10k timeouts
>> during sta_state station removal. Due to insufficient credits beacons
>> can't be sent for ~10 seconds, sta_state station removal fails causing
>> mac80211 call trace splat and later spurious kickout events because
>> peer was never removed from firmware.
>>
>> There's no easy/sane fix for that, yet.
>
> I thought the newer upstream firmware had
> support for mgt frames over normal packet transport instead of over
> the WMI management interface?  Wouldn't that fix things?

I believe this was/is supposed to be available in some recent 10.2.4
builds. I think 10.2.4.48 was first supposed to support it but I see
the available "stable" fw api blob still advertises has-wmi-mgmt-tx.
The 10.2.4.48-2 from untested/ on the other hand doesn't advertise the
bit so I guess it uses the HTT path for management frames which should
prevent the tx credit starvation problem.

@Matthew: Can you try running 10.2.4.48-2 from 10.2.4/untested/ @
github.com/kvalo/ath10k-firmware and see if it helps you, please?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Michal Kazior]

On 6 June 2015 at 15:50, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> This is the dreaded tx credit starvation.
>>
>> In some cases if disassoc+deauth is sent and target station is asleep
>> and unresponsive it'll cause firmware to stall causing ath10k timeouts
>> during sta_state station removal. Due to insufficient credits beacons
>> can't be sent for ~10 seconds, sta_state station removal fails causing
>> mac80211 call trace splat and later spurious kickout events because
>> peer was never removed from firmware.
>>
>> There's no easy/sane fix for that, yet.
>>
>> You can read more on the subject:
>>
>>  http://thread.gmane.org/gmane.linux.kernel.wireless.general/121954
>> http://thread.gmane.org/gmane.linux.drivers.ath10k.devel/638
>
> Should we write an entry to the FAQ about this?

Good point, but..

I think it'd make more sense to actually update the recommended
firmware revision. Currently it's still the 10.1.467 in your git. It's
pretty confusing if you ask me. There's a ton of untested 10.2.4
images. How does a user know which one to use?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Kalle Valo]

Michal Kazior <michal.kazior@tieto.com> writes:

> I think it'd make more sense to actually update the recommended
> firmware revision. Currently it's still the 10.1.467 in your git. It's
> pretty confusing if you ask me. There's a ton of untested 10.2.4
> images. How does a user know which one to use?

Yeah, that's a mess and I should fix it. At the same time we should
reorganise the git repo entirely so that we can cleanly support various
hardware familes like qca6174. Any ideas how to do that?

And my recommendation is to use the latest firmware version from 10.2.4
branch which at this time is 10.2.4.70-2. I would be queries to receive
feedback how it works for people.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Matthew Robbetts]

> On Jun 8, 2015, at 07:42, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> 
> Michal Kazior <michal.kazior@tieto.com> writes:
> 
>> I think it'd make more sense to actually update the recommended
>> firmware revision. Currently it's still the 10.1.467 in your git. It's
>> pretty confusing if you ask me. There's a ton of untested 10.2.4
>> images. How does a user know which one to use?
> 
> Yeah, that's a mess and I should fix it. At the same time we should
> reorganise the git repo entirely so that we can cleanly support various
> hardware familes like qca6174. Any ideas how to do that?
> 
> And my recommendation is to use the latest firmware version from 10.2.4
> branch which at this time is 10.2.4.70-2. I would be queries to receive
> feedback how it works for people.

I’d be happy to keep up with the latest firmware build in general if that’s your recommendation. Are there any release notes available? Any specific behaviour changes to be wary of/look out for?

Thanks,
Matt
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Kalle Valo]

Matthew Robbetts <wingfeathera@gmail.com> writes:

>> On Jun 8, 2015, at 07:42, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> 
>> Michal Kazior <michal.kazior@tieto.com> writes:
>> 
>>> I think it'd make more sense to actually update the recommended
>>> firmware revision. Currently it's still the 10.1.467 in your git.
>>> It's pretty confusing if you ask me. There's a ton of untested
>>> 10.2.4 images. How does a user know which one to use?
>>  Yeah, that's a mess and I should fix it. At the same time we should
>> reorganise the git repo entirely so that we can cleanly support
>> various hardware familes like qca6174. Any ideas how to do that?
>> 
>> And my recommendation is to use the latest firmware version from
>> 10.2.4 branch which at this time is 10.2.4.70-2. I would be queries
>> to receive feedback how it works for people.
>
> I’d be happy to keep up with the latest firmware build in general if
> that’s your recommendation. Are there any release notes available?

Unfortunately the firmware team does not provide me release notes for
new firmware releases.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Re: Warnings/errors in use with a QCA989x card

[Matti Laakso]

> On 5 June 2015 at 17:52, Ben Greear <greearb at candelatech.com <http://lists.infradead.org/mailman/listinfo/ath10k>> wrote:
> >/ On 06/04/2015 10:17 PM, Michal Kazior wrote:
> />>/ On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera at gmail.com <http://lists.infradead.org/mailman/listinfo/ath10k>> wrote:
> />/
> />>>/ [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
> />>>/ [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
> />>>/ [Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
> />>>/ [Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
> />>>/ [Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode
> />>/
> />>/ This is the dreaded tx credit starvation.
> />/
> />/ I have some fixes and work-arounds related to this issue in my kernels and CT firmware.
> />/
> />/ Possibly it would work better for you:
> />/
> />/ http://www.candelatech.com/ath10k.php
> />/
> />/ The beta-14 firmware is probably best at this point..I'll promote it to official
> />/ release soon.
> />/
> />>/ In some cases if disassoc+deauth is sent and target station is asleep
> />>/ and unresponsive it'll cause firmware to stall causing ath10k timeouts
> />>/ during sta_state station removal. Due to insufficient credits beacons
> />>/ can't be sent for ~10 seconds, sta_state station removal fails causing
> />>/ mac80211 call trace splat and later spurious kickout events because
> />>/ peer was never removed from firmware.
> />>/
> />>/ There's no easy/sane fix for that, yet.
> />/
> />/ I thought the newer upstream firmware had
> />/ support for mgt frames over normal packet transport instead of over
> />/ the WMI management interface?  Wouldn't that fix things?
> /
> I believe this was/is supposed to be available in some recent 10.2.4
> builds. I think 10.2.4.48 was first supposed to support it but I see
> the available "stable" fw api blob still advertises has-wmi-mgmt-tx.
> The 10.2.4.48-2 from untested/ on the other hand doesn't advertise the
> bit so I guess it uses the HTT path for management frames which should
> prevent the tx credit starvation problem.
>
> @Matthew: Can you try running 10.2.4.48-2 from 10.2.4/untested/ @
> github.com/kvalo/ath10k-firmware and see if it helps you, please?
>
>
> Michał

I can confirm that with two week's use of 10.2.4.70-2 I've not seen
these problems any more. This is on OpenWrt with cherry picked patches
to enable FW API 5 (which I will post to OpenWrt mailing list shortly).

Matti

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Matthew Robbetts]

Hi Michał,

> On Jun 8, 2015, at 00:18, Michal Kazior <michal.kazior@tieto.com> wrote:
> 
> On 5 June 2015 at 17:52, Ben Greear <greearb@candelatech.com> wrote:
>> On 06/04/2015 10:17 PM, Michal Kazior wrote:
>>> On 5 June 2015 at 03:52, Matthew Robbetts <wingfeathera@gmail.com> wrote:
>> 
>>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:08 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
>>>> [Thu Jun  4 11:07:09 2015] ath10k_pci 0000:02:00.0: failed to transmit management frame via WMI: -11
>>>> [Thu Jun  4 12:05:32 2015] ath10k_warn: 19 callbacks suppressed
>>>> [Thu Jun  4 12:05:32 2015] ath10k_pci 0000:02:00.0: Spurious quick kickout for STA 04:db:56:e1:65:2f
>>>> [Thu Jun  4 12:55:54 2015] device wlp2s0 left promiscuous mode
>>> 
>>> This is the dreaded tx credit starvation.
>> 
>> I have some fixes and work-arounds related to this issue in my kernels and CT firmware.
>> 
>> Possibly it would work better for you:
>> 
>> http://www.candelatech.com/ath10k.php
>> 
>> The beta-14 firmware is probably best at this point..I'll promote it to official
>> release soon.
>> 
>>> In some cases if disassoc+deauth is sent and target station is asleep
>>> and unresponsive it'll cause firmware to stall causing ath10k timeouts
>>> during sta_state station removal. Due to insufficient credits beacons
>>> can't be sent for ~10 seconds, sta_state station removal fails causing
>>> mac80211 call trace splat and later spurious kickout events because
>>> peer was never removed from firmware.
>>> 
>>> There's no easy/sane fix for that, yet.
>> 
>> I thought the newer upstream firmware had
>> support for mgt frames over normal packet transport instead of over
>> the WMI management interface?  Wouldn't that fix things?
> 
> I believe this was/is supposed to be available in some recent 10.2.4
> builds. I think 10.2.4.48 was first supposed to support it but I see
> the available "stable" fw api blob still advertises has-wmi-mgmt-tx.
> The 10.2.4.48-2 from untested/ on the other hand doesn't advertise the
> bit so I guess it uses the HTT path for management frames which should
> prevent the tx credit starvation problem.
> 
> @Matthew: Can you try running 10.2.4.48-2 from 10.2.4/untested/ @
> github.com/kvalo/ath10k-firmware and see if it helps you, please?

Argh! I managed to entirely miss this last statement in your email! I will absolutely try this, immediately.

Out of interest, should I skip straight to 10.2.4.70-2 or might this be specific to .48-2?

Thanks so much!
Matt
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Michal Kazior]

On 23 June 2015 at 00:40, Matthew Robbetts <wingfeathera@gmail.com> wrote:
[...]
>>> I thought the newer upstream firmware had
>>> support for mgt frames over normal packet transport instead of over
>>> the WMI management interface?  Wouldn't that fix things?
>>
>> I believe this was/is supposed to be available in some recent 10.2.4
>> builds. I think 10.2.4.48 was first supposed to support it but I see
>> the available "stable" fw api blob still advertises has-wmi-mgmt-tx.
>> The 10.2.4.48-2 from untested/ on the other hand doesn't advertise the
>> bit so I guess it uses the HTT path for management frames which should
>> prevent the tx credit starvation problem.
>>
>> @Matthew: Can you try running 10.2.4.48-2 from 10.2.4/untested/ @
>> github.com/kvalo/ath10k-firmware and see if it helps you, please?
>
> Argh! I managed to entirely miss this last statement in your email! I will absolutely try this, immediately.
>
> Out of interest, should I skip straight to 10.2.4.70-2 or might this be specific to .48-2?

Both should use htt-mgmt-tx so it shouldn't matter as far as the
mgmt-tx problem is concerned.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Matthew Robbetts]

Hi Michał,

> On Jun 22, 2015, at 22:06, Michal Kazior <michal.kazior@tieto.com> wrote:
> 
> On 23 June 2015 at 00:40, Matthew Robbetts <wingfeathera@gmail.com> wrote:
> [...]
>>>> I thought the newer upstream firmware had
>>>> support for mgt frames over normal packet transport instead of over
>>>> the WMI management interface?  Wouldn't that fix things?
>>> 
>>> I believe this was/is supposed to be available in some recent 10.2.4
>>> builds. I think 10.2.4.48 was first supposed to support it but I see
>>> the available "stable" fw api blob still advertises has-wmi-mgmt-tx.
>>> The 10.2.4.48-2 from untested/ on the other hand doesn't advertise the
>>> bit so I guess it uses the HTT path for management frames which should
>>> prevent the tx credit starvation problem.
>>> 
>>> @Matthew: Can you try running 10.2.4.48-2 from 10.2.4/untested/ @
>>> github.com/kvalo/ath10k-firmware and see if it helps you, please?
>> 
>> Argh! I managed to entirely miss this last statement in your email! I will absolutely try this, immediately.
>> 
>> Out of interest, should I skip straight to 10.2.4.70-2 or might this be specific to .48-2?
> 
> Both should use htt-mgmt-tx so it shouldn't matter as far as the
> mgmt-tx problem is concerned.

Great, thanks!

I actually tried to use this firmware last night with my 4.0.4 kernel, but hit the problem of getting a tonne of:

...
ath10k_pci 0000:02:00.0: htt event (19) not handled
...


in my dmesg whenever a device tried to connect. I found the post:
http://lists.infradead.org/pipermail/ath10k/2015-March/004797.html

implying to me that this is expected and that driver changes are needed to use this new mechanism. Is there an easy way (for an idiot) to get these changes? Are they in the 4.1 kernel, or will I need to patch manually?


Thanks again,
Matt
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Warnings/errors in use with a QCA989x card

[Michal Kazior]

On 23 June 2015 at 18:48, Matthew Robbetts <wingfeathera@gmail.com> wrote:
> Hi Michał,
>
>> On Jun 22, 2015, at 22:06, Michal Kazior <michal.kazior@tieto.com> wrote:
>>
>> On 23 June 2015 at 00:40, Matthew Robbetts <wingfeathera@gmail.com> wrote:
>> [...]
>>>>> I thought the newer upstream firmware had
>>>>> support for mgt frames over normal packet transport instead of over
>>>>> the WMI management interface?  Wouldn't that fix things?
>>>>
>>>> I believe this was/is supposed to be available in some recent 10.2.4
>>>> builds. I think 10.2.4.48 was first supposed to support it but I see
>>>> the available "stable" fw api blob still advertises has-wmi-mgmt-tx.
>>>> The 10.2.4.48-2 from untested/ on the other hand doesn't advertise the
>>>> bit so I guess it uses the HTT path for management frames which should
>>>> prevent the tx credit starvation problem.
>>>>
>>>> @Matthew: Can you try running 10.2.4.48-2 from 10.2.4/untested/ @
>>>> github.com/kvalo/ath10k-firmware and see if it helps you, please?
>>>
>>> Argh! I managed to entirely miss this last statement in your email! I will absolutely try this, immediately.
>>>
>>> Out of interest, should I skip straight to 10.2.4.70-2 or might this be specific to .48-2?
>>
>> Both should use htt-mgmt-tx so it shouldn't matter as far as the
>> mgmt-tx problem is concerned.
>
> Great, thanks!
>
> I actually tried to use this firmware last night with my 4.0.4 kernel, but hit the problem of getting a tonne of:
>
> ...
> ath10k_pci 0000:02:00.0: htt event (19) not handled
> ...

Are you perhaps trying to use the .48-2 as firmware-4.bin with an old
driver? ;-) This won't work. It is API5 so it needs a more recent
driver.


> in my dmesg whenever a device tried to connect. I found the post:
> http://lists.infradead.org/pipermail/ath10k/2015-March/004797.html
>
> implying to me that this is expected and that driver changes are needed to use this new mechanism. Is there an easy way (for an idiot) to get these changes? Are they in the 4.1 kernel, or will I need to patch manually?

This didn't get into 4.1. You'll need to either cherry-pick or build
kernel from github.com/kvalo/ath


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k