Bug 439877 - Kernel panics seemingly at random
Summary: Kernel panics seemingly at random
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-31 20:45 UTC by Benjamin Kreuter
Modified: 2008-10-22 21:39 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-10-22 21:39:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Benjamin Kreuter 2008-03-31 20:45:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux 2.6.24.3-50.fc8) KHTML/3.5.9 (like Gecko)

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

How reproducible:
Always


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

Actual Results:
Panic with 2.6.24.3-50; harder to reproduce with 2.6.24.3-34.

Expected Results:
The kernel should not panic.

Additional info:

Comment 1 Dave Jones 2008-03-31 22:02:01 UTC
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
http://fedoraproject.org/wiki/KernelCommonProblems#head-aacc422f26396dee978174e105c6a2b8ed962971
especially the part about netconsole, and give that a try.


Comment 2 Benjamin Kreuter 2008-04-04 14:50:40 UTC
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 17:41:29 UTC
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 17:55:57 UTC
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 18:51:32 UTC
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-21 02:08:37 UTC
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 21:39:33 UTC
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.