Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Hi all.

Here is the latest update.

We got the following two patches tested by Ceibal ::


a)
0001-TEST-See-if-this-works-for-the-mesh-issue-on-signed-.patch

This patch, adds "/etc/modprobe.d/libertas.conf" to the initramfs image
(unarchiving, adding and archiving during OOB stage).
Unfortunately, this does not seem to work.

We could debug it more, but I fear that that would inevitably mean
modifying the initramfs a fair bit. Since, we are talking at the kernel
level, modifying initramfs even a bit too much, would require exponential
more testing.

Lucking, we have a simple, clean, understood and guaranteed-to-work
solution.




b)
0001-olpc-configure-Reloading-libertas-and-dependent-usb8.patch

(As already stated in earlier mails) This patch reloads the libertas (and
the dependent usb8xxx driver) during intial boot, which mounts the
secondary-storage-based-filesystem. This time, the rules from
/etc/modprobe.d/* are read, and the mesh is appropriately disabled via the
"libertas_disablemesh" KLM parameter.

So, it would be good if this is included upstream.


For brevity, I am re-attaching the two patches.


Thanks and Regards,
Ajay


0001-TEST-See-if-this-works-for-the-mesh-issue-on-signed-.patch
Description: Binary data


0001-olpc-configure-Reloading-libertas-and-dependent-usb8.patch
Description: Binary data
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Sascha Silbe]

Paul Fox  writes:

> yes.  i think we hope there won't actually be any more of those, but
> if there are, that patch will be there.

Great, thanks!

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpeYEFdWOZk1.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Sascha Silbe]

Ajay Garg  writes:

> I tried once again the "Case 2"; and upon resume-from-suspend, the
> icons appeared fine at my end.

OK, that's good and bad. Good in the sense that my patch may not be to
blame; bad in that you encountered a problem that couldn't be
reproduced. It may come back later and bite us twice as hard.


> If I face the unusual result for "Case 2" again, I will post the
> "/var/log/messages", which may be scrutinized.

Please also check for and save core dumps. Not sure they'll be generated
by default for system daemons (I'm thinking NetworkManager in
particular). If they aren't, we should investigate how to enable them
globally in our development builds.

Manuel Kaufmann pointed out (in another thread) that there's
olpc-log. We (= AC) should take a closer look at it [1] and see if we
can extend it to provide a complete snapshot for debugging. Having a
single command that always saves all of the information that may be
needed would reduce the chance of forgetting anything.

Sascha

[1] https://dev.laptop.org/git/projects/olpc-netutils/tree/usr/bin/olpc-log
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpv5Ic3PGm6C.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Sat, May 12, 2012 at 5:40 PM, Jerry Vonau  wrote:
> Don't think OOB is used to generate the initramfs, from the kernel spec
> file:

You are correct as to current state of play. It _used_ to be generated
during the OOB run. Now it is build during the kernel build.

This makes things rather tricky -- currently to get a kernel driver
param such as this one you need to install it _on the machine where
you build your kernel rpm_. This is at best awkward -- the kernel
build environment better be a chroot :-/

So currently Ajay will need to rebuild the kernel rpm in a chroot
where he has installed that libertas.conf he desires. Luckily, we don'
t mess with this too much.

At some point however, I hope that hacking in the initrd gets a bit
more practical.

cheers,



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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Thanks Martin and Jerry.

I followed the following steps ::

a)
Listed "lsinitrd /boot/initrd.img".
It did not show any "/etc/modprobe.d/libertas.conf".


b)
Extracted "/boot/initrd.img" into a temporary folder.
Obviously, no "/etc/modprobe.d/libertas.conf" was seen.


c)
Generated the required "/etc/modprobe.d/libertas.conf" with the content
"options libertas libertas_disablemesh=1" in the tmp folder.


d)
Re-compressed the temp-folder to "/boot/initrd.img".


e)
Listed "lsinitrd /boot/initrd.img".
This time, "/etc/modprobe.d/libertas.conf" was listed.


f)
Rebooted XO-1.


g)
Mesh-icons were still observed :(


h)
Note that I did this, without OOB (i.e. I was just wanting to test that
whether this would work at all).


I guess that there is something else we might be missing.


So, I think that the only solution left now, is to put the "rmmod/modprobe"
hack in olpc-configure.

Would it be an acceptable upstream solution (the change in olpc-utils) ?
Martin (Langhoff) / Daniel (Drake) ?



Looking forward to comments and replies.


Thanks and Regards,
Ajay

On Sun, May 13, 2012 at 3:10 AM, Jerry Vonau  wrote:

> On Sat, 2012-05-12 at 15:20 -0400, Martin Langhoff wrote:
> > On Sat, May 12, 2012 at 4:38 AM, Ajay Garg 
> wrote:
> > > I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> > > (obviously because, this time the "/etc.modprobe.d/libertas.conf"
> could be
> > > fetched/read from persistent storage). Mesh-icons were no more visible
> in
> > > the neighborhood-view (both during reboot, and resume-from-suspend).
> > >
> > > But I too felt that this is more of a hack, and not a clean solution.
> >
> > Well, as you pointed out in later emails, the initramfs generation
> > will pick it up from there. I'd forgotten about that -- sorry.
> >
> > So what you want to do is get libertas.conf into some package
> > (olpc-utils) or install it from an OOB module -- the xo1 module is a
> > good candidate.
> >
> > In fact I'm liking the OOB module option. I think we would accept a
> > patch to OOB's xo1 module, where based on an option it creates this
> > file. Just have to make sure it's created before dracut is used to
> > generate the initramfs.
> >
>
> Hi Martin:
>
> Don't think OOB is used to generate the initramfs, from the kernel spec
> file:
>
> # set to 1 to build the initramfs during kernel-build time
> # set to 0 to build the initramfs during %post on the host
> %define buildinitramfs 1
>
> Doesn't that mean the kernel rpm provides pre-build initrd.img
> and actrd.img? Doesn't OOB just sign what is in the kernel rpm?
>
> Think you would need to re-create initrd.img as needed then place the
> revised initrd.img into the image via OOB, to be signed by OOB.
>
> Jerry
>
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Jerry Vonau]

On Sat, 2012-05-12 at 15:20 -0400, Martin Langhoff wrote:
> On Sat, May 12, 2012 at 4:38 AM, Ajay Garg  wrote:
> > I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> > (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
> > fetched/read from persistent storage). Mesh-icons were no more visible in
> > the neighborhood-view (both during reboot, and resume-from-suspend).
> >
> > But I too felt that this is more of a hack, and not a clean solution.
> 
> Well, as you pointed out in later emails, the initramfs generation
> will pick it up from there. I'd forgotten about that -- sorry.
> 
> So what you want to do is get libertas.conf into some package
> (olpc-utils) or install it from an OOB module -- the xo1 module is a
> good candidate.
> 
> In fact I'm liking the OOB module option. I think we would accept a
> patch to OOB's xo1 module, where based on an option it creates this
> file. Just have to make sure it's created before dracut is used to
> generate the initramfs.
> 

Hi Martin:

Don't think OOB is used to generate the initramfs, from the kernel spec
file:

# set to 1 to build the initramfs during kernel-build time
# set to 0 to build the initramfs during %post on the host
%define buildinitramfs 1

Doesn't that mean the kernel rpm provides pre-build initrd.img
and actrd.img? Doesn't OOB just sign what is in the kernel rpm?

Think you would need to re-create initrd.img as needed then place the
revised initrd.img into the image via OOB, to be signed by OOB.

Jerry


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Sat, May 12, 2012 at 4:38 AM, Ajay Garg  wrote:
> I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
> fetched/read from persistent storage). Mesh-icons were no more visible in
> the neighborhood-view (both during reboot, and resume-from-suspend).
>
> But I too felt that this is more of a hack, and not a clean solution.

Well, as you pointed out in later emails, the initramfs generation
will pick it up from there. I'd forgotten about that -- sorry.

So what you want to do is get libertas.conf into some package
(olpc-utils) or install it from an OOB module -- the xo1 module is a
good candidate.

In fact I'm liking the OOB module option. I think we would accept a
patch to OOB's xo1 module, where based on an option it creates this
file. Just have to make sure it's created before dracut is used to
generate the initramfs.

A bit late, but we may be able to land it for 12.1.0 (or later for 12.2.0).

cheers,



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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Martin,

Some observations ::

a)
All observations (appearance/non-appearance of mesh-icons) is inert to the
presence/absence of the following packages ::

* dracut
* dracut-modules-olpc
* dracut-modules-ceibal


b)
I could only see one initramfs image, on any of the signed/unsigned builds
::

* olpcrd.img (with "initrd.img" being a symbolic link to it)






So, some queries ::


a)
Is the (singular) RAM FS image (olpcrd.img) generated for every kind of
build (but loaded into memory only when ALL of the following are met) ::

* laptop is secured
* image is signed
* there is no developer key, either in pendrive, or on SD
at "/security/develop.sig".


b)
I could not find the place where this (singular) RAM FS image is generated,
in the osbuilder (presumably via dracut).
Doing some greps, gave me the following results ::

##
[ajay@localhost bleeding-edge]$ grep -r -i -s "initrd" .
./modules/xo1_5/kspost.50.xo15-tweaks.inc:   " ${DN}${PN}\initrd.img"
expand$ to ramdisk
./modules/signing/preimage.40.sign-os.sh:if [ -e "$fsmount/boot/initrd.img"
]; then
./modules/signing/preimage.40.sign-os.sh:./sign-os.sh $okey
$fsmount/boot/initrd.img $fsmount/boot/runrd.zip
./modules/signing/preimage.10.extract.sh:if [ -e "$fsmount/boot/initrd.img"
]; then
./modules/signing/preimage.10.extract.sh:cp $fsmount/boot/initrd.img
$tgt/data.img
./modules/signing/README: - if found, the initramfs at /boot/initrd.img (or
/boot/olpcrd.img) will be
./modules/signing/README:found at /boot/initrd.img will be signed into
runos.zip and runrd.zip
./modules/xo1/kspost.50.xo1-tweaks.inc:# FIXME: old olpc.fth looks for
olpcrd.img, but we now use initrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:[ -e "/boot/olpcrd.img" ] || ln -s
initrd.img /boot/olpcrd.img




[ajay@localhost bleeding-edge]$ grep -r -i -s "olpcrd" .
./modules/signing/preimage.10.extract.sh:elif [ -e
"$fsmount/boot/olpcrd.img" ]; then
./modules/signing/preimage.10.extract.sh:cp $fsmount/boot/olpcrd.img
$tgt/data.img
./modules/signing/README: - if found, the initramfs at /boot/initrd.img (or
/boot/olpcrd.img) will be
./modules/xo1/kspost.50.xo1-tweaks.inc:# FIXME: old olpc.fth looks for
olpcrd.img, but we now use initrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:[ -e "/boot/olpcrd.img" ] || ln -s
initrd.img /boot/olpcrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:   " ${DN}${PN}\olpcrd.img" expand$
to ramdisk
##



Looking forward to a reply (especially to the first query).



Thanks and Regards,
Ajay


On Sat, May 12, 2012 at 2:26 PM, Ajay Garg  wrote:

>
>
> On Sat, May 12, 2012 at 2:08 PM, Ajay Garg wrote:
>
>> Thanks Martin.
>> Very neatly explained  :)
>>
>> I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
>> (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
>> fetched/read from persistent storage). Mesh-icons were no more visible in
>> the neighborhood-view (both during reboot, and resume-from-suspend).
>>
>> But I too felt that this is more of a hack, and not a clean solution.
>>
>>
>> So, I ventured out exploring dracut.
>> I created a initramfs image on my home/work laptop, hosting Fedora-14,
>> via the command ::
>>
>>"dracut test.img"
>>
>> and then listed the contents of it
>>
>>"lsinitrd test.img"
>>
>> I saw that "/etc/modprobe.d/*" files were a part of "test.img".
>> So, I think that these files _are_ included as part of the initramfs
>> image, as per say.
>>
>>
>> So,
>>
>> """
>> Is this observation (that /etc/modprobe.d/* files are included, as per
>> say) in line with what is expected?
>> If yes, that is kind of a relief, since that would mean that only
>> "/etc/modprobe.d/libertas.conf" is not being included (in initramfs that
>> is).
>> """
>>
>
> Well, just inspected "lsinitrd olpcrd.img" (assuming "olpcrd.img" _is_ the
> initramfs image in the signed build :D )
> "olpcrd.img", in fact, does not contain any /etc/modprobe/* files.
>
>
> Am looking into exploring customized dracut-modules-olpc..
>
>
> Thanks and Regards,
> Ajay
>
>
>
>>
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>>
>> On Fri, May 11, 2012 at 3:33 AM, Martin Langhoff <
>> martin.langh...@gmail.com> wrote:
>>
>>> On Thu, May 10, 2012 at 1:23 PM, Ajay Garg 
>>> wrote:
>>> > If I boot with "/security/develop.sig" folder in my pendrive,
>>> > a)
>>> > mesh-icons are observed in neighborhood-view, both during reboot and
>>> > resume-from-suspend.
>>>
>>> Welcome to the initramfs stage of your journey! When the laptop needs
>>> activation, it loads a different initramfs that among other things
>>> loads the libertas module.
>>>
>>> You need to get your /etc/modprobe.d/ files into the initramfs. For
>>> 

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

On Sat, May 12, 2012 at 2:08 PM, Ajay Garg  wrote:

> Thanks Martin.
> Very neatly explained  :)
>
> I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
> fetched/read from persistent storage). Mesh-icons were no more visible in
> the neighborhood-view (both during reboot, and resume-from-suspend).
>
> But I too felt that this is more of a hack, and not a clean solution.
>
>
> So, I ventured out exploring dracut.
> I created a initramfs image on my home/work laptop, hosting Fedora-14, via
> the command ::
>
>"dracut test.img"
>
> and then listed the contents of it
>
>"lsinitrd test.img"
>
> I saw that "/etc/modprobe.d/*" files were a part of "test.img".
> So, I think that these files _are_ included as part of the initramfs
> image, as per say.
>
>
> So,
>
> """
> Is this observation (that /etc/modprobe.d/* files are included, as per
> say) in line with what is expected?
> If yes, that is kind of a relief, since that would mean that only
> "/etc/modprobe.d/libertas.conf" is not being included (in initramfs that
> is).
> """
>

Well, just inspected "lsinitrd olpcrd.img" (assuming "olpcrd.img" _is_ the
initramfs image in the signed build :D )
"olpcrd.img", in fact, does not contain any /etc/modprobe/* files.


Am looking into exploring customized dracut-modules-olpc..


Thanks and Regards,
Ajay



>
>
>
> Thanks and Regards,
> Ajay
>
>
>
> On Fri, May 11, 2012 at 3:33 AM, Martin Langhoff <
> martin.langh...@gmail.com> wrote:
>
>> On Thu, May 10, 2012 at 1:23 PM, Ajay Garg 
>> wrote:
>> > If I boot with "/security/develop.sig" folder in my pendrive,
>> > a)
>> > mesh-icons are observed in neighborhood-view, both during reboot and
>> > resume-from-suspend.
>>
>> Welcome to the initramfs stage of your journey! When the laptop needs
>> activation, it loads a different initramfs that among other things
>> loads the libertas module.
>>
>> You need to get your /etc/modprobe.d/ files into the initramfs. For
>> your vanilla build, look into dracut-modules-olpc. If you're hoping to
>> get this integrated into a build with an alternative initramfs (hint:
>> Ceibal) that build will have a custom version of dracut-modules-olpc.
>>
>> That is the right way. When the laptop is in secure mode, olpc.fth is
>> _ignored_, so no chance to set a kernel cmdline there.
>>
>> An easier alternative might be to check for those flags under /sys,
>> and if they are there, rmmod/modprobe libertas  for example in
>> olpc-configure (so during early boot).
>>
>>
>>
>>
>> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Thanks Martin.
Very neatly explained  :)

I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
(obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
fetched/read from persistent storage). Mesh-icons were no more visible in
the neighborhood-view (both during reboot, and resume-from-suspend).

But I too felt that this is more of a hack, and not a clean solution.


So, I ventured out exploring dracut.
I created a initramfs image on my home/work laptop, hosting Fedora-14, via
the command ::

   "dracut test.img"

and then listed the contents of it

   "lsinitrd test.img"

I saw that "/etc/modprobe.d/*" files were a part of "test.img".
So, I think that these files _are_ included as part of the initramfs image,
as per say.


So,

"""
Is this observation (that /etc/modprobe.d/* files are included, as per say)
in line with what is expected?
If yes, that is kind of a relief, since that would mean that only
"/etc/modprobe.d/libertas.conf" is not being included (in initramfs that
is).
"""



Thanks and Regards,
Ajay


On Fri, May 11, 2012 at 3:33 AM, Martin Langhoff
wrote:

> On Thu, May 10, 2012 at 1:23 PM, Ajay Garg 
> wrote:
> > If I boot with "/security/develop.sig" folder in my pendrive,
> > a)
> > mesh-icons are observed in neighborhood-view, both during reboot and
> > resume-from-suspend.
>
> Welcome to the initramfs stage of your journey! When the laptop needs
> activation, it loads a different initramfs that among other things
> loads the libertas module.
>
> You need to get your /etc/modprobe.d/ files into the initramfs. For
> your vanilla build, look into dracut-modules-olpc. If you're hoping to
> get this integrated into a build with an alternative initramfs (hint:
> Ceibal) that build will have a custom version of dracut-modules-olpc.
>
> That is the right way. When the laptop is in secure mode, olpc.fth is
> _ignored_, so no chance to set a kernel cmdline there.
>
> An easier alternative might be to check for those flags under /sys,
> and if they are there, rmmod/modprobe libertas  for example in
> olpc-configure (so during early boot).
>
>
>
>
> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Jerry Vonau]

On Thu, 2012-05-10 at 23:11 +0530, Ajay Garg wrote:
> Oops.. 
> please ignore my previous mail.
> Instead, this is what the issue is (seems this issue has put me in
> mental sleep; I am making stupid, idiotic mistakes) :|
> 
> Anyways, here it is .. (again, please ignore my previous mail
> completely) 
> 

OK, no problem.

> 
> 
> 
> 
> If we do the following ::
> 
> a)
> In OpenFirmware CLI, do 
>  
>   enable-security 
> 
> 

Now you booing the signed zip files.

> b)
> And there is NOT any "/security/develop.sig" file in my pendrive while
> booting.
> 
> 
> 
> c)
> There is NOT any "/security/develop.sig" file on the XO-1,
> 
> 

Your still booting signed zip files. If you were to boot with your
develop.sig present does the disabling of the mesh work?

> 
> 
> it is observed that ::
> 
> i)
> mesh-icons are observed in neighborhood-view, both during reboot and
> resume-from-suspend.
> 
> ii)
> "/var/log/messages" show the loading of "msh0". However, there are no
> exceptions/crash-traces therein.
> 
> iii)
> Also, I see the presence of a folder "/sys/class/net/msh0".
> 
> 
> 
> PLEASE NOTE THAT IF ANY OF a), b) OR c) CONDITIONS ARE NOT MET, THE
> MESH - ICONS ARE NOT OBSERVED (AS IS VERY MUCH EXPECTED).
> 
> 
> 
> Is my observation in line with anyone's observation on olpc/sugar?
> (Note that the issue was reported by UY deployment; and it could be
> reproduced at our end as well).
> 
> 

How are you introducing the libertas_disablemesh=1 option in the
unlocked boot? Are you using modprobe.d or passing a boot arguement
in /boot/olpc.fth?

Jerry


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Thu, May 10, 2012 at 1:23 PM, Ajay Garg  wrote:
> If I boot with "/security/develop.sig" folder in my pendrive,
> a)
> mesh-icons are observed in neighborhood-view, both during reboot and
> resume-from-suspend.

Welcome to the initramfs stage of your journey! When the laptop needs
activation, it loads a different initramfs that among other things
loads the libertas module.

You need to get your /etc/modprobe.d/ files into the initramfs. For
your vanilla build, look into dracut-modules-olpc. If you're hoping to
get this integrated into a build with an alternative initramfs (hint:
Ceibal) that build will have a custom version of dracut-modules-olpc.

That is the right way. When the laptop is in secure mode, olpc.fth is
_ignored_, so no chance to set a kernel cmdline there.

An easier alternative might be to check for those flags under /sys,
and if they are there, rmmod/modprobe libertas  for example in
olpc-configure (so during early boot).




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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Oops..
please ignore my previous mail.
Instead, this is what the issue is (seems this issue has put me in mental
sleep; I am making stupid, idiotic mistakes) :|

Anyways, here it is .. (again, please ignore my previous mail completely)






If we do the following ::

a)
In OpenFirmware CLI, do

  enable-security 


b)
And there is NOT any "/security/develop.sig" file in my pendrive while
booting.



c)
There is NOT any "/security/develop.sig" file on the XO-1,




it is observed that ::

i)
mesh-icons are observed in neighborhood-view, both during reboot and
resume-from-suspend.

ii)
"/var/log/messages" show the loading of "msh0". However, there are no
exceptions/crash-traces therein.

iii)
Also, I see the presence of a folder "/sys/class/net/msh0".



PLEASE NOTE THAT IF ANY OF a), b) OR c) CONDITIONS ARE NOT MET, THE  MESH -
ICONS ARE NOT OBSERVED (AS IS VERY MUCH EXPECTED).



Is my observation in line with anyone's observation on olpc/sugar?
(Note that the issue was reported by UY deployment; and it could be
reproduced at our end as well).



Kindly reply with comments.



Thanks and Regards,
Ajay


On Thu, May 10, 2012 at 10:53 PM, Ajay Garg wrote:

> Hi all.
>
> (Unfortunately) A new use-case has come into effect ::
>
>
> If I boot with "/security/develop.sig" folder in my pendrive,
>
> a)
> mesh-icons are observed in neighborhood-view, both during reboot and
> resume-from-suspend.
>
> b)
> "/var/log/messages" show the loading of "msh0". However, there are no
> exceptions/crash-traces therein.
>
> c)
> Also, I see the presence of a folder "/sys/class/net/msh0".
>
>
>
>
> However, if there is no "security/develop.sig" file in my pendrive,
>
> a)
> No mesh-icons are seen in neighborhood-view, during reboot or
> resume-from-suspend (as expected).
>
> b)
> "/var/log/messages" has no mention of "msh0" (as expected).
>
> c)
> There is no folder "/sys/class/net/msh0" (i guess that is what is
> expected).
>
>
>
>
> Is my observation in line with anyone's observation on olpc/sugar?
> (Note that the issue was reported by UY deployment; and it could be
> reproduced at our end as well).
>
>
>
> Kindly reply with comments.
>
>
>
> Thanks and Regards,
> Ajay
>
>
>
>
>
>
> On Sat, May 5, 2012 at 11:27 PM, Ajay Garg  wrote:
>
>> Hi Kevin.
>>
>> Following are the steps and observations ::
>>
>> a)
>> Booted with mesh-disabled (via "options libertas libertas_disablemesh=1").
>>
>> b)
>> In Neighborhood-View, "wifi" and three "adhoc" network icons were present.
>>
>> c)
>> Then, I turned wifi-radio off, discarded network history. Now, only
>> three "adhoc" network icons were present in Neighborhood-View.
>>
>> d)
>> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
>> network icons could be seen.
>>
>> e)
>> Again, I turned wifi-radio off, discarded network history. Again, only
>> three "adhoc" network icons could be seen in Neighborhood-View.
>>
>> f)
>> Rebooted.
>>
>> g)
>> Only three "adhoc" network icons were seen in Neighborhood-View.
>>
>> h)
>> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
>> network icons could be seen in Neighborhood-View.
>>
>>
>> So, it works fine I guess (note that, mesh-icons were NOT seen anytime
>> in the above steps) :)
>>
>>
>> Regards,
>> Ajay
>>
>> On Sat, May 5, 2012 at 6:43 PM, Kevin Gordon 
>> wrote:
>> >
>> >
>> > On Sat, May 5, 2012 at 6:26 AM, Ajay Garg 
>> wrote:
>> >>
>> >> Well,
>> >>
>> >> I tried once again the "Case 2"; and upon resume-from-suspend, the
>> >> icons appeared fine at my end.
>> >>
>> >> So, the problem was at my end.
>> >> So, it seems that nothing needs to be done right now.
>> >>
>> >> If I face the unusual result for "Case 2" again, I will post the
>> >> "/var/log/messages", which may be scrutinized.
>> >> If someone else faces the same, she/he may do the same.
>> >>
>> >> Till that time, I guess nothing needs to be done.
>> >
>> >
>> > Ajay:
>> >
>> > Since you've already installed the patch, could I be lazy and ask you a
>> > favour?   In the scenario where you have booted with mesh disabled,
>> could
>> > you go over to the Sugar control/panel settings Network applet, turn the
>> > radio off,  discard network history, turn the radio back on, wait a
>> bit, and
>> > see what icons appear in the neighbourhood view?
>> >
>> > Curious to see what happens here.  I'll do some more testing using this
>> > kernel/patch on both gnome and sugar next week, but thought if you had
>> a few
>> > seconds I could get a 'head start' at looking at this situation.  If
>> not, no
>> > big deal - what's done is already really neat!  Thanks.
>> >
>> > Cheers,
>> >
>> > KG
>> >
>> >>
>> >> Sorry Sascha, and everyone.
>> >>
>> >> Regards,
>> >> Ajay
>> >>
>> >> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
>> >>  wrote:
>> >> > just in case, did you try this combination:
>> >> >
>> >> > libertas(without the patch) + disable_mesh.sh(removed) +
>> >> > resume-from-suspend
>> >> > (?)
>> >> >
>> >> > IF NM stil

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Hi all.

(Unfortunately) A new use-case has come into effect ::


If I boot with "/security/develop.sig" folder in my pendrive,

a)
mesh-icons are observed in neighborhood-view, both during reboot and
resume-from-suspend.

b)
"/var/log/messages" show the loading of "msh0". However, there are no
exceptions/crash-traces therein.

c)
Also, I see the presence of a folder "/sys/class/net/msh0".




However, if there is no "security/develop.sig" file in my pendrive,

a)
No mesh-icons are seen in neighborhood-view, during reboot or
resume-from-suspend (as expected).

b)
"/var/log/messages" has no mention of "msh0" (as expected).

c)
There is no folder "/sys/class/net/msh0" (i guess that is what is expected).




Is my observation in line with anyone's observation on olpc/sugar?
(Note that the issue was reported by UY deployment; and it could be
reproduced at our end as well).



Kindly reply with comments.



Thanks and Regards,
Ajay





On Sat, May 5, 2012 at 11:27 PM, Ajay Garg  wrote:

> Hi Kevin.
>
> Following are the steps and observations ::
>
> a)
> Booted with mesh-disabled (via "options libertas libertas_disablemesh=1").
>
> b)
> In Neighborhood-View, "wifi" and three "adhoc" network icons were present.
>
> c)
> Then, I turned wifi-radio off, discarded network history. Now, only
> three "adhoc" network icons were present in Neighborhood-View.
>
> d)
> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
> network icons could be seen.
>
> e)
> Again, I turned wifi-radio off, discarded network history. Again, only
> three "adhoc" network icons could be seen in Neighborhood-View.
>
> f)
> Rebooted.
>
> g)
> Only three "adhoc" network icons were seen in Neighborhood-View.
>
> h)
> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
> network icons could be seen in Neighborhood-View.
>
>
> So, it works fine I guess (note that, mesh-icons were NOT seen anytime
> in the above steps) :)
>
>
> Regards,
> Ajay
>
> On Sat, May 5, 2012 at 6:43 PM, Kevin Gordon  wrote:
> >
> >
> > On Sat, May 5, 2012 at 6:26 AM, Ajay Garg 
> wrote:
> >>
> >> Well,
> >>
> >> I tried once again the "Case 2"; and upon resume-from-suspend, the
> >> icons appeared fine at my end.
> >>
> >> So, the problem was at my end.
> >> So, it seems that nothing needs to be done right now.
> >>
> >> If I face the unusual result for "Case 2" again, I will post the
> >> "/var/log/messages", which may be scrutinized.
> >> If someone else faces the same, she/he may do the same.
> >>
> >> Till that time, I guess nothing needs to be done.
> >
> >
> > Ajay:
> >
> > Since you've already installed the patch, could I be lazy and ask you a
> > favour?   In the scenario where you have booted with mesh disabled, could
> > you go over to the Sugar control/panel settings Network applet, turn the
> > radio off,  discard network history, turn the radio back on, wait a bit,
> and
> > see what icons appear in the neighbourhood view?
> >
> > Curious to see what happens here.  I'll do some more testing using this
> > kernel/patch on both gnome and sugar next week, but thought if you had a
> few
> > seconds I could get a 'head start' at looking at this situation.  If
> not, no
> > big deal - what's done is already really neat!  Thanks.
> >
> > Cheers,
> >
> > KG
> >
> >>
> >> Sorry Sascha, and everyone.
> >>
> >> Regards,
> >> Ajay
> >>
> >> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
> >>  wrote:
> >> > just in case, did you try this combination:
> >> >
> >> > libertas(without the patch) + disable_mesh.sh(removed) +
> >> > resume-from-suspend
> >> > (?)
> >> >
> >> > IF NM still crashes then we have been looking in the wrong direction,
> if
> >> > not
> >> > then we need to look deeper into the patch probably (@silbe ;)).
> >> >
> >> >
> >> > On Fri, May 4, 2012 at 10:20 PM, Ajay Garg 
> >> > wrote:
> >> >>
> >> >> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
> >> >>  wrote:
> >> >> > Did you remove the disable mesh.script for the testing?
> >> >>
> >> >> Yes.
> >> >>
> >> >> Both from ::
> >> >>
> >> >> a)
> >> >> my custom added in '/etc/init.d/NetworkManager'.
> >> >>
> >> >> b)
> >> >> '/etc/powed/postresume.d/disable_mesh.sh'
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ajay
> >> >> >
> >> >> > El may 4, 2012 10:39 p.m., "Ajay Garg" 
> >> >> > escribió:
> >> >> >>
> >> >> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
> >> >> >> 
> >> >> >> wrote:
> >> >> >> > Ajay Garg  writes:
> >> >> >> >
> >> >> >> > [...]
> >> >> >> >> b)
> >> >> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> >> >> >> following line ::
> >> >> >> >>
> >> >> >> >>   options libertas libertas_disablemesh=0
> >> >> >> > [...]
> >> >> >> >> f)
> >> >> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN
> NEIGHBORHOOD
> >> >> >> >> VIEW.
> >> >> >> >
> >> >> >> > Interesting.
> >> >> >> >
> >> >> >> >> g)
> >> >> >> >> Observations e) and f) were observed, _every single time_.
> >> >> >> >
> >> >> >> > OK, I suppose you 

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Hi Kevin.

Following are the steps and observations ::

a)
Booted with mesh-disabled (via "options libertas libertas_disablemesh=1").

b)
In Neighborhood-View, "wifi" and three "adhoc" network icons were present.

c)
Then, I turned wifi-radio off, discarded network history. Now, only
three "adhoc" network icons were present in Neighborhood-View.

d)
After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
network icons could be seen.

e)
Again, I turned wifi-radio off, discarded network history. Again, only
three "adhoc" network icons could be seen in Neighborhood-View.

f)
Rebooted.

g)
Only three "adhoc" network icons were seen in Neighborhood-View.

h)
After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
network icons could be seen in Neighborhood-View.


So, it works fine I guess (note that, mesh-icons were NOT seen anytime
in the above steps) :)


Regards,
Ajay

On Sat, May 5, 2012 at 6:43 PM, Kevin Gordon  wrote:
>
>
> On Sat, May 5, 2012 at 6:26 AM, Ajay Garg  wrote:
>>
>> Well,
>>
>> I tried once again the "Case 2"; and upon resume-from-suspend, the
>> icons appeared fine at my end.
>>
>> So, the problem was at my end.
>> So, it seems that nothing needs to be done right now.
>>
>> If I face the unusual result for "Case 2" again, I will post the
>> "/var/log/messages", which may be scrutinized.
>> If someone else faces the same, she/he may do the same.
>>
>> Till that time, I guess nothing needs to be done.
>
>
> Ajay:
>
> Since you've already installed the patch, could I be lazy and ask you a
> favour?   In the scenario where you have booted with mesh disabled, could
> you go over to the Sugar control/panel settings Network applet, turn the
> radio off,  discard network history, turn the radio back on, wait a bit, and
> see what icons appear in the neighbourhood view?
>
> Curious to see what happens here.  I'll do some more testing using this
> kernel/patch on both gnome and sugar next week, but thought if you had a few
> seconds I could get a 'head start' at looking at this situation.  If not, no
> big deal - what's done is already really neat!  Thanks.
>
> Cheers,
>
> KG
>
>>
>> Sorry Sascha, and everyone.
>>
>> Regards,
>> Ajay
>>
>> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
>>  wrote:
>> > just in case, did you try this combination:
>> >
>> > libertas(without the patch) + disable_mesh.sh(removed) +
>> > resume-from-suspend
>> > (?)
>> >
>> > IF NM still crashes then we have been looking in the wrong direction, if
>> > not
>> > then we need to look deeper into the patch probably (@silbe ;)).
>> >
>> >
>> > On Fri, May 4, 2012 at 10:20 PM, Ajay Garg 
>> > wrote:
>> >>
>> >> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
>> >>  wrote:
>> >> > Did you remove the disable mesh.script for the testing?
>> >>
>> >> Yes.
>> >>
>> >> Both from ::
>> >>
>> >> a)
>> >> my custom added in '/etc/init.d/NetworkManager'.
>> >>
>> >> b)
>> >> '/etc/powed/postresume.d/disable_mesh.sh'
>> >>
>> >>
>> >> Regards,
>> >> Ajay
>> >> >
>> >> > El may 4, 2012 10:39 p.m., "Ajay Garg" 
>> >> > escribió:
>> >> >>
>> >> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
>> >> >> 
>> >> >> wrote:
>> >> >> > Ajay Garg  writes:
>> >> >> >
>> >> >> > [...]
>> >> >> >> b)
>> >> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> >> >> >> following line ::
>> >> >> >>
>> >> >> >>               options libertas libertas_disablemesh=0
>> >> >> > [...]
>> >> >> >> f)
>> >> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
>> >> >> >> VIEW.
>> >> >> >
>> >> >> > Interesting.
>> >> >> >
>> >> >> >> g)
>> >> >> >> Observations e) and f) were observed, _every single time_.
>> >> >> >
>> >> >> > OK, I suppose you repeated this often enough and using exactly the
>> >> >> > same
>> >> >> > environment and procedures as the other test cases? I.e. you are
>> >> >> > sure
>> >> >> > that it's really specific to libertas_disablemesh=0 rather than
>> >> >> > just
>> >> >> > occurring at random even without the libertas_disablemesh setting
>> >> >> > or
>> >> >> > based on how the suspend / resume was triggered (e.g. idle suspend
>> >> >> > vs. lid or power switch)?
>> >> >>
>> >> >> I tried 3 times, and it happened every time. (I tried with the "lid"
>> >> >> approach every time, under identical conditions and set of
>> >> >> procedures.).
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > I don't see anything in the patch or the module params code that
>> >> >> > would
>> >> >> > explain this behaviour. If it's reproducible, I'll have to dive
>> >> >> > into
>> >> >> > it
>> >> >> > and debug a bit...
>> >> >>
>> >> >> It is reproducible every time (at least at my end). :)
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Thanks for testing, BTW!
>> >> >>
>> >> >> My pleasure :)
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Sascha
>> >> >> >
>> >> >> > --
>> >> >> > http://sascha.silbe.org/
>> >> >> > http://www.infra-silbe.de/
>> >> >>
>>

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Paul Fox]

kevin wrote:
 > On Fri, May 4, 2012 at 4:41 PM, Paul Fox  wrote:
 > 
 > > sascha wrote:
 > >  >
 > >  > > i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
 > >  > > did the rest.  this implements a new "libertas_disablemesh" module
 > >  > > parameter which should keep mesh from being enabled.  please test:
 > >  > >
 > >  > >
 > > 
 > http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde
 > 819f.i586.rpm
 > >  >
 > >  > Thanks! Just to be sure: as it's been merged into olpc-2.6.35, all
 > >  > future official 2.6.35 based OLPC kernel builds will include this patch?
 > >
 > > hi sascha --
 > >
 > > yes.  i think we hope there won't actually be any more of those, but
 > > if there are, that patch will be there.  current and future releases
 > > get the patch for free, since it's upstream.  (thank you)
 > 
 > Just because I like to inquire on what to many is the obvious :-)  ... this
 > change is *not* upstream for the 12.1.0 XO1.0 current and future kernels
 > though, correct?

yes, it is.  the change is already upstream -- it just never made
it into the olpc-2.6.35 branch, so it wasn't getting into dextrose.

paul

 > 
 > KG
 > 
 > 
 > 
 > > paul
 > >
 > > p.s.  somehow the git hash i pasted above is incorrect.  the correct
 > > cherry-pick was this one:
 > > -
 > >  commit 6bdbdbf4a151a3a1333818cd17a7d7795e936041
 > >  Author: Sascha Silbe 
 > >  Date:   Wed May 11 14:52:34 2011 +0200
 > >
 > >libertas: Add libertas_disablemesh module parameter to disable mesh
 > > interface
 > >
 > > This allows individual users and deployments to disable mesh support at
 > >runtime, i.e. without having to build and maintain a custom kernel.
 > >
 > > Based on a patch by Paul Fox .
 > >Signed-off-by: Sascha Silbe 
 > >Signed-off-by: John W. Linville 
 > > -
 > >
 > >
 > >  >
 > >  > The reason we've not gone the module parameter route so far (in
 > >  > Dextrose 3) is that we didn't want to divert from upstream (OLPC in
 > > this
 > >  > case) on the kernel level. If it's included now, that concern is
 > >  > addressed and we can go this route, which IMO is technically the best
 > >  > option. It avoids all possible race conditions and only needs a single
 > >  > configuration file to be set up.
 > >  >
 > >  > Sascha
 > >  >
 > >  > --
 > >  > http://sascha.silbe.org/
 > >  > http://www.infra-silbe.de/
 > >
 > > =-
 > >  paul fox, p...@laptop.org
 > >
 > > ___
 > > 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Kevin Gordon]

On Fri, May 4, 2012 at 4:41 PM, Paul Fox  wrote:

> sascha wrote:
>  >
>  > > i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
>  > > did the rest.  this implements a new "libertas_disablemesh" module
>  > > parameter which should keep mesh from being enabled.  please test:
>  > >
>  > >
> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>  >
>  > Thanks! Just to be sure: as it's been merged into olpc-2.6.35, all
>  > future official 2.6.35 based OLPC kernel builds will include this patch?
>
> hi sascha --
>
> yes.  i think we hope there won't actually be any more of those, but
> if there are, that patch will be there.  current and future releases
> get the patch for free, since it's upstream.  (thank you)
>

Just because I like to inquire on what to many is the obvious :-)  ... this
change is *not* upstream for the 12.1.0 XO1.0 current and future kernels
though, correct?

KG



> paul
>
> p.s.  somehow the git hash i pasted above is incorrect.  the correct
> cherry-pick was this one:
> -
>  commit 6bdbdbf4a151a3a1333818cd17a7d7795e936041
>  Author: Sascha Silbe 
>  Date:   Wed May 11 14:52:34 2011 +0200
>
>libertas: Add libertas_disablemesh module parameter to disable mesh
> interface
>
> This allows individual users and deployments to disable mesh support at
>runtime, i.e. without having to build and maintain a custom kernel.
>
> Based on a patch by Paul Fox .
>Signed-off-by: Sascha Silbe 
>Signed-off-by: John W. Linville 
> -
>
>
>  >
>  > The reason we've not gone the module parameter route so far (in
>  > Dextrose 3) is that we didn't want to divert from upstream (OLPC in
> this
>  > case) on the kernel level. If it's included now, that concern is
>  > addressed and we can go this route, which IMO is technically the best
>  > option. It avoids all possible race conditions and only needs a single
>  > configuration file to be set up.
>  >
>  > Sascha
>  >
>  > --
>  > http://sascha.silbe.org/
>  > http://www.infra-silbe.de/
>
> =-
>  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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Kevin Gordon]

On Sat, May 5, 2012 at 6:26 AM, Ajay Garg  wrote:

> Well,
>
> I tried once again the "Case 2"; and upon resume-from-suspend, the
> icons appeared fine at my end.
>
> So, the problem was at my end.
> So, it seems that nothing needs to be done right now.
>
> If I face the unusual result for "Case 2" again, I will post the
> "/var/log/messages", which may be scrutinized.
> If someone else faces the same, she/he may do the same.
>
> Till that time, I guess nothing needs to be done.
>

Ajay:

Since you've already installed the patch, could I be lazy and ask you a
favour?   In the scenario where you have booted with mesh disabled, could
you go over to the Sugar control/panel settings Network applet, turn the
radio off,  discard network history, turn the radio back on, wait a bit,
and see what icons appear in the neighbourhood view?

Curious to see what happens here.  I'll do some more testing using this
kernel/patch on both gnome and sugar next week, but thought if you had a
few seconds I could get a 'head start' at looking at this situation.  If
not, no big deal - what's done is already really neat!  Thanks.

Cheers,

KG


> Sorry Sascha, and everyone.
>
> Regards,
> Ajay
>
> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
>  wrote:
> > just in case, did you try this combination:
> >
> > libertas(without the patch) + disable_mesh.sh(removed) +
> resume-from-suspend
> > (?)
> >
> > IF NM still crashes then we have been looking in the wrong direction, if
> not
> > then we need to look deeper into the patch probably (@silbe ;)).
> >
> >
> > On Fri, May 4, 2012 at 10:20 PM, Ajay Garg 
> wrote:
> >>
> >> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
> >>  wrote:
> >> > Did you remove the disable mesh.script for the testing?
> >>
> >> Yes.
> >>
> >> Both from ::
> >>
> >> a)
> >> my custom added in '/etc/init.d/NetworkManager'.
> >>
> >> b)
> >> '/etc/powed/postresume.d/disable_mesh.sh'
> >>
> >>
> >> Regards,
> >> Ajay
> >> >
> >> > El may 4, 2012 10:39 p.m., "Ajay Garg" 
> >> > escribió:
> >> >>
> >> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
> >> >> 
> >> >> wrote:
> >> >> > Ajay Garg  writes:
> >> >> >
> >> >> > [...]
> >> >> >> b)
> >> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> >> >> following line ::
> >> >> >>
> >> >> >>   options libertas libertas_disablemesh=0
> >> >> > [...]
> >> >> >> f)
> >> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
> >> >> >> VIEW.
> >> >> >
> >> >> > Interesting.
> >> >> >
> >> >> >> g)
> >> >> >> Observations e) and f) were observed, _every single time_.
> >> >> >
> >> >> > OK, I suppose you repeated this often enough and using exactly the
> >> >> > same
> >> >> > environment and procedures as the other test cases? I.e. you are
> sure
> >> >> > that it's really specific to libertas_disablemesh=0 rather than
> just
> >> >> > occurring at random even without the libertas_disablemesh setting
> or
> >> >> > based on how the suspend / resume was triggered (e.g. idle suspend
> >> >> > vs. lid or power switch)?
> >> >>
> >> >> I tried 3 times, and it happened every time. (I tried with the "lid"
> >> >> approach every time, under identical conditions and set of
> >> >> procedures.).
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > I don't see anything in the patch or the module params code that
> >> >> > would
> >> >> > explain this behaviour. If it's reproducible, I'll have to dive
> into
> >> >> > it
> >> >> > and debug a bit...
> >> >>
> >> >> It is reproducible every time (at least at my end). :)
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > Thanks for testing, BTW!
> >> >>
> >> >> My pleasure :)
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > Sascha
> >> >> >
> >> >> > --
> >> >> > http://sascha.silbe.org/
> >> >> > http://www.infra-silbe.de/
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ajay
> >> >> ___
> >> >> Sugar-devel mailing list
> >> >> sugar-de...@lists.sugarlabs.org
> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> ___
> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Well,

I tried once again the "Case 2"; and upon resume-from-suspend, the
icons appeared fine at my end.

So, the problem was at my end.
So, it seems that nothing needs to be done right now.

If I face the unusual result for "Case 2" again, I will post the
"/var/log/messages", which may be scrutinized.
If someone else faces the same, she/he may do the same.

Till that time, I guess nothing needs to be done.

Sorry Sascha, and everyone.

Regards,
Ajay

On Sat, May 5, 2012 at 2:15 PM, Martin Abente
 wrote:
> just in case, did you try this combination:
>
> libertas(without the patch) + disable_mesh.sh(removed) + resume-from-suspend
> (?)
>
> IF NM still crashes then we have been looking in the wrong direction, if not
> then we need to look deeper into the patch probably (@silbe ;)).
>
>
> On Fri, May 4, 2012 at 10:20 PM, Ajay Garg  wrote:
>>
>> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
>>  wrote:
>> > Did you remove the disable mesh.script for the testing?
>>
>> Yes.
>>
>> Both from ::
>>
>> a)
>> my custom added in '/etc/init.d/NetworkManager'.
>>
>> b)
>> '/etc/powed/postresume.d/disable_mesh.sh'
>>
>>
>> Regards,
>> Ajay
>> >
>> > El may 4, 2012 10:39 p.m., "Ajay Garg" 
>> > escribió:
>> >>
>> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
>> >> 
>> >> wrote:
>> >> > Ajay Garg  writes:
>> >> >
>> >> > [...]
>> >> >> b)
>> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> >> >> following line ::
>> >> >>
>> >> >>               options libertas libertas_disablemesh=0
>> >> > [...]
>> >> >> f)
>> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
>> >> >> VIEW.
>> >> >
>> >> > Interesting.
>> >> >
>> >> >> g)
>> >> >> Observations e) and f) were observed, _every single time_.
>> >> >
>> >> > OK, I suppose you repeated this often enough and using exactly the
>> >> > same
>> >> > environment and procedures as the other test cases? I.e. you are sure
>> >> > that it's really specific to libertas_disablemesh=0 rather than just
>> >> > occurring at random even without the libertas_disablemesh setting or
>> >> > based on how the suspend / resume was triggered (e.g. idle suspend
>> >> > vs. lid or power switch)?
>> >>
>> >> I tried 3 times, and it happened every time. (I tried with the "lid"
>> >> approach every time, under identical conditions and set of
>> >> procedures.).
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > I don't see anything in the patch or the module params code that
>> >> > would
>> >> > explain this behaviour. If it's reproducible, I'll have to dive into
>> >> > it
>> >> > and debug a bit...
>> >>
>> >> It is reproducible every time (at least at my end). :)
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > Thanks for testing, BTW!
>> >>
>> >> My pleasure :)
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > Sascha
>> >> >
>> >> > --
>> >> > http://sascha.silbe.org/
>> >> > http://www.infra-silbe.de/
>> >>
>> >>
>> >> Regards,
>> >> Ajay
>> >> ___
>> >> Sugar-devel mailing list
>> >> sugar-de...@lists.sugarlabs.org
>> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Abente]

just in case, did you try this combination:

libertas(without the patch) + disable_mesh.sh(removed) +
resume-from-suspend (?)

IF NM still crashes then we have been looking in the wrong direction, if
not then we need to look deeper into the patch probably (@silbe ;)).

On Fri, May 4, 2012 at 10:20 PM, Ajay Garg  wrote:

> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
>  wrote:
> > Did you remove the disable mesh.script for the testing?
>
> Yes.
>
> Both from ::
>
> a)
> my custom added in '/etc/init.d/NetworkManager'.
>
> b)
> '/etc/powed/postresume.d/disable_mesh.sh'
>
>
> Regards,
> Ajay
> >
> > El may 4, 2012 10:39 p.m., "Ajay Garg" 
> escribió:
> >>
> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe  >
> >> wrote:
> >> > Ajay Garg  writes:
> >> >
> >> > [...]
> >> >> b)
> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> >> following line ::
> >> >>
> >> >>   options libertas libertas_disablemesh=0
> >> > [...]
> >> >> f)
> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
> VIEW.
> >> >
> >> > Interesting.
> >> >
> >> >> g)
> >> >> Observations e) and f) were observed, _every single time_.
> >> >
> >> > OK, I suppose you repeated this often enough and using exactly the
> same
> >> > environment and procedures as the other test cases? I.e. you are sure
> >> > that it's really specific to libertas_disablemesh=0 rather than just
> >> > occurring at random even without the libertas_disablemesh setting or
> >> > based on how the suspend / resume was triggered (e.g. idle suspend
> >> > vs. lid or power switch)?
> >>
> >> I tried 3 times, and it happened every time. (I tried with the "lid"
> >> approach every time, under identical conditions and set of
> >> procedures.).
> >>
> >>
> >>
> >>
> >>
> >> >
> >> > I don't see anything in the patch or the module params code that would
> >> > explain this behaviour. If it's reproducible, I'll have to dive into
> it
> >> > and debug a bit...
> >>
> >> It is reproducible every time (at least at my end). :)
> >>
> >>
> >>
> >>
> >> >
> >> > Thanks for testing, BTW!
> >>
> >> My pleasure :)
> >>
> >>
> >>
> >>
> >> >
> >> > Sascha
> >> >
> >> > --
> >> > http://sascha.silbe.org/
> >> > http://www.infra-silbe.de/
> >>
> >>
> >> Regards,
> >> Ajay
> >> ___
> >> Sugar-devel mailing list
> >> sugar-de...@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

On Sat, May 5, 2012 at 3:42 AM, Martin Abente
 wrote:
> Did you remove the disable mesh.script for the testing?

Yes.

Both from ::

a)
my custom added in '/etc/init.d/NetworkManager'.

b)
'/etc/powed/postresume.d/disable_mesh.sh'


Regards,
Ajay
>
> El may 4, 2012 10:39 p.m., "Ajay Garg"  escribió:
>>
>> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe 
>> wrote:
>> > Ajay Garg  writes:
>> >
>> > [...]
>> >> b)
>> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> >> following line ::
>> >>
>> >>               options libertas libertas_disablemesh=0
>> > [...]
>> >> f)
>> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.
>> >
>> > Interesting.
>> >
>> >> g)
>> >> Observations e) and f) were observed, _every single time_.
>> >
>> > OK, I suppose you repeated this often enough and using exactly the same
>> > environment and procedures as the other test cases? I.e. you are sure
>> > that it's really specific to libertas_disablemesh=0 rather than just
>> > occurring at random even without the libertas_disablemesh setting or
>> > based on how the suspend / resume was triggered (e.g. idle suspend
>> > vs. lid or power switch)?
>>
>> I tried 3 times, and it happened every time. (I tried with the "lid"
>> approach every time, under identical conditions and set of
>> procedures.).
>>
>>
>>
>>
>>
>> >
>> > I don't see anything in the patch or the module params code that would
>> > explain this behaviour. If it's reproducible, I'll have to dive into it
>> > and debug a bit...
>>
>> It is reproducible every time (at least at my end). :)
>>
>>
>>
>>
>> >
>> > Thanks for testing, BTW!
>>
>> My pleasure :)
>>
>>
>>
>>
>> >
>> > Sascha
>> >
>> > --
>> > http://sascha.silbe.org/
>> > http://www.infra-silbe.de/
>>
>>
>> Regards,
>> Ajay
>> ___
>> Sugar-devel mailing list
>> sugar-de...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Abente]

Did you remove the disable mesh.script for the testing?
El may 4, 2012 10:39 p.m., "Ajay Garg"  escribió:

> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe 
> wrote:
> > Ajay Garg  writes:
> >
> > [...]
> >> b)
> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> following line ::
> >>
> >>   options libertas libertas_disablemesh=0
> > [...]
> >> f)
> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.
> >
> > Interesting.
> >
> >> g)
> >> Observations e) and f) were observed, _every single time_.
> >
> > OK, I suppose you repeated this often enough and using exactly the same
> > environment and procedures as the other test cases? I.e. you are sure
> > that it's really specific to libertas_disablemesh=0 rather than just
> > occurring at random even without the libertas_disablemesh setting or
> > based on how the suspend / resume was triggered (e.g. idle suspend
> > vs. lid or power switch)?
>
> I tried 3 times, and it happened every time. (I tried with the "lid"
> approach every time, under identical conditions and set of
> procedures.).
>
>
>
>
>
> >
> > I don't see anything in the patch or the module params code that would
> > explain this behaviour. If it's reproducible, I'll have to dive into it
> > and debug a bit...
>
> It is reproducible every time (at least at my end). :)
>
>
>
>
> >
> > Thanks for testing, BTW!
>
> My pleasure :)
>
>
>
>
> >
> > Sascha
> >
> > --
> > http://sascha.silbe.org/
> > http://www.infra-silbe.de/
>
>
> Regards,
> Ajay
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Paul Fox]

sascha wrote:
 > 
 > > i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
 > > did the rest.  this implements a new "libertas_disablemesh" module
 > > parameter which should keep mesh from being enabled.  please test:
 > >
 > > 
 > > http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
 > 
 > Thanks! Just to be sure: as it's been merged into olpc-2.6.35, all
 > future official 2.6.35 based OLPC kernel builds will include this patch?

hi sascha -- 

yes.  i think we hope there won't actually be any more of those, but
if there are, that patch will be there.  current and future releases
get the patch for free, since it's upstream.  (thank you)

paul

p.s.  somehow the git hash i pasted above is incorrect.  the correct
cherry-pick was this one:
-
 commit 6bdbdbf4a151a3a1333818cd17a7d7795e936041
 Author: Sascha Silbe 
 Date:   Wed May 11 14:52:34 2011 +0200

libertas: Add libertas_disablemesh module parameter to disable mesh 
interface

This allows individual users and deployments to disable mesh support at
runtime, i.e. without having to build and maintain a custom kernel.

Based on a patch by Paul Fox .
Signed-off-by: Sascha Silbe 
Signed-off-by: John W. Linville 
-


 > 
 > The reason we've not gone the module parameter route so far (in
 > Dextrose 3) is that we didn't want to divert from upstream (OLPC in this
 > case) on the kernel level. If it's included now, that concern is
 > addressed and we can go this route, which IMO is technically the best
 > option. It avoids all possible race conditions and only needs a single
 > configuration file to be set up.
 > 
 > Sascha
 > 
 > -- 
 > http://sascha.silbe.org/
 > http://www.infra-silbe.de/

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe  wrote:
> Ajay Garg  writes:
>
> [...]
>> b)
>> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> following line ::
>>
>>               options libertas libertas_disablemesh=0
> [...]
>> f)
>> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.
>
> Interesting.
>
>> g)
>> Observations e) and f) were observed, _every single time_.
>
> OK, I suppose you repeated this often enough and using exactly the same
> environment and procedures as the other test cases? I.e. you are sure
> that it's really specific to libertas_disablemesh=0 rather than just
> occurring at random even without the libertas_disablemesh setting or
> based on how the suspend / resume was triggered (e.g. idle suspend
> vs. lid or power switch)?

I tried 3 times, and it happened every time. (I tried with the "lid"
approach every time, under identical conditions and set of
procedures.).





>
> I don't see anything in the patch or the module params code that would
> explain this behaviour. If it's reproducible, I'll have to dive into it
> and debug a bit...

It is reproducible every time (at least at my end). :)




>
> Thanks for testing, BTW!

My pleasure :)




>
> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/


Regards,
Ajay
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Sascha Silbe]

Ajay Garg  writes:

[...]
> b)
> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> following line ::
>
>   options libertas libertas_disablemesh=0
[...]
> f)
> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.

Interesting. 

> g)
> Observations e) and f) were observed, _every single time_.

OK, I suppose you repeated this often enough and using exactly the same
environment and procedures as the other test cases? I.e. you are sure
that it's really specific to libertas_disablemesh=0 rather than just
occurring at random even without the libertas_disablemesh setting or
based on how the suspend / resume was triggered (e.g. idle suspend
vs. lid or power switch)?

I don't see anything in the patch or the module params code that would
explain this behaviour. If it's reproducible, I'll have to dive into it
and debug a bit...

Thanks for testing, BTW!

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpji401xnu3W.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Sascha Silbe]

Paul Fox  writes:

> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> did the rest.  this implements a new "libertas_disablemesh" module
> parameter which should keep mesh from being enabled.  please test:
>
> 
> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

Thanks! Just to be sure: as it's been merged into olpc-2.6.35, all
future official 2.6.35 based OLPC kernel builds will include this patch?

The reason we've not gone the module parameter route so far (in
Dextrose 3) is that we didn't want to divert from upstream (OLPC in this
case) on the kernel level. If it's included now, that concern is
addressed and we can go this route, which IMO is technically the best
option. It avoids all possible race conditions and only needs a single
configuration file to be set up.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpktCWgQvo8W.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Thanks James.

A second thanks, for the verbose explanation :) , thus making it
easier for future.
Thanks for your efforts.

Regards,
Ajay

On Thu, May 3, 2012 at 11:39 AM, James Cameron  wrote:
> On Thu, May 03, 2012 at 10:58:42AM +0530, Ajay Garg wrote:
>> == JUST ONE LAST QUERY ==
>>
>> Is the "disable-mesh-patch" the only difference between the following ::
>>
>>
>>           kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586
>>             (kernel generated by you)
>>           kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586
>>             (original kernel present on XO-1)
>
> The seven characters between olpc. and .i586 are the git hash for the
> olpc-2.6.35 branch in the git repository git://dev.laptop.org/olpc-kernel
>
> These tell you which git hash was used to build the kernel.
>
> The hash c2bd7b9 is two patches away from bde819f in the branch log.  [1]
>
> One patch [3] is what Paul did for you.  The other patch [2] is XO-1.5
> specific.
>
> So for your purposes, yes, it is the only difference.
>
> You can see a list of previous official kernels.  [4]
>
> References:
>
> 1.
> http://dev.laptop.org/git/olpc-kernel/?h=olpc-2.6.35
>
> 2.
> http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=5d76efb5df8c6b1d181c47b17b1d1e9a39ef66b6
> ov7670: Disable non-YUV modes on XO-1.5 (#11297)
> Non YUV modes cannot be scaled by the via-camera driver without messing
> up the colours in the image.
>
> 3.
> http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=bde819fe60fdc8ca7c7d6e0552105d0438cc7f89
> libertas: Add libertas_disablemesh module parameter to disable mesh
> interfaceolpc-2.6.35
> This allows individual users and deployments to disable mesh support at
> runtime, i.e. without having to build and maintain a custom kernel.
>
> 4.
> http://dev.laptop.org/~kernels/f14-xo1/?C=M;O=D
>
> --
> James Cameron
> http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[James Cameron]

On Thu, May 03, 2012 at 10:58:42AM +0530, Ajay Garg wrote:
> == JUST ONE LAST QUERY ==
> 
> Is the "disable-mesh-patch" the only difference between the following ::
> 
> 
>   kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586
> (kernel generated by you)
>   kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586
> (original kernel present on XO-1)

The seven characters between olpc. and .i586 are the git hash for the
olpc-2.6.35 branch in the git repository git://dev.laptop.org/olpc-kernel

These tell you which git hash was used to build the kernel.

The hash c2bd7b9 is two patches away from bde819f in the branch log.  [1]

One patch [3] is what Paul did for you.  The other patch [2] is XO-1.5
specific.

So for your purposes, yes, it is the only difference.

You can see a list of previous official kernels.  [4]

References:

1.
http://dev.laptop.org/git/olpc-kernel/?h=olpc-2.6.35

2.
http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=5d76efb5df8c6b1d181c47b17b1d1e9a39ef66b6
ov7670: Disable non-YUV modes on XO-1.5 (#11297)
Non YUV modes cannot be scaled by the via-camera driver without messing
up the colours in the image. 

3.
http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=bde819fe60fdc8ca7c7d6e0552105d0438cc7f89
libertas: Add libertas_disablemesh module parameter to disable mesh
interfaceolpc-2.6.35
This allows individual users and deployments to disable mesh support at
runtime, i.e. without having to build and maintain a custom kernel.

4.
http://dev.laptop.org/~kernels/f14-xo1/?C=M;O=D

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Paul, here are the test results ::


== USE-CASE 1 ==

a)
Created file '/etc/modprobe.d/libertas.conf'.


b)
Ensured that '/etc/modprobe.d/libertas.conf' contained only the
following line ::

  options libertas libertas_disablemesh=1


c)
Ensured that there is no "echo 0 > "/sys/class/net/eth0/lbs_mesh"
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


d)
Rebooted.


e)
Wifi icons were visible in Neighborhood-View, but no mesh-icons were visible.


f)
Upon resume-from-suspend, wifi icons were visible in
Neighborhood-View, but no mesh-icons were visible.


g)
Observations e) and f) were observed, _every single time_.



=



== USE-CASE 2 ==

a)
Created file '/etc/modprobe.d/libertas.conf'.


b)
Ensured that '/etc/modprobe.d/libertas.conf' contained only the
following line ::

  options libertas libertas_disablemesh=0


c)
Ensured that there is no "echo 0 > "/sys/class/net/eth0/lbs_mesh"
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


d)
Rebooted.


e)
Wifi icons, and mesh-icons were visible in Neighborhood-View.


f)
Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.


g)
Observations e) and f) were observed, _every single time_.




=



== USE-CASE 3 ==

a)
Ensured that there was no such file, that contained the following line ::

  options libertas libertas_disablemesh


b)
Ensured that there is no "echo 0 > "/sys/class/net/eth0/lbs_mesh"
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


c)
Rebooted.


d)
Wifi icons, and mesh-icons were visible in Neighborhood-View.


e)
Upon resume-from-suspend, wifi-icons and mesh-icons were visible in
Neighborhood-View.


f)
Observations d) and e) were observed, _every single time_.






== SUMMARY==

Barring use-case 2 (which looks a bit odd), use-cases 1 and 3 worked
perfectly as expected.
Thanks Paul for your prompt effort in generating the new kernel, with
the patch. Thanks again.





== JUST ONE LAST QUERY ==

Is the "disable-mesh-patch" the only difference between the following ::


  kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586
(kernel generated by you)
  kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586
(original kernel present on XO-1)





Thanks again.
The issue stands resolved :)


The new kernel could be deployed, provided the answer to the (last,
only) query is a "yes". :)


Regards,
Ajay





On Thu, May 3, 2012 at 2:21 AM, Paul Fox  wrote:
> martin wrote:
>  > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg  wrote:
>  > > I believe that the number of packets being forwarded in this, would be
>  > > (much) less than in the scenario when the users are actually connected 
> to a
>  > > mesh-network-channel.
>  > > Kindly affirm/reject my above notion :)
>  >
>  > I am a very pragmatic man, I would not waste your time if it was a maybe.
>  >
>  > There is no "much less" packet forwarding. You get 100% packet forwarding.
>  >
>  > And as Sam points out, the "UI" part of it can be set already with a
>  > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
>  > revert :-(
>  >
>  > Don't have the kernel patch info. Maybe look in git for changes in the
>  > libertas driver. It's a pretty low traffic driver, so you'll find it
>  > quick.
>
> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> did the rest.  this implements a new "libertas_disablemesh" module
> parameter which should keep mesh from being enabled.  please test:
>
>    
> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>
> paul
>
>  >
>  > cheers,
>  >
>  >
>  >
>  > 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
>
> =-
>  paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Paul Fox]

ajay wrote:
 > Hi all.
 > 
 > One generic query (not necessarily related to NM crash during
 > resume-upon-suspend) ::
 > 
 > I cannot seem to find any "grub.conf" on my XO-1, wherein I could add
 > the kernel boot parameter.
 > So, does XO-1 have any alternative to "grub.conf" ?

look at olpc.fth.   in /bootpart/boot/olpc.fth.

if this is for libertas_disablemesh, i'd suggest adding that
in modprobe.conf (or whatever the right file is under modprobe*/*
these days).

