NVidia proprietary driver + suspend to ram (Slackware 12.1)

El Nigromante · 08-16-2008, 03:14 AM

Hello, Slackware beings:

I have just installed Slackware 12.1 in my desktop machine and everything seems to work fine (I had to add hd?=noprobe at kernel boot, for my SATA drives). I use a console login (runlevel 3).

Well, the fact is I have a NVidia card (NVidia 8400 GS), so installed proprietary NVidia drivers too (NVIDIA-Linux-x86-173.14.12-pkg1.run): KDE runs fine...

But my "problem" is with suspend to ram:

- I have tried the following methods:

* s2ram (suspend package from slacky.eu)
* pm-suspend (pm-utils package from slacky.eu)
* plain "echo -n mem > /sys/power/state"

- (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).

NOTE 2: I have not tested suspend to disk (aka hibernate) yet.

skog · 08-17-2008, 05:10 AM

are you using fbconsole or vesafb console? a high-rez command line? do you have something like this "vga=791" in your /boot/grub/menu.lst or /etc/lilo.conf?

El Nigromante · 08-17-2008, 06:50 PM

Yes, I have vga=788 (800x600). I also have tried with vga=0 and with no success.

With X server running there's no problem with framebuffer, the screen is correctly restored. Problem comes when X server is not running.

luismanson · 10-14-2008, 07:02 PM

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.... ¿?¿?

Woodsman · 10-14-2008, 08:02 PM

I had similar results:

https://www.linuxquestions.org/quest...ml#post3299192

allend · 10-15-2008, 11:06 AM

From /usr/doc/NVIDIA_GLX-1.0/html/chapter-18.html

Quote:

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.

robel · 10-15-2008, 11:16 AM

I had to do this in rc.local:

echo 3 > /proc/sys/kernel/acpi_video_flags

The computer is a laptop. If it doesn't work try another number, or ask somebody what the number means... I don't know. ;-)