From owner-svn-src-head@FreeBSD.ORG Sat Nov 10 22:37:07 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A13AF5ED; Sat, 10 Nov 2012 22:37:07 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 6A9898FC0A; Sat, 10 Nov 2012 22:37:07 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.5/8.14.5) with ESMTP id qAAMb7Qj029482; Sat, 10 Nov 2012 22:37:07 GMT (envelope-from adrian@svn.freebsd.org) Received: (from adrian@localhost) by svn.freebsd.org (8.14.5/8.14.5/Submit) id qAAMb78T029481; Sat, 10 Nov 2012 22:37:07 GMT (envelope-from adrian@svn.freebsd.org) Message-Id: <201211102237.qAAMb78T029481@svn.freebsd.org> From: Adrian Chadd Date: Sat, 10 Nov 2012 22:37:07 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r242880 - head/sys/dev/ath X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 22:37:07 -0000 Author: adrian Date: Sat Nov 10 22:37:06 2012 New Revision: 242880 URL: http://svnweb.freebsd.org/changeset/base/242880 Log: Correct some rather weird and broken behaviour observed when doing actual traffic with an AR9380/AR9382/AR9485. The sample rate control stats would show impossibly large numbers for "successful packets transmitted." The number was a tad under 2^^64-1. So after a bit of digging, I found that the sample rate control code was making 'tries' turn into a negative number.. and this was because ts_longretry was too small. The hardware returns "ts_longretry" at the current rate selection, not overall for that TX descriptor. So if you setup four TX rate scenarios and the second one works, ts_longretry is only set for the number of attempts at that second rate scenario. The FreeBSD HAL code does the correction in ath_hal_proctxdesc() - however, this isn't possible with EDMA. EDMA TX completion is done separate from the original TX descriptor. So the real solution is to split out "find ts_rate and ts_longretry" from "complete TX descriptor". Until that's done, put a hack in the EDMA TX path that uses the rate scenario information in the ath_buf. Tested: AR9380, AR9382, AR9485 STA mode Modified: head/sys/dev/ath/if_ath_tx_edma.c Modified: head/sys/dev/ath/if_ath_tx_edma.c ============================================================================== --- head/sys/dev/ath/if_ath_tx_edma.c Sat Nov 10 21:22:10 2012 (r242879) +++ head/sys/dev/ath/if_ath_tx_edma.c Sat Nov 10 22:37:06 2012 (r242880) @@ -594,13 +594,26 @@ ath_edma_tx_processq(struct ath_softc *s * in the TX descriptor. However the TX completion * FIFO doesn't have this information. So here we * do a separate HAL call to populate that information. + * + * The same problem exists with ts_longretry. + * The FreeBSD HAL corrects ts_longretry in the HAL layer; + * the AR9380 HAL currently doesn't. So until the HAL + * is imported and this can be added, we correct for it + * here. */ - /* XXX TODO */ /* XXX faked for now. Ew. */ if (ts.ts_finaltsi < 4) { ts.ts_rate = bf->bf_state.bfs_rc[ts.ts_finaltsi].ratecode; + switch (ts.ts_finaltsi) { + case 3: ts.ts_longretry += + bf->bf_state.bfs_rc[2].tries; + case 2: ts.ts_longretry += + bf->bf_state.bfs_rc[1].tries; + case 1: ts.ts_longretry += + bf->bf_state.bfs_rc[0].tries; + } } else { device_printf(sc->sc_dev, "%s: finaltsi=%d\n", __func__,