paul

 > 
 > 
 > Regards,
 > Ajay
 > 
 > On Thu, May 3, 2012 at 2:24 AM, Ajay Garg  wrote:
 > > Thanks Paul.
 > > I will test this, and get back to you once done.
 > >
 > > Thanks a ton 
 > >
 > >
 > > Regards,
 > > Ajay
 > >
 > > On Thu, May 3, 2012 at 2:21 AM, Paul Fox  wrote:
 > >> martin wrote:
 > >>  > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg  
 > >> wrote:
 > >>  > > I believe that the number of packets being forwarded in this, would 
 > >> be
 > >>  > > (much) less than in the scenario when the users are actually 
 > >> connected 
 > to a
 > >>  > > mesh-network-channel.
 > >>  > > Kindly affirm/reject my above notion :)
 > >>  >
 > >>  > I am a very pragmatic man, I would not waste your time if it was a 
 > >> maybe.
 > >>  >
 > >>  > There is no "much less" packet forwarding. You get 100% packet 
 > >> forwarding.
 > >>  >
 > >>  > And as Sam points out, the "UI" part of it can be set already with a
 > >>  > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
 > >>  > revert :-(
 > >>  >
 > >>  > Don't have the kernel patch info. Maybe look in git for changes in the
 > >>  > libertas driver. It's a pretty low traffic driver, so you'll find it
 > >>  > quick.
 > >>
 > >> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
 > >> did the rest.  this implements a new "libertas_disablemesh" module
 > >> parameter which should keep mesh from being enabled.  please test:
 > >>
 > >>
 > http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde
 > 819f.i586.rpm
 > >>
 > >> paul
 > >>
 > >>  >
 > >>  > cheers,
 > >>  >
 > >>  >
 > >>  >
 > >>  > 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
 > >>
 > >> =-
 > >>  paul fox, p...@laptop.org

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Hi all.

One generic query (not necessarily related to NM crash during
resume-upon-suspend) ::

I cannot seem to find any "grub.conf" on my XO-1, wherein I could add
the kernel boot parameter.
So, does XO-1 have any alternative to "grub.conf" ?


Regards,
Ajay

On Thu, May 3, 2012 at 2:24 AM, Ajay Garg  wrote:
> Thanks Paul.
> I will test this, and get back to you once done.
>
> Thanks a ton 
>
>
> Regards,
> Ajay
>
> On Thu, May 3, 2012 at 2:21 AM, Paul Fox  wrote:
>> martin wrote:
>>  > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg  wrote:
>>  > > I believe that the number of packets being forwarded in this, would be
>>  > > (much) less than in the scenario when the users are actually connected 
>> to a
>>  > > mesh-network-channel.
>>  > > Kindly affirm/reject my above notion :)
>>  >
>>  > I am a very pragmatic man, I would not waste your time if it was a maybe.
>>  >
>>  > There is no "much less" packet forwarding. You get 100% packet forwarding.
>>  >
>>  > And as Sam points out, the "UI" part of it can be set already with a
>>  > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
>>  > revert :-(
>>  >
>>  > Don't have the kernel patch info. Maybe look in git for changes in the
>>  > libertas driver. It's a pretty low traffic driver, so you'll find it
>>  > quick.
>>
>> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
>> did the rest.  this implements a new "libertas_disablemesh" module
>> parameter which should keep mesh from being enabled.  please test:
>>
>>    
>> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>>
>> paul
>>
>>  >
>>  > cheers,
>>  >
>>  >
>>  >
>>  > 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
>>
>> =-
>>  paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Thanks Paul.
I will test this, and get back to you once done.

Thanks a ton 


Regards,
Ajay

On Thu, May 3, 2012 at 2:21 AM, Paul Fox  wrote:
> martin wrote:
>  > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg  wrote:
>  > > I believe that the number of packets being forwarded in this, would be
>  > > (much) less than in the scenario when the users are actually connected 
> to a
>  > > mesh-network-channel.
>  > > Kindly affirm/reject my above notion :)
>  >
>  > I am a very pragmatic man, I would not waste your time if it was a maybe.
>  >
>  > There is no "much less" packet forwarding. You get 100% packet forwarding.
>  >
>  > And as Sam points out, the "UI" part of it can be set already with a
>  > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
>  > revert :-(
>  >
>  > Don't have the kernel patch info. Maybe look in git for changes in the
>  > libertas driver. It's a pretty low traffic driver, so you'll find it
>  > quick.
>
> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> did the rest.  this implements a new "libertas_disablemesh" module
> parameter which should keep mesh from being enabled.  please test:
>
>    
> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>
> paul
>
>  >
>  > cheers,
>  >
>  >
>  >
>  > 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
>
> =-
>  paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Paul Fox]

