Zaurus Ui Freezes If Suspended Too Long

[macwiz]

I have been getting this problem a lot with RC 9 - RC 10. I tried the apm edit, but it still froze. I reflashed my Z with RC 10 again since my last post, and this time reduced the size of the root partition to 80 Mb - it had been maxed out to 121 Mb. Since then no more freezes.

Don't know why this worked for me, but I am now sort of confident that the problem has gone away and won't just reappear to spite me after I write this.


I would be interested if anyone has any theories.

[jcabrer]

For your consideration:

Let us assume that you have set your screen to blank at 10 minutes and suspend at 30.
Let's also assume that there is some not so perfect behavior in the clock time keeping.

OK, so now you manually suspend because your Girl/Boy friend just showed up.  After 15 minutes you excuse your self to the rest room, and secretly try to power up your Z.  The screen comes on momentarily, even the light may come on, but it powers back off.

In frustration you go back outside for a while, and try again later. say an hour or so.  Still no luck?  RESET.  Then it works.

What's happening is that the suspen timers are not being reset when you power off.  They only reset when a screen tap or some keys are registered.  The result is that if your system wakes up and sees that its suspend timer has expired, it goes back into suspend thinking its been active the whole time.

The real solution to this problem is any fix that actually resets the suspend/screen blank timers when the system wakes up, or right before it suspends.

[takuan]

that makes sense
just click on the power settings and change both to suspend after 0 min (infinite)
then change screen applet to "disable suspend" (probably optional)
so now just manually suspend and you should stop getting problems when you come back....

now as for losing time i'm going to check out adding the sethwclock hack to apm..


(6000-L Kathrin rc10)

[web-angel]

Hi !
Does this topic resolve my problem :

Under Xfce4 I have had a button for the "apm -s" in order to stop the Z.
So it work's fine but when I put the Z on, Xfce4 in very very slow ... I need to quit to console and reload X

So does the Apm Hack resolve this problem ? If not what's a good way to suspend the Z under Xfce ?

[pgas]

inside X use " xset dpms force off" instead of apm -s

[web-angel]

Another thank's pgas ! It work's like a charm ! Thank's a lor for all your help

[gab74]

I try on my C3100 The first time it works....the second time..no...the gui freezes again......

[whit]

inside X use " xset dpms force off" instead of apm -s
[div align=\"right\"][a href=\"index.php?act=findpost&pid=104630\"][{POST_SNAPBACK}][/a][/div]

Nice. That works at least a few times on my 3100. Would there be a way to bind that to the action of the On/Off button under X (that is, does that button trigger a script)? Okay, at least some of the scripts are in /etc/apm, which is an init.d-like setup, and already includes something that's supposed to be handling the clocks, for instance.

Could it be a timing issue, where these scripts are stepping on each other's toes? It looks like all the little hacks with the hwclock elsewhere that work for some people are just repeating stuff that's already attempted here.

Okay, here's what I'm testing, and so far on short suspends (where were a real problem) it's working fine:

- go to /etc/apm and mv suspend.d suspend.d.back

- mkdir suspend.d

- cd scripts.d and cp template xset

- edit xset to add two lines to the suspend section like this:

suspend() {
  sync
  xset dpms force off
}

- cd ../suspend.d

- ln -s ../scripts.d/xset 100xset

The result of this is that instead of the four scripts that were invoked on suspend before, now all that's done is the storage is sync'd (perhaps not necessary, but a safety measure) and then of course dpms is forced off.

This is untested over longer periods. But it can be reversed merely by deleting or renaming the new suspend.d subdir and renaming the old one back to itself. I'll check back later if it proves dependable. In short periods it's working fine to turn it off with the On/Off button, and back on with either that or the Home button, and the clock seems okay. Sure beats having to yank the battery after every suspend.

[whit]

That worked overnight, except on resume it came up confusing EST with GMT - which must be an incompatibility with the resume scripts and having the hwclock in gmt rather than local? Anyway, much better to have it five hours ahead than four days behind. Pretty sure I can correct this back....

Next morning:

It jumped five hours ahead again when being awoken on a new day. Hmm. What's doing that? Something's making a wrong assumption about the localtime setup.

Ah

hwclock --utc
Off/On Off/On, and now it's got it right, with the hwclock set on Greenwich. I'll see if that lasts.

Later:

The real solution:

In /etc/apd/scripts.d/hwclock change line 20 from:

hwclock --httosys

to:

hwclock --utc --hctosys

This is reflecting that I have an /etc/localtime symlinked to the proper time zone file, and have set the hwclock to utc.

With that change it's keeping very good time - maybe a forward drift of about a minute over 24 hours - much better than I've gotten out of a pdaXrom Z before. The resumes are immaculate.

Note this solution is also in conjunction with the xset file in the note just above.