Am Mittwoch, 24. September 2008 17:59:01 schrieb Johannes Berg: > On Wed, 2008-09-24 at 17:55 +0200, Helmut Schaa wrote: > > > > What I meant to say is that it'll give problems with drivers that don't > > > do status reporting properly, and what are you going to do when one of > > > them fails anyway? retry it? how long? assume the connection was lost if > > > it isn't acked? I see little point in it to start with. > > > > The main reason why I'd like to know when the frame was acked is that it might > > happen (and it did happen in my tests already) that the frame notifying the > > AP about entering power save state wasn't send before switching to another > > channel. Hence the AP won't buffer any frames for us. > > We should make these frames able to "skip the queue" so to speak, that > would be smarter either way. Agreed. That would at least enhance the probability that the frame is sent out fast enough. > > > > > > + netif_tx_wake_all_queues(sdata->dev); > > > > > > > > > > This is worsening a problem we already have -- you can enable queues > > > > > that the driver asked to be disabled. Until we fix that, I don't think > > > > > we should tempt our luck even more. > > > > > > > > I see! That's really problematic. > > > > Do you have already an idea on how to fix it? > > > > > > Not really; introduce bits somewhere to keep track of who wants to > > > enable/disable queues I guess. > > > > A first trivial solution would be to just store which queues are active > > when the scan is started and restarting only these queues after the scan > > completed. > > Actually, well, you have to deal with drivers like adm8211 that > stop/start the queues for each packet... Oops. I did not know about drivers behaving like that => have to find a better way to deal with starting/stopping queues. Thanks, Helmut -- 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
