Red Hat Bugzilla – Bug 439877
Kernel panics seemingly at random
Last modified: 2008-10-22 17:39:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux 184.108.40.206-50.fc8) KHTML/3.5.9 (like Gecko)
Description of problem:
Running on a Dell Inspiron 1420. When booting up, especially with
kernel-220.127.116.11-50, the kernel appears to panic, the mouse and keyboard stop
functioning, and the capslock and numlock indicators start blinking. This
problem occasionally happens while the system is in use. I am not able to
determine whether or not the problem is in the kernel or X11.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot up the 18.104.22.168-50 kernel
Panic with 22.214.171.124-50; harder to reproduce with 126.96.36.199-34.
The kernel should not panic.
We really need to capture the panic messages that are being printed to the tty.
This can be tricky whilst you're in X. Read
especially the part about netconsole, and give that a try.
1. Netconsole is difficult in this case, because the panic is difficult to
reproduce. It does not happen as a result of any sort of action, it just
happens at completely random intervals. The machine in question is a laptop,
and is not always on the same network (or on any network at all).
2. I just had the same problem on my machine, a Dell D620. I tried to use
the magic sysrq key, but this did not produce any log messages. The symptoms
are the same -- capslock and scroll lock indicators flashing (with a frequency
of 1 second). Do these indicators flashing have any meaning? It seems like
something that is deliberate... This panic occurred immediately after yum
finished installing some updates, if that is any help.
the flashing lights means "we just paniced, and I spewed a backtrace to a tty"
it's there as an indicator so that when we see a locked up X we can discriminate
between "X locked up" and "kernel panic".
Without seeing that trace, there's really nothing we can do.
The next time this happens, I am going to try the magic sysrq key; I may not
have had it activated last time. Does suspend to RAM cause this key to be
disabled for any reason?
Is there anything else I should try? Is there a possible way to have the
kernel's backtrace dumped into a file instead of a tty (unless, of course, the
problem comes from a disk driver of some sort...)?
if the lights are blinking, sysrq won't do anything. It's already wedged.
we can't dump to a file because after a panic, we've no idea just what state the
kernel is in, and it could corrupt disks if it wrote to them.
I've no idea how well the kdump stuff works right now, that might be worth
Thanks for taking the time to file a report, if you could get more of an error
message or log that would be great. For now I'm going to change the status to
NEEDINFO before this can be fixed.
The information we've requested above is required in order
to review this problem report further and diagnose or fix the
issue if it is still present. Since it has been thirty days or
more since we first requested additional information, we're assuming
the problem is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.
Setting status to "CLOSED: INSUFFICIENT_DATA". If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested,
please feel free to reopen the bug report.
Thank you in advance.