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

[Fabio Rossi <rossi.f@inwind.it>]

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