On Thu, Jun 28, 2007 at 02:08:15PM +0000, Pavel Machek wrote: > > > The results are a bit unclear, I took a 2.6.22-rc4 with beep. > > > Logged into KDE. > > > (hardware: Dell Latitude D810) > > > > > > S = successfull resume > > > D = had to resume 2 times, that means when pressing the power button the > > > LED goes from blinking to on and after a few seconds it goes back to > > > blinking, but without a beep in between; after pressing the power button > > > a second time resume is successfull > > > F = resume failes, NO beep > > > > > > -run 1: D D F > > > -run 2: D D D(some X garbadge) F > > > -run 3: S S S S S S F > > > -run 4: S S F > > > -run 5: D F [..] > It may well be different problem :-(. 100KB diff and I'm not an acpi > expert :-(. > > I just discovered I have problems with s2ram, too, but it looks like > usermodehelper is responsible. Now i think it is a userspace problem, more exactly something in KDE. I got a new laptop(a Dell D830) and discovered that suspend works with gnome and when i directly run /etc/acpi/sleep.sh. (with KDE running, from a xterm... but so somehow it can't interact with the KDE userspace stuff) (i have no remote idea what KDE is doing) So i tried sleep.sh also on my old laptop (D810) once again and it works reliable, well at least for 13 times. Directly afterwards i tried the suspend to ram button again and it failed again as stated above. Can someone else with suspend problems and KDE verify this? i filled a bug against KDE in ubuntu: https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/131855 Christian Leber -- You are searching some interesting studies? http://www.ziti.uni-heidelberg.de/ :-) - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html