Slackware 13.1 suspend only partially works
 

I have been able to get the sleep / suspend mode only partially working. I have read through various threads and the /usr/share/doc/pm-utils readme files. Trying various things has given me partial success and I would like to ask if anyone has any suggestions to get it fully functional.

Here is some background information:
1 - I am running the generic kernel 2.6.33.4-smp
2 - I have an append= line in my lilo.conf pointing to the swap partition, but I have been focusing on a ram suspend
3 - running the scripts in the pm-utils read me files shows that hibernate and suspend are both supported, but hybrid is not
4 - the /sys/power/state file shows mem and disk
5 - I am running the nvidia proprietary drivers 256.44
6 - I created a /etc/mkinitrd.conf file and placed the directives for the module_list, rootdev, rootfs, and resumedev.
7 - My non root user is part of the power group

what IS working is that if I log on as root and startx, I can suspend and resume.

What is not working depends on whether or not I run as root. 1) As root, if I I don't start X the display won't restore, but the machine appears to be partially functional, at least if I press the power button it does a controlled shut down. 2) if I don't run as root, the machine hangs before completing the suspend. The log file /var/log/pm-suspend (attached) seems to indicate that the suspend process completed, but the PC does not go into the suspended state with the power light blinking. Rather it just sits with the fan running and a blank screen. 3) even though my user is a member of the power groups, I can not issue any suspend commands from the terminal for this user. They just say command not found. It I su to root, I can run the commands, but get the same non functional result.

Note: the attached log file is from a root suspend-restore that worked. If run as not-root, it stops at the performing suspend line.

Does anyone have some suggestions as to how to get the suspend mode properly working? It seems to function correctly under Ubuntu which suggests that it is capable of this function, but something is not configured correctly.

give your user permision for power. in groups. try to make sure you run this from telinit 4 or kdm. that way it will not hang and when you come back from ram or disk suspend you will go to a locked screen to sign in from the user that put it in suspend. the screen will be blank and when you move your mouse it will ask you for the users password. remember if running from telinit 3 you have to type startx. if running from KDM or XDM sign or (telinit 4 same thing) in it puts you at runlevel 4 with a session manager after signing in. so now when you resume you resume to telinit 4 as a signed in user but with your screen locked.
sign in as root and run KDM or change your /etc/initab to id:4:initdefault:. and then sign in. you need that session manager to handle the
session for that user.
for lilo add Example:append="resume=/dev/sdYour_Swap_Partition. splash=silent"
grub kernel /boot/vmlinuz-generic-smp-2.6.35.7-smp root=/dev/sda5 ro splash=silent vga=791 acpi=on resume=/dev/sda4

Drakeo, thank you for your assistance. I really appreciate it.

I switched the default run level to 4, which now that I have enough stuff configured properly seems to be fine. Earlier on it was more convenient to start at 3 and launch a gui on command.

I added the splash=silent portion to my lilo configuration (copy attached to this thread) and re-ran lilo. My swap partition is sda5 and my root Slackware partition is sda6 (multi-boot with Windows and Ubuntu).

When I log in as root, the suspend and resume works perfectly. You are correct, you need to perform an activity to bring back the display. However, when I log in as my normal user, the suspend process hangs before it completes. The back light is still on the display, which is otherwise blank, the fans are running, and the keyboard and mouse are non responsive. Typing startx, ctrl-alt + Fx, etc don't appear to do anything. The only recovery seems to be to hold the power button for 5 seconds. The /var/log/pm-suspend.log shows that it is performing the suspend.

When performing a suspend from root, the machine goes to a similar state for about 1 second and then completes the process to the suspended mode, i.e. the screen goes dark, the drives spin down, the back light shuts off, and the power light blinks. Consequently, it looks like there is some subtle difference between the normal user and the root user.

The symptoms make me suspect some form of permissions problem. My normal user is in the power group. As an experiment, I removed the user from the group, rebooted, and the result was that a suspend caused the laptop to go to screen saver. Consequently, the power group allows you to try and suspend, but for some reason is still unable to complete the process.

I ran a find command on the group power and didn't see any files associated with this group. I also tried looking at the various scrips and seeing if the 'sticky' or 'setuid' bit is set for any to allow the process to run as root, but didn't see anything. The only similar symptom thread I found was where someone was still using the huge kernel.

Any ideas as to what could be the difference (permissions?) between the root and normal user that would cause it to hang before completing? Perhaps something in the ACPI where it can't issue the final command?

that light will blink till it rights that image to the harddrive mine takes a minute or so.depending on you cpu speed and ram.
is this suspend to ram or suspend to hard drive check in your groups for daemon and video.
I also stopped running lilo a long time ago and run grub1 it make my multiple systems easier for me. it is in extra.
That said I have 6 people I support that are using lilo.
things I have checked for them are daemon lp power video audio wheel dialout cdrom games tape gdm plugdev netdev scanner
also not a big fan of this but you may need to give that user disk permission to read the image from disk.

Thank you for the reply. I added my user to the groups listed as it wasn't in most of them, just the default ones. Unfortunately, that didn't seem to have an effect. I am going to continue to experiment with the different groups and see if I can find one that triggers a solution. Even if it is not an appropriate group for a user account, it will at least provide a clue as to where to look. This is a somewhat time consuming process because I need to make a change, try it, and if it hangs perform a forced power off and restart.

I have noticed a couple of other, possibly interesting things. I am using the suspend to ram as opposed to hibernate to disk if that makes a difference. 1 - when the root user performs the process, the pc beeps, and the screen goes dark with the back light off. It beeps and stays on when I do this as a user. The back light going off seems to be an symptom or indicator that is indicative of whether or not it will work. 2 - and possibly most telling is that if I first log in as the user, then log out and log back in as root the process will also fail. Apparently having been logged in as a user after power up changes something that is problematic.

One other thing to note that may be related is that there are two other active threads regarding suspend to ram problems: one is on slackware64 and the other says that there is a kernel bug with 2.6.35. I am neither using slackware64 or that kernel, but I am experiencing similar symptoms.

If you want your machine to suspend to ram when you press the power button, then you could edit /etc/acpi/acpi_handler.sh and change ' power) /sbin/init 0 ' to ' power) /usr/sbin/pm-suspend '.
If you want to able to suspend to ram by issuing a command as a user, then edit /etc/sudoers using visudo to give the user sudo privileges for /usr/sbin/pm-suspend.

what is your video card some are unable to suspend do to the driver.

@allend, those are good hints, thank you.

@drakeo, the video card is an nvidia geforce 7000m/610 (which is a laptop model card I believe). I have posted the parts of lspci containing nvidia below. It is more than just the video card. I included it because it surprised me that it contains things like the USB controller. It is as if this machine uses an nVidia integrated IO chips set or something. I double checked the video card information in Windows Vista, which I recall reading a while back that you can sometimes get different or more information, and it reports the same thing.

I run nvidia also . the only thing different from my lilo.conf and yours is I do not use the splash=silent. I remember back away's but I am unable to find it, GrapefruiTgirl did some work on this. start here