My Lenovo 3000 N200 laptop was fine under Slack 12.1 as far as sleep and hibernate were concerned but I seem to have lost this functionality in 13.1

Under Slack 12.1 and KDE 3.5.10, I had three ways of doing achieving these states :
1. In KDE it was an option when closing the KDE session to sleep - worked fine
2. At the command line I could do "acpitool -s" (sleep) or "acpitool -S" (hibernate) - also worked fine.
3. Finally I mapped the relevant laptop hot keys (using xmodmap) to XF86Standby XF86Sleep - also worked very nicely - this is what I ended up using most of the time.

Now the results of attempting these operations are as follows:

KDE and acpitool "sleep" functions seems to put the laptop to sleep (screen goes dark and "sleep" led comes on), but nothing seems to wake it up correctly - screen always blank despite some whirring of the CD drive and some disk activity. No keys work other than the main off key to shut down everything.

KDE and acpitool "hibernate" functions seem to go into a loop in which the "I am going to sleep" LED flashes forever, but no sleep state is achieved. If you are in command-line, you can carry on typing commands...

The keyboard shortcuts seem to just do nothing.

I have tried pm-suspend and pm-hibernate which seem to be the new way of achieving these power-management states. Same effect - "suspend" seems to put the PC to sleep but cannot be awakend, "hibernate" goes into the same apparent half-hearted attempt to put the machine to sleep as achieved by acpitool -S and the KDE option.

I guess at the lowest level all of these methods are passing the acpi system a command, it's just that they are all missing some vital trick in doing so - the Slack 12.1 equivalent fucntions seemed to work well.

Any advice ?

I recently purchased a new notebook and am anxious to get home to try and get Slackware to be able to put the system into Suspend and Hibernate so I have not tried anything yet, but did you look at this thread for a possible solution? http://www.linuxquestions.org/questi...screen-807316/

Thanks for reminding me about that thread - I had seen it, but re-reading down to the end was v helpful because there I found out about the /var/log/pm-suspend-log file. I have examined this and it looks interesting, although (naturally) I don't quite know how to proceed. The log file shows a whole series of suspend processes which all ended in success or were not applicable. However on wake-up, i see after that various other "successes", although if the video does not wake up properly then that explains why I see nothing.

So that may be where things are going wrong, but I have little idea how to put it right - all I know is that suspend and resume worked just fine under Slack 12.1.

I am guessing that I am missing a kernel module somewhere, but not sure how because I am running the Slackware "huge" kernel.

Any help appreciated.

Did you upgrade from 12.1 or did you install 13.1 fresh? I believe it's not recommended to upgrade to 13.1 from anything other than 13.0... Were you able to use the Slackware provided kernels for 12.1 to get Sleep/Hibernate working or did you compile your own kernel?

The 13.1 install was fresh - reformatted hard drive etc. And the 12.1 setup worked (if I remember correctly) without modification to the supplied kernels. I have now tried with both the huge and the 13.1 generic 13.1 kernels with the initrd as recommended in /usr/share/doc/pm-utils/README.SLACKWARE.

I think that what I have to do next is disable some of the "hooks" which are described there and other documentation there. What worries me though is that using acpitool (which I think is independent of pm-utils) also gives the same behaviour - all makes me think that the cause is deep-seated (a kernel module doing something different?).

for sleep:

@rkski : That's just the problem - even issuing this simplest of commands like the one you show, gives me the exact same behaviour as the alternatives - "acpitool -s" and "pm-suspend". That behaviour is as desribed above - cannot awaken from the sleep state, although it looks as though first steps are taken (drives start up), I never get to see anything on the screen and the keyboard does nothing.

Are you passing the kernel a resume point at boot time with a line like . . .
append="resume=/dev/sda5 splash=silent"
in your lilo.conf?

Yes, I have a line almost like that. I added that when I went from huge to generic kernel and added the initrd stuff.

Obviously the device is not the same (but close - /dev/sda4 in my case). Also I do not have the "splash=silent" part of the line. Is this likely to be critical? Also does this only come into play for the hibernate state? Or does the sleep state use the swap device as well ?

Hi,

For 2 computers I did a fresh install of 13.0 on blank drives when it came out; I use Xfce as KDE is always too bloated and slow. I am hopping on/off trains and I need a responsive system on my laptop. In 13.0 suspend from xfce worked as a dream.

