Bug 192416 - [ath] TSFOOR interrupt firing on AR9331
Summary: [ath] TSFOOR interrupt firing on AR9331
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-06 01:52 UTC by Adrian Chadd
Modified: 2024-09-23 01:27 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer freebsd_triage 2014-08-06 01:52:57 UTC 
The TSFOOR interrupt is triggering with the AR9331 in station mode.

take a look to see what's going on:

* is it not RX'ing beacons;
* is the beacon timer programming all fucked up;
* is calibration interfering;
* something else.
Comment 1 Glen Barber freebsd_committer freebsd_triage 2014-08-06 01:58:19 UTC 
Also happens on AR9485, but has not happened for me recently.
Comment 2 Tom 2024-09-22 22:59:23 UTC 
This is also happening for me on the AR9460. Every week or two the wifi on my headless home server will randomly disappear and so I'll hard reboot it. Looking at /var/log/messages there is always a line "kernel: ath0: ath_intr: TSFOOR".
Comment 3 Adrian Chadd freebsd_committer freebsd_triage 2024-09-23 01:27:42 UTC 
(In reply to Tom from comment #2)

TSFOOR happens when it's gone deaf or the beacon timers are all wrong.

You could try this on the machine when it happens to force a reset:

# sysctl hw.ath.hal.force_full_reset=1
# sysctl dev.ath.0.forcebstuck=1

That will force a full reset and then a "beacon stuck" situation.

If it recovers from that then I'll go and ensure TSFOOR schedules a full cold reset to unstick things.