On Sun, Mar 08, 2009 at 10:28:23AM +0100, Jiri Slaby wrote: >> bf_last is no longer a >> valid marker for the self-linked descriptor at the end of the loop since >> we re-add the just-processed descriptor every time through the loop >> (or am I missing something?)... > > Why? bf_last is snapshotted before the loop. And when we see this bf > while processing, we stop. In the next round we check if bf->next is > done. If yes, we move on. I think it works for the first one but doesn't take into account subsequent self-linked descriptors. E.g. if we start with buffers: A->B->C bf_last is 'C'. The hardware sees descriptors: A'->B'->C'(->C') After one round, the hardware sees: B'->C'->A'(->A') Suppose the hardware does A',B',C' before we process any buffer. So after we process A, the hardware moves on to A'. It finishes a packet, re-reads the link and starts overwriting A' again, but for some reason is really slow to complete this second packet. Now, the tasklet burns through B and C. On C we do the check if bf->next (i.e. A) is done, and it is because the hardware wrote one packet to it[1]. However, it's still in the process of writing another frame over A' again. We skip C, send A to __ieee80211_rx, the skb is freed, but the hardware is still writing stuff to it. In the trace Sitsofe posted, I didn't see any tasklets processing more than a couple of packets, though. [1] Note, the status is cleared when we hand the buffer to hardware, but not by the hardware itself when it rewrites the same buffer. That could explain why status is "martian" for overwritten frames. >> If you want I'll cook up a patch for that too. > > If you like, feel free to kick it off. Remember to remove bf->flags > completely, so that we save another bunch of memory ;). Ok, I probably won't get to it until this evening so if you prefer to do it, go ahead - otherwise I'll tackle it then. -- Bob Copeland %% www.bobcopeland.com -- 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
