----- 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@xxxxxxxxxx > > 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
