[ath9k-devel] Weird error messages in logs

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

Hi.

Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
has latest linux driver. Network operates in 801.11g mode. When client
uploads to the AP for a long time I get these errors in logs on AP:

ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0  Attempting
to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 14 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 24 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 34 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 42 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 45 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 63 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 67 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 78 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 85 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
pending frames: 89 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 94 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 101 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 108 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 113 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 120 axq_acq empty: 0 stopped: 0 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.
ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
Attempting to restart tx logic.

Transmission seems to die after this.
Could you please tell me what these messages mean and is it possible
to fix this issue on ath9k side?
Thanks!

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

[ath9k-devel] Weird error messages in logs

[Mohammed Shafi]

On Wed, Feb 2, 2011 at 11:18 AM, Nikolay Martynov <mar.kolya@gmail.com> wrote:
> Hi.
>
> Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
> has latest linux driver. Network operates in 801.11g mode. When client
> uploads to the AP for a long time I get these errors in logs on AP:
>
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0 ?Attempting
> to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 14 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 24 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 34 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 42 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 45 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 63 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 67 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 78 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 85 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 89 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 94 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 101 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 108 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 113 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 120 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
>
> Transmission seems to die after this.
> Could you please tell me what these messages mean and is it possible
> to fix this issue on ath9k side?

Looks like a tx hang and this commit will provide us more details

commit 60f2d1d506195803fa6e1dcf3972637b740fdd60
Author: Ben Greear <greearb@candelatech.com>
Date:   Sun Jan 9 23:11:52 2011 -0800

    ath9k: Restart xmit logic in xmit watchdog.

    The system can get into a state where the xmit queue
    is stopped, but there are no packets pending, so
    the queue will not be restarted.

    Add logic to the xmit watchdog to attempt to restart
    the xmit logic if this situation is detected.

    Example 'dmesg' output:

    ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link:
f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0
Attempting to restart tx logic.

sudo modprobe ath9k debug=0x481(FATAL | XMIT | RESET) will provide us
some useful debug messages


> Thanks!
>
> --
> Truthfully yours,
> Martynov Nikolay.
> Email: mar.kolya at gmail.com
> Phone: +16478220537
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Weird error messages in logs

[Ben Greear]

On 02/01/2011 09:57 PM, Mohammed Shafi wrote:
> On Wed, Feb 2, 2011 at 11:18 AM, Nikolay Martynov<mar.kolya@gmail.com>  wrote:
>> Hi.
>>
>> Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
>> has latest linux driver. Network operates in 801.11g mode. When client
>> uploads to the AP for a long time I get these errors in logs on AP:
>>
>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
>> pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0  Attempting
>> to restart tx logic.

>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
>> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
>> Attempting to restart tx logic.
>>
>> Transmission seems to die after this.
>> Could you please tell me what these messages mean and is it possible
>> to fix this issue on ath9k side?
>
> Looks like a tx hang and this commit will provide us more details
>
> commit 60f2d1d506195803fa6e1dcf3972637b740fdd60
> Author: Ben Greear<greearb@candelatech.com>
> Date:   Sun Jan 9 23:11:52 2011 -0800
>
>      ath9k: Restart xmit logic in xmit watchdog.
>
>      The system can get into a state where the xmit queue
>      is stopped, but there are no packets pending, so
>      the queue will not be restarted.
>
>      Add logic to the xmit watchdog to attempt to restart
>      the xmit logic if this situation is detected.
>
>      Example 'dmesg' output:
>
>      ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link:
> f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
>
> sudo modprobe ath9k debug=0x481(FATAL | XMIT | RESET) will provide us
> some useful debug messages

Looks like my attempt to restart is not working, for whatever reason.
There are several ways it could get stuck...my hack worked around
some of them, but obviously not all of them.

You might also look at the debugfs files while the system is in
the stuck state:

cat /debug/ieee80211/wiphy0/ath9k/stations
cat /debug/ieee80211/wiphy0/ath9k/xmit

Those show info that *might* help debug the problem...

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

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.

  Does any of this sounds reasonable?

  Really hope for your help.

Thanks.
Nikolay.

2011/2/2 Ben Greear <greearb@candelatech.com>:
> On 02/01/2011 09:57 PM, Mohammed Shafi wrote:
>>
>> On Wed, Feb 2, 2011 at 11:18 AM, Nikolay Martynov<mar.kolya@gmail.com>
>> ?wrote:
>>>
>>> Hi.
>>>
>>> Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
>>> has latest linux driver. Network operates in 801.11g mode. When client
>>> uploads to the AP for a long time I get these errors in logs on AP:
>>>
>>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
>>> pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0 ?Attempting
>>> to restart tx logic.
>
>>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
>>> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
>>> Attempting to restart tx logic.
>>>
>>> Transmission seems to die after this.
>>> Could you please tell me what these messages mean and is it possible
>>> to fix this issue on ath9k side?
>>
>> Looks like a tx hang and this commit will provide us more details
>>
>> commit 60f2d1d506195803fa6e1dcf3972637b740fdd60
>> Author: Ben Greear<greearb@candelatech.com>
>> Date: ? Sun Jan 9 23:11:52 2011 -0800
>>
>> ? ? ath9k: Restart xmit logic in xmit watchdog.
>>
>> ? ? The system can get into a state where the xmit queue
>> ? ? is stopped, but there are no packets pending, so
>> ? ? the queue will not be restarted.
>>
>> ? ? Add logic to the xmit watchdog to attempt to restart
>> ? ? the xmit logic if this situation is detected.
>>
>> ? ? Example 'dmesg' output:
>>
>> ? ? ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link:
>> f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0
>> Attempting to restart tx logic.
>>
>> sudo modprobe ath9k debug=0x481(FATAL | XMIT | RESET) will provide us
>> some useful debug messages
>
> Looks like my attempt to restart is not working, for whatever reason.
> There are several ways it could get stuck...my hack worked around
> some of them, but obviously not all of them.
>
> You might also look at the debugfs files while the system is in
> the stuck state:
>
> cat /debug/ieee80211/wiphy0/ath9k/stations
> cat /debug/ieee80211/wiphy0/ath9k/xmit
>
> Those show info that *might* help debug the problem...
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>



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

[ath9k-devel] Weird error messages in logs

[Ben Greear]

On 02/01/2011 11:01 PM, 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?

I think it will detect most problems, but not sure it will
get them all.

>    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.
>
>    Does any of this sounds reasonable?
>
>    Really hope for your help.

Well, use a sniffer on a third box..see if the ath9k is
actually transmitting.

There are lots of counters in that 'xmit' debugfs file I mentioned..
if all of those are not moving, it's likely ath9k isn't sending
anything.

You might try ping as well as whatever other traffic you are sending.
A TCP connection might get stuck before my xmit-stuck logic kicks
in, but ping will keep trying to send pkts regardless.

Thanks,
Ben


>
> Thanks.
> Nikolay.
>
> 2011/2/2 Ben Greear<greearb@candelatech.com>:
>> On 02/01/2011 09:57 PM, Mohammed Shafi wrote:
>>>
>>> On Wed, Feb 2, 2011 at 11:18 AM, Nikolay Martynov<mar.kolya@gmail.com>
>>>   wrote:
>>>>
>>>> Hi.
>>>>
>>>> Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
>>>> has latest linux driver. Network operates in 801.11g mode. When client
>>>> uploads to the AP for a long time I get these errors in logs on AP:
>>>>
>>>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
>>>> pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0  Attempting
>>>> to restart tx logic.
>>
>>>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
>>>> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
>>>> Attempting to restart tx logic.
>>>>
>>>> Transmission seems to die after this.
>>>> Could you please tell me what these messages mean and is it possible
>>>> to fix this issue on ath9k side?
>>>
>>> Looks like a tx hang and this commit will provide us more details
>>>
>>> commit 60f2d1d506195803fa6e1dcf3972637b740fdd60
>>> Author: Ben Greear<greearb@candelatech.com>
>>> Date:   Sun Jan 9 23:11:52 2011 -0800
>>>
>>>      ath9k: Restart xmit logic in xmit watchdog.
>>>
>>>      The system can get into a state where the xmit queue
>>>      is stopped, but there are no packets pending, so
>>>      the queue will not be restarted.
>>>
>>>      Add logic to the xmit watchdog to attempt to restart
>>>      the xmit logic if this situation is detected.
>>>
>>>      Example 'dmesg' output:
>>>
>>>      ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link:
>>> f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0
>>> Attempting to restart tx logic.
>>>
>>> sudo modprobe ath9k debug=0x481(FATAL | XMIT | RESET) will provide us
>>> some useful debug messages
>>
>> Looks like my attempt to restart is not working, for whatever reason.
>> There are several ways it could get stuck...my hack worked around
>> some of them, but obviously not all of them.
>>
>> You might also look at the debugfs files while the system is in
>> the stuck state:
>>
>> cat /debug/ieee80211/wiphy0/ath9k/stations
>> cat /debug/ieee80211/wiphy0/ath9k/xmit
>>
>> Those show info that *might* help debug the problem...
>>
>> Thanks,
>> Ben
>>
>>
>> --
>> Ben Greear<greearb@candelatech.com>
>> Candela Technologies Inc  http://www.candelatech.com
>>
>
>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

[ath9k-devel] Fwd: Weird error messages in logs

[Nikolay Martynov]

Hi.

?I created a small script which should dump those files, if I'm lucky enough.

?I've got several questions, if you do not mind:

?1) Shall packet loss occur if I run 'iwinfo mon.wlan0 scan'? I mean
- is it normal?

?2) How well ath9k (or wifi in general) tolerates other APs on same
channel? I have one or two near by, and it's likely that in my case
only AP, or only client 'sees' them (I.e my AP sees one different AP
on same channel, and client sees one totally different AP on same
channel). Signal is pretty week, though. Can this affect performance?
How severely?

?3) Those error messages - can they occur if for some reason client
suddenly stops ACKing packets?

Really looking forward for your responses. Thanks!

Nikolay.

2011/2/2 Ben Greear <greearb@candelatech.com>:
> On 02/01/2011 11:30 PM, Nikolay Martynov wrote:
>>
>> Hi.
>>
>> 2011/2/2 Ben Greear<greearb@candelatech.com>:
>>>
>>> On 02/01/2011 11:01 PM, 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?
>>>
>>> I think it will detect most problems, but not sure it will
>>> get them all.
>>>
>>>> ? 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.
>>>>
>>>> ? Does any of this sounds reasonable?
>>>>
>>>> ? Really hope for your help.
>>>
>>> Well, use a sniffer on a third box..see if the ath9k is
>>> actually transmitting.
>>>
>>> There are lots of counters in that 'xmit' debugfs file I mentioned..
>>> if all of those are not moving, it's likely ath9k isn't sending
>>> anything.
>>>
>>> You might try ping as well as whatever other traffic you are sending.
>>> A TCP connection might get stuck before my xmit-stuck logic kicks
>>> in, but ping will keep trying to send pkts regardless.
>>
>> ? The problem is that it gets 'unstuck' pretty fast - before I can get
>> something sniffed. I think intel renegotiates connection and
>> everything gets running. The outage period is small an I'm basically
>> unable to get any debug info during it. I get a lot of lost 'pings'
>> though, especially during the day.
>>
>> ? It seems to happen in 'n' mode only, it seems to get much worse when
>> there is other traffic on the same channel (i.e. it doesn't happen at
>> night). And it seems to happen with ath9k-intel pair only. I have
>> macbook and it is fine on same AP.
>>
>> ?Is it definitely or there is still some chance ath9k does something
>> wrong?
>
> I suspect ath9k...I've seen somewhat similar things in my testing
> (and thus all the debug stuff I put in).
>
> Maybe write a script to tail /var/log/messages and if those tx-restart
> messages start showing up, you could snapshot the debugfs files and
> save them to disk for later diagnosis?
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>



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



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

[ath9k-devel] Weird error messages in logs

[Felix Fietkau]

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.

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] Weird error messages in logs

[Mohammed Shafi]

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.

No i think he is using 802.11n(later corrected i think).

>
> 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
>

[ath9k-devel] Weird error messages in logs

[Mohammed Shafi]

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
>

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

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

[ath9k-devel] Weird error messages in logs

[Mohammed Shafi]

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
>

[ath9k-devel] Weird error messages in logs

[Felix Fietkau]

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
>>

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

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

[ath9k-devel] Weird error messages in logs

[Felix Fietkau]

What kind of connectivity problems? I'm currently working on writing
some debug code, as well as setting up some equipment to try to
reproduce issues with Intel clients connecting to ath9k APs.

- Felix

On 2011-02-03 12:56 AM, Nikolay Martynov wrote:
> 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
>>>>
>>
>>
> 
> 
> 

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

Hi.

  I basically have three types of issues:

 1) Almost no usable 'n' mode. It is somewhat usable if there is one
client on AP (and I guess relative silence in the air). If there are
two clients intel card becomes unusable - it seems to receive almost
no packets. Mac clients seems to work fine with same AP (didn't try
too long though).

  2) I often get disconnected from AP with message like: wlan1:
deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3).
This happens for no apparent reason, in 'g' mode (and probably 'n'
too, I just do not run 'n' long enough). And this happens with macbook
too. I'm not sure that message is always the same - often there is no
disconnection message. When client tries to connect back there are
different types of timeouts:
   a) on the client (intel):
[78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3)
[78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3)
[78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3)
[78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out
   b) on the client (intel):
[78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1)
[78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2)
[78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3)
[78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out
  a) and b) happen on intel. I often see 'timeout' in similar mac UI,
but I do not know how to get any diagnostics from mac.
  At the same time on AP:
   b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout
   c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
acknowledge association response
   b) and c) happen for both intel and mac clients. Moreover - one
client may keep trying to connect while other stays connected and
works fine. But if other disconnects it has problems connecting too.
Problem usually can be fixed by restarting 'wifi' on router. I do not
really know whether this is a ath9k problem, or some hostapd issue.
This may happen several times an hour, but sometimes doesn't happen
for hours. 'Disconnection' part happens more often on intel client.

  3) Intel seems to loose heavy loaded tcp connection sometimes. I.e.
I upload something from laptop to machine connected by wire on the
same router and at some point upload stops and connection timeouts.
Or, if a type a lot of stuff in SSH session - ssh session locks. Looks
like bunch of packets get lost and tcp cannot recover. This happens in
'g' mode. Often enough so I cannot upload 600Mb file without loosing
connection. Mac doesn't seem to have this problem.

  I have TEW-326BRP with trunk openwrt (kernel 2.6.37).
  On the client - dell laptop with intel5300, to which I have only two
antennas connected - I replaced card from non-'n' and laptop has only
two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest
compat wireless + exp ucode + patch from
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214.
  Another client - macbook pro.
  I think I'm about 30 meters from AP - AP is no second floor and I'm
in the basement (basement has concrete walls - this might affect
signal quality I guess).

  It'd be really great to have reliable wifi, so I can devote time and
do whatever testing required.
  Please let me know how I can help.
  Thanks!

2011/2/2 Felix Fietkau <nbd@openwrt.org>:
> What kind of connectivity problems? I'm currently working on writing
> some debug code, as well as setting up some equipment to try to
> reproduce issues with Intel clients connecting to ath9k APs.
>
> - Felix
>
> On 2011-02-03 12:56 AM, Nikolay Martynov wrote:
>> 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

[ath9k-devel] Weird error messages in logs

[Felix Fietkau]

Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch
into package/mac80211/patches/ in your OpenWrt build tree.

Then recompile and update the ath9k package on your AP and see if it
prints the "Aggregation session blocked..." messages when tx to the
Intel client stops working.

Thanks,

- Felix

On 2011-02-03 2:46 AM, Nikolay Martynov wrote:
> Hi.
> 
>   I basically have three types of issues:
> 
>  1) Almost no usable 'n' mode. It is somewhat usable if there is one
> client on AP (and I guess relative silence in the air). If there are
> two clients intel card becomes unusable - it seems to receive almost
> no packets. Mac clients seems to work fine with same AP (didn't try
> too long though).
> 
>   2) I often get disconnected from AP with message like: wlan1:
> deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3).
> This happens for no apparent reason, in 'g' mode (and probably 'n'
> too, I just do not run 'n' long enough). And this happens with macbook
> too. I'm not sure that message is always the same - often there is no
> disconnection message. When client tries to connect back there are
> different types of timeouts:
>    a) on the client (intel):
> [78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3)
> [78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3)
> [78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3)
> [78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out
>    b) on the client (intel):
> [78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1)
> [78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2)
> [78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3)
> [78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out
>   a) and b) happen on intel. I often see 'timeout' in similar mac UI,
> but I do not know how to get any diagnostics from mac.
>   At the same time on AP:
>    b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout
>    c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
> acknowledge association response
>    b) and c) happen for both intel and mac clients. Moreover - one
> client may keep trying to connect while other stays connected and
> works fine. But if other disconnects it has problems connecting too.
> Problem usually can be fixed by restarting 'wifi' on router. I do not
> really know whether this is a ath9k problem, or some hostapd issue.
> This may happen several times an hour, but sometimes doesn't happen
> for hours. 'Disconnection' part happens more often on intel client.
> 
>   3) Intel seems to loose heavy loaded tcp connection sometimes. I.e.
> I upload something from laptop to machine connected by wire on the
> same router and at some point upload stops and connection timeouts.
> Or, if a type a lot of stuff in SSH session - ssh session locks. Looks
> like bunch of packets get lost and tcp cannot recover. This happens in
> 'g' mode. Often enough so I cannot upload 600Mb file without loosing
> connection. Mac doesn't seem to have this problem.
> 
>   I have TEW-326BRP with trunk openwrt (kernel 2.6.37).
>   On the client - dell laptop with intel5300, to which I have only two
> antennas connected - I replaced card from non-'n' and laptop has only
> two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest
> compat wireless + exp ucode + patch from
> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214.
>   Another client - macbook pro.
>   I think I'm about 30 meters from AP - AP is no second floor and I'm
> in the basement (basement has concrete walls - this might affect
> signal quality I guess).
> 
>   It'd be really great to have reliable wifi, so I can devote time and
> do whatever testing required.
>   Please let me know how I can help.
>   Thanks!

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

