>>Seeing further, I could see that the "get_mem_map" function at the end >>[if (!is_xen_memory())] >>is attempting to change "info->max_mapnr" value based on "mem=" option. >>-- in particular commit ebe2fa3a5c1e2bfac3778c0fbeca4287a934cc58. >>And in my kernel command line, "mem=2G" was present, as I intended to >>take dump of 2G RAM, >>resulting into reduced "info->max_mapnr". > > Basically, this adjusting info->max_mapnr must be harmless since > it just intends to ignore unused memory regions. > Did you find out why adjusting info->max_mapnr causes the problem ? > Operation of "write_kdump_pages_and_bitmap_cyclic" depends on info->max_mapnr value. That is the reason why we have problem with kdump compressed dump, but not with elf formatted dump. >From the memory regions that I have, the last region does not seem to be mapped (which contains the address sought by crash); because of which, info->max_mapnr is getting adjusted to some reduced value (compared to the previous info->max_mapnr of 880203). Following is the memory regions that I have: mem_map (0) mem_map : ffff8008000c6280 pfn_start : 0 pfn_end : 40000 mem_map (1) mem_map : 0 pfn_start : 40000 pfn_end : 80000 mem_map (2) mem_map : 0 pfn_start : 80000 pfn_end : c0000 mem_map (3) mem_map : 0 pfn_start : c0000 pfn_end : 100000 mem_map (4) mem_map : 0 pfn_start : 100000 pfn_end : 140000 mem_map (5) mem_map : 0 pfn_start : 140000 pfn_end : 180000 mem_map (6) mem_map : 0 pfn_start : 180000 pfn_end : 1c0000 mem_map (7) mem_map : 0 pfn_start : 1c0000 pfn_end : 200000 mem_map (8) mem_map : 0 pfn_start : 200000 pfn_end : 240000 mem_map (9) mem_map : 0 pfn_start : 240000 pfn_end : 280000 mem_map (10) mem_map : 0 pfn_start : 280000 pfn_end : 2c0000 mem_map (11) mem_map : 0 pfn_start : 2c0000 pfn_end : 300000 mem_map (12) mem_map : ffff800045136a80 pfn_start : 300000 pfn_end : 340000 mem_map (13) mem_map : ffff800046136480 pfn_start : 340000 pfn_end : 380000 mem_map (14) mem_map : ffff800047136c00 pfn_start : 380000 pfn_end : 3c0000 mem_map (15) mem_map : 0 pfn_start : 3c0000 pfn_end : 400000 mem_map (16) mem_map : 0 pfn_start : 400000 pfn_end : 440000 mem_map (17) mem_map : 0 pfn_start : 440000 pfn_end : 480000 mem_map (18) mem_map : 0 pfn_start : 480000 pfn_end : 4c0000 mem_map (19) mem_map : 0 pfn_start : 4c0000 pfn_end : 500000 mem_map (20) mem_map : 0 pfn_start : 500000 pfn_end : 540000 mem_map (21) mem_map : 0 pfn_start : 540000 pfn_end : 580000 mem_map (22) mem_map : 0 pfn_start : 580000 pfn_end : 5c0000 mem_map (23) mem_map : 0 pfn_start : 5c0000 pfn_end : 600000 mem_map (24) mem_map : 0 pfn_start : 600000 pfn_end : 640000 mem_map (25) mem_map : 0 pfn_start : 640000 pfn_end : 680000 mem_map (26) mem_map : 0 pfn_start : 680000 pfn_end : 6c0000 mem_map (27) mem_map : 0 pfn_start : 6c0000 pfn_end : 700000 mem_map (28) mem_map : 0 pfn_start : 700000 pfn_end : 740000 mem_map (29) mem_map : 0 pfn_start : 740000 pfn_end : 780000 mem_map (30) mem_map : 0 pfn_start : 780000 pfn_end : 7c0000 mem_map (31) mem_map : 0 pfn_start : 7c0000 pfn_end : 800000 mem_map (32) mem_map : 0 pfn_start : 800000 pfn_end : 840000 mem_map (33) mem_map : 0 pfn_start : 840000 pfn_end : 880000 mem_map (34) mem_map : 0 pfn_start : 880000 pfn_end : 880203 >>So, I commented out this portion and confirmed that "info->max_mapnr" >>remains same >>throughout. And I was able to get kdump compressed vmcore process-able >>by crash utility. > > This sounds like there are some valid data beyond the adjusted info->max_mapnr, > is that true ? I am not sure about it, but crash does look for data in mem_map(34), I haven't yet look into this in-detail. I will do that soon. Regards, Abhishek
