Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, 2013-01-07 at 20:20 +0100, Stanislaw Gruszka wrote: > On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote: > > Stanislaw Gruszka wrote: > > > On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: > > >> Ben Hutchings wrote: > > >>> On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: > > On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: > > >> 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). > > > > > >>> 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. After reviewing the various changes, I agree that applying the three patches looks like it will restore the old (3.1) behaviour of rt2x00. I have reinstated them in the queue for the next 3.2 update. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, 2013-01-07 at 20:20 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote: Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: Ben Hutchings wrote: On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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). 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. After reviewing the various changes, I agree that applying the three patches looks like it will restore the old (3.1) behaviour of rt2x00. I have reinstated them in the queue for the next 3.2 update. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Hello Stanislaw! Stanislaw Gruszka wrote: > On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote: >> Stanislaw Gruszka wrote: >>> On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: Ben Hutchings wrote: > On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: >> On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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). >>> > 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. You're so right, Stanislaw! I should have better looked again at your patch before writing those stupid lines about differentiation between STA and AP. Please apologize! Kind regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote: > Stanislaw Gruszka wrote: > > On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: > >> Ben Hutchings wrote: > >>> On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: > On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: > >> 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). > > > >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Hello Helmut! Helmut Schaa wrote: > On Mon, Jan 7, 2013 at 4:04 PM, Andreas Hartmann > wrote: >> The solution would be IMHO, to implement an own aggregation handling, >> maybe the same way as it was done for carl9170, which had the same problem: >> >> http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 >> >> I prefer to have solutions (if one is known) instead of another workaround. > > JFI, I'm just working on exactly that (handling BAR TX status in > driver to implement proper RX reorder window flushing at the peer). I'll post > it for > further testing to the rt2x00 list once I'm done. Thank you for your time spent on this problem! I really appreciate it! Kind regards! Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Stanislaw Gruszka wrote: > On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: >> Ben Hutchings wrote: >>> On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: >> 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). > >>> 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. Anyway: As Helmut meanwhile mentioned that he thankfully works on a solution now, I'm fine with the second round of workaround. Kind regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: > Ben Hutchings wrote: > > On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: > >> On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: > 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). > > 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. Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 7, 2013 at 4:04 PM, Andreas Hartmann wrote: > The solution would be IMHO, to implement an own aggregation handling, > maybe the same way as it was done for carl9170, which had the same problem: > > http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 > > I prefer to have solutions (if one is known) instead of another workaround. JFI, I'm just working on exactly that (handling BAR TX status in driver to implement proper RX reorder window flushing at the peer). I'll post it for further testing to the rt2x00 list once I'm done. Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Ben Hutchings wrote: > On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: >> On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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. > 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 like this: Let the peer do the aggregation handling. If it's not done by the peer, the connection will break down. Therefore: The solution would be IMHO, to implement an own aggregation handling, maybe the same way as it was done for carl9170, which had the same problem: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 I prefer to have solutions (if one is known) instead of another workaround. If I use my device as STA instead of an AP, it even works fine w/o Stanislaws patch. Do you understand what I'm trying to say? Thanks, kind regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: > On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: > > > 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. But maybe he was confused. I know I'm confused. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: > > 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. Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 12:18:21AM -0800, Jonathan Nieder wrote: > Stanislaw Gruszka wrote: > > On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote: > > >> 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. > > Despite its title, isn't patch 3 not exactly a revert? It includes a > change that depends on patch 2. I don't think patch 2 alone would > have any effect. Yes, all 3 patches should go in. Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Stanislaw Gruszka wrote: > On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote: >> 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. Despite its title, isn't patch 3 not exactly a revert? It includes a change that depends on patch 2. I don't think patch 2 alone would have any effect. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote: > On Sun, 2012-12-30 at 13:38 +0100, Ben Hutchings wrote: > > On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote: > > > Ben Hutchings wrote: > > > > 3.2-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > > > -- > > > > > > > > From: Andreas Hartmann > > > > > > > > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. > > > > > > [...] > > > > > > This patch is a workaround for > > > > > > mac80211: retry sending failed BAR frames later instead of tearing down > > > aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - > > > f0425beda4d404a6e751439b562100b902ba9c98) > > > See: > > > http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 > > > > > > > > > Meanwhile there was a bug report complaining about problems with > > > be03d4a45 when used as STA: > > > http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 > > > You can find there a few other workaround proposals. > > [...] > > > > OK, I'll drop this for now. Once this is sorted out, please send to > > stable a complete list of fixes that are needed. > > 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. Stanislaw -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote: On Sun, 2012-12-30 at 13:38 +0100, Ben Hutchings wrote: On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote: Ben Hutchings wrote: 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Andreas Hartmann andihartm...@01019freenet.de commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. [...] This patch is a workaround for mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - f0425beda4d404a6e751439b562100b902ba9c98) See: http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 Meanwhile there was a bug report complaining about problems with be03d4a45 when used as STA: http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 You can find there a few other workaround proposals. [...] OK, I'll drop this for now. Once this is sorted out, please send to stable a complete list of fixes that are needed. 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. Stanislaw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Stanislaw Gruszka wrote: On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote: 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. Despite its title, isn't patch 3 not exactly a revert? It includes a change that depends on patch 2. I don't think patch 2 alone would have any effect. Jonathan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 12:18:21AM -0800, Jonathan Nieder wrote: Stanislaw Gruszka wrote: On Sun, Dec 30, 2012 at 01:42:37PM +0100, Ben Hutchings wrote: 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. Despite its title, isn't patch 3 not exactly a revert? It includes a change that depends on patch 2. I don't think patch 2 alone would have any effect. Yes, all 3 patches should go in. Stanislaw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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. Stanislaw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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. But maybe he was confused. I know I'm confused. Ben. -- Ben Hutchings If you seem to know what you are doing, you'll be given more to do. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Ben Hutchings wrote: On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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. 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 like this: Let the peer do the aggregation handling. If it's not done by the peer, the connection will break down. Therefore: The solution would be IMHO, to implement an own aggregation handling, maybe the same way as it was done for carl9170, which had the same problem: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 I prefer to have solutions (if one is known) instead of another workaround. If I use my device as STA instead of an AP, it even works fine w/o Stanislaws patch. Do you understand what I'm trying to say? Thanks, kind regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 7, 2013 at 4:04 PM, Andreas Hartmann andihartm...@01019freenet.de wrote: The solution would be IMHO, to implement an own aggregation handling, maybe the same way as it was done for carl9170, which had the same problem: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 I prefer to have solutions (if one is known) instead of another workaround. JFI, I'm just working on exactly that (handling BAR TX status in driver to implement proper RX reorder window flushing at the peer). I'll post it for further testing to the rt2x00 list once I'm done. Helmut -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: Ben Hutchings wrote: On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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). 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. Stanislaw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: Ben Hutchings wrote: On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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). 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. Anyway: As Helmut meanwhile mentioned that he thankfully works on a solution now, I'm fine with the second round of workaround. Kind regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Hello Helmut! Helmut Schaa wrote: On Mon, Jan 7, 2013 at 4:04 PM, Andreas Hartmann andihartm...@01019freenet.de wrote: The solution would be IMHO, to implement an own aggregation handling, maybe the same way as it was done for carl9170, which had the same problem: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 I prefer to have solutions (if one is known) instead of another workaround. JFI, I'm just working on exactly that (handling BAR TX status in driver to implement proper RX reorder window flushing at the peer). I'll post it for further testing to the rt2x00 list once I'm done. Thank you for your time spent on this problem! I really appreciate it! Kind regards! Andreas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote: Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: Ben Hutchings wrote: On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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). 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Hello Stanislaw! Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote: Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: Ben Hutchings wrote: On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: 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). 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. You're so right, Stanislaw! I should have better looked again at your patch before writing those stupid lines about differentiation between STA and AP. Please apologize! Kind regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Sun, 2012-12-30 at 13:38 +0100, Ben Hutchings wrote: > On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote: > > Ben Hutchings wrote: > > > 3.2-stable review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Andreas Hartmann > > > > > > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. > > > > [...] > > > > This patch is a workaround for > > > > mac80211: retry sending failed BAR frames later instead of tearing down > > aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - > > f0425beda4d404a6e751439b562100b902ba9c98) > > See: > > http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 > > > > > > Meanwhile there was a bug report complaining about problems with > > be03d4a45 when used as STA: > > http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 > > You can find there a few other workaround proposals. > [...] > > OK, I'll drop this for now. Once this is sorted out, please send to > stable a complete list of fixes that are needed. 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. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote: > Ben Hutchings wrote: > > 3.2-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Andreas Hartmann > > > > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. > > [...] > > This patch is a workaround for > > mac80211: retry sending failed BAR frames later instead of tearing down > aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - > f0425beda4d404a6e751439b562100b902ba9c98) > See: > http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 > > > Meanwhile there was a bug report complaining about problems with > be03d4a45 when used as STA: > http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 > You can find there a few other workaround proposals. [...] OK, I'll drop this for now. Once this is sorted out, please send to stable a complete list of fixes that are needed. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote: Ben Hutchings wrote: 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Andreas Hartmann andihartm...@01019freenet.de commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. [...] This patch is a workaround for mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - f0425beda4d404a6e751439b562100b902ba9c98) See: http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 Meanwhile there was a bug report complaining about problems with be03d4a45 when used as STA: http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 You can find there a few other workaround proposals. [...] OK, I'll drop this for now. Once this is sorted out, please send to stable a complete list of fixes that are needed. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Sun, 2012-12-30 at 13:38 +0100, Ben Hutchings wrote: On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote: Ben Hutchings wrote: 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Andreas Hartmann andihartm...@01019freenet.de commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. [...] This patch is a workaround for mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - f0425beda4d404a6e751439b562100b902ba9c98) See: http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 Meanwhile there was a bug report complaining about problems with be03d4a45 when used as STA: http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 You can find there a few other workaround proposals. [...] OK, I'll drop this for now. Once this is sorted out, please send to stable a complete list of fixes that are needed. 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. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Ben Hutchings wrote: > 3.2-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Andreas Hartmann > > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. [...] This patch is a workaround for mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - f0425beda4d404a6e751439b562100b902ba9c98) See: http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 Meanwhile there was a bug report complaining about problems with be03d4a45 when used as STA: http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 You can find there a few other workaround proposals. Stanislaw Gruszka proposed here a final(?) workaround, which refines workaround be03d4a45c by shrinking it to AP function: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793 carl9170 had the same problem with f0425beda. There it was fixed like this: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 This approach fixes the real problem (no aggregation handling by the firmware / hardware) by implementing it into the driver. Unfortunately, I didn't see any implementation of c9122c0d63a50 for rt2x00 until now. Kind regards, Andreas Hartmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Ben Hutchings wrote: 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Andreas Hartmann andihartm...@01019freenet.de commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. [...] This patch is a workaround for mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - f0425beda4d404a6e751439b562100b902ba9c98) See: http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 Meanwhile there was a bug report complaining about problems with be03d4a45 when used as STA: http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257 You can find there a few other workaround proposals. Stanislaw Gruszka proposed here a final(?) workaround, which refines workaround be03d4a45c by shrinking it to AP function: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793 carl9170 had the same problem with f0425beda. There it was fixed like this: http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405 This approach fixes the real problem (no aggregation handling by the firmware / hardware) by implementing it into the driver. Unfortunately, I didn't see any implementation of c9122c0d63a50 for rt2x00 until now. Kind regards, Andreas Hartmann -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Andreas Hartmann
commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.
There are connection stalls or very poor throughputs with rt2800
hardware using 802.11n in AP mode since patch "mac80211: retry sending
failed BAR frames later instead of tearing down aggr"[1][2].
Since rt2800 hardware is not able to correctly report the tx status of
BAR frames, this patch removes as workaround the existing error handling
on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails.
As a result, most wifi clients (aside from Intel STAs on Windows)
instead will timeout now the reorder buffer and request the lost frame
again.
The correct solution would be, to tear down BA session on AP side.
This patch was born on the basis of "[RFT] rt2x00: Tear down BA
session on QoS frame failure"[3].
Thanks to Helmut Schaa for his support!
[1]
http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
[2]
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98
[3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569
Signed-off-by: Andreas Hartmann
Acked-by: Helmut Schaa
Signed-off-by: John W. Linville
Signed-off-by: Ben Hutchings
---
drivers/net/wireless/rt2x00/rt2x00dev.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 90cc5e7..dd87d41 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -391,9 +391,10 @@ void rt2x00lib_txdone(struct queue_entry *entry,
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;
+ /*
+* TODO: Need to tear down BA session here
+* if not successful.
+*/
}
if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Andreas Hartmann andihartm...@01019freenet.de
commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.
There are connection stalls or very poor throughputs with rt2800
hardware using 802.11n in AP mode since patch mac80211: retry sending
failed BAR frames later instead of tearing down aggr[1][2].
Since rt2800 hardware is not able to correctly report the tx status of
BAR frames, this patch removes as workaround the existing error handling
on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails.
As a result, most wifi clients (aside from Intel STAs on Windows)
instead will timeout now the reorder buffer and request the lost frame
again.
The correct solution would be, to tear down BA session on AP side.
This patch was born on the basis of [RFT] rt2x00: Tear down BA
session on QoS frame failure[3].
Thanks to Helmut Schaa for his support!
[1]
http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
[2]
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98
[3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569
Signed-off-by: Andreas Hartmann andihartm...@01019freenet.de
Acked-by: Helmut Schaa helmut.sc...@googlemail.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/net/wireless/rt2x00/rt2x00dev.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 90cc5e7..dd87d41 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -391,9 +391,10 @@ void rt2x00lib_txdone(struct queue_entry *entry,
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;
+ /*
+* TODO: Need to tear down BA session here
+* if not successful.
+*/
}
if (rate_flags IEEE80211_TX_RC_USE_RTS_CTS) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
