From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 20:59:59 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2324816A40F for ; Sun, 12 Nov 2006 20:59:59 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B5C743D7D for ; Sun, 12 Nov 2006 20:59:53 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.80] ([10.0.0.80]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kACKxqFg030064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2006 12:59:53 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <45578B48.1090704@errno.com> Date: Sun, 12 Nov 2006 12:59:52 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Lamont Granquist References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ath0 issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2006 20:59:59 -0000 Lamont Granquist wrote: > > i did the same thing with running: > > while(1) > echo foo > sleep 1 > end > > in a window ssh'd into the machine with the ath0 driver, but with the > kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0xffffffff > -- there should be packets sent every second while doing this. Not usually a good idea to enable so much debugging. The console printfs will alter operation. > > i saw the same behavior where tx packets would tend to spool up and > buffer. here's the output of one second where a bunch of spooled up > packets were sent alont with the previous second and following second > and with a note on how long it had been before any ath*tx* routine had > been called. hopefully this is useful for debugging -- i've got copious > amounts of debugging logs, so let me know if i've guessed wrongly about > what is relevant... > > this is the previous debugging notice for ath*tx* which i believe > indicates nothing > sent out on the interface since 11:17:36: If tx stops in ap mode you need to figure out whether the h/w tx q is stalled or something else "above" is blocking outbound traffic. The usual things to check are: 1. are there resources in the driver to send a packet (e.g. buffers on the queue); if the tx q is full then the OACTIVE bit will be marked on the interface and visible with ifconfig 2. if packets are queued to the h/w and not going out then you need to identify whether a higher priority frame is blocking them; this is harder but can occur when something like a beacon frame fails to go out or if there is cabq traffic q'd up behind the beacon frame that doesn't make it out 3. if none of the above is blocking traffic then h/w may consider the media busy; this can happen if your ap is operating in a busy environment and things like protection are being used heavily, or if you have an overlapping BSS that is operating in 11b Often problems such as this are most easily understood by sniffing traffic from another station and looking for traffic patterns coincident with the event on the ap. More useful information can be found in the statistics collected by the driver (use athstats). Sam