Red Hat Bugzilla – Bug 246555
suspend2ram does not wake up on FC7 (OK in FC6) IBM T60
Last modified: 2008-02-15 21:18:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:126.96.36.199) Gecko/20070603 Fedora/188.8.131.52-2.fc7 Firefox/184.108.40.206
Description of problem:
System is an notebook IBM T60 with FC7(update from FC6)(language german). If I choose the option suspend2ram (in german "Ruhezustand") using KLaptop the system goes into the suspend2ram state (display off, fan off sleep LED on) if I close the display or choose "go into suspend2ram". If I open the display, only the fan wakes up, display stays dark, sleep LED stays on. This is since i did the update from FC6 to FC7.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Config see description
This looks like a kernel bug to me, reassigning.
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
I'm now running Linux 220.127.116.11-76.fc7 . The last message is stopping tasks .. done
suspending console(s) ant then the system freezes. I'dont know, weather it runs
in the tuxonice kernel.
You might want to try the following and post back any output as attachments to
# Find out if the system is locked up completely by hitting the caps lock key.
* If the capslock light doesn't toggle, the system is completely dead. Try
again, but this time before suspending, activate the pm_trace functionality with
echo 1 > /sys/power/pm_trace. This reprograms the real time clock to contain a
few bytes of information which we can use to diagnose which driver failed to
resume. After the hang, reboot, boot up again, and save the output of dmesg.
* If the capslock light does toggle, then the system did come back up, and
it's possible that we just failed to reinitialise the video.
http://people.freedesktop.org/~hughsient/quirk may contain further useful
information to diagnose this problem. It may also be useful to initiate the
suspend from a tty (ctrl-alt-f1) and run pm-suspend ; dmesg > dmesg.out ; sync
by hand. Upon resuming you'll now have some more debug info to sift through.
Additionally, this way when it resumes, you already have a console logged in
from which you can type commands 'blind'. Trying vbetool post for example may
bring things back to life.
# Try rmmod'ing various modules before doing the suspend. If this makes things
work again, retry with a smaller set of modules unloaded. Keep retrying until
you narrow down which module is to blame.
# Another trick that sometimes works to force video to come back up is to enable
the BIOS password. This makes the system resume in a VGA text mode that the
kernel recovers from a lot easier. Not a real solution, but it can help to
diagnose other problems.
Did you have any success with the above? Could you attached output as text/plain
from the following:
# lspci -vvxxx
If you are running an nvidia card with the 'nv' driver then you should not
expect suspend to work as there are numerous issues with it.
Closing as per previous comment. Please re-open if this is still an issue for you.