Commit Graph

1097 Commits

Author SHA1 Message Date
adrian
3543a6a83d .. And fix another typo. Grr. 2012-07-02 06:07:46 +00:00
adrian
dfec3def9a Fix another typo. 2012-07-02 06:06:27 +00:00
adrian
614d3d6a0e Fix typo. 2012-07-02 06:05:25 +00:00
adrian
7222dd809d Bring over some further HAL capabilities from the Atheros HAL, as well
as an EDMA check function.

For the AR9003 and later NICs, different TX/RX DMA and descriptor handling
code will be conditional on the EDMA check.

Obtained from:	Qualcomm Atheros
2012-07-02 06:02:12 +00:00
adrian
6a3edead78 Add in some further changes from the AR9300 HAL:
* Add a new ANI variable, for AR9003 and later chips;
* The AR9003 and later series chips support two RX queues now, so start
  down the road of supporting that;
* Add some new TX queue types - uAPSD is possible on earlier chips,
  but PAPRD is relevant to AR9003 and later.

Obtained from:	Qualcomm Atheros, Linux ath9k
2012-07-01 05:14:24 +00:00
adrian
4eb10c74bc Migrate the MAC/BB hang structures out from ar5416_misc.h into the HAL.
The ar9300 HAL also uses these types, so it makes no sense to duplicate
them.
2012-07-01 03:15:18 +00:00
adrian
5d4bc9f384 Bring over capabilities for the AR9300 and later HAL. 2012-07-01 02:44:36 +00:00
adrian
4a4fdd3615 Add OS_MEMCMP(). 2012-07-01 02:37:04 +00:00
adrian
b5dff52250 Fix the HAL debugging to only use one bit to mark a message as unmaskable.
Whilst I'm here, remove the duplication of the #define.
2012-07-01 02:34:32 +00:00
adrian
dbdcceb527 Fix a subtle corner case surrounding the handling of OFDM restart along
with AMPDU aggregate delimiters.

If there's an OFDM restart during an aggregate, the hardware ACKs
the previous frame, but communicates the RXed frame to the hardware
as having had CRC delimiter error + OFDM_RESTART phy error.
The frame however didn't have a CRC error and since the hardware ACKed
the aggregate to the sender, it thinks the frame was received.

Since I have no idea how often this occurs in the real world, add a
debug statement so trigger whenever this occurs.  I'd appreciate an
email if someone finds this particular situation is triggered.
2012-06-27 05:23:33 +00:00
adrian
ac80278535 Bring over some new typedefs as part of the AR9300 HAL import. 2012-06-27 03:24:27 +00:00
adrian
5dd028377a Remove duplicate entries. 2012-06-27 03:00:29 +00:00
adrian
f6d1a69477 Bring over the initial 802.11n bluetooth coexistence support code.
The Linux ath9k btcoex code is based off of this code.

Note this doesn't actually implement functional btcoex; there's some
driver glue and a whole lot of verification that is required.

On the other hand, I do have the AR9285+BT and AR9287+BT NICs which
this code supports..

Obtained from:	Qualcomm Atheros, Linux ath9k
2012-06-26 22:16:53 +00:00
adrian
4183957bce Make sure the BAR TX session pause is correctly unpaused when a node
is reassociating.

PR:		kern/169432
2012-06-26 07:56:15 +00:00
adrian
1b86b779b2 In a complete lack of foresight on my part, my previous commit broke
the assumption that ath_softc doesn't change size based on build time
configuration.

I picked up on this because suddenly radar stuff didn't work; and
although the ath_dfs code was setting sc_dodfs=1, the main ath driver
saw sc_dodfs=0.

So for now, include opt_ath.h in driver source files.  This seems like
the sane thing to do anyway.

I'll have to do a pass over the code at some later stage and turn
the radiotap TX/RX structs into malloc'ed memory, rather than in-line
inside of ath_softc.  I'd rather like to keep ath_softc the same
layout regardless of configuration parameters.

Pointy hat to: 	adrian
2012-06-24 08:47:19 +00:00
adrian
b5c3afbe7d Shuffle these initialisations to where they should be. 2012-06-24 08:28:06 +00:00
adrian
c5fe4faa45 Change the ath_dfs_process_phy_err() method to take an mbuf rather than
a buffer pointer.

For large radar pulses, the AR9130 and later will return a series of
FFT results for software processing.  These can overflow a single 2KB
buffer on longer pulses.  This would result in undefined buffer behaviour.
2012-06-24 08:09:06 +00:00
adrian
a5794ac4d0 Introduce an optional ath(4) radiotap vendor extension.
This includes a few new fields in each RXed frame:

* per chain RX RSSI (ctl and ext);
* current RX chainmask;
* EVM information;
* PHY error code;
* basic RX status bits (CRC error, PHY error, etc).

This is primarily to allow me to do some userland PHY error processing
for radar and spectral scan data.  However since EVM and per-chain RSSI
is provided, others may find it useful for a variety of tasks.

The default is to not compile in the radiotap vendor extensions, primarily
because tcpdump doesn't seem to handle the particular vendor extension
layout I'm using, and I'd rather not break existing code out there that
may be (badly) parsing the radiotap data.

