Suspend to RAM issue
 

I am facing an issue while running pm-suspend for suspending to RAM on ArchLinux.My ArchLinux is running on USB drive.
Whenever I run pm-suspend command, it fails to suspend and becomes black screen and cursor gets displayed.
Sometimes the suspend work and sometimes not.
I need to reboot the machine manually.

I referred to this doc: http://www.mjmwired.net/kernel/Docum...sb/persist.txt
All I tried following http://forum.eeeuser.com/index.php?/...ctually-works/ and tried running:

I dont see any hub.c file under drivers/usb/core directory. There is only one file called kconfig.

First-of-all you're typing the wrong path. The correct path is-

then you will see some other directories and in those directories there is a directory named power and in that power directory there is a file named persist.

You can check this thread also: https://bbs.archlinux.org/viewtopic.php?id=58273
check the man page of pm-suspend command.

Suspend-to-RAM, sometimes called "sleep," and suspend-to-disk, or "hibernate,"
both require that you have configured swap partitions that are larger than your physical RAM size by some amount. I have not seen a precise statement of the size formula, but an extra 1.0 GBytes ought to handle it. That means a workstation
with 4.0 Gbytes of RAM would need 5.0 GBytes of swap.

The software uses swap space to store the current state of the running system
during the interval of suspension. Sleep and Hibernate store different details
-- Hibernate more than Sleep -- but they need to save things somewhere. Swap
is the where.

In addition to this, suspend in every form is a very complex beast. You will find
reams of pages written about troubles with these features.

I wish you luck,
~~~ 0;-Dan

Sorry, but no. Suspend-to-RAM, exactly what its name says, stores the system status to RAM, not to the disk. That means that Suspend-to-RAM should even work on diskless machines.

I agree in principal. Respectfully, I must disagree based on experience.
While I understand that the hardware can "spin down" and "remember" what is
going on, I was not able to get any form of suspend -- sleep or hibernate --
working without swap space as I describe.

I have sent email to developers for months seeking details without success.
I know enough about hardware to appreciate many of the issues involved and
why "suspend" may be problematic in the general case. An end-user, even one
with some level of technical skills, should not be forced to read the code
seeking how things (1) ought to work, and (2) actually work.

If you know differently, please share references so that other may learn the
messy details. I promise to do the same.

In my experience,
~~~ 0;-Dan

I made a simple test to be sure. On my laptop (Slackware -current without KDE) the swap partition is /dev/sda1. So I issued the following commands as root:Just to make sure that the machine has no swap space available at all. Then I launched a simpleThe laptop went to suspend mode and came back without any problems after a press on the power button, as usual.
So I can say for sure that swap space is not needed for a proper suspend to RAM.

** I stand corrected **
 

What a simply and clear demonstration of how things work... WONDERFUL!!

I had every indication that some details were written into swap space
during suspend-to-RAM. On the surface, it appears that I was mistaken.
Did you inspect the partition to make sure that nothing got written
there in some form?

I could see situations where something remembered that /dev/sda1 used to be swap space and used that device for something. I think that any direct write to the device "/dev/sda1" would trash the file system, but writes out in the middle of the list of logical blocks might pass un-noticed.

For now, I'm convinced,
~~~ 0;-Dan

That was rather easy to test:As you can see, the contents on that partition are not altered, otherwise it would have produced a different checksum.

Fantastic! Another simple, easy to reproduce test with black n white results.

So if pm-something does not use swapspace, where does "hibernate" store the
core image across power off? Also, why does "hibernate" cause so much drive
LED flicker on the way down?

Is there logging for all of this? I cannot find any.

~~~ 0;-Dan

Hibernate (S4) and suspend (S3) are two totally different thinks. Suspend is saving the computers state in RAM and then sends the machine into Standby mode, while hibernate stores the systems state on disk and then turns off the machine.

So where does hibernate store its state information if not in swap space?

In my thinking, open() --> write() --> close() of a traditional file
causes a change of state in the file system, not to mention the need to track down however many extents may be needed to write all of the state details.

Stumped,
~~~ 0;-Dan

It actually stores the information in the swap partition (I doubt that a swap file can be used for that). How that exactly that works is unknown to me, since I don't know anything about the format of swap partitions.

Didn't you prove at TobiSGD previous post that the swap partition was not modified at all during suspend? Am I missing something?

~~~ 0;-Dan

Yes, you are missing the point that suspend to RAM (S3) and hibernate (S4) are not the same thing. Suspend to RAM (aka Suspend, Standby, ...) stores the machine's state in RAM and doesn't modify anything on the harddisk, as I have proven in the post you linked. Hibernate (aka suspend to disk) stores the machine's state in the swap partition.

Okay, let me walk through a suspend-to-RAM situation:

I have 4GBytes of RAM.
I boot and run for a while.
At time T=nnn I decide to envoke suspend-to-RAM.
The hardware is in whatever state it is in at T=nnn.
RAM contains some mix of system and user process code and data. For this example, assume that 80% of RAM is in use.

If I understand, you contend that upon entering S3, everything enters stasis
so there is zero requirement to store anything. In contrast, S4 turns power off so things must get stored. Do I understand rightly?

~~~ 0;-Dan