Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jun 2005 23:23:25 -0700
From:      Peter Wemm <peter@wemm.org>
To:        freebsd-arch@freebsd.org, Sue Howard <howardsue@gmail.com>
Cc:        arch@freebsd.org
Subject:   Re: Kernel Dump
Message-ID:  <200506222323.26666.peter@wemm.org>
In-Reply-To: <1e89cd51050616062241e9e201@mail.gmail.com>
References:  <1e89cd51050616062241e9e201@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 16 June 2005 06:22 am, Sue Howard wrote:
> Hi,
>
> I find there are three states of kernel dump support currently.
> 1. ARM and PowerPC.
> Not supported yet.
> 2. I386, AMD64, Alpha.
> The dump file contains dump header plus the raw physical memory
> image. The code in dump_machdep.c is almost same.
> 3. IA64, SPARC
> The dump file has private header besides dump header and raw physical
> memory image. The code is ready for importing a MI dump interface.
>
> I want to understand what IA64 and SPARC are different than i386.
> What is the private header is for? Is it tech problem or historic
> problem? Is it possible to remove the private header in order to make
> IA64 and SPARC share the dump code of i386?

The private header is to standardize the way savecore(8) finds the dump 
images and recovers them.

IA64 and Sparc systems usually had sparse memory configurations and the 
old raw format didn't have any facility to avoid storing holes.

Suppose you had a machine where 1GB of ram appeared at physical adress 
0, and the other 1GB of ram appeared at physical address 7GB.  The i386 
and alpha dump method would require 8GB of dump file and swap device 
usage to record those 2 x 1GB chunks of data.

IA64 uses an ELF "coredump" format to record the memory segments that 
are scattered around its address space.  It is flexible and descriptive 
enough to handle this.

sparc64 uses its own custom format to achieve the same thing.

I've just rewritten the AMD64 crashdump support to use ELF like ia64.  
In fact, I reused most of the ia64 code. We ran into serious problems 
at work, first on the amd64 platform and now also the i386 platform.  
The problem is that x86 machines are increasinly having memory holes.  
The simplistic dump code has no way to skip the memory hole and tries 
to dump things like the AGP frame buffer, pci card MMIO space, 
PCI-Express configuration space (this means accessing hardware!!) and 
so on.

We have already switched to ELF crashdump support at work (yahoo) on 
amd64 and will be backporting to i386 and even RELENG_4 (PAE systems 
expose the same problem on this hardware).

doghouse# file /var/crash/vmcore.1
/var/crash/vmcore.1: ELF 64-bit LSB core file AMD x86-64, invalid 
version (embedded)
doghouse# objdump --headers /var/crash/vmcore.1
Sections:
Idx Name     Size      VMA         LMA         File off  Algn
  0 load0    000a0000  0000000000  0000000000  00001000  2**12
             CONTENTS, ALLOC, LOAD, READONLY
  1 load1    7c1c0000  0000100000  0000100000  000a1000  2**12
             CONTENTS, ALLOC, LOAD, READONLY
  2 load2    00100000  007ff00000  007ff00000  7c261000  2**12
             CONTENTS, ALLOC, LOAD, READONLY

It doesn't mean much, but at least the standard tools let you see inside 
the crash dump.  libkvm and gdb support is trivial.

Anyway, this isn't a new problem for i386 either.  I have one older 
machine in a server room that has 6GB of ram.  2GB at address 0-2GB, a 
2GB pci hotplug hole, and 4GB at 4-8GB.  This 5 year old machine does 
nasty things if you crash it with dumps enabled.

BTW: elf core dumps are really simple.  They're two headers (elf and 
program headers) and then the memory contents.  There isn't much to it.

> In my understanding, it should be possible. Since /dev/mem should be
> a physic memory image.

Anyway, if anything, the i386 code is going away.  Machines with sparse 
memory are becoming more common.

> Howard

-- 
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506222323.26666.peter>