svn commit: r224957 - user/adrian/if_ath_tx/sys/dev/ath

[Adrian Chadd]

Author: adrian
Date: Thu Aug 18 04:39:29 2011
New Revision: 224957
URL: http://svn.freebsd.org/changeset/base/224957

Log:
  Detaching the STA VAP causes a station disassociate frame to be sent.
  This ends up being queued on a TX node that is then being freed, leading
  to a node sticking around whose vap state is now invalid.
  
  For now, just force another hardware and software TXQ flush.
  Later on, investigate why this is the case as this doesn't occur in
  the normal ath tree.

Modified:
  user/adrian/if_ath_tx/sys/dev/ath/if_ath.c

Modified: user/adrian/if_ath_tx/sys/dev/ath/if_ath.c
==============================================================================
--- user/adrian/if_ath_tx/sys/dev/ath/if_ath.c	Thu Aug 18 03:44:32 2011	(r224956)
+++ user/adrian/if_ath_tx/sys/dev/ath/if_ath.c	Thu Aug 18 04:39:29 2011	(r224957)
@@ -1150,6 +1150,27 @@ ath_vap_delete(struct ieee80211vap *vap)
 	}
 
 	ieee80211_vap_detach(vap);
+
+	/*
+	 * XXX Danger Will Robinson! Danger!
+	 *
+	 * Because ieee80211_vap_detach() can queue a frame (the station
+	 * diassociate message?) after we've drained the TXQ and
+	 * flushed the software TXQ, we will end up with a frame queued
+	 * to a node whose vap is about to be freed.
+	 *
+	 * To work around this, flush the hardware/software again.
+	 * This may be racy - the ath task may be running and the packet
+	 * may be being scheduled between sw->hw txq. Tsk.
+	 *
+	 * TODO: figure out why a new node gets allocated somewhere around
+	 * here (after the ath_tx_swq() call; and after an ath_stop_locked()
+	 * call!)
+	 */
+
+	ath_draintxq(sc);
+	ath_sc_flushtxq(sc);
+
 	ATH_LOCK(sc);
 	/*
 	 * Reclaim beacon state.  Note this must be done before