Johannes Berg wrote: > On Sun, 2009-07-26 at 17:52 -0500, Larry Finger wrote: >> While stress testing the newest version of the open-source firmware >> for BCM43XX devices with the latest pull of wireless-testing, I ran >> into a problem of DMA TX queue overrun. Initially I thought this was >> due to the firmware change; however, I got the same error with the >> standard firmware. I have not seen this before, but it may not be a >> regression as it seems to occur only under special circumstances. > > I've also seen it under extreme stress on Intel hardware, cf. > http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497 Fortunately, the b43 coding was robust enough to prevent queue overrun, thus we just end up with a warning. --snip-- >> The system generates the warning for ring->stopped and prints the "DMA >> queue overflow" message. > > Right. Exactly the same behaviour as I'm seeing on Intel hardware. > >> My understanding is that mac80211 serializes the calls for each TX >> queue, and that the TX callback should not have been entered for this >> case. >> >> If I am not understanding the way that mac80211 works, please correct >> me. I would also appreciate any suggestions for further debugging. > > I stared at the mac80211 code for a long time and concluded that it was > a race condition and couldn't really be fixed, see my analysis in the > iwlwifi patch. I'd love to be proved wrong though. > > Are you seeing this multiple times? I don't think you have fragmentation > on, do you? At least I didn't and still saw the problem, which seemed a > bit strange, but I really couldn't see any other way for it to happen. When it occurs, I get just a single warning. Fragmentation was not on. I will prepare a patch that acknowledges that mac80211 might send one extra fragment after the queues are stopped and only issue a warning if we get more than one. Thanks, Larry -- 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
