Can Someone Tell Me About Standby?

[Murff]

Sorry, yes, from a cold boot.

 

[mali]

Regarding boot up time, on mine, from the moment I turn it on to the moment I've got a usable xfce desktop, there's exactly 50 seconds.

That's valuable info

Btw, WarmFluffyUK pinned a feedback thread and it would be great if you lucky few would post your impressions there
http://www.gp32x.de/board/index.php?/topic/53684-pandora-feedback/

 

[skeezix]

The cold boot up time can be improved as well, its doing a few things that lots of people may not need, so we may configure them out. I think ED got it down to 30s, and wasn't done tweaking, but we didn't want to risk breaking the firmware near the end

(minimenu will come up faster than xfce as well)

"Hibernate" does not currently work (and not Pandora limited, pretty much most devices have the same issues.) Many of the drivers needed don't have working hibernate code (and yes, one option we tried was unloading those drivers before hibernating, but some drivers didnt' want to unload cleanly either.) We figured hibernate is less used in handhelds (ie: PDAs, phones, iphone, etc, do not have hibernate at all. Its either standby-off or hard-off.)

It could be fixed, but people will need to get knee deep into driver hackng to make it work

jeff

 

[benced]

Is there a hibernate feature or when the battery runs out to you have to reboot from startup?

If not is there a chance of having this feature in the future?

just noticed Na-Noo already asked this and then skeezix posted a reply just before I posted, kthanx

 

[WizardStan]

Is there a hibernate feature or when the battery runs out to you have to reboot from startup?

If not is there a chance of having this feature in the future?

As Skeezix just said right above you, hibernate has some issues with the drivers. To hibernate, it requires that all drivers be able to unload themselves to disk and then be able to reload right back to their same state again. So long as there's one driver that doesn't do this properly, the whole thing risks falling apart. The good news is that all but the graphics driver (if I recall correctly) are open source, so as long as the graphics driver does the right thing, everything else can eventually be fixed, it'll just take more time and effort. A lot of effort, looking at some of them.

 

[juniorm33]

Yea, I had actually forgotten what the issues was for hibernate.
But having a good standby is more of a priority, when battery starts to get low we can go into standby.
Wonder how low battery can be, to last on standby for a day?

 

[j.pickens]

