From owner-freebsd-stable@FreeBSD.ORG Sun Nov 12 20:43:07 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 0E89B16A407 for ; Sun, 12 Nov 2006 20:43:07 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E6443D5F for ; Sun, 12 Nov 2006 20:43:05 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anc (anb.matik.com.br [200.152.88.34] (may be forged)) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kACKgwak026950 for ; Sun, 12 Nov 2006 17:42:58 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Sun, 12 Nov 2006 18:42:19 -0200 User-Agent: KMail/1.9.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200611121842.20173.joao@matik.com.br> X-Spam-Status: No, score=0.3 required=5.0 tests=ALL_TRUSTED,AWL, J_CHICKENPOX_35,MONOTONE_WORDS_15_2,MR_DIFF_MID autolearn=no version=3.1.3 X-Spam-Checker-Version: Antispam Datacenter Matik msrv.matik.com.br X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean 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:43:07 -0000 On Sunday 12 November 2006 17:32, Lamont Granquist wrote: > i saw the same behavior where tx packets would tend to > spool up and buffer. =A0here'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. =A0hopefully 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... yes and when you then look at athstats you probably see the=20 tx buffer is filled up until the interface stops=20 transmitting sooner or later It seems to me that the tx buffer never becomes empty=20 anymore when the interface raised once "tx stopped because=20 out of txbuffer" until it then completly stops tx, if you=20 are present when it happens you can get it back with=20 ifconfig down/up but when you are late you need to reset it=20 or reboot. It does not matter how high you set the=20 ath.txbuf it seems the problem comes up later when setting higher=20 values for dev.ath.0.acktimeout and dev.ath.0.ctstimeout=20 but I am still testing =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br