From nobody@FreeBSD.org  Thu Jun 14 22:38:46 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D2333106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Jun 2012 22:38:46 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [69.147.83.34])
	by mx1.freebsd.org (Postfix) with ESMTP id A3FBE8FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Jun 2012 22:38:46 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q5EMck0X015415
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Jun 2012 22:38:46 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q5EMck40015414;
	Thu, 14 Jun 2012 22:38:46 GMT
	(envelope-from nobody)
Message-Id: <201206142238.q5EMck40015414@red.freebsd.org>
Date: Thu, 14 Jun 2012 22:38:46 GMT
From: Adrian Chadd <adrian@FreeBSD.org>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [ath] suspend/resume doesn't cause a rescan; the association stays even if the AP is not available
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         169084
>Category:       kern
>Synopsis:       [ath] [suspend/resume] suspend/resume doesn't cause a rescan; the association stays even if the AP is not available
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-wireless
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jun 14 22:40:01 UTC 2012
>Closed-Date:    Tue Apr 22 05:28:47 UTC 2014
>Last-Modified:  Tue Apr 22 05:28:47 UTC 2014
>Originator:     Adrian Chadd
>Release:        9.0-STABLE i386, with -HEAD net80211/ath
>Organization:
>Environment:
>Description:
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.
>How-To-Repeat:
* associate
* suspend
* move elsewhere
* resume
* ifconfig wlan0 - will show you still associated
>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.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless 
Responsible-Changed-By: adrian 
Responsible-Changed-When: Thu Jun 14 22:44:35 UTC 2012 
Responsible-Changed-Why:  
Reassign to maintainer. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=169084 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/169084: commit references a PR
Date: Fri, 15 Jun 2012 01:16:13 +0000 (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"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/169084: commit references a PR
Date: Sun, 17 Jun 2012 03:08:49 +0000 (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"
 
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Tue Apr 22 05:27:54 UTC 2014 
State-Changed-Why:  
should be fixed by commit from 2012. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=169084 
>Unformatted:
