[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Chaoxing Lin]

Just FYI

Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."

I tried it on Dell laptop with ar9390 radio.
Still, I got error message like below

"ath: phy0: Failed to stop TX DMA, queues=0x005!"
"ath: phy0: Failed to stop TX DMA, queues=0x001!"

I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.


-----------------------------

commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Fri Oct 26 00:31:11 2012 +0200

    ath9k: fix stale pointers potentially causing access to free'd skbs
    
    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
    
    bf->bf_next is only while buffers are chained as part of an A-MPDU
    in the tx queue. When a tid queue is flushed (e.g. on tearing down
    an aggregation session), frames can be enqueued again as normal
    transmission, without bf_next being cleared. This can lead to the
    old pointer being dereferenced again later.
    
    This patch might fix crashes and "Failed to stop TX DMA!" messages.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Chaoxing Lin]

Just FYI

Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."

I tried it on Dell laptop with ar9390 radio.
Still, I got error message like below

"ath: phy0: Failed to stop TX DMA, queues=0x005!"
"ath: phy0: Failed to stop TX DMA, queues=0x001!"

I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.


-----------------------------

commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Fri Oct 26 00:31:11 2012 +0200

    ath9k: fix stale pointers potentially causing access to free'd skbs
    
    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
    
    bf->bf_next is only while buffers are chained as part of an A-MPDU
    in the tx queue. When a tid queue is flushed (e.g. on tearing down
    an aggregation session), frames can be enqueued again as normal
    transmission, without bf_next being cleared. This can lead to the
    old pointer being dereferenced again later.
    
    This patch might fix crashes and "Failed to stop TX DMA!" messages.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Georgiewskiy Yuriy]

On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:

Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
i use many different cards but all ar9002 based.

CL>Just FYI
CL>
CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
CL>
CL>I tried it on Dell laptop with ar9390 radio.
CL>Still, I got error message like below
CL>
CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
CL>
CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
CL>
CL>
CL>-----------------------------
CL>
CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
CL>Author: Felix Fietkau <nbd@openwrt.org>
CL>Date:   Fri Oct 26 00:31:11 2012 +0200
CL>
CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
CL>    
CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
CL>    
CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
CL>    an aggregation session), frames can be enqueued again as normal
CL>    transmission, without bf_next being cleared. This can lead to the
CL>    old pointer being dereferenced again later.
CL>    
CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
CL>    
CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CL>--
CL>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
CL>the body of a message to majordomo at vger.kernel.org
CL>More majordomo info at  http://vger.kernel.org/majordomo-info.html
CL>

C ?????????                       With Best Regards
???????????? ????.                Georgiewskiy Yuriy
+7 4872 711666                    +7 4872 711666
???? +7 4872 711143               fax +7 4872 711143
???????? ??? "?? ?? ??????"       IT Service Ltd
http://nkoort.ru                  http://nkoort.ru
JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
YG129-RIPE                        YG129-RIPE

Re: FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Georgiewskiy Yuriy]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2206 bytes --]

On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless@vger.kernel.or...:

Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
i use many different cards but all ar9002 based.

CL>Just FYI
CL>
CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
CL>
CL>I tried it on Dell laptop with ar9390 radio.
CL>Still, I got error message like below
CL>
CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
CL>
CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
CL>
CL>
CL>-----------------------------
CL>
CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
CL>Author: Felix Fietkau <nbd@openwrt.org>
CL>Date:   Fri Oct 26 00:31:11 2012 +0200
CL>
CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
CL>    
CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
CL>    
CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
CL>    an aggregation session), frames can be enqueued again as normal
CL>    transmission, without bf_next being cleared. This can lead to the
CL>    old pointer being dereferenced again later.
CL>    
CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
CL>    
CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CL>--
CL>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
CL>the body of a message to majordomo@vger.kernel.org
CL>More majordomo info at  http://vger.kernel.org/majordomo-info.html
CL>

C уважением                       With Best Regards
Георгиевский Юрий.                Georgiewskiy Yuriy
+7 4872 711666                    +7 4872 711666
факс +7 4872 711143               fax +7 4872 711143
Компания ООО "Ай Ти Сервис"       IT Service Ltd
http://nkoort.ru                  http://nkoort.ru
JID: GHhost@icf.org.ru            JID: GHhost@icf.org.ru
YG129-RIPE                        YG129-RIPE

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Georgiewskiy Yuriy]

On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:

Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
i use many different cards but all ar9002 based.