martin wrote:
 > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg  wrote:
 > > I believe that the number of packets being forwarded in this, would be
 > > (much) less than in the scenario when the users are actually connected to a
 > > mesh-network-channel.
 > > Kindly affirm/reject my above notion :)
 > 
 > I am a very pragmatic man, I would not waste your time if it was a maybe.
 > 
 > There is no "much less" packet forwarding. You get 100% packet forwarding.
 > 
 > And as Sam points out, the "UI" part of it can be set already with a
 > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
 > revert :-(
 > 
 > Don't have the kernel patch info. Maybe look in git for changes in the
 > libertas driver. It's a pretty low traffic driver, so you'll find it
 > quick.

i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
did the rest.  this implements a new "libertas_disablemesh" module
parameter which should keep mesh from being enabled.  please test:


http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

paul

 > 
 > cheers,
 > 
 > 
 > 
 > 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

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Martin,

just out of curiosity .. a logical query comes to my mind.


Why, and to whom, are packets forwarded, even though no user has joined any
channel?

Please do not take this as arrogance; I just wish to clear up some logical
mind-blocks :D
More importantly, this would clear up some of my networking concepts as
well :D


Thanks in advance for being my teacher :D


Thanks and Regards,
Ajay

On Wed, May 2, 2012 at 9:27 PM, Martin Langhoff
wrote:

> On Wed, May 2, 2012 at 11:07 AM, Ajay Garg  wrote:
> > I believe that the number of packets being forwarded in this, would be
> > (much) less than in the scenario when the users are actually connected
> to a
> > mesh-network-channel.
> > Kindly affirm/reject my above notion :)
>
> I am a very pragmatic man, I would not waste your time if it was a maybe.
>
> There is no "much less" packet forwarding. You get 100% packet forwarding.
>
> And as Sam points out, the "UI" part of it can be set already with a
> gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
> revert :-(
>
> Don't have the kernel patch info. Maybe look in git for changes in the
> libertas driver. It's a pretty low traffic driver, so you'll find it
> quick.
>
> cheers,
>
>
>
> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Mikus Grinbergs]

Another comment from the unwashed:

Years back, I used only ethernet to connect my XOs.  Nowadays, I'm using 
both wired and wireless to connect between XOs.  [By the way, I normally 
run my XOs with suspend disabled - so I have not paid much attention to 
problems associated with 'resume'.]


For about the last year, Network Manager has become "super bossy":

It used to be that if I had an XO on ethernet, Network Manager might 
intervene after some 10+ hours - breaking that ethernet connection.  I 
did not mind occasionally having to "reconnect" the ethernet (I just 
invoke a script that re-issues the necessary commands).


But the current Network Manager intervenes in less than ten SECONDS - it 
breaks the connection on the ethernet (eth1) interface - presumably to 
set up the wireless (eth0) interface (to listen for radio signals).


Bottom line - these days, in order to use ethernet on an XO, I need to 
__disable__ Network Manager.


mikus

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Wed, May 2, 2012 at 11:07 AM, Ajay Garg  wrote:
> I believe that the number of packets being forwarded in this, would be
> (much) less than in the scenario when the users are actually connected to a
> mesh-network-channel.
> Kindly affirm/reject my above notion :)

I am a very pragmatic man, I would not waste your time if it was a maybe.

There is no "much less" packet forwarding. You get 100% packet forwarding.

And as Sam points out, the "UI" part of it can be set already with a
gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
revert :-(

Don't have the kernel patch info. Maybe look in git for changes in the
libertas driver. It's a pretty low traffic driver, so you'll find it
quick.

cheers,



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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Well, could someone point me to the kernel fix, which could solve the
problem by backporting.
That should be an interesting exercise.

Regards,
Ajay

On Wed, May 2, 2012 at 8:44 PM, Anish Mangal wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/02/2012 07:59 PM, Martin Langhoff wrote:
> > On Wed, May 2, 2012 at 10:18 AM, Ajay Garg 
> > 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
> >
> >>
> > The patch seems fairly wrong to me. You are hiding the mesh icons
> > in sugar, but the mesh is active. Packet forwarding is still
> > happening.
> >
> > One of the top reasons we stopped using mesh is because it
> > saturates the RF spectrum, which is a bad thing to do when you have
> > many users in a small space (ie: in a school).
> >
> > You had the mesh disable trick working on F11, and (I assume)
> > happy users of that feature. With this, the feature is broken, but
> > you're making the UI look right...
> >
>
> I agree.
>
> The *problem* we are trying to solve is not to have a pretty
> mesh-icon-free-UI (which is a side effect), but disable the mesh at a
> hardware level.
>
> This patch *won't* solve the problem, as it will still flood the air
> with packet forwarding.
>
> - From the discussion, it seems to me that the kernel level switch is
> present in 12.x.x onwards, but not so for 11.3.x.
>
> In 10.3.x(f11) we got lucky as we were able to avoid the race condition.
>
> I suggest we keep looking for a proper solution:
> * Can the kernel fix be backported (might require a lot of work)
> * Can we tinker with the udev, postresume scripts to have it 'just'
> working
>
> I have reverted the commit:
>
>
> http://git.sugarlabs.org/dextrose/mainline/commit/20ef9a14dd55908aec6c04cf3edddc51004aabb0
>
> > cheers,
> >
> >
> >
> > m
>
>
> - --
> Anish
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPoU9PAAoJEBoxUdDHDZVp+DAH/j/RUl6AarwSlz0oUGIuPa5b
> FxpFOwO6edA0Avd4Zv0/0x3FWlaAEHwkkyz6Vcsq3Px0lxecX0JgYrEgaXWJP4l0
> YRBqROOBCzkVKxk7dEWZ003igZSGKbSmuRMlj4v4Qpv0yU9Tfi/GS3T1Q+r02B0o
> igF9XjmLT5lFcZ4U1e7vE/foU4f7Y5ugg/TON6u/Oh0GNF8bDdOSkY/xKhGlAkIf
> 72d1pSt03ypcQgUHy7mRhORj1rc1d1YCWiyZLv2iUXdR2OyR8qjukw2HjQ2Gu5ts
> DwTeumIy+QSF7fDIZkE83dErrmLJLUGvQ/4oqT50zhgI63o+/v8qBpa40XRo3bc=
> =KMS0
> -END PGP SIGNATURE-
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Anish Mangal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/02/2012 07:59 PM, Martin Langhoff wrote:
> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg 
> 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
>
>> 
> The patch seems fairly wrong to me. You are hiding the mesh icons
> in sugar, but the mesh is active. Packet forwarding is still
> happening.
> 
> One of the top reasons we stopped using mesh is because it
> saturates the RF spectrum, which is a bad thing to do when you have
> many users in a small space (ie: in a school).
> 
> You had the mesh disable trick working on F11, and (I assume)
> happy users of that feature. With this, the feature is broken, but
> you're making the UI look right...
> 

I agree.

The *problem* we are trying to solve is not to have a pretty
mesh-icon-free-UI (which is a side effect), but disable the mesh at a
hardware level.

This patch *won't* solve the problem, as it will still flood the air
with packet forwarding.

- From the discussion, it seems to me that the kernel level switch is
present in 12.x.x onwards, but not so for 11.3.x.

In 10.3.x(f11) we got lucky as we were able to avoid the race condition.

I suggest we keep looking for a proper solution:
* Can the kernel fix be backported (might require a lot of work)
* Can we tinker with the udev, postresume scripts to have it 'just'
working

I have reverted the commit:

http://git.sugarlabs.org/dextrose/mainline/commit/20ef9a14dd55908aec6c04cf3edddc51004aabb0

> cheers,
> 
> 
> 
> m


- -- 
Anish
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPoU9PAAoJEBoxUdDHDZVp+DAH/j/RUl6AarwSlz0oUGIuPa5b
FxpFOwO6edA0Avd4Zv0/0x3FWlaAEHwkkyz6Vcsq3Px0lxecX0JgYrEgaXWJP4l0
YRBqROOBCzkVKxk7dEWZ003igZSGKbSmuRMlj4v4Qpv0yU9Tfi/GS3T1Q+r02B0o
igF9XjmLT5lFcZ4U1e7vE/foU4f7Y5ugg/TON6u/Oh0GNF8bDdOSkY/xKhGlAkIf
72d1pSt03ypcQgUHy7mRhORj1rc1d1YCWiyZLv2iUXdR2OyR8qjukw2HjQ2Gu5ts
DwTeumIy+QSF7fDIZkE83dErrmLJLUGvQ/4oqT50zhgI63o+/v8qBpa40XRo3bc=
=KMS0
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

On Wed, May 2, 2012 at 7:59 PM, Martin Langhoff
wrote:

> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg  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
>
> The patch seems fairly wrong to me. You are hiding the mesh icons in
> sugar, but the mesh is active. Packet forwarding is still happening.
>


Hmm, ok (didn't know this).

I believe that the number of packets being forwarded in this, would be
(much) less than in the scenario when the users are actually connected to a
mesh-network-channel.
Kindly affirm/reject my above notion :)


Regards,
Ajay



>
> One of the top reasons we stopped using mesh is because it saturates
> the RF spectrum, which is a bad thing to do when you have many users
> in a small space (ie: in a school).
>
> You had the mesh disable trick working on F11, and (I assume) happy
> users of that feature. With this, the feature is broken, but you're
> making the UI look right...
>
> cheers,
>
>
>
> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Samuel Greenfeld]

It's worth noting that half the battle can be won by overriding the
following XO-1 specific line in OLPC OS Builder's kspost.50.xo1-tweaks.inc:

gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.defaults --type bool --set
/desktop/sugar/network/adhoc false

Setting this to "true", or letting it default to such will show the Ad-hoc
networks by default on XO-1.  It also will cause XO-1's to default to
Ad-hoc if no preferred network is found.

The mesh networks will still be there for manual use; but right now they
seem semi-broken anyway on 12.1.0 as we attempt to connect to "Mesh Network
0" and don't set a channel on the Interface.


On Wed, May 2, 2012 at 10:29 AM, Martin Langhoff
wrote:

> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg  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
>
> The patch seems fairly wrong to me. You are hiding the mesh icons in
> sugar, but the mesh is active. Packet forwarding is still happening.
>
> One of the top reasons we stopped using mesh is because it saturates
> the RF spectrum, which is a bad thing to do when you have many users
> in a small space (ie: in a school).
>
> You had the mesh disable trick working on F11, and (I assume) happy
> users of that feature. With this, the feature is broken, but you're
> making the UI look right...
>
> cheers,
>
>
>
> 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
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Wed, May 2, 2012 at 10:18 AM, Ajay Garg  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

The patch seems fairly wrong to me. You are hiding the mesh icons in
sugar, but the mesh is active. Packet forwarding is still happening.

One of the top reasons we stopped using mesh is because it saturates
the RF spectrum, which is a bad thing to do when you have many users
in a small space (ie: in a school).

You had the mesh disable trick working on F11, and (I assume) happy
users of that feature. With this, the feature is broken, but you're
making the UI look right...

cheers,



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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

On Wed, May 2, 2012 at 7:57 PM, Kevin Gordon  wrote:

>
>
> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg  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.
>

What could be the difference therein? (I could change to one, that could
work in both) :)

Regards,
Ajay


>   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  wrote:
>>
>>> martin wrote:
>>>  > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg 
>>> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Kevin Gordon]

On Wed, May 2, 2012 at 10:18 AM, Ajay Garg  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  wrote:
>
>> martin wrote:
>>  > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg 
>> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

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


Regards,
Ajay

On Wed, May 2, 2012 at 6:02 PM, Paul Fox  wrote:

> martin wrote:
>  > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg 
> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Paul Fox]

martin wrote:
 > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg  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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Wed, May 2, 2012 at 5:32 AM, Ajay Garg  wrote:
> In one of the earlier mails, it was said that the mac address for "msh0" is
> the same as "eth0".

Ah, sorry, you're correct, that won't help.

So your options are

 - a kernel module parameter, as Jon proposes, in modprobe.d/ or in
