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
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
* Updated register dump based on ath5k database (refresh the list)
* Added a generic debug iwpriv delegation method to if_ath
* Added some functions to help diagnose lost ath_buf pointers
[resultant fixes will be checked in subsequent commits]
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3497 0192ed92-7a03-0410-a25b-9323aeb14dbd
This patch differs from the original in that beacon synchronised calibration is not condifured during CAC as no beacons are sent.
Thanks to nbd.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3358 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Based on patches from nbd
* av_beacon_alloc code has been reimplemented using atomic bit operations; I think this is safe for SMP
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3310 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Lots of coding style and formatting, tedious and annoying
* Quite a few bad merges as far as I can tell; at least one of which was serious - reintroduced a leak
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3202 0192ed92-7a03-0410-a25b-9323aeb14dbd
branch to trunk. especially notable is, that due to improved nexttbtt (next
"target beacon transmit time") calculation we will now get the correct backoff
behaviour for beacons, resulting in only one beacon per beacon interval (the
current head version will send N beacons for N stations in the beacon interval
because they are poorly synchronized). also because of the better timer
synchronization there is no more time lag of up to 1 minute until we see
beacons after a merge. thanks to benoit for figuring that out!
the difference between this patch and the version in the dfs-branch is that it
still uses self linked descriptors and uses the SWBA interrupt only for
updating the nexttbtt. this is necessary to recognize HW merges, for which we
don't get any notification by the hardware (see the thread "IBSS testing" on
this list for more details).
also i tried to clean up a bit, use a more descriptive function name for timer
updates (ath_beacon_update_timers instead of ath_beacon_config) and generally
better distingush between a HW merge and a SW merge.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3027 0192ed92-7a03-0410-a25b-9323aeb14dbd
Preprocessor flag now used to toggle printk output prior to blocking on
a spinlock.
There is of course a chance that the spinlock will be taken between the time we check it and print our little message, but this should still be of some assistance troubleshoot locking mistakes that come up in the future.
If you turn on the flag, you can find out what locks are being contended for and from which functions... i.e. ath_intr fights for a particular lock, etc.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2944 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Counters for total outstanding instances for each resource type (skb, ath_node and ath_buf)
* One pair of acquisition/release functions per resource type in unlocked and one in locked
* Adds some more _debug versions of functions in the call chain that acquire/release resources so that the original func/line in the driver as well as the func/line that affected the resource use can be shown in the trace. Intermediate stack frames aren't necessary to trace the leaks.
* Changes naming convention for "lock-required" functions to suffix _locked for the versions that expect locking, to be consistent with some other places in the code.
* Consolidate debug messages to the helper functions that actually affect the reference count or acquire/release a resource
* Additional sanity checks and leak detection (esp for detecting node ref leaks through skb)
* skb references are nulled out by the new sbk unref/free function.
I've tested these changes extensively and found lots of cases where we didn't get enough node references when cloning skbuff, and where the kernel drops packets due to performance issues and leaks our node references.
With these changes and the tracing enabled I have verified that:
* TX BUF: tx buffers always go down to zero when the tx queue is done, and you can watch tx queue usage ratio go up and down again as the driver is working. There are no leaks here at the moment, although there *are* some in the madwifi-dfs branch during CAC at the moment.
* skbuff leaks in all the common flows are fixed. We were leaking node references in a lot of places where kernel was dropping skb's due to congestion and we were failing to increment node references when cloning skbuffs. These are now detected, as are skbuffs that are reaped by the kernel while still holding a node reference.
* the ath_node count works correctly and on an idle system we get about 5 references per station table node, with 2 node instances per VAP. One for the bss and one for the node in the station table, I believe. The ath_node count goes up and down but always lands back at the stable number based on the vaps you have configured and the number of actual stations in the station table. The point here is that it's pretty constant what you will see over time, despite excessive node creation/release in our code during input (esp input_all). Thank god for the slab allocator.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2902 0192ed92-7a03-0410-a25b-9323aeb14dbd
catch messages that occur during VAP startup (before you can possibly invoke
80211debug).
Support for shared debug flags where they take effect across all devices
(i.e. shared flags in athdebug), and when they take effect across all VAPs
(i.e. shared flags in 80211debug).
Some additional debugging flags, including some in preparation for more leak
detection code to be merged shortly as well as some from madwifi-dfs.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2888 0192ed92-7a03-0410-a25b-9323aeb14dbd
SET_MODULE_OWNER() is not defined in 2.6.24, but it's already a no-op in
2.6.23. Make sure that it will be a no-op in 2.6.23 and newer kernels.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2754 0192ed92-7a03-0410-a25b-9323aeb14dbd
