[rt2x00-users] [bugzilla-daemon at bugzilla.kernel.org: [Bug 42828] rt2800pci unstable - chokes after too much I/O]

Helmut Schaa helmut.schaa at googlemail.com
Wed Nov 28 01:39:16 AEDT 2012

On Tue, Nov 27, 2012 at 1:32 PM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>> I think it might be better to just always report BAR frames as
>> successful to mac80211
>> from the rt2800 tx status code. Hence, the BAR resend code will never
>> trigger for
>> rt2x00 devices.
> This is what more or less commit be03d4a45c0 does, and that cause
> problems on Francisco environment. I think problem happens when BAR
> do not reach pear, so it do not sent BA, but we pretend it does.

With be03d4a45c0 we don't even send out a BAR when an AMPDU fails. But AMPDU
failure reporting works fine (in most cases but I won't got into
detail here :D ).

So we can easily send out a BAR to flush the recipients reorder
buffer. However, we
cannot verify if the BAR fails or not, hence, I'd recommend to ignore
the transmission
state of BAR frames and report them back to mac80211 as successful to not end
up sending BARs over and over again.

Of course this has limitations since a BAR can easily be dropped on
the air and we
have no chance to verify that. But we could for example add a
threshold of allowed
AMPDU failures until the BA session gets torn down by mac80211 for example.

I can't provide a patch right now :/ but maybe I find some time to do so.


More information about the users mailing list