[COLOR="#800000"]hello there.
i have been having this problem since the last couple of months.
something happened or i installed something that is making gdm crash/freeze after the second suspend/resume job. the first one usually works. i have been reading other forums and most of them talk about a real issue on this topic going on for gnome 3, but never for gnome 2.
actually i never had this issue before, it was rock solid and i could put the laptop to sleep 8-10 times in a row with no problems. i have been reading about pm-utils, pm-suspend.log, about virtualbox process probably freezing the graphical desktop and i can’t find a solution. when i go to pm-suspend.log apparently everything is going fine after resume.
as i said, everything was working fine before, even with screen-saver password. then i removed the password option, and it did not work either. basically what it happens is, that my graphical desktop crashes and i can only see my mouse moving but the whole screen frozen. i am suspicious of three possibilities: graphics drivers, firefox & something else.
since i own a hybrid video laptop, i had no problems with bumblebee in the past; and usually when the screen freezes, firefox is running with a high cpu%. it cannot be blamed all on firefox since sometimes it freezes even when it is not running.
i am able to return to the graphical desktop by doing ctrl+alt+backspace to kill gdm and re-login again. the problem is, that i lose everything i was doing; or by going to text mode ctrl+alt+[1-6] and typing as root: $reboot since i don’t know another command to replace the gnome shell, other than ctrl+alt+backspace.
my specs:
dell xps l502x laptop
4gb ram
500hd hdd
sled11sp4 with all updates applied
i am going to try to reproduce the problem by going back to sled11sp3 to see if i am able to experience this problem again.
if you have dealt with this problem before and found a solution, let me know.
i’ll share my results if i find something.
cheers.
[/COLOR]
[COLOR="#800000"]update #1
i have formatted & reinstalled sled11sp4. applied all updates currently available on the subscription repository during the installation process (kernel update, firefox, etc).
it was a brand new installation so no external programs would affect the suspend/resume process, therefore, nothing could go wrong.
i went ahead and tried, and my findings are confirmed. the first suspend works properly. when i try the second time, the gnome2 desktop environment freezes. i could only return to normal by doing ctrl+alt+backspace.
i presume there is one specific update that is corrupting the suspend/resume process for the ctrl+alt+f7 environment.
my second test is to reinstall sled11sp4 and apply no updates at all and start testing suspend/resume several times to verify whether the graphical desktop freezes or not.
i also found, that sometimes instead of suspending/resuming, another way to make the desktop environment freeze is by switching between ctrl+alt+[1-6] and ctrl+alt+f7 several times, back and forth.
will report more on this issue in a few hours…
[/COLOR]
[COLOR="#800000"]update #2
i have formatted & reinstalled sled11sp4 again. on this occasion, i skipped the registration process, meaning that i have skipped all updates altogether.
i tested suspend/resume. everything worked properly. then i started adding/installing my usual programs and putting them to sleep. still all working properly.
so far, today i have already suspended & resumed the same session i am now working on six times already. not a single freeze.
that means that there is a file in the update process that breaks the graphical desktop after suspend/resume.
now i am going to register my subscription, but this time, i am going to be very picky on the updates allowed for installation (so far only firefox updates 
like the old saying goes: “if it ain’t broke, don’t fix it”.
will report with more news as i go along…
[/COLOR]
[COLOR="#800000"]update #3
i have installed all non-critical updates and so far suspend/resume still works properly. i still have the following updates pending to apply, but based on my previous experience, one of these files is/are the one(s) breaking the suspend/resume process. i wish i had “deep freeze” or “system restore” to start testing them one by one and identify the offender(s).
pending updates in my system, as of today:
[LIST]
[]augeas-12153
[]autofs-12086
[]gconf2-12129
[]glibc-12042
[]glibc-12130
[]gtk2-12146
[]kernel source update
[]mkinitrd-12172
[]sax2-12047
[]udev-12044
[]xorg updates x4
[]
[/LIST]
since i don’t have much time to experiment and reformat/reinstall/test all off them in my machine (and i am not sure whether a virtual machine can replicate the issue) i just leave it like this and avoid installing these specific updates.
if you have a way to test, and later go back to normal working conditions, let me know how to do it in order to identify them (out of a hunch, i believe these updates might be the ones that break the suspend process in my xps l502x laptop: gconf2, glibc, gtk2, sax2, xorg; since these affect in some way video or gnome underlying internal programming).
waiting for your comments…
[/COLOR]
[COLOR="#B22222"]update #4
for some reason unknown to me, the system on its own updated all patches (with only one exception, the kernel source update) and again the laptop could not execute the suspend/resume process.
since it is such a hassle to reinstall, i decided to check one by one (by downgrading, restarting, testing suspend/resume, checking package, upgrading, restart & try again) what package from my previous post is the one conflicting with the suspend/resume activity.
after a couple of hours of trial & error, i have found out that the xorg updates are the ones breaking my system:
[LIST]
[]
[]xorg-x11-driver-input
[]xorg-x11-driver-video
[]xorg-x11-libX11
[]xorg-x11-server
[]xorg-x11-server-extra
[/LIST]
i already prevented yast from updating these by right-clicking each package and selecting “LOCK”, and now these packages are shown in yast in a grayed-out pattern.
now, when using the update applet, the applet/yast shows a bunch of errors about being unable to patch these files.
that is good news. i now have a working system once again!!
:o
[/COLOR]