On Wednesday 09 July 2008 16:37:01 Ivo van Doorn wrote: > On Wednesday 09 July 2008, Johannes Berg wrote: > > On Wed, 2008-07-09 at 16:00 +0200, Michael Buesch wrote: > > > On Wednesday 09 July 2008 16:04:50 Ivo van Doorn wrote: > > > > On Wednesday 09 July 2008, Michael Buesch wrote: > > > > > On Wednesday 09 July 2008 15:11:45 Ivo van Doorn wrote: > > > > > > Currently only beacons generated in AP mode have the software > > > > > > sequence number inserted. This means IBSS and Mesh mode are broken > > > > > > for all hardware that require software sequence numbers. > > > > > > > > > > Does software seq numbering even work at all? > > > > > What about packets that get sent between the driver requested the > > > > > beacon and the driver does actually queue it? > > > > > > > > For rt2x00 the beacon is requested and queued within interrupt context > > > > > > Well, another CPU could be in progress of walking down the mac80211 TX code > > > and aquire a sequence number in the meantime before you requested the beacon. > > > However that frame will be blocked by your driver locks, so the two seq > > > numbers of the beacon and the other frame will be swapped, as the driver > > > will queue the beacon first. > > If rt2x00 would use a global lock to block all TX and beacons, then yes. > But rt2x00 uses per-queue locking. When a beacon is being updated rt2x00 > will still allow regular frames to be queued. It still leaves a race condition window. That's actually worse than consistently breaking ;) > But we can't halt the TX queues for the beacon update either, because > ieee80211_stop_queues() should only be called from within the TX path. I think the problem can only be fixed by doing sequence numbering in the driver. -- Greetings Michael. -- 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
