Re: Compat-wireless-3.2-rc6-3 is broken for rt2860 device
From: Andreas Hartmann <hidden>
Date: 2012-01-10 14:44:39
Am Tue, 10 Jan 2012 14:43:21 +0100 schrieb Helmut Schaa [off-list ref]:
quoted hunk ↗ jump to hunk
Hi, On Tue, Jan 10, 2012 at 2:01 PM, Andreas Hartmann [off-list ref] wrote:quoted
Helmut Schaa schrieb: [...]quoted
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 :)quoted
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 <redacted> ---diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.cb/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 voidrt2x00queue_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