Bug 471711 - suspend and hibernate not working correctly on laptop with radeon XPRESS 200M
Summary: suspend and hibernate not working correctly on laptop with radeon XPRESS 200M
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 513462
TreeView+ depends on / blocked
Reported: 2008-11-15 02:31 UTC by Jeff Layton
Modified: 2014-06-18 07:38 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-03-24 00:04:40 UTC
Type: ---

Attachments (Terms of Use)
dmesg from boot with nomodeset (30.90 KB, text/plain)
2008-11-15 02:31 UTC, Jeff Layton
no flags Details
Xorg.0.log (98.15 KB, text/plain)
2008-11-15 02:37 UTC, Jeff Layton
no flags Details
lspci -vvv output (1.50 KB, text/plain)
2008-11-15 02:40 UTC, Jeff Layton
no flags Details
dmidecode output (9.49 KB, text/plain)
2008-11-15 02:41 UTC, Jeff Layton
no flags Details
dmesg after resume with nomodeset (36.47 KB, text/plain)
2009-09-01 14:01 UTC, Jeff Layton
no flags Details
dmesg output after boot with KMS for Radeon Xpress 200M RC410 system (29.07 KB, text/plain)
2009-12-09 21:41 UTC, Alex Villacís Lasso
no flags Details

Description Jeff Layton 2008-11-15 02:31:04 UTC
Created attachment 323677 [details]
dmesg from boot with nomodeset

In F9, my laptop was able to hibernate, suspend and resume correctly. In F10, it's not working.

While I'm not certain, I suspect that the problems are related to the display. I get slightly different behavior depending on whether not I boot the laptop with nomodeset:

"normal" boot -- without nomodeset:
suspend makes laptop go to sleep, but it will not resume
hibernate fails to ever power off the machine

with nomodeset:
suspend makes laptop go to sleep, but it will not resume
hibernate and wakeup works as expected

Relevant package versions:



Comment 1 Jeff Layton 2008-11-15 02:37:10 UTC
Created attachment 323679 [details]


Comment 2 Jeff Layton 2008-11-15 02:40:17 UTC
Created attachment 323680 [details]
lspci -vvv output

Comment 3 Jeff Layton 2008-11-15 02:41:57 UTC
Created attachment 323681 [details]
dmidecode output

Comment 4 Jeff Layton 2008-11-15 02:44:00 UTC
I can collect other info on request. I can also test packages if desired...

Comment 5 Mads Kiilerich 2008-11-16 00:52:28 UTC
For the record, this is similar to but apparently different from bug 467429

Comment 6 Bug Zapper 2008-11-26 05:25:13 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:

Comment 7 Edmond 2008-12-01 08:44:35 UTC
This seem like a kernel 2.6.27 problem. I saw this since F9 upgraded to 2.6.27 kernel a while back. I solved the problem by revoked back to 2.6.26 kernel. But F10 default w/ 2.6.27 kernel.....

Comment 8 Edmond 2008-12-01 08:45:28 UTC
my T60's hardware profile: http://www.smolts.org/client/show/pub_ebb802c3-8cce-4494-a6e9-30028c386245

Comment 9 Scott Rossillo 2008-12-11 06:55:25 UTC
Any chance of this actually getting resolved soon or should reverting to FC9 be considered?  I have an IBM T60 suffering from this problem.  If you need more information to solve this bug, I'll gladly provide anything you guys need.

On resume, /var/log/messages shows (found after reboot):
kernel: [drm:radeon_resume] *ERROR* 

Resume shows odd patterns on screen and computer totally unresponsive, a hard reboot is necessary.

Comment 10 Mads Kiilerich 2008-12-11 11:45:07 UTC
Scott, I can't speak for airlied, but I know that he has fixed a lot of issues in this area. Have you tried with the latest kernel and xorg? And both with and without nomodeset?

Comment 11 Scott Rossillo 2008-12-11 16:07:08 UTC
Running kernel with nomodeset does seem to allow the laptop to resume from sleep without issue.  I haven't had enough time to see if this affects anything else - other than disabling graphical boot, obviously.

After upgrading to the resume oddness did change slightly (before setting nomodeset), the display corruption looked different but the laptop still required a hard shutdown.

Offer still stands if you need anything from me to get the bug fixed (hw profile, testing a patch, etc).  Thanks!

