Bug 167902

Summary: [ath] TX block-ack window holes
Product: Base System Reporter: Adrian Chadd <adrian>
Component: kernAssignee: Adrian Chadd <adrian>
Status: Closed FIXED    
Severity: Affects Only Me CC: emaste, gonzo
Priority: Normal Flags: bugmeister: mfc-stable10?
bugmeister: mfc-stable9?
bugmeister: mfc-stable8?
Version: 9.0-STABLE   
Hardware: Any   
OS: Any   

Description Adrian Chadd freebsd_committer freebsd_triage 2012-05-15 05:50:02 UTC 
When doing traffic tests w/ 11n debugging on, I've noticed that the RX side is reporting holes in the TX BA space.

Some example logging is:

wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <310:373> (0 frames) rxseq 309 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <542:605> (0 frames) rxseq 541 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <831:894> (0 frames) rxseq 830 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <886:949> (0 frames) rxseq 885 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <909:972> (0 frames) rxseq 908 tid 0 (retransmit)
--- these
wlan1: [00:03:7f:0b:62:88] move BA win <1372:1435> (62 frames) rxseq 1436 tid 0
wlan1: [00:03:7f:0b:62:88] move BA win <1373:1436> (63 frames) rxseq 1437 tid 0
--- these
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <1447:1510> (0 frames) rxseq 1446 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <1561:1624> (0 frames) rxseq 1560 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <1660:1723> (0 frames) rxseq 1659 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <2054:2117> (0 frames) rxseq 2053 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <2107:2170> (0 frames) rxseq 2106 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <2122:2185> (0 frames) rxseq 2121 tid 0 (retransmit)
wlan1: [00:03:7f:0b:62:88] discard MPDU frame, BA win <2890:2953> (0 frames) rxseq 2889 tid 0 (retransmit)

A pcap of the live traffic showed that some frames inside the BA weren't ever ACKed. I figured that the send side was thus not being properly notified that the transmission failed.

I then added some code to ath_tx_processq() to print out ts_status if it's 0 but not HAL_TXERR_XRETRY. It turns out that I was seeing HAL_TXERR_FILT errors. The filtered frames were just being treated as incorrect completions, hence the above BA window slide.

Fix: 

The TX completion routines need to handle non-XRETRY errors.
How-To-Repeat: * enable 11n
* on the receiving side - wlandebug -i wlanX +11n
* .. do some traffic.
Comment 1 dfilter service freebsd_committer freebsd_triage 2012-05-15 05:55:25 UTC 
Author: adrian
Date: Tue May 15 04:55:15 2012
New Revision: 235461
URL: http://svn.freebsd.org/changeset/base/235461

Log:
  Handle non-xretry errors the same as xretry errors for now.
  
  Although I _should_ handle the other errors in various ways (specifically
  errors like FILT), treating them as having transmitted successfully
  is completely wrong.  Here, they'd be counted as successful and the BAW
  would be advanced.. but the RX side wouldn't have received them.
  
  The specific errors I've been seeing here are HAL_TXERR_FILT.
  
  This patch does fix the issue - I've tested it using -i 0.001 pings
  (enough to start aggregation) and now the behaviour is correct:
  
  * The RX side never sees a "moved window" error, and
  * The TX side sends BARs as needed, with the RX side correctly handling
    them.
  
  PR:		kern/167902

Modified:
  head/sys/dev/ath/if_ath_tx.c

Modified: head/sys/dev/ath/if_ath_tx.c
==============================================================================
--- head/sys/dev/ath/if_ath_tx.c	Tue May 15 03:21:36 2012	(r235460)
+++ head/sys/dev/ath/if_ath_tx.c	Tue May 15 04:55:15 2012	(r235461)
@@ -3597,9 +3597,16 @@ ath_tx_aggr_comp_aggr(struct ath_softc *
 	pktlen = bf_first->bf_state.bfs_pktlen;
 
 	/*
-	 * handle errors first
+	 * Handle errors first!
+	 *
+	 * Here, handle _any_ error as a "exceeded retries" error.
+	 * Later on (when filtered frames are to be specially handled)
+	 * it'll have to be expanded.
 	 */
+#if 0
 	if (ts.ts_status & HAL_TXERR_XRETRY) {
+#endif
+	if (ts.ts_status != 0) {
 		ATH_TXQ_UNLOCK(sc->sc_ac2q[atid->ac]);
 		ath_tx_comp_aggr_error(sc, bf_first, atid);
 		return;
@@ -3839,7 +3846,10 @@ ath_tx_aggr_comp_unaggr(struct ath_softc
 	 * Don't bother with the retry check if all frames
 	 * are being failed (eg during queue deletion.)
 	 */
+#if 0
 	if (fail == 0 && ts->ts_status & HAL_TXERR_XRETRY) {
+#endif
+	if (fail == 0 && ts->ts_status != 0) {
 		ATH_TXQ_UNLOCK(sc->sc_ac2q[atid->ac]);
 		DPRINTF(sc, ATH_DEBUG_SW_TX, "%s: retry_unaggr\n",
 		    __func__);
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2012-05-16 03:22:45 UTC 
State Changed
From-To: open->patched

Over to committer as possible MFC reminder.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2012-05-16 03:22:45 UTC 
Responsible Changed
From-To: freebsd-bugs->adri
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2012-05-16 04:40:47 UTC 
Responsible Changed
From-To: adri->adrian

Fix assignment.
Comment 5 Ed Maste freebsd_committer freebsd_triage 2018-10-02 19:28:09 UTC 
Adrian should this be closed?
Comment 6 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-20 01:20:30 UTC 
There was a commit referencing this bug, but it's still not closed and has been inactive for some time. Closing as fixed. Please re-open it if the issue hasn't been completely resolved.