Red Hat Bugzilla – Bug 264141
Resume occasionally fails on Toshiba Satellite M35X laptop
Last modified: 2008-06-16 22:16:03 EDT
Today on my way into work I put my laptop to sleep several times
(using the menu item System -> Suspend) and woke it up several times
(using the glowing power button). When I arrived at work, the machine
failed to successfully resume. I was able to switch virtual consoles,
but unable to log in. When I switched to the X console (F7), I saw a
mouse cursor which I could not move, and the desktop background, but
no xscreensaver prompt. I hit CTRL-ALT-DELETE, but aside from a
message printed on the console, this seemed to have no effect, so I
had to hold down the power button to hard-reboot the machine.
For the record, I have a wireless card which I detach before I leave
the house. On the subway, I have no network connectivity, and I woke
up the laptop before I plugged in my Ethernet cable at work.
I have attached the portion of /var/log/messages from the time of my
commute, and a Smolt hardware profile. It looks to me like some of
the timestamps from when the laptop resumes reflect the time when the
laptop was going to sleep, so it's difficult for me to tell exactly
where the sleep process stops and the resume process begins.
Created attachment 179401 [details]
/var/log/messages excerpt, Smolt profile
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 so, you might like to
test some of the following to help developers troubleshoot the issue:
# 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.
# Proprietary 3d graphics driver users should test with respective open source
# Laptops using the nv driver should be considered hibernate-only capable as per
If the problem no longer exists then please close this bug as CURRENTRELEASE
indicating what resolved it for you or I'll do so in a few days if there is no
additional information lodged.
With the kernel that was current at the time this bug was reported, I actually
experienced a hard system lock-up upon insertion or removal of the wireless
card, in addition to the problem resuming from sleep.
I haven't experienced any problems recently with kernel-184.108.40.206-91.fc7, even
after trying some repeated resume/suspend and insert/remove cycles. I'm
guessing either the underlying problem was fixed, or it's not easily reproduced
(perhaps because it involves a near-simultaneous sleep/remove or resume/plug-in).
I'll keep the advice posted above in mind in case I do experience any future
Okay Christopher, good to hear the problem appears resolved for you. Could you
close CURRENTRELEASE with kernel-220.127.116.11-91.fc7 as the version that resolved it
if you feel this is appropriate.
I guess I'll do that and re-open if it happens again.
Ah, I spoke ever-so-slightly too soon. I experienced this problem
Yesterday I played with repeatedly inserting and removing the wireless
card and sleeping and resuming the laptop, will no ill effects. I
don't think I've rebooted or logged out since then.
Today I went to work as normal, unplugging my wireless card, power,
and mouse around the same time I put the laptop to sleep, and then
plugging in wired Ethernet, power, and mouse at work. I departed
work, unplugging cables, but when I arrived at the subway, I
experienced problems resuming.
After I pressed the power button (which pulses amber when the laptop
is asleep), the button turned blue (which is normal) and the screen
went through its usual flashing and spewing text. It got stuck on a
text-only screen full of resume output.
I pressed the Caps Lock key, and the light on that key lit up. I
pressed the key again, and the light did not go back out.
I pressed Ctrl-Alt-F1 and found a waiting login. I was able to give
my username and password. The login process got as far as giving me
the time of my last login before getting stuck.
I pressed Ctrl-Alt-F7 and found the screensaver's password dialog. I
pressed the Caps Lock key a few times, and the "You have CAPS LOCK on"
message appeared and disappeared, but the light on the key did not go
off and on.
I typed in my password and the dialog box showed the "Checking..."
message before it, too, got stuck.
I pressed Ctrl-Alt-F1 again, but by this point, everything including
the mouse and the power button were completely frozen. I had to pull
the battery out of the laptop in order to reboot.
I will attach the system log from yesterday's reboot to hang. It has
lots of what I assume are nuisance warnings, and more serious-sounding
Oct 4 18:09:03 localhost kernel: WARNING: at drivers/net/wireless/b43/xmit.c:73
b43_plcp_get_bitrate_ofdm() (Not tainted)
Oct 4 18:19:20 localhost kernel: attempt to access beyond end of device
though I have no idea whether or not they are related.
Let me know if there's anything in particular I should do to obtain more
Created attachment 218251 [details]
/var/log/messages from Oct 4-5
Incidentally, if I do "pm-suspend ; dmesg > dmesg.out ; sync", I get a
completely blank screen after I resume, though the system does run commands I
type. I don't know whether this is intentional or if coming up blank is a sign
of a video reinitialization problem.
It has been a while - any improvements on this? Would you mind also attaching an
if you are able.
"pm-suspend ; dmesg > dmesg.out ; sync" still comes up with a blank screen that
accepts shell commands typed "blind". Is this indicative of the problem, or
should I test suspend/resume with the wireless card again? I've been avoiding
using the wireless card because of the instability it seems to introduce.
I've upgraded to Fedora 8 and I'm now using kernel-18.104.22.168-85.fc8.
Created attachment 291622 [details]
Output from lsmod, as requested
You can try adding the wireless module with:
as this may enable you to sus/res easier. As you were able to run:
pm-suspend ; dmesg > dmesg.out ; sync
you should now have a dmesg.out file which you can attach to this bug.
Created attachment 291637 [details]
dmesg output, as requested
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.
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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 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.