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