[ath9k-devel] Weird error messages in logs

[Nikolay Martynov <mar.kolya@gmail.com>]

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 <nbd@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 <nbd@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.kolya@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.wireless@gmail.com>:
>>>> On Wed, Feb 2, 2011 at 7:54 PM, Felix Fietkau <nbd@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 at lists.ath9k.org
>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Truthfully yours,
>>> Martynov Nikolay.
>>> Email: mar.kolya at gmail.com
>>> Phone: +16478220537
>>>
>
>



-- 
Truthfully yours,
Martynov Nikolay.
Email: mar.kolya at gmail.com
Phone: +16478220537