Re: [ath9k-devel] Script to crash ath9k with DMA errors.

[Felix Fietkau <nbd@openwrt.org>]

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