[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4DE525DB.1000908@openwrt.org>
Date: Tue, 31 May 2011 19:31:07 +0200
From: Felix Fietkau <nbd@...nwrt.org>
To: Nick Kossifidis <mickflemm@...il.com>
CC: "John W. Linville" <linville@...driver.com>,
Jiri Slaby <jirislaby@...il.com>,
"Luis R. Rodriguez" <lrodriguez@...eros.com>,
Bob Copeland <me@...copeland.com>,
linux-wireless@...r.kernel.org, ath5k-devel@...ema.h4ckr.net,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [ath5k-devel] ath5k regression associating with APs in 2.6.38
On 2011-05-17 7:14 PM, Nick Kossifidis wrote:
> 2011/5/17 Seth Forshee<seth.forshee@...onical.com>:
>> On Mon, May 09, 2011 at 09:02:30AM +0200, Seth Forshee wrote:
>>> On Thu, May 05, 2011 at 05:30:42PM +0300, Nick Kossifidis wrote:
>>> > Hmm I don't see any errors from reset/phy code, can you disable
>>> > Network Manager/wpa-supplicant and test connection on an open network
>>> > using iw ? It 'll give us a better picture...
>>> >
>>> > If iw doesn't return any scan results we are probably hitting a PHY/RF
>>> > error specific to your device (not all vendors follow the reference
>>> > design). Maybe we should follow a blacklist/whitelist approach for
>>> > this feature.
>>>
>>> I got the results back from my tester. He was able to get scan results,
>>> but it took multiple tries and the direct probe failures appear in the
>>> log. He didn't enable ATH5K_DEBUG_RESET this time; let me know if you
>>> need that and I'll request he retest with the extra debug logs enabled.
>>
>> I got some more feedback. Most of the time iw does not get scan results,
>> but even when it does connecting to the AP isn't always successful. The
>> tester did note that he doesn't seem to have any trouble if his machine
>> is within a few feet of his AP. Let me know if you'd like something else
>> tested.
>>
>> I noticed that bugzilla #31922 (ath5k: Decreased throughput in IBSS or
>> 802.11n mode) is also fixed by reverting 8aec7af9. It seems like the
>> synth-only channel changes are resulting in poor connection quality.
>> Maybe that patch needs to be reverted?
>>
>> Thanks,
>> Seth
>>
>>
>
> http://www.kernel.org/pub/linux/kernel/people/mickflemm/01-fast-chan-switch-modparm
Disabling fast channel change also fixed a reproducible crash on
Broadcom based MIPS boards with some cards (AR2413, I think).
- Felix
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists