[RFT 0/3] ath9k: more PCU locking enhancements

[RFT 0/3] ath9k: more PCU locking enhancements

[Luis R. Rodriguez]

Here is some more PCU locking enhancements I tested today
while trying to resolve the WARN() that happens when we
try to stop RX DMA and fail. While working on that I figured
I'd work on the TX DMA stuff too, here's a shot at it. I
can no longer get TX / RX DMA rants, please test and let
me know if you do. I only tried some basic testing like
rmmoding while scannign, which typicallly produced some
errors. Now I don't get squat.

Ben if you can test wit your super proprietary application
that'd be great.

This also simplifies locking considerably.

This doesn't break suspend so I'm happy. It also depends
on the last RX DMA fixes I had posted earlier. If you'd
like to get an all-in-one patch of all my patches pending
you can wget this file and git am it:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823

If they do indeed fix the rants, then great, but not sure
if they warrant to be stable fixes.

If this works trick was to not mess with contend on the PCU for RX or TX
and for resets, all together. There is one call not protected here
though, the ath_tx_start_dma() but not sure how to address that or if we
need to.

Luis R. Rodriguez (3):
  ath9k: simplify hw reset locking
  ath9k: move the PCU lock to the sc structure
  ath9k: content DMA start / stop through the PCU lock

 drivers/net/wireless/ath/ath9k/ath9k.h |    3 +-
 drivers/net/wireless/ath/ath9k/init.c  |    1 -
 drivers/net/wireless/ath/ath9k/main.c  |   70 ++++++++++++++------------------
 drivers/net/wireless/ath/ath9k/recv.c  |    2 +-
 drivers/net/wireless/ath/ath9k/xmit.c  |    4 +-
 5 files changed, 34 insertions(+), 46 deletions(-)

-- 
1.7.3.2.90.gd4c43

[RFT 1/3] ath9k: simplify hw reset locking

[Luis R. Rodriguez]

The new PCU lock is better placed so we can just contend
against that when trying to reset hardware.

Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/ath9k.h |    1 -
 drivers/net/wireless/ath/ath9k/init.c  |    1 -
 drivers/net/wireless/ath/ath9k/main.c  |   22 ++++++----------------
 drivers/net/wireless/ath/ath9k/xmit.c  |    4 ++--
 4 files changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 9b8e7e3..1b64a30 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -600,7 +600,6 @@ struct ath_softc {
 	struct ath_hw *sc_ah;
 	void __iomem *mem;
 	int irq;
-	spinlock_t sc_resetlock;
 	spinlock_t sc_serial_rw;
 	spinlock_t sc_pm_lock;
 	struct mutex mutex;
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 95b41db..081179d 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -580,7 +580,6 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
 	spin_lock_init(&common->cc_lock);
 
 	spin_lock_init(&sc->wiphy_lock);
-	spin_lock_init(&sc->sc_resetlock);
 	spin_lock_init(&sc->sc_serial_rw);
 	spin_lock_init(&sc->sc_pm_lock);
 	mutex_init(&sc->mutex);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index b52f1cf..5e036af 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -262,19 +262,15 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 		  channel->center_freq, conf_is_ht40(conf),
 		  fastcc);
 
-	spin_lock_bh(&sc->sc_resetlock);
-
 	r = ath9k_hw_reset(ah, hchan, caldata, fastcc);
 	if (r) {
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to reset channel (%u MHz), "
 			  "reset status %d\n",
 			  channel->center_freq, r);
-		spin_unlock_bh(&sc->sc_resetlock);
 		spin_unlock_bh(&sc->rx.pcu_lock);
 		goto ps_restore;
 	}
-	spin_unlock_bh(&sc->sc_resetlock);
 
 	if (ath_startrecv(sc) != 0) {
 		ath_print(common, ATH_DBG_FATAL,
@@ -884,7 +880,6 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
 		ah->curchan = ath_get_curchannel(sc, sc->hw);
 
 	spin_lock_bh(&sc->rx.pcu_lock);
-	spin_lock_bh(&sc->sc_resetlock);
 	r = ath9k_hw_reset(ah, ah->curchan, ah->caldata, false);
 	if (r) {
 		ath_print(common, ATH_DBG_FATAL,
@@ -892,7 +887,6 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
 			  "reset status %d\n",
 			  channel->center_freq, r);
 	}
-	spin_unlock_bh(&sc->sc_resetlock);
 
 	ath_update_txpow(sc);
 	if (ath_startrecv(sc) != 0) {
@@ -949,7 +943,6 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
 	if (!ah->curchan)
 		ah->curchan = ath_get_curchannel(sc, hw);
 
-	spin_lock_bh(&sc->sc_resetlock);
 	r = ath9k_hw_reset(ah, ah->curchan, ah->caldata, false);
 	if (r) {
 		ath_print(ath9k_hw_common(sc->sc_ah), ATH_DBG_FATAL,
@@ -957,7 +950,6 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
 			  "reset status %d\n",
 			  channel->center_freq, r);
 	}
-	spin_unlock_bh(&sc->sc_resetlock);
 
 	ath9k_hw_phy_disable(ah);
 
@@ -988,12 +980,10 @@ int ath_reset(struct ath_softc *sc, bool retry_tx)
 	ath_stoprecv(sc);
 	ath_flushrecv(sc);
 
-	spin_lock_bh(&sc->sc_resetlock);
 	r = ath9k_hw_reset(ah, sc->sc_ah->curchan, ah->caldata, false);
 	if (r)
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to reset hardware; reset status %d\n", r);
-	spin_unlock_bh(&sc->sc_resetlock);
 
 	if (ath_startrecv(sc) != 0)
 		ath_print(common, ATH_DBG_FATAL,
@@ -1164,18 +1154,15 @@ static int ath9k_start(struct ieee80211_hw *hw)
 	 * and then setup of the interrupt mask.
 	 */
 	spin_lock_bh(&sc->rx.pcu_lock);
-	spin_lock_bh(&sc->sc_resetlock);
 	r = ath9k_hw_reset(ah, init_channel, ah->caldata, false);
 	if (r) {
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to reset hardware; reset status %d "
 			  "(freq %u MHz)\n", r,
 			  curchan->center_freq);
-		spin_unlock_bh(&sc->sc_resetlock);
 		spin_unlock_bh(&sc->rx.pcu_lock);
 		goto mutex_unlock;
 	}
-	spin_unlock_bh(&sc->sc_resetlock);
 
 	/*
 	 * This is needed only to setup initial state
@@ -1396,14 +1383,17 @@ static void ath9k_stop(struct ieee80211_hw *hw)
 	 * before setting the invalid flag. */
 	ath9k_hw_set_interrupts(ah, 0);
 
-	spin_lock_bh(&sc->rx.pcu_lock);
 	if (!(sc->sc_flags & SC_OP_INVALID)) {
 		ath_drain_all_txq(sc, false);
+		spin_lock_bh(&sc->rx.pcu_lock);
 		ath_stoprecv(sc);
 		ath9k_hw_phy_disable(ah);
-	} else
+		spin_unlock_bh(&sc->rx.pcu_lock);
+	} else {
+		spin_lock_bh(&sc->rx.pcu_lock);
 		sc->rx.rxlink = NULL;
-	spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->rx.pcu_lock);
+	}
 
 	/* disable HAL and put h/w to sleep */
 	ath9k_hw_disable(ah);
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 30ef2df..6c0de85 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1148,13 +1148,13 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
 		ath_print(common, ATH_DBG_FATAL,
 			  "Failed to stop TX DMA. Resetting hardware!\n");
 
-		spin_lock_bh(&sc->sc_resetlock);
+		spin_lock_bh(&sc->rx.pcu_lock);
 		r = ath9k_hw_reset(ah, sc->sc_ah->curchan, ah->caldata, false);
 		if (r)
 			ath_print(common, ATH_DBG_FATAL,
 				  "Unable to reset hardware; reset status %d\n",
 				  r);
-		spin_unlock_bh(&sc->sc_resetlock);
+		spin_unlock_bh(&sc->rx.pcu_lock);
 	}
 
 	for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
