Bug 284445

Summary:	Spurious (?) error message after resuming from s2disk
Product:	[openSUSE] openSUSE 10.2	Reporter:	Thomas Ruedas <ruedas>
Component:	Basesystem	Assignee:	Danny Al-Gaaf <dalgaaf>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Minor
Priority:	P5 - None
Version:	Final
Target Milestone:	---
Hardware:	i686
OS:	openSUSE 10.2
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Thomas Ruedas 2007-06-14 19:00:28 UTC

While suspend to disk basically works, I usually get an error message window in KDE telling me that "Suspend failed"; however, everything normally seems to work, so that this message is apparently pointless and misleading. The only thing that does indeed fail frequently is the screenlock which is supposed to be active after resuming.
I also find that keeping even a single ghostview window open when suspending uses to make the machine resume immediately, apparently because of insufficient space for writing on the disk. This did not happen before with SUSE 10.1, so although I don't know if the cause is related to the glitch described above, I suspect that both things have to do with using pm for suspending as of SUSE 10.2.
Hardware: Fujitsu-Siemens Amilo Pi 1536, 1 GB RAM; 1.5 GB swap

Comment 1 Forgotten User ZhJd0F0L3x 2007-09-11 10:27:50 UTC

Hi, sorry for the long delay.

Does this still happen with all the recent online updates installed? We had such a problem in 10.2, but i am quite sure it has been fixed with a HAL- and/or kpowersave update.

Comment 2 Thomas Ruedas 2007-09-24 17:40:56 UTC

Yes, it seems so. My hard disk broke a few weeks ago (hence the delay with my response), and now that I got the replacement, I installed the system anew with all recent updates, but the symptoms remain. To be more precise about the failing screenlock: my impression is that if you don't touch the system until the whole unfreezing is completed, the screenlock will sometimes (or maybe even usually?) get going, but if you hit e.g. the return key after the desktop stuff has become visible, but before the screenlock/screensaver is activated, then you can prevent it from being activated at all. As this time window is several seconds, it is actually pretty much pointless that the screenlock is eventually activated at all.
BTW, the partly disfunctional network connection after rethawing from a suspend-to-RAM, which I reported in a separate report and is maybe also due to HAL and/or kpowersave, is also still there.

Comment 3 Danny Al-Gaaf 2007-11-27 12:20:17 UTC

In which cases do you get the "Suspend failed" message: How did you suspend? via KPowersave, KDE menu, power/suspend buttons? Was there a long time between suspend and resume?

Comment 4 Thomas Ruedas 2007-11-28 00:01:44 UTC

My Window Manager is KDE, and I use the KDE menu (Button "Leave"->Suspend to Disk). There's usually 10-12 hours between suspend and resume (i.e., overnight).

Comment 5 Danny Al-Gaaf 2007-11-28 07:22:20 UTC

Okay, again the DBus timeout. Should be fixable if the KDE guys do what proposed in bug #326848

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