start and the number we've started that have not been alloced yet. Currently
sc_txstarted is constained to 0 or 1 because of the way we start the next
packet, but this will change.
* Update sc_txpending[] when a packet is written, even before we issue the TX
command, since it may be active when we issue the TX command for the
following packet.
* Do not lower the rate in ni_txrate or id_rateidx, because these are used to
keep track of sc_txpending[], and could cause us to get "stuck" at the lower
rate.
ieee80211_media_change handles a lot more conditions than
wi_media_change did.
This helps with the second bug mentioned in kern/25604, which causes
"SIOCSIFMEDIA: Invalid argument."
commit. The rate adaptation code expects them. Usually wi gets
lucky, and an Rx/Alloc/Info event triggers the interrupt handler,
but I had not intended for wi to count on it.
Without Tx/TxExc interrupts enabled, wi will sometimes exhaust all
its rssdescs and cease transmitting. Usually it sets IFF_OACTIVE
in that situation.
I have pulled that code into the function ieee80211_rssadapt_choose
so that I can re-use it in ath(4), atw(4), and in other drivers.
In rssadapt(9), I have also created a struct ieee80211_rssadapt_expavgctl
that contains parameters for rate adaptation. When IEEE80211_RSSADAPT_DEBUG
is enabled, I will using sysctl to expose an ieee80211_rssadapt_expavgctl
for each wireless device.
Also in rssadapt(9), I have introduced an interpolate() macro which
makes the exponential-averaging code more compact.
of bounds, then complain and recover by freeing all of the descriptors.
That will usually provoke additional complaints---see the next
paragraph.
If the firmware returns to us an RSS descriptor that is in-bounds
but out of service (id_node == NULL), then gripe and get out of
the interrupt handler. ***This will still leak RSS descriptors.***
I'm working on a better solution. Possibly I will just free all of
the descriptors.
bug report from Simon Burge: the firmware seems to lock up.
If rate-adaptation is disabled on a Lucent card, then do all the
rate-adaptation work *except* for writing the new transmit rate,
since I suspect that is what locks-up the firmware.
APs to run at "full speed" where before they ran at just 1 or 2Mb/s.
The AP will adapt the data rate for each client based on packet
losses and the received signal strength.
I have also enabled rate adaptation for STA mode and for IBSS mode,
but the hardware gives us less control over the data rate in those
modes.
state, so do not update ic->ic_state in wi_newstate() before calling
ieee80211_newstate(). Instead, update ic->ic_state when we do not
let ieee80211_newstate() run.
writes a hardware register when the data rate selection actually
changes. Add wi_cfg_txrate, which writes the data rate selection
regardless.
Name some fields in the wi Tx buffer which we will use for rate
adaptation.
Name the Prism "Alternate Retry Count" RID, WI_RID_ALT_RETRY_COUNT.
mycroft