Bug 284445 - Spurious (?) error message after resuming from s2disk
Summary: Spurious (?) error message after resuming from s2disk
Status: RESOLVED DUPLICATE of bug 326848
Alias: None
Product: openSUSE 10.2
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Final
Hardware: i686 openSUSE 10.2
: P5 - None : Minor (vote)
Target Milestone: ---
Assignee: Danny Al-Gaaf
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-14 19:00 UTC by Thomas Ruedas
Modified: 2007-11-28 07:22 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 ***