If he's using latest OpenWrt, he already has that patch. I believe that this issue has nothing to do with the queue stop/start state. If you take a look at the messages, it shows that txq->pending_frames is increasing over time. That can only happen if the mac80211 queues are active and the internal aggregation code is queueing up more frames.
ath9k probably ran into a state where ath_tx_form_aggr will no longer form any A-MPDU frames for the active tid, afterwards the number of pending frames gets close to the per-WMM-AC limit, which only then blocks the mac80211 queue (and that's what gets the MacBook Pro stuck in his tests until he stops pinging with the Intel STA). - Felix On 2011-02-02 4:24 PM, Mohammed Shafi wrote: > Can you please try this patch(based on the idea of suggestion of experts). > > commit 92460412367c00e97f99babdb898d0930ce604fc > Author: Felix Fietkau <n...@openwrt.org> > Date: Mon Jan 24 19:23:14 2011 +0100 > > txq_stopped is made '0' i think > > > On Wed, Feb 2, 2011 at 8:43 PM, Nikolay Martynov <mar.ko...@gmail.com> wrote: >> Hi. >> >> Sorry for the original confusion. The AP wan in 'n' mode indeed - my >> mistake - I was under impression I switched it back to 'g' mode. >> I actually noticed those error messages in logs for the first time >> yesterday, but problems with 'n' mode existed ever before, so I'm not >> sure that it is related. >> Since it looks like those error messages (as well as problems with >> 'n' mode) appear more often when there are more stations on the air - >> I'll ltry to reproduce problem again. Yesterday, at 2am connection was >> pretty stable. >> >> As I said - I probably will not be able to get contents of any /sys >> files since when those error messages happen clients seems to >> re-establish connection with AP and I just won have enough time to do >> this. >> Also - I have up to two clients on this AP, and 'n' mode is >> problematic with 'intel' client only. Macbook pro seems to work fine. >> When both clients are connected I have seen following situation: I >> start pings on both machines and on intel pings have huge packetloss, >> while on mac everything is fine. But at some point pings start to show >> huge delay - 5-10 seconds. This starts on intel and then pings on mac >> start to slow down too, although there is no packetloss on mac. If I >> stop pings on intel - mac quite quickly catches up. >> >> And one more thing: both clients are very close together but at some >> distance from AP - I do not know whether this matters. >> >> Is there any additional information I could provide to help to >> diagnose problem? >> >> By the >> >> 2011/2/2 Mohammed Shafi <shafi.wirel...@gmail.com>: >>> On Wed, Feb 2, 2011 at 7:54 PM, Felix Fietkau <n...@openwrt.org> wrote: >>>> On 2011-02-02 8:01 AM, Nikolay Martynov wrote: >>>>> Hi, >>>>> >>>>> I've got a question for you, Ben, if you do not mind. >>>>> Can it get stuck without this error message? >>>>> >>>>> The reason I'm asking is that this pair (ath9k-intel5300) has >>>>> connectivity problems which I was trying to debug with intel team and >>>>> it seems that intel card stops receiving packets at some point and >>>>> they are trying to locate an issue in there firmware. >>>>> But on the other hand can problem be in AP and - queue get stuck and >>>>> that's the reason of client not receiving any packets. >>>> In this case it definitely looks more like an AP problem. Are you sure >>>> that it is running in legacy 802.11g mode? Because I don't see yet how >>>> the AP could get into such a state without using A-MPDU and thus 802.11n. >>> >>> he said: >>> " On AP side it's router: TEW-632BRP, according to x-wrt.org it's AR5416. >>> On client side it's intel 5300. >>> I actually was wrong - network was in 'n' mode. I'm currently trying >>> to reproduce error messages with debug turned on.\". >>> >>> >>>> >>>> The interesting part in the logs shows that more and more frames keep >>>> getting added to the queue (so the mac80211 queue is active), but frames >>>> do not make it to the hardware queue (axq_depth stays at 0) >>>> >>>> The 'tx logic restart' part doesn't really do much except call the >>>> function that creates and sends A-MPDU frames, so it's normal that it >>>> cannot recover the connection by itself. >>>> >>>> - Felix >>>> _______________________________________________ >>>> ath9k-devel mailing list >>>> ath9k-devel@lists.ath9k.org >>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>>> >>> >> >> >> >> -- >> Truthfully yours, >> Martynov Nikolay. >> Email: mar.ko...@gmail.com >> Phone: +16478220537 >> _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
