Slackware 13.1 and KDE on Lenovo with suspend to RAM / swap
 

While this is the second notebook I've had the luxury of running Slackware on, I have never used the the suspend to RAM / swap functions so all of this is new to me. With this new notebook and new installation of Slackware 13.1 I decided to give it a shot as it's definitely a power sucker. The machine is a Lenovo W510 with an NVidia graphics card running KDE. When I tell KDE to go to Sleep (RAM suspension) it looks like it does so properly by blanking the screen and pushing things to RAM. Is there a way to verify that Sleep is working? Anyway after unlocking the system my mouse pointer is no longer visible, however it is still active as I can hover over items to reveal their popups. At this point none of my conky displays are transparent anymore, nor are they actively displaying stats. The windows I have set to display with 88% opacity are no longer as such and are completely opaque. It is as if all the custom window settings are ignored. If I move the the mouse towards the bottom of the screen the screen starts to go crazy with this rainbow of colors across the top of the screen and the only way to get out of this is to press Ctrl-ESC to bring up a System Activity window. Anyone have any suggestions? I have not tried Hibernate yet as I would like to get this resolved first...

Is Slackware 13.1 supposed to be able to Sleep/Hibernate with no special configuration and creation of scripts provided that the system can handle these functions?

See my posts in this thread. In my case a different display driver made a big difference

Thanks bogzab, I have been following your thread! Only reason I created a new one instead of adding to it is because it has been put as solved so I figured this would get more replies if I had created a new thread. Anyhow I may have solved my own issue with a BIOS upgrade that was recently released. Question is, how does one tell that the machine is indeed in Sleep state?

That, of course is a trick question, since if it's asleep it won't interact with you until you wake it up. Nearest you can get is to inspect the log referred to in the other thread - iirc it is at /var/log/pm-suspend.log. In this log there is a series of lines which are written during the suspend process. If all of them show "success" or "not applicable" then the suspend process **thinks** that it got through all its work OK.

In my case the suspend process seemed to have worked OK, as shown in the log and the problems were seen as soon as the wake-up routines started and the specific problem was with waking up the video. New video driver solved the problem.

Thanks! I will have to verify with this log when I get home to see if it is indeed going through the motions of sleep. Like I have said I have never used this feature in the past and after giving the system about a minute to Sleep then moving the mouse, I was surprised it responded so quickly with a prompt to login. Thanks for your assistance!

Welp, looks like I'm still having issues with waking up from sleep. I have the NVIDIA® Quadro® FX 880M on a Slackware64 system so I used NVIDIA-Linux-x86_64-195.36.24-pkg2.run to install my drivers. Believe it or not, I had originally used the IA64 version of the drivers thinking IA64 was the same... anyway I am currently using the former and upon putting the system to Sleep in KDE, I can never wake the system up again. Any mouse movement or keystroke should wake the system up from Sleep right? Well on my system doing so did not do anything except reboot my system! Help!

The following is what is logged to pm-suspend.log

/usr/lib64/pm-utils/sleep.d/00powersave suspend suspend:success.
/usr/lib64/pm-utils/sleep.d/01grub suspend suspend:not applicable.
/usr/lib64/pm-utils/sleep.d/49bluetooth suspend suspend:success.
/usr/lib64/pm-utils/sleep.d/55NetworkManager suspend suspend:success.
/usr/lib64/pm-utils/sleep.d/75modules suspend suspend:not applicable.
/usr/lib64/pm-utils/sleep.d/90clock suspend suspend:not applicable.
/usr/lib64/pm-utils/sleep.d/94cpufreq suspend suspend:success.
/usr/lib64/pm-utils/sleep.d/95led suspend suspend:success.
/usr/lib64/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend:success.
/usr/lib64/pm-utils/sleep.d/99video suspend suspend:kernel.acpi_video_flags = 0
success.
Fri Jun 4 20:33:31 EDT 2010: performing suspend
/usr/lib64/pm-utils/pm-functions: line 295: echo: write error: No such file or directory
Fri Jun 4 20:33:33 EDT 2010: Awake.
Fri Jun 4 20:33:33 EDT 2010: Running hooks for resume
/usr/lib64/pm-utils/sleep.d/99video resume suspend:Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Returned exit code 1.
/usr/lib64/pm-utils/sleep.d/98video-quirk-db-handler resume suspend:success.
/usr/lib64/pm-utils/sleep.d/95led resume suspend:success.
/usr/lib64/pm-utils/sleep.d/94cpufreq resume suspend:success.
/usr/lib64/pm-utils/sleep.d/90clock resume suspend:not applicable.
/usr/lib64/pm-utils/sleep.d/75modules resume suspend:success.
/usr/lib64/pm-utils/sleep.d/55NetworkManager resume suspend:success.
/usr/lib64/pm-utils/sleep.d/49bluetooth resume suspend:success.
/usr/lib64/pm-utils/sleep.d/01grub resume suspend:not applicable.
/usr/lib64/pm-utils/sleep.d/00powersave resume suspend:success.
/usr/lib64/pm-utils/sleep.d/00logging resume suspend:success.



EDIT: running 'echo mem > /sys/power/state' and 'echo disk > /sys/power/state' while in KDE looks like it actually goes through the motions of going into Sleep or Hibernate, but then it wakes up by itself with the following message:
-su: echo: write error: Input/output error

System definitely does not look like it's going to Sleep or Hibernate. While it goes through the motions, network activity still occurs. Shouldn't it stop?

@dimm0k - This suggests that this is a hardware issue. Maybe try fiddling with your memory location slot.
http://forums.lenovo.com/t5/W-Series...sue/m-p/237514

I have been there... For me, Sleep works fine under Windows 7. Put it to Sleep and the external monitor goes blank with the power light turning yellow indicating it is in powersave, wi-fi light turns off and the power button starts flashing. In Linux none of this happens except that the external monitor goes blank, however the power light stays green meaning it is not in powersave.

While not verified, I'm certain I have figured out the issue! See the post here for the result... http://www.linuxquestions.org/questi...4/#post3996872

Basically it was my fault for sticking with the "huge" kernel... something I've been accustomed to for a while and it was something I never meant to do!

Hi,

That's one of the reasons to read the text files provided by the Slackware team.

:hattip: