Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752151AbZAKEwZ (ORCPT ); Sat, 10 Jan 2009 23:52:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750785AbZAKEwO (ORCPT ); Sat, 10 Jan 2009 23:52:14 -0500 Received: from rv-out-0506.google.com ([209.85.198.226]:1857 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750782AbZAKEwM (ORCPT ); Sat, 10 Jan 2009 23:52:12 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xxQCChrKzb0zu26wtOt97lWk9VkjbMxwA7rjrqgLcBunV5xgnAecMUbSSCJ0ZTWLWE c57DoIzRi06K18fQPGfLMvevK0gdIn4ckxJnKrCN8iWuzHbliqAlXpD1+L3xqlb9gAPC Qif/T34AXyTS5gNR3ssI8jsgtWG/s5fQZNVKk= Message-ID: <170fa0d20901102052s7488ff0bl14507169fd4c03b3@mail.gmail.com> Date: Sat, 10 Jan 2009 23:52:11 -0500 From: "Mike Snitzer" To: "Ingo Molnar" Subject: Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact] Cc: "Nicholas Miell" , "Linus Torvalds" , "jim owens" , "H. Peter Anvin" , "Chris Mason" , "Peter Zijlstra" , "Steven Rostedt" , paulmck@linux.vnet.ibm.com, "Gregory Haskins" , "Matthew Wilcox" , "Andi Kleen" , "Andrew Morton" , "Linux Kernel Mailing List" , linux-fsdevel , linux-btrfs , "Thomas Gleixner" , "Nick Piggin" , "Peter Morreale" , "Sven Dietrich" , sam@ravnborg.org, "Dave Anderson" , "Eric W. Biederman" In-Reply-To: <20090111012811.GG12885@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <170fa0d20901100621m74680e0ewd1916c70f1636c9b@mail.gmail.com> <20090110153446.GA13976@elte.hu> <170fa0d20901101021s3b9a18e9qe6150c374efa4d6f@mail.gmail.com> <20090111012811.GG12885@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2409 Lines: 49 On Sat, Jan 10, 2009 at 8:28 PM, Ingo Molnar wrote: > > Note, back when kdump was added to the kernel many moons ago i strongly > supported it and helped out with the patches, etc. I still think it might > have the potential to become big - but it needs a ton of tech and care to > reach that level of convenience. > > 'kdump light' perhaps that dumps the most important data structures like > registers of all CPUs, task struct and the symbol tables, the current task > itself including the kernel stack plus the surrounding 4K of all pointers > that are in current registers and that point into kernel memory - maybe > straight to kerneloops.org [if the user agrees] - or something like that. I think 'kdump light' is a good idea. I'm all for infrastructure that works better for more people. Having to deal with multi-gigabyte dump files can be a chore. The mechanics of dumping your suggested 'light' amount of data vs. all memory should be configurable (e.g. /sys/kernel/kexec_crash_light). And this obviously doesn't change the potentially fragile nature of kexec'ing to a crash kernel from an arbitrary context; or the fact that drivers can easily be incompatible with cleanly shutting down and restarting on kexec. I worked with Eric Biederman testing in the early days of his kexec work and the e1000 driver was incompatible with kexec at that time (IFF it was built into the kernel, workaround was to use a module and unload it before kexec, *shudder*; I was using kexec in a custom bootloader for a storage appliance, not for kdump). But honestly 99+% of my filesystem/storage enduced Linux crashes kexec/kdump properly (with RHEL5, 2.6.22, 2.6.25, and 2.6.28); so all the hard work of people like yourself and other kexec/kdump hackers (upstream and at RedHat) really is paying off for real Linux users! The fairly recent kvm kdump compatibility work (2340b62f) is a perfect example of how hard things can be. But it is encouraging to see such commendable effort being put to making kdump workable for all. Now if only I could fix line numbers when debugging crashes in x86_64 modules with the crash utility! :) Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/