I have have been successful with suspending and resuming to/from
disk/RAM. I am running 64-bit openSuSE 10.2 with vanilla 64-bit kernel
2.6.20, with full pre-emption enabled, ***WITH THE 64-BIT NVIDIA DRIVER
LOADED***. (OpenSuSE 10.2 comes with a "SuSEfied" kernel 2.6.18, but
the 2.6.20 kernel has very good support for the Broadcom wifi. I think
that the Broadcom wifi support in the kernel has regressed in kernel
2.6.22, BTW.) My nVidia driver is 9736 (according to nVidia's web site,
the 96xx drivers are the last to support the GeForce4 cards).
Resuming from either suspend is flawless! No problems with USB,
display, or sound (I haven't tested how the wifi behaves after resume).
I use this laptop also as a gateway; I have a Netgear GA511 cardbus
gigabit ethernet card which handles my internal net (it's based on
Realtek's 8169 and requires the module 'r8169'.), while the bulit-in
ethernet is connected to the public internet. The GA511 resumes fine
and remembers its configuration fine. I also run the dhcpd and named
dæmons for my internal network and they, too, wake up fine. Below I
discuss details of these successful suspend/resume cycles on my Pesario
R3000 US.
The breakthrough came last week when I added the statement Option
"NvAGP" "1" to the "Device" section of the /etc/X11/X86Config
file. So, my "Device" section looks like this:
-----------------------------------SNIP--------------------------------
Section "Device"
BoardName "GeForce4 440 Go 64M"
BusID "1:0:0"
Driver "nvidia"
Identifier "Device[0]"
VendorName "NVIDIA"
Option "NvAGP" "1"
EndSection
--------------------------------------SNIP--------------------------------
Ubuntu Feisty Fawn uses /etc/X11/xorg.conf. I have not tried suspending
under Feisty Fawn. Perusing the nVidia forums, I am led to believe that
even drivers supporting newer nVidia cards require the 'NvAGP' option
turned on to resume successfully.
I have given passworded privileges to a couple of users for the commands
'swsusp' (which suspends to disk) and 's2ram' (which suspends to RAM) in
the /etc/sudoers file. 'swsusp' works without any special options.
However, 's2ram' requires the -f option to work; otherwise, it complains
that the computer is not in its database and aborts (I also use the -a 3
option, but s2ram works without it; run a 's2ram --help' to see all
options). I found out that on my openSuSE 10.2 I need to specify the
-f option for the variable S2RAM_OPTS in file /etc/pm/config for the KDE
desktop to suspend to RAM through its power management menu (accessed by
right-clicking on the power cord icon, usually on the bottom right --I
try to keep the Windows speak from creeping into Linux forums!).
I very seldom use KDE or GNOME because I use this laptop extensively for
numerical simulations with the open-source Scilab package and also the
absolutely free LT Spice circuit simulator, which is available for free
from Linear Technology corp. (I run LTSpice under Wine; it is designed
to take Wine into consideration), so I need every byte of memory I can
scrounge. Therefore, I tend to prefer minimalist desktops such as TWM
(BTW, I have the full 2GB of RAM on this laptop, have not patched the
kernel, but haven't experienced any "over 1GB" problems with the
Broadcom wifi). Without KDE's luxuries, I have to be careful how I
suspend. KDE locks the screen upon resuming, which is wise (otherwise,
if the laptop is left unattended while it is suspended, especially to
RAM, when the lights blink, anybody can make it resume and have access
to the user account from which the laptop was suspended!). To avoid
this security risk, I use the command sequence (on the same line)
sudo s2ram -f -a 3; xlock &
or
sudo swsusp; xlock &
to suspend to RAM or disk, respectively, and lock the screen upon
resuming. To guard against the possibility of misspelling 'xlock'
(which would manifest itself only after resuming!), I entered the above
lines into files, which I made executable, and I invoke the appropriate
file instead of the individual commands.
I hope the above helps. It sure feels good to be able to "freeze" this
laptop with many programs opened and then instantly bring it back to life!
--
Running 64-bit Linux on AMD64