Red Hat Bugzilla – Bug 101915
oops stack backtrace useless
Last modified: 2007-11-30 17:06:53 EST
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):
Steps to Reproduce:
1. do something to cause an oops
2. note lack of backtrace info
only one line of backtrace info is printed, and that line is pretty useless.
full stack trace is printed.
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.
we most likely fixed this already, please check a more current kernel
Are there any more recent kernels for the 2.1 series? e.31 is the latest we have.
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
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.
The latest rhel2.1 ia64 kernel is U5, e.47 found at:
Correcting product version.
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.