Am Freitag, 25. März 2011 schrieb Johannes Berg:

On Fri, 2011-03-25 at 12:08 +0100, Helmut Schaa wrote:

quoted

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.

quoted

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 ...

quoted

Generating the BAR also for filtered frames might improve the situation but
looks more like a workaround to me.

Agree.

quoted

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