"fatal firmware error" happens. Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".
Approved by: adrian@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
"fatal firmware error" happens. Previously it was neccessary to reset
it manually, using "/etc/rc.d/netif restart".
Approved by: adrian@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Centrino 2230 firmware.
This fixes the general statistics block to be actually valid.
I've verified this by contrasting the output of iwnstats before and
after the change. The general block is now correct.
Tested:
* Intel 5100 (old format stats message)
* Intel 2230 (new format stats message)
It turns out that there's a variant format of the RX statisitcs notification
from the intel firmware. It's even more whacked - the non-BT variant has
bluetooth fields; apparently some later NICs return even _more_ bluetooth
related fields.
I'll commit the statistics structure changes here - it's a no-op for the
driver. I'll later teach the driver code to populate a statistics structure
from the received message after reformatting things correctly.
I don't _think_ it's going to fix anything related to sensitivity programming
as the CCK/OFDM (non-11n) fields are in the same place for both formats.
But the HT structure and the general statistics aren't in the same place.
I'll go find some NIC(s) that spit out the other format and when I find one,
I'll go and update the driver to handle things correctly.
Tested:
* Intel 5100 (which returns the legacy, non-BT format)
Obtained from: Linux iwlwifi
The origin of WEP comes from IEEE Std 802.11-1997 where it defines
whether the frame body of MAC frame has been encrypted using WEP
algorithm or not.
IEEE Std. 802.11-2007 changes WEP to Protected Frame, indicates
whether the frame is protected by a cryptographic encapsulation
algorithm.
Reviewed by: adrian, rpaulo
- Simplify MSI allocation and release. For a single one, we don't need to
fiddle with the MSI count and pci_release_msi(9) is smart enough to just
do nothing in case of INTx.
- Don't allocate MSI as RF_SHAREABLE.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
MFC after: 1 week
This chip doesn't require the temperature sensor offset, either v1 or
v2. Doing so causes the initial calibration test to fail.
Tested:
* Intel Centrino 6150
Make the scan state optional - we'll obviously need a vap, but we now
won't require the scan state. the only thing the scan state is needed
for is to check for the list of SSIDs to scan - which we can now
just plain ignore by passing in NULL as the scan state pointer.
Tested:
* Intel 5100 (STA)
This is in preparation for being able to use iwn_scan() to do an off
channel scan to reset the RF tuning.
It should be a no-op.
Tested:
* Intel 5100 (STA)
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
