as possible when using more than one igb(4) adapter. This
means that queues will not be bound to the same CPUs if
there are more CPUs availble.
This is only applicable to a system that has multiple interfaces.
Obtained from: Yahoo! Inc.
MFC after: 3 days
controller to perform MDIO type accesses to a remote transceiver
using message pages defined through MRBE(multirate backplane
ethernet). It's used in blade systems(e.g Dell Blade m610) which
are connected to pass-through blades rather than traditional
switches.
This change directly manipulates firmware's mailboxes to control
remote PHY such that it does not use mii(4). Alternatively, as
David said, it could be implemented in brgphy(4) by creating a fake
PHY and let brgphy(4) do necessary mii accesses and bce(4) can
implement mailbox accesses based on the type of brgphy(4)'s mii
accesses. Personally, I think it would make brgphy(4) hard to
maintain since it would have to access many bce(4) registers in
brgphy(4). Given that there are users who are suffering from lack
of remote PHY support, it would be better to get working system
rather than waiting for complete/perfect implementation.
Tested by: Jan Winter ( jan.winter <> kantarmedia dot de )
Reviewed by: davidch (initial version)
MFC after: 2 weeks
TX and RX PCU stop/drain routines have been thoroughly debugged.
It's also very likely that I should add hooks back up to the
interface glue (if_ath_pci / if_ath_ahb) to do any relevant
bus flushes that are required. A WMAC DDR flush may be required
for the AR9130 SoC.
result in INQUIRY VPD 0x81 to SATA devices to return only 63 bytes of data
instead of 64 during SCSI/ATA translation.
Sponsored by: Intel
Approved by: scottl
MFC after: 1 week
them to cleanup and goto out when acknowledging the LD's. Check
for failure on malloc. Remove a couple of extra lines and remove
the spurious return.
Prompted by: Petr Lampa
MFC after: 3 days
Use MADT to match ACPI Processor objects to CPUs. MADT and DSDT/SSDTs may
list CPUs in different orders, especially for disabled logical cores. Now
we match ACPI IDs from the MADT with Processor objects, strictly order CPUs
accordingly, and ignore disabled cores. This prevents us from executing
methods for other CPUs, e. g., _PSS for disabled logical core, which may not
exist. Unfortunately, it is known that there are a few systems with buggy
BIOSes that do not have unique ACPI IDs for MADT and Processor objects. To
work around these problems, 'debug.acpi.cpu_unordered' tunable is added.
Set this to a non-zero value to restore the old behavior.
Many thanks to jhb for pointing me to the right direction and the manual
page change.
Reported by: Harris, James R (james dot r dot harris at intel dot com)
Tested by: Harris, James R (james dot r dot harris at intel dot com)
Reviewed by: jhb
MFC after: 1 month
list CPUs in different orders, especially for disabled logical cores. Now
we match ACPI IDs from the MADT with Processor objects, strictly order CPUs
accordingly, and ignore disabled cores. This prevents us from executing
methods for other CPUs, e. g., _PSS for disabled logical core, which may not
exist. Unfortunately, it is known that there are a few systems with buggy
BIOSes that do not have unique ACPI IDs for MADT and Processor objects. To
work around these problems
ThunderBolt cannot read sector >= 2^32 or 2^21
with supplied patch.
Second the bigger change, fix RAID operation on ThunderBolt base
card such as physically removing a disk from a RAID and replacing
it. The current situation is the RAID firmware effectively hangs
waiting for an acknowledgement from the driver. This is due to
the firmware support of the driver actually accessing the RAID
from under the firmware. This is an interesting feature that
the FreeBSD driver does not use. However, when the firmare
detects the driver has attached it then expects the driver will
synchronize LD's with the firmware. If the driver does not sync.
then the management part of the firmware will hang waiting for
it so a pulled driver will listed as still there.
The fix for this problem isn't extremely difficult. However,
figuring out why some of the code was the way it was and then
redoing it was involved. Not have a spec. made it harder to
try to figure out. The existing driver would send a
MFI_DCMD_LD_MAP_GET_INFO command in write mode to acknowledge
a LD state change. In read mode it gets the RAID map from the
firmware. The FreeBSD driver doesn't do that currently. It
could be added in the future with the appropriate structures.
To simplify things, get the current LD state and then build
the MFI_DCMD_LD_MAP_GET_INFO/write command so that it sends
an acknowledgement for each LD. The map would probably state
which LD's changed so then the driver could probably just
acknowledge the LD's that changed versus all. This doesn't seem
to be a problem. When a MFI_DCMD_LD_MAP_GET_INFO/write command
is sent to the firmware, it will complete later when a change
to the LD's happen. So it is very much like an AEN command
returning when something happened. When the
MFI_DCMD_LD_MAP_GET_INFO/write command completes, we refire the
sync'ing of the LD state. This needs to be done in as an event
so that MFI_DCMD_LD_GET_LIST can wait for that command to
complete before issuing the MFI_DCMD_LD_MAP_GET_INFO/write.
The prior code didn't use the call-back function and tried
to intercept the MFI_DCMD_LD_MAP_GET_INFO/write command when
processing an interrupt. This added a bunch of code complexity
to the interrupt handler. Using the call-back that is done
for other commands got rid of this need. So the interrupt
handler is greatly simplified. It seems that even commands
that shouldn't be acknowledged end up in the interrupt handler.
To deal with this, code was added to check to see if a command
is in the busy queue or not. This might have contributed to the
interrupt storm happening without MSI enabled on these cards.
Note that MFI_DCMD_LD_MAP_GET_INFO/read returns right away.
It would be interesting to see what other complexity could
be removed from the ThunderBolt driver that really isn't
needed in our mode of operation. Letting the RAID firmware
do all of the I/O to disks is a lot faster since it can
use its caches. It greatly simplifies what the driver has
to do and potential bugs if the driver and firmware are
not in sync.
Simplify the aen_abort/cm_map_abort and put it in the softc
versus in the command structure.
This should get merged to 9 before the driver is merged to
8.
PR: 167226
Submitted by: Petr Lampa
MFC after: 3 days
another process is in open() or stat() for the device node, then
close() from the owning process does not result in cdevsw close
method call. This fixes the pemanent "Device busy" seen.
Changed the sndstat_lock from mutex to sx. This allows to extend
the region covered by the lock, to include the uiomove() call in
sndstat_read() and bufptr increment. This fixes the "panic:
sbuf_put_byte called with finished or corrupt sbuf" seen.
In collaboration with: kib
MFC after: 1 week
entirely of one machdep file lifted from the MALTA port, as well as
a low-level console and tty driver for the gxemul debugging console
device (the emulators stdio). As with many low-level embedded and
hypervisor console devices, it is polled only, so we drive TTY I/O
from a callout; we are perhaps a bit too aware of the MIPS physical
maps in order to attach the console before newbus comes to life.
The sample kernel configuration depends on an MD-based root file
system, which is not provided. However, any 64-bit, big-endian
userspace image (such as one generated for MALTA) should work.
This will hopefully be supplemented by additional device drivers for
gxemul-specific hardware simulations from Juli Mallett. We have
found oldtestmips quite useful for testing and improving aspects of
the MIPS port, so it's worth supporting better in FreeBSD.
Requested by: theraven, jmallett
Sponsored by: DARPA, AFRL
MFC after: 3 weeks
MDIO/MII rendezvous proxy.
* Add an 'mdio' bus, which is the "IO" side of an MII bus (but by design
can be anything which implements the underlying register access API.)
* Add 'miiproxy' and 'mdioproxy', which provides a rendezvous mechanism
for MII busses to appear hanging off arbitrary busses (ie, that aren't
necessarily a traditional looking MII bus.)
MII busses can now hang off anything that implements an mdiobus.
For the AR71xx SoC, there's one MDIO bus but two MII busses. So to
properly support two or more real PHYs, this can be done:
# arge0 MDIO bus - there's no arge1 MDIO bus for AR71xx
hint.argemdio.0.at="nexus0"
hint.argemdio.0.maddr=0x19000000
hint.argemdio.0.msize=0x1000
hint.argemdio.0.order=0
# Create two mdioproxy instances
hint.mdioproxy.0.at="mdio0"
hint.mdioproxy.1.at="mdio0"
# .. and with a follow-up patch
hint.arge.0.mdio=mdioproxy0
hint.arge.1.mdio=mdioproxy0
TODO:
* Do a sweep or two and add appropriate locking in mdio/mdioproxy/miiproxy.
Submitted by: Stefan Bethke <stb@lassitu.de>
Reviewed by: ray
This will give you more bandwidth for isochronous
FULL speed applications connected through a
High Speed HUB.
This patch has been tested with XHCI and EHCI.
MFC after: 1 week
in the HAL. That's very memory hungry (32k just for channel statistics)
which would be better served by keeping a summary in the ANI state.
Or, later, keep a survey history in net80211.
So:
* Migrate the ah_chansurvey array to be a single entry, for the current
channel.
* Change the ioctl interface and ANI code to just reference that.
* Clear the ah_chansurvey array during channel reset, both in the AR5212
and AR5416 reset path.
* Always call ar5416GetListenTime()
* Modify ar5416GetListenTime() to:
+ don't update the ANI state if there isn't any ANI state;
+ don't update the channel survey state if there's no active
channel - just to be paranoid
+ copy the channel survey results into the current sample slot
based on the current channel; then increment the sample counter
and sample history counter.
* Modify ar5416GetMIBCyclesPct() to simply return a HAL_SURVEY_SAMPLE,
rather than a set of percentages. The ANI code wasn't using the
percentages anyway.
TODO:
* Create a new function which fetches the survey results periodically
* .. then modify the ANI code to use the pre-fetched values rather than
fetching them again
* Roll the 11n ext busy function from ar5416_misc.c to update all the
counters, then do the result calculation
* .. then, modify the MIB counter routine to correctly fetch a snapshot -
freeze the counters, fetch the values, then reset the counters.
The reference driver has a 3ms delay for the AR9130 but I'm not as yet
sure why. From what I can gather, it's likely waiting for some FIFO
flush to occur.
At some point in the future it may be worthwhile adding a WMAC
FIFO flush here, but that'd require some side-call through to the SoC
DDR flush routines.
Obtained from: Atheros
and voltage sensor, TWSI is used to get sensor data. msk(4) does
not monitor these sensors and interrupt for TWSI completion is
disabled by default.
However, due to unknown reason, the TWSI completion interrupt fires
and it resulted in interrupt storm. To fix it, acknowledges the
TWSI completion interrupt if driver see the event. Given that not
all Yukon II controllers show the issue it could be a silicon bug
which does not honor interrupt masking.
Probably the right way to address the issue is disabling automatic
TWSI cycle initiation against these sensors. It would be even
better to implement reading voltage/temperature from the NIC but it
requires access to National LM80 through TWSI and documentation to
do that is not available yet(probably will never happen).
Reported by: jhb
Tested by: jhb
MFC after: 2 weeks
which will be needed for AR7010 and AR9287 USB access.
The names differ slightly from Linux and Atheros, for the sake of
consistency.
A lot more work is required in order to convert the 11n HAL support to
fully support USB.
header will make the data go over the 64k limits announced to busdma as
maxsize and the transaction will fail.
With TSO this can result in a TCP regression due to the lost packet.
According to the data sheets ixgbe(4) 82598 and 82599 can handle up to
256k so increase the maximum.
Reported by: Jon Kåre Hellan, UNINETT (jon.kare.hellan uninett.no)
Tested by: Jon Kåre Hellan, UNINETT (jon.kare.hellan uninett.no)
MFC after: 1 week
sys/dev/dpt/dpt_scsi.c:612:18: error: implicit truncation from 'int' to bitfield changes value from -2 to 2 [-Werror,-Wconstant-conversion]
dpt->cache_type = DPT_CACHE_WRITEBACK;
^ ~~~~~~~~~~~~~~~~~~~
by defining DPT_CACHE_WRITEBACK as 2, since dpt_softc::cache_type is an
unsigned bitfield. No binary change.
MFC after: 1 week
- When switching to 4-bit operation, send a SET_CLR_CARD_DETECT command
to disconnect the card-detect pull-up resistor from the DAT3 line before
sending the SET_BUS_WIDTH command.
- Add the missing "reserved" zero entry to the mantissa table used to
decode various CSD fields. This was causing SD cards to report that they
could run at 30 MHz instead of the maximum 25 MHz mandated in the spec.
o Enhancements:
- At the MMC layer, format various info from the CID into a string that
uniquely identifies the card instance (manufacturer number, serial
number, product name and revision, etc). Export it as an instance
variable.
- At the MMCSD layer, display the formatted card ID string, and also
report the clock speed of the hardware (not the card's max speed), and
the number of bits and number of blocks per transfer. It comes out like
this now:
mmcsd0: 968MB <SD SD01G 8.0 SN 276886905 MFG 08/2008 by 3 SD> at mmc0
22.5MHz/4bit/128-block
o Use DEVMETHOD_END.
o Use NULL instead of 0 for pointers.
PR: 156496
Submitted by: Ian Lepore
MFC after: 1 week
sys/dev/nxge/if_nxge.c:1276:11: error: case value not in enumerated type 'xge_hal_event_e' (aka 'enum xge_hal_event_e') [-Werror,-Wswitch]
case XGE_LL_EVENT_TRY_XMIT_AGAIN:
^
sys/dev/nxge/if_nxge.c:1289:11: error: case value not in enumerated type 'xge_hal_event_e' (aka 'enum xge_hal_event_e') [-Werror,-Wswitch]
case XGE_LL_EVENT_DEVICE_RESETTING:
^
This is because the switch uses xge_queue_item_t::event_type, which is
an enum xge_hal_event_e, while the XGE_LL_EVENT_xx values are of the
enum xge_event_e.
Since messing around with the enum definitions is too disruptive, the
simplest fix is to cast the argument of the switch to int.
Reviewed by: gnn
MFC after: 1 week
STAILQ(). While here, fix another clang warning about a switch which
tests an enum type for a regular integer value.
Submitted by: jhb
MFC after: 1 week
assumes for small buffers (< 64k) that the OS driver is actually using
a buffer rounded up to the next power of 2. It also assumes that the
buffer is at least 4k in size. Furthermore, there is at least one
known instance of megarc sending a request with a 12k buffer where the
firmware writes out a 24k-ish reply.
To workaround the data corruption triggered by this "feature", ensure
that buffers for user commands use a minimum size of 32k, and that
buffers between 32k and 64k use a 64k buffer.
PR: kern/155658
Submitted by: Andreas Longwitz longwitz incore de
Reviewed by: scottl
MFC after: 1 week
at least until I can root cause what's going on.
The only platform I've seen this on is the AR9220 when attached to
the AR71xx CPUs. I get immediate PCIe bus errors and all subsequent
accesses cause further MIPS bus exceptions. I don't have any other
big-endian platforms to test this on.
If I get a chance (or two), I'll try to whack this on a bus analyser
and see exactly what happens.
I'd rather leave this on, especially for slower, embedded platforms.
But the #ifdef hell is something I'm trying to avoid.
even in the face of errors.
If the RX descriptor list fails, the RX lock won't be initialised, but
then the DMA free path wil try freeing it.
This commit is brought to you by a working mwl(4).
This may result in a bit of a throughput drop. However, any throughput
drop at this point should be investigated and root caused, as it's likely
because TX scheduling (all the way down to how preemption, scheduler work,
etc) is happening in a sub-optimal fashion.
This also makes it much more likely to be reloadable on a live machine.
Allocating 5120 TX ath_buf entries via contigmalloc is very unlikely
after a few hours of using X/Chromium.
dirty and murky past.
* Override the default cache line size to be something reasonable if
it's set to 0. Some NICs initialise with '0' (eg embedded ones)
and there are comments in the driver stating that various OSes (eg
older Linux ones) would incorrectly program things and 0 out this
register.
* Just default to overriding the latency timer. Every other driver
does this.
* Use a default cache line size of 32 bytes. It should be "reasonable
enough".
Obtained from: Linux ath9k, Atheros
a8af6270bd96be6ccd86f70b60fa6512b710e4f0
virtio_blk: Include function name in panic string
cbdb03a694b76c5253d7ae3a59b9995b9afbb67a
virtio_balloon: Do the notify outside of the lock
By the time we return from virtqueue_notify(), the descriptor
will be in the used ring so we shouldn't have to sleep.
10ba392e60692529a5cbc1e9987e4064e0128447
virtio: Use DEVMETHOD_END
80cbcc4d6552cac758be67f0c99c36f23ce62110
virtqueue: Add support for VIRTIO_F_RING_EVENT_IDX
This can be used to reduce the number of guest/host and
host/guest interrupts by delaying the interrupt until a
certain index value is reached.
Actual use by the network driver will come along later.
8fc465969acc0c58477153e4c3530390db436c02
virtqueue: Simplify virtqueue_nused()
Since the values just wrap naturally at UINT16_MAX, we
can just subtract the two values directly, rather than
doing 2's complement math.
a8aa22f25959e2767d006cd621b69050e7ffb0ae
virtio_blk: Remove debugging crud from 75dd732a
There seems to be an issue with Qemu (or FreeBSD VirtIO) that sets
the PCI register space for the device config to bogus values. This
only seems to happen after unloading and reloading the module.
d404800661cb2a9769c033f8a50b2133934501aa
virtio_blk: Use better variable name
75dd732a97743d96e7c63f7ced3c2169696dadd3
virtio_blk: Partially revert 92ba40e65
Just use the virtqueue to determine if any requests are
still inflight.
06661ed66b7a9efaea240f99f414c368f1bbcdc7
virtio_blk: error if allowed too few segments
Should never happen unless the host provides use with a
bogus seg_max value.
4b33e5085bc87a818433d7e664a0a2c8f56a1a89
virtio_blk: Sort function declarations
426b9f5cac892c9c64cc7631966461514f7e08c6
virtio_blk: Cleanup whitespace
617c23e12c61e3c2233d942db713c6b8ff0bd112
virtio_blk: Call disk_err() on error'd completed requests
081a5712d4b2e0abf273be4d26affcf3870263a9
virtio_blk: ASSERT the ready and inflight request queues are empty
a9be2631a4f770a84145c18ee03a3f103bed4ca8
virtio_blk: Simplify check for too many segments
At the cost of a small style violation.
e00ec09da014f2e60cc75542d0ab78898672d521
virtio_blk: Add beginnings of suspend/resume
Still not sure if we need to virtio_stop()/virtio_reinit()
the device before/after a suspend.
Don't start additional IO when marked as suspending.
47c71dc6ce8c238aa59ce8afd4bda5aa294bc884
virtio_blk: Panic when dealt an unhandled BIO cmd
1055544f90fb8c0cc6a2395f5b6104039606aafe
virtio_blk: Add VQ enqueue/dequeue wrappers
Wrapper functions managed the added/removing to the in-flight
list of requests.
Normally biodone() any completed IO when draining the virtqueue.
92ba40e65b3bb5e4acb9300ece711f1ea8f3f7f4
virtio_blk: Add in-flight list of requests
74f6d260e075443544522c0833dc2712dd93f49b
virtio_blk: Rename VTBLK_FLAG_DETACHING to VTBLK_FLAG_DETACH
7aa549050f6fc6551c09c6362ed6b2a0728956ef
virtio_blk: Finish all BIOs through vtblk_finish_bio()
Also properly set bio_resid in the case of errors. Most geom_disk
providers seem to do the same.
9eef6d0e6f7e5dd362f71ba097f2e2e4c3744882
Added function to translate VirtIO status to error code
ef06adc337f31e1129d6d5f26de6d8d1be27bcd2
Reset dumping flag when given unexpected parameters
393b3e390c644193a2e392220dcc6a6c50b212d9
Added missing VTBLK_LOCK() in dump handler
Obtained from: Bryan Venteicher bryanv at daemoninthecloset dot org
Contrarily to what i wrote in my previous commit, the 82599
does include the CRC in the length. The operating mode is
reset in ixgbe_init_locked() and so we need to hook into
the places where the two registers (HLREG0 and RDRXCTL) are
modified.
interface.
* Introduce a device hint, 'eeprom_firmware', which is the name of firmware
to lookup.
* If the lookup succeeds, take a copy of it and use it as the eeprom data.
This isn't enabled by default - you have to define ATH_EEPROM_FIRMWARE.
I'll add it to the configuration variables in a later commit.
TODO:
* just keep a firmware reference in ath_softc, and remove the need to
waste the extra memory in having sc_eepromdata be a malloc()ed block.
used in polled-mode. The callout invokes uart_intr, which rearms the timeout.
Implemented for bhyve, but generically useful for e.g. embedded bringup
when the interrupt controller hasn't been setup, or if it's not deemed
worthy to wire an interrupt line from a serial port.
Submitted by: neel
Reviewed by: marcel
Obtained from: NetApp
MFC after: 3 weeks
does not include the CRC irrespective of the setting
of CRCSTRIP. The 82599 data sheets (sec. 7.1.6) say differently.
Very strange. Need to check what happens on legacy descriptors,
but for the time being this restores functionality.
and make it easier to replace it with a different implementation.
On passing, also fix indentation.
NOTE: I know that #include "foo.c" is ugly, but the alternative
(add another entry to sys/conf/files, add a separate header with
structs and prototypes, and expose functions that are meant to
be private) looks even worse to me.
We need a more modular way to specify dependencies and build options.
portions were already reapplied in r233708:
- Use a dedicated task to handle deferred transmits from the if_transmit
method instead of reusing the existing per-queue interrupt task.
Reusing the per-queue interrupt task could result in both an interrupt
thread and the taskqueue thread trying to handle received packets on a
single queue resulting in out-of-order packet processing.
- Call ether_ifdetach() earlier in igb_detach().
- Drain tasks and free taskqueues during igb_detach().
MFC after: 1 week
- add a sysctl, dev.netmap.ix_crcstrip, to control whether ixgbe should
strip the CRC on received frames. Defaults to 0, which keeps the CRC.
and improves performance when receiving min-sized (64-byte) frames.
This matters because min-sized frames is one of the standard
benchmarks for switches and routers, some chipsets seem to issue
read-modify-write cycles for PCIe transactions that are not a
full cache line, and a min-sized frame triggers the bug, resulting
in reduced throughput -- 9.7 instead of 14.88 Mpps -- and heavy
bus load.
- for the time being, always look for incoming packets on a select/poll
even if there has not been an interrupt in the meantime. This is
only a temporary workaround for a probable race condition in keeping
track of rx interrupts.
Add a couple of diagnostic vars to help studying the problem.
values as in the Intel driver 3.8.21 for linux. The fact that it
is standard in the above driver suggests that it has no bad side
effects.
But of course there must be a reason for enabling features, not
just "it does not harm", so here it is a good one:
Prefetching enables full line rate even using a single queue (14.88
Mpps, compared to ~12 Mpps without prefetch). This in turn is
terribly useful when one wants to schedule traffic.
For obvious reasons the difference is only visible with netmap
or other high speed solutions, but presumably the advantage
should be in the order of a fraction of a microsecond when
starting transmission on an empty queue.
Discussed with Jack Vogel.
MFC after: 1 week
r228476 fixed superfluous link UP/DOWN messages but broke IPMI
access during boot. It's not clear why r228476 breaks IPMI and
should be revisited.
Reported by: Paul Guyot <paulguyot <> ieee dot org >
MFC after: 1 week
identical now that the bus spaces are unified under sys/x86.
Replace them with a single uart_cpu_x86.c.
o delete uart_cpu_i386.c
o move uart_cpu_amd64.c to uart_cpu_x86.c
o update files.amd64 and files.i386 accordingly.
problem where userspace apps such as smartctl fail due to CAM_REQUEUE_REQ
status getting returned when tagged commands are outstanding when smartctl
sends its I/O using the pass(4) interface.
Sponsored by: Intel
Found and tested by: Ravi Pokala <rpokala at panasas dot com>
Reviewed by: scottl
Approved by: scottl
MFC after: 1 week
add a FreeBSD_version check. It should work fine for compiling
on -HEAD, 9.x and 8.x.
* Conditionally compile the 11n options only when 11n is enabled.
The above changes allow the ath(4) driver to compile and run on
8.1-RELEASE (Hi old PC-BSD!) but with the 11n stuff disabled.
I've done a test against the net80211 and tools in 8.1-RELEASE.
The NIC used in testing is the AR2427 in an EEEPC.
Just to be clear - this change is to allow the -HEAD ath/hal/rate
code to run on 9.x _and_ 8.x with no source changes. However,
when running on earlier kernels, it should only be used for legacy
mode. (Don't define ATH_ENABLE_11N.)
damage which I committed when I had less clue about such things.
Don't ever put normal data frames on the mcast software queue.
Just put mcast frames there if needed.
Pass the txq decision into ath_tx_normal_setup(), as we've already made
the decision. Don't re-do it.
Whilst i'm here, add another random debugging statement.
This fixes bootp on if_smc, as bootp code perform SIOCSIFADDR
ioctl call immediately after sending the request (which causes
if_init being called) which causes the adapter to drop all the
packets received in the meantime.
call these after rate control selection is done.
The duration/protection code wasn't working - it expected the rix to
be valid. Unfortunately after I moved the rate control selection into
late in the process, the rix value isn't valid and thus the protection/
duration code would get things wrong.
HT frames are now correctly protected with an RTS and for the AR5416,
this involves having the aggregate frames be limited to 8K.
TODO:
* Fix up the DMA sync to occur just before the frame is queued to the
hardware. I'm adjusting the duration here but not doing the DMA
flush.
* Doubly/triply ensure that the aggregate frames are being limited to
the correct size, or the AR5416 will get unhappy when TXing RTS-protected
aggregates.
