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
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage 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 drivers. # Laptops using the nv driver should be considered hibernate-only capable as per https://www.redhat.com/archives/fedora-test-list/2007-September/msg00365.html 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-2.6.22.9-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 lock-ups.
Okay Christopher, good to hear the problem appears resolved for you. Could you close CURRENTRELEASE with kernel-2.6.22.9-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 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) and 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.
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.
Hello Christopher, It has been a while - any improvements on this? Would you mind also attaching an output from: lsmod if you are able. Cheers Chris
"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-2.6.23.9-85.fc8.
Created attachment 291622 [details] Output from lsmod, as requested
You can try adding the wireless module with: SUSPEND_MODULES="b43" 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. Cheers Chris
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: http://docs.fedoraproject.org/release-notes/ 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.