Hi,
It was my mistake.
During an earlier debugging, I set verbose=1, misinterpreting it to mean just a few debug prints.
On restoring the code, I'm able to run crash utility quite well. I'm yet to understand the purpose of verbose, though.
On restoring the code, I'm able to run crash utility quite well. I'm yet to understand the purpose of verbose, though.
On a side-topic - is an ARM port of this utility (ie, a vmcore generated on an ARM system, debugged with crash offline on X86) available, or in the offing?
Sumeet
On Tue, Sep 29, 2009 at 7:03 AM, Sumeet Gupta <meetsumeet@xxxxxxxxx> wrote:
Hi All,I downloaded and built crash 4.0.9 for Intel X86 linux machine.I'm trying to debug kdump-generated vmcore, taken using the "crash kernel".Kernel: 2.6.27.34Main kernel argument: crashkernel=64M@16MMain kernel loaded at 2M.The problem:./crash <vmlinux> <vmcore>behaves kinda strange... it gets stuck in the following loop of function calls, during reading totalram_pages symbol:get_symbol_data("totalram_pages") -> readmem("totalram_pages") ->kvtop -> x86_kvtop ("pgd page") ->readmem ("pgd page") ->kvtop -> x86_kvtop("pgd page") -> readmem("pgd page")and eventually crashes, probably when recursion reaches stack limit.Why would such a situation happen...?With gdb, though, things are different - gdb is able to read the vmcore, and give the gdb prompt, at which I can see the init_mm structure, and backtrace etc. I also verified that pgd address (init_mm.pgd) is the same as crash is trying to read through readmem("pgd page").Any inputs will be very useful.Thanks,Sumeet
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
