Hi. Unfortunately I was unable to get those error messages again. I do have script which can catch them running, so as soon as I get them - I'll let you know. Having said that I still can say that I have connectivity problems with 'n' mode and to smaller extent with 'g' mode.
I'll be very happy to provide any other debugging information. Thanks. 2011/2/2 Felix Fietkau <n...@openwrt.org>: > 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 >>> > > -- 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