CL>Just FYI
CL>
CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
CL>
CL>I tried it on Dell laptop with ar9390 radio.
CL>Still, I got error message like below
CL>
CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
CL>
CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
CL>
CL>
CL>-----------------------------
CL>
CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
CL>Author: Felix Fietkau <nbd@openwrt.org>
CL>Date:   Fri Oct 26 00:31:11 2012 +0200
CL>
CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
CL>    
CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
CL>    
CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
CL>    an aggregation session), frames can be enqueued again as normal
CL>    transmission, without bf_next being cleared. This can lead to the
CL>    old pointer being dereferenced again later.
CL>    
CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
CL>    
CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CL>_______________________________________________
CL>ath9k-devel mailing list
CL>ath9k-devel at lists.ath9k.org
CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
CL>

C ?????????                       With Best Regards
???????????? ????.                Georgiewskiy Yuriy
+7 4872 711666                    +7 4872 711666
???? +7 4872 711143               fax +7 4872 711143
???????? ??? "?? ?? ??????"       IT Service Ltd
http://nkoort.ru                  http://nkoort.ru
JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
YG129-RIPE                        YG129-RIPE

Re: [ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Georgiewskiy Yuriy]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2162 bytes --]

On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless@vger.kernel.or...:

Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
i use many different cards but all ar9002 based.

CL>Just FYI
CL>
CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
CL>
CL>I tried it on Dell laptop with ar9390 radio.
CL>Still, I got error message like below
CL>
CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
CL>
CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
CL>
CL>
CL>-----------------------------
CL>
CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
CL>Author: Felix Fietkau <nbd@openwrt.org>
CL>Date:   Fri Oct 26 00:31:11 2012 +0200
CL>
CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
CL>    
CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
CL>    
CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
CL>    an aggregation session), frames can be enqueued again as normal
CL>    transmission, without bf_next being cleared. This can lead to the
CL>    old pointer being dereferenced again later.
CL>    
CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
CL>    
CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CL>_______________________________________________
CL>ath9k-devel mailing list
CL>ath9k-devel@lists.ath9k.org
CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
CL>

C уважением                       With Best Regards
Георгиевский Юрий.                Georgiewskiy Yuriy
+7 4872 711666                    +7 4872 711666
факс +7 4872 711143               fax +7 4872 711143
Компания ООО "Ай Ти Сервис"       IT Service Ltd
http://nkoort.ru                  http://nkoort.ru
JID: GHhost@icf.org.ru            JID: GHhost@icf.org.ru
YG129-RIPE                        YG129-RIPE

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Alexander Szlezak]

Hi,

I can confirm this too. It exists in master mode too in recent trunk 
(later than the version which is referred to as possible fix in trac), 
we experienced it especially when using 3 vaps in master mode. Once it 
occurs all clients hang. I'm willing to support a fix - let me know more 
what is needed.

best,
Alexander

Am 20.11.2012 23:04, schrieb Georgiewskiy Yuriy:
> On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:
>
> Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
> i use many different cards but all ar9002 based.
>
> CL>Just FYI
> CL>
> CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
> CL>
> CL>I tried it on Dell laptop with ar9390 radio.
> CL>Still, I got error message like below
> CL>
> CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
> CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
> CL>
> CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
> CL>
> CL>
> CL>-----------------------------
> CL>
> CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
> CL>Author: Felix Fietkau <nbd@openwrt.org>
> CL>Date:   Fri Oct 26 00:31:11 2012 +0200
> CL>
> CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
> CL>
> CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
> CL>
> CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
> CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
> CL>    an aggregation session), frames can be enqueued again as normal
> CL>    transmission, without bf_next being cleared. This can lead to the
> CL>    old pointer being dereferenced again later.
> CL>
> CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
> CL>
> CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
> CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> CL>_______________________________________________
> CL>ath9k-devel mailing list
> CL>ath9k-devel at lists.ath9k.org
> CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> CL>
>
> C ?????????                       With Best Regards
> ???????????? ????.                Georgiewskiy Yuriy
> +7 4872 711666                    +7 4872 711666
> ???? +7 4872 711143               fax +7 4872 711143
> ???????? ??? "?? ?? ??????"       IT Service Ltd
> http://nkoort.ru                  http://nkoort.ru
> JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
> YG129-RIPE                        YG129-RIPE
>
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

-- 
Follow me on Twitter @ http://twitter.com/magicshark
__________________________________________________________________
Mag. Alexander SZLEZAK


Reischergasse 6/2
A-1130 Vienna
Austria
M +43 699 1 350 41 01
E alex at szlezak.com