Hi.

  Installed new patch and do not have intel stuck yet. Although there
is still 10-15% ping loss. But not new error messages in dmesg/log.
I'll keep testing.

  Two updates:

  1) last problem I mentioned in previous letter seems to be caused by
swcrypt=1 on intel side. I just turned it on yesterday and didn't
realize it can cause such issues. But now I turned it off and it seems
to be fine.
  2) in router logs there are often messages about inability of driver
to stop rx or tx dma, I'm not sure whether this is relevant or not.

Thanks.
Nikolay.

2011/2/2 Felix Fietkau <nbd@openwrt.org>:
> Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch
> into package/mac80211/patches/ in your OpenWrt build tree.
>
> Then recompile and update the ath9k package on your AP and see if it
> prints the "Aggregation session blocked..." messages when tx to the
> Intel client stops working.
>
> Thanks,
>
> - Felix
>
> On 2011-02-03 2:46 AM, Nikolay Martynov wrote:
>> Hi.
>>
>> ? I basically have three types of issues:
>>
>> ?1) Almost no usable 'n' mode. It is somewhat usable if there is one
>> client on AP (and I guess relative silence in the air). If there are
>> two clients intel card becomes unusable - it seems to receive almost
>> no packets. Mac clients seems to work fine with same AP (didn't try
>> too long though).
>>
>> ? 2) I often get disconnected from AP with message like: wlan1:
>> deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3).
>> This happens for no apparent reason, in 'g' mode (and probably 'n'
>> too, I just do not run 'n' long enough). And this happens with macbook
>> too. I'm not sure that message is always the same - often there is no
>> disconnection message. When client tries to connect back there are
>> different types of timeouts:
>> ? ?a) on the client (intel):
>> [78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3)
>> [78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3)
>> [78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3)
>> [78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out
>> ? ?b) on the client (intel):
>> [78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1)
>> [78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2)
>> [78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3)
>> [78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out
>> ? a) and b) happen on intel. I often see 'timeout' in similar mac UI,
>> but I do not know how to get any diagnostics from mac.
>> ? At the same time on AP:
>> ? ?b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout
>> ? ?c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
>> acknowledge association response
>> ? ?b) and c) happen for both intel and mac clients. Moreover - one
>> client may keep trying to connect while other stays connected and
>> works fine. But if other disconnects it has problems connecting too.
>> Problem usually can be fixed by restarting 'wifi' on router. I do not
>> really know whether this is a ath9k problem, or some hostapd issue.
>> This may happen several times an hour, but sometimes doesn't happen
>> for hours. 'Disconnection' part happens more often on intel client.
>>
>> ? 3) Intel seems to loose heavy loaded tcp connection sometimes. I.e.
>> I upload something from laptop to machine connected by wire on the
>> same router and at some point upload stops and connection timeouts.
>> Or, if a type a lot of stuff in SSH session - ssh session locks. Looks
>> like bunch of packets get lost and tcp cannot recover. This happens in
>> 'g' mode. Often enough so I cannot upload 600Mb file without loosing
>> connection. Mac doesn't seem to have this problem.
>>
>> ? I have TEW-326BRP with trunk openwrt (kernel 2.6.37).
>> ? On the client - dell laptop with intel5300, to which I have only two
>> antennas connected - I replaced card from non-'n' and laptop has only
>> two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest
>> compat wireless + exp ucode + patch from
>> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214.
>> ? Another client - macbook pro.
>> ? I think I'm about 30 meters from AP - AP is no second floor and I'm
>> in the basement (basement has concrete walls - this might affect
>> signal quality I guess).
>>
>> ? It'd be really great to have reliable wifi, so I can devote time and
>> do whatever testing required.
>> ? Please let me know how I can help.
>> ? Thanks!
>



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

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

Hi.

  One more thing I've noticed.
  When I do tcpdump on intel mon interface I get quite a lot of
traffic. When I do same thing on router - I hardly see any traffic. Is
this expected?
  This actually regards problem when client cannot reconnect to router
- in this state even though client send association and authentication
requests it doesn't get response.

  Can these two things be related? Is there any chance ath9k can loose
some received control packets or 'forget' to send them?

  Thanks.

2011/2/2 Nikolay Martynov <mar.kolya@gmail.com>:
> Hi.
>
> ?Installed new patch and do not have intel stuck yet. Although there
> is still 10-15% ping loss. But not new error messages in dmesg/log.
> I'll keep testing.
>
> ?Two updates:
>
> ?1) last problem I mentioned in previous letter seems to be caused by
> swcrypt=1 on intel side. I just turned it on yesterday and didn't
> realize it can cause such issues. But now I turned it off and it seems
> to be fine.
> ?2) in router logs there are often messages about inability of driver
> to stop rx or tx dma, I'm not sure whether this is relevant or not.
>
> Thanks.
> Nikolay.
>
> 2011/2/2 Felix Fietkau <nbd@openwrt.org>:
>> Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch
>> into package/mac80211/patches/ in your OpenWrt build tree.
>>
>> Then recompile and update the ath9k package on your AP and see if it
>> prints the "Aggregation session blocked..." messages when tx to the
>> Intel client stops working.
>>
>> Thanks,
>>
>> - Felix
>>
>> On 2011-02-03 2:46 AM, Nikolay Martynov wrote:
>>> Hi.
>>>
>>> ? I basically have three types of issues:
>>>
>>> ?1) Almost no usable 'n' mode. It is somewhat usable if there is one
>>> client on AP (and I guess relative silence in the air). If there are
>>> two clients intel card becomes unusable - it seems to receive almost
>>> no packets. Mac clients seems to work fine with same AP (didn't try
>>> too long though).
>>>
>>> ? 2) I often get disconnected from AP with message like: wlan1:
>>> deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3).
>>> This happens for no apparent reason, in 'g' mode (and probably 'n'
>>> too, I just do not run 'n' long enough). And this happens with macbook
>>> too. I'm not sure that message is always the same - often there is no
>>> disconnection message. When client tries to connect back there are
>>> different types of timeouts:
>>> ? ?a) on the client (intel):
>>> [78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3)
>>> [78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3)
>>> [78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3)
>>> [78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out
>>> ? ?b) on the client (intel):
>>> [78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1)
>>> [78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2)
>>> [78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3)
>>> [78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out
>>> ? a) and b) happen on intel. I often see 'timeout' in similar mac UI,
>>> but I do not know how to get any diagnostics from mac.
>>> ? At the same time on AP:
>>> ? ?b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout
>>> ? ?c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
>>> acknowledge association response
>>> ? ?b) and c) happen for both intel and mac clients. Moreover - one
>>> client may keep trying to connect while other stays connected and
>>> works fine. But if other disconnects it has problems connecting too.
>>> Problem usually can be fixed by restarting 'wifi' on router. I do not
>>> really know whether this is a ath9k problem, or some hostapd issue.
>>> This may happen several times an hour, but sometimes doesn't happen
>>> for hours. 'Disconnection' part happens more often on intel client.
>>>
>>> ? 3) Intel seems to loose heavy loaded tcp connection sometimes. I.e.
>>> I upload something from laptop to machine connected by wire on the
>>> same router and at some point upload stops and connection timeouts.
>>> Or, if a type a lot of stuff in SSH session - ssh session locks. Looks
>>> like bunch of packets get lost and tcp cannot recover. This happens in
>>> 'g' mode. Often enough so I cannot upload 600Mb file without loosing
>>> connection. Mac doesn't seem to have this problem.
>>>
>>> ? I have TEW-326BRP with trunk openwrt (kernel 2.6.37).
>>> ? On the client - dell laptop with intel5300, to which I have only two
>>> antennas connected - I replaced card from non-'n' and laptop has only
>>> two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest
>>> compat wireless + exp ucode + patch from
>>> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214.
>>> ? Another client - macbook pro.
>>> ? I think I'm about 30 meters from AP - AP is no second floor and I'm
>>> in the basement (basement has concrete walls - this might affect
>>> signal quality I guess).
>>>
>>> ? It'd be really great to have reliable wifi, so I can devote time and
>>> do whatever testing required.
>>> ? Please let me know how I can help.
>>> ? Thanks!
>>
>
>
>
> --
> Truthfully yours,
> Martynov Nikolay.
> Email: mar.kolya at gmail.com
> Phone: +16478220537
>



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

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

Hi,

  So I did manage to 'stuck' it again.

  Ping looks like this:
64 bytes from 192.168.1.1: icmp_req=128 ttl=64 time=12408 ms
64 bytes from 192.168.1.1: icmp_req=129 ttl=64 time=11408 ms
64 bytes from 192.168.1.1: icmp_req=130 ttl=64 time=10408 ms
64 bytes from 192.168.1.1: icmp_req=132 ttl=64 time=8942 ms
64 bytes from 192.168.1.1: icmp_req=133 ttl=64 time=7942 ms
64 bytes from 192.168.1.1: icmp_req=134 ttl=64 time=6942 ms
64 bytes from 192.168.1.1: icmp_req=135 ttl=64 time=5942 ms
64 bytes from 192.168.1.1: icmp_req=136 ttl=64 time=4979 ms
64 bytes from 192.168.1.1: icmp_req=137 ttl=64 time=3981 ms
64 bytes from 192.168.1.1: icmp_req=138 ttl=64 time=2981 ms
64 bytes from 192.168.1.1: icmp_req=140 ttl=64 time=10829 ms
64 bytes from 192.168.1.1: icmp_req=141 ttl=64 time=9901 ms
64 bytes from 192.168.1.1: icmp_req=142 ttl=64 time=8925 ms
64 bytes from 192.168.1.1: icmp_req=145 ttl=64 time=6588 ms
64 bytes from 192.168.1.1: icmp_req=146 ttl=64 time=6139 ms
64 bytes from 192.168.1.1: icmp_req=147 ttl=64 time=5133 ms
64 bytes from 192.168.1.1: icmp_req=148 ttl=64 time=4125 ms
64 bytes from 192.168.1.1: icmp_req=149 ttl=64 time=3117 ms
64 bytes from 192.168.1.1: icmp_req=150 ttl=64 time=2109 ms

There were no "Aggregation session blocked" messages in logs.
Here what I've captured:

root at router:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/xmit
Num-Tx-Queues: 10  tx-queues-setup: 0x10f poll-work-seen: 8164
                            BE         BK        VI        VO

MPDUs Queued:          1129641          0         0      2884
MPDUs Completed:       1129641          0         0      2884
Aggregates:             626250          0         0         0
AMPDUs Queued HW:       656532          0         0         0
AMPDUs Queued SW:      4095017          0         0         0
AMPDUs Completed:      4749880          0         0         0
AMPDUs Retried:         197274          0         0         0
AMPDUs XRetried:          1594          0         0         0
FIFO Underrun:               0          0         0         0
TXOP Exceeded:               0          0         0         0
TXTIMER Expiry:              0          0         0         0
DESC CFG Error:              0          0         0         0
DATA Underrun:               0          0         0         0
DELIM Underrun:              0          0         0         0
TX-Pkts-All:           5881115          0         0      2884
TX-Bytes-All:       2056395884          0         0    227872
hw-put-tx-buf:              25          0         0        25
hw-tx-start:           2709929          0         0      2884
hw-tx-proc-desc:       2709441          0         0      2883
txq-memory-address:   80d1db74   80d1db78  80d1db70  80d1db6c
axq-qnum:                    2          3         1         0
axq-depth:                   2          0         0         0
axq-ampdu_depth:             2          0         0         0
axq-stopped                  0          0         0         0
tx-in-progress               0          0         0         0
pending-frames              60          0         0         0
txq_headidx:                 0          0         0         0
txq_tailidx:                 0          0         0         0
axq_q empty:                   0          1         1         0
axq_acq empty:                 0          1         1         1
txq_fifo_pending:              1          1         1         1
txq_fifo[0] empty:             1          1         1         1
txq_fifo[1] empty:             1          1         1         1
txq_fifo[2] empty:             1          1         1         1
txq_fifo[3] empty:             1          1         1         1
txq_fifo[4] empty:             1          1         1         1
txq_fifo[5] empty:             1          1         1         1
txq_fifo[6] empty:             1          1         1         1
txq_fifo[7] empty:             1          1         1         1
txq[2] first-ac: 80b05f18 sched: 1
 first-tid: 80b05a28 sched: 1 paused: 0
root at router:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/stations
Stations:
 tid: addr sched paused buf_q-empty an ac
 ac: addr sched tid_q-empty txq
00:21:6a:70:18:56
 tid: 80b04a28 sched running 0 80b04a1c 80b04f18
 tid: 80b04a74 idle running 1 80b04a1c 80b04f30
 tid: 80b04ac0 idle running 1 80b04a1c 80b04f30
 tid: 80b04b0c idle running 1 80b04a1c 80b04f18
 tid: 80b04b58 idle running 1 80b04a1c 80b04f00
 tid: 80b04ba4 idle running 1 80b04a1c 80b04f00
 tid: 80b04bf0 idle running 1 80b04a1c 80b04ee8
 tid: 80b04c3c idle running 1 80b04a1c 80b04ee8
 tid: 80b04c88 idle running 1 80b04a1c 80b04ee8
 tid: 80b04cd4 idle running 1 80b04a1c 80b04ee8
 tid: 80b04d20 idle running 1 80b04a1c 80b04ee8
 tid: 80b04d6c idle running 1 80b04a1c 80b04ee8
 tid: 80b04db8 idle running 1 80b04a1c 80b04ee8
 tid: 80b04e04 idle running 1 80b04a1c 80b04ee8
 tid: 80b04e50 idle running 1 80b04a1c 80b04ee8
 tid: 80b04e9c idle running 1 80b04a1c 80b04ee8
 ac: 80b04ee8 idle 1 80d1d6ac
 ac: 80b04f00 idle 1 80d1d724
 ac: 80b04f18 sched 0 80d1d79c
 ac: 80b04f30 idle 1 80d1d814
f0:b4:79:22:71:85
 tid: 80b05a28 idle running 1 80b05a1c 80b05f18
 tid: 80b05a74 idle running 1 80b05a1c 80b05f30
 tid: 80b05ac0 idle running 1 80b05a1c 80b05f30
 tid: 80b05b0c idle running 1 80b05a1c 80b05f18
 tid: 80b05b58 idle running 1 80b05a1c 80b05f00
 tid: 80b05ba4 idle running 1 80b05a1c 80b05f00
 tid: 80b05bf0 idle running 1 80b05a1c 80b05ee8
 tid: 80b05c3c idle running 1 80b05a1c 80b05ee8
 tid: 80b05c88 idle running 1 80b05a1c 80b05ee8
 tid: 80b05cd4 idle running 1 80b05a1c 80b05ee8
 tid: 80b05d20 idle running 1 80b05a1c 80b05ee8
 tid: 80b05d6c idle running 1 80b05a1c 80b05ee8
 tid: 80b05db8 idle running 1 80b05a1c 80b05ee8
 tid: 80b05e04 idle running 1 80b05a1c 80b05ee8
 tid: 80b05e50 idle running 1 80b05a1c 80b05ee8
 tid: 80b05e9c idle running 1 80b05a1c 80b05ee8
 ac: 80b05ee8 idle 1 80d1d6ac
 ac: 80b05f00 idle 1 80d1d724
 ac: 80b05f18 idle 1 80d1d79c
 ac: 80b05f30 idle 1 80d1d814
root at router:~# logread | tail
Feb  2 23:56:36 router user.err kernel: ath: Failed to stop TX DMA!
Feb  3 00:01:33 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
WPA: group key handshake completed (RSN)
Feb  3 00:01:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
WPA: group key handshake completed (RSN)
Feb  3 00:04:26 router user.info kernel: device mon.wlan0 left promiscuous mode
Feb  3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
IEEE 802.11: authenticated
Feb  3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
IEEE 802.11: associated (aid 1)
Feb  3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
WPA: pairwise key handshake completed (RSN)
Feb  3 00:11:33 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
WPA: group key handshake completed (RSN)
Feb  3 00:11:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
WPA: group key handshake completed (RSN)
Feb  3 00:11:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
WPA: received EAPOL-Key 2/2 Group with unexpected replay counter

Please let me know if this was useful and what kind if other
information you may need.
Thanks.