-- 
1.7.3.2.90.gd4c43

[RFT 2/3] ath9k: move the PCU lock to the sc structure

[Luis R. Rodriguez]

The PCU lock should be used to contend TX DMA as well,
this will be done next.

Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/ath9k.h |    2 +-
 drivers/net/wireless/ath/ath9k/main.c  |   42 ++++++++++++++++----------------
 drivers/net/wireless/ath/ath9k/recv.c  |    2 +-
 drivers/net/wireless/ath/ath9k/xmit.c  |    4 +-
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 1b64a30..622f42e 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -310,7 +310,6 @@ struct ath_rx {
 	u8 rxotherant;
 	u32 *rxlink;
 	unsigned int rxfilter;
-	spinlock_t pcu_lock;
 	spinlock_t rxbuflock;
 	struct list_head rxbuf;
 	struct ath_descdma rxdma;
@@ -602,6 +601,7 @@ struct ath_softc {
 	int irq;
 	spinlock_t sc_serial_rw;
 	spinlock_t sc_pm_lock;
+	spinlock_t sc_pcu_lock;
 	struct mutex mutex;
 	struct work_struct paprd_work;
 	struct work_struct hw_check_work;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 5e036af..4196336 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -242,7 +242,7 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 	ath9k_hw_set_interrupts(ah, 0);
 	ath_drain_all_txq(sc, false);
 
-	spin_lock_bh(&sc->rx.pcu_lock);
+	spin_lock_bh(&sc->sc_pcu_lock);
 
 	stopped = ath_stoprecv(sc);
 
@@ -268,7 +268,7 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 			  "Unable to reset channel (%u MHz), "
 			  "reset status %d\n",
 			  channel->center_freq, r);
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 		goto ps_restore;
 	}
 
@@ -276,11 +276,11 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to restart recv logic\n");
 		r = -EIO;
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 		goto ps_restore;
 	}
 
-	spin_unlock_bh(&sc->rx.pcu_lock);
+	spin_unlock_bh(&sc->sc_pcu_lock);
 
 	ath_update_txpow(sc);
 	ath9k_hw_set_interrupts(ah, ah->imask);
@@ -616,7 +616,7 @@ void ath9k_tasklet(unsigned long data)
 		rxmask = (ATH9K_INT_RX | ATH9K_INT_RXEOL | ATH9K_INT_RXORN);
 
 	if (status & rxmask) {
-		spin_lock_bh(&sc->rx.pcu_lock);
+		spin_lock_bh(&sc->sc_pcu_lock);
 
 		/* Check for high priority Rx first */
 		if ((ah->caps.hw_caps & ATH9K_HW_CAP_EDMA) &&
@@ -624,7 +624,7 @@ void ath9k_tasklet(unsigned long data)
 			ath_rx_tasklet(sc, 0, true);
 
 		ath_rx_tasklet(sc, 0, false);
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 	}
 
 	if (status & ATH9K_INT_TX) {
@@ -879,7 +879,7 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
 	if (!ah->curchan)
 		ah->curchan = ath_get_curchannel(sc, sc->hw);
 
-	spin_lock_bh(&sc->rx.pcu_lock);
+	spin_lock_bh(&sc->sc_pcu_lock);
 	r = ath9k_hw_reset(ah, ah->curchan, ah->caldata, false);
 	if (r) {
 		ath_print(common, ATH_DBG_FATAL,
@@ -892,10 +892,10 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
 	if (ath_startrecv(sc) != 0) {
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to restart recv logic\n");
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 		return;
 	}
-	spin_unlock_bh(&sc->rx.pcu_lock);
+	spin_unlock_bh(&sc->sc_pcu_lock);
 
 	if (sc->sc_flags & SC_OP_BEACONS)
 		ath_beacon_config(sc, NULL);	/* restart beacons */
@@ -935,7 +935,7 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
 
 	ath_drain_all_txq(sc, false);	/* clear pending tx frames */
 
-	spin_lock_bh(&sc->rx.pcu_lock);
+	spin_lock_bh(&sc->sc_pcu_lock);
 
 	ath_stoprecv(sc);		/* turn off frame recv */
 	ath_flushrecv(sc);		/* flush recv queue */
@@ -953,7 +953,7 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
 
 	ath9k_hw_phy_disable(ah);
 
-	spin_unlock_bh(&sc->rx.pcu_lock);
+	spin_unlock_bh(&sc->sc_pcu_lock);
 
 	ath9k_hw_configpcipowersave(ah, 1, 1);
 	ath9k_ps_restore(sc);
@@ -975,7 +975,7 @@ int ath_reset(struct ath_softc *sc, bool retry_tx)
 	ath9k_hw_set_interrupts(ah, 0);
 	ath_drain_all_txq(sc, retry_tx);
 
-	spin_lock_bh(&sc->rx.pcu_lock);
+	spin_lock_bh(&sc->sc_pcu_lock);
 
 	ath_stoprecv(sc);
 	ath_flushrecv(sc);
@@ -989,7 +989,7 @@ int ath_reset(struct ath_softc *sc, bool retry_tx)
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to start recv logic\n");
 
-	spin_unlock_bh(&sc->rx.pcu_lock);
+	spin_unlock_bh(&sc->sc_pcu_lock);
 
 	/*
 	 * We may be doing a reset in response to a request
@@ -1153,14 +1153,14 @@ static int ath9k_start(struct ieee80211_hw *hw)
 	 * be followed by initialization of the appropriate bits
 	 * and then setup of the interrupt mask.
 	 */
-	spin_lock_bh(&sc->rx.pcu_lock);
+	spin_lock_bh(&sc->sc_pcu_lock);
 	r = ath9k_hw_reset(ah, init_channel, ah->caldata, false);
 	if (r) {
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to reset hardware; reset status %d "
 			  "(freq %u MHz)\n", r,
 			  curchan->center_freq);
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 		goto mutex_unlock;
 	}
 
@@ -1181,10 +1181,10 @@ static int ath9k_start(struct ieee80211_hw *hw)
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to start recv logic\n");
 		r = -EIO;
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 		goto mutex_unlock;
 	}
-	spin_unlock_bh(&sc->rx.pcu_lock);
+	spin_unlock_bh(&sc->sc_pcu_lock);
 
 	/* Setup our intr mask. */
 	ah->imask = ATH9K_INT_TX | ATH9K_INT_RXEOL |
@@ -1385,14 +1385,14 @@ static void ath9k_stop(struct ieee80211_hw *hw)
 
 	if (!(sc->sc_flags & SC_OP_INVALID)) {
 		ath_drain_all_txq(sc, false);
-		spin_lock_bh(&sc->rx.pcu_lock);
+		spin_lock_bh(&sc->sc_pcu_lock);
 		ath_stoprecv(sc);
 		ath9k_hw_phy_disable(ah);
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 	} else {
-		spin_lock_bh(&sc->rx.pcu_lock);
+		spin_lock_bh(&sc->sc_pcu_lock);
 		sc->rx.rxlink = NULL;
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 	}
 
 	/* disable HAL and put h/w to sleep */
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 26ac6d8..0821664 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -317,7 +317,7 @@ int ath_rx_init(struct ath_softc *sc, int nbufs)
 	struct ath_buf *bf;
 	int error = 0;
 
-	spin_lock_init(&sc->rx.pcu_lock);
+	spin_lock_init(&sc->sc_pcu_lock);
 	sc->sc_flags &= ~SC_OP_RXFLUSH;
 	spin_lock_init(&sc->rx.rxbuflock);
 
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 6c0de85..81f63e52 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1148,13 +1148,13 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
 		ath_print(common, ATH_DBG_FATAL,
 			  "Failed to stop TX DMA. Resetting hardware!\n");
 
-		spin_lock_bh(&sc->rx.pcu_lock);
+		spin_lock_bh(&sc->sc_pcu_lock);
 		r = ath9k_hw_reset(ah, sc->sc_ah->curchan, ah->caldata, false);
 		if (r)
 			ath_print(common, ATH_DBG_FATAL,
 				  "Unable to reset hardware; reset status %d\n",
 				  r);
-		spin_unlock_bh(&sc->rx.pcu_lock);
+		spin_unlock_bh(&sc->sc_pcu_lock);
 	}
 
 	for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
-- 
1.7.3.2.90.gd4c43

[RFT 3/3] ath9k: content DMA start / stop through the PCU lock

[Luis R. Rodriguez]

This helps align resets / RX enable & disable / TX stop / start.
Locking around the PCU is important to ensure the hardware doesn't
get stale data when working with DMA'able data.

Cc: Ben Greear <greearb@candelatech.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/main.c |   52 ++++++++++++++++----------------
 drivers/net/wireless/ath/ath9k/xmit.c |    4 +-
 2 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 4196336..f494bb2 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -230,6 +230,8 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 
 	ath9k_ps_wakeup(sc);
 
+	spin_lock_bh(&sc->sc_pcu_lock);
+
 	/*
 	 * This is only performed if the channel settings have
 	 * actually changed.
@@ -242,8 +244,6 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 	ath9k_hw_set_interrupts(ah, 0);
 	ath_drain_all_txq(sc, false);
 
-	spin_lock_bh(&sc->sc_pcu_lock);
-
 	stopped = ath_stoprecv(sc);
 
 	/* XXX: do not flush receive queue here. We don't want
@@ -268,7 +268,6 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 			  "Unable to reset channel (%u MHz), "
 			  "reset status %d\n",
 			  channel->center_freq, r);
-		spin_unlock_bh(&sc->sc_pcu_lock);
 		goto ps_restore;
 	}
 
@@ -276,12 +275,9 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to restart recv logic\n");
 		r = -EIO;
-		spin_unlock_bh(&sc->sc_pcu_lock);
 		goto ps_restore;
 	}
 
-	spin_unlock_bh(&sc->sc_pcu_lock);
-
 	ath_update_txpow(sc);
 	ath9k_hw_set_interrupts(ah, ah->imask);
 
@@ -292,6 +288,8 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 	}
 
  ps_restore:
+	spin_unlock_bh(&sc->sc_pcu_lock);
+
 	ath9k_ps_restore(sc);
 	return r;
 }
@@ -606,6 +604,8 @@ void ath9k_tasklet(unsigned long data)
 		return;
 	}
 
+	spin_lock_bh(&sc->sc_pcu_lock);
+
 	if (!ath9k_hw_check_alive(ah))
 		ieee80211_queue_work(sc->hw, &sc->hw_check_work);
 
@@ -616,15 +616,12 @@ void ath9k_tasklet(unsigned long data)
 		rxmask = (ATH9K_INT_RX | ATH9K_INT_RXEOL | ATH9K_INT_RXORN);
 
 	if (status & rxmask) {
-		spin_lock_bh(&sc->sc_pcu_lock);
-
 		/* Check for high priority Rx first */
 		if ((ah->caps.hw_caps & ATH9K_HW_CAP_EDMA) &&
 		    (status & ATH9K_INT_RXHP))
 			ath_rx_tasklet(sc, 0, true);
 
 		ath_rx_tasklet(sc, 0, false);
-		spin_unlock_bh(&sc->sc_pcu_lock);
 	}
 
 	if (status & ATH9K_INT_TX) {
@@ -650,6 +647,8 @@ void ath9k_tasklet(unsigned long data)
 
 	/* re-enable hardware interrupt */
 	ath9k_hw_set_interrupts(ah, ah->imask);
+
+	spin_unlock_bh(&sc->sc_pcu_lock);
 	ath9k_ps_restore(sc);
 }
 
@@ -874,12 +873,13 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
 	int r;
 
 	ath9k_ps_wakeup(sc);
+	spin_lock_bh(&sc->sc_pcu_lock);
+
 	ath9k_hw_configpcipowersave(ah, 0, 0);
 
 	if (!ah->curchan)
 		ah->curchan = ath_get_curchannel(sc, sc->hw);
 
