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 Busy: 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 .. Fix: Not yet. 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.
Responsible Changed From-To: freebsd-bugs->freebsd-wireless Over to -wireless.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: 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.