[Crash-utility] x86 remap allocator in kernel 3.0

Hi folks, I've just discovered that the crash utility fails to initialize the vm subsystem properly on our latest SLES 32-bit kernels. It turns out that our kernels are compiled with CONFIG_DISCONTIGMEM=y, which causes pgdat structs to be allocated by the remap allocator (cf. arch/x86/mm/numa_32.c and also the code in setup_node_data). If you don't know what the remap allocator is (like I didn't before I hit the bug), it's a very special early-boot allocator which remaps physical pages from low memory to high memory, giving them virtual addresses from the identity mapping. Looks a bit like this: physical addr +------------+ | | +------------+ +--> | KVA RAM | | +------------+ | | | | \/\/\/\/\/\/\/ | /\/\/\/\/\/\/\ | | | virtual addr | | highmem | +------------+ | |------------| | | -----> | | +------------+ | +------------+ | remap va | --+ | KVA PG | (unused) +------------+ +------------+ | | | | | | -----> | RAM bottom | +------------+ +------------+ This breaks a very basic assumption that crash makes about low-memory virtual addresses. The attached patch fixes the issue for me, but may not be the cleanest method to handle these mappings. Ken'ichi Ohmichi, please note that makedumpfile is also affected by this deficiency. On my test system, it will fail to produce any output if I set dump level to anything greater than zero: makedumpfile -c -d 31 -x vmlinux-3.0.13-0.5-pae.debug vmcore kdump.31 readmem: Can't convert a physical address(34a012b4) to offset. readmem: type_addr: 0, addr:f4a012b4, size:4 get_mm_discontigmem: Can't get node_start_pfn. makedumpfile Failed. However, fixing this for makedumpfile is harder, and it will most likely require a few more lines in VMCOREINFO, because debug symbols may not be available at dump time, and I can't see any alternative method to locate the remapped regions. Regards, Petr Tesarik SUSE Linux