From owner-freebsd-bugs@FreeBSD.ORG Mon Nov 4 01:10:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0CDF3894 for ; Mon, 4 Nov 2013 01:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1E162DC7 for ; Mon, 4 Nov 2013 01:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA41A1j0004002 for ; Mon, 4 Nov 2013 01:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA41A15Y004001; Mon, 4 Nov 2013 01:10:01 GMT (envelope-from gnats) Resent-Date: Mon, 4 Nov 2013 01:10:01 GMT Resent-Message-Id: <201311040110.rA41A15Y004001@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Nathan Lay Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6389180A for ; Mon, 4 Nov 2013 01:04:40 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 379722DB2 for ; Mon, 4 Nov 2013 01:04:40 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id rA414d6b034818 for ; Mon, 4 Nov 2013 01:04:39 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id rA414dBl034785; Mon, 4 Nov 2013 01:04:39 GMT (envelope-from nobody) Message-Id: <201311040104.rA414dBl034785@oldred.freebsd.org> Date: Mon, 4 Nov 2013 01:04:39 GMT From: Nathan Lay To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/183644: ath(4) "stops" working X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 01:10:02 -0000 >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@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: