From owner-svn-src-user@FreeBSD.ORG Sat Aug 20 16:34:32 2011 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4133C106566B; Sat, 20 Aug 2011 16:34:32 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id D47B28FC0C; Sat, 20 Aug 2011 16:34:31 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.4/8.14.4) with ESMTP id p7KGYV17059919; Sat, 20 Aug 2011 16:34:31 GMT (envelope-from adrian@svn.freebsd.org) Received: (from adrian@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id p7KGYVn9059917; Sat, 20 Aug 2011 16:34:31 GMT (envelope-from adrian@svn.freebsd.org) Message-Id: <201108201634.p7KGYVn9059917@svn.freebsd.org> From: Adrian Chadd Date: Sat, 20 Aug 2011 16:34:31 +0000 (UTC) To: src-committers@freebsd.org, svn-src-user@freebsd.org X-SVN-Group: user MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r225042 - user/adrian/if_ath_tx/sys/dev/ath X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 16:34:32 -0000 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