What version of backport, compat-wireless or compat-drivers are you using? Without adding the "some" parameters to ieee80211s_hdr, did you experience the same problem?
--- Chun-Yeow On Fri, Nov 1, 2013 at 11:00 AM, syed moulana <[email protected]> wrote: > 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 >
_______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
