XO-1.5 network disconnection button testing
G'day, Those of you who have been testing XO-1.5 builds may have noticed that you cannot disconnect from a wireless network, and you cannot discard network history. The workaround was to remove connections.cfg. Per ticket #9977 and #9788, I've made some changes to Sugar network connection handling code and need some testers. The changes are: - enable the disconnect button on the access point menu in the neighbourhood view, (rather than the button doing nothing), - fix the disconnect button on the wireless device icon in the frame so that the disconnection remains effective, (rather than only disconnecting and reconnecting automatically), - enable the discard network history button in the network control panel, which also now forces a disconnect, and will be insensitive (greyed out) if there are no networks to be discarded, (rather than the button doing nothing), - enforce consistency between the neighbourhood view, the frame, and the control panel, with respect to how the access point is shown. The changes are available as a .tar.gz to simplify testing. Once applied the change will be present until the laptop is reflashed or an olpc-update is done. Instructions for installing: a. check that you are running os114 or os116 (only these versions have been tested, but there is very little reason why other versions in the os1xx series would not work), b. start Terminal or login over SSH, and become root, c. download the tar.gz file to /tmp on the laptop, cd /tmp wget \ http://dev.laptop.org/raw-attachment/ticket/9977/9977-insensitive.tar.gz d. unpack over the top of the root filesystem, cd / ; tar xfz /tmp/9977-insensitive.tar.gz e. restart Sugar using Control-Alt-Erase or Restart, but not by forcing a power down. Instructions for testing: A. confirm that Sugar connects to your preferred access point on restart, if any is defined, B. try to disconnect using the neighbourhood view, note the result, (right-click on the access point icon), C. reconnect, D. try to disconnect using the frame icon for the wireless device, (right-click on the icon, or hover, in the usual fashion), E. reconnect, F. discard the network history, note the result, G. reconnect, note a reprompt if access point is secured, H. use your initiative to try other scenarios, such as whether there is any impact on wired networking, I. report success or failure to the tickets or the mailing list or me. Thanks! -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
SSE/SSE2 support in os116
Happened to run an older version of mplayer on os116 on XO-1.5, and it claimed "SSE supported but disabled" (also for SSE2). So I looked in some Linux forums, and saw there: "CPUID will tell you whether the CPU supports SSE/SSE2, but not the OS. The OS (linux in this case) can have SSE and/or SSE2 disabled." I looked in the config file residing in the boot directory in os116, but saw nothing there about the enabling of SSE or SSE2 (not even of MMX). My question -- was the older mplayer mistaken -- or is SSE/SSE2 actually disabled in os116 ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC/Paraguay] Debugging NetworkManager-0.7.2.995 + Power Management
On Tue, 2010-03-30 at 14:07 -0300, Bernie Innocenti wrote:
> On Tue, 2010-03-30 at 09:16 -0700, Dan Williams wrote:
> > Yeah, I haven't been able to reproduce that, but I only have an XO1.5
> > with me (which doesn't have mesh), and I think the issue is timing
> > related. So it's good that you can reproduce it. That gives us a chance
> > to fix it.
>
> We could definitely reproduce the issue also on the XO-1.5, using os115
> from OLPC:
But... the 1.5 doesn't have the mesh capability (unless you're using a
dongle?) and thus wouldn't hit the codepath specified, no?
Unless there's some really, really egregious bug in the original mesh
code in NM that calls into the mesh device without any mesh device
having ever been created, that is...
> http://build.laptop.org/10.2.0/os115
>
> Just leave the automatic power management on and let the system go to
> sleep a few times.
Sugar or GNOME?
At least if you can reproduce with a 1.5 then I have chance of seeing it
in action too.
Dan
>
> > So what is going on is that the mesh device and the wifi device are
> > obviously the "same" device, because they really share the same silicon.
> > So we need to make sure the mesh device knows about it's companion wifi
> > device.
> >
> > Can I get some /var/log/messages logging from NetworkManager over a
> > suspend/resume cycle? I'd like to see if the kernel removes either the
> > wifi or the mesh device and then adds it back after resume, or whether
> > the device sticks around throughout the entire cycle.
>
> >From what I've seen in gdb after the segfault, it looked very much like
> the is_companinion() callback had being invoked an object that has been
> already freed. The GObject class was zeroed out.
>
> I'll wait for Martin (tch) to come back from lunch to send you the full
> log.
>
>
> > This segfault indicates one of two things:
> >
> > 1) a reference counting issue; there's a missing g_object_ref()
> > somewhere, which means that the Mesh object is getting unreffed one too
> > many times, leading to its destruction
> >
> > 2) the kernel is removing the underlying device and there's a missing
> > idle, timeout, or signal clear command. The mesh device listens for a
> > number of signals of other objects, but when the mesh object gets
> > destroyed, we need to remember to stop listening for those signals or
> > we'll end up in the signal handler after the object is destroyed
> > ("use-after-free").
>
> We looked for paths where the signal is being attached and removed, and
> it *looked* like removal was being done correctly on disposal. Tch added
> some debug output to track the life-cycle of objects.
>
>
> > Can I also get a backtrace of the crash? Bernie's backtrace didn't have
> > debugging info, which your clearly have.
>
> Tch will follow up with the complete backtrace, he has a debugging
> environment where NM was built from sources.
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [OLPC/Paraguay] Debugging NetworkManager-0.7.2.995 + Power Management
On Tue, 2010-03-30 at 09:16 -0700, Dan Williams wrote:
> Yeah, I haven't been able to reproduce that, but I only have an XO1.5
> with me (which doesn't have mesh), and I think the issue is timing
> related. So it's good that you can reproduce it. That gives us a chance
> to fix it.
We could definitely reproduce the issue also on the XO-1.5, using os115
from OLPC:
http://build.laptop.org/10.2.0/os115
Just leave the automatic power management on and let the system go to
sleep a few times.
> So what is going on is that the mesh device and the wifi device are
> obviously the "same" device, because they really share the same silicon.
> So we need to make sure the mesh device knows about it's companion wifi
> device.
>
> Can I get some /var/log/messages logging from NetworkManager over a
> suspend/resume cycle? I'd like to see if the kernel removes either the
> wifi or the mesh device and then adds it back after resume, or whether
> the device sticks around throughout the entire cycle.
>From what I've seen in gdb after the segfault, it looked very much like
the is_companinion() callback had being invoked an object that has been
already freed. The GObject class was zeroed out.
I'll wait for Martin (tch) to come back from lunch to send you the full
log.
> This segfault indicates one of two things:
>
> 1) a reference counting issue; there's a missing g_object_ref()
> somewhere, which means that the Mesh object is getting unreffed one too
> many times, leading to its destruction
>
> 2) the kernel is removing the underlying device and there's a missing
> idle, timeout, or signal clear command. The mesh device listens for a
> number of signals of other objects, but when the mesh object gets
> destroyed, we need to remember to stop listening for those signals or
> we'll end up in the signal handler after the object is destroyed
> ("use-after-free").
We looked for paths where the signal is being attached and removed, and
it *looked* like removal was being done correctly on disposal. Tch added
some debug output to track the life-cycle of objects.
> Can I also get a backtrace of the crash? Bernie's backtrace didn't have
> debugging info, which your clearly have.
Tch will follow up with the complete backtrace, he has a debugging
environment where NM was built from sources.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Slowing down an XO-1.5
On Mar 30, 2010, at 9:56 AM, Mikus Grinbergs wrote: >> Is there a simple way from OFW (or ACPI) to restrict >> the operating frequency of the processor in the XO-1.5 >> to be the lowest possible ? >> >> The relevant comment from a deployment was that they >> can't use full speed XO-1.5 motherboards as replacements >> for XO-1 motherboards. They think kids would break their >> laptop to get it upgraded... > > I would expect any kid enterprising enough to break a laptop in order to > get it upgraded -- to also be enterprising enough to "hack" the > replacement to bypass any software restrictions. Only when the > replacement (despite determined attack) cannot be made better than the > original would the risk of kids "breaking their laptop" be diminished. In Uruguay, the kids can't get to OFW. And if you read further, the software hack is more tor testing the viability of motherboards using lower cost scrapped processors. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Slowing down an XO-1.5
>Is there a simple way from OFW (or ACPI) to restrict > the operating frequency of the processor in the XO-1.5 > to be the lowest possible ? > > The relevant comment from a deployment was that they > can't use full speed XO-1.5 motherboards as replacements > for XO-1 motherboards. They think kids would break their > laptop to get it upgraded... I would expect any kid enterprising enough to break a laptop in order to get it upgraded -- to also be enterprising enough to "hack" the replacement to bypass any software restrictions. Only when the replacement (despite determined attack) cannot be made better than the original would the risk of kids "breaking their laptop" be diminished. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Slowing down an XO-1.5
The "4" is 406 is for 400 Mhz. The normal value is "a06", where "a" is decimal 10 for 1000 Mhz. The "6" is the voltage selection code; this processor only supports the value "6". Mitch Bradley wrote: > ok 406. 199 msr! > > The period after 406 is mandatory - it forces the number to be > 64-bits, suitable as the data operand to msr!. > > > John Watlington wrote: >> Mitch, >>Is there a simple way from OFW (or ACPI) to restrict >> the operating frequency of the processor in the XO-1.5 >> to be the lowest possible ? >> >> The relevant comment from a deployment was that they >> can't use full speed XO-1.5 motherboards as replacements >> for XO-1 motherboards. They think kids would break their >> laptop to get it upgraded... >> >> Cheers, >> wad >> > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Slowing down an XO-1.5
ok 406. 199 msr! The period after 406 is mandatory - it forces the number to be 64-bits, suitable as the data operand to msr!. John Watlington wrote: > Mitch, >Is there a simple way from OFW (or ACPI) to restrict > the operating frequency of the processor in the XO-1.5 > to be the lowest possible ? > > The relevant comment from a deployment was that they > can't use full speed XO-1.5 motherboards as replacements > for XO-1 motherboards. They think kids would break their > laptop to get it upgraded... > > Cheers, > wad > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Slowing down an XO-1.5
On Mar 30, 2010, at 2:48 AM, James Cameron wrote: > They'd also notice the graphics performance differences, and that > wouldn't be amenable to a simple fix. Correct, and they would still get twice the memory and roughly 1.5 times the storage (JFFS2 is compressed). What I didn't mention is that in the course of manufacturing the processors, some of them can't run at full speed. These are lasered into a different product ID, clamped at the lowest speed, and sold as separate product with a lower price. I'd like to see/demonstrate what the performance of such a laptop would be. Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