the boot commandline

 - udev rule / script that triggers before the event is sent to NM




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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Martin, just one small query :

In one of the earlier mails, it was said that the mac address for "msh0" is
the same as "eth0".
So, would blacklisting the (same) device, be feasible? I mean, would that
not _also_ disable general wifi network detections?


Regards,
Ajay

On Wed, May 2, 2012 at 12:58 PM, Martin Langhoff
wrote:

> On Wed, May 2, 2012 at 3:22 AM, Ajay Garg  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.
>
> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Abente]

How hard and sensible do you think it could be to backport that patch? :D
(Assuming that touching the kernel is an option for someone, hehe)

On Wed, May 2, 2012 at 5:21 AM, Jon Nettleton wrote:

> On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
>  wrote:
> > On Wed, May 2, 2012 at 4:07 AM, Martin Abente
> >  wrote:
> >> I think (guessing by the responses) the original problem here is that,
> if
> >> you disable the mesh AFTER NM has taken the device, NM crashes. This a
> >> regression bug, considering that this didn't happened in fedora-11 based
> >> builds.
> >
> > The timings in F11 builds were completely different. Maybe you were
> > winning the race that you're now losing.
> >
> >> So the solution here is to find another place to place the script,
> where it
> >> guarantee that the script will be executed before NM does its job at
> resume
> >> time.
> >
> > udev script :-) -- I am pretty sure you can number yourself lower (to
> > run earlier) than the udev script that fires off the "new device"
> > event to NM.
> >
> >> Another solution is to find out why NM crashes now and why didn't
> before,
> >> but I wouldn't go that way.
> >
> > Making NM completely resilient to these race conditions is probably a
> hard task.
>
> This is also a temporary solution.  There is a kernel patch in 3.1 and
> greater kernels that allows you to disable mesh as a kernel module
> parameter.
>
> I just played around with the udev script and there definitely seems
> to be some timing issues even with that.
>
> -Jon
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Jon Nettleton]

On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
 wrote:
> On Wed, May 2, 2012 at 4:07 AM, Martin Abente
>  wrote:
>> I think (guessing by the responses) the original problem here is that, if
>> you disable the mesh AFTER NM has taken the device, NM crashes. This a
>> regression bug, considering that this didn't happened in fedora-11 based
>> builds.
>
> The timings in F11 builds were completely different. Maybe you were
> winning the race that you're now losing.
>
>> So the solution here is to find another place to place the script, where it
>> guarantee that the script will be executed before NM does its job at resume
>> time.
>
> udev script :-) -- I am pretty sure you can number yourself lower (to
> run earlier) than the udev script that fires off the "new device"
> event to NM.
>
>> Another solution is to find out why NM crashes now and why didn't before,
>> but I wouldn't go that way.
>
> Making NM completely resilient to these race conditions is probably a hard 
> task.

This is also a temporary solution.  There is a kernel patch in 3.1 and
greater kernels that allows you to disable mesh as a kernel module
parameter.

I just played around with the udev script and there definitely seems
to be some timing issues even with that.

-Jon
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Wed, May 2, 2012 at 4:07 AM, Martin Abente
 wrote:
> I think (guessing by the responses) the original problem here is that, if
> you disable the mesh AFTER NM has taken the device, NM crashes. This a
> regression bug, considering that this didn't happened in fedora-11 based
> builds.

The timings in F11 builds were completely different. Maybe you were
winning the race that you're now losing.

> So the solution here is to find another place to place the script, where it
> guarantee that the script will be executed before NM does its job at resume
> time.

udev script :-) -- I am pretty sure you can number yourself lower (to
run earlier) than the udev script that fires off the "new device"
event to NM.

> Another solution is to find out why NM crashes now and why didn't before,
> but I wouldn't go that way.

Making NM completely resilient to these race conditions is probably a hard task.

cheers,



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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Abente]

I think (guessing by the responses) the original problem here is that, if
you disable the mesh AFTER NM has taken the device, NM crashes. This a
regression bug, considering that this didn't happened in fedora-11 based
builds.

So the solution here is to find another place to place the script, where it
guarantee that the script will be executed before NM does its job at resume
time.

Another solution is to find out why NM crashes now and why didn't before,
but I wouldn't go that way.

Cheers,


On Wed, May 2, 2012 at 3:28 AM, Martin Langhoff
wrote:

> On Wed, May 2, 2012 at 3:22 AM, Ajay Garg  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.
>
> 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
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Wed, May 2, 2012 at 3:22 AM, Ajay Garg  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.

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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Thanks Martin (a ton !!)

On Wed, May 2, 2012 at 12:32 PM, Martin Langhoff
wrote:

> On Wed, May 2, 2012 at 2:25 AM, Ajay Garg  wrote:
> > I agree. But there is no working lower-level solution :\
>
> Let's fix that.


Great !!!







> Messing with Sugar won't help you.
>
> Earlier in the thread someone pointed to you the scripts to trigger on
> resume (by powerd). Do those work? Not work? What's the problem there?
>

