Bug 184033 - Video remains black after resume on Intel i855GM
Video remains black after resume on Intel i855GM
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: hal-info (Show other bugs)
12
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-05 00:38 EST by Uno Engborg
Modified: 2013-03-05 22:45 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:18:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
snippet from /var/log/messages during suspend/resume (5.42 KB, text/plain)
2006-03-05 00:38 EST, Uno Engborg
no flags Details
The first few lines of strace /usr/sbin/vbetool post on Thinkpad R50e (21.06 KB, text/plain)
2006-03-07 14:42 EST, Uno Engborg
no flags Details
Still not working on Thinpad 50e (20.10 KB, text/plain)
2006-03-09 23:06 EST, Uno Engborg
no flags Details
Output from echo 1 > /sys/power/pm_trace; pm-suspend; (open lid) dmesg (25.98 KB, text/plain)
2008-07-17 06:24 EDT, Uno Engborg
no flags Details
dmesg.txt (25.98 KB, text/plain)
2008-07-17 06:28 EDT, Uno Engborg
no flags Details
patch to quirks file for X41 (915 bytes, patch)
2009-07-22 22:19 EDT, Richard Monk
no flags Details | Diff

  None (edit)
Description Uno Engborg 2006-03-05 00:38:06 EST
Description of problem:

On my Thinkpad R50e suspend seam to work, but when I try to wake it up, the
screen remains black. Apart from that the machine seam to be running, and I can
ssh into it.

The machine handles suspend/resume just fine in Ubuntu, so I don't think its a
hardware problem. 

Version-Release number of selected component (if applicable):


How reproducible:
pm-utils-0.13-1

Steps to Reproduce:
1.Select suspend from the gnome menu
2.Hear computer beep and screen go black
3.Shut the lid
4.Open the lid
5.Hear beep as the computer wakes up (exept for the screen)
  
Actual results:
The screen remains black

Expected results:
The screen should have been turned on at step 5.

Additional info:
I run:
kernel-2.6.15-1.2009.4.2_FC5
When I start the computer I get the following entries, that might be relevant to
this, in /var/log/messages:

Mar  5 04:53:07 humlan kernel: ACPI wakeup devices:
Mar  5 04:53:07 humlan kernel:  LID SLPB PCI0 PCI1 USB0 USB1 USB2 AC9M
Mar  5 04:53:07 humlan kernel: ACPI: (supports S0 S3 S4 S5)

I will attach a snippet from the /var/log/messages during a suspend resume
event and also the output from lspci so that you can get some idea of what
hardware the machine is equipped with. Finally I will attach output from
lsmod.
Comment 1 Uno Engborg 2006-03-05 00:38:06 EST
Created attachment 125663 [details]
snippet from /var/log/messages during suspend/resume
Comment 2 Uno Engborg 2006-03-05 00:40:54 EST
The output of lspci:
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to
I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor
to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor
to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated
Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics
Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 01)00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
(rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge
(rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97
Modem Controller (rev 01)
02:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller
02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet
Controller (rev 81)

Comment 3 Uno Engborg 2006-03-05 00:41:57 EST
The output of lsmod:

Module                  Size  Used by
button                  6609  0
i915                   18497  1
drm                    63829  2 i915
ppdev                   8773  0
autofs4                19013  1
hidp                   15937  2
rfcomm                 34517  0
l2cap                  23617  10 hidp,rfcomm
bluetooth              44197  5 hidp,rfcomm,l2cap
sunrpc                136573  1
ip_conntrack_netbios_ns     3009  0
ipt_REJECT              5441  1
xt_state                2241  6
ip_conntrack           49261  2 ip_conntrack_netbios_ns,xt_state
nfnetlink               6489  1 ip_conntrack
xt_tcpudp               3265  8
iptable_filter          3137  1
ip_tables              11657  1 iptable_filter
x_tables               12613  4 ipt_REJECT,xt_state,xt_tcpudp,ip_tables
video                  15045  0
ibm_acpi               25025  0
battery                 9285  0
ac                      4933  0
ipv6                  225569  20
lp                     12297  0
parport_pc             25445  1
parport                34313  3 ppdev,lp,parport_pc
nvram                   8393  1
uhci_hcd               28881  0
ehci_hcd               29005  0
snd_intel8x0m          16077  0
snd_intel8x0           30301  1
snd_ac97_codec         83937  2 snd_intel8x0m,snd_intel8x0
snd_ac97_bus            2497  1 snd_ac97_codec
snd_seq_dummy           3781  0
snd_seq_oss            28993  0
snd_seq_midi_event      7105  1 snd_seq_oss
ipw2200                95633  0
snd_seq                47153  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
ieee80211              28681  1 ipw2200
e100                   33093  0
snd_seq_device          8909  3 snd_seq_dummy,snd_seq_oss,snd_seq
mii                     5313  1 e100
snd_pcm_oss            45009  0
ieee80211_crypt         6081  1 ieee80211
snd_mixer_oss          16449  2 snd_pcm_oss
snd_pcm                76997  4
snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss
i2c_i801                8397  0
i2c_core               20673  1 i2c_i801
snd_timer              22597  2 snd_seq,snd_pcm
hw_random               5849  0
snd                    50501  10
snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore               9377  2 snd
snd_page_alloc         10441  3 snd_intel8x0m,snd_intel8x0,snd_pcm
dm_snapshot            15981  0
dm_zero                 2113  0
dm_mirror              19729  0
dm_mod                 50136  6 dm_snapshot,dm_zero,dm_mirror
ext3                  116169  2
jbd                    52692  1 ext3
Comment 5 Tom London 2006-03-05 14:11:57 EST
I have a Thinkpad X41 with an Intel 915 Express and Intel 82801FB/FBM/FR/FW/FRW
that suffers the same problem.

I patched /etc/pm/functions-intel as below, and got it working again:
--- function-intel.save 2006-03-05 10:45:49.000000000 -0800
+++ functions-intel     2006-03-05 10:40:55.000000000 -0800
@@ -13,8 +13,9 @@
 resume_video()
 {
 (
-       /usr/sbin/vbetool post
-       /usr/sbin/vbetool vbestate restore < /var/run/vbestate
+#      /usr/sbin/vbetool post
+#      /usr/sbin/vbetool vbestate restore < /var/run/vbestate
+       /usr/sbin/vbetool dpms on
 ) >/dev/null 2>&1
 }

A bit of further 'poking' seems to indicate that the 'post' may not be
succeeding.  The output below was produced by adding 'echo' commands around the
vbetool commands in /etc/pm/functions-intel.

vbetool post
Calling INT 0x15 (F000:654B)
 EAX is 0x5F20
Error: something went wrong performing real mode call
vbetool vbestate restore
exiting resume_video

I'm running latest development kernel (2.6.15-1.2009.4.2_FC5) and fully updated
against development tree (AKA Rawhide).
Comment 6 Phil Knirsch 2006-03-06 09:32:59 EST
Hm, could you give it a shot with the following combo in resume_video():

      /usr/sbin/vbetool post
      /usr/sbin/vbetool vbestate restore < /var/run/vbestate
      /usr/sbin/vbetool dpms on

Meaning that we run the post code, restore the state and for all cases during
resume turn on dpms again?

I'm seeing various similar problems with ATI btw where some machines need the
former version (with post and restore) while others need the later (only with
dpms on).

Thanks,

Read ya, Phil
Comment 7 Phil Knirsch 2006-03-06 09:40:41 EST
Oh, and another thing: After you run vbetool post could you do an

  echo $?

Because if vbetool returned something else than 0 we could detect this problem
and possibly act upon it (e.g. using a dpms on then instead of the vbestate
restore or in connection with it).

Read ya, Phil
Comment 8 Tom London 2006-03-06 10:35:24 EST
Just adding 'dmps on' doesn't help.... Still black.

OK... I changed resume_video to:

resume_video()
{
(
        echo "vbetool post"
        ls -l /var/run/vbestate
        /usr/sbin/vbetool post
        echo $?
        echo "vbetool vbestate restore"
        /usr/sbin/vbetool vbestate restore < /var/run/vbestate
        echo "vbetool dpms on"
        /usr/sbin/vbetool dpms on
        echo "exiting resume_video"
) >/tmp/foo 2>&1
}

Here is what is produced:

vbetool post
-rw-r--r-- 1 root root 4864 Mar  6 07:20 /var/run/vbestate
Calling INT 0x15 (F000:654B)
 EAX is 0x5F20
Error: something went wrong performing real mode call
1
vbetool vbestate restore
vbetool dpms on
exiting resume_video

So the 'post' is failing.

I tried a simple 'if test' in restore_video from a text console, e.g.:
resume_video()
{
(
        echo "vbetool post"
        if /usr/sbin/vbetool post
        then
                echo "post succeeds"
                echo "vbetool vbestate restore"
                /usr/sbin/vbetool vbestate restore < /var/run/vbestate
        else
                echo "post fails"
                echo "vbetool dpms on"
                /usr/sbin/vbetool dpms on
        fi
        echo "exiting resume_video"
) >/tmp/foo 2>&1
}

but this failed.... I had to blind-type 'vbetool vbestate restore ...." to get
the screen back.

Seems to me that the 'post' is messing things up...
Comment 9 Phil Knirsch 2006-03-06 10:40:24 EST
Hmm... and if you add the manual vbetool vbestate restore call at the end of the
post failure, does that work?

Read ya, Phil
Comment 10 Tom London 2006-03-06 10:43:01 EST
Sorry, but the above was not accurate.....

The above 'patch' (in comment #8) DOES WORK when you select suspend from the
System menu, but DOES NOT WORK when you test it from a text console (e.g.
ATL-CTL-F1, and just enter the above commands).

Here is the output from the script:

vbetool post
Calling INT 0x15 (F000:654B)
 EAX is 0x5F20
Error: something went wrong performing real mode call
post fails
vbetool dpms on
exiting resume_video

But this seems to make the screen light up again.

Any ideas on what 'post' is doing, and why its different from suspend/restore
than from the text console?
Comment 11 Phil Knirsch 2006-03-06 10:49:07 EST
Well, yes, the difference is that the graphics card is in a different mode when
you're on a text console (text mode, no graphics mode). And on a console you can
even have various modes and/or be using framebuffer, too.

So things are quite different in the various modes.

The problem is only that i don't know of a safe way to detect wether i'm in text
mode, framebuffer or normal video mode. If i had that then it would probably be
possible to have 3 different scripts for the various modes.

Read ya, Phil
Comment 12 Tom London 2006-03-06 10:52:58 EST
OK. I'm leaving functions-intel as in #8.

Seems to work for me on my Thinkpad X41.

Thanks!
   tom
Comment 13 Uno Engborg 2006-03-06 12:44:04 EST
(In reply to comment #7)
> Oh, and another thing: After you run vbetool post could you do an
> 
>   echo $?
> 
> Because if vbetool returned something else than 0 we could detect this problem
> and possibly act upon it (e.g. using a dpms on then instead of the vbestate
> restore or in connection with it).
> 
> Read ya, Phil

Still doesn't work on my Thinkpad R50e.

I commented out all lines in the resume_video() method
suspended the machine by selecting suspend from the gnome menu,
The I resumed by closing and opening the lid.

Then I logged in with ssh and performed the commands that was commented
out in resume_video() manually from the ssh session.


/usr/sbin/vbetool post
Calling INT 0x15 (F000:6843)
 EAX is 0x5F40

As you can see it is different from the other guys X41.
The command never terminates, but the computer is still running and I
can terminate it wiht ctrl-C


Comment 14 Uno Engborg 2006-03-06 12:47:39 EST
By the way, my R50e do suspend/resume properly when running Ubuntu Breezy, so I
suspect it should be doable in Fedora as well.
Comment 15 Phil Knirsch 2006-03-06 12:50:19 EST
Hm, i'll be taking a look at how Ubuntu does it then over the next few
days/weeks, maybe i can figure out what the problem is and can make it work in
Fedora as well for as many models/systems as possible.

Read ya, Phil
Comment 16 Uno Engborg 2006-03-07 14:42:10 EST
Created attachment 125769 [details]
The first few lines of strace /usr/sbin/vbetool post on Thinkpad R50e

As I reported that vbetool post on my my Thinkpad R50e with  Intel Corporation
82852/855GM Integrated Graphics Device (rev 02) never terminated and kept on
executing for ever, I did this strace /usr/sbin/vbetool post, so that you can
see wher it goes wrong.
Comment 17 Phil Knirsch 2006-03-08 03:43:24 EST
OK, great, will be looking at that as well of course.

One thing i've already found in the Ubuntu power management solution is that
they can (if necessary) switch to the text console first before going to suspend
and switch back to the original console (e.g. X11) at resume time.

As soon as i have something new to test i'll post it in here.

Thanks for all the testing already,

Read ya, Phil
Comment 18 Tom London 2006-03-09 09:56:46 EST
Phil,

I think Ubuntu may be on to something.....

Here is my situation: Thinkpad X41:
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML
Express Graphics Controller (rev 03)

I typically run SELinux targeted/enforcing.

With the changes described in Comment #8 above, resume works in Permissive mode,
but not Enforcing mode.

I've worked my way through the policy issues, and I think I've gotten the policy
'adapted' to run vbetool, etc., but it still fails in enforcing mode.

I did notice the following difference: in permissive mode, it goes directly from
the gdm/graphical screen to a text console (for about 1=2 seconds) and then
black.  In enforcing mode, it goes from gdm screen to the 'Fedora bubbles'
screen lock screen first (for about 1-3 seconds).

I'm guessing that this somehow puts the video into a different state, and that
vbetool can restore in one (the text console) and not the other (the 'Fedora
bubbles').

Does that sound reasonable?

Is it worthwhile for me to trackdown why enforcing/permissive changes the
display state during suspend?

tom
Comment 19 Phil Knirsch 2006-03-09 10:15:13 EST
Yeah, that seems to be the case for some models. Ubuntu actually allows that to
be specifically done for models that need it but by default doesn't switch to
text mode.

If you could add the following line at the start of suspend_video() a try:

chvt 12

and add to the end of resume_video() the following line:

fgconsole 7

And see what the various vbetool post / dpms on / vbestate save,restore combos
do that would be great.

Thanks,

Read ya, Phil

PS: fgconsole assumes that your X-server is running on VT 7, which is usually
the default. If thats not the case just put in the correct number (the F-key
number you'd use when switching to the X-server via CTRL-ALT F-X).
Comment 20 Tom London 2006-03-09 11:00:44 EST
Curiouser and curiouser.....

I added 'chvt 12' to suspend_video, and 'fgconsole 7' to resume_video as
described above.

Running in permissive mode, here is the 'log' from resume_video:
     vbetool post
     Calling INT 0x15 (F000:654B)
      EAX is 0x5F20
     Error: something went wrong performing real mode call
     post fails
     vbetool dpms on
     fgconsole 7
     12
     exiting resume_video

So, my reading is that we switch to vt 12 in suspend_video and we transitioned
back to 7 in resume_video.  All good.

In enforcing mode, here is the 'resume_video' log:
     vbetool post
     Calling INT 0x15 (F000:654B)
      EAX is 0x5F20
     Error: something went wrong performing real mode call
     post fails
     vbetool dpms on
     fgconsole 7
     7
     exiting resume_video

Again, my reading of this is that we never switched out of vt 7 (or that we
switched back to vt 7 before entering resume_video) !?

There are no different SELinux messages between the two runs...
Comment 21 Tom London 2006-03-09 11:15:32 EST
Hmmm....

I added some 'logging' to suspend_video.

Running under Enforcing mode, I get:
     chvt: VT_ACTIVATE: Operation not permitted
     Allocated buffer at 0x11010 (base is 0x0)
     ES: 0x1101 EBX: 0x0000

So the 'chvt' is failing.

If I add a 'chvt 12' to the resume_video just before the 'vbetool post', I get:

chvt 12
chvt: VT_ACTIVATE: Operation not permitted
vbetool post
Calling INT 0x15 (F000:654B)
 EAX is 0x5F20
Error: something went wrong performing real mode call
post fails
vbetool dpms on
fgconsole 7
8
exiting resume_video

And I get a gdm login screen!!!
Comment 22 Phil Knirsch 2006-03-09 11:26:59 EST
Hm, thats wierd though. Why should you not be allowed to call chvt in
suspend_video() but in resume_video() you can?

Seems something is horked with the selinux policies here...

Read ya, Phil
Comment 23 Tom London 2006-03-09 11:32:53 EST
Agreed.

I'll get a version of the policy that dumps all AVCs and plow my way through it.

At least now I have something to direct the search.

tom
Comment 24 Tom London 2006-03-09 18:30:59 EST
I received two updated selinux-policy-targeted packages from Dan Walsh.

The first let me 'dump all the AVCs'. It appeared that the policy was not
allowing vbetool to do its thing when running in enforcing mode. A couple of
other hald related issues too.

Dan added some new stuff to create policy selinux-policy-targeted-2.2.23-15 that
allow suspend/resume to function in both targeted and enforcing modes, at least
in my initial test cases.

vbetool still complains about 
Error: something went wrong performing real mode call
but the workaround in the resume_video scriptlet shown in Comment #8 seems to
work now, even in enforcing mode.
Comment 25 Uno Engborg 2006-03-09 23:06:24 EST
Created attachment 125920 [details]
Still not working on Thinpad 50e

The /usr/sbin/vbetool post doesn't terminate on Thinkpad R50e. I don't know if
there is anay changes in the output of the strace, but I attach a new one just
in case. 

I run SELinux permissive in mode, so I wouldn't be affected by SELinux
problems, however I get a allow vbetool_t hald_tmp_t:file if I run audit2allow
on the audit.log. So I suppose there still could be some SELinux problem.
Comment 26 Uno Engborg 2006-03-12 15:54:34 EST
In pm-utils 0.14-1 I think hibernate actually worked on my Thinkpad 50e.   In 
version 0.15-1 it stopped working again. I hadn't time to test it extensively
though before it got upgraded, and now I don't seam to find a0.14-1 rpm anymore.

No change in the suspend behavior though. Bothe 0.14-1 and 0.15-1 refuses to
turn on the screen on wake up after being suspended.

Comment 27 Uno Engborg 2006-07-16 22:23:41 EDT
Managed to get my R50e to suspend by replacing my /etc/pm/functions-intel as
follows:


#!/bin/bash

[ -x /usr/sbin/vbetool ] || return

suspend_video()
{
/usr/bin/chvt 1
/bin/sync
/sbin/rmmod button
cat /proc/bus/pci/00/02.0 > /var/cache/video.config
}

resume_video()
{
cat /var/cache/video.config > /proc/bus/pci/00/02.0
/sbin/modprobe button
/usr/bin/chvt 7

}

lcd_on()
{
(
        /usr/sbin/vbetool dpms on
) >/dev/null 2>&1
}

lcd_off()
{
(
        /usr/sbin/vbetool dpms off
) >/dev/null 2>&1
}


I also modify my /etc/X11/xorg.conf to include Option "VBERestore" "true". My
Device section looks like below:

Section "Device"
        Identifier  "Videocard0"
        Driver      "i810"
        VendorName  "Videocard vendor"
        BoardName   "Intel Corporation 82852/855GM Integrated Graphics Device"
        BusID        "PCI:0:2:0"
        Option       "VBERestore"      "true"
EndSection
Comment 28 Uno Engborg 2006-10-29 11:37:47 EST
The bug also applies to FC6 at least on Thinkpad R50e.
Comment 29 Till Maas 2006-11-13 14:07:07 EST
I have an X41 2525

Suspend to ram works for me, when I change in /etc/pm/functions-intel

resume_video() to:

resume_video()
{
:
#{
#       /usr/sbin/vbetool post
#       /usr/sbin/vbetool vbestate restore < /var/run/vbestate
#} >/dev/null 2>&1
}

(which makes resume_video() do nothing) and with "kernel.acpi_video_flags = 1"
in /etc/sysctl.conf resp. "echo -n 1 > /proc/sys/kernel/acpi_video_flags" before
 run pm-suspend
Comment 30 Matthew Miller 2007-04-06 13:55:43 EDT
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]
Comment 31 Uno Engborg 2007-04-07 20:46:10 EDT
The bug still remains in FC6. 
(Tested on Thinkpad R50e)
Comment 32 Matthew Miller 2007-04-08 14:30:28 EDT
Thanks.
Comment 33 Nigel Cunningham 2007-12-10 17:44:12 EST
Are you able to retest with Fedora 8, please?
Comment 34 Uno Engborg 2007-12-17 14:57:55 EST
I have done some more testing  on Fedora 8 (on Thinkpad R50e), and the bug still
remains in X11.

There is a small improvement though, I am now able to suspend and resume in
console mode. 

The suspend/resume operation is still not functional in X11. I tried to chvt to
a text console before suspending (e.g. chvt 1) and then when resumed go back to
X11 (chvt 7) but that FAILED miserably. The screen was just as black as before.

Comment 35 Till Maas 2007-12-24 07:53:14 EST
Did you try to suspend with "gnome-power-cmd.sh suspend"? This will use the
systems quirk database to suspend. For a list of possible quirks see:
http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html

There is also explained, how you can submit the needed quirks for your machine
to the database.
Comment 36 Uno Engborg 2007-12-28 23:57:55 EST
(In reply to comment #35)
> Did you try to suspend with "gnome-power-cmd.sh suspend"? This will use the
> systems quirk database to suspend. For a list of possible quirks see:
> http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-index.html
> 
> There is also explained, how you can submit the needed quirks for your machine
> to the database.


I have tried that, and it still doesn't work. The behavior is rather random
regardless of what quirks I apply. I also tried the various kernel boot
parameters mentioned on the website you mentioned The most common behavior is
that it actually restores the screen, when I move windows it fails to update
properly, and menus and buttons sometimes doesn't show up until I move the mouse
over them.

The only thing that always happens is that I get an error message in the gnome
terminal window from which i invoke the "gnome-power-cmd.sh suspend" command.

The message reads:

Suspending
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
causes include: the remote application did not send a reply, the message bus
security policy blocked the reply, the reply timeout expired, or the network
connection was broken.



Comment 37 Oleg Mikheev 2008-05-20 18:18:17 EDT
Most probably it's a different bug, but with similar symptoms:
https://bugzilla.redhat.com/show_bug.cgi?id=441334
Comment 38 Uno Engborg 2008-07-17 06:24:44 EDT
Created attachment 312026 [details]
Output from echo 1 > /sys/power/pm_trace; pm-suspend; (open lid) dmesg
Comment 39 Uno Engborg 2008-07-17 06:26:17 EDT
I managed to get my Thinkpad R50e to suspend to RAM, and resume successfully on
Fedora 8. The solution was to use the "i810" display driver instead of the
"Intel" driver that is selected by default on installation.

Unfortunately, the "i810" driver is totally broken in Fedora 9 (it doesn't work
at all,), so that work around isn't available in Fedora 9. However, in Fedora 9
the "Intel" driver manages to successfully suspend to disk (hibernate?) and then
resume proberly when I press the power button.

Suspend to RAM still doesn't work with Intel driver, Fedora 9 and the Thinkpad
R50e. When I do resume the screen remains black and the screen back light blinks.

I have tried to use  the sleep quirk debug method as below:
echo 1 > /sys/power/pm_trace
pm-suspend

dmesg > dmesg.txt 

I include the send the as an attachment dmesg.txt in case it is of any help.




Comment 40 Uno Engborg 2008-07-17 06:28:28 EDT
Created attachment 312028 [details]
dmesg.txt

echo 1 > /sys/power/pm_trace
pm-suspend
(close and open lid, to initiate resume)
dmesg > dmesg.txt
Comment 41 Bug Zapper 2008-11-26 01:56:00 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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
Comment 42 Uno Engborg 2009-01-06 11:21:09 EST
The bug still remains in Fedora 9 and 10. Only now the workaround from comment #40 doesn't work anymore.
Comment 43 Richard Monk 2009-07-22 22:19:50 EDT
Created attachment 354805 [details]
patch to quirks file for X41

Regarding the X41 with:
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

I had the same issue until I tried:
pm-suspend --quirk-vbemode-restore --quirk-s3-bios

Which worked.  Since --store-quirks-as-fdi  doesn't seem to work, I modified /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-ibm.fdi and saved it as /etc/hal/fdi/information/99-local-quirk-file.fdi

restarting haldaemon or rebooting solved the issue for me.  I've attached the diff between 20-video-quirk-pm-ibm.fdi and my local modification.
Comment 44 Bug Zapper 2009-11-18 03:05:55 EST
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
Comment 45 Uno Engborg 2009-11-22 18:59:03 EST
The bug still remains in Fedora 12 in the sense that the screen is still black when you try to resume. However the technology used in Fedora 12 is quite different. E.g it uses the intel driver instead of ithe i810 driver.

In Fedora 11 it was possible to return from suspend/hibernate specifying nomodeset as a parameter to the Linux kernel, but in Fedora 12 this workaround is not possible since doing this will hang the computer.


However. This old bug in its original form lives on in Red Hat EL 5.4, that still uses the old technologhy. So perhaps you should change it to a Red Hat bug instead.
Comment 46 Johan Olby 2010-01-08 07:54:40 EST
Probably fixed by patch in http://bugzilla.kernel.org/show_bug.cgi?id=10985
A register wasn't saved and restored correctly.
Comment 47 Johan Olby 2010-01-21 14:12:44 EST
(In reply to comment #46)
> Probably fixed by patch in http://bugzilla.kernel.org/show_bug.cgi?id=10985
> A register wasn't saved and restored correctly.    

The patch solved the problem for me....
Comment 48 Bug Zapper 2010-11-04 08:17:02 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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
Comment 49 Bug Zapper 2010-12-05 02:18:14 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.

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