From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 11 00:15:59 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6214106566C; Sun, 11 Mar 2012 00:15:59 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 41D418FC0A; Sun, 11 Mar 2012 00:15:59 +0000 (UTC) Received: from badger.unsane.co.uk (badger.unsane.co.uk [85.233.185.165]) (authenticated bits=0) by unsane.co.uk (8.14.5/8.14.5) with ESMTP id q2B0Fvmc041567 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 00:15:57 GMT (envelope-from vince@unsane.co.uk) Message-ID: <4F5BEEBC.8010600@unsane.co.uk> Date: Sun, 11 Mar 2012 00:15:56 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Adrian Chadd References: <4F59DD98.8080905@unsane.co.uk> <4F5AA149.8000904@unsane.co.uk> <4F5BDF3C.8070605@unsane.co.uk> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-wireless@freebsd.org Subject: Re: (more) bugs fixed in -HEAD, AP mode is now mostly (again) stable! X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 00:15:59 -0000 On 11/03/2012 00:00, Adrian Chadd wrote: > On 10 March 2012 15:09, Vincent Hoffman wrote: >> Ok now I'm past the panic commit, it ran fine for about 1/2 hour then I got >> Mar 10 22:37:30 ostracod kernel: ath0: device timeout >> and nothing more, which was unexpected. > Right. Well, "device timeout" can occur for a lot of reasons. > > The reason it occurs is that a TX was scheduled but the TX completion > doesn't come in, so the watchdog countdown fires. > > The cause can sometimes be because of an actual TX stall, but these > days it's almost certainly a corner case during background scanning > and/or some vap state transition. > > I know of at least one case where it's due to scan (where it does > something odd - it transitions to scan, sends out a frame, then > cancels interrupts so it can't receive the TX completion; no > subsequent TX completion occurs within 5 seconds. So it's not REALLY a > timeout, it's just bad packet handling.) I'll let the list know when > I've fixed that. > > For now, please disable bgscan (ifconfig wlan0 -bgscan.) I thought I had but i'll make sure. > >> I have >> options ATH_ENABLE_11N >> options AH_DEBUG >> options ATH_DEBUG >> options ATH_DIAGAPI >> >> in my kernel config. >> >> I've reverted to a working 11G version for now as my wife is watching >> bbc iplayer on a tv connected via that machine at the moment ;) >> If you have anything you would like me to try let me know and i'll try >> it once shes's done. > Is this in access point mode, or in station mode? Station mode. AP is a Netgear DGN3500 > >> message log from boot till the timeout (then me rebooting) at >> http://unsane.co.uk/message-ath-timeout.txt > The next time it happens, please do this: > > sysctl dev.ath.0.txagg=1 > > and then check dmesg, email the list the output. I'd like to see if > the TX queue is stuck. > > Then, force a scan: > > ifconfig wlan0 scan > > Even if it's in hostap mode, it'll cause a full TX queue flush and if > 11n TX aggregation is stuck for whatever reason, it'll complain > bitterly at you in dmesg. Will do. Vince > > Thanks, > > > Adrian