Description of problem:
The kdump technology that we ship currently calls for a large amount of ram to be reserved at boot time, which cannot be used by other applications. As such I'd like to add the following footnote to the minumim requirements for RHEL:
If the kdump crash recovery technology is enabled an in use on a given system, minumum memory requirements should be raised by the amount of memory reserved for kdump usage. This value is determined by the user, and specified on the kernel command line, via the crashkernel parameter. The default value for this setting is 128MB.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release. Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release. This request is not yet committed for
CCing Ryan for the release notes, and Jarek, who may end up handling the kdump documentation in the DG (bug 451059). Assigning to Jarek for now for that reason.
Should I add Neil's description (and others I come across such as this one) to the Technical Notes field, as Tom did with bug 606993? This will make it into the 6_1 (not 6_0) Deployment guide.
Fixed in Red_Hat_Enterprise_Linux-Deployment_Guide-6-en-US-0.5-36.
The "Displaying a Backtrace" page in the document is really strange:
It shows this:
PID: 5108 TASK: ee939980 CPU: 0 COMMAND: "bash"
#0 [eeabfde8] ia32_sysenter_target at c0465b5c
#1 [eeabfe3c] oops_end at c077209b
#2 [eeabfe50] ia32_sysenter_target at c04206ac
EAX: 00000000 EBX: c08833f3 ECX: 00000000 EDX: 00000046
DS: fffffed8 ESI: 00000002 ES: fffffe8c EDI: c076ee9d
SS: 0001 ESP: c04207f4 EBP: ee939980 GS: 0002
CS: ffff8210 EIP: 00000000 ERR: eeabfed8 EFLAGS: eeabfea4
I thought this might be a crash bug because it's missing several
frames, the exception frame, etc.
So I create another x86 dumpfile from a 2.6.32-69.el6 kernel, with
kexec-tools-2.0.0-143.el6 to see if I could reproduce the above
with a "echo c > /proc/sysrq-trigger". But when I do it, the
backtrace is correct:
PID: 5591 TASK: f196d560 CPU: 2 COMMAND: "bash"
#0 [ef4dbdcc] crash_kexec at c0494922
#1 [ef4dbe20] oops_end at c080e402
#2 [ef4dbe34] no_context at c043089d
#3 [ef4dbe58] bad_area at c0430b26
#4 [ef4dbe6c] do_page_fault at c080fb9b
#5 [ef4dbee4] error_code (via page_fault) at c080d809
EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000 EBP: 00000000
DS: 007b ESI: c0a09ca0 ES: 007b EDI: 00000286 GS: 00e0
CS: 0060 EIP: c068124f ERR: ffffffff EFLAGS: 00010096
#6 [ef4dbf18] sysrq_handle_crash at c068124f
#7 [ef4dbf24] __handle_sysrq at c0681469
#8 [ef4dbf48] write_sysrq_trigger at c068150a
#9 [ef4dbf54] proc_reg_write at c0569ec2
#10 [ef4dbf74] vfs_write at c051de4e
#11 [ef4dbf94] sys_write at c051e8cc
#12 [ef4dbfb0] system_call at c0409ad5
EAX: ffffffda EBX: 00000001 ECX: b7776000 EDX: 00000002
DS: 007b ESI: 00000002 ES: 007b EDI: b7776000
SS: 007b ESP: bfcb2088 EBP: bfcb20b4 GS: 0033
CS: 0073 EIP: 00edc416 ERR: 00000004 EFLAGS: 00000246
If the dumpfile which was used for the document example is still
around, I would like to see it.
In any case, the document's backtrace is really misleading.
I can re-create each of the crash-utility output segments
that are shown in the document, and attach them to this BZ.
Would that be helpful?
Created attachment 440935 [details]
crash documentation update
Updated output for these examples:
Example 30.3. Running the crash utility
Example 30.4. Displaying the kernel message buffer
Example 30.5. Displaying the kernel stack trace
Example 30.6. Displaying status of processes in the system
Example 30.7. Displaying virtual memory information of the current context
Example 30.8. Displaying information about open files of the current context
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.