Okay, Sharp did me no favor in moving the 3100's power switch to the front, where I'm often hitting it while simply handling it.

If I hit it when X is open, I can't get X back on without pulling the battery. Turning it on with the power button brings up the screen for a second, and then apparently triggers X somehow to shut back down again.

This must be a known bug? I haven't found discussion yet, but the search function here seems a bit lacking. Is there some setting to change in X to disable whatever "helpful" thing it's trying to do by shutting down?

That's a bummer. I've done it a few times myself.



Sounds like you're hitting the "time jump" problem. If that's the case you need to set the system time properly. Search this forum for "hwclock", or "setting clock" or something along those lines should put you on the right track.

-- cheers

Hmm. Coincidently I did also find some of those instructions and used hwclock to set both the clocks today. But I must have not found the definitive fix, because I just tested the 3100's On/Off switch and it puts me in exactly the same position. And sure enough after I pull the battery and restart it reverts to three days ago (which it was doing before the fix, too.)

Kind of disappointing that pdaX hasn't even solved the clock problem in the year since I've loaded a new version. I'd just gotten used to the 860 not keeping meaningful time; but it wasn't causing me to have to pull the freaking battery just to get back to work. The 3100 boots a lot faster, which is good. Still ....

So there's a version of modifying the clock routines that works? Since there's at least one documented here that doesn't, any pointers will be welcome. Lacking that, what is the function that's consulting the time and deciding to shut down the system? How do I decapitate that? I'd already told X not to suspend or blank the screen while the unit's connected to the wall wart, but that doesn't prevent this.

I don't know which fix you used but the one here works for me:

http://www.oesf.org/forums/index.php?act=P...518&qpid=106512


-- cheers

Thanks, but when I click on that it puts me in a new window editing what my previous response.

do you run X as root or as a normal user?

I have this problem when I run X as a normal user it seems it has something to do with writing something (1 or 0) in /proc/power_key_off that a normal user can't do. But I'm not 100% sure about this.

I have the same problem, but it's easy to avoid it:

When you push the power button to suspend (or use the menu in X), just make sure you wait long enough before you resume. (about 15 seconds ?). I don't know exactly how long it is you really have to wait, but it solves the problem for me.

I think that when the screen goes blank, the Z is still busy "suspending" for a few seconds after that. If you try to resume during this suspending procedure, X freezes.

I also pushed the power button by mistake a few times, then I'm tempted to continue immediatly and X freezes. I've learned not to push the button too soon by now.

Chero.

when you push the power button, the backlight is turned off immediately. you can still see the windows/desktop under bright light and perfectly see when the Z really turns off. only after it completely turned off you can savely switch it on again.

regards, ph

Don't use hwclock. It doesn't do anything on the SL series.

Use 'sltime -set' to set the hardware clock (or really its closest equivalent) to the current time.

I can't speak for the 3100 feed, but the 860 feed actually calls sltime -set on every suspend AND resume.

- Bundabrg

Nah. Too many years as a sysadmin. I run as root everywhere I go.

hwclock does all the normal things on a 3100.

What seems to be a fix (so far, fingers crossed) I've posted at http://www.oesf.org/forums/index.php?showt...30&#entry106570 - towards the end.