Date: Mon, 23 Apr 2012 01:44:46 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Lorenzo Perone <lopez.on.the.lists@yellowspace.net> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: Problems with Atheros 9280 - Any chance of an MFC or a test patch against stable/9 for your recent ath(4) work? Message-ID: <CAJ-Vmong2xUMOZ0Kro625roccdo6dX5-=0vAZp0L%2BVoaX6tc6g@mail.gmail.com> In-Reply-To: <4f94bb9d.0817440a.1e25.1907@mx.google.com> References: <4F9499DA.4000509@yellowspace.net> <4f94bb9d.0817440a.1e25.1907@mx.google.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 April 2012 19:16, Adrian Chadd <adrian.chadd@gmail.com> wrote: > Compile with ATH_DEBUG, AH_DEBUG and ATH_DIAGAPI. Then compile up > tools/tools/ath/athstats and run it for me. > To follow up: The LORs you showed (net80211 common lock and net80211 node list lock) are known. I'd like them fixed, but it's going to require a bit of re-jiggling of various bits and pieces to actually fix those. If they were -really- locking things up, you should be able to break into the debugger to find which locks are held (show alllocks) and hopefully we can then identify/fix the dead locks in question. So it could be: * A total crash - eg, because something scribbled into memory it shouldn't have, or some bit of code did something with free'd data somehow, etc * A dead lock - two (or more) locks holding things up I'd like you to run athstats -i ath0 (and then athstats -i ath0 1 for a while) to see what kind of traffic/errors you're seeing. Compiling up tools/tools/net80211/wlanstats/ and running 'wlanstats -i wlan0' (and then wlanstats -i wlan0 1 for a while) couldn't hurt too. You're running it in ap mode, not sta mode, so it's not doing lots of scanning - but are you setting a channel before you enable the hostap interface, or is it also scanning? Is it also seeing lots of stuck beacons in -HEAD ? If not, there's no continous "reset" path going on. I've mostly fixed concurrency issues in the driver; the only real issues are some subtle reset issues and 'RX PCU full' issues that I'm still trying to chase down. Both of which should be logging something. I'd also then like you to try a few things; * try adding kdb/ddb to the kernel, and then break to debugger when things have hung * try then adding the software watchdog to the kernel, enable it before you flip up the wifi device, see if it enters the debugger after the system hangs - the watchdog should fire when it's not patted (assuming it's not being patted!) and enter the debugger Finally, I've not seen this before here, but I've certainly heard the occasional rumour about this kind of behaviour occuring. I'd really like to try and narrow this down but it may take a (long) while. I'm just warning you. :) Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmong2xUMOZ0Kro625roccdo6dX5-=0vAZp0L%2BVoaX6tc6g>