Red Hat Bugzilla – Bug 469517
Resume from suspend broken (ATI M300, Dell Inspiron 6000)
Last modified: 2009-12-18 01:43:34 EST
Suspend and resume has been very stable in F9 kernels but in the F10/rawhide it is broken.
Broken as recently as in the kernel-18.104.22.168-68.fc10.i686 and xorg-x11-drv-ati-6.9.0-38.fc10.i386 / xorg-x11-server-Xorg-1.5.2-10.fc10.i386
How reproducible: on every suspend/resume
Steps to Reproduce:
1. Upgrade to F10/rawhide using preupgrade
2. Boot and log in.
3. Close lid, system suspends. Reopen lid
Actual results: single beep followed by flashing blue and yellow pinstripe/barcode effect. System is unresponsive (caps lock key - no response). Have to power cycle.
Expected results: system resumes and functions normally as on F9
Additional info: Smolt hardware profile: http://www.smolts.org/client/show/pub_44edc881-6d87-4d54-b878-9dda238ef4d0
The display is a largeish 1920x1200 panel, the machine has 2Gb RAM if
that makes a difference.
Please let me know if I can be of help with debugging or testing fixes.
try pm-suspend --quirk-none
to see if it helps.
thanks, I'm pleased to confirm that worked. Do I have to deconfigure some quirks for this hardware? TIA!
Created attachment 323284 [details]
/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi for Inspiron 6000
Suspend/resume works with this addition:
<!-- this needs no quirks -->
<match key="system.hardware.product" contains="6000">
<merge key="power_management.quirk.none" type="bool">true</merge>
(in the Inspiron section)
I should mention, the model with the problem has an upgraded graphics card. The behaviour of the stock model might be different, so this change should really be tested on a stock Inspiron 6000 or made specific to the model with the Radeon card.
It may be related:
Resume from suspend on a Thinkpad T43 (with Ati Graphics) is unreliable. I'll try
as soon as I get the hardware under my fingers.
A possible reason is, F10 uses the radeon framebuffer, F9 did not.
As a further note, recent updates have broken resume again for me (in a different way). I haven't managed to track down the culprit but will post a new bug soon.
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:
adding nomodeset to kernel command line fixes this issue for me.
I am having this problem too, on an Acer Ferrari 4000 (x86_64, ATI RS480 chipset and an ATI X700/R420 graphics chip).
If kernel modesetting is enabled, the laptop hangs on resume. X is also much slower, and enabling desktop effects causes a hard lock.
I guess this feature isn't quite ready for prime-time?
I can confirm the problem hitting here as well. I am having ATI Technologies Inc M56GL [Mobility FireGL V5200] on an IBM thinkpad, T60p. I can confirm that pm-suspend --quirk-none works.
Switching component to hal-info since
(belonging to hal-info) does not contain the fix.
Could you confirm that you still see the bug in F10 ?
Dave, I'll keep you in CC.
François, actually the suspend / resume has been working fine for the last few kernels in F10, kernel-22.214.171.124-170.2.5.fc10.i686, kernel-126.96.36.199-159.fc10.i686, kernel-188.8.131.52-155.fc10.i686. That's with no fdi quirks alterations over hal-info-20090202-1.fc10.noarch, and no special boot cmdline. Graphical boot / modesetting working fine.
I have the Radeon X300 graphics, I'm not sure if the stock Inspiron 6000 with Intel graphics is OK or not.
Cam, thanks for reporting.
Reassigning to kernel / airlied and closing as CURRENT_RELEASE.
This particular bug was fixed and updated packages were published for download. Please feel free to report any further bugs you find.
You can obtain the updated package by typing 'yum update' or using the
graphical updater, Software Update.
Fedora Bugzappers volunteer triage team
I haven't been using suspend/resume for a while (broken battery forced me to hibernate instead) and I missed suspend/resume being broken for this same hardware somewhere between F10 mid-life and F11
Normal suspend hangs hard at resume, just after entering the BIOS password, with no disk activity and an unresponsive caps lock light.
If I check the enabled quirks:
[root@pricey ~]# lshal |grep quirk
power_management.quirk.dpms_on = true (bool)
power_management.quirk.dpms_suspend = true (bool)
power_management.quirk.vbe_post = true (bool)
power_management.quirk.vbemode_restore = true (bool)
power_management.quirk.vbestate_restore = true (bool)
power_management.quirk.vga_mode_3 = true (bool)
IF I suspend without the quirks, it's fine.
[root@pricey ~]# pm-suspend --quirk-none
By disabling these quirks the suspend works. It looks like my comment #3 fix is needed again?
How can this fix be made permanent in the software?
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.