d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

* Reduce the PCU lock overhead a little by only re-acquiring it if we

Browse Source 
actually do have to reinitialise the RX side of things after an RX
  descriptor EOL error.

* Revert a change of mine from quite a while ago - don't shortcut the
  RX initialisation path.  There's a RX FIFO bug in the earlier chips
  (I'm not sure when it was fixed in this series, but it's fixed
  with the AR9380 and later) which causes the same RX descriptor to
  be written to over and over.  This causes the descriptor to be
  marked as "done", and this ends up causing the whole RX path to
  go very strange.  This should fixed the "kickpcu; handled X packets"
  message spam where "X" is consistently small.
This commit is contained in:
Adrian Chadd 2013-02-16 19:11:57 +00:00
parent 7839b23f00
commit 1844ff169f
1 changed files with 20 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
sys/dev/ath/if_ath_rx.c
View File

@ -954,16 +954,31 @@ rx_proc_next:
* need to be handled, kick the PCU if there's
* been an RXEOL condition.
*/
ATH_PCU_LOCK(sc);
if (resched && sc->sc_kickpcu) {
if (resched && kickpcu) {
ATH_PCU_LOCK(sc);
ATH_KTR(sc, ATH_KTR_ERROR, 0, "ath_rx_proc: kickpcu");
device_printf(sc->sc_dev, "%s: kickpcu; handled %d packets\n",
__func__, npkts);
/* XXX rxslink? */
#if 0
/*
* Go through the process of fully tearing down
* the RX buffers and reinitialising them.
*
* There's a hardware bug that causes the RX FIFO
* to get confused under certain conditions and
* constantly write over the same frame, leading
* the RX driver code here to get heavily confused.
*/
#if 1
ath_startrecv(sc);
#else
/*
* Disabled for now - it'd be nice to be able to do
* this in order to limit the amount of CPU time spent
* reinitialising the RX side (and thus minimise RX
* drops) however there's a hardware issue that
* causes things to get too far out of whack.
*/
/*
* XXX can we hold the PCU lock here?
* Are there any net80211 buffer calls involved?
@ -977,8 +992,8 @@ rx_proc_next:
ath_hal_intrset(ah, sc->sc_imask);
sc->sc_kickpcu = 0;
ATH_PCU_UNLOCK(sc);
}
ATH_PCU_UNLOCK(sc);
/* XXX check this inside of IF_LOCK? */
if (resched && (ifp->if_drv_flags & IFF_DRV_OACTIVE) == 0) {