Date:	Fri, 4 Jun 2010 10:42:02 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Vitaly Mayatskikh <v.mayatskih@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Randy Dunlap <rdunlap@...otime.net>
Subject: Re: [PATCH 0/5] kdump: extract log buffer and registers from
	vmcore on NMI button pressing

On Thu, Jun 03, 2010 at 11:01:38AM +0200, Vitaly Mayatskikh wrote:
> 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.

Vitaly, in this case it sounds like writting some user space utility to
display log buffers of previous kernel and pack into initrd/initramfs and
run that utility if network is down and hard disk does not have enough
space to store the dump.

I vaguely remember that dump filtering utility was doing something
similar.

> 
> Other possibilities of failure may include broken RAID controller,
> HDD, RAM. NMI button in such situations is a last chance to see old
> log.

Again, can't we do it with the help of user space utility packed in
initrd.

IMHO, somehow NMI button does not sound like a very good option. At max we
probably can look into doing this through sysrq option but I am not too
keen on that also until and unless we have good examples. You mentioned
that one might not be able to log in, but I am wondering why one would not
be able to login.

In kdump initrd, we can create one default policy that if you can't
capture dump, then try to save only log buffers of previous kernel. If
disk is broken, then just dump the buffers on console etc. This assumes
that console are at least being logged or somebody is looking at the
console. If not, one can always login and run the utility to dump buffers
again.

The only corner case which is not covered is that one can not login into
the system and somebody plugged in cosole later or console was shared. I 
am not sure how common that case is.

Making capture kernel print pervious kernel's buffers does not sound very
convincing to me, at this point. I will 

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists