On 12/08/09 23:00, Johannes Berg wrote: > On Tue, 2009-12-08 at 22:56 +0100, Gertjan van Wingerde wrote: > >> Well, this is a test patch, to validate my theory that this is where the problem is. >> If that is confirmed, then I can start working out a proper solution. > > Well but this patch won't help you test that theory, because it'll just > disable PS completely if there were packets pending when mac80211 asked > you to enable PS, afaict. I don't think so, but that can be because of a big misunderstanding on my side on PS. We just do not go to sleep when being asked to by mac80211, and thus are saving less power. But awake would still work. When quickly testing the patch I did see multiple requests for enabling PS come in which were denied because of this patch. So I don't think that anything is disabled with respect to PS. > >> How does mac80211 look at these things anyway. How does it expect the driver to handle >> the cases where mac80211 asks the driver to go to sleep because of power saving, and >> the driver can't because its queues haven't drained yet? > > mac80211 does expect you to be able to transmit while asleep. Same > happens when PS-polling, where it actually expects you to wait for the > response frame too. I think. I haven't looked at this in a while. OK. If that is the case then it may very well be that the PS implementation of rt2x00 is completely broken, as I cannot find any code to wake up if any TX frames come in. Maybe the safest thing to do would be to disable powersaving from the driver until we have figured out what the proper implementation of it is for rt2x00. --- Gertjan. -- 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
