ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!"

[Adrian Chadd]

http://www.freebsd.org/cgi/query-pr.cgi?pr=166190


adrian


On 16 March 2012 16:23, Adrian Chadd <adrian at freebsd.org> wrote:
> 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