Dave Anderson wrote: > Try using at least -d4 and redirect the output to a file. It's much > more verbose than the above, but it shows every readmem() made from > the dumpfile: > > # crash -d4 vmlinux vmcore.cp > /tmp/debug.cp > q > # crash -d4 vmlinux vmcore.makedumpfile > /tmp/debug.makedumpfile > q > # > > Then compare the two outputs -- they should be pretty much identical > (except for any crash utility user addresses) until the vmcore.makedumpfile > fails. So you should see a successful readmem() of e0000060031417a8 in > the "vmcore.cp" debug output at the point where it fails doing the > read in "vmcore.makedumpfile" above. > > What's kind of strange is that pglist_data.node_zones structure that > it's reading from is in the same page as the base pglist_data > at e000006003140000, i.e., at page offset 17a8 (6056). And the code > looks like it has already read data from that same page prior to > reading the "zone spanned pages". (I'm presuming that the ia64 page > size you're using is greater than 4k). But the -d4 output will > confirm that. Looks like it. In the case of 'cp': ... node_table[0]: id: 0 pgdat: e000006003140000 size: 62720 present: 62720 mem_map: a07ffff8fdd0a800 start_paddr: 6003000000 start_mapnr: 6292224 ... In the case of makedumpfile: ... node_table[0]: id: 0 pgdat: e000006003140000 size: 62720 present: 62720 mem_map: a07ffff8fdd0a800 start_paddr: 6003000000 start_mapnr: 6292224 crash: page excluded: kernel virtual address: e0000060031417a8 type: "zone spanned_pages" jay > > Dave > >