Bug 264141 - Resume occasionally fails on Toshiba Satellite M35X laptop
Resume occasionally fails on Toshiba Satellite M35X laptop
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All All
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-08-29 12:48 EDT by Christopher Beland
Modified: 2008-06-16 22:16 EDT (History)
2 users (show)

See Also:
Fixed In Version: kernel-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-06-16 22:16:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/messages excerpt, Smolt profile (32.46 KB, text/plain)
2007-08-29 12:48 EDT, Christopher Beland
no flags Details
/var/log/messages from Oct 4-5 (144.08 KB, text/plain)
2007-10-05 21:22 EDT, Christopher Beland
no flags Details
Output from lsmod, as requested (3.22 KB, text/plain)
2008-01-14 15:16 EST, Christopher Beland
no flags Details
dmesg output, as requested (22.18 KB, text/plain)
2008-01-14 16:24 EST, Christopher Beland
no flags Details

  None (edit)
Description Christopher Beland 2007-08-29 12:48:28 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.
Comment 1 Christopher Beland 2007-08-29 12:48:28 EDT
Created attachment 179401 [details]
/var/log/messages excerpt, Smolt profile
Comment 2 Christopher Brown 2007-09-30 11:56:11 EDT

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.
Comment 3 Christopher Beland 2007-10-04 18:36:24 EDT
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-, 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
Comment 4 Christopher Brown 2007-10-04 18:49:21 EDT
Okay Christopher, good to hear the problem appears resolved for you. Could you
close CURRENTRELEASE with kernel- as the version that resolved it
if you feel this is appropriate.
Comment 5 Christopher Beland 2007-10-04 18:59:43 EDT
I guess I'll do that and re-open if it happens again.
Comment 6 Christopher Beland 2007-10-05 21:19:18 EDT
Ah, I spoke ever-so-slightly too soon.  I experienced this problem
again today.

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
errors like:

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
diagnostic information.
Comment 7 Christopher Beland 2007-10-05 21:22:05 EDT
Created attachment 218251 [details]
/var/log/messages from Oct 4-5
Comment 8 Christopher Beland 2007-10-05 21:40:22 EDT
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.
Comment 9 Christopher Brown 2008-01-13 14:10:32 EST
Hello Christopher,

It has been a while - any improvements on this? Would you mind also attaching an
output from:


if you are able.

Comment 10 Christopher Beland 2008-01-14 15:14:38 EST
"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-
Comment 11 Christopher Beland 2008-01-14 15:16:32 EST
Created attachment 291622 [details]
Output from lsmod, as requested
Comment 12 Christopher Brown 2008-01-14 15:46:20 EST
You can try adding the wireless module with:


to /etc/pm/config.d/unload_modules

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.

Comment 13 Christopher Beland 2008-01-14 16:24:09 EST
Created attachment 291637 [details]
dmesg output, as requested
Comment 14 Bug Zapper 2008-05-14 10:09:19 EDT
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
Comment 15 Bug Zapper 2008-06-16 22:16:01 EDT
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.

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