Hello Zefir, On Fri, Apr 05, 2013 at 12:08:05PM +0200, Zefir Kurtisi wrote: > On 04/04/2013 08:22 PM, Simon Wunderlich wrote: > > [...] > > > > So the patch does not resolve the problem for you? I've checked it again with > > a little printk in ath9ks config function. > > > > With the patch the radar_enabled flag gets disabled when changing the channel (5500 -> 5200). > > If I don't apply the patch, it stays enabled. I did the same thing (start hostapd on > > channel 5500, wait for CAC, echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/simulate_radar). > > > > Maybe I'm missing something? > > > Hi Simon, > > here is how to reproduce (assuming you are using the patches for DFS testing on > ath9k posted yesterday). > > 1) enable DFS log output at ath9k > echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/debug > > 2) run hostapd on DFS channel, my config is as follows > interface=wlan3 > driver=nl80211 > ssid=testap > hw_mode=a > channel=108 > wmm_enabled=1 > ieee80211d=1 > ieee80211h=1 > country_code=DE > wpa_group_rekey=300 > wpa_gmk_rekey=640 > wpa=2 > wpa_key_mgmt=WPA-PSK > wpa_pairwise=CCMP > wpa_passphrase=testtest > > The log output I see is: > Apr 5 11:44:00: [ 335.210749] IPv6: ADDRCONF(NETDEV_UP): wlan3: link is not ready > Apr 5 11:44:00: [ 335.221152] ath: phy0: DFS enabled at freq 5540 > Apr 5 11:44:04: [ 339.234487] ath: phy0: DFS enabled at freq 5540 > Apr 5 11:44:04: [ 339.260298] ath: phy0: DFS enabled at freq 5540 > Apr 5 11:44:04: [ 339.262750] ath: phy0: DFS enabled at freq 5540 > Apr 5 11:44:04: [ 339.262786] IPv6: ADDRCONF(NETDEV_CHANGE): wlan3: link becomes ready > > So we passed the (shortened to 4s) CAC and AP is operating. > > 3) fire radar > echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/simulate_radar > > I see: > Apr 5 11:44:25: [ 360.294667] ath: phy0: DFS enabled at freq 5540 > Apr 5 11:44:25: [ 360.297217] ath: phy0: DFS enabled at freq 5240 > > > The 'DFS enabled ...' message is print if ath9k_config() is called with > hw->conf.radar_enabled, which should never happen for freq 5240. > > > I wish I had time to learn using ftrace to track it down... As said before, it is > not critical for ath9k, but might be a hint to something going wrong above. Thanks for explaining, I could now see what's happening. I've added another debug messages for "DFS not enabled" in the other case. What I get when running your example (and with my patch applied) is: NOTE: hostapd started [ 668.576380] ath: phy0: DFS not enabled at freq 5540 [ 668.594108] ath: phy0: DFS enabled at freq 5540 [ 672.607996] ath: phy0: DFS enabled at freq 5540 [ 672.928911] ath: phy0: DFS enabled at freq 5540 [ 672.939416] ath: phy0: DFS enabled at freq 5540 [ 704.128876] ath: phy0: DFS enabled at freq 5540 NOTE: radar triggered here [ 704.138482] ath: phy0: DFS enabled at freq 5240 [ 704.149684] ath: phy0: DFS not enabled at freq 5240 Now what happens is: 1. vif_use_channel() calls ieee80211_new_chanctx(), which calls ieee80211_hw_config(). radar flags are not "recalc"d, so the previous value is used 2. Later in vif_use_channel(), ieee80211_recalc_radar_chanctx() is called, which sets the radar flag and calls ieee80211_hw_config() again. As you can see in the output, the right value is applied ~10 - 20ms after the wrong value, at least with the patch originally posted here. Of course this is not beautiful, but should work in practice. We could consider changing this by already applying the correct radar flag in ieee80211_new_chanctx()? If you want, I can post a patch for that. SMPS probably has a similar problem to have the wrong value you set for a short time ... Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