https://www.xing.com/profile/Alexander_Szlezak

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Peter Stuge]

Alexander Szlezak wrote:
> let me know more what is needed.

I think your only chance of getting help is to provide so much
information that developers can reproduce the problem in their lab.

You'll have to create your own lab first, and find out how to
reproduce the problem.


//Peter

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Robert Shade]

I'm using the latest compat-drivers w/patches from 3.7-rc6 and I'm
able to make it happen "at will" with a flood ping to an AP with a
weak signal strength.  (I can do the same with the stock RHEL6 driver)

When it happens, the client disconnects from the AP due to a perceived
lost beacon and reconnects.

On Tue, Nov 20, 2012 at 5:46 PM, Alexander Szlezak <alex@szlezak.com> wrote:
> Hi,
>
> I can confirm this too. It exists in master mode too in recent trunk
> (later than the version which is referred to as possible fix in trac),
> we experienced it especially when using 3 vaps in master mode. Once it
> occurs all clients hang. I'm willing to support a fix - let me know more
> what is needed.
>
> best,
> Alexander
>
> Am 20.11.2012 23:04, schrieb Georgiewskiy Yuriy:
>> On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:
>>
>> Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
>> i use many different cards but all ar9002 based.
>>
>> CL>Just FYI
>> CL>
>> CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
>> CL>
>> CL>I tried it on Dell laptop with ar9390 radio.
>> CL>Still, I got error message like below
>> CL>
>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
>> CL>
>> CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
>> CL>
>> CL>
>> CL>-----------------------------
>> CL>
>> CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
>> CL>Author: Felix Fietkau <nbd@openwrt.org>
>> CL>Date:   Fri Oct 26 00:31:11 2012 +0200
>> CL>
>> CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
>> CL>
>> CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
>> CL>
>> CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
>> CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
>> CL>    an aggregation session), frames can be enqueued again as normal
>> CL>    transmission, without bf_next being cleared. This can lead to the
>> CL>    old pointer being dereferenced again later.
>> CL>
>> CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
>> CL>
>> CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
>> CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> CL>_______________________________________________
>> CL>ath9k-devel mailing list
>> CL>ath9k-devel at lists.ath9k.org
>> CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>> CL>
>>
>> C ?????????                       With Best Regards
>> ???????????? ????.                Georgiewskiy Yuriy
>> +7 4872 711666                    +7 4872 711666
>> ???? +7 4872 711143               fax +7 4872 711143
>> ???????? ??? "?? ?? ??????"       IT Service Ltd
>> http://nkoort.ru                  http://nkoort.ru
>> JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
>> YG129-RIPE                        YG129-RIPE
>>
>>
>>
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
> --
> Follow me on Twitter @ http://twitter.com/magicshark
> __________________________________________________________________
> Mag. Alexander SZLEZAK
>
>
> Reischergasse 6/2
> A-1130 Vienna
> Austria
> M +43 699 1 350 41 01
> E alex at szlezak.com
>
> https://www.xing.com/profile/Alexander_Szlezak
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Georgiewskiy Yuriy]

On 2012-11-20 18:01 -0500, Robert Shade wrote ath9k-devel at lists.ath9k.org:

RS>I'm using the latest compat-drivers w/patches from 3.7-rc6 and I'm
RS>able to make it happen "at will" with a flood ping to an AP with a
RS>weak signal strength.  (I can do the same with the stock RHEL6 driver)

Confirm this too - weak signal about from -70 to -90 always trigger this for me.

