Date: Sat, 20 Aug 2011 16:34:31 +0000 (UTC) From: Adrian Chadd <adrian@FreeBSD.org> To: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: svn commit: r225042 - user/adrian/if_ath_tx/sys/dev/ath Message-ID: <201108201634.p7KGYVn9059917@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108201634.p7KGYVn9059917>