On Mon, 31 Mar 2014 09:48:05 +0000 Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote: > [snip] > > >> > That's because the bitmap length is calculated in prepare_bitmap_buffer > >> > using info->max_mapnr, but create_1st_bitmap() still loops over all > >> > PT_LOAD segments, calling set_bit_on_1st_bitmap() for each PFN. The > >> > offset may easily fall beyond the bitmap size. > >> > >> What about the following patch. It works for me when I specify > >> the "--non-cyclic" option. > >> > >> Michael > >> --- > >> [PATCH] makedumpfile: Fix bitmap create for adjusted info->max_mapnr > >> > >> If info->max_mapnr has been adjusted, for example because the dumped > >> system has specified the "mem=" kernel parameter, makedumpfile writes > >> the following error messages for Xen dumps or when the "--non-cyclic" > >> option has been specified: > >> > >> set_bitmap: Can't read the bitmap(/tmp/kdump_bitmap96s9V8). Success > ^^^^^^^^ > This looks confusing, is it an actual message ? > I suppose it must be "Invalid argument" like Petr's log. Right, I get "Invalid argument". No idea from where I pasted "Success" here... > >> > >> Fix this and consider "info->max_mapnr" in the create bitmap functions. > >> > >> Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com> > >> --- > > [snip] > I found another issue of truncating max_mapnr for Xen. > > The bitmap manages MFN(machine frame number) for Xen > while __exclude_unnecessary_pages() treats PFN(guest-physical frame number). > __exclude_unnecessary_pages() expects that all bits of PFNs > are mapped in the bitmap even if it was reduced by truncated > max_mapnr. However, PtoM mapping isn't linear(probably...), > there is no guarantee that a set of continuous PFNs is mapped > in a set of continuous MFNs. > So the actual I/O offset can exceed the bitmap size when the > bitmap size is reduced. > > In the first place, we shouldn't truncate max_mapnr > based on dom0's mem_section since there are some domU's > memories on Xen dumps. Now, I think a better way for Xen > is just leaving max_mapnr as it is. > > Do you agree with my view ? I don't know the Xen details so I would leave it to Petr to answer this question. Michael
