aboutsummaryrefslogtreecommitdiff
path: root/sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c
diff options
context:
space:
mode:
authorAdrian Chadd <adrian@FreeBSD.org>2021-03-13 07:30:25 +0000
committerAdrian Chadd <adrian@FreeBSD.org>2021-03-13 07:30:25 +0000
commitfb3edd4f3ff89f5883b8309ff71ff4a426279c85 (patch)
tree2a517b969d4932c994ad79ca1a773d886a0e695e /sys/contrib/openzfs/module/os/freebsd/zfs/zfs_vfsops.c
parent51dfae383bf6298af9e6d816a78b92b6f34d68be (diff)
downloadsrc-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