-	spin_lock_bh(&sc->sc_pcu_lock);
 	r = ath9k_hw_reset(ah, ah->curchan, ah->caldata, false);
 	if (r) {
 		ath_print(common, ATH_DBG_FATAL,
@@ -895,8 +895,6 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
 		spin_unlock_bh(&sc->sc_pcu_lock);
 		return;
 	}
-	spin_unlock_bh(&sc->sc_pcu_lock);
-
 	if (sc->sc_flags & SC_OP_BEACONS)
 		ath_beacon_config(sc, NULL);	/* restart beacons */
 
@@ -909,6 +907,8 @@ void ath_radio_enable(struct ath_softc *sc, struct ieee80211_hw *hw)
 	ath9k_hw_set_gpio(ah, ah->led_pin, 0);
 
 	ieee80211_wake_queues(hw);
+	spin_unlock_bh(&sc->sc_pcu_lock);
+
 	ath9k_ps_restore(sc);
 }
 
@@ -919,6 +919,8 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
 	int r;
 
 	ath9k_ps_wakeup(sc);
+	spin_lock_bh(&sc->sc_pcu_lock);
+
 	ieee80211_stop_queues(hw);
 
 	/*
@@ -935,8 +937,6 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
 
 	ath_drain_all_txq(sc, false);	/* clear pending tx frames */
 
-	spin_lock_bh(&sc->sc_pcu_lock);
-
 	ath_stoprecv(sc);		/* turn off frame recv */
 	ath_flushrecv(sc);		/* flush recv queue */
 
@@ -953,10 +953,11 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
 
 	ath9k_hw_phy_disable(ah);
 
-	spin_unlock_bh(&sc->sc_pcu_lock);
-
 	ath9k_hw_configpcipowersave(ah, 1, 1);
+
+	spin_unlock_bh(&sc->sc_pcu_lock);
 	ath9k_ps_restore(sc);
+
 	ath9k_setpower(sc, ATH9K_PM_FULL_SLEEP);
 }
 
@@ -970,13 +971,13 @@ int ath_reset(struct ath_softc *sc, bool retry_tx)
 	/* Stop ANI */
 	del_timer_sync(&common->ani.timer);
 
+	spin_lock_bh(&sc->sc_pcu_lock);
+
 	ieee80211_stop_queues(hw);
 
 	ath9k_hw_set_interrupts(ah, 0);
 	ath_drain_all_txq(sc, retry_tx);
 
-	spin_lock_bh(&sc->sc_pcu_lock);
-
 	ath_stoprecv(sc);
 	ath_flushrecv(sc);
 
@@ -989,8 +990,6 @@ int ath_reset(struct ath_softc *sc, bool retry_tx)
 		ath_print(common, ATH_DBG_FATAL,
 			  "Unable to start recv logic\n");
 
-	spin_unlock_bh(&sc->sc_pcu_lock);
-
 	/*
 	 * We may be doing a reset in response to a request
 	 * that changes the channel so update any state that
@@ -1015,6 +1014,7 @@ int ath_reset(struct ath_softc *sc, bool retry_tx)
 	}
 
 	ieee80211_wake_queues(hw);
+	spin_unlock_bh(&sc->sc_pcu_lock);
 
 	/* Start ANI */
 	ath_start_ani(common);
@@ -1379,25 +1379,25 @@ static void ath9k_stop(struct ieee80211_hw *hw)
 			ath9k_btcoex_timer_pause(sc);
 	}
 
+	spin_lock_bh(&sc->sc_pcu_lock);
+
 	/* make sure h/w will not generate any interrupt
 	 * before setting the invalid flag. */
 	ath9k_hw_set_interrupts(ah, 0);
 
 	if (!(sc->sc_flags & SC_OP_INVALID)) {
 		ath_drain_all_txq(sc, false);
-		spin_lock_bh(&sc->sc_pcu_lock);
 		ath_stoprecv(sc);
 		ath9k_hw_phy_disable(ah);
-		spin_unlock_bh(&sc->sc_pcu_lock);
-	} else {
-		spin_lock_bh(&sc->sc_pcu_lock);
+	} else
 		sc->rx.rxlink = NULL;
-		spin_unlock_bh(&sc->sc_pcu_lock);
-	}
 
 	/* disable HAL and put h/w to sleep */
 	ath9k_hw_disable(ah);
 	ath9k_hw_configpcipowersave(ah, 1, 1);
+
+	spin_unlock_bh(&sc->sc_pcu_lock);
+
 	ath9k_ps_restore(sc);
 
 	/* Finally, put the chip in FULL SLEEP mode */
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 81f63e52..e1383e5 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1148,13 +1148,11 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
 		ath_print(common, ATH_DBG_FATAL,
 			  "Failed to stop TX DMA. Resetting hardware!\n");
 
-		spin_lock_bh(&sc->sc_pcu_lock);
 		r = ath9k_hw_reset(ah, sc->sc_ah->curchan, ah->caldata, false);
 		if (r)
 			ath_print(common, ATH_DBG_FATAL,
 				  "Unable to reset hardware; reset status %d\n",
 				  r);
-		spin_unlock_bh(&sc->sc_pcu_lock);
 	}
 
 	for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
@@ -1780,7 +1778,9 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
 	}
 	spin_unlock_bh(&txq->axq_lock);
 
+	//spin_lock_bh(&sc->sc_pcu_lock);
 	ath_tx_start_dma(sc, bf, txctl);
+	//spin_unlock_bh(&sc->sc_pcu_lock);
 
 	return 0;
 }
-- 
1.7.3.2.90.gd4c43

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Ben Greear]

On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
> Here is some more PCU locking enhancements I tested today
> while trying to resolve the WARN() that happens when we
> try to stop RX DMA and fail. While working on that I figured
> I'd work on the TX DMA stuff too, here's a shot at it. I
> can no longer get TX / RX DMA rants, please test and let
> me know if you do. I only tried some basic testing like
> rmmoding while scannign, which typicallly produced some
> errors. Now I don't get squat.
>
> Ben if you can test wit your super proprietary application
> that'd be great.

I'll make every effort, we should have some testing results later
today.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Ben Greear]

On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
> Here is some more PCU locking enhancements I tested today
> while trying to resolve the WARN() that happens when we
> try to stop RX DMA and fail. While working on that I figured
> I'd work on the TX DMA stuff too, here's a shot at it. I
> can no longer get TX / RX DMA rants, please test and let
> me know if you do. I only tried some basic testing like
> rmmoding while scannign, which typicallly produced some
> errors. Now I don't get squat.
>
> Ben if you can test wit your super proprietary application
> that'd be great.
>
> This also simplifies locking considerably.
>
> This doesn't break suspend so I'm happy. It also depends
> on the last RX DMA fixes I had posted earlier. If you'd
> like to get an all-in-one patch of all my patches pending
> you can wget this file and git am it:
>
> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823

