Am Tue, 10 Jan 2012 14:43:21 +0100 schrieb Helmut Schaa <helmut.schaa@xxxxxxxxxxxxxx>: > Hi, > > On Tue, Jan 10, 2012 at 2:01 PM, Andreas Hartmann > <andihartmann@xxxxxxxxxxxxxxx> wrote: > > Helmut Schaa schrieb: > > [...] > >> So this looks good to me although the broken tx status for BAR frames > >> is for sure a rt2800pci problem (or even a hw issue). > > > > Sorry - What do you mean with "hw issue"? Is my hw broken? > > Hehe, no :) > > > Or is it a specific "behavior" of exactly this device: > > I think most rt2800pci will behave the same and just interpret a > BlockAck as response to a BAR in a different manner as a BlockAck > in response to a Data frame. > > When we send the BAR we tell the hw that the frame needs to be > acknowledged and according to the spec the hw will only count > a normal ACK as successful transmission, the peer will however > answer with a BlockAck as long as a BA session is active. > > It might be possible to advise the hw to allow the BAR to be acked > by a BlockAck by specifying AMDPU=1 in the TXWI. Not sure > if that breaks anything else. > > However, a BAR seems to be "ack-able" by both an ACK and a > BlockAck according to 802.11-2007. If the recipient answers with > an ACK the BA session might already be terminated and we would > stop the BA session as soon as 3 BARs failed with the previous > patch. This should be fine I guess. > > So you might just give the following a try (also fully untested and > maybe with some of your debugging output enabled). > > Signed-off-by: Helmut Schaa <helmut.schaa@xxxxxxxxxxxxxx> > --- > > diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c > b/drivers/net/wireless/rt2x00/rt2x00queue.c > index e4641da..5d0a3d3 100644 > --- a/drivers/net/wireless/rt2x00/rt2x00queue.c > +++ b/drivers/net/wireless/rt2x00/rt2x00queue.c > @@ -393,6 +393,9 @@ static void > rt2x00queue_create_tx_descriptor_ht(struct rt2x00_dev *rt2x00dev, > txdesc->u.ht.txop = TXOP_SIFS; > else > txdesc->u.ht.txop = TXOP_HTTXOP; > + > + if (ieee80211_is_back_req(hdr->frame_control)) > + __set_bit(ENTRY_TXD_HT_AMPDU, &txdesc->flags); > } > > static void rt2x00queue_create_tx_descriptor(struct rt2x00_dev *rt2x00dev, Unfortunately, I don't think it fixes anything (an equal looking sequence could be seen just 10s before - ok other ssn numbers :-)): [38517.363964] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 19 [38517.363977] __set_bit ENTRY_TXD_HT_AMPDU [38517.363989] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 20 [38517.363995] __set_bit ENTRY_TXD_HT_AMPDU [38517.364005] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 21 [38517.364011] __set_bit ENTRY_TXD_HT_AMPDU [38517.364020] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 22 [38517.364026] __set_bit ENTRY_TXD_HT_AMPDU [38517.364034] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 23 [38517.364042] __set_bit ENTRY_TXD_HT_AMPDU [38517.375021] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 24 [38517.375028] status.c ieee80211_tx_status() calls ieee80211_set_bar_pending. tid: <0> control: <4> ssn: <27248> [38517.389129] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 25 [38517.389132] status.c ieee80211_tx_status() calls ieee80211_set_bar_pending. tid: <0> control: <4> ssn: <27264> [38517.397279] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 26 [38517.397283] status.c ieee80211_tx_status() calls ieee80211_set_bar_pending. tid: <0> control: <4> ssn: <27280> [38517.407062] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 27 [38517.407069] status.c ieee80211_tx_status() calls ieee80211_set_bar_pending. tid: <0> control: <4> ssn: <27296> [38517.417684] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 28 [38517.417691] status.c ieee80211_tx_status() calls ieee80211_set_bar_pending. tid: <0> control: <4> ssn: <27312> [38517.417742] ieee80211_check_pending_bar -> ieee80211_send_bar() retry cnt: 2 tid: 0 failed_bar_ssn: 27312 [38517.417751] __set_bit ENTRY_TXD_HT_AMPDU [38517.417763] ieee80211_check_pending_bar -> ieee80211_send_bar() retry cnt: 1 tid: 0 failed_bar_ssn: 27312 [38517.417768] __set_bit ENTRY_TXD_HT_AMPDU [38517.417775] ieee80211_check_pending_bar -> ieee80211_stop_tx_ba_session() retry cnt: 0 tid: 0 failed_bar_ssn: 27312 [38517.417840] Tx BA session stop requested for 00:25:9c:11:22:33 tid 0 [38517.426147] Stopping Tx BA session for 00:25:9c:11:22:33 tid 0 [38517.432511] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 29 [38517.432518] status.c ieee80211_tx_status() calls ieee80211_set_bar_pending. tid: <0> control: <4> ssn: <27312> [38517.439356] rt2x00lib_txdone - no success - low_level_stats.dot11ACKFailureCount: 30 [38517.439362] status.c ieee80211_tx_status() calls ieee80211_set_bar_pending. tid: <0> control: <4> ssn: <27312> [38517.491026] Open BA session requested for 00:25:9c:11:22:33 tid 0 [38517.499048] activated addBA response timer on tid 0 [38517.507633] switched off addBA timer for tid 0 [38517.507637] Aggregation is on for tid 0 Some additional information might be interesting: I'm getting these tx errors nearly always (I haven't seen them in the other direction until now) while sending data from STA -> AP (not from AP -> STA). The throughput from STA -> AP is mostly about 8 MBit/s whereas the other direction reaches up to 15 MBit/s. Kind regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
