Bug 439877 - Kernel panics seemingly at random
Kernel panics seemingly at random
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-31 16:45 EDT by Benjamin Kreuter
Modified: 2008-10-22 17:39 EDT (History)
3 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Benjamin Kreuter 2008-03-31 16:45:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux KHTML/3.5.9 (like Gecko)

Description of problem:
Running on a Dell Inspiron 1420.  When booting up, especially with 
kernel-, 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):
kernel-, kernel-

How reproducible:

Steps to Reproduce:
1. Boot up the kernel
2. Wait.

Actual Results:
Panic with; harder to reproduce with

Expected Results:
The kernel should not panic.

Additional info:
Comment 1 Dave Jones 2008-03-31 18:02:01 EDT
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.
Comment 2 Benjamin Kreuter 2008-04-04 10:50:40 EDT
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.
Comment 3 Dave Jones 2008-04-04 13:41:29 EDT
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.
Comment 4 Benjamin Kreuter 2008-04-04 13:55:57 EDT
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...)?
Comment 5 Dave Jones 2008-04-04 14:51:32 EDT
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
experimenting with.
Comment 6 Zachary Napora 2008-04-20 22:08:37 EDT
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.
Comment 7 Christopher D. Stover 2008-10-22 17:39:33 EDT
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.

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