Hi
I am getting WARN_ON at the following location in function ath_tx_start_dma.
static void ath_tx_start_dma(struct ath_softc *sc, struct sk_buff *skb,
struct ath_tx_control *txctl)
{
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct ath_atx_tid *tid = NULL;
struct ath_buf *bf;
u8 tidno;
if ((sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) && txctl->an &&
ieee80211_is_data_qos(hdr->frame_control)) {
tidno = ieee80211_get_qos_ctl(hdr)[0] &
IEEE80211_QOS_CTL_TID_MASK;
tid = ATH_AN_2_TID(txctl->an, tidno);
WARN_ON(tid->ac->txq != txctl->txq);
}
Please help me understand this situation. On what data conditions I should be
getting this. For futher info....
I did not change anything on the ath driver level. We are trying to add some
parameter to ieee80211s_hdr in IEEE80211 MAC.
For my test scenario it happens only, when we pump lot of data to the driver,
while transmitting between wireless mesh nodes. It kind of happening when we
reach some data threshold on the queues and something get corrupted.
So there is no match for mac80211_qnum parameter inside the structures
tid->ac->txq and txctl->txq.
Here is the WARN_ON splat
-----------------------------------------------------
Badness at c9b057c0 [verbose debug info unavailable]
NIP: c9b057c0 LR: c9b05790 CTR: c01bb04c
REGS: c7ffbd60 TRAP: 0700 Tainted: G W (2.6.35)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24008082 XER: 20000000
TASK = c7ae8000[952] 'phy0' THREAD: c7abc000
GPR00: 00000001 c7ffbe10 c7ae8000 00000032 c7b8a09c c7b8a194 c01b85bc 00100000
GPR08: 00000036 00000108 000cfe47 00000107 24008022 100b1254 07ff9000 00000000
GPR16: 100e0db0 00000000 00000001 00000000 c7b88a80 c7b8a194 c6fc2040 00000274
GPR24: c6f10300 c7b89740 c7ffbe78 00000000 c6a610d8 c6fc2040 c6f1052c c6a610c0
NIP [c9b057c0] ath_tx_start+0x398/0x5a4 [ath9k]
LR [c9b05790] ath_tx_start+0x368/0x5a4 [ath9k]
Call Trace:
[c7ffbe10] [c9b05790] ath_tx_start+0x368/0x5a4 [ath9k] (unreliable)
[c7ffbe70] [c9b004cc] ath9k_tx+0xa0/0x180 [ath9k]
[c7ffbeb0] [c99b5eb8] __ieee80211_tx+0x180/0x340 [mac80211]
[c7ffbef0] [c99b6150] ieee80211_tx+0xd8/0x110 [mac80211]
[c7ffbf50] [c99b64d8] ieee80211_tx_pending+0xd0/0x22c [mac80211]
[c7ffbf90] [c002b714] tasklet_action+0x84/0x100
[c7ffbfb0] [c002b83c] __do_softirq+0xac/0x128
[c7ffbff0] [c0010aac] call_do_softirq+0x14/0x24
[c7abdf30] [c0006214] do_softirq+0x78/0x84
[c7abdf50] [c002baf4] local_bh_enable+0xa0/0xa4
[c7abdf60] [c99a1390] ieee80211_ba_session_work+0x78/0x194 [mac80211]
[c7abdf80] [c0039388] worker_thread+0x108/0x1b0
[c7abdfc0] [c003d328] kthread+0x78/0x7c
[c7abdff0] [c0010f08] kernel_thread+0x4c/0x68
Instruction dump:
57cb3032 801a0004 57c92036 7d295a14 80ba0000 7d290214 3bc9000c 817e0018
808b0000 7c892a78 3169ffff 7c0b4910 <0f000000> 7f842800 419e01ec 80840000
---------------------------------------------------------------
I was using iperf tool to send UDP packets.
The testbed is 3 mesh nodes where the far end nodes does not see each other.
And the WARN_ON comes up only the intermediate node that peered with both far
end nodes.
tq
Syed
_______________________________________________
Devel mailing list
[email protected]
http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
