Jayaraman, Bhaskar wrote: A bit of background would help here, such as what architecture, what distribution, and what kernel version you're running with. Since you're asking, I'm presuming that you're running with something other than RHEL5. But just in case you are running RHEL5, dom0 hosts and paravirtualized x86 and x86_64 guests have the /dev/crash driver built in. So, for a live system, either dom0 or domU, and presuming that you've got the appropriate kernel debuginfo package installed, you can just enter: $ crash and it will look for the correct vmlinux file based upon what it sees in /proc/version. If it can't find it, you can just enter it: $ crash /path/to/vmlinux For dom0/hypervisor kdumps, or for domU xendumps, you have to enter both the vmlinux and vmcore arguments, as in: $ crash /path/to/vmlinux /path/to/vmcore Also, for dom0/hypervisor kdumps, you can alternatively look at the vmcore from the perspective of the xen hypervisor: $ crash /path/to/xen-syms /path/to/vmcore Now, for architectures other than x86 and x86_64 on RHEL5, the /dev/mem driver will most because it is not restricted to the first 256 pages (1MB). For 32-bit kernels, however, you will run into the /dev/mem restriction that only allows lowmem access. But your session should come up, although it may run into some command errors if highmem access is required for mapped virtual-to-physical address translation of user or kernel vmalloc virtual addresses. And then recently the upstream kernel has adopted the new CONFIG_STRICT_DEVMEM option, which cripples the use of /dev/mem by crash in the same way that RHEL kernels do. If you have no control of your kernel, and it has the CONFIG_STRICT_DEVMEM restriction, then you either have to roll your own kernel memory access driver (like the /dev/crash driver), or if you're really adventurous, you can write a kprobe module that modifies the return value of devmem_is_allowed(). In any case, it would be nice if the RHEL5 /dev/crash driver could be packaged such that anybody could simply build it externally for any kernel without any modifications to the kernel source tree -- in a similar manner to the way the kprobes developers show how to build their modules do in the RHEL5 "Documentation/kprobes.txt" file, or in the upstream "samples/kprobes" directory. But the /dev/crash driver does require small modifications to the kernel source, primarily to EXPORT_SYMBOL_GPL() the page_is_ram() function. I can't help much more than attaching the two patches to the RHEL5 tree that implement the /dev/crash driver, linux-2.6-crash-driver.patch and linux-2.6-crash-driver-xen.patch, and letting you run with them: $ lsdiff linux-2.6-crash-driver.patch linux-1050/arch/i386/mm/init.c linux-1050/arch/ia64/kernel/ia64_ksyms.c linux-1050/arch/x86_64/mm/init.c linux-1050/drivers/char/crash.c linux-1050/drivers/char/Kconfig linux-2.6.16.noarch/drivers/char/Makefile linux-1050/include/asm-i386/crash.h linux-1050/include/asm-ia64/crash.h linux-1050/include/asm-x86_64/crash.h $ lsdiff linux-2.6-crash-driver-xen.patch a/arch/i386/mm/init-xen.c a/arch/x86_64/mm/init-xen.c $ and depending upon how your distro is built, you'll need to turn on CONFIG_CRASH so the Makefile will build it. Note that the ia64 stuff in the patch is cruft, won't compile, and is unnecessary since the /dev/mem driver for that architecture still works just fine. That all being said, if you're only dealing with x86_64, then the simplest route would be to remove any /dev/mem restrictions, because then that driver will also work just fine. You can do the same for x86, but just be aware that you may run into some bumps in the road if you need to access any highmem physical addresses. But the basic crash session should come up OK. Dave