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.
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 welcomed.
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: http://people.redhat.com/~jbaron/.private/u5/2.4.18-e.47/
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.