Re: Faster reboots (and a better way of taking crashdumps?)

Suparna Bhattacharya
2002-04-12T14:48:41Z

On Thu, Apr 11, 2002 at 09:35:34AM -0600, Eric W. Biederman wrote:
> Suparna Bhattacharya <suparna@in.ibm.com> writes:
>
>
> > OK. I hadn't looked at your user space pieces earlier, where you
> > patch in the code to jump to real-mode etc.
> > (from my perspective this seems to be the main difference vs bootimg)
>
> I have borrowed techniques from all over. And I will go with whatever
> works. In this case I don't see why bootimg wasn't doing that.
>
> > > Reseting the video mode like monte does is questionable.
> >
> > Could you explain that a bit ?
>
> 1) You should have done proper video shutdown before you left the
> previous kernel.
> 2) You might not have a video card.
> 3) You might not have a working BIOS.
> 4) It is generally a very good idea to make a division of who controls
> what hardware. And after the initial boot and the kernel has
> driven the hardware it isn't reliable to give control back to the
> BIOS. We may have changed state enough to confuse the BIOS.
>
> Or in summary it is generally unnecessary so why the heck are we doing
> it.

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 ?

>
> > > The basic point though is that the monte kernel interface is not set
> > > up to support anything but the linux kernel. The bootimg interface
> > > if fairly general, the user space just happens to be a little
> > > immature.
> >
> > I wasn't really looking at the system call interface as yet. That's
> > important of course, but I first wanted to be understand the actual
> > boot mechanism and the degree of reliability plus any known
> > limitations.
> >
> > The interface which is interesting to me ATM is actually the lower
> > level in-kernel interface to initate the boot with a preloaded image
> > (i.e after the segments are loaded into a kimage).
>
> O.k. Any comments, on that interface?

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.

>
> > > As for skipping the real mode setup code, I prefer to do that cleanly
> > > when it is needed.
> > >
> > > > At first I
> > > > thought some of your querybios stuff achieves a similar effect,
> > > > but then is that for linux bios ?
> > >
> > > Yes that is primarily for linuxbios. But that is when it is necessary
> > > to skip the real mode setup. But all you have to do is specify a
> >
> > OK. Now that I have seen your bzImage kexec userland code, I see the
> > missing link. When I'd looked at the older patches around
> > the time of our elfboot announcment, I couldn't locate the right
> > user space pieces, so things weren't clear.
>
> O.k. Given that I keep evolving this, that is understandable.
> Sorry about that.
>
> > > Unless I missed something the Linux kernel won't work on smp though.
> > > It is a matter of resetting the state of the apics, and ensuring you
> > > are running on the first processor. I don't believe bootimg did/does that.
> >
> > What I tried out was the MCLX crash dump implementation using bootimg
> > and that did work on a 2-way. This has some modifications to run on
> > the boot_cpu, and also to setup the local APIC and program the LVT0
> > register. (The pure bootimg patch I had was pretty old, so never
> > tried that out separately).
>
> O.k. cool. I haven't really looked at that.
>
> > I ran into some errors when building elfboottools.
> > EM_486 is reported to be undeclared. I think it must somehow be
> > picking up the wrong elf.h, but didn't dig around too much
> > into the makefiles.
>
> 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.

Regards
Suparna