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,
Ajay Garg ajaygargn...@gmail.com 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
Paul Fox p...@foxharp.boston.ma.us 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
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
On Sat, May 12, 2012 at 5:40 PM, Jerry Vonau jvo...@shaw.ca 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
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 Sat, May 12, 2012 at 2:08 PM, Ajay Garg a...@activitycentral.com 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
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
On Sat, May 12, 2012 at 4:38 AM, Ajay Garg a...@activitycentral.com 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
On Sat, 2012-05-12 at 15:20 -0400, Martin Langhoff wrote:
On Sat, May 12, 2012 at 4:38 AM, Ajay Garg a...@activitycentral.com 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
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
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,
On Thu, May 10, 2012 at 1:23 PM, Ajay Garg a...@activitycentral.com 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
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)
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
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.
On Sat, May 5, 2012 at 6:26 AM, Ajay Garg ajaygargn...@gmail.com 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
On Fri, May 4, 2012 at 4:41 PM, Paul Fox p...@laptop.org 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:
kevin wrote:
On Fri, May 4, 2012 at 4:41 PM, Paul Fox p...@laptop.org 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
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
Paul Fox p...@laptop.org 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:
Ajay Garg ajaygargn...@gmail.com 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)
On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe si...@activitycentral.com wrote:
Ajay Garg ajaygargn...@gmail.com writes:
[...]
b)
Ensured that '/etc/modprobe.d/libertas.conf' contained only the
following line ::
options libertas libertas_disablemesh=0
[...]
f)
Upon
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:
Did you remove the disable mesh.script for the testing?
El may 4, 2012 10:39 p.m., Ajay Garg ajaygargn...@gmail.com escribió:
On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe si...@activitycentral.com
wrote:
Ajay Garg ajaygargn...@gmail.com writes:
[...]
b)
Ensured that
On Sat, May 5, 2012 at 3:42 AM, Martin Abente
martin.abente.lah...@gmail.com 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
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)
On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com 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
On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
martin.langh...@gmail.comwrote:
On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com 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
On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Wed, May 2, 2012 at 12:13 AM, Ajay Garg ajaygargn...@gmail.com 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
On Wed, May 2, 2012 at 2:25 AM, Ajay Garg ajaygargn...@gmail.com 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?
Thanks Martin (a ton !!)
On Wed, May 2, 2012 at 12:32 PM, Martin Langhoff
martin.langh...@gmail.comwrote:
On Wed, May 2, 2012 at 2:25 AM, Ajay Garg ajaygargn...@gmail.com wrote:
I agree. But there is no working lower-level solution :\
Let's fix that.
Great !!!
Messing with Sugar
On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com wrote:
The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
So we need to understand why it does not work. Is it a race condition?
Perhaps it is better fixed as a udev script -- triggering when the
device appears.
The step
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,
On Wed, May 2, 2012 at 4:07 AM, Martin Abente
martin.abente.lah...@gmail.com 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
On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Wed, May 2, 2012 at 4:07 AM, Martin Abente
martin.abente.lah...@gmail.com 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
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 jon.nettle...@gmail.comwrote:
On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
martin.langh...@gmail.com
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
On Wed, May 2, 2012 at 5:32 AM, Ajay Garg ajaygargn...@gmail.com 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
martin wrote:
On Wed, May 2, 2012 at 3:22 AM, Ajay Garg ajaygargn...@gmail.com wrote:
The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
So we need to understand why it does not work. Is it a race condition?
Perhaps it is better fixed as a udev script -- triggering when the
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 p...@laptop.org wrote:
martin wrote:
On Wed, May
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:
Good News.
I managed to get this working (albeit via changes in sugar).
The details are at ::
http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
I have a couple of minor
On Wed, May 2, 2012 at 7:57 PM, Kevin Gordon kgordon...@gmail.com wrote:
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:
Good News.
I managed to get this working (albeit via changes in sugar).
The details are at ::
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:
Good News.
I managed to get this working (albeit via changes in sugar).
The details are at ::
http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
The patch seems fairly wrong to
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
On Wed, May 2, 2012 at 7:59 PM, Martin Langhoff
martin.langh...@gmail.comwrote:
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg ajaygargn...@gmail.com wrote:
Good News.
I managed to get this working (albeit via changes in sugar).
The details are at ::
-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 ajaygargn...@gmail.com
wrote:
Good News.
I managed to get this working (albeit via changes in sugar).
The details are at ::
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 an...@activitycentral.comwrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2012 07:59
On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com 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
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'.]
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
martin wrote:
On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com 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
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 p...@laptop.org wrote:
martin wrote:
On Wed, May 2, 2012 at 11:07 AM, Ajay Garg ajaygargn...@gmail.com wrote:
I believe that the number of packets
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
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
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
On Tue, May 1, 2012 at 3:55 PM, Ajay Garg a...@activitycentral.com 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
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
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
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
Thanks James for the reply.
On Wed, May 2, 2012 at 9:21 AM, James Cameron qu...@laptop.org 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
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 qu...@laptop.org wrote:
On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
Is there an already tested-cum-recommended method, that could
On Wed, May 2, 2012 at 9:39 AM, James Cameron qu...@laptop.org 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 qu...@laptop.org wrote:
On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg
-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 qu...@laptop.org wrote:
On Wed, May 02, 2012 at
64 matches
Mail list logo
