]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
[ath] Hopefully recover better-er upon RX restart on AR9380.
authorAdrian Chadd <adrian@FreeBSD.org>
Thu, 21 May 2020 04:35:12 +0000 (04:35 +0000)
committerAdrian Chadd <adrian@FreeBSD.org>
Thu, 21 May 2020 04:35:12 +0000 (04:35 +0000)
commita100c050eb3156b6d3d466a1d2912865c5d105ba
treee862370691060c577450efc6e685bb9e5af58376
parent9a2de0c3d607a1254b8eb8e996f8a51082ec4e0a
[ath] Hopefully recover better-er upon RX restart on AR9380.

This is all very long-standing bug stuff that is touchy and still poorly
documented. Ok, here goes.

The basic bug:

* deleting a VAP causes the RX path (and TX path too) to be restarted
  without a full chip reset, which causes RX hangs on the AR9380 and later.
  (ie, the ones with the newer DMA engine.)

The basic fix:

* do an RX flush when stopping RX in ath_vap_delete() to match what happens
  when RX is stopped elsewhere.  This ensures any pending frames are completed
  and we restart at the right spot; it also ensures we don't push new RX buffers
  into the hardware if we're stopping receive.

The other issues I found:

* Don't bother checking the RX packet ring in the deferred read taskqueue;
  that's specifically supposed to be for completing frames rather than
  just yanking them off the receive ring.

* Cancel/drain any pending deferred read taskqueue.  This isn't done inside
  any locks so we should be super careful here.  This stops the hardware
  being reprogrammed at the same time in another thread/CPU whilst we're
  stopping RX.

* .. (yes, this should be better serialised, but that's for another day. maybe.)

* Add more debugging to trace what's going on here.

And the fun bit:

* Reinitialise the RX FIFO ONLY if we've been reset or stopped, rather than just
  reset.  I noticed that after all the above was done I was STILL seeing RXEOL.
  RXEOL isn't enabled on the AR9380 so I'd only see it if I was sending TX frames
  (ie a ping where it'd be transmitted but never received) so I was not being
  spammed by RXEOL.  So, as long as stuff is stopped, restart it.

This seems to be doing the right thing in both AP and STA modes.

What I should do next, if I ever get time:

* as I said above, serialise the receive stop/start to include taskqueues
* monitor RXEOL on the AR9380 and I keep seeing it spammed / lockups, just
  go do a full chip reset to get things back on track. It sucks, but it
  is better than nothing.

Tested:

* AR9380 AP/STA mode, adding/deleting a hostap VAP to trigger the TX/RX
  queue stop/start; whilst also running an iperf through it.  Lots of times.
  Lots.  Of.. Times.
sys/dev/ath/if_ath.c
sys/dev/ath/if_ath_rx_edma.c