* [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. @ 2012-09-18 8:12 Nicolas Cavallari 2012-09-18 13:13 ` Nicolas Cavallari 0 siblings, 1 reply; 8+ messages in thread From: Nicolas Cavallari @ 2012-09-18 8:12 UTC (permalink / raw) To: ath9k-devel 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 [...] ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. 2012-09-18 8:12 [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS Nicolas Cavallari @ 2012-09-18 13:13 ` Nicolas Cavallari 2012-09-18 13:46 ` Sujith Manoharan 0 siblings, 1 reply; 8+ messages in thread From: Nicolas Cavallari @ 2012-09-18 13:13 UTC (permalink / raw) To: ath9k-devel [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 [...] ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. 2012-09-18 13:13 ` Nicolas Cavallari @ 2012-09-18 13:46 ` Sujith Manoharan 0 siblings, 0 replies; 8+ messages in thread From: Sujith Manoharan @ 2012-09-18 13:46 UTC (permalink / raw) To: ath9k-devel 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) || ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. @ 2012-09-18 13:46 ` Sujith Manoharan 0 siblings, 0 replies; 8+ messages in thread From: Sujith Manoharan @ 2012-09-18 13:46 UTC (permalink / raw) To: Nicolas Cavallari; +Cc: ath9k-devel, linux-wireless 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) || ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. 2012-09-18 13:46 ` Sujith Manoharan @ 2012-09-18 14:47 ` Nicolas Cavallari -1 siblings, 0 replies; 8+ messages in thread From: Nicolas Cavallari @ 2012-09-18 14:47 UTC (permalink / raw) To: ath9k-devel 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. @ 2012-09-18 14:47 ` Nicolas Cavallari 0 siblings, 0 replies; 8+ messages in thread From: Nicolas Cavallari @ 2012-09-18 14:47 UTC (permalink / raw) To: Sujith Manoharan; +Cc: ath9k-devel, linux-wireless 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. 2012-09-18 14:47 ` Nicolas Cavallari @ 2012-09-18 22:03 ` Sujith Manoharan -1 siblings, 0 replies; 8+ messages in thread From: Sujith Manoharan @ 2012-09-18 22:03 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS. @ 2012-09-18 22:03 ` Sujith Manoharan 0 siblings, 0 replies; 8+ messages in thread From: Sujith Manoharan @ 2012-09-18 22:03 UTC (permalink / raw) To: Nicolas Cavallari; +Cc: Sujith Manoharan, ath9k-devel, linux-wireless 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-09-18 22:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-18 8:12 [ath9k-devel] ath9k: spurious queue reset (beacon stuck) when joining an IBSS Nicolas Cavallari 2012-09-18 13:13 ` Nicolas Cavallari 2012-09-18 13:46 ` Sujith Manoharan 2012-09-18 13:46 ` Sujith Manoharan 2012-09-18 14:47 ` Nicolas Cavallari 2012-09-18 14:47 ` Nicolas Cavallari 2012-09-18 22:03 ` Sujith Manoharan 2012-09-18 22:03 ` Sujith Manoharan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.