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? The reason I ask is
that if it turns out that HIGHMEM64G is causing the problem with putting the
vmalloc'ed memory into the dump file, then I am trying to understand if that becomes a
compromise of the system only being able to use 3GB of RAM but crash dumps still work.
-Kevin