Re: [ath9k-devel] [RFC] ath9k: Detect and work-around tx-queue hang.

2013-03-12 Thread Ben Greear
On 02/22/2013 04:55 AM, Ben Greear wrote: On 02/22/2013 04:38 AM, Felix Fietkau wrote: On 2013-02-22 1:25 PM, Sujith Manoharan wrote: Felix Fietkau wrote: Please also check if the station(s) that the frames are queued for are in powersave state for some reason. That would prevent the tx path

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

2013-03-12 Thread abhinav narain
Hi Felix, Adrian, /* This packet was aggregated but doesn't carry status info */ if ((info-flags IEEE80211_TX_CTL_AMPDU) !(info-flags IEEE80211_TX_STAT_AMPDU)) return; Any packet with IEEE80211_TX_CTL_AMPDU and not IEEE80211_TX_STAT_AMPDU does not carry valid

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

2013-03-12 Thread Felix Fietkau
On 2013-03-13 12:48 AM, abhinav narain wrote: Hi Felix, Adrian, /* This packet was aggregated but doesn't carry status info */ if ((info-flags IEEE80211_TX_CTL_AMPDU) !(info-flags IEEE80211_TX_STAT_AMPDU)) return; Any packet with

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

2013-03-12 Thread Adrian Chadd
You need to buffer those frames in your trace right up until you get the final frame bit which tells you that hey, this has some status associated with it. It's arguable whether that's the correct thing to do or not. The better (but slower) way would be to stamp each sub-frame with the completion

Re: [ath9k-devel] Questions in 802.11 n timestamps traces for aggregated frames ?

2013-03-12 Thread abhinav narain
On Tue, Mar 12, 2013 at 7:59 PM, Adrian Chadd adr...@freebsd.org wrote: You need to buffer those frames in your trace right up until you get the final frame bit which tells you that hey, this has some status associated with it. This all the driver+mac is giving me, I haven't discarded any