#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
301766 |
|
09-Jun-2016 |
adrian |
[ath] report node queue overflows.
I need to also update athstats to report this too.
|
#
298760 |
|
29-Apr-2016 |
adrian |
[ath] Add counters for STBC TX and LDPC TX.
This is a big no-op until the TX path changes to enable LDPC TX are added.
|
#
296272 |
|
01-Mar-2016 |
jhb |
Remove taskqueue_enqueue_fast().
taskqueue_enqueue() was changed to support both fast and non-fast taskqueues 10 years ago in r154167. It has been a compat shim ever since. It's time for the compat shim to go.
Submitted by: Howard Su <howard0su@gmail.com> Reviewed by: sephe Differential Revision: https://reviews.freebsd.org/D5131
|
#
287197 |
|
27-Aug-2015 |
glebius |
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing.
Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
286437 |
|
07-Aug-2015 |
adrian |
Revert the wifi ifnet changes until things are more baked and tested.
* 286410 * 286413 * 286416
The initial commit broke a variety of debug and features that aren't in the GENERIC kernels but are enabled in other platforms.
|
#
286410 |
|
07-Aug-2015 |
glebius |
Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here:
https://wiki.freebsd.org/projects/ifnet/net80211
Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated.
Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix
|
#
285120 |
|
04-Jul-2015 |
adrian |
Wake up the hardware before doing anything in sysctl.
This stops the panics that occur on MIPS platforms when doing say, 'sysctl dev.ath.0' whilst the MAC is asleep. The MIPS platform is rather unforgiving in getting power-save register access wrong and you will get all kinds of odd failures if you don't have things woken up at the right times.
Tested:
* QCA9558 (TP-Link Archer C7 v2) * AR9331 (Carambola 2)
.. with no VAPs configured and ath0 down (thus the MAC is definitely asleep.)
PR: kern/201117
|
#
276150 |
|
23-Dec-2014 |
adrian |
Bump the valid GPIO range for rfkill up from 8 to 16.
AR5416 and later NICs have more than 8 (Well, more than 6) GPIO pins. So to support rfkill on these NICs we need to bump this up or the rfkill GPIO pin may get reset to the wrong value.
Noticed by: Anthony Jenkins <scoobi_doo@yahoo.com>
|
#
265409 |
|
05-May-2014 |
adrian |
Modify the RX path to keep the previous RX descriptor around once it's used.
It turns out that the RX DMA engine does the same last-descriptor-link- pointer-re-reading trick that the TX DMA engine. That is, the hardware re-reads the link pointer before it moves onto the next descriptor. Thus we can't free a descriptor before we move on; it's possible the hardware will need to re-read the link pointer before we overwrite it with a new one.
Tested:
* AR5416, STA mode
TODO:
* more thorough AP and STA mode testing! * test on other pre-AR9380 NICs, just to be sure. * Break out the RX descriptor grabbing bits from the RX completion bits, like what is done in the RX EDMA code, so .. * .. the RX lock can be held during ath_rx_proc(), but not across packet input.
|
#
265115 |
|
30-Apr-2014 |
adrian |
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver.
The basic power save tracking:
* Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake.
Then, how things are moved into power save:
* Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware.
The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver.
Next, when to wake things up:
* In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those.
Then, some transmit path fixes that aren't related but useful:
* Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation.
Next, some reset path fixes!
* Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk!
Then, beacon fixes in station mode!
* Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.)
Tested:
* AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285
TODO:
* More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing
Obtained from: QCA
|
#
257176 |
|
26-Oct-2013 |
glebius |
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h
Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
250866 |
|
21-May-2013 |
adrian |
Implement a separate hardware queue threshold for aggregate and non-aggr traffic.
When transmitting non-aggregate traffic, we need to keep the hardware busy whilst transmitting or small bursts in txdone/tx latency will kill us.
This restores non-aggregate iperf performance, especially when doing TDMA.
Tested:
* AR5416<->AR5416, TDMA * AR5416 STA <-> AR9280 AP
|
#
250346 |
|
07-May-2013 |
adrian |
Implement STBC receive frame statistics.
The AR9280 and later can receive STBC. This adds some statistics tracking to count these frames.
A patch to athstats will be forthcoming.
|
#
250326 |
|
07-May-2013 |
adrian |
Re-work how transmit buffer limits are enforced - partly to fix the PR, but partly to just tidy up things.
The problem here - there are too many TX buffers in the queue! By the time one needs to transmit an EAPOL frame (for this PR, it's the response to the group rekey notification from the AP) there are no ath_buf entries free and the EAPOL frame doesn't go out.
Now, the problem!
* Enforcing the TX buffer limitation _before_ we dequeue the frame? Bad idea. Because.. * .. it means I can't check whether the mbuf has M_EAPOL set.
The solution(s):
* De-queue the frame first * Don't bother doing the TX buffer minimum free check until after we know whether it's an EAPOL frame or not. * If it's an EAPOL frame, allocate the buffer from the mgmt pool rather than the default pool.
Whilst I'm here:
* Add a tweak to limit how many buffers a single node can acquire. * Don't enforce that for EAPOL frames. * .. set that to default to 1/4 of the available buffers, or 32, whichever is more sane.
This doesn't fix issues due to a sleeping node or a very poor performing node; but this doesn't make it worse.
Tested:
* AR5416 STA, TX'ing 100+ mbit UDP to an AP, but only 50mbit being received (thus the TX queue fills up.) * .. with CCMP / WPA2 encryption configured * .. and the group rekey time set to 10 seconds, just to elicit the behaviour very quickly.
PR: kern/138379
|
#
248671 |
|
23-Mar-2013 |
adrian |
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues.
Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons.
This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here.
The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing.
The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly.
The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things.
Major:
* Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock.
* Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are.
* Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other.
* Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this.
Minor:
* Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down.
* Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away.
Tested:
* AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered)
TODO:
* (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
|
#
248455 |
|
18-Mar-2013 |
adrian |
Print out the current fifo queue depth correctly - not just the max queue depth.
Silly hat to me.
|
#
248451 |
|
17-Mar-2013 |
adrian |
Dump out information about the RX descriptor free list and FIFO information.
|
#
248264 |
|
14-Mar-2013 |
adrian |
Implement "holding buffers" per TX queue rather than globally.
When working on TDMA, Sam Leffler found that the MAC DMA hardware would re-read the last TX descriptor when getting ready to transmit the next one. Thus the whole ATH_BUF_BUSY came into existance - the descriptor must be left alone (very specifically the link pointer must be maintained) until the hardware has moved onto the next frame.
He saw this in TDMA because the MAC would be frequently stopping during active transmit (ie, when it wasn't its turn to transmit.)
Fast-forward to today. It turns out that this is a problem not with a single MAC DMA instance, but with each QCU (from 0->9). They each maintain separate descriptor pointers and will re-read the last descriptor when starting to transmit the next.
So when your AP is busy transmitting from multiple TX queues, you'll (more) frequently see one QCU stopped, waiting for a higher-priority QCU to finsh transmitting, before it'll go ahead and continue. If you mess up the descriptor (ie by freeing it) then you're short of luck.
Thanks to rpaulo for sticking with me whilst I diagnosed this issue that he was quite reliably triggering in his environment.
This is a reimplementation; it doesn't have anything in common with the ath9k or the Qualcomm Atheros reference driver.
Now - it in theory doesn't apply on the EDMA chips, as long as you push one complete frame into the FIFO at a time. But the MAC can DMA from a list of frames pushed into the hardware queue (ie, you concat 'n' frames together with link pointers, and then push the head pointer into the TXQ FIFO.) Since that's likely how I'm going to implement CABQ handling in hostap mode, it's likely that I will end up teaching the EDMA TX completion code about busy buffers, just to be "sure" this doesn't creep up.
Tested - iperf ap->sta and sta->ap (with both sides running this code):
* AR5416 STA * AR9160/AR9220 hostap
To validate that it doesn't break the EDMA (FIFO) chips:
* AR9380, AR9485, AR9462 STA
Using iperf with the -S <tos byte decimal value> to set the TCP client side DSCP bits, mapping to different TIDs and thus different TX queues.
TODO:
* Make this work on the EDMA chips, if we end up pushing lists of frames to the hardware (eg how we eventually will handle cabq in hostap/ibss mode.)
|
#
247087 |
|
21-Feb-2013 |
adrian |
Add an option to allow the minimum number of delimiters to be tweaked.
This is primarily for debugging purposes.
Tested:
* AR5416, STA mode
|
#
247085 |
|
21-Feb-2013 |
adrian |
Add a new option to limit the maximum size of aggregates. The default is to limit them to what the hardware is capable of.
Add sysctl twiddles for both the non-RTS and RTS protected aggregate generation.
Whilst here, add some comments about stuff that I've discovered during my exploration of the TX aggregate / delimiter setup path from the reference driver.
|
#
245465 |
|
15-Jan-2013 |
adrian |
Implement frame (data) transmission using if_transmit(), rather than if_start().
This removes the overlapping data path TX from occuring, which solves quite a number of the potential TX queue races in ath(4). It doesn't fix the net80211 layer TX queue races and it doesn't fix the raw TX path yet, but it's an important step towards this.
This hasn't dropped the TX performance in my testing; primarily because now the TX path can quickly queue frames and continue along processing.
This involves a few rather deep changes:
* Use the ath_buf as a queue placeholder for now, as we need to be able to support queuing a list of mbufs (ie, when transmitting fragments) and m_nextpkt can't be used here (because it's what is joining the fragments together)
* if_transmit() now simply allocates the ath_buf and queues it to a driver TX staging queue.
* TX is now moved into a taskqueue function.
* The TX taskqueue function now dequeues and transmits frames.
* Fragments are handled correctly here - as the current API passes the fragment list as one mbuf list (joined with m_nextpkt) through to the driver if_transmit().
* For the couple of places where ath_start() may be called (mostly from net80211 when starting the VAP up again), just reimplement it using the new enqueue and taskqueue methods.
What I don't like (about this work and the TX code in general):
* I'm using the same lock for the staging TX queue management and the actual TX. This isn't required; I'm just being slack.
* I haven't yet moved TX to a separate taskqueue (but the taskqueue is created); it's easy enough to do this later if necessary. I just need to make sure it's a higher priority queue, so TX has the same behaviour as it used to (where it would preempt existing RX..)
* I need to re-review the TX path a little more and make sure that ieee80211_node_*() functions aren't called within the TX lock. When queueing, I should just push failed frames into a queue and when I'm wrapping up the TX code, unlock the TX lock and call ieee80211_node_free() on each.
* It would be nice if I could hold the TX lock for the entire TX and TX completion, rather than this release/re-acquire behaviour. But that requires that I shuffle around the TX completion code to handle actual ath_buf free and net80211 callback/free outside of the TX lock. That's one of my next projects.
* the ic_raw_xmit() path doesn't use this yet - so it still has sequencing problems with parallel, overlapping calls to the data path. I'll fix this later.
Tested:
* Hostap - AR9280, AR9220 * STA - AR5212, AR9280, AR5416
|
#
242993 |
|
13-Nov-2012 |
adrian |
Place 'dev.ath.X.debug' back under ATH_DEBUG, rather than ATH_DEBUG_ALQ.
|
#
242872 |
|
10-Nov-2012 |
kevlo |
s/ATH_DEBUG/ATH_DEBUG_ALQ
|
#
242803 |
|
08-Nov-2012 |
adrian |
Fix the build - fix up the ath_alq code to not compile by default.
|
#
242782 |
|
08-Nov-2012 |
adrian |
Add some hooks into the driver to attach, detach and record EDMA descriptor events.
This is primarily for the TX EDMA and TX EDMA completion. I haven't yet tied it into the EDMA RX path or the legacy TX/RX path.
Things that I don't quite like:
* Make the pointer type 'void' in ath_softc and have if_ath_alq*() return a malloc'ed buffer. That would remove the need to include if_ath_alq.h in if_athvar.h. * The sysctl setup needs to be cleaned up.
|
#
240899 |
|
24-Sep-2012 |
adrian |
Migrate the ath(4) KTR logging to use an ATH_KTR() macro.
This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time.
Add some new probes for TX and TX completion.
|
#
240639 |
|
18-Sep-2012 |
adrian |
Implement my first cut at filtered frames in aggregation sessions.
The hardware can optionally "filter" frames if successive transmissions to a given node (ie, "entry in the keycache") fail. That way the hardware can implement a kind of early abort of all the other frames queued to that destination, rather than simply trying to TX each frame to that destination (and failing.)
The background:
* If a frame comes back as being filtered, the hardware didn't try to TX it (or it was outside the TX burst opportunity.) So, take it as a hint that some (but not all, see below) frames to the destination may be filtered.
* If the CLRDMASK bit is set in a TX descriptor, the "filter to this destination" bit in the keycache entry is cleared and TX to that host will be unconditionally retried.
* Right now everything has the CLRDMASK bit set, so filtered frames tend to be aggregates and frames that fall outside of the WME burst window. It was a bit worse in the past as I had messed up the TX flags and CLRDMASK wasn't being set on aggregate frames.
The annoying bits:
* It's easy (ish) to do for aggregate session frames - firstly, they can be retried in any order as long as they're within the BAW, and there's already a bunch of infrastructure tracking how many frames the TID has queued to the hardware (tid->hwq_depth.) However, for frames that bypassed the software queue, hwq_depth doesn't get incremented. I'll fix that in a subsequent commit.
* For non-aggregate session frames, the only retries that can occur are ones for sequence numbers that hvaen't successfully been TXed yet. Since there's no re-ordering going on in non-aggregate sessions, if any subsequent seqno frames make it out, any filtered frames before that seqno need to be dropped.
Hence why this initially is just for aggregate session frames.
* Since there may be intermediary frames to the destination that have CLRDMASK set - for example, any directly dispatched management frames to that destination - it's possible that there will be some filtered frames followed up by some non filtered frames. Thus, it can't be assumed that once you see a filtered frame for the given destination node, all subsequent frames for all TIDs will be filtered.
Ok, with that in mind:
* Create a per-TID filtered frame queue for frames that the hardware returns as filtered.
* Track filtered frames per-tid, rather than per-node. It just makes the locking much easier.
* When a filtered frame appears in the completion function, the node transitions to "filtered", and all subsequent completed error frames (filtered or otherwise) are put on the filtered frame queue. The TID is paused once (during the transition from non-filtered to filtered).
* If a filtered frame retry count exceeds SWMAX_RETRIES, a BAR should be sent.
* Once all the frames queued to the hardware for the given filtered frame TID, transition back from filtered frame to non-filtered frame, which means pre-pending all the filtered frames onto the head of the software queue, clearing the filtered frame state and unpausing the TID.
Things get quite hairy around handling completion (aggr, non-aggr, norm, direct-dispatched frames to a hardware queue); whether it's an "error", "cleanup" or "BAR" state as well as filtered, which order to do things in (eg do filtered BEFORE checking for BAR, as the filter completion may be needed to actually transmit a BAR frame.)
This work has definitely reminded me that I have to tidy up all the locking and remove some of the ridiculous lock/unlock/lock/unlock going on in the completion functions.
It's also reminded me that I should really split out TID versus hardware TXQ locking, even if the underlying locking is still the destination hardware TXQ.
Finally, this is all pre-requisite for working on AP mode power save support (PS-POLL, uAPSD) as well as improving performance to misbehaving nodes (as they can transition into filter mode, stopping any TX until everything has caught up.)
Finally (ish) - this should also be done for non-aggregate sessions as there are still plenty of laptops and mobile devices that don't speak 802.11n but do wish for stable, useful power save AP support where packets aren't simply dropped. This requires software retransmission for non-aggregate sessions to be implemented, which includes the caveats I've mentioned above.
Finally finally - this doesn't yet do anything about the CLRDMASK bit in the TX descriptor. That's still unconditionally set to 1. I'll debug the current work (mostly ensuring I haven't busted up the hairy transitions between BAR, filtered, error (all frames in an aggregate failing) and cleanup (when transitioning from aggregation -> non-aggregation.))
Finally finally finally - this is all original work by yours truely, rather than ported from the Atheros internal driver codebase or Linux ath9k.
Tested: * AR9280, AR5416 in STA mode * AR9280, AR9130 in hostap mode * Lots and lots of iperf testing in very marginal and non-marginal conditions, complete with inducing filtered frames + BAR TX conditions.
|
#
239263 |
|
14-Aug-2012 |
adrian |
Dump out the TX FIFO depth.
|
#
238507 |
|
15-Jul-2012 |
adrian |
Handle RX Keymiss events.
The AR9003 series NICs implement a separate RX error to signal that a Keycache miss occured. The earlier NICs would not set the key index valid bit.
I'll dig into the difference between "no key index bit set" and "keycache miss".
|
#
237038 |
|
13-Jun-2012 |
adrian |
Implement a global (all non-mgmt traffic) TX ath_buf limitation when ath_start() is called.
This (defaults to 10 frames) gives for a little headway in the TX ath_buf allocation, so buffer cloning is still possible.
This requires a lot omre experimenting and tuning.
It also doesn't stop a node/TID from consuming all of the available ath_buf's, especially when the node is going through high packet loss or only talking at a low TX rate. It also doesn't stop a paused TID from taking all of the ath_bufs. I'll look at fixing that up in subsequent commits.
PR: kern/168170
|
#
237000 |
|
13-Jun-2012 |
adrian |
Implement a separate, smaller pool of ath_buf entries for use by management traffic.
* Create sc_mgmt_txbuf and sc_mgmt_txdesc, initialise/free them appropriately. * Create an enum to represent buffer types in the API. * Extend ath_getbuf() and _ath_getbuf_locked() to take the above enum. * Right now anything sent via ic_raw_xmit() allocates via ATH_BUFTYPE_MGMT. This may not be very useful. * Add ATH_BUF_MGMT flag (ath_buf.bf_flags) which indicates the current buffer is a mgmt buffer and should go back onto the mgmt free list. * Extend 'txagg' to include debugging output for both normal and mgmt txbufs. * When checking/clearing ATH_BUF_BUSY, do it on both TX pools.
Tested:
* STA mode, with heavy UDP injection via iperf. This filled the TX queue however BARs were still going out successfully.
TODO:
* Initialise the mgmt buffers with ATH_BUF_MGMT and then ensure the right type is being allocated and freed on the appropriate list. That'd save a write operation (to bf->bf_flags) on each buffer alloc/free.
* Test on AP mode, ensure that BAR TX and probe responses go out nicely when the main TX queue is filled (eg with paused traffic to a TID, awaiting a BAR to complete.)
PR: kern/168170
|
#
235491 |
|
15-May-2012 |
adrian |
Migrate ath_debug and sc_debug from an int to a uint64_t / QUAD; add some more BAR debugging logic.
* Change the definition of ath_debug and ath_softc.sc_debug from int to uint64_t; * Change the relevant sysctls; * Add a new BAR TX debugging field; * Use this in if_ath_tx.
This has been tested by using the sysctl program, which happily allows for fields > 32 bits to be configured.
|
#
234090 |
|
10-Apr-2012 |
adrian |
Squirrel away SYNC interrupt debugging if it's enabled in the HAL.
Bus errors will show up as various SYNC interrupts which will be passed back up to ath_intr().
|
#
233989 |
|
07-Apr-2012 |
adrian |
Break out the legacy duration and protection code into routines, call these after rate control selection is done.
The duration/protection code wasn't working - it expected the rix to be valid. Unfortunately after I moved the rate control selection into late in the process, the rix value isn't valid and thus the protection/ duration code would get things wrong.
HT frames are now correctly protected with an RTS and for the AR5416, this involves having the aggregate frames be limited to 8K.
TODO:
* Fix up the DMA sync to occur just before the frame is queued to the hardware. I'm adjusting the duration here but not doing the DMA flush.
* Doubly/triply ensure that the aggregate frames are being limited to the correct size, or the AR5416 will get unhappy when TXing RTS-protected aggregates.
|
#
232764 |
|
10-Mar-2012 |
adrian |
Don't flood the cabq/mcastq with frames.
In a very noisy 2.4GHz environment (with HT/40 enabled, making it worse) I saw the following occur:
* the air was considered "busy" a lot of the time; * the cabq time is quite short due to staggered beacons being enabled; * it just wasn't able to keep up TX'ing CABQ frames; * .. and the cabq would swallow up all the TX ath_buf's.
This patch introduces a twiddle which allows the maximum cabq depth to be set, forcing further frames to be dropped.
It defaults to the TX buffer count at the moment, so the default behaviour isn't changed.
I've also started fleshing out a similar setup for the data path, so it doesn't swallow up all the available TX buffers and preventing management frames (such as ADDBA) out.
PR: kern/165895
|
#
232250 |
|
28-Feb-2012 |
gavin |
Correct capitalization of "Hz" in user-visible text (manpages, printf(), etc).
MFC after: 3 days
|
#
228891 |
|
26-Dec-2011 |
adrian |
Flesh out configurable hardware based LED blinking.
The hardware (MAC) LED blinking involves a few things:
* Selecting which GPIO pins map to the MAC "power" and "network" lines; * Configuring the MAC LED state (associated, scanning, idle); * Configuring the MAC LED blinking type and speed.
The AR5416 HAL configures the normal blinking setup - ie, blink rate based on TX/RX throughput. The default AR5212 HAL doesn't program in any specific blinking type, but the default of 0 is the same.
This code introduces a few things:
* The hardware led override is configured via sysctl 'hardled'; * The MAC network and power LED GPIO lines can be set, or left at -1 if needed. This is intended to allow only one of the hardware MUX entries to be configured (eg for PCIe cards which only have one LED exposed.)
TODO:
* For AR2417, the software LED blinking involves software blinking the Network LED. For the AR5416 and later, this can just be configured as a GPIO output line. I'll chase that up with a subsequent commit.
* Add another software LED blink for "Link", separate from "activity", which blinks based on the association state. This would make my D-Link DWA-552 have consistent and useful LED behaviour (as they're marked "Link" and "Activity."
* Don't expose the hardware LED override unless it's an AR5416 or later, as the previous generation hardware doesn't have this multiplexing setup.
|
#
228888 |
|
26-Dec-2011 |
adrian |
Refactor out the software LED config code into a common function, called ath_led_config().
The eventual aim is to have both software and hardware based LED configuration done here.
|
#
227868 |
|
23-Nov-2011 |
adrian |
Flesh out the TX aggregation completion statistics.
* Failall is now named just that. * Add TX ok and TX fail, for aggregate frame sub-frames.
This will break athstats; a followup commit wil resolve this.
Sponsored by: Hobnob, Inc.
|
#
227410 |
|
09-Nov-2011 |
adrian |
Introduce a work-around for issues with the AR5416 based MAC on SMP devices.
The AR5416 MAC (which shows up in the AR5008, AR9001, AR9002 devices) has issues with PCI transactions on SMP machines. This work-around enforces that register access is serialised through a (global for now) spinlock.
This should stop the hangs people have seen with the AR5416 PCI devices on SMP hosts.
Obtained by: Linux, Atheros
|
#
227375 |
|
09-Nov-2011 |
adrian |
Add a new HAL parameter which forces a full reset rather than warm reset. This forces a full reset of the baseband/radio and seems needed to clear some issues (with Merlin at least) when the baseband gets confused in a very noisy environment.
Sponsored by: Hobnob, Inc.
|
#
227353 |
|
08-Nov-2011 |
adrian |
In preparation for supporting 11n TX/RX properly, allow for TX queue draining and interface resets to be marked as ATH_RESET_DEFAULT, ATH_RESET_FULL, ATH_RESET_NOLOSS.
Currently a reset is still a reset - ie, all tx/rx frames in the hardware queues are purged. This means that those frames will be lost to the 11n TX and RX aggregation state tracking, breaking AMPDU sessions.
The (eventual) new semantics:
* ATH_RESET_DEFAULT: full reset, this is the default for reset situations which I haven't yet figured out what they should be. * ATH_RESET_FULL: A full reset - for things such as channel changes. * ATH_RESET_NOLOSS: Don't flush TX/RX queues - handle pending RX frames and leave TX frames where they are; restart TX DMA from where it was.
|
#
227344 |
|
08-Nov-2011 |
adrian |
Migrate the STAILQ lists to TAILQs.
A bunch of the 11n TX aggregation logic wants to traverse lists of buffers in various ways. In order to provide O(1) behaviour in this instance, use TAILQs.
This does blow out the memory footprint and CPU cycles slightly for some of these operations. I may convert some of these back to STAILQs once the rest of the software transmit queue handling has been stabilised.
Sponsored by: Hobnob, Inc.
|
#
227328 |
|
08-Nov-2011 |
adrian |
Begin merging in some of my 802.11n TX aggregation driver changes.
* Add a PCU lock, which isn't currently used but will eventually be used to serialise some of the driver access.
* Add in all the software TX aggregation state, that's kept per-node and per-TID.
* Add in the software and aggregation state to ath_buf.
* Add in hooks to ath_softc for aggregation state and the (upcoming) aggregation TX state calls.
* Add / fix the HAL access macros.
Obtained from: Linux, ath9k Sponsored by: Hobnob, Inc.
|
#
226798 |
|
26-Oct-2011 |
adrian |
As a prelude to bringing over the 11n work, include some extra statistics fields.
|
#
224502 |
|
29-Jul-2011 |
adrian |
Reset the NIC if ANI is enabled or disabled.
Although this may not be what the original sysctl was designed to do, it feels a bit more "expected".
Before, if ANI is disabled, the initial ANI parameters are still written to the hardware, even if they're not enabled. "ANI enabled" would then adjust the noise immunity parameters dynamically. Disabling ANI would simply leave the existing noise immunity parameters where they are, and disable the dynamic part.
The problem is that disabling ANI doesn't leave the hardware in a consistent, predictable state - so asking a user to disable ANI wouldn't actually reset the NIC to a consistent set of PHY signal detection parameters, resulting in an unpredictable/unreliable outcome. This makes it difficult to get reliable debugging information from the user.
Approved by: re (kib)
|
#
223459 |
|
23-Jun-2011 |
adrian |
Break out most of the HAL related tweaks into a per-HAL instance, rather than global variables.
This specifically allows for debugging to be enabled per-NIC, rather than globally.
Since the ath driver doesn't know about AH_DEBUG, and to keep the ABI consistent regardless of whether AH_DEBUG is enabled or not, enable the debug parameter always but only conditionally compile in the debug methods if needed.
The ALQ support is currently still global pending some brainstorming.
Submitted by: ssgriffonuser@gmail.com Reviewed by: adrian, bschmidt
|
#
221965 |
|
15-May-2011 |
adrian |
* Add some more TX descriptor error counters; this'll be helpful when implementing TX aggregation * Whilst I'm there, comment some RX error counters
|
#
220782 |
|
18-Apr-2011 |
adrian |
Add TX carrier sense timeout statistics.
|
#
220772 |
|
18-Apr-2011 |
adrian |
Add global TX timeout handling.
The global TX timeout counter increments whenever a frame is ready to be transmitted and the medium is busy.
|
#
220132 |
|
29-Mar-2011 |
adrian |
According to ath9k recv.c, one shouldn't be doing self-linked descriptors in the RX path when doing 11n and block-ack'ed frames. Apparently, the MAC will loop over that self-linked descriptor and treat it as "good enough" for (incorrectly!) ACKing the frames in the block-ack.
Until I figure out how to work around this issue in the future, this counter will tell me if packet RX processing ever gets to the point where it's touching the self-linked descriptor. If there's ever enough packets to get to that point, BA's will be invalid and likely very unhappy.
|
#
219180 |
|
02-Mar-2011 |
adrian |
Migrate the sysctl related routines (statistics, debugging, etc) out of if_ath.c and into if_ath_sysctl.c .
|