On Thu, Mar 24, 2011 at 19:32, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Thu, 2011-03-24 at 14:57 +0100, Helmut Schaa wrote: > >> I guess so, yes (as I wrote before this is an Intel 5100 client running Windows >> Vista and the latest Intel driver). It sends a nullfunc going to sleep and returns >> a few hundret ms later. And in the meantime I can see my rt2800 AP sending an >> AMPDU to the sleeping STA which of course times out and therefore ends up as >> filtered frame. > > Ok so it gets reported to mac80211. > >> > Maybe the PS buffer should be larger then? >> >> 128 frames per STA is already large, no? And also it's nothing unusual >> that some frames get dropped if the STA stays in powersave for a long time. >> >> > I don't see how we can lose a >> > frame due to rx/tx processing races either, how does that happen? I >> > thought we had the ability to avoid all those races now. >> >> Good point. Maybe this only happens with rt2x00. The frame exchange looks >> basically like (if you want to see the pcap just ask ;) ): >> >> STA -> AP nullfunc PM=1 >> AP -> STA AMPDU (seqnr 3106 - 3112) >> AP -> STA AMPDU (seqnr 3106 - 3112), retry >> AP -> STA AMPDU (seqnr 3106 - 3112), retry >> AP -> STA AMPDU (seqnr 3106 - 3112), retry >> AP -> STA AMPDU (seqnr 3106 - 3112), retry >> AP -> STA AMPDU (seqnr 3106 - 3112), retry >> ... >> STA -> AP nullfunc PM=0 >> ... Hold on, why do mac80211 send a frame to a sleeping station ? Am I stupid or is this buggy ? Johannes, is this the buggy behavior in PS you were pointing out later in your mail ? >> AP -> STA AMPDU (seqnr 3108) >> STA -> AP BlockAck >> AP -> STA AMPDU (seqnr 3109 - 3114) >> STA -> AP BlockAck >> ... >> >> As you can see 3106 and 3107 somehow got lost and thus leave a hole in >> the STAs reorder buffer leading to the strange behavior I described before. > > but if they are reported to mac80211 they should be put on the queue > again? Are they maybe not reported back quite in the right way? > >> > I don't know, you tell me, does it? :) >> >> Ha Ha ;) >> >> Sending a BAR at this point would at least ensure that the Intel STAs RX >> reorder buffer gets flushed (in case we dropped any frames while the STA was >> sleeping, which happened in this case). > > Right, but so far this looks like it's more like a bug in the powersave > code rather than something we desperately need to recover from with a > BAR. > The originator tried to send data and this data didn't get acked. In this case a BAR should be sent regardless the reason why this frame didn't get acked. This is done by reporting IEEE80211_TX_STAT_AMPDU_NO_BACK to mac80211. Can it be that the rt2800 doesn't report properly the xmit failure ? -- 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