2011/2/2 Nikolay Martynov <mar.kolya@gmail.com>:
> Hi.
>
> ?One more thing I've noticed.
> ?When I do tcpdump on intel mon interface I get quite a lot of
> traffic. When I do same thing on router - I hardly see any traffic. Is
> this expected?
> ?This actually regards problem when client cannot reconnect to router
> - in this state even though client send association and authentication
> requests it doesn't get response.
>
> ?Can these two things be related? Is there any chance ath9k can loose
> some received control packets or 'forget' to send them?
>
> ?Thanks.
>
> 2011/2/2 Nikolay Martynov <mar.kolya@gmail.com>:
>> Hi.
>>
>> ?Installed new patch and do not have intel stuck yet. Although there
>> is still 10-15% ping loss. But not new error messages in dmesg/log.
>> I'll keep testing.
>>
>> ?Two updates:
>>
>> ?1) last problem I mentioned in previous letter seems to be caused by
>> swcrypt=1 on intel side. I just turned it on yesterday and didn't
>> realize it can cause such issues. But now I turned it off and it seems
>> to be fine.
>> ?2) in router logs there are often messages about inability of driver
>> to stop rx or tx dma, I'm not sure whether this is relevant or not.
>>
>> Thanks.
>> Nikolay.
>>
>> 2011/2/2 Felix Fietkau <nbd@openwrt.org>:
>>> Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch
>>> into package/mac80211/patches/ in your OpenWrt build tree.
>>>
>>> Then recompile and update the ath9k package on your AP and see if it
>>> prints the "Aggregation session blocked..." messages when tx to the
>>> Intel client stops working.
>>>
>>> Thanks,
>>>
>>> - Felix
>>>
>>> On 2011-02-03 2:46 AM, Nikolay Martynov wrote:
>>>> Hi.
>>>>
>>>> ? I basically have three types of issues:
>>>>
>>>> ?1) Almost no usable 'n' mode. It is somewhat usable if there is one
>>>> client on AP (and I guess relative silence in the air). If there are
>>>> two clients intel card becomes unusable - it seems to receive almost
>>>> no packets. Mac clients seems to work fine with same AP (didn't try
>>>> too long though).
>>>>
>>>> ? 2) I often get disconnected from AP with message like: wlan1:
>>>> deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3).
>>>> This happens for no apparent reason, in 'g' mode (and probably 'n'
>>>> too, I just do not run 'n' long enough). And this happens with macbook
>>>> too. I'm not sure that message is always the same - often there is no
>>>> disconnection message. When client tries to connect back there are
>>>> different types of timeouts:
>>>> ? ?a) on the client (intel):
>>>> [78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3)
>>>> [78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3)
>>>> [78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3)
>>>> [78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out
>>>> ? ?b) on the client (intel):
>>>> [78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1)
>>>> [78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2)
>>>> [78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3)
>>>> [78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out
>>>> ? a) and b) happen on intel. I often see 'timeout' in similar mac UI,
>>>> but I do not know how to get any diagnostics from mac.
>>>> ? At the same time on AP:
>>>> ? ?b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout
>>>> ? ?c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
>>>> acknowledge association response
>>>> ? ?b) and c) happen for both intel and mac clients. Moreover - one
>>>> client may keep trying to connect while other stays connected and
>>>> works fine. But if other disconnects it has problems connecting too.
>>>> Problem usually can be fixed by restarting 'wifi' on router. I do not
>>>> really know whether this is a ath9k problem, or some hostapd issue.
>>>> This may happen several times an hour, but sometimes doesn't happen
>>>> for hours. 'Disconnection' part happens more often on intel client.
>>>>
>>>> ? 3) Intel seems to loose heavy loaded tcp connection sometimes. I.e.
>>>> I upload something from laptop to machine connected by wire on the
>>>> same router and at some point upload stops and connection timeouts.
>>>> Or, if a type a lot of stuff in SSH session - ssh session locks. Looks
>>>> like bunch of packets get lost and tcp cannot recover. This happens in
>>>> 'g' mode. Often enough so I cannot upload 600Mb file without loosing
>>>> connection. Mac doesn't seem to have this problem.
>>>>
>>>> ? I have TEW-326BRP with trunk openwrt (kernel 2.6.37).
>>>> ? On the client - dell laptop with intel5300, to which I have only two
>>>> antennas connected - I replaced card from non-'n' and laptop has only
>>>> two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest
>>>> compat wireless + exp ucode + patch from
>>>> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214.
>>>> ? Another client - macbook pro.
>>>> ? I think I'm about 30 meters from AP - AP is no second floor and I'm
>>>> in the basement (basement has concrete walls - this might affect
>>>> signal quality I guess).
>>>>
>>>> ? It'd be really great to have reliable wifi, so I can devote time and
>>>> do whatever testing required.
>>>> ? Please let me know how I can help.
>>>> ? Thanks!
>>>
>>
>>
>>
>> --
>> Truthfully yours,
>> Martynov Nikolay.
>> Email: mar.kolya at gmail.com
>> Phone: +16478220537
>>
>
>
>
> --
> Truthfully yours,
> Martynov Nikolay.
> Email: mar.kolya at gmail.com
> Phone: +16478220537
>



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

[ath9k-devel] Weird error messages in logs

[Nikolay Martynov]

Hi,

  Is there anything I can do to help with this problem? Any additional
information/testing/etc?
  Are the logs I've sent before of any use?

Thanks.

