<br><br>
<div class="gmail_quote">On Tue, Sep 29, 2009 at 7:11 PM, Dave Anderson <span dir="ltr"><<a href="mailto:anderson@redhat.com">anderson@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im"><br>----- "Sumeet Gupta" <<a href="mailto:meetsumeet@gmail.com">meetsumeet@gmail.com</a>> wrote:<br><br>> Hi,<br>><br>> It was my mistake.<br>><br>> During an earlier debugging, I set verbose=1, misinterpreting it to<br>
> mean just a few debug prints.<br><br></div>What do you mean by that?  Where are you setting "verbose"?<br></blockquote>
<div>I was talking about the file x86.c, function x86_kvtop, around line 2622, where it returns from the function, or not, depending upon verbose. If the purpose of verbose in this function is only to have more fprintfs, then the behaviour should not change based on this argument. I had (to see whats going on in this function,) set the verbose flag in it to 1. This caused the recursion in function calls I mentioned.</div>

<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im"><br>> On restoring the code, I'm able to run crash utility quite well. I'm<br>> yet to understand the purpose of verbose, though.<br><br></div>Right -- nor do I.  Regardless, I don't know why you should have run<br>
into that problem on that particular symbol.  If you can make that<br>vmcore available for me to download, I can take a look at it.<br></blockquote>
<div> </div>
<div>Thanks Anderson. But that is not necessary any more. I'm able to see into the vmcore using crash. </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im"><br>><br>> On a side-topic - is an ARM port of this utility (ie, a vmcore<br>> generated on an ARM system, debugged with crash offline on X86)<br>> available, or in the offing?<br><br></div>None that I'm aware of.  It was brought up on this list some time<br>
ago, and I gave the requester some initial guidance on the steps<br>to take in order to add support for a new architecture.  But I've<br>heard nothing since then.<br></blockquote>
<div> </div>
<div>If you could give me a link to your previous mail having the guidance steps, that would be helpful.</div>
<div> </div>
<div>Thanks,</div>
<div>Sumeet</div>
<div> </div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>Dave<br>
<div>
<div></div>
<div class="h5"><br><br>><br>> Sumeet<br>><br>><br>> On Tue, Sep 29, 2009 at 7:03 AM, Sumeet Gupta < <a href="mailto:meetsumeet@gmail.com">meetsumeet@gmail.com</a> ><br>> wrote:<br>><br>><br>
><br>><br>><br>> Hi All,<br>><br>> I downloaded and built crash 4.0.9 for Intel X86 linux machine.<br>> I'm trying to debug kdump-generated vmcore, taken using the "crash<br>> kernel".<br>
> Kernel: 2.6.27.34<br>> Main kernel argument: crashkernel=64M@16M<br>> Main kernel loaded at 2M.<br>><br>> The problem:<br>> ./crash <vmlinux> <vmcore><br>> behaves kinda strange... it gets stuck in the following loop of<br>
> function calls, during reading totalram_pages symbol:<br>> get_symbol_data("totalram_pages") -> readmem("totalram_pages") ->kvtop<br>> -> x86_kvtop ("pgd page") ->readmem ("pgd page") ->kvtop -><br>
> x86_kvtop("pgd page") -> readmem("pgd page")<br>><br>><br>> and eventually crashes, probably when recursion reaches stack limit.<br>><br>> Why would such a situation happen...?<br>
><br>> With gdb, though, things are different - gdb is able to read the<br>> vmcore, and give the gdb prompt, at which I can see the init_mm<br>> structure, and backtrace etc. I also verified that pgd address<br>
> (init_mm.pgd) is the same as crash is trying to read through<br>> readmem("pgd page").<br>><br>><br>> Any inputs will be very useful.<br>><br>> Thanks,<br>> Sumeet<br>><br>><br></div>
</div>> --<br>> Crash-utility mailing list<br>> <a href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a><br>> <a href="https://www.redhat.com/mailman/listinfo/crash-utility" target="_blank">https://www.redhat.com/mailman/listinfo/crash-utility</a><br>
<font color="#888888"><br>--<br>Crash-utility mailing list<br><a href="mailto:Crash-utility@redhat.com">Crash-utility@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/crash-utility" target="_blank">https://www.redhat.com/mailman/listinfo/crash-utility</a><br>
</font></blockquote></div><br>