Re: [Testing] Wireless test results
On Mon, Feb 16, 2009 at 12:22 PM, Gary C Martin g...@garycmartin.com wrote: On 16 Feb 2009, at 05:32, Chris Ball wrote: Hi, Last I checked, it was either the firmware or the kernel changes that did it. I posted my findings to the mailing list in the past two weeks. I think your findings actually say it was either the firmware, kernel, or something else altogether. It'd be good to downgrade both at once, but still on candidate-800, so that we can check that at least *one* of the two is the problem. I should be asleep, but instead have been zigzagging through old http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/ staging builds testing WPA and the dialogue cancel dance for the last 4hrs: 790 working 4 working 5 working 6 working - 7 intermittent 11 intermittent 15 broken 800 broken Intermittent means it can occasionally associate with a WPA access point with no cancel dance, but usually I had to dance. Broken means I had to dance every time. One thing I noticed when testing the working 4, 5 and 6 that may help, is that if you do naughtily click an already connected WPA access point you'll get back to one round of the WPA cancel dance. If you make sure you first select 'disconnect' then click the AP again, you get correctly re-associated, no dance required. This suggests that clicking a connected AP should either do NOP, or should at least disconnect properly before trying to connect again. The sound you just heard was my head hitting the pillow :-) I reported this before with build 26 I believe, but it might be of use to point out again. Also on 800, the ability of the XO to connect to an AP have been greatly increased over 767. At the moment connecting to a WPA ap succeeds one in two times. On 767 it varied from 1 in 5 to 1 in 10 to 1 in can't be bothered to try and connect to the fr!@@n access point. I already supplied some logs, but if you'd like some more specific testing output of our setup, I'd be happy to supply it. Just tell what you want to know. /Ties ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] Wireless test results
I find 767, with either q2e18 or q2e24, connecting to a WPA AP succeeds 100% of the time for me using a Linksys WRT54g L. With OFW q2e32 I have seen the network connection die. Seems like the stack is dead. I assume it is the marvell driver that is delivered with q2e32. My other XO running 767 with q2e18 maintains its connectivity. On Feb 16, 2009, at 12:11 AM, Ties Stuij wrote: On Mon, Feb 16, 2009 at 12:22 PM, Gary C Martin g...@garycmartin.com wrote: On 16 Feb 2009, at 05:32, Chris Ball wrote: Hi, Last I checked, it was either the firmware or the kernel changes that did it. I posted my findings to the mailing list in the past two weeks. I think your findings actually say it was either the firmware, kernel, or something else altogether. It'd be good to downgrade both at once, but still on candidate-800, so that we can check that at least *one* of the two is the problem. I should be asleep, but instead have been zigzagging through old http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/ staging builds testing WPA and the dialogue cancel dance for the last 4hrs: 790 working 4 working 5 working 6 working - 7 intermittent 11 intermittent 15 broken 800 broken Intermittent means it can occasionally associate with a WPA access point with no cancel dance, but usually I had to dance. Broken means I had to dance every time. One thing I noticed when testing the working 4, 5 and 6 that may help, is that if you do naughtily click an already connected WPA access point you'll get back to one round of the WPA cancel dance. If you make sure you first select 'disconnect' then click the AP again, you get correctly re-associated, no dance required. This suggests that clicking a connected AP should either do NOP, or should at least disconnect properly before trying to connect again. The sound you just heard was my head hitting the pillow :-) I reported this before with build 26 I believe, but it might be of use to point out again. Also on 800, the ability of the XO to connect to an AP have been greatly increased over 767. At the moment connecting to a WPA ap succeeds one in two times. On 767 it varied from 1 in 5 to 1 in 10 to 1 in can't be bothered to try and connect to the fr!@@n access point. I already supplied some logs, but if you'd like some more specific testing output of our setup, I'd be happy to supply it. Just tell what you want to know. /Ties ___ Testing mailing list test...@lists.laptop.org http://lists.laptop.org/listinfo/testing ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] Wireless test results
The OS is supposed to reload the wireless firmware so the firmware that is in OFW shouldn't affect the OS behavior. rihowa...@gmail.com wrote: I find 767, with either q2e18 or q2e24, connecting to a WPA AP succeeds 100% of the time for me using a Linksys WRT54g L. With OFW q2e32 I have seen the network connection die. Seems like the stack is dead. I assume it is the marvell driver that is delivered with q2e32. My other XO running 767 with q2e18 maintains its connectivity. On Feb 16, 2009, at 12:11 AM, Ties Stuij wrote: On Mon, Feb 16, 2009 at 12:22 PM, Gary C Martin g...@garycmartin.com wrote: On 16 Feb 2009, at 05:32, Chris Ball wrote: Hi, Last I checked, it was either the firmware or the kernel changes that did it. I posted my findings to the mailing list in the past two weeks. I think your findings actually say it was either the firmware, kernel, or something else altogether. It'd be good to downgrade both at once, but still on candidate-800, so that we can check that at least *one* of the two is the problem. I should be asleep, but instead have been zigzagging through old http://xs-dev.laptop.org/~cscott/xo-1/streams/staging/ staging builds testing WPA and the dialogue cancel dance for the last 4hrs: 790 working 4 working 5 working 6 working - 7 intermittent 11 intermittent 15 broken 800 broken Intermittent means it can occasionally associate with a WPA access point with no cancel dance, but usually I had to dance. Broken means I had to dance every time. One thing I noticed when testing the working 4, 5 and 6 that may help, is that if you do naughtily click an already connected WPA access point you'll get back to one round of the WPA cancel dance. If you make sure you first select 'disconnect' then click the AP again, you get correctly re-associated, no dance required. This suggests that clicking a connected AP should either do NOP, or should at least disconnect properly before trying to connect again. The sound you just heard was my head hitting the pillow :-) I reported this before with build 26 I believe, but it might be of use to point out again. Also on 800, the ability of the XO to connect to an AP have been greatly increased over 767. At the moment connecting to a WPA ap succeeds one in two times. On 767 it varied from 1 in 5 to 1 in 10 to 1 in can't be bothered to try and connect to the fr!@@n access point. I already supplied some logs, but if you'd like some more specific testing output of our setup, I'd be happy to supply it. Just tell what you want to know. /Ties ___ Testing mailing list test...@lists.laptop.org http://lists.laptop.org/listinfo/testing ___ Testing mailing list test...@lists.laptop.org http://lists.laptop.org/listinfo/testing ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] Wireless test results
On Mon, Feb 16, 2009 at 11:21:34AM -1000, Mitch Bradley wrote: The OS is supposed to reload the wireless firmware so the firmware that is in OFW shouldn't affect the OS behavior. Agreed. It shouldn't. I wonder if it does, through some mechanism we don't know yet. Has anyone else got the recent OS build to operate fine on WPA with an older version of OFW? -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Testing] Wireless test results
James Cameron wrote: On Mon, Feb 16, 2009 at 11:21:34AM -1000, Mitch Bradley wrote: The OS is supposed to reload the wireless firmware so the firmware that is in OFW shouldn't affect the OS behavior. Agreed. It shouldn't. I wonder if it does, through some mechanism we don't know yet. Has anyone else got the recent OS build to operate fine on WPA with an older version of OFW? One could try adding wlan-reset to /boot/olpc.fth, thus ensuring that the wireless module is not carrying over any state from the firmware. In the normal case of booting from NAND (or USB or SD), OFW doesn't even turn on the wireless module. This is easy to confirm - just observe that the wireless led doesn't turn on until well into the OS startup. I'm quite sure that the OS wireless code doesn't extract the wireless firmware image from OFW - it could in theory do so, but I'm sure that it doesn't - it gets it from the filesystem. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