2011/2/3 Nikolay Martynov <mar.kolya@gmail.com>:
> Hi,
>
> ?So I did manage to 'stuck' it again.
>
> ?Ping looks like this:
> 64 bytes from 192.168.1.1: icmp_req=128 ttl=64 time=12408 ms
> 64 bytes from 192.168.1.1: icmp_req=129 ttl=64 time=11408 ms
> 64 bytes from 192.168.1.1: icmp_req=130 ttl=64 time=10408 ms
> 64 bytes from 192.168.1.1: icmp_req=132 ttl=64 time=8942 ms
> 64 bytes from 192.168.1.1: icmp_req=133 ttl=64 time=7942 ms
> 64 bytes from 192.168.1.1: icmp_req=134 ttl=64 time=6942 ms
> 64 bytes from 192.168.1.1: icmp_req=135 ttl=64 time=5942 ms
> 64 bytes from 192.168.1.1: icmp_req=136 ttl=64 time=4979 ms
> 64 bytes from 192.168.1.1: icmp_req=137 ttl=64 time=3981 ms
> 64 bytes from 192.168.1.1: icmp_req=138 ttl=64 time=2981 ms
> 64 bytes from 192.168.1.1: icmp_req=140 ttl=64 time=10829 ms
> 64 bytes from 192.168.1.1: icmp_req=141 ttl=64 time=9901 ms
> 64 bytes from 192.168.1.1: icmp_req=142 ttl=64 time=8925 ms
> 64 bytes from 192.168.1.1: icmp_req=145 ttl=64 time=6588 ms
> 64 bytes from 192.168.1.1: icmp_req=146 ttl=64 time=6139 ms
> 64 bytes from 192.168.1.1: icmp_req=147 ttl=64 time=5133 ms
> 64 bytes from 192.168.1.1: icmp_req=148 ttl=64 time=4125 ms
> 64 bytes from 192.168.1.1: icmp_req=149 ttl=64 time=3117 ms
> 64 bytes from 192.168.1.1: icmp_req=150 ttl=64 time=2109 ms
>
> There were no "Aggregation session blocked" messages in logs.
> Here what I've captured:
>
> root at router:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/xmit
> Num-Tx-Queues: 10 ?tx-queues-setup: 0x10f poll-work-seen: 8164
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?BE ? ? ? ? BK ? ? ? ?VI ? ? ? ?VO
>
> MPDUs Queued: ? ? ? ? ?1129641 ? ? ? ? ?0 ? ? ? ? 0 ? ? ?2884
> MPDUs Completed: ? ? ? 1129641 ? ? ? ? ?0 ? ? ? ? 0 ? ? ?2884
> Aggregates: ? ? ? ? ? ? 626250 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> AMPDUs Queued HW: ? ? ? 656532 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> AMPDUs Queued SW: ? ? ?4095017 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> AMPDUs Completed: ? ? ?4749880 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> AMPDUs Retried: ? ? ? ? 197274 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> AMPDUs XRetried: ? ? ? ? ?1594 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> FIFO Underrun: ? ? ? ? ? ? ? 0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> TXOP Exceeded: ? ? ? ? ? ? ? 0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> TXTIMER Expiry: ? ? ? ? ? ? ?0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> DESC CFG Error: ? ? ? ? ? ? ?0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> DATA Underrun: ? ? ? ? ? ? ? 0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> DELIM Underrun: ? ? ? ? ? ? ?0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> TX-Pkts-All: ? ? ? ? ? 5881115 ? ? ? ? ?0 ? ? ? ? 0 ? ? ?2884
> TX-Bytes-All: ? ? ? 2056395884 ? ? ? ? ?0 ? ? ? ? 0 ? ?227872
> hw-put-tx-buf: ? ? ? ? ? ? ?25 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ?25
> hw-tx-start: ? ? ? ? ? 2709929 ? ? ? ? ?0 ? ? ? ? 0 ? ? ?2884
> hw-tx-proc-desc: ? ? ? 2709441 ? ? ? ? ?0 ? ? ? ? 0 ? ? ?2883
> txq-memory-address: ? 80d1db74 ? 80d1db78 ?80d1db70 ?80d1db6c
> axq-qnum: ? ? ? ? ? ? ? ? ? ?2 ? ? ? ? ?3 ? ? ? ? 1 ? ? ? ? 0
> axq-depth: ? ? ? ? ? ? ? ? ? 2 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> axq-ampdu_depth: ? ? ? ? ? ? 2 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> axq-stopped ? ? ? ? ? ? ? ? ?0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> tx-in-progress ? ? ? ? ? ? ? 0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> pending-frames ? ? ? ? ? ? ?60 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> txq_headidx: ? ? ? ? ? ? ? ? 0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> txq_tailidx: ? ? ? ? ? ? ? ? 0 ? ? ? ? ?0 ? ? ? ? 0 ? ? ? ? 0
> axq_q empty: ? ? ? ? ? ? ? ? ? 0 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 0
> axq_acq empty: ? ? ? ? ? ? ? ? 0 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo_pending: ? ? ? ? ? ? ?1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[0] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[1] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[2] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[3] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[4] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[5] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[6] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq_fifo[7] empty: ? ? ? ? ? ? 1 ? ? ? ? ?1 ? ? ? ? 1 ? ? ? ? 1
> txq[2] first-ac: 80b05f18 sched: 1
> ?first-tid: 80b05a28 sched: 1 paused: 0
> root at router:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/stations
> Stations:
> ?tid: addr sched paused buf_q-empty an ac
> ?ac: addr sched tid_q-empty txq
> 00:21:6a:70:18:56
> ?tid: 80b04a28 sched running 0 80b04a1c 80b04f18
> ?tid: 80b04a74 idle running 1 80b04a1c 80b04f30
> ?tid: 80b04ac0 idle running 1 80b04a1c 80b04f30
> ?tid: 80b04b0c idle running 1 80b04a1c 80b04f18
> ?tid: 80b04b58 idle running 1 80b04a1c 80b04f00
> ?tid: 80b04ba4 idle running 1 80b04a1c 80b04f00
> ?tid: 80b04bf0 idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04c3c idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04c88 idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04cd4 idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04d20 idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04d6c idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04db8 idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04e04 idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04e50 idle running 1 80b04a1c 80b04ee8
> ?tid: 80b04e9c idle running 1 80b04a1c 80b04ee8
> ?ac: 80b04ee8 idle 1 80d1d6ac
> ?ac: 80b04f00 idle 1 80d1d724
> ?ac: 80b04f18 sched 0 80d1d79c
> ?ac: 80b04f30 idle 1 80d1d814
> f0:b4:79:22:71:85
> ?tid: 80b05a28 idle running 1 80b05a1c 80b05f18
> ?tid: 80b05a74 idle running 1 80b05a1c 80b05f30
> ?tid: 80b05ac0 idle running 1 80b05a1c 80b05f30
> ?tid: 80b05b0c idle running 1 80b05a1c 80b05f18
> ?tid: 80b05b58 idle running 1 80b05a1c 80b05f00
> ?tid: 80b05ba4 idle running 1 80b05a1c 80b05f00
> ?tid: 80b05bf0 idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05c3c idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05c88 idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05cd4 idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05d20 idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05d6c idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05db8 idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05e04 idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05e50 idle running 1 80b05a1c 80b05ee8
> ?tid: 80b05e9c idle running 1 80b05a1c 80b05ee8
> ?ac: 80b05ee8 idle 1 80d1d6ac
> ?ac: 80b05f00 idle 1 80d1d724
> ?ac: 80b05f18 idle 1 80d1d79c
> ?ac: 80b05f30 idle 1 80d1d814
> root at router:~# logread | tail
> Feb ?2 23:56:36 router user.err kernel: ath: Failed to stop TX DMA!
> Feb ?3 00:01:33 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
> WPA: group key handshake completed (RSN)
> Feb ?3 00:01:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
> WPA: group key handshake completed (RSN)
> Feb ?3 00:04:26 router user.info kernel: device mon.wlan0 left promiscuous mode
> Feb ?3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
> IEEE 802.11: authenticated
> Feb ?3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
> IEEE 802.11: associated (aid 1)
> Feb ?3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
> WPA: pairwise key handshake completed (RSN)
> Feb ?3 00:11:33 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
> WPA: group key handshake completed (RSN)
> Feb ?3 00:11:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
> WPA: group key handshake completed (RSN)
> Feb ?3 00:11:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
> WPA: received EAPOL-Key 2/2 Group with unexpected replay counter
>
> Please let me know if this was useful and what kind if other
> information you may need.
> Thanks.
>
>
>
> 2011/2/2 Nikolay Martynov <mar.kolya@gmail.com>:
>> Hi.
>>
>> ?One more thing I've noticed.
>> ?When I do tcpdump on intel mon interface I get quite a lot of
>> traffic. When I do same thing on router - I hardly see any traffic. Is
>> this expected?
>> ?This actually regards problem when client cannot reconnect to router
>> - in this state even though client send association and authentication
>> requests it doesn't get response.
>>
>> ?Can these two things be related? Is there any chance ath9k can loose
>> some received control packets or 'forget' to send them?
>>
>> ?Thanks.
>>
>> 2011/2/2 Nikolay Martynov <mar.kolya@gmail.com>:
>>> Hi.
>>>
>>> ?Installed new patch and do not have intel stuck yet. Although there
>>> is still 10-15% ping loss. But not new error messages in dmesg/log.
>>> I'll keep testing.
>>>
>>> ?Two updates:
>>>
>>> ?1) last problem I mentioned in previous letter seems to be caused by
>>> swcrypt=1 on intel side. I just turned it on yesterday and didn't
>>> realize it can cause such issues. But now I turned it off and it seems
>>> to be fine.
>>> ?2) in router logs there are often messages about inability of driver
>>> to stop rx or tx dma, I'm not sure whether this is relevant or not.
>>>
>>> Thanks.
>>> Nikolay.
>>>
>>> 2011/2/2 Felix Fietkau <nbd@openwrt.org>:
>>>> Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch
>>>> into package/mac80211/patches/ in your OpenWrt build tree.
>>>>
>>>> Then recompile and update the ath9k package on your AP and see if it
>>>> prints the "Aggregation session blocked..." messages when tx to the
>>>> Intel client stops working.
>>>>
>>>> Thanks,
>>>>
>>>> - Felix
>>>>
>>>> On 2011-02-03 2:46 AM, Nikolay Martynov wrote:
>>>>> Hi.
>>>>>
>>>>> ? I basically have three types of issues:
>>>>>
>>>>> ?1) Almost no usable 'n' mode. It is somewhat usable if there is one
>>>>> client on AP (and I guess relative silence in the air). If there are
>>>>> two clients intel card becomes unusable - it seems to receive almost
>>>>> no packets. Mac clients seems to work fine with same AP (didn't try
>>>>> too long though).
>>>>>
>>>>> ? 2) I often get disconnected from AP with message like: wlan1:
>>>>> deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3).
>>>>> This happens for no apparent reason, in 'g' mode (and probably 'n'
>>>>> too, I just do not run 'n' long enough). And this happens with macbook
>>>>> too. I'm not sure that message is always the same - often there is no
>>>>> disconnection message. When client tries to connect back there are
>>>>> different types of timeouts:
>>>>> ? ?a) on the client (intel):
>>>>> [78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3)
>>>>> [78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3)
>>>>> [78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3)
>>>>> [78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out
>>>>> ? ?b) on the client (intel):
>>>>> [78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1)
>>>>> [78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2)
>>>>> [78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3)
>>>>> [78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out
>>>>> ? a) and b) happen on intel. I often see 'timeout' in similar mac UI,
>>>>> but I do not know how to get any diagnostics from mac.
>>>>> ? At the same time on AP:
>>>>> ? ?b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout
>>>>> ? ?c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
>>>>> acknowledge association response
>>>>> ? ?b) and c) happen for both intel and mac clients. Moreover - one
>>>>> client may keep trying to connect while other stays connected and
>>>>> works fine. But if other disconnects it has problems connecting too.
>>>>> Problem usually can be fixed by restarting 'wifi' on router. I do not
>>>>> really know whether this is a ath9k problem, or some hostapd issue.
>>>>> This may happen several times an hour, but sometimes doesn't happen
>>>>> for hours. 'Disconnection' part happens more often on intel client.
>>>>>
>>>>> ? 3) Intel seems to loose heavy loaded tcp connection sometimes. I.e.
>>>>> I upload something from laptop to machine connected by wire on the
>>>>> same router and at some point upload stops and connection timeouts.
>>>>> Or, if a type a lot of stuff in SSH session - ssh session locks. Looks
>>>>> like bunch of packets get lost and tcp cannot recover. This happens in
>>>>> 'g' mode. Often enough so I cannot upload 600Mb file without loosing
>>>>> connection. Mac doesn't seem to have this problem.
>>>>>
>>>>> ? I have TEW-326BRP with trunk openwrt (kernel 2.6.37).
>>>>> ? On the client - dell laptop with intel5300, to which I have only two
>>>>> antennas connected - I replaced card from non-'n' and laptop has only
>>>>> two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest
>>>>> compat wireless + exp ucode + patch from
>>>>> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214.
>>>>> ? Another client - macbook pro.
>>>>> ? I think I'm about 30 meters from AP - AP is no second floor and I'm
>>>>> in the basement (basement has concrete walls - this might affect
>>>>> signal quality I guess).
>>>>>
>>>>> ? It'd be really great to have reliable wifi, so I can devote time and
>>>>> do whatever testing required.
>>>>> ? Please let me know how I can help.
>>>>> ? Thanks!
>>>>
>>>
>>>
>>>
>>> --
>>> Truthfully yours,
>>> Martynov Nikolay.
>>> Email: mar.kolya at gmail.com
>>> Phone: +16478220537
>>>
>>
>>
>>
>> --
>> Truthfully yours,
>> Martynov Nikolay.
>> Email: mar.kolya at gmail.com
>> Phone: +16478220537
>>
>
>
>
> --
> Truthfully yours,
> Martynov Nikolay.
> Email: mar.kolya at gmail.com
> Phone: +16478220537
>



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

[ath9k-devel] Weird error messages in logs

[Felix Fietkau]

Hi,

Please apply this OpenWrt patch to enable HT debugging and more verbose
debugging output from mac80211: http://nbd.name/mac80211-debug.patch

Then send some kernel logs from around the time this issue happens.

- Felix