RS>
RS>When it happens, the client disconnects from the AP due to a perceived
RS>lost beacon and reconnects.
RS>
RS>On Tue, Nov 20, 2012 at 5:46 PM, Alexander Szlezak <alex@szlezak.com> wrote:
RS>> Hi,
RS>>
RS>> I can confirm this too. It exists in master mode too in recent trunk
RS>> (later than the version which is referred to as possible fix in trac),
RS>> we experienced it especially when using 3 vaps in master mode. Once it
RS>> occurs all clients hang. I'm willing to support a fix - let me know more
RS>> what is needed.
RS>>
RS>> best,
RS>> Alexander
RS>>
RS>> Am 20.11.2012 23:04, schrieb Georgiewskiy Yuriy:
RS>>> On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:
RS>>>
RS>>> Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
RS>>> i use many different cards but all ar9002 based.
RS>>>
RS>>> CL>Just FYI
RS>>> CL>
RS>>> CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
RS>>> CL>
RS>>> CL>I tried it on Dell laptop with ar9390 radio.
RS>>> CL>Still, I got error message like below
RS>>> CL>
RS>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
RS>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
RS>>> CL>
RS>>> CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
RS>>> CL>
RS>>> CL>
RS>>> CL>-----------------------------
RS>>> CL>
RS>>> CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
RS>>> CL>Author: Felix Fietkau <nbd@openwrt.org>
RS>>> CL>Date:   Fri Oct 26 00:31:11 2012 +0200
RS>>> CL>
RS>>> CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
RS>>> CL>
RS>>> CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
RS>>> CL>
RS>>> CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
RS>>> CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
RS>>> CL>    an aggregation session), frames can be enqueued again as normal
RS>>> CL>    transmission, without bf_next being cleared. This can lead to the
RS>>> CL>    old pointer being dereferenced again later.
RS>>> CL>
RS>>> CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
RS>>> CL>
RS>>> CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
RS>>> CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
RS>>> CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RS>>> CL>_______________________________________________
RS>>> CL>ath9k-devel mailing list
RS>>> CL>ath9k-devel at lists.ath9k.org
RS>>> CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>>> CL>
RS>>>
RS>>> C ?????????                       With Best Regards
RS>>> ???????????? ????.                Georgiewskiy Yuriy
RS>>> +7 4872 711666                    +7 4872 711666
RS>>> ???? +7 4872 711143               fax +7 4872 711143
RS>>> ???????? ??? "?? ?? ??????"       IT Service Ltd
RS>>> http://nkoort.ru                  http://nkoort.ru
RS>>> JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
RS>>> YG129-RIPE                        YG129-RIPE
RS>>>
RS>>>
RS>>>
RS>>> _______________________________________________
RS>>> ath9k-devel mailing list
RS>>> ath9k-devel at lists.ath9k.org
RS>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>>>
RS>>
RS>> --
RS>> Follow me on Twitter @ http://twitter.com/magicshark
RS>> __________________________________________________________________
RS>> Mag. Alexander SZLEZAK
RS>>
RS>>
RS>> Reischergasse 6/2
RS>> A-1130 Vienna
RS>> Austria
RS>> M +43 699 1 350 41 01
RS>> E alex at szlezak.com
RS>>
RS>> https://www.xing.com/profile/Alexander_Szlezak
RS>> _______________________________________________
RS>> ath9k-devel mailing list
RS>> ath9k-devel at lists.ath9k.org
RS>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>_______________________________________________
RS>ath9k-devel mailing list
RS>ath9k-devel at lists.ath9k.org
RS>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>

C ?????????                       With Best Regards
???????????? ????.                Georgiewskiy Yuriy
+7 4872 711666                    +7 4872 711666
???? +7 4872 711143               fax +7 4872 711143
???????? ??? "?? ?? ??????"       IT Service Ltd
http://nkoort.ru                  http://nkoort.ru
JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
YG129-RIPE                        YG129-RIPE

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[fm]

Hi

I'm having the same problem
"ath: phy0: Failed to stop TX DMA, queues=0x001!"

My board uses an AR9160 with an AR5133

I've observed the same symptom with kernels 2.6.36, 3.4.4 and 3.6.7 and
with wpa_supplicant as well as hostapd and I can reproduce it even with
a good signal level (iwconfig says Link Quality=70/70  Signal level=-36
dBm). I've also tried minstrel as well as ath9k_specific rate control
algos.

It occurs after several Mbytes of data tranfered. I have a similar
problem on the other way, here's the log:

 ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x42000020 DMADBG_7=0x000064c0
 ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x42000020 DMADBG_7=0x000062c0
 ath: phy0: Could not stop RX, we could be confusing the DMA engine when
we start RX up
 ------------[ cut here ]------------
 WARNING: at drivers/net/wireless/ath/ath9k/recv.c:497 ath_stoprecv
