Re: [ath5k-devel] ath5k: 2.6.32-rc6 no further txbuf available, dropping packet
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 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k: 2.6.32-rc6 no further txbuf available, dropping packet
On Mon, Jan 11, 2010 at 7:19 PM, Fabio Rossi ross...@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, sctxbuf_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 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k: 2.6.32-rc6 no further txbuf available, dropping packet
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, sctxbuf_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
Re: [ath5k-devel] ath5k: 2.6.32-rc6 no further txbuf available, dropping packet
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/ ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k: 2.6.32-rc6 no further txbuf available, dropping packet
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 ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
