kern/183644: ath(4) "stops" working

[Nathan Lay]

>Number:         183644
>Category:       kern
>Synopsis:       ath(4) "stops" working
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Nov 04 01:10:01 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Nathan Lay
>Release:        9.2-STABLE
>Organization:
>Environment:
FreeBSD RADIO.LOCAL 9.2-STABLE FreeBSD 9.2-STABLE #0 r257209M: Sun Oct 27 15:39:36 EDT 2013     nslay at RADIO.LOCAL:/usr/obj/usr/src/sys/RADIO  amd64

>Description:
When ath(4) is operating in hostap mode, it would randomly "stop" working during normal Internet usage (wifi devices streaming, browsing the web, etc...). Some symptoms of the problem included several and frequent "stuck beacon" messages in dmesg and sudden unresponsive behavior that required the ath(4) module to be unloaded and then reloaded to function again (restarting hostapd, bringing interface up/down, destroying/creating wlan# again was not sufficient).
>How-To-Repeat:
The exact causes are not known. It's not reproducible.
>Fix:
Adrian Chadd recommended a code snippet from HEAD which resolved the problem with stuck beacons and it apparently solved this problem too. The attached patch has been tested and successfully used since 2/17/2013.

Patch attached with submission follows:

Index: sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c
===================================================================
--- sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c	(revision 257209)
+++ sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c	(working copy)
@@ -27,6 +27,8 @@
 #include "ar5416/ar5416phy.h"
 #include "ar5416/ar5416desc.h"
 
+#define TU_TO_USEC(_tu)         ((_tu) << 10)
+
 /*
  * Stop transmit on the specified queue
  */
@@ -1039,7 +1041,40 @@
 					ah->ah_config.ah_dma_beacon_response_time)
 				- ah->ah_config.ah_additional_swba_backoff) * 1024;
 			OS_REG_WRITE(ah, AR_QRDYTIMECFG(q), value | AR_Q_RDYTIMECFG_ENA);
+		} else {
+			int value;
+			/*
+			 * NB: don't set default ready time if driver
+			 * has explicitly specified something.  This is
+			 * here solely for backwards compatibility.
+			 */
+			/*
+			 * XXX for now, hard-code a CAB interval of 70%
+			 * XXX of the total beacon interval.
+			 *
+			 * XXX This keeps Merlin and later based MACs
+			 * XXX quite a bit happier (stops stuck beacons,
+			 * XXX which I gather is because of such a long
+			 * XXX cabq time.)
+			 */
+			value = (ahp->ah_beaconInterval * 70 / 100)
+				- (ah->ah_config.ah_sw_beacon_response_time
+				+ ah->ah_config.ah_dma_beacon_response_time)
+				- ah->ah_config.ah_additional_swba_backoff;
+			/*
+			 * XXX Ensure it isn't too low - nothing lower
+			 * XXX than 10 TU
+			 */
+			if (value < 10)
+				value = 10;
+			HALDEBUG(ah, HAL_DEBUG_TXQUEUE,
+			    "%s: defaulting to rdytime = %d uS\n",
+			    __func__, value);
+			OS_REG_WRITE(ah, AR_QRDYTIMECFG(q),
+			    SM(TU_TO_USEC(value), AR_Q_RDYTIMECFG_INT) |
+			    AR_Q_RDYTIMECFG_ENA);
 		}
+
 		dmisc |= SM(AR_D_MISC_ARB_LOCKOUT_CNTRL_GLOBAL,
 			    AR_D_MISC_ARB_LOCKOUT_CNTRL);
 		break;


>Release-Note:
>Audit-Trail:
>Unformatted: