[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
Fri Nov 30 23:07:45 AEDT 2012

On Fri, Nov 30, 2012 at 10:10 AM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> On Tue, Nov 27, 2012 at 03:39:16PM +0100, Helmut Schaa wrote:
>> 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 ).
> Uhh, I was confused.
>> 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.
> But will this work and is needed? If BAR will be drooped, and then will not
> get BA from AMPDU, we will send another BAR, and with a bit of luck this
> BAR will not be dropped. And if it does, we probably get out of range so
> connection should be reestablished anyway.

Yup, something like the patch below was what I was thinking of. Thanks
for taking
the time to send a patch :D

So, let's give this a try but I think this is the way to go!


More information about the users mailing list