Hide Forgot
I'm filing this as a separate bug since bug 241783 was resolved, but I'm still seeing some problems with it (although not ones that I'd actually described in bug 243977). Description of problem: When I have the e1000 driver enabled, my system crashes on resume occasionally. I enabled it again after installing kernel 2.6.22.1-41.fc7 on July 31, and crashed on resume twice in slightly less than a week. I disabled it again (by adding "install e1000 /bin/true" to /etc/modprobe.conf) and haven't crashed on resume since. Version-Release number of selected component (if applicable): kernel-2.6.22.1-41.fc7 How reproducible: occasionally Steps to Reproduce: Fn-F4 to suspend (via haldaemon, etc.) Actual results: System sometimes crashes on resume. (I've forgotten some of the details, since it was a few weeks ago, but I could try again if it could be helpful.) My memory is that I saw some text on the console, but it didn't get to the point of restarting X. Expected results: no crash Additional info: from lspci -v: 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) Subsystem: IBM PRO/1000 MT Mobile Connection Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11 Memory at c0220000 (32-bit, non-prefetchable) [size=128K] Memory at c0200000 (32-bit, non-prefetchable) [size=64K] I/O ports at 8000 [size=64] [virtual] Expansion ROM at c0240000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2
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 you are, here are some things to test to help developers troubleshoot your 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. 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.
The above comment doesn't seem to apply to this bug since which driver is causing the problem is already diagnosed. It looks like it's just a standard comment pasted into many bugs, whether it applies or not.
It was a copy and paste job and yes, some of it is irrelevant - my apologies. However it would be helpful to get some dmesg output from a hung suspend/resume and to know exactly what kind of crash is occurring. If you can, could you run the following from a vt: pm-suspend ; dmesg > dmesg.out ; sync and then attach the output as text/plain once you have brought the system back up following a crash. You might even want to try some of the quirks at: http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html to see if they let you leave the network driver enabled and complete a cycle. If you can check whether the caps lock light toggles on and off as well that would be great.
Hello David, Any update on this? Were you able to test out any of the above?
Most of the above was not relevant to this bug. The parts that are (comment 3) seem difficult to do for a bug that's as intermittent as this one is. So, no, I haven't. At some point maybe I'll try figuring out a way to hook up the dmesg suggestion in comment 3 to the normal suspend-resume so that I have logs for all suspend-resume cycles, but I haven't had a chance to look into that yet.
Okay, thanks for the update. You might want to try adding: SUSPEND_MODULES="e1000" to /etc/pm/config.d/unload_modules as this will handle the sus/res a bit more gracefully.
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.