On 2011-02-07 3:39 AM, Nikolay Martynov wrote:
> Hi,
> 
>   Is there anything I can do to help with this problem? Any additional
> information/testing/etc?
>   Are the logs I've sent before of any use?
> 
> Thanks.
> 
> 2011/2/3 Nikolay Martynov <mar.kolya@gmail.com>:
>> Hi,
>>
>>  So I did manage to 'stuck' it again.
>>
>>  Ping looks like this:
>> 64 bytes from 192.168.1.1: icmp_req=128 ttl=64 time=12408 ms
>> 64 bytes from 192.168.1.1: icmp_req=129 ttl=64 time=11408 ms
>> 64 bytes from 192.168.1.1: icmp_req=130 ttl=64 time=10408 ms
>> 64 bytes from 192.168.1.1: icmp_req=132 ttl=64 time=8942 ms
>> 64 bytes from 192.168.1.1: icmp_req=133 ttl=64 time=7942 ms
>> 64 bytes from 192.168.1.1: icmp_req=134 ttl=64 time=6942 ms
>> 64 bytes from 192.168.1.1: icmp_req=135 ttl=64 time=5942 ms
>> 64 bytes from 192.168.1.1: icmp_req=136 ttl=64 time=4979 ms
>> 64 bytes from 192.168.1.1: icmp_req=137 ttl=64 time=3981 ms
>> 64 bytes from 192.168.1.1: icmp_req=138 ttl=64 time=2981 ms
>> 64 bytes from 192.168.1.1: icmp_req=140 ttl=64 time=10829 ms
>> 64 bytes from 192.168.1.1: icmp_req=141 ttl=64 time=9901 ms
>> 64 bytes from 192.168.1.1: icmp_req=142 ttl=64 time=8925 ms
>> 64 bytes from 192.168.1.1: icmp_req=145 ttl=64 time=6588 ms
>> 64 bytes from 192.168.1.1: icmp_req=146 ttl=64 time=6139 ms
>> 64 bytes from 192.168.1.1: icmp_req=147 ttl=64 time=5133 ms
>> 64 bytes from 192.168.1.1: icmp_req=148 ttl=64 time=4125 ms
>> 64 bytes from 192.168.1.1: icmp_req=149 ttl=64 time=3117 ms
>> 64 bytes from 192.168.1.1: icmp_req=150 ttl=64 time=2109 ms
>>
>> There were no "Aggregation session blocked" messages in logs.
>> Here what I've captured:
>>
>> root at router:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/xmit
>> Num-Tx-Queues: 10  tx-queues-setup: 0x10f poll-work-seen: 8164
>>                            BE         BK        VI        VO
>>
>> MPDUs Queued:          1129641          0         0      2884
>> MPDUs Completed:       1129641          0         0      2884
>> Aggregates:             626250          0         0         0
>> AMPDUs Queued HW:       656532          0         0         0
>> AMPDUs Queued SW:      4095017          0         0         0
>> AMPDUs Completed:      4749880          0         0         0
>> AMPDUs Retried:         197274          0         0         0
>> AMPDUs XRetried:          1594          0         0         0
>> FIFO Underrun:               0          0         0         0
>> TXOP Exceeded:               0          0         0         0
>> TXTIMER Expiry:              0          0         0         0
>> DESC CFG Error:              0          0         0         0
>> DATA Underrun:               0          0         0         0
>> DELIM Underrun:              0          0         0         0
>> TX-Pkts-All:           5881115          0         0      2884
>> TX-Bytes-All:       2056395884          0         0    227872
>> hw-put-tx-buf:              25          0         0        25
>> hw-tx-start:           2709929          0         0      2884
>> hw-tx-proc-desc:       2709441          0         0      2883
>> txq-memory-address:   80d1db74   80d1db78  80d1db70  80d1db6c
>> axq-qnum:                    2          3         1         0
>> axq-depth:                   2          0         0         0
>> axq-ampdu_depth:             2          0         0         0
>> axq-stopped                  0          0         0         0
>> tx-in-progress               0          0         0         0
>> pending-frames              60          0         0         0
>> txq_headidx:                 0          0         0         0
>> txq_tailidx:                 0          0         0         0
>> axq_q empty:                   0          1         1         0
>> axq_acq empty:                 0          1         1         1
>> txq_fifo_pending:              1          1         1         1
>> txq_fifo[0] empty:             1          1         1         1
>> txq_fifo[1] empty:             1          1         1         1
>> txq_fifo[2] empty:             1          1         1         1
>> txq_fifo[3] empty:             1          1         1         1
>> txq_fifo[4] empty:             1          1         1         1
>> txq_fifo[5] empty:             1          1         1         1
>> txq_fifo[6] empty:             1          1         1         1
>> txq_fifo[7] empty:             1          1         1         1
>> txq[2] first-ac: 80b05f18 sched: 1
>>  first-tid: 80b05a28 sched: 1 paused: 0
>> root at router:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/stations
>> Stations:
>>  tid: addr sched paused buf_q-empty an ac
>>  ac: addr sched tid_q-empty txq
>> 00:21:6a:70:18:56
>>  tid: 80b04a28 sched running 0 80b04a1c 80b04f18
>>  tid: 80b04a74 idle running 1 80b04a1c 80b04f30
>>  tid: 80b04ac0 idle running 1 80b04a1c 80b04f30
>>  tid: 80b04b0c idle running 1 80b04a1c 80b04f18
>>  tid: 80b04b58 idle running 1 80b04a1c 80b04f00
>>  tid: 80b04ba4 idle running 1 80b04a1c 80b04f00
>>  tid: 80b04bf0 idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04c3c idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04c88 idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04cd4 idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04d20 idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04d6c idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04db8 idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04e04 idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04e50 idle running 1 80b04a1c 80b04ee8
>>  tid: 80b04e9c idle running 1 80b04a1c 80b04ee8
>>  ac: 80b04ee8 idle 1 80d1d6ac
>>  ac: 80b04f00 idle 1 80d1d724
>>  ac: 80b04f18 sched 0 80d1d79c
>>  ac: 80b04f30 idle 1 80d1d814
>> f0:b4:79:22:71:85
>>  tid: 80b05a28 idle running 1 80b05a1c 80b05f18
>>  tid: 80b05a74 idle running 1 80b05a1c 80b05f30
>>  tid: 80b05ac0 idle running 1 80b05a1c 80b05f30
>>  tid: 80b05b0c idle running 1 80b05a1c 80b05f18
>>  tid: 80b05b58 idle running 1 80b05a1c 80b05f00
>>  tid: 80b05ba4 idle running 1 80b05a1c 80b05f00
>>  tid: 80b05bf0 idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05c3c idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05c88 idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05cd4 idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05d20 idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05d6c idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05db8 idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05e04 idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05e50 idle running 1 80b05a1c 80b05ee8
>>  tid: 80b05e9c idle running 1 80b05a1c 80b05ee8
>>  ac: 80b05ee8 idle 1 80d1d6ac
>>  ac: 80b05f00 idle 1 80d1d724
>>  ac: 80b05f18 idle 1 80d1d79c
>>  ac: 80b05f30 idle 1 80d1d814
>> root at router:~# logread | tail
>> Feb  2 23:56:36 router user.err kernel: ath: Failed to stop TX DMA!
>> Feb  3 00:01:33 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
>> WPA: group key handshake completed (RSN)
>> Feb  3 00:01:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
>> WPA: group key handshake completed (RSN)
>> Feb  3 00:04:26 router user.info kernel: device mon.wlan0 left promiscuous mode
>> Feb  3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
>> IEEE 802.11: authenticated
>> Feb  3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
>> IEEE 802.11: associated (aid 1)
>> Feb  3 00:10:36 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
>> WPA: pairwise key handshake completed (RSN)
>> Feb  3 00:11:33 router user.info hostapd: wlan0: STA 00:21:6a:70:18:56
>> WPA: group key handshake completed (RSN)
>> Feb  3 00:11:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
>> WPA: group key handshake completed (RSN)
>> Feb  3 00:11:33 router user.info hostapd: wlan0: STA f0:b4:79:22:71:85
>> WPA: received EAPOL-Key 2/2 Group with unexpected replay counter
>>
>> Please let me know if this was useful and what kind if other
>> information you may need.
>> Thanks.
>>
>>
>>
>> 2011/2/2 Nikolay Martynov <mar.kolya@gmail.com>:
>>> Hi.
>>>
>>>  One more thing I've noticed.
>>>  When I do tcpdump on intel mon interface I get quite a lot of
>>> traffic. When I do same thing on router - I hardly see any traffic. Is
>>> this expected?
>>>  This actually regards problem when client cannot reconnect to router
>>> - in this state even though client send association and authentication
>>> requests it doesn't get response.
>>>
>>>  Can these two things be related? Is there any chance ath9k can loose
>>> some received control packets or 'forget' to send them?
>>>
>>>  Thanks.
>>>
>>> 2011/2/2 Nikolay Martynov <mar.kolya@gmail.com>:
>>>> Hi.
>>>>
>>>>  Installed new patch and do not have intel stuck yet. Although there
>>>> is still 10-15% ping loss. But not new error messages in dmesg/log.
>>>> I'll keep testing.
>>>>
>>>>  Two updates:
>>>>
>>>>  1) last problem I mentioned in previous letter seems to be caused by
>>>> swcrypt=1 on intel side. I just turned it on yesterday and didn't
>>>> realize it can cause such issues. But now I turned it off and it seems
>>>> to be fine.
>>>>  2) in router logs there are often messages about inability of driver
>>>> to stop rx or tx dma, I'm not sure whether this is relevant or not.
>>>>
>>>> Thanks.
>>>> Nikolay.
>>>>
>>>> 2011/2/2 Felix Fietkau <nbd@openwrt.org>:
>>>>> Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch
>>>>> into package/mac80211/patches/ in your OpenWrt build tree.
>>>>>
>>>>> Then recompile and update the ath9k package on your AP and see if it
>>>>> prints the "Aggregation session blocked..." messages when tx to the
>>>>> Intel client stops working.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> - Felix
>>>>>
>>>>> On 2011-02-03 2:46 AM, Nikolay Martynov wrote:
>>>>>> Hi.
>>>>>>
>>>>>>   I basically have three types of issues:
>>>>>>
>>>>>>  1) Almost no usable 'n' mode. It is somewhat usable if there is one
>>>>>> client on AP (and I guess relative silence in the air). If there are
>>>>>> two clients intel card becomes unusable - it seems to receive almost
>>>>>> no packets. Mac clients seems to work fine with same AP (didn't try
>>>>>> too long though).
>>>>>>
>>>>>>   2) I often get disconnected from AP with message like: wlan1:
>>>>>> deauthenticating from xx:xx:xx:xx:xx:xx by local choice (reason=3).
>>>>>> This happens for no apparent reason, in 'g' mode (and probably 'n'
>>>>>> too, I just do not run 'n' long enough). And this happens with macbook
>>>>>> too. I'm not sure that message is always the same - often there is no
>>>>>> disconnection message. When client tries to connect back there are
>>>>>> different types of timeouts:
>>>>>>    a) on the client (intel):
>>>>>> [78513.691609] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 1/3)
>>>>>> [78513.888104] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 2/3)
>>>>>> [78514.088111] wlan1: direct probe to xx:xx:xx:xx:xx:xx (try 3/3)
>>>>>> [78514.288065] wlan1: direct probe to xx:xx:xx:xx:xx:xx timed out
>>>>>>    b) on the client (intel):
>>>>>> [78471.324221] wlan1: associate with xx:xx:xx:xx:xx:xx (try 1)
>>>>>> [78471.524074] wlan1: associate with xx:xx:xx:xx:xx:xx (try 2)
>>>>>> [78471.724064] wlan1: associate with xx:xx:xx:xx:xx:xx (try 3)
>>>>>> [78471.924055] wlan1: association with xx:xx:xx:xx:xx:xx timed out
>>>>>>   a) and b) happen on intel. I often see 'timeout' in similar mac UI,
>>>>>> but I do not know how to get any diagnostics from mac.
>>>>>>   At the same time on AP:
>>>>>>    b) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: EAPOL-Key timeout
>>>>>>    c) hostapd: wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: did not
>>>>>> acknowledge association response
>>>>>>    b) and c) happen for both intel and mac clients. Moreover - one
>>>>>> client may keep trying to connect while other stays connected and
>>>>>> works fine. But if other disconnects it has problems connecting too.
>>>>>> Problem usually can be fixed by restarting 'wifi' on router. I do not
>>>>>> really know whether this is a ath9k problem, or some hostapd issue.
>>>>>> This may happen several times an hour, but sometimes doesn't happen
>>>>>> for hours. 'Disconnection' part happens more often on intel client.
>>>>>>
>>>>>>   3) Intel seems to loose heavy loaded tcp connection sometimes. I.e.
>>>>>> I upload something from laptop to machine connected by wire on the
>>>>>> same router and at some point upload stops and connection timeouts.
>>>>>> Or, if a type a lot of stuff in SSH session - ssh session locks. Looks
>>>>>> like bunch of packets get lost and tcp cannot recover. This happens in
>>>>>> 'g' mode. Often enough so I cannot upload 600Mb file without loosing
>>>>>> connection. Mac doesn't seem to have this problem.
>>>>>>
>>>>>>   I have TEW-326BRP with trunk openwrt (kernel 2.6.37).
>>>>>>   On the client - dell laptop with intel5300, to which I have only two
>>>>>> antennas connected - I replaced card from non-'n' and laptop has only
>>>>>> two antennas. OS - ubuntu, 2.6.38 kernel from it's repository + latest
>>>>>> compat wireless + exp ucode + patch from
>>>>>> http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2214.
>>>>>>   Another client - macbook pro.
>>>>>>   I think I'm about 30 meters from AP - AP is no second floor and I'm
>>>>>> in the basement (basement has concrete walls - this might affect
>>>>>> signal quality I guess).
>>>>>>
>>>>>>   It'd be really great to have reliable wifi, so I can devote time and
>>>>>> do whatever testing required.
>>>>>>   Please let me know how I can help.
>>>>>>   Thanks!
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Truthfully yours,
>>>> Martynov Nikolay.
>>>> Email: mar.kolya at gmail.com
>>>> Phone: +16478220537
>>>>
>>>
>>>
>>>
>>> --
>>> Truthfully yours,
>>> Martynov Nikolay.
>>> Email: mar.kolya at gmail.com
>>> Phone: +16478220537
>>>
>>
>>
>>
>> --
>> Truthfully yours,
>> Martynov Nikolay.
>> Email: mar.kolya at gmail.com
>> Phone: +16478220537
>>
> 
> 
> 

