Suspend to RAM
- Thread starter adhrain
- Start date
λ the β-Redex Reducer
β-Redex Reducing Member
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.
levi
Still fresh, damnit!
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:
(needs superuser privs so sudo or what have you)
It'll be interesting to see what the pyra reports from issuing said command.
Code:
rtcwake -m mem -s 1It'll be interesting to see what the pyra reports from issuing said command.
pimaster
Very Active Member
- Joined
- Oct 19, 2015
- Messages
- 146
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 2021Then 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:
levi
Still fresh, damnit!
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.
Sorry if it caused you problems at shutdown.
pimaster
Very Active Member
- Joined
- Oct 19, 2015
- Messages
- 146
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.
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.
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"..
pimaster
Very Active Member
- Joined
- Oct 19, 2015
- Messages
- 146
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 secondsTried 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.
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.
pimaster
Very Active Member
- Joined
- Oct 19, 2015
- Messages
- 146
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.
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.
levi
Still fresh, damnit!
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.
Could it be the rtc just gets issues because the batterie sometimes lost contact on the early massproduktion units,
so no contact: no rtc
so no contact: no rtc
levi
Still fresh, damnit!
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.
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.
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.
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)
levi
Still fresh, damnit!
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.
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:
