[ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Nicolas Cavallari]

With an AR9382 (well, i think, its PCI-id is 168c:0030 rev 1/168c:3116),
each time I join an IBSS network, the driver repeatedly
resets the queue for a while, because of too many missed beacons.  After
some time, this stops and the card behave normally.  But many packets
are lost in the process.

The problem seems to aggravate when the number of IBSS nodes is higher :
When joining a IBSS network with only one node, Only a few (e.g. 4)
beacons are lost, and no reset takes places. When joining an IBSS
network with two nodes, the queues can be reset up to 224 times in 20
seconds. When joining large IBSS networks, it sometimes never stop
resetting.  Occasionally, when resetting, the driver fails to reset TX DMA

If i hack the driver to not reset when the beacon is stuck, the beacon
tx resumes quickly by itself after 80-200 misses and the network seems
to work normally (if not better). On large&clogged ad-hoc networks, the
card sometimes miss between 1 and 80 beacons, but it might be due to
background scanning i think.

What could be the problem here ? is ad-hoc beaconing kind of broken ?
I do not have the problem with AR9285.

Logs with compat-wireless 2012-09-16 showing an iteration of the reset
loop :

[346208.955736] ath: phy0: TS Start 0x35ac8000 End 0x35acc800 Virt
f5ac8000, Size 512
[346208.957662] ath: phy0: Enabled BB Watchdog timeout (25 ms)
[346208.957832] ath: phy0: IBSS nexttbtt: 102400 intval: 102400
conf_intval: 100
[346208.957876] ath: phy0: Set queue properties for: 9
[346208.957886] ath: phy0: Reset TX queue: 9
[346209.019579] ath: phy0: transmitting packet, skb: edc5a480
[346209.019600] ath: phy0: qnum: 2, txq depth: 0
[346209.019612] ath: phy0: TXDP[2] = 3082ff80 (f082ff80)
[346209.020968] ath: phy0: TX complete: skb: edc5a480
[346209.046911] ath: phy0: slot 0, tsf: 347602220263
[346209.046946] ath: phy0: Transmitting beacon for slot: 0
[346209.047083] ath: phy0: MAC Hang signature not found at DCU complete
[346209.047108] ath: phy0: missed 1 consecutive beacons
[346209.048182] ath: phy0: MAC Hang signature not found at DCU complete
[346209.048194] ath: phy0: missed 2 consecutive beacons
[346209.049231] ath: phy0: MAC Hang signature not found at DCU complete
[346209.049259] ath: phy0: missed 3 consecutive beacons
[346209.050449] ath: phy0: MAC Hang signature not found at DCU complete
[346209.050475] ath: phy0: missed 4 consecutive beacons
[346209.051748] ath: phy0: MAC Hang signature not found at DCU complete
[346209.051776] ath: phy0: missed 5 consecutive beacons
[346209.052776] ath: phy0: MAC Hang signature not found at DCU complete
[346209.052789] ath: phy0: missed 6 consecutive beacons
[346209.053789] ath: phy0: MAC Hang signature not found at DCU complete
[346209.053802] ath: phy0: missed 7 consecutive beacons
[346209.054817] ath: phy0: MAC Hang signature not found at DCU complete
[346209.054848] ath: phy0: missed 8 consecutive beacons
[346209.056082] ath: phy0: MAC Hang signature not found at DCU complete
[346209.056108] ath: phy0: beacon is officially stuck
[346209.056152] ath: phy0: reset work is pending, skip beaconing now
[346209.069038] ath: phy0: Reset TX queue: 0
[346209.069051] ath: phy0: Reset TX queue: 1
[346209.069061] ath: phy0: Reset TX queue: 2
[346209.069070] ath: phy0: Reset TX queue: 3
[346209.069080] ath: phy0: Reset TXQ, inactive queue: 4
[346209.069087] ath: phy0: Reset TXQ, inactive queue: 5
[346209.069095] ath: phy0: Reset TXQ, inactive queue: 6
[346209.069102] ath: phy0: Reset TXQ, inactive queue: 7
[346209.069110] ath: phy0: Reset TX queue: 8
[346209.069125] ath: phy0: Reset TX queue: 9
[346209.069158] ath: phy0: ah->misc_mode 0x10000004
[...]

[ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Nicolas Cavallari]

[resending, as no archive saw my previous message]

With an AR9382 (well, i think, its PCI-id is 168c:0030 rev 1/168c:3116),
each time I join an IBSS network, the driver repeatedly
resets the queue for a while, because of too many missed beacons.  After
some time, this stops and the card behave normally.  But many packets
are lost in the process.

The problem seems to aggravate when the number of IBSS nodes is higher :
When joining a IBSS network with only one node, Only a few (e.g. 4)
beacons are lost, and no reset takes places. When joining an IBSS
network with two nodes, the queues can be reset up to 224 times in 20
seconds. When joining large IBSS networks, it sometimes never stop
resetting.  Occasionally, when resetting, the driver fails to reset TX DMA

If i hack the driver to not reset when the beacon is stuck, the beacon
tx resumes quickly by itself after 80-200 misses and the network seems
to work normally (if not better). On large&clogged ad-hoc networks, the
card sometimes miss between 1 and 80 beacons, but it might be due to
background scanning i think.

What could be the problem here ? is ad-hoc beaconing kind of broken ?
I do not have the problem with AR9285.

Logs with compat-wireless 2012-09-16 showing an iteration of the reset
loop :

[346208.955736] ath: phy0: TS Start 0x35ac8000 End 0x35acc800 Virt
f5ac8000, Size 512
[346208.957662] ath: phy0: Enabled BB Watchdog timeout (25 ms)
[346208.957832] ath: phy0: IBSS nexttbtt: 102400 intval: 102400
conf_intval: 100
[346208.957876] ath: phy0: Set queue properties for: 9
[346208.957886] ath: phy0: Reset TX queue: 9
[346209.019579] ath: phy0: transmitting packet, skb: edc5a480
[346209.019600] ath: phy0: qnum: 2, txq depth: 0
[346209.019612] ath: phy0: TXDP[2] = 3082ff80 (f082ff80)
[346209.020968] ath: phy0: TX complete: skb: edc5a480
[346209.046911] ath: phy0: slot 0, tsf: 347602220263
[346209.046946] ath: phy0: Transmitting beacon for slot: 0
[346209.047083] ath: phy0: MAC Hang signature not found at DCU complete
[346209.047108] ath: phy0: missed 1 consecutive beacons
[346209.048182] ath: phy0: MAC Hang signature not found at DCU complete
[346209.048194] ath: phy0: missed 2 consecutive beacons
[346209.049231] ath: phy0: MAC Hang signature not found at DCU complete
[346209.049259] ath: phy0: missed 3 consecutive beacons
[346209.050449] ath: phy0: MAC Hang signature not found at DCU complete
[346209.050475] ath: phy0: missed 4 consecutive beacons
[346209.051748] ath: phy0: MAC Hang signature not found at DCU complete
[346209.051776] ath: phy0: missed 5 consecutive beacons
[346209.052776] ath: phy0: MAC Hang signature not found at DCU complete
[346209.052789] ath: phy0: missed 6 consecutive beacons
[346209.053789] ath: phy0: MAC Hang signature not found at DCU complete
[346209.053802] ath: phy0: missed 7 consecutive beacons
[346209.054817] ath: phy0: MAC Hang signature not found at DCU complete
[346209.054848] ath: phy0: missed 8 consecutive beacons
[346209.056082] ath: phy0: MAC Hang signature not found at DCU complete
[346209.056108] ath: phy0: beacon is officially stuck
[346209.056152] ath: phy0: reset work is pending, skip beaconing now
[346209.069038] ath: phy0: Reset TX queue: 0
[346209.069051] ath: phy0: Reset TX queue: 1
[346209.069061] ath: phy0: Reset TX queue: 2
[346209.069070] ath: phy0: Reset TX queue: 3
[346209.069080] ath: phy0: Reset TXQ, inactive queue: 4
[346209.069087] ath: phy0: Reset TXQ, inactive queue: 5
[346209.069095] ath: phy0: Reset TXQ, inactive queue: 6
[346209.069102] ath: phy0: Reset TXQ, inactive queue: 7
[346209.069110] ath: phy0: Reset TX queue: 8
[346209.069125] ath: phy0: Reset TX queue: 9
[346209.069158] ath: phy0: ah->misc_mode 0x10000004
[...]

[ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Sujith Manoharan]

Nicolas Cavallari wrote:
> [resending, as no archive saw my previous message]
> 
> With an AR9382 (well, i think, its PCI-id is 168c:0030 rev 1/168c:3116),
> each time I join an IBSS network, the driver repeatedly
> resets the queue for a while, because of too many missed beacons.  After
> some time, this stops and the card behave normally.  But many packets
> are lost in the process.
> 
> The problem seems to aggravate when the number of IBSS nodes is higher :
> When joining a IBSS network with only one node, Only a few (e.g. 4)
> beacons are lost, and no reset takes places. When joining an IBSS
> network with two nodes, the queues can be reset up to 224 times in 20
> seconds. When joining large IBSS networks, it sometimes never stop
> resetting.  Occasionally, when resetting, the driver fails to reset TX DMA
> 
> If i hack the driver to not reset when the beacon is stuck, the beacon
> tx resumes quickly by itself after 80-200 misses and the network seems
> to work normally (if not better). On large&clogged ad-hoc networks, the
> card sometimes miss between 1 and 80 beacons, but it might be due to
> background scanning i think.
> 
> What could be the problem here ? is ad-hoc beaconing kind of broken ?
> I do not have the problem with AR9285.

I think the problem is that we are programming the beacon timers based on
the beacon interval right after joining, but we base it on the HW TSF which
has just been reset. We should be updating the timers based on the TSF after a
HW sync has been done with a received beacon. This is being done for station
mode, but IBSS mode is missing this.

Here is a very rough patch, it abuses STA-mode flags and doesn't differentiate
between creator/joiner mode, but can you check if it makes any difference ?

diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
index 76f07d8..5a1a89d 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -582,16 +582,19 @@ static void ath9k_beacon_config_adhoc(struct ath_softc *sc,
 	struct ath_hw *ah = sc->sc_ah;
 	struct ath_common *common = ath9k_hw_common(ah);
 	u32 intval, nexttbtt;
+	unsigned long flags;
 
 	ath9k_reset_beacon_status(sc);
 
 	intval = TU_TO_USEC(conf->beacon_interval);
 	nexttbtt = intval;
 
-	if (conf->enable_beacon)
+	spin_lock_irqsave(&sc->sc_pm_lock, flags);
+	if (conf->enable_beacon && !(sc->ps_flags & PS_BEACON_SYNC))
 		ah->imask |= ATH9K_INT_SWBA;
 	else
 		ah->imask &= ~ATH9K_INT_SWBA;
+	spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
 
 	ath_dbg(common, BEACON, "IBSS nexttbtt: %u intval: %u conf_intval: %u\n",
 		nexttbtt, intval, conf->beacon_interval);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 3923ad9..ae1c0bb 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1486,6 +1486,7 @@ static void ath9k_bss_info_changed(struct ieee80211_hw *hw,
 	struct ath_common *common = ath9k_hw_common(ah);
 	struct ath_vif *avp = (void *)vif->drv_priv;
 	int slottime;
+	unsigned long flags;
 
 	ath9k_ps_wakeup(sc);
 	mutex_lock(&sc->mutex);
@@ -1517,6 +1518,12 @@ static void ath9k_bss_info_changed(struct ieee80211_hw *hw,
 		memcpy(common->curbssid, bss_conf->bssid, ETH_ALEN);
 		common->curaid = bss_conf->aid;
 		ath9k_hw_write_associd(sc->sc_ah);
+
+		if (bss_conf->ibss_joined) {
+			spin_lock_irqsave(&sc->sc_pm_lock, flags);
+			sc->ps_flags |= PS_BEACON_SYNC;
+			spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
+		}
 	}
 
 	if ((changed & BSS_CHANGED_BEACON_ENABLED) ||

[ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Sujith Manoharan]

Nicolas Cavallari wrote:
> [resending, as no archive saw my previous message]
> 
> With an AR9382 (well, i think, its PCI-id is 168c:0030 rev 1/168c:3116),
> each time I join an IBSS network, the driver repeatedly
> resets the queue for a while, because of too many missed beacons.  After
> some time, this stops and the card behave normally.  But many packets
> are lost in the process.
> 
> The problem seems to aggravate when the number of IBSS nodes is higher :
> When joining a IBSS network with only one node, Only a few (e.g. 4)
> beacons are lost, and no reset takes places. When joining an IBSS
> network with two nodes, the queues can be reset up to 224 times in 20
> seconds. When joining large IBSS networks, it sometimes never stop
> resetting.  Occasionally, when resetting, the driver fails to reset TX DMA
> 
> If i hack the driver to not reset when the beacon is stuck, the beacon
> tx resumes quickly by itself after 80-200 misses and the network seems
> to work normally (if not better). On large&clogged ad-hoc networks, the
> card sometimes miss between 1 and 80 beacons, but it might be due to
> background scanning i think.
> 
> What could be the problem here ? is ad-hoc beaconing kind of broken ?
> I do not have the problem with AR9285.

I think the problem is that we are programming the beacon timers based on
the beacon interval right after joining, but we base it on the HW TSF which
has just been reset. We should be updating the timers based on the TSF after a
HW sync has been done with a received beacon. This is being done for station
mode, but IBSS mode is missing this.

Here is a very rough patch, it abuses STA-mode flags and doesn't differentiate
between creator/joiner mode, but can you check if it makes any difference ?

diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
index 76f07d8..5a1a89d 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -582,16 +582,19 @@ static void ath9k_beacon_config_adhoc(struct ath_softc *sc,
 	struct ath_hw *ah = sc->sc_ah;
 	struct ath_common *common = ath9k_hw_common(ah);
 	u32 intval, nexttbtt;
+	unsigned long flags;
 
 	ath9k_reset_beacon_status(sc);
 
 	intval = TU_TO_USEC(conf->beacon_interval);
 	nexttbtt = intval;
 
-	if (conf->enable_beacon)
+	spin_lock_irqsave(&sc->sc_pm_lock, flags);
+	if (conf->enable_beacon && !(sc->ps_flags & PS_BEACON_SYNC))
 		ah->imask |= ATH9K_INT_SWBA;
 	else
 		ah->imask &= ~ATH9K_INT_SWBA;
+	spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
 
 	ath_dbg(common, BEACON, "IBSS nexttbtt: %u intval: %u conf_intval: %u\n",
 		nexttbtt, intval, conf->beacon_interval);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 3923ad9..ae1c0bb 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1486,6 +1486,7 @@ static void ath9k_bss_info_changed(struct ieee80211_hw *hw,
 	struct ath_common *common = ath9k_hw_common(ah);
 	struct ath_vif *avp = (void *)vif->drv_priv;
 	int slottime;
+	unsigned long flags;
 
 	ath9k_ps_wakeup(sc);
 	mutex_lock(&sc->mutex);
@@ -1517,6 +1518,12 @@ static void ath9k_bss_info_changed(struct ieee80211_hw *hw,
 		memcpy(common->curbssid, bss_conf->bssid, ETH_ALEN);
 		common->curaid = bss_conf->aid;
 		ath9k_hw_write_associd(sc->sc_ah);
+
+		if (bss_conf->ibss_joined) {
+			spin_lock_irqsave(&sc->sc_pm_lock, flags);
+			sc->ps_flags |= PS_BEACON_SYNC;
+			spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
+		}
 	}
 
 	if ((changed & BSS_CHANGED_BEACON_ENABLED) ||

[ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Nicolas Cavallari]

On 18/09/2012 15:46, Sujith Manoharan wrote:
> Nicolas Cavallari wrote:
>> With an AR9382 (well, i think, its PCI-id is 168c:0030 rev 1/168c:3116),
>> each time I join an IBSS network, the driver repeatedly
>> resets the queue for a while, because of too many missed beacons.  After
>> some time, this stops and the card behave normally.  But many packets
>> are lost in the process.
>>
>> The problem seems to aggravate when the number of IBSS nodes is higher :
>> When joining a IBSS network with only one node, Only a few (e.g. 4)
>> beacons are lost, and no reset takes places. When joining an IBSS
>> network with two nodes, the queues can be reset up to 224 times in 20
>> seconds. When joining large IBSS networks, it sometimes never stop
>> resetting.  Occasionally, when resetting, the driver fails to reset TX DMA
>>
>> If i hack the driver to not reset when the beacon is stuck, the beacon
>> tx resumes quickly by itself after 80-200 misses and the network seems
>> to work normally (if not better). On large&clogged ad-hoc networks, the
>> card sometimes miss between 1 and 80 beacons, but it might be due to
>> background scanning i think.
>>
>> What could be the problem here ? is ad-hoc beaconing kind of broken ?
>> I do not have the problem with AR9285.
> 
> I think the problem is that we are programming the beacon timers based on
> the beacon interval right after joining, but we base it on the HW TSF which
> has just been reset. We should be updating the timers based on the TSF after a
> HW sync has been done with a received beacon. This is being done for station
> mode, but IBSS mode is missing this.
> 
> Here is a very rough patch, it abuses STA-mode flags and doesn't differentiate
> between creator/joiner mode, but can you check if it makes any difference ?

With this patch, i see no beacon miss in the logs when joining a large
ad-hoc network. So yes, it does make a difference! haven't tested what
happens when creating an IBSS with or without this patch yet.

Thanks.

Re: [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Nicolas Cavallari]

On 18/09/2012 15:46, Sujith Manoharan wrote:
> Nicolas Cavallari wrote:
>> With an AR9382 (well, i think, its PCI-id is 168c:0030 rev 1/168c:3116),
>> each time I join an IBSS network, the driver repeatedly
>> resets the queue for a while, because of too many missed beacons.  After
>> some time, this stops and the card behave normally.  But many packets
>> are lost in the process.
>>
>> The problem seems to aggravate when the number of IBSS nodes is higher :
>> When joining a IBSS network with only one node, Only a few (e.g. 4)
>> beacons are lost, and no reset takes places. When joining an IBSS
>> network with two nodes, the queues can be reset up to 224 times in 20
>> seconds. When joining large IBSS networks, it sometimes never stop
>> resetting.  Occasionally, when resetting, the driver fails to reset TX DMA
>>
>> If i hack the driver to not reset when the beacon is stuck, the beacon
>> tx resumes quickly by itself after 80-200 misses and the network seems
>> to work normally (if not better). On large&clogged ad-hoc networks, the
>> card sometimes miss between 1 and 80 beacons, but it might be due to
>> background scanning i think.
>>
>> What could be the problem here ? is ad-hoc beaconing kind of broken ?
>> I do not have the problem with AR9285.
> 
> I think the problem is that we are programming the beacon timers based on
> the beacon interval right after joining, but we base it on the HW TSF which
> has just been reset. We should be updating the timers based on the TSF after a
> HW sync has been done with a received beacon. This is being done for station
> mode, but IBSS mode is missing this.
> 
> Here is a very rough patch, it abuses STA-mode flags and doesn't differentiate
> between creator/joiner mode, but can you check if it makes any difference ?

With this patch, i see no beacon miss in the logs when joining a large
ad-hoc network. So yes, it does make a difference! haven't tested what
happens when creating an IBSS with or without this patch yet.

Thanks.

[ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Sujith Manoharan]

Nicolas Cavallari wrote:
> With this patch, i see no beacon miss in the logs when joining a large
> ad-hoc network. So yes, it does make a difference! haven't tested what
> happens when creating an IBSS with or without this patch yet.

The beacon-sync shouldn't be done when we are creating an IBSS network.
Currently, mac80211 doesn't give the necessary information to the driver,
I'll propose a patch.

Sujith

Re: [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS.

[Sujith Manoharan]

Nicolas Cavallari wrote:
> With this patch, i see no beacon miss in the logs when joining a large
> ad-hoc network. So yes, it does make a difference! haven't tested what
> happens when creating an IBSS with or without this patch yet.

The beacon-sync shouldn't be done when we are creating an IBSS network.
Currently, mac80211 doesn't give the necessary information to the driver,
I'll propose a patch.

Sujith