TX ring according to what the firmware requires.
The firmware requires A-MPDU sub-frames to be at a very specific ring
offset - that is, the ring slot offset should be (seqno % 256.)
This holds for every NIC I've tested thus far except the 4965,
which starts erroring out here shortly before the firmware panics.
Which is good, it's doing what it's supposed to (read: capture that
we've screwed up somewhere.)
The specifics about getting this stuff right:
* the initial seqno allocation should match up with the ringid.
* .. yes, this means we can start at a ring offset that isn't zero.
* .. because we program the start seqno in the firmware message
to setup the AC.
* The initial seqno allocation may be non-zero _and_ frames may be
being transmitted during a-mpdu negotiation. I faced similar
issues on ath(4) and had to software queue frames to that node+TID
during A-MPDU negotiation.
* seqno allocation should be in lockstep with ring increments.
* If we fail to transmit some segment, no, we shouldn't reuse that
ring slot. We should just transmit a BAR (which we aren't yet
doing, sigh) and move onto the next seqno.
* In theory there shouldn't be any holes in the seqno space when
we are transmitting frames.
Tested:
* 4965 (throws problems, so yes we have to fix this);
* 5100 (seems ok);
* 6200 (seems ok);
* 2200 (seems ok);
* 2230 (seems ok).
This field needs to be (a) set, and (b) greater than the other timeouts
(passive, active, maxquiet, etc.) It also is in microseconds, not
milliseconds.
I hope this will fix the scan hangs that people are seeing.
Obtained from: Linux iwlwifi
The previous code simply hard-coded IWN_ANT_AB which is only correct for
some of the NICs.
Now, if the NIC is a 1-stream TX, you need to set IWN_ANT_AB and _not_
just a single antenna. The Intel 5100 firmware panics the moment the
link quality table is updated.
So!
* no secondary antenna? Set it to IWN_ANT_AB;
* two-stream device? Transmit on the full transmit antenna configuration.
Tested:
* Intel 5100, STA
* Intel 2200 (eadler)
Obtained from: Linux iwlwifi
support.
* Extend the hardware base_params structure to include a bunch of hardware
flags indicating what is and isn't supported.
* Convert a bunch of the initial hardware configuration conditionals to
consult the base_params structure.
* Add new calibration code for temperature calibration for the Centrino 2xxx
series NICs.
* Add new bluetooth coexistence code for Centrino 2xxx series NICs.
* For NICs that support PAN (personal area networking), use a different
transmit queue and command queue setup, in preparation for said
PAN support.
* Extend the calibration array in iwn_softc to include enough space for
the new calibration types.
Tested (by myself, if not mentioned):
* Intel 4965
* Intel 5100
* Intel 6150
* Intel 2230
* Intel 2200 (eadler)
* Intel 1030
* Intel 6200
* Intel 6230
* Intel 6250
* Intel 6150
* Intel 100
What doesn't work:
* Intel 6235 - fails in calibration at startup
TODO:
* Testing on Intel 53xx series hardware
Submitted by: Cedric Gross <cg@cgross.info>
This is a terrible solution that at least behaves mostly correctly.
It walks the currently active rate table looking for rates to match.
It assumes that the code matches the setup path in the link quality
setup code (much like the previous, much simpler but even more hackish
math did.)
It's O(n), but n<15, so we're okay for the time being.
Tested:
* Intel 5100, STA - 11a, 11n, 11bg modes.
(which is a 1x2 device) panics the firmware.
But, for some 6xxx devices that require IWN_ANT_BC for the TX chainmask,
the link quality entries need to represent _that_.
So, revert this for now until I can figure out what is supposed to be
going on.
NIC and pushed up to the driver. Unfortunately this means there's
no rate control notification done. Thus, if the rate control code
makes a decision that hits a crappy rate that can't succeed, the
rate code would never lower the rate and packet loss would continue.
So, fake some rate control notification in this case.
Without this, a far away station with low signal strength would
associate using the management rate (by default the lowest rate)
and then the EAPOL frames would go out at the current AMRR best
guess. This would result in association failing authentication.
Tested:
* Intel 5100, STA
* Intel 2230, STA
the rate is 11n, rather than whether the channel is 11n.
This correctly allows the PLCP lookup code to return the legacy rates
even on an 11n channel.
PR: kern/183430
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.
Some firmware versions seem to get very unhappy if they're sent btcoex
commands when they don't actually have bluetooth hardware in them.
So, disable sending them those commands.
Tested:
* 5100 (which has bluetooth, no problems)
* 4965 (which doesn't have bluetooth, but didn't seem to crash)
* 6200 (no bluetooth, seems to get unhappy being sent bluetooth commands.)
index lookups.
* My recent(ish) change to iwn(4) and the net80211 rate control API to
support 11n rates broke the link quality table use. So, until I or
someone else decides to fix it, let's just disable it for now.
* Teach iwn_tx_data_raw() to use the iwn_rate_to_plcp() function.
* Eliminate two uses of the net80211 rate index lookup functions - they
are only for legacy rates and they're not needed here.
This fixes some invalid looking rate control TX issues that showed up
on my 4965 but it doesn't fix the two TX hangs I've noticed. Those look
like DMA related issues.
Tested:
* 4965, STA mode
* 5100, STA mode
command register. The lazy BAR allocation code in FreeBSD sometimes
disables this bit when it detects a range conflict, and will re-enable
it on demand when a driver allocates the BAR. Thus, the bit is no longer
a reliable indication of capability, and should not be checked. This
results in the elimination of a lot of code from drivers, and also gives
the opportunity to simplify a lot of drivers to use a helper API to set
the busmaster enable bit.
This changes fixes some recent reports of disk controllers and their
associated drives/enclosures disappearing during boot.
Submitted by: jhb
Reviewed by: jfv, marius, achadd, achim
MFC after: 1 day
* Break out the single, static RX context into a pointer, and ..
* .. extend it to two RX contexts - a default and a PAN context.
Whilst here, add a few extra fields in preparation for further iwn(4)
work.
Tested:
* Intel 4965, STA mode - same level of stability
* Intel 5100, STA mode - no change
Submitted by: Cedric Gross <cg@gross.info>
I haven't yet reviewed the Intel driver(s) in more depth to see if
there are 1x1 NICs that report they support 2 transmit/receive chains..
if so then we'll have to update this.
Tested:
* Intel 4965, which is a 2x2 device with 3 RX and 2 TX chains.
PR: kern/181132
IDs for new devices.
* Add new device IDs
* Extend the ID probe code to include the newer range of bits used
by later model devices
Tested:
* Intel 5100, STA mode
TODO:
* Test on Intel 4965, just to be sure
Submitted by: Cedric GROSS <cg@gross.info>
* Add in some new register debugging under IWN_DEBUG_REGISTER
* Make IWN_DEBUG an option now for building. I'll chase this up
with a commit to 'options' soon.
Submitted by: Cedric GROSS <cg@cgross.info>
* Add 802.11n 2ghz and 5ghz tables, including legacy rates and up to
MCS23 rates (3x3.)
* Populate the rate code -> rate index lookup table with MCS _and_
normal rates, but _not_ the basic rate flag. Since the basic rate flag
is the same as the MCS flag, we can only use one.
* Introduce some accessor inlines that do PLCP and rate table lookup/access
and enforce that it doesn't set the basic rate bit. They're not
designed for MCS rates, so it will panic.
* Start converting drivers that use the rate table stuff to use the
accessor inlines and strip the basic flag.
* Teach AMRR about basic 11n - it's still as crap for MCS as it is
being used by iwn, so it's not a step _backwardS_.
* Convert iwn over to accept 11n MCS rates rather than 'translate' legacy
to MCS rates. It doesn't use a lookup table any longer; instead it's a
function which takes the current node (for HT parameters) and the
rate code, and returns the hardware PLCP code to use.
Tested:
* ath - it's a no-op, and it works that way
* iwn - both 11n and non-11n
It's not enabled by default in net80211 so this is a no-op unless
if you enable it (ifconfig wlan0 powersave).
Tested:
* iwn0: <Intel WiFi Link 5100> mem 0xf4300000-0xf4301fff irq 17 at device 0.0 on pci3
TODO:
* .. test on all the other NICs
* See if I have to disable it during scan and such
* Make it configurable live, rather than only after it's done its initial
receive calibration.
queue is empty or the firmware will go nuts.
PR: kern/167806
Tested by: osa@, Brandon Gooch (earlier version),
Bojan Petrovic (earlier version)
MFC after: 3 days
the TX queue is empty, there won't be a TX done notification, effectly
resulting in an mbuf leak. The correct way to handle this is to free
up mbufs on both BA and TX done notifications up to the last sent seqno.
Tested by: osa@
MFC after: 3 days
