Question for ARM developers/users w/respect to makedumpfile
by Dave Anderson
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
12 years, 2 months
- 4
- 11