[rt2x00-users] [RFT] rt2x00: Tear down BA session on QoS frame failure

[Andreas Hartmann]

On Fri, 09 Mar 2012 18:52:29 +0100
Helmut Schaa <helmut.schaa at googlemail.com> wrote:
> 
> Andreas Hartmann <andihartmann at 01019freenet.de> wrote:
> 
> >Helmut Schaa wrote:
> >> On Fri, Mar 9, 2012 at 3:31 PM, Andreas Hartmann
> >> <andihartmann at 01019freenet.de> wrote:
> >>> Hello Helmut,
> >>>
> >>> Helmut Schaa schrieb:
> >>>> rt2800 hardware is not able to correctly report the tx status of
> >BAR
> >>>> frames. Hence, instead of letting mac80211 send a BAR when an AMPDU
> >>>> subframe fails to flush the peers RX reorder buffer we just take
> >down
> >>>> the whole BA session.
> >>>>
> >>>> This mimics the bahavior of the ralink legacy drivers.
> >>>>
> >>>> Signed-off-by: Helmut Schaa <helmut.schaa at googlemail.com>
> >>>> ---
> >>>>
> >>>> Tested on a single processor system and seems to work just fine.
> >>>> Andreas, mind to run some tests with your rt2800pci AP as well?
> >>>
> >>> Surely :-). Always!

[...]

> > your patch wasn't applied. If it is applied, it crashes the machine
> > again after a few seconds.
> >Conclusion is unchanged: seems not to work for me at all with the
> >tested
> >versions :-(.
> 
> Ah, this is strange. Works perfectly for me here. No crashes :-( i'm travelling over the weekend so cannot take a deeper look ...

While debugging the crash, I figured out, that the following patch is
enough for me to fix the problem introduced with "mac80211: retry
sending failed BAR frames later instead of tearing down aggr".

I tested with rt2860 pci as AP (linux 3.1.10 /
compat-wireless-2012-02-02) against legacy driver rt5572sta
(rt3572 based supplicant) and ath9k (ar9285 based supplicant), using
802.11n / 2.4 GHz / 40 MHz.

I did 2 different tests:
a) netperf (switching back and forth between w/ and w/o the
   following patch applied). I tested three different radio conditions:
   best / good / bad.
b) Terminalsessions through ssh -XC to detect temporary hangs /
   responsiveness in bad radio condition (only tested with rt5572sta).

Conclusion a)
Without the following patch _not_ applied, I immediately could see the
hangs again, introduced with patch "mac80211: retry
sending failed BAR frames later instead of tearing down aggr".
The radio conditions were irrelevant.

Conclusion b)
I couldn't feel any problems regarding responsiveness. It was just
extremely fine - exactly what I'm expecting. No surge, just as if I
would have been using the application directly on the physical machine.
The applications used for testing were Seamonkey mail and browser and
Claws (I'm writing this mail as test). The applications have been
running absolutely smooth.


Long-term test is standing.

Maybe, others could test, if it fixes their problems, too.


Regards,
Andreas

--- drivers/net/wireless/rt2x00/rt2x00dev.c.orig	2012-03-13 13:01:37.052100066 +0100
+++ drivers/net/wireless/rt2x00/rt2x00dev.c	2012-04-11 05:42:31.514914691 +0200
@@ -387,9 +387,6 @@
 		tx_info->flags |= IEEE80211_TX_STAT_AMPDU;
 		tx_info->status.ampdu_len = 1;
 		tx_info->status.ampdu_ack_len = success ? 1 : 0;
-
-		if (!success)
-			tx_info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
 	}
 
 	if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {