From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 07:43:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A3FA16A4CE for ; Tue, 14 Dec 2004 07:43:38 +0000 (GMT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF23043D54 for ; Tue, 14 Dec 2004 07:43:37 +0000 (GMT) (envelope-from csujun@gmail.com) Received: by mproxy.gmail.com with SMTP id w41so329016cwb for ; Mon, 13 Dec 2004 23:43:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:mime-version:content-type:content-transfer-encoding; b=YpcGebePpgi0ybF2z8aJaE6LrIcUFfTlrFOc/4NTUEa7hhg+4WcNr5wtOJ/AgA2WYwu0T5ZlDTDC99Xq0P0Smb10n+cnQW64ZDw1jCjF5EkyR91C0YPxULMdag3Yp3DWyL+oeZ7HH0NPnzpZ8ON7gbCPf95sF1fuwg54tXkzg3Q= Received: by 10.11.94.12 with SMTP id r12mr199851cwb; Mon, 13 Dec 2004 23:43:37 -0800 (PST) Received: by 10.11.118.15 with HTTP; Mon, 13 Dec 2004 23:43:37 -0800 (PST) Message-ID: Date: Tue, 14 Dec 2004 15:43:37 +0800 From: Jun Su To: arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: alc@freebsd.org cc: tegge@freebsd.org cc: delphij@FreeBSD.org Subject: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jun Su List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 07:43:38 -0000 Backgroud ======== Many modern server machines have over 4G, even 16G memory. Full Memory Dump is nightmare for them. In the Linux world, there is a project named LKD that support several dump methods. In Windows, it also supports MiniDump, KernelOnlyDump and FullDump. In our use base, many users can only report the call-stack to the newsgroup. For these users, a MiniDump can severve them very well. Most important message can be generagte at the dumptime and save into dump file. For the limitation of our current kgdb, we can not trace the stack into user memory space. In this scenerio, a KernelOnly dump contains the informaiton that we can used. And in most panic scenerio, VM system is not the root cause and its data structure are very well. It is not so risky to rely on the data of VM subsystem. And we can even create a method to check if the VM subsystem is in a good state before we did KernelOnlyDump. Kernel-Only Dump ============== We now can use /dev/kmem as the core file. If we can generate a dump file with the same information with it, then we can enable kernel-only dump with very limit code changes. 1. Change KVM library to support a new type of file that only contains kernel memory. 2. Change kernel side to write only kernel memory when dumping. 3. Change dumpon utility to do the right checking on the partiction size. MiniDump ======= In a minidump, Register info, plus the crash stack is enough. New Dump MI interface ================= There is only dumpsys method as the MI interface for the dump system. And if we look at the implementation of AMD, x86, Alpha, we will find they are very similiar. We need revise this interface when importing these new feature in. I post this in order to get some feedback and thinking about this idea. Thanks, Jun