On Mon, Aug 01, 2011 at 09:36:30AM -0400, Bob Copeland wrote: > Our accounting for packets is currently messed up due to the > always-leave-one policy that we used in tx_processq to try to avoid DMA > problems. I don't think keeping one buffer unprocessed is the right > approach, but just disabling it (as in this patch) can regress so I need > to think about how to do that properly. This also affects the TX queue > hang timer.
Thinking more about this, and maybe this is wishful thinking, but I can't really imagine that this race in fact exists in hardware: that is, that the hardware updates the completed status field in the descriptor before reading the ds_link. Rather, I think (hope) that this issue is more some problem of locking around list updates and/or inadequate barriers. The docs that I have access to state that: - the tx descriptor is copied into device memory when processing a new packet - the host can process a descriptor as soon as the Done bit is set in status - if a null ds_link is read, the hardware pauses until txe bit is set on the queue. - if the txe bit is written after a write to txdp, then the queue picks up from the txdp - if the txe bit is written without a write to txdp, then the current descriptor is re-read from the host and the descriptor pointed to by ds_link is loaded. This is actually the usual case if we process the last packet in ath5k. So if this is true, we can test it by setting ds_link to some invalid value as soon as we read the done bit (instead of when the packet is re-queued) -- there should be no ill-effect. We just need to ensure ds_link is valid and visible to the device from the time the descriptor is linked into the chain until it is processed. I'll cook up an RFT patch for that. As for missing barriers, I have no doubt there are missing wmb()s and mmiowb()s, but I only have x86 to test with, so it would be helpful if some MIPS people can test things. -- Bob Copeland %% www.bobcopeland.com _______________________________________________ ath5k-devel mailing list [email protected] https://lists.ath5k.org/mailman/listinfo/ath5k-devel
