Oh, okay, I misunderstood.

I again ask any forum participants to test their machines and report if they cannot suspend more than once without a reboot. Is this a generic problem or a Slackware problem? A kernel problem or a pm-utils problem? I haven't a clue. Nobody yet has reported anything and without additional data, filing a bug report would be futile.

Should take no more than five minutes of anybody's time to suspend twice. Thanks.

Edit: I have no such problem with PCLinuxOS. I used that system as a test. That would seem to indicate a Slackware related problem, or something wrong with the way I have configured my system. I'm open to troubleshooting suggestions.

What I'm trying to tell you is that it works here. It works for numerous other people. In fact, if it didn't work fine for the VAST majority of the people who use suspend-to-ram regularly, there would be a plethora of easily found google results for the problem. File a bug against the kernel and let the people who know more about the issue ask questions - there's nothing more to do here.

It works fine on my laptop. In fact, I have /etc/acpi/acpi_handler.sh set up like I close the lid a lot since I use it for work.

Edit:
Just out of curiosity, have you tried to write some sort of wrapper script like the acpi_hanler.sh to call pm-suspend after some event or map it to a key? Also, do you maybe have more than one instance of pm-suspend going at once?

These are desktop machines. One running 12.2, the other running Current. Thus I don't have any events configured like closing the lid. I run the script manually. With Current I use KDE 4 and used the suspend option from the Kickoff menu.

I don't think so. I'll check next time to ensure there are no residual processes running after the resume.

Of course suspend works for many people, which is why I am asking for help. If the problem was common I would have found discussions on the web somewhere. I could understand possibly with the 12.2 system as I haven't performed a clean install since 10.0 days --- I have only updated each release on top of the previous release. In that environment I easily could have something misconfigured through the years.

Yet the Current box is a clean install, not even a remnant of KDE 3.5.10. PCLOS on that same box does not exhibit the problem. Thus I doubt the problem is hardware. PCLOS 2009.2 uses a different kernel version than Slackware but suspends more than once just fine. I think I tested suspend with the huge kernel but I'll try that again. Rather than a kernel bug, I suspect something I have done, although with a clean install that pretty much leaves my recompiled kernel or NVidia drivers as suspects. The problem could very well be the NVidia package conflicting with my kernel config. As the generic nv driver doesn't support the chip set on my new box, the only alternative I have is testing with the vesa video driver.

So right now I'm merely seeking suggestions on what I should check that results in this strange behavior.

Did you solve your blank screen problem?

When I played with pm-utils and suspend/resume, I found this:

http://www.thinkwiki.org/wiki/Proble...-180.2A_series

Which was exactly the issue I was having. I ended up using a root terminal and:

Which sorted out my suspend while in X, fwiw. I've had occasional niggles with resuming, but usually related to resuming while the kvm is switched to another PC. You can find my notes on getting myself sorted here: http://pesartain.com/linux/articles/powersaving but I (fortunately) don't have any repeatable problems with suspend/resume.

Sorry I couldn't be more help!
- Piete.

No.

Thanks for helping. My motherboard is an Asus M3N78-EM, which uses an NVidia MCP78S chip set. Thus the fixes for Intel quirks likely will have no effect. I'm dual booting on that box with 12.2 and Current RC2 (I'll update to 13.0 this weekend). For the latter I'm using the 2.6.30.4 kernel because the 2.6.29.x kernel causes problems with the forcedeth driver.

I tested pm-hibernate. I successfully resumed three times consecutively. Yet pm-suspend will not suspend a second time. The box always self-resumes. From my understanding reading about this problem, people most often have problems with hibernate rather than suspend.

I read a blip that some people have had some suspend problems with the same motherboard although I haven't found many descriptions of my problem. I added the pci=nomsi kernel boot option. That seems to help many people but had no effect for me. The box still would not fully suspend a second time.

I won't pretend to understand MSI but some of the problems I have read relate to using the PCI Express bus. I have a TV capture card that uses PCI Express. I removed the card and then again tried pm-suspend. Same results: suspended and resumed fine the first time but self-resumed the second time.

While writing this response I discovered that MSI (Message Signaled Interrupts) is not enabled in my kernel config. I recompiled a new kernel and tested again. Enabling MSI made things worse. The box suspended but upon resume weird things happened. The box took much longer to resume and the system then became read-only. The pci=nomci kernel boot option then worked but I was back to the same problem of only suspending once.

To add to the confusion, my primary office box uses an Asus M2NPV-VM motherboard connected to a Samsung SyncMaster 712N monitor. (I'm using an Acer X193W+ wide screen monitor on the newer box.) I'm running 12.2 with the office box. I can't suspend twice there either but worse, when the first suspend tries to resume, the monitor remains all black with a thin blue line at the top. I can't restore the video display and I can't toggle to any consoles and have to use the kernel magic keys to reboot.

I'm using the proprietary NVidia 180.29 drivers with the office box and the 185.18.31 drivers with the new box. Suspend won't work at all with the office box with the generic nv and vesa drivers. The generic nv drivers do not support the MCP78S chip set and all I can test there is the generic vesa driver, which also won't suspend.

I have tried bypassing pm-utils by using the direct command echo -n mem > /sys/power/state. Same results.

The problem is not hardware because PCLinuxOS 2009.2 suspends and resumes consecutively many times without problems.