Re: [Crash-utility] [PATCH] crash: ARM: support LPAE
----- 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