On Tue, Sep 22, 2009 at 03:41:50PM -0700, Luis R. Rodriguez wrote: > flush prior to channel change? Well one theory discussed was that we > would see that issue disappear if we actually did a proper TX flush > prior to channel change since we expect we would not see further > incoming frames from our AP if we told it we were going to PS (sending > a null func frame). Yeah, but due to the way ath5k defers frames, there's still a race condition (queue some packets, flush TX to send out the nullfunc frame, then RX tasklet runs on unprocessed packets). I don't think TX flush would hurt though, then we could probably drop the driver-side code that tries to do the same. -- 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
