>Number: 166286 >Category: kern >Synopsis: [net80211] [ath] initial switch to HT40 isn't causing a >hardware channel change call >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 21 00:00:28 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release: 9.0-RELEASE i386, with -HEAD net80211/ath >Organization: >Environment: >Description:
I've been seeing issues with TX failing. Mar 20 16:45:39 marilyn kernel: wlan0: sta_newstate: AUTH -> ASSOC (0) Mar 20 16:45:39 marilyn kernel: [101308] ath0: ath_txq_update: Q1 qflags 0xf aifs 3 cwmin 15 cwmax 1023 burstTime 0 Mar 20 16:45:39 marilyn kernel: [101308] ath0: ath_txq_update: Q0 qflags 0xf aifs 7 cwmin 15 cwmax 1023 burstTime 0 Mar 20 16:45:39 marilyn kernel: [101308] ath0: ath_txq_update: Q2 qflags 0xf aifs 2 cwmin 7 cwmax 15 burstTime 3008 Mar 20 16:45:39 marilyn kernel: [101308] ath0: ath_txq_update: Q3 qflags 0xf aifs 2 cwmin 3 cwmax 7 burstTime 1504 Mar 20 16:45:39 marilyn kernel: wlan0: [00:24:6c:04:f0:79] switch station to HT20 channel 5200/0x210140 Mar 20 16:45:39 marilyn kernel: [101308] ath0: ath_setslottime: chan 5200 MHz flags 0x200140 short slot, 9 usec Mar 20 16:45:39 marilyn kernel: wlan0: [00:24:6c:04:f0:79] assoc success at aid 3: short preamble, short slot time, QoS, HT20 (+AMPDU) Mar 20 16:45:39 marilyn kernel: wlan0: ieee80211_new_state_locked: ASSOC -> RUN (nrunning 0 nscanning 0) Mar 20 16:45:39 marilyn kernel: wlan0: ieee80211_newstate_cb: ASSOC -> RUN arg 16 Mar 20 16:45:39 marilyn kernel: wlan0: sta_newstate: ASSOC -> RUN (16) Mar 20 16:45:39 marilyn kernel: wlan0: link state changed to UP Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_chan_set: 40 (5200 MHz, flags 0x210140) Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_stoprecv: rx queue 0x384100c0, link 0xe9a20060 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_stoptxdma: tx queue [9] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [0] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [1] 0xe92e3c0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [2] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [3] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [8] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_stoptxdma: tx queue [9] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [0] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [1] 0xe92e3c0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [2] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [3] 0, link 0 Mar 20 16:45:39 marilyn kernel: [101309] ath0: ath_tx_stopdma: tx queue [8] 0, link 0 Mar 20 16:45:39 marilyn kernel: ar5416Set11nRegs: chan isht40=0, isht40d=0, isht40u=0, phymode=0x3c0, macmode=0 Mar 20 16:45:39 marilyn kernel: ar5416PerCalibrationN: NF calibration didn't finish; delaying CCA Mar 20 16:45:39 marilyn kernel: wlan0: [00:24:6c:04:f0:79] switch station to HT40 channel 5200/0x240140 >How-To-Repeat: This may be AP specific/dependent. I've not seen this when associating to many work (atheros) or home (freebsd) APs. But this particular one, for whatever reason, is exhibiting this issue. This is on an open access point, rather than one protected by WEP/WPA. # ifconfig wlan0 create wlandev ath0 ssid <SSID> -bgscan up It then shows up in ifconfig as a ht40- AP. xmit debugging (sysctl dev.ath.0.debug=0x3) shows that the frames are being TXed with the HT2040 bit set to 1, thus the frame is trying to go out in 40MHz mode. However, the hardware is configured for 20MHz operation: * AR_PHY_TURBO doesn't have AR_PHY_FC_DYN2040_EN set; * AR_2040_MODE is 0, so the pri/ext RX_CLEAR line isn't being programmed in. Thus any TX will fail, as the rate control code currently transmits _only_ 40MHz frames at this point. Legacy frames will succeed however as they are always transmitted at 20MHz. A manual scan fixes the issue. A background scan also fixes the issue and likely hid this brokenness in the past as once the background scan completes, the hardware is re-initialised into 40MHz mode. >Fix: I'm not sure yet. I need to add some thread debugging to net80211 to see which thread(s) are doing the HT update. It may be one SMP race where the HT40 IE is parsed in another thread and the channel change completes before the IE is parsed and updated. In any case, I do think it's a net80211 issue, as it likely is missing a call to ic_chan_set() after the operational mode change. >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