Comment 12 Matthias Runge 2008-12-11 19:05:51 UTC
The new kernel has still the issues mentioned earlier, so nothing changed :-(

Comment 13 Edmond 2008-12-11 19:14:02 UTC
Same here. I tried the new kernel with and without nomodeset, resume from suspend failed. Also, when nomodeset is on GNOME seem somewhat screw-up. The desktop wallpaper is gone and left with a dark blackhole as the background.....

Comment 14 Matthias Runge 2008-12-12 07:45:10 UTC
/var/log/messages says:
Dec 11 20:48:25 sofja kernel: mtrr: base(0xc0000000) is not aligned on a size(0x3ff8000) boundary
Dec 11 20:48:25 sofja kernel: [drm] Setting GART location based on new memory map
Dec 11 20:48:25 sofja kernel: [drm] Loading R300 Microcode

(probably related, probably not)

Comment 15 Mary Ellen Foster 2008-12-30 14:26:42 UTC
I'm also seeing this on an Acer TravelMate 8100 with an ATI X700 Mobility graphics card.

Comment 16 Mary Ellen Foster 2008-12-30 14:42:06 UTC
Okay, it's not quite the same on the TravelMate in question -- suspend to disk works, but it immediately resumes after the suspend is complete. Suspend to RAM works -- it seems -- but it doesn't resume at all.

Comment 17 Tom Davidson 2009-01-14 22:14:06 UTC
The original reporter couldn't get resume to work even with 'nomodeset'. 

I think that the reports of display corruption after resume on a Thinkpad T60, that *can* be fixed with 'nomodeset' (e.g. Scott Rosillo, possibly also Edmond Hui) may actually be bug 468894 ("modesetting: graphic card not correctly initialized after resume").

Comment 18 Ivo 2009-01-16 15:09:55 UTC
Here is a description of what I have been experiencing with my hardware:

Samsung X22 with ATI Mobility Radeon HD 2400.
video driver: radeon, xorg-x11-drv-ati-6.9.0-63.fc10.i386

1. Suspend
 a) using KMS:
 suspends fine; resume does not work, laptop frozen (not even caps lock works), only hard restart; /var/log/pm-suspend.log has section for suspend only (everything successful) but no section for resume

 b) using nomodeset:
 same as a)

 c) using nomodeset & --quirk-s3-mode
 suspends fine; resumes "fine", but there is a problem - if I suspend once more the following occurs: pm-utils don't work anymore, system restart hangs, a process "events" uses 100% CPU, only hard restart possible;
/var/log/pm-suspend.log has both sections (suspend/resume) and everything is successful

2. Hibernate
 a) using KMS:
 hibernates fine and resumes fine but only once; after a second time see 1c);
/var/log/pm-suspend.log has both sections (suspend/resume) and everything is successful
 b) using nomodeset - not tried yet

I couldn't find anything useful in the logs, but maybe I am looking at the wrong place...

Comment 19 Jeff Layton 2009-01-29 03:16:39 UTC
Just updated my laptop to

With that, the behavior with KMS is still the same as I described in comment 0.

When booting with nomodeset, both suspend and hibernate seem to now work correctly.

Progress, but it would be nice if suspend and hibernate worked correctly with KMS.

Comment 20 Ivo 2009-01-31 22:21:01 UTC
Sorry, but I cannot confirm that on my system (Samsung X22). I have also updated to kernel and with no KMS and no options to pm-suspend (or using the GNOME shortcut for suspend) the laptop freezes upon resuming - even caps lock doesn't work.
If I try pm-suspend --quirk-none (or --quirk-dpms-on) the laptop resumes _seemingly_ fine. However if I try to suspend again (no matter how and what options) nothing happens and the /var/log/pm-suspend.log reads this line:

   >  Inhibit found, will not perform suspend

The system then starts to behave strange, sometimes does not even reboot.

Comment 21 Orion Poplawski 2009-03-23 17:18:25 UTC
I saw kernel: [drm:radeon_resume] *ERROR* messages with but not with 2.6.29-0.64.rc8.git4.fc10 from koji.  My problem now seems to be that the system instantly wakes from hibernate....

Comment 22 Jeff Layton 2009-05-15 12:02:55 UTC
For the record, I'm still seeing this problem on the latest F11 kernels as well. I've moved the laptop to F11, so I'm going to go ahead and move this bug to a rawhide bug as well.

Let me know if you need new info from my laptop since the upgrade.

Comment 23 Bug Zapper 2009-06-09 09:53:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:

Comment 24 Edmond 2009-07-01 19:07:38 UTC
This problem still persists on F11 on a T60, running xorg-x11-drv-ati driver

Comment 25 Jeff Layton 2009-08-14 15:20:44 UTC
Just updated my laptop to rawhide and this is still broken there:


