Bug 184033

Created attachment 125663 [details]
snippet from /var/log/messages during suspend/resume

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)

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

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).

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

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

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...

Hmm... and if you add the manual vbetool vbestate restore call at the end of the
post failure, does that work?

Read ya, Phil

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?

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

OK. I'm leaving functions-intel as in #8.

Seems to work for me on my Thinkpad X41.

Thanks!
   tom

(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

By the way, my R50e do suspend/resume properly when running Ubuntu Breezy, so I
suspect it should be doable in Fedora as well.

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

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.

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

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

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).

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...

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!!!

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

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

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.

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.

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.

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

The bug also applies to FC6 at least on Thinkpad R50e.

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

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.]

The bug still remains in FC6. 
(Tested on Thinkpad R50e)

Thanks.

Are you able to retest with Fedora 8, please?

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.

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.

(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.

Most probably it's a different bug, but with similar symptoms:
https://bugzilla.redhat.com/show_bug.cgi?id=441334

Created attachment 312026 [details]
Output from echo 1 > /sys/power/pm_trace; pm-suspend; (open lid) dmesg

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.

Created attachment 312028 [details]
dmesg.txt

echo 1 > /sys/power/pm_trace
pm-suspend
(close and open lid, to initiate resume)
dmesg > dmesg.txt

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

The bug still remains in Fedora 9 and 10. Only now the workaround from comment #40 doesn't work anymore.

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.

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

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.

Probably fixed by patch in http://bugzilla.kernel.org/show_bug.cgi?id=10985
A register wasn't saved and restored correctly.

(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....

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

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.