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>
