Hey guys, I've completed the implementation of a new "crash --log vmcore" option that dumps the kernel log buffer contents from ELF kdump vmcores and compressed kdump vmcores using the VMCOREINFO data that's contained in an ELF note in the original /proc/vmcore, and which makedumpfile copies into the the compressed kdump header as well. It works well on all arches except ARM, more specifically with ARM compressed kdumps. (It does works OK with the one ARM ELF vmcore I have). But I only have two sample ARM vmcore files that are compressed kdumps. In both cases, it's pretty obvious that the header contains vmcoreinfo data, for example: $ strings vmcore.v2 KDUMP Linux (none) 2.6.38-rc2-00274-g1f0324c-dirty #3 SMP Fri Jan 28 09:37:08 EET 2011 armv7l (none) iC\I OSRELEASE=2.6.38-rc2-00274-g1f0324c-dirty PAGESIZE=4096 SYMBOL(init_uts_ns)=c0590368 SYMBOL(node_online_map)=c058cc2c SYMBOL(swapper_pg_dir)=c0004000 SYMBOL(_stext)=c0008000 SYMBOL(vmlist)=c0b2a4a8 SYMBOL(mem_map)=c0b2a430 SYMBOL(contig_page_data)=c05eb580 SIZE(page)=32 SIZE(pglist_data)=1792 SIZE(zone)=832 SIZE(free_area)=44 SIZE(list_head)=8 SIZE(nodemask_t)=4 OFFSET(page.flags)=0 OFFSET(page._count)=4 OFFSET(page.mapping)=16 ... But the new "crash --log vmcore" option fails because it cannot access the vmcoreinfo data above: $ crash --log vmcore.v2 crash: vmcore.v2: no VMCOREINFO section $ If I bring up a crash session with that dumpfile, and dump the compressed kdump header, I see that it was created by makedumpfile using header version 3, which means that vmcoreinfo data is included: struct kdump_sub_header { unsigned long phys_base; int dump_level; /* header_version 1 and later */ int split; /* header_version 2 and later */ unsigned long start_pfn; /* header_version 2 and later */ unsigned long end_pfn; /* header_version 2 and later */ off_t offset_vmcoreinfo; /* header_version 3 and later */ unsigned long size_vmcoreinfo; /* header_version 3 and later */ off_t offset_note; /* header_version 4 and later */ unsigned long size_note; /* header_version 4 and later */ off_t offset_eraseinfo; /* header_version 5 and later */ unsigned long size_eraseinfo; /* header_version 5 and later */ }; But note that in the actual dumpfile header dump, the "offset_vmcoreinfo" and "size_vmcoreinfo" kdump_sub_header fields are both set to 0: crash> help -n diskdump_data: filename: vmcore.v2 flags: 6 (KDUMP_CMPRS_LOCAL|ERROR_EXCLUDED) dfd: 3 ofp: 4e876a00 machine_type: 40 (EM_ARM) header: 9a178c0 signature: "KDUMP " header_version: 3 utsname: sysname: Linux nodename: (none) release: 2.6.38-rc2-00274-g1f0324c-dirty version: #3 SMP Fri Jan 28 09:37:08 EET 2011 machine: armv7l domainname: (none) timestamp: tv_sec: 495c4369 tv_usec: 0 status: 0 () block_size: 4096 sub_hdr_size: 1 bitmap_blocks: 4 max_mapnr: 65536 total_ram_blocks: 0 device_blocks: 0 written_blocks: 0 current_cpu: 0 nr_cpus: 1 tasks[nr_cpus]: 0 sub_header: 0 (n/a) sub_header_kdump: 9a188c8 phys_base: 80000000 dump_level: 31 (0x1f) (DUMP_EXCLUDE_ZERO|DUMP_EXCLUDE_CACHE|DUMP_EXCLUDE_CACHE_PRI|DUMP_EXCLUDE_USER_DATA|DUMP_EXCLUDE_FREE) offset_vmcoreinfo: 0 (0x0) size_vmcoreinfo: 0 (0x0) ... [ cut ] ... page_cache_buf: 9a21928 evict_index: 11 evictions: 219 accesses: 2996 cached_reads: 2761 (92%) valid_pages: 9a218e0 crash> I'm wondering whether that's the case with all ARM compressed kdump files? Or maybe the dumps I have were created during early development of ARM kexec/kdump? Or is it a bug with the makedumpfile facility on ARM? So my question is, do any of you have an ARM compressed kdump that you can verify has its "offset_vmcoreinfo" and "size_vmcoreinfo" fields set? Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility