I was a bit surprised that there wasn't already a thread dedicated to this.
The "system locks up when resuming from suspend or hibernate" problem is a serious obstacle for me.
My system has switchable graphics (ThinkPad W500), and if the "integrated" video were wired up to drive the DisplayPort (and DVI on mini-dock), I'd be using it because I value suspend/resume that much. (digital output trumps suspend/resume).
Anyway, I'm running Fedora 12 x86_64 with Catalyst 10.5.
I have read a few different suggestions to work around this problem, and I'm hoping you guys can chime in with your experiences.
1) Change HAL fdi so it includes the vbepost and vbestate_restore quirks (I'm suspicious that fedora pm-utils is stripping off all quirks because it believes "the driver can handle it fine". I think that's pretty dumb. If they want to have a rule that strips all quirks for a given set of circumstances, they should do it through HAL where people would expect to see it ...)
2) Change HAL fdi so it includes the s3_mode and s3_bios and dpms_on quirks.
3) Archlinux forum suggested that resume gets broken if a framebuffer is used, so you should add vga=0 to your kernel params.
First off... Can you provide a copy of the dmesg log freshly after boot, and then the log that occurs just after you attempt to suspend the machine. It's possible that the machine has an interrupt which is not being handled properly.
Very polite of me to try to open this discussion and then walk away. Sorry about that! I've been juggling the need to suspend/hibernate (and use the embedded intel video) against the need to drive my external DVI connection (ATI).
It's very strange. /var/log/pm-suspend.log makes it look like I fully resume. It gets through all the pm-hooks, and logs the "Finished." message. At this point the backlight is on, but nobody's home (capslock button doesn't toggle the capslock indicator, etc.). For about 30 seconds, I still see periodic blinks from my wifi light, but after that, it seizes up too.
I've heard a suggestion that this might be a race condition. I know my old RHEL5 laptop setup did in fact shut down all-but-one CPU right at the beginning of suspend. Of course, it was also a lot more verbose about suspend.
When using the onboard intel driver, suspend, hibernate, and resume all work perfectly.