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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
