2:25 a.m.
Hi
Thanks for your quick answer.
On Wed, May 27, 2009 at 4:49 PM, Dave Anderson <anderson(a)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
3:06 a.m.
New subject: Cannot open dump when using 2G/2G memory split with 2.6.27.21 SMP x86 kernel
Hi again
Something was not right in my last post.
<readmem: 8053f700, KVADDR, "kernel_config_data", 32768,
(ROE), 97ab7f8>
..
<readmem: 807348c0, KVADDR, "cpu_possible_map", 4,
(ROE), 8430680>
..
Now after sending this mail, I noticed that the values from running
system that I
copy-pasted do not actually match to symbols from image.
# cat /proc/kallsyms |grep kernel_config_data
8053e700 r kernel_config_data
# cat /proc/kallsyms |grep cpu_possible_map
....
807328c0 B cpu_possible_map
I did check them previously but now I need to verify them again. I
have tried several
combinations, so it might be that I just booted up the wrong kernel.
If this is just a stupid user error, I'll apologize for taking your time...
Tero
4:11 a.m.
New subject: Cannot open dump when using 2G/2G memory split with 2.6.27.21 SMP x86 kernel
Hi
On Thu, May 28, 2009 at 11:06 AM, Tero Pirkkanen <tp(a)pirkkanen.net> wrote:
Hi again
Something was not right in my last post.
> <readmem: 8053f700, KVADDR, "kernel_config_data", 32768, (ROE),
97ab7f8>
..
> <readmem: 807348c0, KVADDR, "cpu_possible_map", 4, (ROE), 8430680>
..
Now after sending this mail, I noticed that the values from running
system that I
copy-pasted do not actually match to symbols from image.
# cat /proc/kallsyms |grep kernel_config_data
> 8053e700 r kernel_config_data
> # cat /proc/kallsyms |grep cpu_possible_map
....
> 807328c0 B cpu_possible_map
This was a problem in the kernel build process I use after all. I just
rebuilt the smp and smp-syms kernels form the same sources (only
difference is CONFIG_DEBUG_INFO) and objdump shows that the addresses
in the symbol table differs. (8053f700 vs. 8053e700 for
kernel_config_data).
For some reason the other configuration combinations produced a correct result.
There is nothing wrong in crash, so I must apologize again for these
unnecessary posts.
Well, at least I learnt something new...
Errare humanum est,
Tero
6:16 a.m.
New subject: Cannot open dump when using 2G/2G memory split with 2.6.27.21 SMP x86 kernel
Hi yet again, hopefully the last time you hear from me regarding this issue...
Even though this is not crash-utility related issue and it's highly
unlikely that someone else runs in to this problem, I'll tell the end
result.
This was a problem in the kernel build process I use after all. I
just
rebuilt the smp and smp-syms kernels form the same sources (only
difference is CONFIG_DEBUG_INFO) and objdump shows that the addresses
in the symbol table differs. (8053f700 vs. 8053e700 for
kernel_config_data).
For some reason the other configuration combinations produced a correct result.
There is nothing wrong in crash, so I must apologize again for these
unnecessary posts.
I was able to get the crash dump of SMP kernel with 2G/2G split to
work by upgrading to 2.6.27.24 kernel. After that kernel build
produced identical symbol table of vmlinux with or without
CONFIG_DEBUG_INFO.
Same configuration (from applicable part) also works with 2.6.28 and
2.6.29. So the only combination that produces the mismatch in symbol
tables is the reported
2.6.27.21 SMP with 2G split. I'm not saying that there is something
wrong in kernel makefiles, but without further investigation there
seems to be a (very) small possibility that this is the case...
Thanks,
Tero
5511
days inactive
5511
days old
devel@lists.crash-utility.osci.io
3 comments
1 participants
participants (1)
-
Tero Pirkkanen