kabsingh@xxxxxxxxxxx wrote:
>
> Sir/Mam,
>
> I have Red Hat Linux release 6.2 (Zoot) Kernel 2.2.13-12 on an i686.
> Is it possible for me ti use LKCD and lcrash in a situation where incase of a
> crash i want
> to analyse the stackframe of the functions leading to the crash.
> I read a document titled "Linux Kernel Crash Dumps" authored by you
> with the following information :
>
> "3.5.4.1 General Layout of Stack Backtrace Functionality
>
> The LCRASH stack trace facility has been organized much like the other
> architecture specific features.
> An architecture independent layer provides a set of functions for finding and
> displaying kernel
> stack backtraces. These functions make calls to platform specific functions,
> which perform
> the actual work. At this time, only support for i386 stack traces has been
> provided. "
>
> Please reply as soon as possible.
> Thanking You in anticipation,
> Regards,
Hi Kabir,
There are two components to LKCD. One is a kernel component (in the form of
a patch) which generates a system crash dump in the event of a system panic.
The other is a utility called lcrash, which is able to read the contents of
the dump and generate information about the state of the kernel at the time
of the crash. Specific to your question, lcrash can generate backtrace
information for all tasks running on the system at the time of the crash.
Below is an example of the stack command output (without and with a stack
frame dump):
>> t c35bc000
================================================================
STACK TRACE FOR TASK: 0xc35bc000(mingetty)
0 schedule+748 [0xc01142bc]
1 schedule_timeout+18 [0xc0113f3e]
2 read_chan+903 [0xc01956d7]
3 tty_read+178 [0xc0184d16]
4 sys_read+140 [0xc012c534]
5 system_call+44 [0xc0108dac]
================================================================
>> t -f c35bc000
================================================================
STACK TRACE FOR TASK: 0xc35bc000(mingetty)
0 schedule+748 [0xc01142bc]
RA=0xc0113f43, SP=0xc35bdea8, FP=0xc35bdefc, SIZE=88
c35bdea8: c35bdef8 c35bc000 03f10000 7fffffff
c35bdeb8: c11d1840 c3cdc000 c3cdc000 c35bc000
c35bdec8: c11c71c0 c33b6000 c11c7d00 0000001a
c35bded8: c02a0000 c11c7b20 c11c71c0 c35bc000
c35bdee8: 0000001d 00000000 c35bc000 c02d5540
c35bdef8: c35bdf1c c0113f43
1 schedule_timeout+18 [0xc0113f3e]
RA=0xc01956dc, SP=0xc35bdf00, FP=0xc35bdf20, SIZE=36
c35bdf00: 00000008 c11d1840 00000000 00014000
c35bdf10: 00000246 c3cdc000 c11d1840 bffffe0c
c35bdf20: c01956dc
2 read_chan+903 [0xc01956d7]
RA=0xc0184d18, SP=0xc35bdf24, FP=0xc35bdf80, SIZE=96
c35bdf24: c3cdc000 c11d1840 c3213820 bffffe0c
c35bdf34: 00000008 c35bc000 c3cdcbf4 c3cdc97c
c35bdf44: c35bdf70 7fffffff 00000000 00000000
c35bdf54: 00000000 c35bc000 bffffe0b 01234567
c35bdf64: c35bc000 00000000 00000000 01234567
c35bdf74: c35bc000 c3cdc980 c3cdc980 c0184d18
3 tty_read+178 [0xc0184d16]
RA=0xc012c536, SP=0xc35bdf84, FP=0xc35bdfa0, SIZE=32
c35bdf84: c3cdc000 c11d1840 bffffe0b 00000001
c35bdf94: ffffffea c11d1840 00000001 c012c536
4 sys_read+140 [0xc012c534]
RA=0xc0108db3, SP=0xc35bdfa4, FP=0xc35bdfc0, SIZE=32
c35bdfa4: c11d1840 bffffe0b 00000001 c11d1860
c35bdfb4: c35bc000 0804ad80 bffffe0b c0108db3
5 system_call+44 [0xc0108dac]
RA=0x400ba534, SP=0xc35bdfc4, FP=0xc35bdfec, SIZE=44
c35bdfc4: 00000000 bffffe0b 00000001 0804ad80
c35bdfd4: bffffe0b bffffe0c 00000003 0000002b
c35bdfe4: 0000002b 00000003 400ba534
================================================================
We currently support two architectures, i386 (which includes
all x86 architectures) and ia64 (linux-2.4.x only). We are in
the process of releasing a kernel patch for the 2.2.17 and
2.4.0-test9 kernels. The 2.2.17 patch, with minor conflict
resolutions also works with the 2.2.16 kernel. We haven't tested
it with earlier 2.2.x kernels. The approach we are taking now
provides the most flexibility with regard to crash analysis tools.
Our kernel patch creates a new target every time the kernel gets built.
This new target, Kerntypes, gets copied to the /boot directory
along with vmlinux and System.map. The lcrash utility uses the
type information (which is in stabs form) in the Kerntypes
object to reference specific pieces of kernel data, in conjunction
with addresses from the symbol table. It should be fairly easy
to get lcrash working with the earlier kernel. It might take more
work for the kernel patch component. You might also want to look
at some of our earlier LKCD releases, which have the lcrash utility
more closely tied to the kernel source and build mechanism. In fact
the FAQ in our web page (http://oss.sgi.com/projects/lkcd/faq.html)
more closely matches the kernel you are using than the one we
currently support (we are in the process of updating the docs to
go along with the new release). Check out the LKCD 1.0.4 release
at ftp://oss.sgi.com/projects/lkcd/download/OLD/1.x/1.0.4.
Note that if you use this older release, your system must have
SCSI disks. Our newest version supports IDE and SCSI. You may have
to do some porting work (with the kernel patch and the utilities)
if you want our current stuff to work on your older kernel.
Hopefully this gives you enough information so that you can make
your decision on the best way to proceed.
Thanks for your interest,
Tom
>
> Kabir Singh
> (Software Engineer)
>
> Hughes Software Systems
> Electronic City,
> Plot 31, Sector 18
> Gurgaon - 122 015
> Haryana (INDIA)
>
> Tel 91-124-6346666,6343703 extn 2348
|