SWBA errors and no ssid

Michal Kazior michal.kazior at tieto.com
Thu Feb 4 01:41:18 PST 2016


On 4 February 2016 at 10:33, Ann Lo <annlo.tech at gmail.com> wrote:
> Hi Michal,
>
> Thanks for your information and suggestion. A limitation we have is
> that we deal with board support package kernel, and we need to worry
> about other drivers as well. We are hoping to make minimal changes.
> There appear to be a number of changes in this area, including:
>
> ath10k: implement and use new beacon method
> http://lists.infradead.org/pipermail/ath10k/2014-January/000940.html
>
> the best ath10k driver
> http://lists.infradead.org/pipermail/ath10k/2015-August/005815.html
>
> Is it possible to apply a number of patches to Kernel 3.14.28? Or,
> port ath10k from Kernel 3.19 which is newer but not as new as Kernel
> 4.4? Is Qualcomm firmware 10.2.4.70.2 the only solution?

Backports allow you to use newer drivers with older kernel.

If that, for some reason, doesn't suit you you're probably left with
approach taken with the driver for chromium:

  https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/qUageXhYDb8

(This was done based on what originally Intel guys did with their iwl driver)

Cherry-picking changes manually is going to be a major pain with an
insane cascade of changes (possibly conflicting with some custom
changes in the kernel you use).


Michał


>
> Thanks,
> Ann
>
> On Wed, Feb 3, 2016 at 11:43 PM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 3 February 2016 at 20:33, Ann Lo <annlo.tech at gmail.com> wrote:
>>> Hello,
>>>
>>> We are seeking for expert opinions on "SWBA errors" and any possible
>>> workarounds. If we run AP+client mode, and the client scans for an
>>> nonexistent ssid, then "SWBA errors" happen easily. From this point
>>> on, the ssid of the AP is no longer visible. We use kernel 3.14.28,
>>> Qualcomm firmware 10.1.167.3-1, and WLE900VX. Qualcomm firmware
>>> 999.999.0.636 has the same problem except that it does not report
>>> "SWBA errors". Is it possible that we can fix this problem by porting
>>> some patches?
>>>
>>> Details of errors
>>> ============
>>> [ 3455.101199] ath10k: SWBA overrun on vdev 0
>>> [ 3455.203616] ath10k: SWBA overrun on vdev 0
>>> [ 3455.305992] ath10k: SWBA overrun on vdev 0
>>> [ 3455.408389] ath10k: SWBA overrun on vdev 0
>>> [ 3455.510768] ath10k: SWBA overrun on vdev 0
>>> [ 3455.613164] ath10k: SWBA overrun on vdev 0
>>> [ 3455.715557] ath10k: SWBA overrun on vdev 0
>>> [ 3455.817992] ath10k: SWBA overrun on vdev 0
>>> [ 3455.920360] ath10k: SWBA overrun on vdev 0
>>> [ 3456.022768] ath10k: SWBA overrun on vdev 0
>>> [ 3457.946735] uap0: failed to remove key (0, a4:2b:8c:04:6d:a8) from
>>> hardware (-11)
>>> [ 3460.118597] net_ratelimit: 40 callbacks suppressed
>>> [ 3460.123463] ath10k: SWBA overrun on vdev 0
>>> [ 3460.221003] ath10k: SWBA overrun on vdev 0
>>> [ 3460.323398] ath10k: SWBA overrun on vdev 0
>>> [ 3460.425785] ath10k: SWBA overrun on vdev 0
>>> [ 3460.528186] ath10k: SWBA overrun on vdev 0
>>> [ 3460.630568] ath10k: SWBA overrun on vdev 0
>>> [ 3460.732971] ath10k: SWBA overrun on vdev 0
>>> [ 3460.835370] ath10k: SWBA overrun on vdev 0
>>> [ 3460.937767] ath10k: SWBA overrun on vdev 0
>>> [ 3460.946679] ath10k: could not remove peer wep key 0 (-11)
>>
>> Looks like firmware has hanged. I recall there were weird issues a
>> long time ago.
>>
>> SWBA is an event reported by firmware to host prompting it to submit a
>> new beacon frame that is to be sent out. The "overrun" means that the
>> driver is unable to submit the beacon because firmware command pipe is
>> busy.
>>
>> You're using quite an old kernel. Can you perhaps try 4.4? If you
>> can't replace the kernel for some reason did you think about using
>> backports[1]?
>>
>> [1]: https://wireless.wiki.kernel.org/en/users/drivers/ath10k/backports
>>
>>
>> Michał



More information about the ath10k mailing list