OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: whit on June 18, 2004, 11:12:44 am
-
About half the time after having the 860 in suspend waking it up doesn\'t fully work - screen comes up and cursur goes to stylus, but nothing responds - a batter-removal reboot is required. Doesn\'t seem to matter whether I\'ve left anything open on the desktop or not.
Is this a known, common 1.0.5 pdaXrom problem, or my particular hardware, or...?
-
its known, there are a few threads/comments made by me over it. Try doing xset +dpms from xterm. This resolves it 99.9% of the time. The other 0.01% I think I forgot, but of course I\'ve no way of checking :-). If you can get remote access you can kill the xserver and it will recover. It\'s a bug somewhere in the X server. The same thing happens when changing virtual terminals.
-
Thanks. I\'ll leave an xterm open for that.
-
ooh I almost forgot, you have to do this every time you resume, it seems to forget.
-
Hmm. Does resume have a script attached to it this could be added to? I seem to recall something in the FAQ mentioning scripts that are called on suspend and resume - but not sure it applies to this ROM.
Later: There\'s a suspend-resume package for some of the other ROMs - might work here but I don\'t want to chance it breaking stuff. Would be good to have in the next pdaXrom version though.
-
ooh I almost forgot, you have to do this every time you resume, it seems to forget.
Just how are you doing this? I just suspended (from the menu) and found it frozen on resume (after just a moment), and I can\'t enter anything in the aterm I left open (because it\'s nonresponsive like the rest of the screen), and although I can ssh in I can\'t use xset there (xset: unable to open display \"\" - something more I have to configure in ssh to get the remote X display working?). Invoking \"aterm\" from ssh will open a new aterm on the Z\'s screen, but can\'t type in that either.
On a fresh start \"xset q\" shows that \"DPMS is Enabled\", for what little that\'s worth. And xset +dpms before reset doesn\'t change any of the values that \"xset q\" displays.
Looking at your post at http://www.zaurususergroup.com/index.php?n...light=xset+dpms (https://www.oesf.org/forums/index.php?showtopic=2423&highlight=xset+dpms) I\'ve tried doing \"xset +dpms\" before suspend, and it locks up for sure then (at least on a couple of tries) :?
-
Think I\'ve found the problem. Have an SMC wifi card plugged in. If I do a \"cardctl eject\" before suspending then the system comes back up right (after a pause where it\'s setting up the card again as it awakens). Otherwise - freeze.
Is the Suspend action hard coded, or is there someplace where I can insert \"cardctl eject\" as an automatic action before suspending? I\'ve looked around, but none of the text files obviously associate with openbox have this evident.
-
Strange enough about these cards... I have GPRS modem, and with it installed and suspended (automatically or by cardctl suspend) my Z became to hang up very often after suspend and wakeup (approx. 75% of all cases). Earlier it didn\'t behave in such a way. Looking forward to see a new release of pdaX.
-
Thanks for the report. Yeah, even the cardctl eject didn\'t work for me this last time - with a suspend of a few hours rather than the few minutes I was testing with before. Maybe physically yanking the card is also necessary - although I don\'t like testing the physical longevity of the plug any more than I like testing how many times the back cover and battery can be removed before trouble - and most always want wifi running anyhow.
Is the new pdaX going to use a newer kernel? On other systems going to a current kernel has often served me well in terms of fixing stability problems, whatever they\'ve been.
Later: Damn it\'s not enough to even both eject and remove the card. Is there any utility to suspend the system after exiting X? If I\'m by other equipment I can ssh in and enter \"reboot\" so I don\'t have to yank stuff, but it would be better to suspend from the prompt - easy enough to exit and enter X.
Later yet: Looks like \"more /proc/sys/pm/suspend\" is enough to suspend the Z. Just found that by accident though - doing anything to that file seems to trigger suspending. It\'s also enough for it to totally lose track of the right time.
An later: This simple script seems to suspend well from the prompt after exiting X, and also keep the clock right (in short-term testing anyhow):
#! /bin/bash
hwclock --systohc
more /proc/sys/pm/suspend
hwclock --hctosys
It also, perversely, freezes it up as good as the normal way when used on my Z from within X - but so be it it\'s better than jerking the back off.
Hmm, top shows that X is eating up about 98% of CPU resources while it\'s frozen. So X must be off in a loop with something while its trying to wake up.
-
there were suspend problems mentioned in other threads with certain cards. I have the problem without having cards in (and sometimes with my 4gb microdrive and SD card combination). The way I dealt with it was, when X starts enter xset +dpms on the cli. Then at next resume do the same as the first activity. I\'ve taken to doing it just before I suspend if I\'m running lot\'s of things.
I looked at automated scripts, but they don\'t seem to work to well, and definitely not well enough to used in a release. But I did try to do this via chvt , and that always reproduced the problem, you wouldn\'t even have valid windows shown.
-
Just a note: that script to suspend from outside X preserves the time perfectly (or within a few seconds).
Also, of course, joe, hnb and mc work just fine outside of X - so when I\'m not going on the Web sometimes I don\'t go into X at all. Now if only this thing booted with a few spare ttys, so I could multitask without X....
-
Then at next resume do the same as the first activity.
My problem is that more often than not I don\'t even get a first activity - even with the card out - since that 98% of CPU that X is going loopy with is enough to keep anything from being entered on the desktop - although if I waited 5 or 10 minutes something might happen I suppose.
-
yes I realise it\'s not much use as a fix, if it\'s already broke ;-). You can create new vt\'s and change them ok when X isn\'t running. The problem is always when X is running for tty changing.