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
