to see those debug message).
Fixed a bug where we removed TX descriptors too early. This should fix NETDEV
WATCHDOG error messages. Apparently, TX descriptor status is updated by the
hardware before TXDP.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3552 0192ed92-7a03-0410-a25b-9323aeb14dbd
The rx overruns should dissapear with the previous performance improvements and a little bit more runway here. The 100 more to tx should only help in cases where large numbers of small packets are set and you are going for maximum throughput. Even then, I haven't proven you will ever need this many tx buffers. I've also bumped the reserve pool for management frames from 5 to 20.
These settings tested well in the lab with multiple station links running bandwidth tests.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3521 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Only hold the RX queue lock while removing and while re-inserting a buffer -
allowing pre-emption to work properly while the tasklet is reaping and
recycling rx buffers.
* All skb and bus handling is managed in the ath_rxbuf_init function now.
* Do not stop processing when ath_rxbuf_init fails, because that means low
free skb but does NOT mean the queue is fully processed. Since we also keep
our skbuff except during a very brief period when we free one and reallocate
one - unless pre-emption or SMP steals it, chances are very good we can keep
processing the queue even under low memory conditions -- and avoid dreaded
rx overruns.
* Add missing locks around code blocks that iterate over rx buffer list in
flush/drain/init/cleanup/etc helper functions.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3519 0192ed92-7a03-0410-a25b-9323aeb14dbd
I've simplified the buffer initialization code so that it
always allocates things as if there were one or more monitor VAPs. This is
defensive since monitor VAPs can are created and/or destroyed while the radio is
up.
The old logic was basically changing the behavior of the initialization function
dynamically based on the presence of a monitor VAP but could lead to a mixed set
of buffers.
The revised code keeps all the buffers the same and make sure there is room for a radiotap
or prism header if necessary in advance.
Without this change, even after adding a monitor VAP you are going to pull SKBs that are too small for a while.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3518 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Fix a bug where we would copy any cloned skb received in ath_hardstart,
and free the original... before returning the original to the queue!
The result of this would be memory corruption at best, randomly placed panic
at worst.
* In one case we returned -ENETDOWN from hard start, which in current kernels
is NOT NETDEV_TX_OK so it would therefore requeue the packet which we just
released.
* Fixes the logic for both requeue and drop in hardstart fail so that we never
leak, never double-free, and never leave the kernel with an invalid pointer
to an SKB we just freed.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3517 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Replace an_halstats it with an_avgrssi (EWMA)
* Only update stats in ath_softc* when we are on-channel and acting as a station,
as there is no meaning to these stats as an AP.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3515 0192ed92-7a03-0410-a25b-9323aeb14dbd
this is what it does.
* Rename ATH_BUFSTATUS_DONE to ATH_BUFSTATUS_RXDESC_DONE since this is what
we mean - has the descriptor been processed.
* Eliminate a case where we were processing each descriptor twice and
double-counting the statistics.
* Delegate decision on whether to schedule the rx queue to
ath_intr_process_rx_descriptors so we do not schedule it when there is no work.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3514 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Beacon calibration interval needs to be per-radio, not global because
each radio is going to have it's IQ gain calibration reached at different
times. With multi-radio systems, you could have one radio calibrated and one
in sorry shape and the calibration interval would be dropped back to the
longer intervals for both. This also necessitated removal of the sysctl var
for "calibrate" since it was the wrong thing.
* Fix for jiffies rollover bugs - use macros and mod_timer calls rather than
hacking timer structures directly.
* Always process noise floor before retrieving it. That is to say, the process
noise floor call and the get channel noise call should always be one after the
other, owing to things like channel changes and scanning.
ath_hal_process_noisefloor(sc->sc_ah);
ic->ic_channoise = ath_hal_get_channel_noise(sc->sc_ah, &(sc->sc_curchan));
* Calculate noise floor and read noise level at more opportune times/places.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3513 0192ed92-7a03-0410-a25b-9323aeb14dbd
This makes sure that the post-hw-reset stuff we do is done consistently in all cases for improved stability and predictability everywhere hardware reset is necessary.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3509 0192ed92-7a03-0410-a25b-9323aeb14dbd
You can override:
- slottime
- ctstimeout
- acktimeout
acktimeout and ctstimeout will be selected from the first available of:
1) the explicitly specified override value [if present]
2) a value derived from an explicitly specified slottime [if present]
3) the HALs default behavior / standard settings for the PHY mode
Setting the distance is shorthand for updating the slottime, and both cts and ack timeout values based upon the usual equations for air propagation, speed of light, etc..etc..
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3508 0192ed92-7a03-0410-a25b-9323aeb14dbd
Further, the tpc module parameter was based upon a misunderstanding of what the HAL really supports and has been re-characterized.
Originally I believed that the HAL implemented per-node power level tuning but they apparently felt the specifications were too complicated and instead they implemented the minimum requirement for ETSI aggregate power limit compliance.
In short, "tpc" really uses a fixed power level for all packets of the regulatory maximum less 3dBm. It also defeats the fine-grained control (per descriptor) we have over the power levels of transmitted packets.
Therefore, I have renamed this to "hal_tpc" and updated the comments to reflect that this really is ETSI-style TPC hack for aggregate power. Since the user can set the power level to max -3dBm just as easily, I don't see the point of it after all, but it's still supported just in case someone finds value in it.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3506 0192ed92-7a03-0410-a25b-9323aeb14dbd
A module parameter and sysctl parameter are provided for changing whether interference mitigation is enabled or disabled.
When interference mitigation is disabled, we work around a HAL defect where the interference mitigation auto-tuning algorithm still starts and/or sets some initially high mitigation levels.
With this fix, disabling interference mitigation with the current HAL behaves like it did in prior HALs.
Far greater receive sensitivity and increased range is supported with this disabled. This is especially useful for long distance point-to-point links.
As a part of this fix, a severe bug that was originally a workaround for the HAL issue has been corrected. When interference mitigation is enabled, we NEVER want to eat or throttle the MIB interrupts as the hardware counter callbacks to the HAL are what drives the interference mitigation calibration state machine. Conversely, if interferference mitigation is being blocked by our driver but the hAL may still be enabling the HAL_INT_MIB in the IMR, then we want to force the interrupt OFF in the mask and eat the interrupt.
The failure case was where the interrupt would fire continually and never get properly handled because the HAL wasn't configured to handle interfernece mitigation - now we mask the interrupt OFF. With the 'throttling' hack, we didn't fix hte problem but made it worse - when interfernce mitigation was enabled we just blocked the necessary signals to get the counters updated and stop the interrupt from continuing to fire.
The timer to re-enable the MIB interrupt after it fired was also wrong cause it would make sure the interrupt could never be disabled by the HAL or the driver.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3505 0192ed92-7a03-0410-a25b-9323aeb14dbd
This pointer is entirely redundant with the pointer already in the SKB. This eliminates an unnecessary source of possible node reference leaks. In all cases this variable was being populated from the SKB's node pointer and was never referenced outside of the context of processing an skb, for obvious reasons.
Use BF_NI(bf) or SKB_NI(skb) macros to obtain the node of a buffer or skb.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3504 0192ed92-7a03-0410-a25b-9323aeb14dbd
We had a local flag that was being used inconsistently to mirror the queue state, but was really brain dead. sc_devstopped could be off even when the queue was stopped and no matter how many buffers were freed, we would never restart the queue. This could lead to liveness issues (mostly after a buffer leak caused excessive buffers to be used).
The kernel has an easy call to find out if the queue is stopped or not, so this checkin uses that.
We will re-awaken the queue if:
1) we have some buffers we are willing to use for data
2) the channel is available (as opposed to being in DFS CAC)
3) the queue is stopped
This is what we were originally going for with reap counters and sc_dev_stopped and all this other nonsense. The new logic is much simpler and cleaner.
This also fixes a performance problem where the queue was being re-awakened when no buffers were available resulting in a constant ping-pong of buffers between the kernel and madwifi and a very very heavy CPU utilization at exactly the wrong time.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3503 0192ed92-7a03-0410-a25b-9323aeb14dbd
HAL will say the CABQ is not active if the trigger has fired and the CABQ has been serviced. Therefore, the conditions under which we were skipping CABQ are EXACTLY when we need to check it.
This was leading to large numbers of rx buffers consumed in the CABQ (multicast, etc) and thus the RX queue would deteriorate over time until RX overruns would eventually start to be a big problem.
I also include better diagnostics.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3502 0192ed92-7a03-0410-a25b-9323aeb14dbd