Suspend seems to work, but it resuming does not. Turning the laptop back on just results in a black screen and an unresponsive machine (caps lock light doesn't turn on and off, for instance).

When I try to make it hibernate, the screen goes black, computer goes unresponsive and the machine never powers off.

To make matters even worse, "nomodeset" seems to have no effect now. KMS is enabled even when I specify that parameter on the kernel command line.

I'll happily collect any info that'd help troubleshoot this. I'm just not sure what I need to collect.

Comment 26 Dave Airlie 2009-08-25 10:44:53 UTC
can you try the latest rawhide kernel, make sure you have latest vbetool/libpciaccess installed as well.

can you vt switch to X and try pm-suspend --quirk-none

and resume and see if the console comes back. if you ssh in does network come back?

try this with modeset, nomodeset should also be fixed in latest kernel

Comment 27 Jeff Layton 2009-08-25 19:58:21 UTC
Didn't help...

Patched the machine up to latest rawhide packages:


...booted without nomodeset parm. Switched to vc and logged in as root and ran:

# pm-suspend --quirk-none

...laptop went into suspend mode. Then I hit the power button to bring it back up it powered on but no screen activity and wired networking didn't come back (same symptoms).

Comment 28 Jeff Layton 2009-08-25 20:16:34 UTC
nomodeset now works again (as you mentioned). suspending still works with KMS disabled but resuming gives a black screen. The network is responsive however -- I still have ssh access to the box after resuming.

If I kill X at that point it comes back but the vc screens just remain dark. I was however able to type "reboot" in one of the dark vc's and the box eventually rebooted so it seems like just the screen isn't coming back with KMS disabled.

Comment 29 Dave Airlie 2009-09-01 10:48:07 UTC
can you get dmesg from the failed resume, if you ssh in afterwards?

Comment 30 Jeff Layton 2009-09-01 14:01:19 UTC
Created attachment 359397 [details]
dmesg after resume with nomodeset

Sort of...it's starting to look like there may be multiple, related problems here...

I patched the machine and now when I boot with nomodeset, the machine seems to freeze as soon as X starts. I just get a black screen and the machine goes unresponsive. Booting with KMS enabled seems to work fine, but suspend and resume still don't work.

I changed the laptop to boot to runlevel 3 and booted with nomodeset. I did a "pm-suspend --quirk" from the console. The machine suspended. When the machine resumed, I still get a black screen, but network connectivity returned and the machine seems to be OK otherwise.

This dmesg output is from that session. I don't see much display related stuff in it.

Comment 31 Jeff Layton 2009-09-01 14:06:00 UTC
That was with:


I get the same behavior when I boot earlier kernels too, so the latest problem with X + nomodeset is likely due to something in userspace.

Let me know if there's other info you'd like me to collect.

Comment 32 Dave Airlie 2009-09-01 22:28:43 UTC
oh so if you resume with kms enabled you don't get network? thats the case I'm more interested in.

Comment 33 Jeff Layton 2009-09-02 10:38:31 UTC
(In reply to comment #32)
> oh so if you resume with kms enabled you don't get network? thats the case I'm
> more interested in.

With KMS enabled, the screen is black and the network is unresponsive after resume.

Comment 34 Bug Zapper 2009-11-16 09:37:02 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:

Comment 35 Edmond 2009-11-23 03:35:29 UTC
Just upgrade to F12 using the i686 live CD, the problem still happen when suspend. However, it seem to improve somewhat. The system does not just freeze, I can see a mouse pointer on a messed up screen. i.e. black w/ some garbage pixels here and there.

Comment 36 David Wood 2009-11-27 10:58:10 UTC
Seem to have the same problem with an HP nx9010 (Radeon IGP 340M).  Suspends okay but on resume I get a black screen, unresponsive keyboard, hard reset required.  Have tried with and without KMS (but not explored 'quirks').

Comment 37 Michael Breuer 2009-11-30 02:32:09 UTC
Thank you for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

Fedora Bugzappers volunteer triage team

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

Comment 38 Michael Breuer 2009-11-30 20:26:47 UTC
My denoting this as duplicate seems to have been premature.

Fedora Bugzappers volunteer triage team

Comment 39 Alex Villacís Lasso 2009-12-09 21:39:28 UTC
This bug also affects my system:


01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200] (prog-if 00 [VGA controller])
	Subsystem: Intel Corporation Device d600
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17
	Memory at d8000000 (32-bit, prefetchable) [size=128M]
	I/O ports at ee00 [size=256]
	Memory at fdef0000 (32-bit, non-prefetchable) [size=64K]
	[virtual] Expansion ROM at fde00000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 2
	Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
	Kernel driver in use: radeon
	Kernel modules: radeon

As in previous reports, specifying nomodeset works around the issue when hibernating. I have not tried suspending.

Comment 40 Alex Villacís Lasso 2009-12-09 21:41:25 UTC
Created attachment 377309 [details]
dmesg output after boot with KMS for Radeon Xpress 200M RC410 system

Comment 41 Edmond 2010-02-17 08:12:10 UTC
Don't know what fix it, but noticed a few days ago that suspend and resume work now.

Comment 42 Edmond 2010-02-17 08:13:17 UTC
My setup: Lenovo T60, Fedora 12

Comment 43 Vedran Miletić 2010-03-24 00:04:40 UTC
Closing as worksforme per comment 41. If someone can still reproduce, please reopen.


Fedora Bugzappers volunteer triage team

Note You need to log in before you can comment on or make changes to this bug.