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 _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
