Bug 169084 - [ath] [suspend/resume] suspend/resume doesn't cause a rescan; the association stays even if the AP is not available
Summary: [ath] [suspend/resume] suspend/resume doesn't cause a rescan; the association...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 9.0-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-14 23:40 UTC by Adrian Chadd
Modified: 2014-06-07 05:29 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer freebsd_triage 2012-06-14 23:40:01 UTC
The ath driver doesn't notice the lack of beacons from the associated station when you suspend and resume. It blindly stays associated to the AP.

The dmesg output (from sysctl dev.ath.0.debug=0x8080, sysctl dev.ath.0.hal.debug=0x10000):


[100317] ath0: ath_suspend: if_flags 8803
[100317] ath0: ath_stop_locked: invalid 0 if_flags 0x8803
ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
[100317] ath0: ath_resume: if_flags 8803
[100317] ath0: ath_init: if_flags 0x8803
[100317] ath0: ath_stop_locked: invalid 0 if_flags 0x8803
[100317] ath0: ath_beacon_config: nexttbtt 47465200 intval 100 (100)
[100317] ath0: ath_beacon_config: tsf 19563 tsf:tu 21 intval 100 nexttbtt 47465300 dtim 100 nextdtim 47465300 bmiss 7 sleep 100 cfp:period 100 maxdur 0 next 47465300 timoffset 0
ar5416SetStaBeaconTimers: next DTIM 47465300
ar5416SetStaBeaconTimers: next beacon 47465300
ar5416SetStaBeaconTimers: beacon period 100
ar5416SetStaBeaconTimers: DTIM period 100
ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
ar5416ResetCalValid: Calibration state incorrect, 2
ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
ar5416GetMibCycleCounts: cycle counter wrap. ExtBusy = 0
[100509] ath0: ath_detach: if_flags 8803
[100509] ath0: ath_stop_locked: invalid 0 if_flags 0x8803


The hardware is being programmed with the TSF of the next beacon however the TSF is reset during a suspend/resume; it counts up from 0.

When the TSF goes past the current programmed TBTT/DTIM, it doesn't cause a bmiss either.

The relevant bit in AR_IMR is set. I'm not sure why it isn't firing.

Fix: 

It's quite possible that the behaviour of the hardware beacon miss timer stuff has changed between pre-11n and 11n.  It's also possible that the ar5416 HAL calls to set the station beacon timers isn't exactly correct.

I know that hardware bmiss interrupts occur when you're associated correctly and the AP goes away. But not when the interface suspend/resumes or corner cases like doing a scan and coming back to find the AP isn't there.
How-To-Repeat: * associate
* suspend
* move elsewhere
* resume
* ifconfig wlan0 - will show you still associated
Comment 1 Adrian Chadd freebsd_committer freebsd_triage 2012-06-14 23:44:35 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Reassign to maintainer.
Comment 2 dfilter service freebsd_committer freebsd_triage 2012-06-15 02:16:13 UTC
Author: adrian
Date: Fri Jun 15 01:15:59 2012
New Revision: 237108
URL: http://svn.freebsd.org/changeset/base/237108

Log:
  Convert ath(4) to just use ieee80211_suspend_all() and ieee80211_resume_all().
  
  The existing code tries to use the beacon miss timer to signal that the AP
  has gone away.  Unfortunately this doesn't seem to be behaving itself.
  I'll try to investigate why this is for the sake of completeness.
  
  The result is the STA will stay "associated" to the AP it was associated
  with when it suspended.  It never receives a bmiss notification so it
  never tries reassociating.
  
  PR:		kern/169084

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

Modified: head/sys/dev/ath/if_ath.c
==============================================================================
--- head/sys/dev/ath/if_ath.c	Thu Jun 14 22:19:23 2012	(r237107)
+++ head/sys/dev/ath/if_ath.c	Fri Jun 15 01:15:59 2012	(r237108)
@@ -1310,8 +1310,13 @@ ath_suspend(struct ath_softc *sc)
 
 	sc->sc_resume_up = (ifp->if_flags & IFF_UP) != 0;
 	if (ic->ic_opmode == IEEE80211_M_STA)
