Werner,
Werner Almesberger wrote:
> Three of the current WLAN problems appear to be caused by flaws in the
> firmware. I've reported them to Atheros and they're looking into the
> issues. Specifically, these are:
>
> - Target assertion at line 0x393
> - Target assertion at line 0x87A
> - AR6k sometimes associates at the wrong channel when roaming
>
> The target associations are serious because all we can do to recover
> from them is to reset the module. The channel problem causes obscure
> performance degradation when it happens, but it seems to need a fairly
> exotic environment to occur and may not matter all that much in real
> life.
>
> There are two more issues that I'm currently investigating:
>
> - sometimes, the key exchange of wpa_supplicant fails, causing
> indefinite attempts to associate.
>
> So far, this appears to happen only when I do one successful
> association, get a DHCP lease, and then restart wpa_supplicant.
> I've also only seen it with a WRT54G running the orignal Linksys
> firmware, but not with a PC acting as AP.
>
> The key exchange fails because the answers wpa_supplicant thinks
> it's sending apparently never get put in the air, but I don't
> know yet where exactly they get lost.
>
> - FSO MS5 is reported to have troubles with WPA as well. I haven't
> reproduced this one yet.
While trying to debug WiFi uptime issues using:
wlan-trial-20090206.uImage
openmoko-fso-image-glibc-ipk--20090202-om-gta02.rootfs.jffs2
I have been trying to use the following u-boot (NOR) CLI commands:
setenv bootargs_base ${bootargs_base} log_buf_len=2M
setenv bootcmd setenv bootargs \${bootargs_base} \${mtdparts}\; nand
read.e 0x32000000 kernel 0x300000\; bootm 0x32000000
boot
even WITHOUT the backslash that I had previously before the "$" in line
one, this line still seems to be a problem - at each boot, I STILL get
the FR taking forever to start with hundreds of lines like:
[xxxx:yyyyyy] r5:.... r4:.....
[xxxx:yyyyyy] ..... kernel ....
[xxxx:yyyyyy] r5:0000... r4:0000.....
Do you want me to try anything else with this setup or should I just
start testing the uptime on more recent images?
Regards,
Phil.
--
Philip Rhoades
GPO Box 3411
Sydney NSW 2001
Australia
E-mail: p...@pricom.com.au
_______________________________________________
devel mailing list
devel@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/devel
