public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Suparna Bhattacharya <suparna@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Faster reboots (and a better way of taking crashdumps?)
Date: Mon, 15 Apr 2002 15:37:29 +0530	[thread overview]
Message-ID: <20020415153729.A1708@in.ibm.com> (raw)
In-Reply-To: <1759496962.1018114339@[10.10.2.3]> <m18z80nrxc.fsf@frodo.biederman.org> <3CB1A9A8.1155722E@in.ibm.com> <m1ofgum81l.fsf@frodo.biederman.org> <20020409205636.A1234@in.ibm.com> <m1y9fvlfyb.fsf@frodo.biederman.org> <20020411192649.A1947@in.ibm.com> <m1hemil03d.fsf@frodo.biederman.org> <20020412201950.A1443@in.ibm.com> <m1sn60kdbs.fsf@frodo.biederman.org>

On Fri, Apr 12, 2002 at 11:59:35AM -0600, Eric W. Biederman wrote:
> Suparna Bhattacharya <suparna@in.ibm.com> writes:
> 
> > OK. The crash with bootimg implementation was known to have occasional
> > difficulties when boot got triggered (via panic) while in X -- sometimes 
> > having the console messed up, and on some occasions even hangs.
> > How's been your experience - no problems in kexec'ing from X, 
> > anytime ?
> 
> So far I haven't tried it from X.  Most of my test machines don't have
> video.  When working on a good machine you should be able to return
> the video to the state you got it.
> 
> I'm not quite certain how to handle the crash dump case.
>  
> > That would be machine_kexec, and the kimage struct, right ?
> > So far looks ok, though I haven't looked at it critically. One thing that 
> > that I require was a way to pass information across boots - 
> > maybe that could be done through command line parameters to the new 
> > kernel.
> 
> A command line work work.  You can arbitrary segments so you can pass
> anything that is needed from the user space side.
> 
> > > Version 2.0 is an early beta.  Some idiot yanked EM_486 and a couple
> > > of other symbols out of elf.h from glibc.  Despite the ELF spec says
> > > EM_486 at least should be there.  In any case that is just a debugging
> > > bit and you can safely disable those.  Or do a make -k and compile the
> > > kexec piece, but not the kparam, which isn't really relevant.
> > 
> > I commented out the EM_486 check from the kexec code, and it built
> > cleanly. I was able to boot a 2-way system with it, though it seemed
> > to take a while, perhaps more so because I didn't seem to be getting
> > any of the bootup/startup messages on my console. In one case there were 
> > some INIT respawning messages that came up. Not sure the fact that
> > I'm using a serial console matters.
> 
> A serial console is my usual test case, so that shouldn't affect
> anything.  I'm glad that it worked. 
> 
> For the speed difference my hunch is perhaps you didn't specify your
> normal kernel command line on the command line.  
> 
> Usually I do something like:
> kexec bzImage root=xxx console=ttyS0,9600 blah, blah, blah.
> 

Oh yes, thanks ! I forgot that kexec expects a command line - had become
used to bootimg picking up the current command line and passing it on.
With the right command line it seems to work ok.
It was an fsck that was taking a lot of that time :)

Regards
Suparna

> Mostly kexec is supposed to be the simple test client instead of a
> full fledged interface.
> 
> Eric

  reply	other threads:[~2002-04-15 10:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-07  1:32 Faster reboots (and a better way of taking crashdumps?) Martin J. Bligh
2002-04-07  2:50 ` Eric W. Biederman
2002-04-07  4:00   ` Martin J. Bligh
2002-04-07  4:12     ` Eric W. Biederman
2002-04-08 14:31   ` Suparna Bhattacharya
2002-04-08 17:09     ` Eric W. Biederman
2002-04-09 15:26       ` Suparna Bhattacharya
2002-04-10 15:40         ` Eric W. Biederman
2002-04-10 17:58           ` Andy Pfiffer
2002-04-11 14:15             ` Suparna Bhattacharya
2002-04-11 15:08             ` Eric W. Biederman
2002-04-16 10:02               ` Pavel Machek
2002-04-16 22:59                 ` Alan Cox
2002-04-11 13:56           ` Suparna Bhattacharya
2002-04-11 15:35             ` Eric W. Biederman
2002-04-12 14:49               ` Suparna Bhattacharya
2002-04-12 17:59                 ` Eric W. Biederman
2002-04-15 10:07                   ` Suparna Bhattacharya [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-05 19:13 Martin J. Bligh
2002-04-05 20:47 ` Jeremy Jackson
2002-04-06  1:48   ` Martin J. Bligh
2002-04-06  2:55     ` Jeremy Jackson
2002-04-08  7:20       ` Suparna Bhattacharya
2002-04-11  3:47         ` Jeremy Jackson
2002-04-11 14:28           ` Suparna Bhattacharya
2002-04-06 17:56 ` Alan Cox
2002-04-07  1:35   ` Martin J. Bligh
2002-04-06 23:27 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020415153729.A1708@in.ibm.com \
    --to=suparna@in.ibm.com \
    --cc=Martin.Bligh@us.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox