Suspend - kapm - can it be disabled?

[whit]

I know this should be fixed with the new release, but meanwhile is there a way to totally disable automatic power management? Got the Z on the power adaptor with an app open that I'd like to get back to, but apm put the damn thing in suspend, so now the clock's totally off on re-awakening, and top shows that kapm-idled has 96.1% of cpu - which means the thing is totally nonresponsive locally - can only be accessed from another system by ssh.

Where's the setting to tell the Z never to suspend except when that's invoked manually? I've tried setting the value to 0 in the utility, but that doesn't accomplish this.

Alternately, is there something like KDE's runaway process catcher utility that will stop kadm from ever seizing all the cpu resources? Maybe this wouldn't work because there seems to be no way to kill kapm anyhow....

added later: There's an interesting doc at http://people.ac.upc.es/mpericas/zaurus_project-final.pdf on Zaurus power management - not sure if it applies yet since it's based on the 5500.

[lardman]

Take a look here: https://www.oesf.org/forums/inde...&hl=kapm\*

I don't think kapm-idled is a problem, to disable power management you need to use the dpms commands:

https://www.oesf.org/forums/inde...ic=2022&hl=dpms

etc.......

Si

[whit]

I don't think kapm-idled is a problem, to disable power management you need to use the dpms commands:

Thanks, I'll look.

From the doc I linked, kapm-idled is the process the kernel runs while the Z is suspended. But even after a reboot I see it listed by top as taking up, now, 98.4% of CPU, without the unit being suspended after reboot. So maybe the top readout on this is inaccurate?

[whit]

Take a look here: https://www.oesf.org/forums/inde...&hl=kapm\*

https://www.oesf.org/forums/inde...ic=2022&hl=dpms

Si,

Um, you did notice that neither of the references you gave report any success at getting control over this? That the second specifically reports failure? Since the freeze-up on waking is a bug the team has been working on, does someone have a more thorough analysis of the control mechanisms?

It does seem that the suspend mechanism is only active when X is running, and the second reference you gave mentions using "xset dpms" to try (unsuccessfully) to get control of the values used. From xset's own help screen, it looks like "xset -dpms" should work. Hmm.... Will try and report back.

Thanks,
Whit

[whit]

Okay, here's what I've learned:

"xset dpms x x x" will set the values for Standby, Suspend and Off - and also set dpms on when executed, so "xset dpms 1 1 1" will suspend the system after one second.

It's possible to do

"xset dpms 1 1 1; sleep 2; xset -dpms"

which will suspend the system after one second, then when you reactivate it turn dpms off. The clock still comes up wrong when it wakes up. Wonder if this manual method of suspending will make X any less likely to freeze on awakening?

Later: It still freezes on awakening some of the time. So suspending from X (or awakening) remains problematic. But "xset -dpms" at least stops X from invoking dpms. Hassle having to suspend after exiting X ("more /proc/sys/pm/suspend" will do that), since can't leave anything open of course on the desktop.

[whit]

Another note: The "Light & Power" utility automatically turns dpms on when accessed - even if the "Apply" button is never pressed.

Hope this behavior is fixed on the new ROM. Checking the light setting, for instance, or the dpms timing settings, for that matter, shouldn't set dpms to on if it's currently off.

[Laze]

A quick note:

All of the above is fixed in the next release :-)

[whit]

All of the above is fixed in the next release :-)

Wonderful!

Anyone happen to know relative power consumption for the Standby, Suspend and Off modes? What I've been calling "suspend" is really Off. Both Standby and Suspend, when set (e.g. "xset dpms 60 300 0"), will blank the screen after the set number of seconds, and I assume step the processor way back. Any action then brings the system right back up - and so far without crashes. But how fast, in Suspend (as compared to Off) mode, will it drain the battery?

[lardman]

Hmm, sorry if it's not linked above, but I'm pretty sure I was able to stop my Z from suspending by disabling DPMS completely. This is not mentioned in the links above, I was just pointing to some quick examples, sorry I should have made myself clearer.

I'll have a dig around if you're still having troubles and see if I can remember what I was using but it was probably 'xset -dpms'. I never had suspend troubles, what machine are you using (I've got a 750)? I'm also not sure that it's the clock which is wrong, but rather the matchbox clock applet which doesn't bother to update itself (again this was all a long time ago so I may well be completely wrong).

Hassle having to suspend after exiting X ("more /proc/sys/pm/suspend" will do that), since can't leave anything open of course on the desktop.

Does that work? With GPE (on my 5500, X11 on top of OZ) if I do that it switches off, but will only come back on for about a second than switches off again - not ideal ;-).


Si

[Mickeyl]

What are you expecting to achieve with disabling apm?

Btw., regarding /proc/sys/pm/suspend: 'more' is wrong, 'echo >' is the correct command.

[whit]

I'll have a dig around if you're still having troubles and see if I can remember what I was using but it was probably 'xset -dpms'. I never had suspend troubles, what machine are you using (I've got a 750)?

860. Using apm's true "Suspend" mode (rather than what the Z calls suspend, which is "Off" as far as the kernel apm code is concerned) has worked fine overnight, but I don't know at what additional power drain (since I left it plugged in). An additional "cardctl suspend" is needed to shut down the wifi in this case. It does have the advantage of being able to leave a terminal open to the Z on another machine, since it's not seen as a dead connection the way it is when the Z is "off" (if the wifi is left on, of course).

I'm also not sure that it's the clock which is wrong, but rather the matchbox clock applet which doesn't bother to update itself (again this was all a long time ago so I may well be completely wrong).

The clock itself is wrong (although the matchbox clock can lag after adjusting it), which may be related to hwclock working sometimes but not others. From outside X, if I invoke this script

Code: [Select]

#! /bin/bash

hwclock --systohc
more /proc/sys/pm/suspend
hwclock --hctosys
when it works at all it saves the system clock to the hardware clock, then suspends, then when I bring the system back up sets the system clock from the hardware clock. But a fair amount of the time that first hwclock command just hangs, in which case it comes back up with a retarded time. This seems to be a known issue that I gather will be fixed in the next ROM.

Hassle having to suspend after exiting X ("more /proc/sys/pm/suspend" will do that), since can't leave anything open of course on the desktop.

Does that work? With GPE (on my 5500, X11 on top of OZ) if I do that it switches off, but will only come back on for about a second than switches off again - not ideal ;-).

Works fine for me, although once in a while it does come up and manage to re-enter that command, so has to be brought up a second time. This is from outside X though. The variant of "echo 1 > /proc/sys/pm/suspend" does the same thing - anything that touches that file suspends the system.

[whit]

What are you expecting to achieve with disabling apm?

I'm a writer. I'm carrying the Z with me and using it to take notes in hnb. Because of control of font and key bindings I prefer to use hnb in X. If I let apm take the Z to Off mode (miscalled suspend) while X is up it will as often as not freeze up on resume - with or without my wifi card involved. And when it doesn't freeze, the clock is wrong - and resetting the clock with ntpdate also can freeze X, so might as well be outside of X already since I like to have the right time on files. (Note there are many reports of apm having trouble with xfree on a variety of platforms if you google for 'em.) So I've been exiting X and running the script in my previous post to suspend (except when hwclock won't work, in which case I hit that "suspend" file directly to trigger suspension).

Now, "xset dpms 60 300 0" for instance sets the system to "Standby" (monitor off) after 60 seconds, "Suspend" (not sure of extent of slowdown/shutdown) after 5 minutes, and "Off" (what's miscalled "suspend" in Z-land) never - and allows me to leave X running and applications open in it. But what I don't know yet is how fast that will run the battery down as compared to being in the "Off" sort of suspension - certainly the wifi needs to be separately suspended or else at least its light stays on, and I assume if this is working right the CPU should be way stepped down, but is still running, if slowly, rather than being off as I take it the Off mode would have it.

All this may be moot with the new ROM.