Bug 165021 - [ath] ath device timeout during scan/attach, if wlan_ccmp/wlan_tkip isn't loaded
Summary: [ath] ath device timeout during scan/attach, if wlan_ccmp/wlan_tkip isn't loaded
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 9.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
Depends on:
Reported: 2012-02-12 03:00 UTC by Adrian Chadd
Modified: 2018-05-28 19:47 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer 2012-02-12 03:00:25 UTC
If wlan_tkip/wlan_ccmp aren't loaded but are required by the hostap, the station mode code will:

* attempt to associate
* succeed
* mark wlanX as UP
* note that the required encryption type is not active
* mark wlanX as DOWN

. then 5 seconds later, "ath0: device timeout" shows up.


After enabling debugging, I discovered this sequence of events:

* a frame was being queued to the hardware - in this instance, a DISCONNECT frame;
* the state would then transition to DOWN;
* the IER was disabled - ie, HAL_INT_GLOBAL was cleared and something called ath_hal_intrset(); so the interrupt wouldn't occur;
* the watchdog timer would kick in and call ath_reset();
* there'd be at least one completed frame in the TX queue, status OK - so it did go out.

The actual cause seems to be that the state transition is going from RUN -> INIT, and this is causing interrupts to be disabled.

ath_newstate() is causing a state transition to INIT, which disables interrupts and blocks the ath taskqueue. Trouble is, this doesn't stop/flush any of the currently pending hardware TX and this is what's eventually causing the watchdog timeout - although the hardware has completed the TX, the driver has disabled all methods of actually being notified about it.
How-To-Repeat: * compile ath/net80211 as modules
* load wlan and ath/ath_pci - but don't load wlan_wep/wlan_tkip/wlan_ccmp
* attempt to associate to a network which requires encryption
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2012-02-17 18:23:14 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-wireless

Comment 2 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:48 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.