[Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Kevin Gordon
kgordon420 at gmail.com
Wed May 2 10:27:03 EDT 2012
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <ajaygargnsit at 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 <pgf at laptop.org> wrote:
>
>> martin wrote:
>> > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <ajaygargnsit at 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.langhoff at gmail.com
>> > martin at 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 at lists.laptop.org
>> > http://lists.laptop.org/listinfo/devel
>>
>> =---------------------
>> paul fox, pgf at laptop.org
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120502/9690158f/attachment.html>
More information about the Devel
mailing list