On Tue, 23 Oct 2018 10:18:54 +0200 Johannes Berg <[email protected]> wrote: > On Tue, 2018-10-23 at 10:44 +0300, Ali MJ Al-Nasrawy wrote: > > Hi, > > > > I am trying to debug brcmsmac wireless driver for spamming the log > > with the message: > > [...] START: tid 2 is not agg'able > > for it does not support AMPDU aggreggation for TID 2. > > > > And after quick tracing, I found that mac80211 keeps trying to start > > AMPDU session for the _same TID and STA_ despite that the driver > > returns non-zero code via its ampdu_action callback and that > > non-zero return codes are recognized as the "HW unavailable" for > > such session (agg-tx.c:ieee80211_tx_ba_session_handle_start) > > > > So, Is that an expected behaviour from mac80211 or not?? > > This depends on the rate control algorithm, it triggers this.
In this case, it is minstrel_ht. > > I think - perhaps depending on the return value - mac80211 *does* give > up eventually, but not really sure. The return value is handled only in agg-tx.c:ieee80211_tx_ba_session_handle_start and it doesn't pass it down or recognize difference between non-zero return values. And I don't think that it gives up retrying: I already have 800MB of compressed logs for the last four days only full of this message and additionally I ran a simple test for the last hour and found that it tries to start ampdu session for every frame to be sent with that TID! > Perhaps just remove the message? OK, I report this just in case of it being unintended behavior with probably a negative performance impact.
