[Crash-utility] Re: Cannot open dump when using 2G/2G memory split with 2.6.27.21 SMP x86 kernel

Tero Pirkkanen tp at pirkkanen.net
Thu May 28 07:25:31 UTC 2009


Hi

Thanks for your quick answer.

On Wed, May 27, 2009 at 4:49 PM, Dave Anderson <anderson at redhat.com> wrote:

> unity-mapped addresses and the data that is being read is obviously
> junk (presuming that you don't have 32 online cpus):

Yes. Junk it is.

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

I added a line that prints the kvbase:

   printf("** kvbase: %x (%x)\n", machdep->kvbase, symbol_value("_stext"));

It produced a value, that to me seems to be correct:

   ** kvbase: 80000000 (80201000)

My kernel configuration says:
#  zcat /proc/config.gz |grep PAGE_OFFSET
CONFIG_PAGE_OFFSET=0x80000000

Also the UP kernel with 2G split (which works) have these same values.

> 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.

Couple of first symbols:
<readmem: 8053f700, KVADDR, "kernel_config_data", 32768, (ROE), 97ab7f8>
   addr: 8053f700  paddr: 53f700  cnt: 2304
   addr: 80540000  paddr: 540000  cnt: 4096
   addr: 80541000  paddr: 541000  cnt: 4096
   addr: 80542000  paddr: 542000  cnt: 4096
   addr: 80543000  paddr: 543000  cnt: 4096
   addr: 80544000  paddr: 544000  cnt: 4096
   addr: 80545000  paddr: 545000  cnt: 4096
   addr: 80546000  paddr: 546000  cnt: 4096
   addr: 80547000  paddr: 547000  cnt: 1792
WARNING: could not find MAGIC_START!
GETBUF(128 -> 0)
FREEBUF(0)
GETBUF(4 -> 0)
<readmem: 807348c0, KVADDR, "cpu_possible_map", 4, (ROE), 8430680>
   addr: 807348c0  paddr: 7348c0  cnt: 4
...
When I compare the address to addresses from running system, at least
the addresses from symbol table seems to be right. I have compiled the
kallsyms in:

# cat /proc/kallsyms |grep kernel_config_data
8053e700 r kernel_config_data
# cat /proc/kallsyms |grep cpu_possible_map
8065f4a4 r __ksymtab_cpu_possible_map
80666d26 r __kstrtab_cpu_possible_map
807328c0 B cpu_possible_map
...
Also the symbol from the vmlinux image containing debugging symbols is correct:

# objdump -t s3/boot/vmlinux-2.6.27.21+smp-syms |grep kernel_config_data
8053f700 l     O .rodata        00002b3a kernel_config_data

Any suggestion how to continue would be appreciated...

Thank you again,
Tero




More information about the Crash-utility mailing list