Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758235Ab0FCJBl (ORCPT ); Thu, 3 Jun 2010 05:01:41 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:40743 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752209Ab0FCJBj convert rfc822-to-8bit (ORCPT ); Thu, 3 Jun 2010 05:01:39 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; b=qsugCnMj3FjYMtUgrwJ7+zl+rppW0hsCxsmwur+yNEGcEgik+OYdgifr7hgtBwgJe4 8fdQ/8dEBGLB+Uw2YefXzar27kV7Z1EhsMYEkcOLQI5IHXtVxZ2/LMLH8AZL9b3uY13a oGjMegeWg943PgFaI4Yp1nGdh4zKT0fGdZBvY= Date: Thu, 03 Jun 2010 11:01:38 +0200 Message-ID: <87iq60a3rh.wl%vmayatsk@redhat.com> From: Vitaly Mayatskikh To: Vivek Goyal Cc: Vitaly Mayatskikh , linux-kernel@vger.kernel.org, Andrew Morton , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Randy Dunlap Subject: Re: [PATCH 0/5] kdump: extract log buffer and registers from vmcore on NMI button pressing In-Reply-To: <20100602151611.GA3174@redhat.com> References: <1275464359-1566-1-git-send-email-v.mayatskih@gmail.com> <20100602151611.GA3174@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/23.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1750 Lines: 38 At Wed, 2 Jun 2010 11:16:11 -0400, Vivek Goyal wrote: > I am not sure what is the problem we are trying to solve here. If we are > unable to capture the dump because second kernel did not boot due to > some dirver issue etc, above patch is not going to help either. > > If kernel has booted, then one should be able to capture the dump, filter > it and look at the log buffers and cpu registers. > > Most of the failures I have seen in capture kernel is that it was unable > to boot due to either deivce issues or failure in early boot. Once it has > crossed those hurdles, after that capturing the dump is easy part. > > How many times does it happen in second kernel that kernel is spinning in > a loop and NMI can still get you information out. > > So can you please give some more information about what kind of failures > while capturing the dump you are addressing by this patchset. Obviously, this change doesn't help if 2nd kernel is not able to boot. But there are other problems, which may prevent vmcore to be captured. For example, machine has RAM > HDD and it may save vmcore only over network. If network fails (e.g., due to bugs in NIC drivers or NFS, what is not so rare), and dump capture environment is non-interactive, or it doesn't have development tools like `crash', there's no chance even to guess what has happened. Other possibilities of failure may include broken RAID controller, HDD, RAM. NMI button in such situations is a last chance to see old log. -- wbr, Vitaly -- 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/