>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 [email protected]:/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:
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
