OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: zaphod on February 15, 2005, 09:31:06 pm
-
I remember this problem in pdaxrom way back in july. Surely, someone has thought of a workaround or fix by now?
I have an SL-C750 and if it is left suspended for more than one day, the touchscreen and keyboard go dead on wakeup. I guess it isn't a problem with matchbox, since now pdax is using openbox. Strangely, sometimes the first tap or two after wakeup work and then no more. The ON/OFF button on the back of the zaurus still works, but suspend/resume does not get the touchscreen/keyboard working. Removing the battery is the only way to reboot the thing and them everything is fine. At least until I forget to use my Z for a day.
-
I have an SL-C750 and if it is left suspended for more than one day, the touchscreen and keyboard go dead on wakeup. ... The ON/OFF button on the back of the zaurus still works, but suspend/resume does not get the touchscreen/keyboard working.
Wow.. I thought I was the only one. *Exactly* the same behavior here on my C760. Odd.
-
I have an SL-C750 and if it is left suspended for more than one day, the touchscreen and keyboard go dead on wakeup. ... The ON/OFF button on the back of the zaurus still works, but suspend/resume does not get the touchscreen/keyboard working.
Wow.. I thought I was the only one. *Exactly* the same behavior here on my C760. Odd.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=67246\"][{POST_SNAPBACK}][/a][/div]
Same with me.. Had to hard reset it by removing the battery twice just today because of this problem. Running RC9.0, was this fixed in 9.1?
-
Have to reset my C750 occasionally because of this. Wasn't able to reproduce when it happens, but it could indeed have something to do with long-time-no-use. Well, that's one way to punish us for not using this beautifull piece of software the way it was meant to use... all the time
-
This would describe a similar problem that I'm having with the 860.
-
I have also this problem, do you use a wifi card?
If yes see this thread (https://www.oesf.org/forums/index.php?showtopic=10464)
for what seems to be a possible solution, I didn't try it though.
-
The hint behind that link may solve Wifi issues, but I have been hit with the problem without a wifi card in the slot. Maybe there are two separate issues here?
-
I had this problem with RC5 on my 860. Experimented with different window managers (fluxbox etc), and the problem went away while using them. When I flashed RC8 the problem went away totally so I did without the other window managers. Now I have flashed RC9, and the problem is back. Any ideas? I am tempted to go back to RC8.
-
I remember this problem in pdaxrom way back in july. Surely, someone has thought of a workaround or fix by now?
I have an SL-C750 and if it is left suspended for more than one day, the touchscreen and keyboard go dead on wakeup. I guess it isn't a problem with matchbox, since now pdax is using openbox. Strangely, sometimes the first tap or two after wakeup work and then no more. The ON/OFF button on the back of the zaurus still works, but suspend/resume does not get the touchscreen/keyboard working. Removing the battery is the only way to reboot the thing and them everything is fine. At least until I forget to use my Z for a day.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=67226\"][{POST_SNAPBACK}][/a][/div]
I also had this problem once. After a long period in suspended state, the
touchscreen and keyboard seemed to lock up.
I noticed that the Zaurus still seemed to be working in this state (new flash cards
were recognized). So I inserted my WIFI-Card and logged in to the Zaurus from
my Desktop-Computer via SSH. I killed and restarted the X Server (on the Z)
and everything was fine afterwards.
Of course this is not a good workaround but at least I didn't have to remove
the battery and risk data loss to get the Z working again...
-
Hi, just to point out to people that think it may be wifi related, there are at least 2 people that posted (including myself) that encountered the problem without a wifi card. I changed my windowmanager to ratpoison and haven't noticed any problems yet. I find myself just staying out of X all together a lot more lately though.
-
My C860 was off since Friday, I just turned it on and no problems. RC9
I have had this problem before, but I don't think it has to do with how long the device is suspended. Maybe what it was doing when it was suspended?
-
it happens to me sometimes, on my 750.
Just for information, it also happens when you suspend the Z while you don't use X (using the command "apm -s") and leave it for some days. When you turn it back on, it automatically close the session and you have to log in again.
Hope it means something to you...
Ho, by the way, i have no wifi card...
-
I thought it was an X11 thing.
# ssh root@z kill -9 Xwould salvage the mess, otherwise i did the old battery pull.
It happens to me so consistently for a suspend of any duration that now I always kill X beforehand.
-
Ho, by the way, i have no wifi card...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=68144\"][{POST_SNAPBACK}][/a][/div]
do you have any type of CF card inserted in the CF slot? or no CF card is inserted at all when the resume lockup occurs?
-
Wasn't there going to be a developer bare bones image released sometime soon? I personally would love to scrap openbox/matchbox all together and put my energy into ratpoison, which is, to me, the best wm for such a small device if you need to get things done.
Laze: any news on that bare bones image?
Wario: I usually freeze up a hundred miles from my home computer. I travel a lot so its always the battery pull. Being that I have a pdaair case that snaps on the bottom, its a real pain in the ass.
-
dvdrw : i always have a cf card in the slot, and a sd card, too.
-
@projekt : this is a bit HS to this thread, but even now you can scrap all the things you want, (even X if you want) all it takes is to remove the packages.
-
dvdrw : i always have a cf card in the slot, and a sd card, too.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=68260\"][{POST_SNAPBACK}][/a][/div]
I modified the apm script to stop PCMCIA services (cardmgr) after eject and before the $APM --suspend, and to restart PCMCIA services on resume (sprinkled some "sleep 1"s throughout as well). seems to help (no more hangs for me) but this could just be luck/timing. browsing all the OESF forums for "resume" shows that there seems to be some core kernel/driver issue that might be beyond our control. e.g., it could be some issue with SD resume as opposed to CF resume, or perhaps none of these at all if it is X (or the WM?) that is crashing. haven't had any time to explore any of this deeper...
if it is just X crashing, another idea might be to have the apm script grep `ps` output to determine if X has crashed on resume, and if it has, kill anything remaining and to auto-restart X. I haven't spent the time trying to repro the resume crash to try this but next time it happens I'll hopefully have time to look into this.
-
pgas: yeah, but I am a bit obsessive compulsive. i guess its because i use my main computer so much, i hate having too much uninstalled software, i frequently ghost back to ideal states. Bah.
dvdrw: actually, its not just X i've found. I've been running just the startup shell without x and a few virtual terminals. sometimes when i come back links and vim have both frozen. bummer.
-
Sorry for coming back to an old post, but i noticed today that my Zaurus only freezes when i set the backlight to very different levels when the Z is pluged in and when it is not.
If i set the light to maximum when the zaurus is plugged and to minimum when it runs on battery, suspend when plugged, then unplug it and then have the zaurus back on, the Z freezes nearly every time.
Don't know if it is revelant, but i think so...
-
for some time, I've been using a test hacked version of /usr/bin/apm to see if this eliminates the problem, and it's been working well:
#!/bin/sh
#
# X11 ROM apm wrapper
# http://www.pdaXrom.org
#
APM=/usr/bin/apm.x
if [ "$1" = "--suspend" -o "$1" = "-s" -o "$1" = "--su" ]; then
cardctl eject 2>/dev/null
sleep 1
/etc/rc.d/init.d/pcmcia stop
sleep 1
$APM --suspend
sleep 1
/etc/rc.d/init.d/pcmcia start
else
$APM $@
fi
note that this test hacked version always does a cardctl eject and PCMCIA stop/start (I removed the check for card present in case that didn't always work). this seems to fix the problem for me (C750 w/CF wi-fi card and SD flash). however if the problem occurs without a CF card installed, then it could very well be SD automount/dismount, or something else. if I get some time, I'll put back the original apm script and look at the SD stuff.
-
Thanks for this hack! I've been using it for a while & have had zero lock ups. I was having several per week.
-
Sorry for coming back to an old post, but i noticed today that my Zaurus only freezes when i set the backlight to very different levels when the Z is pluged in and when it is not.
If i set the light to maximum when the zaurus is plugged and to minimum when it runs on battery, suspend when plugged, then unplug it and then have the zaurus back on, the Z freezes nearly every time.
Don't know if it is revelant, but i think so...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=69800\"][{POST_SNAPBACK}][/a][/div]
I have changed my backlight settings to be the same on mains or battery and have had no lockups since. Coincidence? Maybe.
-
Thanks for this hack! I've been using it for a while & have had zero lock ups. I was having several per week.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=71790\"][{POST_SNAPBACK}][/a][/div]
very cool! I haven't had any lockups as well since I've been using it. it'd be interesting to find out if anyone else has had any luck with this hack...!
-
Thanks for this hack! I've been using it for a while & have had zero lock ups. I was having several per week.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=71790\"][{POST_SNAPBACK}][/a][/div]
very cool! I haven't had any lockups as well since I've been using it. it'd be interesting to find out if anyone else has had any luck with this hack...!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=71890\"][{POST_SNAPBACK}][/a][/div]
I've also noted in another thread that my clock has also kept better time since using this. Not sure if it's related. Anyone else noticed less clock slippage?
-
I'm now also trying this hack (i was too lazy to try it before...) and I have now also remove all the "sleep 1" and so far so good...
-
I also edited apm as per the instructions above and haven't had any
suspend-related problems since.
However, I still get UI lockups after a long period (like half an hour
or so) of xmms music playback.
-
it happens to me sometimes, on my 750.
Just for information, it also happens when you suspend the Z while you don't use X (using the command "apm -s") and leave it for some days. When you turn it back on, it automatically close the session and you have to log in again.
Hope it means something to you...
Ho, by the way, i have no wifi card...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=68144\"][{POST_SNAPBACK}][/a][/div]
Why does everyone jump straight to -9?
DO NOT USE -9 AS YOUR FIRST KILL SIGNAL.
Try a nice friendly -HUP ... perhaps a little stronger -TERM.
If, for some reason, these don't work, knock a little louder with -KILL (ie: -9), but
don't whine if something else gets hosed due to the strong signal (not to scare
anyone, it's unlikely that anything critical is happening anyway, any more than
just writing a file-- but you could leave resources locked/in use (ie: memory, etc)).
Also, use -HUP and -TERM and -KILL .... you'll be thankful when you miss your
kill -1 and do a kill 1 instead ... you'll use -HUP from then on (well, maybe not on
a pda, but on a production server etc.)
Scott
-
I'm now also trying this hack (i was too lazy to try it before...) and I have now also remove all the "sleep 1" and so far so good...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=72526\"][{POST_SNAPBACK}][/a][/div]
I have tried it too, but not so fortunate... still getting lock-ups. I am not a techie, and confess that I am just typing the hack in without any real understanding of what it does (will check again to see if I typed/pasted it right). But what difference does removing the "sleep 1" do? And has anyone made any further modifications?
This fault is really beginning to bug me.
Thanks
-
Hi,
I have had this problem occasionally with pdaXrom but am now running RC10 and have had it a lot over the last couple of days. I tried the 'sleep 1' fix above but it didn't seem to help me. I did however notice that the clock was way out of sync when I resumed by Zaurus even though I had just seen ntpdate set it correctly after I booted up. So I looked in /usr/bin/datentime.py for the commands to set the hardware clock and added them to the stock /usr/bin/apm.
#!/bin/sh
#
# X11 ROM apm wrapper
# http://www.pdaXrom.org
#
pre_suspend() {
# test -e /etc/rc.d/init.d/pcmcia && /etc/rc.d/init.d/pcmcia stop >/dev/null 2>/dev/null
cardctl eject
rmmod -a
rmmod -a
echo -n Suspending ...
}
post_suspend() {
# test -e /etc/rc.d/init.d/pcmcia && /etc/rc.d/init.d/pcmcia start >/dev/null 2>/dev/null
# sleep 1
cardctl insert > /dev/null 2>&1
echo ... Resumed
}
APM=/usr/bin/apm.x
if [ "$1" = "--suspend" -o "$1" = "-s" -o "$1" = "--su" ]; then
pre_suspend
/usr/bin/sethwclock
/sbin/sltime -set
$APM --suspend
post_suspend
else
$APM $@
fi
That is the standard /usr/bin/apm with only the lines '/usr/bin/sethwclock' and '/sbin/sltime -set' added by me.
This has fixed my problem so far and I hope it helps other people.
Cheers,
Matt
-
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.
-
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.
-
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)
-
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 ?
-
inside X use " xset dpms force off" instead of apm -s
-
Another thank's pgas ! It work's like a charm ! Thank's a lor for all your help
-
I try on my C3100 The first time it works....the second time..no...the gui freezes again......
-
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.
-
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.