On 2011-05-17 7:14 PM, Nick Kossifidis wrote:
2011/5/17 Seth Forshee<seth.forshee@xxxxxxxxxxxxx>:
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 linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
