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