Probably, you need to take a look on whether adding the extra field in the mesh header breaking the ieee80211_get_qos_ctl.
--- Chun-Yeow On Fri, Nov 1, 2013 at 3:38 PM, Yeoh Chun-Yeow <[email protected]>wrote: > Probably, you need to take a look on whether adding the extra field in the > mesh header breaking the ieee80211_get_qos_ctl. > > --- > Chun-Yeow > > > On Fri, Nov 1, 2013 at 11:34 AM, syed moulana <[email protected]>wrote: > >> Hi Chun-Yeow >> >> tq for the reply. >> >> I am using linux-2.6.35 and compat-drivers-3.8-1. >> >> Without adding the parameter ...I am not getting any WARN_ON. >> >> When we add parameter to fixed part of mesh header, what are relevant >> code in compat-drivers-3.8-1 we have to change? >> >> >> tq >> syed >> >> >> On Friday, November 1, 2013 11:13 AM, Yeoh Chun-Yeow < >> [email protected]> wrote: >> >> 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
