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