When testing 802.11n hostap mode, the TX side still occasionally hangs.
This is again due to the "busy" buffer management code being slightly wrong, allowing a "busy" buffer to stay busy and eventually clogging up the free TX buffer ring.
This occurs with IEEE80211_SUPPORT_TDMA, as the busy buffer code isn't included otherwise. (It should be though, due to how the MAC behaves. But that's a different problem.)
The relevant output from "sysctl dev.ath.0.txagg=1" is:
HW TXQ 0: axq_depth=2, axq_aggr_depth=2
HW TXQ 1: axq_depth=0, axq_aggr_depth=0
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=0, axq_aggr_depth=0
Total TX buffers: 1; Total TX buffers busy: 1
. the fact that there's only 1 total buffer in the free list, and that one is busy, indicates that things were going pear shaped.
Also, athstats can be helpful:
# athstats | grep tx
294 tx stopped 'cuz no xmit buffer
How-To-Repeat: Just exchange a bunch of traffic whilst in a lossy 802.11 network. It should eventually get angry and stop transmitting. ifconfig wlan0 down / up will flush the TX buffer queue.
Enable both 802.11 and TDMA in the kernel configuration file (ATH_ENABLE_11N and IEEE80211_SUPPORT_TDMA.) Configure the unit as a hostap - in non-hostap mode, the interface resets will cause the TX buffer queue to be flushed.
Sit back and watch the fireworks.
Over to -wireless.
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.