----- Original Message -----
Hi Dave,
Thanks for the quick response. That was the issue I was having. I am
now able to use vtop.
crash> vtop -c 23619 7fff7efa16a6
VIRTUAL PHYSICAL
7fff7efa16a6 201d126a6
PML: 2a948d7f8 => 3f031a067
PUD: 3f031afe8 => 1ed481067
PMD: 1ed481fb8 => 2c9af2067
PTE: 2c9af2d08 => 201d12005
PAGE: 201d12000
PTE PHYSICAL FLAGS
201d12005 201d12000 (PRESENT|USER)
VMA START END FLAGS FILE
ffff81041195dce8 7fff7efa0000 7fff7efa2000 100173
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffff810107065bf0 201d12000 ffff8101eee276f1 7fffffffe 1 200100000000278
So how do I get at the information that is proved by ps –a? What I’m
really after is the arguments of the command.
If the user stack page containing the information needed by "ps -a"
is not in the dumpfile, then you just can't get it. I'm presuming that
your dumpfile has had its user-pages filtered out. Or less likely but
possible, that user stack page happened to be swapped out at the time
the crash occurred. But if you do a "ps -a" and all user tasks generate
the "cannot access user stack" messages, then they must have been filtered.
Note that if it's a compressed kdump dumpfile, then you can see what's
been filtered out, like this RHEL5 vmcore example, which was post-processed
with "makedumpfile -c -d31":
crash> help -n | grep -e " flags" -e dump_level
flags: 6 (KDUMP_CMPRS_LOCAL|ERROR_EXCLUDED)
dump_level: 31 (0x1f)
(DUMP_EXCLUDE_ZERO|DUMP_EXCLUDE_CACHE|DUMP_EXCLUDE_CACHE_PRI|DUMP_EXCLUDE_USER_DATA|DUMP_EXCLUDE_FREE)
crash>
If the "-c" (compressed) flag was not used, then the resultant vmcore
would still be in ELF format, but there's no readily available indication
of what types of pages (if any) have been filtered out. The only thing
you would typically see is that "help -n" would show a very large number
of PT_LOAD segments if it was filtered, whereas if there's just a handful
of PT_LOAD segments, then it's probably a full dump.
Dave
Thanks again.
Steven Soulen