problems using the measure activity.

[Iain (ixo) D]

I found this on the wiki a few days ago.. (unfortunately, I didn't note
where....)

Suspend mode on/off

To prevent suspend from happening.

$ touch /etc/ohm/inhibit-suspend

To re-enable suspend.

$ rm  /etc/ohm/inhibit-suspend


--ixo



On Feb 11, 2008 1:13 AM, John Gilmore <gnu at toad.com> wrote:

> > > we did try this with -rc2 (we upgraded 4-5 machines to -rc2 over the
> > > wekend.)
> >
> > I just tried it again with my two machines and it worked for about 60
> > seconds (at which time the one running on battery did a suspend and the
> > activity stopped)
>
> Why would an activity break when awaiting packets and the system suspends?
> It's supposed to break out of suspend when the next packet arrives.
>
> Oh!  Because the activity sharing/association stuff uses multicast
> packets, and there's bug http://dev.laptop.org/ticket/4616, "Mesh
> doesn't resume from suspend on reciept of multicast packets".
>
> If you create some file somewhere, then Ohm won't suspend.  (Chris,
> how about adding a real control for this into the olpc-control-panel?)
> You could do the research to find that file, then create it, then see
> how Distance works.  I can see that you'd have problems sharing the
> two instances, due to the bug, but then once they are paired, they
> ought to be using unicast packets (via TCP), right?  Sending a unicast
> packet would wake the laptop on the other end out of suspend (this is
> supposed to be working -- but takes a full second or so).  So is there
> another bug, either in Distance, in the infrastructure between shared
> activities, or in suspending, that is causing Distance to fail once fully
> shared?
>
> Unfortunately, fixing that multicast bug may be hard.  It took months
> to convince OLPC that it ought to get fixed, despite the fact that it
> breaks every incoming IPv6 connection.  The WiFi firmware supposedly
> already supports resuming on reciept of interesting multicast packets;
> we just aren't asking to be awakened for them.  The problem is that
> the laptop's presence software is listening to (and transmitting) way
> too many multicast packets all the time -- so it would pop out of
> suspend all the time.
>
> Once the presence service gets the network traffic down to a dull
> roar, and the suspend/resume time gets shorter, it'll be easier to
> fix.
>
>        John
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080211/5d25ad13/attachment.html>