in preparation for the scan based retune logic.
The linux iwlwifi driver does a rescan (onto a non-active channel)
to force an RF retune when the PLCP error rates exceed a certain threshold.
* Add code to track HT PLCP rate errors;
* Separate out the PLCP error count fetch and update so the delta
can be used when checking for PLCP error rates;
* Implement the PLCP error logic from iwlwifi;
* For now, just print out whenever the error rate exceeds the
threshold.
The actual scan based retune will take a bit more effort; the scan
command code right now assumes that a scan state is passed in.
This does need to change to be more flexible (both for this and
in preparation for scanning multiple channels at once.)
Tested:
* 5100 (STA mode)
* 2200 (STA mode)
* 2230 (STA mode)
working on some RF tuning issues.
The linux iwlwifi driver has these thresholds which they use to see
if there are PLCP errors over a certain interval. If they hit this,
they trigger a single-channel (different from active channels!)
scan to retune the RF front-end.
for these chipsets.
* Correctly set the active/passive flag in the scan request - this is
NOT a "is the channel active|passive"; it's to do with whether we
have an SSID to actively scan for or not. The firmware takes care
of the active/passive setup of the channel.
* Calculate the active/passive dwell time based on the beacon interval
and the channel mode, rather than using a hard coded value.
* For now, hardcode the scan service_time. It's defined as:
31:22 - number of beacon intervals to come back onto the home channel
for;
0:21 - time (microseconds) to come back onto the home channel for.
When doing an active scan when the NIC is active (whether we're associated
or not - it only matters if we've setup the NIC to a destination or not)
this determines how much time to stay on the home channel for when
scanning. We can tune this based on the amount of active traffic.
For now it's 4 beacon intervals and 100 microseconds.
* Fix the "good crc threshold" setting. It differs based on the NIC
firmware. Some older firmware required a workaround; the later
firmware instead treats the field as a flag.
* Enforce that we are not sending a scan command if one is already
pending. Any time this is done is a bug and it absolutely needs
to be fixed - so be very loud.
* Add the SCAN flag to a few debug messages that are scan related but
only occuring under STATE.
Now, this does get noisy when you're scanning in an actively busy 2GHz
network as the firmware (for reason I don't quite yet understand) seems
hell bent on staying on some passive channels longer than it should.
However, it should eventually recover and complete the scan.
This is a work in progress; please let me know if things get stuck or
if things improve!
Tested:
* intel centrino 2200
* intel centrino 2230
* intel 6200
* intel 5100
* intel 4965 (gets upset, but that's a known issue)
Obtained from: linux iwlwifi
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).
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
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
This is a no-op for now!
* Add a new flag value for "there are no extra bits" for some random
field;
* Add a definition for the maximum number of calibration entries in
the calibration data cache in iwn_softc. It's not yet used.
* Add regulatory bands for the 2030 NIC.
Submitted by: Cedric Gross <cg@cgross.info>
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.
This is "STA invalid". I saw it during some 4965 testing (kern/183260)
and I still have no idea what is causing it.
Obtained from: Linux drivers/net/wireless/iwlegacy
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
appropriate state handling takes place, not doing so results in the
device doing nothing until manual intervention.
Reviewed by: iwasaki
Tested by: iwasaki (iwi)
MFC after: 4 weeks
cleared/dropped leading to qid2tap[n] being NULL as there no longer
is a tap. Now, if there have been lots of frames queued the firmware
processes and returns those after the tap is gone.
Tested by: osa
MFC after: 1 week
passed over to the runtime firmware on 6050 devices. Instead let
the runtime firmware do the calibration itself. This fixes support
for the 6050 series devices.
Obtained from: OpenBSD
Submitted by: kevlo
Tested by: lx, Tz-Huan Huang(earlier version)
where the driver assumed that BA resources are still available due to
net80211 saying so.
PR: 161407, 159768
Tested by: cperciva, rene
MFC after: 3 days
probe requests at 1Mbps while being associated on a 5GHz channel. Sending
those at 6Mbps does work, so use that instead during a background scan.
This workaround allows us to re-enable background scan support for the
4965 adapters.
Also, just enabling one antenna on 5GHz results in better reception of
beacons:
test 00:26:5a:c6:14:1a 40 54M -71:-95 200 E WME HTCAP ATH
vs
test 00:26:5a:c6:14:1a 40 54M -92:-95 200 E WME HTCAP ATH
Due to roam:rssi thresholds set to 7 by default it might have been
impossible to associate to that network. While here use
IEEE80211_IS_CHAN_5GHZ() to determine the band.
The version is used to check if a module is already preset, not setting
it results in:
can't re-use a leaf (ipw)!
module_register: module pci/ipw already exists!
Module pci/ipw failed to register: 17
while trying to load the module due to an entry in loader.conf. With this
commit we get the expected:
module ipw already present!
Reported by: Dru Lavigne, bz
Tested by: bz
MFC after: 1 week
The other queues, especially the command queue, uses the FIFO mode
which doesn't require the byte count table because queued entries are
processed in order.
Pointed out by: Lucius Windschuh <lwindschuh at googlemail dot com>
- instead of calling iwn_plcp_signal() for every frame, map the expected
value directly within wn->ridx
- concat plcp, rflags and xrflags, there is no clean byte boundary within
the flags, for example the antenna setting uses bit 6, 7 and 8
- there is still need for a custom rate to plcp mapping, as those expected
by the hardware are not conform to the std
On legacy channels every once in a while the firmware throws a SYSASSERT
on line 208. On HT channels though this does always happen and I'm not
aware of any workaround currently.
- If a ENH_SENS TLV section exit the firmware is capable of doing
enhanced sensitivity calibration.
- Newer devices/firmwares have more calibration commands therefore
hardcoding the noise gain/reset commands no longer works. It is
supposed to use the next index after the newest calibration type
support. Read the command index of the TLV section if available.
- 6000 series devices need enhanced sensitivity calibration.
- 6000 series devices need a different setting for the shadow reg.
- set the IWN_FLAG_HAS_11N bit if the EEPROM says the device has 11n
support.
Obtained from: OpenBSD
- read RSSI only for the active chains
- cast RSSI/NF to int8_t before passing it up to radiotap
- remove the htole64() for the timestamp
Obtained from: OpenBSD
- there is a local variable for sc->fw_dma, use that instead
- OpenBSD uses 5*hz to wait for firmware to be loaded
- in case the firmware module contains invalid data, actually release it
from scratch. Remove htole16() calls, rxon.chan is an uint8_t,
ieee80211_chan2ieee() does return an ic_ieee as an int, but I heavily
doubt a htole16() will buy us anything here.
- IWN_TXOP_TO_US is equal to IEEE80211_TXOP_TO_US
- use IEEE80211_DUR_TU
- ieee80211_add_rates/ieee80211_add_xrates are public, use em
- copied ieee80211_add_ssid it is not public
This fixes hostap mode for at least ral(4) and run(4), because there is
no sufficient call into drivers which could be used initialize the node
related ratectl variables.
MFC after: 3 days
- Do not call iwn_calib_reset() for monitor mode. We do not want to query
information and do runtime calibration while in monitor mode. Poking the
firmware with adjustments for calibration results in firmware asserts.
This could happened on RUN -> RUN transition only.
- Adjust blink rate for monitor mode. It's supposed to not freak out and
turn off after a while.
- While here, remove one useless assignment of calib.state, it gets
overwritten later in the function.
Submitted by: Brandon Gooch <jamesbrandongooch at gmail.com>
MFC after: 1 week
longer requested of the boot firmware. Instead of sending those results
to the runtime firmware the firmware is told to do the DC calibration
itself.
MFC after: 1 week
the IEEE80211_C_RATECTL flag set, default to NONE for all drivers. Only if
a driver calls ieee80211_ratectl_init() check if the NONE algo is still
selected and try to use AMRR in that case. Drivers are still free to use
any other algo by calling ieee80211_ratectl_set() prior to the
ieee80211_ratectl_init() call.
After this change it is now safe to assume that a ratectl algo is always
available and selected, which renders the IEEE80211_C_RATECTL flag pretty
much useless. Therefore revert r211314 and 211546.
Reviewed by: rpaulo
MFC after: 2 weeks
the device:
- unobscure some of the code by moving it into its own functions
- get rid of some magic numbers
- create similar structure as the reference driver has, this should
make further syncs easier
