I wrote some code to test my hunch. I was under the mistaken impression that each receive tasklet starts looking at receive buffers from the point where the hardware last copied data. That's not the case, as Bob mentioned in one of his emails. All receive tasklets start traversing the receive queue starting from the head.
In any case, my experiment involved incrementing a global atomic variable when receive DMA was enabled and recording in ath5k_intr the current value of the global. Later, the receive tasklet checks the global DMA count to make sure it's equal to the count stored by ath5k_intr and aborts if the counts are different. The change didn't fix anything, but it did demonstrate that DMA can be enabled several times between a call to ath5k_intr and the activation of ath5k_tacklet_rx. bob ==================== On Mon, Jun 7, 2010 at 10:20 AM, Robert Brown <robert.br...@gmail.com>wrote: > I think corruption of received data can happen whenever > ath5k_reset is called when there are pending instances of ath5k_tasklet_rx > scheduled, but not yet executed. > > ath5k_reset calls ath5k_rx_start to initialize the rxbuf queue, then sets > RXDP to the head of the queue and turns DMA back on. At some point a > delayed ath5k_tasklet_rx is run, but now there's no guarantee that DMA is > not simultaneously overwriting the data in the skb that ath5k_tasklet_rx is > handling. > > bob >
_______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