The /etc/powerd/postresume.d/disable_mesh.sh  doesn't work.
My belief is that there is the same problem - race condition between the
'echo 0' script, and NetworkManager. This causes the NetworkManager to
crash randomly.






>
> AIUI, if you
>
>  - 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.







>  - disable mesh on resume, from a powerd-triggered script
>

Does not work, as explained above.







>  - 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 :)
Could you point me to the suitable (examples) link? I will be heartfully
grateful.



>
> cheers,
>
>
>
> 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
>


Regards,
Ajay
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Wed, May 2, 2012 at 2:25 AM, Ajay Garg  wrote:
> I agree. But there is no working lower-level solution :\

Let's fix that. Messing with Sugar won't help you.

Earlier in the thread someone pointed to you the scripts to trigger on
resume (by powerd). Do those work? Not work? What's the problem there?

AIUI, if you

 - disable mesh on boot
 - disable mesh on resume, from a powerd-triggered script
 - 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.

cheers,



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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Anish Mangal]

On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
 wrote:
> On Wed, May 2, 2012 at 12:13 AM, Ajay Garg  wrote:
>> Just that, we do not wish to set up a mesh-network, as per say.
>
> I think you are missing the background reason here. AFAIK, reasons to
> disable mesh network on XO-1:
>
>  - Mesh can easily saturate RF, so dense usage scenarios (schools!)
> benefit from switching it off.
>
>  - Easier out-of-the-box interop with later XO-1.x models, where the
> "under a tree" network uses ad-hoc 802.11g.
>

+1, this was the reason

>> By removing all references to the device, we could provide a "soft" solution
>
> Nah, messing with Sugar code is the wrong solution.
>
>
>
> 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
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
wrote:

> On Wed, May 2, 2012 at 12:13 AM, Ajay Garg  wrote:
> > Just that, we do not wish to set up a mesh-network, as per say.
>
> I think you are missing the background reason here. AFAIK, reasons to
> disable mesh network on XO-1:
>
>  - Mesh can easily saturate RF, so dense usage scenarios (schools!)
> benefit from switching it off.
>
>  - Easier out-of-the-box interop with later XO-1.x models, where the
> "under a tree" network uses ad-hoc 802.11g.
>
> > By removing all references to the device, we could provide a "soft"
> solution
>
> Nah, messing with Sugar code is the wrong solution.
>

I agree. But there is no working lower-level solution :\


Regards,
Ajay



>
>
> 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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Langhoff]

On Wed, May 2, 2012 at 12:13 AM, Ajay Garg  wrote:
> Just that, we do not wish to set up a mesh-network, as per say.

I think you are missing the background reason here. AFAIK, reasons to
disable mesh network on XO-1:

 - Mesh can easily saturate RF, so dense usage scenarios (schools!)
benefit from switching it off.

 - Easier out-of-the-box interop with later XO-1.x models, where the
"under a tree" network uses ad-hoc 802.11g.

> By removing all references to the device, we could provide a "soft" solution

Nah, messing with Sugar code is the wrong solution.



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

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Anish Mangal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed 02 May 2012 09:39:50 AM IST, James Cameron wrote:
> On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
>> Thanks James for the reply.
>>
>> On Wed, May 2, 2012 at 9:21 AM, James Cameron  wrote:
>>
>> On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
>> > Is there an already tested-cum-recommended method, that could disable
>> > mesh-network, both during reboots and resume-from-suspend?
>>
>> Not that I know of.
>>
>> But I'm curious, why do you need to do this?  Is there some other
>> problem you think you will solve with this?  There might be an alternate
>> solution.
>>
>>
>> No, nothing of that sort.
>> Just wish to remove the mesh-icons from Neighborhood-View.
>
> But why?
>

Because it isn't really used much. Sugar supports adhoc networking
(since 0.88, IIRC) and that is used instead (atleast in dextrose
builds).

So, its better to make the mesh functionality disabled/invisible to the
user.

>> Right now, we were trying the disable-mesh-script (''echo 0 > 
>> "/sys/class/net/
>> eth0/lbs_mesh"") for our purpose.
>> Now, I am thinking of removing all references to devices of type
>> "DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do it.
>
> Yes, that should do it.
>



- --
Anish
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPoLT8AAoJEBoxUdDHDZVpC1QH/0ukS8tfT0IejDCczQkT7SCp
fiAuifIh8JCayK7j3CAY5BMUHoGlL8IRxw/xKqAxF+OZLKklb9GiFIok+5UJHC2o
S2HAHVe/MCHbmcL1npV2qvlSnzVpEIXFtbQvjasX0IGJx6rC5RBDO5cKOXbbKAII
QLwCwBgJmEbRLa5G+2ji++g21Y6OD6WL34ilSwLArcyEwgfozZlP1en0BAStCw1i
543yfN91f72KGNU4hNfa6LlR4GLhcjemLN2TLFB/rgliPF7VEFc77O25Y+YvKnZ8
7A8ZtBvbTt8F5eKGfbzJhfUVYCatTU9gD0H9w3DX/fdQ76+ySxGDrmBBnCsJwbY=
=GKXZ
-END PGP SIGNATURE-

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

On Wed, May 2, 2012 at 9:39 AM, James Cameron  wrote:

> On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
> > Thanks James for the reply.
> >
> > On Wed, May 2, 2012 at 9:21 AM, James Cameron  wrote:
> >
> > On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> > > Is there an already tested-cum-recommended method, that could
> disable
> > > mesh-network, both during reboots and resume-from-suspend?
> >
> > Not that I know of.
> >
> > But I'm curious, why do you need to do this?  Is there some other
> > problem you think you will solve with this?  There might be an
> alternate
> > solution.
> >
> >
> > No, nothing of that sort.
> > Just wish to remove the mesh-icons from Neighborhood-View.
>
> But why?
>

Just that, we do not wish to set up a mesh-network, as per say.
By removing all references to the device, we could provide a "soft"
solution :)

Thanks again.

Regards,
Ajay


>
> > Right now, we were trying the disable-mesh-script (''echo 0 >
> "/sys/class/net/
> > eth0/lbs_mesh"") for our purpose.
> > Now, I am thinking of removing all references to devices of type
> > "DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do
> it.
>
> Yes, that should do it.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[James Cameron]

On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
> Thanks James for the reply.
> 
> On Wed, May 2, 2012 at 9:21 AM, James Cameron  wrote:
> 
> On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> > Is there an already tested-cum-recommended method, that could disable
> > mesh-network, both during reboots and resume-from-suspend?
> 
> Not that I know of.
> 
> But I'm curious, why do you need to do this?  Is there some other
> problem you think you will solve with this?  There might be an alternate
> solution.
> 
> 
> No, nothing of that sort.
> Just wish to remove the mesh-icons from Neighborhood-View.

But why?

> Right now, we were trying the disable-mesh-script (''echo 0 > "/sys/class/net/
> eth0/lbs_mesh"") for our purpose.
> Now, I am thinking of removing all references to devices of type
> "DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do it.

Yes, that should do it.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Thanks James for the reply.

On Wed, May 2, 2012 at 9:21 AM, James Cameron  wrote:

> On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> > Is there an already tested-cum-recommended method, that could disable
> > mesh-network, both during reboots and resume-from-suspend?
>
> Not that I know of.
>
> But I'm curious, why do you need to do this?  Is there some other
> problem you think you will solve with this?  There might be an alternate
> solution.
>

No, nothing of that sort.
Just wish to remove the mesh-icons from Neighborhood-View.

Right now, we were trying the disable-mesh-script (''echo 0 >
"/sys/class/net/eth0/lbs_mesh"") for our purpose.
Now, I am thinking of removing all references to devices of type
"DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do it.

Thanks to all for your quick responses.

Thanks and Regards,
Ajay



>
> --
> James Cameron
> http://quozl.linux.org.au/
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[James Cameron]

On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> Is there an already tested-cum-recommended method, that could disable
> mesh-network, both during reboots and resume-from-suspend?

Not that I know of.

But I'm curious, why do you need to do this?  Is there some other
problem you think you will solve with this?  There might be an alternate
solution.

-- 
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Just an updated version ::


Hi all.

I'll ask this straight ::

"""
Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?
"""

Possible options (not tested by me) ::


a)
A driver,  encapsulating the patch at
http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
(as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)


Query : How can I ascertain if this patch is present on a particular XO-1?





b)
(For Reboot) ::
Add the bootstrap script 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' in
'/etc/init.d/NetworkMaanager'.

(For Resume-Upon-Suspend) ::
Add the disable_mesh.sh script (at
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
in "/etc/powerd/postresume.d".


Query   : While the (For Reboot) case is guaranteed to work stably every
single time, can the same be said about (For Resume-Upon-Suspend) ?
Answer : No. The (Resume-Upon-Suspend) case does not work. So, this
solution is rejected.




c) Any other unknown in-the-dark hack.



Regards,
Ajay

On Wed, May 2, 2012 at 9:10 AM, Ajay Garg  wrote:

> Hi all.
>
> I'll ask this straight ::
>
> """
> Is there an already tested-cum-recommended method, that could disable
> mesh-network, both during reboots and resume-from-suspend?
> """
>
> Possible options (not tested by me) ::
>
>
> a)
> A driver,  encapsulating the patch at
> http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
> (as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)
>
>
> Query : How can I ascertain if this patch is present on a particular XO-1?
>
>
>
>
>
> b)
> (For Reboot) ::
> Add the bootstrap script 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' in
> '/etc/init.d/NetworkMaanager'.
>
> (For Resume-Upon-Suspend) ::
> Add the disable_mesh.sh script (at
> http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
> in "/etc/powerd/postresume.d".
>
>
> Query : While the (For Reboot) case is guaranteed to work stably every
> single time, can the same be said about (For Resume-Upon-Suspend) ?
>
>
>
>
> c) Any other unknown in-the-dark hack.
>
>
>
> Regards,
> Ajay
>
>
>
>
> On Tue, May 1, 2012 at 9:36 PM, Peter Robinson wrote:
>
>> On Tue, May 1, 2012 at 3:55 PM, Ajay Garg 
>> wrote:
>> > which actually brings me back to my original question ::
>> >
>> > """
>> > Why is it so that putting the 'disable-mesh-script' in the 'start()'
>> method
>> > of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never
>> works
>> > for resume-upon-suspend?
>> > """
>>
>> Because on suspend/resume the NetworkManager service isn't
>> started/restarted so the script in /etc/init.d isn't run where as on
>> reboot it is. There's means though to run specific scripts on
>> suspend/resume if that sort of thing is necessary.
>>
>> Peter
>>
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Ajay Garg]

Hi all.

I'll ask this straight ::

"""
Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?
"""

Possible options (not tested by me) ::


a)
A driver,  encapsulating the patch at
http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
(as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)


Query : How can I ascertain if this patch is present on a particular XO-1?





b)
(For Reboot) ::
Add the bootstrap script 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' in
'/etc/init.d/NetworkMaanager'.

(For Resume-Upon-Suspend) ::
Add the disable_mesh.sh script (at
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
in "/etc/powerd/postresume.d".


Query : While the (For Reboot) case is guaranteed to work stably every
single time, can the same be said about (For Resume-Upon-Suspend) ?




c) Any other unknown in-the-dark hack.



Regards,
Ajay



On Tue, May 1, 2012 at 9:36 PM, Peter Robinson  wrote:

> On Tue, May 1, 2012 at 3:55 PM, Ajay Garg 
> wrote:
> > which actually brings me back to my original question ::
> >
> > """
> > Why is it so that putting the 'disable-mesh-script' in the 'start()'
> method
> > of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never
> works
> > for resume-upon-suspend?
> > """
>
> Because on suspend/resume the NetworkManager service isn't
> started/restarted so the script in /etc/init.d isn't run where as on
> reboot it is. There's means though to run specific scripts on
> suspend/resume if that sort of thing is necessary.
>
> Peter
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Peter Robinson]

On Tue, May 1, 2012 at 3:55 PM, Ajay Garg  wrote:
> which actually brings me back to my original question ::
>
> """
> Why is it so that putting the 'disable-mesh-script' in the 'start()' method
> of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never works
> for resume-upon-suspend?
> """

Because on suspend/resume the NetworkManager service isn't
started/restarted so the script in /etc/init.d isn't run where as on
reboot it is. There's means though to run specific scripts on
suspend/resume if that sort of thing is necessary.

Peter
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel