Frequent Freeze On Restore From Suspend

[Alf]

I installed a Debian on my Zaurus C3000 as described here: http://www.eleves.ens.fr/home/leurent/zaurus.html.

I often have a total freeze when I restore my Zaurus from suspend. If i connect on it via ssh through usbnet from my laptop, I can see that actually, the system is still up. Xvnc is dead (no more process) and all the process that were connected to it (Fbvnc, windowmanager, terms, etc.) have been zombified. And as the sharp console is bugged, I get stuck with the last image of X on screen, with no possible action. I tried to have Xvnc up back through ssh using cru commands to escape from the chroot (as ssh is launched by the chrooted Debian), but I only could manage to have my system back by removing battery for a hard reboot :-(

I didn't find anything about this issue on the net, except this (maybe unrelated) :
http://wiki.debian.net/?PocketWorkstationXQT (bottom of page). It is about a problem of automating unmounting/mounting Cf cards on suspend, involving problem with unmounting /proc... I don't know if it is really the same problem (is the internal hard drive considered as an internal Cf card ?) but I am now going out Fbvnc and manually suspend my zaurus to avoid the freezes (seems to work up now...) and recover back my X session by launching a new Fbvnc.

Am I alone to have such a problem ?
Do you have any idea for fixing it ?

[Alf]

Update to this problem: quitting Fbvnc back to sharp console before suspend didn't  reallyu solved the problem, but avoid the hard reboot. I obtained once a segfault of Xvnc. But as I was in the console, there was no lock up, I had direct access to my Z. And then, each time I tried to launch Vncserver , I obtained a segfault. start to stop and relaunch the init.d/zdebian: segfault. I had to manually kill all chrooted process not yet dead to be able to relauch zdebian, and then Vncserver.

What's this #!% problem ? Why is Xvnc so unstable with suspend mode ? And why do I seem the only one with this problem ?

[Alf]

New update.

OK, my problem doesn't inspire many people... I just keep to develop my own investigation as it may help someone else.

So, as the problem seems to be the X vnc server, I checked it: it is an alienized package of xf4vnc. I don't know why shuch non-Debian package was chosen, as vncserver exists in the official repository. And I don't think it is very clean to use a non-properly packaged software for a critical app. So I installed vncserver instead, and it just seems to work identically (except the pointer cursor, which turned blue...).

Tell here later if it is more stable.

[himchen]

New update.

OK, my problem doesn't inspire many people... I just keep to develop my own investigation as it may help someone else.

So, as the problem seems to be the X vnc server, I checked it: it is an alienized package of xf4vnc. I don't know why shuch non-Debian package was chosen, as vncserver exists in the official repository. And I don't think it is very clean to use a non-properly packaged software for a critical app. So I installed vncserver instead, and it just seems to work identically (except the pointer cursor, which turned blue...).

Tell here later if it is more stable.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Have a look at the following pdaxrom topic and the solution, perhaps that applies to your case too:
[a href=\"https://www.oesf.org/forums/index.php?showtopic=10464]Input lockup on resume[/url]

[Alf]

Seems to work up to now... But AAARGH ! Do not forget to make a swap (and remember to activate it on startup !!! I am stupidely too lazy not to have add a line in fstab the first time I created it :-/ ) otherwise Xvnc may just die when you are short of memory (and thus be stuck in the same way).

If I don't add any news there, just mean that this solution (swap file + replace Xf4vnc by regular Debian vncserver) was a good and stable one.