Date: Mon, 22 Apr 2013 05:48:19 +0000 (UTC) From: Adrian Chadd <adrian@FreeBSD.org> To: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: svn commit: r249750 - user/adrian/net80211_tx/sys/dev/ath Message-ID: <201304220548.r3M5mJkq012914@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: adrian Date: Mon Apr 22 05:48:18 2013 New Revision: 249750 URL: http://svnweb.freebsd.org/changeset/base/249750 Log: Add a TODO list. Added: user/adrian/net80211_tx/sys/dev/ath/powersave-todo.txt Added: user/adrian/net80211_tx/sys/dev/ath/powersave-todo.txt ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ user/adrian/net80211_tx/sys/dev/ath/powersave-todo.txt Mon Apr 22 05:48:18 2013 (r249750) @@ -0,0 +1,104 @@ + +Things that need doing with this power save stuff: + +Stuff to clean up before the node pause/resume stuff goes into the +tree: + +* There's an unfortunate "race" at the moment, even before the node pause/unpause - + if the node gets flushed whilst there's stuff in the hardware queue, + then I don't think the aggregation session gets torn down via + the normal path. Check this! + +* .. because if it doesn't, then there's no chance to run cleanup + on the TIDs with hardware-queued frames! + +* When a node cleanup or node reassociation occurs, any flush should + also either trigger a pass through the aggregate down method, + or just a call to TID cleanup. + +* Maybe instead, when a node reassociates, we shouldn't just blindly + cleanup and overwrite the existing state. Instead, maybe we want + to tear down the aggregation sessions ourselves and transition the + node through the "cleanup" before we continue transmitting? + + Ie: + + * Do a cleanup call for each TID - which flushes the swq and + figures out if anything in the BAW is pending in the hardware queue; + * If we're pending completion for any TID - just wait until the + pending count finishes; + * Clear the BAR flags so we don't attempt to TX any BAR frames or wait + for BAR to come back; + * But leave the queue paused, waiting until the transmission on said + VAP has completed! + +-- + +* Modify node cleanup to require the tx lock to be held, but have it + take an athbuf list - make the caller free the cleaned up + frames. That way it can be done outside of the lock. + This makes it easier to call cleanup on all TIDs for a node + during a flush or reassociation. + +stuff to validate once the above is in the tree: + +* What mgmt / control frames are being transmitted whilst a node is asleep? + eg reassociation? + + -- it was something calling ic_raw_xmit() ! + -- .. which was just software queueing, and not checking whether anything + needed to bypass powersave. Sigh. + +* We need to ensure that the node state - bar state, sched state, etc are + reset during a reassociation - but not the paused / incomp bits. + The node may actually be in the process of being recycled. + +* .. so we still have some BAR races that cause unbalanced pause/resume + calls. Track those down! + +* .. and it's going to be interesting to see how a reassoc/assoc + node that already has state (eg the whole pause/resume/cleanup) + stuff is handled. Maybe what I should do during node flush + is to simply mark all frames in the hardware queue as not + being in the BAW any longer (like cleanup) but not pause + the queue until they're done. Just let them transmit. + +* What else could cause an existng node to assoc/reassoc, but leave it + in a stuck state? Hm! + +* Also, why do I keep getting stuck beacon frames? + +Apr 18 01:13:37 lucy kernel: [100822] ath0: ath_tx_raw_start: 8c:7b:9d:d6:65:ba: Node is asleep; sending mgmt (type=0, subtype=176) +Apr 18 01:13:37 lucy kernel: [100822] ath0: ath_newassoc: 8c:7b:9d:d6:65:ba: reassoc; is_powersave=1 +Apr 18 01:13:37 lucy kernel: [100822] ath0: ath_tx_node_wakeup: an=0xd24a1000: node was already awake +Apr 18 01:13:38 lucy kernel: ath0: stuck beacon; resetting (bmiss count 4) +Apr 18 01:14:01 lucy last message repeated 4 times + +.. check to see if I'm doing something daft, like pulling frames off +of the hardware queue without actually stopping DMA? + +* I likely should hack the BAR TX code to not retransmit a BAR frame + due to a timeout if the node is asleep. Retransmit it if it fails, + sure, but not if it times out. Otherwise we may end up queuing multiple + BAR frames to the remote end. + +* It's possible that a sleeping node will slowly consume all available + ath_buf entries until they're all gone. Eg, if my macbook sends a powermgt + frame to go to sleep, then selects another AP. + + So we should limit how deep the per-node queue can get when the device + is asleep. + + .. except management frames, those need to go out. + + .. although again, we may end up typing up all the management frames (eg + BAR frames, or other action frames) so we should also likely limit how + many pending management frames can go into the software queue. + Direct-queuing management/control frames to the hardware is fine + though! + +-- + +done stuff +---------- +
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201304220548.r3M5mJkq012914>