+	/*
+	 * This has been disabled - see PR kern/169084.
+	 */
+#if 0
 		ath_stop(ifp);
 	else
+#endif
 		ieee80211_suspend_all(ic);
 	/*
 	 * NB: don't worry about putting the chip in low power
@@ -1379,6 +1384,15 @@ ath_resume(struct ath_softc *sc)
 	ath_hal_setledstate(ah, HAL_LED_INIT);
 
 	if (sc->sc_resume_up) {
+		/*
+		 * This particular feature doesn't work at the present,
+		 * at least on the 802.11n chips.  It's quite possible
+		 * that the STA Beacon timers aren't being configured
+		 * properly.
+		 *
+		 * See PR kern/169084.
+		 */
+#if 0
 		if (ic->ic_opmode == IEEE80211_M_STA) {
 			ath_init(sc);
 			ath_hal_setledstate(ah, HAL_LED_RUN);
@@ -1392,7 +1406,9 @@ ath_resume(struct ath_softc *sc)
 			 */
 			ath_beacon_config(sc, NULL);
 			sc->sc_syncbeacon = 1;
+			ieee80211_resume_all(ic);
 		} else
+#endif
 			ieee80211_resume_all(ic);
 	}
 
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 3 dfilter service freebsd_committer freebsd_triage 2012-06-17 04:08:49 UTC
Author: adrian
Date: Sun Jun 17 03:08:33 2012
New Revision: 237179
URL: http://svn.freebsd.org/changeset/base/237179

Log:
  After some discussion with bschmidt@, it's likely better to just go
  through ieee80211_suspend_all() and ieee80211_resume_all().
  All the other wireless drivers are doing that particular dance.
  
  PR:		kern/169084

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

Modified: head/sys/dev/ath/if_ath.c
==============================================================================
--- head/sys/dev/ath/if_ath.c	Sun Jun 17 02:46:27 2012	(r237178)
+++ head/sys/dev/ath/if_ath.c	Sun Jun 17 03:08:33 2012	(r237179)
@@ -1309,15 +1309,8 @@ ath_suspend(struct ath_softc *sc)
 		__func__, ifp->if_flags);
 
 	sc->sc_resume_up = (ifp->if_flags & IFF_UP) != 0;
-	if (ic->ic_opmode == IEEE80211_M_STA)
-	/*
-	 * This has been disabled - see PR kern/169084.
-	 */
-#if 0
-		ath_stop(ifp);
-	else
-#endif
-		ieee80211_suspend_all(ic);
+
+	ieee80211_suspend_all(ic);
 	/*
 	 * NB: don't worry about putting the chip in low power
 	 * mode; pci will power off our socket on suspend and
@@ -1383,34 +1376,8 @@ ath_resume(struct ath_softc *sc)
 	ath_led_config(sc);
 	ath_hal_setledstate(ah, HAL_LED_INIT);
 
-	if (sc->sc_resume_up) {
-		/*
-		 * This particular feature doesn't work at the present,
-		 * at least on the 802.11n chips.  It's quite possible
-		 * that the STA Beacon timers aren't being configured
-		 * properly.
-		 *
-		 * See PR kern/169084.
-		 */
-#if 0
-		if (ic->ic_opmode == IEEE80211_M_STA) {
-			ath_init(sc);
-			ath_hal_setledstate(ah, HAL_LED_RUN);
-			/*
-			 * Program the beacon registers using the last rx'd
-			 * beacon frame and enable sync on the next beacon
-			 * we see.  This should handle the case where we
-			 * wakeup and find the same AP and also the case where
-			 * we wakeup and need to roam.  For the latter we
-			 * should get bmiss events that trigger a roam.
-			 */
-			ath_beacon_config(sc, NULL);
-			sc->sc_syncbeacon = 1;
-			ieee80211_resume_all(ic);
-		} else
-#endif
-			ieee80211_resume_all(ic);
-	}
+	if (sc->sc_resume_up)
+		ieee80211_resume_all(ic);
 
 	/* XXX beacons ? */
 }
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2014-04-22 06:27:54 UTC
State Changed
From-To: open->closed

should be fixed by commit from 2012.