I have done some initial testing on the combined patch on top of today's
wireless-testing tree.  I also have the memory-barrier patch applied to
ath9k, as that is still not upstream.  I have no idea if it has any affect
or not (I'm on x86..seems that wmb() stuff was mostly for other platforms?).

So far, it is showing zero problems, certainly no memory poison issues.

The wireless-testing tree has some lockdep warning related to a mouse driver
that disables lockdep early, so it's possible there are lockdep issues waiting.

I will let this test run for a while, but it already looks more stable
than before, so:

Tested-by:  Ben Greear <greearb@candelatech.com>

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Luis R. Rodriguez]

On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
>>
>> Here is some more PCU locking enhancements I tested today
>> while trying to resolve the WARN() that happens when we
>> try to stop RX DMA and fail. While working on that I figured
>> I'd work on the TX DMA stuff too, here's a shot at it. I
>> can no longer get TX / RX DMA rants, please test and let
>> me know if you do. I only tried some basic testing like
>> rmmoding while scannign, which typicallly produced some
>> errors. Now I don't get squat.
>>
>> Ben if you can test wit your super proprietary application
>> that'd be great.
>>
>> This also simplifies locking considerably.
>>
>> This doesn't break suspend so I'm happy. It also depends
>> on the last RX DMA fixes I had posted earlier. If you'd
>> like to get an all-in-one patch of all my patches pending
>> you can wget this file and git am it:
>>
>>
>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
>> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
>
> I have done some initial testing on the combined patch on top of today's
> wireless-testing tree.  I also have the memory-barrier patch applied to
> ath9k, as that is still not upstream.  I have no idea if it has any affect
> or not (I'm on x86..seems that wmb() stuff was mostly for other platforms?).
>
> So far, it is showing zero problems, certainly no memory poison issues.
>
> The wireless-testing tree has some lockdep warning related to a mouse driver
> that disables lockdep early, so it's possible there are lockdep issues
> waiting.
>
> I will let this test run for a while, but it already looks more stable
> than before, so:
>
> Tested-by:  Ben Greear <greearb@candelatech.com>

Awesome! Thanks for testing. So how about the TX dma rants, do you
still get those?

  Luis

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Ben Greear]

On 10/26/2010 03:03 PM, Luis R. Rodriguez wrote:
> On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
>>>
>>> Here is some more PCU locking enhancements I tested today
>>> while trying to resolve the WARN() that happens when we
>>> try to stop RX DMA and fail. While working on that I figured
>>> I'd work on the TX DMA stuff too, here's a shot at it. I
>>> can no longer get TX / RX DMA rants, please test and let
>>> me know if you do. I only tried some basic testing like
>>> rmmoding while scannign, which typicallly produced some
>>> errors. Now I don't get squat.
>>>
>>> Ben if you can test wit your super proprietary application
>>> that'd be great.
>>>
>>> This also simplifies locking considerably.
>>>
>>> This doesn't break suspend so I'm happy. It also depends
>>> on the last RX DMA fixes I had posted earlier. If you'd
>>> like to get an all-in-one patch of all my patches pending
>>> you can wget this file and git am it:
>>>
>>>
>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
>>> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
>>
>> I have done some initial testing on the combined patch on top of today's
>> wireless-testing tree.  I also have the memory-barrier patch applied to
>> ath9k, as that is still not upstream.  I have no idea if it has any affect
>> or not (I'm on x86..seems that wmb() stuff was mostly for other platforms?).
>>
>> So far, it is showing zero problems, certainly no memory poison issues.
>>
>> The wireless-testing tree has some lockdep warning related to a mouse driver
>> that disables lockdep early, so it's possible there are lockdep issues
>> waiting.
>>
>> I will let this test run for a while, but it already looks more stable
>> than before, so:
>>
>> Tested-by:  Ben Greear<greearb@candelatech.com>
>
> Awesome! Thanks for testing. So how about the TX dma rants, do you
> still get those?

I've seen no rants at all.

I'm using my standard 130 STAs trying to associate with an AP that will only
take around 30 associations at a time..leads to 100 or so supplications constantly
trying to scan and associate, and I've never seen this test run more than about
10 minutes without poison warnings and/or lockups.  I used to be happy when it got that far :)

We'll do some more interesting tests with APs + STAs, as well as throughput tests, etc
as soon as we get time.  (Basically, hoping for same support that we pushed into ath5k
recently).

If you are aware of any existing/expected issues with multiple APs + STAs,
please let me know.

Thanks,
Ben

>
>    Luis


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Luis R. Rodriguez]

On Tue, Oct 26, 2010 at 3:11 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 10/26/2010 03:03 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
>>>>
>>>> Here is some more PCU locking enhancements I tested today
>>>> while trying to resolve the WARN() that happens when we
>>>> try to stop RX DMA and fail. While working on that I figured
>>>> I'd work on the TX DMA stuff too, here's a shot at it. I
>>>> can no longer get TX / RX DMA rants, please test and let
>>>> me know if you do. I only tried some basic testing like
>>>> rmmoding while scannign, which typicallly produced some
>>>> errors. Now I don't get squat.
>>>>
>>>> Ben if you can test wit your super proprietary application
>>>> that'd be great.
>>>>
>>>> This also simplifies locking considerably.
>>>>
>>>> This doesn't break suspend so I'm happy. It also depends
>>>> on the last RX DMA fixes I had posted earlier. If you'd
>>>> like to get an all-in-one patch of all my patches pending
>>>> you can wget this file and git am it:
>>>>
>>>>
>>>>
>>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
>>>> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
>>>
>>> I have done some initial testing on the combined patch on top of today's
>>> wireless-testing tree.  I also have the memory-barrier patch applied to
>>> ath9k, as that is still not upstream.  I have no idea if it has any
>>> affect
>>> or not (I'm on x86..seems that wmb() stuff was mostly for other
>>> platforms?).
>>>
>>> So far, it is showing zero problems, certainly no memory poison issues.
>>>
>>> The wireless-testing tree has some lockdep warning related to a mouse
>>> driver
>>> that disables lockdep early, so it's possible there are lockdep issues
>>> waiting.
>>>
>>> I will let this test run for a while, but it already looks more stable
>>> than before, so:
>>>
>>> Tested-by:  Ben Greear<greearb@candelatech.com>
>>
>> Awesome! Thanks for testing. So how about the TX dma rants, do you
>> still get those?
>
> I've seen no rants at all.

Fucking awesome!

> I'm using my standard 130 STAs

I love how now 130 STAs are "standard" for ath9k tests :)

