----- Original Message ----- > > > > I believe the 32-bit vs. 64-bit ELF header is configurable, correct? > > Now if max phyiscal address of ARM platform execceding 4G, kexec > creates 64-bit ELF header. Otherwise, it creates 32-bit ELF header. > > > On RHEL, by default we configure 64-bit ELF headers for 32-bit x86 > > machines regardless of their memory size. So you should be able to > > create a vmcore with a 64-bit ELF header on a system that has less > > than 4GB of physical memory. > > For now the ARM kernel can not parse 64-bit ELF header without my patch > locating at "https://lkml.org/lkml/2014/5/3/63". So perhaps we can not > create a vmcore with 64-bit ELF header for ARM. Otherwise all old > ARM kernels can not generate vmcores correctly. OK. > > But as I mentioned above, there will need to be at least one fix for > > the crash utility, because it will fail at line 258 of netdump.c. > > To accept 64-bit ARM headers, there would need to be a additional > > case statement like this: > > > > case EM_ARM: > > if (machine_type_mismatch(file, "ARM", NULL, > > source_query)) > > goto bailout; > > break; > > > > I'm not sure whether any other fixes would be required? > > On our platform, I usually use makedumpfile to reduce vmcore. > Then it comes to diskdump format. > > But when I dealed with original vmcores. This error occurs: > > ..... > WARNING: machine type mismatch: > crash utility: ARM > ../github/1381_4/vmcore: (unknown) > > crash: ../github/1381_4/vmcore: not a supported file format > > When fully checking is done, I will send the related patches. > Sorry for this mistake! OK thanks -- no problem... > > Note that in some earlier kernels, the "_text" symbol is often much > > higher. But I presume that it would be highly unlikely that the difference > > would ever be 0x5000 in an older kernel -- so until somebody reports a > > problem, it seems OK to do it that way. > > > > However, just in case the layout changes in the future, there should be > > a fail-safe check for the VMCOREINFO_CONFIG(ARM_LPAE) in arm_init(), > > that does something like this: > > > > if ((string = pc->read_vmcoreinfo("CONFIG_ARM_LPAE"))) { > > machdep->flags |= PAE; > > free(string); > > } else > > [check for 0x5000 difference] > > > > There's really no need to check for the "y" contents of the string, because > > if the entry exists, then CONFIG_ARM_LPAE is configured. > > Yes, you advice is much better. We should add this. And perhaps we should also find > another way to recognise LPAE enableed vmcores for old kernels, rather than pg_dir_size. The only other way I can think of is if there is a kernel symbol that only exists in LPAE kernels. I took a quick look at the kernel sources, and didn't see anything obvious, but something may exist. But the swapper_pg_dir size check is a reasonable way to do it. Perhaps a slightly better way would be to compare the symbol value of "swapper_pg_dir" with next higher symbol. Something like this: sp1 = symbol_value("swapper_pg_dir"); sp2 = next_symbol_value("swapper_pg_dir", NULL); difference = sp2->value - sp2->value; In my sample set of ARM dumpfiles, the above results in 0x4000 on all of the non-LPAE kernels. > > BTW, what do you think about parseing big endian vmcores(such as ARMEB vmcores) on > x86-64 host? That cannot be done. The 32-bit x86 binary built on an x86_64 host will be little-endian. The "target=xxx" capability only works if the host machine endianness and data type sizes are the same as the target architecture. Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility