- this also includes virtualization support on these devices
Correct some vlan issues we were seeing in test, jumbo frames on vlans
did not work correctly, this was all due to confused logic around HW
filters, the new code should now work for all uses.
Important fix: when mbuf resources are depeleted, it was possible to
completely empty the RX ring, and then the RX engine would stall
forever. This is fixed by a flag being set whenever the refresh code
fails due to an mbuf shortage, also the local timer now makes sure
that all queues get an interrupt when it runs, the interrupt code
will then always call rxeof, and in that routine the first thing done
is now to check the refresh flag and call refresh_mbufs. This has been
verified to fix this type 'hang'. Similar code will follow in the other
drivers.
Finally, sync up shared code for the I350 support.
Thanks to everyone that has been reporting issues, and helping in the
debug/test process!!
Drivers which rely on net80211 to create the beacon need to call
ieee80211_beacon_update() on iv_update_beacon() calls. This is required
that certain bits, e.g. TIM, get updated. A call to ieee80211_beacon_alloc()
is not enough because it does not care about flags which can only change
during runtime. By design a beacon is supposed to be allocated only once
while moving into RUN state.
To handle all possible calls to iv_update_beacon() the run_updateslot()
function has been revived and run_updateprot() has been added.
run_updateslot() handles slot time changes and run_updateprot() changes
to protection, both can change while nodes associate/leave.
Submitted by: Alexander Zagrebin <alex at zagrebin.ru>,
PseudoCylon <moonlightakkiy atyahoo.ca>
MFC after: 3 weeks
There's still a lot of random issues to sort out with the radio side of
things and AMPDU RX handling (and completely missing AMPDU TX handling!)
but if people wish to give this a go and assist in debugging the
issues, they can define ATH_DO_11N to enable it.
I'm just re-iterating - this is here to allow people to assist in
further 11n development; it is not any indication that the 11n support
is complete and functional.
Important notes:
* This doesn't support 1-stream cards yet - (eg AR9285) - the various bits
that negotiate TX/RX MCS don't know not to try >1 stream TX or negotiate
1-stream RX; so don't enable 11n unless you've first taught the rate
control module and the net80211 stack to negotiate 1-stream stuff;
* The only rate control module minimally 11n aware is ath_rate_sample;
* ath_rate_sample doesn't know about HT/40; so airtime will be incorrectly
calculated;
* The AR9160 and AR9280 radio code is unreliable at the higher MCS rates for
some reason; this will definitely impact 11n performance;
* AMPDU-TX isn't yet implemented;
* AMPDU-RX may be a bit buggy still and will definitely suffer from the
radio unreliability mentioned above (ie, don't expect 150/300mbit
RX just yet.)
The correct bit to set is 0x1 in the high MAC address byte, not 0x80.
The hardware isn't programmed with that bit (which is the multicast
adress bit.)
The linux ath9k keycache code uses that bit in the MAC as a "this is
a multicast key!" and doesn't set the AR_KEYTABLE_VALID bit.
This tells the hardware the MAC isn't to be used for unicast destination
matching but it can be used for multicast bssid traffic.
This fixes some encryption problems in station mode.
PR: kern/154598
- use device_printf() instead of printf() to give more accurate warnings.
- use memcpy() instead of bcopy().
- add missing #if's for non-FreeBSD compilation.
Approved by: thompsa (mentor)
error address on a decoding error to unlatch it and to allow
us to print a better diagnostics message. This also has the
side effect of clearing the condition, which prevents an
interrupt storm.
Revert back to the previous method of doing it for where a node can be
identified and it's an 11n node.
I'll have to do some further research into exactly what is being messed up
with the sequence number matching and I'll then revisit this.
This doesn't yet take into account HT40 packet durations as the node info
(needed to know if it's a HT20 or HT40 node) isn't available everywhere
it needs to be.
putting descriptors (not buffers) across a 4k page boundary can cause issues.
I've not seen it in production myself but it apparently can cause problems.
So, in preparation for addressing this workaround, (re)-expose the particular
HAL capability bit which marks whether the chipset has support for cross-4k-
boundary transactions or not.
A subsequent commit will modify the descriptor allocation to avoid allocating
descriptor entries that straddle a 4k page boundary.
- entirely eliminate some calls to uio_yeild() as being unnecessary,
such as in a sysctl handler.
- move should_yield() and maybe_yield() to kern_synch.c and move the
prototypes from sys/uio.h to sys/proc.h
- add a slightly more generic kern_yield() that can replace the
functionality of uio_yield().
- replace source uses of uio_yield() with the functional equivalent,
or in some cases do not change the thread priority when switching.
- fix a logic inversion bug in vlrureclaim(), pointed out by bde@.
- instead of using the per-cpu last switched ticks, use a per thread
variable for should_yield(). With PREEMPTION, the only reasonable
use of this is to determine if a lock has been held a long time and
relinquish it. Without PREEMPTION, this is essentially the same as
the per-cpu variable.
* The existing radio config code was for the AR5416/AR9160 and missed out
on some of the AR9280 specific stuff. Include said stuff from ath9k.
* Refactor out the gain control settings into a new function, again pilfered
from ath9k.
* Use the analog register RMW macro when touching analog registers.
Obtained from: Linux ath9k
This fixes two problems -
* All packets need to be processed here, not just aggregate ones - as any
received frames (AMPDU or otherwise) in the given TID (traffic class id)
will update the sequence number and, implied with that, update the window;
* It seems there's situations where packets aren't matching a current node but
somehow need to be tracked. Thus just tag them all for now; I'll figure out
the why later.
Whilst I'm here, bump the stats counters whilst I'm at it.
This fixes AMPDU RX in my tests; the main problems now stem from what look
like PHY level error/retransmits which are impeding general throughput, incl.
AMPDU.
TX chainmask.
since the upper layers don't (yet) know about the active TX/RX chainmasks,
it can't tell the rate scenario functions what to use. I'll eventually sort
this out; this restores functionality in the meantime.
controller in question generates frames with bad IP checksum value
if packets contain IP options. For instance, packets generated by
ping(8) with record route option have wrong IP checksum value. The
controller correctly computes checksum for normal TCP/UDP packets
though.
There are two known RTL8168/8111C variants in market and the issue
I observed happened on RL_HWREV_8168C_SPIN2. I'm not sure
RL_HWREV_8168C also has the same issue but it would be better to
assume it has the same issue since they shall share same core.
RTL8102E which is supposed to be released at the time of
RTL8168/8111C announcement does not have the issue.
Tested by: Konstantin V. Krotov ( kkv <> insysnet dot ru )
This isn't strictly required to TX (at least non-agg and non-HT40,
non-short-GI) frames; but as it needs to be done anyway, just get
it done.
Linux ath9k uses the rate scenario style path for -all- packets,
legacy or otherwise. This code does much the same.
Beacon TX still uses the legacy, non-rate-scenario TX descriptor
setup. Ath9k also does this.
This 11n rate scenario path is only called for chips in the AR5416
HAL; legacy chips use the previous interface for TX'ing.
A-MPDU RX interferes with packet retransmission/reordering.
In local testing, I was seeing A-MPDU being negotiated and then
not used by the AP sending frames to the STA; the STA would then
treat non A-MPDU frames that are retransmits as out of the window
and get plain confused.
The hardware RX status descriptor has a "I'm part of an aggregate"
bit; so this should eventually be tested and then punted to the
A-MPDU reorder handling only if it has this bit set.
make use of the aac_ioctl_event callback, if aac_alloc_command fails. This
can end up in an infinite loop in the while loop in aac_release_command.
Further investigation into the issue mentioned by Scott Long [1] will be
necessary.
[1] http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078740.html
The AR5416 and later TX descriptors have new fields for supporting
11n bits (eg 20/40mhz mode, short/long GI) and enabling/disabling
RTS/CTS protection per rate.
These functions will be responsible for initialising the TX descriptors
for the AR5416 and later chips for both HT and legacy frames.
Beacon frames will remain using the non-11n TX descriptor setup for now;
Linux ath9k does much the same.
Note that these functions aren't yet used anywhere; a few more framework
changes are needed before all of the right rate information is available
for TX.
function; which will be later used by the TX path to determine
whether to use the extended features or not.
* Break out the descriptor chaining logic into a separate function;
again so it can be switched out later on for the 11n version when
needed.
* Refactor out the encryption-swizzling code that's common in the
raw and normal TX path.
