On Fri, Jun 03, 2011 at 05:00:01AM +0000, Manoharan, Rajkumar wrote: > > On Fri, 2011-05-20 at 17:52 +0530, Rajkumar Manoharan wrote: > > > Stop tx queues before updating rate control to ensure > > > proper rate selection. Otherwise packets can be transmitted > > > in 40 Mhz whereas hw is configured in HT20. > > > > Looks like I completely missed this since you hid it in an ath9k > > patchset. DON'T DO THAT. > > Sorry for the delayed response. I was on vacation. > > > > Anyway, John, please revert. This is completely useless. Not only is > > abusing the CSA stop reason a show-stopper, the whole patch is also just > > not right, it seems like a workaround around a rate control algorithm > > that isn't able to do an atomic HT change by itself. Also, it won't even > > do what you want, there may be packets being processed concurrently > > while stopping the queue -- calling stop_queues() is no guarantee that > > no packet will be processed afterwards. > > During the channel type change, the pending tx frames in hw queues are dropped by hw config. > But before updating rate control, the packets can be queued again with older HT rates. > This contradicts with hw config mode and sometimes is causing baseband issues. This issue > was observed only on flooding uplink traffic. To ensure that the frames are always xmitted with > updated rates, the queues are stopped before hw config and waken up after rc updation. Johannes, do you find this explanation satisfactory (perhaps with some new queue stop reason definition)? John -- John W. Linville Someday the world will need a hero, and you linville@xxxxxxxxxxxxx might be all we have. Be ready. -- 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
