Bug 469517

try pm-suspend --quirk-none

to see if it helps.

Dave,

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>
        </match>
(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 
pm-suspend --quirk-none 
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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 
/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-dell.fdi
(belonging to hal-info) does not contain the fix.

Camilo,
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-2.6.27.12-170.2.5.fc10.i686, kernel-2.6.27.9-159.fc10.i686, kernel-2.6.27.9-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
https://fedoraproject.org/wiki/BugZappers

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.