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.
I have a feeling this is buggy as well. But, IIRC -- don't have the code in front of me -- ath5k_tasklet_rx takes the rxbuf lock before entering the loop, and ath5k_rx_start does as well, so the two cannot run simultaneously. Then, ath5k_tasklet_rx always looks at the head of the buffer list in its loop which should be the "new" head? We don't pass a specific skb to the tasklet, it grabs the first one in the list. Aside, IMO the buffer list doesn't really buy a whole lot, it could instead be an array with a modular index. Might be a little simpler. *shrug* And I think while it probably isn't the issue, the self-linked descriptor could probably go too in favor of halt + drain + reset on eol. -- Bob Copeland %% www.bobcopeland.com _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
