> On Fri, 5 Apr 2002, Jeremy Jackson wrote:
> > ----- Original Message -----
> > From: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
> > Sent: Friday, April 05, 2002 5:48 PM
> > > I need to avoid going through the BIOS ... this is a
> > > multiquad NUMA machine, and it doesn't take kindly
> > > to the reboot through the BIOS for various reasons.
> > > It also takes about 4 minutes, which is a pain ;-)
> > >
> > > I have source code access to our BIOS if I really wanted,
> > > I just want to avoid modifying it if possible.
> > well keep in mind that the fastest LinuxBIOS boot is 3 seconds...
[ to login prompt ]
> > a large part of the boot time on most PCs is the BIOS setting up
> > DOS support and painting silly logos on the screen, all of which
> > can go away. I'm guessing your NUMA system has a bit more
> > to do at this stage due to the hardware, but still...
Especially given that I can load the kernel on a dual P4 xeon system in
3 seconds from power on. But traditional BIOS's are slow, and getting
slower for unknown reasons.
> Wouldn't it be easier to just ljmp to the start address of the kernel in memory
> (the address after the bootloader has done its thing), effectively restarting
> the kernel from line 1? Or is tehre an issue with some hardware being in an
> invalid state when doing this?
> Maybe Eric Biederman can comment on this since he's adding new functionality to
> the boot loader..
I've also written the patch that allows this.
In the general case where you want to boot another version of the kernel
you must rerun the BIOS query code. In case your new kernel can handle your
hardware better than the previous version.
The are bad cases where the kernel can leave the hardware in a state
that either confuses the BIOS or confuses the drivers when they load.
This is rare and being worked on. But it is an independent problem.
And despite the name I can kexec plain bzImages, now.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/