On 2010-12-06 9:28 PM, Ben Greear wrote:
> On 12/06/2010 11:53 AM, Luis R. Rodriguez wrote:
>> On Mon, Dec 06, 2010 at 11:53:13AM -0800, Luis Rodriguez wrote:
>>> On Mon, Dec 06, 2010 at 11:47:47AM -0800, Ben Greear wrote:
>>>> On 12/06/2010 11:36 AM, Luis R. Rodriguez wrote:
>>>>
>>>>> Can you clarify the status of this issue. It remains unclear to me from
>>>>> your above description how things are going. As I read it some things
>>>>> look OK now but you still get a warning.
>>>>
>>>> Ok, since you asked :)
>>>>
>>>> I worked on this over the weekend and this morning. I had all sorts of
>>>> issues until I realized that I had one STA with non-configured SSID.
>>>> It sometimes connected to one /a AP and the other STAs attempted to connect
>>>> to another /n (on entirely different band) AP. I basically got zero stations associated for any length
>>>> of time due to constant channel switching. No crashes, but lots of
>>>> warnings about DMA failing to stop.
>>>>
>>>> Now..I've fixed this configuration issue (and adding steps to help prevent this mis-configuration
>>>> again).
>>>>
>>>> With 16 properly configured non-encrypted stations, running with wpa-supplicant
>>>> with netlink driver& sharing scan results, the interfaces quickly associate.
>>>>
>>>> However, I do continue to see DMA warnings such as these (I had picked up my
>>>> portable phone, and it knocked all the interfaces offline ..here
>>>> they are coming back up after I hung up the phone).
>>>>
>>>> Please note that I ported Felix's 2.6.37 patch he posted this morning
>>>> to wireless-testing and have applied it.
>>>>
>>>> I'm highly tempted to just make that a WARN_ON_ONCE so at least my logs
>>>> aren't spammed so heavily with the recv.c:531 DMA warning.
>>>
>>> You can send this change upstream as well.
>>
>> Also, feel free to limit the number of STAs you can have up
>> physically by setting this to a number you bless yourself.
>
> I have a feeling there is no hard limit..but if I do find one,
> I'll cook up a patch. Probably not many of us ever going to push
> anywhere near what I'm trying, and folks like me can limit in
> user-space if wanted...
>
> I'll do up the warn-on-once patch shortly.
>
> By the way, would you consider this channel-change suppression
> patch, or something similar?
>
>
> -------------------- drivers/net/wireless/ath/ath9k/main.c --------------------
> index f026a03..6c1c43b 100644
> @@ -1605,6 +1605,16 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
> else
> sc->sc_flags &= ~SC_OP_OFFCHANNEL;
>
> + /* If channels & HT are the same, then don't actually do anything.
> + */
> + if ((sc->sc_ah->curchan == &sc->sc_ah->channels[pos]) &&
> + (aphy->chan_is_ht == conf_is_ht(conf))) {
> + ath_print(common, ATH_DBG_CONFIG,
> + "Skip Set channel: %d MHz, already there.\n",
> + curchan->center_freq);
> + goto skip_chan_change;
> + }
> +
I think this needs to check the offchannel flag as well, at least in one
direction. Skipping on-channel -> off-channel is fine, but the other way
around might break calibration
- Felix
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
