svn commit: r225042 - user/adrian/if_ath_tx/sys/dev/ath
Adrian Chadd
adrian at FreeBSD.org
Sat Aug 20 16:34:32 UTC 2011
Author: adrian
Date: Sat Aug 20 16:34:31 2011
New Revision: 225042
URL: http://svn.freebsd.org/changeset/base/225042
Log:
More updates, now that:
* I know what the current batch of BAW tracking failures are;
* some discussions with Felix (nbd) and I about what this code
and Linux ath9k are doing have given rise to some issues with
channel changes (eg channel, 20/2040 change, mode, etc)
and what this may do to software/hardware queued frames, etc.
Modified:
user/adrian/if_ath_tx/sys/dev/ath/README
Modified: user/adrian/if_ath_tx/sys/dev/ath/README
==============================================================================
--- user/adrian/if_ath_tx/sys/dev/ath/README Sat Aug 20 16:21:40 2011 (r225041)
+++ user/adrian/if_ath_tx/sys/dev/ath/README Sat Aug 20 16:34:31 2011 (r225042)
@@ -37,8 +37,37 @@ Things to debug!
That should be .. well, fixed.
+ Yes, it's this. The problem is the cleanup, flush, drain handling.
+ What I need to do is:
+
+ * for interface -teardown-, the frames can be completed.
+ * for interface -flush-, complete the retries as failed?, and reschedule
+ the frames on the queue.
+ - the problem - what if that flush is a mode change?
+ - or what else? 20/40 change? rate change? etc.
+ * for interface -cleanup-, ?
+ * drain?
+
+
Things that need doing!
+* Handle channel/mode changes which shouldn't flush packets in the
+ software queue (and the packets in the hardware queue that can
+ be recovered after TX DMA is stopped..)
+ + eg a mode change which changes the channel (2/5ghz), or ht<->non-ht,
+ or 40<->20mhz modes - these may end up with packets in the software
+ queue which can't be supported by the new operating mode.
+ + How to fix? :-)
+
+* Perhaps delay the rate lookup until the packet is being hardware queued,
+ rather than doing the rate decision at ath_tx_raw_xmit() / ath_tx_start();
+* .. and since raw queued frames may have invalid rate information, enforce
+ valid rate/flags when the packet is being hardware queued.
+* .. this also will allow for rate lookups to be done on retried frames,
+ which may help with reliability.
+* Find where in the driver the rate table is updated, and do what? Trigger
+ updating the software-queued frames? Or?
+
* Add a swretrysubframe and swretrysubframemax counter, use it
* Scheduling is wrong - the software TXQ needs more time to assemble
More information about the svn-src-user
mailing list