Am Freitag, 25. März 2011 schrieb Johannes Berg: > On Fri, 2011-03-25 at 12:08 +0100, Helmut Schaa wrote: > > So, if a frame failed because the STA entered PS state it will be added > > to the filtered frames queue and no BAR will get generated. > > Right. Of course, if the device could help and the driver would set > IEEE80211_TX_STAT_TX_FILTERED this would be better since then the frames > wouldn't even be on the air... Yeah, unfortunately ralink devices don't seem capable of handling that in hw/fw :( > FWIW, since Intel hw uses special queues for aggregation the ucode just > stops those queues when the station goes to sleep. Caused me some grey > hair in fact since I had naively expected it to reject those frames too. > > > However, if this was the case mac80211 should send out all filtered frames > > after the STA wakes up again, which does not happen in the situation > > above (3106 and 3107 got lost) :( > > Yeah, that's in fact strange. Unless they timed out? Hmm, right, maybe I should enable mac80211 PS debugging to see if frames time out or get dropped from the buffer ... > > Generating the BAR also for filtered frames might improve the situation but > > looks more like a workaround to me. > > Agree. > > > Still debugging the rt2800 tx status reporting. > > Maybe it's not reporting the right status for all frames? So far the tx status as returned by the device look correct. I printed the sequence numbers of failed AMPDU subframes and had a second device capturing the traffic and compared them. But I noticed that there still appear holes from time to time that cause the strange Intel driver stuck problem (which is really really strange and IMHO the driver has a problem too). And it is not necessarily PS related. Johannes, what happens if a frame gets dropped on its way though the tx path after getting a seqnr assigned? That would cause a hole in the sequence number series without the chance to get a IEEE80211_TX_STAT_AMPDU_NO_BACK tx status. 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