> trying to associate with an AP that will only
> take around 30 associations at a time..leads to 100 or so supplications
> constantly
> trying to scan and associate, and I've never seen this test run more than
> about
> 10 minutes without poison warnings and/or lockups.  I used to be happy when
> it got that far :)

:)

> We'll do some more interesting tests with APs + STAs, as well as throughput
> tests, etc
> as soon as we get time.  (Basically, hoping for same support that we pushed
> into ath5k
> recently).

Nice!

> If you are aware of any existing/expected issues with multiple APs + STAs,
> please let me know.

This was my last hunch on issues. Thanks a lot of testing and please
let us know if you run into any other issues.

  Luis

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Ben Greear]

On 10/26/2010 03:17 PM, Luis R. Rodriguez wrote:
> On Tue, Oct 26, 2010 at 3:11 PM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 10/26/2010 03:03 PM, Luis R. Rodriguez wrote:
>>>
>>> On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear<greearb@candelatech.com>
>>>   wrote:
>>>>
>>>> On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
>>>>>
>>>>> Here is some more PCU locking enhancements I tested today
>>>>> while trying to resolve the WARN() that happens when we
>>>>> try to stop RX DMA and fail. While working on that I figured
>>>>> I'd work on the TX DMA stuff too, here's a shot at it. I
>>>>> can no longer get TX / RX DMA rants, please test and let
>>>>> me know if you do. I only tried some basic testing like
>>>>> rmmoding while scannign, which typicallly produced some
>>>>> errors. Now I don't get squat.
>>>>>
>>>>> Ben if you can test wit your super proprietary application
>>>>> that'd be great.
>>>>>
>>>>> This also simplifies locking considerably.
>>>>>
>>>>> This doesn't break suspend so I'm happy. It also depends
>>>>> on the last RX DMA fixes I had posted earlier. If you'd
>>>>> like to get an all-in-one patch of all my patches pending
>>>>> you can wget this file and git am it:
>>>>>
>>>>>
>>>>>
>>>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
>>>>> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
>>>>
>>>> I have done some initial testing on the combined patch on top of today's
>>>> wireless-testing tree.  I also have the memory-barrier patch applied to
>>>> ath9k, as that is still not upstream.  I have no idea if it has any
>>>> affect
>>>> or not (I'm on x86..seems that wmb() stuff was mostly for other
>>>> platforms?).
>>>>
>>>> So far, it is showing zero problems, certainly no memory poison issues.
>>>>
>>>> The wireless-testing tree has some lockdep warning related to a mouse
>>>> driver
>>>> that disables lockdep early, so it's possible there are lockdep issues
>>>> waiting.
>>>>
>>>> I will let this test run for a while, but it already looks more stable
>>>> than before, so:
>>>>
>>>> Tested-by:  Ben Greear<greearb@candelatech.com>
>>>
>>> Awesome! Thanks for testing. So how about the TX dma rants, do you
>>> still get those?
>>
>> I've seen no rants at all.
>
> Fucking awesome!
>
>> I'm using my standard 130 STAs
>
> I love how now 130 STAs are "standard" for ath9k tests :)

I dropped it down to 30 STAs so that all could associate and
be stable with my AP.  I set up a tcp stream running as fast as it could between
two virtual STAs.  It ran about 9Mbps bi-directional overnight
with no obvious problems.

One way or another, I will probably end up backporting this to 2.6.36,
so it wouldn't bother me at all to see these changes show up in stable.

We'll keep testing various scenarios in the meantime...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Luis R. Rodriguez]

On Wed, Oct 27, 2010 at 9:17 AM, Ben Greear <greearb@candelatech.com> wrote:
> On 10/26/2010 03:17 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Oct 26, 2010 at 3:11 PM, Ben Greear<greearb@candelatech.com>
>>  wrote:
>>>
>>> On 10/26/2010 03:03 PM, Luis R. Rodriguez wrote:
>>>>
>>>> On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear<greearb@candelatech.com>
>>>>  wrote:
>>>>>
>>>>> On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
>>>>>>
>>>>>> Here is some more PCU locking enhancements I tested today
>>>>>> while trying to resolve the WARN() that happens when we
>>>>>> try to stop RX DMA and fail. While working on that I figured
>>>>>> I'd work on the TX DMA stuff too, here's a shot at it. I
>>>>>> can no longer get TX / RX DMA rants, please test and let
>>>>>> me know if you do. I only tried some basic testing like
>>>>>> rmmoding while scannign, which typicallly produced some
>>>>>> errors. Now I don't get squat.
>>>>>>
>>>>>> Ben if you can test wit your super proprietary application
>>>>>> that'd be great.
>>>>>>
>>>>>> This also simplifies locking considerably.
>>>>>>
>>>>>> This doesn't break suspend so I'm happy. It also depends
>>>>>> on the last RX DMA fixes I had posted earlier. If you'd
>>>>>> like to get an all-in-one patch of all my patches pending
>>>>>> you can wget this file and git am it:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
>>>>>> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
>>>>>
>>>>> I have done some initial testing on the combined patch on top of
>>>>> today's
>>>>> wireless-testing tree.  I also have the memory-barrier patch applied to
>>>>> ath9k, as that is still not upstream.  I have no idea if it has any
>>>>> affect
>>>>> or not (I'm on x86..seems that wmb() stuff was mostly for other
>>>>> platforms?).
>>>>>
>>>>> So far, it is showing zero problems, certainly no memory poison issues.
>>>>>
>>>>> The wireless-testing tree has some lockdep warning related to a mouse
>>>>> driver
>>>>> that disables lockdep early, so it's possible there are lockdep issues
>>>>> waiting.
>>>>>
>>>>> I will let this test run for a while, but it already looks more stable
>>>>> than before, so:
>>>>>
>>>>> Tested-by:  Ben Greear<greearb@candelatech.com>
>>>>
>>>> Awesome! Thanks for testing. So how about the TX dma rants, do you
>>>> still get those?
>>>
>>> I've seen no rants at all.
>>
>> Fucking awesome!
>>
>>> I'm using my standard 130 STAs
>>
>> I love how now 130 STAs are "standard" for ath9k tests :)
>
> I dropped it down to 30 STAs so that all could associate and
> be stable with my AP.  I set up a tcp stream running as fast as it could
> between
> two virtual STAs.  It ran about 9Mbps bi-directional overnight
> with no obvious problems.

Thanks for the reports, great to hear it is working fine now.

> One way or another, I will probably end up backporting this to 2.6.36,
> so it wouldn't bother me at all to see these changes show up in stable.
>
> We'll keep testing various scenarios in the meantime...

I've submitted my patches for stable. My series of cfg80211 fixes
(also marked for stable) and ath9k PCU fixes have been backported for
2.6.36 here:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2010-10-26/pending-2.6.36-2010-10-26.patch

