[Crash-utility] question on some command params

[Dave Anderson]

Jun Koi wrote:
> 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?

Again, that was for a particular series of Fedora x86 kernels.
Here are the details:

   http://people.redhat.com/anderson/crash.changelog.html#4_0_4_5

The Fedora kernel configuration was changed.

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

That was put in some years ago to quickly determine whether a vmlinux
file was built with -g, and then bail out without running a session.
Way back then it was pretty much up to the user to re-compile his own
kernel with -g, i.e., prior to the distros providing debug-full vmlinux
files.

Dave