+0xfd/0x110 [ath9k]()
 Modules linked in: ath9k mac80211 ath9k_common ath9k_hw ath cfg80211
 Pid: 6, comm: kworker/u:0 Not tainted 3.6.7 #6
 Call Trace:
  [<c102528a>] warn_slowpath_common+0x5a/0x80
  [<e09ec10d>] ? ath_stoprecv+0xfd/0x110 [ath9k]
  [<c10252bf>] warn_slowpath_null+0xf/0x20
  [<e09ec10d>] ath_stoprecv+0xfd/0x110 [ath9k]
  [<e09e8a17>] ath_prepare_reset+0x47/0xd0 [ath9k]
  [<c103b7db>] ? cancel_delayed_work_sync+0xb/0x10
  [<e09e9184>] ath_reset_internal+0x64/0x190 [ath9k]
  [<e09f2100>] ? ath_update_survey_stats+0x40/0x180 [ath9k]
  [<e09ea1e3>] ath9k_config+0x263/0x570 [ath9k]
  [<e0986126>] ieee80211_hw_config+0x106/0x180 [mac80211]
  [<e098c262>] ieee80211_scan_work+0x172/0x4e0 [mac80211]
  [<c103afac>] process_one_work+0x11c/0x380
  [<e098c0f0>] ? ieee80211_run_deferred_scan+0x80/0x80 [mac80211]
  [<c103bed7>] worker_thread+0x127/0x490
  [<c103bdb0>] ? manage_workers.clone.31+0x320/0x320
  [<c103bdb0>] ? manage_workers.clone.31+0x320/0x320
  [<c103fc84>] kthread+0x74/0x80
  [<c103fc10>] ? kthread_create_on_node+0xd0/0xd0
  [<c13e3f06>] kernel_thread_helper+0x6/0xd
 ---[ end trace c0419a945395f030 ]---
 ath: phy0: Failed to stop TX DMA, queues=0x001!
 ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x42000020 DMADBG_7=0x00006040
 ath: phy0: Could not stop RX, we could be confusing the DMA engine when
we start RX up
 ath: phy0: Failed to stop TX DMA, queues=0x001!
 ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024
AR_DIAG_SW=0x42000020 DMADBG_7=0x00006040
 ath: phy0: Could not stop RX, we could be confusing the DMA engine when
we start RX up
 ath: phy0: Failed to stop TX DMA, queues=0x001!


If needed, I can send my .config or any other info. And I can easily
reproduce the problem, so if I can help, I can try patches or run
testsuites.

thanks for any help or suggestion

fm

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Robert Shade]

Some more points of data:

* For my 9160, this appears to be a regression from RHEL 6.2 -> 6.3.
I'm unable to replicate my issue with a flood ping on any RHEL 6.2
kernel.  Pure speculation, but the messages complain about DMA issues
and the patch notes indicate the "dma_unmap state API" was added in
6.3 [1].  The kernel changelog also says that the wireless in 6.3 is
based off kernel 3.2, but I have not been able to find out what 6.2 is
based off of.

* I was also able to replicate the issue in Fedora Core 17 (kernel 3.3.4).

[1]https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.3_Release_Notes/index.html

On Tue, Nov 20, 2012 at 6:01 PM, Robert Shade <robert.shade@gmail.com> wrote:
> I'm using the latest compat-drivers w/patches from 3.7-rc6 and I'm
> able to make it happen "at will" with a flood ping to an AP with a
> weak signal strength.  (I can do the same with the stock RHEL6 driver)
>
> When it happens, the client disconnects from the AP due to a perceived
> lost beacon and reconnects.
>
> On Tue, Nov 20, 2012 at 5:46 PM, Alexander Szlezak <alex@szlezak.com> wrote:
>> Hi,
>>
>> I can confirm this too. It exists in master mode too in recent trunk
>> (later than the version which is referred to as possible fix in trac),
>> we experienced it especially when using 3 vaps in master mode. Once it
>> occurs all clients hang. I'm willing to support a fix - let me know more
>> what is needed.
>>
>> best,
>> Alexander
>>
>> Am 20.11.2012 23:04, schrieb Georgiewskiy Yuriy:
>>> On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:
>>>
>>> Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
>>> i use many different cards but all ar9002 based.
>>>
>>> CL>Just FYI
>>> CL>
>>> CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
>>> CL>
>>> CL>I tried it on Dell laptop with ar9390 radio.
>>> CL>Still, I got error message like below
>>> CL>
>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
>>> CL>
>>> CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
>>> CL>
>>> CL>
>>> CL>-----------------------------
>>> CL>
>>> CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
>>> CL>Author: Felix Fietkau <nbd@openwrt.org>
>>> CL>Date:   Fri Oct 26 00:31:11 2012 +0200
>>> CL>
>>> CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
>>> CL>
>>> CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
>>> CL>
>>> CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
>>> CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
>>> CL>    an aggregation session), frames can be enqueued again as normal
>>> CL>    transmission, without bf_next being cleared. This can lead to the
>>> CL>    old pointer being dereferenced again later.
>>> CL>
>>> CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
>>> CL>
>>> CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>> CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>> CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> CL>_______________________________________________
>>> CL>ath9k-devel mailing list
>>> CL>ath9k-devel at lists.ath9k.org
>>> CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>> CL>
>>>
>>> C ?????????                       With Best Regards
>>> ???????????? ????.                Georgiewskiy Yuriy
>>> +7 4872 711666                    +7 4872 711666
>>> ???? +7 4872 711143               fax +7 4872 711143
>>> ???????? ??? "?? ?? ??????"       IT Service Ltd
>>> http://nkoort.ru                  http://nkoort.ru
>>> JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
>>> YG129-RIPE                        YG129-RIPE
>>>
>>>
>>>
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>> --
>> Follow me on Twitter @ http://twitter.com/magicshark
>> __________________________________________________________________
>> Mag. Alexander SZLEZAK
>>
>>
>> Reischergasse 6/2
>> A-1130 Vienna
>> Austria
>> M +43 699 1 350 41 01
>> E alex at szlezak.com
>>
>> https://www.xing.com/profile/Alexander_Szlezak
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Robert Shade]

