Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 2.1 product line. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 101915

Summary: oops stack backtrace useless
Product: Red Hat Enterprise Linux 2.1 Reporter: Eric Schwartz <eric.schwartz>
Component: kernelAssignee: Don Howard <dhoward>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: medium    
Version: 2.1CC: jbaron, riel
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-16 18:01:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Eric Schwartz 2003-08-08 00:02:34 UTC
Description of problem:
As of Q2, when an oops happens, the backtrace is only one level deep, and
just looks like:

Call Trace: [<e0000000044148b0>] sp=0xe000004045b279f0 bsp=0xe000004045b20f68
decoded to show_stack [kernel] 0x50


Version-Release number of selected component (if applicable):
kernel-2.4.18-e.31

How reproducible:
100%

Steps to Reproduce:
1. do something to cause an oops
2. note lack of backtrace info
    
Actual results:
only one line of backtrace info is printed, and that line is pretty useless.

Expected results:
full stack trace is printed.

Additional info:
The one line we do get is shortly thereafter followed by a panic().  I'm not
sure, but I believe the aborted backtrace may be caused by the recent change to
force an oops to always panic(), causing the panic to interrupt show_stack(),
and causing the machine to reboot.  This is just a theory, and is welcome to be
tossed out if you like.

Comment 1 Arjan van de Ven 2003-08-08 08:14:02 UTC
we most likely fixed this already, please check a more current kernel


Comment 2 Eric Schwartz 2003-08-08 17:01:33 UTC
Are there any more recent kernels for the 2.1 series? e.31 is the latest we have.

Comment 3 Jason Baron 2003-11-10 22:10:50 UTC
The latest is e.38, although i'm not sure if this issue is addressed
there...i'm looking into it...any additional information is more than
welcomed.

Comment 4 Eric Schwartz 2003-11-10 22:23:46 UTC
Can you send me a copy of this kernel?  I don't have any kernels more
recent that e.31.  Alternatively, you should be able to verify this
easily on any ia64 box; as I said, just force an oops() and see what
you get for a stack trace.

Comment 5 Jason Baron 2004-09-08 21:00:52 UTC
The latest rhel2.1 ia64 kernel is U5, e.47 found at:

http://people.redhat.com/~jbaron/.private/u5/2.4.18-e.47/

Comment 6 Ernie Petrides 2005-09-12 19:47:55 UTC
Correcting product version.

Comment 7 Don Howard 2005-09-16 18:01:15 UTC
This is a very old report.  sysrq-c appears to generate correct backtrace info
on current derry kernels.

If this issue is still seen on current kernels, please reopen this bug and add
specific steps to reproduce.