Red Hat Bugzilla – Bug 253555
intermittent crashes on resume with e1000 network driver
Last modified: 2008-06-16 22:11:55 EDT
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
Description of problem: When I have the e1000 driver enabled, my system crashes
on resume occasionally. I enabled it again after installing kernel
126.96.36.199-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):
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
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
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 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:
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
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:
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:
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.