[Crash-utility] x86 remap allocator in kernel 3.0

[Petr Tesarik]

Dne Pá 13. ledna 2012 04:22:50 tachibana at mxm.nes.nec.co.jp napsal(a):
> Hi Petr,
> 
> On 2012/01/12 11:40:08 +0100, Petr Tesarik <ptesarik at suse.cz> wrote:
> > Dne ?t 12. ledna 2012 09:16:06 Atsushi Kumagai napsal(a):
> > > Hello Petr,
> > > 
> > > On Tue, 10 Jan 2012 19:14:32 +0100
> > > 
> > > Petr Tesarik <ptesarik at suse.cz> wrote:
> > > > 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.
> > > 
> > > Thank you for your indication.
> > > 
> > > Could you send me your kernel configuration so that I can reproduce the
> > > issue ?
> > 
> > Attached. The most important settings are:
> > 
> > CONFIG_X86_32=y
> > CONFIG_DISCONTIGMEM_MANUAL=y
> > 
> > This also depends on CONFIG_NUMA=y
> > 
> > FYI my test system runs 3.0.15 (because that's used for SLES11 SP2), but
> > the same issue also exists in any later version.
> > 
> > Petr Tesarik
> > SUSE Linux
> 
> Thank you for the config. I will fix makedumpfile. However it will take
> time to solve various issues because I've never run makedumpfile on 3.0.X.

(crash-utility ML removed from CC.)

I should add something here. I wondered why makedumpfile didn't failed while 
saving /proc/vmcore. After some futile attempts to recreate the failure, I 
realized that the ELF dump above had been saved with "makedumpfile -d 1" by 
mistake. Now, since the remapped area was unused by the kernel, it was all 
zeroes, so makedumpfile created a hole in the ELF dump.

Under normal conditions, it won't fail to read node_start_pfn, but it will 
incorrectly read it as zero, so no filtering will take place.

Petr Tesarik
SUSE Linux