Date: Sun, 12 Nov 2006 18:42:19 -0200 From: JoaoBR <joao@matik.com.br> To: freebsd-stable@freebsd.org Subject: Re: ath0 issue Message-ID: <200611121842.20173.joao@matik.com.br> In-Reply-To: <Pine.GSO.4.60.0611121126390.29168@sploit.scriptkiddie.org> References: <Pine.GSO.4.60.0611112035320.27030@sploit.scriptkiddie.org> <Pine.GSO.4.60.0611121126390.29168@sploit.scriptkiddie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611121842.20173.joao>