ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Arnd Hannemann]

Hi,

is there any reason the packet is dropped and "NETDEV_TX_OK" is returned,
in this case?
Seems pretty stupid to me, because now we are randomly dropping
packets before kernel queuing (qdisc etc) can handle them,
or am I missing something?

Best regards,
Arnd

Re: ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Bob Copeland]

On Tue, Nov 10, 2009 at 12:12 PM, Arnd Hannemann
<hannemann@nets.rwth-aachen.de> wrote:
> Hi,
>
> is there any reason the packet is dropped and "NETDEV_TX_OK" is returned,
> in this case?
> Seems pretty stupid to me, because now we are randomly dropping
> packets before kernel queuing (qdisc etc) can handle them,
> or am I missing something?

Yes, there is a good reason (there are no buffers for the hardware to
play with).  Actually mac80211 tx is never supposed to return anything
but TX_OK.

Try this patch (it needs work which is why it's not upstream yet):

http://patchwork.kernel.org/patch/56785/

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k: 2.6.32-rc6

[David Srbecky]

Bob Copeland <me@...> writes:
> Try this patch (it needs work which is why it's not upstream yet):
> 
> http://patchwork.kernel.org/patch/56785/
> 


I have been using the patch for a while and I do not have any problems anymore.

Thanks a lot,
David

Re: ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Fabio Rossi]

Hi Bob,
I have tried your patch as I get many errors as in subject when I transfer 
huge files (I'm using as a test a 1GB file). With the patch I have the same 
errors.

I'm using wireless-testing.git (v2.6.33-rc2-47131-gc72a18c) in managed mode 
(no AP).

Fabio

On Wednesday 11 November 2009 05:13:03 Bob Copeland wrote:

> Yes, there is a good reason (there are no buffers for the hardware to
> play with).  Actually mac80211 tx is never supposed to return anything
> but TX_OK.
> 
> Try this patch (it needs work which is why it's not upstream yet):
> 
> http://patchwork.kernel.org/patch/56785/
> 

Re: ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Bob Copeland]

On Fri, Jan 08, 2010 at 11:34:16PM +0100, Fabio Rossi wrote:
> Hi Bob,
> I have tried your patch as I get many errors as in subject when I transfer 
> huge files (I'm using as a test a 1GB file). With the patch I have the same 
> errors.
> 
> I'm using wireless-testing.git (v2.6.33-rc2-47131-gc72a18c) in managed mode 
> (no AP).

Ok, well the patch only will affect AP mode -- it addresses a bug where
multicast AP frames are queued but not always processed.  I wonder if your
workload is just filling up the queues and then the queues are awakened
prematurely.  There's a check in ath5k_tx_processq to only re-enable the
queue when there are 40 tx buffers left, but there are a few other paths
that re-enable the queues -- also accounting on txbuf_len could theoretically
get broken.

Maybe a printk in ath5k_tx_queue of sc->txbuf_len caN show how many buffers
are typically available when entering?

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Fabio Rossi]

On Saturday 09 January 2010 04:41:32 Bob Copeland wrote:

> Ok, well the patch only will affect AP mode -- it addresses a bug where
> multicast AP frames are queued but not always processed.  I wonder if your
> workload is just filling up the queues and then the queues are awakened
> prematurely.  There's a check in ath5k_tx_processq to only re-enable the
> queue when there are 40 tx buffers left, but there are a few other paths
> that re-enable the queues -- also accounting on txbuf_len could
>  theoretically get broken.
> 
> Maybe a printk in ath5k_tx_queue of sc->txbuf_len caN show how many buffers
> are typically available when entering?

I put a printk debug statement in ath5k_tx_queue() to see how sc->txbuf_len 
changes. The maximum number of buffers is 200 as defined by ATH_TXBUF. During 
the file transfer, sometimes, sc>txbuf_len decreases up to 1, then it changes 
to 41 and starts again to decrease up to 1, again 41 and so on for a few 
seconds. When the buffer number is 0 I can see the "no further txbuf available, 
dropping packet" message.

Fabio

Re: ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Bob Copeland]

On Mon, Jan 11, 2010 at 7:19 PM, Fabio Rossi <rossi.f@inwind.it> wrote:
> I put a printk debug statement in ath5k_tx_queue() to see how sc->txbuf_len
> changes. The maximum number of buffers is 200 as defined by ATH_TXBUF. During
> the file transfer, sometimes, sc>txbuf_len decreases up to 1, then it changes
> to 41 and starts again to decrease up to 1, again 41 and so on for a few
> seconds. When the buffer number is 0 I can see the "no further txbuf available,
> dropping packet" message.

Ok, well then at least we know that it is working :)  Do you get any ill effects
besides the log spam?  If so then there could be an issue with starvation of the
processing tasklet.  Or maybe we should look at changing the limits
for better flow.

We could also stop the queues a packet earlier, I guess.

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Fabio Rossi]

On Tuesday 12 January 2010 17:35:04 Bob Copeland wrote:

> Ok, well then at least we know that it is working :)  Do you get any ill
>  effects besides the log spam?  If so then there could be an issue with
>  starvation of the processing tasklet.  Or maybe we should look at changing
>  the limits for better flow.

I don't have problems with the connection but sometimes it's seems less 
responsive, for instance it seems the latency in loading the web pages is 
longer. Of course this is a personal impression.

I'm available to test any patches if you think the behavior may be improved, 
also simply to investigate more on the issue.

Fabio

Re: ath5k: 2.6.32-rc6 "no further txbuf available, dropping packet"

[Pavel Ulpi]

Bob Copeland <me@...> writes:

> Yes, there is a good reason (there are no buffers for the hardware to
> play with).  Actually mac80211 tx is never supposed to return anything
> but TX_OK.
> 
> Try this patch (it needs work which is why it's not upstream yet):
> 
> http://patchwork.kernel.org/patch/56785/
> 


I'm using the same configuration. This patch solved the problem for me in AP
mode too.