Suspend to RAM


From what I understand, supposedly this is a hardware problem with the OMAP board and cannot ever be repaired. The next OMAP would supposedly have repaired this defect but was never released.
I may forget something, because it was commented long ago, but as I remember the hardware issue was for a low power state (idle?), but not for suspend to RAM.
Suspend to RAM is mainly a problem of complex software development and lots of testing (and once people try and do it they might discover some hardware issue, but nothing yet known).
But the other low power mode, that didn't require suspend would have been much simpler softwarewise, if the hardware had allowed it.
 
FWIW, in case it's of any use to anyone, one way of forcing the unit to sleep (otherwise known as suspend to ram) is to issue an:
Code:
rtcwake -m mem -s 1
(needs superuser privs so sudo or what have you)

It'll be interesting to see what the pyra reports from issuing said command.
 
sudo rtcwake -m mem -s 1 rtcwake: assuming RTC uses UTC ... rtcwake: wakeup from "mem" using /dev/rtc0 at Mon Sep 20 23:17:20 2021
Then continued to operate as normal.

-edit-
Upon shutdown, it behaved differently. Was complaining about a job running.
Said it reached shutdown state but left they screen and keyboard leds on.
 
Last edited:
When you say it continued to operate as normal, do you mean it returned a new prompt in the terminal window for you to type further on?

Sorry if it caused you problems at shutdown.
 
I should have been more clear about that part.

The terminal never returned (like I would expect a successfully run program). I started up Firefox to see if the system was still functional. Which it was. Wifi seemed to disconnect and reconnect again which seemed odd but I didn't think much of it.
Interestingly I couldn't CRTL+C or CRTL+Z the rtcwake process. I didn't know whether that implied something didn't work or the process had locked up in a weird way.

No stress on helping you test an idea. Holding the power button killed the unit then it was functioning properly again.
I just saw your message and figured it was an easy thing to test for you and provide feedback on.
 
That command shall have lead to system going to sleep and then wake-up after 1 second. Did you notice blank screen for 1 second while system slept? You may try "-s 5" to see clearly if system goes to sleep for 5 seconds.
 
If this scrippt works, i can remember whe had some workaround on the Pandora how to make our own Scripts atached to the Taskbar so you only need to type or copy it in once and then just click on this "Widged"..
 
That command shall have lead to system going to sleep and then wake-up after 1 second. Did you notice blank screen for 1 second while system slept? You may try "-s 5" to see clearly if system goes to sleep for 5 seconds.
Tried it with -s 20 to make sure it had heaps of time to do whatever it needed to do, nothing changed (No screen off. Wifi didn't drop this time).

Remembered to look at the logs whilst I was doing this. Nothing obviously wrong.
==> kern.log <== Sep 22 09:42:38 localhost kernel: [ 101.597106] PM: suspend entry (deep) ==> messages <== Sep 22 09:42:38 localhost kernel: [ 101.597106] PM: suspend entry (deep) ==> kern.log <== Sep 22 09:42:38 localhost kernel: [ 101.617489] Filesystems sync: 0.016 seconds ==> messages <== Sep 22 09:42:38 localhost kernel: [ 101.617489] Filesystems sync: 0.016 seconds

Tried harder to kill the process this time. sudo killall rtcwake didn't cause the process to return. Ended up killing the terminal window (which I thought terminated all child processes) and when I went to execute the process again it said that it couldn't access the rtc device.
 
So it fails to suspend. I guess something is wrong at low level. rtc is real time clock (hardware clock or bios clock), usually at /dev/rtc. Did you notice any issue with date/time when you did reboot?
rtcwake can do other types of suspends (other than suspend to rem, depending on mode you choose), but I think hardware needs to go into idle mode for all that.
 
Can't detect anything wrong with the clock after the forced off.
Unless the hang on shutdown is related to the clock.
Definitely think it is low level as has been discussed for a long time. Wish I was feeling well enough to look into it.
 
You can tell rtcwake to look at a different clock with the -d (for device) flag, but looking at the terminal log posted above I can't see anything to indicate that rtc0 isn't a good clock to look at.
That was in response to this,
...... when I went to execute the process again it said that it couldn't access the rtc device.
 
On desktop PCs the RTC is backed by a little coin cell on the motherboard. On the original XBOX this was achieved using a capacitor to allow you to move the unit between rooms and plug it in again without losing the clock, but any more than that and it would forget the time. On the Pyra it may be achieved using a capacitor similarly. But even if the time has been reset, I don't think it should affect rtcwake so long as the rtc is awake and ticking.

As for as I know you can read the rtc by issing a 'hwclock -ru' (again needs superuser privs). Run this a couple of itmes a note whether the time is advancing. I'd be rather surpirsed if it wasn't.
That was in response to this,
Yes, but that was running rtcwake a second time while the original process was still running. It's not surprising therefore it cannot access it.
 
Tried harder to kill the process this time. sudo killall rtcwake didn't cause the process to return. Ended up killing the terminal window (which I thought terminated all child processes) and when I went to execute the process again it said that it couldn't access the rtc device.
He tried to kill the process using killall and killed the terminal window, before executing the process again. So as per him he was running it after killing the first process, but you may be right that first process may be still running in background, ( I am not sure of this, as process was run in foreground, so killing terminal window shall have killed the process)
Yes, but that was running rtcwake a second time while the original process was still running. It's not surprising therefore it cannot access it.
 
Hmm, quite right. I must have mixed up the order of this thread conversation in my head.

Edit: Although he did conclude that he failed to kill the process, merely killing the window it was in. So in effect he was running trying to run two rtcwake processes at the same time.

Edit2: Yes, it seems that if you spawn a job that's waiting on user input, or writing output, the terminal will error if you try to exit it. But it you start a quiet process and then kill the terminal the process will run to completion.
 
Last edited:
Back
Top