[Crash-utility] question on some command params

[Jun Koi]

On Tue, Sep 23, 2008 at 12:49 AM, Dave Anderson <anderson at redhat.com> wrote:
> Jun Koi wrote:
>>
>> Hi,
>>
>> I found below cmdline params having no documentation anywhere, so
>> could somebody explain their meaning?
>>
>> - memory_module
>> - no_modules
>> - no_ikconfig
>> - no_namelist_gzip
>> - no_kmem_cache
>> - kmem_cache_delay
>> - readnow
>> - buildinfo
>> - zero_excluded
>>
>>
>> Many thanks,
>> J
>
> They're all essentially debug flags for use on kernels/dumpfiles
> that for some reason or other would not initialize properly.
>
> memory_module: if /dev/mem or /dev/crash do not suffice you could
>  force-feed one or the other for live system analysys.

Sorry for stupid question, but how to have /dev/crash device?

> no_modules: if the module initialization code cause crash to
>  during initialization, skip it with --no_modules.
>
> no_ikconfig: if the reading of the in-kernel config data causes
>  an initialization-time failure, skip it with --no_ikconfig
>
> no_namelist_gzip: completely obsolete
>
> no_kmem_cache: if the kmem slab cache initialization causes an
>  initialization-time failure, skip it with --no_kmem_cache
>
> kmem_cache_delay: if the kmem slab cache initialization causes an
>  initialization-time failure, it can alternatively be delayed
>  until the first command that accesses the kmem_cache is run
>
> readnow: useless now, but there was a very short period of time
>  where gcc was creating debuginfo vmlinux files that required
>  --readnow in order to gather all of the debug data at initialization
>  time.
>
> buildinfo: dumps information about who/where/when/gcc w/respect to
>  the crash utility itself.
>
> zero_excluded: if a page was excluded by diskdump or makedumpfile,
>  it normally returns a failure if the page is accessed.  If you
>  want it to just return a page of zeroes, use --zero_excluded.
>
> In any case, if you find that you need to use any of the flags above,
> then it's indicative of (1) a crash utility bug, or (2) a corrupted vmcore.
> In either situation, it's best to find and fix the underlying problem
> instead of working around it.  Using the flags above is only a stop-gap
> measure, and should not be "depended upon".
>

That is more clear now for me. But how about the "-reloc" param?

Besides, I also found some options not documented anywhere, like "-g".

Thanks a lot,
J