Date: Sat, 10 Nov 2012 22:37:07 +0000 (UTC) From: Adrian Chadd <adrian@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r242880 - head/sys/dev/ath Message-ID: <201211102237.qAAMb78T029481@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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__,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211102237.qAAMb78T029481>