[ath9k-devel] Weird error messages in logs

[Mohammed Shafi]

On Wed, Feb 2, 2011 at 9:16 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> 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.

Oh ok thanks.
>
> 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
>>>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Weird error messages in logs

[Mohammed Shafi]

On Wed, Feb 2, 2011 at 12:25 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 02/01/2011 09:57 PM, Mohammed Shafi wrote:
>>
>> On Wed, Feb 2, 2011 at 11:18 AM, Nikolay Martynov<mar.kolya@gmail.com>
>> ?wrote:
>>>
>>> Hi.
>>>
>>> Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
>>> has latest linux driver. Network operates in 801.11g mode. When client
>>> uploads to the AP for a long time I get these errors in logs on AP:
>>>
>>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
>>> pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0 ?Attempting
>>> to restart tx logic.
>
>>> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
>>> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
>>> Attempting to restart tx logic.
>>>
>>> Transmission seems to die after this.
>>> Could you please tell me what these messages mean and is it possible
>>> to fix this issue on ath9k side?
>>
>> Looks like a tx hang and this commit will provide us more details
>>
>> commit 60f2d1d506195803fa6e1dcf3972637b740fdd60
>> Author: Ben Greear<greearb@candelatech.com>
>> Date: ? Sun Jan 9 23:11:52 2011 -0800
>>
>> ? ? ath9k: Restart xmit logic in xmit watchdog.
>>
>> ? ? The system can get into a state where the xmit queue
>> ? ? is stopped, but there are no packets pending, so
>> ? ? the queue will not be restarted.
>>
>> ? ? Add logic to the xmit watchdog to attempt to restart
>> ? ? the xmit logic if this situation is detected.
>>
>> ? ? Example 'dmesg' output:
>>
>> ? ? ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link:
>> f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0
>> Attempting to restart tx logic.
>>
>> sudo modprobe ath9k debug=0x481(FATAL | XMIT | RESET) will provide us
>> some useful debug messages
>
> Looks like my attempt to restart is not working, for whatever reason.
> There are several ways it could get stuck...my hack worked around
> some of them, but obviously not all of them.

Oh Ok. I will look into that code part more deeply.

>
> You might also look at the debugfs files while the system is in
> the stuck state:
>
> cat /debug/ieee80211/wiphy0/ath9k/stations
> cat /debug/ieee80211/wiphy0/ath9k/xmit
>
> Those show info that *might* help debug the problem...

Thanks Ben.

>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>

[ath9k-devel] Weird error messages in logs

[Mohammed Shafi]

On Wed, Feb 2, 2011 at 11:18 AM, Nikolay Martynov <mar.kolya@gmail.com> wrote:
> Hi.
>
> Have ath9k AP and intel 5300 client. AP has latest openwrt, intel5300
> has latest linux driver. Network operates in 801.11g mode. When client
> uploads to the AP for a long time I get these errors in logs on AP:
>
Hi what card you are using?

> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 7 axq_acq empty: 0 stopped: 0 axq_depth: 0 ?Attempting
> to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 14 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 24 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 34 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 42 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 45 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 48 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 63 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 67 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 78 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 85 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d575f8
> pending frames: 89 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 94 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 101 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 108 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 113 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 120 axq_acq empty: 0 stopped: 0 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
> ath: txq: 80c3d7fc axq_qnum: 2, mac80211_qnum: 2 axq_link: a0d58f5c
> pending frames: 124 axq_acq empty: 0 stopped: 1 axq_depth: 0
> Attempting to restart tx logic.
>
> Transmission seems to die after this.
> Could you please tell me what these messages mean and is it possible
> to fix this issue on ath9k side?
> Thanks!
>
> --
> Truthfully yours,
> Martynov Nikolay.
> Email: mar.kolya at gmail.com
> Phone: +16478220537
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>