These can be merged once they hit Linus' tree.

  Luis

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Ben Greear]

On 10/27/2010 09:26 AM, Luis R. Rodriguez wrote:
> On Wed, Oct 27, 2010 at 9:17 AM, Ben Greear<greearb@candelatech.com>  wrote:
>> On 10/26/2010 03:17 PM, Luis R. Rodriguez wrote:
>>>
>>> On Tue, Oct 26, 2010 at 3:11 PM, Ben Greear<greearb@candelatech.com>
>>>   wrote:
>>>>
>>>> On 10/26/2010 03:03 PM, Luis R. Rodriguez wrote:
>>>>>
>>>>> On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear<greearb@candelatech.com>
>>>>>   wrote:
>>>>>>
>>>>>> On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
>>>>>>>
>>>>>>> Here is some more PCU locking enhancements I tested today
>>>>>>> while trying to resolve the WARN() that happens when we
>>>>>>> try to stop RX DMA and fail. While working on that I figured
>>>>>>> I'd work on the TX DMA stuff too, here's a shot at it. I
>>>>>>> can no longer get TX / RX DMA rants, please test and let
>>>>>>> me know if you do. I only tried some basic testing like
>>>>>>> rmmoding while scannign, which typicallly produced some
>>>>>>> errors. Now I don't get squat.
>>>>>>>
>>>>>>> Ben if you can test wit your super proprietary application
>>>>>>> that'd be great.
>>>>>>>
>>>>>>> This also simplifies locking considerably.
>>>>>>>
>>>>>>> This doesn't break suspend so I'm happy. It also depends
>>>>>>> on the last RX DMA fixes I had posted earlier. If you'd
>>>>>>> like to get an all-in-one patch of all my patches pending
>>>>>>> you can wget this file and git am it:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
>>>>>>> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
>>>>>>
>>>>>> I have done some initial testing on the combined patch on top of
>>>>>> today's
>>>>>> wireless-testing tree.  I also have the memory-barrier patch applied to
>>>>>> ath9k, as that is still not upstream.  I have no idea if it has any
>>>>>> affect
>>>>>> or not (I'm on x86..seems that wmb() stuff was mostly for other
>>>>>> platforms?).
>>>>>>
>>>>>> So far, it is showing zero problems, certainly no memory poison issues.
>>>>>>
>>>>>> The wireless-testing tree has some lockdep warning related to a mouse
>>>>>> driver
>>>>>> that disables lockdep early, so it's possible there are lockdep issues
>>>>>> waiting.
>>>>>>
>>>>>> I will let this test run for a while, but it already looks more stable
>>>>>> than before, so:
>>>>>>
>>>>>> Tested-by:  Ben Greear<greearb@candelatech.com>
>>>>>
>>>>> Awesome! Thanks for testing. So how about the TX dma rants, do you
>>>>> still get those?
>>>>
>>>> I've seen no rants at all.
>>>
>>> Fucking awesome!
>>>
>>>> I'm using my standard 130 STAs
>>>
>>> I love how now 130 STAs are "standard" for ath9k tests :)
>>
>> I dropped it down to 30 STAs so that all could associate and
>> be stable with my AP.  I set up a tcp stream running as fast as it could
>> between
>> two virtual STAs.  It ran about 9Mbps bi-directional overnight
>> with no obvious problems.
>
> Thanks for the reports, great to hear it is working fine now.

Of course, as soon as I hit send, something starts looking strange.

One of the interfaces generating ~9Mbps of traffic started bouncing,
with warnings about a class 2 frame received.  Any idea what
that means?

Not sure it's an ath9k issue though, as power-cycling the AP made
everything start working again.  So, plz don't worry about this
until we have a chance to test against different APs, etc.

