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 <[email protected]>
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 <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
On 2012-11-19 19:33 -0000, Chaoxing Lin wrote [email protected]...:
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 <[email protected]>
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 <[email protected]>
CL> Signed-off-by: John W. Linville <[email protected]>
CL> Signed-off-by: Greg Kroah-Hartman <[email protected]>
CL>--
CL>To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
CL>the body of a message to [email protected]
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: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE
On 2012-11-19 19:33 -0000, Chaoxing Lin wrote [email protected]...:
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 <[email protected]>
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 <[email protected]>
CL> Signed-off-by: John W. Linville <[email protected]>
CL> Signed-off-by: Greg Kroah-Hartman <[email protected]>
CL>_______________________________________________
CL>ath9k-devel mailing list
CL>[email protected]
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: [email protected] JID: [email protected]
YG129-RIPE YG129-RIPE