On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <ajaygargn...@gmail.com> wrote:
> Good News. > > I managed to get this working (albeit via changes in sugar). > > The details are at :: > > http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632 > I have a couple of minor observations from the great unwashed - yes me. One is that this solution perhaps wont have any effect when one boots to the Gnome side. Two, this may be build version dependent, as there would appear from some of the discussions in the group that there is an effort for the 12.1.0 builds to more closely link the NM functions on Sugar and Gnome so that settings are identical when restarting the other environment. The echo script in boot startup and the corresponding entry powerd resume , on the other hand, might handle both. Not sure yet, as I'm still playing with WAP variants, and also, I am the newbie :-) > > > Regards, > Ajay > > > On Wed, May 2, 2012 at 6:02 PM, Paul Fox <p...@laptop.org> wrote: > >> martin wrote: >> > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <ajaygargn...@gmail.com> >> wrote: >> > > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work. >> > >> > So we need to understand why it does not work. Is it a race condition? >> > Perhaps it is better fixed as a udev script -- triggering when the >> > device appears. >> >> i think it's almost a guaranteed race. that script essentially >> does this: >> >> while [ ! -f /sys/class/net/eth0/lbs_mesh ] >> do >> sleep 0.5 >> done >> echo 0 > /sys/class/net/eth0/lbs_mesh >> >> in other words -- the disable_mesh script will discover the disable >> node at just about exactly the time that NM discovers the interface. >> >> there's also the "lbs_disablemesh" module parameter, which could be >> supplied at initial module load. does that not work, for some reason? >> (i seem to recall there may be a problem with it.) >> >> paul >> >> > >> > The step that disable_mesh performs is very important. If you don't >> > disable it at that level, you haven't disabled mesh at all and all the >> > problems persist. >> > >> > >> - disable mesh on boot >> > > Done. Added the 'echo 0' script in 'start()' method of >> NetworkManager, so >> > > that the effect takes place before NetworkManager starts up. Works >> like a >> > > charm. >> > >> > Ok. Maybe a udev script is a better place. >> > >> > >> - disable mesh on resume, from a powerd-triggered script >> > > Does not work, as explained above. >> > >> > Right but you MUST find a way to make it work. >> > >> > >> - blacklist the MAC address so NM ignores it >> > >> >> > >> you win. Yes, every XO has a different MAC address, but you can read >> > >> that on first boot of the OS, and write the NM configuration. See >> the >> > >> olpc-configure script for examples. >> > > >> > > >> > > Would be awesome. I believe this is the one and only complete >> solution >> > > possible :) >> > >> > Careful here! This only hides the device from NM so you don't race >> with NM. >> > >> > > Could you point me to the suitable (examples) link? I will be >> heartfully >> > > grateful. >> > >> > look at the latest olpc-configure in git:// >> dev.laptop.org/projects/olpc-utils >> > >> > >> > >> > m >> > -- >> > martin.langh...@gmail.com >> > mar...@laptop.org -- Software Architect - OLPC >> > - ask interesting questions >> > - don't get distracted with shiny stuff - working code first >> > - http://wiki.laptop.org/go/User:Martinlanghoff >> > _______________________________________________ >> > Devel mailing list >> > Devel@lists.laptop.org >> > http://lists.laptop.org/listinfo/devel >> >> =--------------------- >> paul fox, p...@laptop.org >> > > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
