On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote:

Stanislaw Gruszka wrote:

quoted

On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote:

quoted

Ben Hutchings wrote:

quoted

On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote:

quoted

On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote:

quoted

quoted

To be clear, I have all of these in the queue:

be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
ab9d6e4ffe19 Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"

and I'm intending to drop/defer them all.

Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches,
or only patch 2.

No, actually all 3 patches have to be applied. Because last one, except
revert, include flag IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL setting in rt2x00
driver, which make patch 2 work.

Andreas said that that after ab9d6e4ffe19 there was still a regression.

That's not true. There will be no regression after ab9d6e4ffe20. The
only thing is that solution is not perfect. But perfect solution require
lot of changes i.e. is not -stable appropriate (and does not exist currently).

quoted

quoted

But maybe he was confused.  I know I'm confused.

:-))

No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the
requirements of mac80211).

Both workarounds, mine and the new workaround from Stanislaw (which is
nothing more than a restricted version of my initial workaround), work

Your workaround broke STA mode on some environment.

Why are you sure, that this workaround doesn't break some other devices
running in AP mode? We believed at that time too, it wouldn't harm even
STA. But this was wrong for some (which?) devices.

Because it make behaviour the same as it was before 3.2, which introduce
those issues.

Stanislaw