Suspend and resume in Suse 11.2 and KDE 4.3

**stefanhinz** · 03-Mar-2010, 10:48

I've upgraded 4 boxes (32- and 64-bit) from Suse 11.1 to 11.2 with no unresolvable issues. Now I'm stuck with my 5th box, a Dell Dimension 8400 desktop box (yes, an old brick, 32-bit). I can suspend to RAM ("suspend") and to disk ("hibernate") fine, but resume seems to fail.

In Suse 11.1 I used kpowersave (GUI in the sys tray) to suspend to RAM. For some reason, it couldn't suspend to disk but that didn't bother me. kpowersave relies on the powersaved running. Note I had upgraded my 11.1 installation to all shiny and new KDE 4.3 stuff, and while KDE 4.3 seems not to use powersaved (and thus kpowersave) all worked fine.

Upgrading to 11.2 has removed kpowersave and powersaved. I don't mind switching to another way if only I could find documentation what's being used on KDE 4.3 (and/or Suse 11.2). All I find by googling is that the daemon used is powerdevil, and that I should use a GUI for suspending (this battery monitoring plasma app). Well, if I do that on this box it simply does -- nothing.

So I tried s2ram and a2disk directly:

Running s2ram with the --force option works, but the box doesn't resume. Goes on, screen stays blank, mouse and keyboard don't work.
s2disk complains about not being able to "stat the resume device file". I gave it the --resume_device /dev/sda6 option, and it hibernated fine. But it doesn't resume. Pressing the power on button just starts Suse anew (and recovers the file system journals, so I assume it thinks it has crashed before).

So I think I have 2 questions:

What the heck does Suse 11.2 use for suspend/hibernate and resume? Is there any how-to available to learn what I need to configure?
Why can't I resume from successful s2ram or s2disk operations? /var/log/pm-suspend-log or pm-powersave-log don't provide any clues.

**michael_cheah** · 03-Mar-2010, 20:41

See Suspend to RAM - openSUSE

AFAIK the backend is now pm-util and not powersaved anymore since openSUSE 10.2

**stefanhinz** · 06-Mar-2010, 03:35

Thanks for the Suspend to RAM - openSUSE link, but I've already read that page. I've made some further tests, as suggested on that page, but all I can say is:

s2ram -f works fine
s2disk -r /path/to/resume/device works fine
Resume doesn't work at all, neither after suspend to RAM nor to disk

Particularly, what I did to rule out any potential problems caused by KDE or X, was starting the machine with init=/bin/bash. But, as said above, resuming fails utterly. After powering it on again, it's "on", but the screen remains dark.

And again, all was fine while I was on Suse 11.1. Any ideas what upgrading to Suse 11.2 might have changed so that resume fails?

**michael_cheah** · 06-Mar-2010, 12:45

If you can tell us more about your graphic card model maybe somebody can figure out what went wrong here.

Kernel/graphic driver updates may cause regression in this kinds of thing but we can't really say for sure. Or perhaps your configuration of 11.1 is sufficiently difference from 11.2. For example nVidia and newer ATI are known to not play well with suspend/resume unless you use their proprietary driver. Can you also tell us what graphic driver are you using if you have either nVidia / ATI?

Best,
Michael C.

**stefanhinz** · 08-Mar-2010, 01:17

Thanks, Michael! Right, my resume problems could be just a quirk with the graphics driver. Is there any way to debug/confirm that?

I'm on an old Dell Dimension 8400 desktop machine here which has an ATI Radeon X300 card. No special or proprietary drivers installed. YaST Hardware Information has quite some information about display resources; anything I should paste here?

I had a possibly related interesting problem after upgrading to Suse 11.2. Switching to a text terminal (e.g. CTRL+ALT+F1) and then back to KDE (CTRL+ALT+F7) would freeze the box completely and reliably. The only way to stop that was by disabling all those nice and shiny KDE 4.x window effects (compiz) that I had so much become used to.

**michael_cheah** · 08-Mar-2010, 01:43

I believe you're running the opensource radeon driver since you're saying that you have desktop effect.

Unfortunately I do not own a ATI x300 chip (or any legacy ATI chip) so testing from my part is out of the question.

But there're few things that you can try:

1)There's a recent online update for the radeon/radeonhd driver. Try running online update and see if that helps to sort out the problems.

2)You can try other s2ram options from init=/bin/bash just in case you have not tried them yet. See S2ram#ATI_graphics_chipsets
In my case the option s2ram -f -a 3 and s2ram -f -p -m works well. If neither works you can try other options as stated in the page. I know it's a painful process to try each and every combination but it's worth the try.

3)Unfortunately AMD has discontinued driver support for ATI chipset before Radeon HD2000 series. So the latest Catalyst version you can get for you card is 9.3. It can't be say for sure that this will work, and would not normally recommend this, but if it works, why not?

There're other options too, such as updating to a newer opensource radeon driver build, but that's beyond my knowledge.

Some output such as dmesg or /var/log/pm-suspend.log might be useful. But if you find something interesting paste it to something like pastebin and not directly to the forum

Best,
Michael C.

Edit: Of course you can also file a bug report, to see if someone who has more technical knowledge can help, since it seems to be a regression.

**michael_cheah** · 08-Mar-2010, 02:03

Sorry, but the recent xorg driver update I told you about only concerns radeonhd driver which is for ATI chip R500 and beyond

You can still try the other suggestion...

**stefanhinz** · 08-Mar-2010, 02:27

Okay, I've tailed /var/log/pm-suspend.log and found some interesting new things that I've pasted here: pastebin - Unnamed - post number 1828345 ... particularly this snippet seems interesting:

Code:

ERROR: no resume parameter on kernel commandline, can not suspend                                        
WARNING: /var/run/pm-utils.inhibit will be created to prevent suspending!

/var/run/pm-utils.inhibit must be a temporary file, since I cannot find it.

I haven't tried the various -a -m etc. options to s2ram yet (I've tried some, though) -- do they really influence resuming? (Remember, suspending works fine with just the -f option.)

Is it possible that the resume problems are simply caused by some kernel misconfiguration that upgrading to Suse 11.2 did? How would I add a resume parameter to the kernel command line? By editing grub?

**michael_cheah** · 08-Mar-2010, 02:35

I haven't tried the various -a -m etc. options to s2ram yet (I've tried some, though) -- do they really influence resuming? (Remember, suspending works fine with just the -f option.)

You should try.. Because in my case it doesn't work with s2ram -f but works with the two I mentioned.

It does influence suspending because getting a machine to suspend is not the biggest problem, but reinitializing the graphic hardware and restoring the states it had before suspending is the bigger challenge. The various -a -m flags will change the behavior of s2ram.

Is it possible that the resume problems are simply caused by some kernel misconfiguration that upgrading to Suse 11.2 did? How would I add a resume parameter to the kernel command line? By editing grub?

It might be.. But adding resume parameter etc is out of my knowledge...

Edit: Wait.. After reading the pastbin output this looks rather interesting, can you provide

su -c 'cat /boot/grub/menu.lst'

it needs root permission to read that file.