summaryrefslogtreecommitdiffstats
path: root/etc/mtree
diff options
context:
space:
mode:
authoradrian <adrian@FreeBSD.org>2011-06-26 13:53:24 +0000
committeradrian <adrian@FreeBSD.org>2011-06-26 13:53:24 +0000
commit46ff0e559ab79ebfbd80e88d8039edc881cfb02b (patch)
tree4e974abb1c8ba8ff2c1f4203e669d29f9ef72c0c /etc/mtree
parent5c01535c7c4aeafb7ba7768538315dca39fa182c (diff)
downloadFreeBSD-src-46ff0e559ab79ebfbd80e88d8039edc881cfb02b.zip
FreeBSD-src-46ff0e559ab79ebfbd80e88d8039edc881cfb02b.tar.gz
Fix beacon transmission after a channel set.
The DFS code was tickling the channel set directly whilst going through the state RUN -> CSA -> RUN. This only changed the channel; it didn't go via ath_reset(). However in this driver, a channel change always causes a chip reset, which resets the beacon timer configuration and interrupt setup. This meant that data would go out but as the beacon timers never fired, beacons would never be queued. The confusing part is that sometimes the state transition was RUN -> SCAN -> CAC -> RUN (with CSA being in there sometimes); going via SCAN would clear sc_beacons and thus the transition to RUN would reprogram beacon transmission. In case someone tries debugging why suspending a device currently beaconing (versus just RX'ing beacons which is what occurs in STA mode), add a silly comment which should hopefully land them at this commit message. The call to ath_hal_reset() will be clearing the beacon config and it may not be always reset.
Diffstat (limited to 'etc/mtree')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud