Re: Cannot open dump when using 2G/2G memory split with 2.6.27.21 SMP x86 kernel

Dave Anderson <anderson@xxxxxxxxxx> · Wed, 27 May 2009 09:49:01 -0400 (EDT)

----- "Tero Pirkkanen" <tp@xxxxxxxxxxxxx> wrote:

> 
> Hello
> 
> I've been trying to open crashdump produced by 2.6.27.21 SMP kernel
> with 2G memory split without luck.
> I tried to generate the dump by copying from /proc/vmcore and with
> makedumpfile 1.3.3. Both without success.
> The crash works fine with uniprocessor kernel as well as SMP kernel
> using standard memory split. Architecture is 32bit x86 and the crash
> was generated inside vmware server 2.0.
> 
> Is this supported configuration? Have anybody tried crash dump with 2G
> split in recent 2.6.x kernels?

Apparently not -- at least I've never tried it...

But looking at the output, it's failing to read simple unity-mapped
memory, which I presume to be due to a failure to calculate the
correct machdep->kvbase in x86.c:x86_init() here at line 1740:

  machdep->kvbase = symbol_value("_stext") & ~KVBASE_MASK;

And based upon that value, whenever an x86 unity-mapped kernel 
virtual address is requested, it simply does this to find the physical
address:

  #define VTOP(X)            ((unsigned long)(X)-(machdep->kvbase))

And given that the initial set of data accesses are all simply
unity-mapped addresses and the data that is being read is obviously
junk (presuming that you don't have 32 online cpus): 

> .... skip to end
> <readmem: 8053f700, KVADDR, "kernel_config_data", 32768, (ROE), a5f17c0>
> WARNING: could not find MAGIC_START!
> <readmem: 807348c0, KVADDR, "cpu_possible_map", 4, (ROE), 8430680>
> cpu_possible_map: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> 21 22 23 24 25 26 27 28 29 30 31
> <readmem: 806c478c, KVADDR, "cpu_present_map", 4, (ROE), 8430680>
> cpu_present_map: 3 7 8 9 10 14 18 19 21 22 31
> <readmem: 806c42a0, KVADDR, "cpu_online_map", 4, (ROE), 8430680>
> cpu_online_map: 8 9 14 18 19 21 22 31
> <readmem: 807506e0, KVADDR, "xtime", 8, (FOE), 8408d38>
> <readmem: 80679e84, KVADDR, "init_uts_ns", 390, (ROE), 840931c>
> crash: cannot determine base kernel version
> <readmem: 8053a000, KVADDR, "accessible check", 4, (ROE|Q), ff96df04>
> <readmem: 8053a000, KVADDR, "readstring characters", 1499, (ROE|Q), ff96cf00>
> linux_banner:
> &y ï¿½&y ï¿½&y ï¿½(z ï¿½]z ï¿½jz ï¿½ï¿½z ï¿½aï¿½ ï¿½fï¿½ ï¿½ï¿½ï¿½ ï¿½ï¿½ ï¿½ï¿½ï¿½ ï¿½9ï¿½ ï¿½ï¿½ ï¿½0ï¿½ ï¿½6ï¿½ ï¿½<ï¿½ ï¿½ÐŠ
> ï¿½Bï¿½ ï¿½Hï¿½ ï¿½Nï¿½ ï¿½
> crash: s3/boot/vmlinux-2.6.27.21+smp-syms and
> kerneldump-20090526-140502 do not match

So it looks to be a miscalculation of machdep->kvbase.

If you take the same dumpfile above, but use -d8 instead of -d7, you'll
also see the translated physical address after each "readmem" line
above.  

In any case, first determine what's machdep->kvbase is being set
to -- I'm presuming that it should be 0x8000000, but maybe not?

Dave

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility