Are others seeing unsuspend lockups?

[whit]

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...?

[ChrisEBoy]

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.

[whit]

Thanks. I\'ll leave an xterm open for that.

[ChrisEBoy]

ooh I almost forgot, you have to do this every time you resume, it seems to forget.

[whit]

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.

[whit]

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 I\'ve tried doing \"xset +dpms\" before suspend, and it locks up for sure then (at least on a couple of tries) :?

[whit]

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.

[Reaper]

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.

[whit]

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):

Code: [Select]

#! /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.

[ChrisEBoy]

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.

[whit]

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....

[whit]

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.

[ChrisEBoy]

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.