So usually the power button is managed by pndevmapperd, which has a conf file at /etc/pandora/conf/eventmap if I recall right, and that maps the power button to a sh-script; you can switch or alter that sh-script, or change the eventmap conf to refer to somewhere else. Now, since I made the system way too configurable, you can actually drop the eventmap conf on your SD instead of editing the one in-place in NAND -- ie: so that settings can take place from SD, and if you blow it up, you can just eject the SD to get the factory defaults back. (Or you can reflash if you totalyl bugger it up

jeff

This is exactly the sort of geek-fu that the Pandora makes available.
This is exactly why I ordered this thing, and have waited patiently all this time.
There is simply no other portable device with this kind of open environment.
As Monty Burns says, EExxcelent....

 

[WizardStan]

Wonder how low battery can be, to last on standby for a day?

As I recall from the one post someone (I think it was MWeston, but I could be mistaken) made about it, it was about 10 times as long on standby. So a battery with 5 hours remaining while running would get about 50 hours in standby. More or less.

 

[Pleng]

OK so here's a bizzare little 'feature'

You suspend the system, and shut the lid. If you open the lid again to the locking point the screen comes back on, but the unit doesn't come out of suspend mode, so it's still running at v low mhz. To the untrained eye it appears that the machine as crashed. To take the Pandora out of suspend you still need to flip the power switch to the right to bring it out of suspend, which takes a few seconds - but there's no indication that this process is beginning, or has finished.

 

[God Ginrai]

Ok, I understand why we don't have hibernate. (suspend to disk) But this type of standby doesn't exactly sound like suspend to RAM, so why don't we have suspend to RAM? Correct me if I'm wrong on this.

-God Ginrai

 

[mali]

^ It has something todo with having to properly stop/start drivers to make it work correctly, which is not easy, IIRC.

 

[WizardStan]

Ok, I understand why we don't have hibernate. (suspend to disk) But this type of standby doesn't exactly sound like suspend to RAM, so why don't we have suspend to RAM? Correct me if I'm wrong on this.

Suspend to ram has the same limitation as suspend to disk: the drivers need to properly shut down and be able to restore themselves. With suspend to ram, the CPU is shut off, but everything remains in RAM with the idea being that all you need to do is turn the CPU back on and then tell the drivers to restore themselves. Since it's all in RAM, this happens very fast. With suspend to disk, it has to copy the contents of RAM to disk first, and then restore it when you turn back on. The only thing the Pandora isn't really doing that is done in most laptops with a suspend to ram is turning off the CPU completely; in our case it's just being turned down very very slow. We can't turn off the CPU completely because then the drivers would effectively "freeze" which causes undefined behaviour in them.

 

[God Ginrai]

Ok, I understand why we don't have hibernate. (suspend to disk) But this type of standby doesn't exactly sound like suspend to RAM, so why don't we have suspend to RAM? Correct me if I'm wrong on this.

Suspend to ram has the same limitation as suspend to disk: the drivers need to properly shut down and be able to restore themselves. With suspend to ram, the CPU is shut off, but everything remains in RAM with the idea being that all you need to do is turn the CPU back on and then tell the drivers to restore themselves. Since it's all in RAM, this happens very fast. With suspend to disk, it has to copy the contents of RAM to disk first, and then restore it when you turn back on. The only thing the Pandora isn't really doing that is done in most laptops with a suspend to ram is turning off the CPU completely; in our case it's just being turned down very very slow. We can't turn off the CPU completely because then the drivers would effectively "freeze" which causes undefined behaviour in them.

Ok, thanks.

-God Ginrai

 

[BackAssward]

Interestingly, programs like VM ware can 'pause' an OS and restore it at will, regardless of which OS/Drivers are in question. I mean, why is it not possible to 'stop' everything in it current state, pause it, etc. As long as nothing external to the OS changes, it should be able to be stopped in a 'cryo-state' and restored at will, no? Why do drivers even have to be told that this is going on? So long as the drivers can react dynamically to things (say wifi was there now isn't) without crashing, why is suspend or hybernation so difficult?

I mean, the drivers don't have to be told to stop, just remove all CPU cycles from them and freeze them / their memory space as is, and save it. Why do they even have to know what is going on?

 

[God Ginrai]

Interestingly, programs line VM ware can 'pause' an OS and restore it at will, regardless of which OS/Drivers are in question. I mean, why is it not possibly to 'stop' everything in it current state, pause it, etc. As long as nothing external to the OS changes, it should be able to be stopped in a 'cryo-state' and restored at will, no? Why do drivers even have to be told that this is going on? So long as the drivers can react dynamically to things (say wifi was there now isn't) without crashing, why is suspend or hybernation so difficult?

I mean, the drivers don't have to be told to stop, just remove all CPU cycles from them and freeze them / their memory space as is, and save it. Why do they even have to know what is going on?

I see the answer in my head, but I'm not coming up with the words to explain it correctly. -_-'

-God Ginrai

 

[PhillipJ]

I think the difference is that the VM host can save absolutely every detail about the guest OS state and restore it exactly. It is more like an emulator than a "native" operating system; drivers are not directly accessing any hardware so the VM manager can catch their calls and make sure nothing bad happens when the underlying hardware isn't in an appropriate state to respond.
I realise that this isn't exactly how it works with software like VMWare Player which do provide hardware access but it's closeish. I think.

 

[nutki]

Interestingly, programs like VM ware can 'pause' an OS and restore it at will, regardless of which OS/Drivers are in question. I mean, why is it not possibly to 'stop' everything in it current state, pause it, etc. As long as nothing external to the OS changes, it should be able to be stopped in a 'cryo-state' and restored at will, no? Why do drivers even have to be told that this is going on? So long as the drivers can react dynamically to things (say wifi was there now isn't) without crashing, why is suspend or hybernation so difficult?

I mean, the drivers don't have to be told to stop, just remove all CPU cycles from them and freeze them / their memory space as is, and save it. Why do they even have to know what is going on?

Hardware usually have some state beyond RAM, controlled through memory mapped registers. This state is reset to default or random when power is cut down. As this is all device specific, restoring the state after suspend must be done by drivers. Sometimes unloading/loading trick works as the hardware is initialized on load (but not necessarily to the previous state).
VW ware emulates the hardware internally so it can just save the emulated hardware state without relaying on drivers.

 

[BackAssward]

I think I see the reason why (it actually kinda occured to me after I posted, but getting feedback is always a good thing). The problem is that an OS itself is involved with things, not separate/above from them. With virtualization, you have a layer above what is going on, governing everything. So that layer can 'control' all aspects of the virtualized machine. With a non-virtualized machine, the hardware and OS are involved with what is going on, and can't 'step back' and freeze itself.

To use layperson terms and analogies. It's like saying, a person can't use CPR on themselves. The Pandora has a layer above the OS, but it is not feature rich enough to stop the machine in a specific state and save/restore it. In fact, I don't know of any machine other than virtualization that can.

 

[torpor]

I'd like to see cryogen ported to ARM and integrated into Pandora .. this can be used to 'freeze' running programs and un-freeze them later .. that way we could just freeze apps, shutdown normally, and on reboot, if there are a bunch of apps to unfreeze in something like /usr/cryogen/last-freezed/ (or something) simply un-freeze them on boot. This would be a far better method of implementing 'saved state suspends' than having the whole OS get involved ..

 

[PhillipJ]

Would that help boot speeds though? I thought (and I'm quite ignorant about such things so I'm likely wrong) that loading drivers *was* the slow bit.