Re: Warnings/errors in use with a QCA989x card

[Matthew Robbetts <wingfeathera@gmail.com>]

> 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