ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now
mostly (again) stable!"
Adrian Chadd
adrian at freebsd.org
Fri Mar 16 23:24:00 UTC 2012
Hi,
Yup, this seems like a concurrency issue with the driver. I'm trying
to debug exactly what's going on, but it seems that multiple
concurrent threads are doing TX and they're overlapping. I was under
the impression that all TX'ing via ath_start() would be serialised via
ifnet but apparently not. It's also possible some frames that are
legitimately going into the aggregation session (ie, they get a
sequence number and want to be ACKed) are being sent via the
ath_tx_raw() method, which bypasses the ifnet serialisation entirely.
I was reproducing it at home and in the office within 30 seconds:
* have chrome running with say, 15 tabs;
* kill -9 it so it dies very quickly;
* fire up the interface;
* fire up debug logging, which is REALLY VERBOSE btw;
* fire up chrome again;
* reload all the tabs at once;
* watch LOTS of concurrent IO go on from lots of multiple sending
threads/processes;
* then, see some buffers get "stuck" in the software queue, just like you found.
Now, why the heck is that happening.. :)
Adrian
More information about the freebsd-wireless
mailing list