Hi Dave,
Dave Anderson wrote:
>>> Is there a reason that makedumpfile does not fill in the utsname structure
>>> in the compressed dumpfile's header?
>> Thank you for good point.
>>
>> makedumpfile does not fill it because makedumpfile might not be able to
>> get kernel debug information (conta
"Ming Lei" writes:
> Eric,
>
>>>"Ming Lei" writes:
>>> As I understand the code, current destination address is picked up by
>>> either the user(elf image) or kexec-tools. It is not automatic, can
> we
>>> let linux kernel choose the address instead? It is automatic and no
> way
>>> to wipe out
- "Ken'ichi Ohmichi" wrote:
> Hi Dave,
>
> Dave Anderson wrote:
> > Is there a reason that makedumpfile does not fill in the utsname structure
> > in the compressed dumpfile's header?
>
> Thank you for good point.
>
> makedumpfile does not fill it because makedumpfile might not be able
Hi Dave,
Dave Anderson wrote:
> Is there a reason that makedumpfile does not fill in the utsname structure
> in the compressed dumpfile's header?
Thank you for good point.
makedumpfile does not fill it because makedumpfile might not be able to
get kernel debug information (containing symbol s
Hi,
makedumpfile version 1.3.3 is released.
Your comments/patches are welcome.
Changelog:
o New feature
- Add --split option. (by Takao Indoh)
Split the dump data to multiple dumpfiles in parallel.
If specifying dumpfiles on different storage devices, a device can share
I/O load wi