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.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

- (A) In console mode, no X server running, the system suspends and resumes, but the screen is not restored. I can type commands (for an example "halt" to stop the machine).
No options/quirks work with above methods. The card seems to ignore them.

- (B) On the other hand, if X server is running (example, started my KDE session with startx), I can suspend to ram with the simple "echo -n mem > /sys/power/state": the screen is restored correctly on resume.

In fact, in case (A) after resume, if I blindly type "startx", the X server starts correctly, the screen is restored, and have KDE as usual. If I switch to console (ctrl+alt+Fwhatever) the screen goes blank again (although bash is still functional as before). If I switch back to KDE, the screen goes ok again... and so forever.

Thus, the point is the X server "knows" how to cleanly restore the screen after a suspend resume.

My question is: how could I reproduce those actions performed by X server, in order to create a script to suspend from console (without X)?

Thank you.

NOTE: I have reproduced this behaviour in my old Debian Lenny installation too. I was not aware of it until now (I always suspended from gnome).

same here... any progress ??
Video: nvidia 7150m
i only found something... i did not used startx, but just X (but did not see anything...) and also read the logs over SSH
normaly the X shows a zeiko display detected, but if i start without X and make a suspend to ram, when it comes back (with no video at all) X logs shows no display detected...and is uses a CRT.... ¿?¿?

Chapter 18. Configuring a Notebook
Installation and configuration
Installation and configuration of the NVIDIA Linux Driver Set on a notebook is the same as for any desktop environment, with a few additions, as described below.
Power Management
All notebook NVIDIA GPUs support power management, both S3 (also known as "Standby" or "Suspend to RAM") and S4 (also known as "Hibernate", "Suspend to Disk" or "SWSUSP"). Power management is system-specific and is dependent upon all the components in the system; some systems may be more problematic than other systems.
...
In many cases, suspending and/or resuming will fail. As mentioned above, this functionality is very system-specific. There are still many cases that are problematic. Here are some tips that may help:
In some cases, hibernation can have bad interactions with the PCI Express bus clocks, which can lead to system hangs when entering hibernation. This issue is still being investigated, but a known workaround is to leave an OpenGL application running when hibernating.

It does not really help you, but at least you know that the issue is real and has been investigated.