I am playing with new hardware that eventually will become an HTPC. As an HTPC, suspend-to-ram is a decent feature to include.

The stock Slackware 12.2 includes the pm-utils.

Within KDE 3.5.10 I opened a Konsole window and typed pm-suspend. The box shut down but the power LED blinked continuously. I pressed several keys on the keyboard and moved the mouse but the box did not restart. I pressed the power button and the box restored within several seconds.

Well, that was easy. The box uses about 5 watts when in suspend mode as opposed to about 42 watts when idling in KDE.

Same KDE session, same open Konsole window. I waited about 30 seconds after restoring and then repeated the same command. The box started to shutdown, the power LED started blinking, but the suspend never completed and the box restored itself. I did not press the power button. Kill-A-Watt meter indicated no change in consumption. Weird.

I rebooted and again ran the pm-suspend command from within Konsole. Same excellent suspend and restoration result. This time I waited five minutes. I then again tried the command. Same non-suspend result. The machine started to suspend but the fans never stopped, wattage never changed, and the box restored itself.

I rebooted. I did not start KDE. At the console I typed pm-suspend and pressed the Enter key. The box shut down as previously. Same 5 watts and blinking LED. I pressed the power button. The box restarted. My Kill-A-Watt verified the suspend and restart. However, I never saw a video display. I could SSH into the box and connect to NFS shares, but the box would not display any video. Toggling into other consoles (Alt-F2, etc.) had no effect. No video. Weird.

I ran the "quirks" shell script and no quirks were reported.

I notice nothing peculiar or obvious in the pm-powersave.log or pm-suspend.log.

Hardware:

Asus M3N78-EM motherboard, AMD 5050e 2.6 GHz Dual Core CPU, Western Digital WD6400AAKS hard drive, Lite-On iHAS324-08 24X SATA DVD, HDMI, DVI-D, VGA. On-board Nvidia 8300 video. I'm using the proprietary 180.29 drivers.

I'm using a very old Viewsonic 7 CRT monitor because that is all I have for a second monitor. The monitor does not support DPMS or EDID --- very old.

Questions:

Should the power LED keep blinking when in suspend mode? That would be obnoxious in a quiet living room. Is there a way to stop the blinking (other than lifting the connector)?

Is there a way to restart the box using the keyboard or mouse rather than the power switch? I have verified that wake-on-keyboard works with this box.

Why doesn't suspend work with subsequent attempts?

How do I ensure my video is restored when I run pm-suspend from a console (without X/KDE)?

Thanks again.

Update: I tried the same thing with my office box. With that box I use a Samsung SyncMaster 712N LCD monitor. The monitor supports DPMS and EDID.

From within Konsole the box suspended but upon restoration, I did not see the KDE desktop. I saw a screen that looked like a blank screen saver with a thin blue line across the top. I could toggle to alternate consoles but nothing restored the KDE desktop. I could press Ctrl-Alt-Delete to exit KDE and that worked fine, which then I restarted X/KDE.

From the console (without X/KDE), the same no-video problem occurs upon restoring. I can SSH into the box and connect to NFS shares but no video. Alternate consoles were unavailable too. The monitor power LED kept blinking, which indicates no video signal.

The quirks shell script reported no quirks found. I am using the proprietary nvidia 180.29 drivers.

It appears that you have nVidia graphics in both machines. I suggest that you have a look at the nVidia documentation under /usr/doc. From Appendix Q in the documentation for my graphics:
This is true for my laptop! The fix that works for me is to add
to the device section for the nVidia video card in my xorg.conf.

Thanks for trying to help but the option had no effect.

I'd be grateful if anybody would share their experiences with running pm-suspend more than once in succession.

Also why pm-suspend will not restore the video when run from console (no X/KDE running).

Thanks much.

