mirror of
https://github.com/proski/madwifi
synced 2024-11-22 06:21:47 +03:00
b327291039
due to unlucky timing of beacon timer configuration (which we try to avoid) and due to unlucky timing of local TSF updates (triggered by the reception of a beacon with the same BSSID - something we can't avoid) the beacon timers (we have 4) can be updated seperately, leaving one of them in the past, not beeing updated until the timers wrap around. due to the fact that the beacon interval does not fit into the timer period (16 bit) a whole number of times the size of the ATIM window can get bigger than desired (we don't use ATIM right now so the window size should always be 1). this results in a phaenome described as "ramping" (ticket #1154) which is actually a transmission delay, since the hardware is not allowed to transmit data in the ATIM period. the problem is described and discussed in length at http://thread.gmane.org/gmane.linux.drivers.madwifi.devel/6066 since we don't know of a way to disable ATIM alltogether, the following adds some workarounds to this problem: 1.) disable interrupts in timing critical function ath_beacon_config 2.) stop beacons before reconfiguring them 3.) check ATIM window after critical code which might have changed the timers 3a.) beacon configuration 3b.) reception of a beacon with the same BSSID. the hardware will have updated the local TSF and this might have left one of the beacon timers in the past. git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3867 0192ed92-7a03-0410-a25b-9323aeb14dbd |
||
|---|---|---|
| .. | ||
| if_ath_ahb.c | ||
| if_ath_ahb.h | ||
| if_ath_debug.h | ||
| if_ath_hal_extensions.c | ||
| if_ath_hal_extensions.h | ||
| if_ath_hal_macros.h | ||
| if_ath_hal_wrappers.h | ||
| if_ath_hal.h | ||
| if_ath_pci.c | ||
| if_ath_pci.h | ||
| if_ath_radar.c | ||
| if_ath_radar.h | ||
| if_ath.c | ||
| if_athioctl.h | ||
| if_athvar.h | ||
| Makefile | ||
| Makefile.kernel | ||