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
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
___
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
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 trick
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 "/e
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 sto
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
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 imag
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-ic
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
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
> complete
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
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
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
exc
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"
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 be
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:
> > >
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"
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 scrutini
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
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ó
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 :
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.
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
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) a
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-20120
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 "
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.
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/n
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.
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
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
>
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 :)
>
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 netw
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
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 w
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 wr
-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/m
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/4ac1a5300f4c43608b0f
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 "tr
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
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/4ac1a5300f4c43608b0f0
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 th
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
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.
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 comma
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
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
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 th
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 timing
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
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 perf
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 s
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 th
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
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
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
-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:26A
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
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
>
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 kn
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 y
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.i
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/libert
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
65 matches
Mail list logo
