Re: [Crash-utility] question on some command params

On Tue, Sep 23, 2008 at 12:49 AM, Dave Anderson <anderson(a)redhat.com&gt; 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".