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
ieee80211_input can receive cloned skb from the bridge layer, and thus makes copies to modify and use. The original was being freed immediately upon copying. The problem is that when you issue ANY response other than NETDEV_TX_OK the skb is returned to the kernel queue. So, basically there were wild pointers to skb in the skb queue, and these skb were being re-used by other applications and drivers - resulting in crashes all over the place.
With this new logic, we keep the original around until we know whether or not we will requeue it NETDEV_TX_BUSY or consume it NETDEV_TX_OK and we correctly free the skb only when appropriate.
We also get rid of the net80211_input_all function which was doing a bunch of unnecessary (and broken) copies and noe updates.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3501 0192ed92-7a03-0410-a25b-9323aeb14dbd
When CABQ transfer finishes, HAL reports the queue as inactive. Thus, if
we switch modes or change state the CABQ can be left with some ath_buf
referenced by it. The changes in this patch cause the CABQ to be checked
at DTIM even when no multicast is pending for the VAP and if "stalled"
then the queue is drained.
A subsequent patch will fix the tx tasklet logic for CABQ.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3499 0192ed92-7a03-0410-a25b-9323aeb14dbd
before the allocation and initial configuration. Since there shouldn't be any dturbo switches at this point, some null checks prevent the problem. I'm not sure where the code should be moved to, but probably further down in the function.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3498 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
The convention for this function ieee80211_pwrsave is to consume the SKB and either
queue it or free it. Also switch some SKB_CB(...)->ni to SKB_NI(...)
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3491 0192ed92-7a03-0410-a25b-9323aeb14dbd
1) Move all debug preprocessor flags out into make files
2) Add support for remaining preprocessor flags to be set by ENV variables
3) Add support for HAL tracing to include device name
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3481 0192ed92-7a03-0410-a25b-9323aeb14dbd
The need to use software instead of hardware for beacon timers in AP+STA mode (aka nosbeacon) is now just determined in software, as we always knew whether or not to enable this.
The confusing bssid and -bssid parameters are now deprecated.
The "uniquebssid" flag is equivalent to "bssid" and can be used to force IEEE80211_CLONE_BSSID flag. If this is not specified, then the BSSID used will be the next unused BSSID in the sequence, which could very well be the parent device's MAC address.
"uniquebssid" equates directly to IEEE80211_CLONE_BSSID" flag therefore.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3476 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Restructure one set of control blocks into a more readable form
* Add some additional debug output
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3456 0192ed92-7a03-0410-a25b-9323aeb14dbd
progress and only works for eeprom versions < 5.
Reference: r3234
Merged from madwifi-trace and replaced with the exact version from
madwifi-trace to fix minor differences caused by previous merges.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3429 0192ed92-7a03-0410-a25b-9323aeb14dbd
Define _FILE_OFFSET_BITS to 64, so that even 32-bit systems would accept
64-bit addresses and pass then to mmap() correctly. It could be useful
on systems with a 64-bit kernel and 32-bit userspace.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3421 0192ed92-7a03-0410-a25b-9323aeb14dbd
