OHM Power Manager for OLPC laptops

[jg]

We need some desktop component, in concert with sugar and what's on top of the screen as known by a window manager, to determine if our aggressive suspend to RAM should start being invoked. Communications is probably via DBUS.

Richard Hughes, the current author of GnomePowerManager, is in the developer program and wants to help us out.

[hughsient@…]

Yup, I can do this. What are we exposing in the way of configuration and UI? This probably depends on the inclusion of HAL, or we are going to need some sort of system daemon to do the action for us.

[jg]

Dunno if we're going to have Hal for a bit.

Dave Zeuthen has rejoined Rh's desktop group, and that's one of the things he's going to be doing, but the timing isn't clear yet when it will have some of its performance problems fixed to the point we can use it.

I suggest we have a conversation with Adam Jackson around the display piece of this.

[davidz]

Well, the first step is for OLPC to make a list specific problems (startup time, memory usage etc.) you have with hal - it's only a 'yum install hal' away on devel_ext3 and devel_jffs2 images...

For the record, the last time I tried running hal on a A-test board it wasn't really that bad. It would certainly make it easier for me and Richard to prioritize what we need to do once we have a list of specific problems for OLPC. Thanks.

[jg]

Any progress? Hal is in the build these days.

[hughsient@…]

Replying to jg:

Any progress? Hal is in the build these days.

Yes, I've built a slimmed down g-p-m for testing and am integrating the OLPC battery class code into HAL. I've managed to get g-p-m to change the brightness thru HAL (to save power) but I really am waiting on the uevent/poll on ec change from David Woodhouse for battery abstraction. I also need to know what you guys want to expose in the sugar UI - for instance, how do you convey to the user the remaining battery time?

Thanks,

Richard.

[marco]

The UI design for this aspect is not fully flashed out yet. The battery status will likely be displayed with an icon on the home view (the one with the activities donut).

[hughsient@…]

Replying to marco:

The battery status will likely be displayed with an icon on the home view

Will this be some sort of applet or an in-process icon? Have you got any examples on how to do this? I want to design the g-p-m-compatible dbus interface to be suitable for OLPC, n770 etc.

[marco]

Replying to hughsient@gmail.com:

Replying to marco:

The battery status will likely be displayed with an icon on the home view

Will this be some sort of applet or an in-process icon?

I didn't put a lot of thinking into this, since we only started the UI design recently. Though I'm pretty sure it will have to be in-process. We want full control on the the layout of the device icons in the home view, interaction with the icon will be different from desktops, the icon background will have to be transparent, etc.

Have you got any examples on how to do this?

Oh there is really no support in sugar for this yet.

I want to design the g-p-m-compatible dbus interface to be suitable for OLPC, n770 etc.

If you have any doc or code about the interface I'd happy to have a look and see if it's suitable for OLPC. The requirements for battery status in the current design seem pretty simple:

* A way to get the battery level * A way to get the remaining battery time * Notifications when these properties change (?)

If you are interested in seeing the user interface mockups let me know.

[hughsient@…]

Replying to marco:

* A way to get the battery level * A way to get the remaining battery time * Notifications when these properties change (?)

I think this is a little shortsighted - surely more intelligence is needed in the manager - for instance we might want to say to the user "The amount of light falling on the solar panel array is insufficient" rather than exposing this as a blob on an obscure interface. I think a GetDescription() and GetIcon() API is much more suitable.

[marco]

If GetDescription() is going to provide a message about the battery status (which in the very basic case could be something like "30 minutes remaining") than it would probably work.

We also need a way to get the battery level though because we want to show the level graphically (with a bar) rather than as a message.

GetIcon() would be probably OK as long as the actual icons can be themed (by using icon themes for example).

In general the API you are proposing constraints a bit the possible UI representations. That might be OK, but I'll have to check with the design team.

Thanks!

[hughsient@…]

Replying to marco:

GetIcon() would be probably OK as long as the actual icons can be themed (by using icon themes for example).

yes, this is what I assumed.

In general the API you are proposing constraints a bit the possible UI representations. That might be OK, but I'll have to check with the design team.

Brilliant, thanks. I've added this UI to gnome-power-manager CVS so we can play a bit with this.

Richard,

[jg]

Time to also check in with Nokia to see if they've done work in this area. In any case, it is time to get moving on this issue.

[jg]

Cjb and Don Hopkins did a quick and dirty hack to the book reader as a first stab at ebook mode, and got it working with dilinger and rsmith.

Now what? How do we clean this up properly?

[cjb]

The ebook hack is almost totally unrelated to what we need from the power manager -- it's an application specifically initiating suspend when it knows it is idle, whereas the power manager should initiate suspend itself when it discovers everything *else* is idle. Once we have that, the ebook hack should disappear.

The reusable parts are the extensions I made to olpc-power-manager, which now knows how to tell the kernel to suspend and change the video source.

[jg]

Cjb, you own the ball on behalf of OLPC; what are our options here?

[cjb]

Replying to jg:

Cjb, you own the ball on behalf of OLPC; what are our options here?

Richard sent me a copy of his OHM code yesterday, and I've been getting used to it. It's more complete than I expected -- it looks like a sensible option for us, unless we'd rather have something written in Python. (Which might be easier to hack on, but gives us the memory usage of another python process.)

[jg]

have to fish or cut bait. How's the fishing?

[cjb]

Replying to jg:

have to fish or cut bait. How's the fishing?

I tried out OHM today, and am very happy with what I saw -- it dimmed brightness with the AC adaptor going off and on, so it's talking to our setup fine. It doesn't have anything bound to lid/ebook events, though -- Richard, does that sound right?

Here's a list of things I think we need before we can ship it in Trial-2, for which the deadline is next Monday, so we'd need them by Friday:

• power button support -- we should suspend whenever the power button is pressed
• lid event -- we should suspend *and* set the dcon to "sleep" mode via sysfs on lid close
• ebook event -- we should xrandr -o left on ebook=1, xrandr -o normal on ebook=0
• we do *not* require any kind of idleness detection for Trial-2

jg, Kim, do you agree with these goals?

Richard (Hughes), could you let us know whether you'd be able to do these this week, or whether I should? Sounds like we have the infrastructure for them, which is great. HAL already broadcasts the lid and ebook events in the latest build, so that should be easy, but:

HAL doesn't currently see/broadcast the power button -- maybe that's because X uses the grab ioctl on the pm_inputdev device, which would mean we need to split out the power button into its own (correctly labeled) device like we did with lid and ebook. That's a simple kernel patch; if we need to do that, I can get it done quickly.

[hughsient@…]

Replying to cjb:

Replying to jg:

have to fish or cut bait. How's the fishing?

I tried out OHM today, and am very happy with what I saw

Flattery will get you everywhere :-)

-- it dimmed brightness with the AC adaptor going off and on, so it's talking to our setup fine. It doesn't have anything bound to lid/ebook events, though -- Richard, does that sound right?

Yes. All the framework is in place now, we just have to connect up the bits and bobs with policy.

Here's a list of things I think we need before we can ship it in Trial-2, for which the deadline is next Monday, so we'd need them by Friday:

Wow. Okay.

* power button support -- we should suspend whenever the power button is pressed

I'll do this today. I guess it's exposed in HAL as a button of type power.

* lid event -- we should suspend *and* set the dcon to "sleep" mode via sysfs on lid close

How to set dcon to sleep and suspend? What's the _exact_ commands on a B3?

* ebook event -- we should xrandr -o left on ebook=1, xrandr -o normal on ebook=0

What is the ebook event - a HAL button press or dbus api? Can we do the xranr stuff in c bindings rather than run a command - it would be much faster.

* we do *not* require any kind of idleness detection for Trial-2

Ahh sweet, that makes things simpler for now.

jg, Kim, do you agree with these goals? Richard (Hughes), could you let us know whether you'd be able to do these this week, or whether I should? Sounds like we have the infrastructure for them, which is great. HAL already broadcasts the lid and ebook events in the latest build, so that should be easy, but:

I'll do them today. Make sure you follow upstream git, I'll commit there.

HAL doesn't currently see/broadcast the power button -- maybe that's because X uses the grab ioctl on the pm_inputdev device, which would mean we need to split out the power button into its own (correctly labeled) device like we did with lid and ebook. That's a simple kernel patch; if we need to do that, I can get it done quickly.

Yup, it needs to be a separate device, ala ACPI.

I'll make this stuff priority one this morning.

Richard.

[cjb]

Hi Richard,

Replying to hughsient@gmail.com:

* power button support -- we should suspend whenever the power button is pressed