Instead, add the option 'ATH_ENABLE_RADIOTAP_VENDOR_EXT' to your kernel
configuration file to enable these options.
2012-06-24 07:01:49 +00:00
adrian
7dbe608f0c On second thought, let's just set both CRC and PHY errors together on
frames that have it and let the upper layer sort it out.

PR:		kern/169362
2012-06-24 06:37:28 +00:00
adrian
926549a58e Sometimes the AR5416 sends back radar PHY errors with both the PHY error
and the CRC error bits set.  The radar payload is correct.

When this happens, the stack doesn't see them PHY error frames and
isn't interpreted as a PHY error.  So, no radar detection and no radiotap
PHY error handling.

Now, this may introduce some weird issues if the MAC sends up some other
combination of CRC error + PHY error frames; this commit would break that
and mark them as PHY errors instead of CRC errors.

I may tinker with this a little more to pass radar/early radar/spectral
frames up as PHY errors if the CRC bit is set, to restore the previous
behaviour (where if CRC is set on a PHY error frame, it's marked as a CRC
error rather than PHY error.)

Tested on:	AR5416, over the air, to a USRP N200 which is generating a
		large number of a variety of radar pulses.
TODO:		Test on AR9130, AR9160, AR9280 (and maybe radar pulses on
		2GHz on AR9285/AR9287.)

PR:		kern/169362
2012-06-24 05:59:32 +00:00
adrian
841450cb6e AR9287 tidyups:
* Add an OS_A_REG_WRITE() routine - analog writes require a 100usec delay
  on AR9280 and later, so create a method to do it.

* Use it for the AR9287 analog writes.

* Re-indent and style(9) the code.
2012-06-17 05:56:27 +00:00
adrian
79176a3c74 Add an disabled workaround for the AR9285SE.
This just requires a little HAL change (add a new config parameter) and
some glue in if_ath_pci.c, however I'm leaving this up for someone else
to do.

Obtained from:	Qualcomm Atheros
2012-06-17 05:34:41 +00:00
adrian
46e1bb44ef Bring over the AR9285 specific PCIe suspend/resume/ASPM workarounds.
Obtained from:	Qualcomm Atheros, Linux ath9k
2012-06-17 04:48:47 +00:00
adrian
656256d25b After some discussion with bschmidt@, it's likely better to just go
through ieee80211_suspend_all() and ieee80211_resume_all().
All the other wireless drivers are doing that particular dance.

PR:		kern/169084
2012-06-17 03:08:33 +00:00
adrian
f4c9781794 .. and this wasn't supposed to be in the previous commit either. 2012-06-16 22:28:36 +00:00
adrian
e781c0c0fc oops, remove this, it wasn't supposed to be committed. 2012-06-16 22:26:45 +00:00
adrian
3762f77b7e A few nitpicks:
* Use ATH_RC_NUM instead of '4' when iterating over the ratecontrol series
  array.

* A few style(9) fixes, hopefully no regressions here.

* Add some comments that better describe what's going on.
2012-06-16 21:37:15 +00:00
kib
df96c54547 Fix build. 2012-06-16 20:49:08 +00:00
adrian
1e66a452fb Shuffle some more fields in ath_buf so it's not too big.
This shaves off 20 bytes - from 288 bytes to 268 bytes.

However, it's still too big.
2012-06-16 04:41:35 +00:00
adrian
971f393620 Shave four (or eight) bytes off of ath_buf - this field isn't used. 2012-06-16 04:36:08 +00:00
adrian
610e0d131b Convert ath(4) to just use ieee80211_suspend_all() and ieee80211_resume_all().
The existing code tries to use the beacon miss timer to signal that the AP
has gone away.  Unfortunately this doesn't seem to be behaving itself.
I'll try to investigate why this is for the sake of completeness.

The result is the STA will stay "associated" to the AP it was associated
with when it suspended.  It never receives a bmiss notification so it
never tries reassociating.

PR:		kern/169084
2012-06-15 01:15:59 +00:00
adrian
a65a9620af Shrink ath_buf a little more:
* Resize some types.  In particular, bfs_seqno can be uint16_t for now.
  Previous work would assign the unassigned seqno a value of -1, which
  I obviously can't do here.

* Remove bfs_pktdur.  It was in the original code but nothing so far uses
  it.

This gets ath_buf down (on my i386 system) to 292 bytes from 300 bytes.
I'd rather it be much, much smaller.
2012-06-14 04:24:13 +00:00
adrian
27ea453afe Disable BGSCAN for 802.11n for now. Until scanning during traffic is
fixed for 802.11n TX, this needs to be disabled or users wlil see randomly
hanging aggregation sessions.

Whilst I'm here, remove the warning about 802.11n being full of dragons.
It's nowhere near that scary now.
2012-06-14 04:14:06 +00:00
adrian
f85277a163 Disable this warning debug for now, as I'm now aware of the particular
situation where it's occuring.

Whilst I'm here, flesh out a more descriptive description.
2012-06-14 04:01:25 +00:00
adrian
a65b3dd589 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
2012-06-14 00:51:53 +00:00
adrian
528dfae9f3 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
2012-06-13 06:57:55 +00:00
adrian
045b5b971c Remove a duplicate definition. 2012-06-13 05:47:24 +00:00
adrian
60c3364556 Oops, return the newly allocated buffer to the queue, not the completed
buffer.

PR:	kern/168170
2012-06-13 05:41:00 +00:00
adrian
0e5e2a4303 Replace the direct sc_txbuf manipulation with a pair of functions.
This is preparation work for having a separate ath_buf queue for
management traffic.

PR:		kern/168170
2012-06-13 05:39:16 +00:00
adrian
1948616051 Fix uninitialised reference.
Noticed by:	John Hay <jhay@meraka.org.za>
2012-06-11 12:26:23 +00:00
adrian
2cecdd81d8 Wrap the whole (software) TX path from ifnet dequeue to software queue
(or direct dispatch) behind the TXQ lock (which, remember, is doubling
as the TID lock too for now.)

This ensures that:

 (a) the sequence number and the CCMP PN allocation is done together;
 (b) overlapping transmit paths don't interleave frames, so we don't
     end up with the original issue that triggered kern/166190.

     Ie, that we don't end up with seqno A, B in thread 1, C, D in
     thread 2, and they being queued to the software queue as "A C D B"
     or similar, leading to the BAW stalls.

This has been tested:

* both STA and AP modes with INVARIANTS and WITNESS;
* TCP and UDP TX;
* both STA->AP and AP->STA.

STA is a Routerstation Pro (single CPU MIPS) and the AP is a dual-core
Centrino.

PR:		kern/166190
2012-06-11 07:44:16 +00:00
adrian
a067a20110 Add another TID lock. 2012-06-11 07:35:24 +00:00
adrian
932f2b787a Make sure the frames are queued to the head of the list, not the tail.
See previous commit.

PR:		kern/166190
2012-06-11 07:31:50 +00:00
adrian
d2da34afea When scheduling frames in an aggregate session, the frames should be
scheduled from the head of the software queue rather than trying to
queue the newly given frame.

This leads to some rather unfortunate out of order (but still valid
as it's inside the BAW) frame TX.

This now:

* Always queues the frame at the end of the software queue;
* Tries to direct dispatch the frame at the head of the software queue,
  to try and fill up the hardware queue.

TODO:

* I should likely try to queue as many frames to the hardware as I can
  at this point, rather than doing one at a time;
* ath_tx_xmit_aggr() may fail and this code assumes that it'll schedule
  the TID.  Otherwise TX may stall.

PR:		kern/166190
2012-06-11 07:29:25 +00:00
adrian
3559a073df Retried frames need to be inserted in the head of the list, not the tail.
This is an unfortunate byproduct of how the routine is used - it's called
with the head frame on the queue, but if the frame is failed, it's inserted
into the tail of the queue.

Because of this, the sequence numbers would get all shuffled around and
the BAW would be bumped past this sequence number, that's now at the
end of the software queue.  Then, whenever it's time for that frame
to be transmitted, it'll be immediately outside of the BAW and TX will
stall until the BAW catches up.

It can also result in all kinds of weird duplicate BAW frames, leading
to hilarious panics.

PR:		kern/166190
2012-06-11 07:15:48 +00:00
adrian
ddabbbd18b Finish undoing the previous commit - this part of the code is no longer
required.

PR:		kern/166190
2012-06-11 07:08:40 +00:00
adrian
97dfa39fc4 Introduce a new lock debug which is specifically for making sure the
_TID_ lock is held.

For now the TID lock is also the TXQ lock. This is just to make sure
that the right TXQ lock is held for the given TID.
2012-06-11 07:06:49 +00:00
adrian
0760025f8f Revert r233227 and followup commits as it breaks CCMP PN replay detection.
This showed up when doing heavy UDP throughput on SMP machines.

The problem with this is because the 802.11 sequence number is being
allocated separately to the CCMP PN replay number (which is assigned
during ieee80211_crypto_encap()).

Under significant throughput (200+ MBps) the TX path would be stressed
enough that frame TX/retry would force sequence number and PN allocation
to be out of order.  So once the frames were reordered via 802.11 seqnos,
the CCMP PN would be far out of order, causing most frames to be discarded
by the receiver.

I've fixed this in some local work by being forced to:

  (a) deal with the issues that lead to the parallel TX causing out of
      order sequence numbers in the first place;
  (b) fix all the packet queuing issues which lead to strange (but mostly
      valid) TX.

I'll begin fixing these in a subsequent commit or five.

PR:		kern/166190
2012-06-11 06:59:28 +00:00
adrian
d958c69a5f Add a new ioctl for ath(4) which returns the aggregate statistics. 2012-06-10 06:42:18 +00:00
adrian
b1336b8d21 Mostly revert previous commit(s). After doing a bunch of local testing,
it turns out that it negatively affects performance.  I'm stil investigating
exactly why deferring the IO causes such negative TCP performance but
doesn't affect UDP preformance.

Leave the ath_tx_kick() change in there however; it's going to be useful
to have that there for if_transmit() work.

PR:		kern/168649
2012-06-05 06:03:55 +00:00