From owner-svn-src-user@FreeBSD.ORG Fri Sep 16 04:42:05 2011 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94ED7106564A; Fri, 16 Sep 2011 04:42:05 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1168FC13; Fri, 16 Sep 2011 04:42:05 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id p8G4g50A004326; Fri, 16 Sep 2011 04:42:05 GMT (envelope-from adrian@svn.freebsd.org) Received: (from adrian@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id p8G4g5um004324; Fri, 16 Sep 2011 04:42:05 GMT (envelope-from adrian@svn.freebsd.org) Message-Id: <201109160442.p8G4g5um004324@svn.freebsd.org> From: Adrian Chadd Date: Fri, 16 Sep 2011 04:42:05 +0000 (UTC) To: src-committers@freebsd.org, svn-src-user@freebsd.org X-SVN-Group: user MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r225604 - user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416 X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 04:42:05 -0000 Author: adrian Date: Fri Sep 16 04:42:05 2011 New Revision: 225604 URL: http://svn.freebsd.org/changeset/base/225604 Log: Fix the default cabq configuration time to not be "too long". The -HEAD code would configure a cabq time of 100 TU minus the various beacon setup intervals. When doing staggered beacons, this would result in CABQ readytime being 4 * the beacon interval timer, which is 1/ATH_BCBUF (4) the default beacon interval (100 TU.) This didn't seem to annoy the AR9160 MAC but it definitely annoys the AR9220/AR9280 MAC. I then fixed it to use the beacon time configured through a (hopefully earlier!) call to the HAL beacon timer setup code. This reduced the stuck beacon and cabq stall occurances quite a bit, but it didn't eliminate them. Having a CABQ time that's almost the same as the beacon interval seems to annoy AR9280 (Merlin) and later MACs. So, I decided to twiddle things a bit and make it 70% of the beacon interval. Both linux ath9k and the Atheros reference code default to 80% of the beacon interval. This hasn't stopped miss beacons (which could be because the air is "busy", which it tends to be in my apartment..) or eliminated the cabq TX issues (which should still be addressed, as there's no way a few broadcast frames here and there shouldn't make it out when the air is completely free for TX) but it does seem to have (initially) eliminated the stuck beacon conditions on my AR9220 NIC. I'll have to run this for a few hours to see what the story is and I likely should investigate why cabq traffic can't be TXed, but I'm happy to report these last few commits have had a positive effect. TODO: fix this in AR5212 too, just to be correct. TODO: actually set a non-0 readytime value when setting up the CABQ in the ath driver. Modified: user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c Modified: user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c ============================================================================== --- user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c Fri Sep 16 04:26:40 2011 (r225603) +++ user/adrian/if_ath_tx/sys/dev/ath/ath_hal/ar5416/ar5416_xmit.c Fri Sep 16 04:42:05 2011 (r225604) @@ -941,6 +941,7 @@ setTxQInterrupts(struct ath_hal *ah, HAL * Assumes: * phwChannel has been set to point to the current channel */ +#define TU_TO_USEC(_tu) ((_tu) << 10) HAL_BOOL ar5416ResetTxQueue(struct ath_hal *ah, u_int q) { @@ -1018,7 +1019,8 @@ ar5416ResetTxQueue(struct ath_hal *ah, u if (qi->tqi_cbrOverflowLimit) qmisc |= AR_Q_MISC_CBR_EXP_CNTR_LIMIT; } - if (qi->tqi_readyTime) { + + if (qi->tqi_readyTime && (qi->tqi_type != HAL_TX_QUEUE_CAB)) { OS_REG_WRITE(ah, AR_QRDYTIMECFG(q), SM(qi->tqi_readyTime, AR_Q_RDYTIMECFG_INT) | AR_Q_RDYTIMECFG_ENA); @@ -1089,18 +1091,38 @@ ar5416ResetTxQueue(struct ath_hal *ah, u qmisc |= AR_Q_MISC_FSP_DBA_GATED | AR_Q_MISC_CBR_INCR_DIS1 | AR_Q_MISC_CBR_INCR_DIS0; - - if (!qi->tqi_readyTime) { + HALDEBUG(ah, HAL_DEBUG_TXQUEUE, "%s: CAB: tqi_readyTime = %d\n", + __func__, qi->tqi_readyTime); + if (qi->tqi_readyTime) { + HALDEBUG(ah, HAL_DEBUG_TXQUEUE, + "%s: using tqi_readyTime\n", __func__); + OS_REG_WRITE(ah, AR_QRDYTIMECFG(q), + SM(qi->tqi_readyTime, AR_Q_RDYTIMECFG_INT) | + AR_Q_RDYTIMECFG_ENA); + } else { /* * NB: don't set default ready time if driver * has explicitly specified something. This is * here solely for backwards compatibility. */ - value = (ahp->ah_beaconInterval - - (ah->ah_config.ah_sw_beacon_response_time - - 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); + /* + * 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 = TU_TO_USEC((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); + HALDEBUG(ah, HAL_DEBUG_TXQUEUE, + "%s: defaulting to rdytime = %d\n", + __func__, value); + OS_REG_WRITE(ah, AR_QRDYTIMECFG(q), + SM(value, AR_Q_RDYTIMECFG_INT) | + AR_Q_RDYTIMECFG_ENA); } dmisc |= SM(AR_D_MISC_ARB_LOCKOUT_CNTRL_GLOBAL, AR_D_MISC_ARB_LOCKOUT_CNTRL); @@ -1168,3 +1190,4 @@ ar5416ResetTxQueue(struct ath_hal *ah, u return AH_TRUE; } +#undef TU_TO_USEC