Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
[root@stb00 linux-3.2.10-1-ice]# patch -p1 < usb-make-usb-persist-work-after-eve ry-system-sleep.tsa.patch
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Naur linux-3.2.10-1-ice/drivers/usb/core/hub.c linux-2.6-2.6.24.patched/d rivers/usb/core/hub.c
|--- linux-3.2.10-1-ice/drivers/usb/core/hub.c 2008-01-24 22:58:37.000000000 +0 000
|+++ linux-3.2.10-1-ice.patched/drivers/usb/core/hub.c 2008-04-03 15:41:04.0000 00000 +0100
--------------------------
File to patch:
I dont see any hub.c file under drivers/usb/core directory. There is only one file called kconfig.
Distribution: RHEL, CentOS, Debian, Oracle Solaris 10
Posts: 1,420
Rep:
Quote:
# echo 1 >/sys/bus/usb/devices/.../power/persist
-bash: /sys/bus/usb/devices/.../power/persist: No such file or directory
First-of-all you're typing the wrong path. The correct path is-
Code:
# cd /sys/bus/usb/devices/
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.
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.
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.
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.
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.
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:
Code:
swapoff /dev/sda1
mkfs -t ext4 /dev/sda1
Just to make sure that the machine has no swap space available at all. Then I launched a simple
Code:
pm-suspend
The 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.
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.
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.
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.
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.
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.
So where does hibernate store its state information if not in swap space?
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.
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?
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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.