The DMA messages and disconnects went away with the RHEL 6.2 kernel,
but the performance (measured by ping drops/latency) was still rather
poor.  In researching the poor performance, I found some threads
referencing the nohwcrypt module option.  Setting "nohwcrypt=1" not
only gets rid of the performance problem in RHEL 6.2, but eliminates
all of the performance issues and DMA related messages in 6.3 and 6.3
+ latest compat-drivers!  I can now do a flood ping for as long as I
want without packet drops.


On Wed, Nov 21, 2012 at 7:32 PM, Robert Shade <robert.shade@gmail.com> wrote:
> Some more points of data:
>
> * For my 9160, this appears to be a regression from RHEL 6.2 -> 6.3.
> I'm unable to replicate my issue with a flood ping on any RHEL 6.2
> kernel.  Pure speculation, but the messages complain about DMA issues
> and the patch notes indicate the "dma_unmap state API" was added in
> 6.3 [1].  The kernel changelog also says that the wireless in 6.3 is
> based off kernel 3.2, but I have not been able to find out what 6.2 is
> based off of.
>
> * I was also able to replicate the issue in Fedora Core 17 (kernel 3.3.4).
>
> [1]https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.3_Release_Notes/index.html
>
> On Tue, Nov 20, 2012 at 6:01 PM, Robert Shade <robert.shade@gmail.com> wrote:
>> I'm using the latest compat-drivers w/patches from 3.7-rc6 and I'm
>> able to make it happen "at will" with a flood ping to an AP with a
>> weak signal strength.  (I can do the same with the stock RHEL6 driver)
>>
>> When it happens, the client disconnects from the AP due to a perceived
>> lost beacon and reconnects.
>>
>> On Tue, Nov 20, 2012 at 5:46 PM, Alexander Szlezak <alex@szlezak.com> wrote:
>>> Hi,
>>>
>>> I can confirm this too. It exists in master mode too in recent trunk
>>> (later than the version which is referred to as possible fix in trac),
>>> we experienced it especially when using 3 vaps in master mode. Once it
>>> occurs all clients hang. I'm willing to support a fix - let me know more
>>> what is needed.
>>>
>>> best,
>>> Alexander
>>>
>>> Am 20.11.2012 23:04, schrieb Georgiewskiy Yuriy:
>>>> On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:
>>>>
>>>> Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
>>>> i use many different cards but all ar9002 based.
>>>>
>>>> CL>Just FYI
>>>> CL>
>>>> CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
>>>> CL>
>>>> CL>I tried it on Dell laptop with ar9390 radio.
>>>> CL>Still, I got error message like below
>>>> CL>
>>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
>>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
>>>> CL>
>>>> CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
>>>> CL>
>>>> CL>
>>>> CL>-----------------------------
>>>> CL>
>>>> CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
>>>> CL>Author: Felix Fietkau <nbd@openwrt.org>
>>>> CL>Date:   Fri Oct 26 00:31:11 2012 +0200
>>>> CL>
>>>> CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
>>>> CL>
>>>> CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
>>>> CL>
>>>> CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
>>>> CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
>>>> CL>    an aggregation session), frames can be enqueued again as normal
>>>> CL>    transmission, without bf_next being cleared. This can lead to the
>>>> CL>    old pointer being dereferenced again later.
>>>> CL>
>>>> CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
>>>> CL>
>>>> CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>>> CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>>> CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> CL>_______________________________________________
>>>> CL>ath9k-devel mailing list
>>>> CL>ath9k-devel at lists.ath9k.org
>>>> CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>> CL>
>>>>
>>>> C ?????????                       With Best Regards
>>>> ???????????? ????.                Georgiewskiy Yuriy
>>>> +7 4872 711666                    +7 4872 711666
>>>> ???? +7 4872 711143               fax +7 4872 711143
>>>> ???????? ??? "?? ?? ??????"       IT Service Ltd
>>>> http://nkoort.ru                  http://nkoort.ru
>>>> JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
>>>> YG129-RIPE                        YG129-RIPE
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ath9k-devel mailing list
>>>> ath9k-devel at lists.ath9k.org
>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>>
>>>
>>> --
>>> Follow me on Twitter @ http://twitter.com/magicshark
>>> __________________________________________________________________
>>> Mag. Alexander SZLEZAK
>>>
>>>
>>> Reischergasse 6/2
>>> A-1130 Vienna
>>> Austria
>>> M +43 699 1 350 41 01
>>> E alex at szlezak.com
>>>
>>> https://www.xing.com/profile/Alexander_Szlezak
>>> _______________________________________________
>>> ath9k-devel mailing list
>>> ath9k-devel at lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] FYI: "Failed to stop TX DMA!" not fixed in kernel 3.6.7

[Georgiewskiy Yuriy]

On 2012-11-26 20:06 -0500, Robert Shade wrote ath9k-devel at lists.ath9k.org:

Hm, this strange, i don't use encryption at all, and setting nohwcrypt=1
don't change anything for me with compat-wireless 3.6.6-1-snp, may be this
is just another trigger of this problem?

RS>The DMA messages and disconnects went away with the RHEL 6.2 kernel,
RS>but the performance (measured by ping drops/latency) was still rather
RS>poor.  In researching the poor performance, I found some threads
RS>referencing the nohwcrypt module option.  Setting "nohwcrypt=1" not
RS>only gets rid of the performance problem in RHEL 6.2, but eliminates
RS>all of the performance issues and DMA related messages in 6.3 and 6.3
RS>+ latest compat-drivers!  I can now do a flood ping for as long as I
RS>want without packet drops.
RS>
RS>
RS>On Wed, Nov 21, 2012 at 7:32 PM, Robert Shade <robert.shade@gmail.com> wrote:
RS>> Some more points of data:
RS>>
RS>> * For my 9160, this appears to be a regression from RHEL 6.2 -> 6.3.
RS>> I'm unable to replicate my issue with a flood ping on any RHEL 6.2
RS>> kernel.  Pure speculation, but the messages complain about DMA issues
RS>> and the patch notes indicate the "dma_unmap state API" was added in
RS>> 6.3 [1].  The kernel changelog also says that the wireless in 6.3 is
RS>> based off kernel 3.2, but I have not been able to find out what 6.2 is
RS>> based off of.
RS>>
RS>> * I was also able to replicate the issue in Fedora Core 17 (kernel 3.3.4).
RS>>
RS>> [1]https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.3_Release_Notes/index.html
RS>>
RS>> On Tue, Nov 20, 2012 at 6:01 PM, Robert Shade <robert.shade@gmail.com> wrote:
RS>>> I'm using the latest compat-drivers w/patches from 3.7-rc6 and I'm
RS>>> able to make it happen "at will" with a flood ping to an AP with a
RS>>> weak signal strength.  (I can do the same with the stock RHEL6 driver)
RS>>>
RS>>> When it happens, the client disconnects from the AP due to a perceived
RS>>> lost beacon and reconnects.
RS>>>
RS>>> On Tue, Nov 20, 2012 at 5:46 PM, Alexander Szlezak <alex@szlezak.com> wrote:
RS>>>> Hi,
RS>>>>
RS>>>> I can confirm this too. It exists in master mode too in recent trunk
RS>>>> (later than the version which is referred to as possible fix in trac),
RS>>>> we experienced it especially when using 3 vaps in master mode. Once it
RS>>>> occurs all clients hang. I'm willing to support a fix - let me know more
RS>>>> what is needed.
RS>>>>
RS>>>> best,
RS>>>> Alexander
RS>>>>
RS>>>> Am 20.11.2012 23:04, schrieb Georgiewskiy Yuriy:
RS>>>>> On 2012-11-19 19:33 -0000, Chaoxing Lin wrote linux-wireless at vger.kernel.or...:
RS>>>>>
RS>>>>> Hi all, i can confim this, "Failed to stop TX DMA!" steel exists in 802.11s and other modes too,
RS>>>>> i use many different cards but all ar9002 based.
RS>>>>>
RS>>>>> CL>Just FYI
RS>>>>> CL>
RS>>>>> CL>Kernel 3.6.7 change log says "This patch might fix crashes and "Failed to stop TX DMA!" messages."
RS>>>>> CL>
RS>>>>> CL>I tried it on Dell laptop with ar9390 radio.
RS>>>>> CL>Still, I got error message like below
RS>>>>> CL>
RS>>>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x005!"
RS>>>>> CL>"ath: phy0: Failed to stop TX DMA, queues=0x001!"
RS>>>>> CL>
RS>>>>> CL>I am testing 802.11s mesh on 802.11a channel 40, no HT enabled.
RS>>>>> CL>
RS>>>>> CL>
RS>>>>> CL>-----------------------------
RS>>>>> CL>
RS>>>>> CL>commit cd585fb70b89fb57f8dffb03a2a72c30f81f5da6
RS>>>>> CL>Author: Felix Fietkau <nbd@openwrt.org>
RS>>>>> CL>Date:   Fri Oct 26 00:31:11 2012 +0200
RS>>>>> CL>
RS>>>>> CL>    ath9k: fix stale pointers potentially causing access to free'd skbs
RS>>>>> CL>
RS>>>>> CL>    commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.
RS>>>>> CL>
RS>>>>> CL>    bf->bf_next is only while buffers are chained as part of an A-MPDU
RS>>>>> CL>    in the tx queue. When a tid queue is flushed (e.g. on tearing down
RS>>>>> CL>    an aggregation session), frames can be enqueued again as normal
RS>>>>> CL>    transmission, without bf_next being cleared. This can lead to the
RS>>>>> CL>    old pointer being dereferenced again later.
RS>>>>> CL>
RS>>>>> CL>    This patch might fix crashes and "Failed to stop TX DMA!" messages.
RS>>>>> CL>
RS>>>>> CL>    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
RS>>>>> CL>    Signed-off-by: John W. Linville <linville@tuxdriver.com>
RS>>>>> CL>    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RS>>>>> CL>_______________________________________________
RS>>>>> CL>ath9k-devel mailing list
RS>>>>> CL>ath9k-devel at lists.ath9k.org
RS>>>>> CL>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>>>>> CL>
RS>>>>>
RS>>>>> C ?????????                       With Best Regards
RS>>>>> ???????????? ????.                Georgiewskiy Yuriy
RS>>>>> +7 4872 711666                    +7 4872 711666
RS>>>>> ???? +7 4872 711143               fax +7 4872 711143
RS>>>>> ???????? ??? "?? ?? ??????"       IT Service Ltd
RS>>>>> http://nkoort.ru                  http://nkoort.ru
RS>>>>> JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
RS>>>>> YG129-RIPE                        YG129-RIPE
RS>>>>>
RS>>>>>
RS>>>>>
RS>>>>> _______________________________________________
RS>>>>> ath9k-devel mailing list
RS>>>>> ath9k-devel at lists.ath9k.org
RS>>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>>>>>
RS>>>>
RS>>>> --
RS>>>> Follow me on Twitter @ http://twitter.com/magicshark
RS>>>> __________________________________________________________________
RS>>>> Mag. Alexander SZLEZAK
RS>>>>
RS>>>>
RS>>>> Reischergasse 6/2
RS>>>> A-1130 Vienna
RS>>>> Austria
RS>>>> M +43 699 1 350 41 01
RS>>>> E alex at szlezak.com
RS>>>>
RS>>>> https://www.xing.com/profile/Alexander_Szlezak
RS>>>> _______________________________________________
RS>>>> ath9k-devel mailing list
RS>>>> ath9k-devel at lists.ath9k.org
RS>>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>_______________________________________________
RS>ath9k-devel mailing list
RS>ath9k-devel at lists.ath9k.org
RS>https://lists.ath9k.org/mailman/listinfo/ath9k-devel
RS>

C ?????????                       With Best Regards
???????????? ????.                Georgiewskiy Yuriy
+7 4872 711666                    +7 4872 711666
???? +7 4872 711143               fax +7 4872 711143
???????? ??? "?? ?? ??????"       IT Service Ltd
http://nkoort.ru                  http://nkoort.ru
JID: GHhost at icf.org.ru            JID: GHhost at icf.org.ru
YG129-RIPE                        YG129-RIPE