Note--if I run "powersave --suspend-to-ram" from the command line, then it does 
seem to work correctly.  Something between kpowersave and powersave messed up?

Something showing up in /var/log/messages in the moment you are clicking suspend
to disk in kpowersave?

If not, please increase debug level of powersave daemon by changing DEBUG="" in
/etc/sysconfig/powersave/common to DEBUG="15", then restart powersave
(rcpowersaved restart).
Try to suspend again with kpowersave and give us the log messages appearing in
/var/log/messages. Thanks.

I see this when I click suspend to ram in kpowersave...

Sep 14 12:38:12 gandalf kernel: eth1: New link status: AP Changed (0003)
Sep 14 12:47:59 gandalf syslog-ng[3910]: STATS: dropped 0
Sep 14 13:03:11 gandalf kernel: usbcore: deregistering driver lmpcm_usb
Sep 14 13:03:11 gandalf kernel: uhci_hcd 0000:00:1d.2: remove, state 1
Sep 14 13:03:11 gandalf kernel: usb usb3: USB disconnect, address 1
Sep 14 13:03:11 gandalf kernel: uhci_hcd 0000:00:1d.2: USB bus 3 deregistered
Sep 14 13:03:11 gandalf kernel: uhci_hcd 0000:00:1d.1: remove, state 1
Sep 14 13:03:11 gandalf kernel: usb usb2: USB disconnect, address 1
Sep 14 13:03:11 gandalf kernel: uhci_hcd 0000:00:1d.1: USB bus 2 deregistered
Sep 14 13:03:11 gandalf kernel: uhci_hcd 0000:00:1d.0: remove, state 1
Sep 14 13:03:11 gandalf kernel: usb usb1: USB disconnect, address 1
Sep 14 13:03:11 gandalf kernel: uhci_hcd 0000:00:1d.0: USB bus 1 deregistered


I'll change the DEBUG flag now and try again.

Bizarre.  I changed DEBUG to 16, restarted powersaved, and now it works fine.  I 
also reset it to empty again and restarted it and it still seems to be working 
fine. 

I'll reboot and try again with DEBUG set to 16.  =:/

bah.  it seems to work fine after a reboot.  Maybe it was caused by /usr/bin/apm 
getting the suid bit taken away from it after the upgrade? 

It seems that this is working fine now.  I guess I'll close it as WORKSFORME, 
though I wish there was a WTF status....

Sorry for the static....

Okay, I am still seeing this.  I'm reopening this in hopes this can get fixed.  
I will try suspending to RAM from the kpowersave applet and (assuming it will 
fail half-way through) attach the logs....

it looks like this is some offspring of bug #106897.
Can you verify that you are really running the latest version from
/pub/people/seife/?
Please post the output of "rpm -qi --changelog powersave | head -n 40"

I also think that this is a duplicate of bug #106897. However, the logs would be
interesting. Especially if there are also lines like:

Info (initHal:44) could not set up connection to system bus: The maximum number
of active connections for UID 0 has been reached

Per #7:

Name        : powersave                    Relocations: (not relocatable)
Version     : 0.10.15                           Vendor: SUSE LINUX Products 
GmbH, Nuernberg, Germany
Release     : 5                             Build Date: Thu 15 Sep 2005 02:01:17 
PM EDT
Install date: Fri 23 Sep 2005 10:22:40 PM EDT      Build Host: mahler.suse.de
Group       : System/Daemons                Source RPM: powersave-0.10.15-5.src.
rpm
Size        : 1226449                          License: GPL
Signature   : (none)
Packager    : http://www.suse.de/feedback
URL         : http://powersave.sourceforge.net/
Summary     : General Powermanagement daemon supporting APM and ACPI and CPU 
frequency scaling
Description :
Powersave gives you control over the ACPI power buttons, three user
defined battery states (warning, low, critical) and supports proper
standby/suspend handling.

Additionally it could control the frequency of your processor if it
supports SpeedStep(Intel) or PowerNow(AMD) technology. This will
greatly reduce power consumption and heat production in your system.

Together with the kpowersave and yast2-power-management package it
should be the preferred power managing application.



Authors:
--------
    Thomas Renninger (mail@renninger.de, trenn@suse.de)
Distribution: SUSE LINUX 10.0 (i586)
* Wed Sep 14 2005 - ro@suse.de

- simplify if cascade in current postinstall

* Wed Sep 14 2005 - trenn@suse.de

- use userspace governor for all SMP kernels
- use hwinfo --smp for that

* Tue Sep 13 2005 - aj@suse.de

- Use hwinfo so that postinstall works even with UP kernel.

Per comment #8:

Holger, I've posted a bunch of logs to bug #106897, including /var/log/messages 
(https://bugzilla.novell.com/attachment.cgi?id=50980), and the second line 
contains exactly the line you were looking for).

Holger, I just looked at the above attachment and it sure looks odd to me.  If I 
follow things correctly, there is a problem with powersave getting information, 
as it keeps changing my CPU speed from 1200 to 1900 and back.  Also, I can see 
the suspend to ram request come through (Sep 27 17:36:39) and it looks like it 
starts processing it, unloads modules, at some point a kernel crash shows in the 
log in the midst of it unloading modules (Sep 27 17:36:41), and then things 
stop.  I see bunches of these:

Sep 27 17:37:36 gandalf [powersave]: Info (initHal:44) could not set up 
connection to system bus: The maximum number of active connections for UID 0 has 
been reached

and I see this:

Sep 27 17:38:39 gandalf [powersave]: WARNING (checkEventTimeouts:1313) Timeout 
for event global.suspend2ram with id 108 reached, removing it.

Hope this helps....

Yes this helps a lot. So this is a duplicate of bug #106897.

If you like you can file a new bugreport for the kernel crash you mentioned above.

*** This bug has been marked as a duplicate of 106897 ***

Okay, I will file a new bug report for the kernel crash.

Thanks for your help Holger!

I just wanted to mention one thing regarding the crash....  I think I've seen 
this before in other distributions.  If I recall correctly, I can get the kernel 
to have a crash/dump/panic/whatever that is not entirely fatal but still 
problematic by doing a cardctl eject while dhcpd is still running.  For whatever 
reason, it seems that if dhcpd is running, then it causes problems when I try to 
either rmmod the kernel module or stop pcmcia services, etc.

What I've found in the past is that if I stop network services (or kill off 
dhcpcd for that interface), then stop pcmcia services, then I don't get any 
kernel problems (or hangs).  Maybe powersave can follow this flow too if it's 
not?  I'm only mentioning this because from /var/log/messages, it looked like 
the pcmcia card was attempted to be ejected while dhcpcd was still running, 
since after the kernel dump, dhcpcd was still spitting out error messages about 
that interface.