2010-10-27 08:28:06.066  sta11 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:06.075  sta14 (phy #0): scan started
2010-10-27 08:28:06.947  sta14 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:06.994  sta26 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 reason 6: Class 2 frame received from non-authenticated station



2010-10-27 08:28:06.998  sta26 (phy #0): disconnected (by AP) reason: 6: Class 2 frame received from non-authenticated station
2010-10-27 08:28:07.038  sta14 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:0d status: 0: Successful
2010-10-27 08:28:07.038  sta14: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:07.038  sta14 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:0d status: 0: Successful
2010-10-27 08:28:07.038  sta14 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:07.093  sta17 (phy #0): scan started
2010-10-27 08:28:07.961  sta17 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:08.018  sta17 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:10 status: 0: Successful
2010-10-27 08:28:08.027  sta17: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:08.037  sta17 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:10 status: 0: Successful
2010-10-27 08:28:08.038  sta17 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:08.074  sta26 (phy #0): scan started
2010-10-27 08:28:08.943  sta26 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:08.983  sta7 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:06 reason 0: <unknown>
2010-10-27 08:28:08.983  sta7 (phy #0): disconnected (by AP)
2010-10-27 08:28:09.014  sta26 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 status: 0: Successful
2010-10-27 08:28:09.018  sta26: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:09.028  sta26 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 status: 0: Successful
2010-10-27 08:28:09.028  sta26 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:09.053  sta8 (phy #0): scan started
2010-10-27 08:28:09.913  sta8 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
2010-10-27 08:28:09.957  sta23 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:16 reason 0: <unknown>
2010-10-27 08:28:09.958  sta23 (phy #0): disconnected (by AP)
2010-10-27 08:28:09.999  sta8 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:07 status: 0: Successful
2010-10-27 08:28:10.003  sta8: new station 00:14:d1:c6:d2:54
2010-10-27 08:28:10.014  sta8 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:07 status: 0: Successful
2010-10-27 08:28:10.014  sta8 (phy #0): connected to 00:14:d1:c6:d2:54
2010-10-27 08:28:10.035  sta23 (phy #0): scan started

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [RFT 0/3] ath9k: more PCU locking enhancements

[Luis R. Rodriguez]

On Wed, Oct 27, 2010 at 09:38:00AM -0700, Ben Greear wrote:
> On 10/27/2010 09:26 AM, Luis R. Rodriguez wrote:
> > On Wed, Oct 27, 2010 at 9:17 AM, Ben Greear<greearb@candelatech.com>  wrote:
> >> On 10/26/2010 03:17 PM, Luis R. Rodriguez wrote:
> >>>
> >>> On Tue, Oct 26, 2010 at 3:11 PM, Ben Greear<greearb@candelatech.com>
> >>>   wrote:
> >>>>
> >>>> On 10/26/2010 03:03 PM, Luis R. Rodriguez wrote:
> >>>>>
> >>>>> On Tue, Oct 26, 2010 at 2:59 PM, Ben Greear<greearb@candelatech.com>
> >>>>>   wrote:
> >>>>>>
> >>>>>> On 10/26/2010 01:40 AM, Luis R. Rodriguez wrote:
> >>>>>>>
> >>>>>>> Here is some more PCU locking enhancements I tested today
> >>>>>>> while trying to resolve the WARN() that happens when we
> >>>>>>> try to stop RX DMA and fail. While working on that I figured
> >>>>>>> I'd work on the TX DMA stuff too, here's a shot at it. I
> >>>>>>> can no longer get TX / RX DMA rants, please test and let
> >>>>>>> me know if you do. I only tried some basic testing like
> >>>>>>> rmmoding while scannign, which typicallly produced some
> >>>>>>> errors. Now I don't get squat.
> >>>>>>>
> >>>>>>> Ben if you can test wit your super proprietary application
> >>>>>>> that'd be great.
> >>>>>>>
> >>>>>>> This also simplifies locking considerably.
> >>>>>>>
> >>>>>>> This doesn't break suspend so I'm happy. It also depends
> >>>>>>> on the last RX DMA fixes I had posted earlier. If you'd
> >>>>>>> like to get an all-in-one patch of all my patches pending
> >>>>>>> you can wget this file and git am it:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/tmp/pending-mcgrof-2010-10-26-v1.patch
> >>>>>>> sha1sum: 874a3cc1a57f7e26ad191cd7b5045315f94c5823
> >>>>>>
> >>>>>> I have done some initial testing on the combined patch on top of
> >>>>>> today's
> >>>>>> wireless-testing tree.  I also have the memory-barrier patch applied to
> >>>>>> ath9k, as that is still not upstream.  I have no idea if it has any
> >>>>>> affect
> >>>>>> or not (I'm on x86..seems that wmb() stuff was mostly for other
> >>>>>> platforms?).
> >>>>>>
> >>>>>> So far, it is showing zero problems, certainly no memory poison issues.
> >>>>>>
> >>>>>> The wireless-testing tree has some lockdep warning related to a mouse
> >>>>>> driver
> >>>>>> that disables lockdep early, so it's possible there are lockdep issues
> >>>>>> waiting.
> >>>>>>
> >>>>>> I will let this test run for a while, but it already looks more stable
> >>>>>> than before, so:
> >>>>>>
> >>>>>> Tested-by:  Ben Greear<greearb@candelatech.com>
> >>>>>
> >>>>> Awesome! Thanks for testing. So how about the TX dma rants, do you
> >>>>> still get those?
> >>>>
> >>>> I've seen no rants at all.
> >>>
> >>> Fucking awesome!
> >>>
> >>>> I'm using my standard 130 STAs
> >>>
> >>> I love how now 130 STAs are "standard" for ath9k tests :)
> >>
> >> I dropped it down to 30 STAs so that all could associate and
> >> be stable with my AP.  I set up a tcp stream running as fast as it could
> >> between
> >> two virtual STAs.  It ran about 9Mbps bi-directional overnight
> >> with no obvious problems.
> >
> > Thanks for the reports, great to hear it is working fine now.
> 
> Of course, as soon as I hit send, something starts looking strange.
> 
> One of the interfaces generating ~9Mbps of traffic started bouncing,
> with warnings about a class 2 frame received.  Any idea what
> that means?
> 
> Not sure it's an ath9k issue though, as power-cycling the AP made
> everything start working again.  So, plz don't worry about this
> until we have a chance to test against different APs, etc.
> 
> 2010-10-27 08:28:06.066  sta11 (phy #0): connected to 00:14:d1:c6:d2:54
> 2010-10-27 08:28:06.075  sta14 (phy #0): scan started
> 2010-10-27 08:28:06.947  sta14 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
> 2010-10-27 08:28:06.994  sta26 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 reason 6: Class 2 frame received from non-authenticated station

Not sure what these are, but it seems like your AP decided to kick fist STA off.

> 2010-10-27 08:28:06.998  sta26 (phy #0): disconnected (by AP) reason: 6: Class 2 frame received from non-authenticated station
> 2010-10-27 08:28:07.038  sta14 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:0d status: 0: Successful
> 2010-10-27 08:28:07.038  sta14: new station 00:14:d1:c6:d2:54
> 2010-10-27 08:28:07.038  sta14 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:0d status: 0: Successful
> 2010-10-27 08:28:07.038  sta14 (phy #0): connected to 00:14:d1:c6:d2:54
> 2010-10-27 08:28:07.093  sta17 (phy #0): scan started
> 2010-10-27 08:28:07.961  sta17 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
> 2010-10-27 08:28:08.018  sta17 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:10 status: 0: Successful
> 2010-10-27 08:28:08.027  sta17: new station 00:14:d1:c6:d2:54
> 2010-10-27 08:28:08.037  sta17 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:10 status: 0: Successful
> 2010-10-27 08:28:08.038  sta17 (phy #0): connected to 00:14:d1:c6:d2:54
> 2010-10-27 08:28:08.074  sta26 (phy #0): scan started
> 2010-10-27 08:28:08.943  sta26 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
> 2010-10-27 08:28:08.983  sta7 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:06 reason 0: <unknown>

And not sure why but your AP decided to kiss your secondary STA goodbye.

> 2010-10-27 08:28:08.983  sta7 (phy #0): disconnected (by AP)
> 2010-10-27 08:28:09.014  sta26 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 status: 0: Successful
> 2010-10-27 08:28:09.018  sta26: new station 00:14:d1:c6:d2:54
> 2010-10-27 08:28:09.028  sta26 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:19 status: 0: Successful
> 2010-10-27 08:28:09.028  sta26 (phy #0): connected to 00:14:d1:c6:d2:54
> 2010-10-27 08:28:09.053  sta8 (phy #0): scan started
> 2010-10-27 08:28:09.913  sta8 (phy #0): scan finished: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462, ""
> 2010-10-27 08:28:09.957  sta23 (phy #0): deauth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:16 reason 0: <unknown>

And another STA gets kicked off.

> 2010-10-27 08:28:09.958  sta23 (phy #0): disconnected (by AP)
> 2010-10-27 08:28:09.999  sta8 (phy #0): auth 00:14:d1:c6:d2:54 -> 00:00:00:88:55:07 status: 0: Successful
> 2010-10-27 08:28:10.003  sta8: new station 00:14:d1:c6:d2:54
> 2010-10-27 08:28:10.014  sta8 (phy #0): assoc 00:14:d1:c6:d2:54 -> 00:00:00:88:55:07 status: 0: Successful
> 2010-10-27 08:28:10.014  sta8 (phy #0): connected to 00:14:d1:c6:d2:54
> 2010-10-27 08:28:10.035  sta23 (phy #0): scan started

   Luis