Date: Fri, 16 Mar 2012 16:46:16 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Vincent Hoffman <vince@unsane.co.uk> Cc: freebsd-wireless@freebsd.org Subject: Re: ath0 timeout was "Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable!" Message-ID: <CAJ-VmomqD1Q3%2Bj3AdZL8X%2B6OZyO4W1UNGqeo=Zd8YoWXBSwYSA@mail.gmail.com> In-Reply-To: <CAJ-Vmon7qRAw=y8i9xAKeG3zBjNz8NRXcLBUyNKnHXAmc%2BzKOA@mail.gmail.com> References: <CAJ-VmokYNFnNrWxk=Sg%2BhRuOhkGj5%2Bi7TGB3ni_YBT9=pjs8AQ@mail.gmail.com> <4F59DD98.8080905@unsane.co.uk> <CAJ-Vmokurdn-FGfdFuuN84a9==fdoYjAPBOd4icT-eBJ2BuGpg@mail.gmail.com> <4F5AA149.8000904@unsane.co.uk> <CAJ-VmommaSh3Y=huxpfHRbVb0j3HGXTfDNi_OHJ5Tz8_AHqCSQ@mail.gmail.com> <4F5BDF3C.8070605@unsane.co.uk> <CAJ-VmomFfAXncDp48LYQvRTL5-HG4GpnDkkAy71ReTAFRyK41A@mail.gmail.com> <4F5C0302.8090403@unsane.co.uk> <CAJ-Vmo=HpBYR6ci-dyJWJK9_OkUVC2J_bj7YknNvKwR8to0q8w@mail.gmail.com> <4F5CA45C.1010603@unsane.co.uk> <4F5E656F.4040004@unsane.co.uk> <CAJ-Vmomg4mPLA8Weii1_ohFgj8_5zng=0QBQZqS1J=xy_m8h0Q@mail.gmail.com> <4F5FC022.3040202@unsane.co.uk> <CAJ-VmokLzn1oT0MsenfmZ08n5ttBvn1S5RWnL6gD0i7KGsZ3xA@mail.gmail.com> <CAJ-Vmon7qRAw=y8i9xAKeG3zBjNz8NRXcLBUyNKnHXAmc%2BzKOA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
http://www.freebsd.org/cgi/query-pr.cgi?pr=166190 adrian On 16 March 2012 16:23, Adrian Chadd <adrian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomqD1Q3%2Bj3AdZL8X%2B6OZyO4W1UNGqeo=Zd8YoWXBSwYSA>