Bug 669952

Created attachment 473682 [details]
Output from pm-utils-bugreport-info.sh

pm-suspend is failing from runlevel 5, right?

Please also try (from runlevel 5):
# echo mem > /sys/power/state

Maybe bug in i915 driver. I am going to get the T400 for testing.

Yes, pm-suspend is failing from runlevel 5
It works repeatablely at runlevel 3

I tried echo mem > /sys/power/state from runlevel 5 as requested.

The first time it froze my system with a blank screen (I don't believe the sleep LED started flashing). I had to power reset to recover.

I've tried it again and this time was able to successfully suspend and resume 6 times in a row now.

Let me know if I can try anything else...

Thanks, Mark

> I tried echo mem > /sys/power/state from runlevel 5 as requested.
> 
> The first time it froze my system with a blank screen (I don't believe the
> sleep LED started flashing). I had to power reset to recover.

Probably kernel problem.

> I've tried it again and this time was able to successfully suspend and resume 6
> times in a row now.

But this points to pm-utils.

> Let me know if I can try anything else...

I am waiting for the T400 machine to debug this. In the meanwhile you can try disabling the pm-hooks one by one (especially the 98video-quirk-db-handler and the 99video) to isolate the problematic hook, e.g. create file under /etc/pm/config.d with the blacklisted hooks:
HOOK_BLACKLIST="98video-quirk-db-handler 99video"

I tried isolating the hooks with a conf file under /etc/pm/config.d, as requested.

It still fails with
HOOK_BLACKLIST="99video"

but success (6 times in a row) with
HOOK_BLACKLIST="98video-quirk-db-handler"

I think I have the same or a very similar problem.  I just replaced my Fedora 11 partition with Fedora 14.  After updates, the kernel is:
kernel-2.6.35.12-90.fc14.i686 

and pm-utils is:
pm-utils-1.3.1-4.fc14.i686

First (and so far only) thing that doesn't work was suspend. i.e. screen fades but fan and drive do not shut off; the only way to recover is by holding down the power button until a hard boot. The is a HP G70-246US notebook.

After looking around I came across this thread.  Sure enough, my machine will suspend and recover using: "echo mem > /sys/power/state"  And, pm-suspend does work using the above HOOK_BLACKLIST="98video-quirk-db-handler"

pm-suspend also works, without blacklisting the hook, from a getty, however the system locks when I Ctrl+Alt+F1 back to the graphical interface after resume.

If it's any help, lspci shows:

Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

as the display device.

I'm using the blacklist solution for now.
Thanks,
Robert

For what its worth I resolved the problem.

It turns out I was wrong, blacklisting the hooks was a red herring. Instead, "echo mem > /sys/power/state" seems to somehow "prime" the suspend function so it will work maybe 5 times.  It fails every time, as described above, without being thus "primed." I tried PM_DEBUG=true, but there were no errors with or without the blacklisted hooks.

However, I found two errors in dmesg which begin:

[drm:init_ring_common] *ERROR* render ring head not reset to zero ctl  ....
[drm:init_ring_common] *ERROR* render ring head forced to zero ctl ...

Searching on these, I found some comments in an Ubuntu forum indicating it was a kernel problem.  I downloaded and installed the Fedora 15 kernel rpm package, kernel-2.6.38-26.rc1.fc15   Now, dmesg errors are gone and system suspends and resumes as expected.

Of course, I don't know if my problem was the same as the original post. 

Thanks again,
Robert Flory

Well, I am a bit confused now. 

Re comment 1:
It seems it uses KMS and --quirk-no-chvt. The --quirk-no-chvt is added by 98video-quirk-db-handler and processed by 99video quirk, e.g. no chvt is done, because it is not needed with KMS, same as with "echo mem > /sys/power/state".

Re comment 5:
The 98video-quirk-db-handler should only grab the quirks that would be used by 99video. It doesn't perform any destructive operation. Thus if there is something wrong with the quirks, blacklisting the 99video should have the same effect as blacklisting the 98video-quirk-db-handler. So I guess that the observed behaviour could be accidental.

Re comment 6:
It looks like i915/drm problem, but I cannot understand why it works with blacklisted 98video-quirk-db-handler or "echo mem > /sys/power/state". Is this behaviour 100% reproducible? It would be helpful to have debug output of failed run (e.g. with PM_DEBUG=true or bash -x pm-suspend). Otherwise I have no idea, what could be wrong in pm-utils.

F14 is EOL. Still an issue for F16/rawhide?

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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