Bug 176624 - kernel panics "randomly"
Summary: kernel panics "randomly"
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL: http://www.kluge.net/~felicity/panics/
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-12-27 20:49 UTC by Theo Van Dinter
Modified: 2015-01-04 22:23 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-12-27 23:19:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Theo Van Dinter 2005-12-27 20:49:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/416.12 (KHTML, like Gecko) Safari/416.13

Description of problem:
My machine has been stable until the past few weeks where the system will panic randomly.  Nothing 
has changed in terms of hardware, and the kernel hasn't changed since 2005/10/28.  The panic output 
is available at the URL specified in the ticket.

Looking at the panic info, they reference vgacon a bit.  The only related change to the console that I can 
think of (there's no console connected by default) is that I added "/usr/bin/setterm -blank 0" to 
rc.local, just in case a crash happened and I didn't have the serial console connected, I wouldn't have to 
worry about the video console being blank.

System hardware:  2x Opteron 246 (2GHz), 2GB ECC RAM.

Please let me know if you need any other information.

Version-Release number of selected component (if applicable):
kernel-smp-2.6.12-1.1381_FC3

How reproducible:
Didn't try

Steps to Reproduce:
Unknown.  The system runs for several days, then panics.  From "last":

reboot   system boot  2.6.12-1.1381_FC Tue Dec 27 11:51          (03:56)    
reboot   system boot  2.6.12-1.1381_FC Thu Dec 22 13:23         (5+02:25)   
reboot   system boot  2.6.12-1.1381_FC Sat Dec  3 11:39         (24+04:09)  
[...]
wtmp begins Thu Dec  1 08:30:15 2005


Additional info:

Comment 1 Dave Jones 2005-12-27 23:19:56 UTC
This was fixed upstream post 2.6.12, but I'm not sure exactly when, and how.
There were 1-2 reports of this against FC4, but since the last few rebases to
newer upstream releases, the problem got fixed.

The problem with isolating the change responsible for fixing this is that so
much has changed, and it's unlikely to be a small diff, but more likely a series
of reworked core vm functions.  Backporting such changes is very risky, and
could even cause more problems than we currently have.

As FC3 is nearing end of life, the only bugs that are likely to get fixed there
over the few weeks remaining are security issues.  But upgrading to Fedora Core
4 now should have this fixed in the current update kernel.


Comment 2 Theo Van Dinter 2005-12-29 06:24:15 UTC
Hrm.  Ok.  Do you know of any workarounds for this issue then?  Is the problem specifically related to 
disabling screen blanking?  I've been thinking about upgrading to FC4, but haven't had time to do it up to 
now.  Are there any known issues running the FC4 kernel on an FC3 machine?  I'd assume I also would 
have to upgrade things like kernel-utils, lvm, etc?

Thanks.

Comment 3 Dave Jones 2005-12-29 06:50:26 UTC
I don't think it's related to blanking. It's core memory management internals
hitting some corner case, and losing its marbles trying to make sense of things.

it'd probably be a nightmare dependancy mess to put an FC4 kernel on FC3. At the
least, you'd need a new udev, hotplug, initscripts, alsa-utils/lib, and all the
related dependancies that those drag in.  Debugging any other issues that crop
up on 'hybrid' installs like this is near impossible.  The 'upgrade' option in
the installer also fixes up a bunch of other things that a 'yum update' won't
do. (Like removing obsolete entries from your modprobe.conf for one to give you
an example).

(The mess of updated dependancies is also why there's no kernel newer than
2.6.12 for FC3 -- Given it's so close to EOL, it'd be a race against time to get
userspace back in ship-shape again. Rebasing to a newer upstream release is
really painful in this regard, because a lot of the time, we don't realise we
need newer package Y until /after/ we've shipped a kernel update, and broken
previously working setups.



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