[lkml]   [2011]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/9] kdump: Patch series for s390 support
    Hello Vivek,

    I attached a document where the s390 port is described in more detail.
    Perhaps this helps you to understand what want and what we are doing. If
    not - just delete it :-)


    On Thu, 2011-07-07 at 15:33 -0400, Vivek Goyal wrote:
    > On Wed, Jul 06, 2011 at 11:24:47AM +0200, Michael Holzheu wrote:
    > > Hello Vivec,
    > >
    > > On Tue, 2011-07-05 at 16:26 -0400, Vivek Goyal wrote:
    > > > On Mon, Jul 04, 2011 at 07:09:22PM +0200, Michael Holzheu wrote:
    > >
    > > [snip]
    > >
    > > > I don't understand what is stand-alone dump tools and
    > >
    > > S390 stand-alone dump tools are independent mini operating systems that
    > > are installed on disks or tapes. When a dump should be created, these
    > > stand-alone dump tools are booted. All that they do is to write the dump
    > > (current memory plus the CPU registers) to the disk/tape device.
    > >
    > > The advantage compared to kdump is that since they are freshly loaded
    > > into memory they can't be overwritten in memory.
    > > Another advantage is
    > > that since it is different code, it is much less likely that the dump
    > > tool will run into the same problem than the previously crashed kernel.
    > I think in practice this is not really a problem. If your kernel
    > is not stable enough to even boot and copy a file, then most likely
    > it has not even been deployed. The very fact that a kernel has been
    > up and running verifies that it is a stable kernel for that machine
    > and is capable of capturing the dump.
    > > Also the boot process ensures that the hardware is in a initialized
    > > state.
    > Who makes sure that hardware is in initiliazed state? Kdump kernel,
    > stand alone kernel or BIOS.
    > > And last but not least, with the stand-alone dump tools you can
    > > dump early kernel problems which is not possible using kdump, because
    > > you can't dump before the kdump kernel has been loaded with kexec.
    > >
    > That is one limitation but again if your kernel can't even boot,
    > it is not ready to ship and it is more of a development issue and
    > there are other ways to debug problems. So I would not worry too
    > much about it.
    > On a side note, few months back there were folks who were trying
    > to enhance bootloaders to be able to prepare basic environment so
    > that a kdump kernel can boot even in the event of early first
    > kernel boot.
    > > That were more or less the arguments, why we did not support kdump in
    > > the past.
    > >
    > > In order to increase dump reliability with kdump, we now implemented a
    > > two stage approach. The stand-alone dump tools first check via meminfo,
    > > if kdump is valid using checksums. If kdump is loaded and healthy it is
    > > started. Otherwise the stand-alone dump tools create a full-blown
    > > stand-alone dump.
    > kexec-tools purgatory code also checks the checksum of loaded kernel
    > and other information and next kernel boot starts only if nothing
    > has been corrupted in first kernel. So this additional meminfo strucutres
    > and need of checksums sounds unnecessary. I think what you do need is
    > that somehow invoking second hook (s390 specific stand alone kernel)
    > in case primary kernel is corrupted.
    > >
    > > With this approach we still keep our s390 dump reliability and gain the
    > > great kdump features, e.g. distributor installer support, dump filtering
    > > with makedumpfile, etc.
    > >
    > > > why the existing
    > > > mechanism of preparing ELF headers to describe all the above info
    > > > and just passing the address of header on kernel commnad line
    > > > (crashkernel=) will not work for s390. Introducing an entirely new
    > > > infrastructure for communicating the same information does not
    > > > sound too exciting.
    > >
    > > We need the meminfo interface anyway for the two stage approach. The
    > > stand-alone dump tools have to find and verify the kdump kernel in order
    > > to start it.
    > kexec-tools does this verification already. We verify the checksum of
    > all the loaded information in reserved area. So why introduce this
    > meminfo interface.
    > > Therefore the interface is there and can be used. Also
    > > creating the ELF header in the 2nd kernel is more flexible and easier
    > > IMHO:
    > > * You do not have to care about memory or CPU hotplug.
    > Reloading the kernel upon memory or cpu hotplug should be trivial. This
    > does not justify to move away from standard ELF interface and creation
    > of a new one.
    > > * You do not have to preallocate CPU crash notes etc.
    > Its a small per cpu area. Looks like otherwise you will create meminfo
    > areas otherwise.
    > > * It works independently from the tool/mechanism that loads the kdump
    > > kernel into memory. E.g. we have the idea to load the kdump kernel at
    > > boot time into the crashkernel memory (not via the kexec_load system
    > > call). That would solve the main kdump problems: The kdump kernel can't
    > > be overwritten by I/O and also early kernel problems could then be
    > > dumped using kdump.
    > Can you give more details how exactly it works. I know very little about
    > s390 dump mechanism.
    > When do you load kdump kernel and who does it?
    > Who gets the control first after crash?
    > To me it looked like that you regularly load kdump kernel and if that
    > is corrupted then somehow you boot standalone kernel. So corruption
    > of kdump kernel should not be a issue for you.
    > Do you load kdump kenrel from some tape/storage after system crash. Where
    > does bootloader lies and how do you make sure it is not corrupted and
    > associated device is in good condition.
    > To me we should not create a arch specific way of passing information
    > between kernels. Stand alone kernel should be able to parse the
    > ELF headers which contains all the relevant info. They have already
    > been checksum verified.
    > Thanks
    > Vivek

    [unhandled content-type:application/pdf]
     \ /
      Last update: 2011-07-08 16:05    [W:0.035 / U:35.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site