On Wednesday 09 July 2008, Michael Buesch wrote: > On Wednesday 09 July 2008 17:08:04 Ivo van Doorn wrote: > > On Wednesday 09 July 2008, Johannes Berg wrote: > > > > > > > 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. > > > > > > That just widens the window. And if you have multiple queues then you > > > can't do sw sequence numbers anyway because the hardware might reorder > > > the frames. > > > > That doesn't seem to be a problem in the legacy drivers, so I guess the hardware > > does *something* to prevent problems. > > Well, legacy drivers don't use mac80211. Sequence counting can trivially be fixed > by doing it _right_ before queueing the packet to the hardware in the driver, > with the TX queue lock held, that must already be there. True, I have to double check it, but the legacy drivers use per-queue locking as well. And it would still be possible for the driver to send out frames with a higher sequence number before one with a lower number. But I'll put out a request on the rt2400-devel list to see if anybody is interested in looking into this issue for rt2400pci and rt2500pci. In if there is nobody, I'll disable adhoc and master mode for those drivers to prevent problems. Ivo -- 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
