3:14 p.m.
----- Original Message -----
>>
>> Also, I suggested the "-o outputfile" option -- after which you could
simply enter
>> "crash vmlinux outputfile" -- because your implementation requires
that the
>> user must be aware of the base physical address value.
>>
>> Anyway, this all sounds good, so please post a patch. And can you also make one
of
>> these dumpfiles available to me to download?
>>
>> Thanks,
>>
>> Dave
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
Hi Dave,
Patch attached implements raw RAM image support. I have tested it with
a ARM ramdump. Will test it with a arm64 ramdump tomorrow and will
post the results.
I haven't tested this yet, but I do note that the patch doesn't
apply because it appears like you were working with crash-7.0.5?
In the future, please post patches against either the upstream
git development branch, or at least against the current upstream
release, currently crash-7.0.7.
With this change, a raw RAM image can be passed to crash in the following way.
./crash [path to ram image] [path to vmlinux] --ram_start=[address] -o output_file
To start with I have assumed that, dump of a single memory node will
be a single file. That means, the 2 RAM images (ddr1.bin and ddr2.bin
which I guess belongs to a single node) mentioned in the first email
of this mail chain, should be concatenated and passed as a single
file. When multiple images are passed with multiple --ram_start, it
will be considered as different memory nodes, like below.
./crash [path to ram image of node 1] [path to ram image of node 2] [path to vmlinux]
--ram_start=[start address of node 1] --ram_start=[start address of node 2] -o output_file
Anyway, before going any further, the whole command line user-interface
is too complex, verbose, and error-prone. Also, the patch adds too much
RAM-dump related stuff to main(), where the "nodes", "rams",
"rd" and
"elf_out" variables really belong in the ramdump.c file. This is really
just another dumpfile type, and it should be handled in a similar manner
as the other types.
Now, breaking this down, what we have to handle during invocation in main()
is one or more blocks of RAM that start at some physical address, i.e.,
one or more "ram@address" ordered pairs. Why not have a single,
uniquely-identifiable argument string that describes the whole entity?
Here is my counter-proposal, where the invocation would be something
like this:
$ crash vmlinux ramdump@address [-o output_file]
and if there are multiple images, make them a comma-separated list:
$ crash vmlinux ramdump1@address,ramdump2@address [-o output_file]
Then here in main(), handle it like the other "is_dumpfile_type()"
functions by passing the single argument string to an is_ramdump()
function in your ramdump.c file:
while (argv[optind]) {
+ if (is_ramdump(argv[optind]) {
+ if (pc->flags & MEMORY_SOURCES) {
+ error(INFO, "too many dumpfile arguments\n");
+ program_usage(SHORT_FORM);
+ }
+ pc->dumpfile = ramdump_to_elf();
+ if (is_kdump(pc->dumpfile, KDUMP_LOCAL)) {
+ pc->flags |= KDUMP;
+ pc->readmem = read_kdump;
+ pc->writemem = write_kdump;
+ } else {
+ error(INFO, "malformed ELF dump file: %s\n",
+ pc->dumpfile);
+ program_usage(SHORT_FORM);
+ }
+ continue;
+ }
if (is_remote_daemon(argv[optind])) {
if (pc->flags & DUMPFILE_TYPES) {
error(INFO,
"too many dumpfile/memory arguments\n");
program_usage(SHORT_FORM);
}
pc->flags2 |= REMOTE_DAEMON;
optind++;
continue;
}
The is_ramdump() function can verify if it's a valid argument
by first checking for the required/unique "@" character in the
argument string. It can then parse the argument, and save the
required "nodes", "rams", etc. in a "ramdump_def" structure
that can be statically declared in ramdump.c. You should also
have a dump_ramdump_def() function that can be called from
"help -[Nd]".
With respect to the [-o output_file], and given the potential
simplicity of the argument string, I think it should be
optional. You could do something like this in the getopt()
handler, and have the ELF output_file name pre-stored in the
ramdump_def structure:
+ case 'o':
+ ramdump_elf_output_file(optarg);
+ break;
If "-o output_file" is NOT used, then ramdump_to_elf() can
pass back the name of a temporary file.
I can share the memory dumps used.
Thanks,
Vinayak
Great, thanks, I've got them...
I'd also really appreciate having a sample RAM dump from an ARM64
machine as well.
Thanks,
Dave