summaryrefslogtreecommitdiff
path: root/sys/dev/ath/if_ath.c
Commit message (Collapse)AuthorAgeFilesLines
...
* oops, add a missing lock.Adrian Chadd2012-03-291-1/+4
| | | | Notes: svn path=/head/; revision=233682
* Defer the rescheduling of TID -> TXQ frames in some instances.Adrian Chadd2012-03-291-0/+34
| | | | | | | | | | | | | | | | | | | | | Right now ath_txq_sched() is mainly called from the TX ath_tx_processq() routine, which is (mostly) done as part of the taskqueue. It shouldn't be called outside the taskqueue. But now that I'm about to flip back on BAR TX, I'm going to start stressing the ath_tx_tid_pause() and ath_tx_tid_resume() paths. What I don't want to have happen is a reschedule of the TID traffic _during_ the completion of TX frames. Ideally I'd like to have a way to flag back up to the processing code that the current hardware queue should be rechecked for software TID queue frames. But for now, this should suffice for the BAR TX case. I may eventually delete this code once I've brought some further sanity to the general TX queue/completion path. Notes: svn path=/head/; revision=233673
* Add the new channel width change field to the ath(4) driver.Adrian Chadd2012-03-251-0/+27
| | | | | | | | | | | | | | | | This is not entirely correct as it simply resets the channel, flushing whatever is in the TX/RX queue. This can and will break aggregation BAW tracking. But the alternative (HT40 frames being sent with the hardware in HT20 mode) is even worse. There's still a small window between the htinfo being received (and the ni_chw field being updated) which could cause problems. I'll look at fleshing this out in follow-up commits. PR: kern/166286 Notes: svn path=/head/; revision=233453
* Fix a couple of debugging outputs.Adrian Chadd2012-03-161-4/+13
| | | | | | | | | | | | * printf -> device_printf * print the buffer pointer and sequence number for any buffer that wasn't correctly tidied up before it was freed. This is to aid in some current SMP TX debugging stalls. PR: kern/166190 Notes: svn path=/head/; revision=233053
* Add a dependency on ALQ if IEEE80211_ALQ and/or AH_DEBUG_ALQ is included.Adrian Chadd2012-03-161-0/+6
| | | | Notes: svn path=/head/; revision=233051
* Stick the if_drv_flags access (check and modify) behind the ifq lock.Adrian Chadd2012-03-101-9/+18
| | | | | | | | | Although access to the flags to check/set OACTIVE is racy due to how the default if_start() function works, this should remove any races with read/modify/write between threads. Notes: svn path=/head/; revision=232795
* Don't flood the cabq/mcastq with frames.Adrian Chadd2012-03-101-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=232764
* Should the mcast queue be locked here? In case more multicast trafficAdrian Chadd2012-03-091-0/+2
| | | | | | | | | | comes along? This commit was brought to you via an Atheros AR5210, associated to an 3x3 HT40 11na access point. Yes, this driver still works with it. Notes: svn path=/head/; revision=232752
* Insert extra paranoia into the ath(4) driver.Adrian Chadd2012-03-091-0/+4
| | | | | | | | | | | This function must be called with both the source and destination TXQs locked or things will get hairy. I added this as part of some debugging in a PR but it turned out to not be the cause. I still think it's -correct- so, here it is. Notes: svn path=/head/; revision=232719
* Wrap another ATH_LOCK around the scanning flag.Adrian Chadd2012-03-021-0/+2
| | | | | | | PR: kern/163318 Notes: svn path=/head/; revision=232375
* Wrap the scan code state change stuff behind ATH_LOCK and the PCU fiddlingAdrian Chadd2012-03-021-0/+10
| | | | | | | | | | behind the PCU lock. sc_scanning is being checked without ATH_LOCK behind held and could in theory run from multiple threads. Notes: svn path=/head/; revision=232374
* Attempt to further fix some of the concurrency/reset issues that occur.Adrian Chadd2012-02-251-16/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ath_reset() is being called in softclock context, which may have the thing sleep on a lock. To avoid this, since we really _shouldn't_ be sleeping on any locks, break out the no-loss reset path into a tasklet and call that from: + ath_calibrate() + ath_watchdog() This has the added advantage that it'll end up also doing the frame RX cleanup from within the taskqueue context, rather than the softclock context. * Shuffle around the taskqueue_block() call to be before we grab the lock and disable interrupts. The trouble here is that taskqueue_block() doesn't block currently queued (but not yet running) tasks so calling it doesn't guarantee no further tasks (that weren't running on _A_ CPU at the time of this call) will complete. Calling taskqueue_drain() on these tasks won't work because if any _other_ thread calls taskqueue_enqueue() for whatever reason, everything gets very angry and stops working. This slightly changes the race condition enough to let ath_rx_tasklet() run before we try disabling it, and thus quietens the warnings a bit. The (more) true solution will be doing something like the following: * having a taskqueue_blocked mask in ath_softc; * having an interrupt_blocked mask in ath_softc; * only calling taskqueue_drain() on each individual task _after_ the lock has been acquired - that way no further tasklet scheduling is going to occur. * Then once the tasks have been blocked _and_ the interrupt has been disabled, call taskqueue_drain() on each, ensuring that anything that _was_ scheduled or running is removed. The trouble is if something calls taskqueue_enqueue() on a task after taskqueue_blocked() has been called but BEFORE taskqueue_drain() has been called, ta_pending will be set to 1 and taskqueue_drain() will sit there stuck in msleep() until you hard-kill the machine. PR: kern/165382 PR: kern/165220 Notes: svn path=/head/; revision=232163
* Use the passed-in channel rather than ic->ic_curchan.Adrian Chadd2012-02-231-1/+1
| | | | | | | | | | I'm not sure _why_ the ic is NULL here, but I've seen it occasionally do this after I've been tinkering with things for a while. It ends up crashing in a call to ath_chan_set() via the net80211 scan code and scan task. Notes: svn path=/head/; revision=232041
* Try to ensure that ieee80211_newstate() and the vap_newstate methodsAdrian Chadd2012-02-181-0/+15
| | | | | | | | | | | | | | | hold the lock. This is part of my series of work to try and capture when net80211 locking isn't. ObNote: it'd be nice to be able to mark a lock as "assert if the lock is dropped", so I could capture functions which decide that dropping and reacquiring the lock is a good idea (without re-checking the sanity of the state protected by the lock.) Notes: svn path=/head/; revision=231893
* Enforce some consistent ordering and handling of interrupt disable/enableAdrian Chadd2012-02-171-12/+8
| | | | | | | | | | | | | | | | | | with RX/TX halting. * Always disable/enable interrupts during a channel change, just to simply things. * Ensure that the ath taskqueue has completed and is paused before continuing. This dramatically reduces the instances of overlapping RX and reset conditions. PR: kern/165220 Notes: svn path=/head/; revision=231857
* Begin breaking out the txrx stop code into a locked and unlocked variant.Adrian Chadd2012-02-171-3/+14
| | | | | | | PR: kern/165220 Notes: svn path=/head/; revision=231854
* Attempt to address some potential vap->iv_bss race conditions.Adrian Chadd2012-02-131-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are unfortunately a number of situations where vap->iv_bss is changed or freed by some code in net80211. Because multiple threads can concurrently be doing work (and the vap->iv_bss access isn't at all done behind any kind of lock), it's quite possible that: * a change will occur in one thread - eg, by a call through ieee80211_sta_join1(); * a state change occurs in another thread - eg an RX is scheduled in the ath tasklet and it calls ieee80211_input_mimo_all(), which does dereference vap->iv_bss; * these two executing concurrently, causing things to explode. Another instance is ath_beacon_alloc() which takes an ieee80211_node *. It's called with the vap->iv_bss node from ath_newstate(). If the node has changed in the meantime (say it's been freed elsewhere) the reference that it grabbed _before_ refcounting it may be stale. I would _prefer_ that these sorts of things were serialised somewhere but that may be a bit much to ask. Instead, the best we can (currently) hope is that the underlying bss node is still (somewhat) valid. There is a related PR (kern/164382) described by the first case above. That should be fixed by properly serialising the RX path and reset path so an RX can't occur at the same time as the vap free/shutdown path. This is inspired by some related fixes in r212127. PR: kern/165060 Notes: svn path=/head/; revision=231571
* .. oops, use the right chainmask.Adrian Chadd2012-02-101-1/+1
| | | | Notes: svn path=/head/; revision=231370
* Add in a new driver feature to allow the TX and RX chainmask to beAdrian Chadd2012-02-101-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | overridden at attach time. Some 802.11n NICs may only have one physical antenna connected. The radios will be very upset if you try enabling radios which aren't connected to antennas. This allows hints to override the TX and RX chainmask. These hints are: hint.ath.X.rx_chainmask hint.ath.X.tx_chainmask They can be set at either boot time or in kenv before the module is loaded. This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=231369
* Correctly fetch the TX/RX stream count from the HAL.Adrian Chadd2012-01-311-2/+2
| | | | | | | Pointy hat to: me Notes: svn path=/head/; revision=230846
* Two changes from my DFS work:Adrian Chadd2012-01-281-4/+17
| | | | | | | | | | | * Grab the net80211com lock when calling ieee80211_dfs_notify_radar(). * Use the tsf extend function to turn the 64 bit base TSF into a per- frame 64 bit TSF. This will improve radiotap logging (which will now have a (more) correct per-frame TSF, rather then the single TSF64 value read at the beginning of ath_rx_proc(). Notes: svn path=/head/; revision=230657
* Add some node debugging which has helped me track down which particularAdrian Chadd2012-01-261-0/+7
| | | | | | | concurrent vap->iv_bss free issues have been occuring. Notes: svn path=/head/; revision=230564
* Re-enable the PHY radar error frames if sc_dodfs is set.Adrian Chadd2012-01-111-0/+7
| | | | | | | | This was messing up a local port of the atheros reference radar detection code; I'll fix the port instead. Notes: svn path=/head/; revision=229950
* Flesh out configurable hardware based LED blinking.Adrian Chadd2011-12-261-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=228891
* Setup the initial LED state on attach and resume.Adrian Chadd2011-12-261-1/+6
| | | | | | | | | | | | | | | | | | | Some of the NICs I have here power up with the LEDs blinking, which is incorrect. The blinking should only occur when the NIC is attempting to associate. * On powerup, set the state to HAL_LED_INIT, which turns on the "Power" MAC LED but leaves the "Network" MAC LED the way it is. * On resume, also init it to HAL_LED_INIT unless in station mode, where it's forced to HAL_LED_RUN. Hopefully the net80211 state machine will call newstate() at some point, which will refiddle the LEDs. I've tested this on a handful of 11n and pre-11n NICs. The blinking behaviour is slightly more sensible now. Notes: svn path=/head/; revision=228890
* Refactor out the software LED config code into a common function, calledAdrian Chadd2011-12-261-10/+2
| | | | | | | | | | ath_led_config(). The eventual aim is to have both software and hardware based LED configuration done here. Notes: svn path=/head/; revision=228888
* First pass of LED related code changes.Adrian Chadd2011-12-261-44/+1
| | | | | | | | Migrate the LED code out of if_ath.c and into if_ath_led.c. These routines are _all_ software based LED blinking. Notes: svn path=/head/; revision=228887
* Do a quick style(9) pass of some of the code introduced with 802.11nAdrian Chadd2011-12-261-12/+17
| | | | | | | support. Notes: svn path=/head/; revision=228886
* Rework this ugly mess that tries to handle reset serialisation.Adrian Chadd2011-12-231-9/+70
| | | | | | | | | | | | | | | | | | | | | | | Some users were reporting concurrent resets _were_ occuring - ie, either two ath_reset()s ran at the same time (likely one on each CPU) or ath_reset() versus ath_chan_change(). Instead, this now tries to grab the serialisation semaphore and will pause() for a while if it fails. It will always eventually succeed though and will log an error if it hits the recursion situation. All of this stuff needs to die a horrible death at some point and be replaced with a properly serialising method of programming this stuff (eg using the net80211 taskqueue for all of this stuff.) The trouble is figuring out how to handle the concurrent ioctl() based things without introducing more LORs (which is another reason why I haven't just wrapped all of this stuff in large, long-lived locks, a-la what Linux can get away with.) MFC after: Absolutely, positively never. Notes: svn path=/head/; revision=228832
* Make some more of the 11n specific code conditional.Adrian Chadd2011-12-231-0/+4
| | | | | | | | | This doesn't fix compilation w/out AH_SUPPORT_AR5416 as all of the software aggregation support in if_ath_tx.c and 11n code in if_ath_tx_ht.c touches the 11n specific fields. I'll work on that later. Notes: svn path=/head/; revision=228830
* Add a temporary debugging statement in order to try and identify what'sAdrian Chadd2011-12-231-0/+29
| | | | | | | | | | | | | | | | | | | | | | going on with the occasional garbage rs_antenna field reported by AR9285 users. I've discovered that the 11n NICs only fill out the entire RX status descriptor on the final descriptor in an aggregate. Some of the fields (notably RSSI) are complete nonsense for A-MPDU subframes. This may be another example of this. The driver doesn't currently toss out statistics for non-final aggregate frames. It's likely that this should be done. If any users hit this particular debugging message they should report it immediately to freebsd-wireless@freebsd.org - please ensure you have ATH_DEBUG enabled so it prints out the full receive descriptor. PR: kern/163312 Notes: svn path=/head/; revision=228829
* Fix some net80211 enum nits:Bernhard Schmidt2011-12-171-8/+9
| | | | | | | | | | | | | - ic_vap_create() uses an ieee80211_opmode argument - ieee80211_rate2media() takes an ieee80211_phymode argument - ieee80211_plcp2rate() takes an ieee80211_phytype argument - cast to enum ieee80211_protmode and ieee80211_roamingmode to silence compiler warnings Submitted by: arundel@ Notes: svn path=/head/; revision=228621
* Print out the radio RF version at startup, so I can better see whichAdrian Chadd2011-12-151-0/+2
| | | | | | | | | RF frontend versions people have when they submit problem reports. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=228516
* Re-lock the ath lock after ath_reset() has been called.Adrian Chadd2011-11-231-0/+1
| | | | | | | | | | | | | The calibrate callout is done with the sc lock held. This only showed up when using an older NIC (AR5212) whose radio/phy requires the rfgain adjustment. Pointy-hat-to: adrian Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227872
* Use the correct lock when calling msleep().Adrian Chadd2011-11-211-1/+1
| | | | | | | | | | | | This fixes panics that users have been seeing when operating in station mode, where the interface undergoes a lot more resets then in hostap mode (ie whilst doing channel scanning.) Reported by: arundel, wblock@wonkity.com Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227806
* Fix some whitespace pollution.Adrian Chadd2011-11-211-3/+1
| | | | Notes: svn path=/head/; revision=227804
* Begin breaking apart the receive setup/stop path in preparation for moreAdrian Chadd2011-11-191-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "correct" handling of frames in the RX pending queue during interface transitions. * ath_stoprecv() doesn't blank out the descriptor list - that's what ath_startrecv() does. So, change a comment to reflect that. * ath_stoprecv() does include a large (3ms) delay to let pending DMA complete. However, I'm under the impression that the stopdma hal method does check for a bit in the PCU to indicate DMA has stopped. So, to help with fast abort and restart, modify ath_stoprecv() to take a flag which indicates whether this is needed. * Modify the uses of ath_stoprecv() to pass in a flag to support the existing behaviour (ie, do the delay.) * Remove some duplicate PCU teardown code (which wasn't shutting down DMA, so it wasn't entirely correct..) and replace it with a call to ath_stoprecv(sc, 0) - which disables the DELAY call. The upshoot of this is now channel change doesn't simply drop completed frames on the floor, but instead it cleanly handles those frames. It still discards pending TX frames in the software and hardware queues as there's no (current) logic which forcibly recalculates the rate control information (or whether they're appropriate to be on the TX queue after a channel change), that'll come later. This still doesn't stop all the sources of queue stalls but it does tidy up some of the code duplication. To be complete, queue stalls now occur during normal behaviour - they only occur after some kind of broken behaviour causes an interface or node flush, upsetting the TX/RX BAW. Subsequent commits will incrementally fix these and other related issues. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227740
* Flesh out some slightly dirty reset/channel change serialisation codeAdrian Chadd2011-11-181-27/+323
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for the ath(4) driver. Currently, there's nothing stopping reset, channel change and general TX/RX from overlapping with each other. This wasn't a big deal with pre-11n traffic as it just results in some dropped frames. It's possible this may have also caused some inconsistencies and badly-setup hardware. Since locks can't be held across all of this (the Linux solution) due to LORs with the network stack locks, some state counter variables are used to track what parts of the code the driver is currently in. When the hardware is being reset, it disables the taskqueue and waits for pending interrupts, tx, rx and tx completion before it begins the reset or channel change. TX and RX both abort if called during an active reset or channel change. Finally, the reset path now doesn't flush frames if ATH_RESET_NOLOSS is set. Instead, completed TX and RX frames are passed back up to net80211 before the reset occurs. This is not without problems: * Raw frame xmit are just dropped, rather than placed on a queue. The net80211 stack should be the one which queues these frames rather than the driver. * It's all very messy. It'd be better if these hardware operations were serialised on some kind of work queue, rather than hoping they can be run in parallel. * The taskqueue block/unblock may occur in parallel with the newstate() function - which shuts down the taskqueue and restarts it once the new state is known. It's likely these operations should be refcounted so the taskqueue is restored once no other areas in the code wish to suspend operations. * .. interrupt disable/enable should likely be refcounted as well. With this work, the driver does not drop frames during stuck beacon or fatal errors and thus 11n traffic continues to run correctly. Default and full resets however do still drop frames and it's possible this may occur, causing traffic loss and session stalls. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227651
* Introduce a work-around for issues with the AR5416 based MAC on SMP devices.Adrian Chadd2011-11-091-0/+12
| | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=227410
* Fix the KTR option to compile by default - it was referencingAdrian Chadd2011-11-081-0/+2
| | | | | | | | | | | | | | | | | | | some unmerged interrupt status debugging code from my branch. * Add ah_intrstate[8] which will have the record of the last call to ath_hal_getintr(). * Wrap the KTR code behind ATH_KTR_INTR_DEBUG. * Add the HAL interrupt debugging behind AH_INTERRUPT_DEBUGGING. This is only done for the AR5416 and later NICs but it will be trivial to add to the earlier NICs if required. Neither are enabled by default, although to minimise HAL binary API differences, the ah_intrstate[] array is always compiled into the ath_hal struct. Notes: svn path=/head/; revision=227365
* Introduce TX aggregation and software TX queue managementAdrian Chadd2011-11-081-1/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for Atheros AR5416 and later wireless devices. This is a very large commit - the complete history can be found in the user/adrian/if_ath_tx branch. Legacy (ie, pre-AR5416) devices also use the per-software TXQ support and (in theory) can support non-aggregation ADDBA sessions. However, the net80211 stack doesn't currently support this. In summary: TX path: * queued frames normally go onto a per-TID, per-node queue * some special frames (eg ADDBA control frames) are thrown directly onto the relevant hardware queue so they can go out before any software queued frames are queued. * Add methods to create, suspend, resume and tear down an aggregation session. * Add in software retransmission of both normal and aggregate frames. * Add in completion handling of aggregate frames, including parsing the block ack bitmap provided by the hardware. * Write an aggregation function which can assemble frames into an aggregate based on the selected rate control and channel configuration. * The per-TID queues are locked based on their target hardware TX queue. This matches what ath9k/atheros does, and thus simplified porting over some of the aggregation logic. * When doing TX aggregation, stick the sequence number allocation in the TX path rather than net80211 TX path, and protect it by the TXQ lock. Rate control: * Delay rate control selection until the frame is about to be queued to the hardware, so retried frames can have their rate control choices changed. Frames with a static rate control selection have that applied before each TX, just to simplify the TX path (ie, not have "static" and "dynamic" rate control special cased.) * Teach ath_rate_sample about aggregates - both completion and errors. * Add an EWMA for tracking what the current "good" MCS rate is based on failure rates. Misc: * Introduce a bunch of dirty hacks and workarounds so TID mapping and net80211 frame inspection can be kept out of the net80211 layer. Because of the way this code works (and it's from Atheros and Linux ath9k), there is a consistent, 1:1 mapping between TID and AC. So we need to ensure that frames going to a specific TID will _always_ end up on the right AC, and vice versa, or the completion/locking will simply get very confused. I plan on addressing this mess in the future. Known issues: * There is no BAR frame transmission just yet. A whole lot of tidying up needs to occur before BAR frame TX can occur in the "correct" place - ie, once the TID TX queue has been drained. * Interface reset/purge/etc results in frames in the TX and RX queues being removed. This creates holes in the sequence numbers being assigned and the TX/RX AMPDU code (on either side) just hangs. * There's no filtered frame support at the present moment, so stations going into power saving mode will simply have a number of frames dropped - likely resulting in a traffic "hang". * Raw frame TX is going to just not function with 11n aggregation. Likely this needs to be modified to always override the sequence number if the frame is going into an aggregation session. However, general raw frame injection currently doesn't work in general in net80211, so let's just ignore this for now until this is sorted out. * HT protection is just not implemented and won't be until the above is sorted out. In addition, the AR5416 has issues RTS protecting large aggregates (anything >8k), so the work around needs to be ported and tested. Thus, this will be put on hold until the above work is complete. * The rate control module 'sample' is the only currently supported module; onoe/amrr haven't been tested and have likely bit rotted a little. I'll follow up with some commits to make them work again for non-11n rates, but they won't be updated to handle 11n and aggregation. If someone wishes to do so then they're welcome to send along patches. * .. and "sample" doesn't really do a good job of 11n TX. Specifically, the metrics used (packet TX time and failure/success rates) isn't as useful for 11n. It's likely that it should be extended to take into account the aggregate throughput possible and then choose a rate which maximises that. Ie, it may be acceptable for a higher MCS rate with a higher failure to be used if it gives a more acceptable throughput/latency then a lower MCS rate @ a lower error rate. Again, patches will be gratefully accepted. Because of this, ATH_ENABLE_11N is still not enabled by default. Sponsored by: Hobnob, Inc. Obtained from: Linux, Atheros Notes: svn path=/head/; revision=227364
* Make sure TXEOL is set on default queues. Otherwise we don't get anAdrian Chadd2011-11-081-0/+1
| | | | | | | | | | interrupt on the completion of a TX queue and this can cause TX hangs / timeout. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227362
* Refactor out the TX buffer management and completion code inAdrian Chadd2011-11-081-102/+229
| | | | | | | | | | | | | | | | | | | | | preparation for TX aggregation. * Add in logic which calls ath_buf bf->bf_comp if it's set. This allows for AMPDU (and RIFS, and FF, if someone desires) code to handle completion - which includes freeing subframes, retransmitting subframes, etc. * Break out the buffer free, buffer busy/unbusy default completion handler code into separate functions. This allows bf_comp methods to free and unbusy each subframe ath_buf as required. * Break out the statistics update code into a separate function, just to clean up the TX completion path a little. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227361
* Change the descriptor logic to use bf_lastds to point to the lastAdrian Chadd2011-11-081-6/+18
| | | | | | | | | | | | | descriptor, rather than using the maths involving bf_desc[bf_nseg - 1]. When doing TX aggregation, the status will be updated in the -final- descriptor of the -final- subframe in an aggregate. Thus bf_lastds may point to the last descriptor in a completely different ath_buf. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227360
* Change ath_buf allocation to:Adrian Chadd2011-11-081-0/+71
| | | | | | | | | | | | | * Immediately return NULL if a buffer isn't available; * Track the "buffers not available" count; * Clear some fields used for tx aggregation; * Add ath_buf_clone() which clones the majority of buffer state. This is needed when retransmission of a "busy" buffer is required. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227359
* Break out the TX DMA stop code into a separate function.Adrian Chadd2011-11-081-6/+23
| | | | | | | Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227358
* Add a 'vap' to ath_keyset().Adrian Chadd2011-11-081-1/+1
| | | | | | | | | | | | | Add some code (which is currently disabled) which modifies the group multicast key cache behaviour. I haven't yet figured out what the exact/correct behaviour is so I'm leaving it disabled. It's worth investigating and "correcting", especially for future work with mesh/ibss and encryption. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227357
* Some more various fixes, etc from my 11n branch.Adrian Chadd2011-11-081-1/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * When doing software TX queue handling and flush, it's possible that the deletion of a VAP (eg a STA shutdown) will queue a "STA Disassociate" frame whilst the interface is being deleted. The VAP is then deleted, and the frame ends up being queued to a node that is freed before it can be TX'ed. Things go awry at this point. There's no way at the present to avoid freeing the underlying node when the vap is being deleted. It's too late in the game. I suspect the real fix is to make sure the frame is software queued with no completion information somehow, so it doesn't link back to a node whose underlying VAP has been freed. For now, we'll just have to do this. * Add some comments showing what's going on. * Move an instance of the ATH_LOCK() around to protect the interrupt set. I'll worry about changing that to a PCU lock later on once the 11n code is in the tree. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227356
* Add KTR tracepoints to the ath driver, in order to debug TX, RXAdrian Chadd2011-11-081-1/+23
| | | | | | | | | and interrupt handling. Sponsored by: Hobnob, Inc. Notes: svn path=/head/; revision=227354
* In preparation for supporting 11n TX/RX properly, allow for TX queue drainingAdrian Chadd2011-11-081-13/+15
| | | | | | | | | | | | | | | | | | | | | | | 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. Notes: svn path=/head/; revision=227353
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-17 02:27:50 +0000