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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
