[Crash-utility] "cannot access vmalloc'd module memory" when loading kdump'ed vmcore in crash

Worth, Kevin kevin.worth at hp.com
Thu Oct 16 21:02:39 UTC 2008


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




More information about the Crash-utility mailing list