From owner-svn-src-user@FreeBSD.ORG Mon Oct 24 14:50:56 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 E1B97106566C; Mon, 24 Oct 2011 14:50:56 +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 D1F508FC15; Mon, 24 Oct 2011 14:50:56 +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 p9OEouvS048681; Mon, 24 Oct 2011 14:50:56 GMT (envelope-from adrian@svn.freebsd.org) Received: (from adrian@localhost) by svn.freebsd.org (8.14.4/8.14.4/Submit) id p9OEoucK048679; Mon, 24 Oct 2011 14:50:56 GMT (envelope-from adrian@svn.freebsd.org) Message-Id: <201110241450.p9OEoucK048679@svn.freebsd.org> From: Adrian Chadd Date: Mon, 24 Oct 2011 14:50:56 +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: r226693 - 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: Mon, 24 Oct 2011 14:50:57 -0000 Author: adrian Date: Mon Oct 24 14:50:56 2011 New Revision: 226693 URL: http://svn.freebsd.org/changeset/base/226693 Log: More updates 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 Mon Oct 24 14:45:31 2011 (r226692) +++ user/adrian/if_ath_tx/sys/dev/ath/README Mon Oct 24 14:50:56 2011 (r226693) @@ -79,8 +79,6 @@ Things that need doing! 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, @@ -157,34 +155,37 @@ Things that need doing! before it received the next retransmit (and thus the AMPDU RX queue would get flushed.) -Things that need investigating! - -There's a crash which occurs when a wlan interface is destroyed and -re-created. - - -ifconfig wlan0 destroy - -adrian-home-mips# /root/wifi-client ath0 CACHEBOY_11N_1 -ifconfig: interface wlan0 does not exist -wlan0: Ethernet address: 00:15:6d:84:05:52 -kern.msgbuf_clear: 0 -> 0 -net.wlan.0.debug: 0x0 => 0x80000000<11n> -net.wlan.0.debug: 0x80000000 => 0x80800000<11n,assoc> -Trap cause = 4 (address error (load or I-fetch) - kernel mode) -[ thread pid 0 tid 100025 ] -Stopped at ieee80211_node_attach+0x3f4: lw v0,24(v0) -db> reset - -Maybe do a bit of kernel version bisecting to see when this was first broken? -Hopefully it's something easy - * How should channel scanning be handled? Right now it's causing both a HW TXQ and SW TXQ / node flush; this means the BAW will need to be slid along. Eek. * When a node is flushed (but not being deleted) should the BAW also be updated? I don't think it is right now and this could be incorrect. +* Send BAR when needed + + after TX failure + + when else? When shutting down an aggregation session and flushing packets? + + ieee80211_send_bar() will only work if IEEE80211_AGGR_RUNNING is set; + what's that mean for trying to send BAR frames during session teardown? + + it'll call raw_xmit to send the BAR, so the various bits of TX code + are going to have to be recursive. How's that going to work out for us? + (think: with all the TXQ node locks being held..) + + ic->ic_bar_response(ni, tap, status) is called on BAR response, and + ieee80211_ampdu_stop(ni, tap, IEEE80211_REASON_TIMEOUT) is called on + repeated failure to ACK the BAR. + + - I've implemented this; the recursion into the TX path was fixed by + causing all TX scheduling and completion to run in the ath task, + ath_tx_start() / ath_tx_raw_xmit() just queues packets to the hardware + or software queue. It doesn't run scheduling as well. This eliminated + most of the locking issues and the recursion. + + - There's a dirty workaround to unpause the queue if BAR TX is definitely + failing. This needs to be addressed before this work is merged back into + -HEAD. + + + + Stuff to do to the rate control code ------------------------------------ @@ -351,29 +352,6 @@ pid 0 - I had messed up the blockack window tracking a bit, and there were some races in marking the queue scheduled/unscheduled. I've since fixed these. -* Send BAR when needed - + after TX failure - + when else? When shutting down an aggregation session and flushing packets? - + ieee80211_send_bar() will only work if IEEE80211_AGGR_RUNNING is set; - what's that mean for trying to send BAR frames during session teardown? - + it'll call raw_xmit to send the BAR, so the various bits of TX code - are going to have to be recursive. How's that going to work out for us? - (think: with all the TXQ node locks being held..) - + ic->ic_bar_response(ni, tap, status) is called on BAR response, and - ieee80211_ampdu_stop(ni, tap, IEEE80211_REASON_TIMEOUT) is called on - repeated failure to ACK the BAR. - - - I've implemented this; the recursion into the TX path was fixed by - causing all TX scheduling and completion to run in the ath task, - ath_tx_start() / ath_tx_raw_xmit() just queues packets to the hardware - or software queue. It doesn't run scheduling as well. This eliminated - most of the locking issues and the recursion. - - - There's a dirty workaround to unpause the queue if BAR TX is definitely - failing. This needs to be addressed before this work is merged back into - -HEAD. - - * LOR between the net80211 node lock and the txqs - These have disappeared now that the locking has been reworked. @@ -470,3 +448,7 @@ pid 1510 - done - this is currently protected by ATH_LOCK and shadowed in the ath_softc. +* 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(); + - This is done - rate control lookup is done just before it's hardware + queued.