From: ebiederm@xmission.com (Eric W. Biederman)
To: suparna@in.ibm.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: 12 Apr 2002 11:59:35 -0600 [thread overview]
Message-ID: <m1sn60kdbs.fsf@frodo.biederman.org> (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>
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.
Mostly kexec is supposed to be the simple test client instead of a
full fledged interface.
Eric
next prev parent reply other threads:[~2002-04-12 18: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 [this message]
2002-04-15 10:07 ` Suparna Bhattacharya
-- 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=m1sn60kdbs.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=Martin.Bligh@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suparna@in.ibm.com \
/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