[rt2x00-users] [bugzilla-daemon at bugzilla.kernel.org: [Bug 42828] rt2800pci unstable - chokes after too much I/O]
sgruszka at redhat.com
Tue Nov 27 23:32:01 AEDT 2012
On Tue, Nov 27, 2012 at 11:52:11AM +0100, Helmut Schaa wrote:
> On Tue, Nov 13, 2012 at 4:04 PM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> > Ok, I'm voting for reverting both commits:
> > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
> > Author: Andreas Hartmann <andihartmann at 01019freenet.de>
> > Date: Tue Apr 17 00:25:28 2012 +0200
> > rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
> > commit f0425beda4d404a6e751439b562100b902ba9c98
> > Author: Felix Fietkau <nbd at openwrt.org>
> > Date: Sun Aug 28 21:11:01 2011 +0200
> > mac80211: retry sending failed BAR frames later instead of tearing down aggr
> > f0425beda is causing troubles on rt2800 because that hardware do not
> > report BAR ack (perhaps because it is acked by BA frame not ACK frame),
> > so we constantly send BAR frames with the same SSN. This can be hardware
> > problem, but also if we can jump into that simulation if remote station
> > will not ack BAR frames or due to noisy radio conditions.
> > Felix, are you ok with revert of f0425beda ? I think posting BAR at
> > robust rate (see below patch) could address the problem, which commit
> > f0425beda solves.
> 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.
More information about the users