----- "Kevin Worth" <kevin.worth(a)hp.com> wrote:
Hi Dave,
Thanks for all your help with the crash/kexec troubleshooting, I
really appreciate it. At this point I’m going toward the
kernel/kexec/kdump side of things and am trying to do whatever
research I can before sending another mail to kexec-ml. I tried to see
if the issue still occurs with the Ubuntu “generic” kernel, which has
HIGHMEM4G instead of HIGHMEM64G, and the standard VMSPLIT/PAGE_OFFSET
setting. I also noted that enabling HIGHMEM64G also implicitly seems
to select CONFIG_RESOURCES_64BIT=y which was marked Experimental in
2.6.20 (hmmm).
Interestingly enough, when I use the Ubuntu "generic" kernel
(HIGHMEM4G + normal VMSPLIT), the crash dump works just fine and I can
view the modules, etc. This leads me to believe that it's either the
HIGHMEM64G or the modified VMSPLIT that is causing the problem (or
both in combination). I'm going to try compiling kernels with only one
setting changed in each to try to isolate the issue.
Warning: probably a stupid question-- My machine has 4GB of memory. If
I boot the "generic" kernel with HIGHMEM4G, only 3GB is recognized
(according to my understanding of free and /proc/meminfo results).
However, when I create a dump and load it up in crash, I see " MEMORY:
4 GB". Am I just misunderstanding the output of free/meminfo or is
this just crash calculating something differently?
It's the same as my answer about how the "MEMORY: 5GB" was reported
on your earlier dumpfile. If you run with the "-d 1" command line
option, check out the crash-internal "node_table[0]" dump, and multiply
the "present" value times 4K (PAGE_SIZE).
When you run on the live system with "-d 1", the "node_table[0]"
output will be the same as what you see with the dumpfile.
BTW, that's presuming that, with your new kernel configuration,
that your kernel still creates just one node. If by chance, there
are more than one node, you'll see an additional node_table[1] dump,
etc., and the MEMORY: display is the sum total of all the "present"
pages.
Dave