Now I am completely lost after upgrading to 13.1: On both computers there is no connection happening with the messagebus via HAL when I try to 'suspend' or 'quit' from Xfce; that is as far as I understand the very, very belated error-message that comes up. The pm-suspend.log comes up with this as last line:

/usr/lib64/pm-utils/sleep.d/99video suspend suspend:/usr/lib64/pm-utils/functions: line 51: 2547 Terminated "$@"

which is in a function called 'release_lock()'

By the way, the xfce error-message has an exit-button that has to be pressed in order to kill X. This is very bad interface design as it defies the 'fail graciously' principle. The exit should happen by itself...and provide the error-message in some log or when out of X. The feedback in this form can even be damaging, because, being already underway to catch a train before I found out at the station that no exit/suspend whatsoever had happened, my computer was seriously overheating, closed in its bag.

Another worrying thing: I can no longer jump out of X to a TTY screen using Ctrl+Alt+F2; also chvt command comes up with an error VT...something not found. It seems an X-problem as in fluxbox the same (although I can exit normally).

What is happening??.... Of course I missed something, but I cannot see what. All files in /etc/ are updated. Outdated packages removed. Everything has been reinstalled. I use the multilib version. Did not get any error messages anywhere suggesting some of the downloaded packages are corrupted (but maybe it is that..will start downloading the whole stuff again).. Or it must be that somewhere I need to copy over fdi files as for the synaptics touchpad.... but the above is too serious for not to be mentioned in the Upgrade.txt and Hints.

Has some new software (polkit? consolekit?) taken my control and trust away? Do I have to reinstall 13.0???

I have been using slackware since version 8, always upgraded along the way to 13.0 without problems as major as these. Any help much appreciated.

I would at least try it also with a generic kernel and an initrd. Don't know if that will help in any way, but worth a try I guess. This way you could for example try it with intelfb module once loaded and once not, since you experienced that video related line in your log file.

1 members found this post helpful.

This is solved thanks to some non-free software (oops). I remembered that in my 12.1 installation I had installed the nvidia inc nvidia driver, so I did the same for the 13.1 setup and ... wow - suspend and re-start works fine with pm-suspend and from the KDE "suspend" button.

Suggests that something about the X display driver that went in by default under the Slack installation was not compatible with the suspend / restore routines.

This view supported by the fact that I still cannot do a suspend / re-start cycle if I have no X running - pure console mode, pm-suspend still fails on re-start - ie it is the nvidia driver which is the key to this working on my hardware.

Thanks to all who posted helpful suggestions here.

1 members found this post helpful.

Depends on which Nvidia GPU you have. Suspend to disk/ram works with nouveau-kms and my Dell c840 (GeForce 440go). Our other Nvidia laptops use newer GPUs with the Nvidia binary driver. It was documented somewhere to make a pm-utils quirk for ALLOW_NV_SUSPEND="yes" . Forget where I read that, but it stuck with me. Might be old, as suspend with the nv driver used to be disabled by default because it mostly just did not work.

Speaking of quirks, on our laptops that use PCMCIA cards, I had to hack together a pm-utils quirk to stop and start pcmcia services, or else we experienced the same effects you did.

Robby did a good write up in README.SLACKWARE, plus plenty of other docs located at /usr/doc/pm-utils-$VERSION.

Ok, I have X behaving again. It was the ati-graphics (10.5) that was not compiled properly. Maybe because of old stuff hanging around from 13.0. Anyway, I now got the open source radeon driver to work following this method: http://www.linuxquestions.org/questi...-works-760963/ and at least I am back to normal behavior for the ctrl+alt+F although have to figure out how to get suspend to work but found already some hints to try. Great site/forum this (and the phoronix-forum on ati is very helpful as well).

Later... Hmmm, suspend did not work this way. Went back to the ati-driver and installed it with --buildpkg Slackware/All (as found on the phoronix site and when giving the option --listpkg to the ati-driver-installer), which creates two packages to install. This procedure includes the application of a patch (which is maybe missed when using the installer by itself as I normally do). But all is back to normal now, pfui.

1 members found this post helpful.

You have a Lenovo as well and because I am totally new to this Sleep/Hibernate feature in computing, how do you know your machine is in Sleep and not just a blank screen?