The power led blinking continuously implies a kernel panic, which tells me that there's almost certainly some module that doesn't like being suspended. Here's what I would do:
First, try this (even though it doesn't address the kernel panic):
That will put an empty fdi file to override the default one at /usr/share/hal/fdi/information/10freedesktop/21-video-quirk-nvidia.fdi -- my memory of the discussions with upstream tell me that the information in that fdi file is incorrect, and that the quirks *are* needed for nvidia hardware.

If that doesn't work, or even if it does, try this:
1. Build newer hal-info on the 12.2 system and upgrade it.
2. Build newer pm-utils on the 12.2 system and upgrade it.
You can use the build scripts from -current if you change the makepkg line to build a tgz instead of a txz, but you'll also have to get the source tarballs in a gzip'd or bzip2'd compression if they're xz'd in our tree.

Now try again and see what happens.

We still haven't addressed the kernel panic issue, and quite frankly, the easiest way to handle that is to ignore it :-) In other words, try building a newer kernel and see what happens.

Edit: after reading back over the original post, maybe the led blinking is *not* a kernel panic, but I'm not sure what's going on with that :/

Hi Robbie,

I created the new hal information file. I then ran pm-suspend from Konsole.

The power LED again blinked. I understand that when the kernel panics the keyboard LEDs blink, but I'm unsure the blinking power LED indicates a panic. I understand the usefulness of the blinking, but I also appreciate not having the LED blink. I don't know whether the blinking is an effect of pm-utils or the BIOS.

Although wake-on-keyboard functions on this box, the only way I could restore from suspend was pressing the power button. I don't know whether that is by design or a bug. Seems odd to me that the +5V standby is available to the keyboard when powered down but not during suspend. Just weird to me.

The system restored as I expected.

I then waited for the system to settle for a couple of minutes. Then I again issued the pm-suspend command. The system started to suspend, the power LED started blinking, the monitor indicated "no signal," but the box would not stay suspended and again self-restored.

I would be grateful if you or anybody else can report the same event of not suspending the second time. Just weird.

Not previously reported by me, but I had already built and installed pm-utils 1.25. While writing this response I built and installed hal-info from Current but for 12.2. Same results. I rebooted, just in case. Same results.

I'm doing that as I post this message. I need a newer kernel for a different reason --- supporting audio through HDMI.

So my original questions remain:

Questions:

1. Should the power LED keep blinking when in suspend mode? That would be obnoxious in a quiet living room. Is there a way to stop the blinking (other than lifting the connector)?

2. Is there a way to restart the box using the keyboard or mouse rather than the power switch? I have verified that wake-on-keyboard works with this box.

3. Why doesn't suspend work with subsequent attempts?

4. How do I ensure my video is restored when I run pm-suspend from a console (without X/KDE)?

Thanks again.

1. Most of the time when a system goes into Standby or hibernate the power LED will blink. This has been the case on my last 4-5 PCs that I have owned and over several OS's. There is no way that i know to get rid of the blinking other than lifting the connector.

2. To do a keyboard restart set a key combination in your BIOS to trigger it or do a power-on trigger (if your BIOS supports it)

3 and 4, I have no clue

I haven't yet read anything to contradict you. As I mentioned, I understand the blinking as a signal, but I think such a feature should be user-defined.

Wake-on-keyboard works great with this motherboard just not during a suspend-to-ram. I would have thought wake would work then too but apparently not.

Ohhhhhhhh. I was stuck in "you have a laptop, so everyone has a laptop" mode. I was picturing the leds on laptop blinking rather than the actual power button blinking. Yes, I know, it's obvious after re-reading, but you know how that goes sometimes. As C-Sniper stated, I think that's normal behavior, and I don't know any way to disable it -- it happens on my desktop machine too, but it's in a cabinet, so I don't notice...

Re the keyboard-triggered wakeups, I recall reading about someone else wanting that (on lkml iirc), but I don't recall if there was a solution or what it was - sorry.

Re the suspend failing after the first successful attempt, I've seen a few reports of that on LKML, but I was thinking that they were all regressions in 2.6.31rc kernels - maybe not. Either way, definitely try a newer kernel -- if it's a kernel thing, there's not much you can do about it otherwise.

Re getting video output on resume, two suggestions:
1. newer kernel again :-)
2. see the docs in /usr/doc/pm-utils-*/README.SLACKWARE or whatever it's called - follow the links in there to where adding quirks is discussed.

Well if you have VirtualBox with a Windoze installation on it I can give you a BIOS editor if you want to try

I just installed 13.0/Current on my new box. The hardware specs:

Asus M3N78-EM motherboard, AMD 5050e 2.6 GHz Dual Core CPU, Western Digital WD6400AAKS hard drive, Lite-On iHAS324-08 24X SATA DVD, HDMI, DVI-D, VGA. On-board NVidia 8300 video (MCP78S chip set). Acer X193W+ 19 inch 1680x1050 monitor.

Using the Xfce 4.6.1 power manager applet, I suspended-to-ram. Worked as expected. Yet oddly, like my original report, I cannot suspend a second time. The system auto-restores itself. Thus, this problem would seem related to the motherboard BIOS or the NVidia drivers. I was using the 180.29 drivers in my original post but in this test I am using the 185.18.31 drivers.

Using the vesa driver is useless because when the system restores there is no video at all. No toggling to alternate consoles either.

In this last test I used an almost pristine stock 13.0/Current install.

Anybody have a clue what causes this second attempt to fail? Ideas how to troubleshoot further?

This weekend I tested KDE 4 for the first time with Current. I used the suspend to ram option from the kickoff menu. The machine suspended. I then performd the same task several minutes later and once again, like all of my previous reports, the machine started to suspend but stopped and restored itself.

I seem unable to perform a suspend to ram a second time on this machine.

Is there some kind of BIOS setting that could be causing this action? A kernel config option? I really want to get suspend to function correctly as this machine eventually will be an HTPC.

Robbie, Would you please paste the text? I don't have an account at kernel bugs and don't want to create one. Thanks.

I don't see an existing bug report - that link is to file a *new* one, and you'll *have* to create an account.