diff options
author | Adrian Chadd <adrian@FreeBSD.org> | 2021-03-13 07:30:25 +0000 |
---|---|---|
committer | Adrian Chadd <adrian@FreeBSD.org> | 2021-03-13 07:30:25 +0000 |
commit | fb3edd4f3ff89f5883b8309ff71ff4a426279c85 (patch) | |
tree | 2a517b969d4932c994ad79ca1a773d886a0e695e /sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c | |
parent | 51dfae383bf6298af9e6d816a78b92b6f34d68be (diff) | |
download | src-fb3edd4f3ff89f5883b8309ff71ff4a426279c85.tar.gz src-fb3edd4f3ff89f5883b8309ff71ff4a426279c85.zip |
[ath] do a cold reset if TSFOOR triggers
TSFOOR happens if a beacon with a given TSF isn't received within the
programmed/expected TSF value, plus/minus a fudge range. (OOR == out of range.)
If this happens then it could be because the baseband/mac is stuck, or
the baseband is deaf. So, do a cold reset and resync the beacon to
try and unstick the hardware.
It also happens when a bad AP decides to err, slew its TSF because they
themselves are resetting and they don't preserve the TSF "well."
This has fixed a bunch of weird corner cases on my 2GHz AP radio upstairs
here where it occasionally goes deaf due to how much 2GHz noise is up
here (and ANI gets a little sideways) and this unsticks the station
VAP.
For AP modes a hung baseband/mac usually ends up as a stuck beacon
and those have been addressed for a long time by just resetting the
hardware. But similar hangs in station mode didn't have a similar
recovery mechanism.
Tested:
* AR9380, STA mode, 2GHz/5GHz
* AR9580, STA mode, 5GHz
* QCA9344 SoC w/ on-board wifi (TL-WDR4300/3600 devices); 2GHz
STA mode
Diffstat (limited to 'sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c')
0 files changed, 0 insertions, 0 deletions