I'll do this today. I guess it's exposed in HAL as a button of type power.

(See below about us probably needing a kernel change here.)

* lid event -- we should suspend *and* set the dcon to "sleep" mode via sysfs on lid close

How to set dcon to sleep and suspend? What's the _exact_ commands on a B3?

DCON sleep is:

echo 1 > /sys/devices/platform/dcon # sleep
echo 0 > /sys/devices/platform/dcon # wake

And, CPU suspend is the usual:

echo mem > /sys/power/state

* ebook event -- we should xrandr -o left on ebook=1, xrandr -o normal on ebook=0

What is the ebook event - a HAL button press or dbus api?

Lid and ebook are already being broadcast by HAL as the appropriate signals: if you install the latest build and close/open lid and flip/unflip into ebook, lshal --monitor gives:

-bash-3.2# lshal --monitor

Start monitoring devicelist:
-------------------------------------------------
14:56:51.815: computer_logicaldev_input_0 property button.state.value = true
14:56:51.822: computer_logicaldev_input_0 condition ButtonPressed = lid
14:56:52.389: computer_logicaldev_input_0 property button.state.value = false
14:56:52.397: computer_logicaldev_input_0 condition ButtonPressed = lid
14:56:56.328: computer_logicaldev_input_1 property button.state.value = true
14:56:56.429: computer_logicaldev_input_1 condition ButtonPressed = tablet_mode
14:56:57.370: computer_logicaldev_input_1 property button.state.value = false
14:56:57.377: computer_logicaldev_input_1 condition ButtonPressed = tablet_mode

Can we do the xranr stuff in c bindings rather than run a command - it would be much faster.

That sounds fine, though I don't have sample code for doing it with the bindings, and would be happy with getting the exec going now and optimizing it later given our time constraints. Whichever you prefer.

HAL doesn't currently see/broadcast the power button -- maybe that's because X uses the grab ioctl on the pm_inputdev device, which would mean we need to split out the power button into its own (correctly labeled) device like we did with lid and ebook. That's a simple kernel patch; if we need to do that, I can get it done quickly.

Yup, it needs to be a separate device, ala ACPI.

Yeah, makes sense. I'll get a kernel RPM with the extra device for the lid switch ready for when you get in tomorrow.

I'll make this stuff priority one this morning.

You rock. :) Thanks so much!

[jg]

Dcon control gets done by X directly; all Ohm should do is set the right screen saver parameters.

[cjb]

Sorry, I meant:

echo 1 > /sys/devices/platform/dcon/sleep # sleep
echo 0 > /sys/devices/platform/dcon/sleep # wake

But it sounds like we should be using X. I think the X screensaver is broken right now, though -- see #1853.

[hughsient@…]

Replying to cjb:

And, CPU suspend is the usual: {{{ echo mem > /sys/power/state }}}

Surely we just want to issue Suspend() on HAL? The hal-system-power-suspend script can just have the pm-utils bits commented out.

Richard.

[cjb]

Replying to hughsient@gmail.com:

Surely we just want to issue Suspend() on HAL? The hal-system-power-suspend script can just have the pm-utils bits commented out.

My mistake. Yes, sounds good.

[jg]

Replying to cjb:

Sorry, I meant: {{{ echo 1 > /sys/devices/platform/dcon/sleep # sleep echo 0 > /sys/devices/platform/dcon/sleep # wake }}} But it sounds like we should be using X. I think the X screensaver is broken right now, though -- see #1853.

Yes, I'd like Andres to deal with this one as soon as he can. I need to sit down with him and go over his bug list and set priorities. He has problems with ajax's kernel patch...

[hughsient@…]

Okay, So far today:

* OHM suspends the system when you press the power button * OHM dims the screen on battery power * OHM dims further when momentarily idle * OHM sets a key that indicates we should turn off dcon (however we decide to do that) when the system has been idle for a long time * OHM allows a primitive inhibit key (needs a proper dbus api) * OHM allows you to tweak all the defaults as root and allows you to control what can be changed on the session * OHM reports the battery state to the session (percentage)

TODO:

* Report lid state correctly (99% there, just need to map udi's to values) * Do the xrandr callout or in compiled C. * Inhibit API for display and system. Need to discuss this on list first. * Port the accurate time remaining algorithm from g-p-m.

I'll do the first two TODO items this evening.

Richard,

[jg]

I don't understand this one... X will take care of handling the dcon; if the screen isn't being used, it can use the dcon to take over display to save power; if the screen saver is on for a while, the screen saver extension is able to tell the dcon to turn off the screen entirely after the timeout.

*OHM sets a key that indicates we should turn off dcon (however we decide to do that) when the system has been idle for a long time

Otherwise, sounds wonderful!

[hughsient@…]

Replying to jg:

I don't understand this one... X will take care of handling the dcon; if the screen isn't being used, it can use the dcon to take over display to save power; if the screen saver is on for a while, the screen saver extension is able to tell the dcon to turn off the screen entirely after the timeout.

Maybe I'm using the word dcon incorrectly. All I want to do is shut the screen off (as in black screen after a few minutes idle) - or do you just want to go to black and white mode?

And you _really_ don't want a screensaver from a power management point of view.

I assumed OHM would be the thing that turned the display off rather than a session based XScreenSaver type thing.

R.

[jg]

It is fine that OHM be the only object that is messing with the state of the screensaver.

Note that you can safely suspend, and rely on the DCON (via the X screen saver code) to turn off the screen at a later time for you automagically, without having to have the system woken up.

I was clever enough to ask for and get this magic DCON register when the chip was being designed.

[cjb]

Hi,

Jim was talking about the screensaver X extension, which hooks in to DPMS, not a screensaver client. We have X hooked up to shut down the video hardware after 20 mins idle, through DPMS, and this behavior is probably fine for Trial-2. So, I think we don't need any new behavior from OHM here,

Putting the dcon to sleep when the lid is closed is different, because X can't tell when the lid is closed; we need OHM to put the dcon to sleep completely when that happens.

[hughsient@…]

Status update:

* lid status reporting now works, and suspends the system. * xrandr works, but it the logic might be the wrong way round if you know what i mean

All code is in git.

Questions:

* when the lid closes, do i have to do dpms off or echo 1 > /sys/devices/platform/dcon/sleep, or both, or neither? * can we assume the lid is open and the machine is in normal mode when the xo is powered on?

[jg]

dpms force off; & sleep seem to be the right default policy.

when lid is open, the XO will be normally be running unless the user explicitly hits the power button momentarily, or (when we have idle going) the machine has detected idle and has suspended.

This reason for a suspend while open being easy is so a kid can leave the antennae adjusted for their friend's benefit and suspend the machine trivially; back on at the touch of a keyboard or mouse....

[cjb]

Replying to hughsient@gmail.com:

Status update: * lid status reporting now works, and suspends the system.

Great!

* xrandr works, but it the logic might be the wrong way round if you know what i mean

Sure, no problem.

All code is in git. Questions: * when the lid closes, do i have to do dpms off or echo 1 > /sys/devices/platform/dcon/sleep, or both, or neither?

Let's go with sysfs for now -- echo 1 on lid close, echo 0 on lid open.

* can we assume the lid is open and the machine is in normal mode when the xo is powered on?

The state will be set correctly by the kernel, so if the lid is closed between powering up and when ohm starts, ohm should notice that lid==closed when it starts, and do the DCON sleep then. It's the same for ebook mode -- when the kernel boots, it finds the current state of each sensor, and sets the input layer state accordingly. HAL then queries that state the first time through hald-addon-input, using an ioctl, so it gets it right. We haven't tested this recently, so let me know if it seems to misbehave at all.

Thanks very much once again, this is absolutely superb work.

[JordanCrouse]

Replying to cjb:

Replying to hughsient@gmail.com:

* when the lid closes, do i have to do dpms off or echo 1 > /sys/devices/platform/dcon/sleep, or both, or neither?

Let's go with sysfs for now -- echo 1 on lid close, echo 0 on lid open.

I vote the other direction - if you use DPMS, then at least you know X is on board with you - we might as well keep the states synced, if we can.

[cjb]

Replying to JordanCrouse:

I vote the other direction - if you use DPMS, then at least you know X is on board with you - we might as well keep the states synced, if we can.

Okay, fine with me. Richard, DPMS is broken in the build you have, so you won't be able to test this very well. I can/will test it, though.

[jg]

I've asked Andres to get the kernel patch in to fix the dpms working in ASAP.

[JordanCrouse]

Its a X patch, see #1853 - dcbw is testing it as we speak.

[hughsient@…]

Thanks very much once again, this is absolutely superb work.

You haven't tried debugging it yet :-)

Richard.

[cjb]

Replying to hughsient@gmail.com:

Thanks very much once again, this is absolutely superb work.

You haven't tried debugging it yet :-)

You might be right. :) GIT HEAD ohm's now in build499, which you could download and try out on a laptop. It doesn't seem to start automatically, and once started doesn't seem to be responding to the new events -- lsohm shows button.{lid,tablet,power} all at 0, regardless of the hardware state. I checked whether the lid/ebook events are going over lshal --monitor correctly; they are.

[hughsient@…]

it doesn't seem to start automatically

Nope, in the package it's turned off - fedora policy as it's not had a security audit.

doesn't seem to be responding to the new events

Can you post the lshal -m logs pls? I'll try it on my B3 when I get into the office tmw (in 7 hours time!)

[cjb]

Replying to hughsient@gmail.com:

it doesn't seem to start automatically

Nope, in the package it's turned off - fedora policy as it's not had a security audit.

Ah, okay.

doesn't seem to be responding to the new events

Can you post the lshal -m logs pls?

Think I already did: http://dev.laptop.org/ticket/31#comment:24 contains logs for lid and ebook. We *do* get a hal event for power, too, which is cool. No kernel change needed. It says computer_logicaldev_input condition buttonPressed = power.

I'll try it on my B3 when I get into the office tmw (in 7 hours time!)

Eek, go to sleep. ;-) Thanks!

[cjb]

Ah, something else: the idle plugin is switching brightness constantly, so something's up with that. I turned it off locally.

[hughsient@…]

Replying to cjb:

Ah, something else: the idle plugin is switching brightness constantly, so something's up with that. I turned it off locally.

The buttons are fixed in upstream commit fc92dc2fa086317c091ee34fd3cf836d13a3436c you'll also want b0fbca5136d391e191739331ef9381ba20786e20 if you are going to use xrandr. i.e. use the latest upstream master :-)

The brightness will dim after 5 seconds idle - is this what you mean? Is that too short?

[jg]

The brightness will dim after 5 seconds idle - is this what you mean? Is that too short?

Probably; we'll have to do some experiments/tuning of the knobs here soon, as soon as all our knobs are glued on in the right place; we may be in a state to do that tomorrow, if we're lucky.

[hughsient@…]

we'll have to do some experiments/tuning of the knobs here soon

Have a look in /etc/ohm/plugins/* -- if what you are trying to change is not configurable there then yell and I'll make it so.

Richard.

[jg]

I'll check. There are a knob or two for controlling how fast the system goes into dcon mode that will likely be needed.

Since randr 1.2 isn't quite soup, the knobs were to be hidden by ajax in the XFree86 misc extension. When we move to the next server, we'll be able to do that in a more sane way, and also there will finally be a way to control screen brightness from X at long last. But that won't be this month...

[cjb]

OHM's currently starting up and dying after five seconds because it can't open the X display.

[cjb]

The xrandr spawn doesn't work for the same reason; the root-running ohm doesn't have X access.

Should we be running this as user olpc? The specfile doesn't do that -- we'd want to not run it at startup, and do /usr/sbin/ohmd & in .xinitrc or something. Richard, is there anything in ohmd that depends on root access?

[cjb]

Our display is switching away to a VT on suspend; we don't want it do that, we want the dcon to keep showing the X image. I guess there's something in HAL that does VT switching on suspend, which is weird.

The VT change does not happen when I do "echo mem > /sys/power/state".

[cjb]

Running as a user doesn't work, we're not allowed to own org.freedesktop.ohm.

[hughsient@…]

Replying to cjb:

Running as a user doesn't work, we're not allowed to own org.freedesktop.ohm.

You can add the ohm user to the dbus conf file.

[cjb]

Replying to hughsient@gmail.com:

You can add the ohm user to the dbus conf file.

Okay, will do. Is that what we're supposed to do? Should we be running it as a user? Does it require root for anything?

[hughsient@…]

Replying to cjb:

Replying to hughsient@gmail.com:

You can add the ohm user to the dbus conf file.

Okay, will do. Is that what we're supposed to do? Should we be running it as a user? Does it require root for anything?

Not at the moment although I would prefer OHM to start early in initscripts rather than in X. Can't we just try to connect after a few seconds?

Richard.

[hughsient@…]

Replying to hughsient@gmail.com:

Can't we just try to connect after a few seconds?

Can you build git again please. I'm now polling until X starts.

Richard.

[cjb]

Replying to cjb:

Our display is switching away to a VT on suspend; we don't want it do that, we want the dcon to keep showing the X image. I guess there's something in HAL that does VT switching on suspend, which is weird.

Looks like HAL's suspend/resume path is the main reason it takes non-OLPC laptops so long to suspend/resume; it's full of shell scripts and VT changing and sleep statements. I think we should change our HAL call to the simple echo mem > /sys/power/state for now in OHM, and ask for a no-frills suspend in HAL for the future.

[jg]

Lots of X drivers break if you suspend out from under them.

So the bandaid has been to switch VT's first, getting the driver off the hardware.

But hopefully, more X drivers might work in the future, so this suggestion is in order.

[cjb]

Replying to hughsient@gmail.com:

* xrandr works, but it the logic might be the wrong way round if you know what i mean

Yeah, it is. :) Please invert.

[cjb]

Have just attached a patch:

* ohm-suspend-with-sysfs.patch: suspend using /sys/power/state, not HAL

I'd really like it if we could stick with OHM upstream rather than carrying our own patches. Richard, how do you feel about --with-distro=olpc or something?

[cjb]

I've disabled the idle plugin in our local config for now; it seems to be triggering once a second instead of however often it's supposed to. Run build511 on an XO to reproduce.

[dcbw]

both these patches are built into ohm-0.1.1-5.2.20070713git.olpc2 until better solutions can be worked out.

[cjb]

There's a patchset against upstream OHM here:

http://dev.laptop.org/~cjb/ohm-patches/

[hughsient@…]

Replying to cjb:

There's a patchset against upstream OHM here:

Quality. I've applied 1,3 & 4 upstream. I'm hesitant to apply 2. Do you still get the vt switch and slowness if you just put "echo mem > /sys/power/state" in /usr/lib/hal/scripts/hal-system-power-suspend and deleting _everything_ else?

[cjb]

Replying to hughsient@gmail.com:

Quality. I've applied 1,3 & 4 upstream.

Thanks! So, Marco, 2 is the one that was already in our RPM build; you can totally ignore the patches in the directory I linked to, as long as you keep the HAL suspend patch we already have.

I'm hesitant to apply 2. Do you still get the vt switch and slowness if you just put "echo mem > /sys/power/state" in /usr/lib/hal/scripts/hal-system-power-suspend and deleting _everything_ else?

Good question. The reason I haven't done this is that I want to avoid forking a chain of shells and unnecessary syscalls -- in our suspend and resume paths, every ms counts, since we want to suspend/resume "between keystrokes" without being noticed. I could be overestimating how much time we lose by running a few sh processes, though.

[cjb]

(Temporarily reassigning to Marco to run a new build with upstream GIT plus our single suspend patch -- please reassign back to Richard afterwards, thanks.)

[jg]

Replying to cjb:

Replying to hughsient@gmail.com:

Quality. I've applied 1,3 & 4 upstream.

Thanks! So, Marco, 2 is the one that was already in our RPM build; you can totally ignore the patches in the directory I linked to, as long as you keep the HAL suspend patch we already have.

I'm hesitant to apply 2. Do you still get the vt switch and slowness if you just put "echo mem > /sys/power/state" in /usr/lib/hal/scripts/hal-system-power-suspend and deleting _everything_ else?

Good question. The reason I haven't done this is that I want to avoid forking a chain of shells and unnecessary syscalls -- in our suspend and resume paths, every ms counts, since we want to suspend/resume "between keystrokes" without being noticed. I could be overestimating how much time we lose by running a few sh processes, though.

Nope. Shells, particularly bash, don't start all that fast.

[marco]

Rpm built, back to Richard

[jg]

Richard, does this work? Please test and let us know if we should put in the new RPM.

[cjb]

The RPM's already in our build. OHM is pretty much done for Trial-2. The only bug I've noticed is an occasional failure to resume the screen properly/come out of DPMS; I think it's related to the DCONLOAD failure I reported earlier.

[jg]

OK, from here on it may be policy tweaks needed; like timeouts, etc (or of course, new bugs).

[jg]

I'm closing this; please open specific bugs against ohm in the future.